第 7 章 加载并验证第一个 GCP Skill
我停在了“+”按钮前
Skill 把任务方法、指令和工具能力打包起来，装好以后可以反复调用。放到 GCP 场景里，我最关心来源、权限、输入输出、失败方式和金标准测试。页面上的“+”只负责安装，前面这些问题不会由按钮替你回答。
我在“专家·技能·连接器 → 技能”里搜索了“Excel 文件处理”，结果里出现 SkillHub 的 Simple Excel。我没有继续点击安装。它的说明没有写成 GCP 用途，本教程也没有完成来源、权限和金标准验证。停在这里，只表示当前证据不够，并不是在评价这个 Skill 的质量。
第一次验证，选“文件版本一致性核对”
第一次验证可以把范围限定在“文件版本一致性核对”：
- 输入只有虚构的文件清单、版本号、日期和批准状态；
- 动作是解析、比较、找冲突、生成待确认项；
- 输出是差异清单，不做批准判断；
- 金标准答案容易由人工预先制作；
- 不需要 EDC、HIS、邮箱或共享盘连接器。
这项任务只碰虚构元数据，标准答案也容易提前做好。用它可以把 Skill 的读取、比较、输出和失败路径都跑一遍，又不会碰病历或 SAE 处置。
我把安装拆成六个检查动作
- 确认来源：作者、维护方、版本、更新记录是否可识别。
- 阅读范围：Skill 会读取哪些文件、调用哪些命令或外部服务。
- 限制权限：首轮只允许虚构工作区；写入只到
output/。 - 准备金标准：人工先做一份正确答案，不边运行边改标准。
- 测试失败样例：缺版本、日期冲突、重复文件、资料不足。
- 记录结论：通过、限制使用或拒绝，并写明复核人和版本。
使用 GCP Skill 加载与验证清单 留痕。
金标准里要故意放错题
为“版本一致性核对”至少准备四例：
| 用例 | 输入 | 期望输出 |
|---|---|---|
| 正常 | 方案 3.0、ICF 2.1 均已批准且在用 | 无冲突，列出依据 |
| 缺字段 | ICF 没有批准日期 | 待确认，不推算日期 |
| 冲突 | 文件夹名写 2.0，页脚写 2.1 | 版本冲突，同时保留两个来源 |
| 过期/错用信号 | 追踪表在用版本与批准版本不同 | 标记待调查，不自行判定偏离或根因 |
每例都检查：数量、字段、来源、未知值、输出路径、原件是否修改。
回到 WorkBuddy，按这个顺序加载
- 进入“专家·技能·连接器 → 技能”。
- 用任务名搜索，优先选择组织内部已验证版本。
- 打开说明，核对来源、权限和输入输出；不要把“推荐”“精选”当批准证据。
- 完成审批后再点击“+”或“添加技能”。
- 回到一个全新的虚构测试任务，通过“+ → 技能”加载它。
- 运行金标准测试并保存 WorkBuddy 版本、模型、Skill 版本和结果。
- 不通过时移除或停用，修订后重新验证。
安装过程如果要求新的网络、磁盘、登录或凭证权限，我会停在授权发生前，把新增范围交给 IT 或信息安全评估。
Skill 没改，模型更新也可能改结果
模型版本变化，可能让同一套 Skill 得到不同的解析结果；Skill 自己更新，也可能扩大文件范围。下面六项只要有一项变化，我都会重新跑金标准：
- WorkBuddy 主版本；
- 模型名称或版本；
- Skill 版本或依赖；
- 输入模板/文件结构；
- 连接器和权限；
- 验收规则。
统计编程还要防共模错误
主程序员和验证程序员如果都用同一模型、相似提示词，很可能对同一处规范歧义做出相同的错误解释。两边的代码看起来互相验证，错误来源却是同一个。验证程序员仍要从规范独立推导；遇到歧义，交给人走 spec 澄清流程。
能留下这五项证据，再谈投入使用
- [ ] 没有把公开 Skill 的展示标签当批准依据
- [ ] 首轮只使用虚构数据和窄工作区
- [ ] 正常、缺字段、冲突和资料不足样例均测试
- [ ] 记录了 WorkBuddy、模型和 Skill 版本
- [ ] 明确了禁用场景和重新验证触发条件