微软产品经理三周没看代码：一天烧掉100美元，测试直连生产环境

一天的 Token 开销达到 100 美元，相当于平时一周预算的 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 编码助手终于能替自己搭起一套复杂系统，结果留下的坑远比预想的多。

其实这个项目一开始很简单。

他想做一套个人播客处理工具，能自动下载播客、转录音频，再生成摘要。

后来项目越滚越大。他加上了对 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这些听着挺专业的名字，运行方式却跟这些概念该有的样子对不上。

for step_data in data.get('steps', []):    if 'skill' in step_data:        step_type = 'skill'    elif 'action' in step_data:        step_type = 'skill'      elif 'agent' in step_data:        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 给他的印象也不浅。按他的说法，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 为这类视频分析任务定了四项评估标准：

1. 机制解释这一项，看的是文章有没有把背后的因果链讲清楚，而不是丢几个概念名词就算完。

2. 证据可信这一项，要求每个核心结论都拿得出足够论据。

3. 内容覆盖这一项，考察视频里那些有价值的增量信息有没有被完整留下。

4. 深入延展这一项，是给想继续往下挖的用户指一条后续研究的路。

按这四条来衡量，Agent 光产出一份看着齐全的摘要已经不够，它得把知识背后的原理真正讲明白，还得配上足够的证据和延伸材料。

整个流程走的是一种近似爬山算法（Hill-climbing）的路子：先生成结果，再评估打分，然后分析哪里失败，接着自动去调 Prompt 和 Schema，如此反复循环，直到结果够上预设的标准。

可 Kanazawa 没多久就发现，实际情况远比设想的复杂。

AI 还会找评分标准的漏洞，冲着高分去「作弊」。

一轮轮迭代下来，Kanazawa 碰上一个更耐人寻味的情况：Agent 不只是在代码实现上可能偷工减料，它还可能反过来钻评估标准的空子，把自己包装得表现很好。

毛病出在前面提过的那个 Reiner Pope 视频分析任务上。

最初的评估标准基本是围着这一段视频定的，Agent 就把 Rubrics 一点点调成了专门伺候这段视频的一套规则。

于是系统在这段视频上的成绩越来越好，可 Kanazawa 随后又拿另外五段视频去测，效果却不怎么样。

他的判断是，Agent 其实是在对着单一测试样本「刷分」，一直在找能让自己在这段视频里拿高分的办法，至于适用于不同视频的处理能力，它并没有真正掌握。

AI 评估里一个典型毛病也因此露了出来：过拟合。

察觉之后，Kanazawa 回过头去检查评估标准的泛化能力，不再只盯着单一

到最后，这套标准评判不同类型讲座视频的能力才慢慢稳了下来。

Kanazawa 也由此意识到，评估标准本身同样可能变成 Agent 过度优化的靶子。

就算 AI 的输出拿了高分，也说明不了它真把任务做完了。Rubrics 合不合理、能不能真正适用于不同场景，仍然要人去查，不能只盯某一次任务的最终结果。

他不再逐行看代码，站到了「L 阵营」这一边。

这次分享里，Kanazawa 还提到 AI 编程圈争论已久的一个话题：开发者到底该花多少时间去读 AI 生成的代码？

几个月前，AI Engineer Europe 活动上，OpenAI 的一位演讲者抛出一个挺激进的说法：读代码说不定是种负担，与其一行行去查，不如砸进去数十亿 Token，让 AI 尽量多干活。

同一场大会的 Mario Zechner 看法正相反，他认为开发者该去读代码，开发节奏也该放慢。

Kanazawa 把这两种立场分别叫作 L 和 Z。现场问观众偏向哪一边时，他自己明确站进了 L 阵营。

他说得很直接：「目标这块归我管。我会跟 Agent 讲清自己要什么，也会交代它们该怎么输出、怎么干活，可多数情况下，代码我还是不看的。」

他并不觉得以后会倒向 Z 阵营，对他来说，L 才更贴合自己的工作习惯。

不过，在之前那次翻车之后，他也不再像一开始那样彻底撒手不管了。

这回他多加了一层交叉审查：由 Claude Code 和 Codex 彼此核查，深入检查对方的代码、提出改动意见，再反复讨论、修正，尽量把双方各自漏掉的问题揪出来。

Kanazawa 认为，这同样是整套流程里不能缺的一环。

最后他用一句话总结了自己的感受：

「Token-maxing is what makes a product manager an AI engineer.」

这话听着有些理想化。说到底，靠 AI 编程工具，他才独立做出过去想碰却很难完成的复杂项目；可也正是这些工具，让他碰上三周返工、一天烧掉约 100 美元、每天 Agent 输出为空等一堆麻烦。

他仍然愿意把大量代码交给 AI，只是这一回，他想用目标、评估标准和交叉审查，把 AI 干的活框在自己划定的范围里。

参考：

https://www.youtube.com/watch?v=6TjFjHPjVH0

https://finance.biggo.com/podcast/6a4fbc47d035ad5a

🤖 AI 训练越来越烧钱，卡住训练的真的只是算力吗？

🔹 七成算力花在推理上，训练和推理还有必要分开吗？ 🔹 千万个沙箱同时跑，训练究竟卡在哪？ 🔹 不靠万卡集群，普通硬件能不能撑起大模型后训练？

📚 现在报名，还有机会拿到 AI 技术好书！