【系列】AI Coding 冲击下的需求质量与设计断层：需求与设计环节

• 第 1 篇：【系列】应对 AI Coding 提效冲击，研发测试面临的挑战、冲击到底是什么？
• 第 2 篇：【系列】应对 AI Coding 提效冲击，软件研发面临的系统性的挑战是什么？

引言：编码被压缩了，需求与设计反而膨胀了

系列第二篇从上帝视角扫描了研发全流程各环节的系统性问题，我们发现：需求与设计环节是问题的"隐性源头"——AI Coding 不会直接攻击需求与设计，但它会把这两个环节的每一个小问题，指数级放大到编码、测试、交付、运维全链路。

第二篇里有一张表格值得再看一遍：

数据来源：基于行业企业实践案例分析及 MIT SlopCodeBench (2026) 关于 AI 代码结构侵蚀的研究数据综合整理。© iLearnAI 整理，转载请注明出处。

但放大倍数只是表象，真正值得深究的是：为什么 AI Coding 会让需求与设计环节从"幕后配角"变成"前台瓶颈"？

答案藏在研发工时结构的变化里。

2025 年到 2026 年间，AI Coding 正在从根本上改变软件研发各阶段的工时分配：

数据来源：基于行业 SDLC 工时分配调研数据，参考 arte.itlibra.com《How AI Changes the Software Development Lifecycle》(2026) 及中国信通院《AI4SE 行业现状调查报告(2026 年)》综合整理。© iLearnAI 整理，转载请注明出处。

编码从 40% 压缩到 10%，需求与设计从 25% 膨胀到 55%。

这意味着什么？研发重心正在从"写代码"向"定义做什么"转移。 过去，需求粗放一点，编码阶段慢慢修正；设计模糊一些，开发者在写代码过程中逐步补齐。现在，编码被 AI 压缩到近乎瞬时，需求与设计的每一个漏洞都会被 AI 在几分钟内放大成几千行偏差代码。

中国信通院的调研数据也印证了这一趋势：AI 对研发各环节的提效并不均衡——开发环节效率提升从 2024 年的 29.06% 提升到 32.63%，运维环节从 28.67% 跃升至 36.36%，但需求和设计环节的提效幅度明显滞后。

数据来源：中国信通院人工智能研究所《AI4SE 行业现状调查报告(2026 年)》，2026 年 4 月发布。© 中国信通院，引用请注明出处。

换句话说：AI 在编码环节一骑绝尘，在需求与设计环节却几乎没有实质性的提效。 这个效率鸿沟，就是本篇要拆解的核心矛盾。

3.1 问题与场景：需求质量如何被"指数级放大"

场景一：模糊需求 × AI 编码 = 偏差代码洪流

某团队产品经理提交了一份功能需求文档，颗粒度较粗——"做一个用户权限管理模块"。传统模式下，开发者会先与产品经理反复对齐，细化到字段级再动手编码，可能花半天讨论、一天编码。AI Coding 时代，开发者直接把需求文档喂给 AI，AI 在 10 分钟内生成了完整的 CRUD 代码——但业务规则完全错误：权限继承逻辑、角色互斥规则、数据隔离策略这些隐性规则，AI 根本无从得知。

结果：代码产出 5000 行，可用率不到 30%，返工时间反而比手写更长。

这不是个例。Stack Overflow 2025 开发者调查显示，66% 的开发者对"几乎正确但不完全对"的 AI 解决方案感到沮丧，45.2% 认为调试 AI 生成的代码比手写更耗时。

数据来源：Stack Overflow 2025 Developer Survey；the-decoder.com《Developers Rely on AI Tools More Than Ever, But Trust is Slipping》(2025)。© 原调研机构所有，引用请注明出处。

根本原因：需求只存在于"聊天对话"或"模糊的 PRD"中，没有结构化的约束。AI 拿到模糊输入，就会"尽力推断"——推断对了是运气，推断错了是 Bug。

场景二：隐性规则缺失——"老员工脑子里的东西"

企业真正的核心系统——ERP、交易、支付、用户权限——90% 的工作是存量迭代，而不是从 0 到 1。这些系统里有大量隐性规则：权限继承逻辑、角色互斥规则、数据隔离策略、跨模块依赖约束、多版本兼容要求……

这些规则不在文档里，不在 PRD 里，不在注释里，只在老员工的脑子里。

传统模式下，隐性规则靠"人传人"——老员工带新人，Code Review 时口头提醒，踩坑后形成经验。虽然低效，但至少能兜住。AI Coding 时代，AI 不知道这些规则的存在，会按"通用模式"生成代码——语法正确、逻辑错误。

典型案例：某金融系统新增一个"资金划拨"功能，开发者用 AI 生成了完整代码并通过了所有单元测试。但上线后发现：资金划拨绕过了风控审批流程。原因是：风控审批是写在系统里 5 年前的一条隐性业务规则——金额超过 10 万必须走三级审批，这条规则存在于一个老员工的脑子里，没有写在任何文档里，AI 生成代码时完全不知道它的存在。

数据来源：基于行业企业实践案例分析及 CodeRabbit (2025)《State of AI vs Human Code Generation Report》安全漏洞密度数据综合整理。© iLearnAI 整理，转载请注明出处。

场景三：设计断层——AI 绕过架构直接生成

传统开发中，架构设计是编码的前提——先定模块边界、接口契约、数据模型，再按设计编码。AI Coding 时代，AI 可以在没有架构设计的情况下直接生成完整代码，绕过架构约束。

MIT & UW SlopCodeBench (2026) 的研究发现：AI 代码违反架构规则的情况高达人类的 2.9 倍，在 80% 的轨迹中出现结构侵蚀，89.8% 出现冗长问题。核心通过率与全量通过率的差距从 1.4 倍扩大到 13.3 倍。

数据来源：MIT & University of Washington, SlopCodeBench (2026)，arxiv.org/pdf/2603.24755； snorkel.ai《SlopCodeBench: Measuring Code Erosion as Agents Iterate》。© 原研究机构所有，引用请注明出处。

Google 2025 DORA 报告进一步印证了这个趋势：AI 采纳率每提高 90%，Bug 率上升约 9%，代码审查时间增加 91%，PR 体积膨胀 154%。

数据来源：Google《2025 DORA Report》；Harness 2025 开发者调研；GitClear 2020-2024 代码质量分析。© 原研究机构所有，引用请注明出处。

一句话概括这三个场景的本质：需求与设计环节的问题不是 AI 造成的，但 AI Coding 把这个环节问题的代价指数级放大了。模糊需求在传统模式下是"慢工出细活"的修正过程，在 AI 模式下变成了"偏差代码洪流"的源头。

3.2 前后依赖：需求与设计的上下游关系

需求与设计是研发流程的最前端，它的输出质量直接决定了下游所有环节的压力大小。

3.2.1 依赖关系全景

数据来源：© iLearnAI 整理，基于系列各篇规划及行业实践。转载请注明出处。

3.2.2 上游卡点：需求评审缺失"AI 可执行性"检查

传统需求评审关注三个维度：业务价值、功能完整性、可行性。但在 AI Coding 时代，这三个维度已经不够了。

一条模糊的需求，交给人类开发者，他会在编码过程中主动追问、逐步细化。但交给 AI，它不会追问——AI 会"自信地"生成代码，然后你发现它理解错了。

数据来源：© iLearnAI 整理，参考 GitHub Spec Kit 设计理念及企业实践。转载请注明出处。

关键卡点：需求评审目前完全没有"AI 可执行性"这个维度。产品经理写完 PRD，评审通过后直接进入开发，没有人检查这份需求"AI 能不能正确理解"。

3.2.3 下游影响：需求质量决定全链路代价

需求阶段的一个偏差，经过 AI Coding 的放大，到下游会变成什么样的代价？

行业经典的质量修复成本递增模型，在 AI Coding 时代被进一步放大：

数据来源：基于 IBM Systems Sciences Institute 质量成本模型及 CodeRabbit (2025) AI 代码缺陷密度数据推算。© iLearnAI 整理，转载请注明出处。

核心判断：在 AI Coding 时代，需求阶段的投入产出比（ROI）被进一步放大——在需求阶段多花 1 小时把规则显性化，可能避免下游数十小时甚至数百小时的返工。

3.3 关键短板：三个致命缺口

3.3.1 短板一：需求颗粒度未定义——传统 PRD 面向人，不面向 AI

传统 PRD 的读者是人——人类开发者可以通过上下文理解、追问来弥补需求模糊。但 AI 的读者变成了Agent——它不会追问，只会"推断"。

中国信通院在《AI4SE 行业现状调查报告(2026 年)》中明确指出这一趋势：研发流程产物的第一读者正在从"人"转变为"Agent"，产物设计标准从"人类可理解"升级为"Agent 可消费"。

数据来源：中国信通院《AI4SE 行业现状调查报告(2026 年)》；参考 GitHub Spec Kit 设计理念。© 原机构所有，引用请注明出处。

现状：绝大多数企业的 PRD 仍然停留在"面向人"的阶段——自然语言叙述、模糊的验收标准、缺失的边界条件。这种 PRD 交给 AI，等于让 AI "猜"你要什么。

3.3.2 短板二：隐性规则未显性化——"只存在于人脑中的规则"

企业核心系统中大量隐性规则散落在各处：老员工的脑子里、散落的 Wiki 页面中、某些代码注释里、某些测试用例里……从未被系统性梳理。

Veracode 2025 年的研究发现，45% 的 AI 生成代码样本引入了 OWASP Top 10 漏洞，覆盖 100+ 个测试模型。这不是因为 AI "能力不行"，而是因为它不知道这些规则的存在。

数据来源：基于行业企业实践案例估算及 Veracode (2025) AI 代码安全漏洞研究。© iLearnAI 整理，转载请注明出处。

核心矛盾：AI 的编码能力越强，对隐性规则的依赖就越大——因为 AI 生成代码的速度远远超过了人类梳理规则的速度。规则梳理跟不上，AI 代码就永远是"看起来对但逻辑错"。

3.3.3 短板三：架构设计未定义 AI 边界——AI"想改哪里改哪里"

传统架构设计关注模块划分、接口定义、技术选型。但在 AI Coding 时代，还多了一个关键维度：哪些模块允许 AI 生成，哪些必须人工？AI 生成的代码在什么约束下运行？

目前几乎没有企业在架构设计中定义"AI 生成边界"。结果是：AI 在生产代码库中"自由发挥"——该重构的地方它不碰，不该动的地方它大改特改。

Anthropic 2026 年 Agentic Coding 趋势报告揭示了一个关键数据：开发者在约 60% 的工作中使用 AI，但表示能够"完全委托"给 AI 的任务仅占 0%-20%。AI 是强大的合作者，但不是自主操作者。

数据来源：Anthropic《2026 Agentic Coding Trends Report》；参考 GitHub Spec Kit 及 Augment Code SDD 实践。© 原机构所有，引用请注明出处。

关键短板总结：

数据来源：© iLearnAI 整理。转载请注明出处。

3.4 研发模式变化：从"串行接力"到"并行约束"

3.4.1 传统模式：需求 → 设计 → 编码的串行接力

传统研发模式中，需求、设计、编码是串行接力——产品经理写完 PRD，交给架构师做设计，再交给开发者编码。每个环节的输出是下一个环节的输入，节奏匀速，边界清晰。

在这个模式下，需求模糊的后果在编码阶段才慢慢暴露：开发者写代码的过程中发现需求有漏洞，回头找产品经理确认，修改 PRD，再继续编码。虽然效率不高，但反馈周期可控——因为编码本身就是"慢工出细活"的过程，有足够的时间修正。

3.4.2 AI 时代模式：需求 + 设计 +AI 约束的并行定义

AI Coding 时代，这个串行模式被打破了。编码被压缩到近乎瞬时，需求和设计的漏洞会在几分钟内被 AI 放大成数千行偏差代码。这意味着需求和设计必须在编码之前就足够精确——不能再靠编码过程中的反馈来修正。

数据来源：© iLearnAI 整理，参考 Anthropic 2026 Agentic Coding Trends Report 及 Shift-Up Framework 研究框架。转载请注明出处。

3.4.3 新范式的核心：从 Vibe Coding 到 Spec-Driven Development

2025 年 2 月，Andrej Karpathy 提出了"Vibe Coding"——用自然语言描述需求，让 AI 生成代码，"忘记代码的存在"。Collins 词典将其评为 2025 年度词汇。Y Combinator 报告称，2025 年冬季批次 25% 的创业公司代码库 95% 由 AI 生成。

但仅一年后，行业就经历了"Vibe Coding 宿醉"——Fast Company 将其称为"the vibe coding hangover"。甚至连 Karpathy 本人在最新项目中也回到了手写代码，承认 AI Agent 对于一次性实验以外的场景"并不够用"。

问题本质：Vibe Coding 依赖的是即兴的、缺乏边界的自然语言交互。在简单原型中极具爆发力，但在企业级应用中会导致严重的上下文腐化、架构失控和难以追溯的系统性缺陷。

行业给出的答案是 Spec-Driven Development（SDD，规格驱动开发）：

核心原则：不要让 AI 从 Prompt 写代码。给它一份精确描述"做什么"的规格（Spec），再给它确定性工具来处理"怎么做"。

GitHub 于 2025 年 9 月推出 Spec Kit，到 2026 年 4 月已获得超过 90,000 个 Star，支持 20+ 编码 Agent。AWS 发布了 Kiro——第一个内置 SDD 工作流的 IDE。阿里推出了 QoderWork，民生银行在企业级落地了 SDD 实践。

数据来源：GitHub Spec Kit (2025.9 发布，2026.4 数据)；AWS Kiro；腾讯云开发者社区《Agent 与 SDD 重塑 AI 时代的软件开发生命周期》(2026)；民生银行 SDD 实践。© 原平台/机构所有，引用请注明出处。

微软对 SDD 有一句精辟的评价："SDD is version control for your thinking."（SDD 是你的思考的版本控制。）传统版本控制管理代码的演变历史，SDD 管理思考的演变历史——为什么做这个功能、边界在哪里、成功标准是什么。当代码可以被 AI 秒级重写时，真正有价值的不是代码本身，而是代码背后的决策。

3.4.4 SDD 落地的三个层次

ThoughtWorks 杰出工程师 Birgitta Boeckeler 提出了 SDD 的三个成熟度层次：

数据来源：Birgitta Boeckeler, ThoughtWorks；参考民生银行《从"对话式编程"到"规格驱动"：企业级 AI 研发范式重构实践》(2026)。© 原作者/机构所有，引用请注明出处。

民生银行的实践进一步丰富了企业级 SDD 的规格层次设计：

数据来源：民生银行《从"对话式编程"到"规格驱动"：企业级 AI 研发范式重构实践》，掘金 (2026)。© 原作者/机构所有，引用请注明出处。

3.5 流程优化：四步落地方案

第一步：需求颗粒度标准化——定义"AI 可消费"的需求结构

把传统 PRD 从"自然语言叙述"升级为"结构化需求规格"。核心是让需求从"面向人"变成"面向 Agent 可消费"。

推荐的需求规格模板：

## 需求规格

### 目标（Goal）
[一句话描述这个需求要解决什么业务问题]

### 范围（In-scope）
[明确列出这个需求包含的功能点]

### 非范围（Out-of-scope）
[明确列出这个需求不包含的内容，防止AI过度生成]

### 输入/输出契约
[输入参数、输出结果的精确定义，包括类型、格式、约束]

### 业务规则
[显性化的业务规则列表，包括边界条件、异常处理、事务一致性要求]

### 验收标准（Definition of Done）
[可执行的验证条件，推荐 Given-When-Then 格式]

### 约束条件
[性能要求、安全要求、兼容性要求、架构约束]

### 受保护的文件/模块
[不允许AI修改的文件和模块列表]

模板来源：参考 GitHub Spec Kit 需求模板及 RanketAI《How to Reduce Rework in Vibe Coding》(2026) 实践指南。© iLearnAI 整理，转载请注明出处。

这个模板的核心变化是增加了三个传统 PRD 没有的维度：非范围（Out-of-scope）、受保护文件、可执行的验收标准。前两者防止 AI 过度生成，后者让验证可以自动化。

第二步：隐性规则显性化——建设业务规则知识库

隐性规则显性化是一个系统性工程，不可能一蹴而就。建议分三批推进：

数据来源：© iLearnAI 整理，基于行业企业实践。转载请注明出处。

关键经验：不要追求"100% 规则显性化"——这不现实也不经济。优先覆盖核心业务链路（交易、支付、权限、风控），这些领域的隐性规则缺失代价最高。

第三步：AI 生成边界定义——架构设计中增加"AI 约束层"

在架构设计中新增"AI 生成边界"维度，明确每个模块的 AI 生成策略：

数据来源：© iLearnAI 整理，参考 Anthropic 2026 Agentic Coding Trends Report（AI 可完全委托任务仅 0-20%）。转载请注明出处。

同时，架构约束需要从"文档"升级为"机器可读的规则文件"，例如：

• 接口契约：使用 OpenAPI / JSON Schema 定义，让 AI 可以自动验证输出
• 架构约束：使用 C4 模型描述架构层次，ADR（Architecture Decision Records）记录架构决策
• 编码规范：写入 CLAUDE.md / AGENTS.md 等规则文件，AI 每次生成代码时自动加载

Shift-Up 框架（2026）的研究验证了这一思路：使用 BDD（行为驱动开发）+ C4 模型 + ADR 作为"护栏"（guardrails），可以有效约束 AI 的生成范围。研究表明，使用机器可读的 JSON Schema 格式可以让 AI 自验证输出的一致性提高 30%-40%。

数据来源：Shift-Up Framework（Lipsanen et al., 2026；Stirbu et al., 2025）；Augment Code《What Is Spec-Driven Development》(2026)。© 原作者/研究机构所有，引用请注明出处。

第四步：需求变更影响分析——AI 辅助评估变更影响范围

传统模式下，需求变更的影响分析靠"人脑判断 + 经验评估"。AI Coding 时代，变更影响范围更大（AI 已生成大量代码），人工评估已经力不从心。

数据来源：© iLearnAI 整理，基于行业实践。转载请注明出处。

落地优先级：

数据来源：© iLearnAI 整理。转载请注明出处。

3.6 角色变化：从"写需求"到"定义 AI 可执行规格"

3.6.1 产品经理：从"写 PRD"到"定义 AI 可执行需求"

数据来源：© iLearnAI 整理，参考 GitHub Spec Kit 设计理念及企业实践。转载请注明出处。

3.6.2 架构师：从"画架构图"到"AI 边界定义者"

数据来源：© iLearnAI 整理，参考 Shift-Up Framework 及 C4 Model / ADR 实践。转载请注明出处。

3.6.3 新角色：业务规则工程师

随着隐性规则显性化的需求越来越迫切，一个新角色正在浮现：业务规则工程师。

这个角色的核心职责是把散落在各处的隐性规则——老员工脑子里的、Wiki 页面中的、代码注释里的、测试用例中的——系统性地梳理、结构化、文档化，形成可被 AI 消费的规则知识库。

数据来源：© iLearnAI 整理。转载请注明出处。

这个角色可以由资深业务分析师、领域专家或有业务背景的测试工程师转型。关键能力不是编码，而是业务理解力 + 结构化表达能力。

3.6.4 角色转型路线图

数据来源：© iLearnAI 整理。转载请注明出处。

3.7 本篇总结

回到本篇的核心论点：AI Coding 放大了需求粗放和设计断层的代价。需求越模糊，AI 生成的代码偏差越大；设计越缺失，AI 代码的技术债务越重。

数据来源：© iLearnAI 整理，综合各研究机构数据。转载请注明出处。

本篇给出的解决方案框架：

需求颗粒度标准化（面向AI的结构化需求规格）
        ↓
隐性规则显性化（业务规则知识库，优先核心链路）
        ↓
AI生成边界定义（架构约束层 + 机器可读规则文件）
        ↓
需求变更影响分析（AI辅助评估变更范围和返工量）

核心判断：需求与设计环节不是"AI 来了才需要补"的短板，而是"AI 来了之后短板代价被指数级放大"的致命环节。好消息是，行业已经给出了方向——从 Vibe Coding 到 Spec-Driven Development，从"面向人的 PRD"到"面向 Agent 的规格"，这不是倒退到瀑布流，而是研发产物标准的升级。

下一篇文章预告：

需求与设计的问题解决了，接下来就是 AI Coding 的主战场——编码环节。但正如第二篇指出的，编码提速 10 倍只是表象，真正的问题是全功能团队的快速迭代 Loop 断裂：编码 10 倍速，但代码审查、UT、SDV 仍然只有 1 倍速。下一篇将聚焦编码与快速迭代 Loop，拆解如何让整个 Loop 转起来。

版权声明：本文由 iLearnAI 原创，发布于 ilearnai.online。文中引用的研究数据分别来自以下机构的研究报告，版权归原作者所有：

• 中国信通院：《AI4SE 行业现状调查报告(2026 年)》
• MIT & University of Washington：SlopCodeBench (2026)
• CodeRabbit：《State of AI vs Human Code Generation Report》(2025)
• Google：《2025 DORA Report》
• Stack Overflow：2025 Developer Survey
• Anthropic：《2026 Agentic Coding Trends Report》
• GitHub：Spec Kit 项目及相关研究
• Veracode：2025 AI 代码安全漏洞研究
• Harness：2025 开发者调研
• GitClear：2020-2024 代码质量分析
• Shift-Up Framework：Lipsanen et al. (2026), Stirbu et al. (2025)
• 民生银行：企业级 SDD 实践 (2026)
• ThoughtWorks：Birgitta Boeckeler SDD 层次策略