Appearance
Codex 提示词教程：把需求拆成可执行的代码任务
Codex 的输出质量通常取决于任务边界，而不是提示词长短。一个可执行的请求应当让它知道：要改什么、不要改什么、如何判断完成，以及遇到不确定信息时先做什么。
图示：一条可复用的任务提示词由目标、上下文、约束和验收组成，图片为本站原创示意图。
四段式提示词结构
目标：用动词描述结果。把“优化一下登录”改成“在 src/auth 中增加登录失败次数限制，并保留现有 API 返回结构”。
上下文：列出入口文件、相关模块、运行命令和当前现象。不要一次粘贴整个仓库；先让 Codex 自己读取项目，再指出重点文件。
约束：提前写出不可违反的规则，例如“不新增依赖”“保持 Node 20 兼容”“不要改数据库结构”“先补测试再改实现”。
验收：把完成条件写成检查项，包括测试命令、接口示例、错误场景、文件范围和输出格式。
三个可直接改写的模板
新功能模板
text
目标：在 [目录/模块] 增加 [功能]。
先做：阅读 [入口文件]、现有测试和相关类型定义，先说明实现计划。
约束：不新增依赖；保持 [运行环境/接口] 兼容；不要修改 [明确排除项]。
验收：补充 [测试场景]，运行 [命令]，最后列出修改文件和未覆盖风险。Debug 模板
text
现象：执行 [命令] 时出现 [错误]。
环境：[语言、框架、版本、操作系统]。
范围：先检查 [文件/模块]，不要先重写整个功能。
要求：按“复现条件 -> 根因证据 -> 最小修复 -> 回归测试”输出，不确定时明确说明假设。Code Review 模板
text
请审查以下改动，按严重程度排序：正确性、安全性、性能、可维护性、测试缺口。
每条问题包含：文件与行、触发条件、影响、建议修复。
如果没有问题，请说明检查范围和仍需人工验证的部分，不要为了凑数量虚构问题。让 Codex 先计划再动手
对于跨文件任务，可以明确要求“先不要修改，先列出计划和将读取的文件”。审核计划后再让它执行，能减少误删、重复实现和对旧接口的误改。迁移、重构和依赖升级尤其适合这样做。
另一个做法是分阶段提交：先补测试，再实现，再运行检查。每个阶段都保留一个可读 diff，出现偏差时更容易定位。
什么时候换到 AIMI 或 AICNBOX
如果任务重点是把模糊想法整理成产品需求、会议纪要、PPT 大纲或视觉素材，可以先在 AIMI（chat.aimirror123.com）或 AICNBOX（chat.aicnbox.com）中完成内容整理，再把最终需求交给 Codex 落地。两者的具体模型和功能以当前页面为准，也不等同于 OpenAI 官方服务。
常见问题
Codex 提示词教程中为什么要写验收标准？
因为“写完”不是可验证结果。测试命令、错误场景和文件范围能让 Codex 判断任务是否闭环，也方便你复查。
Codex 提示词应该一次写很长吗？
不必。先给目标和范围，再根据计划补充约束，通常比一次堆满背景更容易维护。
Codex Debug 提示词如何减少误修？
要求它先给复现条件和根因证据，再实施最小修复，并限定读取和修改范围。没有证据时，让它明确列出假设。
AIMI、AICNBOX 能替代 Codex 的代码仓库操作吗？
不能直接这样假设。AIMI 与 AICNBOX 更适合多模型对话和内容创作；Codex 的优势在于围绕项目文件、命令和测试形成开发闭环。