一个人活成一支队伍，WorkBuddy 多技能组合实战助力 OPC 创业者

不惑.

406人浏览 · 2026-08-17 21:17:05

不惑. · 2026-08-17 21:17:05 发布

一人公司（OPC，One Person Company）这件事，Paul Jarvis 2019 年写 Company of One 的时候就提出来了。当时读完很兴奋，真上手做才发现，不是能力不够，是时间不够。客户入网要核身份，合同条款要逐页摘，发票要一张张录，客户消息要及时回。每件事单独看都不难，叠在一起就崩溃了。

2026 年工具终于跟上理念了。腾讯云把 27 个 AI 能力封装成了标准化技能包（Skills），WorkBuddy 提供了多技能协同的编排底座。我花了两个月时间，在自己的企业服务对接平台上，把几个高频业务场景做成了"组合技"。每个组合技解决一个具体痛点，技能之间自动串联，一个人就能驱动整条业务链。

这篇文章记录的不是功能测评，是实战。选了哪些技能，怎么组合的，跑通之后给 OPC 创业者带来什么实际价值，踩了哪些坑，都写在这里。

一，OPC 创业者的时间都去哪了

我做的是企业服务对接平台，上游对接供应商，下游撮合客户。生意模式不复杂，但日常运营全是脏活累活。

痛点一，文档处理吃掉近半时间

身份证、营业执照、增值税发票、供应商合同、财务报表，格式五花八门，来源有拍照有扫描。我统计过自己一个月的数据，文档处理相关的工作占总时长的 47%，但创造的价值最低。人工处理的速度有上限，错误率还随疲劳度往上升。

痛点二，身份核验链条断裂

企业服务行业对 KYC 要求严格。客户入网要完成实名认证、人脸比对、活体检测，还得防 AI 换脸攻击。以前这几个环节分散在不同工具里，数据没法自动流转。身份证信息手动录完，得切到另一个平台做人脸验证，验证结果再手动回填。链条一断就得重来。

痛点三，客户沟通响应慢

客户咨询集中在工作时间，问题高度重复。合同进度查询、发票状态确认、开户审核结果，每个问题都得翻系统查记录再回复。高峰期消息回不过来，客户体验差。

痛点四，内容合规审不过来

2026 年 AIGC 内容满天飞，平台上隔三差五冒出 AI 生成的产品图、虚假宣传视频、甚至机器批量生成的营销文案。光靠人工审根本审不过来。

四个痛点说到底都是同一个问题，缺人手。招人走不通，唯一出路是用 AI 把重复性工作自动化。但单个 AI 工具只能解决单个环节，要覆盖完整业务链，得把多个技能串起来用。这就是"组合技"的由来。

Tencent Launches WorkBuddy

二，为什么选 WorkBuddy 做编排底座

市面上 AI 工具很多，我选 WorkBuddy 作为编排底座，主要看中三点。

第一，WorkBuddy 是腾讯 CodeBuddy 团队推出的全场景 AI 原生智能体桌面工作台，2026 年 3 月 9 日正式上线。跟传统 AI 聊天工具的核心区别在于，它不是在聊天，是在帮你干活。你用自然语言描述任务，它自主拆解、规划步骤、调用工具、执行操作，最终交付可直接验收的工作成果。它提供三种核心模式，Ask 模式处理简单咨询和文案，Plan 模式自动拆解多步骤复杂任务，Craft 模式生成文档、表格、PPT 并保存到本地。

第二，技能生态够用。WorkBuddy 支持三种扩展形态，技能 Skill、连接器 Connector、MCP 服务器。腾讯云这次放出来的 AI Skills 矩阵涵盖五大类共 27 个标准化技能包，全部上架在 SkillHub（skillhub.cn）和 ClawHub（clawhub.ai）上。连接器底层走 MCP 协议，内置了 QQ 邮箱、腾讯文档、腾讯乐享等，也能通过 ~/.workbuddy/mcp.json 挂自定义 MCP Server。关键是不用写 API 调用代码，装好技能配好密钥，直接用自然语言驱动就行。

第三，多技能协同是真正的杀手锏。WorkBuddy 内置了 100 多个领域专家，覆盖运营、设计、数据、开发、财务、法务这些角色。技能是能力，专家是能力加视角，团队是多专家分工。我第一次试的时候说了句把这份合同的关键信息提取出来再做份摘要，它自己拆成了文档抽取加文本摘要两步，串起来执行，中间不用我干预。这个体验跟单独调 API 完全不一样。

这里有个判断我想强调一下。WorkBuddy 的多技能协同本质上是声明式编排，你描述目标，它规划路径调工具。这比手写 pipeline 代码灵活太多。但灵活的另一面是，你得学会怎么把需求描述清楚，后面踩坑部分会专门讲这个。

三，四套组合技的整体设计

我的思路是这样的，把日常业务拆成四个高频场景，每个场景选几个技能组合成"招式"，再通过 WorkBuddy 的对话接口统一调度。

用户指令 → WorkBuddy 专家团 → 技能自动编排 → 结果交付

四套组合技的技能配置如下。

组合技	技能组合（官方名称）	解决的问题
客户入网一条龙	身份证识别 + 营业执照识别 + 人脸静态活体检测（高精度版） + 人脸比对 + AI 人脸防护盾	证件信息提取 + 身份核验全链路
文档处理流水线	实时文档抽取 Agent + 表格识别 V3 + 通用票据识别（高级版）	合同要素提取 + 表格识别 + 发票录入
语音交互闭环	腾讯云语音识别 ASR + 腾讯云语音合成 TTS	语音输入 + 语音应答
AIGC 内容审查	图片 AI 生成识别 + 视频 AI 生成识别 + 文本 AI 生成识别 + 多模态理解模型 VITA	图片/视频/文本 AIGC 检测 + 视频内容理解

14 个技能统一使用腾讯云标准 SecretId / SecretKey 鉴权，签名算法为 TC3-HMAC-SHA256（V3 版本）。环境变量配置为 TENCENTCLOUD_SECRET_ID 和 TENCENTCLOUD_SECRET_KEY。一套密钥通吃所有技能，这是多技能组合时最省心的地方。

架构说明，整体三层架构，底层技能能力层、中间 WorkBuddy 编排层、上层业务交互层，标注各技能与场景的对应关系

3.1 测试数据准备

后面的四套组合技每一步都附带了对应的脱敏测试数据，方便你在 WorkBuddy 里直接复现。数据放在工作目录的 mock-data/ 文件夹下，按组合技分四个子目录。

mock-data/
├── combo1-customer-onboarding/     # 组合技一：客户入网
│   ├── idcard-ocr-result.json      # 身份证识别结果（脱敏）
│   ├── bizlicense-ocr-result.json  # 营业执照识别结果（脱敏）
│   ├── face-verify-report.json     # 人脸核验三连汇总报告
│   └── test-cases-150.csv          # 150条测试案例
├── combo2-doc-processing/          # 组合技二：文档处理
│   ├── contract-extract-result.json     # 合同要素提取（正常）
│   ├── contract-extract-anomaly.json    # 合同要素提取（异常）
│   ├── table-recognition-result.json    # 表格识别V3结果
│   ├── invoice-batch-result.json        # 发票批量识别结果
│   └── test-cases-full-430.csv          # 430条测试案例
├── combo3-voice-interaction/       # 组合技三：语音交互
│   ├── asr-result-zh.json          # ASR识别结果（中文）
│   ├── asr-result-mixed.json       # ASR识别结果（中英混说）
│   ├── tts-result.json             # TTS语音合成结果
│   ├── voice-qa-pipeline.json      # 端到端语音问答链路报告
│   └── test-cases-voice-200.csv    # 200条测试案例
└── combo4-aigc-audit/             # 组合技四：AIGC审查
    ├── image-aigc-detection-result.json  # 图片AI检测
    ├── video-aigc-detection-result.json  # 视频AI检测
    ├── text-aigc-detection-result.json   # 文本AI检测
    ├── vita-multimodal-result.json       # VITA多模态分析
    ├── audit-summary-report.json         # 审查汇总报告
    └── test-cases-aigc-audit-120.csv     # 120条测试案例

每个 JSON 文件包含 Response（腾讯云 API 标准响应格式）和 _metadata（测试元数据）两部分。CSV 文件用 UTF-8 BOM 编码，Excel 可直接打开。所有姓名、身份证号、公司名称等敏感信息均已脱敏处理，可放心用于 WorkBuddy 测试。

在 WorkBuddy 中使用这些数据有两种方式。第一种，把 JSON 文件放到 WorkBuddy 工作目录，在指令中引用文件路径让 WorkBuddy 读取解析。第二种，把 CSV 文件导入 WorkBuddy，用表格技能做批量统计和可视化分析。后面每个组合技的具体操作步骤里都会标明用哪个数据文件。

四，组合技一，客户入网一条龙

客户入网是我这个平台最高频的操作。传统手工流程是这样的，收到客户发来的身份证照片和营业执照照片，手动核对信息，录入 CRM 系统，让客户做一次人脸验证，最后人工审核通过。整个流程平均 35 分钟，还容易出错。

这套组合技把 5 个技能串成一条完整的身份核验链路，目标是把 35 分钟压到 5 分钟以内，全程自动化，只在最后一步做人工确认。

4.1 技能安装，对话式操作

安装方式非常简单，不需要命令行，直接在 WorkBuddy 对话框里用自然语言告诉它要装什么就行。比如对 WorkBuddy 说，帮我安装身份证识别、营业执照识别、人脸静态活体检测、人脸比对、AI 人脸防护盾这五个技能。WorkBuddy 会自动从 SkillHub（skillhub.cn）或 ClawHub（clawhub.ai）搜索并安装，全程对话式操作，不需要打开终端。

也可以在 WorkBuddy 客户端的技能管理页面手动搜索安装。访问 https://skillhub.cn/skills/tencentcloud-ocr-idcard 等 SkillHub 页面，或 https://clawhub.ai 搜索对应 slug，点击安装即可。

用户指令，帮我安装以下五个技能，
身份证识别 tencentcloud-ocr-idcard，
营业执照识别 tencentcloud-ocr-bizlicense，
人脸静态活体检测 tencentcloud-faceid-detectlivefaceaccurate，
人脸比对 tencentcloud-faceid-compareface，
AI 人脸防护盾 tencentcloud-faceid-detectaifakefaces

安装完成后，前往腾讯云官网产品控制台申请 API 密钥（SecretId / SecretKey），在 WorkBuddy 的环境变量或设置页面完成配置。这五个技能统一使用标准的 SecretId 和 SecretKey 鉴权，配置一次即可通用。多数服务提供每月 1000 次免费额度，人脸识别提供每月 1 万次免费额度，首次开通各技能对应的腾讯云 AI 产品可享受一定免费额度，对初期成本控制很有帮助。

4.2 第一招，证件信息秒提取

第一个环节用身份证识别（tencentcloud-ocr-idcard）提取身份证信息。这个技能调用 IDCardOCR 接口，API 域名为 ocr.tencentcloudapi.com，默认 QPS 限制 20 次/秒。官方标称识别准确度达 99% 以上，支持中国大陆二代身份证正反面所有字段。

它能识别正反面全部 9 个字段，人像面包括姓名、性别、民族、出生日期、住址、身份证号，国徽面包括发证机关、有效期限。还支持 7 种告警功能，复印件告警、翻拍告警、边框不完整告警、PS 痕迹告警、临时身份证告警、有效日期不合法告警、图片模糊告警。告警码体系覆盖 -9101 到 -9111 共 11 种状态码。

用户指令，帮我识别这张身份证，提取姓名身份证号地址等字段，
同时检测是否为复印件或翻拍件，把结果整理成表格

# 如果暂无真实身份证图片，可先用脱敏数据验证流程
# 读取 mock-data/combo1-customer-onboarding/idcard-ocr-result.json，
# 解析 Response 中的 9 个字段和 7 种告警结果，整理成表格输出

WorkBuddy 会自动调用身份证识别技能，传入图片路径或 Base64，返回结构化结果。如果手上暂时没有真实证件图片，可以让 WorkBuddy 读取 mock-data/combo1-customer-onboarding/idcard-ocr-result.json，这个文件包含一份完整的脱敏身份证识别结果（姓名张*明，Quality=88，全部告警通过），用来验证后续流程的数据流转是否通畅。关键参数配置如下。

参数	值	说明
Config	{“CropIdCard”: true, “CopyWarn”: true, “BorderCheckWarn”: true, “ReshootWarn”: true, “DetectPsWarn”: true}	同时开启裁剪和五种告警
CardSide	不传	自动判断正反面
CardWarnType	Advanced	开启进阶 PS 检测，效果更佳但耗时更长
EnableRecognitionRectify	true（默认）	身份证号、出生日期、性别三字段矫正补齐

截图位置 3，身份证识别结果输出截图，展示 WorkBuddy 返回的结构化数据（姓名、身份证号、地址等字段，以及各项告警检测结果，注意对真实信息打码）

有个细节值得注意。身份证照片质量直接影响识别效果。官方建议图片分辨率 500x800 以上，支持 PNG/JPG/JPEG/BMP 格式，Base64 编码后不超过 10M。手机拍的清晰照片识别率很高，但客户偶尔发来微信压缩过的图，分辨率掉到 500px 以下，偶尔出现身份证号末位识别错误。

我的解决办法是在 WorkBuddy 里加一步预检，先用通用文字识别（高精度版）（tencentcloud-ocr）跑一遍，如果置信度低于 90 就提示客户重新发高清图。这个预检步骤让整体识别准确率从 97.3% 提升到 99.1%。计费方面，身份证识别后付费刊例价为 0.15 元/次（1 万次以内），阶梯递减至 0.06 元/次（100 万次以内），每月有 1000 次免费额度。

紧接着用营业执照识别（tencentcloud-ocr-bizlicense）提取营业执照信息。这个技能调用 EnterpriseLicenseOCR 接口，默认 QPS 限制 5 次/秒。能识别统一社会信用代码、公司名称、法定代表人、注册资本、组成形式、成立日期、营业期限、经营范围等全字段。

我开启了两个关键配置。EnableCopyWarn 设为 true 检测复印件和翻拍件，EnablePeriodComplete 设为 true 自动拼接营业期限。营业执照上的期限经常分两行印，手动录入容易出错，自动拼接这个功能挺实用。实测营业执照全字段识别准确率 98.5%，营业期限拼接准确率 100%。支持 PNG、JPG、JPEG 格式，不支持 GIF，图片 Base64 编码后不超过 7M。

同样，mock-data/combo1-customer-onboarding/bizlicense-ocr-result.json 里有一份完整的营业执照识别结果（深圳市**科技有限公司，信用代码 91440300MA5****8X，营业期限已自动拼接为"2020年06月15日至长期"），可以直接让 WorkBuddy 读取验证。

4.3 第二招，人脸核验三连

证件信息提取完成后，接下来是人脸核验环节。这里用到三个技能串联，组成一条完整的身份核验链路。

人脸静态活体检测（高精度版） → 人脸比对 → AI 人脸防护盾

第一招，人脸静态活体检测（高精度版）（tencentcloud-faceid-detectlivefaceaccurate）做活体检测。调用 DetectLiveFaceAccurate 接口，API 域名 iai.tencentcloudapi.com，Version 2020-03-03。客户对着摄像头拍一张自拍，这个技能判断照片是真人还是翻拍的。它增强了对高清屏幕、裁剪纸片、3D 面具等攻击的防御能力，官方标称攻击拦截能力约为业内同类型产品的 4 到 5 倍。

接口返回一个 0 到 100 的 Score 值，阈值分档为 [5, 10, 40, 70, 90]，官方推荐阈值为 40。我把阈值调到了 72，代价是偶尔误拒真人，好处是基本杜绝了纸片翻拍攻击。图片要求 Base64 后不超过 5M，JPG 长边不超过 4000px，其他格式不超过 2000px，人脸尺寸需大于 100x100 像素，宽高比建议接近 3:4。计费方式为后付费 0.15 元/次，每月有 1 万次免费额度。

第二招，人脸比对（tencentcloud-faceid-compareface）做人脸比对。调用 CompareFace 接口，把客户自拍和身份证照片上的人脸做相似度比对。接口使用 3.0 算法模型（FaceModelVersion 参数），误识率与分数的对应关系为，千分之一误识率对应 40 分，万分之一对应 50 分，十万分之一对应 60 分，一般超过 50 分可认定为同一人。

我的配置是 50 分以下直接拒绝，50 到 60 分之间人工复核，60 分以上自动通过。这个分层策略在测试中表现不错，误拒率控制在 1.2% 以内。接口还支持 QualityControl 参数控制图片质量（0 到 4 五档），NeedRotateDetection 参数支持旋转图片识别。

第三招，AI 人脸防护盾（tencentcloud-faceid-detectaifakefaces）做 AI 换脸检测。调用 DetectAIFakeFaces 接口，API 域名 faceid.tencentcloudapi.com，Version 2018-03-01，默认 QPS 限制 5 次/秒。这一步在 2026 年尤其重要，AIGC 换脸技术越来越成熟，静态照片已经很难用肉眼分辨。

这个技能基于多模态 AI 大模型算法，能识别换脸攻击、高清翻拍、黑产批量攻击、水印等痕迹。它返回三个风险等级，Low（低风险）、Mid（中度疑似）、High（高度疑似）。同时返回 AttackRiskDetailList 攻击痕迹详情列表和 ExtraInfo 中的 SimilarityScore（取值范围 0 到 2，默认阈值 0.6，小于 0.6 判定为攻击）。我的规则是 High 直接拒绝，Mid 转人工复核，Low 放行。图片建议 480x640 分辨率，不超过 10M，支持 JPG 和 PNG。

三个技能的串联在 WorkBuddy 里是自动完成的。指令示例如下。

用户指令，对客户 {姓名} 做身份核验，
先做活体检测，再和身份证照片做人脸比对，
最后检测是否有 AI 换脸攻击，
把三步结果汇总成报告，给出通过或拒绝的建议

# 验证流程时可用脱敏数据
# 读取 mock-data/combo1-customer-onboarding/face-verify-report.json，
# 参照其中的报告格式，核对三步检测结果：
# 活体检测 Score=84（阈值72，通过）
# 人脸比对 Score=78.5（阈值60，通过）
# AI换脸检测 RiskLevel=Low（SimilarityScore=0.12，通过）
# 最终结论：PASS

WorkBuddy 会自动按顺序调用三个技能，中间不需要人工干预。每一步的结果会自动传入下一步作为输入。最后生成一份包含三步检测结果的汇总报告，附带通过或拒绝的建议。整个过程大约 8 秒。face-verify-report.json 这个文件就是一份完整的汇总报告模板，三步检测的结果（活体 Score=84、比对 Score=78.5、AI 换脸 RiskLevel=Low）和最终结论（PASS）都写在里面，可以直接拿来跟 WorkBuddy 生成的报告做对比验证。

4.4 实战效果

这套组合技跑了两个月，处理了 150 个真实客户入网案例。其中 132 个正常案例，18 个异常案例（6 个复印件、4 个翻拍件、3 个 PS 修改件、3 个 AI 换脸、2 个非本人操作）。

指标	手工流程	组合技自动化	变化
平均处理时长	35 分钟	3.2 分钟	-91%
信息录入错误率	8.3%	0.5%	-94%
异常案例检出率	61%（11/18）	94%（17/18）	+54%
AI 换脸检出率	0%（人工无法识别）	100%（3/3）	-

18 个异常案例中，自动化流程漏掉了 1 个。那是一张低分辨率翻拍件，活体检测 Score 刚好卡在 70 分阈值线上，人脸比对也过了 50 分。后来我把阈值调到 75，漏检率降为零，但误拒率上升到 3.1%。这是一个精度和召回的权衡，最终选择 72 分作为活体检测阈值，兼顾安全和体验。

成本算一笔账。150 个测试案例，5 个技能各调用 150 次，单次费用 0.15 元，总 API 调用费用约 112.5 元，扣除免费额度后实际支出约 70 元。平均每个客户入网的成本约 0.47 元。相比人工处理 35 分钟的时间成本，这个 ROI 非常可观。

完整的 150 条测试案例数据在 mock-data/combo1-customer-onboarding/test-cases-150.csv，包含每条案例的姓名脱敏、身份证号脱敏、案例类型、异常子类型、身份证质量分、活体分数、比对分数、AI 换脸风险等级、最终结果、处理耗时和 API 费用。在 WorkBuddy 里可以这样分析：

用户指令，读取 mock-data/combo1-customer-onboarding/test-cases-150.csv，
统计正常案例和异常案例的比例，
分析 5 类异常（复印件/翻拍/PS/AI换脸/非本人）各自的检出率，
按活体分数分布画个直方图，输出分析报告

五，组合技二，文档处理流水线

文档处理是 OPC 场景中最吃时间的工作。合同、发票、财报，三类文档各有特点，用的技能也不一样。我把三个 OCR 技能组合起来，分别对付不同类型的文档。

5.1 合同要素秒提取，实时文档抽取 Agent

供应商合作协议通常有 20 到 30 页，但真正关心的字段就那么几个。合同编号、签约双方、合同金额、有效期、付款方式、违约条款、争议解决方式。人工通读再摘录，一份合同平均 90 分钟。

实时文档抽取 Agent（tencentcloud-ocr-extractdocagent）正好解决这个问题。它调用 ExtractDocAgent 接口，API 域名 ocr.tencentcloudapi.com，默认 QPS 限制 5 次/秒。官方说明提到它的模型参数更小、速度更快，推荐场景为实时性要求高（30 秒以内）且样本输入输出 Token 不超过 2000 的实时场景。

它的核心原理是按自定义字段从图片或 PDF 中结构化抽取信息，支持 KV 对（KeyType=0）和表格（KeyType=1）两种字段类型。通过 ItemNames 参数配置自定义字段名称、类型和提示词。

用户指令，从这份合同 PDF 中提取以下字段，
合同编号，甲方名称，乙方名称，合同金额，有效期起，有效期止，
付款方式，违约金比例，争议解决方式，
把结果输出为 JSON 格式

# 技能内部构造的 ItemNames 参数
ItemNames = [
    {"KeyName": "合同编号", "KeyType": 0},
    {"KeyName": "甲方名称", "KeyType": 0},
    {"KeyName": "乙方名称", "KeyType": 0},
    {"KeyName": "合同金额", "KeyType": 0},
    {"KeyName": "有效期起", "KeyType": 0, "KeyPrompt": "合同生效日期"},
    {"KeyName": "有效期止", "KeyType": 0, "KeyPrompt": "合同终止日期"},
    {"KeyName": "付款方式", "KeyType": 0},
    {"KeyName": "违约金比例", "KeyType": 0},
    {"KeyName": "争议解决方式", "KeyType": 0}
]

这里有一个关键技巧。KeyPrompt 参数是字段的描述提示词，能显著提升抽取准确性。比如合同里写的是生效日期和终止日期，但定义的字段名是有效期起和有效期止，不加提示词的话模型可能匹配不上。加了 KeyPrompt 说明这是合同生效日期和合同终止日期，准确率从 89% 提升到 96.8%。

mock-data/combo2-doc-processing/ 目录下有两个合同提取结果文件可以对照。contract-extract-result.json 是正常案例，9 个字段全部提取成功，平均置信度 97.7%，合同编号 HT-2026-0518-007，合同金额 38 万元。contract-extract-anomaly.json 是异常案例，一份低质量扫描件，乙方名称、有效期起、有效期止三个字段缺失，平均置信度只有 45.3%。两个文件对比着看，能直观感受图片质量对抽取效果的影响。

用户指令，读取 mock-data/combo2-doc-processing/contract-extract-result.json，
解析 Response.Items 中每个字段的 Confidence 值，
找出置信度最低的 3 个字段，输出优化建议

再读取 contract-extract-anomaly.json，对比两个文件的字段提取完整度，
总结低质量扫描件容易丢失哪些字段

接口还支持 EnableCoord 返回字段坐标，EnableAudit 开启审核逻辑（支持字段配置比对内容和语意规则），PdfPageNumber 指定 PDF 页码。计费方式为按页计费，自适应价格模式下抽取字段大于 10 记两次费用，小于等于 10 记一次费用。免费额度 1000 次（首次开通，一年有效）。实测单份合同抽取平均 12 秒，比人工快了 450 倍。

5.2 嵌套表格不怕了，表格识别 V3

有些客户发来的报价单是表格格式的 PDF，或者直接拍照的纸质表格。表格识别 V3（tencentcloud-ocr-recognizetableaccurate）调用 RecognizeTableAccurateOCR 接口，默认 QPS 限制 2 次/秒。它基于腾讯优图实验室自研新一代生成式表格结构还原算法，官方标称平均技术指标达到 96% 以上。

它能识别常规有线表格、无线表格、多表格、嵌套表格，还支持旋转表格图片识别，支持导出 Excel 格式。最让我惊喜的是它对无线表格的识别能力。以前用其他 OCR 工具，无线表格基本识别不了，出来的结果是一堆乱序文字。这个技能用了 V3 引擎，对复杂版式的处理能力明显优于 V2。测试集中有一份供应商产品报价单，包含 3 个嵌套表格，总计 47 个单元格，识别准确率达到 95.3%。

这份供应商产品报价单的识别结果完整保存在 mock-data/combo2-doc-processing/table-recognition-result.json 里，5 行 8 列共 35 个单元格，包含序号、产品名称、规格型号、单位、单价、数量、金额、备注 8 列，其中合计行有一个合并单元格。文件里的 TableInfos.Cells 记录了每个单元格的行列坐标和文本内容，ExcelFile 字段是导出的 Excel Base64 数据。在 WorkBuddy 里可以这样验证：

用户指令，读取 mock-data/combo2-doc-processing/table-recognition-result.json，
解析 TableInfos 中的 Cells 数组，
按行列坐标还原成表格，输出为 Excel 文件，
同时统计每个单元格的 Confidence，标注低于 95 的单元格

实战提醒，表格识别 V3 的默认频率限制是 2 次/秒，是所有 OCR 技能中最严格的。批量处理大量表格文档时，一定要在 WorkBuddy 的工作流里加节流逻辑。我采用每处理完一份文档后等待 600 毫秒的策略，稳定运行在 1.5 次/秒的速率。QPS 叠加包价格为 10 到 100 QPS 区间 55 元/QPS/日或 1120 元/QPS/月。

5.3 发票批量录入自动化，通用票据识别（高级版）

发票录入是最机械的工作。通用票据识别（高级版）（tencentcloud-ocr-vatinvoice）调用 VatInvoiceOCR 接口，默认 QPS 限制 10 次/秒。它支持 6 种发票类型，增值税专用发票、增值税普通发票、增值税电子专票、增值税电子普票、电子发票（普通发票）、电子发票（增值税专用发票）。

能识别发票全字段，包括发票代码、发票号码、开票日期、合计金额、校验码、税率、合计税额、价税合计、购买方识别号、销售方识别号、购买方名称、销售方名称、服务名称、规格型号、数量、单价、金额、税额、收款人、复核、开票人等。还支持 PDF 多页识别和一页中多张混合票据的自动分类。

实战工作流是这样的。客户把发票照片打包发过来，在 WorkBuddy 里输入指令，帮我把这个文件夹里的发票全部识别，提取关键字段，生成 Excel 汇总表。WorkBuddy 自动遍历文件夹，逐张调用票据识别技能，最后用 xlsx 技能生成 Excel 文件。

用户指令，批量识别 /invoices/ 目录下所有发票图片，
提取发票号码，开票日期，购方名称，销方名称，
价税合计金额，税额，明细条目，
汇总生成 Excel 表格，按开票日期排序

# 无真实发票时可先用脱敏数据验证批量流程
# 读取 mock-data/combo2-doc-processing/invoice-batch-result.json，
# 该文件包含 12 张发票的批量识别结果，
# 覆盖增值税专票/普票/电子专票/电子普票/电子发票6种类型，
# 解析 batch_summary 中的统计信息，按 invoice-batch-result 的 excel_output 配置生成汇总表

invoice-batch-result.json 里展示了 12 张发票的完整批量处理结果，涵盖 6 种发票类型各两张。每张发票的 Response 包含发票号码、开票日期、购销双方信息、明细条目、价税合计等全字段。文件的 batch_summary 部分有批量统计信息（总价税合计 156,830 元，总税额 9,410 元，平均置信度 98.7%），excel_output 部分定义了汇总表的列名和排序规则，可以直接作为 WorkBuddy 生成 Excel 的模板。

5.4 实战效果

这套组合技处理了 80 份合同、300 张发票、50 份表格文档。

文档类型	数量	手工耗时	自动化耗时	准确率	API 费用
供应商合同	80 份	120 小时	16 分钟	96.8%	约 27 元（0.34 元/页）
增值税发票	300 张	25 小时	40 分钟	99.1%	约 45 元（0.15 元/次）
表格文档	50 份	15 小时	8 分钟	95.3%	约 7.5 元（0.15 元/次）
合计	430 份	160 小时	64 分钟	-	约 79.5 元

430 份文档从 160 小时压到 64 分钟，API 总费用约 79.5 元，扣掉免费额度后实际花了不到 50 块。换算一下，以前要 20 个工作日才能处理完的文档量，现在 1 个多小时搞定，花费不到一顿午餐的钱。这就是组合技的力量。

完整的 430 条测试数据在 mock-data/combo2-doc-processing/test-cases-full-430.csv，按文档类型分为合同 80 条、表格 50 条、发票 300 条，每条记录包含文档类型、子类型、案例类型、异常子类型、字段提取数、总字段数、平均置信度、处理耗时和 API 费用。

用户指令，读取 mock-data/combo2-doc-processing/test-cases-full-430.csv，
按文档类型分组统计平均置信度和处理耗时，
分析 13 条异常案例的异常子类型分布，
对比三类文档的准确率差异，生成可视化对比图

六，组合技三，语音交互闭环

前两套组合技解决的是文档处理效率问题。但还有一个场景同样关键，客户沟通。高峰期一天几十条消息，大多是重复问题。需要一套语音驱动的自动应答机制来兜底。

6.1 听得懂，腾讯云语音识别 ASR

腾讯云语音识别 ASR（tencentcloud-asr）是微信同款 ASR 引擎，API 域名 asr.tencentcloudapi.com，Version 2019-08-23。它提供三种识别模式，一句话识别（SentenceRecognition，60 秒以内的短音频同步识别）、录音识别极速版（FlashRecognize，2 小时或 100MB 以内的中长音频同步返回）、录音文件识别（CreateRecTask 异步创建，DownloadRecResult 下载结果，支持 5 小时长音频）。

支持普通话、英语、粤语、日语、韩语、德语等 20 多种语言，中英粤混说场景行业领先。通过 EngineModelType 参数指定引擎模型，如 16k_zh（中文）、16k_zh_en（中英混说）、16k_yue（粤语）、16k_en（英语）、16k_ja（日语）、16k_ko（韩语）、16k_multi_lang（多语言）等。

我的实战场景是实时语音问答。客户发来语音消息，WorkBuddy 先用 ASR 转成文字，再交给大模型理解意图并生成回复，最后用 TTS 把回复转成语音发回去。实测整个链路的平均延迟为 3.4 秒，体验上可以接受。

ASR 技能的执行规范很严格。ClawHub 页面显示该技能作者为 stardusten，版本 v0.1.5，下载量超过 2100 次。它有一套预检流程，先运行 inspect_audio.py 探测音频参数（采样率、时长、格式），再按时长和大小路由到不同的识别脚本。缺少 ffmpeg 时会自动安装。收到新凭证时先跑 self_check.py 自检。这些设计让技能的稳定性很好，我这边连续运行三个月没有出现崩溃。

实测数据，用 200 条真实客户语音做了测试。中文语音识别准确率 97.8%，中英混说场景准确率 94.2%。一句话识别模式（60 秒以内）平均响应 1.2 秒，录音极速版（2 小时以内）平均响应 8 秒。计费按调用量阶梯，10 万次 80 元起，量越大单价越低。

mock-data/combo3-voice-interaction/ 下有两个 ASR 识别结果文件。asr-result-zh.json 是中文一句话识别，音频时长 4.8 秒，识别出 28 个字（“你好，我想问一下我们上个月签的那份技术服务合同的进度怎么样了”），置信度 98.5%，每个字都带时间戳。asr-result-mixed.json 是中英混说场景，客户说了"invoice number 2440017890"等英文插入词，引擎用 16k_zh_en，置信度 95.1%，比纯中文略低。

用户指令，读取 mock-data/combo3-voice-interaction/asr-result-zh.json，
解析 Response.WordList 中的逐字时间戳，
计算平均每字的识别耗时，
再读取 asr-result-mixed.json，对比两个引擎的置信度差异

6.2 说得自然，腾讯云语音合成 TTS

腾讯云语音合成 TTS（tencentcloud-tts）调用 TextToVoice 接口，API 域名 tts.tencentcloudapi.com。支持基础音色、精品音色、大模型音色和超自然大模型音色四档。通过 ModelType 参数选择（1=基础、2=精品、3=大模型），VoiceType 参数指定音色 ID（如 101001 为智语音色）。

我用的是默认的 101001 语音类型，声音自然度还行。免费额度方面，超自然大模型音色 2 万字符、大模型音色 10 万字符、基础和精品音色 800 万字符。后付费精品音色约 0.3 元/万字符，大模型音色约 0.4 到 1 元/万字符。

有个实践经验值得分享。单次合成文本建议不超过 300 字符，这也是官方推荐。如果回复内容较长，让 WorkBuddy 自动分段合成，再拼接成完整音频。这样做的好处是每段合成的质量更稳定，不会出现长文本合成时尾部语音质量下降的问题。TTS 还支持 Volume（音量 0 到 10）、Speed（语速 -2 到 6）、SampleRate（采样率）等参数微调。

tts-result.json 记录了一次完整的分段合成结果，98 字符的回复文本被分成 3 段独立合成，总音频时长 11.8 秒。Subtitles 数组里每段文字都带 BeginTime 和 EndTime 时间戳，可以作为字幕使用。_metadata 里记录了音色 ID（101001 智语音色）、自然度评分（4.2 分）和计费字符数（98 字符，费用 0.003 元）。

6.3 闭环，端到端语音问答

完整的语音问答链路是这样的。

客户语音消息 → ASR 转文字 → 大模型理解意图 → 检索业务数据 → 生成回复 → TTS 转语音

业务数据检索这一步，通过 WorkBuddy 的连接器接入了腾讯文档和 TAPD。连接器底层采用 MCP 协议，在 WorkBuddy 设置界面的连接器入口查看并启用，按提示完成授权即可。客户问合同进度，系统自动去 TAPD 查，问发票状态就查腾讯文档里的发票台账。

voice-qa-pipeline.json 是一次完整的端到端语音问答执行报告，记录了 7 个步骤的详细数据。Step 1 接收语音（200ms），Step 2 音频预检探测采样率 16000Hz（150ms），Step 3 ASR 识别出 28 字（1200ms），Step 4 意图理解识别为"合同进度查询"并通过 TAPD 连接器检索到合同 HT-2026-0518-007（850ms），Step 5 大模型生成 98 字回复（600ms），Step 6 TTS 分 3 段合成 11.8 秒音频（2100ms），Step 7 发送语音回复（150ms）。总延迟 5.25 秒，API 费用 0.006 元。

用户指令，读取 mock-data/combo3-voice-interaction/voice-qa-pipeline.json，
解析 pipeline_steps 中每一步的 duration_ms，
画出 7 步链路的耗时瀑布图，
标注哪一步是延迟瓶颈（预期是 TTS 合成）

6.4 实战效果

语音交互上线后，白天的消息回复响应时间从平均 12 分钟降到 30 秒以内。客户满意度明显提升，有客户反馈说感觉团队扩充了。实际团队还是我一个人，只是背后多了一群 AI 专家在帮忙。

指标	数据
测试语音条数	200 条
ASR 中文准确率	97.8%
ASR 中英混说准确率	94.2%
端到端平均延迟	3.4 秒
TTS 自然度评分（5 分制）	4.2 分
客户满意度（问卷）	4.3 分（n=45）

200 条测试语音的完整数据在 mock-data/combo3-voice-interaction/test-cases-voice-200.csv，包含每条语音的识别模式、引擎类型、音频时长、字数、ASR 准确率、端到端延迟、TTS 自然度、客户满意度和 API 费用。190 条正常案例覆盖中文和中英混说两种语言，10 条异常案例覆盖背景噪音、低音量、语速过快、方言干扰、英文识别失败、音频截断等 10 种异常。

用户指令，读取 mock-data/combo3-voice-interaction/test-cases-voice-200.csv，
按引擎类型分组统计 ASR 准确率，
分析 10 条异常案例的子类型和对应的准确率下降幅度，
计算端到端延迟的分位数（P50/P90/P99）

七，组合技四，AIGC 内容审查

做对接平台最怕什么，怕用户上传假东西。2026 年 AIGC 内容满天飞，平台上隔三差五就冒出 AI 生成的产品图、虚假宣传视频、甚至机器批量生成的营销文案。光靠人工审根本审不过来，得建一套覆盖图片、视频、文本三种媒介的自动化审查链路。这套组合技用了 4 个技能，是四套组合技里技能最多的。

7.1 图片真伪一秒辨，图片 AI 生成识别

图片 AI 生成识别（tencentcloud-aigc-recog-image）专门检测图像是不是 AIGC 生成的，支持 Stable Diffusion、Midjourney、GPT-4o 这些主流模型。它覆盖四种场景，AI 全图生成、局部重绘、AI 换脸、AI 风格化。这个技能对合规很重要，国家《AIGC 标识办法》要求对 AI 生成内容做标识，你得先能识别出来才能标识。

返回结果分三档，Pass 是真实图片，Review 是存疑需人工复核，Block 是大概率 AI 生成。同时给置信度分数。计费 0.1 元/张，按量日结。

用户指令，检查这个文件夹里的产品图片哪些是 AI 生成的，
输出检测结果，标注每张图的判定结果和置信度分数

# 无真实图片时可用脱敏数据验证检测逻辑
# 读取 mock-data/combo4-aigc-audit/image-aigc-detection-result.json，
# 该文件包含 6 张图片的检测结果，覆盖 4 种 AIGC 场景：
# 真实照片(Pass, 96.8%)、SD全图生成(Block, 98.2%)、
# MJ全图生成(Block, 95.7%)、GPT-4o局部重绘(Review, 72.3%)、
# AI换脸(Block, 91.5%)、AI风格化(Review, 68.5%)

image-aigc-detection-result.json 是一份批量检测结果，6 张图片覆盖了全部 4 种检测场景。真实产品照片判定 Pass（置信度 96.8%），Stable Diffusion 生成的图片判定 Block（置信度 98.2%，检测到频率伪影、纹理不一致、光照异常），Midjourney 图片也判 Block（置信度 95.7%）。GPT-4o 局部重绘判 Review（置信度 72.3%，检测到局部重绘边界），AI 换脸判 Block（置信度 91.5%，检测到人脸边缘融合、肤色不一致）。每个结果的 DetectionDetails.detected_artifacts 里列出了具体的检测特征，拿来跟 WorkBuddy 的检测结果对比很有参考价值。

有个坑得提一下。这个技能有个必填环境变量 TENCENTCLOUD_AIGC_RECOG_IMAGE_BIZ_TYPE，是审核策略编号，要去腾讯云控制台的 AI 生成检测配套策略页面创建并获取。不配的话直接报错，报错信息还不太直观。我第一次调的时候卡了二十分钟才找到原因，后来发现 ClawHub 的技能详情页底部有说明，早点去看能省不少时间。

7.2 视频也能验，视频 AI 生成识别

光审图片不够，平台上还有产品演示视频。视频 AI 生成识别（tencentcloud-aigc-recog-video）能识别视频是不是 AI 生成的，支持 Veo3、Hunyuan、Jimeng、Hailuo 这些模型产出的视频。跟图片检测类似，返回 Pass、Review、Block 三档结果加置信度。

实测中发现一个有意思的现象。AI 生成的视频在画面连贯性上已经做得很逼真，但在某些帧的边缘细节上还是会露出马脚，比如手指运动轨迹不自然、光影变化跟物理规律不符。这个技能的检测逻辑应该就是抓这些特征。测试中 AI 生成视频的检出率比图片高一些，可能因为视频的信息量更大，可分析的维度更多。

video-aigc-detection-result.json 记录了一段 15 秒 AI 生成视频的检测结果，375 帧中抽取 15 帧分析，判定 Block（置信度 94.8%）。frame_results 数组记录了每帧的检测置信度，8 帧的置信度都在 92% 到 96.8% 之间，波动很小说明检测结果稳定。detected_artifacts 列出了 4 种异常特征：时间不一致、帧闪烁、运动伪影、物理规律违反。

7.3 文案也能查，文本 AI 生成识别

第三个是文本 AI 生成识别（tencentcloud-aigc-recog-text），根据文本的形式和内容特征判断是不是 AI 写的。这个技能我用得比较意外，一开始没规划到，后来发现平台上有些供应商的产品描述文案明显是 ChatGPT 批量生成的，读起来通顺但空洞，还带翻译腔。

这个技能对文本长度有要求，太短的文本特征不明显，建议至少 200 字以上。我拿 100 篇产品描述文案测试，50 篇人工写的，50 篇 AI 生成的。结果 AI 生成文本的检出率 89.2%，人工文本的误判率 6%。比图片和视频检测略低，但作为初筛工具已经够用。

text-aigc-detection-result.json 是一篇 528 字营销文案的检测结果，判定 Block（置信度 93.5%）。文件里的 paragraph_scores 对 4 个段落分别评分，每段的 AI 概率都在 91.8% 到 95.2% 之间。overall_perplexity（困惑度）只有 13.2，远低于人类写作的阈值 30。burstiness_score（突发性）0.12，也低于人类写作的 0.3 阈值。这两个指标是判断 AI 文本的核心特征，困惑度低说明用词可预测性强，突发性低说明句子长度分布均匀，都是大语言模型的典型输出特征。

7.4 内容理解交给 VITA

前三个技能解决的是"是不是 AI 生成"的问题。多模态理解模型 VITA（tencentcloud-vita）解决的是"内容本身合不合规"的问题。它兼容 OpenAI 协议的 Chat Completions 接口，模型名 vita-video-3.0 和 vita-video-long，支持图片、视频、音频的理解与问答。

VITA 按 Token 计费，输入 1.2 元/百万 Token，输出 3.5 元/百万 Token。我主要拿它做两件事。一是审产品视频的关键帧，检测有没有违禁品或违规宣传画面。二是给视频自动生成内容摘要，替换掉供应商自己写的那些水分很大的产品描述。第二个用途是意外发现的好功能，VITA 写的摘要比供应商自己写的还靠谱。

vita-multimodal-result.json 是一段 30 秒产品宣传视频的分析结果，VITA 把视频分成 5 个场景：品牌 Logo 展示（0-6 秒）、产品界面演示（6-12 秒）、用户办公场景（12-18 秒）、3D 功能动画（18-24 秒）、联系方式结尾（24-30 秒）。每个场景都标注了检测到的物体、行为和异常标记。OverallAssessment 里判定该视频疑似包含 AIGC 内容（置信度 78.5%），给出了三条证据：场景间光照过渡不自然、3D 动画存在运动模糊伪影、开场画面有轻微闪烁。这个结果帮助决定对该视频做进一步的人工复核。

7.5 实战效果

测试集包含 600 张图片（300 真实 + 300 AI 生成）、80 个视频（40 真实 + 40 AI 生成）、100 篇文本（50 人工 + 50 AI 生成）。

指标	数据
图片 AI 生成识别准确率	94.2%
图片误报率（真实判为 AI）	3.1%
图片漏报率（AI 判为真实）	5.8%
图片高风险（score > 80）检出率	98.7%
视频 AI 生成识别准确率	96.1%
文本 AI 生成识别准确率	89.2%
文本误判率（人工判为 AI）	6.0%
VITA 视频审核准确率	91.5%
VITA 视频摘要平均耗时	7.8 秒（3 分钟视频）
总检测费用	约 78 元

漏报率 5.8% 看起来偏高，拆开看发现漏掉的主要是高质量产品级渲染图，这类图人眼都难分辨。视频检测的准确率反而更好，96.1%。文本检测因为短文本特征不明显，准确率垫底但也接近 90%。所有中风险结果（score 60 到 80 之间）统一转人工复核，这部分大约占总量的 8%，人工工作量可控。

120 条测试数据的完整记录在 mock-data/combo4-aigc-audit/test-cases-aigc-audit-120.csv，按媒介分为图片 60 条、视频 20 条、文本 40 条，每条包含检测场景、预期结果、检测标签、置信度、检测到的模型名称、处理耗时和 API 费用。另外 audit-summary-report.json 是一份月度审查汇总报告，统计了 120 条内容的 Pass/Review/Block 分布（84 Pass / 16 Review / 20 Block）、检测准确率 96.2%、误报率 2.1%、漏报率 1.7%，以及各类媒介的费用明细（总费用 24 元）。

用户指令，读取 mock-data/combo4-aigc-audit/test-cases-aigc-audit-120.csv，
按媒介类型分组统计 Pass/Review/Block 的分布比例，
分析 Block 案例中检测到的 AIGC 模型分布，
再读取 audit-summary-report.json，核对费用明细和准确率指标

八，四套组合技跑下来的整体账

四套组合技全部上线跑了两个月后，我做了一次全面的效果评估。数据采集周期是 2026 年 5 月到 6 月，共 61 天。

维度	改造前	改造后	变化
日均文档处理量	8 份	52 份	+550%
客户入网处理时长	35 分钟/例	3.2 分钟/例	-91%
消息响应时间	12 分钟	30 秒	-96%
内容审核覆盖率	20%（抽检）	100%（全量）	+400%
月度运营成本	约 8000 元（含外包）	约 1200 元（API 调用费）	-85%
错误率	8.3%	0.5%	-94%

成本这一块展开说。改造前每月花 5000 元请外包处理文档录入，加 3000 元办公软件和工具订阅费，合计 8000 元。改造后外包砍掉了，每月 API 调用费约 1200 元。拆开看，OCR 类调用占 40%，人脸核身占 28%，语音类占 12%，AIGC 检测类（图片+视频+文本）占 12%，VITA 占 8%。WorkBuddy 本身注册送 5000 Credits，加少量 Credits 订阅每月 200 元左右。总成本从 8000 元降到 1400 元（含 WorkBuddy 订阅），降幅 82.5%。

数据说明，降本增效综合评估，展示改造前后六个维度的数据对比，红色为改造前基线，绿色为改造后指标

整体算下来，我一个人借助 WorkBuddy 和腾讯云 AI Skills，干完了以前需要 3 到 4 个人才能覆盖的活。月度成本从 8000 元降到 1400 元，降幅 82.5%。这就是 OPC 的核心价值，用 AI 专家团替代人力扩充，一个人就是一家公司。

九，给 OPC 创业者的几点建议

技能覆盖度够用吗

四套组合技共计调用 14 个腾讯云 AI 技能，覆盖了 OPC 场景中最高频的业务环节。客户入网的身份核验全链路（5 个技能串联），文档处理的合同发票表格三大类型（3 个 OCR 技能），语音交互的 ASR 加 TTS 双向链路（2 个语音技能），内容合规的图片检测加视频检测加文本检测加视频理解（4 个 AIGC 类技能）。腾讯云 AI Skills 生态共 5 大类 27 个技能包，这套方案调用了其中的 14 个，占比超过一半。OPC 场景的核心业务环节都能找到对应的技能，不需要额外开发自定义模型。

准确率够不够用

场景	技能	核心准确率指标	实战结论
身份证识别	IDCardOCR	99.1%（官方 99%+）	达到生产可用标准
营业执照识别	EnterpriseLicenseOCR	98.5%	全字段识别稳定
人脸活体检测	DetectLiveFaceAccurate	拦截率 4-5 倍竞品	阈值 72 下误拒率 3.1%
人脸比对	CompareFace	98.9%（阈值 50，FAR 0.01%）	分层策略下误拒率 1.2%
AI 换脸检测	DetectAIFakeFaces	100%（3/3）	高风险场景必需
合同要素提取	ExtractDocAgent	96.8%（KeyPrompt 优化后）	实时场景表现优秀
表格识别	RecognizeTableAccurateOCR	95.3%（官方 96%+）	无线表格仍有提升空间
发票识别	VatInvoiceOCR	99.1%	6 种发票类型全覆盖
ASR 中文识别	SentenceRecognition	97.8%	中英混说略降至 94.2%
TTS 语音合成	TextToVoice	4.2 分/5 分制	基础音色够用
图片 AI 生成识别	IMS 接口	94.2%	高风险检出率 98.7%
视频 AI 生成识别	视频检测接口	96.1%	信息维度多，表现优于图片
文本 AI 生成识别	文本检测接口	89.2%	短文本受限，适合长文初筛
VITA 视频审核	Chat Completions	91.5%	适合初筛加人工复核

整体准确率在 89% 到 99% 之间。OCR 类和身份核验类技能表现最稳，AIGC 检测类因媒介类型不同有差异，视频检测优于图片优于文本。所有准确率数据与官方标称值对比，偏差在合理范围内。

不足和下一步

实战中踩到的坑也不少。第一，图片 AI 生成识别的漏报率 5.8% 偏高，主要集中在高质量产品级渲染图上，只能靠人工复核兜底。第二，文本 AI 生成识别对短文本效果一般，200 字以下的文案误判率明显上升。第三，无线表格识别准确率 95.3%，复杂嵌套表格仍有信息丢失。第四，VITA 视频审核准确率 91.5%，初筛够用但不能完全替代人工。第五，多技能协同的数据传递依赖指令描述的精确度，对 Prompt 工程能力有一定要求。第六，表格识别 V3 的 2 次/秒 QPS 限制在批量场景下偏紧，得买 QPS 叠加包或者加节流逻辑。

下一步我计划做四件事。第一，把 WorkBuddy 的企业微信连接器配好，让客户直接在企微里语音提问，实现真正的不离企微全自动交互。第二，接入更多技能，混元生 3D（hy-3d-generation）做产品展示素材，视频特效（tencentcloud-video-effects）做营销内容，图片人像分割（tencentcloud-yt-segment-portrait）做商品抠图。第三，参考腾讯云官方推荐的财报三表勾稽自动化案例（基于表格识别 V3 技能构建），把这套 OPC 工作流也打包成自定义技能上架 SkillHub，让其他创业者能直接复用。第四，探索试题批改 Agent（tencentcloud-ocr-questionmarkagent）在教育培训场景的延伸应用。

最后的话

做完这套系统，我的判断是这样的。腾讯云 AI Skills 把复杂的 AI 能力封装成了开箱即用的技能包，27 个标准化技能覆盖语音、OCR、AIGC、安全、VITA 五大类，统一鉴权、统一安装、一键调用。不需要懂深度学习，不需要写模型推理代码，装好技能配好密钥就能跑。WorkBuddy 把这些技能编排成了一条自动化流水线，100 多个领域专家自动分工，一个人就能驱动。

OPC 这个概念以前听起来像天方夜谭，一个人怎么开公司。这套组合技给出的答案是，一个人加 WorkBuddy 加腾讯云 AI Skills，能开。方案有瑕疵，但已经跑起来了。14 个技能覆盖四个核心业务场景，整体准确率 89% 到 99%，月度成本降幅 82.5%，人力替代比 1 比 3 到 4。技能的组合方式有无数种，这套只是其中一种解法。找到适合自己业务场景的组合，比追求大而全更重要。