Prompt 提示词秘籍

同样的模型，提示词不同，产出天差地别。差别不在辞藻，而在是否把"任务、约束、参照、验收"说清楚。

本篇面向编程与交付场景。日常聊天场景的入门动作（任务、上下文、示例、角色），先看《提示词入门》。

1. 让 AI 一次生成更准的四个要素

1.1 任务：说清做什么

用动词开头，一句话说清动作和对象。"帮我优化代码"是坏提示词；"把 formatDate 函数改成支持时区参数"是好提示词。

1.2 约束：说清边界

• 技术约束：只用现有依赖、不引入新库。
• 兼容约束：保持函数签名不变、不能破坏现有调用。
• 范围约束：只改指定文件，不要顺手重构别处。

AI 很爱"顺手多做"，明确写出"只改 X，其他不动"能省掉大量回退。

1.3 参照：给示例或模板

"参考 getUser 的写法"比十句描述都有效。让 AI 模仿项目里已有的好代码，是最快的对齐方式。

1.4 验收：说清怎么算完成

写明验证命令（构建、测试、lint），并要求 AI 完成后自己跑一遍。AI 自己验证过的交付，质量明显高于"写完就交"。

2. 结构化需求模板

复杂需求直接套这个模板：

目标：一句话说清最终效果
背景：相关的业务或技术背景，两三句即可
涉及文件：明确列出或让 AI 先搜索定位
要求：
1. 约束一（技术/兼容/范围）
2. 约束二
3. 参照物：参考 XX 的实现风格
验收：完成后运行 XXX 命令，必须通过

简单任务不必全套照搬，但"目标 + 约束 + 验收"三样始终值得写。

3. 先方案，后实现

3.1 为什么要两步走

直接说"实现它"，AI 会把构思和编码挤在一次输出里，方案缺陷被代码细节淹没。两步走把"想清楚"和"做出来"解耦。

3.2 标准话术

第一步：

先不要写代码。给出实现方案：要改哪些文件、新增哪些函数、
有没有风险点。等我确认后再动手。

第二步：审完方案，提出修改意见，然后说"按这个方案实现"。

3.3 追问让方案更扎实

• "这个方案对现有调用方有什么影响？"
• "有没有更简单的做法？"
• "边界情况怎么处理？"

4. 审查与修复循环

4.1 收到代码后的审查清单

• diff 是否只包含要求内的改动。
• 错误处理是否覆盖（网络、空值、越界）。
• 命名与风格是否符合项目惯例。
• 有没有硬编码的值、临时的 console.log。

4.2 高效的修复提示词

报错时把完整报错信息 + 复现步骤给 AI，比转述有效得多：

运行 npm run build 报错如下（完整粘贴）：
XXX
我做了哪些操作：XXX
先分析根因，不要急着改代码。

"先分析根因，不要急着改"这句话能阻止 AI 头痛医头地乱打补丁。

4.3 让 AI 自查

交付前让 AI 用一段固定话术自查：

检查你刚才的改动：有没有多余改动、遗漏的边界情况、
未使用的导入。发现问题直接修复。

5. 常见的坏习惯

• 一句话甩需求，让 AI 猜："帮我做个登录。"
• 贴整屏代码而不是让它自己搜索定位。
• 报错只说"跑不起来"，不贴原始信息。
• 连续追加需求在同一会话，上下文越滚越乱。
• 生成后不审查直接合并。

对照这份清单改掉一条，产出质量立刻能上一个台阶。

相关阅读：《通用 AI 编程方法论》（任务拆解与验证闭环）、《从零到驾驭 AI：成长路径》第一阶段（提问基本功的刻意练习）。