提示词的质量,决定返工的次数
上一节讲了拆解任务。这一节聚焦高质量提示词——在拆好的每个子任务上,把「怎么问」做到最好,让 Codex 一次做对,少返工。
file-lib v2.0 的 watch 功能拆成了四个子任务。这一节,我们把每个子任务包装成「高质量提示词」丢给 Codex——给足上下文、一次一目标、说清要/不要、给验收标准。用「高质量提示词 vs 普通提示词」的对比,看同一件 file-lib 的活,怎么问差出几轮返工。高质量提示词的四个要素
1. 给足上下文
相关代码、报错、约束,一次给足。别让 Codex 瞎猜:
❌ 「帮我修一下登录」 ✅ 「
login.ts里POST /api/login,传正确密码也返回 401,报错:401 Unauthorized。相关代码在第 30 行。」
对 file-lib,让 Codex 修 io.js 时:
❌ 「io.js 崩了,修一下」 ✅ 「
lib/io.js的readFile读不存在的文件会 throw,报ENOENT。相关代码在第 12 行。我在用{ ok:false }结构做错误处理,参考lib/path.js的错误处理风格。」
上下文一次给足,Codex 不用猜「崩是什么意思、该用什么风格」。
2. 一次一目标
一个提示词只做一件事,别塞一堆需求:
❌ 「顺便把注册也做了、再优化下性能」 ✅ 「先只修登录的 401 问题」
对 file-lib,别一个提示词又加功能又重构又写文档。先只做「给 date 模块加 leapYear」。
3. 说清「要什么、不要什么」
既给目标,也划禁区:
✅ 「修复登录 401,但不要改动数据库 schema,也不要改前端。」
对 file-lib:
✅ 「给
watch功能做监听引擎,但不要动string.js,也不要改现有模块的导出签名。」
把禁区划清楚,Codex 才不会顺手碰到不该碰的。
4. 给验收标准
让它知道「做到什么样算对」:
✅ 「修完跑一遍测试,确认登录能返回 200。」
对 file-lib:
✅ 「实现完
watch监听引擎,写测试覆盖新建 / 修改 / 删除三种事件,跑npm test全部通过。」
给了验收标准,Codex 才知道「做到哪算做完」。
反馈循环:改对为止
Codex 第一次不一定做对。用反馈循环逐步逼近:
Codex 出结果 → 你看哪里不对 → 具体反馈 → 它再改 → 再看 → …
反馈要具体:指出「哪里错 + 要什么」,别只说「不对」。对 file-lib,如果 Codex 实现的 watch 回调触发时机不对:
❌ 「不对,再改改」 ✅ 「事件回调触发得太晚——文件修改后等了 2 秒才触发。我预期是在文件变化后立即(< 100ms)触发。看一下
lib/watch.js的监听逻辑,检查是不是有防抖或缓冲设置错了。」
具体的「错在哪 + 要什么 + 指向哪」,Codex 一轮就能改对,而不是来回试。
一个对比:普通 vs 高质量
普通提示词:
「优化下这个函数」
高质量提示词:
「
fetchUsers里每次循环查一次用户,是 N+1。改成一次性IN查询所有用户再映射。改完跑npm test,别动调用方。」
| 普通 | 高质量 | |
|---|---|---|
| 上下文 | 没给 | 给了问题+位置 |
| 目标 | 模糊 | 明确改法 |
| 约束 | 没有 | 别动调用方 |
| 验收 | 没有 | 跑测试 |
高下立判,返工次数天差地别。放到 file-lib 的 io.js 同样是「优化」:
❌ 「优化下 io.js」 ✅ 「
io.js的readFile一次性读全量,大文件内存占用高。改成fs.createReadStream流式读取。改完跑测试,别动path.js。」
前者 Codex 不知从何下手,后者它一次做到位。
形成「提示词 → 反馈」的循环
熟练之后,把它变成一个稳定的循环:
1. 高质量提示词 → Codex 第一次就接近目标
2. 还有偏差 → 具体反馈 → 修正
3. 每轮都往目标靠近
4. 验收通过 → 结束
提示词越高质量,反馈循环的轮数越少。
fs.watch 相关上下文、一次一目标、说清别动其他模块、给「覆盖三种事件 + npm test」验收);发给 Codex;若偏差,用「具体错在哪 + 要什么 + 指向哪个文件」反馈,循环到验收通过。②怎么判断做对了:Codex 第一次就接近目标(返工 ≤ 1 轮)、它没碰禁区文件、验收标准(三事件 + 测试通过)达成。③卡住了怎么办:如果 Codex 答非所问,回看提示词是不是少了上下文或禁区;如果反馈不收敛,停下来把「当前行为 vs 期望行为」用表格列给它对比。常见坑:反馈只给情绪,不给信息
循环反馈里,最拖节奏的反馈是只有情绪、没有信息:「不对」「再改」「还是不行」。Codex 面对这种反馈只能瞎猜,来回好几轮都在原地打转。
避坑办法:反馈必须包含「对比 + 指向」——当前的输出 vs 你期望的输出,差异在哪、大概在哪个文件。给你一个通用模板:
你现在的做法:____
我期望的做法:____
差异点:____
请检查:____(具体文件/逻辑)
在 file-lib 上这么用:
你现在:watch 只在文件删除时才触发回调
我期望:新建、修改、删除都要触发
差异点:增改事件没被监听到
请检查:lib/watch.js 里 fs.watch 的监听事件是不是只注册了 'delete'
有对比、有差异、有指向的反馈,一轮就能修对;只有情绪的反馈,纯靠运气。 高质量的循环,靠的是高质量的信息。
小结
- 提示词质量 = 返工次数的决定因素
- 四要素:给足上下文、一次一目标、要/不要、验收标准
- 反馈循环:具体指出「哪里错 + 要什么」
- 高质量提示词 → 反馈轮数少
下一模块进入「综合实战」。