一家 30 多人的公司，创始人花了 5 天时间，把公司从品牌视觉到应用部署，整个重做了一遍。

这件事值得一号位读，不是因为他用了什么新技术——恰恰相反，他做的事里几乎没有新东西。品牌 VI、设计组件、PPT 模板、知识库、中台，都是早就在讲的东西。

真正的新东西只有一处：他把这些全部交给了 AI 去生产和维护，然后用一套规则，让公司里每个人都能调用。

他的原话是，过去很长时间，他一直在想一件事：AI 时代，公司里的同事究竟该怎么协同。

先把痛点讲清楚。

这家公司里，人人都用 AI 已经是常态——人力、财务、运营、内容、行政、商务，都会自己动手做一个自己的产品，甚至给合作的同事做一个产品。

最典型的一个例子是财务。过去商务要开一张发票，都得跟财务说一句「帮我开个 XX 的发票」，来回沟通，成本不低。财务干脆自己动手，做了一个开票助手，直接跟公司整体的项目表打通：商务自助申请，财务收到机器人通知，核对一下，一键开出。

两边都省事，评价很高。

但问题跟着就来了。

大家创造的应用，怎么部署到服务器？怎么做权限管理？怎么只让特定的人可以用？还有各种 Skill 的协同和分发，怎么管？

这几件事很难协同，而且必须有人定顶层规则。这是这件事的第一个关键判断：它不是技术问题，是一号位要拍的组织问题。

本文所据，是一家外部公司创始人自己公开的复盘记录，所引细节均出自其公开表述，量级可参考。

他做的第一件事，是品牌 VI。

起因很朴素：logo 早就设计了，但品牌的视觉统一性一直是乱的。他把整套 VI 交给 AI 来做——延展、字号、排版都快，最慢的是辅助图形，他和 AI 来回讨论了一个多小时才定下来。整套做完，除了辅助图形，不到一个小时。

第二件事，是 UI 设计组件。

因为公司里人人都在自己搭产品，做出来的界面参差不齐，没有一套完整的体验。他索性做了一套设计组件。他本人是 UI 设计师出身，这一次几乎一个组件都没改，只额外提了一轮需求：把数据展示类的组件饱和式地补上。做完不到一个小时。

第三件事，是 PPT 模板。

他嫌公司原来的 PPT 模板太乱，于是又花了一个小时，做完了整套品牌 PPT——一百多页，基本把所有情况都考虑进去了，每一页都有细腻的原生动效。

三件事做完，他把它们包装成了两个 Skill：一个管 PPT，一个管设计组件。

这一步的意义不在省了一个设计师，而在于：公司对外呈现的每一份东西，从此有了同一个来源。

东西做出来了，新的问题马上来了：同事怎么用？

把组件库和 PPT 库传到知识库上，让所有人自己看？他的评价是：太原始了。

他把两件事叠在一起看：一件是同事做的应用没人会部署、没人会分享；另一件是公司所有的数据、项目进度、文档，都长在一套现成的协同平台上，而那套平台的工作台满足不了他们的需求。

于是他想要的，不是「一个分享的地方」，而是一个更底层的中台——以 Agent 操作为原生、以公司现有的数据为基建。

他给的决定时间很短：10 月 4 号，犹豫了 20 分钟，说了句「干」。两天以后，中台就出来了。

这里有个冷知识值得记下来：那套协同平台支持把工作台入口配置成公司自己的网页。也就是说，用一个自己的域名，就能替换掉原生的工作台——同事进平台，点工作台，自动进入公司自己的中台，体验极其顺畅。

更关键的是，因为数据底层全部来自那套平台，所以文档、多维表格里的数据都是实时同步的；权限体系也直接复用了，不用重新搭，安全性也保得住。

中台最核心的是两个 Tab：应用，和 Skill。

应用 Tab 就是一个公司内部的应用广场——同事做的应用，在这里上架、分享、被使用。上线初期，上面已经挂了几个同事自己做的东西。

Skill 更简单，直接上传就行。如果平台检测到本地版本和平台版本不一致，中台会提醒你更新。

这两个 Tab，才是他一定要自建中台的原因。

前面铺垫的所有东西，都是为了解决这一个问题：同事做的应用，怎么部署到公司服务器上，还要管得住权限。

他的选择是租一台属于公司的服务器，然后把整个中台包装成一个 MCP。

MCP 是模型和外部工具之间的标准接口。包装成 MCP 之后，部署这件事就变成了三步。

第一步，把你的 Agent 连上中台。你只需要把页面上的一段 Prompt 发给你的 Agent，它就能自动安装中台的 MCP；因为走的是原来的账号登录，权限天然可控。

第二步，在应用页面点右上角的「发布我的应用」，复制那段 Prompt，打开你项目的文件夹，粘贴发送。

第三步，中台的 MCP 会自动在服务器上把项目做好隔离，跟账号 ID 和权限绑定，然后部署上线。

还有两个顺手的规范。域名：所有通过中台部署的应用，都会自动分配一个子域名，Agent 会根据你的项目名自动分配；如果项目连产品名都没有，Agent 会把产品名、域名甚至图标一起做好。

权限范围：发布过程中，Agent 会自动问你一句，你希望的权限配置是什么样的？是自己用，还是指定同事可见。发布之后还能随时改。

为了验证这条路，他拿商务团队的流程做了个 Demo。

过去的流程是：商务接到需求，整理一份投放组合给品牌方；品牌方确认后，回一个 Excel 或者在线表格链接；商务同学根据表格内容再整理一封邮件；最后广告执行同学把整个表格录入项目表。问题就出在最后一步，录入过程中经常出错。

他做的小应用，把这几步压成了三屏：录入项目、上传 Excel、确认信息，相关同事自动关联出来；下一步直接生成一封邮件模板，可以导入邮箱、存进草稿箱，自动抄送相关负责人；再下一步，把项目数据导入项目底表，交给后面的执行同学。

他自己的理念是：这种事务性、机械性的工作，能不让人做就不让人做。

这个应用开发只用了一个小时。第二天的过程更有意思：他让几个商务同学体验，然后直接拉了个会，让大家当场说问题，全程开着录音。15 分钟把流程里不对的地方和想优化的点说完，拿到一份纯文字的总结，直接扔回给 AI，让它按这份总结去改逻辑。又半个小时，改完了。

这件事真正的门槛，从来不是开发——一个小时就够。门槛是有没有人，愿意来定这套规则。

这套中台有一个设计，最能说明问题：每个人的首页都是千人千面的。

每位同学都可以自己调整首页关注的模块、看的数据，甚至放一张自己喜欢的照片。做法是：把一段话发给自己的 Agent，告诉它你想在首页看到什么；Agent 读取中台和规则，给你做出一个符合你需求的首页，并且跟你的账号 ID 绑定。

但这里有个尴尬的地方：因为中台没有任何人工配置的入口，如果你想用传统的方式去改首页，几乎做不到。如果你平时不常用 Agent，在这个中台里会寸步难行——甚至可能连首页都改不了。

反过来，越会用 Agent 的人，在这里就越顺手。

更彻底的一件事是数据。他们现在所有的多维表格、所有跟数字相关的数据，全部交给 Agent 自动维护。他的评价是：录入和规则设计，比人做的强太多。

过去人工录入留下的错误，会堆成一座座数据屎山。现在的做法是：让 Agent 把规则全部推演一遍，跟团队确认后，列出一份异常项清单，大家统一口径，把过去遗漏的逻辑和规则清掉。

他给出的判断是：数据和 Context，以及被构建起来的协同关系，是一个企业在未来最核心的资产。

所以这件事的落点，最后落在了一句很轻的话上。

他希望有一天，公司新来的同学入职第一天，发现某个流程很蠢，跑去问旁边的同事：「你们这个新人流程怎么这么麻烦啊？」同事很自然地回他一句：「是吗，那你让 Agent 改一下呗。」

第二天，一个新的应用上线了，它代表一个新的流程，整个公司都用上了他改好的版本。

过去，我们总是在想怎么让员工适应公司的系统。未来，或许终于轮到公司、公司的系统、公司的知识，去适应每一个活生生的人了。

这周先做一件事：

这套东西晚做一年，最贵的不是服务器和 token，是你公司里那几个已经在自己动手做应用的人，会先凉下来。