Hugo Zhu's Blog

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

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

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

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

前几天刷社交媒体，看到一个技术总监发的帖子：「AI 帮我把周报、PPT、邮件全干了之后，我突然不知道该干嘛了。」底下几百条评论，清一色共鸣。

这不是段子。越来越多管理者发现，当 AI Agent 把开会、写文档、review 代码、处理审批从每天 8 小时压缩到 2 小时之后，他们面对一个从未想过的问题——多出来的 6 个小时，用来做什么？

这个问题，林语堂在 1937 年就回答了。

周五下午 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 的，接口层才是杠杆。

上周在钉钉里看到一条消息，让我意识到一个根本性的转变正在发生。

一位产品经理在群里 @AI 助理：「帮我总结一下今天会议的要点。」AI 很快给出了回复。几分钟后，她又 @采购 Agent：「根据这份 PRD，生成采购计划并提交审批。」

同样是 @AI，但两次操作的性质完全不同。第一次是 问一个问题，第二次是 派一个任务。

这个细微的差别，恰恰是 AI 时代 IM（即时通讯）正在发生的最深刻的范式转移： 沟通正在从「对话」演进为「协同」。

上周和一个做了十五年全栈的朋友吃饭。他最近从大厂出来，拿到两个 offer：一个是去创业公司做 Agent，一个是去传统企业做数字化。他选了后者，理由是「Agent 太新了，不确定性太大」。

我问他：你觉得做网站和做 App 有什么区别？

他想了想：「差不多，都是接需求、写代码、上线、迭代。」

我又问：那做 Agent 呢？

他说：「也是接需求、写代码、上线、迭代。只是交付物从页面变成了 Agent。」

他自己把答案说出来了，但没意识到这句话有多重要。

上个月一个前同事找我吃饭。他在某大厂做了八年后端，刚被裁。手里有两个选择：去创业公司做 Agent 工程师，或者自己干。

他问我：「自己干的话，我该做什么？」

我说：你做过钉钉 FDE 那种到客户现场交付 Agent 的项目吗？

他说没有，只在公司内部做过。

我说：那你差的就是三个项目。做完三个，你就可以一个人开公司了。

他愣了一下：「三个就够了？」

够了。但不是随便三个。

接着 销售流程 AI 化系列 的汽配分销商案例讲。

上一篇讲的是理念：解决方案对象、拜访质检、履约 SOP 编译。这一篇讲落地：FDE 到客户现场，怎么用基础设施在一天内把这些理念变成可运行的 Agent。

老周（售前）和小林（FDE）一起到了汽配客户现场。客户有 200 家门店，销售团队 30 人，每天处理 50+ 客户咨询、20+ 报价单、10+ 合同审批。

问题是：销售流程全靠人肉，信息散落在微信、Excel、邮件里，老周那份 80 页 PPT 签完单就死了。

周一早上，#platform-eng 频道。

Leo 发了一条消息：「checkout 今早变慢了，有人遇到吗？」

Dana 秒回：「我也是。」然后她 @了 Claude：「查一下今早部署的 diff，对比延迟数据，找出原因。」

接下来六分钟里发生的事，值得每个做 Agent 架构的人仔细看一遍。

9:02  Dana @Claude — Session 启动
9:02  Claude: "is thinking..." — 沙箱构建中
9:03  Claude 贴出 checklist:
        ✅ 拉 Datadog p99 延迟数据
        ✅ 对比 deploy 4f2c1 和 main 的 diff
        ⏳ 本地复现慢查询
        ⏳ 开 PR 修复
9:04  Sam 中途加入：「顺便查一下是不是和上周缓存改动有关？」
9:06  Claude: 已确认是 4f2c1 引入的 N+1 查询，PR #382 已开，CI 跑着

六分钟。从发现慢查询到 PR 开出。

周一早上，运营群里有人 @了运营 Agent：「帮我看看上周退款率为什么涨了」。

Agent 开始干活。它先查了 AI 表格里的退款明细，又调了客服工单系统的投诉分类，接着跑了一段 SQL 算出各渠道的退款占比，最后生成一份带趋势图的分析报告发到群里。整个过程 40 分钟，中间还主动追问了一句：「要不要把退款金额 > 500 的单独拉出来？」

报告质量不错。但安全团队事后审计时发现了三个问题：

1. Agent 查退款明细时，用的是 @它那个人的 App Token——这个人恰好是运营总监，有全量数据权限。群里其他人没有这个权限，但他们都看到了报告。
2. Agent 调工单系统时，用的是一个 写死在环境变量里的 API Key，这个 Key 的权限范围是 read:all，理论上 Agent 可以读任何人的工单。
3. 日志里只记了「运营总监访问了退款表」， 没有记录是 Agent 在执行。

这是一个典型场景，我在不同企业里见过不同程度的版本。

在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中，我讨论了 Agent 为什么需要自己的身份。这篇接着往下走： 当 Agent 进入钉钉群，权限、凭证、审计这套架构具体怎么设计？

周一早上九点，小林到了客户的运营部。

他不是来做产品演示的，也不是来签合同的。他的工牌上写的是「Forward Deployed Engineer」——一个在钉钉内部新设立的岗位，外部还没有对应的职称。

上周客户提了一个需求：「每天有 20 个人整理会议纪要，能不能用 AI 提效？」

普通工程师听到这句话，想到的是做一个会议纪要工具。

小林想到的是：

会议
    ↓
纪要
    ↓
任务拆解
    ↓
责任人
    ↓
审批
    ↓
提醒
    ↓
知识沉淀

他要做的不是一个纪要工具，而是一个 会议 Agent。