1. 复现 processUserData 的「假完成」先看 AI 把校验漏成了什么样在《AI程序员崛起》3.1 节里processUserData被 AI 写成了空壳。补全它我用 TaoToken 接 Codex——先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建 API Key再改 Codex 的~/.codex/config.tomlBase URL 填 https://taotoken.net/api。这样 Codex 走的是统一 API 通道模型 ID 以模型广场为准。下面从复现这个空壳开始。1.1 AI 版本为什么能骗过眼睛public void processUserData(User user) { user.setProcessed(true); }这段代码能通过编译在 demo 里也能跑通。麻烦在于它把「执行动作」和「校验结果」混为一谈只要走到这一行不管 user 是 null、邮箱为空、余额为负状态都会被改成processed。真实的业务系统里这种函数往往处在入口位置上游传来什么就处理什么下游消费时又默认数据已经被清洗过于是脏数据一路流到报表或对账环节才暴露。它最大的问题不是「代码少」而是「失败路径完全没有被建模」。1.2 模糊需求如何诱导模型偷懒原文里人类工程师只描述了一句话「创建一个函数处理用户数据」。这句话没有定义什么算合法、什么算处理成功、失败时该抛异常还是返回结果。模型在训练数据里见过大量setProcessed(true)这类状态位操作遇到模糊指令时会优先选择统计频率最高的实现而不是语义最完整的实现。可以类比成让实习生「把快递处理一下」实习生的第一反应是签收而不是检查破损、登记单号、通知收件人——因为指令里根本没提这些步骤。1.3 为什么这种空壳能穿过 code review空壳函数没有语法错误也没有明显的逻辑错误。code review 时如果只盯「这段代码是否做了该做的事」它确实把processed状态写了。只有追问「如果 user 非法会怎样」「转换失败会怎样」「这笔处理记录去哪查」才会暴露缺口。这也是本文要把校验、异常、审计一起补全的原因不是为了让代码看起来更厚而是让函数在每条路径上都有明确行为。2. 对照 validateUser、ProcessingException、auditLog找出空壳缺了什么2.1 人类健壮版到底多写了什么同样一句话人类工程师给出的版本会先把校验、异常、审计、转换、返回值这五件事排好public UserProcessingResult processUserData(User user) { ValidationResult validation validateUser(user); if (!validation.isValid()) { auditLog.logRejected(user, validation.errors()); throw new ProcessingException(validation.errors()); } User processed transformationPipeline.apply(user); auditLog.logProcessing(user, processed); return new UserProcessingResult(processed, Status.SUCCESS); }表面上是多写了几个方法调用实际上是多了三层设计入口处先做防御失败时不静默而是抛出带错误明细的异常成功路径也不忘留审计痕迹。用表格对照能力AI 空壳版人类健壮版入参校验无validateUser失败处理无ProcessingException转换逻辑无transformationPipeline审计日志无auditLog返回结果voidUserProcessingResult2.2 把修复需求写成 Codex 能执行的 prompt补全 prompt 不能只说「帮我写健壮点」要把验收标准写进去现有代码 public void processUserData(User user) { user.setProcessed(true); } 请补全为健壮版本要求 1. validateUser 负责校验user 为 null 或字段非法时返回 ValidationResult 2. 校验失败时先记录拒绝审计再抛出 ProcessingException 3. 校验通过后走 transformationPipeline.apply 4. 成功后 auditLog 记录处理明细 5. 返回 UserProcessingResult状态 SUCCESS 6. 只输出 Java 代码和 JUnit 测试不要连接任何外部环境第六点很重要。Codex 这类工具接到模糊任务时默认会「往完整了猜」但如果你不约束边界它可能顺手引入数据库访问或外部服务调用。把「只输出代码和测试」写进 prompt补全结果就限定在你可以本地验证的范围内。3. 在 Codex 的 config.toml 里把模型通道切到 TaoToken3.1 创建 API Key打开 TaoToken 注册登录进入控制台后创建一个 API Key。创建完复制保存下一步要填到环境变量里。这个页面同时也是模型广场和用量控制台的入口后续想看模型 ID 或核对 token 消耗都在这里。注意官网落地页和接口地址是两回事。落地页给你注册、建 Key、看面板真正填进 Codex 的 Base URL 是 https://taotoken.net/api末尾不要加/v1也不要把官网地址填进去。3.2 Codex 的配置不是 ANTHROPIC_BASE_URL如果你之前配过 Claude Code 那类工具可能会习惯性去找 ANTHROPIC_BASE_URL。Codex 不读这套变量它读~/.codex/config.toml。按下面这样新建或修改model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后导出 Keyexport TAOTOKEN_API_KEYYOUR_API_KEYYOUR_MODEL_ID 不要自己编后缀打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 的模型广场选一个当前列表里真实存在的 ID 填进去。base_url 固定是 https://taotoken.net/apiCodex 会自动处理路径拼接你多加一个/v1反而会拼出错误地址。提示model的值以模型广场当时列表为准不要沿用任何旧文章里的模型名。3.3 先验证连通性再干活改完配置先跑一条最轻量的指令codex exec 只回复 OK如果 Codex 能正常返回说明 Key、Base URL、模型 ID 这条路是通的。此时再贴 processUserData 的修复 prompt排障成本最低。常见失败先在这里暴露401 基本是TAOTOKEN_API_KEY没导出或复制不全model not found 是模型 ID 和广场列表不一致。与其等整个补全任务跑到一半才发现通道有问题不如先用一句话验证。4. 用补全后的 processUserData 替换空壳Java 代码与 JUnit 测试4.1 Codex 按 prompt 输出的完整版本把上面的 prompt 交给 Codex 后拿到的大致是这个级别public class UserDataProcessor { private final TransformationPipeline pipeline; private final AuditLog auditLog; public UserDataProcessor(TransformationPipeline pipeline, AuditLog auditLog) { this.pipeline pipeline; this.auditLog auditLog; } public UserProcessingResult processUserData(User user) { ValidationResult validation UserValidator.validate(user); if (!validation.isValid()) { auditLog.logRejected(user, validation.errors()); throw new ProcessingException(validation.errors()); } try { User processed pipeline.apply(user); auditLog.logProcessing(user, processed); return new UserProcessingResult(processed, Status.SUCCESS); } catch (TransformationException ex) { auditLog.logFailure(user, ex); throw new ProcessingException(ex.getMessage(), ex); } } }比原版多出来的部分是 try-catch。原文的人类健壮版处理了「校验失败」和「成功」两头但转换管道本身也可能抛异常把TransformationException也接到审计日志里才算把失败路径闭环。这也说明 prompt 里只写「校验、异常、审计」还不够最好再补一句「转换过程抛异常也要记录并抛出」。4.2 JUnit 测试盖住三条失败路径class UserDataProcessorTest { Test void rejectsNullUser() { UserDataProcessor processor new UserDataProcessor(new NoopPipeline(), new InMemoryAuditLog()); assertThrows(ProcessingException.class, () - processor.processUserData(null)); } Test void rejectsInvalidUserAndLogs() { InMemoryAuditLog auditLog new InMemoryAuditLog(); UserDataProcessor processor new UserDataProcessor(new NoopPipeline(), auditLog); User invalid new User(null, -1); assertThrows(ProcessingException.class, () - processor.processUserData(invalid)); assertEquals(1, auditLog.rejectedCount()); } Test void logsTransformationFailure() { InMemoryAuditLog auditLog new InMemoryAuditLog(); TransformationPipeline failing user - { throw new TransformationException(boom); }; UserDataProcessor processor new UserDataProcessor(failing, auditLog); assertThrows(ProcessingException.class, () - processor.processUserData(new User(u, 1))); assertEquals(1, auditLog.failureCount()); } }三条测试分别对应null 入参、字段非法、转换失败。跑通这三条processUserData就不再是「已处理但不安全」的空壳而是把入口、转换、审计都焊死的正规函数。5. 本地 mvn test 跑一遍把报错贴回 Codex 完成排障闭环5.1 运行边界Codex 生成代码后不要让它在会话里直接连生产库或操作线上数据。你把上面这些 Java 文件放到本地工程用mvn test或对应的构建命令跑一遍再把报错信息原样贴回对话让它继续修。这个分工是固定的Codex 负责生成、解释、对照代码编译运行和结果确认留在你本地。AI 编程工具没有你的业务上下文也不该被赋予执行权限它能看到的是你贴回去的报错文本而不是整个生产环境。5.2 排障对照表现象原因处理codex exec返回 401TAOTOKEN_API_KEY 没导出或 Key 不对执行echo $TAOTOKEN_API_KEY确认回控制台重新复制返回 model not found模型 ID 与广场不一致打开模型广场核对后再改 config.tomlmvn test找不到 ProcessingException异常类没有一并生成让 Codex 把异常类定义也加到输出里测试通过但 auditLog 计数为 0注入的 AuditLog 是空实现换 InMemoryAuditLog检查 pipeline 是否提前 return5.3 补全后的收尾检查测试变绿只是第一步还要人为核对三件事校验失败时是不是先写拒绝日志再抛异常转换失败时有没有把原始异常包进ProcessingException成功路径里auditLog.logProcessing是否真的记录了 user 和 processed 两个对象。Codex 生成的代码经常「看起来正确」但只有这三条路径都验证过才算把空壳补完。6. 跑通后回控制台对一下这次 Codex 调用6.1 用模型对话确认 Key 状态配置保存后先在 TaoToken 模型对话 里用同一把 Key 发一条消息确认模型 ID 和 Base URL 没填错。Codex 里的配置如果没问题模型对话里应该也能正常返回这样你可以区分是 Codex 路径的问题还是 Key 本身的问题。这一条消息也会出现在用量记录里正好用来核对计费口径。6.2 对一下用量和套餐跑通补全任务后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 的控制台看这次会话的 token 消耗。如果打算长期让 Codex 写这类补全活可以打开 Coding Plan 看套餐是否够用Key 管理在 控制台 API Keys 创建。下次再遇到 Codex 生成空壳函数先别急着骂它把校验、异常、审计写进 prompt再走一遍这个流程剩下的就是本地跑测试的事。 processUserData 校验缺失，用 TaoToken 让 Codex 按健壮版补全
1. 复现 processUserData 的「假完成」先看 AI 把校验漏成了什么样在《AI程序员崛起》3.1 节里processUserData被 AI 写成了空壳。补全它我用 TaoToken 接 Codex——先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建 API Key再改 Codex 的~/.codex/config.tomlBase URL 填 https://taotoken.net/api。这样 Codex 走的是统一 API 通道模型 ID 以模型广场为准。下面从复现这个空壳开始。1.1 AI 版本为什么能骗过眼睛public void processUserData(User user) { user.setProcessed(true); }这段代码能通过编译在 demo 里也能跑通。麻烦在于它把「执行动作」和「校验结果」混为一谈只要走到这一行不管 user 是 null、邮箱为空、余额为负状态都会被改成processed。真实的业务系统里这种函数往往处在入口位置上游传来什么就处理什么下游消费时又默认数据已经被清洗过于是脏数据一路流到报表或对账环节才暴露。它最大的问题不是「代码少」而是「失败路径完全没有被建模」。1.2 模糊需求如何诱导模型偷懒原文里人类工程师只描述了一句话「创建一个函数处理用户数据」。这句话没有定义什么算合法、什么算处理成功、失败时该抛异常还是返回结果。模型在训练数据里见过大量setProcessed(true)这类状态位操作遇到模糊指令时会优先选择统计频率最高的实现而不是语义最完整的实现。可以类比成让实习生「把快递处理一下」实习生的第一反应是签收而不是检查破损、登记单号、通知收件人——因为指令里根本没提这些步骤。1.3 为什么这种空壳能穿过 code review空壳函数没有语法错误也没有明显的逻辑错误。code review 时如果只盯「这段代码是否做了该做的事」它确实把processed状态写了。只有追问「如果 user 非法会怎样」「转换失败会怎样」「这笔处理记录去哪查」才会暴露缺口。这也是本文要把校验、异常、审计一起补全的原因不是为了让代码看起来更厚而是让函数在每条路径上都有明确行为。2. 对照 validateUser、ProcessingException、auditLog找出空壳缺了什么2.1 人类健壮版到底多写了什么同样一句话人类工程师给出的版本会先把校验、异常、审计、转换、返回值这五件事排好public UserProcessingResult processUserData(User user) { ValidationResult validation validateUser(user); if (!validation.isValid()) { auditLog.logRejected(user, validation.errors()); throw new ProcessingException(validation.errors()); } User processed transformationPipeline.apply(user); auditLog.logProcessing(user, processed); return new UserProcessingResult(processed, Status.SUCCESS); }表面上是多写了几个方法调用实际上是多了三层设计入口处先做防御失败时不静默而是抛出带错误明细的异常成功路径也不忘留审计痕迹。用表格对照能力AI 空壳版人类健壮版入参校验无validateUser失败处理无ProcessingException转换逻辑无transformationPipeline审计日志无auditLog返回结果voidUserProcessingResult2.2 把修复需求写成 Codex 能执行的 prompt补全 prompt 不能只说「帮我写健壮点」要把验收标准写进去现有代码 public void processUserData(User user) { user.setProcessed(true); } 请补全为健壮版本要求 1. validateUser 负责校验user 为 null 或字段非法时返回 ValidationResult 2. 校验失败时先记录拒绝审计再抛出 ProcessingException 3. 校验通过后走 transformationPipeline.apply 4. 成功后 auditLog 记录处理明细 5. 返回 UserProcessingResult状态 SUCCESS 6. 只输出 Java 代码和 JUnit 测试不要连接任何外部环境第六点很重要。Codex 这类工具接到模糊任务时默认会「往完整了猜」但如果你不约束边界它可能顺手引入数据库访问或外部服务调用。把「只输出代码和测试」写进 prompt补全结果就限定在你可以本地验证的范围内。3. 在 Codex 的 config.toml 里把模型通道切到 TaoToken3.1 创建 API Key打开 TaoToken 注册登录进入控制台后创建一个 API Key。创建完复制保存下一步要填到环境变量里。这个页面同时也是模型广场和用量控制台的入口后续想看模型 ID 或核对 token 消耗都在这里。注意官网落地页和接口地址是两回事。落地页给你注册、建 Key、看面板真正填进 Codex 的 Base URL 是 https://taotoken.net/api末尾不要加/v1也不要把官网地址填进去。3.2 Codex 的配置不是 ANTHROPIC_BASE_URL如果你之前配过 Claude Code 那类工具可能会习惯性去找 ANTHROPIC_BASE_URL。Codex 不读这套变量它读~/.codex/config.toml。按下面这样新建或修改model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后导出 Keyexport TAOTOKEN_API_KEYYOUR_API_KEYYOUR_MODEL_ID 不要自己编后缀打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 的模型广场选一个当前列表里真实存在的 ID 填进去。base_url 固定是 https://taotoken.net/apiCodex 会自动处理路径拼接你多加一个/v1反而会拼出错误地址。提示model的值以模型广场当时列表为准不要沿用任何旧文章里的模型名。3.3 先验证连通性再干活改完配置先跑一条最轻量的指令codex exec 只回复 OK如果 Codex 能正常返回说明 Key、Base URL、模型 ID 这条路是通的。此时再贴 processUserData 的修复 prompt排障成本最低。常见失败先在这里暴露401 基本是TAOTOKEN_API_KEY没导出或复制不全model not found 是模型 ID 和广场列表不一致。与其等整个补全任务跑到一半才发现通道有问题不如先用一句话验证。4. 用补全后的 processUserData 替换空壳Java 代码与 JUnit 测试4.1 Codex 按 prompt 输出的完整版本把上面的 prompt 交给 Codex 后拿到的大致是这个级别public class UserDataProcessor { private final TransformationPipeline pipeline; private final AuditLog auditLog; public UserDataProcessor(TransformationPipeline pipeline, AuditLog auditLog) { this.pipeline pipeline; this.auditLog auditLog; } public UserProcessingResult processUserData(User user) { ValidationResult validation UserValidator.validate(user); if (!validation.isValid()) { auditLog.logRejected(user, validation.errors()); throw new ProcessingException(validation.errors()); } try { User processed pipeline.apply(user); auditLog.logProcessing(user, processed); return new UserProcessingResult(processed, Status.SUCCESS); } catch (TransformationException ex) { auditLog.logFailure(user, ex); throw new ProcessingException(ex.getMessage(), ex); } } }比原版多出来的部分是 try-catch。原文的人类健壮版处理了「校验失败」和「成功」两头但转换管道本身也可能抛异常把TransformationException也接到审计日志里才算把失败路径闭环。这也说明 prompt 里只写「校验、异常、审计」还不够最好再补一句「转换过程抛异常也要记录并抛出」。4.2 JUnit 测试盖住三条失败路径class UserDataProcessorTest { Test void rejectsNullUser() { UserDataProcessor processor new UserDataProcessor(new NoopPipeline(), new InMemoryAuditLog()); assertThrows(ProcessingException.class, () - processor.processUserData(null)); } Test void rejectsInvalidUserAndLogs() { InMemoryAuditLog auditLog new InMemoryAuditLog(); UserDataProcessor processor new UserDataProcessor(new NoopPipeline(), auditLog); User invalid new User(null, -1); assertThrows(ProcessingException.class, () - processor.processUserData(invalid)); assertEquals(1, auditLog.rejectedCount()); } Test void logsTransformationFailure() { InMemoryAuditLog auditLog new InMemoryAuditLog(); TransformationPipeline failing user - { throw new TransformationException(boom); }; UserDataProcessor processor new UserDataProcessor(failing, auditLog); assertThrows(ProcessingException.class, () - processor.processUserData(new User(u, 1))); assertEquals(1, auditLog.failureCount()); } }三条测试分别对应null 入参、字段非法、转换失败。跑通这三条processUserData就不再是「已处理但不安全」的空壳而是把入口、转换、审计都焊死的正规函数。5. 本地 mvn test 跑一遍把报错贴回 Codex 完成排障闭环5.1 运行边界Codex 生成代码后不要让它在会话里直接连生产库或操作线上数据。你把上面这些 Java 文件放到本地工程用mvn test或对应的构建命令跑一遍再把报错信息原样贴回对话让它继续修。这个分工是固定的Codex 负责生成、解释、对照代码编译运行和结果确认留在你本地。AI 编程工具没有你的业务上下文也不该被赋予执行权限它能看到的是你贴回去的报错文本而不是整个生产环境。5.2 排障对照表现象原因处理codex exec返回 401TAOTOKEN_API_KEY 没导出或 Key 不对执行echo $TAOTOKEN_API_KEY确认回控制台重新复制返回 model not found模型 ID 与广场不一致打开模型广场核对后再改 config.tomlmvn test找不到 ProcessingException异常类没有一并生成让 Codex 把异常类定义也加到输出里测试通过但 auditLog 计数为 0注入的 AuditLog 是空实现换 InMemoryAuditLog检查 pipeline 是否提前 return5.3 补全后的收尾检查测试变绿只是第一步还要人为核对三件事校验失败时是不是先写拒绝日志再抛异常转换失败时有没有把原始异常包进ProcessingException成功路径里auditLog.logProcessing是否真的记录了 user 和 processed 两个对象。Codex 生成的代码经常「看起来正确」但只有这三条路径都验证过才算把空壳补完。6. 跑通后回控制台对一下这次 Codex 调用6.1 用模型对话确认 Key 状态配置保存后先在 TaoToken 模型对话 里用同一把 Key 发一条消息确认模型 ID 和 Base URL 没填错。Codex 里的配置如果没问题模型对话里应该也能正常返回这样你可以区分是 Codex 路径的问题还是 Key 本身的问题。这一条消息也会出现在用量记录里正好用来核对计费口径。6.2 对一下用量和套餐跑通补全任务后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 的控制台看这次会话的 token 消耗。如果打算长期让 Codex 写这类补全活可以打开 Coding Plan 看套餐是否够用Key 管理在 控制台 API Keys 创建。下次再遇到 Codex 生成空壳函数先别急着骂它把校验、异常、审计写进 prompt再走一遍这个流程剩下的就是本地跑测试的事。