昨天一个校招生在钉钉上问我：「日报能不能让 AI 帮我写？我每天花 30 分钟凑那些东西，感觉像在演戏。」
我没有急着回答「能」或「不能」。因为这个问题的背后藏着一个更大的矛盾——
如果日报真的只是「写给主管看的汇报」，那让 AI 写完全合理，甚至应该让 AI 写。但如果日报的价值远不止于此，那用 AI 替代的可能恰恰是最不该被替代的部分。
问题不是「AI 能不能写日报」，而是： 在一个 AI 能替你写字的时代，人还应该写什么？
管理者的第一个 Agent Skill：Loop 工程实现每周重要事项进展汇总
Your first Agent Skill as a manager -- why loop engineering beats manual progress tracking
周五下午 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 的，接口层才是杠杆。
| 对比维度 | 手动汇总 | Agent Skill |
|---|---|---|
| 耗时 | 2-3 小时（经验估算） | Agent 运行约 10 分钟 + 人工审阅约 5 分钟（基于实际运行经验） |
| 覆盖率 | 高概率遗漏 1-3 人 | 16 人全覆盖，未回复显式标 ⚠️ |
| 可溯源性 | 凭记忆，无法定位原文 | 每条标注「单聊 MM-DD HH:MM」来源 |
| 扩展性 | 增加 4 人 = 多翻 4 个窗口 | 改 4 行映射表 |
| 一致性 | 受情绪/疲劳影响 | 相同输入 ≈ 相同输出 |
Loop Engineering：AI Agent 工程的第五层
From Prompt to Goal — the human defines the finish line, the agent finds the path
4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。