作者 / 来源：中智凯灵 / AiDD
【篇首语｜企业 AI，正在从“会用”走向“能交付” 】
国庆七日谈·第一日｜需求契约
▼
过去，产品经理常常催开发：“需求已经写好了，什么时候能排上？”
现在，越来越多团队遇到的场景却反了过来：代码生成变快了，开发在等需求；Agent 已经准备执行，团队却还没有把目标、边界和验收条件讲到足够清楚。
问题不只是 PRD 写得短，也不只是提示词写得不够详细。自然语言天然允许省略、默认和模糊，人类会用经验把缺口补上，Agent 则可能用概率把缺口“猜”上。编码速度越快，一处未经确认的假设就越容易被迅速扩散到设计、代码、测试和部署中。
2026 年 AiDD 上海站、北京站和成都站的三场分享，从不同角度指向了同一条工程链路：需求先从供人阅读的说明转成 Agent 可以处理的执行态，再进入验收规格和真实环境，最后把执行证据回写到持续维护的需求资产中。
所谓给需求装上一台“编译器”，并不是发明一种万能文档格式。它真正要做的，是把业务意图翻译成机器能够执行、团队能够验收、结果能够追踪的共同事实。
当编码加速，需求开始成为新瓶颈
在 AiDD 成都站《从 PRD 到 Specs：AI 重塑需求工程》中，Inspire AI 总监咨询顾问亢江妹把变化概括得很直接：过去是“需求等开发”，现在开始出现“开发等需求”。
代码生成、测试生成和部署自动化不断提速，但需求侧仍可能停留在多轮沟通、多人转述和文档交接中。业务提出一个想法，产品经理补成 PRD，BA、SA、研发和测试分别再做一次理解。每经过一次交接，目标、规则与边界都可能发生变化。
图 1：亢江妹《从 PRD 到 Specs：AI 重塑需求工程》：编码自动化后，“需求”开始成为新的交付瓶颈
人类团队过去还能用会议、即时沟通和个人经验修补这种模糊。Agent 不会天然知道企业内部的默认规则：一句“支持批量导入”，背后可能包含接口、并发、回滚、错误提示、权限和异常恢复；一句“完成订单列表”，也没有自动说明排序、状态切换、字段范围和哪些功能明确不做。
所以，AI Coding 把一个原本容易被掩盖的问题提前暴露了出来：需求如果不能被验证，就很难被可靠执行。
这不是要求所有需求一开始就毫无遗漏，而是要求团队把“尚未确定什么、确定到什么程度、以什么证据判定完成”显式化。需求工程的任务，也从“写一份文档交出去”，转向“维护一套持续收敛的契约”。
“需求编译”，是把需求从阅读态转成执行态
在 AiDD 上海站，上海交通大学副教授林云在《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》中，把“需求编译”的核心落到了一个更具体的变化上：测试左移之后，需求要从阅读态转成执行态。
阅读态需求主要服务人的理解。人可以结合行业知识、历史系统和口头沟通补齐省略的信息；执行态需求则必须让 Agent 知道要处理什么对象、覆盖哪些场景、按什么步骤行动，以及每一步应当出现什么结果。
图 2：林云《从代码编写到需求编译》：测试左移推动需求从“阅读态”转向“执行态”
这也是为什么“需求编译”不等于把一份 PRD 原样上传给模型。真正可编译的需求，需要显式结构。
林云材料中的需求模型，把需求、场景、步骤、动作和预期组织成可以关联的层级。它还有一个很重要的工程含义：需求也可以“编译不通过”。当场景缺失、前后约束冲突、步骤没有预期结果时，问题应该在进入实现之前被暴露，而不是等代码生成后再靠人猜测原意。
图 3：林云《从代码编写到需求编译》：需求—场景—步骤—预期形成可检查的结构化模型
这里的“编译不通过”不是说系统已经能够自动理解全部业务语义，而是给团队建立一种新的工作方式：需求本身也要接受检查。它需要有可定位的对象、可追踪的约束和可验证的完成条件。
于是，需求与测试不再是前后分离的两份材料。验收条件开始参与定义任务，测试也从末端检查前移为生成过程的约束。AI 不是拿到一段自然语言就自由发挥，而是在需求结构与完成条件共同形成的空间里执行。
验收规格，要成为生成与交付的共同契约
需求被结构化之后，还需要回答一个问题：这些结构怎样进入真实研发流程？
在 AiDD 北京站《基于智研的ATDD端到端实践》中，中兴通讯公司级敏捷教练、资深架构师、AI 教练高林林，把“业务语义库、验收规格和 ATDD Skill”放在了一条链上。
业务语义库提供企业内部的术语、接口、参数、状态流转和规则；验收规格把输入、前置条件、验收标准和异常规则写成结构化契约；ATDD Skill 则把解析规格、生成用例、部署环境和执行验证等动作封装成可编排能力。
图 4：高林林《基于智研的ATDD端到端实践》：业务语义库、验收规格与 ATDD Skill 构成契约到执行的链路
这条链最重要的变化，是把验收标准从研发末端拉到了需求入口。过去，测试常常在代码完成后才确认“需求究竟是什么意思”；现在，验收条件需要先参与定义任务，让产品、研发、测试和 Agent 对“什么算完成”建立共同理解。
但只有验收规格还不够。长程任务仍可能跳步、循环或提前报告完成；模型也可能在缺少真实接口和环境时生成看似完整、实际无法执行的用例。
高林林的材料把应对方式概括为三层重构：用语义库和规格完成“翻译”，用任务编排引擎铺设“铁轨”，再用规格确认、环境执行和质量看板配置“检验员”。
图 5：高林林《基于智研的ATDD端到端实践》：以“翻译、铁轨、检验员”稳定需求到验收的长链路
这套框架背后的原则，是把概率性推理与确定性工程分开。需求理解、测试生成和异常推理可以交给 AI；流程顺序、必经节点、状态维护、超时熔断和验收门槛，则要由工程系统保证。
真正的验收还必须进入真实环境。高林林展示的完整机制分成三段：入口处核验规格与业务语义是否一致；过程中让用例在真实测试环境执行并留下断言；出口处根据真实数据决定放行、打回或人工复核。
图 6：高林林《基于智研的ATDD端到端实践》：规格确认、环境执行与看板决策共同构成完整验收机制
这也解释了为什么“AI 生成了用例”不能等同于“系统已经可以验收”。只有规格经过确认、结果来自真实执行、证据能够复现和追溯，需求才从文档变成团队共同认可的工程事实。
从 PRD 到 Specs，不是一次交接，而是逐级提高确定性
如果需求契约只在启动阶段整理一次，很快就会和实现脱节。亢江妹在成都站材料中提出的需求漏斗，补上了契约形成和持续维护的过程。
从 research、explore、prototype，到 storymap、story 和 handoff，每一步都要形成明确产物和完成定义，并在关键节点保留人工确认。它不是要求所有团队照搬六个阶段，而是强调：需求不应从模糊想法直接跳到开发任务，中间需要逐级减少不确定性。
图 7：亢江妹《从 PRD 到 Specs：AI 重塑需求工程》：需求漏斗通过分阶段产物与确认点逐级提高确定性
这样做还有一个现实价值：当需求被打断或发生变化时，团队损失的是某一步的工作，而不是推翻整篇 PRD 重新开始。已经确认的用户、场景、规则和边界仍然可以保留，并继续成为后续 Agent 的上下文。
经过确认的契约也不能在 handoff 后封存。业务语义变化相对慢，实现细节变化更快，两者需要不同的同步节奏：一次变更结束前更新对应 Specs，一个 Epic 收尾时再把跨变更形成的领域模型、业务流程、服务边界和产品阶段回流到 Baseline。
图 8：亢江妹《从 PRD 到 Specs：AI 重塑需求工程》：Spec Sync 与 Baseline Sync 让需求资产持续保持有效
这一步决定了 Specs 是“一次性交付材料”，还是可以持续复用的组织资产。没有版本、变更理由和基线同步，规格很快就会和代码分离；有了共同版本和更新节奏，Agent 才能知道当前有效的事实是什么，下一次需求也不必再从旧文档和聊天记录中重新拼接上下文。
需求契约的终点，是一条可追踪的证据链
把三站分享放在一起，可以拼出一条完整链路：
业务意图经过分阶段澄清，转成可检查的需求模型；需求模型进一步形成验收规格，驱动 Agent 与 Skills 执行；执行结果在真实环境中生成证据，再回写 Specs 和 Baseline。
这条链路不能只停在文档之间。需求、设计、代码、测试和执行记录还要保持追踪关系。当某条验收失败时，团队需要知道它对应哪个需求场景、哪次设计决策和哪段实现；当需求发生变化时，也要能够定位哪些代码和测试需要同步更新。
图 9：林云《从代码编写到需求编译》：需求、设计、代码与测试通过追踪记录形成证据链
可追踪不是为了增加更多表格，而是为了让“为什么这样做、做到了什么、凭什么认为完成”能够被共同检查。只有这三件事连起来，需求才真正成为生成、验证、变更和复盘的主干。
对企业来说，不必一开始就建设一套庞大的“需求编译平台”，可以从一个最小闭环开始：
第一，选择一个边界清晰、频率较高的真实需求。让它完整穿过澄清、规格、生成和验收，而不是先覆盖全部产品线。
第二，建立一份最小业务语义库。先写清关键术语、接口、规则、错误码和边界，不追求一步到位。
第三，把验收条件前置，并设置人工确认点。AI 可以生成规格和用例，但范围、业务规则与放行条件要有人承担决策责任。
第四，打通一条真实环境链路。让至少一个用例真正执行、留下断言和结果，再讨论扩大自动化范围。
它看起来没有“一句话生成完整系统”那么炫目，却更接近企业真正需要的能力：不是让 AI 猜得更准，而是让模糊之处更早暴露，让每次交付都有契约、有证据、有回写。
还有一个容易忽略的边界：需求契约不能变成新的文档负担。凡是不能驱动设计、生成、测试或验收的字段，都应谨慎增加；凡是已经影响执行的规则，都不能只留在会议纪要和个人经验里。好的 Specs 不是最长的 Specs，而是每一条约束都能在后续环节被消费，每一次变化都能找到来源，每一个完成判断都能落到证据。
结语：需求不再只是写给人看的
AI Coding 让代码变得便宜，也让模糊需求的代价变得更高。
当生成速度不再稀缺，企业下一步真正要建设的，是把业务意图转成工程事实的能力。PRD 仍然重要，因为它承载价值、用户与范围判断；需求模型、Specs 和验收契约进一步把这些判断变成可执行、可验证的共同约定；测试和真实运行证据，则让契约不只是纸面承诺。
所以，给需求装上一台“编译器”，不是把产品经理变成程序员，也不是要求所有事情在开始前一次性写死。它是让人和 Agent 在同一套目标、边界、规则与完成条件上协作，并允许这些资产随着验证结果持续更新。
这可能是 AI 时代需求工程最重要的变化：需求不再只是研发工作的起点，也开始成为贯穿生成、验证、变更和复盘的主干。
国庆七日谈·第二日，我们继续讨论：上下文窗口越来越长，Agent 为什么还是不懂你的业务？
主要参考演讲
• 林云：《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》，第9届 AI+研发数字峰会（AiDD 2026 上海站）。
• 高林林：《基于智研的ATDD端到端实践》，AiDD 2026 北京站。
• 亢江妹：《从 PRD 到 Specs：AI 重塑需求工程》，AiDD 2026 成都站。
这么好的内容，你不转一下吗 下一站
北京营销中心
北京通州北京ONE国际广场10层
上海研究中心
上海市浦东软件园
厦门研究中心
厦门观音山国际商务运营中心
海外市场中心
香港中环香港站国际金融中心
加入智库
成为客户
