Article body
正文
一、需求模糊：AI研发失败的第一大根因
每一个在AI研发上受过挫折的团队，都能说出类似的故事：
“我们明明把需求写得很详细了，但AI给出的实现还是不对。” “AI写的代码能跑，但跟我们想要的差了一截，改来改去，最后还不如自己写。” “给AI的任务描述改了五六遍，还是跑偏，最后放弃了。”
这些挫折背后，有一个被反复验证的规律：在AI研发中，任务说明的完备程度是决定成功率的最关键因素，没有之一。
多项研究显示，同一个AI模型，在高质量需求描述下的任务完成率，比在模糊需求描述下高出40%-60%。很多被归因为”模型能力不足”的失败，本质上是输入定义不清楚。
这个现象揭示了一个深刻的矛盾：AI研发的效率上限，被需求工程的质量严格限制——而需求工程，恰恰是软件开发中历来最难被工具化的环节。
二、传统需求工程在AI研发场景下的深层局限
2.1 PRD的结构性缺陷
产品需求文档（PRD）是大多数团队的需求管理核心工具。在人工研发时代，PRD有其合理性：人类工程师能够利用常识、经验、上下文推断来”补全”PRD中未明确的部分。
但在AI研发场景下，PRD的结构性缺陷被放大：
缺陷一：隐含了大量未文档化的假设
一份典型的PRD会写：“用户点击提交按钮后，系统保存表单数据。”
这句话对人类工程师来说是清晰的，因为他们能补全背后大量的隐含逻辑：
- 提交前应该进行前端校验
- 校验失败应该显示错误提示，不能提交
- 保存成功后应该给用户反馈
- 保存失败应该提示用户，并允许重试
- 按钮在提交过程中应该禁用，防止重复提交
AI在处理这个需求时，可能”正确地”实现了”保存表单数据”这件事，但遗漏了所有的隐含逻辑——因为这些逻辑在PRD中根本没有出现。
缺陷二：需求边界描述不精确
PRD通常描述”正常流程”，对边界条件和异常情况的覆盖严重不足。“如果用户输入了非法字符应该怎么处理？""如果网络在提交过程中断开了怎么办？""如果并发提交了两次相同的表单怎么处理？”
这些场景，人类工程师会基于经验自行处理；AI则倾向于只处理被明确描述的场景，对未描述的边界案例要么忽略，要么给出不确定性较高的处理方式。
缺陷三：静态文档无法反映动态演进
需求是动态演进的。版本V1.0的PRD描述了某个功能的初始设计；三个月后，这个功能经历了多次迭代，但PRD可能只被部分更新，或者更新和代码之间存在不一致。
AI拿到这份PRD，无法判断哪些部分是有效的最新需求，哪些是已经被代码实现推翻的旧描述。
2.2 “需求写清楚”本身的难度
一个更根本的问题是：“把需求写清楚”本身就是软件工程中最难的事情之一。
弗雷德·布鲁克斯在《人月神话》中写道：
“软件开发中最难的部分，不是实现，而是决定要实现什么。”
需求的困难不在于表达，而在于发现：
- 业务方很多时候说的是”他们想要的”，而不是”他们真正需要的”
- 很多需求的细节，只有在实现过程中才能被发现和澄清
- 需求之间往往存在矛盾和冲突，需要权衡和决策
- 业务目标在随时间演进，“完成”的定义在不断变化
这意味着：要求工程师在写任务之前”把需求写完整”，本质上是要求他们在充分理解问题之前就解决问题。这是一个悖论。
三、需求持续迭代重构的全周期模型
真正理解需求的本质，是接受需求天然是不完整的，开发过程本身是需求发现过程的一部分。
基于这个认知，我们提出需求持续迭代重构的全周期模型：
需求澄清不是一次性事件，而是贯穿整个开发周期的持续过程。每一轮实现，都会暴露初始需求中未被发现的歧义和缺失；每一次歧义被发现，都是一次需求完善的机会；每一次完善，都要回传到任务定义，影响后续实现。
3.1 三类核心歧义及其处理
在实践中，需求歧义主要分三类：
业务逻辑歧义：需求描述中对某个业务场景的处理没有明确说明，或者说明了但存在解释空间。
示例：“订单金额不足100元时不允许使用优惠券。” 歧义点：使用优惠券后金额不足100元，还是使用前不足100元？预付定金的订单如何计算？
处理方式：识别歧义 → 向产品方澄清 → 在需求文档中增加明确说明和反例 → 更新验收标准
边界条件歧义：需求描述了正常场景，但对边界条件没有规定。
示例：“搜索结果按相关度排序。” 歧义点：搜索结果为空时如何展示？相关度相同时如何排序？
处理方式：系统性地问”如果……怎么办”——对正常流程的每个步骤，都补充边界条件的处理规定
跨需求一致性歧义：不同需求文档或不同版本之间，对同一概念的定义不一致。
示例：A模块的需求文档里，“有效用户”指注册超过30天的用户；B模块的需求文档里，“有效用户”指完成实名认证的用户。
处理方式：建立业务术语词典，对关键业务概念给出统一、精确的定义，并在所有需求文档中引用。
3.2 验收标准的动态演进管理
需求全周期模型中，最难管理的是验收标准的动态演进。
验收标准是”完成”的定义。在真实项目中，“完成”的定义会随着业务理解的深化而持续更新：
- 最初的验收标准是”用户能成功提交表单”
- 第一轮开发后，发现还需要”表单提交后3秒内给用户邮件确认”
- 第二轮开发后，发现还需要”如果邮件发送失败，有重试机制”
如果验收标准的变化没有被系统化记录，会出现两个问题：
- 新的验收标准要求”覆盖”了旧的，但旧的测试用例没有被更新，出现测试和代码不一致
- 历史上验收通过的功能，在新的验收标准下可能不再合格，但没有人意识到需要重新验收
四、需求闭环自治的技术实现
“需求闭环自治”的目标，是让需求的发现、澄清、更新、继承过程尽可能自动化，减少对人工手动维护的依赖。
4.1 歧义自动检测
在AI研发流程中，可以引入”需求预检”环节：在AI接收任务开始执行之前，先对任务描述进行歧义检测。
衡石科技的HENGSHI JARVIS在需求预检方面有实际的工程落地。在HENGSHI SENSE的产品研发中，JARVIS会在每次任务启动前自动执行四维歧义检测：
检测维度：
- 关键词模糊性检测：识别”尽快”、“合理”、“友好”、“通常”等模糊词汇，要求给出具体定义
- 边界条件完整性检测：对每个业务操作，检查是否定义了空值处理、异常处理、并发处理的规定
- 术语一致性检测：检查需求中使用的业务术语是否与术语词典一致
- 验收标准完整性检测：确认是否有明确、可验证的验收条件
在HENGSHI SENSE的实际研发中，JARVIS的需求预检平均每个任务发现2-3个歧义点，避免了约60%的”需求返工”场景。特别是在数据分析场景中——如”按部门统计销售额”这样的需求，JARVIS能自动识别”部门层级是否展开”、“退货金额是否扣除”等业务口径歧义，在代码编写之前就完成澄清。
4.2 需求结构化修正
在歧义被澄清后，需要将澄清结果结构化地更新回需求文档，而不是仅停留在对话记录中。
结构化修正原则：
- 每次澄清，都应该在需求文档中有对应的更新
- 更新应该在原始描述中就地修改，不是另起一份”补充说明”
- 更新应该标注版本号和日期，便于追踪
4.3 需求知识的跨任务继承
在多任务并行或顺序执行的场景下，某个任务中发现的需求歧义和澄清结果，应该自动被后续相关任务继承。
实现机制：
- 每次需求澄清，都触发”影响范围分析”：这次澄清可能影响哪些其他任务或模块？
- 影响范围内的任务，在启动时自动注入相关的澄清结论
- 如果澄清涉及业务术语的重新定义，自动更新全局术语词典
这一机制在HENGSHI SENSE的多客户定制化场景中尤为关键。不同客户（如WPP与宝马）对同一数据分析功能的需求细节常有差异，JARVIS的需求知识继承机制确保：当某个客户场景下的需求歧义被澄清后，相关结论自动传递到同类型的其他客户定制任务中，避免重复澄清。
五、AI友好的结构化需求书写规范
5.1 标准需求模板
5.2 反例对比：什么样的需求让AI”失控”
反例一：模糊的正常流程
❌ 不好的写法：
“用户登录后跳转到首页。”
✅ 好的写法：
“用户输入正确的账号密码，点击登录按钮，登录成功后：
- 如果用户本次登录前有未完成的表单，跳转到未完成表单页面
- 否则跳转到个人首页
- 登录成功的同时，更新用户的lastLoginTime字段（格式：UTC时间戳）
- 当前会话有效期为24小时（可在用户设置中调整，最长7天）”
反例二：缺失边界条件
❌ 不好的写法：
“搜索框输入关键词，返回匹配的商品列表。”
✅ 好的写法：
“用户在搜索框输入关键词（至少1个字符，最多50个字符），点击搜索或按回车键触发搜索。 边界条件：
- 关键词为空时：按钮置灰，不触发搜索
- 关键词超过50字符时：截断到50字符后执行搜索，不报错
- 关键词包含特殊字符（如<、>、SQL注入关键词）时：过滤后执行搜索
- 搜索结果为空时：展示’未找到相关商品’提示，同时推荐热门搜索词
- 搜索请求超时（>3s）时：展示超时提示，提供重试按钮”
反例三：缺失”Out of Scope”说明
❌ 不好的写法（什么也没说）→ AI可能”顺手”实现了搜索历史记录、搜索建议、搜索结果排序配置等功能，但这些都超出了本次需求的范围，引入了未经审查的代码。
✅ 好的写法：
“本期不实现：
- 搜索历史记录功能（下期需求）
- 搜索建议/自动补全（暂不实现）
- 搜索结果排序方式切换（固定按相关度排序）“
六、需求工程是AI研发的最高杠杆点
回到文章开头的问题：为什么AI研发在实践中经常跑偏？
根本原因是：我们在期待AI解决”实现”的问题，但实际上最大的浪费发生在”定义”的环节。
一个典型的AI研发项目，时间分布可能是：
- 需求定义与澄清：20%
- AI执行与人工Review：30%
- 修正与重做（因为需求不清晰）：50%
这意味着：如果需求质量提升50%，总工时可能减少25%以上。投入需求工程的单位ROI，远高于优化模型选择或提示词调优。
需求闭环自治的最终目标，不是”让AI自己写需求”，而是：
- 让需求歧义能被及时发现，而不是等到代码写完才暴露
- 让需求澄清的结论被系统化记录和继承，而不是停留在口头沟通
- 让验收标准随业务演进自动更新，而不是永远停留在初始版本
- 让AI拥有执行任务所需的完整上下文，而不是在信息残缺的条件下”猜测”实现
七、结语：从”说清楚”到”自动清晰”
传统需求工程的理念是”说清楚需求”——这是对工程师提出的高标准要求。需求闭环自治的理念是”需求在过程中自动清晰”——这是对工程体系的系统化要求。
从前者到后者，是AI研发走向成熟的必经之路。
衡石科技的HENGSHI JARVIS，正是这一理念的产品化实践。它不是让AI替代人类定义需求，而是让需求从”依赖个人经验的手工文档”升级为”系统化沉淀、自动澄清、跨任务继承的工程知识”。当HENGSHI SENSE的服务对象从几十家扩展到200+企业客户时，需求工程的质量直接决定了产品能否持续高质量交付——而JARVIS，就是确保这一点的工程基础设施。