openai、codex、代码生成

用 Codex 这类模型写代码，最常见的心累不是它不会写，而是你分不清它是真写对了还是在编。改一个函数很顺，牵到三四个文件就开始漏调用点、编不存在的依赖，跑起来才发现。这篇不聊协议怎么配、客户端怎么装，只聊工程上怎么划能力边界：哪些活可以放心交，哪些必须自己收尾，以及怎么用日志和评测把这套判断固定下来。

用 Codex 这类模型写代码，最累的不是它不会写，而是你分不清它到底写对了还是在编。改一个函数很顺，牵到三四个文件就开始漏调用点、编出不存在的依赖，等跑起来才炸。这篇不聊协议怎么配、客户端怎么装，只聊工程上怎么划边界。

核心判断只有一条：这个任务的正确答案，能不能在你喂给它的上下文里被验证。能验证就放心交，只能靠跑起来才知道的活，自己上手更快。下面按「哪些活能交、它常在哪翻车、怎么验收、怎么兜底」四个角度拆开讲。

先分类：哪些代码活能交给它，哪些别交

把任务按「答案可见性」分三档，交出去之前先给自己归个类。分错档位的代价不是多改几行，而是你在一个本该自己写的任务上反复让它重试，最后代码被改得面目全非。

不适用的场景也说清楚：如果你只贴了一个文件，却让它改一个被十几个地方调用的函数，那前面的「能验证」就不成立了。上下文不全时，别拿它的输出去改主干代码。

它最常在哪几种地方翻车

翻车不是随机分布的，集中在这几类。提前知道，验收时就知道盯哪里。它引入的每一个新名字——新函数、新类、新依赖包、新配置项——都要当成嫌疑人，先搜仓库确认真的存在。

• 凭空造依赖和函数名：包名、方法名、配置项看着都像真的，装的时候才报错；它新引入的每个名字都先搜一遍仓库
• 只改被点到的那一处：一个签名改了，其它调用点没跟着改，编译期才炸；让它改之前先让它列出所有引用点
• 忽略项目约定：命名风格、错误处理方式、日志字段、目录分层，它默认按通用写法给，不按你的仓库给
• 时序和边界想当然：空值、超时、重试、并发写同一份数据，它写得像那么回事，但少了防御
• 上下文不全是放大器：你给的信息越少，上面几种翻车概率越高，这时别拿它的输出去改主干

验收清单：不跑起来也要先过这几关

别急着合。先按下面的顺序过一遍，跑不过就回到上下文，把缺的信息补齐再让它动手，而不是让它在你没看懂的代码上继续改。

1. 看 diff 范围改了多少文件、多少行，跟你预期的范围对不上就先别合。
2. 查新增标识符每一个新函数名、类名、依赖包，逐个在仓库里确认存在。
3. 对调用点用搜索把被改动函数或接口的引用点全列出来，逐个对一遍是否同步改了。
4. 补边界测试空输入、失败分支、异常路径有没有覆盖，没有就自己补测试。
5. 跑最小验证先跑类型检查、静态检查、单测，再跑一次真实调用，全过再说合并。

工程上的兜底：日志、降级、评测

光靠人工审查撑不住长期使用，得把判断固定下来。日志记够复盘用的字段，降级有明确顺序，再拿一小撮代表性任务当固定验收集，换提示词或换模型都跑一遍，看通过率是掉了还是稳住了。

日志字段

改动了哪些文件、模型来源、耗时、是否走了降级，出问题能还原当时喂了什么

降级顺序

主模型跑偏或不可用时，先退回自己写小改动，再考虑换模型，别在原结果上反复修

固定验收集

挑十几个仓库内有代表性的小任务，每次改动都跑一遍看通过率

成本分任务看

同一类任务连跑几次都不过，就该判定不适合交给它，而不是加长提示词硬撑

具体消耗量级别凭感觉，到 /usage真实用量榜 核对当时的数字，看看别人在同一类任务上实际花了多少。

能当场验证的活交出去，只能靠跑起来才知道的活自己上手。