一个万能提示词，让Codex先理解项目再动手

通过项目理解、需求复述、问题澄清、实施计划和验收标准，让 Codex 在修改代码前先确认范围，减少误改、过度重构和不可验证的实现。

很多人使用 Codex 的第一句话是：

帮我增加一个登录功能。

然后 Codex 立刻开始：创建文件、安装依赖、调整目录、修改配置……，几分钟后，你发现它确实写了很多代码。

但问题是：

它可能根本没有真正理解你的项目。 它不知道现有代码是怎么组织的。 不知道项目有哪些开发规范。 不知道哪些功能不能修改。 不知道你希望它改到什么程度。 甚至不知道应该如何验证结果。

于是，Codex 做得越快，项目可能越乱。

解决方法其实很简单：

不要让 Codex 收到任务后立刻动手。

先让它完成四件事：

阅读项目; 复述需求; 提出问题; 制定计划;

下面这条提示词，建议每个 Codex 新手都保存下来。

万能提示词：先理解项目，再开始修改

直接复制下面这段：

请先完整理解当前项目和这次任务，不要立即修改任何文件。

第一步：了解项目

请阅读与当前任务相关的目录、代码、配置文件和项目文档，并告诉我：

1. 这个项目的主要用途是什么；
2. 当前项目使用了哪些主要技术；
3. 与本次任务相关的核心文件有哪些；
4. 当前功能是如何实现的；
5. 项目中是否存在 AGENTS.md、README.md 或其他开发规范；
6. 项目应该如何启动、测试和验证。

第二步：理解需求

请用你自己的语言复述我的需求，并明确：

1. 这次任务要解决什么问题；
2. 用户最终应该看到什么结果；
3. 哪些功能需要修改；
4. 哪些内容不在本次任务范围内；
5. 你认为任务完成的判断标准是什么。

第三步：发现问题

如果需求中存在模糊、冲突或缺失的信息，请先向我提问。

不要自行假设重要的业务规则、页面流程、数据结构或技术方案。

如果存在多种实现方式，请说明：

1. 每种方案的优缺点；
2. 对现有项目的影响；
3. 你推荐哪一种；
4. 推荐它的理由。

第四步：制定计划

请给出一个分步骤的执行计划，并说明：

1. 准备修改哪些文件；
2. 每个文件准备修改什么；
3. 是否需要创建新文件；
4. 是否需要安装新的依赖；
5. 是否会影响现有功能；
6. 可能存在什么风险；
7. 修改完成后如何测试和验收。

在我确认计划之前：

- 不要修改任何文件；
- 不要创建新文件；
- 不要删除代码；
- 不要安装或升级依赖；
- 不要执行数据库迁移；
- 不要修改环境变量；
- 不要运行具有破坏性的命令。

请先输出：

1. 项目理解；
2. 需求复述；
3. 待确认问题；
4. 实施计划；
5. 风险和验收方式。

等待我确认后，再开始执行。

这段提示词看起来很长。

但它真正做的事情只有一句话：

先证明你理解了，再允许你动手。

为什么一定要让 Codex 先阅读项目？

同一个功能，在不同项目里的实现方式可能完全不同。

例如，你让 Codex 增加一个登录功能。

项目可能已经使用：

• 现成的身份验证服务
• 自己开发的账号系统
• 第三方登录
• 本地模拟账号
• 还没有任何后端

如果 Codex 没有先阅读项目，它可能直接安装一套新的登录框架。

结果就是：

原有系统还在，新系统又加了一套。

代码重复、逻辑冲突，后面越来越难维护。

所以，在修改之前，Codex 至少应该先回答：

当前项目已经有什么？

而不是直接决定：

我要新增什么？

不了解现状，就无法做出合理修改。

为什么要让它复述需求？

很多人觉得，自己的要求已经写得很清楚。

但你理解的“完成”，和 Codex 理解的“完成”，可能完全不同。

你说：

增加客户搜索功能。

你想要的可能是：

• 支持姓名搜索
• 支持电话号码搜索
• 输入时实时筛选
• 没有结果时显示提示
• 清空搜索后恢复全部客户

Codex 理解的可能只是：

• 增加一个搜索框
• 点击按钮后过滤当前页面的数据

两种结果都可以叫“搜索功能”。

但只有一种符合你的真实需求。

所以，在执行之前，让它先复述：

你准备做什么？ 不准备做什么？ 什么状态才算完成？

如果它复述错了，你只需要改几句话。

如果它已经写完才发现理解错了，你可能需要重做几十个文件。

先纠正理解，永远比事后纠正代码便宜。

为什么要让它主动提问？

新手最容易犯的错误之一，是以为 Codex 什么都知道。

实际上，它只能根据现有文件和你的描述进行推断。

例如，你要求：

增加订单退款功能。

这里至少还有很多问题：

退款是全部退款还是部分退款？ 退款后订单状态是什么？ 是否需要记录退款原因？ 是否真的调用支付平台？ 谁有权限发起退款？ 退款失败后怎么办？ 是否需要发送通知？

如果这些问题没有答案，Codex 只能自己选择。

而涉及业务逻辑时，AI 自己做决定通常非常危险。

所以提示词里一定要写：

如果存在模糊或缺失的信息，请先提问，不要自行假设。

一个好的 Codex，不应该只是执行命令。

它还应该知道：

什么时候不能继续执行。

为什么要先看计划？

计划的作用，不是让内容显得专业。

而是让你在代码被修改之前，提前发现方向错误。

一份合格的计划，应该告诉你：

• 它准备修改哪些文件
• 为什么需要修改
• 是否会增加依赖
• 是否会影响旧功能
• 准备如何测试
• 出错后怎样恢复

例如，Codex 的计划里出现：

重构整个用户模块。

但你原本只要求：

修改登录按钮的提示文字。

这时你就能立刻阻止它。

可以直接回复：

不要重构用户模块。本次任务只修改按钮文案和相关测试，请缩小改动范围。

计划是成本最低的纠错阶段。

此时改变方向，只需要修改几句话。

等代码全部写完再改变方向，可能意味着推倒重来。

确认计划后，应该怎么让它开始？

不要只回复：

好，开始吧。

可以使用一条更稳的执行指令：

计划确认，可以开始执行。

请严格按照已经确认的计划进行修改，不要扩大任务范围。

执行过程中请遵守以下要求：

1. 一次只完成一个步骤；
2. 不要修改与当前任务无关的文件；
3. 安装新依赖前先说明原因；
4. 遇到计划外的问题时暂停并询问我；
5. 每完成一个步骤，检查是否影响现有功能；
6. 修改完成后运行相关测试；
7. 不要为了让测试通过而删除测试或降低验证标准。

完成后请告诉我：

1. 修改了哪些文件；
2. 每个文件具体修改了什么；
3. 执行了哪些命令；
4. 测试结果是什么；
5. 是否还有未完成事项；
6. 是否存在风险；
7. 我应该如何手动验收。

这样做的目的，是避免 Codex 在执行过程中突然“顺便”做更多事情。

例如：

顺便升级框架。 顺便重构目录。 顺便替换数据库。 顺便修改其他页面。

很多项目不是被一个明显错误弄坏的。

而是被无数个“顺便优化一下”慢慢改乱的。

小任务也需要这么长的提示词吗？

不一定。

如果只是修改一个错别字、调整按钮颜色或补充一段说明，不需要每次都发送完整模板。

简单任务可以使用精简版：

请先检查与这个任务相关的代码，不要立即修改。

先告诉我：

1. 当前功能是如何实现的；
2. 你准备修改哪些文件；
3. 修改后如何验证；
4. 是否会影响其他功能。

等我确认后再执行。

复杂任务使用完整版。

简单任务使用精简版。

判断标准不是“要写多少代码”，而是：

这次修改出错后，影响有多大。

涉及以下内容时，建议使用完整版：

• 登录和权限
• 数据库结构
• 支付功能
• API 接口
• 项目架构
• 大规模重构
• 生产环境
• 用户隐私数据
• 多个模块之间的联动

还可以增加一条：优先最小改动

Codex 有时会为了实现一个小功能，主动进行大范围重构。

你可以在提示词中增加：

请优先选择改动范围最小、最容易测试、最容易恢复的实现方式。

除非现有结构确实无法完成需求，否则不要重构无关模块，不要替换现有技术方案，也不要升级主要依赖。

这句话非常有用。

因为实际项目中，最好的方案不一定是“最先进”的方案。

而通常是：

在不破坏现有功能的前提下，用最小成本解决当前问题。

再增加一条：明确完成标准

不要只要求 Codex“把功能做完”。

把完成标准写出来。

例如：

本次任务只有同时满足以下条件，才算完成：

1. 用户可以根据姓名和电话号码搜索客户；
2. 搜索结果与输入内容一致；
3. 没有结果时显示明确提示；
4. 清空搜索内容后恢复完整列表；
5. 不影响客户新增、编辑和删除功能；
6. 相关测试全部通过；
7. 项目可以正常重新启动。

Codex 最容易停下来的位置是：

代码已经写完。

而你需要的完成标准应该是：

功能已经验证可用。

代码完成，不等于任务完成。

一个真实的使用示例

假设你想给客户管理工具增加搜索功能。

不要只说：

增加客户搜索。

可以这样写：

我希望为当前客户管理工具增加搜索功能。

目标：

用户可以根据客户姓名或电话号码搜索客户。

具体要求：

1. 输入关键词后显示匹配客户；
2. 姓名支持部分匹配；
3. 电话号码支持部分匹配；
4. 搜索内容为空时显示全部客户；
5. 没有结果时显示“未找到客户”；
6. 不要影响客户新增、编辑和删除功能；
7. 不要更换现有技术方案。

请先阅读相关项目文件，不要立即修改。

先告诉我：

1. 当前客户列表是如何实现的；
2. 客户数据来自哪里；
3. 需要修改哪些文件；
4. 你推荐前端筛选还是后端搜索；
5. 两种方案有什么区别；
6. 你准备如何测试。

如果存在不确定的信息，请先向我提问。

在我确认方案之前，不要修改文件、安装依赖或创建新模块。

这条提示词并没有使用复杂的技术术语。

但它清楚说明了：

要做什么。 不能影响什么。 怎样才算完成。 什么时候可以开始。

这比一句“增加搜索功能”可靠得多。

最后总结

让 Codex 先理解项目再动手，本质上要完成五步：

第一，阅读项目。 先了解现有结构和实现方式。

第二，复述需求。 确认它理解的结果和你想要的一致。

第三，提出问题。 不要让它自行猜测重要规则。

第四，制定计划。 提前检查修改范围、风险和测试方法。

第五，等待确认。 没有得到允许之前，不修改、不安装、不删除。

Codex 最大的优势是执行速度。

但执行速度越快，方向错误的代价也越大。

所以，不要一开始就问：

你能不能马上把它做完？

应该先问：

你是否真正理解了这个项目和任务？

先理解，再计划。

先确认，再执行。

这可能是使用 Codex 最简单，也最有效的一条规则。