## 导语
![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/779a3496b92ec7ad5cd02f5626f626db.png)


“测试通过了，为什么上线后还是报错？”

在AI编程助手参与开发之后，这句话的含义变了。以前我们担心的是代码写错；现在还要担心模型拿着过期文档，把已经废弃的SDK、旧参数和旧调用方式写得非常像真的。代码能运行，只能证明它没有立刻崩溃，不能证明它使用的是当前版本，也不能证明它符合团队约定。

Google最近公开了一套很值得测试工程师借鉴的做法：为Gemini API准备一套Agent Skill，再用117条Prompt搭建Evaluation Harness，对比“没有Skill”和“启用Skill”时模型生成的代码。这个案例的价值不在于某个模型的分数，而在于它把“知识是否新鲜”变成了可以回归、可以量化、可以进CI的测试问题。citeturn3view0

这篇文章不讨论如何照抄Google的Skill，而是把这个思路翻译成测试团队可以落地的工作流：如何设计样本、如何检查工具调用、如何拦截过期SDK，以及如何判断一个Skill究竟是在帮忙，还是在制造新的错误。


## 一、Skill不是一段提示词，而是一层“可更新的测试知识”

很多团队第一次做Skill，会把它写成一大段“请遵守以下规则”。这很容易变成另一个静态说明书：模型能读到，但测试团队不知道它是否被使用，也不知道里面的版本信息什么时候过期。

Google的做法更接近一个可调用的知识组件。它把API能力、当前模型和SDK版本、示例代码以及官方文档来源组织在一起；Agent需要时，通过工具激活Skill、获取文档，再生成代码。这样，测试点就不再是“答案看起来像不像”，而是可以拆成下面四个问题：

1. Agent有没有激活正确的Skill？
2. Skill是否引用了当前版本的权威文档？
3. 生成的代码有没有调用已经废弃的接口？
4. 生成过程中的工具调用，能不能解释最后的代码从哪里来？

这四个问题分别对应知识发现、版本正确性、行为正确性和可追溯性。它们比单纯执行一次单元测试更接近AI代码在真实项目中的风险。

## 二、117条Prompt告诉我们：先做样本，再谈“效果很好”

Google在文章中披露，它用117条Prompt建立了一个评测集，覆盖Agentic Coding、聊天机器人、文档处理、流式调用和SDK特性等场景，并对比了启用Skill与未启用Skill时的结果。文章还提到，如果Agent继续使用旧SDK，评测会直接暴露这一问题；不同模型对Skill的收益也并不相同。citeturn3view0

对测试团队来说，这里有一个很重要的顺序：不要先写“我们的Skill让准确率提升了30%”，而要先固定Prompt样本和通过标准。

一个最小可用的样本应包含四类信息：

```json
{
  "id": "gemini-streaming-014",
  "prompt": "使用当前Python SDK实现流式输出，并处理空响应",
  "expected": {
    "sdk_major": 2,
    "must_use": ["stream", "error handling"],
    "must_not_use": ["legacy_generate_content"]
  },
  "sources": ["official-docs-url"]
}
```

注意，expected不是“答案必须和参考代码一模一样”。它应该描述不可妥协的工程事实：版本、必需能力、禁止调用、错误处理和数据来源。这样即使模型换了写法，测试仍然有效。

## 三、把最终代码拆成四个可判定的断言

如果只运行生成代码，测试很可能漏掉“代码能跑，但使用了旧接口”的情况。可以把每个Case拆成四个断言：
![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b03c2402b3825c3be4d060e8e502290f.png)

```python
def evaluate(case, result):
    return {
        "version_ok": result.sdk_major == case["expected"]["sdk_major"],
        "required_api_ok": all(
            api in result.used_apis for api in case["expected"]["must_use"]
        ),
        "legacy_api_absent": all(
            api not in result.used_apis for api in case["expected"]["must_not_use"]
        ),
        "source_traceable": bool(result.source_urls)
    }
```

真正落地时，`result`不应该只有一段代码文本，而应包含：模型输出、工具调用序列、Skill激活记录、引用的文档地址、依赖版本和构建日志。

这样做的好处是，失败原因会从“AI回答不对”变成可操作的分类：

- `version_ok=false`：知识或依赖版本过期；
- `required_api_ok=false`：Skill没有覆盖这个任务，或模型没有调用它；
- `legacy_api_absent=false`：模型知道新接口，但仍然混用了旧写法；
- `source_traceable=false`：输出看似正确，却无法追溯依据。

每一类失败都可以单独修复，也可以单独统计趋势。



## 四、把测试结果放进CI：Skill也要有“版本回归”

一个常见误区是：Skill一旦上线，就默认它永远正确。实际上，Skill和测试数据都可能过期。SDK发布新主版本、文档移动路径、参数改名，都会让一份曾经有效的Skill变成风险源。

建议每次Skill或依赖升级时自动执行下面的回归流程：

```text
拉取最新官方文档
  ↓
运行固定Prompt集
  ↓
记录Skill激活、工具调用、引用来源
  ↓
静态检查版本与废弃API
  ↓
构建/单测/最小运行
  ↓
输出按失败类型聚合的报告
```

门禁不要只设一个总分。可以设置三条硬规则：

1. 不允许出现已废弃API；
2. 每个生成结果必须至少有一个可验证的官方来源；
3. 关键场景的版本正确率不能低于上一次基线。

这比“平均得分提升了”更适合作为发布条件，因为平均分可能掩盖一个高风险的旧API调用。

## 五、三个适合初级工程师的Skill切入点

如果团队还没有完整的Agent评测平台，可以先从三个小Skill开始。它们不是越复杂越好，而是要能形成明确的输入、输出和断言。

**版本侦察Skill**：输入技术栈和任务，输出当前稳定版本、弃用列表和官方链接；测试它是否引用了最新文档。

**代码脚手架Skill**：输入业务场景，输出最小可运行代码；测试它是否带依赖锁定、异常处理和可运行命令。

**回归检查Skill**：输入生成代码和旧版本差异，输出新增API、删除API和潜在兼容性问题；测试它能否识别一组人工注入的旧接口。

这三个Skill解决的是初级工程师最常遇到的三个问题：我应该看哪个版本、生成的代码怎么跑、升级后哪里可能坏。先把它们做成可度量的小闭环，比一次性写一份“万能测试Skill”更容易成功。

## 六、Google案例给测试团队的真正提醒

Google的文章也提醒了一个容易被忽略的限制：Skill需要模型具备足够的推理和工具使用能力；有些场景下，简单的AGENTS.md或项目级规则反而更有效；而Skill本身也可能因为更新不及时而产生伤害。citeturn3view0

所以，Skill不是“装上就变聪明”的插件，而是一份需要持续测试的工程资产。它至少要有版本号、维护人、失效日期、样本集和回滚方式。每当官方SDK发生变化，都应该像升级生产依赖一样重新跑回归。

最终目标也不是让AI永远不犯错，而是让错误尽快暴露，且能回答三个问题：它为什么错、依据是什么、下次如何避免。做到这一步，Skill才真正从提示词变成了测试基础设施。

## 参考来源

Google Developers Blog：Closing the knowledge gap with agent skills

https://developers.googleblog.com/closing-the-knowledge-gap-with-agent-skills/

在AI编程助手参与开发之后，这句话的含义变了。以前我们担心的是代码写错；现在还要担心模型拿着过期文档，把已经废弃的SDK、旧参数和旧调用方式写得非常像真的。代码能运行，只能证明它没有立刻崩溃，不能证明它使用的是当前版本，也不能证明它符合团队约定。

3个Skills解决SDK版本、代码生成和回归测试，初级测试也能照着做

测试

人工智能

开发工具

AI编程助手生成代码时可能引用过期SDK，导致测试通过但上线报错。Google通过Agent Skill与117条Prompt评测集，将知识新鲜度转化为可回归、可量化、可进CI的测试问题。本文提出四类断言验证版本、API、废弃调用与来源追溯，并设计版本侦察、脚手架、回归检查三类Skill落地工作流，确保Skill作为可更新的测试资产持续保障代码正确性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI编程助手生成代码时可能引用过期SDK，导致测试通过但上线报错。Google通过Agent Skill与117条Prompt评测集，将知识新鲜度转化为可回归、可量化、可进CI的测试问题。本文提出四类断言验证版本、API、废弃调用与来源追溯，并设计版本侦察、脚手架、回归检查三类Skill落地工作流，确保Skill作为可...

3个Skills解决SDK版本、代码生成和回归测试，初级测试也能照着做-腾讯云开发者社区-腾讯云

3个Skills解决SDK版本、代码生成和回归测试，初级测试也能照着做

3个Skills解决SDK版本、代码生成和回归测试，初级测试也能照着做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐