第 4 课：给 Codex 写好提示词——让它少猜、少改、做得更准
适合谁
这节课适合遇到过这些情况的人：
Codex 做出来的东西不是我想要的
明明只想改一处，它却改了很多文件
它总是反复问我问题
任务完成了，但我不知道结果是否可靠
同一个要求，有时做得好，有时做得差
问题往往不在于“提示词不够高级”，而在于任务里缺少必要信息。
本课目标
学完这一课，你应该能够：
一、提示词不是“咒语”，而是任务单
很多人学习提示词时，会寻找所谓“万能句式”或“高级关键词”。
但使用 Codex 时，最有效的提示词通常不是最华丽的，而是最像一张清楚的工作任务单。
你可以把 Codex 想象成刚加入项目的新同事。你只说：
把这个页面做好一点。
它一定会遇到很多问题：
“好一点”是更美观，还是更快？
只改手机端，还是电脑端也改？
能不能修改接口？
能不能安装新组件？
怎样才算完成？
你没有提供的信息，Codex 就只能猜。
提示词的作用，就是减少这些猜测。
二、好提示词的五个要素
这一课把第1课的公式扩展成五个要素：
目标 + 上下文 + 范围与限制 + 验证方式 + 输出要求
目标：最终要得到什么
目标要描述结果，而不是只描述动作。
不清楚：
改一下登录页。
更清楚：
让登录页在手机屏幕上不再出现横向滚动，并让登录按钮保持完整显示。
“改一下”只是动作；“不再横向滚动、按钮完整显示”才是结果。
上下文：为什么要做、现状是什么
上下文可以包括错误现象、用户场景、已有设计或相关文件。
当前登录页在宽度小于 375px 时会出现横向滚动，截图见附件。
项目已有统一按钮组件，请优先复用。
上下文不是越多越好，只提供完成任务真正需要的信息。
范围与限制：允许改什么，不允许改什么
范围能防止任务越做越大。
只修改登录页及其直接使用的样式。
不要改登录接口，不要替换现有组件库，不要做无关重构。
常用限制包括：
先不要修改文件
只修改必要文件
不要新增第三方依赖
不要改变接口行为
不要删除现有功能
不要处理与当前任务无关的问题
限制不是越多越安全。只写真正重要的边界，否则 Codex 可能为了遵守过多限制而无法完成任务。
验证方式：怎样证明做对了
没有验证方式，任务就只有“看起来完成了”。
完成后运行与登录页相关的测试。
如果项目没有对应测试，请说明怎样在 375px 和 320px 宽度下手动检查。
验证方式可以是：
运行现有测试
运行格式或类型检查
在浏览器里走一遍操作流程
检查生成文件
对照截图或设计稿
列出手动检查步骤
输出要求：完成后怎样汇报
你不需要让 Codex 写长篇报告，但至少要求它说明：
改了哪些文件
为什么这样改
执行了什么检查
检查结果如何
还有什么没有验证
这能帮助你快速判断任务是否真的完成。
三、一条完整提示词长什么样
把五个要素合起来：
目标：修复登录页在手机屏幕上出现横向滚动的问题，并保证登录按钮完整显示。
上下文：问题出现在宽度小于 375px 时。项目已有统一按钮组件，请优先复用现有写法。
范围与限制：只修改登录页和它直接使用的样式；不要修改登录接口，不要新增依赖，不要重构无关组件。
验证：完成后运行最相关的检查；如果没有自动测试，请给出在 375px 和 320px 宽度下的手动验证步骤。
输出：列出修改的文件、验证结果和仍未确认的风险。
这条提示词不需要“你是一位世界顶级工程师”之类的开场。任务清楚，本身就足够有效。
四、什么时候先让 Codex 分析
不是每个任务都适合直接执行。
遇到下面情况时，先让它分析或计划：
你不熟悉这个项目
不知道问题出在哪里
任务会影响很多模块
涉及删除、迁移或重要数据
你无法判断什么方案更合适
可以这样写：
先不要修改任何文件。
请阅读相关代码，说明问题原因、可能影响的范围、可选方案和推荐方案。
等我确认后再执行。
适合直接执行的通常是：
目标明确
范围很小
改错后容易恢复
完成结果容易验证
例如修正文案、更新一段说明、调整一个确定的样式值。
五、一次只给一个主要目标
下面这条任务看起来省事，其实很容易失控：
修复登录问题，顺便优化首页、升级依赖、补测试，再更新 README。
这里至少有五个目标。任何一步出错，都很难判断问题来自哪里。
更好的方式是拆成：
任务 1：修复登录问题并验证
任务 2：补充登录相关测试
任务 3：更新 README 中的登录说明
任务 4：单独评估是否需要升级依赖
一次一个主要目标，不代表效率低。相反，它让每一步更容易检查，也减少返工。
六、不要把实现方案写死
提示词要明确结果和边界，但不一定要替 Codex 决定所有技术细节。
例如你真正需要的是：
导出当前筛选后的订单数据。
如果你并不了解项目，就不要强行要求：
必须新建三个类，再安装某个库，用某种架构实现。
可以改成：
优先复用项目现有工具和模式，不要新增依赖。
如果有多种实现方式，先说明推荐方案和原因。
你负责定义结果和边界；Codex 可以帮助选择与现有项目匹配的实现方式。
七、常见任务的提示词示范**（需要体验或长期使用请联系:AI0109088)**
示例 1：理解陌生项目
请阅读当前项目，不要修改文件，也不要安装依赖。
请用小白能听懂的话说明：
如果有无法从代码确认的内容，请明确说“不确定”，不要猜测。
示例 2：修复 bug
用户点击“保存”后出现错误：【粘贴错误信息】。
复现步骤是：【填写步骤】。
请先定位根因，再做最小修改。
不要重构无关代码，不要隐藏错误信息。
完成后运行最相关的测试，并说明根因、改动文件和验证结果。
示例 3：增加小功能
请给文章列表增加标题搜索。
搜索只针对当前已经加载的数据，不调用新接口。
输入框放在列表上方，并复用项目现有输入框样式。
不要新增依赖，不要修改其他筛选功能。
完成后说明怎样手动验证搜索、清空和无结果三种情况。
示例 4：审查代码
请审查当前改动，先不要修改文件。
重点检查：真实 bug、边界情况、数据丢失风险和缺少的测试。
不要把个人风格偏好当成问题。
按严重程度列出发现，并给出对应文件和原因；如果没有发现明确问题，也请直说。
示例 5：更新文档
请对照当前项目检查 README 的安装、启动和测试步骤。
只修正与项目实际情况不一致的内容。
不要编造不存在的功能或命令。
完成后列出修改点，并说明你实际验证了哪些命令。
八、提示词写完后的快速检查（需要体验或长期使用请联系:AI0109088)
发送前，用十秒钟检查五个问题：
我要的最终结果清楚吗？
Codex 知道必要的背景吗？
允许和禁止的范围清楚吗？
完成后有办法验证吗？
我要求它怎样汇报了吗？
缺少哪一项，就补哪一项。没有必要把提示词写成论文。
九、常见误区***（需要体验或长期使用请联系:AI0109088)***
误区 1：提示词越长越好
错误。无关信息会淹没真正重要的要求。好提示词是信息够用，不是字数最多。
误区 2：必须使用专业术语
不需要。你可以用普通中文描述想看到的结果。对不确定的技术细节，要求 Codex 先检查项目再推荐。
误区 3：一次就要写出完美提示词
不需要。先给出明确目标，看到 Codex 的分析后再补充信息，是正常协作过程。
误区 4：Codex 说完成就代表真的完成
不代表。是否完成要看文件改动、测试结果和实际功能，而不是只看它的文字回复。
误区 5：把所有限制都写成“绝对不能”
限制太死可能让任务无法完成。真正重要的事情写成硬限制，其他偏好可以写“优先”或“如果可行”。
十、通用提示词模板
以后可以直接复制这份：
任务目标：
【最终要实现什么结果】
必要上下文：
【当前现象、错误信息、用户场景或相关文件】
范围与限制：
【允许修改什么；不要修改什么；是否允许新增依赖；是否先只分析】
验证方式：
【运行哪些检查，或怎样手动验证】
输出要求：
完成后列出修改文件、关键改动、验证结果和仍未确认的风险。
如果你不知道某一项怎样填，可以先写：
这一项我不确定，请先检查项目并给出建议，不要直接修改。
十一、本课作业
把下面三条模糊任务，分别改写成包含五个要素的提示词：
然后选其中一条发给 Codex，但先要求它只分析任务是否清楚：
先不要执行。请检查这份任务是否已经说明目标、上下文、范围与限制、验证方式和输出要求。
如果缺少关键信息，只指出缺少什么，不要替我猜。
根据反馈补充一次，再让它执行。
本课总结
写好 Codex 提示词，不靠神秘技巧，只靠把任务说完整：
目标 + 上下文 + 范围与限制 + 验证方式 + 输出要求
提示词的真正作用不是控制每一步，而是减少不必要的猜测，让 Codex 知道要做什么、不能越过什么边界，以及怎样证明结果正确。
下一课：
第 5 课：审查 Codex 的改动——看懂文件变化、测试结果和风险
