很多人觉得 Codex 不稳定,其实有时候不是工具不好用,而是任务给得太模糊。
比如你说:
|
1 |
帮我看看这个项目。 |
这句话能用,但不够具体。Codex 可能会泛泛总结一堆东西,却没有真正帮你解决问题。
更好的方式是给它明确任务、范围、约束和输出格式。
这篇整理 7 个我觉得最适合新手直接照抄的 Codex 提示词模板。
适合场景:刚打开一个新项目,不知道从哪里看。
|
1 2 3 4 5 6 7 |
请阅读当前项目结构,不要修改任何文件。 请输出: 1. 项目主要技术栈 2. 入口文件在哪里 3. 核心目录分别负责什么 4. 最重要的 5 个文件 5. 新手应该按什么顺序阅读 |
这个模板非常适合接手旧项目。它的重点是“不修改任何文件”,先让 Codex 做分析。
适合场景:你知道要改某个功能,但不知道代码在哪。
|
1 2 3 4 5 6 7 |
我想修改【具体功能】。 请先在项目中定位相关文件,不要修改代码。 请告诉我: 1. 相关页面或组件在哪里 2. 相关接口在哪里 3. 相关状态管理在哪里 4. 如果要修改,最可能需要动哪些文件 |
比如把【具体功能】换成:
|
1 2 3 4 5 |
登录功能 用户头像上传 订单列表筛选 首页轮播图 文章发布按钮 |
这比直接说“帮我改登录功能”稳很多。
适合场景:已经知道要改什么,希望 Codex 直接动手。
|
1 2 3 4 5 6 7 |
请帮我修改【具体需求】。 要求: 1. 只做最小必要修改 2. 保持现有代码风格 3. 不改变无关功能 4. 修改完成后列出改了哪些文件 5. 说明如何手动验证 |
这里的关键是“最小必要修改”。它能提醒 Codex 不要顺手大改。
适合场景:有报错,但不知道从哪里查。
|
1 2 3 4 5 6 7 |
我遇到的问题是:【粘贴问题描述】。 请先不要修改代码。 请帮我分析: 1. 最可能的 3 个原因 2. 每个原因对应应该检查哪个文件 3. 应该优先看哪些日志或变量 4. 如果需要修改,建议从哪里开始 |
这个模板的重点是:先分析原因,不要马上改。
很多 bug 最怕一上来就修。先定位,再动手,成功率会高很多。
适合场景:你自己改完代码以后,想让它帮你检查。
|
1 2 3 4 5 6 7 8 |
请 review 当前改动。 重点检查: 1. 是否有回归风险 2. 是否有边界条件遗漏 3. 是否有命名不清楚的地方 4. 是否有重复代码 5. 是否需要补充测试 请按严重程度排序输出。 |
这个模板适合提交前用。就算项目没有测试,也可以让 Codex 帮你过一遍逻辑。
适合场景:项目能跑,但文档很乱。
|
1 2 3 4 5 6 7 8 9 |
请基于当前项目生成一份 README。 要求包含: 1. 项目简介 2. 技术栈 3. 安装依赖方式 4. 本地启动方式 5. 目录结构说明 6. 常见问题 7. 新手如何开始阅读代码 |
这个非常适合开源项目、练手项目、外包交付项目。文档不是越长越好,关键是让别人能跑起来。
适合场景:需求比较大,不知道怎么开始。
|
1 2 3 4 5 6 7 8 |
我想完成这个需求:【粘贴完整需求】。 请不要直接写代码。 请先帮我拆成 5 到 8 个小任务。 每个任务请包含: 1. 目标 2. 涉及文件 3. 风险点 4. 验收方式 |
这个模板适合中大型需求。比如重构、迁移、接入新接口、做新页面,都可以先让 Codex 拆任务。
如果你记不住上面的模板,记住这个公式就够了:
|
1 |
目标 + 范围 + 约束 + 输出格式 + 是否允许修改文件 |
举个例子:
|
1 2 3 4 5 |
目标:帮我排查登录失败问题 范围:只看前端代码 约束:不要修改任何文件 输出格式:列出可能原因、相关文件、排查顺序 是否允许修改:暂时不允许修改 |
组合起来就是:
|
1 2 3 |
请帮我排查登录失败问题。 只看前端代码,暂时不要修改任何文件。 请按可能原因、相关文件、排查顺序输出。 |
这就是一个清晰很多的 Codex 指令。
Codex 不是只能“写代码”。它更适合参与完整开发流程:
|
1 2 3 4 5 6 7 |
读项目 定位文件 拆任务 写代码 查 bug 做 review 补文档 |
新手最重要的技巧,是不要把需求丢成一团。你给它越清楚的目标、范围和验收方式,它越容易给出稳定结果。
如果你刚开始用 Codex,可以先从这 7 个模板里挑一个最简单的练习。不要一上来就让它重构整个项目,先让它帮你读懂一个模块,改一个小功能,写一份 README。这样更容易建立信心,也更容易看见它真正的价值。