Claude 写代码的十个 Prompt 模板：从需求到验收

使用前先补齐四类上下文

每次给出语言/框架实际版本、相关文件或接口、输入输出契约和可执行验收标准。示例均是提示模板，没有代表已经运行过代码。只提供有权分享的源码，删除密钥和客户数据；新增依赖、迁移数据库、访问生产环境要单独核准。

1. 生成功能

“用[项目语言与版本]实现[功能]，只能用[已有依赖]。输入：[类型与样例]；输出：[契约]；错误：[处理方式]。先指出需求缺口，再给最小实现和测试。”例：CSV分组求均值，要说明缺失值规则、空组结果、编码和列缺失的异常，不能只写“统计数据”。

2. 调试缺陷

“这是最小复现、预期、实际、堆栈和最近改动：[材料]。列出可验证假设，先找最可能根因；给最小修复及能先失败后通过的回归测试。未运行的步骤明确标注。”例：时区转换跨日错误，提供输入时区与时间，避免让模型只改显示格式。

3. 代码审查

“仅审查[diff]造成的行为变化，结合[调用方/测试]。每个发现列路径、行范围、触发条件、实际影响和修复方向；缺证据的猜测单独放待确认。”例：分页接口改动，检查重复/漏页和排序稳定性；风格意见不冒充高优先级缺陷。

4. 安全重构

“重构[模块]以改善[可测目标]，保持公开接口和当前行为，先列现有测试缺口；按小步骤给补丁与回滚方法，不顺手换框架。”例：拆分费用计算函数，应固定四舍五入与货币精度规则，再比较重构前后相同输入的结果。

5. SQL 查询与优化

“根据[数据库类型/版本、表结构、索引、数据规模]写只读查询完成[指标]，说明粒度、去重和空值处理；先给 EXPLAIN 的检查项，未获授权不执行。”例：月活用户先定义时区和事件范围，避免一对多连接使计数膨胀。优化结论须由实际执行计划证实。

6. API 设计

“为[业务]设计接口，给请求/响应 schema、鉴权、幂等、错误、分页与版本兼容要求；说明哪些操作需要用户确认。”例：取消订单不能只设计 POST 路径，还要定义已发货、重复取消、并发支付和结果未知时的处理。

7. 正则表达式

“在[语言/正则引擎]中匹配[明确范围]，给正例、反例、Unicode与长度边界，避免灾难性回溯；复杂结构优先建议解析器。”例：提取内部工单号，规定仅接受 TKT- 后六位数字，而不是要求一个正则验证所有邮箱。

8. 单元测试

“为[函数及契约]生成测试，覆盖正常、边界、异常和回归用例；模拟外部服务，不访问真实账号。预期值从契约推导，不能照抄被测实现。”例：折扣计算同时测0、上限、负数输入和精度，说明遇到非法输入是拒绝还是归一化。

9. 解释与文档

“面向[读者]解释[代码]，按输入、状态变化、输出、副作用和失败模式组织；引用相关函数，不补写代码里不存在的保障。”例：解释缓存时必须说清失效条件和租户范围，而不是仅写“提高性能”。不把未知设计意图写成作者事实。

10. 技术方案比较

“比较[候选A/B]满足[负载、可靠性、团队约束]的取舍；列已有事实、假设和需要实验的项，给最小验证计划与退出条件。”例：本地JSON还是数据库保存会话，要评估并发写、备份、查询和权限，而不是只看上手速度。

从提示到可合并代码

选择一个模板后先处理一个小范围，运行格式、类型和单元测试，再检查依赖来源、授权与安全影响。输出太长时按文件或函数生成，不能只说“继续”后不检查拼接。模型自查只能作为补充，测试结果和人工审查才是验收证据。

提交时区分“生成了测试”“运行了测试”“测试通过”。如果没有可运行环境，保留明确的待验证清单，不宣称生产可用；不要让一个漂亮的 Prompt 代替真实项目上下文。