这几年AI编程工具迭代得飞快，但绝大多数人还停留在“开个网页对话框，把代码粘进去，再把答案粘回来”的阶段。而真正把AI用出生产力的，是那些把提示词工程固化到工作流里、让AI稳定地承担固定角色的人。Claude Code的出现改变了这个局面——它在终端里直接运行，能读你的仓库、执行命令、改文件、跑测试，相当于一个真正能上手的结对工程师。但用得越多，我越发现一件事：如果每次都在对话里临时写“请帮我审查这段代码”“请生成提交信息”，Claude Code的表现会很不稳定，时好时坏。真正让它的能力稳定发挥出来的，是一套按场景沉淀下来的模板系统。
我花了大约三周时间，把项目里几乎所有高频场景的Claude Code模板整理成了一整套体系，覆盖代码审查、提交信息生成、大型重构、单元测试、文档生成、故障排查等场景。实测下来，同样的任务，用模板和不用模板的效果差距非常明显——不用模板时，它像个聪明但散漫的实习生，经常做着做着就跑偏；用了模板后，它就是个稳定输出的熟练工。这篇就完整分享我这套模板库的设计思路、配置方法、实际效果和踩过的坑。
1. 模板库的整体设计与目录规划
1.1 一个模板库要解决的实际问题
先说结论：Claude Code的能力上限并不取决于模型本身，而是取决于你给它的上下文质量。模型再强，如果你不给它明确角色、不给它规范输出格式、不告诉它哪些事情不要做，它就会按照自己默认的方式干活——写代码时可能很冗长，审查时可能只提表面的风格问题，做重构时可能大动干戈改出一堆回归。
我的模板库本质上做的是三件事：
- 把“角色设定”固化。在CLAUDE.md里定义清楚“在什么场景下，Claude是什么角色，应该用什么标准工作”，而不是每次对话靠临场发挥。
- 把“工作流程”固化。用自定义斜杠命令把多步骤流程封装成一条命令，比如代码审查不再是“帮我看看这段代码有什么问题”，而是执行
/review src/auth/login.ts——它会自动触发一个完整的审查流程。 - 把“输出规范”固化。规定报告格式、行文风格、代码风格，让输出结果可预期、可复用，而不是每次都是不同结构。
这套方案适合谁？如果你每天都在用Claude Code写代码、做代码审查、处理重构，或者你带团队、想让团队成员的AI使用方式标准化，这套模板体系都能直接拿来改。
1.2 目录结构与核心文件说明
我的模板库采用了一套非常清晰的目录层级，核心结构如下：
backup/ ├── .claude/ │ ├── CLAUDE.md │ ├── commands/ │ │ ├── review.md │ │ ├── commit.md │ │ ├── refactor.md │ │ ├── test.md │ │ ├── docs.md │ │ └── debug.md │ └── settings.json第一份仓库级CLAUDE.md是我的全局约束和行为基线，声明所有场景下Claude需要遵守的通用规则，比如“不要动未指明的文件”“提问时优先给出具体方案”等。commands目录下每个文件对应一个自定义斜杠命令，它们本质上是带YAML frontmatter的Markdown提示词文件——frontmatter里声明命令名称、描述、参数，正文则写具体的执行指令。
这套设计有一个非常明显的优势：配置是声明式的，不是编程式的。你不需要写任何脚本逻辑，只需要用自然语言描述清楚这个命令的场景目标和执行步骤，Claude Code会自己理解并执行。这意味着团队里任何成员都能往里面添加新模板，不需要会写代码。后续我要做的所有事情，都是往这个骨架里填充内容。
1.3 为什么这么设计：三个关键选型背后的逻辑
在整个方案设计阶段，我其实调研过几种不同的模板组织思路，包括比较“重”的方式——写一个Python脚本来动态生成不同的提示词上下文，也试过完全靠CLAUDE.md一个文件堆全部规则。最终都否掉了，原因如下。
第一种，动态脚本方案。看起来高大上，但引入了额外的运行层，出问题时要同时排查脚本和模型行为，成本很高。第二种，单文件堆规则方案，文件会膨胀到几百行，模型对全文的注意力会分散到不相关内容上，实际效果反而不如短小精悍的命令文件。
而我选定的这套方案，本质上是把CLAUDE.md当作“宪法”，把commands当作“部门规章”。宪法管底线，部门规章管具体场景操作。这样有两个显而易见的好处：一是每个模板的体积都很小，上下文聚焦；二是排查问题时边界清晰——行为不符合预期，要么是CLAUDE.md的规则没写清楚，要么是具体命令文件的指令有歧义，定位很快。
另外，这套方案还有一个隐性收益：模板文件本身就是给人类看的文档。团队成员看一遍commands目录，就能知道这个团队用Claude Code做哪些事、每件事的标准是什么。它天然成了团队的AI使用规范文档，一举两得。
2. CLAUDE.md的核心语法与配置实践
2.1 项目级、用户级、会话级配置的层级关系
在深入写CLAUDE.md内容之前，有一个基础机制必须先搞明白：Claude Code的配置是有层级的。简单来说，用户级配置（~/.claude/CLAUDE.md）在所有项目里都生效，项目级配置（./CLAUDE.md）只对当前仓库生效，会话级配置则通过/memory命令或对话中的指令临时生效。
这三者的关系有点像我日常处理配置的习惯：用户级配置放“普适价值观”，任何项目都适用的底线规则，比如“不要编造不存在的函数”“不要在没有证据的情况下断言性能问题”。项目级配置放这个仓库特有的技术栈、架构约定、目录规范。会话级配置则是在具体动手前临时强调的东西——比如这次想让它重点检查安全漏洞，而不只是逻辑正确性。
我见过很多人在项目级配置里写了一大堆“一定要负责”之类的空话，其实完全没有意义。CLAUDE.md的价值在于用具体的、可执行的指令约束行为，而不是用抽象的道德要求。写“不要修改未提及的文件”比写“请谨慎操作”有效一百倍。
2.2 权限与安全配置：让AI在笼子里跳舞
Claude Code最强大的能力之一就是能直接执行命令、读写文件。但在共享文件系统里，这种能力有多强、风险就有多大。我第一周用的时候就被它“自作主张”修改了一个还没提交的配置文件，虽然问题不大，但那次之后我迅速把权限模型研究透了。
Claude Code的权限配置在settings.json里，核心字段分两个维度：允许执行的Bash命令白名单和文件读写权限控制。我采用的是“默认禁止，白名单放行”的策略：
{ "permissions": { "defaultMode": "acceptEdits", "allow": [ "Bash(npm run lint:fix)", "Bash(npm test)", "Bash(git status)", "Bash(git diff)", "Bash(git add *)", "Bash(git commit -m *)", "Read(//)", "Edit(//)" ], "deny": [ "Bash(rm -rf *)", "Bash(git push --force *)", "Bash(sudo *)" ] } }这里的核心原则是：放行的命令必须能覆盖工作流里高频操作，禁止的命令必须能挡住破坏性后果。比如npm test这类命令天天都要跑，每次手动确认太烦，放进白名单。git commit -m *放行，但提交信息格式由模板控制，所以加了个带-m参数的限制，防止它弹出交互式编辑器挂起。rm -rf和强制推送则必须拦截，这类误操作根本没法后悔。
还有defaultMode这个字段，我设置为acceptEdits，意思是它可以直接执行文件编辑操作，不用每次弹确认框。如果你在更敏感的环境里（比如生产仓库），建议设为plan，让它所有编辑先出方案、等确认。权限写得越细致，后面用起来越顺手，以下配置我优化了三次才达到“顺畅又安全”的平衡点。
2.3 一个我实测有效的CLAUDE.md基础模板
这是我在多个仓库里验证过的通用模板，不是空泛的规则堆砌，每条都有明确意图：
# Project Context This project uses TypeScript with React frontend and Node.js backend, tested with Vitest, linted with ESLint, formatted with Prettier. # General Rules 1. Only modify files that are explicitly relevant or directly requested. 2. Use TypeScript strict mode, no `any` type unless absolutely necessary. 3. Write tests for all new business logic. Place tests adjacent to the source file. 4. When asked to "review code", always output a severity-tagged report (P0/P1/P2) before suggesting any changes. 5. If the code base differs from the above conventions, point out the discrepancy rather than silently following what the code appears to do. # Commands Style - Use `npm` for package management, never `yarn` or `pnpm`. - Always use `npx` for tools that are not explicitly listed as dependencies.写技术栈声明，是为了让Claude独立自主地选择符合项目惯例的API用法和工具链；写"如果代码库和规范不一致，要指出差异而不是盲目跟从"，是为了防止Claude在面对老代码时直接模仿糟糕的旧写法。
这里的规则数量不宜太多，最好控制在10条以内——规则越多，注意力分散越严重，模型会倾向于只遵守前几条。我把最核心的“只能改和任务相关的文件”“写测试”“报告分级”排在前面，让它们在上下文窗口中占据更显著的位置。
3. 高频场景模板实现
3.1 代码审查命令：从“看法”到“分级报告”
代码审查是我最常用的场景，也是最值得做成模板的。在没有模板之前，我让Claude“帮我看看代码”，结果经常是：它把重点放在变量命名上，而忽略了真正重要的并发问题和错误处理欠缺。问题的根源在于“看看代码”这个指令太模糊了——模型不知道你的审查标准、关注的优先级和输出格式。
我的review.md模板把审查分成了四个层次，按重要程度排序，并且强迫它输出分级报告，用P0/P1/P2标记严重性：
--- description: Run code review on target files argument-hint: file1, file2, ... --- You are a senior software engineer. Review ONLY the files provided: $ARGUMENTS. Follow this review process strictly: 1. Read each file carefully, analyze control flow, error handling, and edge cases. 2. For each issue found, classify it as: - P0: Bug that will cause incorrect behavior, data loss, or security issue. - P1: Significant issue that will cause problems in mainline scenarios. - P2: Style, readability, or minor issue. 3. Output the report as a table: File, Line, Severity, Issue, Suggested Fix. 4. Do NOT modify any file. Do NOT run any command. 5. After the table, if there are P0 or P1 issues, summarize the top 3 fixes you would recommend, ordered by expected effort. Remember: report first, fix later. Review should only produce a report during this step.这个模板最关键的设计是那一句“Do NOT modify any file。Do NOT run any command”——这句话把“审查”和“修复”做了明确分离，默认让Claude先当纯粹的审查者而不是修改者。好多人实际用的时候没有这个限制，结果Claude一边说“发现了一个bug”一边就把代码改了，审查报告变成了代码修改记录，完全失控。
另一个关键点是$ARGUMENTS参数。我在命令文件里通过argument-hint告诉用户传文件路径，实际执行时用/review src/auth.ts, src/api.ts这种形式把目标文件传进去。参数越多，审查越精确，而不是让它自己去“整个仓库里随便找找”。
3.2 提交信息生成：利用git diff自动产出符合规范的commit message
提交信息这件事，看着简单，但实际上非常影响团队协作质量。我给Claude写的第一版提交信息模板，效果很差——它产出的提交信息像教科书里的例子，全是“feat: add new feature”这种毫无信息量的标题。后来我意识到问题在于：模板没有强制要求它先看git diff的具体内容，它在没有上下文的情况下只能编。
现在的commit命令模板是这样写的：
--- description: Generate a commit message based on current changes --- First, run `git status --short` and `git diff --stat` to understand what changed. Then, run `git diff --no-color` to read the actual content changes. Based on the changes, generate a commit message following this format: <type>(<scope>): <subject> - type: feat, fix, refactor, docs, test, chore, perf, style - scope: module or component name - subject: imperative mood, lowercase, no trailing period Then add a body with bullets explaining WHY the change is needed, not just WHAT changed. Do not mention unrelated files. Do not include generated or lockfile changes. Output only the final commit message in a fenced code block. Do not execute `git commit`.这个模板的精髓在于把信息获取步骤显式写进模板。加上“Do not execute git commit”是为了防止它在生成完信息后顺手把提交也执行了——很多场景下我想先看看提交信息再手动执行。如果确实想让它自动提交，就在对话里追加一句“run it now”。
在实际使用中，还有一个很实用的扩展：配合权限配置里的Bash(git diff *)白名单，这个命令不需要反复请求权限确认，路径很顺畅。第一版模板没有这一行，Claude执行git diff时每次都弹权限请求，非常拖拉。理解了“模板决定流程，权限决定卡点”之后，体验就流畅多了。
3.3 大型重构命令：限制范围、输出计划、逐步执行
在有Claude Code之前，大型重构通常要花我一整个下午，改到一半脑子就乱了。有了它之后，重构真实效率提升很大，但如果控制不好，危险也很明显——它胆子大，敢改，容易把改动范围从“重构A函数”扩大到“顺手优化了B文件的类型定义、调整了C组件的命名”。这种“顺手优化”是我最不想看到的，它会让代码评审变成一场大型考古行动。
所以我的refactor模板设计了一条强约束：先输出计划，确认范围，再动手；每一步都说明动了什么、为什么这样动。
--- description: Refactor code with minimal scope and structured process argument-hint: target file or description --- You are an expert in safe refactoring. Your task: $ARGUMENTS Before writing any code, output a refactoring plan: - List the files that need to change, and what specifically changes in each. - State explicitly which behaviors must remain unchanged after refactoring. - Identify risky transformation points and how you will minimize risk. After the plan is presented, wait for the user to confirm or adjust. Once confirmed: 1. Implement changes file by file, not all at once. 2. After each file is changed, run any available type checks or tests that cover it. 3. Do not refactor anything not listed in the plan. 4. Output a summary of changed files and test results at the end. If you discover incidental issues while refactoring, note them in a "Deferred" section. Do not fix them unless explicitly asked.实际测试中这个模板最成功的部分，是末尾的“Deferred”机制。之前Claude做重构时，看到旧代码里有个明显bug，直接顺手改了——它的逻辑是“我需要让代码正确”。但这个行为和重构目标是冲突的，因为评审人员无法分辨哪次改动是重构引入的、哪次是顺手修bug。有了“记入待处理事项，不主动修复”这条约束，重构行为才真正可控。
3.4 单元测试生成：不只是生成用例，还要生成测试意图
写单测是最容易被ChatGPT“看起来解决了、实际上没解决”的场景——它能生成能跑的测试，但测试质量往往很差：只覆盖happy path、断言很薄弱、没有边界条件。更重要的是，它生成的测试常常在测实现细节，而不是测行为契约，一旦实现方式变了测试就崩。
我的test命令模板要求Claude先列出测试意图，再写代码：
--- description: Generate unit tests for target source file argument-hint: source file path --- Analyze the target file: $ARGUMENTS Before writing tests, output a test intent list: - For each function or module behavior, write one line describing what behavior is verified. - Include normal cases, edge cases, error cases, and boundary values. - Specify which mocking strategy is needed, if any. Then write the actual tests using the project's testing framework and conventions. Follow these constraints: - Do not mock anything that can be tested without mocking. - Do not test implementation details, only observable behavior. - One test case per logical behavior, with clear test description. - If the production code is hard to test, note that in the summary instead of weakening the test. Finally, run the tests and report the results.这个模板让Claude Code的测试产出质量达到了接近独立开发者的水平。它这一条“Do not mock anything that can be tested without mocking”解决了一个普遍问题——AI喜欢过度mock，因为简化mock能让测试快速通过，但一个全部依赖mock的测试套件基本没有回归保护作用。
跑测试这步是必须的。模板里写了“run the tests”，配合权限白名单里的Bash(npm test)，Claude写完测试会顺手跑一遍，如果失败了它会看到具体报错并自己修。这个过程如果是手动转述，效率会低很多。
3.5 故障排查模板：基于证据的根因分析
故障排查是Claude Code最能体现价值、也最需要模板规范的场景。没有模板时，你问“帮我看看为什么这个接口报500”，它会掷骰子一样给出各种可能原因，从数据库连接池满了到某个依赖升级了，罗列十几种可能——这种信息一个经验丰富的开发根本不需要。
我的debug命令模板强制要求它先说清楚现象、再找证据、最后才给结论：
--- description: Debug an issue by analyzing evidence before concluding argument-hint: issue description or error message --- Investigate the issue: $ARGUMENTS Follow this order strictly: 1. Reproduce context: what command or HTTP request triggers this issue? If unknown, ask the user to provide it before proceeding. 2. Gather evidence: inspect logs, stack traces, relevant source code, configs, or execute diagnostic commands. Quote the evidence in your response. 3. Form a hypothesis: base it strictly on the evidence. If the hypothesis is not confirmable with current data, say so explicitly. 4. Propose fixes: list possible fixes, ordered by expected impact and risk. 5. Do NOT modify code or run non-diagnostic commands unless the user explicitly asks. If you do run something, show the command and output.这个模板最有价值的是第二点“引用证据”——Claude被禁止空口说白话，在给出结论前必须引用具体的日志行、堆栈帧或代码片段。这直接解决了AI调试里最大的问题：“自信地胡说”。
我用这个模板排查过一个很蛋疼的问题：一个服务在部署后偶发超时，但本地完全复现不了。Claude Code在模板驱动下先看了Nginx访问日志，发现超时请求全部来自一个特定的上游路径，再检查代码发现这个路径下有一个同步的Redis调用没有设置超时，上游Redis在特定时段响应慢就把整个请求拖死了——它引用日志里的具体行来支撑每一步分析，整个推理链条非常扎实。这个过程，如果没有模板强制约束，它大概率在前两步就跳到“可能是网络问题”这种废话结论了。
4. 团队统一性与命令的复用机制
4.1 把模板放进团队仓库：使用规范与争议
把CLAUDE.md和commands目录放进Git仓库后，整个团队的行为基线会快速趋同。新入职的同事，第一次运行/review就能看到一个标准的、和团队定义一致的审查报告格式；代码风格冲突问题也少了不少——CLAUDE.md里写了"用双引号、不写分号"，Claude Code生成的代码就不会和ESLint规则打架。
但有一个点需要提前跟团队说明：CLAUDE.md本身也是代码，是需要Review的。我见过最离谱的情况是有人为了“提高AI效率”，给CLAUDE.md写了一堆“如果用户让你做X，你应该只做X”的“防呆规则”，结果规则的表达互相冲突，模型行为变得更怪。所以我把CLAUDE.md当成一等公民，任何变更都要走PR，还要求写清楚改了什么行为、为什么要改。
另一个值得注意的点是：不要让团队里几个人用得很好、另外几个人完全不用。如果Claude Code的行为在不同成员手里差距过大，用得好的人觉得是神器，用不好的人觉得就是另一个聊天机器人。模板进仓库是统一体验最廉价的方式——每个成员第一天跑一下/review，就能立刻感受到这套体系的价值。
4.2 初始化脚本：一条命令拉起整套环境
为了让新成员能快速上手，我写了一个初始化脚本，本质上是把Clone仓库后需要的配置一次性完成：
#!/bin/bash set -euo pipefail # Ensure ~/.claude directory exists mkdir -p ~/.claude/commands # Link template commands to user-level directory (available across all repos) for cmd_file in .claude/commands/*.md; do ln -sf "$(pwd)/$cmd_file" ~/.claude/commands/ "$(basename "$cmd_file")" done # Merge project-level CLAUDE.md into user-level config if [ -f ~/.claude/CLAUDE.md ]; then echo -e "\n# Project Templates\n" >> ~/.claude/CLAUDE.md cat .claude/CLAUDE.md >> ~/.claude/CLAUDE.md else cp .claude/CLAUDE.md ~/.claude/CLAUDE.md fi echo "Setup complete. Run 'claude' to start."这份脚本的作用是将项目模板全局化，让团队成员的CLAUDE.md和命令在任何仓库里都可用——也就是说，即使你在一个还没有模板的旧仓库工作，也照样能跑/review、/refactor这些命令。新成员跑一次脚本就能获得和团队一致的能力基线，不用凭空摸索规则。
这里有个值得注意的细节：链接命令文件用的是软链接而不是复制。理由是模板库在Git里会持续更新，软链接能保证本地命令永远指向最新版本。如果你用复制，每次更新模板都得手动同步，容易漏。小小的实现差异，维护成本差很多。
4.3 settings.json的团队基线：什么该统一，什么该放权
团队共享settings.json是个双刃剑。统一权限配置确实能减少很多“为什么你的Claude能做这件事，我的不行”的困惑，但如果统一得太死，每个人的工作流都会被卡住。我的解决方案是把settings.json分成两层：仓库级的settings.json只放怎么都不会有异议的通用规则，用户级的~/.claude/settings.json放个人偏好。仓库级的白名单里只放测试、Lint、Git状态查看这类人人都需要的，个人偏好比如“某个特定脚本的路径”“个人常用的发布命令”放用户级。
有效做法是在项目文档里明确写清楚：通用部分以仓库级为准，个人扩展可以在用户级加。规则本身其实不会有歧义，歧义来自没有写明“谁说了算”的权限边界。写清楚这个边界后，团队里的疑问基本就消失了。
还应提示一点：不要在仓库级settings.json里放Read(//)全局读权限之外的东西。如果你允许它全局编辑，它在看到可疑代码时就会忍不住动手改。团队环境里，“默认只读、按命令放行编辑”是最稳妥的策略。
5. 常见问题与实战经验
5.1 命令不生效，或Claude Code根本不认识自定义斜杠命令
这个问题新人碰到最多。自定义命令的格式检查有固定规则：命令文件必须放在.claude/commands/目录下，文件名就是命令名，比如review.md对应/review，且必须有.md扩展名。yml格式或者放在错误位置的命令是识别不出来的。检查有没有生效，最简单的办法是启动Claude Code后输入/，如果弹出命令列表，说明识别到了；没弹出，就从文件位置和文件格式查起。
还有另一种情况：文件没问题，但Claude “认识命令却在执行时把它当成普通对话处理了”。这通常是是因为命令文件里的frontmatter格式写错了，比如description字段缺少冒号、或者用了中文冒号。YAML frontmatter解析严格，一旦解析失败，整个文件会被当正文处理。我的习惯是写完之后先快速看一眼frontmatter的格式是否有误，再做一次实际调用。
5.2 模板文件又长又复杂，Claude像“失忆”一样不遵守
这个问题我调试了很久才找到规律。原因在于：CLAUDE.md和命令文件虽然都被写进上下文，但当对话进行很多轮之后，早期注入的指令会逐渐被挤占注意力，模型开始只关注最近几轮的内容。典型表现是：用了30轮对话之后，它开始违背景景里“不要修改未提及文件”的指令。
解决方案有几个层次。轻量手段是：关键约束在模板里重复出现，例如在review.md和refactor.md里都写了“Don't modify”，重复的强化是有效的。更实用的做法是把任务拆短——一次对话只做一件事，不把太多步骤塞进同一个会话。我还尝试过用/memory命令把关键约束固化到会话级记忆里，在长会话场景下有一定作用。
如果任务确实很长（比如一整个模块的重构），建议拆步骤：先单独一次对话生成重构计划，确认后新开一个对话让Claude执行第一批改动，再新开对话执行第二批。虽然过程看起来略繁琐，但每一步的指令清晰度都大幅提升，质量反而更稳定。
5.3 权限放太宽：Claude Code“主动做”了不该做的事
默认情况下，Claude Code为了效率会倾向于自主行动，尤其是你放行了Edit(//)和一堆Bash命令之后。有次它执行git add * && git commit -m "refactor: update auth module"，实际上把三个无关的临时文件也加进去了——因为提交信息模板没有明确规定“只能提交和任务相关的文件”，它在“合理范围内”自行判断了。
这个问题的修法我在CLAUDE.md里加了明确指令：“Before staging files, rungit status --shortand verify that only files related to the task are staged。If unrelated files exist, do NOT stage them automatically。”加上这个之后，它每次提交前会主动做一次核对，误提交的概率基本归零。核心经验是：权限给得越宽，模板里的“行为边界”就要写得越细，用细节规则去约束自主性。
5.4 模板对性能没有提升：任务太难，什么模板都没用
最后得说点实在的。模板能解决的是“行为规范”问题，不是“能力上限”问题。如果一个任务本身超出了模型的能力边界，比如需要极其复杂的多文件跨层推理、需要大量领域知识且仓库上下文明显不够，那么模板写得再好，它也只能在错误答案里选一个“格式最漂亮的错误”。这种情况我的做法是不硬撑——模板块作为第一轮，把问题拆小，先让它完成“调查和方案”，再让有经验的开发者接手关键部分。AI工具的定位是把人从80%的事务性工作中解放出来，那剩下20%的深度判断，还是得靠人。
5.5 经验总结：三周模板化的前后效果对比
这三周用下来，不说虚的，质量变化最明显的是代码审查报告。之前全靠对话式审查，一次能找出两三个基本问题，还经常停留在代码风格层面；现在用/review模板，每次至少给出P0/P1级别的实质性问题，比如并发竞态、错误处理缺失、权限校验遗漏等。提交信息规范统一后，回看提交历史做版本回溯真的轻松很多，之前的提交记录基本无法一眼看懂改动意图。重构流程稳定性提升也很明显——之前借用AI重构，改完总有隐藏回归；现在按模板一步步执行、逐个文件测试，改完基本敢直接打包。
最后分享一个小技巧。模板库不是一次建完就完事的，至少要用两周再回头审视。第一个版本一定会有各种问题——有些规则是多余的、有些约束是模糊的、有些步骤的顺序不对。我每个模板都改了三轮以上，比如review.md第一版没有强制它只输出报告、不改代码，导致它总是“顺手修一下”，后来加上才真正稳定。迭代的方法很简单：每次运行命令后，如果你做了任何手动修正——改输出、调整范围、补指令——就打开对应的模板文件，把这个修正固化进去。模板不是写给机器看的说明，而是你工作方式的提炼。你希望它怎么干活，就用模板把它写下来，它就会一直用那个标准替你干活。
