桌面端 Agent 应用使用手册

从 0 到 1 先用起来，从 1 到 100 把每次成功沉淀为可复用的工作系统，真正把 AI 变成生产力。

本手册适用于任何桌面端 AI Agent 应用（下文统称"Agent"）。不绑定具体品牌，凡具备"自然语言下达任务、本地自主执行、交付可用产物"能力的桌面 Agent，均可按本手册上手。

TASK        完成一个真实任务
  ↓
CASE        复盘成可复现案例
  ↓
WORKFLOW    沉淀 Skill 与自动化
  ↓
AI TEAM     组合成协作团队

国际主流产品

国内主流产品

怎么读这张表

• 别纠结选型，先跑通任务。产品之间的差距远小于"会用与不会用"的差距。本手册的方法（五要素任务说明、Skill 沉淀、连接器打通、自动化验收）在上述任何一款产品上都能落地。
• 关注三类能力：本地文件操作（桌面端的核心优势）、Skill/工作流沉淀（复用的关键）、连接器生态（打通云端系统）。三者在哪家产品上齐备，哪家就能承载你的工作系统。
• 概念可迁移。不同厂商对同一概念的叫法不同（Skill / 智能体 / GPTs / 工作流），但"把做法固化、按需加载、可复用可分享"的本质一致。学会一家，处处可用。

覆盖第 1–10 章：认识 Agent、安装登录、界面与工作区、第一个任务、Skill、专家团、连接器、IM 助理、外部 API 与自动化任务。读完后，你将拥有一个能稳定交付结果的 AI 工作台。

本篇的写法是"边读边做"：每一章都对应一个可以在当天完成的动作。不要只浏览概念——每完成一章，至少留下一个可复用的指令、模板或操作记录。这十个动作串起来，就是你未来那套 AI 工作系统的地基。

从"回答问题"到"交付结果"

传统 AI 助手陪用户聊天、回答问题、给出建议；桌面端 Agent 不一样——你用一句自然语言描述需求，它理解任务目标，在你的电脑上自主规划执行步骤，并交付可用产物。

授权之后，它可以读取和处理本地文件，完成批量文件处理、文档生成、表格分析、PPT 制作、多模态内容创作、行业调研、本地知识库构建等工作。对于复杂任务，它还能自主拆解步骤，通过多个智能体并行执行，减少你在不同工具、文件和任务之间反复切换的成本。

flowchart LR
    A[说清目标] --> B[读取授权资料]
    B --> C[拆解任务与选择工具]
    C --> D[执行并生成产物]
    D --> E[人工验收]
    E -->|不通过| F[指出问题并返工]
    F --> D
    E -->|通过| G[归档或发布]

举一个具体的例子：你可以直接告诉 Agent"分析这个文件夹里的销售数据，生成一份汇报 PPT"。它会自主读取相关文件、理解数据内容、完成分析和总结，并生成最终可以查看和修改的成果。整个过程中，你不需要手动上传每一个文件，也不需要一步一步告诉它下一步该做什么——Agent 面向的是完整的工作任务，而不是一问一答。

Agent 的核心能力拆解

把上面这段描述拆开，桌面端 Agent 的核心能力其实是三句话：

1. 听得懂人话：用自然语言下达任务，不需要学命令、学配置；
2. 能自主思考规划：把目标拆解成步骤，自己决定先做什么、用什么工具；
3. 真的能操作电脑：读写本地文件、调用工具、触发系统操作，最后交付文件而不是一段话。

为了完成不同类型的任务，成熟的桌面端 Agent 通常还提供一组扩展机制，本书后面会逐一用到：

与聊天机器人的三个本质区别

这张表也解释了为什么"会聊天"不等于"会干活"。交付物的形态变了——从一段要你自己复制走的文字，变成一份直接能用的文件；执行方式变了——从你推一下它动一下，变成它自己跑完全程、你只负责验收；与本机的关系变了——它第一次真正"住进"了你的电脑。

它能替你做什么：一张任务地图

授权之后，Agent 能承担的工作可以归为七类，每一类都给出了第一次尝试的建议：

新手的三个常见误解

刚接触 Agent 的人，几乎都会经历下面三个误解带来的失望。提前知道它们，能省掉很多"AI 不行"的错误结论：

三个误解的共同根源，是把 Agent 当成"一个更聪明的搜索引擎"。而它实际的定位是"一个需要管理的新同事"——能力不差，但需要你交代清楚、过程适度过问、成果亲自验收。

一个最小的心理预期

• 第一次用，先给一个小任务（整理一个文件夹、总结一份 PDF），不要一上来就托付核心业务。
• Agent 的产出是"高完成度的初稿"，不是免检终稿。验收环节永远属于人。
• 成本意识：任务越复杂、模型越强，积分或 Token 消耗越高。先小后大，先廉价模型试错，再切强模型定稿。

从今天开始积累的三样东西

读本章不需要动手装任何东西，但有三样"零成本资产"可以从今天开始攒，它们是后面九章所有沉淀动作的起点：

1. 一个演练目录：在电脑上建一个专门放"给 Agent 练手"的文件夹，今后所有新任务先在这里跑；
2. 一份指令库文件：建一个 指令库.md，每次写出一段好用的任务说明就存进去——第 4 章开始往里放第一条；
3. 一个提问习惯：每次对 Agent 的产出不满意时，先问自己"是我没说清，还是它没做到"，再决定怎么改。

这三样东西的共同点是：把"用过"变成"留下痕迹"。这本手册反复强调的主线——把成功沉淀为系统——就从这三个动作开始。

风险与人工关口

自主执行是 Agent 的价值来源，也是它的风险来源。针对本地文件操作、终端执行等场景，桌面端 Agent 普遍提供高危指令拦截和权限控制机制，降低自主执行过程中的风险。但要记住：机制兜底不等于免检，三条人工关口始终有效——

1. 授权关口：工作区给多大，Agent 就能摸多大（第 3 章展开）；
2. 计划关口：高风险任务先看它的执行计划，确认后再放行；
3. 验收关口：产物进入真实使用前，由人做最后判断。

认识这些边界，不是让你畏手畏脚，而是让你敢把越来越多的事交出去——因为你知道每一次交付都有把关的地方。这本书后面的所有章节，都在教你把"这一次做成了"变成"每次都能做成"。

本章验收：能用自己的话说清"Agent 和聊天 AI 的区别"，并举出一个你打算交给它的第一个小任务。

为什么要认真对待安装这一步

安装环节最容易被当作"点下一步"的过场，但桌面端 Agent 与普通软件不同：它会在获得授权后操作你的文件、读取你的数据、连接你的账号。安装阶段做出的三个决定——从哪里下载、授予哪些权限、绑定什么账号——决定了后面所有任务的安全基线。花十分钟把这一步做对，比事后收回权限省力得多。

安装流程

1. 从官网或可信渠道下载对应平台的安装包（Windows / macOS 注意芯片架构）；
2. 安装时留意系统权限申请：辅助功能、屏幕录制、文件夹访问，按最小必要原则授予；
3. 首次启动后完成账号登录与设备绑定；
4. 在设置中检查更新通道，保持最新版本。

四个步骤里最值得停下来的是第 2 步。权限弹窗出现时，逐条问自己：这个能力是马上要用的吗？不是的先不授予，等任务真正需要时再开。权限是一次性的决定、长期的风险敞口。

环境准备清单

下载前建议顺手做两件事：确认下载渠道是官方网站（对照产品官网公布的域名，警惕搜索结果里的仿冒站点）；确认安装包的芯片架构与你的电脑匹配（macOS 的 Apple 芯片与 Intel 芯片安装包不通用，装错了轻则无法启动，重则需要重装）。

首次登录与设备绑定

登录环节的要点是"账号即边界"：

• 登录后，你的任务历史、工作区配置、Skill 与连接器授权通常都挂在这个账号下，换设备时可以迁移；
• 设备绑定意味着这台电脑上的授权操作会关联到你的身份——不要把个人账号借给他人在本机使用；
• 如果产品支持多账号或企业账号，工作与个人用途建议分开，避免工作区的任务记录混入私人数据。

权限授予的最小必要原则

安装与首启阶段常见的权限申请，逐一给出建议：

原则一句话：权限跟着任务走，任务没了权限收。第 7 章讲的连接器授权、第 8 章讲的远程触发，都沿用这一原则。

常见安装问题排查

排查的总原则：先怀疑环境和渠道，再怀疑产品本身。九成"装不上、用不了"的问题出在前者。

安全底线

• 只从官方渠道下载，警惕二次打包的安装包；
• 登录凭证不要交给他人共用，工作区内的任务记录可能包含敏感数据；
• 企业环境先确认 IT 合规政策，再安装使用。

第三条尤其重要：不少企业对"AI 应用接触公司数据"有明确规定，先问 IT 再安装，比装完被要求卸载、迁移工作区成本低得多。

账号与数据的归属

安装阶段还有一个容易被忽略的问题：数据放在谁那里。理清归属，日后换设备、离职交接、处理异常时都省事：

两个实践建议：换电脑时，先迁移工作区目录、再在新设备上授权，顺序不要反；卸载应用前，先导出 Skill 清单与任务历史（如有导出功能），本地工作区另行备份。

更新策略

保持最新版本不是强迫症，而是安全习惯：版本更新通常包含权限机制修复与高危拦截规则升级，旧版本可能带着已知漏洞在操作你的文件。建议开启自动更新，或至少每月手动检查一次；更新后如果权限被重置，按本章的原则重新授予一遍，正好做一次权限体检。

安装完成检查清单

本章结束时，逐项确认：

• [ ] 应用从官方渠道下载，架构与本机匹配；
• [ ] 登录成功，账号归属清晰（个人/企业分开）；
• [ ] 权限按最小必要授予，多余的已拒绝或收回；
• [ ] 工作区指向专门目录，不是整个用户主目录；
• [ ] 版本为最新，更新通道已确认；
• [ ] 企业用户：IT 合规已确认。

六项全过，说明你的 Agent 运行在一个干净、可控的环境里。环境越干净，后面你敢交给它的任务就越大——这是本章给全书铺的第一块地基，也是"沉淀为系统"的前提：系统需要一个稳定的宿主。

安装、授权、登录——这些一次性决定做好之后，你的 Agent 就有了稳定、安全的运行环境。接下来的一切能力，都构建在这个地基上。

本章验收：应用安装成功、可正常登录，版本为最新；同时检查一遍已授予的权限清单，确认没有超出实际需要的授权。

认识三个核心概念

桌面端 Agent 与网页版最大的差异在工作区：它默认只能访问你授权的目录。这是安全边界，也是它敢于批量操作文件的前提。网页版 AI 想碰你的文件，你得一个个上传；桌面端 Agent 不需要上传，但代价是它获得了对授权目录的读写能力——所以授权范围的选择，就是你与 Agent 之间最重要的契约。

实践建议：给 Agent 建一个专门的工作目录（例如 ~/agent-workspace/），每次任务在里面开独立子目录。不要直接授权"桌面"或"文档"这种大杂烩目录——那等于把整个房间都交了出去。

主界面的四个区域

• 对话区：输入任务、观察执行过程（计划、工具调用、文件变更）；
• 产物区：预览生成的文档、表格、图片，可直接打开或分享；
• 任务列表：管理历史任务，可恢复上下文继续迭代；
• 能力区：管理 Skill、专家、连接器（后续章节逐一展开）。

四个区域对应一次任务的完整生命线：在对话区下达并观察，在产物区验收，在任务列表里追溯历史，在能力区里沉淀复用。第一次打开应用时，建议先各点一遍，不求记住功能，只求建立"东西都在哪"的空间感。

一个任务的生命周期

从界面角度看，一次完整的任务经历五个阶段：

下达 → 规划 → 执行 → 验收 → 归档
 │       │       │       │       │
 输入    出计划   调工具   看产物   入任务列表
 任务说明  可中断  改文件   可返工   可恢复上下文

关键认知："执行"不等于"完成"。Agent 报告执行完毕，只是它认为自己做完了；任务是否真正完成，取决于你在验收阶段的判断。验收不通过就指出问题让它返工——对话区支持多轮迭代，返工成本远低于人工重做。

对话区里观察什么

对话区不只是输入框，它是你了解 Agent 工作方式的窗口。执行过程中通常能看到三类信息，各有各的看头：

新手常犯的错是发完指令就去干别的——直到产物出来才发现方向早偏了。养成"发送后盯 30 秒"的习惯：看完它的计划再走，成本几乎为零，却能拦下大部分跑偏。

模式选择

多数桌面 Agent 提供三种模式，首次使用建议先在演练目录里各试一遍：

三种模式的本质是不同的信任预付额度：问答模式预付零信任（只动嘴不动手），计划模式预付一半（先看方案再放行），执行模式预付全部信任（直接开干）。选模式的判断依据很简单：这个任务搞砸了的代价有多大？代价越大，越往问模式和计划模式靠。

任务列表：你的执行台账

任务列表不只是历史记录，它是三类日常动作的入口：

• 恢复上下文：上周做过的任务，点开后补一句"按同样规则再来一次"，比重写指令快十倍；
• 对比迭代：同一任务的 v1、v2、v3 摊开对比，能清楚看到"我改了什么指令、结果好在哪里"；
• 追溯排查：产物出问题时，回到原任务查看它当时读了哪些文件、执行了哪些步骤。

用好它的关键是命名：默认任务名往往是一截指令开头，建议养成重命名的习惯——"1122-销售数据周报-v2"这样的名字，一个月后还能认出来。这看似琐碎，却是第 23 章复盘方法的基础设施。

产物管理：验收之后的事

产物验收通过，只是任务结束的一半；另一半是管理：

1. 留在原地：产物默认落在工作区子目录，保持"一个任务一个目录"的结构；
2. 版本标识：多轮迭代的产物带版本号（v1、v2），不要互相覆盖；
3. 择要归档：真正有复用价值的产物，归档到知识库目录（第 16 章），其余留在工作区自然沉淀；
4. 外发检查：分享给他人前，确认产物不含敏感或涉密信息，按公司规范选择共享范围。

工作区授权：安全边界的三条规则

1. 范围最小：一次任务只授权它需要的目录，任务结束可以收回或缩小；
2. 演练先行：新类型的任务先在演练目录（放几份不重要的样例文件）里跑，跑顺了再上真实数据；
3. 高危有拦截：主流桌面 Agent 对批量删除、覆盖、执行危险命令等操作有拦截机制，会要求人工确认——这类确认弹窗出现时，值得花十秒认真看，而不是条件反射地点"允许"。

理解了工作区，你就理解了桌面端 Agent 与本机关系的全部逻辑：能力被关在授权范围内，风险也被关在授权范围内。 后面第 7 章的连接器授权、第 8 章的远程触发，都是这一逻辑向云端和移动端的延伸。

首日练习：三问三答

界面熟悉不需要教程，用三个自问自答完成：

1. "我的工作区在哪？"——能立刻说出当前授权目录的路径，并知道怎么改；
2. "我上次的任务在哪？"——能从任务列表找到最近一次任务，并说出它的产物存在哪；
3. "我现在该用哪个模式？"——随手想一个今天的任务，能判断它该用执行、问答还是计划模式。

三问都能秒答，说明界面已经成为你的肌肉记忆，后面的章节可以专注在"怎么把任务做好"上。任何一问卡壳，回到对应的区域再点一遍。

本章验收：能指出对话区、产物区、任务列表的位置，并能解释"工作区授权"限制了什么。

创建一个任务的步骤

1. 点击"新建任务"；
2. 选择或创建独立工作目录（首次操作先在演练目录进行）；
3. 判断使用模式，默认为执行模式，高风险操作建议改为计划模式；
4. 选择模型——不同模型积分消耗不同，试错用轻量模型，定稿用强模型；
5. 输入任务说明；
6. 如有必要，指定 Skill、专家、连接器或资料库（本章先忽略）；
7. 发送后观察计划、工具调用和文件变更；
8. 在结果区预览产物并验收。

八个步骤里，第 5 步"输入任务说明"决定了这次任务质量的上限——后面的内容都围绕它展开。第 7 步提醒你：发送之后不要走开，观察 Agent 的计划与工具调用过程，是建立信任、及早发现跑偏的最好方式。

⚠️ 安全提示：桌面 Agent 采用文件夹级授权与高危拦截，但授权范围内批量移动、覆盖、删除仍需谨慎。处理真实业务数据前，先备份、先演练、先看计划。

如何写一个任务说明

很多"AI 做得不好"，根源不是模型不会做，而是人没把交付标准说清楚。任务说明要回答五个问题：

五要素的检验方法很简单：把任务说明读给一个不了解背景的同事听，他能不能不追问任何问题就开始干活？能，说明说明合格；不能，他追问什么，你的任务说明就缺什么。

示例：第一个任务（联网调研 + 生成报告）

第一个任务不依赖任何本地文件——新装的电脑上可能什么数据都没有，但 Agent 联网检索公开信息的能力随时可用。选一个你真实关注的话题，按五要素写一份任务说明：

目标：调研【一个你关注的话题，例如：主流桌面端 AI Agent 目前能完成
      哪些类型的任务】，产出一份可以直接转发给同事的调研简报。
输入：联网检索公开信息（官方网站、产品文档、权威媒体报道），
      不需要本地文件；以下背景信息供参考：【你的关注点、用途】
动作：检索 → 筛选信源 → 提炼要点 → 交叉验证关键事实 → 撰写成文。
约束：只使用公开信息；每条关键结论标注来源链接和发布日期；
      查不到可靠来源的信息明确写"未找到可靠来源"，不要编造；
      语言克制，不写营销式表述。
输出：交付《调研简报.md》，包含两部分——
      A. 五分钟速读版：3 条核心结论，每条一句话；
      B. 完整版：背景、现状梳理、主要方案对比、趋势判断、风险提示。

这份说明里五要素各就各位：目标说清了"给谁用、干什么"；输入用公开网页和对话中提供的背景；动作是完整的检索-验证-写作流程；约束重点堵住了"编造"这个调研类任务最大的坑；输出定义了文件名、结构和分层（速读版 + 完整版）。

发送后观察执行过程：Agent 会先给出计划，然后逐个检索、读取网页、汇总信息。如果发现它检索方向偏了，随时在对话区补充一句"重点看 XX 方面"——首次任务中途纠偏很正常，不算失败。

验收清单

• [ ] 产物存在且能打开；
• [ ] 数字能回到源文件核对（本例中：结论能回到来源链接核对）；
• [ ] 格式符合使用场景（投屏不溢出、字号可读；本例中：速读版确实 3 分钟能读完）；
• [ ] 原始文件未被意外修改；
• [ ] 抽查 3 条关键结论：来源链接可打开、日期有效、结论与来源内容一致；
• [ ] 没有查不到来源却写得言之凿凿的内容。

验收重点与任务类型匹配：文件处理类任务验收"数字对不对"，调研类任务验收"来源真不真"。把本例的验收方法留下来，它就是你在第 15、18 章要做的资讯整合与专业分析的雏形。

有本地文件时的典型升级版任务

当你的电脑里有了数据文件，第一个任务可以升级为"输入文件 → 输出报告"的经典形态，例如：

请分析工作区里的《电商销售数据.xlsx》：
1. 输出核心指标（总量、环比、TOP5 商品）；
2. 标出异常数据和可能原因；
3. 生成一份 8 页以内的汇报 PPT，风格正式，适合管理层汇报。
不要修改原始数据文件。

与联网调研任务的差别只在"输入"一栏：从公开网页换成本地文件，五要素框架不变。注意这条说明里的约束"不要修改原始数据文件"——文件类任务里，保护输入数据是最常被遗漏、也最重要的一条约束。

常见失败模式与修正

第一次任务不一定一次成功。失败是常态，关键是能定位原因。第一任务的失败几乎都落在下表五种模式里：

注意修正的指向：前四条都在改"人这边"的输入，只有最后一条在改流程。这与第 1 章的结论一致——多数"AI 做得不好"，先检查任务说明是否说清了。

第一个任务之后：留下点什么

任务验收通过后，别急着关窗口。按顺序做三个小动作，总共不超过五分钟：

1. 存指令：把这次的任务说明另存进"指令库"文件，并在末尾补一行"下次可改进：____"；
2. 命名任务：给这次任务起一个"日期-主题"的名字（第 3 章的习惯），一个月后还能找到它；
3. 判断复用性：问自己一句"这类任务我每周会遇到吗？"——会，它就是第 5 章 Skill 和第 6 章专家的候选种子。

这些动作很小，却是本书主线"把成功沉淀为系统"的第一步——第 23 章的任务卡、第 22 章的 Skill 蒸馏，都是从这一行记录长出来的。第一个任务的价值从来不只是那份产物，而是它帮你跑通的那条"下达 → 执行 → 验收 → 沉淀"的完整路径。

本章验收：完成一个"输入文件 → 输出报告"的完整任务（或本例的联网调研任务），并按上面清单走一遍验收。

Skill 是什么

Agent 本身负责理解任务和组织执行；Skill 是一组可复用的说明、脚本、参考资料和资源，告诉 Agent 某类任务应该怎样做、调用什么工具、交付什么格式。

更准确地说，Skill 不只是提示词，也不是简单的脚本，而是经验 + 知识 + 执行路径的封装体：把领域专家的做法、判断规则和踩坑记录固化成一个可复用的单元，供 Agent 在任务执行中调用。它的核心公式是：

好的 Skill = AI 能力 × 业务深度 × 真实反馈持续迭代

三者的乘法关系意味着：缺任何一项，Skill 的价值都会急剧衰减——只有 AI 能力没有业务深度，产出空洞；有业务深度但从不迭代，很快过时。

一个标准的 Skill 是一个文件夹，只有 SKILL.md 是必须的：

my-skill/
├── SKILL.md          # 必须：名称、描述、工作流程
├── scripts/          # 可选：可执行脚本
│   └── check.py
├── references/       # 可选：参考资料
│   └── guide.md
└── assets/           # 可选：模板等资源
    └── template.pptx

SKILL.md 的最简写法：

---
name: tech-article-writing
description: 用于撰写 AI 产品、模型评测和科技行业相关文章
---

收到写作任务后：
1. 先确认文章核心角度
2. 查找一手资料
3. 对核心事实交叉验证
4. 根据用户写作风格完成初稿
5. 检查禁用句式和 AI 味表达

Skill 是怎么工作的：渐进式披露

假设你的 Agent 装了 100 个 Skill，它不会把 100 份完整内容全部塞进上下文。标准做法分三层：

1. 启动时：只加载所有 Skill 的名称和 description（数十至上百 Token）；
2. 匹配时：Agent 根据 description 判断某个 Skill 与当前任务相关，才加载完整 SKILL.md；
3. 执行中：需要参考资料或脚本时，才继续按需读取。

所以 Skill 解决了一个长期困扰 Agent 的问题：怎么给 Agent 很多知识和工作方法，又不把所有东西永远塞在 Prompt 里。

渐进式披露也决定了参考文件的组织原则——一层直达，避免深层嵌套引用：

• 不良示例：SKILL.md → advanced.md → details.md（多层转引，信息可能在传递中被截断遗漏）
• 良好示例：SKILL.md 直接链接 basic.md / advanced.md / reference.md / examples.md

原则：参考文件保持一层深度，让 Agent 一次就能完整读取目标文件，减少遗漏风险。

Skill 跟 Prompt 的区别

最简单的理解：Prompt = 任务，Skill = 做法。

Skill 的四个作用

• 补充程序性知识：模型知道 SQL，但不知道你公司那张表的口径——这类私有知识最适合做成 Skill；
• 固定复杂工作流：把行业调研的七步流程固化下来，不用每次重新思考"先查什么、怎么验证"；
• 减少重复指令："不要 AI 味、长短句结合、要有判断"这类反复说的话，天然适合做成风格 Skill；
• 经验资产化：Skill 是文件，可以版本管理、团队共享、持续迭代。

好 Skill 的五个特征

不是所有流程都值得做成 Skill。一个高质量的 Skill 应具备五个要素：

场景越真实，Skill 越可靠。 最有价值的 Skill 不是从技术文档里推导出来的，而是从业务一线每天被问得最多的问题里长出来的——业务天天在喊痛，AI 能力就天天在长。

怎么造一个 Skill：先实践，再沉淀

不要等流程完全想清楚了再写 Skill。推荐的创建路径是：先让 Agent 执行任务，通过对话反馈和调试优化，再沉淀成 Skill：

Agent 执行任务 → 对话反馈 → 调试优化 → 真实任务验证（跑 1-2 次）→ 沉淀为 Skill

这条路径尤其适合流程未清、需要试错、容易踩坑的场景。动手写之前，先完成四步校准：

1. 定义输出：输出长什么样——格式、内容、用途；
2. 反推输入：数据从哪里来——输入是否齐全、准确、可用；
3. 梳理 SOP：步骤怎么编排——参照最佳实践，必要时请专家补位；
4. 定义验证：怎么才算好——定性定量标准、验收方式。

四步到位的标志：输出清楚、输入可靠、流程可执行、标准可验证。

Skill 的四层能力分层

按从工具调用到个性化决策，Skill 可以分为四个层级——越往上，越贴近真实任务和个人偏好：

对应的架构决策还有两条：

• 低频与高频知识的分工：低频知识（稳定、长期不变的通用规则和方法论）内置到 Skill；高频变化的知识（实时数据、政策、价格）通过脚本动态获取——避免 Skill 刚写完就过时。
• 设置适当的自由度：根据任务脆弱性匹配指令的具体程度——

把 Skill 装进任务：装配能力

真正能落地的 Agent，需要把知识、Skill、工具和权限装配到同一个任务里。装配能力，是让 Agent 从"会说"变成"能做"的关键一步：

• Skill 注册与发现：让 Agent 知道有哪些 Skill 可用；
• 工具选择：为 Skill 绑定所需的工具能力（CLI / API / MCP）；
• 凭证选择：配置访问权限；
• 上下文策略：定义任务执行时注入哪些上下文。

对于高风险或批量操作型任务，把执行拆成「计划-验证-执行」三步：

分析任务 → 生成结构化计划(changes.json) → 脚本验证计划
→ 执行更改 → 结果复验 → 输出结果

这样做的价值：错误在真正改动前就被拦截；计划可以被脚本机器校验（比肉眼可靠）；保留计划文件便于回滚；出问题时定位更快更准。

维护一个 Skill：每次修改都要跑 Evals

Skill 不是写完就结束。每次修改，都要跑一遍评估集（Evals），形成质量闭环：

真实任务样本 → 评估集与评分规则 → 修改后离线评估 → 质量门禁
→ 通过：小流量上线 → 收集线上反馈
→ 未通过：错误分析与修正 → 回到版本迭代

评估集来自真实任务样本，作用是防止 Skill 改着改着，旧问题又复发。配套的模型选择策略也很简单：创建期用强模型（深度理解、高质量沉淀），使用期普通模型即可（成本可控、效率平衡）。关于如何从跑通的案例中蒸馏 Skill，第 22 章有完整的迭代方法。

安装与使用

• 从内置技能市场搜索，或用"查找技能"描述需求；
• 支持导入本地 zip 技能包；
• 使用时通常通过 / 唤出技能列表，或让 Agent 根据任务自动匹配；
• 不再需要时可关闭或卸载。

Skill 健康度判断：六个关口

一个 Skill（或基于它的工作流）是否值得投入，用六个关口检验，任何一关失守，都不能算健康项目：

1. 客户愿付费：有人愿意为这个 Skill 的价值买单；
2. 问题值得解决：解决的是真实痛点，不是自嗨；
3. 条件允许落地：数据、权限、风险都在可控范围内；
4. 结果可以验收：有明确的验收标准和评测方式；
5. 用户真正采用：使用者愿意在日常工作中持续使用；
6. 能够复制并盈利：经验可以沉淀为可复用资产。

一图总结：Skill 开发与落地的六阶段

① 发现            ② 创建            ③ 装配
识别真实痛点      定义输出/输入      注册与发现
确定高价值用途 ──→ 梳理SOP/验证  ──→ 绑定工具
划清边界条件      先实践再沉淀      配置权限/注入上下文

④ 运行            ⑤ 评估            ⑥ 复用
CLI/API/MCP       建立评测集        抽象为模板
打通业务系统   ──→ 每次修改跑Evals──→ 种进知识库
人工确认兜底      错误分类归因      跨场景复制/产品化

Skill 开发与落地的本质，是把一线业务经验通过标准化的工程方法固化为可复用的数字资产。它不是一次性的编码工作，而是从业务中生长、在实践中迭代、在复用中增值的持续过程。

本章验收：安装一个与你工作相关的 Skill 并完成一次任务，对比"裸 Prompt"和"带 Skill"的产出差异；再用四步校准法给自己要做的 Skill 写一张校准卡。

从 Skill 到专家

如果说 Skill 是"做法"，专家就是"人格化的做法"：一个专家 = 角色设定 + 一组 Skill + 常用资料 + 默认工具偏好。专家适合长期承担某一类职责，而不是一次性任务。

三者的关系可以这样理解：Skill 回答"这类事怎么做"，专家回答"谁长期负责做这类事"，专家团回答"一件复杂事怎么分工"。日常使用中你接触最多的是前两者；专家团在第 24 章展开，这里先建立概念。

创建一个自己的专家

创建专家通常只需要回答三个问题：

1. 职责：它长期负责什么（例：周报整理、客户研究、内容排版）；
2. 装备：绑定哪些 Skill、资料库、连接器；
3. 规矩：语气、格式、禁用事项、必须由人确认的环节。

创建入口一般在"专家 → 我的专家 → 创建"，按给定格式填写即可。三个问题可以套进一张"专家卡"，填完即创建：

【专家卡】
名称：周报整理官
职责：每周五汇总本周任务记录与产物清单，生成部门周报初稿
装备：
  - Skill：周报模板 Skill、文档格式 Skill
  - 资料库：团队 OKR 目录（只读）
  - 连接器：云盘（读取本周新增文件）
规矩：
  - 语气：客观克制，只写事实与数据，不写形容词
  - 格式：固定周报模板，先结论后细节
  - 禁止：不引用资料库以外的信息，不评价个人表现
  - 人工关口：涉及对某人工作的量化评价，标注"待确认"

注意"规矩"一栏的最后一条——必须由人确认的环节要显式写出来。专家是长期角色，它的规矩会在你不在场时也生效，所以风险边界必须一开始就写清，而不是出事后再补。

先用预置专家跑通场景

多数桌面 Agent 自带一批预置专家，覆盖常见职场职责。自建之前，先把它们用起来——既能快速验证"专家"这个形态对不对你有用，也能学到官方是怎么写角色设定的：

用预置专家的正确姿势：给它一两个真实小任务，观察它的默认规矩（语气、格式、追问方式），记下"差在哪"——这些差距就是你自建专家时要写进"规矩"一栏的内容。

使用建议

• 先用系统预置专家跑通场景，再自建；
• 专家越聚焦越好用，"全能助理"型专家往往样样疏松；
• 给专家明确的交接物标准（输出什么文件、什么结构），比给一堆形容词有效。

第三条值得展开：给专家定标准时，"要专业、要有深度"这类形容词几乎不产生约束力，"每次交付一份 300 字以内的摘要 + 一份结构化清单"才产生约束力。检验标准写得够不够好，就看换一个人（或换一个会话）执行时，产物是否还长得一样。

什么时候用专家，什么时候直接说

专家不是所有任务的默认入口。用不用专家，看任务的出现频率和固定程度：

一个简单的记账法：当你发现自己第二次输入几乎相同的指令时，就该考虑专家了；第三次还在输入，就是明确信号。

专家的迭代：像带新人一样带它

专家创建后不是一成不变的。每完成一次任务，把两样东西写回专家设定：一是这次发现的偏好（"周报数据一律保留一位小数"），二是这次踩的坑（"不要把内部代号直接写进对外摘要"）。这跟带一个新人的过程完全一样——区别在于专家不会离职，你教的每一条都会一直生效。当某个专家的规矩越攒越多，说明该把它拆成更聚焦的角色了。

使用专家的日常动线

专家建好后，日常使用是这样的：

平时：同类任务直接 @该专家下达（或让 Agent 自动匹配）
      ↓ 产物合格 → 直接使用，什么都不用做
      ↓ 产物有偏差 → 一句话纠正 + 把纠正写回专家的"规矩"
每月：扫一眼专家清单——还在用吗？规矩过时了吗？该拆分了吗？

这条动线里唯一需要刻意维护的动作是"写回规矩"。三个月后你会发现，一个被持续写回的专家和一个建完就不管的专家，产出稳定性差距巨大——前者越来越像一位真正的老同事，后者始终是个记性差的新人。

风险与人工关口

• 权限随装备走：专家绑定了哪些资料库和连接器，它就能摸到哪些数据，创建时按最小必要配置；
• 长期角色的惯性风险：专家的规矩会持续生效，过时的规矩（比如已废弃的模板）要定期清理；
• 署名与责任：专家产出的内容由你对外负责，外发前的人工审核不能省。

专家是把 Skill 从"一次任务的加速器"升级为"一个长期岗位"的方式——你的第一个专家，就是未来那支 AI 团队的第一名成员。

本章验收：创建一个自己的专家，并连续三天把同类任务交给它，观察产出稳定性。

连接器解决什么问题

Skill 让 Agent"会做事"，连接器让 Agent"够得着事"——邮件、日历、云盘、IM、在线文档、项目管理工具，这些数据在云端账号里，没有连接器，Agent 就是一个只能摸本地文件的孤立助手。

考虑一个典型的工作日：待办在项目管理工具里、会议在日历里、材料在云盘里、沟通在 IM 里。没有连接器时，你得自己把这些信息搬运给 Agent；有了连接器，Agent 可以直接读日程、拉材料、查状态，完成跨系统的整合任务。

连接器背后的协议：MCP 是什么

多数现代连接器建立在 MCP（Model Context Protocol，模型上下文协议）之上——一个由 Anthropic 于 2024 年底推出并开源的行业标准，现已成为 AI 工具生态的基础设施之一。用一个通俗的比喻：MCP 就是 AI 世界的"USB-C 接口"。

它解决的是集成复杂度问题。在过去，让 AI 应用连接外部工具（代码托管、数据库、IM、办公套件），开发者必须为"每一个 AI 应用"和"每一个工具"分别编写对接代码：10 个应用 × 10 个工具 = 100 个接口（N × M 的集成噩梦）。有了 MCP，工具方只需按标准开发一个"MCP Server"（相当于 USB-C 设备），任何支持 MCP 的应用内置"MCP Client"（相当于 USB-C 接口）即可即插即用，复杂度从 N × M 降为 N + M。

MCP 标准化了三种核心能力，正好对应 Agent 连接外部世界的三类动作：

两个对使用者重要的特性：一是解耦——你可以随时更换底层模型或增删数据源，不用推倒重来；二是本地优先——MCP 支持通过本地标准输入输出（stdio）或本地 HTTP 通信，MCP Server 可以完全跑在你自己的电脑上，敏感数据不需要上传到云端第三方服务器，模型只在需要推理时获取必要上下文。这正是连接器能做到"够得着事"又不至于"什么都交出去"的技术底座。

常见连接器类型

选择从哪个连接器开始，标准只有一条：哪个工具里的数据你每天都要用。高频邮箱就先接邮件，重度日历用户就先接日历——连接器的价值与数据的使用频率成正比。

接入与使用流程

以接入一个会议连接器为例，典型流程是四步：

1. 打开"连接器"管理页，从支持列表中找到目标服务；
2. 走完 OAuth 授权（跳转到服务方页面、登录、确认授权范围）；
3. 回到 Agent，先用一条简单指令验证连通性，例如："帮我创建一个明天下午 3 点的会议，主题'项目讨论'，时长 1 小时"；
4. 验证成功后，把该连接器组合进日常任务（如"读明天日程 + 汇总相关邮件 + 生成会前简报"）。

如果官方列表里没有你要的服务，多数桌面 Agent 还支持自定义连接器：在连接器管理页选择"自定义连接器"，按引导配置 MCP 服务（服务地址、鉴权方式），访问范围由你自己设定。这意味着：只要目标系统提供 MCP Server 或开放 API，你的 Agent 就能连上它——连接器的边界不再由厂商预置列表决定。

一个完整例子：会前简报

把"连接器够得着事"落到实处。假设你明天有一个跨部门评审会，接入日历、邮件、云盘三个连接器后，一条指令就能完成全部准备：

我明天 10 点有一个评审会（见日历）。
请帮我准备会前简报：
1. 读取该会议的日程信息（时间、参会人、主题）；
2. 检索我最近两周与参会人的相关邮件往来，摘出未闭环事项；
3. 在云盘「评审材料」文件夹中找到本次评审相关文档，
   各给三句话摘要；
4. 汇总为一份《会前简报.md》：会议信息、背景摘要、
   未闭环事项、建议提前阅读的材料清单。
只读取，不发送任何邮件，不修改云盘文件。

注意最后的约束条款：只读、不外发——第一次使用连接器组合时，把动作限制在读取和汇总，等对它的行为有把握了，再逐步放开"帮我发会议通知"这类写操作。这条指令跑顺后，它就是第 17 章会议工作流的会前环节。

连接器解锁的典型任务

单个连接器的价值有限，连接器真正的杠杆在于组合成日常任务。以下是四类已被反复验证的高频组合：

这些任务形态的共同点：数据在多个系统之间流动，人做搬运工，Agent 做整合者。你可以在第 15 章（资讯）、第 17 章（会议）看到它们的完整展开。

连接器故障排查

授权与安全

• 连接器授权遵循最小必要：只授予要用的能力，不用就断开；
• 区分"只读"与"可写"：先接只读，跑顺后再放开写权限；
• 外发类操作（发邮件、发群消息、写回业务系统）建议保留人工确认关口；
• 定期检查授权列表，清理不再使用的连接。

这四条与第 2 章的本地权限原则一脉相承，但风险等级更高：本地权限越界最多动你一台电脑的文件，连接器越界可能以你的身份向外部发消息、改业务系统数据。所以"只读先行、写操作留人工关口"这两条，建议当作硬规则执行，不当作可选建议。

从单个连接器到连接网络

单个连接器解决"够得着一个系统"，多个连接器组合才产生真正的杠杆——"日历 + 邮件 + 云盘"拼出会前简报，"项目管理 + IM"拼出状态同步。当你发现某几个连接器总是组合出现在同一类任务里，就是把这组组合沉淀进专家或 Skill 的时机（回到第 5、6 章的装配能力）。连接器是管道，管道之上长出来的工作流，才是你的系统资产。

本章验收：接入一个你最高频使用的办公工具连接器，让 Agent 完成一次跨系统任务（如"读取日历明天日程 + 汇总相关邮件 + 生成会前简报"）。

为什么要接入 IM

桌面 Agent 的短板是"人不在电脑前"。把 Agent 接入 IM（或小程序、手机端助理）后，你可以远程下达任务、接收结果、拍板决策——把碎片时间变成指挥时间。

典型场景：通勤路上想到一个方案要改，地铁里发一句话，到公司时修改稿已经在云盘里；出差途中同事要一份数据，你在机场 @一下机器人，两分钟后结果回到群聊。桌面端负责执行，移动端负责指挥——两者结合，Agent 才真正覆盖了你的完整工作时间。

典型形态

• IM 机器人：在群或私聊中 @机器人 下达任务，产物回传到聊天或云盘；
• 移动助理：手机端查看任务进度、审批关键节点；
• 定时推送：自动化任务的结果推送到指定会话（见第 10 章）。

三种形态对应三种使用姿态：IM 机器人是"随口指挥"，移动助理是"盯着进度"，定时推送是"被动接收"。第三种最容易被低估——它把第 10 章的自动化任务变成"每天自动出现在你手机上的工作简报"，是后面第 15 章资讯整合的交付通道。

接入步骤

把 Agent 接入 IM 通常是一条引导流程，四个环节逐一确认：

1. 绑定渠道：在桌面端设置中找到 IM/移动端入口，按引导完成绑定（扫码或授权）；
2. 配置可见范围：决定机器人在哪个群、对谁可见——建议先只绑自己，跑通后再进群；
3. 发送测试指令：在手机上发一条简单任务（如"工作区里有哪些文件"），验证链路通畅；
4. 打通产物回传：绑定云盘或确认文件回传方式，否则大文件只能以链接形式回来。

第 2 步值得强调：先私聊、后进群。私聊阶段暴露的问题（指令格式不兼容、产物太大回传失败）不会让同事看到，试错成本最低。

远程使用的工作流

手机下达任务 → 桌面端 Agent 在授权工作区执行 → 产物存到云盘
→ IM 推送结果链接 → 人在移动端预览、反馈、确认

这条链路成立的前提是三件事各自就位：手机端能触达 Agent（IM 接入）、桌面端在执行（授权工作区）、产物能回来（云盘或聊天回传）。缺任何一环，远程指挥就会断在半路——所以本章的动手内容，就是把这三环逐一打通。

远程指挥的指令写法

远程指令比桌面端指令更要"自包含"——你没有屏幕可以边看边纠偏，指令必须一次说清。参考模板：

@Agent 请重新生成昨天的周报，规则不变：
1. 数据源：工作区 reports/ 目录下最新的日度数据；
2. 输出：沿用上周模板，存到云盘"周报"文件夹；
3. 完成后把链接发到本群，并 @我。
如果找不到数据或模板，直接在群里说明缺什么，不要自行替代。

三个要点：指明数据源（远程无法现场指文件）、指定交付方式（存哪里、通知谁）、定义失败行为（缺什么就说什么，不许自行替代）。第三条最重要——远程任务失败时，你需要的是明确的失败报告，而不是一份悄悄降级过的产物。

把自动化接进 IM

IM 接入的第 10 章用法是最省心的一种：你什么都不用做，每天在固定会话里收到自动化任务的产物。配置要点只有三个：

1. 在自动化任务的"交付"一栏，把通知渠道指向你与 Agent 的会话（先私聊，不进群）；
2. 产物本体存云盘、消息里只发链接——IM 里发大文件既占空间又难检索；
3. 消息模板里带一句"如需调整回复本消息"——让你能顺手迭代。

这样做完，你的手机每天会准时出现一份自己生成的简报。看起来只是省了几分钟，真正的意义在于：这是第一条不需要你触发、也不需要你在场的完整工作流——从这一刻起，你运营的不再是一个工具，而是一个系统。

远程指挥的典型场景

远程场景与桌面场景的重心不同：桌面端重在"执行与迭代"，移动端重在"指挥与拍板"。四类最适合移动端的动作：

注意这些指令的共同点：都建立在一个已跑通的任务之上。远程不适合从零开始定义新任务——那需要多轮试错，是桌面端的活。

移动端的人工关口

远程链路让"人确认"这个动作也搬到了手机上，两个使用建议：

• 审批即拍板：桌面任务遇到高危确认时，推送会到达手机，点一下即可放行——但正因为太方便，更要看清楚确认的是什么再点；
• 超时宁可取消：如果产品支持设置审批超时策略，选择"超时自动取消"而不是"超时自动通过"。漏掉一次确认的代价，通常小于一次误放行。

安全提醒

• 远程指令同样受工作区授权约束，不要为了方便扩大授权范围；
• 群聊中使用注意信息可见范围，产物含敏感信息时改为私聊回传；
• 高危操作（删除、外发、支付类）建议关闭远程触发。

第三条展开一点：远程触发意味着任何能进入该 IM 会话的人，都可能以你的身份指挥 Agent。所以 IM 通道本身要有访问控制（群成员管理、机器人可见范围），谨防他人冒充指令；涉及"删除、外发敏感文件、支付类"的操作，直接在设置里关闭远程触发能力，只允许在桌面端、由你本人确认后执行。

再补一条经验法则：远程链路上，能私聊就不进群。群聊里机器人的每一次回复都是公开的，一次误发敏感产物，撤回未必来得及。等你对产物的敏感度控制有十足把握，再把机器人引入工作群，并明确约定它在群里只发链接、不发正文。

远程能力的边界

远程接入让 Agent 的可用时间从"坐在电脑前的 8 小时"扩展到"醒着的全部时间"，但边界依然清晰：远程适合下达、验收、拍板，不适合精细操作——需要多轮看图调整的排版、需要对照源文件核对的数据分析，还是回到桌面端做。远程指挥 + 桌面执行 + 定时推送，三者组合起来，你的 Agent 就初步具备了"系统"的形态：不依赖你在场也能运转。

本章验收：在手机上给桌面 Agent 下达一个任务，并在移动端收到结果。

什么时候需要 API

当 Agent 需要的数据或动作既不在本地、也不在内置连接器覆盖范围里——私有业务系统、第三方数据服务、自建工具——就需要接入外部 API。

判断方法很简单：想清楚这个任务需要的信息或操作在哪里。在本地文件里，用工作区；在主流云服务里，用连接器（第 7 章）；都不在——公司内部系统、小众数据服务、自己写过的工具——那就是 API 登场的场景。第 7 章的 MCP 是"标准化的连接器"，本章的 API 接入是"没有现成连接器时的通用解法"。

三种接入方式

三者的关系是投入递增、复用性递增：直接调用最快，适合验证"这个 API 有没有用"；一旦确认要长期用，就值得封装成 MCP 服务或 Skill，让它变成第 5 章讲的那种可复用资产。推荐路径：先直接调用跑通，再逐步固化。

接 API 前的决策清单

接入外部 API 之前，用五个问题确认值不值得做、能不能安全地做：

• [ ] 连接器列表里确实没有这个服务了吗？（有就用连接器，成本更低）
• [ ] 这个 API 有正式文档吗？（端点、参数、返回结构、错误码）
• [ ] 调用频率限制清楚吗？任务的调用密度会不会触线？
• [ ] 密钥能放进应用的密钥管理或环境变量吗？
• [ ] 这个接口是只读的还是写入的？写入类的人工关口想好了吗？

五问都过关，再进入下面的步骤；任何一问存疑，先解决那一问。尤其是第一问——很多人绕过连接器直接接 API，最后发现官方早就支持了。

最小可行步骤

1. 准备 API 文档（端点、参数、返回结构）和密钥；
2. 把密钥配置在安全位置（环境变量或应用的密钥管理，不要明文写进对话）；
3. 告诉 Agent："这是 X 服务的 API 文档，帮我查询 Y"；
4. 观察它的调用与解析，逐步固化到 Skill。

第 3 步的实际指令可以是这样：

这是【服务名】的 API 文档（附文档链接或文件）。
请帮我查询：【具体数据，如"上海未来三天的天气"】。
要求：
1. 先读文档确认端点与参数，再发起调用；
2. 返回结果整理为简明表格；
3. 如果调用失败，报告具体的错误码和原因，不要猜测结果。

Agent 会自己读懂文档、拼装请求、解析返回——这正是它比传统自动化工具省力的地方：你不需要写胶水代码，只需要给文档、说清要什么。

示例：一次查询任务的全过程

以"查询某城市未来三天天气"为例，走一遍完整过程，看 Agent 实际做了什么：

你的指令：这是天气服务的 API 文档（附链接），
          查询上海未来三天的天气，结果整理成表格。

Agent 的动作序列：
① 读取文档 → 找到"逐日预报"端点，确认参数（城市代码、日期范围）
② 处理鉴权 → 从环境变量读取密钥，拼装请求头
③ 发起调用 → 请求成功，拿到 JSON 返回
④ 解析整理 → 提取日期、温度、天气现象，渲染成表格
⑤ 交付 → 表格 + 一句"数据来源：X 服务，查询时间：____"

整个过程你只出了一句话。但注意第 ⑤ 步——让 Agent 养成标注数据来源和查询时间的习惯，这是 API 类任务可信度的关键：数据是实时的，不标注时间，三天后没人分得清这份表格是新是旧。

接入之后：从一次调用到一个 Skill

单次调用成功只是起点。观察 Agent 这次的调用过程：它读了文档的哪些部分、怎么处理鉴权、怎么解析返回结构——把这套做法固化进一个 Skill（调用端点、参数约定、结果解析规则、常见错误处理），下次同类需求就不再需要重新给文档。这是第 5 章"先实践，再沉淀"路径在 API 场景的具体应用：API 是接口，Skill 是对接口用法的企业级记忆。

常见的坑

第五个坑最隐蔽也最危险：Agent 面对 API 报错时，可能顺着惯性生成一段"看起来像结果"的内容。把"失败必须如实报告"写进指令和 Skill，是 API 类任务的保命条款。

安全底线

• 密钥一旦发进对话就可能被记入任务历史，优先使用应用的密钥管理功能；
• 只读接口先行，写接口（下单、发布、转账类）必须留人工确认；
• 企业内部 API 先过安全审批。

三条中第一条最容易踩：把密钥直接粘贴进对话框很方便，但任务历史可能被保存、被同步、被他人在授权下查看——密钥进了历史就等于换了把锁。正确做法是把密钥放进环境变量或应用的密钥管理，对话中只引用变量名。第三条则提醒：企业内部 API 背后往往是核心业务数据，接入前的安全审批不是流程障碍，而是让你在出问题时有人兜底。

最后明确一条责任边界：API 接错了、数据取错了，责任在使用者，不在 Agent。Agent 只是按你给的文档调用——所以文档版本、接口语义、返回字段的核对，是你在接入前必须亲自完成的家庭作业。

本章验收：让 Agent 通过一个外部 API 完成一次查询类任务，并把调用方法沉淀进一个 Skill。

从"随叫随到"到"主动干活"

前面所有任务都是人触发的。自动化任务让 Agent 按时间表或事件自己开工：每天早上九点的资讯日报、每周五的周报汇总、文件一落地就启动的处理流水线。

这是 Agent 使用的分水岭：此前你是"使用者"，任务由你发起；此后你是"运营者"，系统自己运转，你负责维护与抽检。也是从这一章起，前面各章的能力开始合流——自动化任务的执行体通常是 Skill（第 5 章），数据来自连接器（第 7 章），交付走 IM 推送（第 8 章），必要时调用外部 API（第 9 章）。

自动化任务的三要素

三要素中"触发器"决定它何时干活，"交付"决定你如何知道它干了——而执行体的质量决定这一切是否值得。一个不稳定的执行体被自动化后，只是把一次性的错误变成每天重复的错误。所以下面创建步骤的第 1 步（先手动跑通）不可跳过。

创建一个自动化任务的步骤

1. 先以手动方式把流程跑通至少 3 次，确认稳定；
2. 把指令固化为 Skill 或标准 Prompt（自动化里没有机会中途追问，指令必须自包含）；
3. 创建定时/触发任务，绑定工作区与通知渠道；
4. 先低频试运行（如每天一次、只通知自己），观察一周；
5. 再提高频率、扩大交付范围。

第 2 步的"自包含"是自动化指令与普通指令的核心区别。手动任务里，Agent 遇到模糊处可以问你；自动化任务运行时你不在场，所以指令必须预先回答所有可能被追问的问题：数据从哪来、格式什么样、缺数据怎么办、产物存哪里、通知发给谁。写完指令后自查一遍：如果这条指令在凌晨 3 点无人值守时执行，每一步它都知道该怎么做吗？

一个可直接套用的自动化指令模板：

【每日资讯简报】
触发：每天 09:00
执行：
1. 抓取以下信源的最新更新：【信源清单】；
2. 按标准筛选：【筛选标准，如相关性、重要性、可行动性】；
3. 生成简报：每条 = 标题 + 三句话摘要 + 原文链接 + 一句话点评，
   不超过 15 条，按重要性排序，标出需要立即行动的条目；
4. 存到云盘「简报」文件夹，文件名带日期；
5. 推送到【IM 会话】，并 @我。
异常处理：信源抓取失败时，在简报末尾注明"以下信源今日未获取"，
不要静默跳过；全部失败时，仅发送失败原因说明。

触发器的三种选择

定时的关键是频率克制——从每天一次开始，不要一上来就每小时一次。事件触发则要注意防抖：同一事件重复到达时（同一封邮件被同步两次），任务不应重复执行。

哪些任务适合自动化

不是所有手动跑通的任务都值得自动化。四个判断维度，缺一不可：

一个经验法则：自动化奖励"无聊的任务"。越是重复、规则明确、无人愿意做的活，自动化后的收益越大；越是需要判断力和创造力的活，越应该留在"人 + Agent 协作"的模式里。

可靠性设计（详见第 25 章）

• 每次运行留下日志与产物版本，失败可追溯；
• 失败时降级交付（缺什么说清楚），而不是静默失败；
• 关键产物设置人工抽检节点，自动化不等于免检。

自动化最大的敌人是静默失败：该发的简报没发，你以为"今天没新闻"；发的其实是昨天的产物，你以为"今天没什么变化"。信任一旦崩塌，重建的成本远高于建设。所以上线后的第一个月，建议保持每周一次的人工抽检——哪怕只是打开产物扫一眼日期和数据。

试运行一周看什么

低频试运行的那一周，每天只花两分钟，看四件事：

1. 按时出现：产物是否在预期时间生成并推送；
2. 内容稳定：对比三天的产物，结构是否一致、质量是否在线；
3. 失败诚实：出问题时收到的是明确的失败报告，还是一声不吭；
4. 消耗可控：积分或 Token 消耗是否在预期范围内——自动化是消耗大户，跑偏了要及早发现。

四项都过关，再提高频率、扩大推送范围；任何一项不稳，回到手动模式修指令，修稳了再来。

自动化台账（起步版）

每个自动化任务配一张小卡片，从第一天就开始记：

【自动化台账】
任务名：每日资讯简报
触发：每天 09:00
产物位置：云盘/简报/（文件名带日期）
通知渠道：IM 私聊 → 我
最近抽检：____（每周至少一次）
状态：试运行 / 稳定 / 已下线
备注：信源清单每月复核一次

这张卡片现在只有六行，但它会在第 25 章长成完整的可靠性台账——日志、降级策略、抽检记录都会挂上来。系统的样子，就是从这样一张卡片开始的。

从一个自动化到一张任务表

第一个自动化任务稳定运行后，用一张简单的台账管理它们：任务名、触发时间、产物位置、最近一次抽检日期。这张表会在第 25 章长成完整的可靠性台账，也会成为你判断"哪些该沉淀、哪些该下线"的依据。至此，第一篇的全部能力——任务、Skill、专家、连接器、IM、API——都被一条自动化串了起来：这就是"系统"最初的形状。

本章验收：建立一个每天运行一次的自动化任务（如资讯摘要、日程提醒），连续运行三天无人工干预且产物合格。

五层模型：把前十章串起来

十个章节学下来，能力清单已经不短：会下任务、会验收、有 Skill、有专家、接着连接器、通了 API、跑了自动化。信息一多就容易散——你需要一张全景图，看清这些东西彼此的关系和各自的位置。

把前十章串起来，一个完整的个人 AI 工作系统由五层构成：

L1  模型层    底座能力：理解、规划、生成（第 1 章）
L2  执行层    工作区 + 文件操作 + 工具调用（第 3–4 章）
L3  能力层    Skill：把做法固化（第 5、22 章）
L4  连接层    连接器 + API + IM：打通内外（第 7–9 章）
L5  运营层    自动化 + 多 Agent：让系统自己转（第 10、24 章）

五层是递进关系，不是并列菜单：没有 L2 的工作区与验收习惯，L3 的 Skill 沉淀无从谈起；没有 L3 的能力固化，L5 的自动化只是定时执行的临时指令。多数人卡在 L2——会用 Agent 做事，但每次成功都停留在聊天记录里，没有向上生长。

各层的标志物

判断你走到了哪一层，看每一层留下的"标志物"：

这张表可以当自查表用：找到自己最高达标的那一行，下一行就是你本周要做的事。

为什么是这五层

这个分层不是随意拼凑，每一层解决上一层遗留的一个问题：

注意一个规律：越往上，越不是在买能力，而是在做积累。L1 到 L2 装个应用就有了；L3 以上，每一层都要求你留下文件、配置和习惯。这也解释了为什么两个用同一款 Agent 的人，效率可以差出一个数量级——差在 L3 以上的积累厚度。

第一篇完成度自查

合上第一篇之前，对照下面这张清单打勾。全部打勾，说明你拥有的不再是一个"装了 AI 应用的电脑"，而是一个可运转的工作台：

• [ ] 完成过一个按清单验收的任务（第 4 章）
• [ ] 安装并对比过一个 Skill 的效果（第 5 章）
• [ ] 创建过一个自己的专家（第 6 章）
• [ ] 接入过一个高频工具的连接器（第 7 章）
• [ ] 在手机上收到过一次任务结果（第 8 章）
• [ ] 调通过一个外部 API 查询（第 9 章）
• [ ] 一条自动化任务连续三天合格交付（第 10 章）

打勾的每一项，都对应一份留下的资产：一段指令、一个 Skill、一张专家卡、一条自动化。这正是五层模型从图纸变成现实的过程。

从使用到系统

判断你的 AI 使用处于哪一层，就看一个标志：你的成功经验是记在聊天记录里，还是存在文件里。 前者是使用，后者是系统。

第一篇到这里结束了。回顾这十章，你做的事情其实只有两类：打通能力（安装、界面、任务、Skill、专家、连接器、IM、API），和让能力自己运转（自动化）。从下一章起，手册进入案例篇——每个案例都是把本篇的某一组能力，放进一个真实任务里淬炼一遍。而每个案例的终点，都应该是回到本篇的五层模型：多一个 Skill、多一条自动化、多一层系统。

接下来去哪

带着你的真实任务进入第二篇案例篇，按问题选入口：

案例跑通之后，回到第三篇系统篇：用第 22 章的方法把案例蒸馏成 Skill，用第 23 章的任务卡复盘，用第 24、25 章把它们组装成可靠运转的多 Agent 系统与自动化工作流。到那时再回头看这张五层图，每一层后面都应该跟着你自己的资产清单。

本章验收：对照五层模型与标志物表，标出你当前所在的层级，并列出通往下一层要做的一件事。

第二篇不再解释概念，只回答一个问题：第一篇学到的那些能力，拼在一起能交付什么？

每一章对应一类你本周就可能接到的活——写一份复盘、清一个目录、在外面指挥家里的电脑、管一件家务、追一个行业。写法统一：先说这类活的坑在哪里，再给一条能照抄的工作流，配可以直接复制的指令模板，最后列风险与人工关口。每章末尾的"本章验收"是唯一的出口标准：跑不通就回头返工，跑通了就去第 23 章填任务卡，值得复用的流程去第 22 章蒸馏成 Skill。

这一篇的隐藏主线仍是 FROM TASK TO TEAM 的下半程：先让一个个任务产出你能验收的成果，第三篇再把这些成果变成可持续运转的工作流。

动手之前：三份清单法

办公任务返工的头号原因，不是 Agent 能力不够，而是任务说明里混着三件没分开的事：给它的材料、要它交的东西、以及你怎么判断交得对。三份清单法就是在写任务之前，把这三件事各自列成一张清单：

三份清单花不了五分钟，但它们把"帮我做个报告"这类模糊指令，变成了带验收标准的合同。以本章贯穿案例"季度客户服务复盘"为例，三份清单可以填成这样：

案例总览：一次季度客户服务复盘

场景设定：客服部季度复盘，输入两份原始数据，输出三份交付物。三个文件不要并行开工，而要按"数字只算一遍"的顺序串联：

这个顺序的价值在返工时最明显：数据有错，改台账一处；报告和 PPT 只要按模板重跑引用即可。反过来如果三个文件各自算各自的，改一次数据要追三个文件。

第一步：Excel 问题分类台账

台账阶段的核心不是做图，而是把脏数据处理成可审计的口径。指令里要写死三件事：先检查再清洗、归类必须有理由、算不动的进兜底区。

请读取 csat-2026Q1-raw.xlsx 和 tickets-2026Q1.csv，先不修改原文件。
任务：生成 output/台账-客服问题-2026Q1.xlsx。
第一步，读表检查：描述两份文件的字段、行数、时间范围，列出缺失值、
重复工单号和格式异常；异常记录超过总数 5% 就停下来向我报告，不要继续。
第二步，清洗与归类：
1. 工单按"产品缺陷/物流履约/服务态度/价格争议/其他"五类归类，
   每条归类理由写进"归类理由"列，空着理由的视为未归类；
2. 归不进去的进"待人工归类"工作表，不要猜。
第三步，透视统计：按问题类别统计工单量、占比、平均处理时长、
关联 CSAT 降幅，并单独建一张"透视口径说明"工作表，逐指标写明：
分子、分母、剔除规则、时间口径（按工单创建时间还是关闭时间）。
验收标准：台账工单总数 = 清洗后记录数；各分类之和 = 总数，差额为 0。
输出 output/台账-客服问题-2026Q1.xlsx 和 output/清洗说明.md。

"透视口径说明"这张表最容易被省掉，也最值钱：下季度复盘、领导追问"这个 23% 怎么算的"时，答案就在表里，不用任何人重新推导。

第二步：Word 复盘报告（8–12 页结构表）

报告的结构先定页数配额，再填内容。8–12 页的分配参考：

基于 output/台账-客服问题-2026Q1.xlsx 生成季度客服复盘报告 Word 初稿。
读者：客服部负责人与分管副总；用途：季度经营分析会决策参考。
章节结构与页数配额：摘要 1 页、季度概况 1 页、分类分析 2-3 页、
典型问题深挖 2 页、根因与建议 1-2 页、待确认与风险 1 页、附录 1 页。
约束：
1. 全文 8-12 页，摘要结论不超过 3 条，每条不超过 40 字；
2. 所有数字只能引用台账，禁止重新计算，禁止使用你记忆中的行业数据；
3. 每条建议必须指向一个具体数据结论，格式："依据：台账 XX 表"；
4. 数据撑不住的判断写进"待确认与风险"，不写成结论；
5. 输出 output/报告-客服复盘-2026Q1-v1.docx。

第三步：管理层汇报 PPT（10 页大纲）

PPT 阶段唯一的工作是取舍：从 8–12 页的报告里抽出管理层 8 分钟听完能拍板的东西。10 页大纲先确认再生成：

基于 报告-客服复盘-2026Q1-v1.docx 制作 10 页管理层汇报 PPT。
汇报时长 8 分钟，受众为公司管理层，不熟悉客服执行细节。
要求：
1. 每页一个结论式标题，不用"客服工作汇报"这类名词式标题；
2. 数字一律与报告一致，页脚标注"来源：问题分类台账"；
3. 不引入报告之外的事实和行业数据；
4. 先输出 10 页大纲（每页标题 + 要点）给我确认，确认后再生成文件；
5. 生成后自查：文字是否溢出、图表数字与台账是否一致、备注页是否有讲稿要点。
输出 output/汇报-管理层-客服复盘-2026Q1.pptx。

版本管理：别让三个文件三个数

三件套任务最常见的翻车不是某一稿写得差，而是同一指标在三个文件里是三个数。预防靠两条规矩：

规矩一：口径文件单一来源。 全案只允许台账产生数字，报告引用台账，PPT 引用报告。数据修订时顺序不能反：先改台账 → 重跑报告的引用 → 重生成 PPT。任何跳步都会制造第二套数字。

规矩二：文件名带身份。 命名规范四个字段：类型、主题、期间、版本。

版本号只增不减，禁止"最终版""真最终版"；对外发送前，把工作目录里的旧版本移进 archive/ 子目录，只留要发的那一版——你永远不知道"报告 v1"会不会在三个月后被谁翻出来当最新口径。

常见失败与返工

这类任务跑顺两轮之后，把三份清单和固定指令沉淀成 Skill（见第 5 章的四步校准），下季度复盘就是一句话的事。

本章验收：完成一次"一份数据 → 台账 Excel + 报告 Word + 汇报 PPT"的三件套任务，并核对三件事——三个文件中同一指标的数字完全一致；台账每个指标都能在"透视口径说明"里查到口径；PPT 每页标题是一句结论而非一个名词。

为什么从下载文件夹开始

下载文件夹通常是整台电脑最乱、又最无关痛痒的地方：安装包、合同扫描件、聊天里的图片、临时导出的表格，全堆在一层。它恰好满足首任务的三条标准——你完全看得懂（都是你自己的文件）、它完全做得了（移动和重命名）、错了也无所谓（几乎没有程序依赖这里的文件）。

更重要的是，这个任务会逼你第一次完整走一遍"Agent 出方案 → 人拍板 → 执行 → 留回滚依据"的流程。这条流程在第 11 章是三份清单，在第 12 章变成一份预览报告，形式不同、关口相同。

第一步：现状盘点（只读，不动一个文件）

治理从盘点开始。指令的第一句就要把"只读"写死——这不是客气话，是合同条款：

请扫描 下载 文件夹，只做统计，未获我确认不得移动、重命名或删除任何文件。
输出一份现状盘点报告：
1. 总量：文件总数、总大小、最早与最新文件的日期跨度；
2. 构成：按类型统计数量与大小（安装包/压缩包/文档/表格/图片/视频/其他）；
3. 时间分布：近 30 天、31-90 天、90 天以上三段各多少个文件、占多大空间；
4. 大文件清单：超过 100MB 的前 10 个，列出路径、大小与最后访问时间；
5. 疑似可清理项：重复下载（同名带序号）、零字节文件、
   与已安装软件版本不符的旧安装包。
现在只输出这份报告，不做任何操作。

拿到报告先看两个数：90 天以上未访问的文件占比（决定治理量级），以及安装包与压缩包占掉的空间（通常是白拿回的）。这份报告同时是下一轮对比的基线——治理完再跑一次，前后两份报告就是效果的证据。

归档三分法：每一份文件的三条出路

盘点之后、动手之前，你要先定判定规则。归档三分法把每份文件的出路压成三条，没有第四条：

注意第三条的措辞："可直接清理"也不直接删。它先进缓冲区放 7 天——这 7 天就是你的人工关口，期间想起任何一份文件都还来得及捞回来。删除动作永远保留给人，这条写进指令。

第二步：两套方案，你来拍板

让 Agent 基于盘点报告同时出两套方案，你选一套：

首次治理建议选保守方案：先把最安全的一半做完，验证流程没有意外，第二次再上激进方案。选好之后下达执行指令：

按【保守方案】执行下载文件夹治理。执行约束：
1. 先完整输出移动预览清单（原路径 → 新路径），等我回复"确认执行"再动手；
2. 动手前生成 output/move-log-20260405.csv，逐行记录：文件名、原路径、
   新路径、操作类型（移动/重命名）、时间；
3. 同名文件不覆盖：新位置已有同名文件时，本次文件名追加序号并在日志中
   标记"冲突"；
4. "待清理"目录只放入文件，不删除任何内容，删除留给我 7 天后自己做；
5. 执行完成后汇报四项：移动数、重命名数、冲突数、待人工处理数，
   并确认移动数 = 预览清单总行数。

命名规范：日期前缀 + 项目代号 + 版本号

命名公式：YYYYMMDD_项目代号_主题_v版本号。三个字段各管一件事：日期管排序，项目代号管归属，版本号管迭代。对照示例：

两条细则：日期取文件内容对应的日期（合同签署日、数据截止日），不是下载日——按下载日命名，三个月后你自己都对不上号；项目代号控制在 2–6 个字符，与"进行中"目录下的事项子目录同名，文件和目录互相指认。

还有一条隐性收益值得记下：命名规范统一后，找文件可以从"翻目录"退化成"说名字"——你报出"上个月某项目的协议 v2"，Agent 按命名规则反查即可定位。结构是为检索服务的，检索才是治理的终点。

第三步：执行、抽查与回滚演练

执行完成不等于任务完成，验收三步走：

对照表（move-log）保留至少 30 天。任何时点发现归错了，一句指令就能整体回退：

请按 output/move-log-20260405.csv 做逆向恢复：
把"新路径"列的文件移回"原路径"列，同样先输出预览清单，
我确认后执行，并生成 restore-log.csv。只恢复，不做其他操作。

治理是一次性动作，维护才是长期动作。结构建好后的常见死法是"三个月后又乱了"——原因不是结构不好，而是新文件落地时没人执行归位。对策是把判定规则和命名规范沉淀成一个维护 Skill，每周对目录说一句"按治理规范执行维护"，新文件各归各位，日志照常生成。这正是第 22 章要讲的蒸馏：一次跑通的任务，第二次就该变成一句话。

常见失败与返工

本章验收：完成一次下载文件夹（或任意混乱目录）治理，手里留下三样东西——治理前的盘点报告、你拍过板的方案、move-log 对照表；"待清理"目录里的文件一个都没被删除，且按对照表成功逆向恢复过一个文件。

两个真实场景

场景一：出差途中，客户要一份标书终版。 人在高铁上，终版在公司电脑里，手机里只有三天前同事发的旧版。你需要的是：让公司电脑找到那份文件，确认它就是终版，然后把文件递到你手机上。

场景二：出门半天，家里的批量任务还在跑。 上午让 Agent 批量整理 300 份资料，现在人在外面，想知道跑到第几份、有没有报错、要不要重跑。你需要的是：一条进度查询，外加出问题时能喊停。

两个场景的共同点：你不需要看到那块屏幕，你需要的是结果和状态。远程交互的基本单位不是鼠标键盘，而是"一条指令、一条回执"。这个认知决定了远程指令的写法与本地完全不同——本地指令可以边看边改，远程指令必须一次说清、自带判据、失败可见。

远程任务三要素

任何一条要发到远端的指令，发出前对照这张表自检，三行都答得上来再发：

三要素里最容易被忽略的是第二条。很多人默认任务一旦发出去就会一口气跑完，但远程任务最常见的状态恰恰是"中间态"——批量任务跑到 170/300 时网络抖了一下、公司电脑弹了个系统更新。可中断的设计让"中间态"本身无害：分段落盘、进度可见、随时可以放弃已跑部分而不是推倒重来。

失联与中断：提前想好对策

远程场景有一类风险本地没有：链路上的任何一个环节断掉，你都会失去对任务的感知。对策要在事前配置，不要等发生再补救：

共同原则只有一条：远程任务宁可收到十条"没做成"，不要一片寂静。每一条对策的本质都是把不可见的状态变成一条会主动发到你手机上的消息。

指令模板：远程查文件（场景一）

远程找文件最容易错在"最新"二字——修改时间最新的未必是终版。模板里加了一道"先报候选、人再确认"的关口：

【通过 IM 下达】
在工作区/投标-某项目/ 目录找标书终版：
1. 列出该目录下全部 .docx 和 .pdf 文件，带修改时间，按时间倒序；
2. 圈出文件名或备注含"终版"的候选，先回我文件名和修改时间，等我确认；
3. 我确认后，把该文件上传并回传链接；
4. 候选不止一个或都无"终版"标记时，全部列出让我选，不要自作主张。

指令模板：远程盯任务（场景二）

进度查询是纯只读操作，风险最低，但同样要有结构化回执：

【通过 IM 下达】
查询 资料整理 批量任务的当前状态：
1. 统计 output/资料整理/ 目录下已生成的结果文件数，与预期总数 300 对比；
2. 检查最近 10 分钟内是否有新文件产出；
3. 读取任务日志最后 20 行，标出报错关键词；
4. 用三行回我：进度（x/300）、是否仍在推进、有无异常及关键词；
5. 本次只做读取，不重启任务、不修改任何文件。

如果判断需要远程续跑或重跑一个流程，用回执更强的版本：

【通过 IM 下达】
执行 资料翻译 任务：
1. 输入：工作区/待翻译/ 目录下全部 .docx 文件；
2. 按已验证的翻译流程逐份处理，产物写入 output/译文/；
3. 每完成 10 份，在本会话发一行进度（已完成/总数）；
4. 任一文件处理失败：跳过并记录原因，继续处理其余文件，
   不要为单份文件反复重试超过 2 次；
5. 全部结束后回执四项：成功数、失败数、失败清单、产物目录。

"静默重试"是远程场景的头号敌人：它埋头重试五轮，你在手机那头分不清是卡住了还是成功了。限制重试次数、强制分段汇报，把不可见变成可见。

安全边界：最小授权与双人确认

远程能力放出去之前，先把这张配置表逐行过一遍，每一行都是"宁麻烦、不冒险"：

其中"双人确认"值得多说一句：凡是会写入、外发、影响他人的远程动作，要求 Agent 收到指令后先回一句确认请求，你回复事先约定的口令才执行。口令本身不重要，重要的是给"冲动指令"加了一个强制冷静的间隔。

另外三条纪律：IM 通道要有访问控制（机器人只响应你的私聊或指定管理群，否则群里任何人都在远程控制你的电脑）；远程任务控制在 10 分钟量级，超长任务拆段或回本地跑；电脑休眠即失联，要么接受"开机时段可用"，要么提前调整电源设置。

最后提醒一句边界：这一章讲的是"用指令换结果"，不是远程桌面。你能做的取决于桌面端 Agent 被授权做什么——授权范围之内，它比远程桌面快得多（不用等画面传输）；授权范围之外，它一步都不会走。这条边界正是它安全的原因。

常见失败与返工

远程能力建议从只读查询起步，稳定两周后再放开"跑已验证流程"，写入与分发放在最后——每一级都留下观察记录，放开下一级时你手里才有真实的失败数据，而不是凭感觉的信任。

本章验收：人在电脑之外，通过 IM 完成"查文件 — 人确认 — 收到文件"和"跑一个已验证任务 — 收到三行结构化回执"各一次；全程未触碰授权目录之外的内容，且没有任何删除或覆盖类操作发生。

先判断：这件琐事值不值得交给 Agent

生活场景的任务选择标准与办公一致，但检验得更狠——办公任务错了有人一起兜，生活任务错了只有你自己重做。动手前过一遍三列判断表：

三项全过再动手。有一项不过，先改造任务本身——比如"规则写不出来"的场景，先把规则硬写成一张表，规则明确度这一列就过了；写不出来的，说明这件事暂时不值得交给它。

场景一：菜谱与采购清单联动

痛点：每周日想"下周吃什么"要想半小时，去超市凭记忆买，回来发现缺两样、多三样。搭建方式是一份菜谱库加一份家中库存清单：

请根据 菜谱库.md 和 家中现有食材.md 安排下周 6 顿晚餐：
1. 从菜谱库选 6 道菜，荤素搭配、烹饪方式不连续重复，
   每顿列出菜名、主料、耗时；
2. 先把 6 顿菜单发我确认，未确认不生成采购清单；
3. 确认后汇总所需食材，扣除家中现有数量，按蔬菜/肉禽/水产/
   粮油/冷冻五个分区排列，标注每项用量和对应菜品；
4. 输出 output/采购清单-YYYYMMDD.md，总项数控制在 25 项以内；
5. 菜谱库里没有的菜不要推荐，需要扩充菜谱时先问我。

最后一条是生活助手的立身之本：只做被交代的事。一个主动推荐"您可能还想买"的采购助手，两周内就会沦为被无视的营销号。

场景二：家电保修卡与说明书的数字档案

痛点：冰箱坏了想查保修，翻遍全屋找不到购买凭证；说明书永远在扔掉的前一周被需要。搭建方式：一个目录 + 一张台账 + 一条自动化。

命名与台账规范：

命名里带保修截止日，是整个档案的高价值设计：第 10 章的自动化任务每月 1 号扫一遍文件名，临近截止 60 天推一条提醒——而厂商的延保促销窗口恰好也开在这段时间，提醒本身就是钱。

请整理 家电档案/ 目录下本周新增的照片：
1. 识别每张图的品类、品牌、购买日期、保修截止日期；
2. 按规范"品牌_品类_购于YYYYMMDD_保修至YYYYMMDD"重命名；
3. 识别不出保修截止日的，移入"待人工补录"并在汇报中列出，
   不要根据品牌常识猜测日期；
4. 更新 家电台账.xlsx：品类、品牌、型号、购买日期、保修截止、
   凭证文件名、录入日期；
5. 完成后汇报：新增几条、补录几条、重命名了哪些文件。

场景三：孩子学校通知的摘要与日历同步

痛点：班级群每天几十条消息，交费通知、带物要求、活动改期混在"收到"和表情包里，漏一条就是第二天早上的人仰马翻。流程：把群消息定期复制进一个收集文件，Agent 每晚提取、摘要、设提醒。

【每晚 21:00 自动执行】
读取 学校通知-收集.md 今天新增的内容，提取需要家长处理的通知：
1. 只保留含明确时间、动作或截止日期的条目，闲聊与表情消息一律丢弃；
2. 每条输出：事项、时间、要准备什么、来源（引自哪条消息）；
3. 含截止日期的，在截止前一天 20:00 和当天 7:30 各设一次日历提醒；
4. 拿不准是否与我家相关的，列入"待我确认"，不直接进日历；
5. 最后输出一段 100 字以内的晚间摘要推送给我。

"待我确认"这个出口在生活场景尤其重要：把"班级集体活动"误判成"与我无关"和把闲聊误判成通知，代价同样低，但前者你会心疼——宁可多问，不要替你做主。

三个场景的公共结构

三个场景看似无关，拆开是同一副骨架，这也是它们能共用流程的原因：

看懂这副骨架，第四个生活场景（健身餐计划、宠物用品补给、家庭药箱效期盘点）你就能自己搭——这比照抄任何一个模板都值钱。

边界与红线

• 不可逆动作留给人：下单支付、给老师回消息、扔东西，Agent 最多做到"生成待办 + 提醒"；
• 隐私最小化：家电档案含住址与发票、学校通知含孩子信息，产物不外发、不进群、不进任何共享目录；
• 生活场景是办公场景的练习场：把采购清单跑稳的手感，与把库存周报跑稳的手感是同一份——自动化的失败模式（静默失败、数据过期、推送过吵）在这里全都能小成本地先踩一遍。

常见失败与返工

本章验收：三个场景任选一个跑满两周——菜谱采购（连续两周没再手写采购清单）、家电档案（存量保修凭证全部入台账，且到期提醒真实触发过一次）、学校通知（连续两周每晚收到摘要，且没有漏掉任何一条含截止日期的通知）。

痛点：不是没有信息，是信息没有"到点出现"

多数人和行业信息的关系是"偶尔想起去打捞"：收藏夹越来越长，群里的转发永远"稍后再看"，等真正想起来去找，要么信息已经过期，要么翻找的成本高过信息本身的价值。偶尔打捞一次很累，于是更少打捞，最后彻底断供。

资讯整合要解决的不是"看得更多"，而是让该知道的事在固定时刻自己走到你面前，其余的永远别来打扰。前者靠的是一条流水线，后者靠的是克制的规则——这一章两件事都给。

三层漏斗：一切资讯通知的共同骨架

无论你追踪的是行业动态、竞品动作还是政策更新，能长期活下来的资讯通知都长同一个样子：三层漏斗，层层收窄。

三层各有一个最常见的死法：采集层死于信源泛滥（什么都收，等于什么都没收），加工层死于规则含糊（"看起来重要的推给我"），分发层死于推送失控（条数越推越多，最后你把它当垃圾通知关掉）。下面的案例把三层各搭一遍。

案例实录：搭一份"AI 行业动态晨报"

场景：你在一家用 AI 工具做产品的团队，需要每天花 10 分钟知道行业发生了什么。从零到稳定运行，分三步。

第一步：采集层——建信源池。 初始 8 条，每条标优先级。优先级的含义不是"内容好坏"，而是"漏掉的代价"：

分池原则：官方与竞品为高优先，因为它们命中即大事，宁低量不漏收；媒体为中，允许采样；论文与榜单为低，只看标题。起步时 6–10 条足够，超过 15 条的池子没有维护价值。

第二步：加工层——筛选规则与摘要模板。 规则要写成 Agent 能执行、你周末能复盘的条款，初始 5 条：

摘要模板固定四件套：一句事实标题 + 两句话摘要 + 来源与日期 + 一句"对我们的影响"。影响写不出来时，就写"暂无直接影响"——承认没有影响，比硬编一个影响可信一百倍。

第三步：分发层——渠道、时刻与版式。 渠道选 IM 私聊（不进群，进群就有观众压力），时刻固定每天 8:30，必看区硬上限 8 条，超出的进归档文档。晨报版式：

【AI 晨报 YYYY-MM-DD】
▍必看（x 条）
· <一句话事实标题>
  <两句话摘要>
  来源：<官方/媒体> <日期> ｜ 影响：<一句话或"暂无直接影响">
▍参考（x 条，最多 5 条）
· <标题> —— <一句话摘要>
▍今日共采集 xx 条，其余见 output/晨报归档/YYYYMMDD.md

版式一旦定下就不要动：格式的稳定性就是扫读速度，天天换版式等于天天重新学怎么读它。

上线节奏与指令模板

直接上自动化必翻车，按三段走：

主指令模板：

【每天 8:30 执行】
按 信源池.md 抓取各信源过去 24 小时的更新，生成今日 AI 晨报：
1. 逐条对照 筛选规则.md 打标：高 / 需行动 / 参考 / 丢弃；
2. "高"与"需行动"进入必看区，最多 8 条；"参考"最多 5 条；
3. 每条摘要不超过两句；"影响"写不出就写"暂无直接影响"，禁止编造；
4. 同一事件多来源报道时合并为一条，保留最早或官方来源；
5. 全部条目（含被丢弃的标题）写入 output/晨报归档/YYYYMMDD.md；
6. 任一信源抓取失败，在晨报末尾注明"该源今日缺失"，不要静默跳过。
按晨报版式输出到本会话。

噪音控制：让信源池自己瘦身

晨报活了之后，最大的敌人从"漏信息"变成"变吵"。控制手段不是凭感觉删信源，而是一套量化淘汰标准：

每周五复盘，统计各信源近 14 天的"有效命中数"（进入必看区的条目数）。连续 14 天有效命中为 0 的中低优先信源，移出信源池进"冷冻区"；冷冻 30 天内你没有手工捞回过它，就删除。高优先信源不适用此规则——官方与竞品低命中是常态，命中即大事。

信源健康表（每周五生成一张）：

另外三条防吵铁律：条数上限是硬顶，宁可漏掉次要的，不可让人关掉通知；去重窗口跨 7 天，同一事件换个标题再推一次，是信任崩塌的最快路径；推送时刻只有 8:30 一个，突发事件如果真的重要到不能等，单独建一条"高优通道"并规定它的触发条件，而不是把主晨报改成随时推送。

常见失败与返工

本章验收：搭一份自己的每日通知——信源池至少 6 条且每条标了优先级；连续 7 天在固定时刻收到条数不超标的推送，每条可溯源到链接；第 7 天做一次信源健康复盘，对至少一条信源做出保留、降频或冷冻的明确处置，并把这张健康表留档。

痛点：你收藏的是"安全感"，不是知识

点下"收藏"的那一秒，焦虑确实消失了——但知识并没有因此转移。三个月后打开收藏夹，几百条链接躺在那里，每一条都眼熟，没有一条记得"当时为什么收"。检验知识管理是否有效，考场只有一个：下一次动笔、做决定、回消息时，你能不能在两分钟内把那条材料调出来用上。

调不出来，问题不在记性，在结构。收藏夹只完成"存"这一个动作，它不管"找"，更不管"用"。本章要搭的库反过来设计：为"再次使用"而存——存进去的每一条，都要为未来的某次调用做好准备。

知识库三层结构：快照、卡片、地图

一个能被反复调用的知识库，分三层：

• 原始层：原文快照。文章、报告、截图按存进来时的样子原封保留，只读、不删改——它是最终的证据层；
• 卡片层：每个快照配一张卡片，一句话摘要加两个标签，回答"这条材料主张什么、归到哪里"；
• 索引层：一张主题地图，回答"我库里有哪些主题、每个主题下有什么"。日常检索从这层进入，而不是一头扎进文件堆。

目录树示例（个人写作素材库）：

writing-vault/
├── 00-INDEX.md              # 索引层：主题地图
├── 01-raw/                  # 原始层：原文快照，只读
│   ├── 2025-06-02_开头三段拆解_某公众号.md
│   ├── 2025-06-10_数据叙事案例_某行业报告.pdf
│   └── 2025-06-15_标题修辞十二条_写作课讲义.md
├── 02-cards/
│   └── cards.md             # 卡片层：一行一卡
└── 03-topics/               # 按主题沉淀的成稿与半成品
    ├── 开头写法/
    └── 数据叙事/

三层之间靠固定的流转规则连接，谁触发、谁执行、谁把关，提前写死：

案例实战：从 0 搭一个写作素材库

案例设定：写作者小柯，散落在收藏夹、备忘录、聊天记录里的素材约 200 条，决定用一个周末完成冷启动。

第一步只做一件事：把素材一次性倒进原始层，批量入库指令：

【批量入库：周末冷启动】
请处理 收藏夹导出/ 目录下的全部文件（约 200 条），执行：
1. 存档：将每个文件复制到 01-raw/，重命名为"日期_一句话主题_来源"，
   原始内容不做任何修改；
2. 制卡：为每个快照在 02-cards/cards.md 追加一行卡片：
   - 摘要：一句话说清它主张什么（40 字内，禁止复述标题）；
   - 标签：从既有标签表选取，最多 2 个；确需新标签的单独列清单等我批准；
   - 关系：与库内已有卡片标注"补充/对立/替代/无关"；
3. 拒收：纯链接无正文、时效超过两年且非经典材料的，列入"建议退回"清单，
   不要自行入库。
完成后输出入库台账：入库数、退回数、待批新标签数。我抽 5 张卡片核对质量。

第二步，让索引层从卡片里长出来：

请基于 02-cards/cards.md 重建索引层 00-INDEX.md：
1. 按主题分组：主题名、一句话定位、卡片数、最近一次被引用的时间；
2. 卡片数不足 3 张的主题并入相近主题，不要为孤卡单开主题；
3. 连续 3 个月未被引用的主题移入"冷冻区"，单独列出；
4. 输出"孤儿卡片"清单：无法归入任何主题的卡片，等我人工归置。
约束：只写 00-INDEX.md，不改动原始层与卡片层。

两步跑完，200 条素材变成"200 张卡片 + 一张地图"。第三步是习惯：写任何东西之前，先让 Agent 按主题地图查一遍库，把"查库"变成动笔的默认第一步——这一步值得用第 5 章的方法写进写作类 Skill 的固定流程，靠结构而不是靠自觉。

入库三问：每收一条，先过三道闸

三层结构解决"存得对"，入库三问解决"该不该存"。每收一条新材料，先回答三个问题：

三问的真正作用是把囤积冲动拦在库外：第一问淘汰焦虑型收藏，第二问防止主题爆炸，第三问强迫你在存入的那一刻完成一次消化——消化发生在入库时，而不是幻想中的"以后有空"。

一个直观的比例参考：小柯冷启动的 200 条原料，过三问后真正入库的只有 137 条——剩下 63 条留在收藏夹里，一个月后无人问津，印证了拒收是对的。

出库率：知识库唯一值得盯的指标

这个库是资产还是仓库，只看一个数：出库率 = 当月被引用的卡片数 ÷ 卡片总数。引用的判定标准很具体：某次任务的产物里出现"引自 02-cards/某卡片"的标注，记一次出库。

出库率由 Agent 每月自动统计（方法见第 10 章自动化任务），随月报推送。它同时是三层结构的体检表：出库率低，先查索引层（主题地图是否失真），再查卡片层（摘要是否可用），最后才怀疑原始层（收错了东西）。

顺带说清为什么不看"库规模"：500 张卡片听起来比 200 张体面，但规模不产生价值，出库才产生。规模是虚荣指标，出库率是产能指标——报月报时只报后者。

风险与人工关口

• 快照不可变：Agent 对 01-raw/ 只有添加权限，不能修改与删除，保住证据链；
• 标签表受控：新标签必须经人批准，否则一个月后标签比文件还多；
• 引用必须留痕：任务产物引用库内材料时标注来源卡片，这是出库率可信的前提；
• 版权边界：入库快照仅限个人检索使用，产物对外发布时按版权规则另行处理。

本章验收：完成一次三层结构的冷启动（原始层、卡片层、索引层各就位并留档），并在随后的一次真实写作任务中，让 Agent 经由主题地图调出至少 3 张卡片用于成稿——产物中留有引用标注，每条标注可回溯到具体快照文件。

痛点：散会那一刻，共识开始蒸发

会议的产出从来不是散会时大家脑中的集体记忆，而是事后还留在纸面上的东西。现实往往是这样：决议没人落笔，三天后每个人记忆里的版本各不相同；会上认领的事没有截止日，下周例会上再"认领"一次；讨论过的关键数据散落在各人的笔记本里，下次要用时谁也找不齐。

会后的整理工作机械、琐碎、没人爱干——正因如此，它是最该交给 Agent 的工序。而它需要的全部输入（议程、材料、转写），Agent 都够得着。

会议的三种产物：决策记录、行动清单、信息存档

把"会议纪要"这个笼统的东西拆成三种产物，每种有自己的字段、去处和生命周期：

拆开的好处是各有各的验收：决策记录要经得起半年后有人翻旧账；行动清单要能直接进督办流程；信息存档要能让没参会的人还原现场。一份什么都往里塞的"大纪要"，三种验收一个都过不了。

会中：主持人的三个动作

会中环节主要靠人，但主持人有三个固定动作，直接决定会后 Agent 拿到的原料质量：

• 开场一分钟交代：宣布本场录制与转写的用途和范围——这一分钟既是合规动作，也让随后所有发言都在"可留档"的预期下进行；
• 议题收口时复述：每项议题结束，用一句话复述结论或现状（"这条先按 A 方案做，下周看数据"）——复述是给转写留下最干净的段落边界，会后整理时议题切分不靠猜；
• 行动项当场点名：谁认领、什么时间交付，请本人开口确认——本人说出的截止日，比主持人替他定的更有约束力，也让转写里的负责人归属毫无歧义。

三个动作成本极低，却把会后整理的三大难点（分段、定性、归属）在会上就地解决。

案例实战：项目周例会的完整一周

以一个十人项目组的周例会为例，看三种产物如何被生产出来。

会前：材料包。 周一上午发出指令：

【周例会材料包：第 28 周】
明天 10:00 项目周例会，请整理材料包 output/周例会材料包-W28.md：
1. 行动清单核对：actions.md 逐条标注"已完成/进行中/延期"，
   延期项附原因与新截止日，本周到期项置顶；
2. 风险信号：从工作区与知识库检索本周新增的阻塞、缺陷、外部变化；
3. 产出一览：从共享目录提取各成员本周交付物清单；
4. 待拍板议题草案：每项附背景一句话、可选方案、受影响的人。
20:00 前给我，留出我补数据的时间。

材料包让例会前二十分钟的口头汇报环节直接消失，会上一开口就是议题。

会后：整理。 拿到转写文件后（录音与转写须经会议平台授权、参会人知情；有外部人员参加的会议须事先取得对方同意——这是先于一切效率的合规底线），发出整理指令：

请根据转写 record-W28.txt 整理本次周例会，全部结论按三分法归类：
- 已决定的：会上明确通过、或负责人当场认领的事项；
- 讨论中的：有倾向但未拍板的，记录分歧双方各自的理由；
- 需要升级决策的：超出本会权限、或需上级与客户确认的，注明卡在谁那里。
输出三份产物：
1. 决策记录（追加进 decisions.md）：只收"已决定的"，
   每条附转写原句片段与时间点，格式如"见 record-W28 00:42:15"；
2. 行动清单（更新 actions.md）：每条含唯一负责人、截止日、验收标准；
   找不到负责人的单列"待认领"，禁止写"大家"；
3. 信息存档（archive/W28-各议题.md）：关键数据与未采纳方案，注明发言人。
转写含糊或我未参与讨论的部分，标"待核实"，禁止合理推测补全。

三分法是这份模板的灵魂："已决定的"进决策记录，"讨论中的"留在存档里继续发酵，"需要升级决策的"单独浮出来。多数会议事故源于三者混作一团——把倾向当决议执行，把该升级的事在本会层面硬拍。

会后第二天：督办。 行动清单通过连接器（第 7 章）转入任务系统，或经 IM 助理（第 8 章）逐条推送负责人。会议的闭环不在会议室里完成，在截止日之前完成。

分发路径也随产物固化：决策记录进项目频道（全员可查），行动清单只发各负责人（点到人），信息存档按需检索、不主动推送——三种产物三种路径，这是"最小分发"红线的落地。

纪要质量红线：四条不容商量

四条里"保真"最值得反复强调：这不是措辞问题，是责任问题——一条被升格的倾向，可能让整个团队为一件没人拍过板的事加班两周。

常见失败与返工

最后一条的本质是：行动清单是会议与执行之间的合同，合同里不能有"乙方待定"的条款。

进阶：把周例会流程沉淀为 Skill

周例会每周发生、流程高度固定，是第 22 章蒸馏方法的理想原料。手动跑通三次后，把它做成一个"周例会管家" Skill：SKILL.md 里写死三种产物的字段表、三分法规则与四条红线，变量只留"周数、转写文件名、待认领事项的通知对象"。此后每周的全部动作收敛为两句指令：周一"出材料包"，周二"转写好了，整理"。

沉淀的红利：决策记录变成项目资产

坚持一个季度后，三种产物会显出比"省时间"更大的价值：

• decisions.md 成了项目的"判例集"——新人问"当初为什么选 A 不选 B"，答案是一条带出处的决策记录，而不是老员工的模糊回忆；
• actions.md 的历史数据能回答管理问题：哪类行动最容易延期、谁的认领量长期超额，周例会的议程安排因此有据可调；
• archive/ 让"我们讨论过这个"变成可验证的陈述——半年后翻旧账，靠的是存档，不是记忆。

单场会议的价值有限，一个季度的三种产物，就是项目自己的知识库（建库方法见第 16 章）。

本章验收：用三种产物跑通一次完整的周例会循环——会前材料包、会后三份产物、行动清单全部进入督办且逐条有唯一负责人与截止日——并随机抽取一条决策记录，回放转写核对出处无误。

痛点：选型最贵的成本，是"选完就不再看"

团队在两个开源方案之间摇摆了两周，终于拍板用了 A。半年后，方案 B 发布了颠覆性的大版本、方案 A 的核心维护者出走——没人知道，因为选型报告交上去的那天，这件事就在所有人心里结案了。

专业分析真正的难点不是第一次研究，而是研究之后的持续盯守。人工盯不住不是人不勤快，是成本结构不允许：每天花一小时巡检十个信息源，一个月就是二十多个小时。本章要做的是把盯守成本压到每天五分钟，同时保证关键变化一个不漏。

案例设定：两个开源报表引擎的选型

团队要在两个开源报表引擎之间做技术选型：方案 A，老牌项目，社区大、文档全，但近一年迭代放缓；方案 B，后起之秀，性能数据漂亮，但生态薄、存在单人维护风险。结论要在一个月后的架构评审会上拍板。

第一步：监控清单——只留十个信号源

清单刻意压在 10 个以内——与第 15 章同样的教训：监控的敌人是噪音过载，不是覆盖不足。每个信号源都必须能回答"它在改变评估的哪个维度"，回答不了的删掉。

第二步：评估维度表——能力、生态、成本、风险

维度和权重在启动前定死、写进 Skill——这叫尺子先于数据：没有固定维度，每天的监控只是信息堆积；有了它，每条新信息都必须回答"改变了哪个格子的判断"。

两轮工作法：增量轮与深研轮

日常运转分两轮，节奏完全不同：

• 每日增量轮：只回答"昨天到今天，评估维度表里有什么变了"，输出不超过半页；没有变化就写"今日无实质变化"，禁止凑数；
• 触发深研轮：重大变化才启动，按维度表完整重跑一轮研究，更新证据列，产出对比报告。

顺带一条运维规则：监控清单里的链接失效是高频事故，增量轮指令要求每轮报告"今日失效的信源"，而不是静默跳过——信源悄悄死掉两周一无人知，是持续盯守最常见的断点。

深研轮不能天天跑——它贵，而且频繁重启会稀释结论的严肃性。启动条件提前写成表：

增量轮指令模板：

【每日增量轮：报表引擎选型】
请检查监控清单（选型监控.md）各信号源自昨日以来的更新。
输出增量简报，不超过半页：
1. 变化条目：只列与评估维度相关的事，每条注明"影响的维度 + 来源 + 日期"；
2. 影响判断：一句话说明该变化是改变判断、还是噪音；
3. 深研触发：对照启动条件表，明确输出"触发/不触发"及依据；
4. 无实质变化时，只写"今日无实质变化"五个字，不要展开。

深研轮指令模板：

【深研轮：报表引擎选型重启】
触发原因：【如：方案 B 发布 3.0 大版本】。
请按评估维度表完整重跑一轮：
1. 逐维度更新证据：每条证据附来源链接与发布时间；
2. 关键数字（性能、工时、成本）至少两个独立来源交叉验证，
   达不到的标注"单源未验证"，不得进入结论；
3. 项目方自述的性能数字单独标注"官方口径"，与第三方实测分开呈现，
   不得混排在同一行；
4. 结论按三级标注：事实（有据）/ 推断（写明推理链）/ 建议（供人裁决）；
5. 输出 选型对比报告-YYYYMMDD.md，末尾附完整来源清单。

事实核验：专业分析的护栏

深研轮模板里的三条核验规则值得单独展开，它们是一切专业分析的通用护栏：

• 来源时效标注：每条证据带"来源 + 日期"，超过一年的数据降级为"背景参考"，不得作为当前判断的依据——在开源世界，一年前的性能数据约等于考古；
• 双源交叉验证：关键数字至少两个独立来源一致才可采用；"独立"指两家分别得出，而非一家转载另一家；
• 宣传与评测分离：项目方自述（官方文档、发布会）与第三方评测（基准站、迁移实录）是两种性质的证据，前者必须标注"官方口径"单列。方案 B 的性能优势如果只有官方数据撑着，这个事实本身就该记进风险维度。

结论分级：事实、推断、建议

报告里的每个结论必须标明等级：事实（两个以上来源支持）、推断（由事实推出，须写明推理链）、建议（供人裁决的倾向）。分级的意义在评审会上兑现：评审人只需对"建议"投票，不必逐条重验"事实"——核验成本被结构化地压缩了。

常见失败与返工

风险与人工关口

• 选型拍板、对外承诺、涉及预算的判断，人工关口不可省略——Agent 的报告是评审会的输入，不是评审会的决议；
• 每季度人工复核一次维度与权重：业务重点变了，尺子要跟着换（复核方法见第 23 章复盘）；
• 增量轮按第 10 章接入自动化任务，每日推送至 IM；深研轮触发时单独提醒发起人，由人决定是否启动。

本章验收：为一个真实的持续分析需求（选型、竞品或行业跟踪）建立监控清单与评估维度表，增量轮连续运行五个工作日（其中至少一次如实输出"今日无实质变化"），并完成一份按"事实/推断/建议"三级标注、关键数字全部双源核验的深研报告。

场景：60 秒演示视频，从一份功能文档开始

产品下周上线"批量导入"功能，需要一支 60 秒演示短视频：产品截图、功能动效、字幕，发在官网与三个社交平台。传统做法要串起文案、设计、剪辑三个工种排期一周；桌面 Agent 的做法是把这条流水线装进一个任务，两天交付。

这类任务的特征是工序固定、产物分层：脚本、分镜、素材、成片是层层递进的独立产物。需要多角色深度分工与交接设计时，见第 24 章；本章先解决单人单任务能跑通的基础版。

三个中间产物：脚本、分镜脚本、素材清单

从功能文档到成片，中间只设三个产物，每一个都是一次人工检查点：

中间产物即检查点——这是流水线不返工的关键：脚本确认了才做分镜，分镜确认了才备素材；每一层的改动只牵动下一层，而不是整条链重来。三个产物按目录分文件存档：

video-批量导入/
├── 01-脚本.md
├── 02-分镜.md
├── 03-素材清单.md
├── assets/          # 只收版权状态明确的素材
└── output/          # 成片与平台版本

下达任务：任务书模板

【任务：批量导入功能演示短视频，60 秒】
素材基础：docs/功能说明-v2.3.md、screenshots/ 目录、动效录屏 raw/demo.mov。
目标观众：一线业务员，第一次接触这个功能。
核心信息只有一条：过去 3 分钟的手工录入，现在 10 秒完成。
请先产出脚本（第一个中间产物），暂不做分镜与素材：
- 逐秒时间轴，总长不超过 60 秒；
- 每个卖点标注功能文档的章节号作为依据；
- 前 3 秒钩子单独写两个备选；
- 结尾落在"去帮助中心搜'批量导入'"。
脚本经我确认后再进入分镜环节。

逐产物确认：放行模板

分镜脚本已审，两处修改后放行素材环节：
1. 镜头 4 的动效描述太抽象，改为 screenshots/import-02.png 逐级放大；
2. 镜头 7 结尾补一张字幕卡："详见帮助中心 - 批量导入"。
按修订版生成素材清单：逐项标注来源与版权状态，
标注"待查"的素材一律列为缺口，不得进入 assets/ 目录；
缺口里我们自己能录的（操作录屏）整理成录制清单给我。

两个模板合起来构成"下达—放行"的节奏：任务书把全部变量（观众、核心信息、时长、素材基础）一次说清，放行指令只做局部修订——修订永远只针对单一产物，这正是分层存档的价值。

两天交付的实际节奏

本章案例的真实时间线，供对照排期：

人的总投入约 90 分钟，其余时间流水线自走。对比排期一周的传统流程，省下的不是"做"的时间，而是工序之间互相等待的时间。

全自动还是半自动：按四个维度选

本章案例走半自动：对外发布、含产品承诺，三个产物节点全部人工确认。同一条流水线做内部培训视频时可以切成全自动——模式不是信仰，是对单条内容的成本核算。

多平台版本：一次生产，三处改编

成片之外，同一批产物直接派生平台版本：竖版短视频（前 3 秒钩子、字幕加大）、图文帖（关键帧截图 + 步骤说明）、纯文字版（口语化改写，去掉依赖画面的表述）。改编不是裁剪——竖版要重排信息顺序，这活儿 Agent 做得比人快，但改完的版本同样要过人工终审。

三个改编版本各有各的检查点：

• 竖版：钩子是否落在前 3 秒、字幕在小屏上是否可读；
• 图文帖：每张卡片图脱离上下文也能独立看懂；
• 纯文字版：是否还残留"如图所示"式依赖画面的表述。

风险与人工关口

• 版权关口：素材清单上"来源待查"的条目永远进不了 assets/，音乐与字体单独核权；
• 事实关口：视频里出现的参数与承诺，逐条回功能文档核对，不得为戏剧效果放大数字；
• 发布关口：成片外发前人工终审——与第 20 章同一条铁律，内容责任无法外包给工具。

常见失败与返工

本章验收：从一份真实文档出发，产出一条 60 秒以内的演示视频；三个中间产物（脚本、分镜、素材清单）留档可查；素材清单中无版权状态不明的条目；并产出至少一个平台改编版本。

增长循环四环节：努力只是其中一环

多数创作者的日常是：今天想到一个题，写一篇，发出去，看数据，失望，明天再来。这是打一枪换一个地方，不是经营账号。账号增长是一条循环，四个环节缺一不可：

        ┌─────────────────────────────────────────────┐
        ↑                                             │
   选题库建设  →  批量生产  →  多平台分发  →  数据回流
  （攒候选）     （集中做）    （改编分发）    （回填选题库）

• 选题库建设：持续把评论区问题、搜索联想词、行业事件攒进一个候选池，让"写什么"永远不依赖当天灵感；
• 批量生产：每周集中一段时间批量成稿，把启动成本摊薄在 7 条而不是 1 条上；
• 多平台分发：一稿多平台改编，而不是一稿原样群发；
• 数据回流：每条内容发布后的表现数据回填选题库，决定下周候选的优先级。

四环节里"批量生产"是被普遍高估的那个——AI 时代单条内容的生产成本已经很低，真正的稀缺是选题库的厚度和数据回流的纪律。

选题四问：候选池的过滤网

选题库进多少条不是本事，留得下什么才是。每条候选过四问：

四问全过的候选进"本周待产"；过三问的留在库里等素材补齐；过两问以下的直接删——选题库不是越满越好。

案例实战：一个职场干货账号的三十天

账号设定：定位"跨部门协作"，主平台发长文，同步短视频与图文社区。以下是其第一个月的运转记录。

第一周：冷启动选题库。 原料只有两样：主平台后台三个月的评论区提问（87 条），和后台搜索来源词里的高频联想词。入库指令：

【选题库入库：每周日晚】
请整理本周选题原料，更新 选题库.md：
1. 评论区问题：从平台后台导出的本周评论中筛出"提问类"，
   每条记录：原话、平台、点赞数、是否与库内选题重复；
2. 搜索联想词：把本周进入账号主页的 top10 搜索词与上周对比，新增的记录在案；
3. 合并去重后按"选题四问"逐条预打分，四问全过与过三问的分别列出；
4. 输出周报：新增 X 条、淘汰 Y 条、累计 Z 条，
   拿不准的边界案例单独列出等我定。

冷启动那周入库 23 条，四问全过 6 条。

第二周：一次批量生产 7 条。 排期表：

周二下午的人工过稿是全周唯一人工关口，但成本被压缩到"看初稿、标问题"——因为事实核对已经在周一前置完成（素材调用走第 16 章的知识库）。

持续运转：平台分发适配清单。

指标表：只盯三个数

数据回流环节最大的坑是指标贪多。只盯三个：

三个数每周汇成一行回填选题库：完播高收藏低的选题偏"好看不耐用"，互动高完播低的选题偏"标题强内容弱"——归因时永远把平台因素与内容因素分两栏记录。

周复盘指令模板（每周日晚运行）：

【周复盘：数据回流】
请汇总 数据表.md 中本周发布内容的三个核心指标，输出周复盘：
1. 每条内容一行：标题、平台、完读/完播率、互动率、收藏率、
   归因分两栏（内容因素 / 平台因素），只写有据的归因，猜测标"待观察"；
2. 本周最优与最差各一条，展开分析差异在哪一环
   （选题、标题、开头结构、发布时间）；
3. 回填选题库：给库里未生产的候选重新排优先级，
   与本周高表现内容同类的候选加分，同类连续两轮低分的降级；
4. 输出下周建议生产的条数与选题方向，理由附数据。

这条指令在第 30 天的产出，就是月度循环的收口：选题库的优先级由数据说了算，而不是由"我觉得"说了算。

风险与人工关口

• 发布前人工终审：标题终选与事实核对在人，内容责任无法外包；
• 数据回流由 Agent 自动汇总（第 10 章自动化任务），但归因结论是否采纳、下周优先级怎么调，人说了算；
• 批量生产不等于批量注水：选题四问挂掉的条目宁可不发，账号可信度是复利资产；
• 评论区提问入库时隐去用户身份信息，平台导出的数据不离开授权范围。

本章验收：跑通一个完整的月度循环——选题库累计不少于 20 条候选、完成至少一次 5 条以上的批量生产、多平台适配分发到位、数据回填后用三个核心指标完成一次周复盘，并据复盘实际调整了下一周的选题优先级。

GEO 是什么：入口从"链接列表"变成"一段回答"

过去用户在搜索框里查"少儿编程哪家好"，得到十条链接，点谁看运气；现在用户直接问 AI 助手同一个问题，得到一段现成答案——机构名字、理由、甚至价格区间都替用户总结好了。被 AI 答案提到，就是新的流量入口；不被提到，等于不存在。GEO（生成引擎优化）做的就是这件事：让你的内容更容易成为 AI 回答里被采纳、被转述的那个来源。

它与传统 SEO 不是一回事：

一句话记住差异：SEO 是优化给爬虫看，GEO 是优化给"替用户做总结的引擎"看——后者对可验证性的胃口远大于对文采的胃口。

被发现三步：盘点、改造、监测

第一步：内容资产盘点。 优化之前先盘家底：

第二步：结构化改造。 把缺口表里的问题逐个补成"结论 + 数据 + 出处"形态的公开页面——散落在内部课件和朋友圈里的数字，引擎引用不到。

第三步：提问监测。 定期在主流 AI 搜索中输入固定问题清单，记录被采纳情况，逐轮累积：

案例实战：一家少儿编程机构的 GEO 实践

背景：一家本地少儿编程机构，两年发了 140 篇公众号推文，招生线索却越来越依赖老客转介绍——家长开始在 AI 助手里问"附近少儿编程怎么选"，答案里从来没有它。

第一步产出：目标问题清单 10 条（从 300 条客服咨询记录聚类而来，措辞此后固定不变）：

1. 附近哪家少儿编程机构靠谱？
2. 孩子几岁开始学编程合适？
3. Scratch 和 Python 应该先学哪个？
4. 学编程会不会影响主科成绩？
5. 少儿编程一年大概要花多少钱？
6. 线上编程课和线下课怎么选？
7. 信息学奥赛对升学有帮助吗？
8. 怎么判断孩子适不适合学编程？
9. 编程等级考试证书有用吗？
10. 家长完全不懂编程，能辅导孩子吗？

清单里刻意保留了两条机构并无优势的问题（Q08、Q10）——监测竞对如何回答它们，本身就是下一轮内容策略的输入。措辞固定后每轮逐字使用：改一个字，轮次之间就失去可比性。

第二步产出：内容改造前后对照（节选）：

第三步产出：提问监测记录（首轮节选）：

首轮 10 个问题：点名引用 1 次、部分转述 3 次——对两个月前在 AI 答案里"完全不存在"的机构，这就是起步线。

监测轮指令模板：

【GEO 提问监测：每月第一周】
请在三个主流 AI 搜索中分别输入 geo-questions.md 里的 10 个固定问题（逐字原句），
逐条追加到 提问监测表.xlsx：
1. 采纳情况：未采纳 / 部分转述 / 点名引用，被转述的记录原句；
2. 同台来源：每个问题本轮被引擎引用的全部来源，按出现顺序记录；
3. 缺口初判：我们未被采纳的问题，初判是无内容、结论含糊还是数据无出处。
注意：同一问题两轮结果波动是正常的，如实记录即可，
不要反复重测去挑"好看"的那一次；三轮统计之后再下结论。

三个引擎要分开记录、分开解读：不同引擎的引用口味差异很大——有的偏爱百科与媒体报道，有的偏爱第一手数据页。首轮监测的意义不是下结论，而是摸清每个引擎在这些问题上"愿意引用谁"，为下一轮改造提供靶子。

可引用性自检：五条过关标准

每篇要对外发布的内容，过一遍这五条：

1. 直答性：第一段是否直接回答一个具体问题，而不是先讲品牌故事；
2. 数值化：关键主张有没有数字支撑，数字有没有统计口径与时间；
3. 出处完整：外部数据带链接，内部数据说明样本量与来源；
4. 边界诚实：写清结论在什么条件下不成立（年龄段、地区、班型）；
5. 时效可查：页面标注最近更新日期，过期数据明确标注"历史口径"。

其中"边界诚实"最反直觉也最值钱：敢写"什么情况下不选我们"的机构，在生成引擎的可信度排序里往往反而靠前。

风险与人工关口

• 严禁编造数据：生成引擎对来源可信度的记忆是累积的，一次造假，之后所有内容的采纳概率一起受损——这是本章唯一不可妥协的红线；
• 监测结论以三轮以上统计为准，单轮波动不构成判断；
• GEO 是以季度计的内容工程，不是一次性技巧——建议把它挂进第 20 章内容循环的"多平台分发"环节，成为每月的固定分支。

本章验收：为一个真实业务（你的产品、机构或账号）建立 10 条措辞固定的目标问题清单，完成内容资产盘点与一轮结构化改造（至少 3 处"改造前后"留档），并跑完首轮提问监测——监测表覆盖全部 10 问的采纳情况，且每条未采纳问题都附一条待补内容的具体行动计划。

覆盖第 22–25 章：把跑通的案例蒸馏为可复用的 Skill、用复盘把一次成功变成一套方法、设计多 Agent 协作系统、让自动化工作流可靠运转。前两篇解决"用起来"，本篇解决"留下来"——让每个跑通的案例，都变成一句指令就能重演的资产。

判断你是否需要本篇的标准很简单：同一个任务，你是否已经用几乎相同的指令做过第二次。如果是，你已经在为"没有系统"支付重复成本。本篇四章是一条资产化工序：第 22 章把案例蒸馏成 Skill，第 23 章用复盘把经验变成方法，第 24 章把多个角色组装成协作系统，第 25 章让系统在无人值守时依然可靠。

本章与第 5 章的分工

一句话说清：第 5 章回答"Skill 是什么、怎么从零造一个"，本章回答"怎么从你已经跑通的实战案例里蒸馏 Skill，并把它当工程资产来管理"。第 5 章的概念——SKILL.md 结构、渐进式披露、四步校准、Evals、四层能力分层——本章直接引用不再展开；本章补上的是从"第二次重复"到"可交接资产"之间的完整工序。

完整走一个案例：每周竞品价格监控周报

蒸馏 Skill 最好的原料不是想象中的完美流程，而是你自己手动跑通过三次以上的真实任务。以"每周竞品价格监控周报"为例，完整走一遍。

第 1 周：手动跑通。 你给 Agent 下达这样一条指令：

查一下 A、B、C 三家竞品官网的价格页（链接见下），整理成表格：
产品型号 | 竞品A价格 | 竞品B价格 | 竞品C价格 | 我方价格 | 价差%
另外看看有没有新品上架或套餐变化，单独列出来。

这一轮产物粗糙：列名不统一、价差口径时有时无、新品信息散在表格备注里。你返工两次，补了一句"价差按我方价格减竞品价格再除以竞品价格"，又补了"每行标注采集日期"。跑通了。

第 2、3 周：重复中出现信号。 第二周你把上周的指令翻出来，改了改又发了一遍；第三周重复。把三次指令并排一比，真相浮现——每次变的只有一小截，其余全是原样复制：

固定的部分，就是 Skill 的主体；变量的部分，就是使用时的参数。识别到这一步，蒸馏的条件就齐了。

提炼固定流程与验收。 别急着写 SKILL.md，先按第 5 章的四步校准过一遍：输出（周报 xlsx：六列表格 + 变动说明段）；输入（竞品价格页链接清单、我方价目表）；流程（抓取 → 比对 → 算价差 → 标变动 → 落表）；验证（价格数字能在官网页面上找到、价差重算一致、缺货写"缺货"不写 0）。四步都答得上来，再动笔。

落成 price-watch Skill。 完整的 SKILL.md 示例：

---
name: competitor-price-watch
description: 每周竞品价格监控周报。当用户提到"竞品价格、价格周报、
  价格监控"时使用。输入为本周的关注重点，其余信息从本 Skill 的
  固定配置读取。
version: 1.0.0
---

收到价格监控任务后：
1. 读取 references/竞品清单.md（链接、产品对照表、我方价格）；
2. 逐个抓取价格页，记录每个产品的当前售价与采集日期；
3. 按固定口径计算价差：价差% = (我方价格 - 竞品价格) / 竞品价格 × 100；
4. 单独列出三类变动：调价、新品上架、套餐/促销变化；
5. 生成本周周报：output/价格周报-YYYYMMDD.xlsx（六列固定表头）
   + 一段不超过 150 字的摘要（本周最大变动是什么、建议关注什么）。

交付前检查：
- 每个价格数字可回溯到具体页面，抽查 3 个能对上；
- 价差列抽 2 行人工重算，口径一致；
- 抓取失败的竞品在周报首行标注"本周未获取"，不许留空、不许填旧价。

禁止：用上周数据补本周空缺；把"缺货"写成 0；修改 references/ 下任何文件。

注意这个 Skill 的结构基因：固定信息（竞品清单）进了 references/，变量（本周关注重点）留在使用时的指令里，验收标准写成了可勾选的条款——这三点分别对应渐进式披露、参数化、可验收。

三问过滤：一个流程值不值得做成 Skill

不是每个跑通的案例都值得蒸馏。动手前先过三问：

三问的组合决定处理方式：

三问过滤的价值在于挡住两种浪费：给低频任务过度建设，和给未成熟流程过早定型。

SKILL.md 的写作要领

（本节沿用第 5 章以来的原创要领，此处汇总并补两条实战条款。）

补充的两条实战条款：一是把每次返工的修正直接写进步骤——上面案例里"价差口径"那句话，就是第二次返工时补的，它必须从你的记忆搬进 SKILL.md；二是变量与常量分开——会变的写在使用指令里，不变的写进 Skill 和 references/，混在一起的话，每次参数变化都要改 Skill 本体。

Skill 的工程化管理

个人随手写三五个 Skill 不需要管理；一旦超过十个、或开始给团队共享，就需要四样基础设施。

语义化版本。 用版本号标记 Skill 的成熟度：v0.x 表示试用版（自己还在迭代，别扩散）；v1.0 表示定稿版（流程与验收稳定，可以给别人用）。此后每次对外可见的改动升一位：修缺陷升 0.0.1，加能力升 0.1.0，改到不兼容旧用法（比如输出格式变了）升主版本。判断"该不该发给别人"从此有了客观标准：看版本号第一位。

变更记录。 在 Skill 目录下维护 CHANGELOG.md，每次改动记三行：

## 1.1.0  2025-07-14
- 新增：周报摘要末尾附"连续三周涨价产品"提示
- 原因：使用者反馈需要趋势信号，而不只是当周快照

变更记录回答的是三个月后的那个问题："这个 Skill 为什么是现在这个样子？"没有它，要么不敢改（怕改坏），要么乱改（没人知道改了什么）。它同时是第 5 章 Evals 回归测试的输入：每次改动跑一遍评估集，确认旧行为没被改坏。

命名规范：动词 + 对象 + 场景。 competitor-price-watch（监控·竞品价格·周报场景）、summarize-meeting-minutes（生成·会议纪要）。命名的价值在检索：半年后你只记得"那个管价格的东西"，动词+对象的组合能让它在列表里被一眼认出。避免 my-skill-2、final 这类名字——它们在第三个 Skill 出现时就会失效。

团队 Skill 库与上架前检查单。 团队共享的 Skill 建议集中在一个共享目录，每个 Skill 上架前过一遍检查单：

• [ ] 版本号 ≥ 1.0.0，已连续稳定使用一个月；
• [ ] description 写明了触发场景与不适用场景；
• [ ] 附至少一个演示任务（输入样例 + 期望输出）；
• [ ] references/ 中的配置不含个人信息与凭证；
• [ ] 有明确的维护人，CHANGELOG 完整。

上架前检查单的最后一项最容易被忽略：没有维护人的 Skill 上架之日，就是它开始腐坏之日。

交接边界：蒸馏完成的 Skill 如何交给别人

Skill 写完只算完成一半，另一半是别人能不能用起来。交接需要两样东西，缺一不可：

1. README 一段话：这个 Skill 干什么、什么时候用、什么时候别用、输入要准备什么。不超过十行——写不进十行说明你自己还没想清楚边界；
2. 一个演示任务：demo/ 目录里放一组真实输入和对应的期望输出。接手的人跑一遍演示任务，产物与期望输出对得上，就完成了信任建立；对不上，说明交接材料有问题，而不是使用者的水平问题。

交接边界的验收标准只有一条：另一个人（或另一个全新会话）不问你任何问题，只凭 Skill 文件和演示任务，复现出合格产物。 做不到，回来补材料，而不是让使用者去猜。

风险与人工关口

• 过时失修：竞品改版、价格页 URL 变更会让 Skill 静默失效——对策是在 SKILL.md 里标注"检查周期"（如每季度复核一次 references/ 的链接有效性）；
• 越改越胖：每次迭代都加条款，主流程膨胀到一页放不下——对策是定期把低频细节移入 references/，主文件只保留主干流程与验收；
• 凭证安全：references/ 里的链接与配置不得包含账号密码，需要凭证的环节走第 9 章的环境变量方案。

本章验收：挑一个你手动跑通过三次的任务，按三问过滤确认值得蒸馏，写出 v1.0 的 SKILL.md（含验收条款与 references/），配好 demo/ 演示任务，然后换一个全新会话只用一句指令复现出合格产物。

为什么要复盘

不复盘，成功就只是一段聊天记录。具体地说，不复盘会让你持续支付三笔账：重复成本（下次同类任务，还得从头摸索指令）；归因成本（成功了不知道为什么成功，失败了不知道错在哪一环）；移交成本（你休假或离职，这条能力随聊天记录一起消失）。

复盘还有一个常被低估的判断：错例比成功更值钱。成功证明一条路走得通，错例标出所有走不通的路。只记成功不记返工的复盘，价值减半。本章给的四样工具——任务卡、返工日志、五个为什么、复盘四栏——前两样攒原料，后两样做分析，最后用节奏表和产出去向表保证复盘不烂尾。

任务卡：复盘的最小单元

每跑通一个任务，花十分钟填这张卡：

填写纪律比表格本身更重要：当天填——隔三天再填，"返工原因"基本会写成"记不清了"；流程栏从任务记录里摘，不要凭记忆写——任务记录里有真实的执行顺序和报错，凭记忆写的流程会自动美化；迭代栏是全卡最值钱的一栏——返工原因写清楚，下次的任务说明就知道往哪里加一句话。

返工日志法：十次返工里藏着 Skill 的雏形

任务卡按"任务"为单位，返工日志按"次"为单位——每返工一次，记一行。格式越简越好，超过一分钟就记不完：

【返工日志：PPT 数据汇报任务】
# | 时间   | 为何返工                 | 怎么修的
1 | 14:02 | 表格里混入了去年旧数据    | 指令加"只用 2025 年 sheet"
2 | 14:15 | 环比算成了同比            | 明确"环比=对上月"
3 | 14:40 | 图表数字与表格对不上      | 要求图表引用表格单元格，不许重算
4 | 15:10 | PPT 第 3 页引用了无来源数据 | 指令加"所有数字标注出处"

记满十次，做一次横向扫读：反复出现的"为何返工"，就是下一次任务说明里该前置写死的条款；反复出现的"怎么修的"，就是 Skill 步骤的原材料。 上面这份日志里，第 2、3、4 条全是"口径没说清"一族——它们合起来就是一条 Skill 铁律：凡涉及数字，先写口径，再让它动手。第 22 章的蒸馏工序，原料正是从这里来。

五个为什么：追到口径那一层

返工日志记的是表象，真因要靠追问。以"PPT 数据对不上"为例，演示一条完整的追问链：

现象：汇报 PPT 第 5 页的营收数字与源表格不一致
为什么 1：Agent 用错了数据 —— 它算的是含税口径
为什么 2：它怎么知道要含税？—— 任务说明里没写口径
为什么 3：为什么没写？—— 我默认"营收"就是不含税，没意识到存在歧义
为什么 4：为什么没意识到歧义？—— 上次任务的数据源只有一列，这次有两列
为什么 5：为什么没检查数据源变化？—— 任务说明模板里没有"确认字段口径"这一步
真因：任务说明缺少"数字口径确认"环节，而不是"数字算错了"
对策：把"先确认每个金额字段的口径并写进任务说明"加入标准流程，
     而不是只把这一次的数字改对

追问的关键在第三问之后：前三问通常还在"谁做错了"里打转，第四、五问才开始暴露流程缺陷。判断追问是否到位的标准：如果答案是"因为某人/某模型不行"，追问还没到位；如果答案是"因为流程里缺一个环节"，才算追到。 只改数字不改流程，同样的返工下个月再来一次。

复盘四栏：一张表看懂一次任务

返工日志和五个为什么针对"出错"，复盘四栏针对整个任务——不管成功失败都填。四栏是：目标 / 实际 / 差距 / 原因。一个填好的示例：

任务：季度销售复盘 PPT（12 页，给区域经理会使用）

目标：12 页成品，数据全部可溯源，会议前一天 18:00 交付
实际：11 页成品，2 处数字无出处，当天 21:30 交付
差距：少 1 页；2 处数字不可溯源；晚 3.5 小时
原因：① 第 12 页需要的渠道明细表当天下午才拿到（输入晚）
      ② 无出处的 2 处来自我口述补充的"行业经验值"（口径外数据混入）
      ③ 晚点主要耗在等输入和对 ② 的返工上
去哪：① 写入任务卡"前置条件"——渠道表须在交付前 6 小时到位
      ② 经验值单独一页并标注"非源数据"，不再混入正文 → 教训清单
      ③ 本次不建 Skill（季度一次，频次不过关），指令存指令库

四栏的纪律：差距只写事实，原因只写归因，去哪一行必须出现——没有"去哪"的四栏表只是情绪记录。"去哪"的具体选项见下一节的产出去向表。

教训清单：最小但最高频的沉淀物

产出去向表里"记教训清单"一栏值得单独展开，因为它是使用频率最高的资产——每次写任务说明前扫一遍，三十秒挡掉一批已知坑。教训清单的条目格式固定三段：坑是什么 / 一句话避法 / 来自哪次任务。

【教训清单.md】（持续追加，只增不改）
# 金额字段先问口径 —— 含税不含税写进任务说明再动手（2025-06 销售复盘）
# 带日期的数据先看年份 —— 上游重发旧文件时，新任务会误当新数据（2025-07 周报）
# 转写里的"下周"没有锚点 —— 让 Agent 先把相对时间换算成绝对日期（2025-07 会议纪要）
# 图表数字必须引用单元格 —— 让它重算必出两套数（2025-08 汇报 PPT）

判断一条教训写得好不好：避法必须是可执行的句子，而不是提醒。"注意数据时效"没有约束力，"先看文件年份再动手"有。清单超过四十条时按主题分组，但不要删——被删掉的教训通常会在最贵的一次返工里回来。

复盘节奏表：三个刻度

复盘最大的敌人不是不会，是不持续。用三个时间刻度把它钉进日历：

三个刻度分工明确：单任务攒原料，每周做分流，每季做治理。每周 30 分钟是整个体系的枢纽——把一周的返工日志摊开扫一遍，标记出"同类第三次出现"的条目，它们就是进入第 22 章蒸馏工序的候选。

产出去向表：复盘完的东西去哪

复盘最常见的死法是"填完就归档吃灰"。每条复盘产出必须有一个明确去向，五选一：

第五个去向和前四个同样重要：什么都舍不得丢的知识库，三个月后就没人检索了。每条产出在复盘时就被指定去向，"先存着以后看"不是一个合法选项。

风险与人工关口

• 复盘变成形式主义：只填表不使用——对策是把"本月从复盘产出中提炼了几个 Skill / 建了几条自动化"作为唯一硬指标，填卡数量不是指标；
• 把偶然当方法：一次成功可能依赖当时的特殊条件——对策是任务卡"前置条件"一栏诚实标注，"此流程依赖渠道表提前 6 小时到位"比假装通用更有价值；
• 复盘成本失控：单任务复盘超过 15 分钟就说明模板太重——砍栏目，保住"迭代"和"去哪"两栏即可。

本章验收：为你最近的三个任务各填一张任务卡和返工日志；用五个为什么追一次真实返工的真因；在产出去向表中为每条产出指定去向，至少一条进入第 22 章的蒸馏工序。

什么时候需要多个 Agent

多 Agent 不是更高级的默认选项，而是特定条件下的解法。每多一个角色，你都在支付协调成本、上下文成本和错误传染的风险。判断要不要拆，看三个拆分信号：

1. 子任务可并行独立：两个以上的子任务互不依赖、可以同时进行（如资料收集与图表模板准备）；
2. 需要不同工具或资料：子任务各自需要隔离的工具权限或互不重叠的资料集（如图表师只碰数据文件，不碰全文）；
3. 需要独立评审：自己生成、自己检查已经不够，需要一方生产、另一方拿独立标准去验。

三个信号满足任意两个，才值得考虑拆分；一个都不满足，单 Agent 加人工节点就是最优解。

不该拆的反例：一封邮件的润色、一份 PDF 的总结、一张表格的格式化——流程虽有多步，但步与步之间共享同一份上下文、同一组工具，拆开的唯一效果是把一次调用变成五次。记住判断式：角色数量与流程长度无关，与隔离需求有关。 流程长就在关键处加人工确认，而不是加角色。

三种编排模式

拆分确定后，选编排模式。多数多 Agent 系统落在三种模式里：

三条选型经验：默认从流水线接力开始，它最像人类熟悉的工序交接；质量底线类任务（对外交付、合规审查）在流水线末端追加独立评审者，组成评审小组模式；竞标众包只用于"生成成本低、择优标准明确"的场景——如果你说不清"什么叫更好"，多方案只是在多花钱。

完整案例：季度行业研究报告组

以"季度行业研究报告"为例，把三种工件落地。这个任务的特征：信源多且杂、分析有固定框架、图表与正文要互相印证、对外引用必须可核查——三个拆分信号全中。四个角色：资料员（信源清单与抓取）、分析师（框架化分析）、图表师（数据可视化）、审校员（事实核查与引用核对）。

编排流程（流水线接力 + 末端独立评审）：

flowchart TD
    A[下达任务：季度行业研究报告] --> B[资料员：按信源清单抓取与初筛]
    B --> C{检查点1：信源覆盖与抓取质量}
    C -->|确认| D[分析师：按固定框架分析]
    C -->|补信源| B
    D --> E{检查点2：分析框架与结论}
    E -->|确认| F[图表师：数据可视化]
    E -->|存疑| D
    F --> G[审校员：逐条事实核查与引用核对]
    G --> H{检查点3：终稿放行}
    H -->|通过| I[交付：季度行业研究报告.pdf]
    H -->|退回| G

交接规范（Handoff Spec）：每个角色的输入、输出、格式约定、禁止事项，开工前定死。这张表是多 Agent 设计的核心工件：

禁止事项一列不是装饰：多数多 Agent 事故出在"该做什么都写了、不该做什么没写"。例如分析师的禁令"不引入 20-raw/ 之外的信息"，挡住的就是最隐蔽的一类事故——模型凭通识补了个漂亮数字，全链路无人体制能发现它。

黑板模式：共享目录即唯一事实源。四个角色之间不传话、不口头交接，一切信息通过共享工作目录流动——目录就是黑板，文件就是事实：

quarterly-report/
├── 00-task/任务说明.md       # 人写下：范围、期限、验收标准
├── 10-sources/信源清单.md    # 资料员产出
├── 20-raw/                   # 资料员产出：原始材料（信源编号_日期命名）
├── 30-analysis/分析报告.md   # 分析师产出
├── 40-charts/                # 图表师产出：图表 + 数据引用表.md
├── 50-review/审校意见.md     # 审校员产出
└── 90-final/研究报告.pdf     # 三个检查点全过后生成

黑板模式的规则只有三条：下游只读上游的正式产物文件，不读对话；每个角色的产出落在自己的编号目录，编号即工序顺序；同一内容只有一个权威版本，要改就改原文件并留下版本痕迹，不许另存副本。角色间用对话传递内容有三个天然缺陷——转述截断、版本不明、事实分叉；文件传递恰好补齐这三点。判断一个多 Agent 设计是否成熟，就看关键事实是流过对话，还是流过文件。

检查点与熔断

检查点：人必须确认的三个节点。 上图已标出，对应的是错误传播路径上拦截成本最低的三个位置：

检查点数量的原则：宁少而准。每个检查点都要人花真实注意力，五个检查点等于没有检查点——人会疲于点击"确认"。三个是多数流水线的上限；检查点更少时，把它们放在"错误影响面最大"的节点：越靠前的错误传播得越远，所以第一个检查点几乎总是不可省的。

熔断：角色失败时的处理原则。 预先写死，不临场决定：

• 可重试的失败（抓取超时、单信源不可达）：原地重试一次，仍失败则降级——报告标注"该信源本期缺失"，不中止整线；
• 交付物受损的失败（图表生成出错、分析中断）：降级交付——交出已完成部分 + 明确的缺失说明（"第 3 节图表缺失，数据引用表完整"），不伪装成完整成果；
• 方向性失败（分析框架跑偏、审校发现系统性引用错误）：暂停整线，回到出错的工序重做——此时继续跑只是在错误方向上加速。

错误会传染的三种典型与阻断方法：

第三种最隐蔽：它不产生任何报错，只是让整份报告用一套错误的语言自洽地讲完。这也是审校员必须拿独立清单工作、而不是拿生成者的思路工作的原因——评审的独立性是买来的，不是生成的。

成本意识：多 Agent 值不值

多 Agent 的调用成本可以粗估：流水线接力约为单 Agent 的 1.5–2 倍（各角色装载上下文 + 交接校验）；评审小组约 2–3 倍（生成 + 评审 + 至少一轮修订）；竞标众包按方案数线性放大（三方案并行即 3 倍起）。

成本判断的最终标尺不是省了多少钱，而是单位合格产物的成本——一次带独立核查的 3 倍成本交付，常常便宜过三次返工的单 Agent。

另一个容易忽略的成本项是人的注意力：每个检查点、每张 Handoff Spec 表都要人维护。角色越多，设计文档越厚，半年后连你自己都要重新读一遍才能改——这也是"能三个角色就不用六个"的第二层理由。

本章验收：为一个你自己的复杂任务回答三个问题：三个拆分信号中了几个？选哪种编排模式、为什么？写出四行式的 Handoff Spec 表和黑板目录结构，并跑通一次含至少两个检查点的多角色协作。

自动化的天敌

自动化任务一旦"静默失败"——该发没发、发的是错的、发的是上次的——信任就会崩塌。可靠性不是功能，是设计出来的。自动化有四种典型事故，危害递增：

四种事故的共同根源：自动化把"没人看"变成了常态，而错误恰恰在没人看的地方生长。 可靠性设计的全部思路，就是为"没人看"装上替代的眼睛。

可靠性设计清单

六个环节按执行时序排列：输入校验是第一道闸门，文件不存在、日期不对、记录数为零，任何一项命中就不该往下跑；执行日志只记关键节点——每步的开始结束、读了什么、产出了什么，排查时只需回答"错误发生在哪两步之间"；异常处理的原则是"失败要大声"，宁可半夜一条报警吵到你，不要默默吞掉错误；输出自检是最后机会，推送前核对占位符是否填全、关键数字是否来自本次输入、与上次产物的差异是否合理；追溯能力决定事故后的恢复速度；人工抽检是对抗渐进式劣化（信源慢慢变质、格式慢慢走样）的唯一手段——它不会被任何自检规则发现，只能靠人眼定期校准。

降级策略：四档预案

每个自动化任务都应预先回答："如果某一步失败，交付什么？"

正常：完整产物 + 推送
降级：部分产物 + 缺失说明 + 推送
兜底：无产物 + 失败原因 + 报警
禁止：静默失败 / 用旧产物冒充新产物

四档之间的切换规则要预先写死。为每个任务填一张降级卡：

任务名：每日资讯简报
失败场景 1：信源抓取全部失败
  → 兜底：发送"今日信源不可达"通知，不发空简报
失败场景 2：单个信源失败
  → 降级：正常发简报，标注"以下 2 个信源今日缺失"
失败场景 3：推送渠道故障
  → 兜底：产物落盘 + 换备用渠道报警
硬约束：任何情况下不得用昨日简报冒充今日

降级交付必须说明缺了什么，不伪装成完整成果——一份"标注了缺口的部分成果"可以被补救，一份"看起来完整的次品"会摧毁信任。

数据新鲜度防线：别让自动化消费过期输入

四种事故里"内容腐坏"和"旧物冒充"共享同一个源头：自动化在消费过期数据时毫无知觉。输入校验要再细一层，构成三道防线：

水位线值得多说一句：它是防"旧物冒充"的机制核心。没有水位线的任务，处理过的和没处理的数据无法区分，一旦上游补发或重跑旧文件，自动化会把上周的旧数据当新数据再算一遍。水位线文件本身要随产物一起归档（如 output/watermark.txt 写一行"已处理至 2025-06-30"），它同时是排查"这份报告到底吃了哪些数据"的凭据。

三道防线不必靠自觉执行，直接写进自动化任务的执行体（Skill 或固定指令）：

【新鲜度校验指令片段 —— 放在任务第一步】
开始前依次校验，任何一条不通过就停止并报警，不要继续生成：
1. 输入文件 data/sales-YYYYMMDD.csv 是否存在；
2. 文件数据日期是否为今天（或任务约定的时间窗内）；
3. 数据行数是否大于 0；
4. （有水位线的任务）数据最大日期是否晚于 output/watermark.txt
   中记录的"已处理至"日期。
校验失败的消息必须写明：哪条没过、实际值是什么、期望值是什么。

这段片段的价值在于把"防线"从原则变成可粘贴的条款——四条校验任何一条失败，任务的下一步就不该发生。上线前配合故意失败演练逐条验证：每次只破坏一个条件，看它是否真的停了下来。

监控与演练

• 上线前做"故意失败演练"：主动制造故障，验证行为符合降级卡；
• 为自动化建台账：任务名、触发时间、产物位置、负责人、最近抽检；
• 定期清理不再需要的自动化——僵尸任务既耗积分又藏风险。

故意失败演练清单（上线前每项各做一次）：

台账模板（可直接建为电子表格）：

| 任务名 | 触发时间 | 产物位置 | 负责人 | 最近抽检 | 抽检结论 |
|--------|----------|----------|--------|----------|----------|
| 资讯简报 | 每日 09:00 | /outputs/brief/ | 我 | 2025-06-01 | 合格 |
| 周报汇总 | 每周五 17:00 | /outputs/weekly/ | 我 | 待抽检 | — |

台账的"最近抽检"一栏超过一个月为空，就该触发一次抽检。僵尸任务的判别标准：连续一个月没有人读过它的产物——没人消费的自动化，产出再准时也是纯成本。

从单任务可靠到系统可靠

单个自动化的可靠靠清单；一组自动化的可靠靠治理。三条系统级纪律：

1. 共享规范：同一套输入校验、日志格式、降级模板复用到所有任务——规范不一致意味着每次排查都要重新学习；
2. 分级管理：按后果严重性分级，对外推送类高于对内参考类，级别越高，抽检频率和降级要求越严；
3. 依赖显性化：任务 A 依赖任务 B 的产物时，台账里必须写明——B 停了 A 会怎样，要提前有答案，而不是事故后才发现连坐。

最后回到信任：自动化的终极产出不是产物，而是你可以不看它的心理状态。这个状态只能靠可靠性设计一点点挣得，并且会被一次静默失败瞬间清零——这正是"禁止旧物冒充"必须写成铁律的原因。

本章验收：给你第 10 章建立的自动化任务补齐日志、降级四档预案与抽检台账，完成一次故意失败演练，并为至少一个任务加上数据新鲜度三道防线（时间戳校验、水位线、空数据告警）中的两道。

覆盖第 26–27 章。前三篇解决的是"一个人如何把桌面端 Agent 用好"，这一篇回答组织层面的两个问题：不同岗位各自从哪个场景切入、按什么节奏扩大使用；一个组织如何把散落的个人经验，升级为带验收与边界的行业化工作系统。读完这一篇，你应该能拿出两样东西：一张属于自己岗位的场景立项单，一份本行业的可自动化工序与不可自动化关口清单。

26.1 从哪里切入：三个先决问题

岗位置换不了提示词，能置换的只有场景选择。动手之前先回答三个问题，答案直接决定你该做什么、不该做什么：

• 哪些工作在你身上每周重复发生？ 每周都在做的事才值得投入建设成本，一年一次的事临时对话即可；
• 哪些产物有公认的验收标准？ 有标准的产物（周报、清单、核对表）才适合固化；标准还在漂移的产物，先和团队把标准谈拢，再谈交给 Agent；
• 哪些决定必须由你签名担责？ 对外承诺、预算审批、人事判断，Agent 的上限是"把材料备齐"，拍板永远是人。

三个问题分别指向本手册已有的三件工具：重复 → Skill（第 5、22 章）；标准 → 任务卡与验收（第 4、23 章）；责任 → 人工关口（第 25 章）。岗位落地不发明新东西，只是把这些工具按岗位的痛点重新组装。

26.2 推广三阶段：试点、固定、放量

一个场景从"想到"到"团队都在用"，建议按三个阶段推进，每个阶段有明确的放行条件与回退条件：

两条使用原则：

• 影子运行是信任的地基：两周并行对比花的是时间，买到的是"这个场景 AI 具体错在哪"的第一手证据；
• 不是所有场景都要走到放量期。低频、责任重或每次差异大的工作，长期停在"AI 准备材料 + 人做决定"反而是最优解。阶段与风险匹配，比一味往前推更重要。

26.3 产品经理

产品经理近半的时间耗在"把散落的输入变成结构化文档"上，而这恰好是 Agent 最稳的能力区。

指令示例（PRD 初稿）：

请根据附件的三份材料（需求评审会纪要、原型草图、上一版 PRD）起草 PRD 初稿。
要求：章节结构沿用上一版 PRD；
每个需求点标注来源（哪份材料、哪一段）；
与上一版表述冲突的地方单独列"待确认冲突清单"，不要自行取舍；
本文档是初稿，需求范围以我确认为准。

26.4 运营与市场

运营的痛通常不是没想法，而是活动结束后复盘文档拖三周才补、排期全靠脑子记、社群里同样的问题答了三十遍。

指令示例（活动复盘）：

请基于附件整理本次活动的复盘报告。
数据：曝光、点击、转化、ROI，与目标值逐项对比；
执行：按时间线列出关键动作与实际发生时间；
问题：数据异常点与执行延误点，每条附证据出处；
建议：三条可执行建议，各自标注预期影响，不要写成口号。

26.5 销售与售前

销售的时间最贵，Agent 的价值是把拜访前一小时的手忙脚乱，变成十分钟的成套材料。

指令示例（拜访前准备包）：

我明天下午拜访【客户名】，请生成一份准备包。
背景：一屏以内，只保留与本次拜访相关的信息；
近况：近 3 个月公开动态，每条附来源链接与日期；
切入话题：结合我方产品（见附件简介）给出 3 个，
每个话题标注依据是哪条动态，推测性话题明确标"推测"；
只用 12 个月内的信息，无法核实的一律标"未证实"。

26.6 HR 与行政

HR 与行政掌握全公司最敏感的数据（薪酬、评价、身份信息），原则是：能力上大胆用，数据上最小给。

指令示例（简历摘要）：

请为附件中的 12 份简历各生成一页摘要。
每份包含：核心经历时间线、与本岗位要求的匹配点、
存疑点（空窗期、表述模糊处）、建议追问的面试问题两条。
要求：只做事实归纳，不做录用建议；
与岗位无关的个人信息（年龄、婚育等）不要写入摘要。

26.7 财务与法务

这两个岗位对"与原文一致"的要求接近苛刻——金额、条款、日期错一个字符就是事故。因此 Agent 的角色严格限定为"提取与对照"，判断永远归专业人员。

指令示例（对账差异表）：

请对比附件两个文件：本月账单与银行流水。
先给出你拟用的匹配规则（建议：金额完全相等 + 日期相差 3 天以内），
我确认后再出表。
输出差异表：序号 | 账单侧记录 | 流水侧记录 | 差异类型。
要求：金额与日期逐字引用原文，不做四舍五入；
匹配不上的归入"待人工核查"，不要强行配对。

26.8 研发与 IT

研发的产物正确性可以机器验证（编译、测试、监控指标），所以最容易走到放量期；但生产环境一旦出事，影响面也最大。

指令示例（上线前检查单）：

请根据附件生成本次上线的检查单。
基础项：配置核对、数据库变更、回滚方案、监控告警是否就绪；
历史项：从过去 5 次上线复盘（附件）中提取曾出错的环节，
逐条转为检查项并标注出自哪次复盘；
输出为可勾选清单，每项写明由谁负责确认。

补充一句：当某个场景复杂到单次对话装不下（如多模块的发布流程），再考虑按第 24 章的多 Agent 编排拆分——用交接规范定义传递物，用检查点与熔断兜底；拆分之前，先把单流程跑稳。

26.9 场景立项单：动手前的一页纸

每个岗位从上表先选一个场景，填这张立项单再动手。它不是审批形式，作用是强迫你在写下第一行指令之前，先想清楚回退预案：

填好的示例（运营岗，场景：三平台数据周复盘）：

26.10 推广中的三种失败模式

岗位落地的终点不是"人人会问 AI"，而是每个岗位沉淀出若干有负责人、有验收、出问题能回退的标准场景——新人接手时，凭文档和 Skill 就能复现。

本章验收：为你自己的岗位填写一张场景立项单，并让选定场景完成至少一周的影子运行对比。

27.1 行业化的本质

通用能力（文档、数据、内容）每个行业都用得上，但行业价值藏在三样东西里：行业语料（术语、规范、案例）、行业工作流（工序与交付标准）、行业合规边界（什么能自动化、什么必须持证的人签字）。

三者缺一，行业化就会失败：

• 只有语料没有工作流，产出是"很懂行的聊天"，交不了付；
• 只有工作流没有合规边界，迟早撞上监管或安全事故；
• 只有边界意识没有语料，Agent 说的每句话都需要专家重写一遍。

27.2 行业工作流的三步构建法

1. 盘点：列出本行业高频、高人工成本、标准清晰的工序（如门店日报、病历摘要、标书初稿、合规检查表）。盘点时同时记录每道工序的责任人与现有人工耗时，这是后面算 ROI 的基线；
2. 组装：通用能力 + 行业 Skill（规范、模板、术语表）+ 行业连接器（业务系统）。组装顺序是先 Skill 后连接器——先用本地文件跑通流程，再接系统打通数据；
3. 设界：明确人工关口（签字、复核、外发）与数据边界（客户数据不出授权范围）。设界要在自动化上线之前完成，而不是出事之后补。

27.3 行业示例方向

下表给出六个方向的切入参考。前三个与第 26 章各岗位场景可直接衔接，后三个说明同一方法如何迁移到合规更重的领域：

两个补充说明：

• 医疗方向：Agent 定位为医护的文档助手，不接触诊断决策。病历摘要的验收标准是"每个临床表述可回到原始记录"；患者身份信息按最小必要脱敏后再进入任务；
• 电商与教育方向：共同特点是量大、模板化程度高、出错可承受度中等——最适合按第 26 章的三阶段从试点期起步，观察一个季度再决定是否进入放量期。

27.4 组织落地的四个顺序

1. 先试点期再放量期，顺序不能反。团队级的工作流与多 Agent 编排，素材来自大量个人级场景的影子运行记录与任务卡；没有这些，编排搭起来了，里面却没有一个经过验收的流程。跳步的典型症状是：系统很热闹，产物没人敢用；
2. 先低风险场景建信任，再碰核心流程。第一批场景的选择标准是"错了能改、损失可控"。信任不是宣讲出来的，是影子运行两周的对比数据攒出来的。核心流程（财务、医疗、生产）永远放在信任建立之后；
3. 先沉淀 Skill 与知识库这些资产，再谈规模化。规模化放大的不只是效率，还有错误。资产先行的判断标志（第 5 章）：经验存在文件里，而不是聊天记录里；
4. 权限、成本、审计制度先行，自动化后行。自动化是无人值守的，制度是其唯一的护栏。上线任何自动化之前先回答：授权范围多大、每月成本上限多少、出事找谁、日志在哪。答不出这四问的自动化不该上线。

27.5 数据边界分级

行业化绕不开数据问题。建议把所有可能进入任务的数据分为三级，分级规则先于场景推广成文：

三条补充规则：

• 一份材料的级别由它最敏感的成分决定，混装文件按最高级处理；
• 影子运行与自动化任务同样受边界约束——对比样本要脱敏，定时任务的数据源要经审批（第 25 章）；
• 分级标准写入行业检查清单，新场景立项时逐条对照，而不是靠当事人临场判断。

27.6 推广中的常见失败模式与对策

27.7 ROI 度量思路

行业落地绕不开"值不值"的追问。建议从三个口径度量，立项时先记基线，否则事后无法计算：

三条务实原则：

• 只度量场景立项单上登记的场景，不要用全公司口径的宏大数字；
• 成本侧记三类：模型与积分消耗、人的验收工时、资产维护工时；
• 观察周期至少一个完整业务周期（月度工序看一个月，季度工序看一个季度），单周数据不足为凭。

27.8 落地检查清单

组织级推广进入规模化之前，逐项核对：

• [ ] 每个已推广场景有填好的场景立项单（第 26 章）与影子运行记录；
• [ ] 每个场景明确标注了人工关口，且关口有具体的人；
• [ ] 沉淀的 Skill 有负责人、有版本记录、出问题可追溯；
• [ ] 数据边界按三级分级成文（27.5 节），新场景立项时逐条对照；
• [ ] 自动化任务有日志、降级策略与抽检台账（第 25 章）；
• [ ] 成本有预算上限，超出即报警而非静默扣减；
• [ ] ROI 三口径的基线已在立项时记录；
• [ ] 新人可以只凭文档和 Skill 复现任一标准工作流。

八项全过，才谈"规模化"；任何一项缺失，先补齐再扩张。

本章验收：为你所在行业列出"可自动化工序清单"与"不可自动化关口清单"各五条，并为其中一道工序标注数据分级与处理规则。

A.1 文件整理

请整理当前文件夹中的文件。
按文件类型和主题分类，生成新的文件夹结构。
在执行前先给我一个整理方案，不要直接移动文件。

A.2 Excel 分析

请分析这个 Excel 文件。
请输出：核心指标、异常数据、趋势变化、可能原因、建议行动。
请生成一个摘要报告和图表。

A.3 PPT 生成

请根据这份 Word 文档生成一份 PPT 大纲。
要求：10 页左右，每页包含标题、3-4 个要点和建议图表。
风格正式，适合管理层汇报。

A.4 会议纪要

请整理这段会议内容。
输出：会议结论、待办事项、负责人、截止时间、风险点、未决问题。

A.5 行业调研

请调研【行业/公司/产品】。
输出：市场背景、主要玩家、竞品对比、趋势判断、机会点、风险点。
请附上信息来源链接。

A.6 销售方案

请基于客户资料生成一份售前方案。
包括：客户背景、痛点分析、推荐场景、实施路径、预期收益、演示流程。

A.7 任务说明（通用五要素）

目标：【最终要解决什么问题】
输入：【使用哪些文件、目录或链接】
动作：【分析 / 整理 / 转换 / 生成】
约束：【哪些不能改，采用什么规范】
输出：【交付什么文件，什么格式，交给谁】

A.8 Skill 沉淀（SKILL.md 骨架）

---
name: my-workflow
description: 用于【场景描述】，当用户提到【触发词】时使用
---

收到任务后：
1. 【步骤一：动词开头】
2. 【步骤二】
3. 【步骤三】
交付前检查：【验收标准】
禁止：【禁用事项】

完成一个真实任务 → 复盘成可复现案例 → 沉淀 Skill 与自动化 → 组合成协作团队