Codex 提示词怎么写？20 个 AI 编程任务 Prompt 模板

Codex 的效果，很大程度取决于你如何描述任务。好的提示词不是越长越好，而是把目标、上下文、约束、输入文件、期望输出和验证方式说清楚。本文整理 20 个 AI 编程任务 Prompt 模板，适合站长、开发者和内容团队直接复用。

如果你正在搭建 AI 编程工作流，可以继续查看站内 实战工作流；如果你更关注日常操作，也可以浏览 使用技巧教程 和 问题排查教程。

写 Codex Prompt 的核心原则

和普通聊天不同，Codex 面对的是一个真实代码项目。你需要告诉它要解决什么问题、代码在哪里、不能做什么、如何判断完成。缺少这些信息时，AI 很容易过度修改、误解需求或跳过验证。

一个好 Prompt 应该包含什么

建议至少包含六类信息：任务目标、项目背景、相关文件、限制条件、期望输出、验证方式。如果任务复杂，还可以补充优先级、失败处理、兼容性要求和不要修改的范围。

不要只写一句话

“帮我优化代码”“修一下 Bug”“做个功能”都太模糊。更好的写法是：说明当前现象、目标行为、相关路径、不要改动的边界，以及完成后需要运行哪些检查。

通用 Prompt 框架

在开始使用 20 个模板之前，可以先记住这个通用框架。大部分 AI 编程任务都可以按这个结构改写。

通用模板

请完成以下任务：
目标：说明要实现或修复什么。
上下文：说明项目背景、相关模块和当前行为。
相关文件：列出可能相关的路径，未知时请先搜索。
限制：说明不要修改哪些内容，不要泄露密钥，不要做无关重构。
输出：说明希望得到代码修改、解释、测试结果还是清单。
验证：说明需要运行哪些命令、打开哪些页面或检查哪些结果。

这个框架适合大多数场景。接下来所有模板都围绕它展开。

模板 1-5：功能开发类

功能开发类任务最容易失控，因为 AI 可能会顺手重构项目。写提示词时要明确功能范围、交互细节和验收标准。

模板 1：新增一个小功能

请在现有项目中新增一个功能：[功能名称]。
要求：
1. 先阅读相关目录和现有实现风格；
2. 保持现有代码风格，不做无关重构；
3. 实现 [具体行为]；
4. 补充必要的错误状态和空状态；
5. 完成后说明修改了哪些文件，并给出验证步骤。

模板 2：新增页面

请新增一个页面：[页面名称]。
页面需要包含：[主要区块]。
请复用项目已有布局、组件和样式体系。
不要新增不必要的依赖。
完成后运行可用的检查命令，并汇总结果。

模板 3：新增 API 接口

请新增一个 API 接口：[接口用途]。
要求包含参数校验、错误处理、权限判断和返回结构。
请先查找项目现有 API 写法，并保持一致。
不要把任何密钥写入源码。

模板 4：新增 WordPress 自动化能力

请在当前 WordPress 自动发布脚本中新增：[能力]。
规则：密钥只能从 .env 读取，默认文章状态必须是 draft，不允许直接 publish，不允许删除线上文章。
请保持输出字段清晰，并避免打印任何敏感信息。

模板 5：实现前端交互

请实现 [交互名称]。
需要处理默认状态、加载状态、错误状态和移动端表现。
请优先复用已有组件，不要引入新的 UI 框架。
完成后说明如何手动验证。

模板 6-10：修复和排查类

修复类任务最重要的是复现信息。给 Codex 的信息越具体，越容易定位根因。

模板 6：根据报错修复 Bug

我遇到一个 Bug：
现象：[描述现象]
报错：[粘贴错误信息]
复现步骤：[步骤]
期望结果：[结果]
请先定位根因，不要直接修改。确认相关文件后，给出最小修改方案并说明验证方式。

模板 7：根据截图排查问题

请根据这张报错截图和项目代码排查问题。
请先判断可能的前端、后端或配置原因。
如果信息不足，请列出还需要哪些日志或文件。
不要猜测性大改，优先给出最小验证路径。

模板 8：修复构建失败

项目构建失败，错误如下：[错误日志]。
请分析失败原因，找到相关文件，给出最小修复。
修复后运行构建命令，并说明是否还有剩余风险。

模板 9：修复测试失败

以下测试失败：[测试名称和日志]。
请分析是测试需要更新，还是业务代码有问题。
不要为了通过测试而隐藏真实错误。
修复后重新运行相关测试。

模板 10：排查线上问题

线上出现问题：[现象]。
已知信息：[日志、时间、影响范围]。
请帮我列出排查顺序、可能原因和需要查看的文件。
先不要修改代码，先给出风险最小的诊断步骤。

模板 11-15：质量提升类

质量提升类任务包括重构、代码审查、性能优化、安全检查和测试补充。重点是限定范围，不要让 AI 做全项目大改。

模板 11：代码审查

请以代码审查的方式检查以下改动。
优先找 Bug、回归风险、安全问题和缺失测试。
请按严重程度排序，并给出文件和行号。
如果没有明显问题，也请说明剩余风险。

模板 12：小范围重构

请只重构 [文件/函数/模块]。
目标是提升可读性和减少重复。
不要改变对外行为，不要修改无关文件。
请说明重构前后逻辑是否等价，并给出验证方式。

模板 13：补充测试

请为 [功能/函数] 补充测试。
测试应覆盖正常情况、边界情况和错误情况。
请参考项目已有测试风格。
完成后运行相关测试命令。

模板 14：性能优化

请分析 [页面/接口/函数] 的性能问题。
先找瓶颈，不要直接重写。
优先给出低风险优化方案，并说明可能影响。
完成后说明如何衡量优化效果。

模板 15：安全检查

请检查 [模块] 是否存在安全风险。
重点关注权限、输入校验、输出转义、密钥泄露、文件上传和数据删除。
请只提出和当前代码相关的问题，不要泛泛而谈。

模板 16-20：交付和维护类

交付类任务帮助你把代码变成可维护成果，包括文档、部署、迁移、发布说明和工作流沉淀。

模板 16：生成使用文档

请为 [功能/脚本] 编写使用文档。
包括用途、配置项、运行命令、输入输出、常见错误和注意事项。
请基于当前代码，不要编造不存在的功能。

模板 17：整理发布说明

请根据本次修改整理发布说明。
包含新增功能、修复问题、影响范围、测试结果和回滚建议。
语言要简洁，适合给非技术成员阅读。

模板 18：部署前检查

请为当前改动生成部署前检查清单。
包括环境变量、依赖、数据库、缓存、权限、测试命令和回滚方案。
请标出高风险项。

模板 19：迁移旧代码

请把 [旧模块] 迁移到 [新结构]。
要求保持现有行为兼容，分步骤进行，不要一次性大改。
每一步都说明修改范围和验证方式。

模板 20：沉淀项目工作流

请根据当前项目，整理一份 AI 编程协作工作流。
包括需求描述、代码阅读、修改范围、测试验证、发布检查和风险控制。
要求适合团队复用。

如何组合这些模板

真实任务往往不只属于一个类型。比如新增功能时，可能还需要补测试、写文档和生成发布说明。推荐做法是分阶段提问，而不是把所有要求塞进一条超长 Prompt。

推荐顺序

可以先用“代码阅读”模板让 Codex 理解项目，再用“功能开发”模板实现，再用“代码审查”模板检查，最后用“测试”和“发布说明”模板收尾。这个流程也适合沉淀到 实战工作流。

常见问题

Codex Prompt 是不是越详细越好？

不是。有效信息越清楚越好，但无关细节越多，越容易干扰判断。重点写目标、上下文、约束和验证方式。

可以直接让 Codex 修改代码吗？

简单任务可以直接修改。大型项目、线上问题和高风险模块，建议先让 Codex 分析，再确认方案，最后应用补丁。

Prompt 里要不要写“不要泄露密钥”？

涉及配置、发布、接口和自动化脚本时建议写清楚。密钥应从环境变量读取，不应写进源码或输出日志。

这些模板适合 WordPress 项目吗？

适合。尤其是自动发布、插件开发、主题适配和问题排查，但要额外强调不修改主题核心文件、不删除线上文章、默认草稿状态。