1. 项目概述Claude Code 模板到底解决了什么问题1.1 从一次“对话失控”说起先讲个真实场景。我刚开始用 Claude Code 时满脑子都是“让 AI 帮我写代码”结果第一周几乎每天都在跟它“拉扯”——让它改个接口它把我的测试文件也重构了让它写个脚本它默认假设项目用的是 TypeScript而实际上这是个纯 Python 仓库我明明说了“只要改这一个函数”它非要顺带把风格不一致的地方全“好心纠正”一遍。后来我意识到问题不在模型能力而在于我每次对话都从零开始交代背景、规则、边界。同一个项目昨天说过的约束今天又得复述一遍同一个任务类型每次都要重新描述一遍“你该怎么思考、该输出什么、不该碰什么文件”。这种重复劳动极其消耗心智。于是我开始给 Claude Code 建模板把高频任务的“行为方式”固化下来。所谓 claude-code-templates本质就是一套围绕 Claude Code 工作流的提示词模板、项目规范文件和任务指令模板。你可以把它理解成“给 AI 的一份岗位说明书 工作流清单”。它不是玄学也不是什么高阶技巧就是用结构化文本把上下文、规则、输出格式、边界约束一次性讲清楚让每次对话都站在一个稳定的起点上。1.2 模板化思维把 AI 交互当成接口来设计我把这种思路称为“接口化思维”。写代码的时候我们都懂 API 要稳定输入输出、要定义好参数、要有一致的行为契约。但面对 Claude Code 时很多人反而不讲契约了——想到哪说到哪上下文忽多忽少规则前后矛盾输出自然飘忽不定。模板的作用就是把这些“软交互”硬化为“接口”。一份好的模板至少表达四层信息一是角色与边界告诉 Claude 它在这轮任务里是什么身份、能碰什么、不能碰什么二是项目上下文把技术栈、目录结构、编码规范一次性交代清楚三是任务定义明确输入是什么、输出是什么、验收标准是什么四是行为约束比如“不要改测试文件外的代码”“不要自动安装依赖”这类边界条件。换个角度看你使用 Claude Code 的体验上限其实在对话开始前就被决定了。模板就是把这件事从“靠临场发挥”变成“靠体系保障”。1.3 这些模板适合谁从我的实践经验来看有几种人特别需要这套东西。第一种是深度使用 Claude Code 做日常开发的人。你的重复任务越多模板带来的收益越大。比如我每天都要做代码审查、写提交信息、补测试用例这三件事我各做了一份模板现在每次输入只需要给一个文件路径或者粘贴一段 diff 就行剩下的全由模板驱动。第二种是团队里需要多人共享 AI 协作方式的人。代码风格可以靠 lint 强制统一但 AI 交互风格往往五花八门。一套团队级模板能让大家对 AI 的产出预期趋于一致减少“为什么你的 AI 写出来的和我差这么多”这类争执。第三种是刚开始接触 Claude Code 的新手。模板看起来是给老手准备的效率工具但对新手反而是最佳入门教材——你拆开一份好的模板看看就知道好的 AI 协作应该交代哪些信息、设定哪些预期。2. 模板体系设计先想清楚分层再动手写文件2.1 三层模板结构项目级、任务级、交互级我见过很多人搭模板库上来就开始写文件写了十来份却彼此内容重叠、边界混乱。我自己重构过两轮之后沉淀下来一套三层结构现在一直用这套划分。第一层是项目级模板核心就是 CLAUDE.md 以及配套的架构说明文件。这一层负责回答“这个项目是什么、有什么约定、目录怎么看”。它应该被放在项目根目录伴随项目仓库走团队里所有人都能共享。项目级模板的内容尽量不要写死某次任务的目标而是要写稳定的、长期有效的约束。第二层是任务级模板负责定义“一类任务该怎么干”。比如代码审查、需求拆解、重构实施、Bug 排查、写测试、写提交信息。每个模板只聚焦一种任务类型内容要极其具体。这一层是使用频率最高、收益最明显的部分。第三层是交互级模板负责处理“单次对话中如何给模型设定角色与约束”。这些内容通常不需要单独存成文件而是作为一段前缀文本在启动特定任务时粘贴进 Claude Code 的输入框或者用斜杠命令动态加载进来。三层之间有一个明确的依赖关系项目级确定背景任务级确定流程交互级确定语气和边界。缺失任何一层另外两层的效果都会被稀释。2.2 命名与存储规范让模板库可用、可维护模板库最容易腐烂的地方不是没人写而是写完之后找不到、分不清。我的目录结构是这个样子claude-templates/ ├── project/ │ ├── CLAUDE.md.md │ └── ARCHITECTURE.md ├── task/ │ ├── code-review.md │ ├── feature-plan.md │ ├── refactor.md │ ├── bug-hunt.md │ ├── write-tests.md │ └── commit-message.md └── session/ ├── strict-mode.md ├── explore-mode.md └── fix-quick.md命名上有一个原则模板文件名就是触发词。比如我的task/code-review.md内容第一行写的是“当我说 review 或 审查 时默认进入此流程”。这样我用的时候只需要说“帮我 review 一下 src/worker.py”Claude 就能理解调用的是哪份模板。如果你用了斜杠命令命名更要简洁/review、/plan、/refactor这类短名称远比/code-review-with-lint-and-security-check好用。存储上我强烈建议用 Git 管理模板库而不是随手丢在某个笔记软件里。因为模板会演进你需要能回溯“为什么当时是这么写的”需要能对比不同版本的差别。我自己的模板库放在独立的仓库里每次调整都写提交信息半年来积累了三十多条演进记录回头看非常有价值。2.3 参数化设计一份模板适配多种场景模板最怕写得太死。比如代码审查模板在小项目审查用一套规则在大项目合流审查又是另一套规则如果写成两份维护负担直接翻倍。参数化设计是解决之道。我在模板里约定用双重大括号包住可变项## 审查范围 本次仅审查以下内容 {{FILES}} ## 审查深度 {{DEPTH:standard}} - standard常规逐行审查重点关注逻辑错误与安全隐患 - deep逐行审查 功能回归风险分析 修改建议完整代码 - quick静态扫描级别只看明显的错误与风格问题这样模板本身没有绑死变量而是给出一组可选项让使用者从外部注入。Claude Code 对上下文里的指令遵循能力很强当你明确给出一个参数选项它很少会忽略比我试过的很多低代码工作流工具都靠谱。参数化还有一个好处模板可以数据驱动。我可以写一个脚本从 Git 分支名里提取变更文件列表自动拼好审查模板的参数把最终内容通过管道喂给 claude 命令。相当于真正把模板变成了程序里的一个函数。3. 实操从零搭建一套可直接复用的模板库3.1 第一步从 CLAUDE.md 开始而不是从任务模板开始很多人的第一反应是先写“审查模板”“重构模板”因为这类模板用起来感觉明显。但我建议先把项目级模板做扎实原因很简单项目级模板是所有任务级模板的底盘。我的 CLAUDE.md 至今保留这些核心块# 项目概述 内部订单管理系统后端 Python FastAPI前端 Vue3PostgreSQL 数据库。 仓库地址gitgithub.com:example/order-system.git # 关键目录 - backend/app/api/ 路由层只负责参数解析与响应封装 - backend/app/service/ 业务逻辑层所有规则判断必须在这层 - frontend/src/views/ 页面组件禁止直接写 API 调用 - frontend/src/api/ API 封装层所有请求必须通过这层 # 编码规范 - Python 用 Black 格式化行宽 88 - 禁止在 service 层 catch 所有异常后吞掉 - 前端优先使用 composition API不使用 options API - 数据库迁移文件命名YYYYMMDD_description.sql # 绝对约束 1. 不得修改 database/migrations/ 下已提交的迁移文件 2. 不得对 backend/tests/ 下的测试用例做“为了让测试通过而修改”的行为 3. 遇到需求不明确时先列出假设不要直接开写你可能会觉得这些内容平平无奇但请注意它的两个设计要领。第一个要领是“写清绑定关系”比如“路由层只做参数解析”这句话的价值在于当 Claude 准备把业务规则塞进路由时它会被这几个词拉回来。第二个要领是“写清负面约束”三条绝对约束中前两条都是负面清单我实践下来的结论是负面约束对 AI 行为的引导作用远超正面要求。3.2 第二步编写一份高质量的代码审查模板代码审查是收益最直接的任务模板。我的完整模板长这样你可以直接抄去改# 角色与边界 你是一位资深代码审查员。你的任务是对给定代码变更进行审查输出审查意见。 你只能提出建议和发现缺陷不得直接修改代码不得输出重构后的代码。 # 输入 以下代码变更来自 {{BRANCH_NAME}} 分支涉及文件{{FILES}} {{DIFF}} # 审查维度按优先级排列 1. 功能正确性是否有逻辑错误、边界条件遗漏、并发问题 2. 安全问题SQL 注入、敏感信息泄露、越权访问、依赖漏洞 3. 性能隐患是否有明显复杂度问题、N1 查询、不必要的大对象加载 4. 可维护性命名是否清晰、函数是否过长、是否有重复逻辑 5. 风格一致性是否符合作业与本项目规范参见 CLAUDE.md # 输出格式 输出 markdown 列表每条问题包含以下字段 - 位置文件路径 行号 - 严重级别CRITICAL / MAJOR / MINOR / NIT - 问题描述一句话说明 - 修改建议具体可操作的修改方案 # 行为约束 - 只能用现有代码推断语境如果上下文不足列出“需要人工确认的信息”不能自行脑补 - 风格层面的问题标记为 MINOR不能在风格上纠缠 - 审查完毕后输出一段总结整体质量评价 建议合并或打回这份模板的精髓在“只能提出建议不得直接修改代码”。我一开始没写这条结果 Claude 自带一种“顺手把代码改了”的冲动每次输出审查意见时总是夹带私货直接给了整段修改后的函数。这对于代码审查是致命的因为审查者的价值是发现风险而不是替作者做决定。3.3 第三步编写需求拆解与实施计划模板很多人让 Claude 写代码之前总会先让 Claude 直接开写结果经常发现方向偏了。我的习惯是先跑一份需求拆解模板把“开写之前的所有思考”单独拿出来。模板框架如下# 角色与边界 你是一位资深技术负责人。你的任务是拆解需求输出实施计划不写业务代码。 在计划被用户确认之前不得开始编码。 # 输入需求 {{REQUIREMENT}} # 你的任务 1. 识别需求的真实目标区分“必须实现”和“可以被简化” 2. 梳理技术影响面列出所有需要修改的模块基于 CLAUDE.md 和项目结构 3. 分析风险点哪些改动可能破坏现有功能哪些接口变更需要同步调整 4. 输出分步实施计划每步要包含改动范围、涉及文件、验收方式 # 实施计划格式 ## 阶段概述 ## 第1步xxx - 改动位置 - 改动内容 - 验收标准 ## 第2步xxx ... # 行为约束 - 如果需求描述不清晰输出“存疑清单”把不明确的地方逐个列出要求用户澄清 - 计划必须考虑向后兼容不能假设一次性重构完成 - 预估每步的工作量S/M/L仅做相对估算用这份模板跑了一周之后我感觉自己的开发节奏发生了明显改变。代码生成之前的思考时间被转移到了模板交互上看起来像是多了一步流程实际上节省了大量“写完推翻重写”的时间。3.4 第四步让模板与 Claude Code 的加载机制协同工作模板文件本身写好只是第一步关键是平时怎么调用。这里我推荐几种加载方式按使用频率排序。最简单的一种交互式启动时直接粘贴。claude命令启动后把模板内容粘进去接着粘贴具体任务。这种方式适合不频繁的任务。更好用的一种利用CLAUDE.md的引用。我可以在 CLAUDE.md 里加入一行## 任务模板 当用户请求涉及代码审查时读取 task/code-review.md 并遵循其中的工作流程。这样任务级模板可以“按需加载”而不是全部堆进上下文。经过我的实测这比把每位模板都直接塞给 Claude 稳妥得多——后者不仅浪费 token还会引入大量无用约束干扰核心任务推理。最灵活的做法是写一层薄薄的脚本封装让模板参数化落到实处。比如我写了一个 bash 脚本review.sh#!/usr/bin/env bash DIFF$(git diff $1) FILES$(git diff --name-only $1 | paste -sd, -) sed -e s/{{DIFF}}/$DIFF/ -e s/{{FILES}}/FILES/ -e s/{{BRANCH_NAME}}/$1/ \ task/code-review.md | claude --print把拼好的模板通过管道交给 Claude Code 的无交互模式获得的输出就是标准化的审查意见。这本质上实现了“一份模板 一个参数 一个稳定执行的任务”。4. 核心机制解析模板如何真正影响 Claude Code 的行为4.1 提示词的位置会影响模型的采信权重有关键细节值得展开模板内容如果只是堆在提示词末尾效果会打折扣。我推荐的模板主体顺序是“角色定义 → 任务输入 → 任务步骤 → 输出格式 → 约束条件 → 总结指令”。角色定义放最前面相当于先确立行为框架后面所有内容都会被这个框架过滤。这与模型注意力机制有关。靠后的内容在长上下文里容易被稀释所以我把“不得修改代码”“只输出审查意见”等负面约束放在具体步骤之后、输出格式之前。这个位置既不容易被忽略又不会抢占任务理解的空间。它更像一道紧箍咒在模型准备“输出建议代码”的时候兜住它。我的经验是模板不需要每次对话都用 100% 完整的原文。像交互级模板我常用的一段精简前置提示是这样的你是我的代码助手。在本次对话中 1. 先理解问题再动手方案设计 2. 设计通过后列出改动文件清单等我确认后开始写代码 3. 写代码时遵循 CLAUDE.md 中项目规范 4. 写完后简要说明改动内容和影响这段内容虽然短但四句话覆盖了角色、流程、规范和交付要求效果比一段冗长的万能提示词更好。4.2 模板与工具、子代理的配合机制Claude Code 不只是文本交互界面它有大量工具调用能力比如执行命令、读写文件、搜索代码库。模板需要显式地控制这些工具的边界否则它会在错误时机调用工具。在代码审查模板里我写的是“你只能提出建议和发现缺陷不得直接修改代码”但我们都知道审查是需要查看代码、搜索定义的。所以另一个边界约束也必不可少“你可以调用工具来获取上下文但最终输出只能包含审查意见”。显式区分“允许获取信息”和“不允许修改文件”两件事才能达到预期效果。对于更复杂的任务比如重构跨模块的代码我使用子代理的思路把模板拆成“主流程模板 子任务模板”。这个做法像团队分工一个代理负责规划另一个代理负责具体实施一个代理专门做验证。模板库相当于给它们各发了一本岗位手册避免彼此越权。4.3 上下文管理的边界模板不是越长越好这是我最想强调的实战经验。模板库有个天然冲动是往里面堆内容今天想到一条规则加一条明天看到一次错误输出又加一条。结果是模板越来越长效果越来越差。我的上限是以单次任务能完整喂给模型且不挤占任务本身空间为准。实测下来一份任务级模板的合理篇幅在 500 到 800 字之间超过这个长度模型的遵循度会显著下降。因为模板内容本身会占据注意力资源这就像一个会议开场前念了十分钟免责声明真正开议的时候听众早就疲惫了。为了控制模板膨胀我给自己定了一条规矩模板里只保留“写错了会花很长时间回来修”的规则。锦上添花的建议、可写可不写的风格调整全部删除。宁可少一条规则也不要让关键规则被淹没。4.4 版本管理与团队共享经验模板库的演进不能靠记忆。我始终强调用 Git 管理不是形式主义是真的有这个需求。举一个真实案例我们有次做安全专项审查临时在代码审查模板里加了“必须检查认证与授权逻辑”的专项维度。那次的效果特别好但如果没有版本管理这个临时改动就会被淹没在模板的历史里下次安全专项时又得重新想起来。因为模板库有 Git 历史我现在可以轻松回溯那个版本或者通过合并请求把这条专项维度合并进正式模板。团队协作时模板库的作用更加放大。我建议在团队内建立“模板评审”机制每个人都有权限提交模板变更但至少要有一个人负责归口管理防止互相冲突的规则同时被打进代码里。这跟代码仓库的评审流程是一个道理。5. 常见问题与排查技巧实录5.1 模板明明写了却不生效这是出现频率最高的问题。排查顺序我一般是这样的先检查模板有没有被正确加载。你用claude --print直接运行的话模型拿到的内容就是你在命令行里输入的内容不会自动去读 CLAUDE.md 之外的模板文件。你以为的“写了模板应该自动生效”在很多时候是不成立的。CLAUDE.md 会被自动加载但放在task/目录下的文件不会你必须通过引用、粘贴或脚本拼装让它进入上下文。再检查模板内容是否和上下文冲突。有一次代码审查模板不生效我排查了半天发现是 CLAUDE.md 里写了一句“你是一个乐于助人的编程助手”这句全局角色设定中和了审查模板的“不得修改代码”约束。修复方式是在 CLAUDE.md 里删掉冲突内容。最后检查是不是参数没拼对。比如我脚本里的sed替换遇到 diff 内容里包含特殊字符导致模板变量没被正确替换喂给模型的还是一堆{{DIFF}}。后来我改用 Python 脚本做模版拼接这类问题就消失了。5.2 模板之间的角色冲突项目级模板写“你是一个后端开发专家”任务级模板写“你是一位严格的代码审查员”两个角色有冲突时模型有时候会摇摆不定输出一会儿是开发者的口吻一会儿是审查者的口吻。解决思路是给角色设定一个优先级。我会在 CLAUDE.md 里加一句# 角色优先级 当任务模板定义了具体角色时以任务模板的角色为准未定义时才使用项目级角色。CLAUDE.md 的指令优先级本来就足够高这样写在逻辑上很顺。事实上模型的指令遵循有就近原则任务级模板的权重天然高于项目级模板但显式声明优先级可以降低角色混乱概率。5.3 模板内容被截断或覆盖长模板加上大段 diff很容易把上下文窗口撑爆。对策有两个方向压缩模板体积或者拆分任务。压缩方向我把输出格式做了简化比如审查模板的输出格式从七八个详细字段压缩成“级别 位置 一句话建议”的紧凑列表。很多格式上的花哨描述都是冗余压缩之后的模板语义几乎没有损失。拆分方向把大任务切成两个阶段。比如重构任务先跑规划模板得到计划确认后再单独跑实施模板不让两套指令同时占据上下文。这两个阶段各用各的模板上下文干净模型注意力集中。5.4 维护时机模板库什么时候值得更新模板库不应该是写一次就完事的东西。我的经验是每次“对话失控”之后不是去怪模型而是去问模板库缺了什么。如果 AI 这次搞错了项目技术栈说明项目级模板缺了技术栈说明如果它这次越界改了不该改的测试文件说明负面约束里缺了“不得修改测试文件”这条如果它这次的输出格式不符合要求说明任务模板的输出格式写得不够明确。把每次失败当成一次模板迭代的契机模板库就会越来越接近你的真实工作方式。我现在的维护频率大约是一周调整一次每次只改一发小步快跑。长期积累下来这个习惯带来的效率收益远超过写模板本身的投入。6. 我踩过的坑与最终心得6.1 第一个坑迷信“万能模板”我一度试图做一份“万能模板”把角色、规范、审查、测试、计划全部塞进一个文件里。结果每一次使用都像在开一场混乱的会议规则太多反而无从执行。后来我把它拆成独立的专项模板整体体验立刻改观。合理的模板不是一把多功能瑞士军刀而是一套工具箱每样工具解决一类问题。6.2 第二个坑拿模板当任务清单而不是行为约束其实模板本身写什么决定了你在跟 AI 协作时是“发号施令”还是“确立规则”。前者是授权它执行一串指令后者是给它一个决策框架。我的模板大量使用“如果……则……”的句式体现的正是行为逻辑比如“如果需求不明确则输出存疑清单再开始”这样模型在遇到同类分支时能自主做出决策。6.3 模板是一种投资而不是成本如果把模板当成每次对话的负担那你很难坚持下去。但把它当成一次投资就完全不一样了。我现在每次新建一个项目花二十分钟写一份 CLAUDE.md这项工作会在后续每一次与 Claude 的协作中自动复利。随着时间拉长我发现模板帮我省下的不只是打字时间更是大量“把思路理清楚重来一遍”的心智损耗。6.4 最后分享我的一个实用小技巧不管什么类型的模板我建议在末尾留一节“完成后的回顾”。也就是让 Claude 输出任务结果的同时自答三个问题本任务中哪些地方符合预期哪些地方你觉得可以做得更好下一轮模板有哪些值得更新的规则。这样一个简单的小节让模板库实现了自进化每一次使用可能都是在优化它自身。现在的我越来越不关心“怎么写一段更好的提示词”这件事因为我发现真正的问题是“怎么建立一套稳定的协作框架”。claude-code-templates 这个方向的核心价值正是把一次次临时交互沉淀成体系让 AI 协作从碰运气变成确定性高的常规流程。希望这篇总结能给你一些实操思路也欢迎你踩过更多坑之后再回来看看这份模板库那时候你会真正理解我为什么说它值得投入时间去构建。 Claude Code模板实战：从提示词到高效AI协作工作流
1. 项目概述Claude Code 模板到底解决了什么问题1.1 从一次“对话失控”说起先讲个真实场景。我刚开始用 Claude Code 时满脑子都是“让 AI 帮我写代码”结果第一周几乎每天都在跟它“拉扯”——让它改个接口它把我的测试文件也重构了让它写个脚本它默认假设项目用的是 TypeScript而实际上这是个纯 Python 仓库我明明说了“只要改这一个函数”它非要顺带把风格不一致的地方全“好心纠正”一遍。后来我意识到问题不在模型能力而在于我每次对话都从零开始交代背景、规则、边界。同一个项目昨天说过的约束今天又得复述一遍同一个任务类型每次都要重新描述一遍“你该怎么思考、该输出什么、不该碰什么文件”。这种重复劳动极其消耗心智。于是我开始给 Claude Code 建模板把高频任务的“行为方式”固化下来。所谓 claude-code-templates本质就是一套围绕 Claude Code 工作流的提示词模板、项目规范文件和任务指令模板。你可以把它理解成“给 AI 的一份岗位说明书 工作流清单”。它不是玄学也不是什么高阶技巧就是用结构化文本把上下文、规则、输出格式、边界约束一次性讲清楚让每次对话都站在一个稳定的起点上。1.2 模板化思维把 AI 交互当成接口来设计我把这种思路称为“接口化思维”。写代码的时候我们都懂 API 要稳定输入输出、要定义好参数、要有一致的行为契约。但面对 Claude Code 时很多人反而不讲契约了——想到哪说到哪上下文忽多忽少规则前后矛盾输出自然飘忽不定。模板的作用就是把这些“软交互”硬化为“接口”。一份好的模板至少表达四层信息一是角色与边界告诉 Claude 它在这轮任务里是什么身份、能碰什么、不能碰什么二是项目上下文把技术栈、目录结构、编码规范一次性交代清楚三是任务定义明确输入是什么、输出是什么、验收标准是什么四是行为约束比如“不要改测试文件外的代码”“不要自动安装依赖”这类边界条件。换个角度看你使用 Claude Code 的体验上限其实在对话开始前就被决定了。模板就是把这件事从“靠临场发挥”变成“靠体系保障”。1.3 这些模板适合谁从我的实践经验来看有几种人特别需要这套东西。第一种是深度使用 Claude Code 做日常开发的人。你的重复任务越多模板带来的收益越大。比如我每天都要做代码审查、写提交信息、补测试用例这三件事我各做了一份模板现在每次输入只需要给一个文件路径或者粘贴一段 diff 就行剩下的全由模板驱动。第二种是团队里需要多人共享 AI 协作方式的人。代码风格可以靠 lint 强制统一但 AI 交互风格往往五花八门。一套团队级模板能让大家对 AI 的产出预期趋于一致减少“为什么你的 AI 写出来的和我差这么多”这类争执。第三种是刚开始接触 Claude Code 的新手。模板看起来是给老手准备的效率工具但对新手反而是最佳入门教材——你拆开一份好的模板看看就知道好的 AI 协作应该交代哪些信息、设定哪些预期。2. 模板体系设计先想清楚分层再动手写文件2.1 三层模板结构项目级、任务级、交互级我见过很多人搭模板库上来就开始写文件写了十来份却彼此内容重叠、边界混乱。我自己重构过两轮之后沉淀下来一套三层结构现在一直用这套划分。第一层是项目级模板核心就是 CLAUDE.md 以及配套的架构说明文件。这一层负责回答“这个项目是什么、有什么约定、目录怎么看”。它应该被放在项目根目录伴随项目仓库走团队里所有人都能共享。项目级模板的内容尽量不要写死某次任务的目标而是要写稳定的、长期有效的约束。第二层是任务级模板负责定义“一类任务该怎么干”。比如代码审查、需求拆解、重构实施、Bug 排查、写测试、写提交信息。每个模板只聚焦一种任务类型内容要极其具体。这一层是使用频率最高、收益最明显的部分。第三层是交互级模板负责处理“单次对话中如何给模型设定角色与约束”。这些内容通常不需要单独存成文件而是作为一段前缀文本在启动特定任务时粘贴进 Claude Code 的输入框或者用斜杠命令动态加载进来。三层之间有一个明确的依赖关系项目级确定背景任务级确定流程交互级确定语气和边界。缺失任何一层另外两层的效果都会被稀释。2.2 命名与存储规范让模板库可用、可维护模板库最容易腐烂的地方不是没人写而是写完之后找不到、分不清。我的目录结构是这个样子claude-templates/ ├── project/ │ ├── CLAUDE.md.md │ └── ARCHITECTURE.md ├── task/ │ ├── code-review.md │ ├── feature-plan.md │ ├── refactor.md │ ├── bug-hunt.md │ ├── write-tests.md │ └── commit-message.md └── session/ ├── strict-mode.md ├── explore-mode.md └── fix-quick.md命名上有一个原则模板文件名就是触发词。比如我的task/code-review.md内容第一行写的是“当我说 review 或 审查 时默认进入此流程”。这样我用的时候只需要说“帮我 review 一下 src/worker.py”Claude 就能理解调用的是哪份模板。如果你用了斜杠命令命名更要简洁/review、/plan、/refactor这类短名称远比/code-review-with-lint-and-security-check好用。存储上我强烈建议用 Git 管理模板库而不是随手丢在某个笔记软件里。因为模板会演进你需要能回溯“为什么当时是这么写的”需要能对比不同版本的差别。我自己的模板库放在独立的仓库里每次调整都写提交信息半年来积累了三十多条演进记录回头看非常有价值。2.3 参数化设计一份模板适配多种场景模板最怕写得太死。比如代码审查模板在小项目审查用一套规则在大项目合流审查又是另一套规则如果写成两份维护负担直接翻倍。参数化设计是解决之道。我在模板里约定用双重大括号包住可变项## 审查范围 本次仅审查以下内容 {{FILES}} ## 审查深度 {{DEPTH:standard}} - standard常规逐行审查重点关注逻辑错误与安全隐患 - deep逐行审查 功能回归风险分析 修改建议完整代码 - quick静态扫描级别只看明显的错误与风格问题这样模板本身没有绑死变量而是给出一组可选项让使用者从外部注入。Claude Code 对上下文里的指令遵循能力很强当你明确给出一个参数选项它很少会忽略比我试过的很多低代码工作流工具都靠谱。参数化还有一个好处模板可以数据驱动。我可以写一个脚本从 Git 分支名里提取变更文件列表自动拼好审查模板的参数把最终内容通过管道喂给 claude 命令。相当于真正把模板变成了程序里的一个函数。3. 实操从零搭建一套可直接复用的模板库3.1 第一步从 CLAUDE.md 开始而不是从任务模板开始很多人的第一反应是先写“审查模板”“重构模板”因为这类模板用起来感觉明显。但我建议先把项目级模板做扎实原因很简单项目级模板是所有任务级模板的底盘。我的 CLAUDE.md 至今保留这些核心块# 项目概述 内部订单管理系统后端 Python FastAPI前端 Vue3PostgreSQL 数据库。 仓库地址gitgithub.com:example/order-system.git # 关键目录 - backend/app/api/ 路由层只负责参数解析与响应封装 - backend/app/service/ 业务逻辑层所有规则判断必须在这层 - frontend/src/views/ 页面组件禁止直接写 API 调用 - frontend/src/api/ API 封装层所有请求必须通过这层 # 编码规范 - Python 用 Black 格式化行宽 88 - 禁止在 service 层 catch 所有异常后吞掉 - 前端优先使用 composition API不使用 options API - 数据库迁移文件命名YYYYMMDD_description.sql # 绝对约束 1. 不得修改 database/migrations/ 下已提交的迁移文件 2. 不得对 backend/tests/ 下的测试用例做“为了让测试通过而修改”的行为 3. 遇到需求不明确时先列出假设不要直接开写你可能会觉得这些内容平平无奇但请注意它的两个设计要领。第一个要领是“写清绑定关系”比如“路由层只做参数解析”这句话的价值在于当 Claude 准备把业务规则塞进路由时它会被这几个词拉回来。第二个要领是“写清负面约束”三条绝对约束中前两条都是负面清单我实践下来的结论是负面约束对 AI 行为的引导作用远超正面要求。3.2 第二步编写一份高质量的代码审查模板代码审查是收益最直接的任务模板。我的完整模板长这样你可以直接抄去改# 角色与边界 你是一位资深代码审查员。你的任务是对给定代码变更进行审查输出审查意见。 你只能提出建议和发现缺陷不得直接修改代码不得输出重构后的代码。 # 输入 以下代码变更来自 {{BRANCH_NAME}} 分支涉及文件{{FILES}} {{DIFF}} # 审查维度按优先级排列 1. 功能正确性是否有逻辑错误、边界条件遗漏、并发问题 2. 安全问题SQL 注入、敏感信息泄露、越权访问、依赖漏洞 3. 性能隐患是否有明显复杂度问题、N1 查询、不必要的大对象加载 4. 可维护性命名是否清晰、函数是否过长、是否有重复逻辑 5. 风格一致性是否符合作业与本项目规范参见 CLAUDE.md # 输出格式 输出 markdown 列表每条问题包含以下字段 - 位置文件路径 行号 - 严重级别CRITICAL / MAJOR / MINOR / NIT - 问题描述一句话说明 - 修改建议具体可操作的修改方案 # 行为约束 - 只能用现有代码推断语境如果上下文不足列出“需要人工确认的信息”不能自行脑补 - 风格层面的问题标记为 MINOR不能在风格上纠缠 - 审查完毕后输出一段总结整体质量评价 建议合并或打回这份模板的精髓在“只能提出建议不得直接修改代码”。我一开始没写这条结果 Claude 自带一种“顺手把代码改了”的冲动每次输出审查意见时总是夹带私货直接给了整段修改后的函数。这对于代码审查是致命的因为审查者的价值是发现风险而不是替作者做决定。3.3 第三步编写需求拆解与实施计划模板很多人让 Claude 写代码之前总会先让 Claude 直接开写结果经常发现方向偏了。我的习惯是先跑一份需求拆解模板把“开写之前的所有思考”单独拿出来。模板框架如下# 角色与边界 你是一位资深技术负责人。你的任务是拆解需求输出实施计划不写业务代码。 在计划被用户确认之前不得开始编码。 # 输入需求 {{REQUIREMENT}} # 你的任务 1. 识别需求的真实目标区分“必须实现”和“可以被简化” 2. 梳理技术影响面列出所有需要修改的模块基于 CLAUDE.md 和项目结构 3. 分析风险点哪些改动可能破坏现有功能哪些接口变更需要同步调整 4. 输出分步实施计划每步要包含改动范围、涉及文件、验收方式 # 实施计划格式 ## 阶段概述 ## 第1步xxx - 改动位置 - 改动内容 - 验收标准 ## 第2步xxx ... # 行为约束 - 如果需求描述不清晰输出“存疑清单”把不明确的地方逐个列出要求用户澄清 - 计划必须考虑向后兼容不能假设一次性重构完成 - 预估每步的工作量S/M/L仅做相对估算用这份模板跑了一周之后我感觉自己的开发节奏发生了明显改变。代码生成之前的思考时间被转移到了模板交互上看起来像是多了一步流程实际上节省了大量“写完推翻重写”的时间。3.4 第四步让模板与 Claude Code 的加载机制协同工作模板文件本身写好只是第一步关键是平时怎么调用。这里我推荐几种加载方式按使用频率排序。最简单的一种交互式启动时直接粘贴。claude命令启动后把模板内容粘进去接着粘贴具体任务。这种方式适合不频繁的任务。更好用的一种利用CLAUDE.md的引用。我可以在 CLAUDE.md 里加入一行## 任务模板 当用户请求涉及代码审查时读取 task/code-review.md 并遵循其中的工作流程。这样任务级模板可以“按需加载”而不是全部堆进上下文。经过我的实测这比把每位模板都直接塞给 Claude 稳妥得多——后者不仅浪费 token还会引入大量无用约束干扰核心任务推理。最灵活的做法是写一层薄薄的脚本封装让模板参数化落到实处。比如我写了一个 bash 脚本review.sh#!/usr/bin/env bash DIFF$(git diff $1) FILES$(git diff --name-only $1 | paste -sd, -) sed -e s/{{DIFF}}/$DIFF/ -e s/{{FILES}}/FILES/ -e s/{{BRANCH_NAME}}/$1/ \ task/code-review.md | claude --print把拼好的模板通过管道交给 Claude Code 的无交互模式获得的输出就是标准化的审查意见。这本质上实现了“一份模板 一个参数 一个稳定执行的任务”。4. 核心机制解析模板如何真正影响 Claude Code 的行为4.1 提示词的位置会影响模型的采信权重有关键细节值得展开模板内容如果只是堆在提示词末尾效果会打折扣。我推荐的模板主体顺序是“角色定义 → 任务输入 → 任务步骤 → 输出格式 → 约束条件 → 总结指令”。角色定义放最前面相当于先确立行为框架后面所有内容都会被这个框架过滤。这与模型注意力机制有关。靠后的内容在长上下文里容易被稀释所以我把“不得修改代码”“只输出审查意见”等负面约束放在具体步骤之后、输出格式之前。这个位置既不容易被忽略又不会抢占任务理解的空间。它更像一道紧箍咒在模型准备“输出建议代码”的时候兜住它。我的经验是模板不需要每次对话都用 100% 完整的原文。像交互级模板我常用的一段精简前置提示是这样的你是我的代码助手。在本次对话中 1. 先理解问题再动手方案设计 2. 设计通过后列出改动文件清单等我确认后开始写代码 3. 写代码时遵循 CLAUDE.md 中项目规范 4. 写完后简要说明改动内容和影响这段内容虽然短但四句话覆盖了角色、流程、规范和交付要求效果比一段冗长的万能提示词更好。4.2 模板与工具、子代理的配合机制Claude Code 不只是文本交互界面它有大量工具调用能力比如执行命令、读写文件、搜索代码库。模板需要显式地控制这些工具的边界否则它会在错误时机调用工具。在代码审查模板里我写的是“你只能提出建议和发现缺陷不得直接修改代码”但我们都知道审查是需要查看代码、搜索定义的。所以另一个边界约束也必不可少“你可以调用工具来获取上下文但最终输出只能包含审查意见”。显式区分“允许获取信息”和“不允许修改文件”两件事才能达到预期效果。对于更复杂的任务比如重构跨模块的代码我使用子代理的思路把模板拆成“主流程模板 子任务模板”。这个做法像团队分工一个代理负责规划另一个代理负责具体实施一个代理专门做验证。模板库相当于给它们各发了一本岗位手册避免彼此越权。4.3 上下文管理的边界模板不是越长越好这是我最想强调的实战经验。模板库有个天然冲动是往里面堆内容今天想到一条规则加一条明天看到一次错误输出又加一条。结果是模板越来越长效果越来越差。我的上限是以单次任务能完整喂给模型且不挤占任务本身空间为准。实测下来一份任务级模板的合理篇幅在 500 到 800 字之间超过这个长度模型的遵循度会显著下降。因为模板内容本身会占据注意力资源这就像一个会议开场前念了十分钟免责声明真正开议的时候听众早就疲惫了。为了控制模板膨胀我给自己定了一条规矩模板里只保留“写错了会花很长时间回来修”的规则。锦上添花的建议、可写可不写的风格调整全部删除。宁可少一条规则也不要让关键规则被淹没。4.4 版本管理与团队共享经验模板库的演进不能靠记忆。我始终强调用 Git 管理不是形式主义是真的有这个需求。举一个真实案例我们有次做安全专项审查临时在代码审查模板里加了“必须检查认证与授权逻辑”的专项维度。那次的效果特别好但如果没有版本管理这个临时改动就会被淹没在模板的历史里下次安全专项时又得重新想起来。因为模板库有 Git 历史我现在可以轻松回溯那个版本或者通过合并请求把这条专项维度合并进正式模板。团队协作时模板库的作用更加放大。我建议在团队内建立“模板评审”机制每个人都有权限提交模板变更但至少要有一个人负责归口管理防止互相冲突的规则同时被打进代码里。这跟代码仓库的评审流程是一个道理。5. 常见问题与排查技巧实录5.1 模板明明写了却不生效这是出现频率最高的问题。排查顺序我一般是这样的先检查模板有没有被正确加载。你用claude --print直接运行的话模型拿到的内容就是你在命令行里输入的内容不会自动去读 CLAUDE.md 之外的模板文件。你以为的“写了模板应该自动生效”在很多时候是不成立的。CLAUDE.md 会被自动加载但放在task/目录下的文件不会你必须通过引用、粘贴或脚本拼装让它进入上下文。再检查模板内容是否和上下文冲突。有一次代码审查模板不生效我排查了半天发现是 CLAUDE.md 里写了一句“你是一个乐于助人的编程助手”这句全局角色设定中和了审查模板的“不得修改代码”约束。修复方式是在 CLAUDE.md 里删掉冲突内容。最后检查是不是参数没拼对。比如我脚本里的sed替换遇到 diff 内容里包含特殊字符导致模板变量没被正确替换喂给模型的还是一堆{{DIFF}}。后来我改用 Python 脚本做模版拼接这类问题就消失了。5.2 模板之间的角色冲突项目级模板写“你是一个后端开发专家”任务级模板写“你是一位严格的代码审查员”两个角色有冲突时模型有时候会摇摆不定输出一会儿是开发者的口吻一会儿是审查者的口吻。解决思路是给角色设定一个优先级。我会在 CLAUDE.md 里加一句# 角色优先级 当任务模板定义了具体角色时以任务模板的角色为准未定义时才使用项目级角色。CLAUDE.md 的指令优先级本来就足够高这样写在逻辑上很顺。事实上模型的指令遵循有就近原则任务级模板的权重天然高于项目级模板但显式声明优先级可以降低角色混乱概率。5.3 模板内容被截断或覆盖长模板加上大段 diff很容易把上下文窗口撑爆。对策有两个方向压缩模板体积或者拆分任务。压缩方向我把输出格式做了简化比如审查模板的输出格式从七八个详细字段压缩成“级别 位置 一句话建议”的紧凑列表。很多格式上的花哨描述都是冗余压缩之后的模板语义几乎没有损失。拆分方向把大任务切成两个阶段。比如重构任务先跑规划模板得到计划确认后再单独跑实施模板不让两套指令同时占据上下文。这两个阶段各用各的模板上下文干净模型注意力集中。5.4 维护时机模板库什么时候值得更新模板库不应该是写一次就完事的东西。我的经验是每次“对话失控”之后不是去怪模型而是去问模板库缺了什么。如果 AI 这次搞错了项目技术栈说明项目级模板缺了技术栈说明如果它这次越界改了不该改的测试文件说明负面约束里缺了“不得修改测试文件”这条如果它这次的输出格式不符合要求说明任务模板的输出格式写得不够明确。把每次失败当成一次模板迭代的契机模板库就会越来越接近你的真实工作方式。我现在的维护频率大约是一周调整一次每次只改一发小步快跑。长期积累下来这个习惯带来的效率收益远超过写模板本身的投入。6. 我踩过的坑与最终心得6.1 第一个坑迷信“万能模板”我一度试图做一份“万能模板”把角色、规范、审查、测试、计划全部塞进一个文件里。结果每一次使用都像在开一场混乱的会议规则太多反而无从执行。后来我把它拆成独立的专项模板整体体验立刻改观。合理的模板不是一把多功能瑞士军刀而是一套工具箱每样工具解决一类问题。6.2 第二个坑拿模板当任务清单而不是行为约束其实模板本身写什么决定了你在跟 AI 协作时是“发号施令”还是“确立规则”。前者是授权它执行一串指令后者是给它一个决策框架。我的模板大量使用“如果……则……”的句式体现的正是行为逻辑比如“如果需求不明确则输出存疑清单再开始”这样模型在遇到同类分支时能自主做出决策。6.3 模板是一种投资而不是成本如果把模板当成每次对话的负担那你很难坚持下去。但把它当成一次投资就完全不一样了。我现在每次新建一个项目花二十分钟写一份 CLAUDE.md这项工作会在后续每一次与 Claude 的协作中自动复利。随着时间拉长我发现模板帮我省下的不只是打字时间更是大量“把思路理清楚重来一遍”的心智损耗。6.4 最后分享我的一个实用小技巧不管什么类型的模板我建议在末尾留一节“完成后的回顾”。也就是让 Claude 输出任务结果的同时自答三个问题本任务中哪些地方符合预期哪些地方你觉得可以做得更好下一轮模板有哪些值得更新的规则。这样一个简单的小节让模板库实现了自进化每一次使用可能都是在优化它自身。现在的我越来越不关心“怎么写一段更好的提示词”这件事因为我发现真正的问题是“怎么建立一套稳定的协作框架”。claude-code-templates 这个方向的核心价值正是把一次次临时交互沉淀成体系让 AI 协作从碰运气变成确定性高的常规流程。希望这篇总结能给你一些实操思路也欢迎你踩过更多坑之后再回来看看这份模板库那时候你会真正理解我为什么说它值得投入时间去构建。