你有没有遇到过这种场景在Claude Code里想让它做一个代码审查于是把“请检查这段代码的安全性、性能、可读性最后给出修改建议”这句话从头到尾敲一遍下一次想让写单元测试又得重新组织一段需求描述再过几天做重构又得小心翼翼的给模型塞一堆上下文生怕它理解偏了。这就是我为什么要整理一套claude-code-templates的原因。简单说它是一组结构化的提示词模板和配套脚本把高频的编码场景——代码生成、审查、重构、调试、文档撰写、测试编写——固化成可以直接复用的文件。你不再需要每次手动“喂”指令只要引用对应模板Claude Code 就会按照预设的步骤、约束条件和输出格式工作。这套东西对我这种高频使用 CLI 编程助手的人来说省下的不光是打字时间更重要的是让每一次交互的输出质量变得更稳定。如果你是刚接触 Claude Code 想提升效率的开发者或者正在团队里推广规范化 AI 编程流程的人这篇内容就是为你准备的。1. 为什么需要一套 claude-code-templates1.1 裸用 Claude Code 的三个痛点我刚开始用 Claude Code 的时候效率其实并不高。虽然它能直接读文件、跑命令、改代码但我总是陷入同一种循环指令写得太模糊模型理解不到位我要反复补充说明指令写得详细又会占掉大量对话上下文聊不了几轮就感觉它“忘事”了。第一个痛点是上下文碎片化。每次任务的目的、约束、输出格式都散落在对话里Claude Code 需要从历史消息中自行拼凑意图。一旦任务做到一半中断下次重新开会话之前的所有设定全部作废。第二个痛点是输出不稳定。同样是让写单元测试今天它给你 pytest明天给你 unittest后天又给你写了一个奇怪的自定义断言框架完全取决于对话上下文和模型状态。第三个痛点是团队协作无标准。你审代码的标准和同事审代码的标准可能完全不一样最后产出的审查结论、修改建议、代码风格全都五花八门根本没法沉淀成团队经验。这三个痛点本质上都是同一个问题编程助手的“工作方式”没有被显式定义。而模板就是把这个“工作方式”从脑海里、对话里搬到文件里、版本控制里。1.2 模板化的核心理念把不可控变得可控我设计 claude-code-templates 时遵循的核心思路很简单先定义输入再定义处理流程最后约束输出。这和传统软件开发里的“接口约定”非常像。模板就是你和 Claude Code 之间的接口它告诉模型你接下来要接收什么信息、按照什么顺序思考、最终交付什么格式的结果。举个例子我写代码审查模板的时候不是简单写一句“请审查代码”。而是先告诉它“你是一名有 10 年经验的后端架构师关注安全性、性能、可维护性三个维度”。再告诉它处理流程“先梳理代码逻辑再逐项检查最后按‘问题严重级别 建议修改方案’的格式输出”。最后约束输出“每个问题必须给出对应的文件路径和行号建议修改代码用 diff 格式展示”。这样做有个额外的好处模板本身是可测试的。当我发现某个模板输出效果不好我可以单独调它的措辞和步骤而不用重新构建整个对话。我甚至可以维护多个版本的模板针对不同项目类型做微调。时间久了模板库就成了一个私人经验库也可能成为团队的最佳实践库。2. 模板仓库的整体架构2.1 目录结构与命名规范claude-code-templates 的目录结构是我反复调整过的最终稳定成了下面这样claude-code-templates/ ├── CLAUDE.md ├── templates/ │ ├── generate/ │ │ ├── generate_feature.md │ │ ├── generate_script.md │ │ └── generate_api.md │ ├── review/ │ │ ├── review_code.md │ │ ├── review_security.md │ │ └── review_pr.md │ ├── refactor/ │ │ ├── refactor_small.md │ │ └── refactor_module.md │ ├── debug/ │ │ ├── debug_error.md │ │ └── debug_perf.md │ ├── test/ │ │ ├── test_unit.md │ │ └── test_integration.md │ └── docs/ │ ├── docs_api.md │ └── docs_readme.md ├── scripts/ │ ├── apply_template.py │ └── list_templates.py └── examples/ ├── review_example.md └── generate_example.md每个模板文件都采用小写加下划线的命名方式目录则按任务类型划分。文件名本身就是一个长尾关键词比如review_security.md一眼就能看出来是“安全审查专用”在会话里用templates/review/review_security.md引用的时候非常直观不需要记忆任何编号。2.2 模板内部的核心组成四个固定区段每一个模板文件我建议都包含四个区段。这四个区段不是随便分的而是为了让模型的理解成本降到最低。第一个是角色区段。直接定义“你是谁”比如“你是资深 Go 语言工程师熟悉并发编程和性能调优”。这看似简单但对输出质量影响极大。角色设定越具体模型调用的知识领域就越聚焦回答也更符合预期。第二个是变量区段。这是模板里最灵活的部分通常会列出本次任务需要填充的关键信息。例如代码审查模板可能约定以下变量变量名含义示例$SCOPE审查范围src/auth/$FOCUS重点关注问题并发安全$OUTPUT_FORMAT输出格式markdown第三个是流程区段。用有序列表写明执行步骤。我会刻意选用“先…再…最后…”这类带有强顺序感的表达让模型严格按步骤推进。第四个是约束区段。用“不要”“必须”“如果…否则…”这类条件句式把边界情况说清楚。比如“不要提出无法落地的建议每个修改必须给出具体代码示例”就是一个非常有效的约束。2.3 为什么选择 Markdown 而不是 JSON 或 YAML可能有人会问既然模板是给程序用的为什么不用结构化更强的 JSON 或 YAML我在第一版也试过 JSON后来推翻了。原因有两条。第一Claude Code 的上下文加载方式偏好纯文本。模型对自然语言的解析能力远超对嵌套结构的解析能力。一段优雅的 Markdown 文字可以直接原样作为指令注入而 JSON 还需要在模型心里先“反序列化”一遍反而增加了理解负担。第二Markdown 的可维护性最好。模板不仅要给 Claude Code 看还要给团队成员看。JSON 写注释不方便YAML 缩进敏感而 Markdown 可以自然地插入标题、表格、引用块、示例代码人看起来不累模型看起来也友好。我甚至会在模板里直接放一段“参考示例”代码块告诉模型“这就是我想要的输出格式”。这是纯 JSON 结构很难做到的。3. 上手实操从零搭建并使用模板3.1 初始化模板仓库我上手的第一步是用 Git 初始化模板仓库这样可以随时回滚模板的改动。执行命令如下mkdir claude-code-templates cd claude-code-templates git init git remote add origin 你的远程仓库地址然后在根目录创建CLAUDE.md。这个文件在真实项目里是 Claude Code 的“记忆锚点”每次会话开始它都会自动读取。我写的 CLAUDE.md 内容很短主要是告诉 Claude Code “本仓库是一套模板库当用户要求应用某个模板时先读取对应文件并按其中的规则执行”。3.2 编写第一个代码审查模板接下来直接写一个真实能用的模板。打开templates/review/review_code.md我会填入如下内容# 代码审查模板 你是一名资深软件工程师拥有多年架构设计和代码审查经验。本次审查请你保持客观、严谨所有结论必须基于代码事实。 ## 任务输入 - 审查对象{{ FILES }} - 审查重点{{ FOCUS }} - 输出语言{{ LANGUAGE }} ## 审查流程 1. 先通读代码梳理核心逻辑和模块边界用自己的话简述这段代码是做什么的。 2. 从以下维度逐项检查 - 正确性是否存在边界条件处理不当、逻辑遗漏、隐式类型转换错误。 - 安全性是否有注入风险、敏感信息泄露、越权访问、不安全的资源释放。 - 性能是否存在不必要的循环嵌套、重复计算、无索引查询、大对象常驻内存。 - 可维护性命名是否清晰、函数是否过长、是否有重复代码、是否有注释过度或缺失。 3. 对发现的问题排序严重问题在前轻微问题在后。 ## 输出格式 使用 Markdown 表格输出包含以下列问题等级、问题描述、文件与位置、复现路径、修改建议。 ## 约束 - 只能基于提供的代码内容做审查不要臆测代码之外的业务逻辑。 - 不要提交琐碎且无实际意义的风格修改聚焦逻辑问题。 - 每条建议必须附带可执行的修改方案不能只说“建议优化”却不给具体办法。 - 如果没有发现问题请明确说明“未发现明显问题”不要强行编造。这个模板具备了前面说的四个区段。使用的时候我只需要在 Claude Code 会话中输入类似这样的指令请应用 templates/review/review_code.md 模板。 审查对象src/auth/login.go 审查重点并发安全和输入校验 输出语言中文3.3 写一个代码生成模板刻意强调约束代码生成模板和审查模板有所不同因为生成类任务最容易失控必须把约束写得非常具体。我的templates/generate/generate_feature.md是这么设计的# 功能开发模板 你是一名精通 TypeScript 和 Node.js 的全栈工程师。请严格按照以下要求实现一个新功能。 ## 功能描述 - 功能名称{{ FEATURE_NAME }} - 需求细节{{ REQUIREMENTS }} - 技术栈{{ STACK }} - 目标文件{{ TARGET_FILES }} ## 实现步骤 1. 先分析需求列出至少 3 个关键边界条件和异常场景。 2. 设计模块结构和对外 API确认数据流方向。 3. 编写实现代码代码必须包含类型定义。 4. 为关键函数编写简短的 JSDoc 注释。 5. 最后用 3 个测试用例验证核心逻辑。 ## 输出要求 按以下顺序输出 1. 边界条件分析 2. 模块结构设计 3. 核心代码 4. 测试用例 ## 硬性约束 - 不要添加任何与需求无关的代码。 - 不要使用any类型必须显式定义类型。 - 所有外部输入必须做校验不允许直接信任传入数据。 - 代码中禁止出现魔法数字常量必须定义并注释含义。你可以看到生成模板和审查模板的结构框架相同但约束密度大幅提高。这背后的经验是生成类任务模型偏向自由发挥审查类任务模型偏向谨慎保守。所以模板要根据任务类型动态调整约束强度。3.4 在 Claude Code 会话中加载模板的实际体验加载模板的方式我强烈建议用引用直接拼接文件内容而不要靠对话里的记忆。原因很简单Claude Code 的每次会话都有上下文窗口上限如果你在对话中手动复制粘贴模板那么模板本身就会占用大量 token而通过引用文件内容会以更结构化的方式进入上下文节省下来的 token 可以留给代码分析和长对话。实际操作起来是这样的。我先进入项目目录运行claude命令启动会话然后在第一轮消息里这样写templates/review/review_code.md 应用此模板。 审查对象src/utils/sort.ts 审查重点排序算法的正确性和边界条件这样 Claude Code 会优先读取review_code.md并按照模板里的流程执行。我会刻意在开头的第一句就提供“审查对象”和“审查重点”因为变量区段必须在模板输入的同一轮里补齐不要等到第二轮再补那样模型容易丢失指令的关联性。4. 模板设计避坑指南4.1 上下文窗口与 token 预算模板不是越长越好。我见过很多人写模板恨不得把整个团队规范都塞进去最终效果反而很差。原因在于 Claude Code 的上下文窗口是有限的模板占得越满留给实际代码和后续对话的空间就越小。尤其是处理大型代码文件时如果模板消耗了太多 token模型甚至可能没有足够空间读取完整文件。我的经验是单个模板尽量控制在 500 字以内。因为模板里要装的是“思考框架”和“约束边界”而不是长篇大论的业务背景。业务背景应该由用户在变量区段里提供。另外模板里尽量少贴大段示例代码一个简短的 5 到 10 行示例就足够说明输出格式了再多就是浪费。4.2 避免模板和项目规则冲突第二个容易踩的坑是模板里的约束和项目根目录下CLAUDE.md里的项目规则互相矛盾。比如项目的 CLAUDE.md 里规定“所有提交必须通过 lint 检查且遵循 Prettier 格式”而模板却要求“不要关注代码风格”。这种冲突会让模型产生行为分裂。我的处理原则是项目 CLAUDE.md 是最高优先级模板不能与之冲突。如果模板想强调某个特殊要求就用“在满足项目规范的前提下额外注意以下内容”这种兼容性表达。例如我会在代码生成模板里加一句“代码风格遵循项目 CLAUDE.md 约定如果项目未约定则使用常规社区标准。”这样既保留了模板的约束力又不会覆盖项目规则。4.3 测试模板像测试代码一样测模板模板更新后一定要测试不要想当然。我自己的做法是准备一个专门examples目录里面放了每组模板对应的“输入样例”和“期望输出样例”。比如review_example.md会放一段有明显缺陷的代码加上一份我心中比较理想的审查结果。每次改模板后我会用这个样例重新跑一遍对比新输出和期望输出确认没有跑偏。如果输出差得很远我会微调模板措辞再跑一遍。这个循环虽然有点花时间但长期非常划算。因为模板一旦在团队里推广出错成本远高于调模板的时间成本。我也建议把模板文件纳入代码评审流程改模板必须说明测试结果。这能防止团队里出现“谁都能改模板改完就有人遭殃”的混乱状态。5. 常见问题与排查技巧实录5.1 模板没生效怎么办我遇到最频繁的问题是明明在会话里引用了模板但 Claude Code 完全不按模板执行。排查这个问题的第一步是确认你引用文件路径是否正确。路径写错是最常见的低级错误。第二步是检查CLAUDE.md和模板文件是否有互相矛盾的内容如果有模型往往会倾向遵循项目级规则而忽略模板。第三步是看引用方式建议把引用放在对话第一句如果混在长段落中间模型可能把它当成普通文本而不是指令。这里有一个更隐蔽的原因模型像人类一样会选择性忽略重复出现的提示。如果你在同一会话里反复引用同一模板到第三次之后模型可能只记得前半部分。所以我的习惯是每个会话只引用一次模板后续说“继续按模板规则执行”就好不要重复粘贴模板全文。5.2 模板输出质量不稳定的原因如果你发现同一个模板、同一个输入两次输出却差异很大多半问题出在变量区段描述不完整。比如代码审查模板关于“审查重点”的变量如果我只写“性能”模型可能理解为笼统概述如果我写“重点检查数据库查询次数、循环中的同步调用、大文件的内存占用”输出就会精准得多。另一个原因是模板里的流程步骤不够具体。检查一下你是否用了“考虑”这类模糊动词比如“考虑代码安全性”。这种表达给模型的自由度过大。改成“检查代码中是否存在 SQL 注入、XSS、反序列化风险”后效果立刻不同。模板的本质是缩小模型的搜索空间而不是增加它的想象空间。5.3 团队协作时的模板维护技巧团队共用一套模板时最怕文件混乱。我的经验是用版本控制加分支管理。模板文件不要散落在某个人的本地环境要统一放在项目仓库里通过 PR 更新。更新模板时目录命名必须有明确的用途不允许出现template_v2_final.md这类命名文件一旦归档就用语义化命名。同时我建议在模板仓库里维护一份变更日志记录每一版模板改动的原因和效果。比如“review_code.md v2增加了对并发安全问题的检查因为 v1 经常漏掉。”这些经验记录比代码本身更有价值下次忘了当初为什么加这条约束看日志就能想起来。下面整理一个表格把常见问题快速过一遍问题现象常见原因排查与修复模板完全没生效引用路径错误、指令被淹没检查路径把指令放在会话第一句输出不符合模板要求变量描述不清晰补充更具体的 FOCUS、SCOPE模型行为与项目规则冲突模板与 CLAUDE.md 冲突统一优先级兼容表述模板输出内容过长约束不足、示例代码过多增加“不要输出”约束精简示例同一模板多次使用后失效上下文被其他内容稀释新会话重新引用模板模板里的中文表达被误解使用模糊动词改用明确动词列出具体检查项6. 进阶扩展让模板自动跑起来6.1 搭配脚本快速调用模板手动引用模板虽好但每次都敲“应用某个模板加参数”也很重复。我给 claude-code-templates 配了一个极小的 Python 脚本apply_template.py作用是把参数填进模板并输出最终指令。他的实现逻辑不复杂核心是读模板文件找到{{ VAR }}占位符用命令行参数替换然后打印最终指令。你可以像这样使用python scripts/apply_template.py templates/review/review_code.md \ --replace FILESsrc/auth/login.go \ --replace FOCUS并发安全 \ --replace LANGUAGE中文脚本输出结果后我再手动复制到 Claude Code 会话里。如果你用的是支持管道的终端工具甚至可以直接把脚本输出拼接到claude命令的启动参数中。这个自动化程度对个人使用已经足够不需要引入复杂框架。6.2 用 Git 管理模板版本模板一旦成为团队共识就必须有可追溯性。所有模板都放进同一个 Git 仓库用分支开发、PR 合并。每次更新模板时标题栏注明更新人、日期、动机。这能解决我实际遇到过的“某天模板变差了但不知道是谁改的”这个难题。Git 历史和 blame 功能可以定位到具体改动原因。我给模板仓库配置了轻量的测试路径examples目录放样例Git 钩子里跑一个简单的 diff 检查看模板改动后能否生成合法输出。说到 Git 钩子我建议至少加一个pre-commit钩子阻止文件名中出现final、_v2这类字眼强制性保证命名规范。6.3 在 CI 中复用模板更进一步的玩法是把模板接入 CI 流程。比如在每次代码合并前用代码审查模板自动跑一轮静态审查。做法是写一个 GitHub Actions 或 GitLab CI 任务在流水线里调用脚本生成审查指令再把 Claude Code 的输出作为评论发到 PR 上。需要提醒的是这种情况必须做召回保护不要让模型直接修改代码并提交。CI 里的模板只负责分析和建议不负责动代码。把这个约束写进模板的“约束区段”后整体安全性会提高很多。除此之外我还在实验室里试过用模板自动生成 API 文档把接口代码和模板拼接起来让模型按统一格式输出文档。这个场景特别适合模板化因为文档结构天生标准化模板能极大消除文档风格漂移的问题。我个人在实际操作中一个很受用的体会是模板的价值不在“写了什么表面文字”而在“它的约束有没有把你的质量标准真正传递给模型”。我踩过最多次的坑是以为模板写得足够清楚结果模型的输出还是飘。后来我养成了一个习惯每次写模板后我会故意在样例里埋几个不易发现的逻辑错误然后跑一遍模板看它的审查能力是否真的按我设计的节奏走。这套验证思路比读多少篇“提示词工程教程”都管用。最后再分享一个我自己经常用的小技巧在模板的设计上我往往会保留一个“反馈变量”例如在审查模板里让模型以“本次审查有什么无法确定的信息”作为收尾。这个收尾项看起来简单实际上能让模型主动暴露信息盲区你会发现由此产生的追问质量非常高。下一次使用这个模板的时候你也就知道自己该提前补什么内容了。如果你也在用 Clcode Code 处理复杂工程任务真的建议给自己搭一套模板它可能是你投入产出比最高的一次工程化尝试。 
长河君 · 2026/10/17 5:21:59 · 阅读 1.2k Claude Code提示词模板库：固化代码审查与生成流程
你有没有遇到过这种场景在Claude Code里想让它做一个代码审查于是把“请检查这段代码的安全性、性能、可读性最后给出修改建议”这句话从头到尾敲一遍下一次想让写单元测试又得重新组织一段需求描述再过几天做重构又得小心翼翼的给模型塞一堆上下文生怕它理解偏了。这就是我为什么要整理一套claude-code-templates的原因。简单说它是一组结构化的提示词模板和配套脚本把高频的编码场景——代码生成、审查、重构、调试、文档撰写、测试编写——固化成可以直接复用的文件。你不再需要每次手动“喂”指令只要引用对应模板Claude Code 就会按照预设的步骤、约束条件和输出格式工作。这套东西对我这种高频使用 CLI 编程助手的人来说省下的不光是打字时间更重要的是让每一次交互的输出质量变得更稳定。如果你是刚接触 Claude Code 想提升效率的开发者或者正在团队里推广规范化 AI 编程流程的人这篇内容就是为你准备的。1. 为什么需要一套 claude-code-templates1.1 裸用 Claude Code 的三个痛点我刚开始用 Claude Code 的时候效率其实并不高。虽然它能直接读文件、跑命令、改代码但我总是陷入同一种循环指令写得太模糊模型理解不到位我要反复补充说明指令写得详细又会占掉大量对话上下文聊不了几轮就感觉它“忘事”了。第一个痛点是上下文碎片化。每次任务的目的、约束、输出格式都散落在对话里Claude Code 需要从历史消息中自行拼凑意图。一旦任务做到一半中断下次重新开会话之前的所有设定全部作废。第二个痛点是输出不稳定。同样是让写单元测试今天它给你 pytest明天给你 unittest后天又给你写了一个奇怪的自定义断言框架完全取决于对话上下文和模型状态。第三个痛点是团队协作无标准。你审代码的标准和同事审代码的标准可能完全不一样最后产出的审查结论、修改建议、代码风格全都五花八门根本没法沉淀成团队经验。这三个痛点本质上都是同一个问题编程助手的“工作方式”没有被显式定义。而模板就是把这个“工作方式”从脑海里、对话里搬到文件里、版本控制里。1.2 模板化的核心理念把不可控变得可控我设计 claude-code-templates 时遵循的核心思路很简单先定义输入再定义处理流程最后约束输出。这和传统软件开发里的“接口约定”非常像。模板就是你和 Claude Code 之间的接口它告诉模型你接下来要接收什么信息、按照什么顺序思考、最终交付什么格式的结果。举个例子我写代码审查模板的时候不是简单写一句“请审查代码”。而是先告诉它“你是一名有 10 年经验的后端架构师关注安全性、性能、可维护性三个维度”。再告诉它处理流程“先梳理代码逻辑再逐项检查最后按‘问题严重级别 建议修改方案’的格式输出”。最后约束输出“每个问题必须给出对应的文件路径和行号建议修改代码用 diff 格式展示”。这样做有个额外的好处模板本身是可测试的。当我发现某个模板输出效果不好我可以单独调它的措辞和步骤而不用重新构建整个对话。我甚至可以维护多个版本的模板针对不同项目类型做微调。时间久了模板库就成了一个私人经验库也可能成为团队的最佳实践库。2. 模板仓库的整体架构2.1 目录结构与命名规范claude-code-templates 的目录结构是我反复调整过的最终稳定成了下面这样claude-code-templates/ ├── CLAUDE.md ├── templates/ │ ├── generate/ │ │ ├── generate_feature.md │ │ ├── generate_script.md │ │ └── generate_api.md │ ├── review/ │ │ ├── review_code.md │ │ ├── review_security.md │ │ └── review_pr.md │ ├── refactor/ │ │ ├── refactor_small.md │ │ └── refactor_module.md │ ├── debug/ │ │ ├── debug_error.md │ │ └── debug_perf.md │ ├── test/ │ │ ├── test_unit.md │ │ └── test_integration.md │ └── docs/ │ ├── docs_api.md │ └── docs_readme.md ├── scripts/ │ ├── apply_template.py │ └── list_templates.py └── examples/ ├── review_example.md └── generate_example.md每个模板文件都采用小写加下划线的命名方式目录则按任务类型划分。文件名本身就是一个长尾关键词比如review_security.md一眼就能看出来是“安全审查专用”在会话里用templates/review/review_security.md引用的时候非常直观不需要记忆任何编号。2.2 模板内部的核心组成四个固定区段每一个模板文件我建议都包含四个区段。这四个区段不是随便分的而是为了让模型的理解成本降到最低。第一个是角色区段。直接定义“你是谁”比如“你是资深 Go 语言工程师熟悉并发编程和性能调优”。这看似简单但对输出质量影响极大。角色设定越具体模型调用的知识领域就越聚焦回答也更符合预期。第二个是变量区段。这是模板里最灵活的部分通常会列出本次任务需要填充的关键信息。例如代码审查模板可能约定以下变量变量名含义示例$SCOPE审查范围src/auth/$FOCUS重点关注问题并发安全$OUTPUT_FORMAT输出格式markdown第三个是流程区段。用有序列表写明执行步骤。我会刻意选用“先…再…最后…”这类带有强顺序感的表达让模型严格按步骤推进。第四个是约束区段。用“不要”“必须”“如果…否则…”这类条件句式把边界情况说清楚。比如“不要提出无法落地的建议每个修改必须给出具体代码示例”就是一个非常有效的约束。2.3 为什么选择 Markdown 而不是 JSON 或 YAML可能有人会问既然模板是给程序用的为什么不用结构化更强的 JSON 或 YAML我在第一版也试过 JSON后来推翻了。原因有两条。第一Claude Code 的上下文加载方式偏好纯文本。模型对自然语言的解析能力远超对嵌套结构的解析能力。一段优雅的 Markdown 文字可以直接原样作为指令注入而 JSON 还需要在模型心里先“反序列化”一遍反而增加了理解负担。第二Markdown 的可维护性最好。模板不仅要给 Claude Code 看还要给团队成员看。JSON 写注释不方便YAML 缩进敏感而 Markdown 可以自然地插入标题、表格、引用块、示例代码人看起来不累模型看起来也友好。我甚至会在模板里直接放一段“参考示例”代码块告诉模型“这就是我想要的输出格式”。这是纯 JSON 结构很难做到的。3. 上手实操从零搭建并使用模板3.1 初始化模板仓库我上手的第一步是用 Git 初始化模板仓库这样可以随时回滚模板的改动。执行命令如下mkdir claude-code-templates cd claude-code-templates git init git remote add origin 你的远程仓库地址然后在根目录创建CLAUDE.md。这个文件在真实项目里是 Claude Code 的“记忆锚点”每次会话开始它都会自动读取。我写的 CLAUDE.md 内容很短主要是告诉 Claude Code “本仓库是一套模板库当用户要求应用某个模板时先读取对应文件并按其中的规则执行”。3.2 编写第一个代码审查模板接下来直接写一个真实能用的模板。打开templates/review/review_code.md我会填入如下内容# 代码审查模板 你是一名资深软件工程师拥有多年架构设计和代码审查经验。本次审查请你保持客观、严谨所有结论必须基于代码事实。 ## 任务输入 - 审查对象{{ FILES }} - 审查重点{{ FOCUS }} - 输出语言{{ LANGUAGE }} ## 审查流程 1. 先通读代码梳理核心逻辑和模块边界用自己的话简述这段代码是做什么的。 2. 从以下维度逐项检查 - 正确性是否存在边界条件处理不当、逻辑遗漏、隐式类型转换错误。 - 安全性是否有注入风险、敏感信息泄露、越权访问、不安全的资源释放。 - 性能是否存在不必要的循环嵌套、重复计算、无索引查询、大对象常驻内存。 - 可维护性命名是否清晰、函数是否过长、是否有重复代码、是否有注释过度或缺失。 3. 对发现的问题排序严重问题在前轻微问题在后。 ## 输出格式 使用 Markdown 表格输出包含以下列问题等级、问题描述、文件与位置、复现路径、修改建议。 ## 约束 - 只能基于提供的代码内容做审查不要臆测代码之外的业务逻辑。 - 不要提交琐碎且无实际意义的风格修改聚焦逻辑问题。 - 每条建议必须附带可执行的修改方案不能只说“建议优化”却不给具体办法。 - 如果没有发现问题请明确说明“未发现明显问题”不要强行编造。这个模板具备了前面说的四个区段。使用的时候我只需要在 Claude Code 会话中输入类似这样的指令请应用 templates/review/review_code.md 模板。 审查对象src/auth/login.go 审查重点并发安全和输入校验 输出语言中文3.3 写一个代码生成模板刻意强调约束代码生成模板和审查模板有所不同因为生成类任务最容易失控必须把约束写得非常具体。我的templates/generate/generate_feature.md是这么设计的# 功能开发模板 你是一名精通 TypeScript 和 Node.js 的全栈工程师。请严格按照以下要求实现一个新功能。 ## 功能描述 - 功能名称{{ FEATURE_NAME }} - 需求细节{{ REQUIREMENTS }} - 技术栈{{ STACK }} - 目标文件{{ TARGET_FILES }} ## 实现步骤 1. 先分析需求列出至少 3 个关键边界条件和异常场景。 2. 设计模块结构和对外 API确认数据流方向。 3. 编写实现代码代码必须包含类型定义。 4. 为关键函数编写简短的 JSDoc 注释。 5. 最后用 3 个测试用例验证核心逻辑。 ## 输出要求 按以下顺序输出 1. 边界条件分析 2. 模块结构设计 3. 核心代码 4. 测试用例 ## 硬性约束 - 不要添加任何与需求无关的代码。 - 不要使用any类型必须显式定义类型。 - 所有外部输入必须做校验不允许直接信任传入数据。 - 代码中禁止出现魔法数字常量必须定义并注释含义。你可以看到生成模板和审查模板的结构框架相同但约束密度大幅提高。这背后的经验是生成类任务模型偏向自由发挥审查类任务模型偏向谨慎保守。所以模板要根据任务类型动态调整约束强度。3.4 在 Claude Code 会话中加载模板的实际体验加载模板的方式我强烈建议用引用直接拼接文件内容而不要靠对话里的记忆。原因很简单Claude Code 的每次会话都有上下文窗口上限如果你在对话中手动复制粘贴模板那么模板本身就会占用大量 token而通过引用文件内容会以更结构化的方式进入上下文节省下来的 token 可以留给代码分析和长对话。实际操作起来是这样的。我先进入项目目录运行claude命令启动会话然后在第一轮消息里这样写templates/review/review_code.md 应用此模板。 审查对象src/utils/sort.ts 审查重点排序算法的正确性和边界条件这样 Claude Code 会优先读取review_code.md并按照模板里的流程执行。我会刻意在开头的第一句就提供“审查对象”和“审查重点”因为变量区段必须在模板输入的同一轮里补齐不要等到第二轮再补那样模型容易丢失指令的关联性。4. 模板设计避坑指南4.1 上下文窗口与 token 预算模板不是越长越好。我见过很多人写模板恨不得把整个团队规范都塞进去最终效果反而很差。原因在于 Claude Code 的上下文窗口是有限的模板占得越满留给实际代码和后续对话的空间就越小。尤其是处理大型代码文件时如果模板消耗了太多 token模型甚至可能没有足够空间读取完整文件。我的经验是单个模板尽量控制在 500 字以内。因为模板里要装的是“思考框架”和“约束边界”而不是长篇大论的业务背景。业务背景应该由用户在变量区段里提供。另外模板里尽量少贴大段示例代码一个简短的 5 到 10 行示例就足够说明输出格式了再多就是浪费。4.2 避免模板和项目规则冲突第二个容易踩的坑是模板里的约束和项目根目录下CLAUDE.md里的项目规则互相矛盾。比如项目的 CLAUDE.md 里规定“所有提交必须通过 lint 检查且遵循 Prettier 格式”而模板却要求“不要关注代码风格”。这种冲突会让模型产生行为分裂。我的处理原则是项目 CLAUDE.md 是最高优先级模板不能与之冲突。如果模板想强调某个特殊要求就用“在满足项目规范的前提下额外注意以下内容”这种兼容性表达。例如我会在代码生成模板里加一句“代码风格遵循项目 CLAUDE.md 约定如果项目未约定则使用常规社区标准。”这样既保留了模板的约束力又不会覆盖项目规则。4.3 测试模板像测试代码一样测模板模板更新后一定要测试不要想当然。我自己的做法是准备一个专门examples目录里面放了每组模板对应的“输入样例”和“期望输出样例”。比如review_example.md会放一段有明显缺陷的代码加上一份我心中比较理想的审查结果。每次改模板后我会用这个样例重新跑一遍对比新输出和期望输出确认没有跑偏。如果输出差得很远我会微调模板措辞再跑一遍。这个循环虽然有点花时间但长期非常划算。因为模板一旦在团队里推广出错成本远高于调模板的时间成本。我也建议把模板文件纳入代码评审流程改模板必须说明测试结果。这能防止团队里出现“谁都能改模板改完就有人遭殃”的混乱状态。5. 常见问题与排查技巧实录5.1 模板没生效怎么办我遇到最频繁的问题是明明在会话里引用了模板但 Claude Code 完全不按模板执行。排查这个问题的第一步是确认你引用文件路径是否正确。路径写错是最常见的低级错误。第二步是检查CLAUDE.md和模板文件是否有互相矛盾的内容如果有模型往往会倾向遵循项目级规则而忽略模板。第三步是看引用方式建议把引用放在对话第一句如果混在长段落中间模型可能把它当成普通文本而不是指令。这里有一个更隐蔽的原因模型像人类一样会选择性忽略重复出现的提示。如果你在同一会话里反复引用同一模板到第三次之后模型可能只记得前半部分。所以我的习惯是每个会话只引用一次模板后续说“继续按模板规则执行”就好不要重复粘贴模板全文。5.2 模板输出质量不稳定的原因如果你发现同一个模板、同一个输入两次输出却差异很大多半问题出在变量区段描述不完整。比如代码审查模板关于“审查重点”的变量如果我只写“性能”模型可能理解为笼统概述如果我写“重点检查数据库查询次数、循环中的同步调用、大文件的内存占用”输出就会精准得多。另一个原因是模板里的流程步骤不够具体。检查一下你是否用了“考虑”这类模糊动词比如“考虑代码安全性”。这种表达给模型的自由度过大。改成“检查代码中是否存在 SQL 注入、XSS、反序列化风险”后效果立刻不同。模板的本质是缩小模型的搜索空间而不是增加它的想象空间。5.3 团队协作时的模板维护技巧团队共用一套模板时最怕文件混乱。我的经验是用版本控制加分支管理。模板文件不要散落在某个人的本地环境要统一放在项目仓库里通过 PR 更新。更新模板时目录命名必须有明确的用途不允许出现template_v2_final.md这类命名文件一旦归档就用语义化命名。同时我建议在模板仓库里维护一份变更日志记录每一版模板改动的原因和效果。比如“review_code.md v2增加了对并发安全问题的检查因为 v1 经常漏掉。”这些经验记录比代码本身更有价值下次忘了当初为什么加这条约束看日志就能想起来。下面整理一个表格把常见问题快速过一遍问题现象常见原因排查与修复模板完全没生效引用路径错误、指令被淹没检查路径把指令放在会话第一句输出不符合模板要求变量描述不清晰补充更具体的 FOCUS、SCOPE模型行为与项目规则冲突模板与 CLAUDE.md 冲突统一优先级兼容表述模板输出内容过长约束不足、示例代码过多增加“不要输出”约束精简示例同一模板多次使用后失效上下文被其他内容稀释新会话重新引用模板模板里的中文表达被误解使用模糊动词改用明确动词列出具体检查项6. 进阶扩展让模板自动跑起来6.1 搭配脚本快速调用模板手动引用模板虽好但每次都敲“应用某个模板加参数”也很重复。我给 claude-code-templates 配了一个极小的 Python 脚本apply_template.py作用是把参数填进模板并输出最终指令。他的实现逻辑不复杂核心是读模板文件找到{{ VAR }}占位符用命令行参数替换然后打印最终指令。你可以像这样使用python scripts/apply_template.py templates/review/review_code.md \ --replace FILESsrc/auth/login.go \ --replace FOCUS并发安全 \ --replace LANGUAGE中文脚本输出结果后我再手动复制到 Claude Code 会话里。如果你用的是支持管道的终端工具甚至可以直接把脚本输出拼接到claude命令的启动参数中。这个自动化程度对个人使用已经足够不需要引入复杂框架。6.2 用 Git 管理模板版本模板一旦成为团队共识就必须有可追溯性。所有模板都放进同一个 Git 仓库用分支开发、PR 合并。每次更新模板时标题栏注明更新人、日期、动机。这能解决我实际遇到过的“某天模板变差了但不知道是谁改的”这个难题。Git 历史和 blame 功能可以定位到具体改动原因。我给模板仓库配置了轻量的测试路径examples目录放样例Git 钩子里跑一个简单的 diff 检查看模板改动后能否生成合法输出。说到 Git 钩子我建议至少加一个pre-commit钩子阻止文件名中出现final、_v2这类字眼强制性保证命名规范。6.3 在 CI 中复用模板更进一步的玩法是把模板接入 CI 流程。比如在每次代码合并前用代码审查模板自动跑一轮静态审查。做法是写一个 GitHub Actions 或 GitLab CI 任务在流水线里调用脚本生成审查指令再把 Claude Code 的输出作为评论发到 PR 上。需要提醒的是这种情况必须做召回保护不要让模型直接修改代码并提交。CI 里的模板只负责分析和建议不负责动代码。把这个约束写进模板的“约束区段”后整体安全性会提高很多。除此之外我还在实验室里试过用模板自动生成 API 文档把接口代码和模板拼接起来让模型按统一格式输出文档。这个场景特别适合模板化因为文档结构天生标准化模板能极大消除文档风格漂移的问题。我个人在实际操作中一个很受用的体会是模板的价值不在“写了什么表面文字”而在“它的约束有没有把你的质量标准真正传递给模型”。我踩过最多次的坑是以为模板写得足够清楚结果模型的输出还是飘。后来我养成了一个习惯每次写模板后我会故意在样例里埋几个不易发现的逻辑错误然后跑一遍模板看它的审查能力是否真的按我设计的节奏走。这套验证思路比读多少篇“提示词工程教程”都管用。最后再分享一个我自己经常用的小技巧在模板的设计上我往往会保留一个“反馈变量”例如在审查模板里让模型以“本次审查有什么无法确定的信息”作为收尾。这个收尾项看起来简单实际上能让模型主动暴露信息盲区你会发现由此产生的追问质量非常高。下一次使用这个模板的时候你也就知道自己该提前补什么内容了。如果你也在用 Clcode Code 处理复杂工程任务真的建议给自己搭一套模板它可能是你投入产出比最高的一次工程化尝试。