--- title: "GSD 工作流完整实战：从会话驱动到阶段化工程" author: deletexiumu pubDatetime: 2026-04-11T15:00:00+08:00 featured: false draft: false tags: - Claude Code - AI Agent - 教程 - 效率 description: "GSD（Get Shit Done）把 Claude Code 从单 prompt 聊天接力赛升级为九阶段工程化流水线——含完整命令、设置踩坑、worktree 血泪规则与 12% token 节省技巧。" --- ![GSD 工作流完整实战封面：工程化流水线隐喻插画](/blog/gsd-workflow-practice/cover.jpg) ## 一、你的 Claude Code 还停留在接力赛模式吗 打开一个 Claude Code 会话，敲一句"帮我清理一下项目里的历史技术债"，它开始写。写到一半问你"XX 模块要不要保留"，你说"保留"。结果它改错了地方，你让它撤回，它又把上一版的修改一起撤了。你再补一句话，它又开始编辑另一个文件。十分钟过去，你已经不知道 AI 到底在改什么。 这是多数人用 Claude Code 的日常——**单 prompt 接力赛模式**。一句话描述需求，等结果，再补一句，再等结果。前三轮惊艳，第五轮跑偏，第十轮失控。 问题不在模型。在 [《别让 AI 乱写代码：从方法论到实战，我的 Claude Code 工作流》](/posts/claude-code-plan-before-code/) 里我写过 Boris Tane 的手工三阶段方法论：Research → Plan → Implement，用 Markdown 文件作为共享的可变状态，在审阅并确认书面计划之前，不让 Claude 写一行代码。 这套方法论已经解决了一半问题。剩下的一半是——**它仍然依赖开发者的自律**。你必须自己记得先 Research、再 Plan、再 Implement，自己维护批注循环，自己判断什么时候该评审、什么时候该 merge。 团队内部最近做了一次培训，分享一套把这套哲学落成可执行流程的工作流，叫 **GSD（Get Shit Done）**。它把九个阶段拆成九个命令，每个阶段有明确的输入、产出和门禁，评审环节内置，多代理并行时自带 worktree 对齐保护。培训之后团队把某内部项目完全切到 GSD 驱动，一个月下来结论很明确：慢一些，但思考更全，质量更可控，代理再多也不跑飞。 这篇把整套流程记下来，顺带带上团队踩过的坑和那些你从官方文档里看不到的设置陷阱。 ## 二、配套工具链：五件套 进 GSD 之前，先装五个工具。它们和 GSD 本身无关，但都是后续工作流里每天都要用到的基建。 | 工具 | 一句话用途 | 仓库 | |---|---|---| | claude-island | Claude Code 跑长任务完成时弹通知（仿灵动岛） | github.com/engels74/claude-island | | Lark CLI | 命令行批量操作飞书文档，以个人身份读写 | github.com/larksuite/cli | | OpenCLI | 跨平台信息获取，支持 Grok、Gemini、携程、豆瓣、微信等几十个平台 | github.com/jackwener/OpenCLI | | CCometixLine | Claude Code 状态栏，显示分支、context 占用、当前模型 | github.com/Haleclipse/CCometixLine | | claude-sound-fx | 声音提醒，Windows 友好，跨平台 | github.com/6m1w/claude-sound-fx | 装法都一样——`npm install` 或按 README 指示走，不复杂。这里有一条隐藏规则，先记下，到第四节会详细解释：**能用 CLI 就别用 MCP**。OpenCLI 之所以优先于同名 MCP 工具，核心原因是 token 成本，后面回收。 一点额外体验优化：如果你用 WARP 终端，中断会话后可以 `resume` 还原；状态栏能让你实时看到 context window 占用，一般超过 170K 就该 compact 一下——如果你拖到 195K 再压缩，很可能报"压缩窗口不够"，整个会话就废了。 ## 三、GSD 九阶段：一条流水线 装好 GSD 插件集（`github.com/gsd-build/get-shit-done`），进入正题。GSD 的基本单位不是一次对话，是一个**里程碑（milestone）**。一个里程碑下面拆成多个**阶段（phase）**，每个阶段走一遍九步走。 ### 第 1 步：`/gsd-new-milestone` —— 需求对齐 进入项目目录敲一条： ``` /gsd-new-milestone 清理历史技术债 ``` GSD 会自动扫描项目、识别已有的 roadmap、生成候选需求清单让你确认。如果前面已经开发过几个版本，它会先扫已有的技术债和延后任务，给你一份清单。 为什么第一步是需求对齐？因为后面所有阶段都会基于这份"你已经签字确认过"的需求开工。把模糊问题在第一步就拍死，避免 execute 阶段还在改方向。 首次进项目可以用 `/gsd-new-project` 代替，它会顺便做目录结构初始化和 Git 配置。 ### 第 2 步：`/gsd-discuss-phase` —— 阶段讨论 里程碑确认后，GSD 会自动拆成若干个阶段（比如 front clean up / back clean up / 验证 / 质量扫除）。你确认拆解合不合理，然后对每个阶段单独走 discuss： ``` /gsd-discuss-phase 51 ``` GSD 会侦查现有代码，针对这个阶段列出它识别到的**常见坑和边界问题**，让你逐个选哪些需要讨论。这一步不是自动化——是给人把关的机会。 培训里有一句话我印象很深：**"这里真的需要一些技术功底在里面，因为这一步会涉及技术路线的选择。"** AI 再强也不能替你决定"这张表是按天分区还是按月分区"这种业务侧判断。discuss 就是把这些决策摆在桌面上。 ### 第 3 步：`/gsd-research-phase` —— 调研 discuss 结论敲定后，走 research： ``` /gsd-research-phase 51 ``` GSD 会基于 discuss 内容做技术 + 业务调研，产出一份研究报告（一份 Markdown 文件）。这一步和序号 15 里的 "Research" 阶段思路一致——让 AI 先把代码和相关依赖读透，写出来你能审阅的文档。 discuss 是收敛**需求**，research 是收敛**实现路径**。 ### 第 4 步：Codex 对抗审查 + Grok 最佳实践（关键加餐） 这一步不是 GSD 官方命令，是团队在培训里反复强调的**关键加餐**，也是全流程的兜底。 GSD 官方流程是 research 直接 plan。但团队在 research 和 plan 之间插了一层：**把研究报告发给 Codex 做对抗审查，涉及最佳实践的部分用 Grok 搜社区讨论，多轮迭代直到 Codex 审核通过。** 为什么必须插这一步？两个现实问题： **第一，大模型的知识库有延迟。** 现在是 2026 年 4 月，Claude 的官方知识库很可能还停留在 2025 年上半年，半年以上的延迟是常态。你在写一个今年才发布的库的集成代码，模型记得的还是去年的 API。 **第二，Codex 和 Claude 的训练偏差不一样。** 用 Codex 审查 Claude 产出的研究报告，相当于让两个有不同盲区的模型互相挑刺，比同一模型反复自我批评有效得多。 Grok 的作用是实时社区信号。它天然集成了社交平台的实时搜索能力，在抓取最新技术讨论上几乎是最强的。退而求其次用 Gemini（Google 搜索保底）。 团队把这一步封装成一句固定 prompt： > 把研究报告发送给 Codex 审查，根据审查意见进行修改。如果涉及最佳实践，则使用 Grok 搜索社区最佳实践。修改后再次复审，多轮迭代直至 Codex 审核通过。 调用时有两个硬规则，踩过坑才记住的： - **Codex MCP**：调用必须带 `model: "gpt-5.4"` + `config: {"reasoning": "high"}`，缺一不可。审查用 `read-only` sandbox，测试/执行用 `danger-full-access`，切换 sandbox 要新开对话 - **Grok 优先走 CLI 不走 MCP**：用 `opencli grok ask "具体问题"` 直接从命令行搜索，而不是走 Grok MCP。原因后面第四节展开 这一层带来的心理松弛感很具体：**哪怕你对这个技术领域完全不懂，至少这一层审查在帮你拦一道。** 这是团队里几个非开发背景的同事也敢用 GSD 驱动业务开发的底气来源。 ### 第 5 步：`/gsd-plan-phase` —— 计划制定（UI 分叉） 评审通过后做 plan。这里有一个分叉： - 涉及前端页面 → 先走 `/gsd-ui-phase`，再走 `/gsd-plan-phase` - 纯后端 / 纯数据管线 → 直接 `/gsd-plan-phase` UI 风格必须先对齐，否则多个页面做出来会"一个红一个绿一个五彩斑斓"。`/gsd-ui-phase` 就是做这件事——先定页面风格、交互模式、配色基调，产出一份 UI SPEC（设计合约），后续所有 UI 阶段都遵守这份合约。 plan 阶段产出的不是代码，是一份可审阅的计划文件。GSD 自己会做一轮 plan 检查（相当于"让它先自己检查一下自己的计划"），也就是 `/gsd-settings` 里的"规划检查"选项——保持默认开启就行。 ### 第 6 步：`/gsd-execute-phase` —— 执行 + 自动单元测试 到了这一步基本是机械执行： ``` /gsd-execute-phase ``` 前面四层（discuss → research → 评审 → plan）已经把方向定死，execute 不再纠结"要做什么"，只负责"怎么做"。开发完 GSD 自动跑一轮单元测试，不需要人工介入。 execute 阶段会并行拉起多个 subagent，底层用 Git worktree。如果波次之间有依赖关系（比如必须先跑通 A 波次的建表，才能跑 B 波次的写数），可以让 Codex 测试介入——把测试内容连同必要的环境信息和权限发给 Codex，让它跑一遍确认，再继续 B 波次。 多代理并行有一条团队踩过第一血案的规则，放到第四节的设置踩坑里详细讲。 到这里前五步是定方向，后四步是干活和收尾。 ### 第 7 步：`/gsd-verify-work` —— UAT 测试（人机分工） execute 完成后走 UAT： ``` /gsd-verify-work ``` 这里有一条团队总结出来的**人机分工规则**： - **纯后端 / 纯数据管线** → 整体交给 Codex 做三方测试。提供测试内容、环境信息、相关权限，让 Codex 执行测试、返回结果 - **涉及 UI 的阶段** → 必须人工测试 UI 不能交给自动化的原因，培训里举了一个非常具象的例子——某内部项目里一个知识图谱，最开始做出来"整个图谱全部团成一团毛线，节点全堆一起"。自动化测试跑得过，Playwright 能打开页面截图，但它根本不知道这团毛线是正常还是异常。人一眼就能看出来"这丑爆了"。 UI 类的坑就是这样：功能都对，但视觉表达完全错位。自动化看不出来，必须人工过一遍。 ### 第 8 步：`/gsd-audit-milestone` —— gaps 审计 所有阶段都 verify 通过后，走里程碑审计： ``` /gsd-audit-milestone ``` GSD 会对比"最初 roadmap 承诺要做的事"和"实际做出来的东西"，总结两类清单： - **gaps**：和原计划的偏差（可能是遗漏、可能是方向跑偏） - **tech debt**：为了赶进度故意留下的技术债 gaps 通常有三种处理方式： 1. **修复**（最常用）—— 既然识别为 gap，一般就是忘了或者做漏了，直接补 2. **修改文档**（次常用）—— 实际实现比原计划好，反过来把设计文档对齐到实际实现 3. **推后修复**（最少用）—— 说明本来就不该放进这个里程碑，下个版本再修 技术债一般不在当前里程碑修复——既然决定欠债，就是因为本阶段不想做。 如果审计出 gaps 需要处理，用 `/gsd-plan-milestone-gaps` 制定修复计划，再用 `/gsd-execute-phase --gaps-only` 按计划修。 ### 第 9 步：`/gsd-complete-milestone` —— 合并发布 ``` /gsd-complete-milestone ``` 把里程碑分支 merge 到 main，打 tag，做 release，可选跑 CICD 做生产发布。这是标准的软件工程收尾动作，GSD 只是把这步纳进来一起编排。 ### 配角：`/gsd-quick` 和 `/gsd-progress` 不是所有需求都值得走完整九阶段。团队的实操规则： - **小 bug 修复** → `/gsd-quick` - **一张表的数据开发** → `/gsd-quick` - **UAT 发现的小问题** → `/gsd-quick` - **新功能开发 / 重构 / 疑难杂症** → 完整九阶段 quick 同时适用 fix bug、fix gaps 和一些小功能开发。它保留 GSD 的状态管理和原子提交，但跳过 discuss / research / 评审 / plan 这几步——没必要大炮打蚊子。 另一个救命命令是 `/gsd-progress`。场景很具体：你上周干了一半，中间紧急事情插进来跑去忙别的，一周后回来完全忘了上次干到哪。一句 `/gsd-progress` 查看当前开发进度和下一步任务。 ## 四、关键设置与踩坑经验 光知道命令还不够，GSD 有几个**反直觉的设置**和一条**不设置就等着翻车的规则**。 ### 设置三批 `/gsd-settings` 打开的配置分三批。大部分保持推荐就行，只有三个关键点需要注意： **1. 模型档位——configure CC switch 比选 quality 还重要** CC switch 是 Claude Code 的模型路由层（npm 安装的同名工具 `cc-switch`），它把 `haiku`、`sonnet`、`opus` 三个别名映射到你实际使用的模型——可以是 Anthropic 官方，也可以是国内代理站上的某个模型 ID。GSD 内部按别名调度，`quality/balance/saver` 三档只是选别名的语法糖。 三档差别不大（除非你用 Claude 官方订阅做细分）。真正重要的是：去 CC switch 里把三个别名都配上。你选 balance 档它就去找 `sonnet` 别名，你不配全直接报错。 **2. 自动推进流水线——必须改成 no** 默认是 yes，结果是讨论阶段 AI 自问自答一路跑下去没人把关。团队在群里反复提醒"怎么自己问自己答下去了"，多半就是这个设置没改。 **这个选项在讨论阶段尤其致命**——讨论需要的是人和 AI 的对话，不是 AI 自己和自己玩。改成 no，所有自动推进都停在需要人确认的地方。 **3. Git 分支策略——不采用默认推荐** 这是全部设置里**唯一一项**推荐反默认的选项。默认推荐"直接在 main 分支开发"，必须改成**每里程碑独立分支**。 原因很直接：GSD 开发过程中会有大量中间提交，如果都堆在 main 上，main 分支就永远处于"半成品"状态，生产部署根本不敢动。一个里程碑一个分支，做完 merge 回 main，main 始终保持可部署。 其他设置（提问前研究最佳实践选 no、自助模式不跳过阶段、并行代理用 worktree）都保持推荐即可。 ### 血泪规则：worktree 分支对齐 前面第六节提过 execute 阶段会拉起多个 subagent 用 worktree。这里有一个**不设置就等着翻车**的规则： > **默认 worktree 可能基于 main 分支，而不是当前 feature 分支。** 结果：不同 subagent 基于不同分支开发，开发完 merge 时 feature 分支的修改被**静默降级**——相当于整个开发白做了。团队第一次中招时用的是顶配档位的模型，原以为顶配大模型不会犯这种错误，结果一样犯。 救命规则，直接写进**全局 memory**（即 `~/.claude/CLAUDE.md`，每次启动 Claude Code 都会自动加载的个人全局指令文件，用法详见 [《同样的话跟 Claude Code 说了八遍，是时候让它自己记住了》](/posts/claude-code-memory-rules/)）： > 当使用 Claude Code 启动多 SubAgent 开发时，必须在 Prompt 中强制要求对齐 worktree 的 base 版本。默认以当前 branch 作为 worktree base。如果 merge-base 检查不可靠，使用 `git reset --hard {EXPECTED_BASE}` 强制对齐，并验证关键文件存在。 这条规则我已经写进 `~/.claude/CLAUDE.md` 全局经验教训文件，每次会话自动加载。建议你也加上。 ### 省 12% token：一条 CLAUDE.md 的事 GSD 工作流跑起来 token 消耗非常大——团队一天能跑两亿 token。如果你也是高频用户，有一个极其简单的优化能省出 12%： 在 `CLAUDE.md` 里加一条精简规则，禁止 Claude 的礼貌话术。Claude 默认的回复里充斥着 `Sure! Great question!` 开头、`I hope this helps!` 结尾、"让我来复述一下你的问题"、对明显错误的观点先说一句 `You're absolutely right!` 再反驳。这些废话全部消耗 token，信息量为零。 具体规则（精简版，按需裁剪）： ``` - Think before acting. Read existing files before writing code. - Be concise in output but thorough in reasoning. - Prefer editing over rewriting whole files. - Do not re-read files you have already read. - Test your code before declaring done. - No sycophantic openers or closing fluff. - Keep solutions simple and direct. - User instructions always override this file. ``` 参考仓库 `claude-token-efficient`，两天 1900 star。作者原文实测输出 token 直降 63%，第三方基准测试的编码任务总成本省 17.4%，团队日常跑下来省 12% 左右——越接近纯对话的任务省得越多，越接近编码+工具调用的任务省得越少。 作者明确指出适用边界：这个文件本身每轮对话都作为输入 token 加载。**只有日均 100+ prompt 的高频场景才有净收益**，偶尔用反而更贵。GSD 恰好落在这个区间——一个里程碑几百次工具调用，规模效应非常明显。 ### 三个让命令行更顺手的小技巧 培训里顺手讲了几个小技巧，每个都很短但日常救命： **Ctrl+S 暂存命令。** 正在打一长串提示词，突然想起应该先跑个 clear？按 Ctrl+S 暂存当前命令，打 `clear`，执行完再按一下 Ctrl+S 把刚才的命令恢复出来。避免删了重打的烦躁。 **ESC 快速回退 + WARP terminal resume。** 几下 ESC 立刻中断当前任务并回退；如果你用 WARP 终端，中断之后 WARP 会显示"你可以 resume 这个会话"，恢复到中断前的状态继续干。 **BTW 旁路提问。** 执行长任务时用 `BTW` 开头问问题，**不打断当前任务，不占用主上下文窗口**。比如： ``` BTW 当前阶段 51 技术方案大致怎么做？ ``` Claude 会开另一条线答复，你看完按 enter 或 space 回到主任务。底层应该做了特殊处理，总之窗口占用不变。这个对 GSD 特别有用——execute 跑到一半你想确认某个细节又不想打断波次执行，BTW 完美解决。 ### 安全围栏：给"踩油门"加刹车 `--dangerously-skip-permissions` 这个参数让 Claude 跳过所有权限确认，不用每次敲 y。体验提升巨大，但**不加护栏裸奔等于把一把枪顶着自己脑袋**。 正确姿势是三道防线（详见 [《Claude Code 安全三道防线：从权限模式到 Hook 兜底的纵深防护实战》](/posts/claude-code-safety-three-defenses/)）： 1. **第一道：权限模式 + 权限规则 + 沙箱边界** ——粗粒度全局边界，Claude Code 内置配置 2. **第二道：Discernment 门禁** ——高风险任务执行前强制走一轮语义级风险评估，规则文件驱动、纯 prompt 级 3. **第三道：Hook 兜底** ——硬编码规则拦截，命令黑名单（`rm -rf`、`drop table` 一类一刀切的破坏性操作）+ 文件白名单（不允许改 `~/.ssh/config` 这类项目外文件），不依赖 AI 判断 ⚠️ 配 Hook 黑名单时有一个容易踩的坑——**不要把 `git reset --hard` 无脑拦掉**。本文前面血泪规则里对齐 worktree 用的就是这条命令，读者如果把两处规则都直接照抄，worktree 对齐会被自己的 Hook 先拦住。破坏性 git 命令的拦截要做得更精细，只拦主仓库、放行临时 worktree 目录下的 reset。 三道防线都配好，并且你确认当前是**容器、VM 或隔离沙箱环境**之后，再考虑给 `claude` 命令加个 alias： ```bash alias claude="claude --dangerously-skip-permissions" ``` **裸机主机上不要直接设这个 alias**——三道防线那篇里反复强调过这一条。真要跳权限，要么跑在 Docker 里、要么跑在单独的虚拟机里、要么临时 `claude --dangerously-skip-permissions` 一次性调起，不要当默认值。 ### CLI > MCP：回收伏笔 第二节埋的线现在收回来。为什么能用 CLI 就别用 MCP？ **MCP 工具会在上下文里注入大量工具描述，每轮对话都加载。** 一个 MCP server 暴露十几个 function schema，加起来可能几千 token；你装五个 MCP server，光是工具描述就吃掉 context window 几万 token。而 CLI 调用是一行命令，用完即走，不占窗口。 规模效应在 GSD 场景下被进一步放大。一个里程碑跑几百次搜索调用，每次都加载工具描述，积累下来的差距是几十万 token 量级。 具体规则： - **Grok 搜索用 CLI 不用 MCP**：`opencli grok ask "具体问题"`，比 Grok MCP 快而且不占窗口 - **飞书文档操作用 Lark CLI**：比 Lark MCP 省得多 - **Codex 审查用 MCP**：因为 Codex 需要把整个文件内容作为上下文传过去，这个场景 CLI 反而麻烦，MCP 的 token 开销是值得的 判断标准：**这次调用是一次性的简单查询还是反复的长上下文交互？** 前者用 CLI，后者用 MCP。 ## 五、尾声：慢，是故意的慢 把全部流程走一遍，最直观的感受是：**GSD 的慢是故意的慢**。 - 慢，是因为 discuss / research / 评审都认认真真做了一遍 - 快，是因为 execute 阶段一次跑完基本不返工 净效应是一个里程碑 1-3 天，看起来比"聊天式开发"慢得多，但节省的是反复返工和 context switch 的时间。更重要的是，**你不用再自己记得"先 Research 再 Plan 再 Implement"**——流程会把你拽着走，不自觉也跑不偏。 这也是手工三阶段方法论和 GSD 的核心差异：前者依赖开发者自律，后者靠工程化兜底。 ### 最小起步三步 完整配置有点多，不要一次全上。最小起步路径就三步： 1. **装插件集**：`github.com/gsd-build/get-shit-done`，跟着 README 初始化 2. **跑 `/gsd-settings` 改三项**：自动推进改 `no`、Git 分支策略改"每里程碑独立分支"、CC switch 配全三档别名，其他一律保持推荐 3. **用 `/gsd-quick` 修一个手头的小 bug**：不要追求完整九阶段，先感受 GSD 的状态管理和原子提交 ### 进阶优化 小 bug 跑通之后再加两条长期收益的配置： - **启动多代理之前**：把 worktree 对齐规则写进 `~/.claude/CLAUDE.md`，永久生效 - **高频使用场景**：在 `CLAUDE.md` 里加一条 token-efficient 规则，省 12% ### 需求模糊时的组合拳 如果你开一个新里程碑时还不确定需求是什么，先用 `brainstorm` 和 Claude 头脑风暴一段，**不要 clear**，紧接着 `/gsd-new-milestone`，带着前面的讨论上下文进入。 ### 安全前置 所有 `--dangerously-skip-permissions` 的使用都放到**容器或 VM 里**。不要在主机裸机上图省事设 alias——序号 24 里有完整的三道防线配置指南。 感受 GSD 价值最直接的时间点，是第一次看到"Codex 审查通过"的那一刻——你会突然意识到自己已经不在一个人跟 AI 对话，而是在监工一条小型流水线。 --- ## 附录：GSD 命令速查表 | 阶段 | 命令 | 说明 | |---|---|---| | 项目初始化 | `/gsd-new-project` | 新项目首次使用 | | 制定里程碑 | `/gsd-new-milestone` | 日常起点 | | 阶段讨论 | `/gsd-discuss-phase` | 暴露常见问题 | | 技术调研 | `/gsd-research-phase` | 产出研究报告 | | UI 规划 | `/gsd-ui-phase` | 仅涉及前端时 | | 整体计划 | `/gsd-plan-phase` | 纯后端直接这步 | | 执行 | `/gsd-execute-phase` | 自动跑单元测试 | | UAT 验证 | `/gsd-verify-work` | 后端交 Codex / UI 人工 | | 里程碑审计 | `/gsd-audit-milestone` | gaps + 技术债 | | 完成里程碑 | `/gsd-complete-milestone` | merge + tag + release | | 追加阶段 | `/gsd-add-phase` | 末尾追加阶段 | | 插入阶段 | `/gsd-insert-phase` | 指定位置插入 | | 快速修复 | `/gsd-quick` | 小修小补、fix bug | | 查看进度 | `/gsd-progress` | 忘记干到哪 | | 代码走查 | `/gsd-code-review` | execute 之后用 | | 走查修复 | `/gsd-code-review-fix` | 配合 code-review | | 安全审查 | `/gsd-secure-phase` | 注入风险检查 | | 文档更新 | `/gsd-docs-update` | 代码改完文档没跟 | | gaps 计划 | `/gsd-plan-milestone-gaps` | 审计后出现 gaps | | gaps 修复 | `/gsd-execute-phase --gaps-only` | 按计划修 gaps | | 工作流设置 | `/gsd-settings` | 三批配置入口 | ## 参考资料 - GSD 工作流插件集： - claude-island： - Lark CLI： - OpenCLI： - CCometixLine 状态栏： - claude-sound-fx 声音提醒： --- ## 相关阅读 - [《别让 AI 乱写代码：从方法论到实战，我的 Claude Code 工作流》](/posts/claude-code-plan-before-code/) — 本文的自然前置。手工版 Research→Plan→Implement 三阶段方法论，GSD 九阶段是它的工程化封装 - [《Claude Code 安全三道防线：从权限模式到 Hook 兜底的纵深防护实战》](/posts/claude-code-safety-three-defenses/) — GSD 让你踩油门，三道防线才能让你安全踩油门 - [《同样的话跟 Claude Code 说了八遍，是时候让它自己记住了》](/posts/claude-code-memory-rules/) — 全局 memory 的配置指南，GSD worktree 对齐规则就写在这类 CLAUDE.md 文件里