鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册

全网刷屏的 Jev 模型正式开放!一手实战测评 + 保姆级教程

程序员鱼皮
程序员鱼皮
2026-09-21 16:11
阅读 12
程序员鱼皮
2026-09-21 16:11
阅读 12

大家好,我是程序员鱼皮。

过去几年,不管是 ChatGPT、Claude 还是 DeepSeek,AI 大模型的目标一直都是「跟人聊天」和「帮人干活」。

但最近有个模型突然火了,它有点儿特别,不说人话、不能跟人聊天。

它叫 Jev,由前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI 发布,这哥们是 ChatGPT 的共同发明人之一!

我刚看到的反应是:一个不说人话的 AI,能有什么用?又是噱头吧?

了解之后发现,还真有点东西!

这篇文章我就从零开始,带大家搞懂 Jev 到底是什么、怎么用、到底好不好用。没有任何技术基础的小白也能看懂,看完还能直接上手体验。

一、Jev 入门介绍

Jev 是什么?

传统的大模型主要是跟人对话的,你问它一个问题,它回你一段话。

但这就带来一个问题,比如你想让它帮你判断一下「这封邮件紧急吗」,它不会直接告诉你「是」或者「否」,而是先给你写一大段分析,然后才给出结论。不仅速度慢、烧 Tokens,还需要你自己从回答里把答案抠出来。

Jev 就完全不一样了。你问它「这封邮件紧急吗」,它就直接告诉你「是,概率 95%」。

模型返回的是一段结构化的 JSON 数据,你的程序可以直接拿来用:

▼
json
复制代码
{ "is_urgent": { "noul": 0.95 } }

可以说,没有任何 AI 比它更直接、更不绕弯子。

TypeSafe AI 管这种模型叫 System One Model(系统一模型),灵感来自诺贝尔奖得主 Daniel Kahneman 的《思考,快与慢》。系统一是人类大脑里负责快速直觉判断的部分,比如你一眼就能看出「这个人在生气」;系统二是负责深度推理的,比如「算一下 17 × 24」。

传统 LLM 更像系统二,Jev 就是系统一。

根据 TypeSafe 官方自测的数据,两者的差距还挺夸张的:

传统 LLM(如 GPT-5.6)Jev
输出方式生成文字,需要解析直接返回结构化决策结果
响应速度3 - 329 秒70 - 500 毫秒
输入价格$0.20 - $10 / 百万 token$0.042 / 百万 token
输出价格约输入价的 5 倍免费
结构化输出错误率0.58% - 45.5%0%(数学保证)

响应速度最高快了将近 200 倍,输入价格便宜了几十倍到上百倍,输出还不要钱,而且结构化输出零错误。这也太香了吧!

那 Jev 到底是怎么用的?为什么能这么快?下面一个一个来讲。

Jev 能回答什么类型的问题?

Jev 的调用方式非常简单,你给它两样东西,一个是 state 状态,就是你想让它分析的上下文信息;另一个是 questions 问题,就是你想让它回答的问题。然后它就直接返回结构化的答案。

Jev 支持回答 3 种类型的问题,TypeSafe 官方把它们叫做「AI 原语」。

1、Noul 是或否

简单来说,就是让 AI 做判断题,问一个「是不是」的问题,返回 0 到 1 之间的概率值。

比如你收到一封客户邮件,想判断是否紧急,就把邮件内容作为 state 传给 Jev,再加上一个 Noul 类型的问题:

▼
json
复制代码
{ "state": "我连续 3 天无法连接 Stripe 账户,正在丢失销售额,请尽快处理!", "questions": { "is_urgent": { "type": "noul", "instructions": "这条消息是否传达了紧急性或时效性" } } }

Jev 返回的结果长这样:

▼
json
复制代码
{ "is_urgent": { "type": "noul", "noul": 0.95 } }

0.95 意味着有 95% 的把握认为这条消息是紧急的。你在代码里直接 if noul > 0.8 就可以触发告警了。

2、Choice 多选一

这个就像让 AI 做选择题,从你预设的选项里选一个,并告诉你每个选项的概率分布。

比如判断一个工单该分给哪个部门,你可以把部门选项列在 criteria 里让 Jev 来选:

▼
json
复制代码
{ "questions": { "department": { "type": "choice", "instructions": "这个工单应该分配给哪个团队处理", "criteria": { "billing": "付款、发票、退款相关问题", "technical": "Bug、系统故障、集成问题", "sales": "定价、账户咨询" } } } }

返回:

▼
json
复制代码
{ "department": { "type": "choice", "choice": "billing", "confidence": 0.8, "probabilities": { "billing": 0.87, "sales": 0, "technical": 0.13 } } }

不光告诉你选了 billing,还把每个选项的概率都算出来了。目前 Choice 最多支持 255 个选项。

3、Score 评分

这个就像让 AI 做打分题,在你自定义的量表上打分,分数可以落在两个等级之间。

比如判断无法登录的客户有多沮丧,你可以定义从「冷静」到「愤怒」的几个等级,让 Jev 来打分:

▼
json
复制代码
{ "questions": { "frustration": { "type": "score", "instructions": "客户看起来有多沮丧", "criteria": [ "冷静,只是在陈述事实", "不满但还算礼貌", "非常愤怒,言辞激烈" ] } } }

返回:

▼
json
复制代码
{ "frustration": { "type": "score", "score": 1.04, "confidence": 0.94, "probabilities": { "0": 0, "1": 0.96, "2": 0.04 } } }

Score 1.04 表示介于第 1 级(不满但礼貌)和第 2 级(非常愤怒)之间,偏向不满。这里我定义了 3 个等级,实际使用时你可以根据需要定义 2 到 10 个等级,等级越多,评分的粒度就越细。

Jev 有什么特别的?

看到这里,可能有接触过 AI 应用开发的朋友会想:我之前在提示词里引导 AI 输出 JSON,或者用大模型自带的结构化输出功能,也能让 AI 返回固定格式的结果啊…… Jev 跟它们有什么区别?

你别说,区别还真挺大的!

首先,传统 LLM 做结构化输出,底层还是一个 token 一个 token 地「写字」,写完再校验格式。就好比让一个作文高手去做选择题,他还是会先在脑子里打一遍草稿,然后再从里面挑答案,自然就慢。而且写着写着格式就可能出错。

Jev 的做法完全不一样,它用的是 并行采样,不像传统 LLM 那样逐字生成文本,而是直接在预定义好的选项上输出概率分布。也就是说,前面提到的 3 种问题可以在一次请求里同时问,问 1 个和问 10 个问题的响应时间几乎没差别。

此外,Jev 的训练方式也跟传统模型不同。传统 LLM 用 RLHF 人类反馈强化学习,优化目标是让回答读起来通顺,让人类满意;推理模型用 RLVR 可验证奖励强化学习,优化目标是让那些有标准答案的问题做对,比如数学证明能不能验证通过、生成的代码能不能编译运行。

而 Jev 用的是 TypeSafe 自研的 RLCD 校准决策强化学习,优化目标是让模型「说到做到」,如果 AI 说有 90% 的把握,那在大量预测中这类判断确实有约 90% 是对的。

理解了这些原理,前面表格里那些夸张的数据就好解释了。

Jev 不用一个字一个字地写回答,直接并行输出所有概率分布,所以速度能快上百倍。

它也不需要生成任何输出文字,成本自然就低了。

而且输出结构在数学上就是确定的,所以结构化错误率是 0%。

更重要的是,因为 Jev 的概率是校准过的,你的程序可以直接拿这个概率来做自动化决策,比如概率高于 0.8 就让 AI 自动处理,低于 0.5 就转人工。

Jev 能用来干嘛?

虽然 Jev 不能聊天,但是它的适用场景还真不少,这也是它能火起来的原因之一。

TypeSafe 官方建议把 Jev 当成一个「智能的 if 语句」,所有需要做判断和决策的场景,都可以用 Jev。

我看了网上大家的玩法,总结了几个比较典型的场景。

1)工单和消息分类

比如客服系统收到用户消息,一次性判断该分给哪个部门、是否紧急、情绪如何。社区里有人拿 Jev 给 1018 篇论文做分类,分类部分只花了 0.08 刀。

2)AI Agent 的决策中间层

比如 Codex 等 Harness 里的 Agent 每一步都要做判断,可以让 Jev 先快速决定该调哪个工具、这个操作有没有风险,只有需要写代码的时候才让传统的 LLM 上。

有人用这个思路做了 浏览器自动化 Agent,7.1 秒就在 Google Flights 上搜索完一次航班,成本只有 0.0039 刀。

3)内容审核和风控:比如一次性判断这条评论是否违规、属于哪种违规类型、风险等级多高,每条消息的判断成本不到 0.001 刀。

4)给 LLM 输出做质检

比如 LLM 生成了一段回答,用 Jev 快速检查有没有跑题、质量打几分,用便宜的 AI 检查贵的 AI。社区里有人做了一个多阶段代码审查工具,用 Jev 先做风险评估再逐文件打分。

5)实时游戏决策

有人用 Jev 玩地铁跑酷游戏,操作速度超过人类;有人用 Jev 控制超级马里奥,甚至还有人打通了《星际争霸》第一关!

这类对响应速度要求极高的场景,以前用传统的 LLM 根本不可能做到。

之后,需要生成文字的场景用传统 LLM,需要快速做判断的场景用 Jev,两者互补,可以让任务完成速度又快又准。

二、Jev 实战体验

了解了 Jev 是什么之后,接下来看看怎么实际用上它。

怎么使用 Jev?

Jev 现在已经正式开放注册了,直接用邮箱在 TypeSafe 官网 注册登录就行。

注册之后,最简单的使用方式就是直接在官方 Playground 里体验,也可以通过 API 和 SDK 接入到自己的项目里。另外也可以通过 Vercel、Cloudflare 这些第三方平台来调用 Jev。

方式一、官方 Playground

最简单的使用方式就是打开 官方的在线 Playground,左边填写提供给 AI 的上下文和想让 AI 分析的问题,点击运行就能在右侧看到结果。

方式二、调用官方 API 和 SDK

登录之后,可以到 TypeSafe 的控制台 中创建 API Key。

TypeSafe 提供了 Python SDK 和 JavaScript SDK,方便开发者在自己的项目里直接调用 Jev,也可以通过 HTTP API 调用。官方文档的 Quick Start 页面 有完整的示例代码。

以 Python 为例,安装 SDK 之后几行代码就能跑:

▼
python
复制代码
# pip install typesafe-sdk from typesafe_sdk import Choice, Noul, Score, TypeSafeClient client = TypeSafeClient() # 自动读取环境变量 TYPESAFE_API_KEY response = client.system_one( state="客户说:我被重复扣款了,订单号 A-104,请退款。", questions={ "department": Choice( instructions="这个工单应该分配给哪个团队处理", criteria={ "billing": "付款、发票、退款相关", "technical": "Bug、系统故障、集成问题", "sales": "定价、账户咨询", }, ), "is_urgent": Noul( instructions="这条消息是否传达了紧急性或时效性", ), }, ) print(response.answers["department"].choice) # "billing" print(response.answers["is_urgent"].noul) # 0.95

当然,现在用 AI 编程,这些代码都不用自己写,后面会讲到怎么让 AI 工具直接帮你调用 Jev。

方式三、通过第三方平台调用

除了 TypeSafe 官方的 API,Vercel AI Gateway 和 Cloudflare Workers AI 这些第三方平台也已经支持了 Jev,可以直接在这些平台上调用。

以 Vercel 为例,它的 AI SDK 专门新增了一个 experimental_evaluate 接口来对接 Jev 这类决策模型,详细教程可以查看 Vercel 官方文档。

我这里还用 AI 接入 Vercel AI Gateway 做了一个 中文版的 Jev 调试广场,可以直接在网页上体验 Jev 的三种回复方式。

点击「运行」之后,就能直接看到 Jev 返回的决策结果和原始 JSON 数据。

接入 AI 工具

上面几种方式都需要你自己写代码调用 Jev,那有没有更简单的方式呢?

其实日常大家还是用 GPT、Claude、DeepSeek 这些大模型,Jev 更适合作为一个扩展能力来搭配使用。

TypeSafe 官方提供了一个通用的 Skills 技能包,简单理解就是一份配置文件,告诉 AI 编程工具 Jev 是什么、怎么调用、参数怎么传,这样 AI 工具就知道怎么帮你调用 Jev 了。只要安装了 Skills 技能包,所有主流的 AI 编程工具都能用。

安装方法非常简单,官方提供了一段 现成的提示词,可以让 AI 帮你把技能安装到你用的 AI 工具里。

不过官方的提示词默认只在当前项目下安装。我把提示词翻译成中文并改为了全局安装的版本,这样所有项目都能用:

▼
text
复制代码
全局安装 TypeSafe 技能。如果你是 Codex(Claude Code),请执行 `claude plugin marketplace add typesafe-ai/skills`,然后执行 `claude plugin install typesafe@typesafe-ai`。如果你是其他 Agent,请执行 `npx skills add typesafe-ai/skills --skill typesafe-ai -g` 并选择你的 Agent。只需使用一种安装方式即可。技能文件可以在这里查看:https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md

比如我在 Codex 中执行这段提示词。它的原理就是根据你用的 AI 工具,执行对应的命令把技能文件从 GitHub 仓库拉取下来。

安装完成之后,还需要在环境变量里配置好 TypeSafe 的 API Key,AI 工具才能帮你调用 Jev。

直接让 AI 帮你配置就好:

配好之后,你就可以在 AI 编程工具里直接使用斜杠命令 /typesafe-ai 来触发技能,AI 会自动帮你调用 Jev 来完成判断和决策。

你也可以在对话中直接告诉 AI「用 Jev 来帮我做判断」,AI 同样会自动加载 TypeSafe 技能并调用 Jev 的接口:

Jev API 实战测评

学会了怎么使用 Jev 之后,咱们来通过实际的测试来看看 Jev 的表现到底怎么样。

我分别用 Jev 和 DeepSeek V4.1 Flash 来完成同一个任务,对比两者的速度、价格和准确度。

1、用 Jev 实时玩数字华容道

数字华容道是一个经典的滑块拼图游戏,4 × 4 的棋盘上有 15 个数字方块和 1 个空位,目标是把所有数字按顺序排列好。

每一步 Jev 需要判断「空位应该往哪个方向移动」,这对决策能力的要求很高。

开始测试,左边是 Jev,右边是 DeepSeek V4.1 Flash,两边同时开始,实时展示每一步的决策时间、累计消耗的 token 数和价格。

最终,Jev 在完成速度上遥遥领先 DeepSeek V4.1 Flash,而且输入 token 和累计价格也更低。

2、用 Jev 批量分类 1000 封邮件

第二个测试更贴近实际业务场景。假设你公司的邮箱每天会收到大量邮件,需要快速判断每封邮件的优先级、紧急程度和该转给哪个部门处理,这个任务就可以交给 AI。

我模拟了 1000 封不同内容的邮件,让 Jev 和 DeepSeek V4.1 Flash 分别对每封邮件做优先级分类、紧急程度判断和部门路由,两边拿到的邮件列表完全一样。

最终结果,Jev 用了 15.6 秒处理完 1000 封邮件,平均每秒处理 64 封,累计花费 0.0177 刀;而 DeepSeek V4.1 Flash 用了 48.9 秒,平均每秒 20 封,累计花费 0.0207 刀。Jev 在速度上快了接近 2 倍,价格也略低一些。

AI 工具 + Jev 实战测评

除了直接调用 API,我还试了一下把 Jev 接入 AI 工具之后的使用效果。

这次我用的是 Codex 工具 + GPT 模型,装好 TypeSafe 技能之后直接让 AI 干活。

1、用 Jev 玩连连看

连连看大家都玩过吧?

这次我用 Jev 来玩连连看,可以测试它在实时决策场景下的反应速度和判断准确度,游戏逻辑用代码处理,每一步选哪对方块消除的决策交给 Jev。

在 Codex 中使用 /typesafe-ai 技能,然后跟它说:

▼
markdown
复制代码
/typesafe-ai 帮我用 Jev 模型玩连连看游戏

Codex 加载了 TypeSafe 技能之后,会自动分析页面结构,识别出方块的位置和图案,然后调用 Jev 来做每一步「选哪对方块消除」的决策,最后操作页面完成消除。

虽然 AI 顺利通关了游戏,但是我觉得执行速度没有达到预期。快的时候可以 2 秒消除 1 个,但经常消除几个之后会卡一会儿,总共花了 5 分钟左右才完成了整局游戏的消除。

虽然 Jev 的决策速度确实很快,但问题出在「看」这个环节。Jev 只能处理文本和 JSON 数据,没办法直接「看到」网页上方块的位置和图案。这次测试我用的是本地的连连看网页版,Codex 可以直接解析到原始的 HTML 和 DOM 结构,所以还能跑起来。但如果你让它去玩那些用 Canvas 渲染的网页游戏,如果 DOM 里获取不到足够的信息,效果会更差。

其实社区里那些用 Jev 玩游戏的博主,思路基本都是一样的,就是先用代码把游戏画面转成结构化的数据(比如读取游戏内存),然后再把数据喂给 Jev 做判断,而不是让 Jev 直接看截图。

2、用 Jev 给开源教程文章打标签

前面的连连看游戏主要考察的是 Jev 的实时决策速度,这次换个方向,考察一下 Jev 对文本内容的分类和打分能力。

我让 Codex 用 Jev 模型给自己 《AI 编程教程》 中的每篇文章自动打标签,包括判断文章属于什么主题、适合什么水平的读者、难度打几分。

提示词如下:

▼
markdown
复制代码
/typesafe-ai 读取 ai-guide 仓库里的文章列表,用 Jev 给每篇文章打标签。 1. 主题分类(AI 基础/提示词工程/AI 编程实战/工具推荐/行业趋势) 2. 适合的读者水平(零基础/有编程基础/有 AI 经验) 3. 内容难度打分(入门/进阶/高级) 不改动原始文章,只是最后输出一份报告。

Codex 会先盘点文章范围、数量和篇幅,再按上下文限制设计可靠的批处理,批量调用 Jev 模型来判断文章的标签。

最终只用了几分钟,就完成了 697 篇长文章的标签分类!这个速度真的非常快了。

这类批量分类打标签的场景特别适合 Jev,因为每篇文章的判断逻辑是一样的,只是输入内容不同,可以批量并行处理。而且分类结果是结构化的,拿到之后可以直接用来生成目录、做筛选功能。

三、Jev 使用感受

最后说说我使用 Jev 的感受。

如果把 Jev 作为决策模型直接接入到自己的应用里(比如客服分类、内容审核、数据打标签),体验是非常好的,速度快、价格低、结果准确。做了上面这么多任务,总共也才花了不到 2 块钱。

但如果是通过 AI 工具来间接使用 Jev,目前的体验还有不少提升空间,主要瓶颈在于 AI 工具对网页内容的感知能力还不够强,很多场景下没办法给 Jev 提供足够准确的输入数据。

而且 Jev 的能力有明确的边界,不能生成文字、不能做算术推理、日期比较也不靠谱。

如果你在做 AI 应用开发,想要把分类、路由、审核这类判断逻辑的成本和延迟降下来,Jev 是值得一试的。一定要确保你能给 Jev 提供足够准确的结构化输入数据,它判断得准不准,取决于你喂给它的信息质量。

我个人比较看好 Jev 在 AI Agent 决策层的应用。现在 Agent 每一步操作都要调一次大模型来判断,如果把这类快速判断交给 Jev,整体效率应该会有一个质的提升。

OK 就分享到这儿,本文会收录到我免费开源的 《AI 编程零基础入门教程》,上千张图、几十万字,带你从 0 开始快速学会 AI 编程,做出自己的产品、跑通变现全流程,一次拿捏。

开源指路:https://github.com/liyupi/ai-guide

鱼皮的 AI 编程教程

我是鱼皮,持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~

也欢迎在评论区聊聊:你有用过 Jev 模型么?你看好它的发展么?

AI
编程
程序员
AI编程
人工智能
站长:程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题
🔥 热门文章
1
离谱,DeepSeek 崩了 5 小时,大家却喊:梁圣恩情还不完??
450
2
B 站上 DeepSeek 闹鱼灾了,我发起《大肥鱼清除计划》!
410
3
DeepSeek 全新模型发布,性价比最高的一集!
400
4
自己学习ai,直接买cursor 的套餐,还是买gpt 或者claude 的套餐?
370
5
又一个国产版 Codex 神器,也来卷办公了!
340
6
Vibe Coding 实战:从零构建现代专业级 AI 搜索引擎
330
7
day3-如何写出一个高质量的 Skill(组内分享) 高质量 Skill 不是“一个调得很顺的巨型 Prompt”,而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”,再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子,但方法是通用的。 --- 一、先想清楚:Skill 到底是什么 一个 Skill 至少包含四部分: 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做,每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办,而不是硬编一个看似合理的结果 高质量 Skill 的共同点:职责单一、接口清晰、规则可定位、输出可验证。 反例:把几十条经验全塞进一个主 Prompt,改一条规则要重调整个 Prompt,评估时也不知道是哪条规则退化。 --- 二、核心方法:先建评估,再写 Skill 不要先写转换器再补测试。正确顺序是: 1. 定义输出契约:什么算合法、什么算合格; 2. 建金标准集:一小批人工认可“可放行”的样本; 3. 先写评估 Skill:让它在金标准集上跑出基线; 4. 再迭代生成 Skill:每次修改跑同一套评估,无退化且目标维度提升才算正向。 这就是评估驱动开发:评估是 Skill 的单元测试,金标准集是回归锚点。 --- 三、评估 Skill:三层门禁,逐层递进 前一层不过,后一层不跑。每层留可追溯证据。 第 1 层:确定性硬门禁 用解析器、Schema、校验器完成,不消耗模型成本。 · 输出可解析; · 必填字段齐全,类型/枚举合法; · 引用目标存在,无悬空引用、无不可达节点; · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层:语义断言 用脚本 + 结构遍历检查“逻辑对不对”,仍然保持确定性。 通用检查项: · 覆盖率:源材料里的关键步骤、分支、条件,输出里是否都有对应? · 完整性:每个判断节点是否都有明确出口?有没有死胡同? · 可达性:每条路径是否都能到达预期终点?有没有无出口循环? · 顺序与依赖:有先后依赖的操作,是否保留了顺序?有没有被拍平成无序列表? 例子:故障诊断转换中,检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层:LLM-as-Judge 只处理解析器表达不了的维度:忠实度、完整性、可执行性。 但 Judge 会漂移,不能单独放行,必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化,换模型必须用金标准集重新校准。 通用 Judge 维度: 维度 问什么 忠实度 输出是否忠实源材料意图?有没有自行发明内容? 完整性 关键步骤、条件、证据是否保留?隐式知识有没有被压成空话? 收敛性 输出是否仍指向原目标,而不是发散? 可执行性 下游不依赖源材料能否直接使用? --- 四、金标准集:回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子,扩到 15~30 份,覆盖失败模式而非随机抽样: · 完整正例:典型流程; · 边界/异常分支:异常路径、循环、前置失败回退; · 已知易错模式:实际踩过的坑; · 留出集:不参与调优,只用于最终验收,防过拟合。 金标准不需要完美,只需要当前标准下认可可放行。 回归指标:关键路径用 pass^k(k 次全过),稳定性用 pass@k。 --- 五、工程约束:让批量产出可重放 · 幂等:同输入 + 同 Skill 版本 + 同规则 → 输出一致,否则无法判断变好是 Skill 改了还是随机波动; · 隔离不阻断:单份失败进隔离队列,记录失败层和原因,不阻塞其余; · 版本绑定:规则、rubric、金标准集进 Git;每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”; · 抽样人工复核:Judge 临界样本 + 易错模式,人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅,写清:输入约定、输出契约、分步流程、硬规则、降级策略; · 经验规则放 references/ 或 rules/,按失败模式分类,不要全塞进主 Prompt; · 不确定时标 needs_review: true,不要硬编看似合理的结果; · 迭代由评估报告驱动:报告告诉你哪层挂了、哪类失败模式,你改对应规则文件,而不是漫无目的调 Prompt。 --- 七、落地顺序(不要反过来) 1. 固化输出契约:Schema + 结构约束; 2. 建金标准集:从已认可的 + 最易出错的样本开始; 3. 先写评估 Skill:跑出基线报告; 4. 再迭代生成 Skill:每次修改对比逐项通过率,无退化且目标提升才算正向; 5. 批量运行 + 隔离回放:失败进队列,结束后人工抽检; 6. 评估 Skill 自身版本化:换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”:每次修改必须附评估报告对比,逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数:前两层挂了,Judge 分数没有意义。 3. 不许把规则堆进主 Prompt:规则按失败模式分文件,评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”,评估 Skill 决定“敢不敢用”。 先让评估体系站稳,再让生成器迭代。这样交付的不是一堆“看起来还行”的产出,而是一套可证明、可回归、可交接的 Skill 质量体系。
320
8
我的第一个出海产品!7 天 2 万
310
9
WorkBuddy 本地 API 桥 + dsh 插件:把你的 WorkBuddy 额度,变成手边随手可用的模型
310
10
什么是LLM
300
11
最近在落地 AI Native 项目,卡在团队资产协同这块,想请教下社区各位有实际落地经验的同学: 我们现在的资产分为三块:项目文档(PRD/ADR/ 运行手册)、Agent Skill(业务技能、执行 SOP、提示词包)、MCP 工具服务定义。 目标是做到:人和多 Agent 共用一套可信资料源,Skill、MCP 配置、项目文档能够版本化、同步、共享、可评审。 目前我们初步方案是用 Git 做底层版本主线: - 文档:Markdown + ADR,带元信息,支持 RAG 检索 - Skill:单技能包目录化,带版本、评估用例、依赖声明 - MCP:项目级声明文件纳入 Git 但实际协作里遇到不少疑问,想参考大家成熟的实践: 1. 大家团队里,文档、Skill、MCP 三者是怎么组织目录和版本管理的?有没有稳定的仓库结构模板? 2. 多人协作时,Skill 的变更评审、灰度升级、依赖管理怎么做?如何避免本地版本不一致、“本地能跑别人不行”? 3. MCP 是统一中心化网关模式,还是大家各自本地启动 + git 同步配置?权限白名单、调用审计这块有什么好方案? 4. 有没有成熟工具链做自动同步(类似 agentmeld /teamai-cli)、变更校验、eval 回归门禁? 5. 文档和 Agent 的打通:哪些文档放进 Git 作为可信真值,哪些放外部知识库,边界怎么划分? 如果有现成的仓库样例、目录规范、团队协作流程,非常希望能分享参考,感谢!
260
12
PHP 被曝两大致命漏洞,请所有程序员抓紧做这件事!
260