编码代理缺失的其实是产品定义

Coding Agent 可以阅读代码、测试和工单，但如果没有可靠的产品定义，它们仍然不得不重新推断这个产品究竟应该如何运作。

我们正在把代码库的控制权交给 AI，却没有同时给它一份可靠的产品定义。

让 Coding Agent 修改免费试用结束后的行为。工作区应该变为只读吗？是否有宽限期？用户还能导出数据吗？定时任务是否继续运行？受邀的团队成员会怎么样？

Agent 可以找到相关代码和测试，但它无法判断：这些答案中，哪些才代表产品当前的真实意图。

证据不是产品定义

答案通常散落在定价页面、旧的发布工单、计费与权限逻辑、测试、客服处理手册，以及某个人的记忆里。每个来源都有价值，但没有一个能够完整定义产品当前的状态。

试用到期涉及计费、权限、协作、数据保留、数据导出和自动化等多个方面。每个系统都可能各自表现得逻辑一致，最终却共同产生一种从未有人有意设计过的客户体验。

Agent 并不是在发现产品，而是在重构产品。它会用从未有人明确做出的产品决策填补每一处空白，然后像这些推断已经获得批准一样编写代码。

代码是最接近实际发布行为的证据，但它无法解释这些行为意味着什么。临时的变通方案看起来可能与刻意制定的业务规则毫无区别。测试只能确认会发生什么，却无法说明为什么必须这样。

更完善的文档仍然不够

Wiki、设计文档和决策日志很适合记录信息，但它们有一个共同的弱点：无法告诉我们自己什么时候已经失真。当底层行为发生变化时，文档不会触发任何失败，只会悄无声息地变得不再正确。

问题并不在于产品定义难以编写，而在于书面产品定义无法知道自己现在已经错了。

Agent 将模糊变成行动

人们也会根据同样的零散信息重构产品。Coding Agent 只是做得更快，而且会立即根据重构结果采取行动。

更多上下文只能为 Agent 提供更多证据。它既无法创造出那些只存在于某次对话中的缺失决策，也无法区分某项约束究竟是有意设计，还是历史偶然。

最终得到的可能是看似合理的代码，却实现了一个存在细微偏差的产品。Reviewer 能发现其中一部分问题，其余的则会被直接发布。

持久可靠的产品定义需要什么

仅仅把产品记录得更清楚还不够。一份持久可靠的产品定义必须满足以下条件：

当前且集中：用一份共享定义说明产品应该如何运作，并随着产品变化持续更新。

与代码共同版本化：和实现保存在同一套变更历史中。

人和 Agent 都能阅读：具有结构化形式，同时又不会晦涩难懂。

围绕产品行为组织：涵盖角色、用户旅程、场景和规则。

与证据关联：当实现与意图产生偏差时，让这种漂移清晰可见。

你可以称它为产品模型，也可以称它为产品定义。名称并不重要，重要的是它必须具备一种特性：不能悄无声息地沦为虚构。

有了这样的定义，人们无须进行考古式挖掘，就能理解产品当前的状态；Agent 也可以基于明确的决策进行构建，而不是自行编造缺失的部分。

过去几周，我一直在开发一套用于产品定义的开放标准，以及它的开源实现。我计划很快发布它们。

如果今天需要一个 AI Agent 理解你的产品，它应该去哪里了解这个产品实际上应该做什么？

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。