AI Coding进入深水区，我们最近一个月到底改了什么

最近一个月，团队在 AI Coding 上又往前走了一段。

如果只看表面，我们做的事情还是那些：用 AI 写 PRD、查业务、出方案、改代码，再想办法把整套流程搬到云端。可越往下做，我越发现问题早就不只是“模型能不能写代码”了。

我们开始面对两个更难的问题。

一个是，怎么把人的业务知识变成 AI 可以长期使用、团队也可以持续维护的工程资产。另一个是，怎么在 AI 的自由和传统软件的确定性之间，找到一个可以长期运行的平衡。

这两个问题，刚好对应了最近一个月 PRD skill 和 Zeus Talos 的两次变化。

第一版PRD Skill，先解决了信息差

最开始做 PRD skill 时，我们先制定了一版非常标准、也非常详细的需求文档模板。

那一版一共有 10 个大章节。除了需求来源、背景目标和功能详细说明，还包含独立的非目标、系统范围、项目方案描述、非功能需求、核心验收标准、上线计划、其他事项和版本历史。

再往下拆，还有组织范围、目标用户和典型场景、系统模块规划、业务流程、表单与状态、页面定位、接口语义、入参出参、错误码、功能级 DoD、业务度量验收、上线步骤……

现在回头看，确实有点多。但在刚开始的时候，我们想得也很直接：先把一份标准 PRD 可能需要的信息尽量列全，再让 AI 按照模板一步步引导产品经理补齐。

第一版 /req-prd-draft 就是在这个基础上做出来的。

运行一段时间以后，好的地方很快就体现出来了。产品同学最大的收益，是写 PRD 时不需要再到处问研发各种业务逻辑，也不需要自己一点点体验系统，一边猜测、一边总结。

Zeus 会先读已有的业务知识，再去真实代码里确认系统现在是怎么运行的，最后把线上已经完成的业务逻辑整理出来。

这件事看起来只是少问了几个人，实际解决的是一个长期存在的信息差：过去大量业务事实只存在于研发的代码和少数人的经验里，产品经理想写清楚现状，往往要靠人肉拼图。现在，这部分信息开始能够被直接查证和复用。

这是第一版 PRD skill 最明确的价值。

产品经理也需要参与Skill的建设

当然，不好的反馈也很快出现了。

产品同学提得最多的两个问题，一个是不会用 Git，另一个是为什么原型图不能每次都自动、稳定地生成。

这两个问题，我当时直接忽略了。也不能说完全忽略吧，就是选择不想回答。

因为我认真想过，第一版 PRD skill 是我写的，但我又不是每天写 PRD 的人。一个并不高频使用它的人，按照自己的理解设计出来的 skill，可能也就 60 分。

剩下的 40 分，不可能继续靠我坐在这里猜。

最清楚哪个问题影响效率、哪一段引导最别扭、哪种原型容易失败的人，还是每天使用它的产品同学。如果产品同学不学习怎么调整 skill，也不掌握最基础的 Git 使用，就很难自驱动地完成知识库和 skill 的工程化建设，更谈不上持续迭代。

最后很容易又回到原来的状态：每个人电脑上都有一个自己的 skill，各自改得挺顺手，但无法共享，也没有一份团队共同维护的真源。

我们现在的实际情况，其实也差不多。我仍然在努力让产品同学接受这个观点。

Git 不是为了把产品经理变成研发，skill 编写也不是要让每个人都去研究模型。它们只是新的协作基础。既然需求知识已经开始以代码和文件的方式被 AI 使用，那么负责这些知识的人，也需要能够参与维护它。

AI Coding 不是多安装一个工具，而是开始参与一套新的工程协作方式。

PRD写得越完整，评审反而越困难

产品侧的收益逐渐明确以后，研发侧的反馈也开始集中到几个问题上：PRD 字太多、内容重复、排版不好。

更现实的问题是，产品经理评审时大概只讲了整份文档的 20%。剩下的内容虽然写在 PRD 里，但在这么大的信息量下，技术同学很难判断哪些是产品已经确认的决策，哪些只是模板要求补出来的信息，也就很难评估 PRD 本身的质量。

这让我意识到，文档完整和信息有效不是一回事。

一份 PRD 如果在背景、系统范围、项目方案、功能详述和验收标准里反复描述同一件事，看起来很完整，实际上会让重要信息被重复内容淹没。评审的人需要不断判断“这句话前面是不是已经说过”“两个章节为什么口径不完全一样”，注意力也就离产品决策本身越来越远。

所以最近我们对整批 PRD skill 做了一次比较大的调整。核心不是再增加模板能力，而是做减法。

原来的 10 个大章节被收敛成了 7 个。独立的“非目标”、系统范围、项目方案描述、核心验收标准、研发上线步骤和其他事项，要么被删除，要么被放回对应的章节。

现在，范围只有一个真源，就是功能地图。每个功能都有稳定的 FR-ID，并按照业务旅程组织。只有真的存在多角色、多渠道、多页面时，才保留覆盖矩阵；只有存在跨功能流转时，才需要流程和共享规则。

功能详述也不再套固定的大骨架，而是根据功能形态组织。每个功能重点写清楚：现在是什么、这次改什么、规则和结果是什么、有哪些例外、什么明确不变。

可测条件和必要边界直接写在对应功能里，不再单独复制一遍验收章节。技术证据进入 plan.md，测试穷举进入 test-plan.md，大表和完整枚举进入附件，原型源码留在 mockups/，PRD 里只放评审需要的静态截图。

说到底，就是让 PRD 主文只承载产品决策，而不是把调研、技术方案、原型工程和测试用例全塞进同一个文件。

这次调整以后，我感觉 PRD 这一批 skill 大概可以从 60 分提高到 80 分了。

从一个Skill，变成一组协作流程

这批能力现在也不再挤在一个大而全的 skill 里，而是有了比较清楚的分工。

• req-prd-explore 负责只读调研业务和系统现状，把结论和证据整理出来。
• req-prd-draft 负责从一句话、BRD 或已有草稿开始，引导生成结构化 PRD。
• req-prd-revise 负责修改已有 PRD，并保证一次改动涉及的章节能够同步更新。
• req-prd-mockup 负责单独生成或重做改动原型，不把原型源码混进 PRD。
• req-prd-check 负责检查完整性、可测性、业务一致性、影响面和信息密度。

它们合在一起，才是一套能够持续运转的 PRD 工作流。

产品经理可以先用 explore 查清楚现状，再用 draft 起草，用 revise 持续修改，需要页面表达时生成 mockup，评审前再通过 check 做质量检查。每个 skill 只承担一类职责，产物也有各自的边界。

这其实和我们后来对 Zeus、Talos 的重新设计很像：不是试图让一个 AI 会做所有事情，而是先把不同层次的问题拆开。

Talos在自由和控制之间走了两个极端

我最初设计 Talos 时，就思考过一个问题：是不是直接把 Zeus 工作流起一个“小龙虾”就可以了？

让它自己观察任务、调用 Zeus、判断下一步，遇到问题也自己处理。这样看起来既智能又自由，也很符合大家对 Agent 的想象。

但我当时的判断是，产研工作流不能这么无约束地自由。什么时候可以修改代码，什么时候应该重试，什么时候必须停止，什么风险一定要交给人，这些都需要明确的逻辑约束。

所以我选择自己做 Talos。

可是在实现过程中，因为遇到了各种坑坑绊绊的问题，我又慢慢走向了另一个极端：为了让流程稳定，我把越来越多的判断写成了固定逻辑。

它确实不再那么自由了，但也没有原来想象中那么智能了。系统只能处理提前预设过的情况，一旦出现新的组合问题，就很容易停在逻辑没有覆盖的位置。

AI很智能，但它不是传统软件

这件事最麻烦的地方在于，AI 真的很智能。

也正是因为它智能，执行过程才会有很大的自由度。它会根据上下文选择不同的工具、不同的路径，也会对中间结果做自己的判断。这种能力让它可以处理传统固定流程很难覆盖的问题，但同时也带来了一个事实：它的确定性没有传统软件那么高。

以前写一段普通代码，只要输入和环境不变，单元测试就可以一次又一次稳定地验证结果。但在复杂的产研工作流里，即使给 AI 设计了测试，也很难保证它每次都经过完全相同的路径。

一次长任务中，任何一步都有可能出现意料之外的中断。更麻烦的是，AI 有时完成了某个动作，就倾向于认为目标已经完成；但动作执行过，并不代表系统事实真的发生了变化。

如果让 AI 拥有绝对的自由，它可能会自己绕过很多问题，但整个过程也很难被约束。反过来，如果希望它的每一步都像传统程序一样确定，就会不断为各种意外补逻辑分支，最后系统越来越复杂，AI 能发挥的空间反而越来越小。

我之前就陷在了这里。

好在最后还是跳出来了，哈哈。

答案不是把所有事情都交给 AI，也不是把所有步骤全部写死，而是把自由和确定性放在不同的层次。

Zeus负责能力，Talos负责闭环

现在 Zeus 和 Talos 的架构已经逐渐清晰了。

一条飞书请求进来，先由飞书通道层负责可靠接收、去重、入队，并把进度和结果送回原来的话题。

然后由 Agent 决策层理解用户到底是在问一个业务问题，还是希望系统完成一项交付。如果是需要持续执行的任务，再进入 Goal 编排层，把目标、当前状态和上下文持久化下来。

Goal 编排层按照“观察、决策、执行、核验、保存检查点”的循环推进。真正需要写 PRD、出方案、改代码、测试和提交时，才进入 Zeus 的独立 skill 会话。

Zeus 负责一件具体的工程工作怎么做好，Talos 负责下一步做什么、失败后怎么办、重启后怎么继续，以及什么时候必须停下来交给人。

状态机、权限、预算和门禁负责给 AI 划边界，边界内的分析、判断和异常处理仍然交给 AI。一次 skill 执行结束，也不能只听模型说“已经完成”，而是必须带着产物和证据回到 Goal，由 Goal 核验真实状态以后才能继续。

这样一来，它既不是一只完全自由的“小龙虾”，也不再是一个只会按照流程图机械跳转的纯逻辑系统。

我现在更愿意把 Zeus + Talos 理解成一个分层的 Loop：Zeus 里的小循环负责完成一次具体工程任务，Talos 的大循环负责让整个需求持续向终点推进，并在失败、中断和重启以后接着运行。

真正的深水区，是先治理我们自己

做到现在，我越来越觉得，AI Coding 已经进入深水区了。

在我们这种一千多万行代码的规模下，困难程度是很多人不太能够理解的。真正的问题早就不只是模型会不会写代码，而是它能不能理解复杂业务，能不能在巨大的代码库里控制噪音，能不能跨越多个系统保持事实一致，能不能在任务中断后恢复，以及能不能在自由和确定性之间找到平衡。

这些问题，不是再换一个更强的模型就会自动消失。

除了继续优化工作流和云端自动化，我们现在还在做两件很重要的事情。

第一件，是清理无用代码，持续降低 AI 面对代码库时的噪音。对 AI 来说，已经废弃但仍然存在的接口、分支和调用关系，不只是维护成本，也会直接变成理解系统时的认知成本。

第二件，是继续梳理服务化和业务域，明确每个服务、每个业务域究竟负责什么。职责边界越清楚，AI 分析一个具体问题时越能聚焦，也越不容易把不同系统、不同渠道和不同阶段的业务逻辑混在一起。

模型当然还会继续变强，Zeus 和 Talos 也还会继续变化。

但走到今天，我反而更相信，真正拉开差距的未必只是模型能力，而是谁能更早把自己的代码、知识、流程和反馈，整理成一套 AI 可以长期工作的工程环境。

这件事，我们还在突破中。