为什么 Codex 提示词要像工程任务书
Codex Prompting Guide 的核心不是教你写漂亮 prompt，而是教你把代码任务交代成可执行、可验收、可持续推进的工作单。官方指南强调 Codex 模型在长时间自治、token 效率、上下文压缩和 Windows / PowerShell 环境上都有改进，但这些能力只有在任务边界清楚时才会发挥出来。需求写得松，模型再强也会把精力浪费在猜测上。
任务开头先写目标和约束
一个好的 Codex 任务应该先说明最终要达到什么状态，而不是只说「帮我优化一下」。例如「修复结账页移动端按钮遮挡，不能改支付逻辑，完成后用 390px 和 1440px 浏览器验收」。目标、禁止项、验收页面和测试方式放在开头，能显著减少无关修改。对大型任务，还要写清哪些文件是权威上下文，哪些目录不要碰。
给代码库探索留空间
Codex 很适合先读代码再动手，所以提示词里不要把实现方式写死。更好的写法是告诉它先定位现有模式，再按项目风格改。比如「先查已有详情页组件和外链处理逻辑，再补缺口」。这样可以防止它新建一套平行抽象，也能让它发现已有工具、测试和部署脚本。
把验收标准写成可执行动作
不要只写「页面好看」「性能要高」。改成「无横向滚动」「外链 rel 包含 nofollow noopener noreferrer」「点击外链先出现站外提醒」「审计脚本必须通过」。Codex 对明确检查项更稳定，也更容易在完成前自检。对于前端任务，验收标准里要写浏览器真实路径、视口尺寸和关键 DOM 信号。
长任务要允许持续推进
官方指南提到 Codex 适合更长时间自治，也支持上下文压缩。实际使用时，提示词要避免让它每一步都停下来等确认。可以写「遇到低风险实现细节自行决策，只有 live 写库、破坏性命令或业务冲突再询问」。这样既保留安全边界，又不会把 Agent 变成每五分钟问一次的执行器。
一份实用模板
- 目标，写清最终用户可见状态。
- 上下文，列出相关路径、路由、文档和已知问题。
- 边界，明确不能改什么、哪些数据不能写。
- 实现要求，描述偏好和项目规则，不细到绑死方案。
- 验收，写命令、浏览器路径、截图或审计脚本。
- 收口，说明是否提交、是否推送、是否同步生产。
建议产出
团队可以把这篇指南沉淀成内部 Codex 任务模板。每次发任务前先补齐目标、边界和验收，Codex 才更像一个可靠工程协作者，而不是只会生成代码片段的聊天窗口。