前言
探讨了在使用 AI 辅助开发时如何避免过度提供上下文导致的 “喂养野兽” 问题。今日前端早读课文章由 @Sobu 分享，@飘飘编译。
译文从这开始～～
2025 年 8 月 27 日
关于上下文窗口、智能体专精以及真正能交付的血泪指南
一位尼日利亚的软件开发者形象，手中握着发光的缰绳，这些缰绳连接着多条平行的光流，代表着 git worktrees 和 AI 智能体，在太空中形成一个 OODA 回路（观察–定位–决策–行动）的图案。深色背景，电蓝与青色的高光，风格干净、几何化，像一张技术示意图。
一个用户故事。一个满足所有条件的简单聊天界面规范。清晰的验收标准。GraphQL 模式。数据库模型。甚至还有 ASCII 风格的 UI 流程图。
我把这些都交给了 Claude Code。它开始写代码。写啊写啊写。
【早阅】逆向工程 Claude Code：学习这些 Agent 技巧
数万行代码之后，它还在某个数字深渊里继续着，努力满足自己定义的 “完成标准”。一个完美的实现却从未交付。一个永不知足的怪兽。
房间里的大象
我原以为自己做得对：详尽的规格说明，详尽的上下文，把所有文件都丢进上下文窗口。提供最多的信息以获得最多的输出。
但事实是，我给的上下文越多，Claude 生成的内容就越复杂。它不是在构建我想要的东西，而是在构建它认为我该想要的东西。为原型设计搭建生产级架构。为本地脚本生成 Kubernetes 部署。为单元测试再写单元测试。
于是我意识到：我是在试图一口吞下整头大象，而不是拿刀叉慢慢切。
这种情况，你肯定经历过：一个简单的 CRUD 接口，最后演变成分布式微服务架构；一个 CSS 微调，最终触发完整的设计系统改造；一个小小的 bug 修复，先是变成了重构，最后竟演变成了重写。
我们被灌输的理念是：AI 助手只需要更多上下文。把一切都丢进去，让魔法发生。
但问题是 —— 上下文堆砌并不会减少幻觉，它只会放大幻觉。每多一个文件，就多一个 “创造性误读” 的入口。
驱使你不断喂养怪兽的三种恐惧
当你 “丢资料 + 祈祷” 时，其实背后是三种恐惧：
- “我是在训练我的替代者。” 它写的每一行都是你未曾写下的。你的手指日渐萎缩，而机器却愈发强大。
- “规划就是浪费时间。” 既然能交付成果，为什么要探索？既然它能以光速前行，为何还要去掌控方向？
- “它应该懂我想要什么。” 我都把一切交给它了：规格说明、文件、仓库。它还缺什么？
但真正的认知转变在于：驾驭一个超级智能的伙伴，需要更多工程判断，而不是更少。你不是被取代，而是被晋升 —— 从 “流水线厨师” 变成 “主厨”。
光速下的 OODA 循环
约翰・博伊德上校为战斗机飞行员开发了 OODA 循环：观察 → 定位 → 决策 → 行动。在空战中，谁更快完成 OODA 循环，谁就赢。
你的 AI 运行速度极快。但没有你，其决策循环（OODA 循环）就会中断：
所以，你才是那个缺失的环节。你来闭合整个回路。
这就是为什么 “探索→规划→执行” 在一次性提示失败的地方能够奏效。
探索 → 规划 → 执行：对抗 AI 赌徒心态的解药
“一次性提示” 就像赌博。有时赢了，但大多数时候是输的。Claude 偶尔一次性命中时带来的多巴胺快感？远不及后续清理的代价。
【第3575期】解锁 AI 响应中的丰富 UI 组件渲染
探索：教会它去 “看”
在写代码之前，让 AI 去探索一下整体情况。这不是胡乱丢上下文，而是有目的的发现。
每一次探索都会暴露假设：我的、你的、AI 的。
让它一次向你提出一个问题来澄清情况。这样就能把那些藏在你脑子里但没写进规格说明里的隐含要求找出来。
规划：分而治之
探索之后便是进入规划。这时候你要拿起刀叉。
该规划不只是列任务，而是划定边界：我们要做什么，不做什么，做到哪一步就停。
AI 自己并不知道该停在哪里。每个函数都可以写得更健壮，每个组件都可以写得更通用，每个抽象都能再抽象。
执行：保持克制
执行阶段，纪律最重要。小步迭代，频繁验证。一个智能体，一项任务，一个专注点。
真正的魔力不在于速度，而在于操控。
九个惨痛的教训
我如何学会不再焦虑，而是驾驭这头野兽
这些教训都是用时间、文件损坏，或者惨痛失败为代价换来的。它们不是理论，而是真实留下的 “伤疤”。
教训 1：上下文窗口破产
我亲眼看着 49k 个 token 消失了，还没来得及输入一个字。后来才发现，我的 MCP 服务器吞掉了 25% 的上下文 ——context7、Zen、Serena、Playwright。
现在我运行 /context 就像查银行余额一样频繁。YAGNI（You Ain’t Gonna Need It）不仅适用于代码，也适用于工具。
【第1046期】JavaScript 中的执行上下文和调用栈是什么？
教训 2：精神分裂的 CLAUDE.md
前端的 CLAUDE.md 写着 “用 npm”。后端写着 “用 yarn”。根目录里又写着 “用 pnpm”。Claude 想讨好所有人。结果？一个 package.json 看起来像三位开发者在里面打架。
现在我的做法是：每个文件夹都有自己的 CLAUDE.md。明确性胜过混乱。
教训 3：拯救圣诞节的澄清问题
我说：“帮我做一个仪表盘。” 四个小时后，Claude 给我造了一个带 Grafana 集成的企业级分析平台。
但我真正想要的：只是三张图表。
现在我让 Claude 主动问我问题 —— 一次只问一个：
十分钟的问题，能省下十小时的删除。
教训 4：智能体交响乐灾难
两个智能体，同时改同一个文件，但思路完全不同：一位是采用形式验证来实现业务逻辑的 “证明引导编码员”，另一位是为同一代码编写测试的 “质量保证工程师”。
合并冲突看起来就像抽象艺术。现在我的代理们在平行宇宙中工作 ——git 工作树将它们隔离，直到它们准备好协调一致。
教训 5：OODA 循环拯救理智
我曾眼睁睁看着 Claude 写了 500 行代码，最后才发现那个 API 根本不存在。
现在的做法是：写 10 行，测试；再写 10 行，再测试。
Boyd 上校早就说过 ——OODA 回路跑得最快的人才能赢。小步快跑，问题在小的时候就能被发现。
教训 6：智能体是专家，而不是通才
- “调试这个 PostgreSQL 错误” → debugger agent 找到根因。
- “审查这段 Go 代码” → code-reviewer 抓出了竞争条件。
- “检查安全问题” → security-guardian 定位到 SQL 注入。
智能体擅长聚焦的专业任务，但面对宽泛模糊的指令就会乱套。一个智能体，一种专长，一次成功。
教训 7：上下文整理就是架构设计
以前：把整个 src/ 文件夹都丢进去。
现在：只放三个相关文件，一个类型定义，以及那个出错的测试。
结果：幻觉减少 90%，相关性提升 100%。
你的上下文窗口，就是你的架构。要有设计感。
教训 8：主智能体是指挥，不是演奏者
你的主要负责人不应编写代码 —— 而应指挥全局。技术负责人设计架构。验证引导型程序员在验证下进行实现。质量保证工程师编写测试。代码审查员确保质量。当您的主要负责人保持在较高层次时，您的环境就会保持整洁。
教训 9：探索能避免 “挖坑”
那个所谓的 “小功能”，结果需要数据库迁移、API 版本管理、前端状态处理？
要是先探索一下就好了。
花五分钟问 “要实现这个需要什么？”，能省下五小时的 “这为什么不工作？”。
从流水线厨师到主厨
你并没有失去技能，而是获得了更大的掌控力。
流水线厨师照着食谱做事。切洋葱，煎牛排。重要，但范围有限。
主厨则负责设计菜单、管理团队、保证品质、创造体验。
你的 AI 负责语法，你负责语义。它生成各种可能性，你来做决策。它写代码，你创造未来。
这不是 AI 在取代你，而是你在指挥一支 AI 智能体的乐队，每个成员都有自己的角色，而你确保它们最终协同，朝着你的愿景奏响和谐乐章。
明天你就能做的事
别再无止境地喂养那头野兽。开始学会引导它。
- 审视你的 AI 工作流：你是不是在靠 “一次性提示” 赌博？跟踪一周的成功率 —— 赌场永远是赢家。
- 为每个文件夹写 CLAUDE.md：尤其是在 monorepo 里。清晰的上下文指令能避免复杂的误解。
- 尝试「探索 → 规划 → 执行」：下次做新功能时，克制住直接开写的冲动。前期的投入会带来复利回报。
- 像对待货币一样管理上下文：在会话前、中、后都用
/context 检查。上下文就是你的 “资金”—— 要花得精明。 - 练习 OODA 回路：小改动 → 验证 → 小改动 → 再验证。靠微小的连续胜利积累势能，而不是寄希望于 “一次登月”。
你的 AI 搭档能以光速前进。没有你的掌舵，它只会带着混乱一路狂奔。
这头野兽会吞掉你喂给它的一切。
所以 —— 请聪明地喂养它。
关于本文
译者：@飘飘
作者：@Sobu
原文：https://sobu1.substack.com/p/ooda-loops-and-git-worktrees-nine
这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下。
