让 Codex 修改现有项目时，提示词先说清目标、上下文、约束、验收四件事：改什么、从哪里找依据、哪些边界不能越过、怎样判断完成。文件路径和测试命令应来自你的真实仓库；不确定时让 Codex先读取项目并报告发现，避免凭空指定接口。
先把任务缩到一个可核对的改动
假设你维护一个已有的 Web 项目，想修复“搜索框清空后列表仍保留旧结果”。下面是教学示例，不是对某个真实仓库的测试记录。实际使用时，把页面名称、相关目录和复现步骤换成你的项目内容。
目标：修复商品列表页搜索框清空后仍显示旧搜索结果的问题。
上下文：先阅读项目说明、商品列表页面及它调用的数据请求代码；用现有实现确认状态从哪里更新。若文件位置不明，先定位并说明依据。
约束：沿用现有组件与请求方式；只改与这次搜索状态有关的文件。不要修改接口契约、权限逻辑或无关页面；遇到业务口径不明先指出。
验收：复现“输入关键词→看到筛选结果→清空输入”的流程，清空后列表应按项目原有规则恢复；运行相关测试或现有检查命令，并列出改动文件、验证结果及未验证之处。OpenAI 官方 Codex 最佳实践把 Goal、Context、Constraints、Done when 列为一种推荐的任务结构，并建议给出相关文件、文档、错误及完成条件。四段是帮助组织信息的写法，不是 Codex 必须识别的特殊语法。
四段各写到什么程度
- 目标：描述用户可观察到的错误和期望结果；“优化整个搜索系统”过宽，“清空后恢复列表”更容易检查。
- 上下文：给已经确认的目录、报错、复现步骤或项目文档。路径未知就让 Codex先定位，不要编一个文件名。
- 约束：写真实的架构和业务边界，例如复用已有请求方法、不要改权限判断。若必须改接口，先核对项目契约。
- 验收：写可重复的操作和检查结果。测试命令以仓库现有脚本为准；若环境无法运行，要明确记录原因和仍需人工核对的部分。
拿到结果后怎样验收
先看 Codex 列出的实际改动文件，再逐项打开差异，确认没有扩大到无关模块。按提示词中的复现流程操作一次，检查清空前后的列表状态；随后运行项目已有的相关测试。只有“代码已修改”的回复并不能证明问题已经修好，测试失败或无法运行都应保留为未完成的验证项。
如果 Codex 找不到页面入口或业务规则不明确，补充真实项目路径、截图文字或现有接口说明后再继续。不要让它自行发明“清空后显示全部”这类业务结论；有些项目可能按默认筛选条件恢复，正确行为要以当前产品规则为准。
本文示例未在读者仓库运行，也不保证同一提示词适用于所有项目。你可以先复制示例结构，再替换成真实问题、代码位置和验收条件；最终以文件差异与实际复现结果为准。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/30072.html
