为什么企业需要 Spec Driven：AI 写代码越快，需求越要结构化

——基于第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（4）

▼

AI 编程最容易制造一种错觉：只要模型足够强，软件交付就会自然变快。

在个人项目里，这种感觉很真实。一个想法、一段提示词、几轮对话，原型就能跑起来。过去需要几天写出的界面，现在可能一小时就有结果。于是很多团队开始相信，软件研发的主要矛盾已经从“写不出来”变成了“写得还不够快”。

但企业级研发恰恰相反。

当 AI 把“写代码”的速度推高，真正暴露出来的不是代码生产能力不足，而是需求表达、业务约束、系统边界和验收标准的薄弱。AI 越能写，模糊需求被放大的速度就越快；AI 越能改，局部变更引发系统偏移的概率就越高；AI 越像一个可调度的开发者，企业越需要一套能让它理解、复用、验证和追踪的结构化规格体系。

这就是Spec Driven 重新变重要的原因。它不是回到厚重文档时代，而是把企业过去散落在需求评审、产品经验、架构约定、测试用例和上线规则里的隐性知识，转化成 AI 可以读取、执行、校验和持续演化的工程资产。

图1：高桥《基于要素因子Spec需求工程实现质效双提》：需求分析的四类长期痛点（PPT第7页）

▍需求不结构化，AI 只是把混乱执行得更快

企业为什么不能只靠 Vibe Coding？

不是因为 Vibe Coding 没价值。恰恰相反，它非常适合探索、验证灵感、生成原型，也能显著降低从想法到可运行界面的门槛。问题在于，企业软件不是一个孤立页面，而是一组长期演进的业务规则、权限边界、系统集成、质量指标和合规要求。

中兴通讯需求领域AI教练高桥在峰会分享里，把需求分析的长期痛点归纳为四类：看不清对象、讲不清覆盖、理不清波及、效率低下。这四个问题并不新，但 AI 让它们变得更急迫。过去需求讲不清，开发会在评审、联调、测试阶段一点点暴露问题；现在 AI 可以在需求还没说清的时候直接生成大量代码，问题会更快进入系统内部。

这也是很多团队在尝试 AI Coding 后出现落差的原因：局部效率提升了，整体返工却未必下降。开发者不再卡在“怎么写一个函数”，而是卡在“这到底是不是业务想要的结果”“这个边界谁定义过”“这个改动会不会影响已有流程”“验收标准到底是什么”。

如果需求仍然只是一段自然语言描述，AI 很难判断哪些是核心意图，哪些是可变实现；哪些是必须遵守的边界，哪些只是临时举例；哪些验收项能自动化验证，哪些需要人工确认。它会努力完成任务，但完成的可能只是文字表面上的任务。

所以 Spec Driven 的第一层价值，是把“说给人听的需求”，进一步变成“人和 AI 都能共同执行的需求结构”。

▍Spec 的核心不是文档，而是可组合的需求数据结构

很多人一听到 Spec，第一反应是文档负担：更多模板、更多字段、更多评审、更慢的流程。

这是一种误解。企业真正需要的 Spec，不是把自然语言需求换一种格式存起来，而是把需求拆成可组合、可复用、可验证的数据结构。

高桥分享的要素因子化建模提供了一个很具体的视角：先识别对象的要素，再识别影响结果的因子和取值，通过正交组合形成场景空间，最后用 Given-When-Then 等方式实例化为可检查的用例。这个过程看起来像需求分析方法，实际上更像给 AI 准备一套“需求中间表示”。

图2：高桥《基于要素因子Spec需求工程实现质效双提》：要素化建模的关键概念（PPT第16页）

这套结构解决的是企业研发里最难自动化的一环：把经验从个人脑子里拿出来。

过去，资深产品经理知道哪些异常场景不能漏，资深测试知道哪些组合容易出问题，资深架构师知道哪些接口假设最危险。但这些经验往往以会议讨论、评审意见、历史问题单、口头提醒的形式存在。AI 如果拿不到这些结构，就只能依赖通用知识和当前上下文猜测。

Spec Driven 要做的，是把这些隐性判断固化成团队共享的结构：对象是什么，场景有哪些，边界在哪里，约束怎么表达，验收如何判定。这样 AI 不只是“生成代码”，而是在一个更明确的业务空间里工作。

当 Spec 成为数据结构，它还能被复用。一次需求分析留下的要素、因子、取值、测试场景和边界条件，可以成为下一次类似项目的起点。企业的研发能力因此不再只沉淀在代码库里，也沉淀在需求库、规格库、用例库和知识库里。

▍AI 写得越快，越需要约束它不要“自由发挥”

网易CodeWave智能开发平台架构师赵雨森在峰会分享中，把问题放在了更典型的企业 AI Coding 场景里：模型能力增强后，Vibe Coding 工具快速普及，但企业落地会遇到 AI 生成发散、技术栈不受控、代码难维护、效果难度量等问题。

这些问题的本质，不是模型不会写代码，而是企业没有把“什么样的代码可以进入系统”表达清楚。

图3：赵雨森《从Vibe Coding到Spec Driven网易智企智能化软件工厂的思考和实践》：Vibe Coding的企业级风险（PPT第9页）

AI 默认会追求完成当前任务。它可能选择最快的实现方式，可能引入团队不熟悉的依赖，可能绕过既有框架，也可能在一个局部修改中破坏长期维护性。个人开发时，这些选择可以接受；企业研发里，它们会变成后续交付、运维、安全和审计的成本。

因此，Spec Driven 的第二层价值，是为 AI 建立行为边界。

这个边界不是一句“代码要高质量”就能完成，而要落到具体结构上：需求应当如何澄清，EARS 或类似格式如何把模糊描述变成可判断表达，平台允许哪些技术栈，组件和接口怎么复用，生成代码要满足哪些规范，测试和评测如何进入流水线。

图4：赵雨森《从Vibe Coding到Spec Driven网易智企智能化软件工厂的思考和实践》：Spec-Driven对AI Coding流程的约束与贯通（PPT第26页）

这意味着企业里的 AI Coding 不应只是“给开发者一个更聪明的编辑器”，而应进入研发平台和工程流程：需求标准化、上下文管理、代码仓库理解、多 Agent 执行、效果评测、成本优化，都需要被纳入同一个规格驱动体系。

写代码越快，越不能让每次生成都成为一次孤立冒险。

▍Spec 还不够，企业最终要管理的是 Intent

如果 Spec 解决“怎么做得清楚”，那么 Intent 解决“为什么做、做到什么程度、如何判断值得交付”。

北京兴云数科资深需求AI教练、产品架构师郑涛在峰会的分享中提出了一个关键升级：Spec-Driven Development 已经能通过结构化规格降低偏差和返工，但复杂系统里还会遇到规格膨胀、语义漂移、代码与规范不一致等问题。原因在于，规格往往会越写越细，却不一定始终抓住业务意图。

图5：郑涛《意图驱动交付：Agent时代从交付系统到交付价值的实践》：SDD的核心价值（PPT第8页）

企业真正稳定的不是某个实现方案，而是业务想要达成的结果。

例如，一个员工档案系统的意图不是“做一个表单和几个按钮”，而是让员工从入职到离职的全生命周期状态可追溯，信息变更可审批、可留痕，权限范围内可查询。围绕这个意图，才会继续展开系统能力、集成约束、质量要求和边界条件。

图6：郑涛《意图驱动交付：Agent时代从交付系统到交付价值的实践》：从规格到意图的核心理念变化（PPT第12页）

这对 AI Agent 尤其重要。Agent 不只是执行一条指令，它会规划、拆解、调用工具、修改文件、运行测试，甚至与其他 Agent 协作。如果它只拿到局部 Spec，很容易在执行中丢失业务目标；如果它能持续对齐 Intent，Spec、代码、测试和交付物才有同一个方向。

因此，未来企业的需求资产可能会形成三层结构：Intent 负责表达业务价值和目标状态，Spec 负责表达解决方案和约束，Verification 负责表达验收准则与质量门禁。

图7：郑涛《意图驱动交付：Agent时代从交付系统到交付价值的实践》：意图对齐、意图执行、意图评估的闭环（PPT第22页）

这时，人类角色也会变化。人不再只是逐行检查 AI 写了什么，而是更早地定义意图，更清晰地设定边界，更系统地评审结果是否满足业务目标。

▍需求会成为 AI 时代的新“源代码”

上海交通大学副教授、系副主任、博士生导师林云在峰会分享里，用“需求编译”给出了一个更远的视角。

过去软件工程的抽象层不断上移：从二进制到汇编，从汇编到高级语言，从高级语言到框架和平台。AI 智能体出现后，新的抽象层可能是面向 AI 模型的中间表示，也就是可以被“编译”的需求。

图8：林云《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》：需求编译的历史类比（PPT第7页）

这件事听起来很超前，但已经可以在教学和实验场景中看到雏形。林云团队在软件工程课程试点中，让学生交付可以被编译的需求文档，并由 Agent 根据需求生成项目，再通过 GUI 测试验证结果。试点数据显示，需求编译成功率达到 100%，需求编译项目的 GUI 测试平均通过率约为 90.3%。

图9：林云《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》：需求编译试点结果（PPT第9页）

这个结果的意义不在于“AI 已经可以完全替代开发”，而在于它提示了一个方向：当需求足够结构化，软件交付可以从“人读需求、人写代码”，逐步变成“人定义需求表示，Agent 生成并验证交付物”。

林云提出的 ARC（Agentic Requirement Compiler）也对应了企业落地会遇到的四个问题：长上下文产生的幻觉、多模态处理、可维护性、以及智能体编程的调试。换句话说，需求编译不是简单把 PRD 扔给模型，而是需要需求建模、测试驱动、多模态对齐、交互式调试等工程能力共同支撑。

图10：林云《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》：ARC方法论对挑战的回应（PPT第14页）

如果说过去企业最核心的研发资产是代码库，那么 AI 时代企业还需要建设另一类资产：可被 AI 消化和执行的需求资产。

这些资产包括用户意图、业务规则、场景模型、交互约束、接口契约、非功能指标、验收准则、测试样例、历史缺陷和评审经验。它们共同决定 AI 生成的代码是否能进入真实系统，而不是停留在 demo。

▍企业需要的不是更厚的文档，而是更短的闭环

Spec Driven 最容易被误解为“前期写得更细，后期就少犯错”。这只说对了一半。

企业真正需要的是更短的闭环：从意图到规格，从规格到实现，从实现到验证，再把验证结果回流到规格和知识库。文档只是其中一种载体，关键是这些信息能不能被工具读取、被 Agent 使用、被测试验证、被团队复用。

因此，好的 Spec Driven 不应该拖慢团队，而应该减少三类浪费。

第一类浪费，是反复解释同一个业务规则。只要规则没有结构化，每个新人、每个 Agent、每次上下文重启，都要重新理解一遍。

第二类浪费，是把问题留到代码之后。需求边界、异常场景、非功能约束越晚出现，返工成本越高。AI 写代码越快，越应该在生成前把关键约束显式化。

第三类浪费，是交付后无法判断对错。如果验收标准没有被结构化，AI 生成物只能靠人工主观检查；如果验证意图清晰，测试、评测和质量门禁就能更早介入。

这也是 Spec Driven 对企业的真正价值：它让 AI 编程从“快写代码”进入“可控交付”。

▍结语：AI 越强，需求越不能停留在口头

AI 编程正在把软件工程推向一个很有意思的拐点。

过去，企业常常抱怨需求变化太快、开发资源不足、交付周期太长。现在，AI 正在缓解“写代码慢”的问题，却也把另一个事实暴露得更清楚：如果需求、规格、意图和验证没有结构化，企业只是更快地生产不确定性。

Spec Driven 的意义，不是让每个团队回到厚文档、重流程、慢评审，而是让企业把真正重要的工程判断沉淀下来：什么是业务目标，什么是系统边界，什么是可接受的实现，什么是必须验证的结果。

当这些内容变成 AI 可以理解和执行的资产，企业才可能真正把 AI Coding 从个人效率工具，升级为组织级研发能力。

🔖 主要参考演讲

·高桥：《基于要素因子Spec需求工程实现质效双提》，第9届AI+研发数字峰会（AiDD 2026 上海站），2026-05-23。

·赵雨森：《从Vibe Coding 到 Spec Driven网易智企智能化软件工厂的思考和实践》，第9届AI+研发数字峰会（AiDD 2026 上海站），2026-05-23。

·郑涛：《意图驱动交付：Agent时代从交付系统到交付价值的实践》，第9届AI+研发数字峰会（AiDD 2026 上海站），2026-05-23。

·林云：《从代码编写到需求编译：AI智能体驱动下的软件工程演进与前沿探索》，第9届AI+研发数字峰会（AiDD 2026 上海站），2026-05-23。

🔖 相关文章

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（1）：AI赋能研发组织提效的效果度量：从“个人效率”走向“组织交付”的新标尺

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（2）：从跑分到护栏：AI Agent 规模化落地，为什么必须先补上质量底座？

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（3）：从 AI Coding 到 Agentic Engineering：研发提效正在进入第二阶段

·硬核对话：从1000人到1人：AI编程的"规模化陷阱"如何破？

·第9届AI+研发数字峰会（AiDD）上海站圆满收官！

这么好的内容，你不转一下吗

转发本篇文章至朋友圈，截图私信后台可免费领取AiDD上海站演讲PPT下载链接！

下一站

Spec Driven 的故事，上海站只是开篇。

从 Vibe Coding 到 Spec Driven，再到 Intent Driven Delivery 和需求编译，背后其实是同一个问题：当 AI 能够更快地完成实现，人类和组织应该如何更清晰地定义“要什么”。

2026 年 AiDD 北京站，将在上海的基础上继续深挖：AI+业务与需求、智能需求工程、企业级 AI Coding 工作流，以及从意图到验证的完整交付闭环，还有更多企业的一线实践，等待登台分享。

AI 写代码会越来越快，但企业竞争力会越来越取决于：谁能把需求、知识和验证沉淀成可复用的组织资产。

北京，我们继续聊。