5.1 用 Constitution 驯化 AI

constitution.md 是整个项目的灵魂文件，它定义技术信条、架构约束、代码风格、测试标准等非协商行为准则。

撰写建议：

• 明确团队的“永远不变”规则，例如：
• 设置约束项，如必须使用特定框架（Next.js 等）。
• 定义你的质量门槛（最低测试覆盖率、性能基准）。

实践技巧：

• Constitution 文件放在 memory/constitution.md；
• 每次 /speckit.plan 运行时将被 AI 引用作为上下文Constitution；
• 运行 /speckit.clarify 验证规范完整性。

5.2 尽量不要跳过 /speckit.clarify

虽然 /speckit.clarify 命令是可选的，但使用它是最佳实践。这个命令会根据/specify 的需求，自动生成一系列针对性的问题，涵盖可能不清楚或需要更多细节的区域。在/speckit.plan之前运行clarify可以减少下游的返工，避免欠规范（under-specification）的问题。答案被记录在规范的"Clarifications"部分中，确保所有相关人员都达成验收共识。

针对模糊的需求， Clarify 自动生成问题，例如：

• “该应用如何在浏览器会话间保存目标数据？（A 本地存储 B 云端数据库 C 文件导入导出等）”
• “目标完成时间已过如何处理？（A 标记为逾期 B 移动到已完成栏 C 弹窗警告 D 删除等）”
• “用户提交表单若有空字段，应怎样反馈？”
• “右侧栏的已完成目标应按什么顺序展示？”
• “对于很久之后才截止的目标，剩余天数显示格式如何选择？”

开发者逐条答复：

• 例如，/specify “实现一个购物车“。 这是一个含糊的问题，通过/clarfy 后则生成如下的澄清：

Clarify 阶段完成后：

• 规范文档中 "Clarifications" 部分新增这些澄清解释。
• 每个复杂或含糊需求都被问到并确认，系统实现时不会再有理解偏差或漏洞。

5.3 用 /checklist，提前发现问题

通过/checklist ，生成针对需求的检查点列表，这样可以在大模型生成代码前，就尽可能发现需求描述中的模糊、遗漏或歧义点，减少后续返工。

通常位于 Speckit 工作流的第 2～3 步之间，即在 /speckit.clarify（澄清）之前或之后执行都可以，用于验证该功能的“可交付准备状态”。

⚠️注意：若是探索性原型（spike）或临时方案，可以选择跳过，但应明确记录原因。

实践技巧：

• 迭代执行 2～3 次：每当Spec/Requirement更新后， 建议重新运行 checklist 以确认所有修改仍符合标准。
• 关注失败项目的严重性标签： “Critical” 表示必须修正； “High” 表示清晰度或一致性问题； “Medium / Low” 表示用词或表达可优化。
• 整合报告输出：

使用 AI 生成报告，列出规格路径、通过率、未完成项及下一步建议，可作为评审会议材料。

5.4 新业务开发模式的推荐指令工作流

5.5 小缺陷开发模式的推荐的 SpecKit 指令工作流

这种“跳过 specify，直接执行 plan → tasks → implement”的“小规格修复流”是当前 speckit 官方社区推荐的轻量模式，被称为 Fast Path Workflow，它能够让 bug 修复周期缩短 40–60%，同时保持原有规范的完整。

5.6 不复杂需求的节省 Token 和平衡性能的指令工作流

对于小规格需求和缺陷，重新生成完整 spec.md 的投入成本很高，因为specify 阶段要生成详细的规范说明（功能意图 + 使用场景 + 约束条件），会占用大量上下文和令牌，而这些内容对单个 bug 修复几乎没有复用价值，也容易使 AI 生成冗余、非重点信息。

因此，直接从 /specify → 通过 CodeBuddy Code  的 Plan 模式及 内置的 Task 能力  → /implement 可显著提高反馈速度。