AI 能写出代码，不代表它知道该写什么。需求没写清、没拆细、没接进验证，这些问题不解决，模型越强，返工越贵。
近日，量子位智库发布《Agent 驱动的企业智能化：单点提效到规模化重塑》（以下简称"报告"）。报告把企业 AI 落地的卡点归纳为六条断点，排在第一位的不是模型能力、不是数据质量，而是任务不清晰。
放到企业软件交付领域里，这句话可以翻译得更直白：AI 交付的上限，由喂给它的需求决定。 而把需求变成"机器能准确消费的东西"这件事，有一个朴素的名字：需求工程。它是 AI Coding 时代最被低估的投入。
我们在自己的交付项目里，为这句话付过学费。网易智企·CodeWave 的解法，是把需求工程做成三个动作：把需求写成规则、把需求拆成可分配的任务、把需求接进验证。
01一个交付负责人的"暂停之夜"
我们交付团队今年接了一套业务全流程管理系统：16.8 万字 PRD、15 个模块、11 类角色、10 条审批流、50 张数据表、43 个页面、5 个外部系统集成。团队是一个 5 人小队：1 个产品、2 个开发、1 个测试，加团队负责人。
项目一开始就用 AI Coding。想法很朴素：把 PRD 喂给模型，一个模块一个模块写。
一个月后，项目暂停。
站会上，开发同学说了一句话："我感觉我现在不是在用 AI 写代码，而是在给 AI 擦屁股。"暂停那晚，负责人逐行读 AI 生成的代码，发现每一个 bug 的根因都指向同一处：需求。退回逻辑错，是因为 PRD 只写了"支持退回"，没写退到哪里、退回后其他节点怎么处理。
第二天站会的结论只有一句：每次返工的本质，是需求没说清。
02AI 不跟你辩论？把需求写成规格
你说"支持导出"，AI 不问导什么格式、全量还是筛选后、要不要按权限脱敏，直接挑一种理解开写。你说"列表要快一点"，它不问是分页、虚拟滚动还是加缓存。
别怪 AI。自然语言的天然缺陷就是同一句话十种理解。真正的差别在于：人会追问，AI 不会，它会直接去做。
我们的做法是用 EARS 语言（一套把需求写成"当......发生时，系统应......"的书写规范）把需求收敛为只有一种理解的句式。
- 常见写法：编辑内容后，最好能自动保存
- EARS 写法：当用户停止输入超过 5 秒时，系统应将当前内容自动保存至草稿箱。
过去这些歧义要等代码写完、测试提 bug 才暴露；现在在动手之前就被拎出来，AI 逐条追问，问清楚再写。并且所有澄清记录被结构化存档。需求从一段随时丢失的对话，变成一份可追溯、可审查的契约。
这正是报告指出的："哪些条件还没有说清楚"，不该靠人自觉回答，而该由流程强制回答。
03上下文炸了？把需求拆成可分配的任务
旗舰模型标称 1M 上下文窗口，16.8 万字塞进去理论上绰绰有余。实际上，受成本、提示词与工具占用限制，编辑器可用窗口普遍在 200k 上下；再叠加"lost in the middle"。塞得越多，中间越容易被忽略。
于是三种症状准时报到：前后矛盾，上午说"退回到任意节点"，下午生成的代码变成"只能退回上一级"；功能被悄悄漏掉，主流程在、边界条件和权限校验没了；越改越乱，让 AI 改审批的退回逻辑，它顺手把检查的流程也"优化"了。
解法不是换更大的窗口，而是拆需求。四步：
- 结构化解析：对 PRD 做提纯，提炼大纲、标准词表与模块拆分，去掉冗余描述与格式噪音；
- **原子任务：**按依赖拆成边界清晰、单个小于 4 小时的任务。"方案审批"一条流程拆出了 14 个原子任务，拆完团队才发现，一条审批流里藏着这么多过去从没注意到的分支；
- **按需分配：**每个环节起一个专项智能体，只携带当前任务所需的需求、组件与接口定义，做功能 A 就不给功能 B 的材料；
- 断点续跑： 会话状态持久化，长程任务可中断、可恢复。
拆需求的过程本身就在暴露隐藏需求。 那 14 个原子任务里，有一半是过去"写代码时才发现"的分支。需求工程的价值不只是喂 AI，而是让人在动手之前就知道有多少活、边界在哪。
需求功能按依赖推进任务，为专项智能体配置所需上下文，并保存阶段状态。
04代码快了，项目反而慢了 ？把 AI 接进交付全链路
一个功能从"甲方说要做"到"上线能用"，要过六个阶段：需求理解、需求澄清、方案设计、编码实现、测试验证、部署发布。AI 提效的只有编码这一段，上游下游照旧人工。
中间快了，两头慢了。总时间没省多少。
想明白这一点之后，我们不再把 AI 当成"写代码的工具"，而是当成"跑流水线的工人"。它不只写代码，它还参与需求解析、方案设计、自动化测试和部署。 每一个环节，都在同一个平台上闭环运转。
其中变化最大的，是测试这一环。
AI 一口气吐出几百行代码，看起来没问题、跑一遍也不报错，但没人知道它有没有顺手改了没让它改的东西。测试于是从抽查退化成全量人肉回归：AI 每改一次，整条审批流从头跑一遍。
现在，测试用例不再是人写的，而是 AI 生成的 E2E 测试用例。例如 Spec 里写了"风险官在一般预警流程中无审核权"，就会自动生成一条对应的权限校验用例。
052 人 3 周，和一笔被算错的账
前期需求结构化与任务拆分，我们扎扎实实做了近一周。之后：
- 整体交付周期从预估的**"5 人全职 10 个月"，压缩到"2 人 3 周"**，整体交付效率提升 30 余倍；
- 43 个页面、10 条审批流、50 张数据表，100% 覆盖；
- UAT 阶段严重缺陷为 0。样式细节、交互微调当然有，但"功能做错了"没有发生。
甲方验收时的评价是："这是我们合作过的项目里，来回调整最少的一次。"
需求阶段多花的一周，这恰恰是被算错的那笔账。大家算 AI 的账，总是算开发段省了多少时间，而需求工程的回报，藏在消失的返工、消失的人肉回归和消失的联调等待里。
报告给出的衡量框架正好用来纠正这个偏差：衡量要同时看效率、质量、业务结果与成本；实施前记录基线，实施后按同一范围、同一口径比较，并把失败与转人工的任务也纳入统计。
用这把尺子量，答案很清楚：需求阶段投入是同类项目的 2--3 倍，换回来的是测试与返工段的几乎归零。
复盘的最后一句话，我们想原样抄在这里**：AI 是好枪，但好枪也得有人瞄准。**
瞄准的动作发生在需求工程里。而把需求工程变成一套可复制的工程能力，正是 CodeWave SDD 想替团队承担的部分，这套方法已完成标准化，并沉淀到产品中。目前已有数百家企业用它交付 AI 软件项目。