当团队成员都能用 AI 写出小应用，新的瓶颈往往出现在应用写完之后：放在哪里、谁能访问、如何共享技能，以及不同工具怎样使用同一套业务数据。
公众号“数字生命卡兹克”记录了一次针对其 30 多人团队的 AI 改造。作者在约五天内，从品牌视觉规范做起，逐步搭建出基于飞书数据、由 MCP 连接 Agent 的内部协作中台。以下按业务问题整理这一案例；其中开发时间和使用效果均为原作者自述。
起点：人人会做应用，部署与协作却没有统一入口
原文团队的人力、财务、运营、内容和商务等岗位，已经会借助 AI 编程为自己或同事制作小工具。
一个例子是开票助手。过去商务需要开票时，要向财务说明项目和金额，再由双方反复确认。财务制作的小应用与项目表打通后，商务可以直接提交申请，财务收到飞书机器人通知，核对后继续处理。
单个流程变顺畅了，但团队还面临几个共性问题：
- 应用作者不熟悉服务器部署，工具容易停留在个人电脑上。
- 有价值的应用没有共享入口，其他同事不知道它存在。
- 部分工具只能给自己或特定成员使用，需要访问权限。
- Skills、PPT 模板、品牌资料散落在各处，版本与使用方式不统一。
这让改造目标从“再写几个工具”，转向“建立能够持续交付工具的内部平台”。
先统一品牌规范，再让 Agent 使用规范
作者先让 AI 根据已有 Logo 延展品牌 VI，包括字号、排版和辅助图形。在此基础上，又制作了 UI 组件与 PPT 模板，并补充团队经常使用的数据展示场景。
原文提到，辅助图形的讨论耗时较长，而组件和模板的生成更接近大模型擅长的任务。PPT 模板扩展到 100 多页，覆盖多种业务展示需求。
关键变化发生在交付形式上：这些资料没有只作为文档放进知识库，而是进一步包装成设计组件 Skill 和 PPT Skill。这样，成员在使用 Agent 制作页面或演示文稿时，可以直接调用品牌规则和模板。
对团队而言，可复用的资产至少包含两层：一层是组件、模板和素材，另一层是告诉 Agent 何时使用、如何使用这些资产的规则。想了解 Skills 的组织方式，可参考本站的 Claude Code Skills 使用说明。
飞书承载数据，中台重组入口和体验
原作者的团队长期使用飞书，项目进度、文档和业务记录主要存在多维表格与文档中。因此，自建中台的方向并非重新搬迁全部数据，而是在既有数据上增加一个更适合 Agent 与团队使用的操作层。
按原文描述，中台复用飞书身份与权限，并与相关文档、多维表格保持同步。作者还把自定义网页配置成飞书工作台入口，让成员从日常使用的办公入口进入新平台。
这部分可以借鉴的重点是：先识别现有数据和身份体系，再决定增加哪些界面与操作能力。是否能复用具体权限、做到怎样的同步频率，仍取决于实际使用的飞书接口、授权范围和应用配置。
中台初期主要提供应用、Skills、资料和 OKR 等模块。其中，应用和 Skills 是连接个人创造与团队复用的核心。
应用广场：让 Agent 接管部署流程
作者租用公司服务器，并把内部中台的部署能力包装成 MCP，供员工自己的 Agent 调用。原文展示的流程是：
- 成员按内部指引，把 Claude 或 Codex 等 Agent 接入中台 MCP。
- 在应用页面复制发布提示，回到项目目录交给 Agent。
- Agent 调用中台提供的能力，在服务器上安排部署、账号关联和访问权限。
- 平台为应用分配子域名，并把应用展示到团队入口。
按作者描述，如果项目尚未确定产品名、域名或图标，Agent 也会协助补齐。应用发布过程中还会询问访问范围，例如仅自己使用、指定成员使用或面向全公司，之后可以调整。
这使团队成员面对的是一个发布流程，而不必每次独立研究服务器、域名和权限配置。不过，原文未公开该中台 MCP 的完整实现和安装地址，也未给出服务器隔离、发布回滚等技术细节，因此不能把案例当成可直接复制的开源部署教程。
业务样例：把 Excel、邮件与项目表串起来
原文用商务流程说明应用广场的价值。
该团队承接项目后，客户可能返回 Excel 或飞书表格。商务需要整理信息、生成邮件，再由执行同事录入项目底表。重复录入既占用时间，也容易因字段理解不同产生错误。
作者制作的小应用将这几个步骤连接起来：
- 上传项目表格，并检查识别出的项目信息。
- 关联对应同事，生成邮件模板。
- 将邮件放入草稿箱，并安排相关抄送人。
- 确认后把结构化信息写入项目底表，交给后续岗位处理。
这里保留了人工检查的步骤。邮件生成和数据写入由程序协助，业务含义与关键信息仍需要负责同事确认。
原作者还记录了一次反馈闭环：先交给商务试用，再用一次约 15 分钟的会议收集逻辑问题和体验建议，把录音转出的文字总结交给 AI 继续修改。其自述开发初版约一小时，后续修改约半小时；这些时间反映的是该团队特定流程和现有基础，不能作为所有企业项目的工期估算。
Skills、资料和个性化首页
应用之外，中台也承担 Skills 的上传与分发。按原文描述，平台发现本地 Skill 版本与平台版本不同，会提示成员更新。品牌 VI、PPT 模板和组件库则进入统一资料入口。
作者还制作了 OKR 可视化页面，并允许每位成员通过 Agent 调整自己的首页。
成员复制“改我的首页”的提示，告诉 Agent 希望查看哪些模块和数据；Agent 再通过 MCP 读取相应信息、使用公司品牌与页面组件，生成与该成员账号关联的首页。
这一设计体现了 Agent 参与配置的思路，也带来一个使用门槛：原文平台几乎没有传统的手动配置界面，不习惯使用 Agent 的成员修改页面会更困难。团队落地时，需要结合成员习惯决定保留哪些可直接操作的入口。
数据治理：让自动化使用经过确认的规则
原作者把后续工作的重点放在业务数据与上下文上。团队利用 Agent 梳理过去人工录入留下的异常，推演字段之间的规则，再由成员确认统一口径。
这个过程适合拆成三步理解：先列出异常项，再确认业务规则，最后按确认后的规则修正和持续维护。AI 能帮助发现不一致，却不能仅凭模型推演就保证所有业务数据正确。
数据、规则、历史上下文与岗位间的协作关系，会随着应用使用逐步积累。相比一次生成多少页面，这些积累更直接影响工具能否长期运行。
这次案例能借鉴什么
这个中台在原文发布时仍处于早期，作者也明确提到维护问题和后续困难仍有待解决。
对已经在使用 AI 编程的团队，它提供了一条具体路径：从真实的重复工作出发，统一数据与身份，再补应用部署入口、技能分发和反馈机制。一个小工具被同事发现、使用、提出问题并继续改进，才形成完整的协作闭环。
原作者期待的场景是：新成员发现流程可以改善后，能够借助 Agent 做出新应用，再通过统一平台交给团队使用。这个目标要求系统既方便创造，也能管理权限、规则和维护责任。
