Management

每周一早上，我在董事群发一条消息，列出 16 位高管本周的重点事项。

接下来一周，我靠记忆和同事的自觉来掌握进度。有人及时反馈，有人到周五才想起有这回事，有人直接忘了。

上周五，我试了一下让 AI Agent 帮我跟。结果超出预期。

昨天一个校招生在钉钉上问我：「日报能不能让 AI 帮我写？我每天花 30 分钟凑那些东西，感觉像在演戏。」

我没有急着回答「能」或「不能」。因为这个问题的背后藏着一个更大的矛盾——

如果日报真的只是「写给主管看的汇报」，那让 AI 写完全合理，甚至应该让 AI 写。但如果日报的价值远不止于此，那用 AI 替代的可能恰恰是最不该被替代的部分。

问题不是「AI 能不能写日报」，而是： 在一个 AI 能替你写字的时代，人还应该写什么？

周五下午 4 点。你打开钉钉，你的 D 群里「本周的重点事项」消息已经发了 24 小时。16 位负责人被 @，每个人的进展回复散落在三个地方：有人私聊你说了三段话，有人在群里回了一个 emoji，还有人到现在一个字没发。

你要整理的，是一份让所有人都看得懂、能 action 的结构化进度报告。

手动做这件事需要 2-3 小时（经验估算）。你打开 16 个单聊窗口 + 群聊消息列表，翻来翻去。做得再仔细，也跑不掉三个 bias： recency bias ——最后看到的记得最清， salience bias ——写了一大段的人得到最多篇幅，写了三个字的人被一笔带过。 survivorship bias ——没回复的人直接消失在你的视野里，而不是被明确标记。

我手动做了这件事好几个月。然后写了一个 Agent Skill 文件——不到 200 行的 Markdown，把你的工作流程像岗位说明书一样写清楚。跑起来之后的效果不是「更快了」，而是 总结质量比手动好：每条来源可溯源、16 人全覆盖、没回复的标 ⚠️ 而不是消失。从 12 人扩到 16 人时，只改了 4 行映射表。

这篇文章讲的就是这个案例——以及如何把 Loop Engineering（让 Agent 自主跑到终点的工程方法）从写代码的场景，搬到管理协调的场景。

这个工程能落地，最关键的工具是 钉钉 DWS（DingTalk Workspace CLI）。DWS 是 Agent 与钉钉的统一接口层，它的设计让钉钉对 Agent 友好、对开发者友好。无论你使用哪款 Agent——OpenClaw、Hermes、OpenCode、悟空、MuleRun、WorkBuddy——都能通过 DWS 应用这套 AI 驱动的管理方法。Agent 是 fungible 的，接口层才是杠杆。

每个周五下午，你的团队在做同一件事：打开空白文档，回忆这周干了什么，凑出一份周报。

这件事的荒谬之处在于——周一到周五，你们已经开了 10 次站会，讨论了 50 个问题，做了 20 个决策。所有信息都已经存在了，只是散落在会议录音、聊天记录、任务系统里。周报不是「写」出来的，应该是「长」出来的。

这篇文章用一个 War Room Scrum 的完整案例，说明怎么用 AI 原生思维重构日报和周报流程。核心转变： 不是让 AI 帮你润色周报，而是让 AI 从日常运转的数据中自动聚合出周报。

Netflix 的「Context, not Control」曾经是最有影响力的管理理念之一。

它的核心假设很简单：给聪明人足够的上下文，他们会用你没想到的方式达成目标。你不需要控制过程，只需要提供信息、方向、约束。人的判断力、创造力、直觉——这些是 context 之外的东西，也是 Control 管不到的东西。

但这个理念套到 Agent 上，假设崩塌了。

「对人不提要求，就是对组织不负责。」

这句话我说过很多次，也被质疑过很多次。有人说这是 PUA，有人说这是管理者的傲慢。但我越做管理，越觉得这是一条被严重低估的基本原则——尤其在 AI 时代。

上周和一个做 AI 创业的朋友吃饭，他说了这样一段话：

“当一个 3.75 的同学收到超预期的即时奖励时，他爆发出来的效率是 10 倍的提高。再加上 AI 这个放大器，一个人绝对有可能达到 100 倍的效率提升。”

我当时第一反应是：这个数字太夸张了。但回来路上仔细想，我发现真正值得讨论的不是 100 倍这个数字是否准确，而是这句话背后隐含了一个组织范式的根本性转变——

传统组织靠控制来管理风险，AI 原生组织靠激发来释放上限。

而这两者的底层假设，完全不同。

上周三，一家头部互联网公司的CTO在季度复盘会上盯着一组数据沉默了整整两分钟。

Q1 的 AI 投入报表显示：工程团队 token 消耗同比增长 400%，人均 AI 工具支出逼近 20 万美元/年——已经和一个高级工程师的人力成本持平。但业务端呢？营收增长 35%，客户满意度提升了 8 个百分点。

“我们买了蒸汽机，但跑出来的速度还不如马车。“他最终说了这么一句。

会议室里没人接话。因为所有人都知道，问题不在 AI 技术本身——他们的工程师确实写出了更多代码，做了更多功能。问题在于：组织的工作方式没有变。AI 被塞进了旧的流程、旧的考核、旧的管理思维里，变成了"更贵的自动化”。

这不是个例。2026 年硅谷一线的最新观察揭示了一个残酷现实：AI 技术迭代已经进入"周级范式转换”，但绝大多数企业的组织形态还停留在"年度规划+季度复盘"的工业时代节奏里。技术跑得太快，组织跟不上，中间的鸿沟正在吞噬 AI 本该带来的价值。

去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。

他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”

这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。