Appearance
05 · 提示词四件套
📚 系列导航：上一篇 04 四种入口与界面 教你把手指放对地方。这一篇教你怎么说——同样一个需求，话说得好不好，Codex 干出来的活儿天差地别。
01 四件套框架
每次提需求前在脑子里过一遍这四件：
| 要件 | 回答的问题 | 缺了会怎样 |
|---|---|---|
| 目标（Goal） | 要做成什么 | 它猜你想要啥，方向全凭运气 |
| 范围（Scope） | 动哪、不动哪 | 它满项目大海捞针，顺手动别的 |
| 约束（Constraint） | 有啥不能碰的讲究 | 它按自己偏好来，回头未必合你心意 |
| 验证（Verification） | 怎么算成功 | 它「感觉差不多了」就收工，漏洞你来逮 |
| 场景 | ❌ 烂提问 | ✅ 好提问 |
|---|---|---|
| 修 Bug | 登录接口挂了，修一下 | 用户超时后调 POST /api/login 返回 500。先写失败测试复现，查 src/auth/ token 刷新，再修，跑测试确认转绿 |
| 写测试 | 给 parser.py 加测试 | 给 parse_date 写测试，覆盖空字符串和非法格式，不用 mock，跑 pytest 确认通过 |
| 加功能 | 加个导出功能 | 照 report.py 里 export_csv 的模式加 export_json，别引新依赖 |
TIP
唯一例外：找灵感阶段可以故意模糊。当你自己还没想清楚方向时，一句「你觉得这个文件有什么可以改进的？」往往能炸出盲区。要结果就往死里具体，找灵感才留白。
02 给上下文：能贴的绝不用嘴说
| 你想给的料 | ❌ 用嘴描述 | ✅ 直接喂 |
|---|---|---|
| 某个文件的内容 | 「项目里有个处理认证的文件」 | 需求里点名 src/auth/session.ts |
| 一段报错 | 「它报了个 undefined 的错」 | 把完整 traceback 原样贴进去 |
| 一个 UI 问题 | 「按钮位置不对」 | 直接粘截图 |
03 给验收标准
NOTE
不给标准，Codex 凭「感觉差不多了」就收工，你成为验证循环——每个错误都在等你发现。给一个能跑出「通过/失败」的检查，循环就自己闭合。
进阶玩法 /goal： 把验收标准钉成整个任务的目标——每跑完一轮，Codex 对照标准复查，没达成就接着干，达成了才停。
text
/goal 把这个代码库从 JavaScript 迁到 TypeScript，要求在 strict 模式下编译通过，且不出现显式的 any 类型配置 /goal 的完整实操
/goal 不是默认开启的，需要先打开功能开关：
bash
codex features enable goals或直接让 Codex 代劳：
text
帮我打开 goal 模式它会自动修改 ~/.codex/config.toml，加入：
toml
[features]
goals = true完成后，在会话中直接输入 /goal 即可进入目标模式。成功后你会看到一个「Goal Mode」提示。
/goal 与普通提问的区别
| 对比项 | 普通提问写验收 | /goal 目标模式 |
|---|---|---|
| 管多久 | 就这一轮，跑完可能还你控制权 | 整个任务，没达标不撒手 |
| 适合 | 单个需求、一两步的活 | 步骤多、要清晰完成定义的长活 |
| 标准怎么写 | 写测用例跑一遍 | 写成可量化、可测的「是/否」标准 |
| 要不要开开关 | 不用 | 要 features.goals = true |
WARNING
目标得写成 Codex 自己能判「是/否」的可量化标准。「代码质量很高」这种判不了。
04 大任务拆小步
大任务别整吞——拆成「每步自带验证、小到一眼能审」的小块。
| 任务 | 怎么处理 |
|---|---|
| 改错别字、加一行日志 | 直接干，一句话能说清 diff 的别拆 |
| 给单个函数加校验 | 四件套一步到位 |
| 跨多文件、你不熟的代码 | 先 /plan 出方案，你审完再分步放行 |
| 实现整个系统 | 拆成 5-8 个自带验证的小步，逐步跑 |
实用的判断土办法： 能不能一句话说清这次改完长啥样？能，直接干；卡壳了，说明这活儿够复杂，先拆、先让它列计划。改个错别字也走 /plan，纯属给自己加戏。
05 动手：同一需求两种说法
bash
mkdir prompt-demo && cd prompt-demo
echo 'def average(nums): return sum(nums) / len(nums)' > stats.py
codex❌ 烂提问： @stats.py 帮我改改这个函数 → 预期：它猜方向，大概率不是修除零
✅ 好提问： @stats.py 里的 average 函数有个 bug：空列表时除以零崩溃。期望空列表返回 0。修复并补两个测试：average([]) 返回 0、average([2,4]) 返回 3。写完跑 pytest 确认通过。 → 预期：定位→修→写测试→跑绿
对比看到差距——烂提问省略了目标（修什么）和验证（怎么算好），Codex 只能猜；好提问把目标、范围、约束、验收一次全说死，它不需要任何推断。
06 小结
| 心法 | 一句话 | 落地写法 |
|---|---|---|
| 四件套 | 目标+范围+约束+验收 | 缺哪件它就在哪件上脑补 |
| 给上下文 | 能贴的绝不说 | @ 文件、整段报错、粘截图 |
| 给验收标准 | 让它自己能验 | 测试用例+跑一遍；狠的上 /goal |
| 大任务拆小步 | 每步自带验证 | 不会拆用 /plan 先出方案 |
NOTE
下一篇：06 四类高频工作流：探索、修 Bug、重构、写测试，每类给一套标准模板。