Agent-Skill

岗位真实，人名与数据已脱敏。这是一篇可以被复制的实践——文末有千问办公实操路径。

我是某条业务线的一号位，每周要向 CEO 汇报商业化、产品与组织三条线的进展。10 位直接下属，周报形态五花八门——有人发长文消息，有人甩一个文档链接，有人发文件附件；同一个指标，业务线和 BI 各有一个数，谁也不服谁。

上周日，我第一次让 AI 同事全程接管这件事。没有 SOP，没有模板，纯靠对话指挥：一个个群、一个个单聊地读，一份份总结、比对、入稿。从早到晚干了三个多小时，周报是交出来了，token 烧了上亿。

贵，但值——因为做完之后，我让 AI 把整个过程复盘了一遍： 哪一步是固定动作？哪一步踩过坑？哪个数字要过谁的口径？ 然后把这些蒸馏成了一份 weekly-report 技能文档：固定坐标、模版结构、素材来源对应表、指标字典、历史教训，一条不落。

这周日，我只说了一句话：开始整理本周的周报。

AI 同事加载技能，按流程执行：读上周远端文档定结构、批量收集十个来源、报「已收/未交」清单、按字典压缩入稿—— 不到十五分钟，一份质量过关的周报草稿出来了，全是重点信息。

省下来的时间，我去做了真正值钱的事：写下业务、产品、组织面对客户与竞争的方向判断，预演 CEO 的追问，补上风险与决策请求，再把待确认的问题分发给责任人。下面是这份周报背后的五个细节。前四个发生在十五分钟里，第五个，是十五分钟和 AI 都替代不了的。

本文全部时间线与数字来自 2026-08-30 一次真实执行记录，可在本机数据库逐条复核。

昨天傍晚六点三十七分，我中断了一个正在跑的任务。

任务叫 wx post 376——一句话，AI 同事全套接管：把博客文章排版成公众号 HTML、钉钉投递、生成朋友圈文案、发到“数字员工协作群”让另一个 agent 转发到 X.com，最后驱动已登录的 Chrome 进公众号后台，把标题、正文、作者、封面、原创声明一项项填进编辑器存草稿。

它跑了四十分钟，干完了八成。然后，在原文链接设置成功后的第十四秒，会话被我中断，留下一份半成品草稿。

今天我对 AI 同事说了一句话：「回顾下处理 376 的整个过程，找出优化空间。」

它做了三件事：从本地数据库里挖出自己的完整执行历史，重建逐分钟时间线；找出六个优化点；当场把 Skill 改写为 v2.2.0。

这篇想写的就是这个过程给我的冲击——一个 Skill 里最值钱的不是流程，是翻车记录；而这份事故报告，可以不用人来写。

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