第五章：高质量提示词：目标/约束/验收标准三件套

5.1 你给 Claude 的不是“问题”，而是“工单”

高质量提示词的本质是：把任务变成可执行、可验证、可交付的工程工单。

推荐固定格式：

目标：
约束：
验收：

5.2 三件套怎么写（每条都要“可操作”）

目标：一句话说清“要交付什么”

好目标：

• “为 /api/orders 增加分页与排序参数，并补上单测”

坏目标：

• “优化一下订单接口”

约束：把风险与边界提前写死

常用约束句式：

• 不新增依赖
• 不改数据库结构
• 不改外部接口协议
• 只改 src/ 与 tests/
• 保持向后兼容

验收：告诉 Claude “如何证明是对的”

验收应至少包含：

• 复现步骤（修 bug 必备）
• 必跑命令（测试/lint/build）
• 输出物（/diff + 变更说明）

5.3 两个高收益技巧：先“调查”，再“修改”

在任何非简单任务里，建议你加一句：

先不要改代码。先定位入口与证据，再给出最小改动方案。

这会把 Claude 的行为从“猜测式编辑”拉回“证据驱动”。

5.4 典型场景模板（可直接复制）

修 bug 模板

目标：修复 XXX 问题。
约束：不要新增依赖；不要改接口协议；只改 XXX 目录。
验收：
1) 给出最小复现步骤
2) 定位根因（指出文件/函数/调用链）
3) 修复后运行：<你的测试命令>、<你的 lint 命令>
4) 输出 /diff，并解释为什么这么改

加功能模板

目标：实现 XXX 功能（包括边界条件）。
约束：保持向后兼容；不要重构无关模块；接口变更必须提供迁移说明。
验收：提供用例；跑测试与 lint；/diff 可审阅。

重构模板

目标：把 XXX 模块重构为更清晰的分层（列出目标结构）。
约束：行为不变；对外 API 不变；优先小步提交。
验收：跑全量测试；/diff 分段展示关键改动点。

5.5 本章小结

你已经把提示词从“描述愿望”升级成“工程工单”：

• 目标明确：交付什么
• 约束明确：边界在哪
• 验收明确：怎么证明对

下一章我们把风险再降一级：文件修改与审阅的最佳实践，如何让每次改动都可控、可回滚。