这一篇不讲怎么做，只把一个问题想清楚：要让 AI 做复杂系统的业务需求，需要先了解当前互联网公司的需求实现流程是如何运作的。下面是我这一路想下来的链条，拆成几张图。
一、起点
想让 AI 做复杂需求
│
│ 总得先有个需求交给它
▼
这个"需求"是怎么来的？靠谱吗？
│
▼
┌─────────────────────────┐
│ 谁定义的？定义得全不全？ │
│ 不搞清楚，后面全是空中楼阁 │
└─────────────────────────┘
│
▼
顺着 PRD 往下扒
通常我们理解的产品需求是由 PRD 文档提供的。
二、第一种思路：把 PRD 写到极详尽
有的公司：PRD 要写到事无巨细
───────────────────────────
PM 梳清 happy path + 各种异常交互
│
▼
┌──────────────────────────────┐
│ 隐含假设： │
│ 脑子在 PM 那儿动完，工程师翻译 │
│ 文档越细 → 越像伪代码 │
└──────────────────────────────┘
│
▼
复杂系统里，这套塌了
│
┌──────────┴───────────┐
│ PM 只能写下他想得到的 │
│ 但真正的异常来自： │
│ · 状态组合炸出来的 │
│ · 并发时序冒出来的 │
│ · 上下游意外的返回 │
└──────────┬───────────┘
▼
文档很厚，洞还在（穷举不完）
│
▼
更糟：文档看着全 → 工程师松懈
→ 照着有洞的文档把洞也实现错
国内不少大公司对 B 端产品的要求是这样的，事无巨细都要写在 PRD 里，这个和当前公司运转的定责机制是分不开的。
如果 PRD 上没写的逻辑，发布到外部出事了，那么 PM 和研发分锅的时候可以 55 开。
三、那洞到底谁来补？几种公司，几种赌法
核心问题：happy path 以外、又夹在
产品与技术中间的灰色地带，谁来接？
┌────────────────┬──────────────────────────────┐
│ 做法 │ 赌的是 │
├────────────────┼──────────────────────────────┤
│ PM 穷举着填满 │ 文档能写全（填不满） │
│ │ │
│ 薄 PRD，只讲 │ 工程师写 TRD 和 code 时补遗漏 │
│ 做什么不讲怎么做 │ （赌工程师的判断力） │
│ │ │
│ 一群人在评论区 │ 把藏着的洞从各方嘴里吵出来 │
│ 来回吵（100+ h） │ （薄，但一点不轻松） │
│ │ │
│ 干脆取消 PM 角色 │ 工程师边写文档边定义需求 │
│ 写文档 + 严格评审 │ 疏漏太贵，没人敢赌文档能穷举 │
└────────────────┴──────────────────────────────┘
│
│ 做法不同，底子是同一个
▼
╔════════════════════════════════════╗
║ 补疏漏，需要一个 ║
║ 有判断、会追问、为后果负责的人 ║
║ 区别只在于：一个人补，还是一群人吵着补 ║
╚════════════════════════════════════╝
PRD 写的比较简单的，需要工程师边写 TRD 和代码，边追问，补充细节。
PRD 写的详细的，工程师当 PRD 翻译机就好了。
公司连 PM 都没有的。。工程师只能既要又要了。
四、一个戳破幻觉的事实
被引用最多的《How to Write a Good PRD》
───────────────────────────────────
2005 Marty Cagan 写下"怎么写好 PRD"
· 你的活是"画靶子"
· 但他自己点破：
细节太少 → 出事
细节太多 → 没人看
中间没有"写全了就万事大吉"的甜点
│
▼
2006 Cagan 又写《Revisiting the Product Spec》
基本推翻前作：PRD 过时了，
他几乎不再推荐客户写
│
▼
2012 连"PRD 是产品圣经"的 Ben Horowitz
也承认那套对今天可能不灵了
│
▼
┌────────────────────────────────────┐
│ 定义了 PRD 怎么写的人，写完一年就放弃 │
│ │
│ 结论不是"PRD 写得不够好" │
│ 而是：把需求提前写清楚再交给别人实现， │
│ 这条路在人手里就没走通过 │
└────────────────────────────────────┘
现在很多公司，产品先用线框图写第一版 PRD，后续在设计的参与下用高保真原型来做最终版。
五、于是不写规格了，改做原型
PRD 之后，主流转向：
产品经理最重要的活不是写明白需求，
而是搞清楚到底该造什么
│
▼
不写规格 → 做原型，又快又便宜地先试：
用户要不要 · 会不会用
能不能造 · 对生意划不划算
│
▼
给工程师的不再是"做什么"的清单，
而是"要达到什么效果"的目标
→ 怎么解、解成什么样，一起边试边摸
│
▼
行业花二十年得到的结论：
复杂需求没法提前写清楚再交给别人做。
不是文档不够好，是这事本身不成立。
产品成了决策什么该做什么不该做的人。
六、但原型里大部分还是 happy path
原型做到极致 = 高保真原型直接当规格
（连文字都省了，做出来的东西自己就是规格）
│
│ 但要问一句：能当规格的，是哪部分？
▼
原型说到底是个"模拟"
做出来的，大部分还是 happy path
── 用户看得见、点得到的那条主路
│
│ 系统内状态组合炸出来的异常，
│ 在原型里根本罗列不完整
▼
把系统行为摊开看 ↓
┌─────────────────────┬──────────────┐
│ happy path 上的流程 │ 原型基本都在画 │ ← 但最不容易出事
│ 状态组合的异常 │ 列不完整 │ ← 组合一炸就放弃
│ 纯系统行为： │ │
│ 超时重试/回滚 │ │
│ 消息去重幂等 │ 原型根本碰不到 │ ← 真正会半夜炸的
│ 并发写冲突 │ │ 全在这
│ 最终一致性时间窗 │ │
│ 对账 / 定时任务边界 │ │
└─────────────────────┴──────────────┘
│
▼
现实是两条腿走路：
┌──────────────────┐ ┌──────────────────────┐
│ 用户看得见的路 │ │ 看不见的系统行为 │
│ → 靠原型 │ │ → 靠工程文档 + 评审 │
│ → 产品/设计主导 │ │ → 工程师主导 │
└──────────────────┘ └──────────────────────┘
"原型即规格"只讲漂亮了左边，
右边它没解决，只是默默甩给了工程师
原型的问题在于，他展示的还是 user journey，大多都是 happy path。
复杂系统的后台逻辑没法在原型上做罗列，还是需要工程师来搞。
七、收口：那么 AI 呢
把整条链捋一遍 ↓
PM 穷举着补 ───────────► 补不完
一群人吵着补 ──────────► 薄但费劲
工程师边写边补 ────────► 干脆取消了 PM
发明 PRD 的人 ─────────► 写完一年就放弃
改成做原型给真人看 ────► 只盖得住看得见的那半
│
▼
╔════════════════════════════════════════════╗
║ 剩下那些会让系统半夜三点炸掉的系统行为： ║
║ 没有哪份文档、哪个原型写得全， ║
║ 一直靠工程师在写 TRD 和 code 时， ║
║ 凭判断一点点补上。 ║
║ ║
║ 这是二十年来唯一没被替掉、只能靠人扛的一环。 ║
╚════════════════════════════════════════════╝
│
▼
现在要让 AI 来做复杂需求 ——
给它原型？ 原型里没有系统行为
给它详尽 PRD？ 穷举不完，行业早放弃了
让它像工程师 ◄── 这正好是问题的核心
那样凭判断补上？
│
AI 特别擅长把想法飞快变成能跑的东西，做原型它太在行。
但原型能一秒生成，"放到真人面前、看懂反馈、
判断这个洞要不要补、怎么补"——这部分 AI 在不在场，
是另一回事。
│
▼
┌──────────────────────────────────────────┐
│ 所以问题落到很具体的一点： │
│ │
│ 那些谁都没写下来、只活在工程师脑子里的 │
│ 系统行为，AI 补得上吗？ │
│ │
│ 它会停下来问一句"这个失败的情况你想过没有"， │
│ 还是闷头、还挺自信地， │
│ 把那个洞也实现成它猜的样子？ │
└──────────────────────────────────────────┘
我们在用 AI 做项目的过程中，发现如果你的产品文档和技术 TRD 里没有写的东西，AI 很容易就擅自发挥出了不符合预期的结果，这一点上和把活交给人类工程师差别很大，而 happy path 一般 AI 写的都不错。
这个问题可以解决吗？我认为是可以解决的，请看下一篇。
