摘要先看结论：四段演示的成果与可执行的三项动作
1界定交办模式：由人搬运产出改为由 Claude 交付成品
两名讲者各自负责本场演示中的一条真实业务流程。
- Ian Chan 任职于营销运营与分析岗位，负责每周供管理层与营销同事使用的指标回顾，对应演示一。
- Annabel Custer 负责营销活动运营，覆盖自需求受理至线上活动上线的完整链路，对应演示二至演示四。
开场投票的题目为「营销运营中最大的瓶颈是什么」，四个选项与后续演示逐项对应。
- 选项「出报表与取数」对应演示一的周度指标回顾。
- 选项「搭活动与做线上活动」对应演示二与演示四。
- 选项「工具之间打不通」对应演示四的浏览器扩展方案。
- 选项「其他」未在演示中单独处理。
Annabel Custer 以三个年份标定能力演进，本场演示建立在第三阶段之上。
- 2023 年的聊天形态。用户提问并获得回答，任务执行仍由人完成。
- 2025 年的 Claude Code。面向工程师，具备直接修改文件与运行指令的执行能力。
- 2026 年的 Cowork。同等执行能力开放给不写代码的岗位，无须使用终端。
第 08 页将两种模式并排对照，差异集中在产出的交付环节。
- 聊天模式。用户提问、追问并获得文字回答，仍需自行把结果复制到目标系统。
- 交办模式。用户给出目标，Claude 自行检索邮件、起草报告、自文件取数，直接交付可用成品。
- 业务场景对照。前者相当于助理每接一条指令执行一步；后者相当于交代「整理本周会议纪要为一页管理层摘要」，助理自行取材、撰写、自检后提交。
第 09 页把一次交办拆为五个动作，末行标注的行为约束是本页重点。
- 理解。Claude 先就不明确之处提问。
- 拆解。Claude 把任务拆为可执行的条目清单。
- 执行。Claude 跨系统完成各条目。
- 检查。Claude 核对成果的质量与准确性。
- 交付。Claude 提交可直接使用的成品。
第 09 页末行写明 Claude 会提出尖锐问题、指出用户未询问的风险，且不会一味认同用户判断，该行为属刻意设计。
第 10 页以四张卡片收束前半场，分别对应上下文、交办范围、能力复制与执行时机四个维度。
2备齐两项基础：连接界定可见范围，技能界定执行方法
连接指把 Claude 接入团队现有系统，接入后取数环节无须人工执行。Ian Chan 说明数据分布的实际状况与由此产生的差异。
- 部分指标仅存在于客户管理系统，另有部分存于人工维护的表格，其余散落于 Slack 频道与文档。
- 能查询数据库的工具已属常见，差异不在查询本身。
- Claude 的作用是把结构化与非结构化数据一并取出，识别各自的格式，再整理为所需形态。
技能指把团队既有做法写成说明文件，可涵盖模板、报告口径、流程或文案与设计规范。技能建立后，团队任一成员均可调用并得到一致结果。
- 业务场景对照。技能相当于交付给新进人员的作业指导书，差别在于该文件由 Claude 读取执行，且不会遗漏步骤。
- 筛选判据。Ian Chan 给出的判据是同一任务反复执行即应评估写成技能。
- 生成方式。该评估可直接交给 Claude，由它依据日常工作内容推荐候选并生成技能文件。
第 15 页列出周度指标回顾使用的四个技能，名称前的斜杠为调用写法。Ian Chan 说明调用时无须逐字念出技能名称，Claude 可依据当前任务自行匹配，直接要求「执行本周周报」即可。
第 16 页列出活动搭建使用的四个技能，覆盖分派、搭建、查验与数据导入四个环节。两页对照可见技能的粒度按单项业务任务划分，而非按系统或工具划分。
3拆解演示一：周报产出时间由两天压缩至两小时
演示一由 Ian Chan 执行。他每周产出一份指标回顾，供管理层与营销同事在周会使用，该报告原本耗时两天，现为两小时。他声明本次运行在演示环境，流程与每周实际执行的一致。
启动指令为一句话，未附带任何背景说明。Claude 随即进入第一阶段，自行确定本期的时间范围与数据来源。
- Claude 判定本期覆盖 7 月 6 日至 7 月 12 日。
- Claude 识别出当前环境日期为 7 月 14 日，据此判定本期较原定的 7 月 13 日延后一天发布。
- 上述两项判断均未经人工提示。
Claude 随后列出本期数据的七个来源，该表说明了此项工作原本耗时的原因。
- 七个来源中仅 2 个为结构化数据，分别来自数据仓库与客户管理系统。
- 其余 5 个分别为文档、会议记录、Slack 帖子，以及同事人工维护的表格。
- 人工执行该环节须逐个打开来源并逐项抄录。
Claude 接着读取上周报告的评论区，把七条意见中仍未关闭的六条整理为一张表，逐条标明提出人、意见内容与本周状态变化。
Ian Chan 据此说明 Claude 与固定脚本的差异：脚本每次返回同一批指标，即使写入叙述规则，也只能针对脚本可见的指标生成叙述；Claude 能识别本周值得讨论的议题，并自行决定深入分析或回头确认。
销售部门完成组织架构调整后，Claude 主动询问是否需要调整报告口径以匹配新架构。
- Ian Chan 的常规要求是 Claude 一次只处理一项事务。
- 本次 Claude 未等待回复即先行提取指标，Ian Chan 判定该行为可接受，原因是提取指标属必要步骤。
- 他随后收窄指令，仅要求 Claude 就组织调整给出处理建议。
Ian Chan 反复采用的工作方式是先对齐头条，再展开正文。他指出 Claude 在无约束时倾向产出大段连续文字，因此每轮先要求给出三项最重要结论，确认后再扩写。
三条头条的定案形态如下。每条均为完整判断句，写明发生事项、成因与本期处理方式，而非罗列指标名称。
正文完成后自动执行校对，该校对由 Ian Chan 单独建立为技能。他建议凡使用 Claude 产出内容者均应要求 Claude 生成一个校对技能。
- 校对规则一。文档中出现的每一个指标均须可回溯至数据库或数据源中的出处。
- 校对规则二。任何结论性判断均须有对应指标支撑。
- 设立依据。Claude 存在过度自信的情形，会给出未经证实的因果判断，经追问后自行承认表述过头，因此改由规则约束自查。
成品为两份而非一份，依据是两类读者的使用方式不同：管理层先阅读一页幻灯片，需要细节时再查阅文档；执行营销活动的同事直接使用详细版本。两份均为可打开、分享与协作的成品文件，而非聊天窗口内的文字。
第二份为完整周报文档，除执行摘要与指标记分卡外，另设讨论区，单独列出本期尚无结论、须当面确认的事项。
收尾环节由 Claude 执行两项动作。
- Claude 把周报发布至 Slack 对应频道。
- Claude 把本轮提出但决定不处理的事项逐条登记为 Asana 任务，登记时主动询问各事项的负责人；Ian Chan 当场指定其中一项的负责人，另一项判定无须登记。
Ian Chan 在收尾前固定询问本轮应记入的纠正项。Claude 将本次结论写为一条常驻规则补入技能，并另行产出一份修改说明标明改动内容。
他补充一项要求：若 Claude 未主动执行该动作，用户应主动提出，原因是 Claude 具备更新自身技能的能力。
4拆解演示二：把散落的需求转为可追踪的受理流程
演示二由 Annabel Custer 执行，她负责营销活动运营，同事的需求经由一个 Slack 频道提出。她说明本人于 2025 年 8 月入职时即在后台执行这些活动运营工作，当时全部为人工处理。
受理入口为频道内的一个按钮，点击后展开表单，下拉选单提供八种需求类型，每种类型对应 Claude 侧的一个专门技能。
选定类型后展开对应表单，表单字段即 Claude 完成该任务所需的全部信息。
- 字段涵盖提出人、目标客户分层、活动名称、日期与时区、活动说明文档链接，以及所属系列。
- 该设计的作用是把需求的格式在进入环节即固定下来，取代此前散落于聊天记录、须人工回溯的形态。
提交后的需求以结构化消息落在频道内，字段可直接读取。团队以表情反应标记各条状态，Claude 据此判定哪些尚未开始、哪些已在执行。
Claude 承接任务时先在讨论串内认领，消息使用她本人的头像与身份，并附一行「由 Claude 发出」的标注。
- 该消息的作用是防止重复承接。排程任务每小时运行一次，缺少认领消息时，下一次运行会由另一个 Claude 再次承接同一需求。
- 两个 Claude 同时处理同一需求将导致重复建立活动与广告活动。
任务完成后 Claude 发出完工报告，列出生成的全部链接并标出须人工确认的事项。
- 链接涵盖活动平台的直播页、客户管理系统的广告活动、营销自动化平台的邮件与报名看板。
- 待确认事项包含某页面仍为草稿状态须人工发布、某广告活动的负责人默认为她本人，以及一条早先重建时留下的重复记录。
查验为实际执行而非静态检查。第二个 Claude 以测试邮箱在活动页完成一次报名，随后核对该报名是否正确流入客户管理系统、确认信是否发出、页面文案是否存在错字或图片失效。
查验产出两份消息：一份为对外可见的完工说明，另一份仅发给她本人，记载须她知悉但无须需求方看到的问题。她说明每次均完整阅读后一份，并逐条处理其中标出的事项。
5拆解演示三：挂上排程，取消人工监看频道
第一步为接入系统。在对话框点击加号即可展开连接器清单，逐一接入所需系统并确认已启用，同一菜单亦可管理技能与插件。
连接器的作用界定。连接器相当于系统访问凭证，Claude 仅能访问已授予凭证的系统，未授予者无法进入。
第二步为建立技能。画面所示为该配置背后的技能库，条目名称直接对应各自负责的任务，含审核活动落地页、整理记忆、数据导入、企业分析与名单导入。
- 建立方式为逐项累加。她自最简单的数据导入起步，随后逐项增加，而非一次设计完整体系。
- 步骤较多时使用语音口述。依据是待交代的内容篇幅长且跨多个系统，口述效率高于键入。
第三步为挂上排程。她最初按需求类型各挂一个排程任务，分别负责数据导入、活动搭建与线上活动搭建，实际运行后判定数量过多、不易管理。
- 现行配置仅保留一个排程任务，由它扫描频道并把每条需求分派至对应技能。
- 该任务每小时运行一次，需求量大的周次改为每半小时一次。
本屏所示为一次判定无事可做的运行。Claude 扫描七天窗口后，判定三条需求分别为已结案、已关闭且超出范围、已结案，因此全部跳过。
其结论为该窗口确实为空，无待分派事项、无待延后事项、无待标记问题，因此选择静默退出，不发送 Slack 消息、不发送通知、不触及任何生产系统。能够静默地不执行动作与能够完成任务同等重要，否则每小时一次的排程将转为每小时一次的干扰。
6拆解演示四：跨七个系统完成活动搭建，无接口时改用浏览器操作
演示四处理的是部分系统不提供可对接接口的情形，Annabel Custer 给出的方案为浏览器扩展，该方案取消了对现成接口的依赖，对应开场投票中的「工具之间打不通」选项。
- 登录方式为单点登录。Claude 无法键入密码，改由单点登录进入，因此无须交付账号凭证。
- 教学方式为口述既有流程。说明必填字段、点击位置与执行顺序即可，无须为自动化重新设计流程。
Salesforce 环节的处理方式与其余环节不同，构成本段的关键机制。
- Claude 优先调用现有接口。Salesforce 提供 MCP 接口，因此该环节在后台完成，未经浏览器点击。
- 无接口时改用浏览器操作。Goldcast 不提供接口，因此改由浏览器执行。
- 两种方式自动切换，无须人工指定。Claude 默认先检索接口，检索不到才退回浏览器路径。
最终成品为本场讲座的报名页。Annabel Custer 指出该段自动化的价值在于「搭建一场线上活动」这一表述简单的需求实际横跨七个系统与多条流程，现由 Claude 自需求受理执行至页面上线，中途无人工介入。
她给出的适用范围判断是：凡可在浏览器内完成的操作，均具备自动化的条件。
