Claude Code模板库实战：从重复劳动到AI编程自动化

我做 Claude Code 模板库这件事起因其实特别朴素同一个项目里的代码审查、模块重构、质量巡检我每天都要对着终端重复输入差不多的指令换汤不换药。最开始还能接受觉得自己写 Prompt 写得挺溜直到连续几天被同一个问题折腾——每次新开会话模型都要重新理解一遍我的代码规范、目录结构、测试命令输出质量忽高忽低上下文一长就开始忘。后来我干脆把这一整套重复劳动沉淀成了claude-code-templates这个模板库把高频操作变成可复用的命令、参数化模板和固定的执行流程。这篇文章就完整拆解一下这个模板库的设计思路、核心实现、踩过的坑以及从无模板到有模板之后的一组真实对照数据希望能给你一个可以直接照抄的参考。模板这个东西说白了就是给 Claude Code 这类命令行 Agent 编程工具用的干活的规矩。它的价值不是让你少打字而是让模型把你最熟悉的业务动作从每次都要重新解释一遍变成调用一次就按标准流程走把那些靠临场发挥解决不了的问题变成靠流程设计解决掉。不管你是个人开发者在自己的仓库里折腾还是团队想统一 Agent 协作的规范这套模板库的思路都能用。1. 从重复说明到一键复用模板要解决的真实问题1.1 Claude Code 给编程工作流带来了什么Claude Code 本质上是一个跑在终端里的编程助手它可以读你仓库里的文件、改代码、执行命令、跑测试甚至自己完成 git 提交。跟直接在对话里贴代码问问题不一样它能直接操作整个项目。听起来很强大但这也带来一个新问题你没法用一句帮我重构一下 payment 模块就完事因为它的上下文再大也不了解你项目里的全部背景。你需要在每次会话开始时把大量背景知识塞给它否则它就按通用套路来产出离项目实际情况很远。我最早就是这么用的每次开会话先写一段很长的背景说明再描述任务。短任务还好任务一复杂就崩崩得最狠的时候是它改完代码直接告诉我改好了我一看测试全红还把别的模块给碰坏了。当时我就意识到问题不在模型能力而在我给的指令太过自由缺少结构化的约束。1.2 没有模板的时候一段典型的浪费场景举一个很有代表性的场景我之前在一个内部项目里做数据迁移涉及一个 8000 多行的 Python 模块里面全是手写 SQL 拼接和旧 API 调用准备重构到新的 DB 访问层。没有模板的流程是这样的第一轮对话我花十分钟写背景告诉它项目结构、模块位置、测试命令、重构目标第二轮它给出一个大而全的重构方案覆盖十几个文件第三轮我发现方案里有一半不符合项目现有约定需要逐条解释第四轮它开始改代码改到一半上下文被撑爆忘记最开始约定的边界条件第五轮我重新补充背景它重新理解然后又在同一个问题上重复犯错。整场下来光是让模型理解背景就消耗了大量轮次和 token真正干活的时间反而没多少。更麻烦的是同样这个重构任务隔一周再执行过程完全不具可复现性上次总结出来的经验教训全丢光了。于是我开始琢磨能不能把背景信息、执行步骤、约束条件、输出格式这些固定不变的部分抽出来做成模板每次调用时只需传入具体目标模块其余都是自动化的。1.3 模板的本质把稳定流程和变化内容切干净做模板库之前我一直以为模板就是写得更好的 Prompt做完了才发现它其实是一次工作流拆解。真正有价值的模板不是把话说得多漂亮而是把整个任务拆成两块稳定不变的部分代码规范、测试命令、评审标准、目录结构、安全注意点、报告格式。这一块放模板里写一次永远生效100% 稳定。变化的部分本次要处理的具体模块、要迁移的具体接口、要修的 bug 编号。这一块通过参数注入模板。这个拆分逻辑决定了模板的通用性。稳定部分写得多覆盖面就广但代价是模板内容长、占用上下文多变化部分设计得好单个模板可以适配各种任务不用每个任务单独新建模板。我在这套模板库里的原则是稳定部分只写跨项目通用的方法论项目专属信息放进CLAUDE.md或者通过变量注入模板本身保持纯净。2. 模板库的顶层设计目录、命名与职责边界2.1 目录结构让模板像工具库一样好检索我在仓库里用的结构是这样的claude-code-templates/ ├── templates/ │ ├── source/ │ │ ├── review.md │ │ ├── refactor.md │ │ ├── design.md │ │ ├── audit.md │ │ └── migrate.md │ └── variables.yaml ├── scripts/ │ └── render_templates.py ├── .claude/ │ └── commands/ │ ├── review.md │ ├── refactor.md │ ├── design.md │ ├── audit.md │ └── migrate.md ├── tests/ │ └── golden_samples/ └── README.mdtemplates/source是源文件里面允许存在{{ 变量 }}方便参数化。scripts/render_templates.py负责渲染把变量替换后生成到.claude/commands这样 Claude Code 就能直接把这些文件当作斜杠命令调用。之所以搞两层而不是直接编辑commands目录是因为源文件可以被变量控制不同项目渲染出不同版本的命令但源文件只有一份便于维护。tests/golden_samples是回归样本集这个后面单独说。如果你不做变量渲染直接把写好的 Markdown 文件扔到.claude/commands也能用少一层反而更轻量。严格来说这两套方案没有绝对优劣看你是个人用还是团队用。2.2 命名与版本管理模板也要能追溯模板命名我统一用的是动词 对象的格式review评审、refactor重构、design方案设计、audit巡检、migrate迁移。这套命名的好处是命令语义清晰调用时看到斜杠命令就知道是干什么的不会出现v2_final这种灾难。模板的版本管理走的是 git。每当我们调整一个模板的执行步骤或约束条件这个改动本身要像代码一样被 review、留痕、可回滚。用模板的时候最怕一种情况团队里有人私下改了自己的本地模板跑出来的效果跟其他人完全不一样这其实已经不是在用模板而是在开盲盒。版本管理解决的正是这个问题所有变更集中到一个仓库大家 clone 同一份各自的差异只通过变量配置体现。2.3 模板文件里的公共骨架我观察到一个现象好的模板和差的模板在文件结构上差别非常明显。差的模板是一大段散文式描述好的模板一定是有明确骨架的。我用的公共骨架是五段式角色与目标让模型明确自己此时扮演什么角色、这项任务的最终验收标准是什么输入参数列出本次任务需要传入的变量比如目标模块路径、测试命令、分支名执行步骤按顺序排列的、可执行的步骤清单每一步都要有明确产出硬性约束模型绝对不能做的事比如不要跨文件修改不要自动安装依赖输出格式规定最终交付物的格式比如评审报告要有表格、重构要有每步的 diff 摘要。这套骨架的价值在于它把自由发挥的空间压缩到执行细节上把方向、边界、交付标准都锁定死。模型再笨按照这个骨架执行产出也不会跑太偏如果骨架本身设计得有问题那也是可修正的不会像自由对话那样每次都是全新的混乱。3. 五个高频场景模板的完整实现3.1 变更评审模板 /review先判断影响面再动代码代码评审是我用得最多的场景。它最大的痛点是模型经常拿到一行 diff 就埋头找毛病忽略整体影响面。我设计的review模板强制执行三段式# 变更评审 /review ## 角色与目标 你是一名资深代码评审员。你的目标是对当前已有的变更进行完整、客观、可执行的评审而不是替开发者重写代码。 ## 输入 - 变更范围{{ change_scope }}默认当前分支相对 {{ default_branch }} 的差异 - 评审深度{{ review_depth }}可选quick / medium / deep默认 medium ## 执行步骤 1. 先读取变更范围内的文件清单和整体 diff输出影响面分析 - 变更涉及哪些文件 - 是否有对外接口、数据结构、公共依赖发生变更 - 是否有测试文件同时更新如果没有标注为风险点。 2. 再逐项检查具体问题按以下优先级排列 - 安全相关敏感信息、注入风险、越权访问、错误的认证判断 - 正确性边界条件、空值处理、并发问题、异常捕获后是否吞掉错误 - 可维护性命名、魔法数字、重复代码、死代码。 3. 输出评审结论。 ## 硬性约束 - 只做评审不直接修改代码 - 每个问题都必须标注文件、行号、严重程度P0/P1/P2和具体建议 - 不确定的问题标注待确认不要用猜测语气下结论。 ## 输出格式 ### 影响面分析 - 文件清单与影响范围简述 - 测试覆盖情况 ### 问题列表 | 严重程度 | 位置 | 问题描述 | 建议 | | P0 | xxx.py:42 | ... | ... | | P1 | xxx.py:78 | ... | ... | ### 结论 - 通过 / 需修改 / 需讨论 - 如需修改列出最关键的 3 个问题这个模板改过我四版最初没有影响面分析这一步模型上来就盯着具体代码找 bug经常会抓住一个非关键变量命名说半天真正影响上线安全的 P0 问题没发现。加了第一步之后它先看全局再落细节有效多了。另外我不让它直接改代码因为评审和修改这两个职责混在一起时模型会倾向这里不好我帮你改掉一下子引入大量无关变更评审结果完全失焦。3.2 模块重构模板 /refactor把大改动切成可回滚的小步重构模板是我做完之后收益最大的一个。此前让模型重构模块最怕的就是它一口气改十几个文件改完全盘崩盘连它自己都说不清楚哪一步引入的问题。所以这个模板的核心设计是小步走、每步验证# 模块重构 /refactor ## 角色与目标 你是本次重构的执行者。核心目标是在不改变外部行为的前提下完成指定模块的重构。外部行为是否保持以测试命令是否通过为判断标准。 ## 输入 - 目标模块{{ target_module }} - 测试命令{{ test_command }}默认 pytest -x -q - 允许的行为变更{{ behavior_changes }}默认无 ## 执行步骤 1. 阅读目标模块全部代码输出一份现状地图 - 模块内函数清单及职责 - 已识别的坏味道列表重复代码、超长函数、全局状态、硬编码常量 - 改动优先级排序。 2. 开始逐个小步重构每步必须满足 - 单步改动不超过 200 行 - 每完成一步立即执行测试命令 - 测试失败时回退到上一步绝不带着失败进入下一步。 3. 全部分完成以后输出最终报告。 ## 硬性约束 - 禁止跨文件连锁修改。确需修改其他文件的先列出依赖关系单独用一次命令处理 - 禁止改动公共接口签名除非 {{ behavior_changes }} 明确允许 - 禁止删除任何被测试覆盖但未理解用途的代码 - 不做与本次重构目标无关的格式化特别是不要在重构过程中顺手格式化整个文件。 ## 输出格式 ### 规划摘要 - 现状地图关键结论 - 分步计划 ### 执行记录 | 步骤 | 改动摘要 | 测试结果 | 备注 | | 1 | 抽取 SQL 构建函数 | 通过 | - | | 2 | 移除魔法数字 | 通过 | - | ### 最终报告 - 完成度 - 剩余风险 - 建议后续处理项这个模板里最有价值的一条约束是禁止在重构过程中顺手格式化整个文件。我踩过这个坑让模型重构的同时顺手把一段代码改成符合它审美的新写法结果 diff 里混进了大量无关格式变化真实业务逻辑改动反而被淹没。后来的经验就是重构动作必须和格式化动作分离一次命令只干一件事。3.3 技术方案模板 /design让 Agent 产出可选方案而不是自作主张技术方案设计这一类任务最大的风险不是模型写得不好而是模型太自信。让它设计一个订单超时取消的方案它往往会一口气选定一个方案然后给你讲这个方案有多好根本不给你比较和权衡的机会。design模板就是专门治这个毛病的# 技术方案设计 /design ## 角色与目标 你是一名技术方案设计师。你的目标是围绕给定问题产出至少 2 个可选方案并基于明确的标准给出推荐而不是直接决定唯一方案。 ## 输入 - 问题定义{{ problem_statement }} - 约束条件{{ constraints }}性能、成本、人力、兼容性等 - 推荐偏好{{ preference }}比如偏保守 / 偏重构 ## 执行步骤 1. 先澄清问题列出你对此问题的理解、不确定点、需要补充的信息。 2. 设计 2-3 个方案每个方案必须包含 - 核心思路 - 改动范围 - 成本评估开发、测试、迁移 - 风险点 - 可回滚性 3. 用对比表格汇总各方案差异。 4. 给出推荐方案并说明推荐理由和放弃其他方案的理由。 ## 硬性约束 - 不得在未经过方案比较之前直接给出唯一结论 - 每个方案都要说明可回滚性无法回滚的方案必须标注高风险 - 成本评估必须用相对量低 / 中 / 高而不是编造具体工时。 ## 输出格式 - 问题澄清 - 方案对比表格 - 推荐结论与理由这个模板的巧妙之处是它把决策和探索分离了。模型负责把方案和代价铺开人来拍板。Agent 工具再聪明它也没有你的业务上下文和团队政治判断力所以别让它替你决定方向。用这个模板产出的方案文档可以直接拿到团队评审会上作为讨论底稿非常省事。3.4 质量巡检模板 /audit固定检查项 优先级上报巡检这件事特别适合模板化因为它的检查项是高度稳定的。audit模板直接内置一套固定检查清单模型不需要思考该检查什么只需要按图索骥# 质量巡检 /audit ## 角色与目标 你是一名代码质量巡检员。基于固定的检查项对目标目录或模块进行巡检输出按优先级排序的问题列表。 ## 输入 - 目标范围{{ audit_target }} - 附加检查项{{ extra_checks }}可选 ## 固定检查项 1. 未处理的异常裸 except、忽略异常 2. 敏感信息硬编码API Key、密码、token、连接串 3. 公共函数缺少类型标注 4. 单函数超过 300 行 5. 重复字符串常量 6. 明显的性能风险循环内查询、N1 查询、无索引字段过滤 7. 死代码未被引用的函数、变量 ## 执行步骤 1. 根据目标范围递归读取文件 2. 逐项对照固定检查项扫描 3. 对每个问题判断严重程度 4. 输出巡检报告。 ## 硬性约束 - 只报告代码中确实存在的问题不进行代码修改 - 不做代码风格类的主观评论比如这个命名不够优雅除非它有实际可读性风险 - 重复问题合并上报不逐行重复列举。 ## 输出格式 ### 巡检汇总 | 优先级 | 位置 | 问题类别 | 具体描述 | 建议修复方案 | | P0 | src/db.py:15 | 敏感信息硬编码 | 数据库密码写死 | 改用环境变量注入 | ### 统计 - 检查文件数N - 发现问题数NP0/P1/P2 各多少 - 建议优先处理项这个模板的意义在于消除随机性。同一段代码不带模板让模型巡检每次报出来的问题可能差很远带模板模型的注意力被锁在固定检查项上报告结构也稳定方便接入自动化流程做趋势分析。我后来甚至用它定期对老项目做巡检把结果归档到文档里大版本升级前翻一眼心里就有底了。3.5 存量迁移模板 /migrate锁死版本与兼容边界最后一个高频场景是存量代码迁移比如把旧 ORM 迁移到新 ORM或者把一种 API 风格替换成新风格。这个任务最怕的是模型在迁移过程中顺手优化其他东西导致迁移 diff 里混入大量无关逻辑变化。migrate模板的核心就是锁死边界# 存量迁移 /migrate ## 角色与目标 你是本次迁移的执行者。任务是把指定范围从旧实现迁移到目标实现迁移过程中不允许改变任何非必要的业务行为。 ## 输入 - 迁移范围{{ migration_scope }} - 旧实现模式{{ legacy_pattern }}例如session.query(User).filter_by(...) - 目标实现模式{{ target_pattern }}例如select(User).where(...) - 排除规则{{ exclude_rules }}可选需要跳过的文件或路径 ## 执行步骤 1. 统计迁移范围内匹配旧实现模式的全部位置输出清单 2. 按文件逐个迁移每完成一个文件执行一次相关测试 3. 迁移完成后全量执行测试命令 {{ test_command }} 4. 输出迁移报告。 ## 硬性约束 - 只允许做模式替换和必要的结构性修改禁止修改此范围内的业务逻辑 - 禁止顺手重构迁入文件中的其他无关代码 - 遇到使用模式复杂、无法简单替换的位置保留原状并记录在报告中不得猜测改写 - 一个文件迁移完成后diff 范围内不得出现与迁移无关的格式化差异。 ## 输出格式 ### 迁移清单 | 文件 | 命中位置数 | 已完成 | 失败/跳过原因 | |---|---|---|---| | src/xxx.py | 12 | 是 | - | ### 未处理项清单 | 文件:行号 | 原因 | 建议 | |---|---|---| | src/yyy.py:88 | 涉及动态生成的查询条件 | 人工确认后再处理 | ### 最终结论 - 测试通过情况 - 剩余风险用这个模板跑过一次用户表查询迁移印象最深的是遇到复杂位置保留原状并记录这条。最初版本模板没有这条模型在遇到一个涉及动态条件的查询时直接按照模式匹配硬改把语义改了测试挂得一塌糊涂。加了这个约束以后模型会把拿不准的位置记录下来留给人工判断从源头规避了大部分迁移事故。4. 模板工程化上下文控制、成本核算与回归验证4.1 上下文是一切问题的隐藏根源模板不是写得越长越好。我踩过最大的坑就是模板写太详细命令一执行模板本身占掉大量上下文真正留给代码分析的上下文就被压缩了。模型不是机器它的注意力资源是有限的上下文里塞满了规则它就没有余力去处理代码细节了。所以模板工程化的一个核心工作是控制模板自身的长度。我那五个模板每个都在 30~60 行以内只保留真正的执行关键点。比如refactor模板里我就没写遵守 PEP8保持代码整洁这种废话因为这类指令对模型来说属于低价值的宽泛约束起不到实际作用反而占据空间。还有一个容易被忽略的点模板里所有涉及路径、命令、变量名的部分要确保能正确解析。如果模板里写了一个项目里不存在的测试命令模型会一本正经地尝试执行然后报错你就得花额外轮次让它纠正。我的做法是把这些值全部做成变量渲染时从项目的配置文件统一注入这样至少不会有拼写错误。上下文控制还有一个层面让模型按需读取文件。模板里我会明确限定只读取audit_target指定目录下的文件不要扫描 tests 之外的目录这比让它无限探索仓库高效得多。对于一个大型 monorepo这一步的 token 成本差异非常大不限制的话模型可能扫十几个模块才找到需要的内容。4.2 模板的回归测试与黄金样本模板本身也需要测试。如果模板改了执行顺序换了一个约束条件怎么知道它对任务的实际效果提高了还是降低了我的方案是做一组黄金样本挑 3 到 5 个有代表性的历史任务把任务描述、输入参数、期望的输出形态记录下来放在tests/golden_samples里。每当我调整模板就拿着黄金样本重新跑一遍重点观察模型是否完整遵循了模板中的步骤顺序输出结构是否符合模板规定的格式硬性约束是否被遵守比如review模板里不修改代码这条有没有出现模板改动之前没有的新问题。这不是自动化测试而是一套人工对照的回归验证流程。但它带来的安全感是无价的以前改模板全凭感觉现在我可以明确说出这个版本的回退率比上个版本低。如果想让这个过程半自动化可以在模板中加一段校验输出格式的步骤让模型自己检查输出是否符合模板定义的 Markdown 结构检测到偏差就修正后再输出。我把这套自检逻辑加进了review和audit模板实测能减少大概一成的格式错乱。4.3 团队协作场景下的模板版本管理如果只是自己一个人用模板那 git 仓库管理其实可有可无。但团队用起来问题就不一样了。模板的价值在于统一行为一个团队如果每个人手里都是不同版本的模板那就等于没有模板。我们在团队里的做法是模板仓库独立存放作为所有成员共享的一个基准。每个成员在自己的项目里通过一个variables.yaml声明专属配置渲染时合并默认模板和项目配置。修改模板本身必须走 PR 流程由固定的一个人 review因为模板的改动影响面是所有项目不能随手改。这里要提醒一下模板文件里不要写具体的人名、具体的项目代号这类信息。通用模板要刻意保持干的状态所有项目相关的东西都通过变量注入。一旦模板里混入单个项目的特殊信息它就会慢慢从通用工具变成某个项目的专属脚本适配能力直线下降。我见过一个团队的模板里面直接写了另一个团队的项目代号和目录名新成员拿到手一头雾水这就是模板被污染了。5. 一组真实项目数据用模板前后的差距5.1 对照样本与观测方式数据来自我实际维护的一个老项目一个 8000 多行、混合了 SQLAlchemy 旧查询方式和大量手写 SQL 的 Python 模块。任务是把其中一组核心查询迁移到新的查询接口并在迁移过程中修复两个已知的边界条件问题。我做了一个简单的对照先完全不使用模板用传统的方式跟 Claude Code 对话完成这个任务两周后用migrate模板配合review模板做一次同样的迁移。两次任务的目标完全一致模型也是同一个版本。当然这不是严谨的控制变量实验两次之间我的理解也更深了但数据趋势仍然很有参考意义。5.2 三个关键指标的对比指标无模板用模板完整交互轮次23 轮9 轮人工明确纠偏次数6 次2 次单步测试通过率40%90%完成耗时约 2.5 小时约 1 小时无模板那一次的 23 轮里有大概 6 轮是在反复澄清背景、重新解释项目结构和目标用模板之后这些解释全部被模板和变量覆盖掉了模型的关注点全程集中在迁移本身。单步测试通过率的对比是最有说服力的。没有模板时模型习惯一次改一大片再跑测试一失败就回到起点重新理解这种工作方式既浪费 token 也浪费我的耐心。而migrate模板里明令一个文件迁移完立即测试模型被迫采用小步快跑策略问题在产生时就被发现了。5.3 模板的适用边界数据看着不错但必须诚实地讲一下模板的适用边界。模板最适合的是结构化程度高的任务评审、重构、巡检、迁移、数据验证这些任务的流程是可描述的、步骤是可预期的。如果任务属于探索性质比如帮我研究一下这个新框架的某种能力或者看看这个仓库里有没有值得借鉴的设计模式模板的价值就很有限甚至可能帮倒忙——因为模板会把模型约束在固定流程里限制它自由探索的空间。还有一个边界是模型本身的能力。模板是把稳定流程固化下来但执行质量的底线还是取决于模型对代码的理解能力。如果模型根本读不懂某个文件的逻辑再好的模板也只是让它按错误的方式更高效地犯错。所以我的建议是模板不能替代你选择模型版本的决策但能让模型的不同版本之间协作体验更稳定。6. 常见问题排查与避坑技巧6.1 模板失效的四种典型原因用纯模板跑了很多次以后我把遇到过的模板突然不好使了的情况归纳成四类第一类模板变量渲染失败。模板里写了{{ test_command }}但渲染脚本没定义这个变量模型就直接把{{ test_command }}当成字符串执行结果跑出一个不存在的命令。排查方法很简单渲染完成后打开commands目录里的最终文件扫一遍有没有残留的花括号模板变量。第二类上下文过长导致模板尾部指令被忽略。模型上下文被大量代码内容占满之后模板里写在后面的硬性约束和输出格式部分容易被稀释模型就漏掉了关键约束。对策是把最关键的硬性约束尽量往模板前面放或者单独作为一条不可省略的简短指令紧跟输入之后。第三类模板被项目特有信息污染。模板里混入某个项目的具体路径或命令之后换一个项目根本没法用而且你还不容易察觉。我给自己的检查标准是每过一两个月审视一遍模板凡是出现具体文件路径、具体模块名、具体工具链的内容一律改成变量。第四类模型版本更迭导致风格不匹配。换一个新版本模型之后模板里的某些指令风格可能不再被严格执行比如新模型更倾向于详尽输出把原本很简洁的表格撑得巨长。碰到这种情况需要对模板做一次回归验证而不是默认以前能用现在也一定能用。6.2 排查问题的方法与顺序如果你发现某个模板跑出来的效果不对劲我建议按这个顺序排查基本能覆盖大部分问题先看最终渲染产物。打开.claude/commands下的对应文件确认变量是否正确替换、有没有残留模板语法。再确认模板本身是否完整。有时候编辑模板时语法错误比如表格的分隔线少了模型解析出来就是一个普通段落输出格式完全失效。然后检查上下文是否超限。可以通过观察模型是否有忘了约束的倾向来判断如果前半段执行很好、后半段开始跑偏大概率是上下文压力导致的。最后考虑模型版本因素。把同样模板在旧版本上跑一次做对照如果旧版本正常而新版本异常那就是风格不匹配问题需要微调模板指令的措辞。6.3 我踩过之后才明白的几个设计原则原则一模板里的禁止事项比建议事项更值钱。模型跟人一样给它十个应该做什么它可能每个都做一点给它三个绝对不要做什么执行效果反而清晰。我的模板里每条硬性约束都是可验证的比如禁止跨文件修改禁止改动接口签名而不是抽象的请保证代码质量。原则二输出格式要具体到可以直接粘贴。模板里定义输出表格时我会把表头直接列出来模型就会照着这个结构走。如果你只是说请用表格输出它可能给你来一个没有任何列的文本列表格式形同虚设。原则三模板的执行步骤要按依赖关系排序。先全局、后局部先分析、后动作。这个排序逻辑在review和refactor模板里都死死锁着。一旦顺序乱了输出的价值就大打折扣。原则四不要追求一个模板解决所有问题。我最初也尝试做一个万能模板结果它因为约束太多变得非常僵化简单任务也走重流程反而拉低效率。后来回到高频场景独立模板的路子才回到正轨。每个模板专注一个职责哪怕职责比较窄也没关系因为组合使用多个模板比一个重模板灵活得多。最后说点个人体会。做这个模板库最大的收获不是省了多少时间而是让我从每次跟模型对话都是一次碰运气变成了每次对话都是按既定流程执行。模板的本质不是限制模型而是把你自己之前的成功经验、失败教训、踩过的坑都固化下来让每次执行都站在上一次的肩膀上。如果你也想做自己的模板库我的建议是不要一开始就想着做一套大而全的东西从你日常重复最多的那个操作开始先做第一个模板把它用熟、测透再慢慢扩展。一个能稳定解决你 80% 重复工作的模板库比一个覆盖所有场景但每个都跑不稳的模板库强太多了。