AI编程结构化工作流：从临时问答到可复用的工程实践

weixin_30847939

439人浏览 · 2026-05-01 15:45:55

weixin_30847939 · 2026-05-01 15:45:55 发布

1. 项目概述：一套为AI编程时代设计的结构化工作流命令

如果你和我一样，每天都在Cursor、Claude Code这类AI驱动的IDE里写代码，那你肯定经历过这种场景：脑子里蹦出一个新功能的想法，兴冲冲地打开AI聊天框，敲下一句“帮我实现一个用户登录功能”，然后看着AI生成的一堆代码，心里却开始打鼓——“这真的覆盖所有边界情况了吗？”“安全漏洞检查了吗？”“设计决策有没有记录下来，万一以后要改怎么办？” 更常见的是，几天后当你想回顾为什么某个API要这么设计时，却发现当时的思考过程早已淹没在聊天历史里，无处可寻。

这就是 cursor-workflow-commands 这个项目要解决的核心痛点。它不是什么复杂的框架或库，而是一套精心设计的、开箱即用的 提示词命令模板 。你可以把它理解为一套为AI编程助手定制的“标准操作程序”。它把从问题捕获、需求探索、方案设计、代码实现、质量审查到事后复盘的全生命周期，拆解成一个个可执行的、结构化的命令。当你输入 /capture_issue 时，AI会引导你系统地描述问题；输入 /create_plan 时，它会帮你把模糊的需求拆解成原子化的实现步骤。这套工作流特别适合 独立开发者、小团队技术负责人 ，或者任何希望将AI辅助编程从“随机问答”提升到“可预测、可复盘工程实践”的人。

我花了几个月时间在实际项目中打磨这套命令，发现它带来的最大改变是 思维的纪律性 。AI不再是一个即问即答的“代码生成器”，而是一个能和你一起遵循工程方法、保留决策上下文、并持续从经验中学习的协作伙伴。接下来，我会带你深入这套工作流的每一个环节，分享我是如何配置、定制并使用它来真正提升开发质量和效率的。

2. 核心设计哲学：为什么“结构化提示”是AI编程的胜负手

在深入具体命令之前，我们必须先理解其背后的设计哲学。很多开发者对AI编程的初体验是兴奋的，但随之而来的是挫败感——生成的代码看似能用，但缺乏架构考量，难以维护，且每次交互都是孤立的“会话”，没有累积的智慧。 cursor-workflow-commands 的出发点，正是为了解决这些深层次问题。

2.1 从临时问答到可复用流程

传统的AI编程是高度线性的：你提问，它回答。这种模式对于 “这个函数语法是什么” 这类简单查询有效，但对于 “为我们的电商平台设计一个优惠券系统” 这样的复杂任务，它立刻暴露出短板。需求会在对话中丢失，设计权衡不会被记录，生成的代码也缺乏一致性检查。

这套工作流命令的核心转变在于，它将开发视为一个 有状态、多阶段的过程 。每个命令（如 /explore , /design_decisions ）不仅完成当前任务，还会将其输出持久化到项目根目录下的 .ai/context/ 文件夹中。这意味着，当你在后续阶段执行 /execute_plan 或进行 /code_review 时，AI能够读取之前所有阶段的决策记录，确保上下文不丢失。这种设计模拟了人类开发者撰写设计文档、记录TODO、保存会议纪要的行为，只不过现在是AI和你一起在维护这份“项目记忆”。

2.2 平衡自由与规范：提供护栏，而非枷锁

一个常见的担忧是：这么多步骤，会不会让开发变得僵化、官僚化？这正是设计者深思熟虑的地方。这套工作流被明确分为 “标准步骤” 和 “可选步骤” 。

例如，对于任何一个新功能， /capture_issue （问题捕获）、 /explore （需求探索）、 /create_plan （创建计划）、 /design_decisions （设计决策）和 /pre_implementation_checklist （实施前检查）被标记为“标准步骤”。它们构成了一个可靠的最小闭环，确保你不会在没想清楚之前就仓促动手。而对于一个简单的Bug修复，你可能只需要 /capture_issue 和 /execute_plan 。

另一方面， /security_scan （专项安全扫描）、 /peer_review （人工同行评审）和 /project_wrap_up （项目收尾与交接）则是“可选步骤”。它们适用于高风险模块、团队协作场景或需要完整交接的项目。 这种设计给了你选择的权力 ：你可以根据任务的复杂度、风险等级和协作需求，灵活组合这些命令，而不是被强制套用一套冗长的流程。

2.3 将AI定位为“执行伙伴”而非“魔法黑盒”

这套工作流重新定义了开发者与AI的关系。开发者不再是不断提出微观问题的“提问者”，而是 流程的驱动者和关键决策的制定者 。AI则成为负责执行具体步骤、维护上下文、并提醒你检查清单的“执行伙伴”。

举个例子，在 /design_decisions 阶段，AI会引导你思考并记录：“这个服务将采用什么设计模式？（如工厂模式、策略模式）”、“API的输入输出数据结构是什么？”、“它与现有哪些模块存在集成点？”。它不会替你做出这些决策，但会确保这些决策被明确地提出、讨论并记录下来。随后，在 /execute_plan 阶段，AI生成的代码就会严格遵循这些已记录的设计决策，保证了代码与设计意图的一致性。

这种分工将开发者的智慧集中在 架构、设计和业务逻辑 等高价值判断上，而将 代码生成、格式检查、基础测试用例编写 等重复性工作交给AI，实现了人机协作的效率最大化。

3. 环境配置与多IDE适配实战

理论再好，也得落地。 cursor-workflow-commands 的另一个强大之处在于它对主流AI IDE的广泛支持。下面我将以最常用的Cursor和VS Code为例，详细讲解安装、配置过程中的细节和避坑指南。

3.1 Cursor IDE：原生支持与最佳实践

Cursor是这套工作流的“首发”和最佳运行环境，因为它原生支持项目级或全局的 /.cursor/commands/ 目录。

项目级安装（推荐） 我强烈建议进行项目级安装。这样，工作流命令和生成的上下文（ .ai/context/ ）都保存在项目内，便于版本管理（当然，上下文目录通常需要加入 .gitignore ），也保证了项目环境的一致性。

# 在你的项目根目录下执行
git clone https://github.com/Leftyshields/cursor-workflow-commands.git
cp -r cursor-workflow-commands/commands/ ./.cursor/commands/
mkdir -p ./.ai/context/

操作完成后，你的项目结构会是这样：

my-awesome-project/
├── .cursor/
│   └── commands/          # 所有工作流命令文件
│       ├── capture_issue.md
│       ├── explore.md
│       └── ...
├── .ai/
│   └── context/          # 所有命令生成的上下文文件都存这里
├── src/
└── package.json

一个关键技巧 ：确保你的 .cursor 目录没有被 .gitignore 全局忽略。有些默认的Git忽略模板会包含 .cursor* ，你需要检查并调整你的项目 .gitignore 文件，至少保留 .cursor/commands/ 目录以便团队共享配置。

安装成功后，在Cursor的聊天面板中直接输入 / ，你就会看到所有可用的命令列表，如 /capture_issue 、 /explore 等，体验非常流畅。

3.2 VS Code + Continue 扩展：功能最强大的替代方案

如果你主要使用VS Code，那么搭配 Continue 扩展是目前实现类似体验的最佳选择。Continue不仅支持自定义slash命令，其强大的上下文管理能力（能读取整个工作区、终端输出、浏览器信息）与这套工作流理念完美契合。

配置步骤：

在VS Code中安装Continue扩展。
打开Continue的配置文件。通常位于 ~/.continue/config.json （全局）或你的项目目录下的 .continue/config.json 。
将工作流命令添加为自定义的 slashCommands 。这里不建议直接粘贴整个提示词内容，而是采用 文件引用 的方式，这样更易于维护。

{
  "slashCommands": [
    {
      "name": "capture_issue",
      "description": "开始一个新功能或Bug修复：捕获问题与需求",
      "prompt": "{{readFile:./.continue/commands/capture_issue.md}}"
    },
    {
      "name": "code_review",
      "description": "对当前变更进行自动化代码审查",
      "prompt": "{{readFile:./.continue/commands/code_review.md}}"
    }
    // ... 添加其他命令
  ]
}

将下载的 commands/ 文件夹复制到你的Continue配置目录下。

cp -r cursor-workflow-commands/commands/ ~/.continue/commands/
# 或者项目级：cp -r cursor-workflow-commands/commands/ ./.continue/commands/

同样，在项目根目录创建 .ai/context/ 文件夹用于持久化上下文。

一个真实踩坑经验 ：早期我尝试在VS Code Copilot Chat中使用这些命令，发现体验很割裂。Copilot Chat对项目级文件系统的读取权限和上下文管理较弱，很难实现跨会话的状态持久化。而Continue通过其配置文件和对工作区的深度集成，完美解决了这个问题。现在，我在VS Code里也能获得几乎和Cursor一样的结构化开发体验。

3.3 上下文持久化目录：工作流的“记忆中枢”

无论你使用哪种IDE， .ai/context/ 目录都是这套工作流的灵魂。它是一个 跨IDE共享 的上下文仓库。这意味着，即使你今天用Cursor写代码，明天换到配置了Continue的VS Code，只要项目目录相同，AI都能读取到昨天记录的设计决策和执行计划。

它的工作原理很简单：每个命令在执行时，都会将其关键输出（如探索报告、实施计划、设计决策文档）以Markdown格式写入这个目录。后续命令会首先读取这些文件来建立上下文。

重要注意事项 ：

版本控制 ：这个目录下的文件是动态生成的，且可能包含临时性、过程性的内容。 务必将其加入 .gitignore ： echo ".ai/context/" >> .gitignore 。你应该将 /.cursor/commands/ 或 /.continue/commands/ 下的命令模板文件纳入版本控制，但不要提交上下文文件。
清理策略 ：这个目录可能会随着时间积累大量文件。建议定期手动清理，或建立一个简单的清理脚本（如保留最近7天的文件）。切勿在开发会话中途删除正在被引用的文件。

4. 四阶段工作流深度解析与实战案例

现在，让我们进入最核心的部分，以一个真实的“为用户资料页添加社交媒体账号绑定功能”为例，走一遍完整的四阶段工作流。我会在每个阶段分享具体的操作、AI的交互反应以及我总结的实操心得。

4.1 第一阶段：规划与设计——谋定而后动

步骤1：使用 /capture_issue 捕获问题 我输入 /capture_issue ，AI会弹出一个结构化的提示，引导我填写：

问题标题 ：用户无法在资料页绑定第三方社交媒体账号。
当前行为 ：资料页仅有基础信息字段，无社交媒体入口。
期望行为 ：用户可连接GitHub、Twitter、LinkedIn账号，并在资料页显示图标和链接。
优先级与影响 ：P2（中优先级），提升用户个人品牌展示与社区连接。
非目标 ：不实现OAuth授权流程（使用现有认证服务），不在此阶段支持账号解绑后的数据清理。

AI会生成一个唯一的 ISSUE_ID （如 PROJ-42 ），并自动将这份摘要保存到 .ai/context/last_capture.md 。心得：强迫自己用结构化语言描述问题，能立刻澄清模糊的需求，这个习惯价值连城。

步骤2：使用 /explore 深入探索 接着，我运行 /explore 。AI会基于刚才捕获的问题，引导我进行深度思考，并将输出保存为 last_explore.md 。这个过程通常涉及：

技术栈确认 ：前端是React + TypeScript，后端是Node.js + Prisma，数据库是PostgreSQL。
外部依赖 ：需要调用公司统一的OAuth代理服务获取 access_token 。
数据结构设计 ：需要在 User 表中新增一个 social_links JSON字段，还是新建一个 SocialLink 关联表？AI会列出优劣。
风险识别 ：第三方API的速率限制、Token过期处理、用户输入XSS防护。
开放性问题 ：是否允许用户自定义显示顺序？图标是本地存储还是从CDN获取？

这个阶段的关键是 不写一行代码 ，只做研究和决策。AI在此扮演了一个经验丰富的技术顾问，帮你把能想到的角落都照亮。

步骤3：使用 /create_plan 创建实施计划 探索完成后， /create_plan 命令会读取探索阶段的输出，并将其转化为一份原子化的任务清单。生成 execution_plan.md 文件可能包含：

数据库迁移 ：创建 SocialLink 模型（id, userId, platform, username, url, createdAt）。
后端API ：
- 创建 GET /api/users/me/social-links 端点。
- 创建 POST /api/users/me/social-links 用于添加/更新。
- 创建 DELETE /api/users/me/social-links/:platform 。
- 集成OAuth服务，验证 access_token 并获取用户第三方平台用户名。
前端组件 ：
- 创建 SocialLinksEditor 组件（用于编辑）。
- 创建 SocialLinksDisplay 组件（用于展示）。
- 在用户资料页集成上述组件。
测试：为每个API端点编写集成测试，为组件编写单元测试。

这份计划不是命令，而是可讨论的蓝图。我通常会手动调整任务的顺序或拆分更细的步骤。

步骤4：使用 /design_decisions 固化设计 在动手前，最后用 /design_decisions 将关键决策固化下来，生成 design_decisions.md 。例如：

数据模型 ：采用独立的 SocialLink 表，便于查询和未来扩展。
API设计 ：RESTful风格，使用PATCH进行部分更新。
状态管理 ：前端使用React Query缓存社交链接数据。
安全：所有用户输入（如username）在存入数据库和渲染前都必须经过清理。
错误处理 ：定义统一的错误响应格式，并记录OAuth服务调用失败。

这份文档是后续开发和审查的 唯一真相来源 ，极大减少了沟通和理解偏差。

步骤5：使用 /pre_implementation_checklist 最终检查 这是一个简单的检查点，AI会问我：“计划是否已评审？设计决策是否已记录？所有开放问题是否已解决？”。确认无误后，才真正进入编码阶段。这个仪式感能有效防止“边做边想”导致的返工。

4.2 第二阶段：实施——让AI成为高效的执行者

核心命令： /execute_plan 这是编码的主力阶段。我输入 /execute_plan ，AI会首先读取 execution_plan.md 和 design_decisions.md ，然后开始按步骤工作。

它的工作方式非常智能： 它不是一次性生成所有代码 ，而是会和我进行迭代式对话。例如，对于“1. 数据库迁移”，AI可能会说：

“我将开始执行步骤1：创建Prisma数据模型。根据设计决策，我将创建 SocialLink 模型。这是初步的schema.prisma修改建议，请确认是否符合预期。”

在我确认后，它才会生成具体的Prisma schema代码。然后它会问：“步骤1已完成。是否继续执行步骤2（后端API）？” 我可以选择继续，也可以暂停，手动运行迁移命令 npx prisma migrate dev ，然后再继续。

可选命令： /tdd 测试驱动开发 当实现一个复杂的算法（比如验证社交媒体用户名格式的通用函数）时，我会切换到 /tdd 模式。AI会进入经典的“红-绿-重构”循环：

红：AI先为我编写一个失败的测试用例（例如，期望输入 @username 能解析出 username ）。
绿：我或AI编写最简单的实现让测试通过。
重构：在测试保护下，优化代码结构。

这个过程能产出高度可靠且设计良好的复杂逻辑代码。心得：对于业务CRUD代码，直接 /execute_plan 更高效；对于核心算法和工具函数， /tdd 能带来更高的代码质量。

4.3 第三阶段：质量保证——多维度审查网

代码写完了，但绝不能直接部署。质量保证阶段是守住底线的关键。

核心命令： /code_review 这是最常用的审查命令。AI会对当前更改（或指定文件）进行一次全面的自动化审查，通常包括：

安全性 ：检查是否有硬编码的秘密、可能的SQL注入、XSS漏洞。
正确性 ：逻辑是否完整，边界条件（空值、极值）是否处理。
架构一致性 ：是否遵循了之前记录的设计决策（如是否用了React Query？）。
代码质量 ：命名、函数长度、代码重复度。
性能：是否有潜在的非必要重渲染、低效的数据库查询（如N+1问题）。

AI会以列表形式给出发现的问题和建议。例如，它可能指出：“在 SocialLinksEditor.tsx 的第45行，直接使用了 userInput 插入HTML，存在XSS风险，建议使用 DOMPurify 清理或React的 dangerouslySetInnerHTML 。” 你需要逐一评估并决定是否采纳。

可选但重要的命令： /security_scan 如果功能涉及用户数据、身份验证或第三方集成，强烈建议运行此命令。它比通用的 /code_review 在安全上钻得更深：

依赖检查 ：检查 package.json 中是否有已知漏洞的依赖版本。
身份验证与授权 ：确保每个API端点都进行了正确的权限校验。
数据存储 ：敏感信息（如第三方平台的 access_token ）是否加密存储？
配置管理 ：API密钥等是否通过环境变量管理，而非写在代码里？

手动检查命令： /qa_checklist AI会生成一份面向功能验收的手动测试清单，例如：

[ ] 用户能成功通过OAuth流程添加GitHub账号。
[ ] 添加后，资料页正确显示GitHub图标和链接。
[ ] 尝试添加已存在的平台账号，会提示“已存在”并执行更新。
[ ] 输入超长的用户名，前端有截断或提示，后端有验证。
[ ] 网络异常时，前端有友好的错误提示。
[ ] 移除某个账号后，页面即时更新。

这份清单是交付给测试人员或自己进行冒烟测试的完美指南。

4.4 第四阶段：反思——让每一次开发都成为进步

项目上线不是终点。反思阶段是个人和团队成长的关键。

核心命令： /postmortem 运行此命令，AI会引导你回顾整个开发过程：

哪些环节最顺畅？ （例如， /execute_plan 按步骤生成代码非常高效。）
遇到了哪些摩擦或返工？ （例如，在实现OAuth回调时，发现设计决策里没明确错误处理流程，导致临时调整。）
根本原因是什么？ （需求探索阶段对错误场景考虑不足。）
如何改进流程或文档？ （在 /explore 模板中增加“错误处理策略”必填项。）

AI会总结一份“经验教训”文档，保存到上下文。下次开始新功能时，这些经验会自动成为你的知识库。

可选命令： /project_wrap_up 对于需要交接或归档的重要项目，这个命令非常有用。它会：

执行一次最终的 /security_scan 。
合成 .ai/context/ 下的所有文档，生成一份完整的项目报告。
创建一份简明的“接手文档”，包含项目简介、架构图、部署步骤和常见问题。
甚至可以生成一份给下一个维护者（可能是未来的你或其他AI）的“简报”。

5. 高级定制与个性化配置

这套工作流命令的魅力在于它并非铁板一块，而是完全可定制的Markdown文件。你可以根据自己团队的技术栈和开发习惯进行深度改造。

5.1 定制命令模板

每个命令都是一个 .md 文件。打开 commands/code_review.md ，你会发现它其实就是一段结构化的提示词。例如，你可以：

增加技术栈特定规则 ：在 /code_review 命令中，为你的React项目添加对 React Hooks 依赖数组完整性的检查规则。
修改检查清单 ：在 /qa_checklist 中，为你的移动端应用加入“深色模式适配”、“屏幕旋转测试”等条目。
调整措辞 ：让AI以更严厉或更温和的语气进行审查。

示例：为Node.js项目强化 /code_review 你可以编辑 code_review.md 文件，在“安全性”部分增加：

## 安全性 (Node.js 专项)
- **错误处理**：检查是否使用了 `try-catch` 包裹了所有异步操作，避免未处理异常导致进程崩溃。特别关注 `JSON.parse`、`fs` 操作和第三方API调用。
- **日志记录**：检查敏感信息（如密码、令牌、个人身份信息）是否被意外记录到日志中。确保使用了像 `pino` 这样的结构化日志库，并正确配置了日志级别。
- **依赖安全**：提醒运行 `npm audit` 或使用 `snyk` 检查依赖漏洞。

5.2 创建全新的自定义命令

工作流是开放的。假设你的团队在部署前有独特的“合规性检查”要求，你可以轻松创建 /compliance_check 命令。

在 commands/ 目录下复制一个现有命令文件作为模板，例如 cp code_review.md compliance_check.md 。
编辑 compliance_check.md ，写入你的专属提示词：

# 合规性检查清单

在部署至生产环境前，请确认以下合规要求：

## 数据隐私 (GDPR/CCPA)
- [ ] 所有收集用户数据的表单都有明确的隐私政策链接。
- [ ] 用户数据导出和删除功能已实现并测试。
- [ ] 没有在客户端代码或日志中暴露任何个人可识别信息(PII)。

## 可访问性 (WCAG)
- [ ] 所有图片都有 `alt` 文本。
- [ ] 表单控件都有关联的 `<label>`。
- [ ] 颜色对比度符合 WCAG AA 标准（可使用 axe 工具检查）。

## 内部审计要求
- [ ] 所有数据库变更都已记录在审计日志表中。
- [ ] 金融相关计算已通过双重验证。
- [ ] 变更已通知合规部门负责人（@合规团队邮箱）。

现在，你就可以在IDE中使用 /compliance_check 命令了。

5.3 集成外部工具与脚本

工作流还可以与你的开发工具链结合。例如，你可以在 /pre_implementation_checklist 的最后，让AI提醒你运行一个自定义的脚本：

## 最终确认
- [ ] 我已阅读并理解所有设计决策。
- [ ] 我已准备好开始编码。

**行动项**：请在开始前运行项目预检脚本：`./scripts/preflight-check.sh`。

或者，在 /postmortem 中，让AI建议你将本次的“经验教训”自动提交到团队的知识库Wiki中。

6. 常见问题与故障排查实录

在实际使用中，你可能会遇到一些问题。以下是我和社区成员遇到的一些典型情况及其解决方案。

6.1 命令不显示或无法触发

问题：在Cursor或VS Code Continue中输入 / ，看不到自定义的命令列表。

检查安装路径 ：确认命令文件是否放入了正确的目录。对于Cursor，是 .cursor/commands/ （项目级）或 ~/.cursor/commands/ （全局）。路径错误是最常见的原因。
检查文件格式 ：确保命令文件是 .md 格式，并且内容完整。有时文件下载不完整会导致命令失效。
重启IDE ：部分IDE需要重启后才能加载新的自定义命令。
检查IDE版本 ：确保你的AI IDE版本支持自定义slash命令功能。过于陈旧的版本可能不支持。

6.2 上下文（Context）不连贯或丢失

问题：执行 /execute_plan 时，AI似乎忘记了之前 /design_decisions 中记录的内容。

确认上下文目录 ：首先检查项目根目录下是否存在 .ai/context/ 文件夹，并且之前的命令（如 design_decisions.md ）是否成功写入。可能是文件权限问题导致写入失败。
检查命令模板 ：打开 execute_plan.md 文件，查看其提示词开头。它应该包含读取上下文文件的指令，例如“首先，请读取 .ai/context/design_decisions.md 文件以了解设计约束...”。如果这部分被误删，上下文就会断裂。
会话隔离 ：有些AI聊天会话是隔离的。确保你是在同一个“会话”或“线程”中连续使用这些命令。如果开启了新会话，可能需要手动将之前的上下文文件内容粘贴进来作为背景信息。

6.3 AI生成的代码质量不稳定

问题：有时 /execute_plan 生成的代码不符合预期，或 /code_review 提出的建议不准确。

提供更丰富的上下文 ：AI的表现严重依赖于上下文。确保在项目开始时，通过 /explore 命令提供了尽可能详细的技术栈、架构模式和业务规则。你也可以在项目根目录放置一个 ARCHITECTURE.md 或 TECH_STACK.md 文件，并在首次对话中让AI“阅读”它。
迭代与引导 ：不要期望AI一次就生成完美代码。将 /execute_plan 视为一个迭代过程。当AI生成一段有问题的代码时，直接指出问题所在（例如：“这个函数没有处理空值情况”），AI通常会根据反馈进行修正。你是在引导一个强大的助手，而不是向一个神谕提问。
结合 /tdd ：对于逻辑复杂的部分，切换到 /tdd 模式。测试用例本身就是最精确的需求描述，能极大提升AI生成代码的准确率。
模型选择 ：如果你使用的AI IDE允许选择底层模型（如GPT-4o、Claude 3.5 Sonnet等），尝试切换到更新、能力更强的模型，它们在代码生成和理解复杂指令上通常表现更好。

6.4 工作流感觉过于冗长

问题：对于一个小修改，走完全部四阶段感觉杀鸡用牛刀。

灵活裁剪 ：这正是“标准步骤”与“可选步骤”设计的用意。对于一个明显的拼写错误修复，你完全可以只用 /capture_issue （简要描述）然后直接修改。工作流是为你服务的工具箱，不是束缚你的枷锁。
创建快捷命令 ：你可以基于常用场景创建自定义的快捷命令。例如，创建一个 /quick_fix 命令，它只组合了 /capture_issue 的精简版和 /code_review 的核心检查项。
关注核心价值 ：问自己，跳过某个步骤的风险是什么？如果只是几行代码的简单调整，且上下文清晰，跳过深度设计可能是合理的。但如果改动涉及数据流或状态管理，即使很小，花几分钟运行 /design_decisions 也能避免未来数小时的调试。

6.5 团队协作时如何统一工作流

问题：如何让团队所有成员都使用这套规范？

共享配置入库 ：将定制好的 commands/ 目录作为项目模板或脚手架的一部分，纳入项目仓库。在新成员初始化项目时，自动复制这些命令到其本地IDE配置目录。可以在项目 README.md 或 CONTRIBUTING.md 中明确说明工作流的使用方法。
代码审查中引用 ：在团队的Pull Request模板中，可以加入检查项，例如“本次变更是否已通过 /code_review 命令审查？”、“复杂功能是否附有 /design_decisions 文档？”。通过流程而非强制来推广最佳实践。
定期复盘 ：在团队迭代会上，使用 /postmortem 的输出来讨论开发过程中的共性摩擦点，并共同决定如何调整命令模板来优化团队流程。让工作流随着团队一起进化。