CD-02 · 追溯码上传成功确认台账

① 场景引入

一、这件事现在是什么样

外包赋码岗 · 真实业务触发

批包装完成、XML 导出上传之后。点了上传、没报错，这件事在所有人认知里就结束了。真正的反馈来自厂外：药店扫码显示「未激活」，电话当天就打过来。而此时距离生产可能已经过了两周 —— 刚好压在平台「15 天以内可自行删除单据、超过 15 天需审核」这条线上。

二、痛点 · 每条都有来源

1. 有从业者在论坛发帖问「追溯码上传后怎么核实上传成功」—— 这个问题本身就是证据：企业内没人被明确指定负责这件事，也没有一个可查的界面告诉你这一批到底传成了没有
   依据：制药从业者论坛发帖询问「追溯码上传后怎么核实上传成功」—— 证明「上传是否成功」在企业内无人被明确指定负责、也没有可查界面
2. 平台单据管理规则是「15天以内可自行删除、超过 15 天需审核」—— 这是一条硬时间窗。上传对账如果不在 15 天内做，纠错成本会突然上升一个台阶，而这条线现在没人盯
   依据：药品追溯平台单据管理规则 —— 「15 天以内可自行删除单据、超过 15 天需审核」。这是一条硬时间窗：上传对账若不在 15 天内做，纠错成本会突然上升一个台阶
3. 后果已经不是合规问题而是现金流问题：2025 年 7 月 1 日起定点医药机构销售环节按要求扫码后方可进行医保基金结算，截至 2025 年 6 月已累计归集追溯码 398.85 亿条 —— 传不上去，药店那一盒就结算不了，电话当天就来
   依据：国家医保局药品追溯码采集应用政策 —— 截至 2025-06 已累计归集追溯码 398.85 亿条；2025 年 7 月 1 日起定点医药机构销售环节按要求扫码后方可进行医保基金结算；一盒药只应有一次被扫码销售记录，重复出现可能涉假药或回流药，违规可致解除协议并处 2 倍罚款
4. 零盒与零箱是必然产生的：小盒数除以装箱比例几乎不可能整除，尾数必然形成零盒与零箱，而这两类恰恰是赋码系统里单列的异常处理功能 —— 也就是最容易在关联关系上出问题的地方
   依据：国产赋码系统厂商功能说明 —— 逐条列出异常处理功能：药监码剔除与解除、药监码替换（原码作废）、按批次解除整批关联数据、已上传的需通过平台「药监码注销」功能批量注销、对已印刷未使用的码补打。这些功能的存在反证了这些异常在现实中高频发生

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 有从业者在论坛发帖问「追溯码上传后怎么核实上传成功」—— 这个问题本身就是证据：企业内没人被明确指定负责这件事，也没有一个可查的界面告诉你这一批到底传成了没有平台单据管理规则是「15 天以内可自行删除、超过 15 天需审核」—— 这是一条硬时间窗。上传对账如果不在 15 天内做，纠错成本会突然上升一个台阶，而这条线现在没人盯
• 后果已经不是合规问题而是现金流问题：2025 年 7 月 1 日起定点医药机构销售环节按要求扫码后方可进行医保基金结算，截至 2025 年 6 月已累计归集追溯码 398.85 亿条 —— 传不上去，药店那一盒就结算不了，电话当天就来
• 零盒与零箱是必然产生的：小盒数除以装箱比例几乎不可能整除，尾数必然形成零盒与零箱，而这两类恰恰是赋码系统里单列的异常处理功能 —— 也就是最容易在关联关系上出问题的地方

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

6 步 · 每一步的产出都是下一步的输入

1. 触发 · XML 导出上传完成，没有报错KT26-0815 上传任务显示成功。按现有流程，这件事到这里就结束了第 2步逐层算应传条数 · 含零盒零箱小盒 11742 个；按 20 小盒/中盒 → 587 个中盒余 2 小盒（零盒 1 条）；按 10 中盒/大箱 → 58 箱余 7 中盒（零箱 1 条）。应传合计 11742 + 587 + 58 + 1 + 1 = 12389 条
2. 与平台实收对齐平台侧实收

11801 条 → 差 588 条未上传成功，占 4.75%。上传任务显示「成功」而条数不符 —— 这是现有流程的盲区第 4 步差异定层 · 说清差在哪一层把 588 条按层级归属拆开，判断是某个中盒下整组小盒缺失、还是零盒零箱这两类尾数出了问题第 5 步时间窗校验 · 算距离 15 天线还有多久按本批上传日期算出剩余可自行纠错的天数；超过 15 天的批次单独标红（纠错要走审核，成本不同）第 6 步留证 · 生成上传确认台账与补传清单台账逐批记录应传/实收/差额/时间窗剩余；补传动作与责任人栏留给赋码岗填，不代填

要准备什么：在线采集日志（赋码系统导出）各层级实际采集与关联的条数与时间戳导出的 XML 关联关系文件★ 按品种与包装比例分别导出，条数需要自己算 —— 平时没人算过追溯平台客户端上传任务列表截图或手抄，没有导出习惯；只显示任务成功/失败，不显示条数明细批包装记录物料平衡页提供本批的实际使用数，作为应赋码数的基准

为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 4 ÷ 落地难度 2 = 10.0

最大差异点：不要求客户接平台接口。用赋码系统的导出文件与平台客户端的任务状态截图/导出做核对，逐层算清应传条数 —— 包含零盒零箱这两类最容易漏的尾数。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：追溯码上传确认台账.xlsx 正式件 · 3 sheet（逐批确认主表 / 层级条数核算 / 时间窗提示）· 含编制与复核签批栏
• 可派发清单：待补传清单.xlsx 可派发 · 每条含层级、条数、差异归属、时间窗剩余天数
• 可派发清单：历史未确认批次清单.xlsx 可派发 · 近半年上传任务显示成功但条数从未核对的批次，标出已超窗口的

这套东西不承诺什么：不代做上传 —— 平台侧的上传、删除、注销一律由人在客户端执行。不代登录追溯平台 —— 不接触客户的平台账号。不判定这批能不能放行。不修改 XML 文件内容。台账只做「应传多少、实收多少、差多少、差在哪一层」的核对，补传动作由赋码岗执行。责任认定栏留空。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：康泰生物制药有限公司外包间旁边的赋码工位。KT26-0815 批包装完成后，邹立辉按流程导出 XML、点了上传，客户端显示「成功」—— 按现有流程，这件事到这里就结束了。今天上午药店打电话来说有几盒扫码显示「未激活」，这是距生产已经过了十二天之后才传回来的反馈。而平台的单据管理规则是十五天以内可自行删除、超过十五天需审核，也就是说还剩三天。

输入文件4 份应传条数12,389平台实收11,801结论差异未定层不能签已确认

输入混合制造企业手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_在线采集日志_KT26-08
• 15_各层级条数.xlsx 赋码系统导出的采集与关联记录 —— 产线上码到底采到没采到，看这份赋码系统自动记录 · 可导出 · 含时间戳
• 02_XML导出分文件与平台任务回执对账.xlsx ★ 把导出的分文件条数与平台任务列表回执逐层比对 —— 这份此前不存在，平时只看客户端那句「成功」导出 XML 文件（按层级分三个文件）+ 平台客户端任务列表 · 回执平时靠截图或手抄，没有导出习惯
• 03_批包装记录物料平衡页_KT26-0815.xlsx 提供本批实际使用数作为应赋码数的基准 —— 应传多少条要从这里推赋码岗填写 · 批记录 P42–P43 · QA 复核
• 04_近半年上传任务与条数核对情况.xlsx 翻近半年的上传记录 —— 有几批同样显示「成功」但条数从来没人核过平台客户端任务列表历史 +各批采集日志 · 首次做横向核对

注意标橙色那一份 —— 02_XML导出分文件与平台任务回执对账.xlsx。它导出 XML文件（按层级分三个文件）+ 平台客户端任务列表 · 回执平时靠截图或手抄，没有导出习惯，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是一批的在线采集日志、导出的 XML 文件，还有平台上传任务的截图。 上传任务显示成功，但我不知道条数对不对。帮我算清应该传多少条——小盒、中盒、大箱，还有零盒零箱那些尾数别漏了——然后和平台实收的条数比。 差的那些要说清是差在哪一层，不要只给一个总数。另外算一下这批距离 15 天窗口还有几天。 补传谁去做、什么时候做，这两栏留空，我来填。

短是因为逐层条数算法、零盒零箱规则、15 天窗口这些都写在能力包里了。你只需要说清给了哪几份材料。

触发XML 导出上传完成，客户端显示「成功」

按现有流程这件事到这里就结束了 —— 真正的反馈来自厂外

这一步的看点 · 从历史里想起了公司踩过的坑翻近半年的上传记录，发现另有 2 个批次的上传任务同样显示「成功」，但条数从来没人核过 —— KT26-0405 差 587 条、KT26-0702 差 588条。更要紧的是这 2 批都已经超过了 15 天窗口（距今 146 天与 58 天），现在补传要走平台审核，成本比本批高一个台阶。这 2 批当时都没有药店反馈，不是因为没问题，而是因为那部分货还没卖到需要扫码结算的环节 —— 所以「没人投诉」根本不能作为「传成功了」的证据。这条不靠谁记得：平台客户端的任务列表和赋码系统的采集日志都能导出，两边并排一比就出来了。过去没比，是因为没有任何流程要求比。

第 1 步 · 逐层算应传条数 · 含零盒零箱

从物料平衡的实际使用数出发，按包装比例逐层推算 —— 尾数必须单列

这一步的看点 · 该拦的地方拦住了这里要拦一个很自然的算法：用领用数 12000 去推应传条数。12000 是领用量，里面包含了残损 168、退库 78、销毁 12 —— 这些都没有变成货，不该有关联关系。用 12000 算会得出 12600 多条，然后跟平台实收一比会显示差八百多条，把一个真问题算成了一个更大的假问题。正确的基准是物料平衡的「使用数」11742，而不是「领用数」12000。这两个数在批记录 P42 上是相邻两栏，很容易取错。顺带说清一件事：残损那 168 个对应的是 168 条作废码，作废码不进关联关系、也不该上传 —— 它们的问题由 CD-01 那条对账线管，与本场景的上传条数是两件事。

第 2 步 · 与平台实收对齐 · 找出差额

上传任务显示「成功」而条数不符 —— 这是现有流程的盲区

这一步的看点 · 排除性结论采集环节可以排除。依据是：在线采集日志的条数与按物料平衡实际使用数逐层算出的应传条数完全一致（都是 12389 条），而且五个层级逐层都对得上 —— 小盒 11742、中盒 587、大箱58、零盒 1、零箱 1。导出环节也可以排除：三个 XML 分文件的条数相加 11742 + 588 + 59 = 12389，同样一致。这两条排除掉之后，排查范围从整条赋码链收敛到「上传」这一个动作上 —— 码采到了、关联关系生成了、文件也导出了，丢在了从导出到平台之间。这个收窄很实用：邹立辉不需要重新跑一遍产线数据，只需要盯平台任务列表这一件事。3差异定层 · 说清 588 条差在哪一层

是某个中盒下整组小盒缺失，还是零盒零箱这两类尾数出了问题

层级应传平台实收差额归属判断小盒11742117420完整中盒5870587整层缺失大箱58580完整零盒101随中盒文件一起缺零箱110完整（在大箱文件内）合计1238911801588中盒 587 + 零盒 1逐层比对后差异定位得很干净：588 = 中盒 587 + 零盒1，而小盒、大箱、零箱三层完全完整。反向也能验证：平台实收 11801 = 小盒 11742 + 大箱 58 + 零箱 1，正好是除中盒文件之外的全部。机制就清楚了：XML 是按层级分三个文件导出的，FILE-02_中盒.xml 那一个整体没有上传成功，而零盒的关联关系恰好写在中盒文件里，所以跟着一起丢了。平台任务列表里只有 2 条任务记录、没有 FILE-02 那一条—— 这个文件根本没进平台。所以不是零散丢码，是整个分文件丢了 —— 补传方式也不同：不用逐条找，重传

这一步的看点 · 该拦的地方拦住了这里要拦一个会引出大麻烦的做法：把整个 12389 条重传一遍。从操作上看这最省事 —— 反正差了不知道哪些，全传一遍总不会漏。但已经成功上传的 11801 条会形成重复记录，而官方口径很明确：「一盒药的追溯码只应有一次被扫码销售记录，若重复出现可能存在假药、回流药或串换销售」。更直接的后果是：重复结算会解除医保协议并处 2 倍罚款。为了补 588 条而给 11801 条制造重复风险，这个交换完全不成立。所以定层这一步不是为了写得好看，它决定了补传动作是「重传一个文件」还是「全量重传」 —— 现在结论明确：只重传 FILE-02_中盒.xml，涉及 587 个中盒 + 1 条零盒。

第 4 步 · 时间窗校验 · 算距离 15 天线还有多久

超过 15 天的批次单独标红 —— 纠错要走审核，成本不同

这一步的看点 · 把技术动作翻译成钱588 条对应 588 盒。这些盒到了药店会扫出「未激活」，而2025 年 7 月 1 日起，定点医药机构销售环节按要求扫码后方可进行医保基金结算，截至 2025 年 6 月已累计归集追溯码 398.85 亿条。所以这 588 盒在该渠道结算不了 —— 这不是三个月后审计才发现的问题，是上架当天药店就会打电话回来的问题。本批就是这么被发现的。把三批加起来：1763 盒在同样的状态里，其中 1175 盒（KT26-0702 与KT26-0405）已经超了窗口。反过来这也是这个场景最容易讲通的地方：追溯码错误现在是现金流问题，不是合规问题。合规问题可以排期整改，现金流问题当天就有人催。

第 5 步 · 留证 · 生成上传确认台账与补传清单

台账逐批记录应传/实收/差额/窗口剩余 · 补传动作与责任人栏留给赋码岗填

这一步的看点 · 从历史里想起了公司踩过的坑把近半年 6 批横向核完，最值得写进台账的不是本批那 588 条，而是「6 批全部显示成功、6 批条数全都没核过」这个事实。其中 3 批实际有差、2 批已超窗口 —— 而这 2 批当时都没有药店反馈。所以「没人投诉」从来不能作为「传成功了」的证据，它只说明那批货还没走到需要扫码结算的环节。这条不靠谁记得：平台任务列表能导出历史、各批采集日志也都在系统里，两边并排一比，三批差异当场就出来了。过去没比，是因为没有任何流程要求比，也没有任何人被指定负责这件事。所以这份台账最该固定下来的是那一栏「窗口剩余天数」 —— 它把一件没人负责的事变成了一件有截止日期的事。

这批的上传确认台账现在还不能签「已确认」：差异已经定层定清：应传 12389 条、平台实收 11801 条、差 588 条（占4.75%），而 588 = 中盒 587 + 零盒 1 —— FILE-02_中盒.xml 那个分文件整体没有上传成功（平台任务列表里只有 2 条任务记录、没有它）。采集与导出两个环节均可排除：采集日志与三个 XML 分文件条数都是 12389，逐层吻合。但签「已确认」就等于确认本批上传完整，而这 588 条还没补、平台回执也还没拿到。本场景不代做上传、不代登录追溯平台、不修改 XML 内容、不判定这批能不能放行 —— 补传动作由赋码岗执行，责任认定栏留空。方案一 · 今天就重传 FILE-02 一个文件，明天签台账：差异已定位到单个分文件，邹立辉在客户端删除原任务后重传 FILE-02_中盒.xml即可，涉及 587 个中盒 + 1 条零盒，半天内能完成并拿到平台回执。本批距 15 天窗口还剩 3 天，在窗口内可自行删除重传，不用走审核。代价是这半天里那 588 盒仍处于「未激活」状态，药店可能继续打电话来；好处是不用全量重

传，避免给已成功的 11801 条制造重复码风险（重复结算会解除医保协议并处 2 倍罚款）。方案二 · 把三批一起处理，本批顺带做：近半年横向核出 3 批有差、合计 1763 条，其中 KT26-0702 与 KT26-0405 已分别超窗 43 天与 131 天、纠错须走平台审核。一次性向平台提交这两批的审核申请，同时自行重传本批。好处是把这半年的历史缺口一次清掉，而且顺带能把「上传条数确认」这件事定给具体的人 —— 现在它不在任何人的岗位说明书里。代价是平台审核周期不可控，而本批的 3 天窗口不等人 —— 如果两件事捆在一起做，本批可能被拖过窗口，从「自行重传」变成「也要走审核」。所以稳妥的做法是本批先自行处理完，历史两批另起一条线走。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 台账多了一条：企业第一次有了一份逐批的「应传/实收/差额」记录，而不是只有「任务显示成功」
• ✓ 两条口径被固定下来：应传条数必须含零盒零箱两类尾数、「上传成功」的定义从「任务无报错」改为「条数核对一致」
• ✓ 一条历史教训被真正用上：近半年 2 个从未核对条数的批次被翻出来，其中 1 批已超 15 天窗口 —— 这两批此前没有任何人知道
• ✓ 岗位角色变了：从「点上传、不报错就算完」变成「交一份能签字的上传确认台账，并且知道哪几批还差多少条」

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 平台显示上传成功了，还要核什么？ 任务成功和条数完整是两件事。这一批任务显示成功，实际差 588 条。
• 现场可以直接问一句：你们怎么知道这一批传全了？ 如果答案是「任务没报错」，那这个场景就有价值。
• 能不能让它自动帮我补传？ 不能。平台侧的上传、删除、注销一律由人在客户端执行，我们也不接触客户的平台账号。我们做的是把「差多少、差在哪一层、还剩几天可以自行纠错」算清楚，动作由赋码岗做。
• 15 天窗口过了会怎样？ 平台规则是 15 天以内可自行删除单据、超过 15 天需审核。所以过了窗口不是不能改，是纠错成本上一个台阶、要走审核。这也是为什么这件事值得有一张定期核的台账 —— 它的价值全在窗口内被发现。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

追溯码上传成功确认台账 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

upload-confirm.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是混合制造企业手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁CD-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_在线采集日志_KT26-0815_各层级条数.xlsx 赋码系统导出的采集与关联记录 —— 产线上码到底采到没采到，看这份
• 02_XML导出分文件与平台任务回执对账.xlsx ★ 把导出的分文件条数与平台任务列表回执逐层比对 ——这份此前不存在，平时只看客户端那句「成功」
• 03_批包装记录物料平衡页_KT26-0815.xlsx 提供本批实际使用数作为应赋码数的基准 —— 应传多少条要从这里推
• 04_近半年上传任务与条数核对情况.xlsx 翻近半年的上传记录 —— 有几批同样显示「成功」但条数从来没人核过

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这是一批的在线采集日志、导出的 XML 文件，还有平台上传任务的截图。 上传任务显示成功，但我不知道条数对不对。帮我算清应该传多少条——小盒、中盒、大箱，还有零盒零箱那些尾数别漏了——然后和平台实收的条数比。 差的那些要说清是差在哪一层，不要只给一个总数。另外算一下这批距离 15 天窗口还有几天。 补传谁去做、什么时候做，这两栏留空，我来填。

为什么这么短就够了：短是因为逐层条数算法、零盒零箱规则、15 天窗口这些都写在能力包里了。你只需要说清给了哪几份材料。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• CD-02_追溯码上传确认台账.xlsx 正式件 · 3 sheet（逐批确认主表 / 层级条数核算 / 时间窗提示）· 含编制与复核签批栏
• CD-02_待补传清单.xlsx 可派发 · 每条含层级、条数、差异归属、时间窗剩余天数
• CD-02_历史未确认批次清单.xlsx 可派发 · 近半年上传任务显示成功但条数从未核对的批次，标出已超窗口的

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：在线采集日志（赋码系统导出）各层级实际采集与关联的条数与时间戳导出的 XML 关联关系文件★ 按品种与包装比例分别导出，条数需要自己算 —— 平时没人算过追溯平台客户端上传任务列表截图或手抄，没有导出习惯；只显示任务成功/失败，不显示条数明细批包装记录物料平衡页提供本批的实际使用数，作为应赋码数的基准

人工边界：不代做上传 —— 平台侧的上传、删除、注销一律由人在客户端执行。不代登录追溯平台 —— 不接触客户的平台账号。不判定这批能不能放行。不修改 XML 文件内容。台账只做「应传多少、实收多少、差多少、差在哪一层」的核对，补传动作由赋码岗执行。责任认定栏留空。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

外包赋码岗 · 产出即下一步输入

CD-01 · 作废码与物料平衡逐条对账 — 物料平衡 100.00% 闭合，纸面上完美无缺 · 但有 3 个该作废的码，此刻仍是「已关联」状态 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。