第 04 模块 · 2 节

高质量提示词与反馈循环

《Codex 进阶实战》04 任务规划与提示词 · 本节时长 37 分钟

提示词的质量,决定返工的次数

上一节讲了拆解任务。这一节聚焦高质量提示词——在拆好的每个子任务上,把「怎么问」做到最好,让 Codex 一次做对,少返工。

贯穿项目上一节我们把 file-lib v2.0 的 watch 功能拆成了四个子任务。这一节,我们把每个子任务包装成「高质量提示词」丢给 Codex——给足上下文、一次一目标、说清要/不要、给验收标准。用「高质量提示词 vs 普通提示词」的对比,看同一件 file-lib 的活,怎么问差出几轮返工。

高质量提示词的四个要素

1. 给足上下文

相关代码、报错、约束,一次给足。别让 Codex 瞎猜:

❌ 「帮我修一下登录」 ✅ 「login.tsPOST /api/login,传正确密码也返回 401,报错:401 Unauthorized。相关代码在第 30 行。」

file-lib,让 Codex 修 io.js 时:

❌ 「io.js 崩了,修一下」 ✅ 「lib/io.jsreadFile 读不存在的文件会 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-libio.js 同样是「优化」:

❌ 「优化下 io.js」 ✅ 「io.jsreadFile 一次性读全量,大文件内存占用高。改成 fs.createReadStream 流式读取。改完跑测试,别动 path.js。」

前者 Codex 不知从何下手,后者它一次做到位。


形成「提示词 → 反馈」的循环

熟练之后,把它变成一个稳定的循环:

1. 高质量提示词 → Codex 第一次就接近目标
2. 还有偏差 → 具体反馈 → 修正
3. 每轮都往目标靠近
4. 验收通过 → 结束

提示词越高质量,反馈循环的轮数越少。

练习用高质量提示词推进 file-lib 的 watch 功能。①三步走:从上一节的四个子任务里挑「监听引擎」,用四要素写一条高质量提示词(给足 fs.watch 相关上下文、一次一目标、说清别动其他模块、给「覆盖三种事件 + npm test」验收);发给 Codex;若偏差,用「具体错在哪 + 要什么 + 指向哪个文件」反馈,循环到验收通过。②怎么判断做对了:Codex 第一次就接近目标(返工 ≤ 1 轮)、它没碰禁区文件、验收标准(三事件 + 测试通过)达成。③卡住了怎么办:如果 Codex 答非所问,回看提示词是不是少了上下文或禁区;如果反馈不收敛,停下来把「当前行为 vs 期望行为」用表格列给它对比。

常见坑:反馈只给情绪,不给信息

循环反馈里,最拖节奏的反馈是只有情绪、没有信息:「不对」「再改」「还是不行」。Codex 面对这种反馈只能瞎猜,来回好几轮都在原地打转。

避坑办法:反馈必须包含「对比 + 指向」——当前的输出 vs 你期望的输出,差异在哪、大概在哪个文件。给你一个通用模板:

你现在的做法:____
我期望的做法:____
差异点:____
请检查:____(具体文件/逻辑)

file-lib 上这么用:

你现在:watch 只在文件删除时才触发回调
我期望:新建、修改、删除都要触发
差异点:增改事件没被监听到
请检查:lib/watch.js 里 fs.watch 的监听事件是不是只注册了 'delete'

有对比、有差异、有指向的反馈,一轮就能修对;只有情绪的反馈,纯靠运气。 高质量的循环,靠的是高质量的信息。


小结

  1. 提示词质量 = 返工次数的决定因素
  2. 四要素:给足上下文、一次一目标、要/不要、验收标准
  3. 反馈循环:具体指出「哪里错 + 要什么」
  4. 高质量提示词 → 反馈轮数少

下一模块进入「综合实战」。