先在普通 Chat 规划，再让 Codex 执行

方法是什么

数字生命卡兹克分享的核心不是一个神奇提示词，而是一种工作分工：

1. 在普通 ChatGPT 会话中澄清需求、分析日志和业务数据、形成实施计划。
2. 必要时以只读、最小权限方式提供 GitHub、日志或业务上下文。
3. 输出一份不依赖原对话的自包含执行 Brief。
4. 将 Brief 交给 Codex。
5. Codex先对照真实仓库核验假设，再修改、测试和交付。

这可能减少规划阶段占用的 Codex 配额，但不代表整个系统使用的总 token 下降。你是在重新分配工作，而不是让思考凭空消失。

什么时候值得用

适合：

• 需求复杂，需要多轮澄清
• 根因可能在业务流程、日志或生产数据，而不只是代码
• Codex 每周额度紧张
• 普通 Chat 额度仍充足
• 任务实施范围可以在规划后明显收窄

不适合：

• 改一个明确文案
• 已经知道文件和修复方式的小 Bug
• 为了规划而重复向两个模型提供同一整仓上下文
• 无法安全提供数据，却强行连接生产系统

规划阶段提示词

你是一名软件架构师。现在只分析和规划，不修改代码。

任务目标：
[写清楚目标]

可用上下文：
[仓库结构、相关文件、日志、只读数据]

请完成：
1. 描述当前行为和目标行为。
2. 给出根因假设，并区分已证实与待核验内容。
3. 找出最可能相关的文件、调用链和数据流。
4. 写出最小实施步骤。
5. 列出必须测试的场景和验收标准。
6. 标明不应修改的范围。
7. 输出一份可以直接交给 Codex、且不依赖本对话历史的执行 Brief。

不要虚构未看到的文件；缺少证据时明确写“需要 Codex 在仓库中核验”。

交给 Codex 的执行提示词

请根据下面的执行 Brief 工作，但不要盲目信任它。

1. 先在真实仓库中核验每个文件、调用链和假设。
2. 如果 Brief 与仓库不一致，说明差异并采用仓库事实。
3. 只实施 Required scope，不做未授权重构。
4. 运行最小且足够的相关测试。
5. 最后报告改动文件、验证结果、剩余风险和未完成事项。

[粘贴执行 Brief]

数据访问的安全底线

如果规划需要真实业务数据：

• 只读账号
• 最小字段
• 敏感信息脱敏
• 工具白名单
• 写操作默认拒绝或要求批准
• 输出长度限制
• 记录访问审计
• 不把密钥、Cookie、token 写入聊天

普通 Chat 与 Work 不要混淆

当前官方规则中，ChatGPT Work 与 Codex 共用 agentic usage。这个方法的前提是把规划放在普通 Chat 会话中，而不是切换到 Work 后继续消耗同一个池。规则可能变化，实际使用前应查看当前官方额度说明。

如何判断它对你是否有效

连续选择 5 个相似复杂度任务，记录：

• Codex执行前后的额度变化
• 规划耗时
• Codex 首次实施是否成功
• 返工次数
• 总完成时间

与“从一开始全部交给 Codex”的任务进行对照。只有在完成质量相当时，额度下降才有意义。

原始灵感来源

• 数字生命卡兹克：《分享一个大幅节省Codex额度的邪修方法，不要浪费了你的ChatGPT Pro会员。》
• 原文：查看来源 ↗

本页是本站原创整理与扩展，不是原文转载。