AI Product Growth 101｜03｜AI Development Loop：从功能迭代到行为迭代
传统软件的需求通常可以写成确定行为。
用户点击保存，数据应该被保存。接口收到合法请求，应该返回规定字段。
AI 功能没有这么整齐。
同一个提示词换一份输入，结果可能完全不同。模型升级、上下文顺序、工具描述甚至输出长度，都可能改变行为。
如果团队仍然只用“开发完成、QA 通过、发布上线”管理 AI 功能，就会在生产环境里反复遇到同一类问题：
Demo 很好，真实用户不稳定；修好了一个案例，另外十个案例退化；模型换新版本，没人知道产品整体变好还是变差。
功能没有变，行为已经变了
AI 产品里的“代码没改”不代表产品没变。
模型供应商升级了模型，检索库增加了文档，系统提示词插入了一条规则，工具返回格式多了一个字段，都可能改变最终结果。
所以版本管理不能只记录代码版本。
还要记录模型、提示词、工具定义、检索配置、上下文策略和评估集版本。
这些东西共同构成一次产品行为。
Anthropic 在 2026 年的 Agent Evals 实践中给了一个很朴素的起步数：早期不需要几百道题，20 到 50 个来自真实失败的任务就足以开始。更值得注意的是它对 outcome 的定义：订票 Agent 在对话里说“已经订好”不算完成，数据库里真的出现预订记录才算。这个区别把评估从“它说得像不像成功”拉回到“世界状态有没有改变”。
一条六步闭环
1. Observe：收集真实任务
从生产使用中采样，不只收集报错。
成功案例告诉你用户真正重视什么。失败案例告诉你系统边界在哪里。被用户大改的结果，往往比明确报错更值得研究。
2. Label：定义好与坏
不要只写“回答质量高”。
把质量拆成可判断的维度：事实是否正确、关键字段是否覆盖、引用是否可追溯、动作是否符合权限、语气是否适合场景。
不同任务需要不同标准。
客服回复可以容忍措辞变化，财务数字不能容忍近似正确。
3. Reproduce：让问题可复现
保存完成任务所需的输入快照：用户请求、关键上下文、工具返回和配置版本。
不需要保存所有敏感数据，但必须能重建失败条件。
无法复现的反馈，很难进入工程闭环。
4. Evaluate：同时跑确定性检查和模型评估
能用规则判断的，不要全交给模型判断。
JSON 是否合法、链接是否存在、金额是否一致、必填字段是否缺失，这些适合确定性检查。
完整性、相关性、语气和推理质量，可以使用人工标准、模型评估或二者结合。
评估器也会犯错。它需要用人工标注样本校准。
5. Improve：修改最小必要层
失败不一定靠换模型解决。
可能缺的是上下文，可能是工具接口不清楚，可能是 UI 没有让用户表达约束，也可能是任务本身应该拆成两步。
先定位失败发生在哪一层，再修改那一层。
6. Release：小流量比较
离线评估通过，不等于线上一定更好。
新版本先进入小流量或内部用户，比较结果接受率、人工修订量、延迟、成本和严重错误。
保留快速回退能力。
评估集不是考试题库
很多团队建立评估集后，会逐渐对它过拟合。
每次失败都改提示词，直到固定样本全部通过。分数越来越高，用户体验却没有同步改善。
评估集应该分层：
- 核心集：长期稳定，覆盖最重要行为。
- 回归集：来自已经修复的生产问题。
- 新鲜集：定期从近期真实任务中抽样。
- 红队集：专门覆盖权限、安全和极端输入。
核心集保证产品没有忘记基本功。
新鲜集防止团队只会做旧题。
把失败变成资产
传统软件里，失败通常是要消灭的 Bug。
AI 产品里，失败还是产品知识。
每一个被清楚描述、可以复现、已经标注的失败案例，都会让团队更理解任务边界。
时间久了，真正的壁垒不只是提示词，而是这套围绕真实工作流积累的行为数据：什么算好，什么绝对不能发生，什么情况下应该交还给人。
小结
AI 产品开发不是“做功能，然后看指标”。
它是一条持续的行为闭环：观察、标注、复现、评估、改进、发布。
当这条闭环运转起来，团队才不需要靠少数人的感觉判断模型是否变好。
下一篇，我们会把视角转向用户第一次使用：什么才算真正激活，而不只是完成注册或发送第一条消息。