1. 前言

在此前的系列文章中，笔者已经从理论和工具维度详细介绍了 SDD （规范驱动开发）的全貌：

• 《SDD规范驱动开发：AI时代的软件工程新范式》 - SDD 的设计思想、核心理念与三款主流工具概览
• 《OpenSpec：轻量级AI工程规范管理框架》 - OpenSpec 的核心概念、目录结构与基础使用方法
• 《Spec-kit：SDD规范驱动开发的工程化工具》 - Spec-kit 的工作流设计与模板约束机制
• 《Superpowers：为AI编程智能体赋予工程化超能力》 - Superpowers 的可组合技能库与工作流能力

然而，理论与实践之间始终存在落差。本文聚焦 实战 ：记录笔者如何选择 OpenSpec 作为落地框架、如何配置 Claude Code 工具链、如何在真实项目中执行 SDD 开发闭环，以及在实践过程中踩过的坑和总结出的改进方案。

本文的项目基于 Claude Code + GLM/Claude/GPT 实践，项目地址： https://github.com/gqcn/openspec-practice/

2. SDD工具横向对比

在深入实践之前，有必要先梳理清楚三款主流 SDD 工具的能力边界，方便读者根据自身情况做出合理选型。

2.1 对比概览

2.2 工具选型

综合以上对比，笔者选择了 OpenSpec 作为 SDD 落地的核心框架，主要原因如下：

2.2.1 学习成本低

OpenSpec 的核心概念只有四个（ specs 、 changes 、 delta specs 、 artifacts ），五分钟内即可理解并开始使用。

2.2.2 易于定制扩展

OpenSpec 的设计遵循"流动而非刚性"原则，可以根据项目需求灵活添加自定义技能，弥补其功能简单的短板。

2.2.3 工具兼容性广

与几乎所有主流 AI 开发工具（ Claude Code 、 Cursor 、 GitHub Copilot 等）兼容，不受特定平台约束。

2.2.4 满足大部分需求

对于中小规模的 AI 协同开发项目， OpenSpec 的核心工作流 - 探索、提案、实现、归档 - 已能满足绝大部分场景需求，额外的测试和审查能力通过自定义技能补全。

3. 开发工具配置：Claude Code

AI 代码开发工具选择的是 Claude Code - 目前业内公认综合开发能力最强的 AI Agent 开发工具，在复杂系统理解、长上下文记忆、多步骤任务执行等方面均有出色表现，能够很好地支持 SDD 的工程化落地实践。

3.1 已安装插件

以下是笔者在 Claude Code 中安装的插件列表：

有的插件看起来不错，但如何触发仍是一个谜，例如 code-review 和 code-simplifier 、 ralph-loop ，在与 AI 交互的过程中，并没有显式地看到 AI 有自动调用这些插件。

3.2 已安装技能（Skill）

除插件外，还安装了以下技能来强化特定领域的开发能力：

其中 goframe-v2 是当前实践项目使用的 Golang 后端框架，各位看官如果使用不同的技术栈，可以考虑开发或寻找对应的技能来提供框架规范审查能力，例如 Spring Boot 、 Django 、 Express 等主流后端框架都可以通过类似的技能实现规范审查。

3.3 OpenSpec配置文件

OpenSpec 初始化后会在 openspec/ 目录下生成 config.yaml 配置文件，这是框架的核心配置入口。通过合理配置该文件，可以为 AI 生成的所有变更产物注入项目上下文约束，避免重复在每次提示词中说明。

以下是项目中实际使用的 config.yaml 配置：

schema: spec-driven

# 项目上下文（可选）：在 AI 创建各类产物时会自动注入
# 适合放置技术栈说明、规范要求、领域知识等
context: |
  Output language: All artifact content must be written in Simplified Chinese,
  including section titles, descriptions, scenario text, and task items.

# 各产物的独立约束规则
rules:
  tasks:
    - |
      When a task involves E2E test cases, the TC ID generating should follow
      the openspec-e2e skill conventions.

配置建议 ：在 context 中明确声明产物的输出语言，能确保 AI 生成的 proposal.md 、 design.md 、 tasks.md 等文档始终保持一致的语言风格，避免中英文混杂。

4. OpenSpec工程实践流程

4.1 流程全景图

4.2 工程实践流程概述

在项目中，完整的一次功能迭代遵循以下五步标准化流程。 OpenSpec 原生设计中，每个阶段均需用户 手动输入对应的斜杠命令 来驱动流程推进 - 例如探索结束后需手动执行 /opsx:propose ，实现完成后需手动执行 /opsx:archive 等。这对用户造成了一定的心智负担，也容易出现跨阶段混乱调用的情况（例如忘记先 propose 就直接 apply ）。

为此，笔者在项目的 CLAUDE.md 规范文档中补充了对每个阶段 自动触发条件 的明确描述，将流程驱动的判断从"人工记忆"转移为"规范约束"：

1. 探索式对话结束、形成清晰解决方案时 → 自动进入变更提案阶段
2. 变更提案文档生成完毕后 → 自动进入代码实现阶段
3. 每个任务代码实现完成后 → 自动触发 E2E 测试与 openspec-review 审查
4. 用户反馈问题或改进点时 → 自动触发 openspec-feedback 反馈修复流程
5. 用户确认本次迭代完成没有问题后 → 自动触发归档流程

通过这种方式，流程的推进变得更加丝滑和自动化，用户只需专注于业务需求本身，无需记忆和手动触发每一个阶段命令，从而有效降低了心智负担，也避免了因跨阶段调用导致的流程混乱问题。

第一步：探索式对话（ /opsx:explore ） - 手动或自动触发

这一阶段通常使用高复杂度、高模糊度、强推理，且上下文窗口较大的模型，例如 Claude Opus 4.6 1M 。

在开始任何实现之前，通过 /opsx:explore 斜杠指令进入探索模式。给定需求描述后， AI 会扮演思维伙伴的角色，深入分析问题背景、梳理多种解决方案并评估各方案的风险与收益，通过 ASCII 图表直观呈现架构思路。 探索模式不产生任何代码 ，只沉淀清晰的思路与方案共识。

4.2.2 第二步：生成正式变更提案（ /opsx:propose ） - 手动或自动触发

这一阶段通常使用高复杂度、高模糊度、强推理，且上下文窗口较大的模型，例如 Claude Opus 4.6 1M 。

当探索对话收敛、形成清晰的解决方案后，通过 /opsx:propose feature-name 将思路转化为正式的 OpenSpec 变更提案文档。命令中的 feature-name 为当前变更的描述性名称，使用 kebab-case 格式（如 user-auth 、 data-export ）。

执行后，在 openspec/changes 目录下自动生成以下变更产物：

openspec/changes/feature-name/
├── proposal.md      # 变更提案：做什么、为什么
├── design.md        # 技术实现方案：怎么做
├── specs/           # 增量规范文档（Delta Specs）
│   └── *.md
└── tasks.md         # 实现任务清单（带勾选框）

4.2.3 第三步：按任务清单逐条实现（ /opsx:apply ） - 手动或自动触发，建议手动

这一阶段通常使用高标准化、高重复、成本敏感的模型，例如 Claude Sonnet(1M) 或者高性价比的国内模型 GLM-5 。

执行 /opsx:apply 后， AI 按照 tasks.md 中的任务清单逐条完成代码实现、测试编写和文档更新。 每个任务完成后自动调用 /openspec-review 技能进行代码和规范审查 。涉及前端页面功能的任务，还需创建 E2E 端到端测试用例并在执行过程中自动运行，确保功能实现的正确性。

4.2.4 第四步：处理用户反馈（ /openspec-feedback 扩展技能） - 手动或自动触发，建议手动

这一阶段通常使用高复杂度、高模糊度、强推理，且上下文窗口较大的模型，例如 Claude Opus 4.6 1M 。

用户对已实现功能进行验收时，发现的问题或改进点通过 /openspec-feedback 技能处理。技能会自动将反馈组织为可追踪的任务记录，评估是否需要更新当前迭代的设计文档，进行影响面分析，并在修复完成后自动触发测试和审查流程。 每个反馈任务完成后也会自动调用 /openspec-review 技能进行审查 。

4.2.5 第五步：归档变更（ /opsx:archive ） - 手动或自动触发，建议手动

这一阶段通常使用高标准化、高重复、成本敏感的模型，例如 Claude Sonnet(1M) 或者高性价比的国内模型 GLM-5 。

用户确认本次迭代全部功能完成且无问题后，执行 /opsx:archive 将变更归档。 归档前会自动调用 /openspec-review 技能进行全面审查 ，确保代码质量与规范遵循。归档时， AI 会将必要的增量规范（ Delta Specs ）同步合并到外层 specs/ 目录，完成规范的持久化沉淀。

4.3 OpenSpec核心斜杠命令

4.4 自定义扩展技能

由于 OpenSpec 框架默认不包含测试覆盖和代码审查的标准化流程，笔者通过编写 Agent Skills 技能对其进行了工程化扩展，实现了自动化的测试、反馈和审查闭环：

5. 实践中的问题与改进方案

真正落地后才会发现，框架工具只解决了功能"有无"的问题，但功能质量却需要在工程实践中不断打磨。以下是实践过程中遇到的核心工程难题及对应的改进方案。

5.1 工程架构约束

问题 ：在落地过程中， AI 会重复犯错 - 相同类型的问题在不同会话、不同功能实现中反复出现，例如不符合框架规范的代码模式、错误的 API 设计、测试用例命名不规范等。

改进方案 ：由于笔者使用的是 Claude Code ，因此通过 CLAUDE.md 文件来实现工程约束。 CLAUDE.md 不仅是项目介绍文档，更是 工程约束文件 - 每次 AI 犯了某种典型错误后，就将该错误的正确约束规则补充到 CLAUDE.md 中，让后续所有会话都自动继承这份"经验积累"。

以下是项目 CLAUDE.md 中定义的主要规范类别： CLAUDE.md

通过 CLAUDE.md 将工程经验持续沉淀为机器可读的约束，能够让 AI 在每次开发中少犯错，整体上显著提升了人机协作的工程质量。

不同 AI 开发工具都有类似的约束配置机制，可根据所使用的工具选择对应的方式：

无论使用哪款 AI 开发工具，核心思路一致： 将项目开发过程中积累的规范和约束以机器可读的形式固化到约束配置文件中 ，让 AI 在每次开发中自动遵循这些规范，减少重复犯错。

5.2 强制测试验收要求

问题 ： OpenSpec 框架本身没有内置测试覆盖的强制要求，完全依赖 AI 或开发者的自觉性。在实践初期发现，许多功能实现后缺乏有效的回归保护，用户的每次验收都可能引入新的质量风险。

改进方案 ：通过编写 openspec-e2e 技能，在项目层面建立了严格的 E2E 测试规范： openspec-e2e

• 强制覆盖 ： tasks.md 中所有涉及用户可观察行为变更的任务，必须创建对应的 E2E 测试用例（ Playwright ）
• 命名规范 ：测试文件统一采用 TC{NNNN}-{brief-name}.ts 格式， TC ID 全局唯一且单调递增，不允许复用
• 目录组织 ：测试用例按功能模块分目录存放（如 auth/ 、 admin/ 、 notebook/ ），保持结构清晰
• 验收门控 ：每个任务的修复或新增实现完成后，必须运行相关 E2E 测试并确认通过，才允许标记任务为已完成

这一机制将回归测试从"可选"变成了"必须"，显著降低了迭代过程中出现质量回退的概率。

5.3 提升人机协作效能

问题 ： AI 完成的功能和生成的代码并非 100% 可靠。例如，业务需求背景描述不够全面、实施完成后的需求变更、细节调整等情况在业务迭代开发中极为普遍。虽然通过工程质量手段能解决一部分问题，但仍存在约 20%~40% 的不确定性，导致用户不得不投入大量精力进行验证和修复。

改进方案 ：设计并实现了 openspec-feedback 技能，构建自动化的反馈闭环： openspec-feedback

• 问题追踪 ：用户一旦发现问题，直接通过自然语言描述即可触发技能，技能自动将问题分类（ Bug 、功能缺失、交互改进、测试缺口）并记录到 tasks.md ，确保可追溯
• 规范联动 ：技能会评估反馈是否涉及"规范层"变更（即需求本身有变化），若是则先更新 Delta Specs 再记录任务，保证规范与代码的双向同步
• 影响评估 ：记录任务时自动分析影响范围和根本原因，对影响面回归执行端到端测试，避免"修了这里坏了那里"的情况
• 自动闭环 ：每个反馈任务修复完成后，自动触发 openspec-review 进行全面审查，形成"反馈→修复→审查→验证"的完整闭环

这一机制将原本碎片化的口头反馈转变为结构化的工程流程，极大地提升了人机协作的整体效能。

注意 ：技能（ Skill ）的自动触发并非百分之百可靠，依赖 AI 对当前上下文的识别和判断。在实际使用中，关键的交互场景下更推荐通过 斜杠指令显式触发 （如 /openspec-feedback ），以确保技能按预期执行，避免因触发时机不准确而导致反馈处理被遗漏。

5.4 代码审查与规范审查

问题 ：在 AI 协同开发过程中，代码质量和规范遵循的不一致性非常普遍。 AI 在不同会话、不同上下文下的输出风格可能存在差异，缺乏系统化的审查机制会导致代码库逐渐"腐化"。

改进方案 ：通过 openspec-review 技能实现了结构化的多维度代码审查，审查维度包括： openspec-review skill

• 后端代码审查 ：调用 goframe-v2 技能检查 GoFrame 框架惯用规范（软删除、时间自动维护、 DAO 使用等），同时对照 CLAUDE.md 检查业务代码规范
• 接口规范审查 ：检查 HTTP 方法与操作语义的对应关系，确保所有接口符合项目 REST 设计规范
• 架构规范审查 ：检查代码是否遵循 CLAUDE.md 中定义的架构设计原则，如模块解耦、服务层文件命名等
• E2E 测试审查 ：调用 openspec-e2e 技能检查测试用例文件是否符合命名规范和结构规范

审查结果分为 Critical （必须修复，阻断归档）和 Warning （建议修复，不阻断）两个级别，确保关键问题在归档前得到解决。

5.5 开发过程的上下文治理

问题 ：为了保证项目规范和质量，项目拥有一份完整的 CLAUDE.md 规范文档（约 17K 上下文），会在每个会话开始时自动注入。然而模型的上下文窗口是有限的（例如 GLM-5 只有 250K 上下文），随着会话轮次的增加，上下文会被压缩，导致模型"降智"，遗忘规范细节，输出质量下滑。

改进方案 ：

1. 小步迭代，拆分变更粒度 ：避免在单个 OpenSpec 变更中包含过多功能点。例如一个业务需求迭代 v1.1.0 包含 10 个功能点，应拆分为 10 个独立的小变更分别执行，而不是作为一个大变更一次性实现。每个变更的上下文信息保持精简，能够有效维持模型的智能水平。

2. 利用 SubAgent 机制隔离上下文 ： Claude Code 以及部分主流的 AI 开发工具支持 SubAgent 机制，每个 SubAgent 拥有独立的上下文窗口。对于执行周期较长的任务（例如 e2e 测试），可以显式地告诉 Claude Code 根据任务的耦合性自行开启 SubAgent 来完成，避免主会话上下文过载。

3. 适时开启新会话（ /new ） ：当一轮完整的变更任务执行完成后，使用 /new 开启新会话再进行下一轮任务，让每轮任务都在清洁的上下文窗口中执行，从根本上杜绝上下文堆积导致的降智问题。

5.6 迭代的熵治理

问题 ：随着项目迭代的不断推进， openspec/changes/ 目录下积累的变更越来越多，面临两个难题：

• 上下文污染 ：历史变更的产物（ proposal.md 、 design.md 、 specs/ ）被全部加载到上下文中，占用大量上下文窗口，引发降智
• 规范漂移 ：历史迭代的 Delta Specs 散落各地，主规范目录（ openspec/specs/ ）不能反映项目的最新全貌

改进方案 ： OpenSpec 的归档（ /opsx:archive ）机制从根本上解决了这一问题：

1. 增量规范合并 ：归档时， AI 分析当前变更的 Delta Specs ，将必要的增量规范合并同步到外层 openspec/specs/ 目录，完成规范的持久化积累
2. 变更归档隔离 ：合并后，当前变更目录整体移入 openspec/changes/archive/YYYY-MM-DD-<name>/ ，不再参与日常开发的上下文加载
3. 按需追溯 ：归档后的历史变更仅作为后续必要时的参考，不影响当前工作的上下文质量

通过"小粒度变更+及时归档"的组合策略，项目始终保持一个"精简活跃变更+完整主规范"的健康状态，有效控制了迭代过程中的上下文熵增。

5.7 其他实践总结

除以上几个核心问题外，以下几点经验也值得参考：

• 需求描述质量决定输出质量 ：在 /opsx:explore 阶段投入足够多的时间来澄清和细化需求，是整个 SDD 流程质量的关键。模糊的需求描述几乎必然导致实现偏差，与其在后期反复修复，不如在探索阶段多花时间打磨需求共识。由于需求澄清并不会创建持久化存储的文件，因此在这一阶段尽可能使用上下文足够大的模型（如 Claude Opus 4.6 1M 模型），以及使用思考深度更好的策略（如 Effort: Max ）。

• Git 提交粒度与变更粒度对齐 ：建议每完成一个 OpenSpec 变更或重要任务节点就进行一次 Git 提交，而不是等到所有任务全部完成才提交。这样既保留了原子化的更改历史，也让代码审查和问题追溯更加便捷。

• 技能是对框架的"补丁"而非替代 ： Claude Code 技能（ Skill ）最适合做的事不是重建一套完整的工作流，而是针对框架的某个薄弱环节提供精准补充。 openspec-review 、 openspec-feedback 、 openspec-e2e 这三个技能的本质是为 OpenSpec "打补丁"，弥补其在测试和审查层面的缺失，而不是重造一套 Spec-kit 。

• 合理设定 AI 的权限边界 ：在实际使用 Claude Code 时，明确告知 AI 哪些目录或文件是"禁止修改"的（如自动生成的 DAO/Entity 文件），往往能避免很多意外的修改问题。这些约束在 CLAUDE.md 中明确定义，是架构约束的重要组成部分。

6. 常见问题

6.1 各类文档该使用中文还是英文？

这三类文档（ OpenSpec 生成的规范产物、 CLAUDE.md 、自定义 Skill ）的语言选择并不相同，核心差异在于 受众是人还是 AI ：

6.1.1 OpenSpec 生成的规范产物（如 proposal.md 、 design.md 、 tasks.md ）

推荐使用中文（如果团队语言是中文）。这类文档的主要受众是团队成员，中文可大幅降低阅读和维护成本，整体收益高于大模型对英文的些微语义优势。通过在 openspec/config.yaml 的 context 字段中声明 Output language: All artifact content must be written in Simplified Chinese ，即可确保所有 AI 生成的规范文档统一使用简体中文输出，无需在每次提示词中重复说明。

6.1.2 CLAUDE.md 规范文档内容

推荐使用中文（如果团队语言是中文）。 CLAUDE.md 的核心受众同样是项目团队成员，母语编写的规范约束可读性更高、维护更自然，这一协作效率上的收益足以弥补语义理解上的细微差异。

6.1.3 自定义 Skill （ SKILL.md ）内容

推荐使用英文。 Skill 文件的核心受众是 AI ，而非人类团队成员——由于主流大模型的训练语料以英文为主，英文编写的技能指令能获得更高的语义理解精准度和遵循一致性，同时也更易于在社区中共享和复用。技能中涉及的具体业务约束可通过引用 CLAUDE.md 来实现，无需在技能文件中重复定义业务上下文。

6.2 CLAUDE.md是否需要完整地手动编写？

不需要从零手写。推荐以下渐进式方式建立 CLAUDE.md ：

1. 基础骨架 ：让 AI 根据项目技术栈自动生成初版 CLAUDE.md ，包含基本的目录结构说明、常用命令、技术栈描述等
2. 错误驱动补充 ：每当 AI 在开发过程中犯了某种重复性错误，立即将正确约束追加到 CLAUDE.md 对应章节中
3. 评审驱动完善 ：每次 openspec-review 发现某类规范违规时，评估是否需要将其固化为 CLAUDE.md 的约束条目

通过这种"边用边补"的方式， CLAUDE.md 会随着项目迭代自然成长为一份完整的工程约束手册，而不是一次性的繁重文档任务。

6.3 AI生成的变更产物质量不理想怎么办？

常见原因及对应处理方式：

• /opsx:explore 阶段不充分 ：如果探索式对话不够深入就急于 propose ，生成的 proposal.md 和 tasks.md 往往过于粗糙。解决办法是在探索阶段多追问细节，确保需求边界、技术方案和风险点都已充分讨论。
• config.yaml 缺少项目上下文 ： context 字段为空时， AI 生成的文档缺乏项目特定约束，容易产生与实际技术栈不符的内容。建议在 context 中明确说明使用的框架、语言、架构约定等关键信息。
• 上下文窗口已过载 ：若当前会话轮次较多，模型理解可能已出现偏差。此时应使用 /new 开启新会话后重新执行。

6.4 同一项目可以存在多个活跃变更吗？

可以，但 不推荐同时保持过多活跃变更 。多个活跃变更会导致 openspec-feedback 技能在判断反馈归属时产生歧义，也会增加主规范目录与 Delta Specs 之间的冲突风险。建议遵循"单线推进"原则：完成一个变更并归档后，再开启下一个，保持变更目录的简洁性。

6.5 AI生成的代码是否需要人工Review？

需要 ，尤其是在项目早期阶段。

6.5.1 早期迭代（建议前10个迭代）：保持较高的Review强度

项目初期是规范沉淀的关键窗口期，建议对 AI 生成的每一份代码变更保持较严格的人工 Review 。其目的不只是发现当次的问题，更重要的是：

• 识别 AI 的高频错误模式 ：找出 AI 在该项目中反复犯错的地方（如特定框架用法、命名约定、错误处理方式等）
• 将规范约束固化 ：将发现的问题转化为 CLAUDE.md 中的约束条目或自定义 Skill ，形成可复用的工程规范
• 建立质量基线 ：通过充分的 Review 为项目建立可参照的代码质量标准，为后续降低 Review 频率打好基础

6.5.2 中期迭代：引入工具辅助，减少人工干预

随着规范逐步完善，可通过工具手段提升 Review 效率、降低人工成本：

• 自动化规范检查 ：基于 openspec-review 等 Skill 工具，让 AI 在提交前自动对照既定规范进行自查，主动识别违规点
• 完善E2E测试覆盖 ：通过 openspec-e2e 等工具持续补充端到端测试用例，将用户可观察行为的验收自动化，形成有效的质量兜底机制

6.5.3 长期迭代：降低频率，但保留关键节点的Review

随着项目的深入迭代， AI 生成代码的质量会因规范约束的不断完善而逐步提升，人工 Review 的频率可以适当降低。但仍建议在以下场景保持必要的审查力度：

• 关键功能与复杂逻辑 ：对于涉及核心业务、安全鉴权、数据一致性等高风险模块，不应完全依赖 AI 自查
• 新引入的技术方案或架构变更 ：此类变更超出既有规范覆盖范围，需人工判断是否符合长期演进目标
• 发现质量退化信号时 ：若某个阶段测试失败率上升或反馈问题集中，应及时恢复较高强度的人工 Review

总体原则是： 前期投入规范建设是为了后期解放双手，但"解放"不等于"放弃" 。持续的审查意识是防止技术债务积累的最后一道防线。

6.6 没有前端功能的变更是否也需要E2E测试？

对于纯后端变更（如新增 API 接口、数据库迁移、定时任务等），可以豁免 E2E 测试要求，但建议补充 API 层面的集成测试或单元测试作为替代。 E2E 测试的核心价值在于覆盖"用户可观察行为"，没有 UI 变化的纯后端变更并不在其适用范围内。

7. 总结

OpenSpec 作为一个轻量级的 AI 工程规范管理框架，其最大的价值在于 简单、易学、易扩展 。它不试图覆盖所有场景，而是提供一套最小可行的规范工作流，让开发者能够快速上手，并根据项目的实际需要灵活地通过自定义技能进行扩展和定制化，最终构建出一套真正适合自己团队的 SDD 工程实践体系。

通过 OpenSpec 工程落地实践，开发者能够更深入地理解和掌握 SDD 规范驱动开发的核心思想： 规范先于代码，共识先于实现 。当每一次功能迭代都经过"探索→提案→实现→归档"的完整闭环，当每一次代码变更都有对应的规范文档为其背书， AI 协同开发便从"随兴编码"升级为具备可预测性和可追溯性的系统工程。

当然， SDD 的落地并非一帆风顺。测试覆盖不足、代码审查缺失、人机协作摩擦、上下文窗口溢出、迭代规范熵增……这些挑战在实践初期都真实存在。但这些问题并没有想象中难以解决 - 通过合理的工具设计（如 openspec-e2e 、 openspec-feedback 、 openspec-review 技能）、科学的上下文治理策略（小粒度变更、 SubAgent 隔离、及时归档）以及持续积累的工程约束（ CLAUDE.md ），每一个问题都能得到有效控制。

更重要的是，这套方法论本身也在持续迭代。每次踩坑、每次反思、每次改进，都会沉淀为更完善的规范约束和更成熟的技能工具。 SDD 工程实践的终点不是"找到一套完美的流程"，而是建立一套能够持续自我完善的工程文化。