分角色落地案例

方法只有落到具体岗位上才有意义。这里按岗位整理了真实工作中的改造案例：每个案例都包含原来的痛点、输入目录、WorkBuddy 分步搭建、可复制指令、验收、固化和前后耗时对比。

案例里的耗时是示例基线，用于展示记录方式；请用你自己测量的数字替换它们。

1. 怎么使用这些案例

1. 先用《WorkBuddy 搭建底座》建立通用目录和人工闸门；
2. 找到与你最像的岗位，先只搭建一个案例；
3. 复制案例里的指令，用 3～20 条代表性数据跑通小样；
4. 打开案例卡底部的场景页，补齐该任务的专业检查方法；
5. 记录你的原耗时、输入、步骤、错误和验收结果；
6. 完成一次真实委托后，回到《成长路线》推进。

2. 行政与项目管理：周例会纪要与待办跟催

行政 / 项目助理

把 60 分钟项目周会的录音转写整理成纪要，并跟催上周期待办

!每次会后花 90 分钟写纪要，待办经常漏掉负责人，跟催靠翻聊天记录

改造前每次约 110 分钟

改造后每次约 30 分钟

这样改造

1. 会上只录转写，会后把转写原文 + 上期纪要一起交给 AI
2. AI 先输出结构化表：决定、待办、负责人、截止时间、原文定位
3. 没有明确信息的字段写“未指定”，不推断
4. 人工核对三处：负责人、日期、数字
5. 确认后发群里，并把未完成待办复制进跟催清单

这样验收

• 抽 3 条待办回听原文，口径一致
• 负责人和日期全部来自会议原话
• 与上期纪要的待办状态能对上

纪要 30 分钟内发出；漏掉负责人的情况从每周 2～3 次降到基本没有。

耗时为示例基线，请用你自己的记录为准。查看会议与邮件场景 →

2.1 准备工作空间与输入

创建 AI-Work/周例会-YYYY-MM-DD/，按《WorkBuddy 搭建底座》建立五个子目录。把本周转写、上期纪要和项目成员表复制到 01-原始输入/；在 brief.md 写明会议名称、参会人、纪要接收人和交付时间，在 acceptance.md 写明“每条决定和待办都有原文时间戳”。

2.2 在 WorkBuddy 中分步搭建

1. 选择该文件夹为工作空间，先要求 WorkBuddy 盘点三份输入，不生成纪要；
2. 让它把上期待办整理为“已完成 / 进行中 / 未更新”，只以本周原文为状态依据；
3. 先提取 3 条待办做样本，核对说话人、负责人、日期和时间戳；
4. 样本通过后再提取全部内容，生成 03-待审核交付/会议纪要.md 和 待办清单.xlsx；
5. 人工确认后再移入 04-已确认交付/，由人发群和写入任务系统。

读取 @01-原始输入/本周转写、@01-原始输入/上期纪要 和 @01-原始输入/项目成员表。
先输出决定、行动项、未决问题、风险四张表；每行保留原文时间戳。
负责人、日期或状态未明确时写“未指定”，不要根据职位或语气推断。
先只处理 3 条行动项，保存到 02-处理中间件/sample.md，等待我确认。

2.3 首次验收与固化

随机抽 3 条待办回听录音，再核对上期未完成项是否全部出现。连续运行三周后，把稳定字段保存成纪要模板；只有当负责人确认率和时间戳准确率稳定达标，才连接任务系统，并继续保留“创建任务前人工确认”。

3. 电商运营：月度销售数据分析

电商店铺运营

从导出的订单表分析上月销售变化，写给老板的一页汇报

!每次在表格里手动筛数据、做透视表，写出来的结论只有“涨了/跌了”，说不清原因

改造前每月约 3 小时

改造后每月约 50 分钟

这样改造

1. 导出订单明细，先让 AI 输出字段字典和数据质量报告
2. 确认统计口径：退款单是否剔除、时间范围、对比周期
3. AI 先出计算明细和汇总表，不直接给结论
4. AI 列出变化最大的 SKU 和只能从数据确认的事实
5. 运营补充活动、库存等业务原因，AI 再生成一页汇报

这样验收

• 汇总总数与后台报表对得上
• 每条结论能追溯到计算过程
• 事实与猜测的原因分开写

汇报里第一次能区分“数据事实”和“业务解释”，老板追问时每条都能回溯。

耗时为示例基线，请用你自己的记录为准。查看数据分析场景 →

3.1 准备工作空间与输入

创建 AI-Work/月度销售-YYYY-MM/。在 01-原始输入/ 放订单明细副本、平台月报和活动日历；在 brief.md 固定分析月份、时区、币种和汇报对象；在 acceptance.md 写清退款、取消单、测试单、跨月订单和空值的处理口径。

3.2 在 WorkBuddy 中分步搭建

1. 先让 WorkBuddy 输出字段字典、行数、日期范围、重复和空值报告；
2. 人工确认“支付时间”为统计时间、“实付金额减退款”为净销售额等口径；
3. 只取一个自然日重算订单数、销售额和退款额，与平台后台对账；
4. 小样通过后生成 SKU / 渠道 / 日期三张汇总表和趋势图；
5. 最后把“数据事实”和“业务解释”分栏写入一页汇报。

先读取 @01-原始输入，不要解释业务原因。
输出字段字典和质量报告；等我确认口径后，用一个自然日做计算样本。
所有指标同时给出公式、分母、样本量和明细定位。
事实只能来自订单表，活动、库存等原因只能引用 @活动日历；无法证明的原因标“待确认”。
交付 sales-detail.xlsx、monthly-review.md 和 qa-report.md。

3.3 首次验收与固化

先对总额，再抽 5 笔订单重算净销售额，最后检查每张图的单位和时间轴。连续三个月稳定后，固定导出文件名和字段映射；平台字段变化时停止复用旧模板，重新做字段盘点和单日样本。

4. 人力资源：简历初筛与面试安排

HR 招聘专员

从 200 份简历中筛出 20 份进入电话初筛，并发出面试邀约

!逐份打开简历逐项对照 JD，一天看不完；邀约邮件每封都现写

改造前每批约 5 小时

改造后每批约 80 分钟

这样改造

1. 把 JD 拆成硬性条件（必须）与加分项（可选）两栏
2. AI 按两栏条件逐份输出判断表，附简历原文依据
3. 只人工复核“边缘候选人”，不复核明显符合/不符合的
4. 用固定模板让 AI 起草邀约与婉拒邮件，人工改称呼后发送
5. 标注哪些判断是 AI 做的，录用决定永远由人做

这样验收

• 抽 10 份核对 AI 判断与人工判断是否一致
• 没有因为格式排版误杀候选人
• 对外邮件经人工确认后才发出

初筛时间压缩到原来三分之一，且每一份筛选结论都有原文依据可查。

耗时为示例基线，请用你自己的记录为准。查看文档阅读场景 →

4.1 准备工作空间与输入

创建 AI-Work/招聘初筛-岗位名-日期/，放入脱敏简历副本、岗位 JD、筛选量表和邮件模板。量表必须把“硬性条件”“加分项”“不得用于判断的敏感属性”分开；给每份简历分配候选编号，姓名与联系方式单独由招聘人员保管。

4.2 在 WorkBuddy 中分步搭建

1. 先让 WorkBuddy 把 JD 转成可观察条件，每项都写判断证据；
2. 人工确认量表，删除年龄、性别、婚育、照片等与岗位无关的字段；
3. 随机选 10 份简历做双人小样：招聘人员独立判断，WorkBuddy 同时生成证据表；
4. 比较分歧，修改量表后重新跑同一批，不能只改最终标签；
5. 批量输出“满足 / 待人工复核 / 明确缺少证据”，不自动淘汰，不自动发送邮件。

依据 @岗位JD 和 @筛选量表分析候选编号对应的简历。
每个条件输出：满足、未找到、信息矛盾；同时附简历原文位置。
不要推断未写出的经历，不使用量表禁止的属性，不给“是否录用”结论。
先处理 10 份样本并生成 screening-sample.xlsx，等待人工校准。

4.3 首次验收与固化

统计 10 份样本的人机一致率和漏检项，所有边缘候选人逐份人工复核。邮件草稿只引用已确认的岗位、时间和地点，称呼、收件人和附件逐封检查后由人发送。岗位条件变化时创建新版量表，不覆盖旧版。

5. 财务：月度费用对账

财务 / 出纳

把银行流水、报销单和台账按月对平，标记异常待人工处理

!三张表来回核对到深夜；异常项混在正常记录里，发现时已经过了报账期

改造前每月约 4 小时

改造后每月约 60 分钟

这样改造

1. 约定对账口径：金额容差、日期口径、唯一编号
2. AI 输出对账表：每笔匹配状态 + 差异原因分类
3. 只输出“对不上”的清单和可能原因，正常项一笔带过
4. 异常项由人逐笔处理，处理结果写回台账
5. 每月把新出现的异常类型补进口径说明

这样验收

• 三张表的总额对平后才看明细
• 每条异常有编号、原因和处理人
• AI 结果不直接进账，人复核后确认

报账期内就能发现差异；口径说明沉淀成文档，新人也能接手。

耗时为示例基线，请用你自己的记录为准。查看数据分析场景 →

5.1 准备工作空间与输入

创建 AI-Work/月度对账-YYYY-MM/，在 01-原始输入/ 放银行流水、报销单导出和台账的只读副本。另建 reconciliation-rules.md，写明唯一编号优先级、金额容差、日期容差、币种、手续费和一对多 / 多对一匹配规则。

5.2 在 WorkBuddy 中分步搭建

1. 先盘点三张表的字段、行数、金额合计和日期范围；
2. 将字段统一映射为 来源、编号、日期、金额、币种、摘要、对方，不改原表；
3. 先拿 20 笔已知结果做样本，输出精确匹配、规则匹配、未匹配和重复四类；
4. 人工逐笔确认样本并调整规则，再处理整月；
5. 生成对账总表、异常清单和按原因汇总表，禁止 WorkBuddy 直接记账或修改财务系统。

读取三份只读副本和 @reconciliation-rules.md。
先核对各表行数、借贷方向、币种和总额；发现口径冲突立即停止。
匹配时保存左右两侧原始行号、命中规则和差额。
先处理前 20 笔已知样本，未经确认不要运行整月数据。
未匹配项只列可能原因，不编造凭证，不写入任何业务系统。

5.3 首次验收与固化

财务人员先核对期初、发生额和期末总额，再逐笔处理异常；处理结果和凭证编号写回人工台账。连续三个月出现的异常才能加入固定规则，新规则必须用历史样本回放，确认不会把不同交易误配。

6. 销售与客户成功：客户邮件处理

销售 / 客户成功

每天处理 20～30 封客户邮件：分类、提取问题、起草回复

!邮件散在收件箱里，报价、售后、合同混在一起；回复质量全看当天状态

改造前每天约 90 分钟

改造后每天约 35 分钟

这样改造

1. 定义四类邮件：咨询、售后、商务、垃圾，各类有固定回复框架
2. AI 批量输出分类表：客户、类型、问题摘要、紧急度
3. 按分类批量起草回复，报价和承诺留空由人填
4. 人工逐封确认后发送，重点客户邮件全文重读
5. 每周把新出现的邮件类型补充分类规则

这样验收

• 数字、价格、承诺全部由人填写或确认
• 回复中提到的事实能对应到客户邮件原文
• 没有把 A 客户的信息写进给 B 客户的回复

回复速度稳定了，客户等待时间从最长 2 天降到当天；承诺类内容不再漏确认。

耗时为示例基线，请用你自己的记录为准。查看邮件场景 →

6.1 准备工作空间与输入

创建 AI-Work/客户邮件-YYYY-MM-DD/。只导入当天需要处理的邮件副本、已批准的产品资料、价格表和回复模板；在规则文件中定义咨询、售后、商务、垃圾四类及升级条件。不同客户的附件分别放入独立子目录，避免串用。

6.2 在 WorkBuddy 中分步搭建

1. 先处理 5 封覆盖四个类别的邮件，只做分类和问题提取；
2. 人工校准紧急度、客户归属和需升级条件；
3. 再生成回复草稿，把价格、折扣、交付日期和承诺留为 [人工填写]；
4. 批量运行当天邮件，输出总表和每封独立草稿；
5. 人工打开原邮件逐封确认收件人、历史上下文和附件后发送。

每封邮件独立处理，不得把其他客户信息带入当前草稿。
先输出：邮件编号、客户、类别、问题、日期/金额/附件、紧急度、升级原因。
回复只能依据 @已批准资料 和 @回复模板；价格、折扣、承诺和无法确认的信息写 [人工填写]。
先处理 5 封样本，不发送邮件，不操作邮箱。

6.3 首次验收与固化

重点核对客户名称、产品版本、金额、附件和下一步；投诉、合同、报价、退款及重点客户全部升级人工全文审查。连续两周统计错分类、漏问题和串客户次数，再决定是否连接邮箱；即使连接，也默认只生成草稿。

7. 市场与内容：公众号文章生产

市场 / 内容运营

每周产出 2 篇行业文章：选题、资料、初稿、配图与发布素材

!每篇从搜资料到成稿要一整天，初稿常常被批“没有观点”

改造前每篇约 6 小时

改造后每篇约 2.5 小时

这样改造

1. 选题会上人先定观点，AI 负责找支持和反对的证据
2. AI 输出证据表：观点、来源、原文摘录、可信度
3. 人确认结构后，AI 按结构写初稿
4. AI 扮演反方审稿人，列脆弱论点；人决定怎么改
5. 人核验事实和引用后定稿，AI 生成标题与摘要备选

这样验收

• 每个关键论点有至少一条可打开的一手来源
• 反方审稿挑出的问题至少处理或标注一次
• 数据和引文回到原文核对

初稿不再“没有观点”——观点来自人，AI 只负责证据和文字；单篇时间过半。

耗时为示例基线，请用你自己的记录为准。查看写作场景 →

7.1 准备工作空间与输入

创建 AI-Work/内容选题-YYYY-MM-DD/，放入选题简报、已确认的一手资料、品牌语气说明和发布规格。brief.md 先由人写一句核心观点、目标读者和希望读者采取的行动；没有核心观点时不进入写稿。

7.2 在 WorkBuddy 中分步搭建

1. 让 WorkBuddy 围绕核心观点建立支持、反对和限制条件三栏证据表；
2. 人工打开关键来源，确认日期、原文和适用范围；
3. 要求提供 2 个结构方案，人确认后再逐节生成，不一次写全文；
4. 初稿完成后单独发起“反方审稿”，标记证据不足、逻辑跳跃和过度承诺；
5. 人决定修改，最后才生成标题、摘要和配图需求清单。

目标读者、核心观点和行动见 @brief.md；只使用 @01-原始输入/已确认资料。
先生成 evidence-table.md：论点、支持证据、反证/限制、来源链接、日期、待确认项。
等待我确认证据和结构后再写正文；事实不足时保留 [待确认]，不要补写案例或数字。
每完成一节就停止，保存到 03-待审核交付/draft.md。

7.3 首次验收与固化

逐条打开引用并核对数字、专名和原意，再用品牌语气清单做第二轮编辑。记录从选题到发布每一阶段耗时和返工原因；连续四篇都稳定后，把证据表、结构评审和事实核验做成固定模板，但观点选择和最终发布仍由人负责。

8. 教育与自学：考试备考

备考 / 自学者

三个月备考一门职业资格：看教材、做题、纠错、复盘

!教材看完就忘，错题只抄不总结，不知道自己弱在哪一章

改造前每天约 2 小时，效率不稳定

改造后每天约 1.5 小时，弱项可见

这样改造

1. 让 AI 根据考纲把教材拆成 20 分钟一节的问题清单
2. 每节学完后，AI 出 5 道自测题并批改，错因归类
3. 错题按“概念不清 / 记不准 / 粗心”分类统计
4. 每周让 AI 根据错题分布生成下周复习重点
5. 模考后让 AI 对比历次成绩，指出停滞的章节

这样验收

• AI 的解释能对应到教材原章节
• 拿不准的题目回归教材或真题答案
• 复习计划真的执行过并留下了记录

学习从“从头再读一遍”变成“按错题数据定点补漏”，模考分数两次连续提升。

耗时为示例基线，请用你自己的记录为准。查看学习场景 →

8.1 准备工作空间与输入

创建 AI-Work/备考-科目/，放入官方考纲、教材目录、允许使用的讲义和个人错题表。brief.md 写考试日期、每周可用时间和目标分数；acceptance.md 写“解释可回到教材章节、每周有闭卷测试、错题必须二次作答”。

8.2 在 WorkBuddy 中分步搭建

1. 先把考纲映射到教材章节，输出“考点—章节—掌握状态”表；
2. 做 20 道覆盖不同章节的诊断题，先答后批，不允许提前展示答案；
3. 按诊断结果生成首周计划，每天只安排可在现有时间完成的学习块；
4. 每节完成后做 5 题闭卷练习，把错误归为概念、记忆、应用或粗心；
5. 每周重新测试最弱的三个考点，只有连续两次答对才改为“已掌握”。

依据 @官方考纲 和 @教材目录建立学习地图，不补充无法定位到教材的结论。
先出 20 道诊断题，一次只显示一道；我回答后再给评分、教材章节和错因。
把结果追加到 02-处理中间件/error-log.xlsx，不覆盖历史记录。
每周计划必须包含学习、闭卷练习、复测和一个可检查作品。

8.3 首次验收与固化

每周由人核对题目是否超纲、答案是否能回到官方材料，并做一次不使用 AI 的限时练习。连续四周用错题分布调整计划；如果某类错误没有下降，回到教材和真题，不继续增加新内容。

9. 产品与研发：需求文档与排错

产品经理 / 工程师

把用户反馈整理成需求文档；线上报错时快速定位可疑提交

!用户反馈散落在三个渠道，写需求全靠回忆；排查问题从读代码大海捞针

改造前每份文档约 2 小时 / 每次排错约半天

改造后每份文档约 40 分钟 / 每次排错约 1 小时

这样改造

1. 导出三个渠道的反馈，AI 按主题聚类并去重
2. AI 输出反馈表：主题、频次、典型原文、影响范围
3. 人决定优先级和取舍，AI 按模板生成需求文档初稿
4. 排错时把报错日志、时间线和最近变更交给 AI，让它列出可疑点
5. 每个可疑点人工验证后才改代码，AI 不直接动生产

这样验收

• 需求里的每条反馈能回链到原始记录
• AI 的可疑点全部经过人工复现确认
• 文档版本和变更原因有记录

需求评审时不再被问“这个需求有多少人提过”；排错从读代码变成先验证假设。

耗时为示例基线，请用你自己的记录为准。查看编程场景 →

9.1 准备两个独立工作空间

需求整理创建 AI-Work/需求-主题-日期/，放入三个渠道的脱敏反馈、需求模板和产品术语表；故障排查创建 AI-Work/故障-编号/，放入日志、复现步骤、环境版本、最近提交列表和已知正常基线。不要把生产密钥、客户原始数据或可写的生产目录放入工作空间。

9.2 需求文档的 WorkBuddy 搭建过程

1. 先按渠道盘点数量并去除完全重复项，保留原始编号；
2. 取 20 条反馈做主题聚类样本，人确认主题定义后再处理全部；
3. 输出“主题、频次、典型原文、用户影响、来源编号”，不让 AI 决定优先级；
4. 产品经理确认取舍和成功指标后，再按模板生成需求文档；
5. 每条需求保留反馈回链，评审修改记录在 changelog.md。

只整理 @用户反馈，不判断优先级。
先对 20 条样本聚类；每个主题给定义、包含/排除规则和原始反馈编号。
人工确认主题后再跑全量，并生成 feedback-evidence.xlsx。
只有我补充优先级、范围和成功指标后，才生成 PRD 草稿。

9.3 故障排查的 WorkBuddy 搭建过程

1. 先复述现象、期望行为、时间线和影响范围，缺失项写“未知”；
2. 根据日志和最近变更列出不超过 5 个可证伪假设；
3. 每个假设写验证命令、期望结果、风险和回滚，不直接修改代码；
4. 人工选择一个假设，在隔离环境复现并保存输出；
5. 复现后先写失败测试，再最小修改，依次运行测试、类型检查和构建。

读取 @故障材料，只做定位计划，不修改代码、不连接生产。
输出事实时间线和最多 5 个假设；每个假设必须引用日志或变更证据，并给出最小验证步骤。
等我选择后，只验证一个假设并保存命令与完整输出。复现成功后再提议失败测试。

9.4 首次验收与固化

需求侧抽查反馈数量和回链，故障侧要求失败测试在修复前失败、修复后通过。每次评审或排错结束，把新术语、主题定义、验证命令和误判原因写回复盘；发布和生产变更仍按团队现有审批流程执行。

10. 把案例换成你自己的工作

以上案例覆盖了常见岗位的代表性任务，但真正有效的做法永远是：用你自己的任务跑一遍，再和案例对照哪里不同。

1. 在《完成第一件真实工作》里选一件 20 分钟级别的任务；
2. 用案例卡里的字段记录：原耗时、输入、步骤、验收方式；
3. 跑通后把你的案例补充到自己的工作笔记里，形成个人案例库。

如果案例里的方法连续两次不奏效，回到《像委托同事一样委托 AI》检查简报是否完整。