上个月，我们团队一位产品经理花了两周写了一份 40 页的 PRD，描述一个智能审批 Agent 的需求。用户故事、流程图、异常分支、验收标准，写得滴水不漏。
她把 PRD 丢给 Coding Agent，说：「按这个做。」
三天后 Agent 交付了。代码能跑，测试通过，接口对齐。但她试了五分钟就皱眉：「这不是我要的东西。」
哪里不对？她说不清。审批流程是对的，权限校验是对的，消息通知是对的。但 Agent 处理「领导已读不回超过 48 小时」的策略，不是她脑子里想的那个。PRD 里写的是「超时后自动提醒」，Agent 就老老实实给所有超时审批发了一轮提醒——包括那些「领导出差没看手机」的非紧急件。她真正想要的是「先判断这条审批是否紧急，紧急的才提醒，不紧急的等下次汇总」。
这个判断，她没写进 PRD。因为她觉得这是「常识」。
Agent 没有常识。Agent 只有你给它的判据。
一、PRD 的根本问题：不是写得不够细，是载体不对
大多数人对 PRD 失效的归因是「写得不够详细」。解法：写更详细的 PRD。加更多边界条件、更多异常分支、更多验收标准。
这条路走不通。
原因不是 PM 偷懒，而是 PRD 这种载体的信息结构，天然不适合 Agent 消费。
PRD 是自然语言文档。它的读者是人——一个有行业常识、有上下文推断能力、能「读懂言外之意」的人。PM 写「超时后自动提醒」，人类工程师会追问：「什么算超时？提醒谁？提醒几次？紧急和不紧急怎么处理？」
Agent 不会追问。Agent 会按字面意思执行，然后交出一个「正确但不对」的结果。
我在 悟空技巧十：评估与度量 里讲过一个核心观点： AI 的输出「看起来很好」不等于「工程上可用」。 但那时候我的解法还是「用评分卡验收 AI 的产出」——本质上还是在 PRD 范式里打补丁：先写 PRD，再验收。
现在我意识到，问题出在更前面。 不是验收环节缺了 eval，是需求环节就应该用 eval 替代 PRD。
二、从 Spec 到 Loss Function：范式已经迁移了
2026 年上半年，AI 工程领域发生了一个安静但深刻的范式迁移。
Peter Steinberger 说了一句话：
「你不该再给 coding agents 写提示词了。你应该设计提示 agents 的循环。」
这句话的完整版叫 Loss Function Development（LFD）——损失函数开发。核心思想：不要告诉 Agent「做什么」，要告诉它「什么算做好了」，然后让它自己找路径。
LFD 的损失函数包含四个组件：
┌─────────────────────────────────────────────────┐
│ Loss Function │
│ │
│ ① Goal（目标） │
│ 足够大，使枚举/记忆不划算 │
│ 绝对盲测，运行期间不暴露答案 │
│ │
│ ② Constraints（约束） │
│ 时间预算 / 资金上限 / 接触面 / 方法论 │
│ │
│ ③ Harness（仪表） │
│ 每个约束有 CLI 可查的度量 │
│ 目标分辨率足够高（pixel-diff 而非 LLM 打分） │
│ │
│ ④ Forced Entropy（强制熵） │
│ 过拟合反思 / 停滞跳跃 / 迭代日志 │
└─────────────────────────────────────────────────┘
# generated by hugo AI
拿审批 Agent 的例子对照：
| 组件 | PRD 时代怎么写 | LFD 时代怎么设计 |
|---|---|---|
| Goal | 「实现智能审批流程」 | 200+ 条真实审批场景的 eval set，覆盖紧急/非紧急/已读不回/多人会签/跨级审批 |
| Constraints | 「两周内上线」 | 硬性时间预算 2h，API 调用上限 500 次，只允许调用钉钉审批 API |
| Harness | 「产品经理验收」 | 每条 eval 场景有预期输出，自动 diff 比对，通过率 < 90% 不交付 |
| Forced Entropy | 无 | 每轮自问：「是在记忆 eval 还是真正理解审批逻辑？」 |
一个真实案例：有人用 LFD 框架让 Agent 构建一个网页爬虫产品。Agent 前三个循环都在「作弊」——生成 seed data 过 eval、为每个 eval 条目生成精确关键词、关键词膨胀到数百个。直到所有捷径被封死，Agent 才真正开始优化架构。最终产出：6300 行代码，爬取 92k 页面，$40 API 成本， 性能超参考产品 50 倍。
关键洞察： 作弊不是 Agent 的 bug，是你的 eval 设计有漏洞。 每一条你没有封住的廉价路径，都会成为优化器全力冲刺的方向。
这恰恰是 PRD 做不到的事。PRD 描述「做什么」，但无法封住「不做什么」。
三、行业验证：Eval 已经是默认路径
这不是理论推演。2026 年，eval-first 已经在多个工程体系里成为默认路径。
Google ADLC（Agent Development Lifecycle）：2026 年 4 月 Google Cloud Next 发布的 agents-cli，scaffold 出来的项目 自带 eval set + eval config。Coding Agent 被训练成「写完先跑 eval」。不是可选项，是默认路径。
agents-cli eval generate # 跑 eval 生成 traces
agents-cli eval grade # LLM-as-judge 打分
agents-cli eval compare # 对比两次 run
agents-cli eval optimize # 自动调优 prompt
agents-cli eval dataset synthesize # 合成多轮 eval 场景
# generated by hugo AI
QQ 音乐 Harness Engineering：50+ 微服务的单仓架构，把需求评审做成了机读化门禁。需求文档不合格？门禁直接阻塞，不进入设计阶段。每个门禁对应专属 Agent/Skill，结论写入固定格式文件，杜绝「口头通过」。
Spec-Driven Development 实战数据：一个 500+ 文件的 Java→Go 迁移项目，引入验证基础设施后：
| 指标 | 之前 | 之后 |
|---|---|---|
| 端到端交付提速 | 13% | 28% |
| 需求返工率 | 34% | 15% |
| 首轮 review 通过率 | 41% | 68% |
注意： 编码提速 10 倍，端到端交付只快 13%。 中间 87% 的效率损耗不是模型问题，是意图到代码的有损转换。Eval 解决的就是这个有损转换——把 PM 脑子里的判断标准，变成 Agent 可执行的验证管道。
四、钉钉 FDE：不写 PRD 的人
我在内部推动 FDE（Forward Deployed Engineer）模式时，有一个刻意的设计：FDE 的产出不是 PRD。
| 维度 | 传统产品经理 | FDE |
|---|---|---|
| 产出 | PRD | 可运行的 Agent + 模式报告 |
| 周期 | 季度 | 天/周 |
| 验证方式 | 评审会 | 客户现场跑通 |
| 质量标准 | 「逻辑清晰、结构完整」 | eval 通过率 + 客户确认 |
FDE 到客户现场，不是去收集需求写 PRD 的。是去 设计 eval——把客户的业务判断翻译成 Agent 可执行的验证标准。
举个例子：一家制造企业的采购审批，「金额超过 50 万需要总经理审批」是规则，PRD 能写清楚。但「这个供应商上个月刚出过质量问题，这次采购要加审」是判断，PRD 写不清楚。
FDE 的做法：把过去半年的真实审批记录拉出来，标注哪些是「事后证明应该加审但没加审」的，做成 eval set。Agent 不需要理解「为什么」，它只需要在这些场景里做出正确的判断。
PRD 传递的是描述，eval 传递的是判断。 描述是有损的，判断通过测试用例无损传递。
五、PM 的技能栈升级
说到这里，不是要宣布「PRD 已死」。PRD 承载的战略思考——为什么做这个、不做那个、优先级怎么排——这些不会消失，也不应该消失。
消失的是 PRD 作为「Agent 执行指令」的角色。
PRD 时代 Eval 时代
───────────────────── ─────────────────────
PM 写需求描述 PM 设计损失函数
工程师翻译成代码 Agent 直接消费 eval
QA 写测试用例（下游） Eval set 就是测试用例（上游）
验收靠人肉 Review 验收靠自动化 eval 管道
「看起来对」就通过 「跑过 eval」才通过
PM 需要的新能力：
- Eval 设计能力——把业务判断翻译成可执行的验证标准。不是写「系统应该智能处理超时」，而是设计 200 条真实超时场景，每条标注预期行为
- 约束设计能力——知道哪些捷径必须封死。时间预算、成本上限、接触面限制、方法论约束
- 仪表设计能力——为每个约束提供可量化的度量。不是「性能要好」，而是「P99 延迟 < 200ms，CLI 可查」
- 反作弊意识——Agent 会找最短路径。你的 eval 设计如果有漏洞，Agent 一定会钻。这不是 bug，是特性
我在 中国 SaaS 厂商的护城河应该怎么建 里写过，Agent-Native 架构的核心原则之一是「意图优先」。但意图优先的前提是： 你必须能把「什么算好」定义清楚。 否则 Agent 执行的就是一个没有判据的意图——它一定会给你一个「正确但不对」的结果。
六、一个升维问题
回到开头那位产品经理。
她后来没有重写 PRD。她花了三天，把过去一年的审批工单拉出来，标注了 300 条「事后证明处理策略不对」的案例，做成了 eval set。然后让 Agent 对着 eval set 迭代。
第一轮，通过率 62%。她看了失败案例，发现 Agent 把所有「已读不回」都当成「不紧急」。她加了一条约束：已读不回超过 24 小时且金额 > 10 万的，默认紧急。
第二轮，通过率 89%。她又看了失败案例，发现跨级审批的场景 Agent 完全没处理。她补了 20 条跨级审批的 eval。
第三轮，通过率 96%。上线。
她没写一行需求描述。她做的事情，本质上是把自己脑子里「什么算好」的判断标准，外化成了 Agent 可执行的测试集。
这就是 eval 时代产品经理的工作方式：你不是在写文档，你是在设计损失函数。你的交付物不是一份 PDF，是一个可运行的 eval set。
你的 PRD，还能让 Agent 一次做对吗？欢迎留言讨论。