Codex 高质量 Prompt 写法

这是一篇方法论 + 模板教程。看完你应该能自己写出 80 分的 prompt,剩下的 20 分靠模型版本。

1. 高质量 Prompt 的三个错觉

写 prompt 之前,先破除三个常见错觉:

• 错觉一:Prompt 越长越好 → 错,关键信息密度比长度重要
• 错觉二:Prompt 要有礼貌 → 错,清晰直接 > 客气委婉
• 错觉三:Cot(思维链)一定有用 → 错,简单任务反而会拖慢

2. 六步公式

角色 → 上下文 → 任务 → 约束 → 格式 → 验收。把这 6 项填全,基本就 80 分了。

2.1 角色(Role)

告诉 Codex 它”是谁”。越具体越好:

你是一位有 8 年经验的前端架构师,擅长 React + TypeScript,
对性能优化有强迫症。

2.2 上下文(Context)

只贴必要的代码片段、需求背景。不要把整个仓库塞进去。

2.3 任务(Task)

一句话说清”要做什么”。

2.4 约束(Constraints)

列出”不能做什么”——技术栈、性能预算、不能改的 API。

2.5 格式(Format)

明确输出形式:Markdown 表格?JSON?diff?每段几个 bullet?

2.6 验收(Acceptance)

定义什么样的输出算合格,让模型自己检查。

3. 10 个可直接抄的模板

3.1 重构函数

角色: 高级 TS 工程师
任务: 把 src/utils/diff.ts 里的 diff 函数重构成纯函数,
      支持自定义比较器。
约束: 不引入新依赖;保持向后兼容;增加单测。
格式: 输出完整 diff;解释关键设计点。
验收: 跑 pnpm test 全绿;函数签名不变。

3.2 写单测

为 src/parser/parser.ts 的 parse() 函数补全单元测试,
覆盖:空输入、非法字符、嵌套结构、超长字符串(>1MB)。
用 vitest,所有断言要带 message。

3.3 Code Review

以资深 reviewer 视角,审查 PR #234 的变更。
只指出真正严重的问题: 性能、安全、可维护性。
忽略风格 nit。
输出格式: severity / file:line / 一句话说明 / 建议改法

3.4 解释 bug

下面这段代码在 macOS 上正常,Linux 上崩溃。
解释最可能的 3 个原因,按可能性排序,给出验证方法。
[粘贴代码]

3.5 写 migration

生成一个 SQL 脚本,把 users 表的 email 列从 VARCHAR(255) 改成 VARCHAR(320),
不锁表,兼容 MySQL 8.0+。
要求:可回滚,带详细注释。

3.6 翻译 / 本地化

把下面这段 i18n key 的英文翻译成简体中文、日文、韩文。
保持 {{var}} 占位符原样,语气专业、克制。

3.7 性能分析

分析下面这段 React 组件为什么会触发多余 re-render。
给出: 根因 / 复现步骤 / 最小修复 patch。

3.8 文档生成

为 src/api/auth.ts 生成 JSDoc 注释,
包含:功能描述、参数、返回值、抛错条件、一个 @example。

3.9 数据清洗

把下面这份 CSV 转成 JSON,字段命名改 camelCase,
日期统一成 ISO 8601。
忽略第一行表头之外的注释行。

3.10 单元测试 fixture

为登录页面写 3 组端到端 fixture:
成功登录、密码错误、账号锁定。
用 Playwright,断言包含截图、URL、cookie 清除。

4. 反模式

写法	问题	改法
”写一个牛逼的网站”	太模糊	指定类型 + 风格 + 受众
把整本《XX 指南》塞上下文	上下文爆炸	只贴相关章节
”用最简单的方法”	主观	列出可接受的依赖数
不给验收标准	模型会”自我感动”	明确”成功 = X”

5. 一些细节

• 示例 > 描述:给一个完整示例,比写 3 段描述更省 token
• 温度参数:Codex 默认 0.2,代码场景一般不要再调高
• 多次迭代:复杂 prompt 分 3-4 轮给,比一次性塞进去更稳

写在最后

写 prompt 是工程活而不是”玄学”。把上面六步公式记熟,再把 10 个模板背下来,你写代码的速度会快 3 倍。