别急着改支付和权限：先让 Codex 问完高风险开工问题

教程定位

这篇教程解决什么问题

有些需求看起来只有一两行代码，实际却不应该让 Codex 直接开改。比如“订单取消后自动退款”“管理员可以代用户重置权限”“删除项目时顺便清理关联数据”。这些句子很短，但它们碰到的是钱、权限和不可恢复数据。这里的主要风险不是 AI 会不会写语法，而是它可能在事实不完整时给出一个看似合理的实现：漏掉重复退款，扩大了管理员权限，把软删除改成硬删除，或者绕过了审计日志。

这篇教程的目标，是把 Codex 从“马上写代码的助手”先切换成“高风险开工前的提问官”。你要让它阅读需求、相关代码、数据表、历史事故记录和告警规则，然后输出一份可复核的材料：哪些问题必须问清楚，哪些证据已经在代码里找到，哪些地方必须补审计日志，灰度和回滚要满足什么条件，哪些节点必须由人确认后才能继续。

最终产物不是一份泛泛的风险清单，而是一份可以拿去开评审会或贴进任务单的“高风险变更开工包”。它应该包含四块内容：风险问题清单、代码和数据证据、灰度发布要求、人工审批点。拿到这份材料后，工程师再决定是否让 Codex 进入下一步实现。没有确认的问题，不能用 AI 的猜测补上。

本文用一个安全虚构的场景说明：你要修改订阅系统的“取消订单后退款”逻辑。产品说“用户取消未使用的增值包时自动退还余额”，但代码里已经有支付回调、手动退款、权限审批、账务流水、软删除和告警规则。这个需求不是不能做，而是不能在问题没问完时做。

使用场景

什么情况下最适合用这一套

你是负责后台系统或核心业务系统的工程师。你熟悉代码库，也愿意用 Codex 帮你加速，但你知道有些文件不能像普通页面组件那样随手改。只要这次需求碰到下面任意一种情况，就应该先做高风险提问，而不是直接实现：

典型对话是这样的：产品或同事说“这里很简单，取消后退一下余额就行”。你打开代码，发现 `cancelSubscription()` 里已经处理了订单状态，`refundPayment()` 又会被支付回调调用，后台还有一个“客服手动退款”入口。数据表里有 `payment_transactions`、`balance_ledger`、`refund_requests` 和 `audit_logs`。历史事故记录里曾经出现过“支付回调重试导致重复退款”。这时候直接让 Codex “帮我实现自动退款”，就是把最关键的问题留给运气。

你真正需要它先做的，是把隐藏问题问出来：

这些问题不是“谨慎一点”的姿态，而是开工门槛。高风险代码的第一步不是写代码，是明确什么信息缺失、谁能确认、确认后如何留痕。Codex 很适合做这件事，因为它可以不知疲倦地沿着代码路径、表结构和历史记录列问题。但 Codex 不适合替你批准风险。批准权必须在人手里。

• 支付、退款、余额、积分、发票、账务流水。
• 登录、权限、角色、审批、越权访问、管理员代操作。
• 删除、归档、清空、解绑、撤销、覆盖、批量导入。
• 生产数据迁移、历史数据修复、定时任务补偿。
• 告警、风控、审计日志、合规留痕。
• 取消动作是否一定代表可以退款？
• 是否存在支付回调和用户主动取消同时发生？
• 自动退款和客服手动退款是否会重复写账？
• 哪些角色可以触发退款，是否需要二次确认？
• 退款失败后订单状态怎么处理？
• 账务流水、审计日志、告警规则要不要一起补？
• 灰度时先对哪些订单类型开放？
• 生产开关关闭后，已经排队的退款任务怎么处理？

材料准备

开始前先把材料和边界备齐

准备材料时，尽量给 Codex 足够的上下文，但不要给真实密钥、真实用户隐私或生产数据明文。你可以给脱敏后的字段名、表名、状态名、日志片段和事故摘要。高风险场景里，输入材料的质量直接决定提问清单有没有价值。

第一类材料是需求说明。不要只写“取消后自动退款”。要写清楚触发条件、用户类型、排除范围、失败处理和期望产物。例如：“未使用的增值包在用户主动取消后，如果订单已支付且未开票，可以自动退回账户余额；已开票订单、争议订单、管理员代取消订单不在本轮处理。”

第二类材料是相关代码。可以是路径、函数名、关键片段或让 Codex 自己只读检索。重点包括入口函数、状态流转、权限判断、事务边界、幂等键、队列任务、支付回调、后台手动操作入口、审计日志写入点。你不是让它改这些文件，而是让它找“改动会影响哪里”。

第三类材料是数据表和约束。至少给出与本需求有关的表：订单表、支付流水表、余额流水表、退款申请表、审计日志表、软删除字段、唯一索引、外键、状态枚举。很多生产事故不是函数写错，而是没有理解数据约束。例如没有唯一幂等键，就很难证明不会重复退款。

第四类材料是历史事故或告警规则。即使只有几行摘要也很有用，比如“2025 年曾因回调重试造成重复退款，后来补了 `refund_request_id` 唯一索引”“告警规则监控 10 分钟内退款失败率和单用户多次退款”。这些材料能让 Codex 把问题问得更像你的系统，而不是像教科书。

第五类材料是发布规则和审批习惯。告诉 Codex：哪些变更必须走安全评审，谁审批支付开关，能否灰度，是否允许脚本修数据，生产配置谁能改，出现异常时由谁值守。没有这些约束，AI 很容易输出“加 feature flag、观察指标、必要时回滚”这种正确但不够落地的话。

开始前先给 Codex 一个硬边界：

这句话很重要。高风险场景里，Codex 的价值是把不确定性摊开，而不是用流畅回答把不确定性盖住。

本轮只做只读分析和提问清单，不修改代码，不生成迁移，不运行写入脚本，不调用支付、权限或删除相关接口。
如果信息不足，请列为“必须人工确认”，不要替我猜。

实操流程

按这套步骤把工作跑起来

第一步，先给需求贴风险标签。让 Codex 判断这次变更涉及哪些风险面：资金、权限、删除、账务、审计、合规、外部服务、批处理、数据修复。每个标签都要对应证据，比如“涉及资金，因为 `refundPayment()` 会写入 `balance_ledger`”；“涉及权限，因为后台入口使用 `admin:subscription:cancel` 判断”；“涉及不可恢复数据，因为取消流程会触发 `cleanupUnusedPackage()`”。没有证据的标签可以写成待确认。

第二步，让 Codex 找所有入口，而不是只看你准备改的函数。高风险逻辑通常不止一个入口。退款可能来自用户取消、客服后台、支付回调、定时补偿、失败重试、批量导入修复；权限变更可能来自管理后台、邀请链接、组织同步、脚本；删除可能来自页面按钮、API、定时清理和级联删除。要求它输出“入口清单”和“是否会触发同一段核心逻辑”。

第三步，要求它列出状态机问题。支付和权限事故经常发生在状态边界。比如订单是 `paid`、`cancel_requested`、`refunding`、`refunded`、`refund_failed`，还是只有一个 `cancelled`？从 `cancelled` 能否再次进入 `refunding`？支付回调迟到时如何处理？权限从 `owner` 降为 `member` 后，未完成任务是否继续执行？删除进入 `pending_delete` 后还能恢复吗？让 Codex 把每个状态转换写成问题，而不是直接给答案。

第四步，把幂等和并发单独拎出来。只要涉及钱、权限或删除，就要问“同一个动作执行两次会怎样”。让 Codex 检查是否存在幂等键、唯一索引、事务、锁、队列去重、重试策略和补偿任务。输出必须回答：重复点击、接口超时重试、支付回调重放、队列重复消费、管理员和用户同时操作时，系统会不会重复写账、重复授权或重复删除。

第五步，要求 Codex 检查审计和可追溯性。高风险变更不是只要业务结果对，还要能解释“谁在什么时候因为什么做了什么”。让它找现有审计日志格式、操作者字段、请求来源、关联订单或资源 ID、旧值和新值、失败原因、审批单号。然后列出缺口：本次是否需要新增审计事件，是否记录自动动作和人工动作的区别，是否能从账务流水追到订单和用户操作。

第六步，整理灰度和开关要求。让 Codex 不要泛泛写“加开关”，而是问清楚开关的粒度：按租户、按用户角色、按订单类型、按金额上限、按支付渠道、按环境，还是只在后台配置。还要问默认值、谁能打开、打开是否需要审批、关闭后正在处理的任务怎么办。高风险开关不只是布尔值，它是一套止损机制。

第七步，让 Codex 产出人工确认点。所有它无法从代码和材料里证明的事项，都应该进入确认点。例如“财务是否允许余额退款替代原路退款”“合规是否要求保留取消前后的权限快照”“客服是否需要看到自动退款失败原因”“数据删除是否有法定保留期限”。确认点要写成可以发给具体角色的问题，而不是“和业务确认一下”。

第八步，生成审批材料草案。格式可以很短，但必须能支撑评审：变更摘要、影响面、已确认事实、未确认问题、建议灰度、回滚方式、监控告警、人工审批人。你可以把它贴到任务系统、PR 描述或评审文档里。它的作用是防止后续实现时把风险背景丢掉。

第九步，人工删改 Codex 的问题。Codex 可能会问出一些不适合你们系统的问题，也可能漏掉团队内部约束。你要把它的问题分成三类：必须回答后才能开工、可以在实现前补充、不是本次范围。只有第一类清完，才适合让 Codex 开始改第一步代码。

第十步，下一轮实现时继续收窄边界。提示词应该写成“只实现审批材料中已确认的第一个低风险改动”，而不是“根据上面的讨论实现需求”。例如先补审计事件常量和测试，或先增加只读的风险日志，不要一上来改退款执行路径。

输入示例

可以直接参考的输入材料

下面是一份可以交给 Codex 的脱敏材料。它保留工程判断需要的信息，但不包含真实用户、真实金额、真实密钥或生产数据。

这份输入有一个关键特点：它不要求 Codex “实现退款”。它要求 Codex 先把风险问题问完，并把证据和审批点整理出来。这样做会慢半步，但能避免在最危险的地方快错。

任务：
修改订阅系统的取消逻辑。产品希望“用户取消未使用的增值包时，自动退还到账户余额”。

本轮目标：
请只做高风险开工前分析，输出必须问清楚的问题、代码证据、审计需求、灰度要求和人工审批材料草案。不要改代码。

需求边界：
- 只处理用户主动取消。
- 只处理未使用的增值包。
- 已开票订单不处理。
- 争议订单不处理。
- 管理员代取消订单是否处理，目前不确定。
- 退款方式暂定为退到账户余额，不做原路退回。

相关路径：
- server/subscription/cancel.ts：取消订阅入口。
- server/payment/refund.ts：退款逻辑。
- server/payment/webhook.ts：支付回调。
- server/admin/manualRefund.ts：客服手动退款入口。
- server/audit/writeAuditLog.ts：审计日志。
- jobs/refundRetryJob.ts：退款失败重试任务。

相关表：
- subscriptions(id, user_id, status, package_id, cancelled_at)
- orders(id, subscription_id, status, paid_at, invoice_status)
- payment_transactions(id, order_id, provider_txn_id, status)
- balance_ledger(id, user_id, order_id, amount, reason, idempotency_key)
- refund_requests(id, order_id, status, source, created_by, idempotency_key)
- audit_logs(id, actor_id, action, resource_type, resource_id, before_json, after_json)

历史事故摘要：
- 曾经因为支付回调重试导致重复写入余额流水。
- 后来给 balance_ledger 增加了 idempotency_key，但不确定所有退款入口是否都使用。
- 告警监控：10 分钟内 refund_failed 超过阈值；单个用户 1 小时内退款次数异常。

发布要求：
- 必须 feature flag 默认关闭。
- 需要先在内部租户灰度。
- 生产打开前需要支付负责人和客服负责人确认。
- 出现异常时优先关闭开关，不允许直接改生产数据。

提示词

可复制使用的提示词

下面这段可以直接复用。把方括号替换成你的真实但已脱敏材料。

如果你已经让 Codex 读了仓库，可以在开头加一句：“引用代码证据时请给出文件路径、函数名和你看到的判断依据；不确定的地方不要补全。”这样输出会更适合评审。

你现在扮演高风险代码变更的开工审查助手，不是代码实现助手。

硬性边界：
- 本轮只读分析，不修改代码。
- 不生成数据库迁移，不运行写入脚本，不调用生产或外部接口。
- 信息不足时必须写“需人工确认”，不要猜答案。
- 不要把最终批准权交给 AI；请明确哪些点必须由人确认。

变更背景：
[粘贴需求说明、触发条件、非目标、失败处理预期]

相关材料：
[粘贴相关代码路径、关键函数、数据表、历史事故、告警规则、发布要求]

请输出一份“高风险变更开工包”，包括：
1. 风险标签和证据：说明本变更涉及资金、权限、删除、审计、外部服务或数据修复中的哪些风险，每项都要给证据或标注待确认。
2. 入口和影响面：列出所有可能触发同一逻辑的入口，包括用户入口、后台入口、回调、定时任务、重试任务和脚本。
3. 必问问题清单：按业务规则、状态机、幂等并发、权限边界、审计日志、灰度发布、回滚止损分组。
4. 审计和留痕需求：说明本次至少需要记录哪些字段，哪些现有日志可能不够。
5. 灰度要求：给出 feature flag 粒度、默认值、打开条件、关闭后的处理方式、监控指标。
6. 人工审批材料草案：写成可以放进任务单或 PR 描述的版本，列出已确认事实、待确认问题、审批人和禁止开工条件。
7. 下一步建议：只推荐“开工前需要补的材料”或“第一个最低风险改动”，不要直接实现。

输出要求：
- 问题要具体到可以发给产品、支付负责人、安全负责人、客服负责人或 DBA。
- 对无法从材料证明的内容，不要写成事实。
- 对任何会影响资金、权限扩大或不可恢复删除的点，必须标注人工确认。

输出样例

AI 应该输出到什么程度

下面是使用上面输入后，理想情况下会得到的缩略输出。实际项目里应当包含更具体的文件路径和证据。

这类输出的价值不在于它替你决定怎么改，而在于它把“不能靠猜”的地方亮出来。你可以直接把待确认问题分发给对应负责人，或把禁止开工条件贴到任务单顶部。

高风险变更开工包：取消未使用增值包后自动退余额

一、风险标签和证据

1. 资金风险：涉及 balance_ledger 写入和 refund_requests 状态变化。证据：需求要求退到账户余额；材料中存在 server/payment/refund.ts、balance_ledger、refund_requests。
2. 幂等风险：历史事故出现过支付回调重试导致重复写余额。证据：事故摘要提到已增加 idempotency_key，但不确定所有入口是否使用。
3. 权限和代操作风险：用户主动取消和管理员代取消可能共用 cancelSubscription()。证据：存在 server/admin/manualRefund.ts，且“管理员代取消是否处理”未确认。
4. 审计风险：自动退款需要区分用户触发、系统自动执行、客服手动处理。证据：存在 audit_logs，但需求未说明新增 action。
5. 灰度风险：开关默认关闭是发布要求，但未说明按租户、订单类型还是金额限制灰度。需人工确认。

二、入口和影响面

- 用户取消入口：server/subscription/cancel.ts。需确认取消后是否同步调用退款，还是进入退款申请队列。
- 支付回调入口：server/payment/webhook.ts。需确认回调迟到或重复到达时是否会再次触发退款判断。
- 客服手动退款入口：server/admin/manualRefund.ts。需确认是否与自动退款共享 idempotency_key。
- 退款重试任务：jobs/refundRetryJob.ts。需确认失败重试是否会重复写 balance_ledger。
- 数据修复脚本：材料未提供。需确认是否存在历史补偿脚本会写 refund_requests。

三、必须问清楚的问题

业务规则：
- “未使用”由哪个字段判断？是 package usage 为 0，还是没有生成任何权益消耗记录？
- 已开票订单不处理时，用户取消后订单状态应停在哪个状态？
- 退到账户余额是否需要财务确认？是否会影响发票、税务或对账？

状态机：
- paid -> cancelled -> refunding -> refunded 是否是允许路径？
- refund_failed 后用户能否再次取消或重新发起退款？
- 支付回调晚于取消动作时，以哪个事件为准？

幂等和并发：
- 自动退款的 idempotency_key 如何生成？建议至少包含 order_id 和 refund source。
- 用户重复点击取消、接口超时重试、回调重复投递时，是否会写入多条 balance_ledger？
- 客服手动退款和自动退款同时发生时，谁先谁后如何仲裁？

权限边界：
- 管理员代取消是否触发自动退款？当前需求未确认，禁止默认纳入。
- 哪些角色可以查看自动退款失败原因？
- 是否需要二次确认或审批才能打开生产 feature flag？

审计日志：
- 至少记录 actor_id、actor_type、action、order_id、subscription_id、refund_request_id、idempotency_key、before status、after status、failure reason。
- 需要区分 user_cancel_auto_refund、admin_manual_refund、system_retry_refund。

灰度和回滚：
- feature flag 必须默认关闭。
- 建议第一阶段只对内部租户、未开票、金额低于人工确认阈值的订单开放。
- 关闭开关后，不应创建新的 refund_requests；已进入 refunding 的请求需要按现有重试或人工处理策略完成，不能静默丢弃。
- 监控至少包括 refund_failed 比例、单用户退款次数、balance_ledger 重复 idempotency_key 冲突、退款队列堆积。

四、人工审批材料草案

变更摘要：
用户主动取消未使用增值包后，系统在满足未开票、非争议、开关打开等条件时，创建自动余额退款请求并写入账务流水与审计日志。

已确认事实：
- 本变更涉及余额流水和退款请求。
- 系统已有退款失败告警。
- feature flag 要求默认关闭。

待确认问题：
- 支付负责人确认：退到账户余额是否符合财务和对账要求。
- 产品负责人确认：“未使用”的准确定义。
- 客服负责人确认：自动退款失败后客服后台如何展示和处理。
- 安全或权限负责人确认：管理员代取消是否触发自动退款。
- DBA 或后端负责人确认：idempotency_key 是否覆盖所有退款入口。

禁止开工条件：
- 未确认“未使用”判定标准。
- 未确认自动退款和手动退款的幂等策略。
- 未确认 feature flag 打开审批人和关闭后处理方式。
- 未确认审计日志字段。

下一步建议：
先补充材料：列出 cancelSubscription() 的所有调用方、manualRefund 是否共享 refund_requests、现有 audit action 枚举。材料补齐前，不建议修改退款执行路径。

人工验收

人要怎么检查和改到可用

Codex 输出后，工程师必须做一次人工复核。高风险场景里，复核不是润色，而是判断哪些内容能进入开工门槛。

先检查证据是否真实。凡是 Codex 写了“代码中存在”“当前逻辑会”“已有索引保证”，都要回到代码、表结构或文档确认。如果它没有引用路径或依据，就把这句话降级为“待确认”。高风险材料里，猜测不能伪装成事实。

再检查问题是否可回答。一个好问题应该能发给具体的人。例如“退款会不会有风险”太宽；“已开票订单取消后是否允许退到账户余额，是否需要财务审批”才可回答。你可以把问题后面补上责任人：产品、支付负责人、客服负责人、安全负责人、DBA、值班负责人。

然后检查是否漏掉你们团队自己的规则。比如你们可能规定所有支付变更必须双人 review，所有权限扩大必须过安全评审，所有删除逻辑必须先做 7 天软删除，所有生产开关必须记录审批单号。这些内部规则 Codex 不一定知道，要由你补进审批材料。

最后检查下一步是否足够小。如果 Codex 建议“确认后实现自动退款”，还不够。你要把下一步改成更窄的动作，比如“只补调用方列表和现有测试覆盖报告”“只增加审计事件定义和测试，不触发退款”“只增加 feature flag 默认关闭的读取逻辑，不接入业务路径”。高风险改动必须一层一层打开。

人工复核清单可以直接照下面过一遍：

• 是否明确本次涉及资金、权限或不可恢复数据中的哪一种。
• 是否列出所有入口，包括后台、回调、任务、脚本和重试。
• 是否说明重复执行同一动作的结果。
• 是否确认状态转换和失败状态。
• 是否确认审计日志字段和查询路径。
• 是否确认 feature flag 默认关闭、打开审批人和关闭后的处理。
• 是否列出监控和告警指标。
• 是否把 AI 无法证明的内容标成“需人工确认”。
• 是否写明禁止开工条件。
• 是否避免把最终批准权交给 Codex。

教程正文

适用边界

这套方法适合“风险高但还没有进入实现”的阶段。你已经知道要改哪个业务方向，也能提供相关代码或数据线索，但还没有把规则、灰度、审计和审批问清楚。它尤其适合支付、退款、角色权限、数据删除、批量修复、生产迁移、后台管理能力这类改动。

它不适合用来替代正式安全评审、财务评审或合规审批。Codex 可以帮你准备问题和材料，但不能代表支付负责人同意退款策略，不能代表安全负责人批准权限扩大，也不能代表法务同意删除策略。

它也不适合在生产事故进行中临时指挥处置。事故中应先遵守团队既有应急流程：止血、保全证据、通知值班负责人、记录时间线。Codex 可以在只读材料范围内帮你整理事实，但不应该在未授权时建议写生产数据或关闭关键保护。

如果只是低风险文案、样式、小型内部工具页面，使用这套流程会显得过重。判断标准很简单：如果改错后可以无感回滚，且不影响钱、权限、用户数据和审计记录，就不必做完整开工包；如果改错后需要补账、追责、恢复数据或解释越权访问，就值得先问完。

失败反例

这些失败反例要提前避开

【反例一：让 Codex 直接实现“自动退款”】

错误提示词：

这个提示词的问题不是太短，而是它没有任何风险边界。Codex 可能会找到一个取消函数，然后加一行调用退款逻辑。它不知道管理员代取消是否包含在内，不知道支付回调是否会重复触发，不知道账务流水有没有幂等要求，也不知道自动退款是否需要财务确认。对普通功能来说，这可能只是需求不完整；对支付逻辑来说，这就是事故入口。

更好的做法是先要求它输出开工问题和审批材料，明确“不要改代码”。等幂等、审计、灰度和人工确认点都清楚后，再让它实现最小的一步。

【反例二：只问“这样改安全吗”】

错误提示词：

这类问题会诱导 Codex 给出概括性判断，比如“需要注意幂等和异常处理”。但你需要的不是一句“注意”，而是完整问题清单：所有入口、状态转换、重复执行、权限边界、审计日志、灰度开关、失败补偿、人工审批。高风险场景里，不要问 AI “安全吗”；要让它列出“哪些事实没确认，所以现在不能说安全”。

【反例三：把 feature flag 当成唯一止损方案】

错误提示词：

开关很重要，但开关不等于止损。你还要问：开关按什么粒度打开，谁审批打开，关闭后已经进入队列的退款请求怎么办，已写入的余额流水是否可追溯，失败任务是否会继续重试，告警是否能发现异常。只写一个默认关闭的布尔值，无法解决重复退款、审计缺失和半路失败。

【反例四：让 Codex 代替负责人做业务决定】

错误提示词：

这是最危险的一类用法。已开票订单、权限扩大、永久删除、账务调整，都不是 Codex 可以替团队拍板的事项。正确做法是让它把问题写给负责人：需要财务确认什么、需要产品确认什么、需要安全确认什么、确认前哪些代码不能动。AI 可以帮你把会议前的问题准备好，但不能替代会议本身。

帮我改一下取消订阅逻辑，用户取消未使用增值包时自动退款到账户余额。

我准备在 cancelSubscription 里调用 refundPayment，这样安全吗？

给自动退款加一个开关，默认关闭，然后就可以上线。

你判断一下已开票订单取消后要不要退余额，并按你觉得合理的方式实现。

主题边界

它和相邻主题的区别

这篇文章和“把大功能拆成小改动”的主题不同。拆小改动关注的是实施顺序：如何把一个已确认的功能切成多个可合并步骤。本文关注的是更早的开工门槛：当需求碰到支付、权限或不可恢复数据时，哪些问题没问清楚就不能开始实现。

它也不同于“改功能前查配置和环境变量”。配置审计主要处理开发、预发、生产环境差异，比如变量名、默认值和部署覆盖。本文的中心是业务风险和生产责任：幂等、状态机、审计、灰度、人工审批和禁止开工条件。配置开关会出现，但只是高风险止损机制的一部分。

它还不同于普通需求澄清。普通需求澄清可能问用户故事、验收标准和页面行为；本文的提问对象更偏工程和生产责任，问题会具体到退款入口、唯一索引、管理员代操作、审计字段、告警阈值和审批人。目标不是让需求更完整，而是判断当前信息是否足以触碰高风险代码。

如果你后续要让 Codex 写代码，可以把本文产出的开工包当作上游材料。先确认问题，再拆实施顺序，再逐步实现。顺序反过来，就容易在看似简单的“一行改动”里埋下生产事故。