AI IDE规范驱动开发（SDD）中的四大鸿沟与噪声治理

在AI集成开发环境（AI IDE）中，规范驱动开发（Specification-Driven Development, SDD）范式正重新定义生产代码的效率。

其关键不同在于，产品经理或开发者通过自然语言描述意图，LLM自动生成规范（PRD）、设计（Spec）、任务列表（Tasklist）、代码，最终实现10x效能的软件开发。

我相信SDD代表了软件工程生产模式的飞跃。它让更多人，以更高效地方式介入到数字化创新之中。

尽管在一些稍微复杂的项目中，采用SDD的模式，代码表现就会里出外进，里倒歪斜，然而我依然认为SDD有巨大的生命力，这是任何新生物种的自然规律。

1. SDD，并不是开发者把规范制定好后就有了一劳永逸的、自动化开发的方案。至少今天还不是。

我们需要深潜当下问题，从而找到应对策略，释放SDD这种设计思想以及LLM的价值。

如果你简单套用SDD模式，很容易陷入“噪声过载”的困境。

LLM并非全知全能的设计师，这是一个基于概率的推理工具，它天然有一种倾向去制造“无效需求”、“过度设计”和“过度工作”这三种噪声。

2. 更深层次的问题在于，从【开发者意图】到【最终实现】的链条中，存在着四个本质性的鸿沟（Gaps）。

这四大Gaps是SDD流程中固有的。即使没有LLM也会存在，脱离了SDD的语境，在手工管理软件项目中，也依然存在。但LLM的介入，会放大它们，并让其更为复杂。

当我们试图利用LLM跨越这些Gap时，不知不觉中也纵容了噪声的存在。这些噪声累计放大了误差，最终导致了项目coding的完全失败。

Gap 1: 从意图到PRD之沟

制定PRD，是为了将模糊、抽象的商业目标和想法，转化为具体、无歧义、可执行的需求说明文档。

开发者的意图中充满隐含上下文，也包含许多未言明的假设。

我们期待PRD具体明确。但是在LLL生成PRD的过程中，LLM无法理解言外之意，只能基于文本模式进行补全。除了开发者未表明的意图之外，LLM制定的PRD，也有很多语义上的模糊地带。

Gap 2: 从PRD到设计之沟

制定详细的SPEC设计，包括很多方面，功能设计、交互设计、系统的架构设计、数据结构设计、API接口设计。它们互相依赖，互相影响。

在以往的开发模式中，产品经理和开发者的主观能动性发挥关键作用。他们的经验、常识、习惯、风格、好奇心、判断力和权衡取舍，在项目中发挥关键的作用。

LLM在这种本质的价值判断上，还是飘忽不定的。在技术决策方面，它依赖训练数据中的技术组合。在检查PRD的一致性和适用性上，并不具备天然的能力。

Gap 3: 从设计到任务之沟

这个阶段，开发者利用LLM制定Tasklist，将设计方案拆解为原子化、可排序、可执行的工作项。

这需要开发者理解工作之间的依赖关系、优先级和颗粒度。LLM能生成任务列表，但往往需要开发者进一步评估拆完整性和效率。仅凭LLM生成的任务清单，很容易产生冗余或遗漏。

Gap 4: 从任务到实现之沟

此期间，我们期待LLM将文本描述的tasklist任务指令，转换为准确、高效、安全且符合约束的代码。

当开发主体从人类变为LLM时，此Gap的性质发生巨变，它从“可沟通的理解偏差”变为“不可预测的生成偏差”。

3. 接下来，关键问题是“滋生噪声”

LLM在奋力跨越每一个Gap时，都会因其“贪图完整、屎上雕花”的本性，制造出大量的噪声（noises）。

从理解开发者意图到设计PRD的过程中，它会滋生“无效需求”。

LLM会补全看似相关，但实际不必要的功能需求，或过度详细地描述非核心的边角功能，污染PRD的纯净性。

从PRD转化到详细设计过程中，滋生“过度设计”。

LLM倾向于选择复杂、“时髦”的技术栈，设计过度抽象的API，或引入不必要的设计模式，以显得“专业”，从而增加系统复杂性和维护成本。

从详细设计到任务列表的转化过程中，滋生“过度工作”

基于有噪声的PRD和SPEC设计，LLM生成的任务清单会包含大量冗余、无效或优先级错乱的任务项，导致开发资源浪费。

从任务列表转化为代码实现的过程中，会继续放大之前累积的噪声，滋生更多的“逻辑与安全隐患”

这是自动化编程模式下最难以控制的噪声。 LLM生成的代码语法完美，但有隐秘的逻辑错误，或大规模引入安全反模式（如SQL注入）、API“幻觉”（过度拆分）。

4. 降噪策略：将LLM定位为“生成工具”，而非“决策主体”

实施SDD的关键，不在于消除Gap（这是不可能的），而在于系统地管理Gap。

也不在于完全信任LLM，而在于建立严格的流程来过滤和审计其输出。

我们需要一套“前置锚定、过程过滤、后置校验、测试并行”的机制。

前置锚定（Anchor Upfront）：在Gap的起点就明确边界。

需求与约束并行：在生成PRD时，必须同时明确“要做什么”和“禁止做什么”（功能边界、技术限制、资源上限）。

结构化表达：使用（Who/Given/Then/Shall）等结构化模板编写需求，压缩LLM的自由发挥空间。

强制拆分优先级：明确P0（本周期的核心）、P1（后续迭代）、P2（远期）。仅对P0进行详细展开。

过程过滤（Filter in Process）：在跨越每个Gap后立即进行净化。

收敛与简化：生成SPEC后，立即要求LLM对其进行精简，砍非核心功能、合并重复交互、简化技术栈、精简系统结构。

一致性校验：使用LLM自动比对PRD与Spec、Spec与Tasklist，生成“偏离清单”，并引导人工逐一确认和修正。

后置校验（Verify at the End）：在Gap的终点设置坚固防火墙。

人工审核：所有约束项和最终任务清单必须经过人工最终审核。

基线校验：每个开发任务启动前，都必须对照P0需求清单和禁止约束清单进行确认。

强制单元测试：每个任务完成后，必须同步生成并通过单元测试，覆盖功能、边界和约束，否则不能继续。

强制约束（Enforce Constraints）：在IDE中配置硬性规则，引入人为干预。

例如“禁止LLM在未经用户允许的情况下创建文件。严格执行任务清单，完成一项，验收一项，再推进下一项。在任何阶段都遵循用户指令，不擅自变更需求、设计或范围。”

5. 总结

用AI构建软件项目，你不再是追求代码编写速度，而是谁能更高效、高质量地治理LLM产生的噪声，谁能持续地、优雅地跨越四大鸿沟。

开发者需要转型为流程的监督者、规范的制定者和质量的守门人。产品、开发、测试角色越来越交叉，技能边界越来越模糊，。

通过流程优化，提升SDD的信噪比，将LLM生成能力约束在期望的轨道上，这是使用AI进行开发的人都需要关注的，也是会长期从中受益的。

Enjoy spec-coding！

（未完待续，后续我们会探索具体的SDD噪声/信噪比的评估和优化方案）

---

原文链接：https://mp.weixin.qq.com/s/q4VOGmdOPYmMqrU-NsxvXQ

来源：XT