我为传感器销售设计了一套“AI技术助理”工作流：WorkBuddy + 腾讯云 AI Skills 多 Skills 协同实践

本文为设计实践。文中主角“销售 AI 助理”的完整 OCR/ASR 协同链路为下一阶段规划；已真实落地的 WorkBuddy 自动化（内容生产线）作为“已实现”部分，在第九节单列佐证。

一、为什么传感器销售特别需要一个“AI技术助理”？

我是一名国际传感器销售，日常工作并不只是“给客户报价”。

客户可能上午问我：

“Do you have a linear displacement sensor with 0-100 mm range and 4-20 mA output?”

下午又发来一张产品铭牌照片：

“Can you provide an equivalent model?”

晚上可能是一段语音：

“The sensor works normally at room temperature, but after the machine runs for some time, the output starts to fluctuate...”

与此同时，我还需要处理：

• 产品 Datasheet
• PDF 技术手册
• 客户图片
• Excel 参数表
• 邮件
• 客户会议记录
• 售后问题
• 竞品资料
• 报价和交期

这些事情有一个共同特点：

信息很多，但格式非常不统一。

PDF 是一种格式，图片是另一种格式，语音又是另一种格式。

真正耗时间的往往不是“回答客户”，而是：

先把这些非结构化信息整理成我能理解和使用的数据。

所以我开始尝试一个思路：

能不能利用腾讯云 AI Skills 的 OCR、ASR 等能力，把不同来源的信息先转换成结构化内容，再交给 WorkBuddy 进行分析和组织？

于是，我设计了一套面向传感器销售场景的 AI 工作流。

二、我想做的不是“聊天机器人”，而是一条销售工作流

我给它起了一个很简单的名字：

Sensor AI Assistant

它的目标不是替我直接做销售决策，而是帮助我处理销售工作中大量重复的信息整理工作。

整体思路是：

这里我特别强调一个原则：

AI负责整理和辅助判断，人负责最终确认。

尤其是传感器行业，产品参数属于技术信息。

量程、精度、输出信号、安装尺寸、工作温度、防护等级等信息，一旦写错，就可能直接影响客户选型。

所以我不会让 Agent 在没有人工审核的情况下直接向客户承诺产品参数。

三、为什么选择“多 Skills”，而不是只使用一个大模型？

最开始接触 AI 工具时，我也会直接把客户的问题复制进去：

“帮我分析一下客户需要什么传感器。”

这种方法在简单问题上没有问题。

但真正进入工作场景后，我发现一个问题：

模型能分析文字，但首先得有人把图片、PDF和语音里的信息整理成文字。

例如客户给我一张传感器铭牌。

人工方式是：

看图片 → 找型号 → 查 Datasheet → 手动抄参数 → 再分析客户需求。

如果客户发来语音：

听录音 → 做笔记 → 提取型号 → 整理需求 → 再查产品资料。

所以我把问题拆成了两个层次：

第一层：信息获取

让专业 Skill 负责处理不同类型的信息。

• OCR → 图片 / PDF → 文字
• ASR → 语音 → 文字

第二层：业务分析

让 WorkBuddy 负责：

• 信息整理
• 需求提取
• 参数结构化
• 问题归类
• 回复草稿生成

这样就形成了：

Skill负责“看懂输入”，Agent负责“组织和使用信息”。

这是我认为这次腾讯云 AI Skills 最值得尝试的地方。

四、场景一：客户发来 Datasheet，我先让 OCR 帮我“读参数”

传感器销售每天会接触大量 Datasheet。

一个很典型的情况是：

客户发来一个 PDF 或产品图片，然后问：

“Can you provide an equivalent product?”

如果文件是扫描版，或者参数表格比较复杂，人工阅读和整理会比较麻烦。

我的设想是把这个流程拆成：

最终希望得到类似：

这里有一个很重要的细节：

“待核对”必须允许存在。

因为 AI 提取到了一个数字，不代表这个数字就一定正确。

尤其是 OCR 场景，图片模糊、表格错位、字符识别错误，都可能导致参数发生变化。

所以我设计的原则是：

OCR负责提取，WorkBuddy负责整理，销售负责确认。

五、场景二：客户发来一段语音，我让 ASR 把“口语需求”变成文字

这可能是我认为 ASR 在国际销售场景里最有价值的地方。

客户现场交流时，很少会像 Datasheet 一样告诉你：

Measuring range = 0–100 mm Output = 4–20 mA Accuracy = ±0.1%

更多时候是：

“We need something for a hydraulic cylinder. The stroke is around 100 millimeters, and we'd prefer a 4-20 milliamp output...”

甚至客户会一次说很多内容。

如果全部靠人工记录，很容易漏掉信息。

因此我希望形成这样的流程：

WorkBuddy进一步把内容整理成：

对于销售来说，这比单纯得到一段语音转写文字更有价值。

因为：

ASR解决的是“听懂”，Agent解决的是“整理”。

六、场景三：让 WorkBuddy 把客户需求变成“选型确认表”

传感器销售真正容易出错的地方，是客户只提供了一部分参数。

比如客户说：

“I need a pressure sensor, 0-10 bar, 4-20mA.”

看起来信息不少。

但真正选型时可能还缺：

• 测量介质
• 过程接口
• 电气接口
• 工作温度
• 环境温度
• 过载压力
• 精度要求
• 安装方式
• 防护等级
• 认证要求

所以我不会让 AI 直接输出：

“推荐型号 XXX。”

而是让它先判断：

信息是否足够？

例如：

然后生成：

当前信息不足以完成最终选型，请客户补充以下参数……

这一点对我来说非常重要。

因为在销售工作中：

“不知道”比“猜错”更安全。

这一点在传感器行业尤其关键，因为“缺一个参数”往往不是小问题，而是选型错误的前兆。举几个真实场景里的坑：

• 介质兼容性：同样是 0–10 bar 压力传感器，测洁净水、液压油、还是强腐蚀性化学介质，膜片材质可能要从 316L 不锈钢换成 Hastelloy C276，选错直接导致膜片腐蚀穿孔；
• 过程接口：G1/2"、NPT、M12 电气接口、齐平膜还是引压式——接口不对，装都装不上；
• 输出信号：4–20 mA 是两线制工业标准，但在无布线、需诊断的场合，IO-Link 或 WirelessHART 反而更合适，这不是“更先进”而是“更匹配工况”；
• 温度相关误差：用 Pt100 测温度时，引线电阻会带来零点漂移，长距离必须采用三线或四线制补偿。

这些都不是 AI 看一眼“0–10 bar、4–20 mA”就能替你拍板的。所以我的工作流宁可输出一张“缺失参数清单”，也绝不直接给型号——这正是“不知道比猜错更安全”的工程含义。

七、我给 WorkBuddy 使用的核心 Prompt

为了让这个流程可以重复使用，我没有每次重新描述需求，而是把它做成固定提示词模板。

核心逻辑类似：

这个 Prompt 对我来说比“让 AI 更聪明”重要。

因为它给 Agent 设置了一个非常明确的边界：

缺参数就问，不确定就标记，不允许为了完整而编造。

八、这套工作流目前到底做到哪一步？

这里我想特别诚实地说明实际状态。

截至本文撰写时，我已经实际使用和验证的是 WorkBuddy 相关的自动化和提示词工作流，包括：

• Prompt 模板设计
• 销售场景拆解
• WorkBuddy 工作流设计
• 内容和结构化信息生成
• 自动化任务的配置和运行验证

需要特别说明：截至本文撰写时，已经实际配置并运行验证的 WorkBuddy 自动化，是“内容生产”这条线（本文的方法论与提示词设计，正是从这条线沉淀而来，并已经真实运行产出过多篇草稿）；而本文主角“销售 AI 助理”的完整链路（OCR → ASR → WorkBuddy 协同）目前以工作流设计为主，OCR / ASR 的实际接入属于下一阶段。

而 OCR、ASR、TTS、生视频等腾讯云 AI Skills 的组合，是我基于这次活动进一步设计的应用方案。

因此：

本文不会把“计划接入”写成“已经接入”，也不会把设计目标写成实际业务成果。

对于我来说，这一点非常重要。

因为这篇文章真正想分享的是：

如何把一个真实销售场景拆成可以由不同 AI 能力协同完成的工作流。

九、已落地的真实产物（可复现证据）与下一步规划

前面反复强调“销售 AI 助理”的 OCR/ASR 链路是规划中。为让本文经得起复现，我把已经真实跑通的 WorkBuddy 自动化单独列出来：它不是本文主角，但它是同一套“Skill + 定时任务”方法论的真实验证，也是读者照着就能做的最小可复现样例。

(1) 技能包 sensor-article-engine 真实配置（节选）

文件 ~/.workbuddy/skills/sensor-article-engine/SKILL.md，核心包括：

• 12 个轮换主题池（选型计算、标定批处理、展会问答、竞品分析、标准翻译、报价单、CRM、双语手册、价格监控、售后工单、月度简报、招投标）；
• 强制“诚实原则”：规划中事项必须标“规划中”，量化数据标“测算”而非“实测”；
• 配套定时任务频率 FREQ=DAILY;INTERVAL=2（每 2 天）。

(2) 定时任务真实配置

• 任务 ID：automation-1785318652068
• 频率：FREQ=DAILY;INTERVAL=2（每 2 天触发）
• 模式：Craft
• 动作：调用 sensor-article-engine 技能，生成投稿草稿并落盘

(3) 真实落盘草稿（截至 2026-08-14，共 9 篇；文件名与日期均可在工作目录核实，非虚构）

这 9 篇就是“Skill + 定时任务”真实产出的证据。读者只要在 WorkBuddy 建一个同款技能、配一个同款定时任务，就能复现同样的内容生产线——这正是“可复现”的落地方式。

下一步规划（销售 AI 助理完整链路）：

• OCR / ASR：把客户 Datasheet、铭牌、语音转写接入，形成“输入 → 结构化 → 需求匹配”闭环；
• TTS / 生视频：把已生成内容再加工成音频与短视频，覆盖多平台分发；
• 长周期效率统计：记录单篇生成时间、人工修改时间、参数纠错次数、采用率，用真实样本说话。

以上均为下一阶段设计，本文不将其描述为已落地。

十、这条工作流的价值，与我工作习惯的改变

如果只是做一个：

“OCR识别图片”

其实很难和其他参赛作品形成明显区别。如果只是：

“ASR把会议录音变成文字”

同样是非常成熟的应用。对于传感器销售来说，我真正感兴趣的是：

怎样把这些能力嵌入一条完整的工作流程。

传感器销售的工作并不是一个单点任务，它是：

信息获取 → 技术理解 → 产品选型 → 客户沟通 → 报价 → 售后 → 内容沉淀

AI Skills 解决其中不同环节的信息处理，Agent 把能力串起来。所以我的理解不是“我用了几个 AI 工具”，而是：

“我把几个 AI 能力变成了一条销售工作流。”

这种认识也改变了我的习惯。以前遇到客户信息，我习惯直接处理：客户发资料 → 我看资料 → 我回复客户。现在我先问一句：

这条信息能不能结构化？

图片 → OCR；语音 → ASR；一堆参数 → WorkBuddy 结构化；参数不完整 → 自动生成待确认问题；确认完成 → 再进入选型和报价。变化很小，但让我意识到：

AI Agent 真正能帮助销售的，不只是“回答问题”，而是重新设计信息流。

十一、我为什么坚持人工把关与诚实边界

有人会问：既然 AI 可以识别参数、分析需求，为什么不让它直接选型和报价？

因为传感器不是一个适合完全自动决策的行业。同一个“0–10 bar 压力传感器”，被测介质、过程接口、工作温度、精度、安装空间、防护等级、认证要求不同，对应的产品可能完全不同。所以我的分工是：

AI 负责： 读取、转写、整理、归类、提示。 人负责： 确认、判断、选型、报价、承诺。

这可能不是最“炫”的 Agent，但更接近真实企业环境。

另一层原因是诚实。我在技术销售场景里最看重的一条原则是：

不要让 AI 为了“完整”而编造。

如果客户没提供工作温度，就写“待确认”；无法确定型号，就写“需要进一步确认”；没有真实数据，就不要生成一个漂亮的百分比；功能还没实际接入，就明确写“规划中”。因为：

AI 应用的可信度，比 Demo 看起来有多完整更重要。

十二、我的实践建议

1. 不要一开始就做“大而全”的 Agent

先从一个真实痛点开始。例如“客户发来的 Datasheet，我需要花很多时间整理参数”，那就先做 OCR + WorkBuddy，跑通之后再考虑其他能力。

2. Skill 负责专业能力，Agent 负责流程

我的理解是：OCR 擅长识别，ASR 擅长转写，WorkBuddy 负责组织和处理业务逻辑。不要让一个工具承担所有任务，把不同能力组合起来，反而更容易构建稳定的工作流。

十三、结语：我想做的不是一个“会聊天的销售机器人”

这次参加「腾讯云 AI Skills 最佳实践」，让我重新思考了一件事：

对于一个每天处理大量技术资料和客户信息的传感器销售来说，真正有价值的 AI，不一定是一个什么都能做的超级 Agent。它可以从非常具体的事情开始：

帮我读一份 Datasheet。 帮我听懂一次客户沟通。 帮我整理十几个零散参数。 帮我发现客户还缺哪些选型信息。

然后，再把这些能力一步一步串起来。

我现在设计的这套 Sensor AI Assistant，还在持续完善过程中。目前已经完成的是 WorkBuddy 工作流和相关自动化能力的实践（第九节已列真实产物）；OCR、ASR、TTS、生视频等 Skills 的组合应用，则是我下一阶段希望继续验证的方向。

我希望最终形成的不是一个“替销售回复客户”的机器人，而是一个：

能够帮销售处理信息、整理需求、减少重复劳动，同时把最终判断权留给人的 AI 工作伙伴。

对于传感器这种参数复杂、应用场景高度依赖专业判断的行业来说，我认为这可能才是 AI Agent 更现实、也更值得落地的方向。

让 AI 处理重复的信息，让人把时间留给真正需要经验和判断的工作。

本文实践状态说明

本文中的工作流设计基于作者实际的传感器销售工作场景。

文中明确区分：

• 已完成： WorkBuddy 工作流设计、Prompt 模板、自动化相关实践及基础验证（第九节所列技能包、定时任务、9 篇真实草稿均为已落地证据）；
• 应用设计： 将腾讯云 OCR、ASR 等 AI Skills 接入上述工作流的方案；
• 后续规划： TTS、生视频及更完整的多 Skills 协同；
• 人工环节： 产品参数确认、最终选型、报价和客户正式回复。

本文不将规划中的能力描述为已经落地，也不使用虚构客户、订单、销售额、故障率或效率数据作为实际成果。

涉及具体产品型号和技术参数时，应以对应产品官方 Datasheet 和实际应用条件为准。