Skills 输出稳定化：Schema、验证与回归测试

gemini镜像站入口：chat.aimirror123.com
gemini 镜像备用站：gemini-3.shop。
摘要：本文讨论输出稳定性：Schema、验证与回归测试。

结构化输出是地基

你如果只让模型“用自然语言回答”，结果一定会漂。结构化输出就是把结果收口。 Gemini 支持在请求里指定 response_mime_type 为 JSON，并提供 response_json_schema 来限定结构。

文档里说得很清楚：JSON Schema 只支持子集。别贪心，字段越少越稳。 我常用 4~6 个字段，比如标题、步骤、注意事项、标签。

Schema 设计要从“使用场景”反推

不是所有字段都该进 Schema。你要先想清楚“这份输出要被谁用”。是进表格？还是直接发给用户？ 如果是进表格，就要把字段拆细；如果是给人看，就可以只保留关键摘要。

我常用的策略是“先少后多”：第一版只保留必要字段，跑通流程后再扩展。 这样你不会被 Schema 绑住，也不会因为字段太多导致模型填错。

什么时候用结构化，什么时候用 Markdown

结构化输出不是万能。只要你的结果需要被系统处理，比如进数据库、进表格，就必须结构化。

如果只是给人看，而且格式要求不强，Markdown 反而更灵活。你可以在不同场景下切换， 不必为了“统一”而强行 JSON。

别把“格式正确”当成“质量合格”

很多人看到模型能返回 JSON 就松一口气。但格式正确不等于内容靠谱。你还需要质量检查。 这里有两个简单但有效的方法。

第一，写一组固定测试用例。比如三种不同输入，看输出是否保持结构和语气。 第二，做一个“人工对照样例”，把理想输出放在旁边对比。

把错误当成产品反馈

结构化输出减少格式问题，但内容跑偏仍会发生。你需要一个“错误回路”： 输出不合格时，模型应该知道哪里错了。

我会在系统指令里写清楚“哪些情况算失败”，并要求模型在失败时返回空结果或错误码。 这样你能在系统层面处理，而不是让错误悄悄混进结果。

字段类型要严一点

如果某个字段只有有限选项，就用枚举。比如“难度”只能是入门/进阶/高级。 你让模型自由写，它就会出现“中级”“略难”这种乱七八糟的词。

数值字段也一样。能用数字就别让它写汉字。这样后续统计和筛选都更轻松。

自动校验比人工盯着靠谱

你可以在服务端做 JSON 校验，发现字段缺失或类型错误就直接判失败。

这种校验不复杂，但很关键。它能把“格式正确但字段缺失”的情况挡在门外。

不要忽略安全设置

如果你在做对外的 Skills，就要考虑安全过滤。Gemini 提供 safety settings， 你可以设置不同类别的拦截阈值。默认设置通常够用，但至少要知道它存在。

这一步听起来枯燥，但线上问题往往出在这里。不要等出事才想起来。

回归样例要“稳定 + 有代表性”

很多人回归测试随便挑几条输入，结果测不出问题。正确做法是保留两类样例： 一类是常规输入，另一类是边界输入（短文本、超长文本、含模糊描述）。

这样你每次改动后跑一遍，能很快发现“哪类输入被你搞坏了”。

回归测试是最划算的投入

Skill 很容易“今天好用，明天变味”。每次你改了 prompt、字段或工具，都应该跑一轮回归。 回归测试不需要复杂框架，几条样例就够了。

我会保留 5~10 条最常见的输入，每次改动后让模型跑一遍。只要有一条明显退化，就不要上线。 这件事成本低，但效果极好。

版本管理比你想的更重要

当 Skill 被团队使用时，版本号就不是可有可无。你改了字段就要升版本， 你改了边界也要记录。否则别人会遇到“怎么突然不能用了”。

最简单的办法是把版本写进输出，比如 version 字段。这样你拿到结果时， 能知道它来自哪一版。

让输出可审计

如果你在做比较严肃的内容，比如教程、公告、政策摘要，最好保留来源或证据。 有条件的话，搭配检索工具，让模型引用实际来源，再做摘要。

这一步可以显著减少“凭空编造”的风险，也更适合公开发布。

质量可以量化

如果你需要持续改进，就要有指标。比如“字段完整率”“摘要一致性”“人工退回率”。

这些指标不需要复杂，哪怕用表格统计一周，也能看到趋势。没有指标就只能靠感觉。

输出对齐规则越明确越好

我会写一份“输出规则小抄”，告诉模型哪些字段必须出现、顺序是否固定、是否允许空值。 这样做不是矫情，而是为了让你后续解析更简单。

如果某个字段可以为空，就明确写出来。模型最怕“可能可以”，它会乱填。

灰度发布能救命

大多数问题不是你在测试时发现的，而是上线后才暴露。最简单的办法是灰度： 先让 10% 请求走新版本，观察一两天。

这招很土，但很稳。只要你做过一次线上事故，就会明白它的价值。

上线前留一个“人工抽检”

我会固定抽 5% 的结果看一遍，尤其是新版本上线的一周内。人工抽检能发现模型在语气、细节、 逻辑上的奇怪偏差。等你把样例补进回归集里，后面就省心了。

质量问题常见于“换人使用”

你自己用起来没问题，不代表别人用也稳定。因为别人给的输入往往更短、更模糊。 所以我会在文档里写“输入示例”和“反例”。告诉别人哪些输入会出问题。

这一点很土，但很有效。很多质量问题不是模型问题，而是使用方式问题。

保留原始输入，方便回放

当输出出问题时，你需要知道“当时输入了什么”。所以我会把原始输入一起存档。 不一定永久保存，但至少保留一段时间，方便回放。

这样你能快速定位：是输入本身有问题，还是 Skill 变了。否则你只能凭感觉猜。

写给想稳定上线的人

Skill 的稳定性不是一次性写出来的，是靠测试、反馈和版本管理堆出来的。 结构化输出只是开始，质量保障要靠流程。

如果你只做一件事，那就是建立一套回归样例。它会在你最忙的时候保护你。