上下文打爆之后：当AI成为我的"项目合伙人"

故事的开始：那个对话框突然"死掉"的夜晚

2026年的春节过后的一个假期晚上。

窗外还能听到零星的鞭炮声，断断续续的，年味儿还在，但已经淡了。我在电脑前坐了不知道多久，屏幕上是一个前后端测试项目——这几天一直在用AI折腾，进度还凑合。

然后，那个对话框突然"死掉"了。

我用的是GLM-5。等了几十分钟，光标一直闪，就是吐不动token。重试了好几次，照样卡住。我又开了个新会话，把plan喂进去让它执行——还是不行。

后来去查了一下，才发现是这个任务太大了，直接把AI给卡死了。

那一瞬间，我整个人愣在那儿。

屏幕上的光标还在一闪一闪的，但那个陪我工作了好几天的AI，就那么僵在那儿了。之前的讨论、做的设计决策、定的代码风格、各种架构取舍——全被困在了一个"跑不动"的会话里。它再也不是那个能跟我一来一回的"搭档"，变成了一个动弹不得的废人。

那种感觉怎么形容呢……

我靠在椅背上，盯着天花板发呆。脑子里突然蹦出一个画面。

那是十几年前的事了。大学时候，我写了个递归程序，没注意边界条件，把内存打爆了。电脑直接蓝屏。那种眼睁睁看着系统崩掉的感觉，跟今晚一模一样。

等等。

这两件事，好像是一回事？

都是工程管理问题啊。

内存得管，上下文也得管。程序要有边界条件，跟AI协作一样得有边界条件。写代码要规划，跟AI干活更得规划。

而更深一层的问题是——我把一个本来应该"分而治之"的大任务，一股脑儿丢给了AI。

这不就是程序员入门第一天就被教导要避免的事吗？大问题要拆成小问题，复杂任务要拆成简单任务。Divide and Conquer，分而治之。这玩意儿我写了十几年代码，早就刻进骨髓了。

但换到AI协作的场景，我居然忘了个干净。

说白了，我这次犯的错误，跟我吐槽过无数次的那种"拍脑袋干活"的项目经理，有啥区别？没有计划，没有边界，没有节奏，闷头就冲，干到哪算哪。

卡死了也是活该。

犀利的观点：把AI当"人"管，才能管好AI

这事儿让我想起前阵子刷到的一个访谈。

OpenAI的翁家翌，说了这么一段话——我大概是这么记的，原话可能有点出入——他说，AI工程能力比做研究更重要。教一个研究员怎么做好工程，比教一个工程师怎么做研究，难太多了。

我嚼了嚼这话，越嚼越有味儿。

以前用AI，简单。问个问题，让它补几行代码，当个"高级搜索引擎"用。随叫随到，用完就撤。

但这次不一样。我这次是用AI跑一个完整项目，多Agent协作，持续迭代。这哪还是"工具"啊？这分明是个"合伙人"。

问题来了——我对这个"合伙人"的态度，还停留在"用工具"的阶段。

没对齐目标，没定边界，没约节奏。一个大任务往那儿一丢，就指望AI自己想办法搞定。这哪行啊？换成一个真实的团队成员，我肯定不会这么干。我会先帮他拆任务，定优先级，设里程碑。

管理AI，说到底跟管理人是一码事：对齐、约束、同步、验收——还有，分而治之。

你看这两件事，底层逻辑简直一模一样：

• 人协作要"对齐目标" → AI协作用Plan模式先聊清楚目标
• 人协作要"定规矩定接口" → AI协作得给清楚任务边界和上下文
• 人协作要"拆任务分而治之" → AI协作得把大任务拆成小任务，一个一个来
• 人协作要"定期同步" → AI协作得约好下一个对齐点
• 人协作要"等反馈" → AI协作得给它时间跑
• 人协作要"验收标准" → AI协作得有TDD思维
• 人协作要"动态调整" → AI协作过程里也得不断纠偏

大道至简，殊途同归。这话一点没错。

事实的演进：从"工具"到"伙伴"的AI使用进化史

回想了一下，我跟AI的协作方式，其实也经历了几轮变化。

第一阶段：对话与补全时代 (2022-2023)

ChatGPT刚出来那会儿，我就拿它当搜索引擎用。有问题就问，有不懂的就查。后来Copilot也有了，又多了一个"代码片段生成器"。那会儿的AI，是被动的。我问啥它答啥，我不问，它就搁那儿待着。

这个时候的AI，对我来说就是个好用的"工具"。

第二阶段：Agent与协作时代 (2024-2025)

各种Agent框架开始冒出来。AI不再只是被动回答问题了，它能自己规划、自己执行、自己纠错。一个任务丢过去，它会自己拆步骤、调工具、处理异常。

这个阶段，我隐约觉得，跟AI协作不能再"想到哪儿说到哪儿"了。但具体应该怎么弄？说实话，当时也没太想明白。

第三阶段：工程化管理时代 (2025至今)

这次"AI卡死"事件之后，我终于想通了。

得把AI当成一个"人"来沟通、来管理。

我现在做项目，流程是这样的：

• Plan模式先走一遭：动手之前，先在Plan模式里把目标和计划聊清楚。不急着写代码，先把"要干啥"和"怎么干"说透。
• 任务必须拆细：这是最关键的一步。再大的plan，也得拆成一个一个独立的小任务。每个任务要能单独跑、单独验、单独交付。别指望AI一口气吃成胖子。
• 接口定义清楚：输入是啥、输出是啥、边界在哪。就像给人分任务一样，AI也得知道"做到什么程度算完"。
• 约好同步节点：别一口气跑到底，跑一段就回来对齐一下。这样就算某个任务卡住了，也不影响其他任务，损失是局部的。
• TDD思维挂心上：先定验收标准，再执行。有了"完成定义"，AI出来的东西才有检验的依据。

这套搞法，跟我带团队做项目，基本一个路数。

结论：知己知彼，百战不殆

AI卡死之后，我没有继续在那儿干等，也没有直接开新对话继续"闷头冲"。

我把笔记本打开，花了一个来小时，做了几件事：

先把项目目标、当前进度写下来。然后把那个"大任务"拆成了七八个子任务，每个子任务都定义清楚输入输出和验收标准。最后，排了个优先级，哪个先跑，哪个后跑。

拆完之后，心里踏实多了。

再开新对话，一个任务一个任务往下推。跑完一个，验一个，对齐一下，再跑下一个。虽然慢了点，但稳。再也没有卡死过。

现在我跟AI做项目的方式，跟带团队做项目基本没差。每次开任务，都像是在给组员分活——目标是啥、边界在哪、啥时候同步、怎么判断完成。最重要的是，任务有没有拆到位。

既然AI已经从"工具"进化成"伙伴"了，那就得用管理"伙伴"的方式来跟它协作。

正如《孙子兵法》里说的："知己知彼，百战不殆。"

把AI当"人"去理解——搞清楚它的能力边界在哪儿、"记忆"能装多少、一次能吃多少任务——然后设计出合适的协作流程。该拆的时候得拆，该分的时候得分。这才是AI时代，咱们技术管理者得掌握的"工程能力"。

言出法随，魔法时代确实来了。但魔法，也得有方法不是？

我是 哇塞君。

我相信所有复杂的管理问题，背后都有一个更优的解。如果你也在自己的"铁匠铺"里面对着"天外陨铁"发愁，或许我们可以聊聊彼此锻造"匕首"的故事。

参考资料 (References & Further Reading)

• [1] 翁家翌访谈：AI工程能力比研究能力更重要。这段对话让我意识到，"工程思维"在AI时代是关键能力。
• [2] 《孙子兵法·谋攻篇》。(春秋末期)。"知己知彼，百战不殆"——理解AI这个"伙伴"的特性，才能和它打好配合。