Claude Code 执行 Prompt：规划、实现、验证

12 个 Prompt 让 Claude Code（或 Codex）真正完成工程任务——范围明确的特性、外科手术式修复、迁移、重构、TDD、性能、调试、代码审查。

发布于: 2026/05/17 作者: AI Productivity Guide Team 🌐 查看英文版本

Claude Code 表现最好需要四件事提前给到：范围明确、先读哪些文件、好坏标准、什么不能动。少其中一件，结果就是过度热心的重构、突如其来的 schema 变更、需要回滚的 PR。下面这些 Prompt 命中这些结构，并在风险高的地方加上规划闸口。合并前可配合代码审查 Prompt。

这套 Prompt 适合用在哪

在 {repo} 实现 {feature}。

先读：{清单}
可改：{清单}
绝不许改：{清单}
好坏标准：
- 测试过
- 不动 schema
- 新代码沿用 {file} 已有模式
- diff 可审，<300 行

先用要点形式给计划。我批准前别动代码。

修：{描述}。
复现：{步骤}。
预期 vs 实际：{应该 / 当前}。

约束：
- 最小 diff，不许重构
- 加 1 个修复前会失败的回归测试
- 可能涉及：{清单}

先给 diff 再 apply。

在 {area} 把 {from} 迁到 {to}。

约束：
- 每个 commit 独立可部署
- 过渡期新旧并存
- 回滚 = 逐 commit revert，不做手工清理

先给 commit 计划：每个 commit 的标题 + diff 范围。我批准后再执行。

重构 {component}。三阶段，每段可独立合并：

阶段 1：与旧并存引入新抽象（不动调用方）
阶段 2：逐个迁调用方，旧实现仍可用
阶段 3：删旧，不留兼容层

先只给阶段 1 的 diff。暂不动调用方。

按 spec 起 {name}：{粘贴}。

仓库约定：{1 段——目录结构、命名、错误处理、测试风格}。
镜像参考：{file}。

先给文件结构 + 公开接口（不要实现）。我批准后再填实现。

TDD 实现 {feature}。

1. 为这些行为写失败测试：{清单}
2. 给我测试，等我批准
3. 写让测试通过的最小代码
4. 全绿后再重构

不要为我没列出的行为加测试。

我要验证 {feature} 的思路。请用 50 LOC spike 展示核心。

- 不必考虑 edge case 和错误路径
- 配置类直接硬编码
- 每个偷工的地方标 `// TODO: 真实实现需处理 X`

目的：我读完 spike 就能判断思路是否正确，再决定要不要正式做。

性能问题：{描述}。怀疑原因：{假设或 "未知"}。

步骤：
1. 加一个能复现慢路径的 benchmark
2. 跑基线，报数
3. 迭代修；每次修后给出 benchmark 相对基线的差值
4. 当差值 <5% 改进或达到 {目标 X}，停

任何代码改动前，先给我 benchmark。

在 {repo} 调查 {问题或现象}。本轮不要改任何文件。

步骤：
1. 读这些入口：{清单}
2. 跟踪相关调用链
3. 输出一份简短分析：(a) 现象是什么；(b) 为什么；(c) 2-3 个候选修法按风险排序

我挑修法，再走单独一轮编辑。

下面是 {branch} 的完整 diff。审查：
- 与原工单一致性：{粘贴工单}
- 在 {经常顺带出错的兄弟模块} 是否引入回归
- 新行为是否缺测试
- 命名 / 结构是否偏离 {file} 的约定

输出结构化评论列表：行号 + 关切 + 建议改动。

{粘贴 diff}

{branch} 的 CI 红了。失败 job：{job name}。日志节选：{粘贴关键段，不要整份}。

诊断：
1. 测试在断言什么？
2. 为什么现在挂？最近 {area} 有改动？
3. 最小修法：改测试、改代码、还是 revert {commit}？

先讲推理再给修法。

在 {repo} 把 {dep} 从 {old} 升到 {new}。

先输出风险地图：
- changelog 里碰到我们用法的破坏性改动
- 我们代码里命中的相关文件
- 应该加 / 扩的测试
- 回滚计划

然后给出最小的第一个 PR。不要把这次升级和无关改动绑在一起。