GPT-5.6 代码专用 Prompt 模式：让 Codex / Cursor 一次写对的 12 个模板
GPT-5.6 家族给代码场景优化的 12 个 prompt 模板：架构理解、增量实现、bug 定位、code review、测试生成、重构、依赖升级。配合 Codex CLI / Cursor / Aider 使用。
代码 prompt 跟通用 prompt 是两套逻辑——通用 prompt 写『帮我优化这段代码』模型就开始自由发挥，代码 prompt 必须给精确上下文 + 明确输出格式 + 边界 case。本文 12 个经过 GPT-5.6 实测的代码 prompt 模板，覆盖开发全流程，配 Codex CLI / Cursor / Aider 用。
模板 1：架构理解
让 AI 读懂一个 codebase 的整体结构。
你是一个 senior 工程师。请阅读 {repo_path} 的代码，回答以下问题：
1. 这个项目的整体架构是什么？画一张模块依赖图（用 mermaid）。
2. 数据流向：从用户请求到响应，经历了哪些模块？
3. 关键的 design decision 有哪些？分别在哪些文件？
4. 如果要加一个新功能 {feature}，应该改哪些文件？
只读不改。输出 markdown 格式，不要写代码。
适用：新人 onboarding、接手老项目、code review 前了解上下文。
模板 2：增量实现
实现一个新功能，最小 diff。
任务：在 {repo_path} 加一个新功能 {description}。
要求：
- 只改必要的文件（避免无关修改）
- 保持现有 API 兼容
- 加单元测试（覆盖正常 / 异常 / 边界 case）
- 跑现有测试保证不破
- 输出：列出改了哪些文件 + 每个文件的 diff 摘要
参考实现：{reference_repo} 里的 {file_path}（如有）。
适用：feature 增量开发、跨服务调用新接口。
模板 3：bug 定位
定位一个具体 bug，给出根因 + 修复方案。
Bug 描述：{bug_description}
重现步骤：{steps}
期望行为：{expected}
实际行为：{actual}
任务：
1. 阅读相关代码 {file_paths}，定位根因（不要瞎猜，要给具体代码行号）
2. 给出修复方案（最小 diff）
3. 给出回归测试用例
4. 评估修复的风险（是否影响其他模块）
适用：生产 bug 修复、test flake 定位。
模板 4：单元测试生成
为已有函数生成完整的单元测试。
为 {file_path} 里的 {function_name} 函数生成单元测试。
要求：
- 用 {framework} (pytest / jest / go test)
- 覆盖：正常 case / 边界 case（空 / 最大 / 最小）/ 异常 case（非法输入 / 超时）
- mock 外部依赖（数据库 / HTTP / 第三方服务）
- 目标覆盖率：>= 90%
- 输出：完整测试文件 + 覆盖率报告
参考：现有测试风格 {existing_test_path}。
适用：提升测试覆盖率、新功能 TDD。
模板 5：code review
给一个 PR 做 review。
Review 这个 PR：{diff}
从以下维度评估：
1. 正确性：逻辑是否正确？边界 case 是否处理？
2. 安全：是否有 prompt injection / XSS / SQL injection / 越权访问？
3. 性能：是否有 N+1 查询 / O(N²) 算法 / 内存泄漏？
4. 可维护性：命名 / 结构 / 文档是否清晰？
5. 测试：是否覆盖核心路径？是否有 flake 风险？
输出格式：
- 必改项（blocker）：列出具体问题 + 行号 + 建议修复
- 建议项（nice-to-have）：列出可以改进的地方
- 亮点：列出做得好的部分
适用：PR review、AI 辅助 code review。
模板 6：重构
把一段代码重构得更清晰，保持外部行为不变。
重构 {file_path} 里的 {code_block}。
要求：
- 保持外部行为完全不变（所有现有测试必须通过）
- 改善：可读性 / 模块化 / 错误处理 / 命名
- 不要引入新依赖
- 输出：完整重构后的代码 + 改动理由
注意：
- 重构和重写不一样——目标是『结构更好』，不是『功能改变』
- 任何行为变化必须明确标注
适用：技术债清理、老代码现代化。
模板 7：文档生成
为代码生成高质量文档。
为 {file_path} 生成文档。
要求：
- 模块级：写 docstring / README，说明这个模块做什么、为什么存在、关键设计决策
- 函数级：每个 export 函数写 docstring，描述输入 / 输出 / 异常 / 示例
- 类型级：所有 export interface / type 写注释
- 复杂逻辑：行内注释解释『为什么』不是『做什么』
风格：参考 {existing_doc_path}。
适用：开源项目文档、企业内部 API 文档。
模板 8：依赖升级
把项目里的某个依赖升级到新版本。
升级 {package_name} 从 {old_version} 到 {new_version}。
任务：
1. 阅读 changelog（{changelog_url}）找出 breaking changes
2. 找出所有用到这个依赖的文件 {grep_results}
3. 修改代码适配新 API
4. 跑测试确认
5. 输出：列出改了哪些文件 + 适配说明
适用：framework 升级（React / Next.js / Vue）、库 major 版本升级。
模板 9：PR 描述生成
生成 PR description / PR body。
根据这个 PR 的 diff（{diff}）生成 PR description。
格式：
## What
- 这次改了什么？（1-3 句话）
## Why
- 为什么改？解决什么问题？
## How
- 怎么改的？（关键设计决策）
## Test
- 怎么验证？（单测 / 集成测 / 手动测）
## Risk
- 风险是什么？回滚方案？
## Screenshot（UI 改动）
- 截图 / GIF（可选）
适用：所有 PR 自动化提交流程。
模板 10：commit message 生成
git diff --staged | codex exec "基于这个 diff 生成 conventional commit message。格式：
<type>(<scope>): <subject>
<body>
<footer>
type: feat / fix / docs / refactor / test / chore
subject: 50 字以内，imperative mood（『add』而非『added』）
body: 解释 why + how，wrap at 72 chars
footer: 关联 issue（Closes #123）"
适用：git hook 自动化 commit message。
模板 11：注释翻译
把中文注释翻译成英文（或反过来）。
翻译 {file_path} 里的注释。
要求：
- 保留代码不变，只改注释
- 保留技术术语不翻译（function / class 名 / API 名）
- 保持简洁：原注释如果啰嗦，翻译时可以精简
- 输出：完整文件
用最便宜的模型（gpt-5.6-luna），注释翻译不需要 reasoning。
模板 12：性能分析
定位代码的性能瓶颈。
分析 {file_path} 里的 {function_name} 的性能。
任务：
1. 时间复杂度（最好 / 平均 / 最坏）
2. 空间复杂度
3. 是否存在：N+1 查询 / 重复计算 / 不必要的拷贝 / 阻塞 I/O
4. 在 {test_data_size} 数据量下的预期耗时
5. 优化建议（具体到代码行）
适用：性能优化、production incident 性能定位。
五步走流程：『读懂一个 codebase』
接手新项目时的完整 prompt 流程：
# Step 1：架构理解（模板 1）
codex exec "$(cat template-1.txt)" --repo ./repo
# Step 2：找到核心模块
codex exec "列出 ./repo 里最重要的 5 个文件，解释为什么重要" --repo ./repo
# Step 3：跑测试看覆盖率
codex exec "跑 ./repo 的测试，输出覆盖率报告，列出 < 50% 的文件" --repo ./repo
# Step 4：找技术债
codex exec "在 ./repo 里找 10 个『可以改进』的地方，按影响排" --repo ./repo
# Step 5：写 onboarding 文档
codex exec "基于以上输出，写一份 ONBOARDING.md 给新工程师" --repo ./repo > ONBOARDING.md
5 个步骤 10 分钟，新人就能上手。
常见反模式
| 反模式 | 问题 | 修正 |
|---|---|---|
| "帮我优化这段代码" | 太开放，AI 自由发挥 | "优化 N 处的算法复杂度从 O(N²) 到 O(N log N)，保留原有 API" |
| 不给文件路径 | AI 不知道改哪里 | 明确写 只改 file X |
| 不要求输出格式 | AI 输出飘 | "输出 diff / 输出完整文件 / 输出 mermaid 图" |
| 不给边界 case | AI 只测 happy path | "覆盖：空输入 / 超长输入 / 非法字符 / 并发" |
| 不要求测试 | AI 写代码不写测试 | "必须加测试覆盖 XX case" |
| 不说『不引入新依赖』 | AI 帮你装一堆 | 明确约束 |
模型选型
| 任务 | 推荐模型 | 理由 |
|---|---|---|
| 架构理解 / 复杂重构 | gpt-5.6-sol | reasoning 最强 |
| 日常代码生成 | gpt-5.6-terra | 性价比最高 |
| bug 定位 / 注释翻译 | gpt-5.6-luna | 成本 1/5 |
经验值：Codex CLI 跑代码任务，70% 用 Terra + 25% 用 Sol + 5% 用 Luna。盲目全用 Sol 浪费钱。
下一步
- 想了解 Codex CLI 入门？读 《OpenAI Codex CLI 入门：从零配置到日常编码流》。
- 想了解 Codex 团队协作？读 《Codex 团队协作最佳实践：worktree、审查与 CI 集成》。
- 想了解 Codex 跑进 CI？读 《Codex CI 集成实战：把 Codex CLI 跑进 GitHub Actions》。
- 想了解通用 prompt 模式？读 《Prompt Engineering 核心模式：8 个让 GPT 表现翻倍的模板》。
关键要点
- 代码 prompt 要『精确上下文 + 明确输出格式 + 给出失败/边界 case』。不写这三件套，模型只能猜，结果飘
- 12 个模板覆盖：架构理解、增量实现、bug 定位、单元测试、code review、重构、文档生成、依赖升级、PR 描述、commit message、注释翻译、性能分析。每个都有适用场景 + 反例
- GPT-5.6 Sol 适合复杂架构理解 + 跨文件重构；Terra 适合日常代码生成；Luna 适合注释翻译 / 简单 bug 定位这种低成本任务。模型选错既贵又慢
- 配合 Codex CLI / Cursor 用时，prompt 必须含：(1) 文件路径（让 AI 知道在哪改）；(2) 期望的 diff 范围（不要让 AI 自己找）；(3) 测试要求（『保证现有测试不破 + 加新测试』）
- 代码 prompt 最重要的反模式是『开放式描述』（如『帮我优化这段代码』）——改成『优化 N 处的算法复杂度从 O(N²) 到 O(N log N)，保留原有 API』，输出质量立刻翻倍
常见问题
官方参考
相关文章
Prompt 评测与失败排查实战：LLM-as-judge + 回归测试 + Debug 模式
Prompt 上 production 后怎么做评测：LLM-as-judge 自动打分、回归测试集、失败 case 分类（幻觉 / 偏题 / 格式错误）、Debug 模式 + token / cost 可视化。
阅读全文Prompt Engineering 进阶：多轮上下文、结构化输出与 GPT-5.6 调优
Prompt Engineering 第二篇：多轮上下文管理、结构化输出（JSON Schema）、few-shot 模式、长上下文策略与 GPT-5.6 reasoning.effort 调优。
阅读全文Prompt Engineering 核心模式：8 个让 GPT 表现翻倍的模板
系统讲解 8 个高频 Prompt 模式：角色扮演、Few-shot、Chain-of-Thought、ReAct、Self-Consistency 等，每种配可复用模板。
阅读全文订阅 GPTMap Weekly
每周一封邮件，精选 OpenAI 重要更新、深度解读与最佳实践。无广告，可随时退订。