如果你也和我一样每天打开 Claude Code 的第一件事就是把同一段角色设定、同一套审查要求、同一个输出格式再敲一遍那你大概率会在某一天突然问自己我到底是在用 AI 干活还是在替 AI 做填空题我大概是第三周的时候想明白这件事的。当时我每天要处理十几个代码审查请求每个请求我都要先输入你是一位资深工程师重点关注安全性和性能……再把 diff 粘进去最后还得补一句请用表格输出问题清单。这些话毫无信息量但每一条都占着上下文窗口。于是我把高频指令逐步沉淀成了一套 Claude Code 模板库也就是现在这个 claude-code-templates 项目。这套模板库不是什么惊天动地的工程但它确实把我从大量低质量、不稳定的重复会话里捞了出来。这篇博文就把整个设计过程、文件组织方式、模板原文和踩过的坑完完整整拆给你看适合那些已经在用 Claude Code、但总觉得每次对话结果都像开盲盒的朋友。1. 为什么我决定把 Claude Code 的常用指令全部模板化很多人有个误区Claude Code 这类工具是对话式的所以每次都应该自然语言聊天。但实际用起来你会发现对话式交互的最大问题不是能力不够而是结果方差太大。同一个问题今天问是详尽的 600 字报告明天问可能就变成 3 条敷衍的 bullet。这种不稳定很多时候并不怪模型而是因为你每次给的指令质量就不稳定。1.1 没做模板之前我的使用状态我先描述一下模板化之前的典型场景。早上一到工位打开终端我要审查一个 pull request。我的第一轮输入通常是帮我看一下这几个文件的改动重点看看有没有 bug还有代码风格怎么样。听起来没毛病但对 Claude Code 来说这句话里有大量信息缺失它不知道你要不要考虑安全性、不知道输出格式是什么、不知道风格指的是你们团队规范还是通用 PEP8、甚至不知道它有没有权限去查相关上下文。于是我往往要来回追问两三轮才能得到一份可用的审查报告。更痛苦的是那些重复性极高的任务。写单测、生成 git commit message、解释一段陌生代码、设计一个重构方案——这些任务本身高度标准化我却每次都重新临场组织语言。有一次我连着给三个不同项目生成了三份风格完全不一样的测试计划原因是三次表述里覆盖边界条件这个要求分别被我说成了测试别太水、分支覆盖超过 80%和把异常路径都照顾到。信息密度不同输出自然参差不齐。模板化的直接动机就是消灭这种重复决策。1.2 模板化的本质把临场发挥变成标准作业程序打个比方。做饭这件事普通人炒菜靠感觉放盐厨师做菜靠配方和克数。配方不是为了抹杀厨师的创造力而是为了保证一道菜在食材变化时依然稳定。Claude Code 模板的本质也一样把高频任务里的角色设定、检查维度、约束条件、输出格式提前固定下来让 AI 每次都在同一个起点上开始工作。不过这并不意味着把提示词写死。我设计的这套模板库始终保留了一个取舍原则模板负责稳定框架人负责提供变量。比如代码审查模板会固定审查维度但不会固定你要查哪个文件重构模板会固定设计原则但不会预设你项目的技术栈。这个度我一开始也没拿捏好后来翻过几次车才慢慢调整具体问题我在第 5 节单独讲。2. 模板库的文件骨架commands、CLAUDE.md 与 agents 怎么分工做模板库的第一步不是写内容而是决定这些模板放哪。Claude Code 支持三种不同的长期记忆载体很多人用了一两个月都没分清它们的职责导致模板要么堆在一起失效要么互相打架。我按自己的实践把它们整理成了三条清晰路径。2.1 三条存放路径各自解决什么问题第一条路径是项目根目录下的CLAUDE.md。我把它当成团队的通用上下文里面记录的是所有会话都需要知道的背景信息比如项目技术栈、目录结构、代码规范、测试命令、禁用事项。它不承担具体任务指令只负责让每一次对话从同一条基线出发。第二条路径是.claude/commands/目录。这里放的是高频单点任务模板每个 Markdown 文件对应一个斜杠命令。比如你建一个review.md就能在会话里直接输/review触发代码审查建一个commit-msg.md就能输/commit-msg生成提交信息。这是整个模板库里最常用、ROI 最高的一部分。第三条路径是.claude/agents/目录用来定义有固定人设的子代理。如果你有一个场景是需要数据库设计专家连续多轮参与方案讨论而不是一次性的指令那比起写个 command更适合定义成一个 agent。它的文件头带name和descriptionClaude Code 会在需要时自动选它出场或者你用schema-designer主动召唤。2.2 一套我实测下来很顺手的目录结构以下是我当前在用的目录布局你可以直接抄project-root/ ├── CLAUDE.md └── .claude/ ├── commands/ │ ├── review.md │ ├── refactor.md │ ├── test.md │ ├── commit-msg.md │ └── bug-analysis.md └── agents/ ├── schema-designer.md └── security-auditor.md命名上我建议全部用短横线小写因为斜杠命令的补全体验对-最友好。每个 command 文件内部我统一用front matter 正文的结构front matter 里写description用来告诉 Claude Code 这个命令是干什么的也可以在需要时声明允许使用的工具。这种组织方式对个人和小团队都够用最重要的是别人 clone 仓库后不需要任何额外配置全部约定自动生效。3. 四段式模板语法角色、任务、约束、输出格式怎么拆模板文件不是越长越好。我把过去几百次对话里效果明显好和效果明显差的提示词放在一起对比发现所有高质量指令都具备四个共同模块。我把它叫四段式身份与视角、任务与范围、约束与禁区、输出格式。下面用一个完整模板演示。3.1 一个可以直接抄的代码审查模板我在.claude/commands/review.md里写的就是下面这段--- description: 对当前工作区改动执行代码审查聚焦逻辑、性能与安全隐患 --- 你是一名有 10 年经验的软件工程师擅长从代码可维护性、性能隐患、安全隐患三个维度审查代码。 任务 1. 分析当前工作区未提交的 git diff如果 diff 过大则优先审查本次新增文件。 2. 检查逻辑正确性错误处理是否完备边界条件是否覆盖并发场景是否有竞态风险。 3. 检查性能隐患是否存在明显低效的循环、不必要的重复查询、可以合并的 IO 操作。 4. 检查安全隐患用户输入是否经过校验是否需要权限校验是否使用不安全的拼接方式。 约束 - 只报告你有把握的问题禁止臆测。 - 不要修改代码只输出审查意见。 - 所有问题必须给出文件路径和建议改法。 输出格式 ### 审查结论 一句话总结本次改动整体质量。 ### 问题清单 | 严重度 | 文件 | 位置 | 问题描述 | 修改建议 | |--------|------|------|----------|----------|这段模板看起来并不复杂但它关键的细节都在模块分工上。身份段把审查视角锚定在十年经验软件工程师并且明确说只关注三个维度这样 AI 就不会在格式美观这种无关维度上浪费注意力。任务段给了明确的动作顺序先看什么再看什么。约束段最重要——只报告有把握的问题直接抑制了 AI 最常见的表现为了显得勤奋而列一堆无关痛痒的 suggestion。输出段用表格强制结构化方便我快速扫视严重度和文件路径。3.2 变量与占位符的使用技巧模板里最忌讳写死细节。我写重构方案模板的时候一开始直接写了针对 Python 项目建议引入类型注解……后来给一个 JavaScript 项目用的时候就尴尬了。现在的做法是模板里写条件式分支让 AI 自己判断。比如任务 1. 分析当前重构目标。 2. 如果项目使用静态类型语言如 Python、TypeScript重点检查类型设计的合理性。 3. 如果项目是动态弱类型语言重点关注运行时错误是否可能被掩盖。你也可以用{{变量}}的形式预设填空位但我个人的经验是给填空位提供默认值和候选值比单纯挖空更好用。比如生成 commit message 的模板里我会写提交类型可用feat / fix / refactor / docs / test这样用户只需要做选择题不用凭空想词。4. 按使用频率沉淀下来的场景模板清单模板库最怕做成什么都想覆盖的大杂烩。我筛选模板的唯一标准是过去两周我是否在这个任务上重复发力超过三次。下面是我最终保留下来、并且每天都在用的模板清单按使用频率从高到低排列。4.1 高频三件套审查、测试、提交最高频的三个命令是/review、/test、/commit-msg。/review上面已经给了全文。/test的模板核心是强制 AI 先列测试计划再动手写用例并且要求对每个测试用例标注它覆盖的业务逻辑我看到结构化的测试计划之后再来决定要不要执行。/commit-msg则是我自己最得意的模板它会把git diff的统计信息先读一遍然后按 conventional commits 规范生成 3 个候选提交信息再让我选。用过这个之后我几乎再也没手写过提交信息。这三个模板之所以高频是因为它们都有一个共同特征输入容易获得、输出格式明确。代码审查只需要工作区有 diff测试生成只需要选中目标文件提交信息只需要有 git 暂存区。模板设计要尽量满足这个规律——让 AI 能在最少的人工补充下完成工作否则调用者会嫌麻烦而放弃。4.2 中频场景重构方案、Bug 根因分析、技术方案设计/refactor、/bug-analysis、/design属于中频模板。它们比高频三件套更需要交互重构方案往往要确认目标边界Bug 分析需要喂错误日志技术方案设计则需要更充分的背景信息。所以这些模板的写法不同我在里面刻意留下追问引导。比如/bug-analysis模板里有一段先不做任何猜测。第一步列出你理解的问题表象。 第二步列出你需要的诊断信息清单日志、复现步骤、环境变量等。 第三步在用户提供信息后按可能性从高到低给出三个假设并用排除法验证。这是我跟模板化之前最明显的区别以前的我会直接问这个 bug 怎么回事AI 也真的会直接就猜现在模板逼着它先列信息清单我照着清单喂数据根因定位的成功率大幅提升。4.3 低频但值得沉淀Git 历史梳理、代码转文档、API 评审低频模板我目前留了三个/git-story用来梳理一段混乱的 Git 历史并输出给团队看的变更说明/docs-from-code负责把一段没有注释的业务代码转成结构清晰的技术文档/api-review用来对接口设计做评审重点检查 RESTful 风格、错误码设计、幂等性和兼容性。低频模板的 ROI 跟高频不同它不追求每天被调用而是追求半年后需要时能一键得到及格线以上的结果。所以这类模板我会写得稍微保守一些输出模板也是确定性最高的那种。我把完整的场景模板清单整理了一下命令触发场景模板核心模块维护频率/review审查代码改动三维审查 问题表格季度/test生成/补全单测测试计划先行季度/commit-msg生成提交信息规范约束 候选半年/refactor制定重构方案边界确认 原则约束季度/bug-analysis排查线上/本地 bug信息清单 假设排除季度/design输出技术方案方案结构 取舍记录季度/git-story梳理 git 历史时间线 变更说明半年/docs-from-code代码转文档读者对象 结构模板半年/api-review接口设计评审风格/错误码/兼容性长期这个表格本身也值得定期回看——当某一行长期不再被使用我就会把它删掉避免模板库变成无人维护的废弃代码。5. 实测翻过车的四个模板设计错误与修正方法这套模板库不是一次成型的。我前前后后改了大概五轮有四个错误特别典型如果你正准备起步建自己的 Claude Code 模板库这四个坑大概率也会遇到。5.1 第一个坑模板太长上下文被无关内容占满我第一次写审查模板时为了让结果更专业塞进了大量背景说明项目历史、团队规模、历史遗留问题、甚至公司规范。写出来 800 多字结果实际使用效果非常奇怪——Claude Code 很认真地执行了模板末尾的输出格式但开头要求的审查深度反而被稀释了有时候给出的建议明显是泛泛而谈。后来我意识到模板不是论文它不需要说服 AIAI 也不需要通过阅读长文来建立信任。修正方案是背景信息从模板里剥离全部放进 CLAUDE.md。模板里只保留角色、任务、约束、输出格式这四件事。现在我的每个 command 模板基本都能控制在 300 到 500 字之间。命令文件重点在于聚焦指令项目背景这种长期不变的上下文交给 CLAUDE.md两者各司其职上下文窗口的压力也小很多。5.2 第二个坑过度约束把 AI 变成复读机第一次把模板发给同事用收到的反馈是这东西太机械了。我复盘了一下发现早期我追求确定性走到极端把执行步骤写到了指令级第一步读文件、第二步提取函数列表、第三步逐函数分析、第四步核对错误处理……Claude Code 确实按步骤执行了但也确实变成了复读机——遇到没有预料到的场景它不会变通只会硬套步骤。这里的问题在于我把约束和控制混淆了。约束应该界定边界比如不要修改代码只报告确定的问题但控制是规定 AI 的每一个动作。后来我把很多强制性步骤换成了目标式描述确保所有公开函数都有错误处理路径而不是检查第 3 步中列出的所有函数是否包含 try-catch。这样既保留了检查的目标也给了它根据实际情况调整路径的空间。5.3 第三个坑占位符滥用模板变成填空题做模板库的人很容易陷入一种冲动什么都要参数化。我一度在模板里塞满了{{项目名}}、{{技术栈}}、{{目标模块}}、{{团队成员}}……结果每次调用前先做五分钟填空题比直接手写提示词还累两三天我就烦了。后来我给自己定了一条规则一个命令模板最多允许三个占位符而且必须至少提供一个候选值。比如文档转换模板里我允许用户指定读者对象但默认值是新加入项目的开发工程师。大多数情况下直接回车就能用只有确实遇到特殊场景才填空。模板应该降低启动成本而不是增加使用成本。5.4 第四个坑模板不维护半年后自己都不想用模板库最隐蔽的成本是维护。技术栈会升级、团队规范会变化、项目目录会重构模板里如果写了具体的文件路径或过时的流程轻则输出失效重则给出误导性建议。我曾因为一个/refactor模板里还写着旧测试框架的命令导致 AI 连续三次生成根本无法执行的测试方案。修正这个问题的唯一办法是主动淘汰。我现在每个季度会花半天时间专门过一遍模板库检查还有多少命令在用、模板里有没有过时的技术名词、输出格式是否需要调整。平时调用时的直觉很重要——每次使用后如果你觉得这个结果差点意思不要顺手改对话而是回去改模板。一个模板如果连续三次让你有这种感觉它就该进回收站了。6. 模板库从个人到团队复用机制与持续维护当个人模板库稳定之后自然会产生一个想法让团队一起用。这里面的坑比个人使用还要多一些最大的问题不是技术而是所有权。6.1 团队复用的前提每个模板必须有一个 Owner模板放进团队仓库并不难难的是维护责任落在谁头上。如果没有指定 Owner半年后必然出现这种情况A 改了一版审查模板B 觉得不合适又改回去C 干脆自己建了私有的 review 命令。我把自己的模板分享给团队时特意在每个文件的 front matter 里加了一个maintainer字段。这个字段不是为了做权限控制而是为了让所有人都知道有意见找这个人不要自己动手改公共文件。建议团队里先让最积极用 Claude Code 的那个人当第一任 owner等他离职或兴趣减退了再移交。Owner 的核心职责只有两件事响应同事的反馈、每季度做一次模板体检。6.2 模板库必须配 README否则就是摆设一个没有任何说明的模板库对团队成员来说就是一排看不懂名字的文件。我在仓库根目录维护了一份 README内容包括每个命令是干什么的、使用前需要准备什么、输出的样子是什么、常见问题怎么处理。这部分工作虽然不起眼但它是团队采纳率的分水岭。我的观察是有 README 的模板库同事约两周后能自己频繁使用没有 README 的模板库基本只会被两三个积极分子当私货使用。6.3 度量模板效果别只凭感觉最后聊一个很多人忽略的事情模板的效果是可以被量化的。我自己用的最粗暴有效的指标有三个模板被调用的频率、输出被直接采纳而不是大幅修改的比例、用户是否在模板输出的基础上二次追问。第二个指标尤其重要如果每次执行完模板会话还要追问三四轮说明模板质量不合格要回去补约束条件。第三指标则是反向信号如果用户从不追问也不一定代表模板好可能是因为输出太差以至于懒得救了。我个人的习惯是每个月扫一眼命令历史把高频命令的表现列成一张小表然后针对性地调整。模板库这个东西真正麻烦的不是搭起来而是让它在你和团队的日常工作中持续产生价值。到现在我也没有完全满意的版本但比起最早那个每天重复敲指令的状态这套 claude-code-templates 已经帮我省下了大量重复劳动。它给了我一个很实际的启示Claude Code 的能力上限固然重要但你能不能让它的每次输出都被稳稳地接住往往取决于你有没有认真设计那些放在.claude目录里的小文件。