第五章：提示词工程化：目标/约束/验收三件套与模板库

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

高质量提示词不是写得更长，而是写得更可执行、更可验证。

推荐固定格式：

目标：
约束：
验收：

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

目标：一句话说明要交付什么

好目标：

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

坏目标：

• “优化一下订单接口”

约束：把边界提前写死

常用约束句式：

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

验收：明确怎么证明改对了

验收建议至少包含：

• 复现/用例（修 bug 必备）
• 必跑命令（tests/lint/build）
• 输出物（变更摘要 + diff + 风险点与回滚）

5.3 高收益技巧：先调查，再修改

建议在大多数任务里加一句：

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

它会让 Cursor 从“猜测式编辑”变成“证据驱动”。

5.4 三个可复用模板（可直接复制）

修 bug 模板

目标：修复 XXX 问题。
约束：不要新增依赖；不要改接口协议；只改 src/ 与 tests/。
验收：
1) 给出最小复现步骤
2) 根因定位到文件/函数/调用链
3) 修复后运行：<测试命令>、<lint 命令>
4) 输出 diff，说明风险点与回滚方式

加功能模板

目标：实现 XXX 功能（包含边界条件与错误处理）。
约束：保持向后兼容；不要重构无关模块；不要新增依赖。
验收：给出用例；跑测试与 lint；输出可审阅 diff。

重构模板

目标：重构 XXX 模块使结构更清晰（列出目标结构）。
约束：行为不变；对外 API 不变；小步提交；不要全仓库格式化。
验收：跑全量测试；输出分段 diff 与改动摘要。

5.5 本章小结

你已经把“随口描述”升级成“工程工单”：

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

下一章进入具体操作：行内改动与重构怎么做才能小步、可回滚、可审阅。