我一路问 WorkBuddy，用腾讯云 OCR Skills 在几分钟内完成了投标审查

采购评审最费时间的，并不是阅读某一份文件，而是在招标要求、技术响应和报价表之间反复核对。供应商写了“满足”未必真的满足，报价更低也未必能够推荐。

我用 WorkBuddy 从零搭了一套投标审查流程。不懂密钥、OCR 开通、Python 依赖和 Skill 开发也可以直接问它；它会给出入口、定位问题，并完成能够代办的本地操作。流程由腾讯混元 Hy3 驱动，在我测试期间处于限时免费体验阶段，具体期限以官方页面为准。

结果很直接：8 份逐页 PDF 生成 4 个评审文件，符合性矩阵覆盖 30 个检查点。流程识别出供应商 B 的两份报价相差 3,959.96 元，还把其自评的“12 日不满足”纠正为 12 <= 15**，实际满足**。

两家供应商跨文件符合性审查和报价对比

单组材料实际处理为几十秒到几分钟。若人工完成同等摘录、核算和整理需要一小时以上，效率会达到 10 倍量级；这是按人工基线换算的场景测算，不是严格的对照实验。

先把业务问题说清楚

测试材料是一份虚构的智慧仓储标签打印设备采购项目。招标文件要求采购 12 台工业条码标签打印机、12 个备用打印头以及安装调试和培训服务，核心门槛包括：打印速度不低于 200 mm/s、分辨率不低于 300 dpi、支持 Wi-Fi 6、15 个日历日内完成交付、整机及打印头质保不少于 3 年，同时还要求提交技术响应表、分项报价表、交付计划、质保承诺函和类似项目说明。

我故意准备了两家不完全合格的供应商：A 的 Wi-Fi 是 Wi-Fi 5，交付要 18 日，盖章版质保承诺函没有提交；B 的分辨率只有 203 dpi，质保只有 1 年，报价摘要还和独立报价表对不上。B 的响应表把 12 日交付自评为“不满足”，但招标要求是最多 15 日，12 <= 15**，最终应该判定为满足**。这个错误专门用来检验流程会不会照抄供应商结论。

输入文件按页准备，是因为实时文档抽取接口对 PDF 使用页码参数，逐页上传更容易在不同 WorkBuddy 版本中复现。最终完整审查使用 8 个文件：招标文件 2 页，A 响应文件 2 页和报价表 1 页，B 响应文件 2 页和报价表 1 页。报价表虽然只有一页，也放在 pages/ 目录中统一管理。

先装两个识别 Skill，再确认分工

这套流程的分工很明确。

腾讯云的表格识别（V3）接口支持常规表格、无线表格和多表格检测，能够返回单元格文字，并支持保存为 Excel。这个案例里的报价表没有边框，型号、数量、税率、小计和质保挤在同一行，先恢复单元格结构，后面的金额核对才有可靠输入。

添加腾讯云表格识别 V3 Skill

搜索时我直接使用完整 slug tencentcloud-ocr-recognizetableaccurate。它在本案例中只负责报价页：保留 9 个业务列、三行明细和合计行，不负责判断供应商是否满足招标要求。

第二个安装的是 tencentcloud-ocr-extractdocagent。它处理招标文件和响应文件，把“15 日内”“不少于 3 年”这类自然语言约束抽成字段，同时返回来源页码。两个 Skill 的职责没有重叠：一个恢复表格，一个抽取文档字段。

添加腾讯云文档抽取 Agent Skill

两个 Skill 安装后，我回到“我安装的”页面确认开关状态。此时文档抽取 Agent 和表格识别 V3 都已启用，后续自定义 Skill 才有可以调用的底层能力。安装阶段的客户端版本是 5.3.11，正式审查时升级到了 5.3.14，入口和调用方式没有变化。

WorkBuddy 中已安装并启用的两个腾讯云 OCR Skills

从“不知道怎么配”开始，直接问 WorkBuddy

安装成功不等于能够调用腾讯云接口。我没有先查一遍配置教程，而是直接让 WorkBuddy 做一次不上传业务文件的最小自检。它检查了 Skill 文件、鉴权变量和运行依赖，随后把问题缩小到两处：TENCENTCLOUD_SECRET_ID/KEY 没有读到，tencentcloud-sdk-python 没有安装。原本模糊的“Skill 用不了”，到这里已经变成两个可以处理的具体问题。

第一次 OCR Skill 最小自检失败

我当时并不知道这组密钥应该去哪里创建，于是直接追问：“从哪获取 TENCENTCLOUD_SECRET_ID/KEY？”WorkBuddy 给出了腾讯云访问管理 CAM 的直达地址、创建步骤、可用的配置位置，以及 SecretKey 只显示一次的注意事项。这里不需要用户先弄懂 CAM 是什么，先照着准确路径完成必要操作即可。

WorkBuddy 反查腾讯云密钥获取路径

按照它给出的地址，我进入 CAM 的“API 密钥管理”页面创建密钥。这一步必须由账号本人完成；生产环境更适合使用仅授予 OCR 所需权限的子用户密钥，避免直接使用权限过大的主账号密钥。

在腾讯云 CAM 中创建 API 密钥

创建密钥后，我仍然不知道 OCR 服务从哪里开通，继续问一句“开通链接有吗”。WorkBuddy 随即返回文字识别控制台、API 密钥管理、智能结构化 OCR 和表格识别 V3 文档地址，并把“一键开通文字识别服务”的步骤列了出来。

WorkBuddy 返回 OCR 开通入口

密钥最初被我写进了 ~/.zshrc。我也分不清 Skill 具体从哪里加载环境变量，只告诉 WorkBuddy：“你现在看看呢，我配置好了。”它读取当前环境后发现，Skill 的 env_loader 不会自动 source ~/.zshrc，所以运行时依然拿不到凭证。接下来的修复由 WorkBuddy 完成：把同一组密钥落到加载器支持的 $HOME/.env，再把缺失的 tencentcloud-sdk-python 安装进托管 venv。再次自检时，两个 Skill 已能读取鉴权，Python SDK 也可以正常导入。

这段配置过程反而把 WorkBuddy 的作用体现得最直接：不知道就问，出错就把现状交给它查。 用户可以不知道 SecretId 在哪里创建，不知道 OCR 有没有开通，也不知道 Skill 如何加载环境变量。WorkBuddy 会根据实际检查结果给出下一步，并把它能执行的本地修复继续做完。它同时保留了必要的边界提醒：代码层全绿不等于云端接口已经可用，OCR 服务仍需在控制台开通。

WorkBuddy 修复密钥读取和 SDK 依赖，OCR 服务仍待开通

开通 OCR 后再核对免费资源包

按照 WorkBuddy 给出的链接打开文字识别控制台，页面提示当前账号尚未开通服务。勾选服务条款并点击“立即开通”，才算补齐云端接口的调用条件。这里的分工很清楚：WorkBuddy 负责诊断和带路，Skill 负责发起调用，涉及账号授权的创建密钥和开通服务仍由用户确认。

腾讯云文字识别服务开通页

服务开通后，我进入数据报表查看实际资源包。控制台中，表格识别 V3、文档抽取基础版和多模态版均显示剩余免费额度；按照官方免费额度说明，表格识别 V3 归入共享的 1000 次/月资源包，文档抽取 Agent 则是首次开通后 1000 次/用户、有效期 1 年。页面呈现的是当前账号已到账的资源包，Agent 的额度规则仍以官方说明和账号实际到账为准。

腾讯云 OCR 控制台的免费额度

从两个 Skill 到一个业务 Skill

单独安装两个能力包还不够。采购人员不应该每次都重新解释“先抽招标文件，再抽响应文件，再识别报价表，最后按门槛比较”。我也没有从头学习 Skill 目录规范、手写 SKILL.md 和校验脚本，而是进入 WorkBuddy 的“创建技能”，用自然语言说明输入文件、必须调用的两个 OCR Skill、判定规则和四个输出文件，让 skill-creator 创建 tender-compliance-reviewer。

在 WorkBuddy 中进入创建 Skill 的入口

这个自定义 Skill 里固化了四类规则：

1. 招标文件抽取项目编号、采购范围、核心技术指标、交付周期、质保期限、付款方式和必交文件。
2. 供应商响应抽取型号、逐项技术参数、交付承诺、质保承诺和缺失文件。
3. 报价表逐行保留名称、型号、数量、含税单价、税率、含税小计、交付周期、质保和合计。
4. 每项结论必须带招标要求、响应值、比较表达式、状态、文件名和页码；没有出现的材料只能标记为“缺失”，不同文件出现不同值则标记“待确认”。

投标符合性审查专用 Skill 创建完成

WorkBuddy 最终生成了完整的 Skill 目录、字段定义、判定规则、输出模板和构建脚本，并完成校验与打包。这里的“自定义”不是再训练一个模型，而是把业务字段、调用顺序和判定口径固定下来。Hy3 负责理解和组织任务，真正识别表格和文档的动作仍然落到两个腾讯云 Skill 上；流程既能用自然语言启动，又不会把专业识别全压在通用对话模型身上。

第一轮：先把招标文件变成门槛

正式测试的第一轮只上传招标文件两页，不上传任何供应商材料，也不把人工基准 CSV 提前交给 WorkBuddy。提示语要求每个字段附原文件名和页码，先得到招标方的结构化要求。

按招标文件字段抽取要求并调用自定义 Skill

右侧结果已经不是一段泛泛摘要，而是带来源的字段集合：打印速度至少 200 mm/s，分辨率至少 300 dpi，接口要求包含 USB、千兆以太网和 Wi-Fi 6，交付周期是合同生效后 15 个日历日，质保不少于 3 年，并且包含 4 小时响应、24 小时内给出处理方案的服务时限。

它还抽出了普通摘要容易漏掉的验收条件：支持 203 mm 外径纸卷、连续打印 500 张、断线重连后任务不丢失，以及安装 12 台设备并培训不少于 6 名仓库人员。每个条件都有来源页码，后面审查供应商时才有比较基准。

第二轮：供应商 A 的表格先恢复，再谈符合性

A 的第二轮输入是响应文件 p1、p2 和 供应商A_分项报价表_p1.pdf。在自定义 Skill 的约束下，响应文件交给文档抽取 Agent，报价表交给表格识别 V3。结果页明确写出了两条调用路径，报价表还导出了可编辑的 Excel 文件。

供应商 A 的响应抽取与无线报价表恢复

A 的技术响应并不复杂，难的是把它和招标门槛放到同一张表里：打印速度 250 mm/s，分辨率 300 dpi，质保响应 3 年，这三项满足；Wi-Fi 5 不等于 Wi-Fi 6，18 日也大于 15 日。商务响应里还出现了 48 小时给出处理方案，而招标要求是 24 小时，不能因为付款比例一致就把商务部分判成“无偏差”。

报价表识别结果保留了三行明细：TL-3000 共 12 台，含税小计 168,000 元；PH-TL3000 共 12 件，含税小计 18,960 元；服务包-A 为 8,000 元；合计 194,960 元。更值得注意的是，响应表写了整机 3 年质保，但报价表里的备用打印头和安装培训只写了 1 年。这个问题不能直接判定为不满足，也不能忽略，正确状态是 “待确认”。

第三轮：供应商 B 证明了为什么要保留原始值

B 的输入同样是两个响应页和一份单页报价表。这里我在提示语中特别加了一句：不要直接采信供应商填写的“满足/不满足”，同时保留供应商自评和基于招标门槛的独立核对。

供应商 B 的抽取结果和供应商自评复核

B 的 203 dpi 小于 300 dpi，1 年质保小于 3 年，这两项硬性偏差没有争议；12 日交付则相反，12 <= 15**，数值上满足。WorkBuddy 还指出 B 的响应文件报价摘要是 178,960 元，而独立报价表合计是 175,000.04 元**，两份文件里的备用打印头和安装培训金额也不一致。

当我用完全相同的文件和要求重复运行时，WorkBuddy 直接复用了已经生成的 B 结果，避免再次消耗 OCR 调用。这个机制适合日常处理，但做性能测试时要新建会话并确认调用记录，不能把缓存命中算成一次新的接口执行。

最终审查：四个文件和一次复核

完整审查把 8 个逐页文件一次性交给 WorkBuddy，要求先抽取招标门槛，再比较两家响应，最后核对报价明细。结果生成了四个可以继续流转的文件：30 项符合性矩阵、分级风险清单、报价对比 CSV 和一页审查摘要。

两家供应商跨文件符合性审查和报价对比

首轮汇总统计为 满足 11 项、不满足 8 项、缺失 3 项、待确认 8 项。A 的核心问题是无线网络、交付周期和服务响应时限；B 的核心问题是分辨率、质保期限、服务响应时限和报价文件冲突。WorkBuddy 没有把 B 的低价直接写成推荐，而是把 “硬性不满足” 和 “需要澄清” 分开交付，采购人员可以先处理影响资格的偏差，再处理材料补正和金额确认。

报价对比表保留了原始小数：B 的第一行单价是 12,666.67 元，小计是 152,000.04 元，三行相加得到 175,000.04 元。金额没有被格式化成整数，也没有用响应文件里的 178,960 元覆盖独立报价表。对于采购审查来说，这种可追溯的原始行比一句“B 报价更低”有用得多。

最后一轮复核：把模型的判断拉回规则

我没有把完整审查的摘要当成最终结论，而是再发起一次只针对 7 个边界项的复核，要求逐项输出“招标要求｜响应值｜比较表达式｜判定｜证据文件及页码”。这一步把结论重新落到数字和原文上。

七项边界条件的逐项复核结果

最终复核给出了清晰的结果：A 的 Wi-Fi 5、18 日交付和 48 小时处理方案均不满足；B 的 203 dpi、1 年质保和 48 小时处理方案不满足；B 的 12 日交付满足；B 未提交同类项目证明属于 缺失。结果中还保留了一个谨慎的提示：招标文本抽取结果只明确出现“类似项目说明”，是否严格要求“至少 2 个”的数量，仍应由采购人员回看完整招标文件确认。

这一步把流程的责任边界定得很清楚：它能把容易看错的数值重新算一遍，也能把两个文件的矛盾挑出来，但不会把“缺失”和“不满足”混成同一类，更不会替采购人员完成最终定标。

这一套 Skill 最终达到了什么效果

采购人员留下来的工作更聚焦：确认质保口径、判断缺失材料能否补正、决定冲突报价以哪份文件为准，以及复核硬性偏差的处理方式。实时文档抽取对 PDF 页输入仍有约束，长文件需要拆页；免费额度也不是无限调用。涉及合同效力、盖章真实性、报价有效性和最终定标时，仍应回到原文和制度完成签字确认。

结语

这次从空白 WorkBuddy 会话开始，整个过程没有要求我先弄清密钥获取、OCR 开通、环境变量加载或 Skill 开发。遇到不清楚的地方就直接问，遇到失败就让 WorkBuddy 检查当前状态；它给出入口、定位原因、完成本地修复，再把两个腾讯云 OCR Skill 组织成投标审查流程。最终，8 份文件进入 WorkBuddy，输出 4 个可继续流转的评审文件，每个关键判断都能回到原文、数字和证据。

对于采购、合同、验收和供应商准入这类材料密集型工作，我更愿意把 WorkBuddy 当成流程编排台，把专业 Skill 当成可验证的工具节点。模型可以快，输出可以自动生成，但最后一行结论仍然应该能回答三个问题：依据哪条要求，读到了哪个响应值，证据在文件第几页。