Claude Code 提示词模板包：修 Bug、写功能、重构、测试全覆盖

Claude Code 真正好用，不是因为你会问“帮我写代码”，而是因为你能把任务目标、项目上下文、约束条件、验收标准和输出格式讲清楚。对于修 Bug、写功能、重构和测试这四类高频任务，提示词越结构化，Claude Code 越容易给出可审查、可验证、可回滚的代码改动。

本文整理一套可以直接复制使用的 Claude Code 提示词模板包，覆盖 Bug 修复、新功能开发、代码重构、测试补齐、代码审查、日志排查和 PR 总结。模板默认遵循“先分析、再计划、确认后修改、最后验证”的工程节奏。想先搭好环境的读者，可以查看本站 环境配置教程 和 安装部署教程；遇到执行失败，可以继续参考 问题排查教程；想把模板放进团队流程，可以看 实战工作流。

摘要

Claude Code 提示词最重要的不是措辞华丽，而是任务边界清楚。修 Bug 时要提供现象、复现步骤、错误日志、预期结果和禁止扩散的限制；写功能时要提供用户场景、接口约束、数据结构、兼容要求和验收标准；重构时要强调行为不变、分批迁移、保留 API、补充测试和输出风险；测试任务要明确测试类型、覆盖路径、失败用例、运行命令和最终结论。本文给出的模板都可以直接复制，根据项目替换方括号内容即可使用。

正文

使用模板前，先给 Claude Code 四类信息

一个稳定的提示词通常包含四类信息：目标、上下文、约束、验收。目标说明你要解决什么问题；上下文说明相关文件、报错、业务规则和已有实现；约束说明不能改什么、不能删除什么、不能引入什么依赖；验收说明怎么判断任务完成。缺少任何一类，Claude Code 都可能写出“看似完成、实际不可交付”的代码。

通用开场模板：
你现在在一个已有项目中工作。
任务目标：[写清要完成的结果]
相关上下文：[文件路径 / 错误日志 / 业务规则 / 接口说明]
限制条件：
- 不要修改无关文件
- 不要读取或输出 .env、密钥、生产配置
- 不要删除线上数据或迁移生产库
- 先分析并给计划，等我确认后再改文件
验收标准：
- [测试命令] 能通过
- [关键场景] 行为正确
- 输出修改摘要、风险点和验证结果

修 Bug 模板：先复现，再定位，再最小修复

修 Bug 最怕提示词只有一句“这里报错了，帮我修”。Claude Code 可能会根据表面错误改一堆无关代码。更好的方式是把现象、复现路径、错误日志、期望行为、影响范围和修改限制写清楚，让它先做根因分析。

请帮我修复一个 Bug，但先不要修改文件。

问题现象：
[描述用户看到的问题]

复现步骤：
1. [步骤一]
2. [步骤二]
3. [步骤三]

实际结果：
[当前错误表现]

预期结果：
[正确行为]

错误日志：
[粘贴脱敏后的日志]

限制条件：
- 只修改与该问题直接相关的代码
- 不重构无关模块
- 不改变现有 API 返回字段
- 不读取或输出密钥

请先输出：
1. 可能根因
2. 需要检查的文件
3. 最小修复方案
4. 需要补充或运行的测试
等我确认后再修改。

确认方案后，可以继续给第二段执行提示词：

按刚才确认的最小修复方案修改代码。
修改后请：
1. 运行相关测试：[测试命令]
2. 如果测试失败，先分析失败原因，再做最小补丁
3. 输出变更摘要
4. 输出验证结果
5. 列出仍需人工检查的风险点

写功能模板：把需求变成验收标准

新功能开发需要比 Bug 修复更多的业务约束。如果只说“加一个导出功能”，Claude Code 不知道导出哪些字段、权限怎么判断、空数据怎么处理、文件格式是什么、失败时如何提示。提示词应该把需求拆成用户场景、输入输出、权限、异常、兼容和验收标准。

请帮我实现一个新功能，先分析方案，不要立即改文件。

功能名称：
[功能名]

用户场景：
[谁在什么页面，为了解决什么问题而使用它]

功能要求：
- [要求一]
- [要求二]
- [要求三]

输入与输出：
- 输入：[参数、表单、请求体]
- 输出：[页面变化、API 响应、文件、状态]

兼容要求：
- 不破坏现有接口
- 不改变旧数据结构
- 保持现有权限逻辑

验收标准：
- [场景一] 应该 [结果]
- [场景二] 应该 [结果]
- 异常情况 [情况] 应该 [结果]

请输出：
1. 涉及文件
2. 实现方案
3. 数据结构或接口变化
4. 测试计划
5. 风险点
等我确认后再执行。

如果功能涉及前端、后端、数据库和权限，建议让 Claude Code 分阶段执行。先实现后端接口和测试，再接前端页面，再做异常处理和回归验证。这样每一步都能审查 diff，问题更容易定位。

重构模板：行为不变是第一约束

重构不是“把代码写得更漂亮”。工程上可接受的重构，必须保持外部行为不变，或者明确说明行为变化。Claude Code 做重构时，要先让它画出调用链、识别边界、列出风险，再分批执行。

请帮我重构以下模块，先不要修改文件。

重构目标：
[例如：降低重复代码 / 拆分过大的 service / 提取公共校验逻辑]

范围：
- 允许修改：[文件或目录]
- 禁止修改：[文件或目录]

硬性约束：
- 外部行为保持不变
- API 字段保持不变
- 不引入新依赖，除非先说明原因
- 不混入新功能
- 每次只做一类重构

请先输出：
1. 当前调用链和模块职责
2. 重构边界
3. 分批计划
4. 每一批如何验证
5. 最可能出错的地方
等我确认第一批后再修改。

重构执行时，建议每批都要求 Claude Code 输出“本批只改了什么、没有改什么、如何验证”。这能防止它把重构扩展成大范围重写。

执行第一批重构。
要求：
- 只做 [第一批目标]
- 不改业务行为
- 不新增功能
- 修改后运行 [测试命令]
- 输出 diff 摘要和验证结果
如果发现需要扩大范围，先停止并说明原因。

测试模板：不要只说“帮我补测试”

测试任务要明确测试层级。你要的是单元测试、集成测试、端到端测试，还是回归检查清单？不同测试需要不同上下文。提示词里还要说明已有测试框架、命令、关键路径、边界输入和历史 Bug。

请为以下功能补充测试，先分析测试计划。

功能范围：
[功能或文件]

已有测试框架：
[Jest / Vitest / PHPUnit / Pytest / Playwright / 其他]

需要覆盖：
1. 正常路径：[描述]
2. 空数据：[描述]
3. 异常输入：[描述]
4. 权限不足：[描述]
5. 历史 Bug 回归：[描述]

限制条件：
- 尽量复用现有测试工具和 helper
- 不改生产逻辑，除非发现代码不可测并先说明
- 不依赖真实外部服务

请输出：
1. 测试用例列表
2. 需要 mock 的对象
3. 测试文件位置
4. 运行命令
等我确认后再写测试。

测试写完后，再要求 Claude Code 运行测试并解释失败原因。不要让它为了让测试通过而降低断言质量。

请运行测试：[测试命令]
如果失败：
1. 先判断是测试写错、生产代码有 Bug，还是环境问题
2. 不要删除断言来绕过失败
3. 给出最小修复方案
4. 修改后重新运行测试
最后输出测试结果和剩余风险。

代码审查模板：让 Claude Code 先找风险

除了写代码，Claude Code 也适合做代码审查。审查提示词不要只问“这段代码怎么样”，而要指定关注点，例如安全、边界条件、性能、并发、兼容性、测试缺口和可维护性。

请对当前改动做一次代码审查，不要修改文件。

请重点检查：
1. 是否有行为回归
2. 是否有安全或权限问题
3. 是否遗漏边界条件
4. 是否破坏向后兼容
5. 是否缺少必要测试
6. 是否有过度设计或无关改动

输出格式：
- P0/P1/P2 风险列表
- 每个问题对应文件和原因
- 建议的最小修复方案
- 可以接受但需要人工确认的取舍

日志排查模板：把日志变成行动清单

遇到构建失败、测试失败、线上错误、CI 失败时，可以把脱敏日志交给 Claude Code，但要提醒它不要直接大范围修改。先让它定位错误来源，再给最小修复方案。

下面是一次失败日志，请先分析，不要修改文件。

执行命令：
[命令]

失败日志：
[粘贴脱敏日志]

请输出：
1. 第一处关键错误
2. 错误来自环境、依赖、测试还是业务代码
3. 需要查看哪些文件
4. 最小修复方案
5. 验证命令

如果信息不足，请列出还需要我提供什么。

PR 总结模板：让交付信息更清楚

当 Claude Code 完成修改后，不要只让它说“已完成”。最好要求输出适合 PR 或提交说明的摘要，包括改了什么、为什么改、如何验证、风险在哪里。

请根据当前 diff 生成 PR 总结。

输出：
1. 背景：为什么做这个改动
2. 主要变更：按模块列出
3. 验证：运行了哪些测试或检查
4. 风险：哪些地方需要 reviewer 重点看
5. 不包含：明确说明本次没有做哪些容易误解的事

要求：
- 不夸大结果
- 不编造测试
- 没有运行的测试标记为“未运行”并说明原因

团队通用模板：固定提示词，减少沟通成本

如果团队多人使用 Claude Code，建议把模板放进项目文档或内部知识库。统一提示词结构能让 AI 输出更稳定，也方便 reviewer 理解任务边界。你可以在项目中建立“任务模板、测试命令、禁止事项、PR 输出格式”四类规范。

团队标准提示词骨架：
任务类型：[修 Bug / 写功能 / 重构 / 测试 / Review]
任务目标：[一句话说明结果]
相关文件：[路径列表]
限制条件：[不能改什么，不能做什么]
执行方式：[先计划 / 确认后修改 / 分批提交]
验证命令：[测试或构建命令]
输出格式：[摘要 / 测试结果 / 风险 / 后续事项]

使用提示词模板时的安全规则

任何模板都不能替代工程判断。使用 Claude Code 时，至少要遵守这些规则：不要粘贴真实密钥，不要让 AI 默认读取 .env，不要自动删除数据，不要直接发布生产环境，不要跳过代码审查，不要把没有运行的测试写成已通过。

如果任务涉及权限、支付、账号、数据库迁移、生产配置和用户隐私，提示词中必须写清楚禁止事项和人工确认点。相关报错排查可以查看本站 问题排查教程，更多 AI 编程工具用法可以继续关注 AI工具最新动态 和 使用技巧教程。

一份最小可复制模板

如果你只想先保存一份万能版，可以用下面这段：

请作为谨慎的软件工程助手处理这个任务。

任务类型：[修 Bug / 写功能 / 重构 / 测试]
目标：[写清最终结果]
上下文：[相关文件、日志、业务规则]
限制：
- 先分析，不要立即修改
- 不修改无关文件
- 不读取或输出密钥
- 不删除数据
- 不直接发布
验收：
- [测试命令] 通过
- [关键场景] 正确

请先输出：
1. 你理解的任务
2. 需要查看的文件
3. 执行计划
4. 风险点
5. 验证方式
等我确认后再开始改代码。

FAQ

Claude Code 提示词越长越好吗？

不一定。提示词要结构清楚，不是越长越好。目标、上下文、约束和验收标准齐全，比堆很多形容词更有用。

修 Bug 时为什么要先让 Claude Code 分析，不直接改？

因为很多 Bug 的表面报错不是根因。先分析可以让你确认修改范围，避免 Claude Code 大范围重构或改到无关文件。

重构提示词最重要的限制是什么？

最重要的是行为不变、分批执行、不混入新功能、保留 API 兼容，并且每一批都要有验证方式。

测试模板里为什么要写测试命令？

明确测试命令能让 Claude Code 知道如何验证结果，也方便它在失败后继续根据日志做最小修复。

可以把这些模板放进团队规范吗？

可以，而且建议这么做。团队统一模板后，任务边界、验证命令和输出格式更一致，代码审查也更高效。