前言

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

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

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

SDD工具横向对比

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

对比概览

工具	定位	优点	缺点
OpenSpec	轻量级规范管理框架	极简上手、目录结构直观；支持20+主流AI工具开箱即用；易于针对项目特性进行定制扩展；心智负担低，适合中小团队快速落地	功能相对简单，高级工程能力（测试覆盖、代码审查）需要自行通过技能扩展实现
Spec-kit	全流程规范工程工具包	功能完整丰富，覆盖从需求到实现的完整链路；CLI工具自动化程度高；constitution.md宪法机制确保技术一致性；广泛兼容主流AI工具	框架较重，目录结构和命令集学习成本高；全程需要人工通过既定指令精确驱动流程，心智负担高；对于频繁迭代的小功能显得臃肿
Superpowers	AI智能体工程化技能库	自动化程度极高，SubAgent并行执行加速开发；技能可自由组合，覆盖TDD、代码审查、调试等完整工程能力；集成度强	框架过于复杂，上手门槛高；部分核心能力（如上下文注入）依赖AI工具的特定特性支持，并非所有AI开发工具都兼容

工具选型

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

1. 学习成本低：OpenSpec的核心概念只有四个（specs、changes、delta specs、artifacts），五分钟内即可理解并开始使用；
2. 易于定制扩展：OpenSpec的设计遵循"流动而非刚性"原则，可以根据项目需求灵活添加自定义技能，弥补其功能简单的短板；
3. 工具兼容性广：与几乎所有主流AI开发工具（Claude Code、Cursor、GitHub Copilot等）兼容，不受特定平台约束；
4. 满足大部分需求：对于中小规模的AI协同开发项目，OpenSpec的核心工作流——探索、提案、实现、归档——已能满足绝大部分场景需求，额外的测试和审查能力通过自定义技能补全。

开发工具配置：Claude Code

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

已安装插件

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

插件名称	用途描述
code-review	代码审查插件，识别代码潜在问题并给出改进建议
code-simplifier	代码简化插件，识别过度复杂的实现并提供更简洁的替代方案
context7	实时上下文增强插件，能够从外部文档（如官方库文档）动态注入最新API上下文，显著提升AI对第三方库的理解准确性
frontend-design	前端设计辅助插件，帮助生成符合设计规范的前端UI代码
github	GitHub集成插件，支持在会话中直接获取Issue、PR、代码仓库信息
gopls-lsp	Go语言服务器插件，提供Go代码的类型检查、诊断分析和符号解析能力
playwright	Playwright测试集成插件，支持E2E测试用例的自动化生成与运行
ralph-loop	反馈循环插件，通过持续迭代帮助改进代码质量和实现方案
skill-creator	技能创建与优化插件，用于创建新的Claude Code技能或改进现有技能

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

已安装技能（Skill）

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

技能名称	用途描述
find-skills	元技能，帮助用户发现和安装适用于当前任务的Claude Code技能，自动扩展能力边界
goframe-v2	GoFrame v2框架规范技能，为Go后端开发提供框架最佳实践指导，确保代码符合GoFrame惯用模式

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

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.

配置项	说明
schema	使用的工作流模式，spec-driven为规范驱动模式（默认推荐）
context	全局上下文注入，所有产物生成时均会带入此内容；适合声明语言要求、技术栈信息等
rules	针对特定产物（如tasks）追加的约束规则，不影响其他产物

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

OpenSpec工程实践流程

流程全景图

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

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

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

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

工程实践流程概述

第一步：探索式对话（/opsx:explore）

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

第二步：生成正式变更提案（/opsx:propose）

当探索对话收敛、形成清晰的解决方案后，通过/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         # 实现任务清单（带勾选框）

第三步：按任务清单逐条实现（/opsx:apply）

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

第四步：处理用户反馈（/openspec-feedback扩展技能）

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

第五步：归档变更（/opsx:archive）

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

OpenSpec核心斜杠命令

命令	触发时机	核心行为
/opsx:explore	需求分析与方案设计阶段	进入探索模式，充当思维伙伴，通过对话分析问题、比较方案、评估风险；禁止产生任何代码
/opsx:propose	方案收敛后	创建变更目录，依序生成proposal.md、design.md、specs/、tasks.md等所有变更产物
/opsx:apply	开始代码实现	读取tasks.md，逐条执行任务，每任务完成后自动触发openspec-review审查；前端任务附带E2E测试
/opsx:archive	迭代验收通过后	执行归档前审查，将Delta Specs同步到主规范目录，将变更目录移入archive/存档

自定义扩展技能

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

技能名称	自动触发时机	核心职责
openspec-review	/opsx:apply每任务完成后、/openspec-feedback每任务完成后、/opsx:archive归档前	对修改的代码进行结构化审查，包括后端代码规范审查、RESTful API合规检查、架构设计规范审查和E2E测试规范审查；发现关键问题时阻断归档流程
openspec-feedback	用户报告Bug或提出改进点时	解析并分类用户反馈，将问题记录至tasks.md，评估规范影响范围并更新Delta Specs，完成修复和验证后自动触发openspec-review
openspec-e2e	编写或审查E2E测试用例时	定义项目E2E测试用例的目录结构、文件命名（TC{NNNN}格式）、TC ID分配规则和测试文件模板，确保测试用例规范一致

实践中的问题与改进方案

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

工程架构约束

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

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

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

规范类别	核心约束示例
开发流程规范	使用SDD驱动开发，必须经过explore→propose→apply→archive完整流程；用户报告问题时必须调用openspec-feedback技能
架构设计规范	模块必须支持按需启用/禁用；禁用模块后前端UI元素必须完全隐藏而非置灰；后端服务间通过接口而非硬依赖实现模块解耦
接口设计规范	查询操作禁止使用POST；删除操作必须使用DELETE；URL中使用名词复数，禁止动词（如/getUser）
后端代码规范	禁止手动设置created_at/updated_at（由框架自动维护）；禁止手动添加WhereNull(deleted_at)条件；DAO/Entity文件由gf gen dao自动生成，禁止手动修改
SQL文件管理	每次迭代新建SQL文件而非修改旧文件；Mock数据放mock-data/目录而非业务迭代SQL
前端代码规范	表格页面必须使用useVbenVxeGrid+Page组件；图标使用IconifyIcon组件；实现前先参考前端框架的对应页面
E2E测试规范	测试文件命名TC{NNNN}*.ts；涉及用户可观察行为变化时必须编写或更新测试；修复完成后必须运行并确认通过才能标记任务完成

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

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

AI开发工具	工程约束配置文件	说明
Claude Code	CLAUDE.md	放置于项目根目录，每次会话自动注入
Cursor	.cursorrules 或 .cursor/rules/*.mdc	支持全局规则和目录级规则两种粒度
GitHub Copilot	.github/copilot-instructions.md	在仓库级别为Copilot提供上下文和约束
Windsurf	.windsurfrules	放置于项目根目录，作用与CLAUDE.md类似
OpenCode	AGENTS.md	兼容CLAUDE.md，同时支持AGENTS.md作为约束文件

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

强制测试验收要求

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

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

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

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

提升人机协作效能

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

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

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

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

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

代码审查与规范审查

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

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

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

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

开发过程的上下文治理

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

改进方案：

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

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

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

迭代的熵治理

问题：随着项目迭代的不断推进，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. 按需追溯：归档后的历史变更仅作为后续必要时的参考，不影响当前工作的上下文质量

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

其他实践总结

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

• 需求描述质量决定输出质量：在/opsx:explore阶段投入足够多的时间来澄清和细化需求，是整个SDD流程质量的关键。模糊的需求描述几乎必然导致实现偏差，与其在后期反复修复，不如在探索阶段多花时间打磨需求共识。

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

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

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

常见问题

OpenSpec生成的文档应该使用中文还是英文？

推荐使用中文。对于中文团队而言，proposal.md、design.md、tasks.md等变更产物使用中文能大幅降低阅读和维护成本。通过在openspec/config.yaml的context字段中声明Output language: All artifact content must be written in Simplified Chinese，即可确保所有AI生成的规范文档统一使用简体中文输出，无需在每次提示词中重复说明。

CLAUDE.md中的内容应该使用中文还是英文？

推荐使用中文（如果团队语言是中文）。CLAUDE.md的核心受众是项目团队成员，使用母语编写的规范约束可读性更高，维护起来也更自然。实测表明，Claude Code对中文CLAUDE.md的理解和遵循效果与英文版本相当，不存在明显的语言理解差异。

自己编写的Skill应该使用中文还是英文？

推荐使用英文。Claude Code的Skill（技能描述文件SKILL.md）建议使用英文编写，主要原因有两点：其一，Claude Code对英文指令的理解精准度和遵循一致性更有保障；其二，英文技能文件更易于在社区共享和复用。技能中涉及的具体业务约束可以通过引用CLAUDE.md来实现，无需在技能文件中重复定义业务上下文。

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

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

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

欢迎在评论区分享你在SDD落地实践中的经验与挑战。