把业务数据交给 WorkBuddy 分析，官方场景包怎么用才靠谱

2026-08-16

官方三大场景包里的第三个，面向的是最需要「拿数据说话」的那批人：

业务数据洞察与自动化响应 推荐用户：运营、客户成功、管理等需对业务数据做出反应的角色 能力描述：把业务数据表格/日志交给它，自动完成深度分析、提炼问题、总结规律，并生成指导方案 典型任务：

用户反馈与舆情分析：分析用户反馈与评论文档，情感归类与问题提炼，生成附带优化建议的周期性洞察报告

销售与业绩洞察：提供 CRM 中的销售管道与成交数据，分析成丢单原因并预测业绩，输出销售策略调整与重点客户跟进建议

能力描述里有两个词值得先划出来：「分析成丢单原因」和「预测业绩」。这两件事最需要人把关。

本文依据腾讯云 CodeBuddy 国内站产品页 codebuddy.cn/work/ 的场景包描述与官方使用技巧、权限模式文档，核对日 2026-08-16。我们没有安装客户端，本文不含实测数据。

一、动手之前：数据进目录前先脱敏

这是本场景第一条、也是最重要的一条。

业务数据里通常混着不需要的敏感字段：手机号、身份证号、客户联系人姓名、银行账号。如果你的分析任务不需要它们，处理前先把那些列删掉。

为什么这一步不能省：

官方在数据安全说明里写的是「文件系统隔离：只能访问预先授权的工作空间目录」——边界是你划的，但目录里放什么是你决定的；
官方在日志说明里明确写了日志可能包含对话记录、设备信息等数据——万一你要提反馈上传日志，那些内容可能一起走；
官方英文隐私文档里那个「帮助优化模型」开关默认是开启的——开着的时候对话可能被用于训练和改进模型。

这一步是纯手工的，但它是你唯一 100% 可控的环节。

配套的目录习惯：给数据分析类任务建独立目录，比如 customer-data-cleanup（官方给的命名示例之一），里面放副本不放原件。

二、用户反馈与舆情分析：指令模板

【目标】分析 <反馈文件> 中的用户反馈，输出周期性洞察报告

【输入】D:\WorkBuddy\fankui\本月反馈_脱敏.xlsx
        （已删除手机号与姓名列，仅保留反馈内容、时间、渠道）

【输出格式】
- Markdown，保存在当前工作空间
- 结构：问题分类统计表 → 高频问题 TOP5（每条附原文引用 2 条）→ 情感分布 → 待确认事项

【约束】
- 分类必须基于原文，不要把没出现过的问题归进去
- 每个分类给出条数，条数必须与原始数据对得上
- 引用原文时逐字引用，不要改写
- 【事实】与【建议】分开标注
- 不做「用户为什么这么想」的心理推测
- 不需要开场白

最后两条约束是这类任务的关键：

「不做心理推测」——它很容易写出「用户可能是因为担心 XX 才这么说的」，这种句子读起来很有洞察力，但没有依据；
「事实与建议分开」——统计数字是事实，优化建议是它的推断，混在一起你分不清哪部分能直接用。

三、销售与业绩洞察：归因不能交出去

官方场景包提到「分析成丢单原因并预测业绩」——这两件事都要格外小心。

指令模板：

【目标】基于 <CRM 导出数据>，输出销售管道分析

【输出格式】
- 表格 + 文字说明，保存在当前工作空间
- 内容：各阶段转化数据 → 成单/丢单的客观特征对比 → 待跟进清单

【约束】
- 只列客观特征差异（如成单客户的平均跟进次数 vs 丢单客户），
  ★ 不要写「丢单是因为 XX」这类归因结论
- 不做业绩预测；如果我需要，我会单独要
- 所有数字必须来自数据文件，没有的写「数据中无此字段」
- 金额一律保留原值，不四舍五入

为什么归因不能交出去：

丢单的真实原因往往在数据之外——客户预算被砍了、对接人换了、竞品给了更好的条件、你们的响应慢了。这些 CRM 字段里大多没有。

AI 能看到的只有数据里的相关性。它写出来的「因为客户规模小所以丢单」，可能只是因为你们的小客户跟进得少。相关不等于因果，而这一步的判断需要你对业务的了解。

正确的用法：让它列出客观差异，归因由你来做。比如它告诉你「成单客户平均跟进 5.2 次，丢单客户平均 2.1 次」——这是事实；至于「是不是跟进不够导致的丢单」，你来判断。

关于业绩预测：官方在专家中心明确提示 AI 生成内容仅供参考，无法替代专业判断，不构成决策和投资建议。预测数字拿去汇报之前，务必自己过一遍逻辑。

四、通用的四步流程

不管哪类数据分析，这个顺序都成立：

第一步：先让它描述数据。

读取 <文件>，告诉我这张表有哪些列、共多少行、有没有明显的空值或异常值。先不要分析。

这一步经常被跳过，但价值很高——你可能自己都不完全清楚这份导出的数据长什么样。几秒钟，能避免后面整个方向做错。

第二步：做减法。

只保留 <列1、列2、列3> 三列，输出成新的 xlsx 存在当前工作空间。

分析地区成交额只需要两三列，其他二十列都是噪音。而且列少了，敏感字段被带进去的机会也少了。

第三步：基于新文件做分析。 用第二、三节的模板。

第四步：抽查验收。 随机挑两三个数字回原始文件核对。对不上就整份重来——一处错说明取数逻辑有问题，别只改那一处。

五、想配成自动任务的话

这个场景很适合周期性跑（周报、月报），但有两条要注意：

一、官方的自动化判据是三条：重复性高、规则明确、无需实时人工干预。数据分析类通常满足前两条，第三条要看你的口径稳不稳定——如果每次都要根据当期情况调整关注点，那不适合。

二、涉及客户与财务数据的自动任务，「推送到小程序」这一项要慎开。 官方说明开启后推送会通过安全链路把文件同步到云端。

折中做法：在提示词里让它只输出一句不含具体数字和客户名称的摘要推送，完整报告仍存在本地目录里。

六、什么时候别用

需要担责的决策：要不要砍掉某条产品线、要不要换供应商；
对外发送的数据：给客户看的报表，让它做草稿，你核对后手动发；
无从校验的数字：它给的数你没有原始数据可以核，那就别用这个结果；
口径还没定的分析：你自己都说不清「成单」怎么算的时候，先把口径定下来。

七、一条容易被忽略的红线

别让它替你「解释」异常。

数据里出现一个异常波动，最有价值的动作是你去查发生了什么——那天是不是搞了活动、是不是系统故障、是不是某个大客户一次性下单。

如果你让它给解释，它会给一个听起来合理的说法，而你可能就此停止追查。一个似是而非的解释，比没有解释更危险。

指令里加一句能挡住这个：

只描述数据中的波动事实（时间、幅度、涉及维度），不要解释原因。

小结

官方场景包：业务数据洞察与自动化响应，面向运营、客户成功、管理；典型任务是用户反馈与舆情分析、销售与业绩洞察。
★ 第一条也是最重要的一条：数据进目录前先脱敏——不需要的敏感列先删掉。这是唯一 100% 可控的环节。
反馈分析的两条关键约束：不做心理推测、【事实】与【建议】分开标注。
★ 销售分析的红线：只列客观特征差异，不要写归因结论。丢单的真实原因往往在数据之外，相关不等于因果。
四步流程：先让它描述数据 → 做减法只留需要的列 → 基于新文件分析 → 抽查验收，对不上就整份重来。
配自动任务前对照官方三条判据；涉及客户与财务数据时慎开「推送到小程序」（会同步到云端），可只推不含数字的摘要。
一条容易忽略的红线：别让它替你解释异常——一个似是而非的解释，比没有解释更危险。

功能与场景描述以官方为准，核对日 2026-08-16。