在与大型企业共创 AI 时代开发新范式的过程中，词元无限发现了一个关键变化：当 AI 能够快速生成代码时，传统的"边写边调整"研发模式已经不再适用。
AI 的代码生成速度远超人工，意味着在代码生成之前，就需要明确定义"应该怎么写"。
这促使我们重新审视 SDD（Spec-Driven Development，规格驱动开发）在 AI Coding 场景下的价值。本文将结合真实项目的实践经验，探讨企业研发如何通过 SDD 实现 AI Coding 的规模化落地。
Tokfinity
# 01AI Coding 场景下的 SDD 重构
1.1 传统 SDD 的局限性
传统的 SDD 强调"先写规格再写代码"，核心目标是为开发人员提供清晰的实现参照。在人工编码场景下，开发人员可以在编码过程中逐步理解需求、调整设计、对齐规范。规格文档的不完备性，可以通过人的理解能力来弥补。
这种模式在人工编码时代是有效的。人的编码速度相对较慢，有足够的时间在编码过程中进行思考和调整。
然而，AI Coding 场景下，这种模式遇到了根本性的挑战。
AI 的代码生成速度远超人工，往往几分钟就能完成一个模块的实现。当 AI 在信息不完整的情况下开始编码时，它会根据已有上下文自行补全假设，而这些假设可能与实际需求存在偏差。
等到代码生成完成、进入 Code Review 阶段时才发现很多地方需要修改，这时修改成本已经大幅增加。
1.2 AI Coding 对 SDD 的新要求
AI Coding 场景下，SDD 需要解决的问题发生了本质变化。
在输入侧，我们需要将模糊的需求转化为 AI 可理解的结构化规格。这不仅包括业务逻辑的完整描述，还包括边界条件和异常处理的明确定义，以及技术实现的约束和规范。AI 无法像人一样通过"常识"来补全缺失的信息，它需要的是明确、完整、结构化的输入。
在执行侧，我们需要为 AI 提供可验证的执行标准。这包括代码规范和质量标准、架构约束和安全边界、测试要求和验收条件。这些标准不能只停留在文档中，而需要能够被自动化工具检查和验证。只有这样，AI 生成的代码才能在第一时间得到反馈，而不是等到人工 Review 时才发现问题。
在输出侧，我们需要建立自动化的质量保障机制。这包括代码审查的标准和流程、问题定位和修复的方法、经验沉淀和知识复用。AI Coding 的价值不仅在于提升当前任务的效率，更在于通过持续的经验积累，让后续任务的质量和效率都能得到提升。
1.3 SDD 与 Harness Engineering 的协同
近期，Harness Engineering 在 AI Coding 领域受到广泛关注。Harness 通过沙箱环境、自动化测试、权限控制、日志追踪等机制，确保 AI Agent 的执行过程可控、可验证。这些机制解决了 AI Agent 在长时间、自主执行任务时的稳定性和安全性问题，让 AI 能够"跑得稳"。
但 Harness 的有效运行依赖于一个前提：明确的规格基线。测试需要知道验证什么，权限控制需要知道哪些边界不能突破，质量门禁需要知道哪些标准必须满足，回滚机制需要知道什么状态是正确的。如果没有这个规格基线，Harness 可能只是让 AI 稳定地跑偏——执行过程很稳定，但执行结果却不符合预期。
这正是 SDD 的价值所在。SDD 为 Harness 提供了这个规格基线，定义了"什么是正确的执行"。Harness 解决"跑得稳"的问题，SDD 解决"跑得对"的问题。两者共同构成了企业级 AI Coding 的治理体系：SDD 在输入侧提供清晰的规格，Harness 在执行侧确保规格的实现，两者缺一不可。
# 02标准化 SDD 流程设计
词元无限在与大型企业项目的实践中，共同建立了一套 7 步标准化 SDD 流程。
这套流程的核心理念是：在 AI 生成代码之前，先把"要做什么、怎么做、做到什么程度"定义清楚，并在执行过程中持续验证和优化。
每个步骤都有明确的输入、输出和质量标准，确保 AI Coding 的可控性和可复现性。
步骤 1：需求澄清
需求澄清是整个 SDD 流程的起点，其目标是将模糊的需求转化为完整的功能规格。在传统研发模式下，开发人员往往是拿到一个简单的需求描述就开始编码，在编码过程中逐步理解需求细节。但在 AI Coding 场景下，这种方式会导致 AI 在信息不完整的情况下自行补全假设，从而产生偏差。
我们通过requirment_clarify 这个核心 Skill，让开发人员与 AI 进行结构化对话。AI 会通过渐进式提问，帮助开发人员澄清需求的各个方面：业务目标是什么？功能范围包括哪些？数据从哪里来？异常情况如何处理？验收标准是什么？通过这种方式，最终产出一份完整的 Spec 文档，为后续的设计和实现提供清晰的基础。
步骤 2：Spec Review
有了需求规格之后，下一步是检查 Spec 的完备性和正确性。人工 Review 虽然质量高，但耗时严重，容易成为瓶颈。我们引入了 AI 辅助 Review 机制，通过 spec_review 这个 Skill，让 AI 自动检查 Spec 中的常见问题，并以结构化的方式输出问题清单和修复建议。
这里的关键是明确 Review 标准。我们要求 AI 只标记会导致实现问题的严重问题，而不是纠结于措辞偏好或风格问题。输出格式采用 [行号]: [严重程度] [问题描述]. [修复建议]. 的结构化形式，便于开发人员快速定位和修复。人工只需要确认关键问题和修复方案，大幅降低了工作量。
Spec Review 的价值在于"防患于未然"。很多问题如果在设计阶段就能发现，修复成本是最低的；如果等到代码写完、联调失败、测试阻塞后才暴露，修复成本会成倍增加。通过 AI 辅助 Review，我们在设计阶段就能拦截大部分问题，避免实现阶段的返工。
步骤 3：详细设计
基于澄清和审查后的 Spec，下一步是生成技术实现方案。tech_design这个 Skill 会根据 Spec 生成详细的技术设计文档，包括模块划分、接口定义、数据结构、依赖关系等。这份设计文档不仅要说明"做什么"，还要说明"怎么做"，为后续的代码生成提供清晰的技术蓝图。
详细设计的价值在于提前暴露技术风险。在设计阶段，我们可以识别出哪些模块的职责不清晰、哪些接口的定义有歧义、哪些依赖关系可能导致循环依赖。这些问题如果在代码实现阶段才发现，往往需要大规模重构；而在设计阶段发现，只需要调整设计文档即可。
同时，详细设计文档本身也是一种技术资产。它记录了技术实现的关键决策和理由，为后续的维护和演进提供了重要参考。当新成员加入团队或需要修改某个模块时，设计文档能够帮助他们快速理解系统的技术架构。
步骤 4：Plan Review
有了技术设计之后，需要将其转化为可执行的实现计划。plan_review 这个 Skill 会将技术方案拆解为一系列可执行的任务步骤，明确每个步骤的输入、输出和验收标准，识别任务间的依赖关系和潜在风险。
Plan Review 的核心价值是确保实现计划的可执行性和可验证性。一个好的实现计划应该满足三个条件：第一，每个步骤都有明确的输入和输出，不存在模糊地带；第二，每个步骤都有清晰的验收标准，可以判断是否完成；第三，步骤间的依赖关系清晰，不会出现循环依赖或阻塞。
这个步骤也为 Harness 的执行提供了清晰的任务边界。Harness 需要知道每个任务的范围、约束和验收标准，才能有效地进行沙箱隔离、权限控制和质量门禁。Plan Review 产出的结构化实现计划，正是 Harness 所需要的规格基线。
步骤 5：代码生成
在前面四个步骤的基础上，代码生成阶段的 AI 已经拥有了完整的上下文：清晰的需求规格、详细的技术设计、可执行的实现计划。code_generation 这个 Skill 会严格遵循这些文档，自动应用项目规则和代码规范，生成符合团队标准的代码。
代码生成不仅包括业务逻辑的实现，还包括配套的单元测试。测试用例会覆盖关键逻辑和边界条件，确保代码的可靠性。同时，代码风格、命名规则、日志规范等团队规范会被自动应用，避免后续 Code Review 中的低价值修改。
这个阶段的关键是"质量内建"。通过前面步骤的充分准备，AI 生成的代码质量是可控的，符合团队规范的，可以直接进入 Code Review 阶段，而不需要大量的返工和修改。
步骤 6：Code Review
代码生成之后，需要进行质量审查。code_review 这个 Skill 实现了人机协同的 Code Review 机制：AI 负责自动审查代码规范、命名规则、异常处理、日志记录等常见问题；人工负责审查架构设计、业务逻辑、接口契约、安全边界等需要深度理解的问题。
这种分工充分发挥了 AI 和人各自的优势。AI 擅长发现规则性的问题，可以快速扫描代码，找出不符合规范的地方；人擅长理解业务逻辑和架构设计，可以判断代码是否真正解决了业务问题，是否符合系统的整体架构。
Code Review 的另一个重要价值是经验沉淀。当我们在 Review 中发现某个问题具有通用性时，就可以将其提炼为项目规则，注入到后续任务的上下文中。这样，同样的问题就不会在下一次编码时再次出现，实现了从"事后检查"到"事前约束"的转变。
步骤 7：Debug
即使经过了前面六个步骤的层层把关，代码在运行时仍然可能出现问题。debug这个 Skill 提供了系统化的问题定位和修复流程：首先复现问题，然后定位根因，最后验证修复效果。
Debug 的关键原则是避免猜测式修复。很多时候，开发人员看到一个错误，会根据经验猜测可能的原因，然后尝试修复。这种方式在简单问题上可能有效，但在复杂问题上往往会导致"修好了这个问题，又引入了那个问题"。系统化的 Debug 流程要求我们理解问题的根因，而不是仅仅修复表面症状。
同时，Debug 过程中积累的经验也应该沉淀为项目规则。常见问题的症状、根因和修复方法，都可以记录下来，形成团队的 Debug 知识库。这样，当类似问题再次出现时，就可以快速定位和修复，避免重复踩坑。
# 03规则（Rules）沉淀与知识复用
3.1 规则体系的构建
在企业实践中，我们沉淀了 9 大类项目规则，这些规则来自真实的开发、Review 和 Debug 过程，具有很强的实践价值。规则体系的构建不是一蹴而就的，而是在每一次 Code Review、每一次 Bug 修复、每一次技术讨论中逐步积累起来的。
代码风格规则是最基础的一类规则，它定义了类名、方法名、变量名的命名约定，缩进、换行、空格的使用规范，以及面向对象、函数式等编程范式的选择标准。这些规则看似简单，但对于保持代码的一致性和可读性至关重要。当 AI 生成代码时，如果没有明确的代码风格规则，每次生成的代码风格可能都不一样，给后续的维护带来困扰。
架构约束规则定义了系统的结构性约束。它明确了各模块的职责范围和边界定义，模块间的依赖方向和依赖方式，以及模块间接口的定义和约束。这些规则确保 AI 在生成代码时不会违反系统的架构原则，不会引入不合理的依赖关系，不会破坏模块的边界。
业务逻辑规则、接口规范规则、日志规范规则、异常处理规则、测试要求规则、权限校验规则，这些规则共同构成了业务实现层面的约束体系。它们定义了业务功能的范围和限制、接口返回数据的统一格式、日志应包含的关键信息、异常在调用链中的传播方式、单元测试的覆盖范围、权限校验的时机和方式等。这些规则确保 AI 生成的代码不仅在技术上是正确的，在业务上也是符合要求的。
调试经验规则是一类特殊的规则，它记录了项目中常见问题的识别和分类、常见问题的标准修复方法、问题根因定位的系统化方法。这些规则来自于实际的 Debug 过程，是团队踩过的坑、解决过的问题的结晶。有了这些规则，当类似问题再次出现时，AI 可以快速定位和修复，避免重复踩坑。
3.2 规则的生命周期管理
规则不是一次性制定的，而是在实践中持续演进的。规则的生命周期包括五个阶段：发现、提炼、应用、验证、优化。
发现阶段发生在 Code Review 或 Debug 过程中。当我们发现某个问题时，首先要判断这个问题是个例还是具有通用性。如果只是个例，解决掉就可以了；如果具有通用性，就进入提炼阶段。
提炼阶段需要将具体的问题抽象为通用的规则。这个过程需要思考：这个问题的本质是什么？它在什么场景下会出现？如何表述才能让 AI 理解并遵守？提炼出的规则应该是清晰的、可执行的、可验证的。
应用阶段是将规则注入到后续任务的上下文中。在 AI Coding 场景下，规则可以通过多种方式应用：可以写入项目的配置文件，可以注入到 AI 的[REDACTED]中，可以通过 Skills 自动检查。关键是让 AI 在生成代码之前就知道这些规则的存在。
验证阶段是观察规则的实际效果。规则应用后，我们需要持续观察：AI 是否理解了这个规则？是否正确地遵守了这个规则？规则是否真的解决了问题？如果发现规则的效果不理想，就需要进入优化阶段。
优化阶段是根据反馈调整规则。可能是规则的表述不够清晰，需要重新表述；可能是规则的粒度不合适，需要拆分或合并；可能是规则的应用时机不对，需要调整应用方式。通过持续的优化，规则会越来越精准、越来越有效。
3.3 知识沉淀的多层次机制
除了显性的规则，项目还可以建立更细粒度的知识沉淀机制。我们设计了四类结构化的知识文件，分别对应不同层次的知识沉淀需求。
code-style.json 记录代码风格偏好，包括命名规范的具体要求、格式化风格的详细配置、编程范式的选择标准。这些偏好往往是团队长期形成的习惯，很难用简单的规则描述，但通过结构化的配置文件，可以让 AI 精确地理解和遵守。
debugging.json 记录调试模式和错误解决方案，包括常见问题的症状描述、问题的根因分析、标准的修复方法。这是一个动态增长的知识库，每次 Debug 都可能向其中添加新的条目。随着知识库的不断丰富，AI 的 Debug 能力也会不断提升。
workflow.json 记录工作流程偏好，包括任务执行的标准顺序、工具使用的最佳实践、团队协作的流程规范。不同的团队可能有不同的工作习惯，通过 workflow.json，可以让 AI 适应团队的工作方式，而不是让团队适应 AI。
preferences.json记录用户通用偏好，包括选项选择的默认值、交互方式的个性化配置、团队习惯的记录。这些偏好可能不直接影响代码质量，但会影响开发体验。通过记录这些偏好，可以让 AI 提供更加个性化的服务。
这些结构化的知识沉淀，使得 AI Coding 能够持续学习企业的研发方式，实现能力的持续提升。每一次交互都是一次学习的机会，每一次沉淀都是一次能力的积累。
# 04SDD 在企业级研发组织转型中的新定位
AI Coding 的快速发展，使得 SDD 从一个可选的工程实践，变成了必要的治理手段。
在传统研发模式下，SDD 的价值主要体现在提高需求理解的准确性、减少实现阶段的返工、促进团队协作和知识共享。
这些价值在人工编码时代是重要的，但不是必需的——即使没有完善的 SDD 流程，有经验的开发人员依然可以通过自身的理解能力和技术能力完成高质量的代码实现。
但在 AI Coding 场景下，SDD 的价值发生了质的变化。它已经不再只是提升效率和质量的手段，而是成为了 AI Coding 能够正常运行的前提条件。
AI 需要清晰、完整、结构化的输入才能生成符合预期的代码，这要求我们必须在代码生成之前就把需求、设计、约束都定义清楚。
同时，SDD 为 Harness 提供了可验证的规格基线，使得 AI 的执行过程可以被自动化地监控和验证。SDD 还为组织提供了可沉淀的知识资产，让每一次 AI Coding 的实践都能转化为组织的能力积累。
词元无限在企业中的实践表明，SDD 是企业落地 AI Coding 的关键路径。
通过建立标准化的 SDD 流程、沉淀项目规则、积累知识资产，企业可以实现从个人提效到组织能力提升的跨越。
如果您对上文中提到的大型企业 SDD 实践过程感兴趣，欢迎关注公众号并后台与我们联系。
