AI 编程 Prompt

AI 编程 Prompt 的目标不是让模型凭空写代码，而是把“帮我做一下”改写成工程 师能执行、AI 能理解、完成后能验证的任务说明。它需要交代项目背景、现有代 码、错误现象、修改范围、禁止事项和验收命令。

这页适合开发者、产品经理、技术负责人、学生、创业者和需要和 Codex 协作的 团队。你可以用它读代码、修 Bug、写测试、做小重构、生成代码审查清单，也可 以把普通聊天 Prompt 改成适合交给 Codex 的 Goal。

把编程 Prompt 变成可验证工程任务

单次代码问题可以先在 OfApp.cn 的网页入口中整理思路；当任务需要进入仓库、脚本、Codex 或内部工具时，再把 Prompt 改成带范围、验证和交付要求的任务说明。具体模型、能力和价格请以 OfApp.cn 控制台或官方文档为准。

打开 OfApp.cn

页面摘要

项目	说明
阅读时间	约 6 分钟
更新时间	2026-07-03
适合读者	开发者、产品经理、学生、创业者、技术团队
适合任务	读代码、修 Bug、写测试、重构、代码审查、Codex Goal
你会得到	通用编程 Prompt、读代码模板、修 Bug 模板、写测试模板、重构模板、代码审查模板、Codex 任务 Prompt、交付格式和复核矩阵
不适合做什么	不适合替代安全审计、生产迁移审批、密钥管理、合规判断或没有验收标准的大范围重写

适合哪些编程任务

场景	AI 适合做什么	人要复核什么
读代码	解释模块职责、调用关系、状态流和风险点	业务语义、权限边界、历史兼容
修 Bug	整理复现、分析可能根因、提出最小修复	真实影响范围、回归路径、上线风险
写测试	列测试用例、补边界场景、生成测试文件	断言是否有效、是否覆盖关键业务
小重构	减少重复、拆函数、补类型、整理命名	行为是否保持、diff 是否过大
代码审查	找错误处理、空状态、权限和安全风险	是否误判业务规则、是否遗漏上下文
生成任务单	把聊天需求改成 Codex Goal	范围、验证命令、禁止事项是否完整

不适合直接交给 AI 的任务包括：没有验收标准的大范围重写、生产数据迁移、权 限和支付核心逻辑、密钥处理、合规判断，以及需要业务负责人拍板的架构决策。

编程任务成熟度分层

层级	典型说法	更好的 Prompt 形态	是否适合交给 Codex
0 想法阶段	这个功能能不能做	让 AI 帮你拆需求、列风险和待确认问题	不适合直接执行
1 问题分析	这里为什么报错	给错误现象、环境、日志和复现步骤	适合先分析
2 小范围修改	修复这个按钮、补一个测试	给文件范围、行为边界和验证命令	适合执行
3 多文件任务	重构模块、接入工具、补完整测试	给目标、禁区、计划、测试矩阵和交付格式	适合执行但要分阶段
4 团队流程	每次 PR 都要审查、生成测试建议	把 Prompt 固化到脚本、CI 或内部工具	适合工具化

很多失败的编程 Prompt 卡在 0 到 1 层：用户心里有一个模糊目标，却没有给出代 码路径、错误现象或验收方式。把任务提升到 2 层，AI 才更容易给出可检查的工 程结果。

编程 Prompt 流程图

通用编程 Prompt

这段适合大多数开发任务。使用时把方括号换成真实信息，不确定的部分写“需要 确认”，不要让模型猜。

你是一个谨慎的高级工程师。请基于我提供的代码、日志和项目背景完成任务，
不要假设不存在的文件、API、依赖、配置或业务规则。

任务类型：
[读代码 / 修 Bug / 写测试 / 重构 / 代码审查 / 生成 Codex Goal]

项目背景：
- 技术栈：[语言、框架、运行方式]
- 相关路径：[文件、目录、测试、配置]
- 当前现象：[报错、需求、用户行为或性能问题]

目标：
[希望完成什么，用户应该看到什么结果]

限制：
- 不要修改：[文件、模块、数据库、接口契约]
- 不要引入：[新依赖、破坏性迁移、无关重构]
- 安全边界：[不要读取或输出密钥、Cookie、用户隐私]

验证命令：
[npm test / npm run build / pytest / cargo test / 其他]

请输出：
1. 你对任务的理解和假设
2. 需要检查的文件或日志
3. 建议的最小修改方案
4. 风险和验证方式
5. 如果信息不足，请先列出需要补充的问题

输入材料：
[粘贴脱敏日志、代码片段、文件路径或需求说明]

读代码 Prompt

读代码时不要只问“这段代码什么意思”。更稳定的做法是说明你想理解的层级： 模块职责、调用链、数据流、状态变化、权限边界，还是后续要改哪里。

请阅读下面的代码或文件路径，帮我理解它在项目中的作用。

我关心：
- 模块职责
- 主要输入输出
- 调用关系
- 状态或数据如何变化
- 修改这里可能影响哪些功能
- 哪些地方需要我回到源码确认

代码或路径：
[粘贴代码片段或文件路径]

适合输出：

输出	用途
模块摘要	快速知道代码负责什么
调用关系	判断改动会影响哪里
风险点	找到权限、状态、错误处理问题
待确认问题	避免把猜测当结论

修 Bug Prompt

修 Bug 的 Prompt 要围绕复现和验证展开。只贴一行错误，模型很容易给出泛泛建 议；给出命令、日志、环境、预期行为和限制，才适合进入真实修复。

请帮我分析下面的 Bug，并生成最小修复计划。

复现步骤：
1. [操作或命令]
2. [操作或命令]

实际结果：
[错误信息、截图描述、状态码或失败命令]

预期结果：
[正确行为]

环境：
[系统、浏览器、Node/Python/SDK 版本、部署环境]

限制：
- 先定位根因，不要直接大范围重构
- 不要删除已有功能绕过错误
- 如果需要改代码，请说明要改哪些文件
- 修复后需要补或更新回归测试

日志或代码：
[粘贴脱敏日志、stack trace、相关文件路径]

把这段交给 Codex 前，可以继续参考 用 Codex 修 Bug。

写测试 Prompt

写测试的关键不是“覆盖率数字”，而是把业务路径、边界输入、错误状态和已有测 试风格写清楚。没有这些信息，AI 可能生成能运行但没有价值的断言。

请为下面的函数、组件或接口设计测试用例，并尽量沿用项目已有测试风格。

目标对象：
[函数名、组件名、API 路径或文件路径]

需要覆盖：
- 正常输入
- 空值、缺失字段或非法格式
- 权限不足或外部服务失败
- loading、empty、error 状态
- 已知 Bug 的回归场景

限制：
- 不要改业务实现，除非测试暴露明确问题
- 不要引入新的测试框架
- 如果现有代码不可测试，请说明阻塞点和最小改造建议

请输出：
1. 用例表
2. 建议新增或修改的测试文件
3. 测试代码
4. 运行命令
5. 仍需人工确认的断言

更完整的流程可以参考 用 Codex 生成测试。

重构 Prompt

重构 Prompt 要把“为什么改”和“不能改变什么”写清楚。否则模型容易把重构做 成重写，导致 diff 难审、回归难查。

请评估下面这段代码是否适合做小范围重构，并给出保守方案。

重构目标：
[减少重复 / 拆函数 / 提升可读性 / 补类型 / 降低耦合]

行为边界：
- 对外 API 不变
- UI 文案不变
- 数据结构不变
- 旧测试应继续通过

请输出：
1. 当前代码的主要问题
2. 是否值得重构
3. 最小重构方案
4. 可能改变行为的风险
5. 需要补充的测试
6. 如果风险过高，请建议暂不修改

代码或路径：
[粘贴代码片段或文件路径]

如果已经准备让代理执行，可继续看 用 Codex 重构项目。

代码审查 Prompt

代码审查 Prompt 不应只要求“看看有没有问题”。你要指定审查重点：正确性、错 误处理、安全、性能、可访问性、兼容性、测试缺口和隐私风险。

请以代码审查的方式检查下面的 diff 或代码片段。

审查重点：
- 是否实现了目标行为
- 是否存在空值、边界、权限或并发问题
- 是否泄露密钥、Cookie、用户隐私或内部地址
- 是否缺少错误状态、加载状态或回归测试
- 是否引入无关格式化、无关重构或不必要依赖

请按严重程度输出：
1. 必须修复的问题
2. 建议修复的问题
3. 缺少的测试
4. 可以保留的风险
5. 需要作者补充的信息

代码或 diff：
[粘贴内容]

审查输出要能回到具体文件、函数或行为，不要只接受“整体看起来不错”。

Codex 任务 Prompt

给 Codex 的 Prompt 更像任务单。它要允许 Codex 读取仓库、修改文件和运行命 令，因此必须写清可以动哪里、不能动哪里、如何证明完成。

Goal: 在当前项目中完成 [任务名称]，保持现有架构和代码风格。

背景：
- 项目类型：[Astro 文档站 / Next.js 应用 / Python CLI / 其他]
- 用户目标：[谁在什么场景下需要什么结果]
- 相关路径：[文件、目录、测试或让 Codex 自行查找]

要求：
- 先读取项目结构、配置、相关源码和已有测试。
- 修改前给出简短计划，说明准备检查哪些文件。
- 只做完成目标所需的最小改动。
- 不要覆盖用户已有修改，不要做无关重构。
- 不要读取、打印或提交真实 API Key、Cookie 或用户隐私数据。

验证：
- 运行：[测试、lint、构建或手动验收命令]
- 如果无法运行，请说明原因和替代检查。

完成后请汇报：
1. 改动文件
2. 关键实现思路
3. 验证命令和结果
4. 剩余风险或需要人工确认的事项

更多任务单写法可以看 Codex Goal 提示词模板。

交付格式模板

给编程任务增加固定交付格式，可以减少“看起来改了，但不知道改对没有”的情 况。适合在普通对话、Codex Goal 或团队内部工具里复用。

请按下面格式交付：

任务理解：
- 用 2 到 4 条说明你认为要解决的问题。
- 标出你做出的假设。

修改计划：
- 列出准备检查的文件、命令和风险点。
- 如果信息不足，先列问题，不要直接改。

实现说明：
- 列出修改文件。
- 说明每个文件为什么要改。
- 明确没有改动的边界。

验证结果：
- 列出已运行命令和结果。
- 如果某条命令无法运行，说明原因和替代检查。

剩余风险：
- 标出需要人工确认的业务规则、视觉细节、安全边界或上线步骤。

这个格式不追求长答案，而是让结果能被复核。特别是团队协作时，交付信息比单 段解释更容易进入 PR 描述、任务记录和复盘文档。

示例：把一句话改成可执行任务

不推荐这样问：

帮我修一下登录报错。

更稳定的写法：

请帮我把下面的问题整理成可交给 Codex 的修复任务。

问题：登录后跳回首页，但用户仍显示未登录。
复现：本地运行 npm run dev，使用测试账号登录，回调后刷新页面状态丢失。
期望：登录成功后保持会话状态，刷新页面仍能识别用户。
已知信息：浏览器控制台没有明显报错，Network 里回调接口返回 200。
限制：不要改数据库 schema，不要更换认证方案，不要提交真实 Cookie。
验证：修复后运行 npm test 和 npm run build，并手动检查登录流程。

请输出 Goal Prompt，包含背景、需要检查的文件、禁止事项、验证命令和交付格式。

理想结果应该包含：

模块	示例
背景	本地登录回调后会话状态丢失
检查范围	auth 配置、回调路由、session 读取、客户端状态同步
禁止事项	不改数据库，不打印 Cookie，不重写认证体系
验证	单元测试、构建、本地登录流程
交付	根因、改动文件、验证结果、剩余风险

发布前复核清单

检查项	问题
目标	Prompt 是否说明用户要完成什么，而不是只描述技术动作？
上下文	是否提供框架、命令、文件路径、错误日志或相关代码？
范围	是否写明可以修改和禁止修改的区域？
安全	是否排除密钥、Cookie、生产数据和个人隐私？
验证	是否给出测试、lint、构建或手动验收方式？
输出	是否要求列出假设、风险、改动文件和验证结果？
复核	是否要求人工检查 diff、测试断言和业务边界？

Prompt 质量判断矩阵

维度	低质量写法	可执行写法
目标	帮我优化一下	修复登录回调后刷新丢失会话的问题
上下文	代码有问题	本地 npm run dev，回调接口 200，刷新后用户态为空
范围	你自己看着改	优先检查 auth 配置、回调路由和 session 读取，不改数据库 schema
约束	随便实现	不更换认证方案，不打印 Cookie，不引入新依赖
验证	应该能用	运行 npm test、npm run build，手动验证登录后刷新
交付	给我答案	输出根因、改动文件、验证命令、剩余风险

如果一个 Prompt 在这六个维度都能写清，通常已经从“聊天问题”变成了“工程任 务”。这时再交给 Codex 或脚本化工作流，失败率会低很多。

什么时候接入工具链

如果只是一次性代码解释或报错分析，用对话式 Prompt 就够。只要任务需要读取 仓库、修改文件、运行命令、补测试或提交代码，就应改成 Codex Goal 或内部工 具任务单。

如果项目需要统一调用 OpenAI 兼容接口，可以在开发工作流中使用 OfApp.cn 作 为入口。具体模型、能力、套餐和价格请以 OfApp.cn 控制台或官方文档为准。更 偏工程落地的配置方式可参考 AI 辅助开发。

常见问题

AI 编程 Prompt 要贴完整项目吗？

不用一开始就贴完整项目。更好的方式是给目标、现象、相关路径、验证命令和限 制，让 AI 先判断需要读哪些文件。给 Codex 时，可以要求它自行读取项目结构和 相关源码。

什么时候给代码，什么时候只给路径？

短代码片段可以直接粘贴；真实仓库任务更适合给路径和目标，让 Codex 读取本 地文件。涉及敏感业务、生产日志或用户数据时，先脱敏再提供。

AI 写的代码可以直接合并吗？

不建议。代码需要经过测试、构建、diff 审查和业务复核。Prompt 中应明确要求 模型说明假设、验证结果和剩余风险。

修 Bug 时为什么要写复现步骤？

复现步骤能让 AI 区分“看到报错”和“证明问题存在”。没有复现，模型容易猜根 因，也容易改到无关位置。

写测试 Prompt 应该要求覆盖率吗？

覆盖率可以作为参考，但更重要的是关键路径和边界条件。建议要求 AI 先列用例 表，再生成测试代码，便于人工判断断言是否有意义。

能不能让 AI 一次完成重构和加功能？

不建议混在一个任务里。新增功能、修 Bug、补测试和重构最好拆开，否则 diff 难审，回归范围也不清楚。

OfApp.cn 在编程 Prompt 中适合做什么？

它更适合作为统一的 AI 入口：单次问题可在网页入口中整理，稳定任务可接入 Codex、脚本或内部工具。涉及具体模型、能力和价格时，请以 OfApp.cn 控制台 或官方文档为准。

相关文章

• Prompt 模板中心：从办公、写作、研究、自动化等场景选择模板。
• AI 辅助开发：把 Prompt 落到代码仓库和验证流程。
• Codex Goal 提示词模板：把任务写成代理可执行的 Goal。
• 用 Codex 修 Bug：围绕复现、根因和回归测试修复问题。
• 用 Codex 生成测试：把用例、断言和命令写清楚。
• 用 Codex 重构项目：控制重构范围和回归风险。
• AI 自动化 Prompt：把重复开发流程变成可执行方案。

资料来源

• OfApp.cn 官方首页、API 文档与 Genius Playground 页面：用于确认网页入口、API Key、OpenAI 兼容接口、Codex 相关入口和产品事实边界；涉及模型、能力、套餐和价格时，请以 OfApp.cn 控制台或官方文档为准。
• OpenAI Prompt engineering 文档：用于参考把指令放入文件、明确任务目标、上下文材料和输出要求的组织方式。
• OpenAI Codex 文档与案例：用于参考让代理先阅读项目、理解结构、再生成代码、文档或审查结果的工作方式。
• 本站已有专题：AI 辅助开发、Codex Goal 提示词模板、用 Codex 修 Bug 和 用 Codex 生成测试。

带走什么

AI 编程 Prompt 的质量取决于上下文、边界和验证。把需求背景、现有代码、限 制、测试命令和交付要求写清楚，模型才更可能给出可审查、可运行、可回退的工 程结果。