ChatGPT Plus / Pro + Codex 编程实战：20 个开发者可直接复制的高质量 Prompt

很多人使用 ChatGPT 或 Codex 写代码时，最常输入的一句话可能是：

帮我看看这段代码。

或者：

帮我修复这个 Bug。

再或者：

帮我把这个项目优化一下。

不能说这些 Prompt 没有用。

但如果你真正开始让 Codex 接触完整项目，就会发现一个非常明显的问题：

任务描述越模糊，AI 自由发挥的空间越大。

而在软件工程里面：

自由发挥

很多时候并不是优点。

因为你真正需要的通常是：

只修这个 Bug 不要改其他功能 不要随便加依赖 不要改变 API 先找到根因 修改以后跑测试

这也是我现在使用 ChatGPT、Plus、Pro 和 Codex 时越来越重视的一点：

Prompt 的核心不是“写得长”，而是“边界清楚”。

目前 OpenAI 对 Codex 的定位已经明显偏向完整的软件工程 Agent：它可以围绕真实代码仓库完成开发、重构、迁移、代码审查等任务；Codex CLI 也能够在终端环境中检查代码、编辑文件以及执行命令。

所以这篇不讨论什么复杂的 Prompt 理论。

直接整理：

20 个我认为开发者真正用得上的 Codex Prompt

基本都可以直接复制，然后根据自己的项目稍微修改。

一、项目接手：先让 Codex 看懂整个仓库

这是我认为最值得保存的一条 Prompt。

第一次让 Codex 进入一个陌生项目时，不要立刻：

帮我优化这个项目。

先让它做 Repository Exploration。

Prompt 01：快速理解陌生项目

先不要修改任何文件。 请系统阅读当前代码仓库，并帮助我快速理解这个项目。 重点分析： 1. 项目的主要技术栈； 2. 程序入口； 3. 核心目录分别负责什么； 4. 数据库访问方式； 5. 用户认证方式； 6. API 的组织方式； 7. 前端状态管理方式； 8. 测试框架和测试目录； 9. 构建、Lint、Type Check 命令； 10. 项目中最重要的 5 个核心模块。 最后给我输出： - 项目架构概览； - 一次正常请求的数据流； - 最重要的文件； - 新开发者最容易踩坑的地方。 暂时不要修改代码。

它适合：

接手旧项目 开源项目研究 公司历史项目 第一次让 Codex 进入仓库

这里最重要的是：

暂时不要修改代码

先建立正确上下文。

二、不要直接修 Bug，先让它找“根因”

很多人遇到 Bug：

登录失败，帮我修。

Agent 很可能直接开始改代码。

但我们真正想要的是：

Root Cause Analysis

Prompt 02：Bug 根因分析

先不要修改代码。 问题： [在这里描述 Bug] 请先调查这个问题的根因。 要求： 1. 找到与问题相关的代码路径； 2. 从用户操作开始追踪完整执行流程； 3. 找出最可能的根因； 4. 区分“根因”和“表面现象”； 5. 判断是否还有其他地方存在相同问题； 6. 给出最小修改方案。 输出格式： Root Cause: 根因是什么 Evidence: 你根据哪些代码判断 Affected Files: 涉及哪些文件 Minimal Fix: 最小修改方案 Risk: 这个修改可能产生什么副作用 暂时不要修改代码。

这条非常适合真实项目。

因为最怕的情况是：

Bug A ↓ AI 打补丁 ↓ Bug A 暂时消失 ↓ 真正根因还存在 ↓ 出现 Bug B

三、第二阶段才真正让 Codex 修 Bug

根因确认以后，再执行：

Prompt 03：最小范围修复 Bug

根据刚才确认的根因修复这个 Bug。 要求： 1. 优先做最小范围修改； 2. 不重构无关代码； 3. 不改变现有公共 API； 4. 不增加新的第三方依赖； 5. 保持当前代码风格； 6. 为这个 Bug 增加回归测试； 7. 运行相关测试； 8. 如果测试失败，先判断是否由当前修改导致。 完成后告诉我： - 修改了哪些文件； - 每个文件为什么修改； - 增加了哪些测试； - 实际执行了哪些验证命令； - 是否还有剩余风险。

这里我最重视一句：

不重构无关代码

因为 AI Coding Agent 很容易：

修一个 Bug，顺手重构半个项目。

四、新功能开发，不要直接说“帮我实现”

例如：

增加邀请成员功能。

听起来非常明确。

实际上里面还有很多问题：

权限？ Token？ 过期时间？ 重复邀请？ 并发？ 已注册用户？ 未注册用户？ 撤销邀请？

所以最好分成 Plan 和 Implement。

Prompt 04：新功能技术方案

我要增加以下功能： [描述你的功能] 暂时不要写代码。 请先阅读项目中相关实现，然后给出技术方案。 方案必须包括： 1. 当前项目中可以复用哪些模块； 2. 需要新增什么； 3. 需要修改哪些文件； 4. 数据库是否需要改变； 5. API 是否需要新增或修改； 6. 权限如何控制； 7. 异常情况有哪些； 8. 并发情况下可能出现什么问题； 9. 应该增加哪些测试； 10. 是否存在向后兼容风险。 优先选择： 最少代码 最少新依赖 最少公共接口变化 最小修改范围 最后给出分步骤 Implementation Plan。 不要实施。

Prompt 05：按照方案实现功能

Plan 没问题以后：

按照刚才确认的 Implementation Plan 实现功能。 规则： - 不扩大功能范围； - 不修改无关代码； - 优先复用现有工具； - 保持现有 API 风格； - 不增加不必要的依赖； - 所有新的业务逻辑必须有对应测试； - 修改完成后运行相关测试； - 如果项目有 Type Check / Lint，也执行相关检查。 不要因为测试失败就直接修改已有测试。 首先判断： 是实现有问题， 还是测试确实应该改变。 最后输出： Files Changed Tests Added Commands Executed Test Results Remaining Risks

这两个 Prompt 配合使用，会比：

帮我实现 XXX

稳定很多。

五、让 Codex 专门检查 Git Diff

我认为这是 AI 编程中一个非常被低估的场景。

不是：

AI 写代码

而是：

AI Review 人写的代码

甚至：

AI Review AI 写的代码

OpenAI 当前也把代码审查作为 Codex 的主要工程场景之一。

Prompt 06：高质量 Git Diff Review

Review 当前 Git Diff。 先不要修改任何文件。 只关注真正可能影响生产环境的问题： 1. Logic Bug 2. Security Issue 3. Race Condition 4. Backwards Compatibility 5. Data Corruption Risk 6. Missing Error Handling 7. Missing Important Tests 8. Performance Regression 不要花大量篇幅讨论： - 命名偏好； - 格式； - 纯审美问题； - 无关紧要的重构建议。 每一个发现必须包含： Severity: Critical / High / Medium / Low File: 具体文件 Problem: 问题是什么 Scenario: 什么情况下会触发 Impact: 可能造成什么后果 Recommended Fix: 建议如何修改 如果没有发现真实问题，明确告诉我没有发现， 不要为了输出内容而强行寻找问题。

最后一句很重要：

不要为了输出内容而强行寻找问题。

六、专门检查安全问题

通用 Review 和 Security Review 最好分开。

Prompt 07：Security Review

对当前项目进行安全审查。 暂时不要修改代码。 重点检查： Authentication Authorization SQL Injection Command Injection XSS CSRF SSRF Path Traversal File Upload Rate Limiting Token Handling Password Handling Secrets Exposure Privilege Escalation IDOR 要求： 不要只根据理论列安全风险。 必须结合当前代码判断。 每一个问题给出： 1. 漏洞位置； 2. 触发条件； 3. 攻击路径； 4. 潜在影响； 5. 严重等级； 6. 建议修复方式。 如果某一风险已经被现有代码正确防御， 也说明现有防御机制在哪里。 先报告，不修改。

这种 Prompt 的关键在于：

必须结合当前代码判断

否则 AI 很容易给你一份：

Web 安全十大常见问题百科。

七、性能问题不要直接“优化整个项目”

这是另一个非常常见的问题。

Prompt：

帮我优化项目性能。

范围实在太大。

可以改成：

Prompt 08：接口性能分析

调查这个接口为什么慢： [接口路径] 先不要修改代码。 从请求入口开始追踪整个执行路径。 重点检查： 1. 数据库查询次数； 2. 是否存在 N+1； 3. 是否重复查询相同数据； 4. 是否存在不必要的串行操作； 5. 外部 API 调用； 6. 大量数据转换； 7. 不必要的网络请求； 8. 缓存使用情况； 9. 算法复杂度； 10. 是否存在阻塞操作。 最后按照影响排序： P0 P1 P2 给出最可能影响 P95 latency 的三个问题。 不要先重构代码。 先找到真正瓶颈。

Prompt 09：实施性能优化

根据刚才确定的性能瓶颈， 只优化优先级最高的问题。 要求： - API 输入输出保持不变； - 不修改数据库 Schema； - 暂时不要增加缓存； - 不增加新依赖； - 修改范围尽量小； - 必须保留现有行为。 如果项目存在 Benchmark 或性能测试， 运行对应验证。 最后比较： Before After 并说明性能改善来自哪里。

这样 Agent 的目标会非常清楚。

八、重构代码：一定要锁住“行为不变”

AI 非常擅长重构。

同时也非常容易：

重构着重构着 把行为也改了

所以：

Prompt 10：安全重构 Prompt

Refactor 以下模块： [模块路径] 目标： 提高可读性和可维护性。 严格约束： 1. 对外行为完全不变； 2. 公共 API 不变； 3. 函数输入输出不变； 4. 数据库行为不变； 5. 错误类型和关键错误信息不变； 6. 不添加新功能； 7. 不增加第三方依赖； 8. 不修改无关模块。 开始之前： 先运行现有测试并确认基线。 重构完成之后： 再次运行相同测试。 最后展示： Before behavior After behavior Tests before Tests after Files changed

重构时最重要的词其实不是：

Clean

而是：

Behavior Preservation

九、数据库 Migration 是非常适合 Agent 的任务

例如：

User 增加 status 字段。

不要只让 AI 修改 schema。

Prompt 11：安全数据库 Migration

我要进行以下数据库变更： [描述变更] 先分析现有 Schema 和数据访问代码。 然后设计 migration。 重点考虑： 1. 现有数据如何兼容； 2. 是否需要默认值； 3. NULL 如何处理； 4. Migration 是否会锁表； 5. 回滚方式； 6. 旧版本应用与新 Schema 是否能短暂共存； 7. 是否需要分阶段部署； 8. 哪些查询需要同步修改。 优先设计 Backwards-Compatible Migration。 先给方案，不要直接执行数据库修改。

尤其真实生产系统：

Schema Migration

和：

改 TypeScript interface

完全不是一个风险等级。

十、让 Codex 自动补测试

AI 很适合补测试。

但不要写：

多写点测试。

Prompt 12：补充有价值的单元测试

分析这个模块现有测试覆盖： [模块路径] 不要为了提高 Coverage 数字而机械增加测试。 重点寻找真正重要但尚未覆盖的行为： 1. 正常路径； 2. 输入边界； 3. 空值； 4. 非法状态； 5. 权限问题； 6. 重复请求； 7. 并发情况； 8. 外部依赖失败； 9. 数据库异常； 10. 历史 Bug 的回归场景。 先告诉我缺少哪些测试。 按照风险排序。 然后只添加高价值测试。

这一条中的关键是：

不要为了 Coverage 数字而机械增加测试

十一、专门让 AI 找“没考虑到的边界条件”

开发时间长了会发现：

Bug 最多的地方通常不是：

Happy Path

而是：

Edge Cases

Prompt 13：Edge Case Hunter

不要修改代码。 阅读以下功能： [功能或文件] 假设正常路径已经可以工作。 你的任务不是检查正常情况， 而是专门寻找 Edge Cases。 从以下角度考虑： - null - empty - zero - negative - duplicate - retry - timeout - concurrency - permission - deleted data - stale data - network failure - partial failure - extremely large input - repeated submission 给出最值得测试的 10 个边界场景。 每个场景说明： Input Expected Behavior Current Behavior Potential Risk

这是我非常喜欢的一类 Prompt。

十二、前端页面 Bug 也不要只描述“页面不对”

Prompt 14：React / Next.js 前端 Bug 分析

调查以下前端问题： [描述问题] 先不要修改代码。 请追踪： User Action ↓ Component ↓ State ↓ Hook ↓ API Request ↓ Response ↓ State Update ↓ Render 重点检查： 1. stale state； 2. race condition； 3. duplicated request； 4. incorrect dependency； 5. loading state； 6. error state； 7. optimistic update； 8. component unmount； 9. cache invalidation； 10. server/client boundary。 找到最可能的根因后， 给出最小修改方案。

对于 React 项目，这种“数据流追踪”往往比：

帮我看看组件

效果更好。

十三、TypeScript 项目禁止 AI 用 any 糊弄过去

非常经典：

遇到类型错误。

AI：

constdata:any=...

错误没了。

问题也被埋起来了。

Prompt 15：TypeScript 类型修复

修复当前 TypeScript 类型错误。 要求： 禁止： - 使用 any； - 使用 @ts-ignore； - 使用 @ts-nocheck； - 删除类型检查； - 无意义的强制类型断言。 优先寻找真正的类型不一致来源。 检查： API response type Database model Shared type Component props Generic Nullable value 目标不是： 让 TypeScript 不报错。 目标是： 让类型真实反映运行时数据。 修改以后运行 Type Check。

这比：

Fix TypeScript errors

靠谱得多。

十四、让 Codex 清理技术债，但不要让它重写项目

Prompt 16：Technical Debt Audit

对当前项目做一次 Technical Debt Audit。 不要修改代码。 寻找： 1. 重复业务逻辑； 2. 已废弃代码； 3. TODO / FIXME； 4. 过度复杂模块； 5. 重复数据库查询； 6. 绕过类型系统的代码； 7. 没有测试保护的关键逻辑； 8. 过度耦合； 9. 隐式业务规则； 10. 高风险 Legacy Code。 按照： Impact × Probability × Fix Cost 进行排序。 只列最值得处理的前 10 项。 不要建议“重写整个系统”。

最后一句也是灵魂：

不要建议重写整个系统。

十五、让 AI 判断“这个依赖到底有没有必要”

现在很多项目：

npm install

越来越随意。

AI 也特别喜欢推荐新库。

Prompt 17：Dependency Review

我要实现： [功能] 在添加任何新的第三方依赖之前， 先检查当前项目。 回答： 1. 现有依赖是否已经能完成； 2. Node / Browser / Framework 原生能力能否完成； 3. 自己实现需要多少代码； 4. 引入新依赖的收益； 5. Bundle Size 影响； 6. Maintenance Risk； 7. Security Risk； 8. Lock-in Risk。 只有当新依赖明显优于现有方案时， 才建议添加。 否则优先复用已有能力。

十六、让 Codex 帮你拆大型需求

假设老板一句话：

做一个团队权限系统。

千万别直接 Implement。

Prompt 18：大型需求拆解

需求： [粘贴完整需求] 不要写代码。 请把这个需求拆成可以独立开发、 独立测试、独立 Review 的任务。 原则： 每一个 Task 应尽量： - 修改范围小； - 目标单一； - 可以独立测试； - 可以独立提交； - 尽量减少跨模块依赖。 输出： Phase 1 Task 1 Task 2 Phase 2 Task 3 Task 4 Phase 3 Task 5 每一个 Task 写清楚： Goal Affected Modules Dependencies Tests Risk Definition of Done 最后给出推荐实施顺序。

这就是把：

“大需求”

转换成：

Agent 可以执行的小任务

十七、让 Codex 做上线前最后一次检查

Prompt 19：Pre-Release Review

假设当前 Branch 明天就要上线生产环境。 不要修改代码。 对当前 Branch 相比主分支的所有修改 进行一次 Pre-Release Review。 重点检查： 1. 数据库 Migration； 2. 配置变更； 3. Environment Variables； 4. Breaking Change； 5. Authentication； 6. Permission； 7. Error Handling； 8. Logging； 9. Monitoring； 10. Rollback； 11. Data Compatibility； 12. Tests。 最终输出： BLOCKER 上线前必须解决 WARNING 建议解决 SAFE 已经检查，没有明显问题 最后回答： 从代码角度， 你是否建议当前版本进入生产环境？ 说明原因。

这个场景非常适合在 PR 合并前跑一次。

十八、最后一个：让 Codex 检查“自己刚才写的代码”

这是一个非常简单但特别实用的 Prompt。

AI 写完以后，不要马上结束。

再发：

Prompt 20：Self Review

重新检查你刚才完成的所有修改。 把自己当成一个没有参与开发的 Senior Engineer。 不要假设刚才的实现是正确的。 重新阅读： - 原始需求； - Implementation Plan； - Git Diff； - 相关测试。 重点寻找： 1. 是否遗漏需求； 2. 是否错误理解需求； 3. 是否修改了无关代码； 4. 是否存在更小的实现方案； 5. 是否引入 Bug； 6. 是否存在并发问题； 7. 是否有安全问题； 8. 是否破坏向后兼容； 9. 测试是否真的覆盖核心行为； 10. 是否存在“测试通过但功能错误”的可能。 先只 Review。 不要立即修改。 如果发现问题， 按严重程度告诉我。

我经常建议在复杂任务结束时做这一步。

因为：

Implement Mode

和：

Review Mode

实际上是两种不同的思考方式。

十九、这 20 个 Prompt 背后的共同规律

如果仔细观察前面的 Prompt，会发现我并没有使用很多所谓的：

神奇咒语

例如：

你是世界顶级程序员

或者：

你拥有 20 年开发经验

真正反复出现的是这些东西：

Goal Scope Constraints Process Verification Output

也就是：

Goal

到底要解决什么问题？

Scope

允许修改什么？

Constraints

不能做什么？

Process

先分析还是直接开发？

Verification

怎么证明完成了？

Output

最终我要看到什么？

这六个部分，比大量形容词重要得多。

二十、我现在最常用的万能 Codex Prompt 模板

如果上面 20 条你不想全部保存，只保存一条，可以保存下面这个：

Task: [描述任务] Goal: [最终希望实现什么] Before Coding: 先阅读相关代码并理解当前实现。 如果任务涉及多个模块， 先输出 Implementation Plan。 暂时不要立即修改。 Constraints: - Prefer the smallest reasonable change. - Do not modify unrelated code. - Do not introduce new dependencies unless necessary. - Preserve existing public APIs. - Follow existing project patterns. - Reuse existing utilities whenever possible. Implementation: 按照确认后的方案实现。 Verification: 修改完成后： 1. 运行相关测试； 2. 运行 Type Check； 3. 根据项目情况运行 Lint / Build； 4. 修复由当前修改引入的问题。 Review: 重新检查 Git Diff。 重点检查： - logic bugs - security issues - race conditions - backwards compatibility - missing tests Final Report: 告诉我： 1. Changed Files 2. What Changed 3. Tests Executed 4. Test Results 5. Remaining Risks

然后每次只替换：

Task

和：

Goal

就已经能覆盖大量日常开发场景。

二十一、ChatGPT Plus / Pro + Codex 真正拉开效率差距的地方

很多开发者刚开始使用 ChatGPT 编程时，关注的是：

这个模型会不会写代码？

后来关注：

生成的代码准确率高不高？

但进入 Coding Agent 阶段以后，我认为应该增加另外几个问题：

它是否理解我的仓库？

它是否知道修改边界？

它有没有真的运行测试？

它能否自己检查 Git Diff？

它有没有破坏原有行为？

任务失败以后能否继续调查？

Codex 现在已经不仅存在于单一聊天窗口中，而是覆盖 ChatGPT、终端、编辑器以及 Codex App 等开发入口；官方也在持续强化多 Agent、代码审查和工程任务执行能力。

与此同时，Codex 还支持通过AGENTS.md为项目提供持续性的开发指导，这意味着很多以前每次都需要重新写进 Prompt 的规则，可以进一步沉淀成项目上下文。

因此真正值得建立的不是：

Prompt 收藏夹

而是：

自己的 AI Development Workflow

二十二、推荐的实际工作流程

我现在更推荐：

需求 ↓ ChatGPT 分析 ↓ 形成明确 Task ↓ Codex Explore ↓ Codex Plan ↓ 人工检查 Plan ↓ Codex Implement ↓ Codex Test ↓ Codex Review ↓ 人工检查 Git Diff ↓ Commit

复杂任务再增加：

Security Review Performance Review Edge Case Review Pre-Release Review

于是 ChatGPT / Codex 就不再只是：

代码生成器

而逐渐成为：

需求分析 + 代码搜索 + 方案设计 + 开发 + 测试 + Review

这一整套工程工作流的一部分。

结语

如果 2023 年使用 ChatGPT 写代码的核心技巧是：

学会向 AI 提问。

那么到了现在，我认为更重要的是：

学会给 AI 定义任务边界。

特别是在 ChatGPT Plus、Pro 和 Codex 这样的工具组合逐渐进入真实开发流程以后，Prompt 的价值已经不只是：

让回答更漂亮

而是：

控制 Agent 行为

真正好用的开发 Prompt，往往都会告诉 AI：

你要解决什么

你先做什么

你不能做什么

你可以修改什么

你如何证明已经完成

如果把这些基本原则建立起来，即使没有所谓的“神级 Prompt”，日常使用 ChatGPT 和 Codex 的稳定性也会提高很多。

最终真正值得积累的，也不是：

1000 条 Prompt

而是一套属于自己的：

ChatGPT + Codex AI 编程工作流

Prompt 会不断变化。

模型会不断升级。

Plus、Pro 的具体产品能力和使用方式也可能继续变化。

但是软件工程最核心的几个原则不会轻易改变：

理解问题 ↓ 控制范围 ↓ 最小修改 ↓ 运行验证 ↓ 代码审查 ↓ 再交付

当 AI 真正进入软件开发流程之后，

这些原则反而比以前更重要。