你有没有遇到过这种情况——
团队里每个人都在推进，方向也都没错，但系统却越来越像一堆散件，而不是一台机器。
这是企业级 AI 项目最典型的死法之一。
今天我们开了一场会，专门聊怎么防止这件事发生。
不是因为出了什么惊天动地的新功能，而是因为我们越来越清楚：
一个企业级 AI 项目，难的从来不只是把功能做出来，而是让人、流程、知识和 Agent，在同一套系统里协调地往前走。
今天会上聊了文档、协作、多 Agent、上下文、测试、提交流程。看起来分散，但把它们放在一起，其实都在回答同一个问题：
企业级 AI，到底怎么从“能跑”走向“可持续”。
一、当团队开始认真整理文档，系统才算真正进入工程阶段
这两天，团队把docs目录重新整理了一轮。
表面上看，只是文档结构更清楚了。但如果你做过稍微复杂一点的项目就会知道：
一个团队开始认真对待文档，往往说明它已经不满足于“先跑起来”，而是开始考虑：以后，怎么持续演进。
这次整理里，有两个东西特别关键。
1）协作待办，从 Bug 流程里独立出来了
Bug 还是 Bug，修复、验证，按流程闭环。
但那些长期推进的需求、模块任务、协作事项，不再混在缺陷列表里，而是有了单独的协作待办，分成四种状态：
认领中
已完成
已取消
阻塞中
这件事看似基础，其实很重要。
多人协作系统最容易出现的问题，不是没人做事，而是每个人都在做事，却没人知道别人做到哪一步了。
更重要的是，这份待办不只是给人看的，也是给 AI 看的。
谁认领了、谁在做、谁阻塞了——这些状态一旦清楚，AI 就知道哪些任务被锁定、哪些模块正在推进、哪些地方不该重复介入。
文档不再只是“记录”，而开始参与协作本身。
2）ADR 被引入了：记录的不只是“现在是什么”，还有“为什么会这样”
ADR，全称Architecture Decision Record，架构决策记录。
它的意义不在于把事情写得更正式，而在于——给系统留下演化记忆。
任何一个复杂系统，当你问它“你为什么会变成这样”，最可怕的答案不是“有 bug”，而是：
“不知道，反正就变成这样了。”
ADR 就是在对抗这件事。
当初为什么这么设计？这个选择替代了什么？这个变化是临时方案，还是长期方向？
这些问题，ADR 都在留答案。
很多系统最后变乱，不是因为没人写代码，而是因为没人持续记录：
我们为什么会走到这里。
而在 AI 参与越来越深的情况下，这件事比以前更重要。
因为文档不仅是给人看的，它也是 AI 能不能理解系统、跟上系统的前提。
二、多 Agent 协作，我们没有急着押宝，而是让三条路同时接受检验
今天信息量最大的一块，是多 Agent 协作。
目前团队同时在跑三种模式，而且都已经进入集成测试阶段。
很多人在做多 Agent 时，第一反应是：
“到底哪种模式最好？”
但真实工程里，这个问题往往没有标准答案。不同任务，对协作方式的要求本来就不一样。
所以我们没有先押宝某一种，而是让三条路同时跑，让真实任务场景来给出反馈。
第一条：交叉验证模式
每个 Agent 都拿到完整上下文，从不同角度独立思考，再互相验证结论。
它强调的不是分工，而是多视角校验。
适合那些结论质量要求高、不能太依赖单一路径判断的任务。
第二条：多 Teams 模式
任务先拆分，交给不同 Team 或子 Agent 分别推进，Team 内部再做循环校验。
它更像标准工程分工：
边界明确
效率优先
适合可拆解、可并行的任务
第三条：黑板模式
每个 Agent 先做自己的部分，再把结果汇总到一块“黑板”上，由 Leader Agent 统一审阅和收敛输出。
它更像现实世界的项目组协作：
先分头做
最后集中拍板
这三条路线背后，对应的是三种协作哲学：
多视角碰撞
并行分工推进
中心角色收敛
哪条最终更优，今天还没有结论。但有一件事已经越来越明确：
多 Agent 的难点，不在于把 Agent 变多，而在于让它们形成有效协作。
演示系统喜欢展示“我能调起几个 Agent”；真正要落地的系统，更在意的是：
这些 Agent 到底怎么分工
怎么校验
怎么收敛
最后能不能稳定地产出结果
这，就是企业级 AI 和演示型 AI 的区别之一。
三、一个“上下文小问题”，背后是企业 AI 的核心命题
今天还有一个讨论，越聊越大。
起点只是个看起来不大的问题：
当用户进入飞书和 AI 对话时，系统能不能知道这个人是谁、在组织里是什么角色、和其他人是什么关系？
目前，这件事还没完全做好。
于是问题来了：
要不要把组织架构直接注入上下文，让 AI 一进来就“认人”？
这个想法听起来很顺。但只要继续往下问两句，就会碰到真正的难点：
如果组织有几百人，是否值得每次全量注入？
如果不全量注入，应该在什么时候触发召回？
如果要召回，要不要先做意图识别？
你会发现，一个“把用户身份带进去”的小问题，往下拆，已经连到了三件事：
上下文管理
记忆召回
意图识别
而这三件事，恰恰构成了企业级 AI 体验最关键的一条链路。
很多人把注意力放在“模型回得好不好”，但越往后做越会发现，真正决定体验上限的，往往不是模型说了什么，而是：
在它开口之前，系统到底给了它怎样的上下文。
模型只是最后负责表达。真正决定智能边界的，是上下文组织能力。
四、那些“不性感”的工程细节，反而最决定系统能不能跑稳
今天会里还有一部分内容，很日常，但我反而觉得特别重要。
比如提交节奏：
先本地验证，再推代码；先独立提交，再集中同步。
有人已经在多个 Worktree 上并行开发，每条线各自推进、各自测试，最后统一合并。
这其实是在速度和秩序之间，寻找一个现实可行的平衡点。
再比如测试环境。
自动化流水线还不够完善，部分流程仍依赖手动打包。短期看只是“麻烦”，长期看它会直接决定团队的验证效率和协作质量。
还有一个细节：
有成员开始各自申请自己的飞书机器人，在本地直接验证功能，而不是被动等测试环境发版。
这些事情单独看都不大。
但真正做项目的人都知道：
决定一个系统能不能长期稳定演进的，往往不是最耀眼的新功能，而是这些最容易被忽视的工程纪律。
因为系统一旦复杂起来，真正拖垮迭代速度的，通常不是“不会做”，而是：
明明做了，却总是接不上、测不稳、收不拢。
五、项目做到这一步，协作本身已经成了核心能力
今天会上另一个感受也很强：
每个人都在往前推，而且推的方向都不一样。
有人在做多 Agent 协作，有人在补上下文工程，有人在写知识图谱和 Wiki 页面，有人在做测试集和接口测试，也有人在整理文档、补护栏、补规范。
项目是活的，而且活得很快。
但项目越快，另一个问题就越突出：
信息扩散的速度，已经开始比代码提交的速度更快。
你这边刚改了某个 session 的逻辑，另一边可能还在基于旧假设设计 Agent；
你这边刚对知识库做了兼容降级，另一边可能还默认它一定存在。
所以今天最重要的，不是哪一个功能又多做完了一截，而是大家越来越主动地说清楚：
我在做什么
现在做到哪一步
接下来可能影响哪里
哪些地方别人先别碰
这件事，在传统研发里叫“协同”；在 AI 深度参与研发之后，它已经更像一种核心工程能力。
因为当参与者除了人，还包括 AI 和 Agent 时，“说清楚”本身，就是生产力的一部分。
六、第十天，我们还没有答案，但已经开始长出方法
十天前，我们还在讨论：
这个项目到底要做成什么样。
十天后，很多东西都变了——
我们开始并行测试不同的 Agent 协作模式，开始认真搭文档体系，开始讨论上下文、记忆、检索之间怎么协同，开始给测试和提交补纪律，也开始意识到：
真正难的不是功能本身，而是系统如何在持续变化中保持一致性。
项目当然还没有完成。很多机制还在搭，很多问题还没彻底解决，新的麻烦也一定还会继续冒出来。
但有一件事已经越来越清楚：
一个企业级 AI 系统的成熟，不会因为某个瞬间突然到来。它是在每天多讲清楚一件事、多补完整一条规则、多做顺一次协作的过程中，慢慢长出来的。
这，是第十天。
不是一个阶段的结束，而是一个系统开始真正长出“方法”和“秩序”的时刻。
《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。
