别再只管理“人”了，AI时代下管理者的核心是“上下文”

故事的开始：老K的“救火”日常

老K是我的一位朋友，一个经验丰富的研发经理。上周我们约着喝咖啡，他来的时候，脸上还带着没熄灭的“火药味”。

“刚开完迭代规划会，” 他灌了一大口冰美式，说：“又崩了。”

我问他怎么了。

“一个电商大促的需求，产品、运营、市场塞了一堆东西进来。我带着团队拆解任务，两个小时下来，白板画得满满当登，但每个人的脸上都写满了迷茫。” 老K揉着太阳穴，“有人问‘这个支付逻辑和上次的活动一样吗？’，有人说‘这个库存接口得重构，不然撑不住’，还有人抱怨‘需求的文档链接又失效了’……”

会议室里，需求文档、聊天记录、原型图、过往项目的代码……无数的信息碎片在空中乱飞。每个工程师都像是在浓雾中驾驶，小心翼翼地切换着不同的“上下文”，生怕一不留神就撞上冰山。

老K的结论是：“团队的承载能力到极限了，下个季度必须招人。”

我看着他疲惫的样子，问了一个问题：“老K，你有没有想过，问题可能不在于团队的人手不够，而在于我们为他们提供的‘工作上下文’，本身就是一团乱麻？”

他愣住了。

犀利的观点：优秀的管理者，是“首席上下文官”

昨天深夜，我正在试验一个AI Agent，想让它帮我构建一个复杂的竞品价格监控爬虫。我使用了流行的Scrapy框架，然后给了它一个宏大的指令：“请为我构建一个能监控所有竞品网站、处理反爬、并存入数据库的全功能爬虫。”

结果可想而知。Agent像个无头苍蝇，它生成的代码逻辑混乱，在处理不同网站的页面结构时反复出错，最终陷入了无尽的循环和报错。它被这个过于庞大和模糊的“上下文”彻底压垮了。

于是，我改变了策略。我将任务分而治之：

• 指令一：“请分析这个具体的产品列表页URL，使用Scrapy框架，为我提取出商品名称、价格和链接的CSS选择器，并编写一个函数。”
• 指令二：“现在，针对这个具体的产品详情页，为我提取出详细规格参数。”
• 指令三：“请编写一个独立的Python模块，用于管理User-Agent轮换，以应对基础的反爬机制。”

奇迹发生了。面对这些边界清晰、目标明确的“小上下文”，AI Agent的表现堪称完美。它迅速、准确地生成了一段段高质量、可复用的代码。最后，我只花了少量时间，就将这些“零件”组装成了一个强大的爬虫。

这并非AI Agent带来的全新启示，而是对计算机科学中最古老、最强大的思想——“分而治之”（Divide and Conquer）——在组织管理学上的一次深刻回响。从最早的专家系统，到如今的Agent架构，其核心哲学从未改变：再复杂的系统，都可以被拆解为一系列简单的、上下文独立的子问题。

这与《敏捷宣言》中“响应变化高于遵循计划”和“可工作的软件是首要进度度量标准”的精神不谋而合。我们突然意识到，我们管理团队的方式，与管理一个AI Agent的上下文窗口，本质上并无不同。一个优秀的管理者，其核心职责，早已不是分配任务，而是为团队设计一个个小而美的、无歧义的‘上下文窗口’。

我们不应该再是那个催促划船的“监工”，而应该成为团队的“首席上下文官 (Chief Context Officer)”。

事实的演进：从管理“任务”到管理“上下文”

这个观点并非空穴来风，回溯软件工程的发展史，你会发现，我们所有的努力，都是一部“上下文管理”的进化史。

第一阶段：任务管理时代 (约2005-2015)
还记得那个时候吗？我们用着Jira、Redmine。我们学会了敏捷，把庞大的“项目”拆解成一个个独立的“任务卡片”。这是一个巨大的进步，我们开始尝试将工作放进一个个独立的“盒子”里。但问题是，这些盒子之间是割裂的。需求的上下文在Wiki里，代码的上下文在SVN里，部署的上下文在运维的脚本里。工程师们的大部分精力，都耗费在了手动连接这些盒子上。

第二阶段：流程管理时代 (约2015-2025)
然后，DevOps理念兴起，像阿里云“云效”这样的BizDevOps平台开始成为主流。这又是一次巨大的飞跃。

我们来看看云效做了什么：

• 项目协作Projex 将需求、任务、缺陷紧密绑定，让计划的上下文不再漂移。
• 代码管理Codeup 通过关联需求，让每一行代码的提交，都带上了清晰的“业务上下文”。
• 流水线Flow 将代码的构建、测试、部署过程自动化，将“交付的上下文”标准化。

在这个阶段，我们不再只管理孤立的“任务”，我们开始管理一条端到端的、上下文自动流转的“价值流”。老K团队的混乱，其实就是没有用好这个时代的工具，让上下文重新退化到了“口头同步”的原始状态。

第三阶段：上下文驱动时代 (2025及未来)
现在，我们正站在新时代的门槛上。AI Agent的能力越来越强，而Spec-Driven Development (规约驱动开发)这个概念也开始崭露头角。

SDD的核心，是创造一份机器可读、逻辑严谨、毫无歧义的“规约（Spec）”，并以此作为驱动所有后续工作的唯一真相来源。

这，就是“上下文管理”的终极形态。

一份完美的Spec，就是一个完美的“Prompt”，一个完美的“上下文窗口”。在这个窗口里，无论是人类工程师，还是AI Agent，都能心无旁骛地进行最高效的创造。

结论：回到老K的困境

让我们回到老K的迭代规划会。作为“首席上下文官”，他应该做什么？

他应该把80%的精力，都花在会议开始之前。他需要和产品经理一起，将每一个需求，都打磨成一个清晰、独立、可验证的“上下文窗口”。这个窗口里应该包含：

• 明确的用户故事和验收标准 (Spec的一部分)。
• 相关的设计稿和数据结构。
• 清晰的技术约束和依赖关系。

当他把这样一个“开箱即用”的上下文交给团队时，会议室里将不再是迷茫和争吵，而是高效的估点和认领。团队的“承载能力”，可能会超乎他的想象。

你的价值，不再是监督和驱动，而是设计和维护一个能让“执行者”（无论是人，还是AI）高效产出的上下文环境。这，就是AI时代赋予每一位管理者的全新使命。

我是Dukemon。

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