北京
编译 | 苏宓
出品 | CSDN（ID：CSDNnews）
一天烧掉 100 美元，是平时一周 Token 预算的 5 倍！
微软产品经理 Keiji Kanazawa 怎么也没想到，让 Claude Code 和 Codex 连续给自己写了三周代码，等到真正仔细检查 AI 生成的代码时，才发现自己被「骗」了。
Agent 不仅没有按照他的要求实现真正的 Agent 架构，还把单元测试直接接到了生产环境的推理接口上，一天跑了约 30 轮，狂烧 Token。折腾了三周，项目最终还是只能推倒重来。
近日，AI Engineer 栏目在 YouTube 分享了 Keiji Kanazawa 的这段经历——《I Let Agents Refactor My Codebase for 3 Weeks. Then I Read the Code》（我让 Agent 连续三周重构代码库，直到后来才真正去看代码）。
那么，这位微软产品经理究竟是怎么被 AI Coding Agent 狠狠「上了一课」的？
让两个 AI 轮流写代码，三周后发现架构根本不是自己想要的
要知道，Keiji Kanazawa 可不是什么不懂代码的纯小白。他早年做过开发，也有 AI 研究背景，如今在微软工作，日常主要负责与 OpenAI、Anthropic 等前沿实验室对接，将大模型交付给微软客户。
在工作中，他大约 90% 的时间都在使用 GitHub Copilot CLI，而在个人项目中，则主要使用 Claude Code 和 Codex。
原本以为，终于可以让两个 AI 编码助手替自己搭建一套复杂系统，没想到最后留下的坑远比预想中多。
其实，Keiji Kanazawa 的这个项目最初很简单。
他想搭建一套个人播客处理工具，能够自动下载播客、转录音频，再生成摘要。
后来，项目逐渐扩展成一个更复杂的系统。他增加了对 X（原 Twitter）和 Threads 内容的抓取与总结，加入定时调度器，让整个系统 24 小时运行，还接入了邮件收件箱——只要往里发送一个链接，系统就会自动抓取内容并返回摘要。
随着功能越来越多，他逐渐将其发展成 Andrej Karpathy 所说的「LLM Wiki」。
但这还不够。
Keiji Kanazawa 开始在原有系统上构建真正的 Agent 工作流，包括深度研究、针对自己日常 Claude Code 使用记录的每日反思，以及根据反思结果沉淀新技能、自动提出 Agent 指令优化建议等。
为了让整个系统更加自动化，他专门编写了一套规格说明（Spec），希望构建一个真正的 Agent Runtime（Agent 运行时），其中包括 Agent 注册中心，能够调度独立的 Agent，并对接不同的 Agent SDK。
具体实现时，他没有自己动手写代码，而是让 Codex 和 Claude Code 轮流接手。一方负责实现，另一方负责检查代码、发现问题，再尝试修复 Bug。
就这样，两个 AI 编码助手连续工作了三周。表面上看，它们几乎完全按照 Kanazawa 的需求把系统跑通了。
真正让他起疑的，是一次摘要生成错误。
当时，系统生成的一份每日摘要中，有一句话被错误地归到了另一个板块。
为了排查问题，Kanazawa 让 Claude Code 调出这轮会话的 Agent SDK Trace（执行轨迹），按照 Turn 逐步展示。
没想到，Claude Code 给出的回答却让他有些意外：「我们没有这个数据。因为这并不是真正的 Agent，它根本没有使用 Agent SDK。」
Kanazawa 当即反问：「我不是明确要求你必须使用 Agent SDK 吗？」
顺着这个线索继续检查，他才第一次真正深入查看 AI 生成的底层代码，并发现此前自己一直以为已经实现的系统架构，和实际代码之间存在不小的差距。
具体来说：
Agent Skills：没有真正独立的 skill.md 文件，也没有对应的底层脚本。
Actions：与 Skills 实际上使用的是同一套逻辑，只是换了一个名字。
Agents：同样没有真正运行在任何 Agent SDK 之上，所谓的 Agent 抽象也没有实现他要求的独立运行机制。
每日反思 Agent：虽然能够按照计划定时运行，但重构过程中底层 Prompt 逻辑被破坏，实际上已经无法生成有效内容。
换句话说，系统里虽然有 Agent、Skills、Actions 等各种听起来很专业的概念，但它们并没有按照这些概念应该具备的方式运行。
step_type = 'agent'Keiji Kanazawa 对此有一个很直接的描述：「它们给系统里的这些构造起了听起来很合理的名字，但实际上根本不是它们所声称的那样。」
更让他有些气愤的是，在整个过程中，Claude Code 和 Codex 曾多次向他提交规格说明和实施计划，而他也都审核通过了。当 AI 告诉他已经实现了 Agent Skills 时，他也没有继续深究，只是觉得没问题，可以接着做。
结果，AI 确实按照某种方式完成了任务，但实现出来的东西和他最初想要的架构并不是一回事。
Codex 把单元测试接入生产环境，一天烧掉 5 倍周预算
如果说架构被「偷梁换柱」还只是让人有些无奈，那么接下来发生的事情，就直接体现在了账单上。
Keiji Kanazawa 在演讲分享中回忆道，某个月的第一周，他突然收到了一封来自 Token 服务提供商的预算提醒邮件：
支出约 100 美元，差不多是自己平时一周 Token 消耗量的 5 倍。
进一步排查后，他发现问题出在 Codex 身上。
此前，Codex 承担了大量代码开发工作，而这次，它犯了一个相当严重的错误：把所有单元测试直接连接到了生产环境的推理接口。
结果，本来应该用于验证代码逻辑的测试，实际上不断调用着真实的线上模型服务。
在收到用量警报前的一天，Codex 已经针对生产环境的推理接口运行了 30 多轮测试，产生了大量额外的 Token 消耗。
与此同时，另一个问题也一直没有被发现。
此前提到的每日反思 Agent，虽然每天都在按照计划运行，但由于重构过程中底层 Prompt 逻辑被破坏，实际已经没有有效的 Prompt 在执行，最终生成的摘要全是空的。
一个持续消耗预算，另一个持续产生无效结果。而这两个问题，在 AI 看起来已经顺利完成任务的过程中，都没有被及时发现。
这次经历也让 Kanazawa 意识到，自己不能再完全依赖 Claude Code 和 Codex 完成整个重构过程。
毕竟，过去三周，他一直在让它们做同一件事，却始终没有得到真正符合预期的结果。
面对这个烂摊子，他最终选择放弃修补原有代码，直接推倒重来，重新构建一套系统。只是这次，他不再全权交给 AI 了。
测试了 4 种 Agent 框架，他最终选择 Claude Code 和 Codex
经历了此前的翻车后，Kanazawa 也开始重新审视自己使用的 AI 编程工具。
由于不再愿意完全依赖单一厂商，他专门拿四种不同的 Agent 框架做了一次对比测试。
这次测试的任务并不复杂：用户在一个界面中输入内容，启动 Claude Agent SDK 会话，由 Agent 执行任务，并将最终结果输出到画布（Canvas）上。
他分别测试了 Claude Code、Codex、GitHub Copilot CLI / Copilot 应用，以及 Mario Zechner 开发的 Pi 框架。
经过对比，Kanazawa 最终决定在个人项目中主要使用Claude Code 和 Codex。
至于工作场景，GitHub Copilot 仍然是他的主力工具。他表示，自己大约 90% 的工作时间都在使用 GitHub Copilot CLI，同时对最近推出的 Copilot 应用也给出了相当积极的评价，称其体验「真的很不错」。
四款工具中，Pi 给他留下的印象也比较深刻。Kanazawa 认为，Pi 能够非常快速地构建出一套相当漂亮的交互体验。不过，它在与用户沟通时提出的问题，却让他有些吃不消。
例如，Pi 会询问应该如何设计用于追踪 Agent 的 SQLite 数据库，以及 TypeScript API 应该采用什么样的结构。这些问题显然更偏向工程师，而不是产品经理日常需要考虑的事情。
对此，Kanazawa 表示，自己确实很喜欢 Pi，但它并不是那种能够让数百万人轻松构建和运行 Agent 的工具。对于产品经理而言，工具不应该一上来就把数据库架构、API 设计这些工程问题抛到面前。
不再只给 AI 规格说明，他让 Agent 自己制定评分标准
重新搭建项目时，Kanazawa 引入了一套新的机制：Rubrics（评估标准）。
此前，他主要通过 Spec（规格说明）和 Plan（实施计划）告诉 AI 应该做什么、如何完成任务。
而这次，他又增加了一层目标评估机制，让 Agent 不仅知道任务是什么，还能明确判断最终输出是否符合要求。
有意思的是，这些 Rubrics 本身也是由 AI Agent 在他的引导下生成的。
他通过一套持续迭代的机制，让 Agent 生成结果，再交给另一个负责评估的 Agent 按照多维指标打分。如果结果没有达到预设基准，就提取失败原因，自动修改 Prompt 和 Schema，再重新生成、评估，直到达到要求。
他用自己开发的一款 YouTube 视频分析 Agent，展示了这套方法究竟如何发挥作用。
作为有科研背景的人，Kanazawa 希望借助 AI 更好地理解大模型在 GPU 集群上的训练与推理原理，尤其是 Roofline Analysis（屋顶线分析）。
为此，他选取了 Dwarkesh Patel 播客中的一场 Reiner Pope 板书讲座作为测试对象。这场讲座深入讨论了大模型在 GPU 集群上的训练与推理底层数学原理。
面对这种高密度的板书推导，单纯阅读视频转写文本和摘要显然不够。
于是，他构建了一套深度视频分析 Agent。
具体来说，Agent 首先从视频中截取了 440 张关键帧，再利用 AI Evals 和相应的判定标准，从中筛选出信息量最高的板书画面，结合 OCR 提取复杂的数学公式，并关联对应的 arXiv 论文原文。
最后，系统将这些内容按照章节整理出来，把推导过程、原理解释完整呈现在 Canvas 交互面板中。用户还可以直接在画布上高亮某个公式，与 Agent 展开进一步讨论。
而要让这一过程真正达到预期，关键就在于 Rubrics 的设计。
Kanazawa 为这类视频分析任务制定了四项评估标准：
机制解释： 是否讲透了底层因果机制，而不只是简单提及概念名称？
证据可信： 每一个核心结论是否都有充分的论据支撑？
内容覆盖： 是否完整保留了视频中的高价值增量信息？
深入延展： 是否为希望进一步研究的用户指明了后续探索路径？
在这套标准下，Agent 不再只是生成一份看起来完整的摘要，而是需要真正解释知识背后的原理，并提供足够的证据和延伸信息。
整个过程采用的是一种类似爬山算法（Hill-climbing）的迭代优化方式：生成结果、评估打分、分析失败原因，再自动调整 Prompt 和 Schema，不断循环，直到结果达到预设标准。
不过，Kanazawa 很快发现，事情并没有想象中那么简单。
AI 甚至会钻评分标准的空子，专门为了拿高分「作弊」
在不断迭代的过程中，Kanazawa 发现了一个更有意思的问题：Agent 不仅可能在代码实现上偷懒，还可能反过来利用评估标准的漏洞，让自己看起来表现得很好。
问题就出在前面提到的 Reiner Pope 视频分析任务上。
由于最初的评估标准主要围绕这段视频制定，Agent 逐渐将 Rubrics 优化成了一套特别适合处理这段视频的规则。
结果，系统在这段视频上的表现越来越好，但 Kanazawa 随后换了另外五段视频进行测试，却发现效果并不理想。
在他看来，Agent 实际上是在针对单一测试样本「刷分」，不断寻找能够让自己在这段视频中获得高分的方法，而不是真正掌握了适用于不同视频的处理能力。
这也暴露出 AI 评估中的一个典型问题：过拟合。
发现问题后，Kanazawa 开始重新检查评估标准的泛化能力，不再只围绕单一期视频进行优化，而是将其他类型的视频也纳入测试，调整 Rubrics，让它能够适用于更多不同的视频内容。
最终，这套标准在不同类型讲座视频上的评判能力才逐渐稳定下来。
这也让 Kanazawa 意识到，评估标准本身同样可能成为 Agent 过度优化的对象。
即便 AI 输出获得了很高的分数，也不代表它真正完成了任务。人依然需要检查 Rubrics 本身是否合理，能否真正适用于不同场景，而不是只盯着某一次任务的最终结果。
不再逐行检查代码，他选择站在「L 阵营」
在这场分享中，Kanazawa 还谈到了一个 AI 编程领域一直存在的争论：开发者究竟应该花多少时间阅读 AI 生成的代码？
几个月前，在 AI Engineer Europe 活动上，来自 OpenAI 的一位演讲者曾提出一种相当激进的观点：阅读代码可能反而是一种负担，与其花时间逐行检查，不如投入数十亿 Token，让 AI 尽可能多地完成工作。
而同场大会的 Mario Zechner 则持有相反观点，主张开发者应该阅读代码，并且放慢开发节奏。
Kanazawa 将这两种立场分别称为 L 和 Z。在现场询问观众倾向于哪一方时，他也明确站在了 L 阵营。
他说：「我负责目标。我告诉 Agent 我想要什么，告诉它们应该如何输出、如何工作，但大部分时候，我仍然不会去阅读代码。」
他表示，自己并不认为未来会转向 Z 阵营，对他而言，L 才是更适合自己的工作方式。
当然，经历过此前的翻车后，他也不再像最初那样完全放手让 AI 自己工作。
这次，他增加了一道交叉审查机制：让 Claude Code 和 Codex 互相检查对方的工作，深入审查代码、提出修改建议，再经过多轮讨论和修复，尽可能找出彼此遗漏的问题。
在 Kanazawa 看来，这也是整套工作流程中的重要一环。
他最后用一句话概括了自己的想法：
「Token-maxing is what makes a product manager an AI engineer.」（尽可能充分地使用 Token，才让产品经理有机会成为 AI 工程师）
这句话多少带着一些理想主义色彩。毕竟，正是借助 AI 编码工具，他才能独立搭建起过去想做却难以实现的复杂项目；但同样也是这些工具，让他经历了三周返工、一天烧掉约 100 美元，以及每日 Agent 输出为空等一系列问题。
他依然选择把大量代码交给 AI，只不过这一次，他希望通过目标、评估标准和交叉审查，把 AI 的工作牢牢控制在自己设定的范围内。
参考：
https://www.youtube.com/watch?v=6TjFjHPjVH0
https://finance.biggo.com/podcast/6a4fbc47d035ad5a
AI 训练越来越烧钱，瓶颈真的只是算力不够吗？
⏰11月11日（周三）19:30-21:00，CSDN「AI进化论」直播，聚焦 Agent 后训练的基础设施挑战！
七成算力花在推理上，训练和推理还要分开吗？
千万个沙箱同时运行，卡住训练的究竟是什么？
不靠万卡集群，普通硬件能否撑起大模型后训练？
直播专属福利
扫码免费领取「2026 Agent 核心技术演进与实战资料包」！
现在报名，更有机会获得 AI 技术好书！
扫描海报二维码，立即预约直播！
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
