鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
8
3
17

RAG 不是外挂知识库，而是一套证据链系统

Ryan
Ryan
2026-06-26 19:11
阅读 1618
Ryan
2026-06-26 19:11
阅读 1618

你有没有发现，现在很多 AI 回答最大的问题不是“答不上来”，而是“答得太像真的”。

它语气很稳定，结构很完整，甚至还会列出步骤、注意事项和看起来很专业的判断。

可真正危险的地方在于：你不知道它到底是根据什么说出这句话的。

很多人第一次听到 RAG，会把它理解成“给 AI 接一个知识库”。

这个理解不算错，但太浅。

知识库只是资料放在哪里。RAG 真正要解决的是另一个问题：

当 AI 给你一个答案时，你能不能判断这个答案到底靠不靠谱？

比如你在电商平台问客服：

我这个商品还能退吗？

一个普通大模型可能会根据常见售后规则回答：

一般情况下，签收 7 天内可以申请退货。

这句话听起来很正常，甚至很像客服话术。

但问题是：它真的知道你的订单状态吗？知道你买的是不是定制商品吗？知道商品有没有拆封吗？知道是否超过签收时间吗？知道当前店铺的退货政策是不是最新版吗？

如果这些信息都没有，它直接回答“可以退”，其实就是在没有证据的情况下装作知道。

RAG 真正要解决的，不只是让 AI 多读几份文档，而是让它在回答前先去找证据：订单状态是什么，商品类型是什么，售后政策怎么写，是否存在例外条款。只有这些证据足够支持结论，它才能回答；如果证据不够，它就应该说“不确定，还需要查询订单状态”。

所以我现在更愿意这样理解 RAG：

RAG 不是让模型知道更多，而是让模型的回答有证据、有边界、可追溯、可评测。

什么是 RAG：让模型先找证据，再回答问题

RAG = Retrieval-Augmented Generation，检索增强生成。

这个概念来自 2020 年 Lewis 等人的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。这篇论文提出的核心思路，是把预训练模型的参数化记忆和外部检索得到的非参数化记忆结合起来，让模型在知识密集型任务中利用外部资料生成回答。但在今天的 AI 应用工程里，如果我们要把 RAG 用到客服、企业知识库、求职材料、内部系统，就不能只停留在“检索 + 生成”，还要继续解决引用、权限、拒答、评测和可追溯问题。

用更简单的话说：

RAG 不是让大模型只靠“脑子里记住的参数”回答，而是在回答前先去外部知识源检索相关资料，再把检索到的内容作为上下文交给模型生成答案。

基本流程可以理解成：

▼
text
复制代码
用户问题
  ↓
检索相关文档 / 数据 / 片段
  ↓
把检索结果作为上下文
  ↓
交给大模型生成回答
  ↓
返回答案 + 来源

image.png

更准确地说，RAG 不等于知识库。

知识库是数据。 Embedding 是表示方式。 Vector DB 是存储和检索工具。 RAG 是把检索结果接入生成过程的架构。 可信 RAG 还要有 citation、faithfulness、abstention、eval。

所以：

有知识库 ≠ 有 RAG。 有向量库 ≠ 有可信 RAG。

很多“AI 知识库聊天机器人”只是做到了文档检索 + 模型回答，但还没有真正解决证据是否可靠、引用是否准确、回答是否忠实、证据不足时是否拒答这些问题。

RAG 的真正价值：不是知识更多，而是答案更可追溯

大模型的参数里确实存了大量知识，但这种知识有几个天然问题。

第一，它不一定新。

模型训练完成后，外部世界继续变化。政策会改，商品库存会变，订单状态会更新，公司内部文档会迭代。如果只依赖模型参数，知识更新成本很高。

第二，它不一定属于你的业务。

企业内部 SOP、用户简历、订单物流、客户服务记录、项目 README、私有代码文档，都不可能稳定存在于通用模型参数里。

第三，它很难给出 provenance，也就是可追溯的依据。

模型生成一个结论时，你很难知道它到底依据了哪份文档、哪段材料、哪条规则。

RAG 的核心价值就在这里：它把生成过程从纯参数记忆拉回到外部证据上。LangChain 文档把 retrieval 描述为在查询时获取相关外部知识，以增强 LLM 对上下文特定信息的回答能力；Spring AI 的 RAG 文档里，QuestionAnswerAdvisor 会查询向量数据库，把相关文档追加到用户文本中，为模型生成提供上下文。

这也是为什么 RAG 很适合作为 AI 应用工程里的长期专题。它不是一个单点技术，而是一条系统链路：

文档进入系统之前，要清洗、切块、加元数据。 问题进入系统之后，要改写、检索、混合召回、重排。 答案生成之前，要选择证据、控制上下文、约束输出。 答案生成之后，要检查引用、忠实度、拒答、可追溯性。 系统上线之后，还要持续评测、监控、回放、修复。

image.png

如果只写“Embedding 是什么”“Vector DB 怎么用”，你只是在写 RAG 的零件。

真正值得写的是：这些零件如何共同决定一个 AI 应用是否可信。

第一个误区：只要接了知识库，就算有 RAG 了

很多人做 RAG 的第一个动作，是接一个向量数据库。

这当然重要。

有了 embedding 之后，需要一个地方存这些向量，并支持按相似度检索。这就是 Vector DB。

比如 pgvector 是 PostgreSQL 的开源向量相似搜索扩展，它可以让你在 PostgreSQL 里存向量，并支持精确或近似最近邻搜索、余弦距离、内积、L2 距离等能力。

如果你用 Java / Spring Boot / PostgreSQL 技术栈，PGVector 很适合作为入门和工程落地选择。因为你可以把 document、chunk、embedding、metadata、tenant_id 放在同一个 PostgreSQL 体系里，而不是一开始就维护单独的向量数据库集群。

但 Vector DB 不是 RAG 的全部。

Vector DB 解决的是：

▼
text
复制代码
这些 chunk 里，哪些和用户问题的向量最接近？

它不解决：

这个 chunk 是否来自最新版文档？ 这个 chunk 是否属于当前用户或当前租户？ 这个 chunk 是否完整包含限制条件？ 这个 chunk 是否真的能支撑答案？ 模型是否忠实使用了这个 chunk？ 证据不足时系统是否拒答？

所以不要把“接入向量库”误认为“完成了 RAG”。

如果你没有好的 chunk，没有 metadata filter，没有 citation，没有拒答，没有 eval，那它只是一个“向量检索 + Prompt”demo。

更准确地说：

Vector DB 负责存向量和查相似，但它不能自动保证答案可信。

第二个误区：只靠向量检索，就能找到正确证据

很多 RAG 教程会从 Embedding 开始。

Embedding 的确重要。OpenAI 文档把 embedding 定义为向量表示，并指出可以通过向量之间的距离衡量文本之间的相关程度。

简单说，Embedding 可以把一段文本变成一串数字，让系统按语义相似度检索内容。

比如用户问：

出差住酒店最多能报销多少钱？

文档里写的是：

差旅住宿报销标准：一线城市 600 元/晚，其他城市 400 元/晚。

这两句话词不完全一样，但意思相关。Embedding 能把它们映射到相近的向量空间里，让系统知道它们语义接近。

但真实系统里，只靠 Embedding 很容易出问题。

比如用户问：

退款政策第 7 条怎么说？

向量检索可能召回“售后政策总则”“退货流程说明”“跨境商品说明”，但漏掉真正包含“第 7 条”的精确条款。

用户问：

SKU-A1937 是否支持德国仓发货？

这里的关键不是语义相似，而是精确编号、地区、仓库、商品属性。BM25 / lexical search 这类词面检索反而更稳。

OpenSearch 文档把 BM25 描述为一种基于关键词的 lexical search 算法，会考虑词频、逆文档频率等因素来计算文档相关性。

所以，RAG 检索的第一条原则是：

不要迷信单一检索器。

Embedding 解决的是语义相似，不等于事实正确。 BM25 / lexical search 擅长词面匹配、编号、术语、错误码、固定表达。 Hybrid Search 把稀疏检索和稠密检索结合起来，降低漏召回风险。 RRF 可以把多个检索器的排序结果融合起来。 Reranker 再对候选结果做更精细的 query-document 匹配。

Qdrant 的 hybrid queries 文档也把 dense、sparse、多向量检索，以及 RRF、DBSF 等融合方式放在同一个检索框架下讨论。

一个最简 RAG demo 可能是：

▼
text
复制代码
query → embedding → vector db → answer

但一个更接近生产的 RAG，应该更接近：

▼
text
复制代码
query
  ↓
query rewrite
  ↓
BM25 / lexical recall + vector recall
  ↓
RRF fusion
  ↓
rerank
  ↓
evidence selection
  ↓
answer generation
  ↓
citation / faithfulness check

这条链路看起来复杂，但它解决的是同一个问题：

先尽可能不要漏掉证据，再尽可能把真正相关的证据排到前面。

第三个误区：把文档切碎，就等于做好了知识库

Chunking 是 RAG 里最容易被低估的环节。

很多人会直接用固定长度，比如 500 tokens 一个 chunk，50 tokens overlap。这个做法能跑，但不一定能用。

因为真实文档不是纯文本流。真实文档有标题、层级、表格、FAQ、代码块、步骤、异常说明、法律条款、商品参数、订单字段、版本记录。

如果你把一个退款规则从条件和例外之间切开，模型可能只看到“支持退款”，看不到“定制商品除外”。

如果你把项目架构图的说明和模块列表切散，模型可能知道用了 Redis，却不知道 Redis 是用于限流、缓存还是会话。

如果你把简历项目经历按固定长度切开，模型可能看到“AI 应用开发”，却看不到对应技术栈和结果证据。

所以 Chunking 的本质不是“把长文变短”，而是：

把文档切成适合被检索、被引用、被验证的证据单元。

好的 chunk 至少要满足几个条件：

它要足够小，小到能被精确召回。 它要足够完整，完整到能支撑一个回答 claim。 它要保留结构，例如标题、章节、来源、页码、版本、所属租户。 它要可追溯，生成答案时能反查原文位置。 它要可评测，能判断某个 query 是否应该召回它。

这也是为什么“RAG 做不好”很多时候不是模型问题，而是知识工程问题。

第四个误区：检索到相似内容，就等于找到了证据

相似，不等于正确。

这个问题在 RAG 里非常常见。

比如用户问：

这个订单还能退吗？

系统召回了一段“通用退款政策”，这当然相关。但它是否足够回答这个订单能不能退？

不一定。

因为这个问题还需要订单状态、商品类型、签收时间、是否定制商品、是否有质量问题、是否拆封等信息。

也就是说，检索到“相似内容”只说明系统找到了一些可能相关的文本，不代表它已经找到了足够支撑结论的证据。

这里至少有三层过滤。

第一层是 topK：最多取多少条候选 chunk。topK 太小，可能漏掉关键证据；topK 太大，可能把噪声塞进上下文。

第二层是 similarity threshold：相似度低于某个分数的结果不要。阈值太高，可能过滤掉有用证据；阈值太低，又会放进太多无关内容。

第三层是 metadata filter / tenant filter：只在正确范围里检索。

Metadata，就是文档或 chunk 附带的信息。

比如：

▼
json
复制代码
{
  "tenantId": "merchant_001",
  "sourceType": "refund_policy",
  "language": "zh",
  "version": "v3",
  "status": "active",
  "updatedAt": "2026-06-01"
}

用户问退款政策时，系统要先判断：

是不是当前商家的政策？ 是不是当前语言？ 是不是当前版本？ 是不是 active 状态？ 是不是当前用户有权限访问？ 是不是对应业务线？

如果不做 metadata filter，系统可能召回旧版本政策、其他租户文档、测试文档、英文文档、无权限文档、已废弃规则。

这不是回答不准的问题，而是系统边界问题。

尤其在多租户系统里，tenant filter 不是 Prompt 约束，而是数据访问控制。你不能靠一句“请只回答当前商家的内容”来防止越权检索。真正的过滤应该发生在数据库查询、检索条件和权限系统里。

一句话总结：

RAG 不是在全库里找最像的内容，而是在正确范围里找能支撑答案的证据。

第五个误区：有引用，就说明答案可信

普通大模型胡说，用户至少还会怀疑：

它是不是编的？

但 RAG 系统一旦答错，问题反而更隐蔽。因为它通常会带着文档名、引用片段、相似度分数和来源链接，看起来像是经过检索验证的结果。

真正危险的不是 AI 没有依据，而是它拿着不完整、错误或不相关的依据，生成了一个看起来很确定的答案。

很多 RAG 系统会在回答后面附上引用来源，看起来很专业。但 citation 不等于 faithfulness。

引用只能说明：系统给了一个来源。 它不能自动说明：答案中的每一句都被这个来源支持。

举个例子。

原文说：

跨境定制商品非质量问题不支持七天无理由退货。

AI 回答：

所有跨境商品都不支持退货。

这个回答可能带着引用，但它把“定制商品”“非质量问题”“七天无理由”这些限定条件丢掉了。它不是没引用，而是引用不忠实。

所以 RAG 的可信问题至少要拆成三层：

Context relevance：检索到的上下文是否真的相关。 Groundedness / Faithfulness：回答是否被上下文支持。 Answer relevance：回答是否真正回应用户问题。

TruLens 的 RAG Triad 使用 context relevance、groundedness、answer relevance 三个维度来检查 RAG 应用；DeepEval 的 faithfulness 指标也强调要判断生成结果是否与 retrieval context 中的内容事实一致。

这三件事不能混在一起。

检索相关不代表生成忠实。 生成忠实不代表回答完整。 回答完整也不代表应该回答。

有些问题在证据不足时就应该拒答。

一句话总结：

Citation 问的是答案来自哪里，Faithfulness 问的是来源到底支不支持答案。

第六个误区：AI 应该永远给出答案

真正成熟的 RAG 系统必须有 abstention，也就是拒答能力。

当证据不足时，它应该说“不确定”。 当检索结果冲突时，它应该暴露冲突。 当问题超出知识库范围时，它应该说明边界。 当用户试图诱导它越权访问其他租户数据时，它应该拒绝。 当答案需要实时数据库状态，而当前只检索到静态文档时，它应该提示需要调用订单系统或业务 API。

很多 AI 应用失败，不是因为它答不出来，而是因为它在不该回答时回答了。

对客服系统来说，这可能是错误承诺。 对求职材料来说，这可能是简历造假。 对医疗、法律、金融来说，这可能是高风险误导。 对企业内部知识库来说，这可能是权限越界。

所以 RAG 不应该只追求“回答率”，还要追求“正确拒答率”。

一个可信 RAG 的目标不是让模型每次都有话说，而是让系统在证据不足、权限不足、上下文冲突或需要实时数据时，能主动暴露边界。

一句话总结：

可信 RAG 不应该永远回答，它应该知道什么时候不该回答。

第七个误区：问几个问题感觉不错，就可以上线

RAG demo 最危险的地方是：你问三五个问题，感觉它回答不错，就以为系统可用了。

但 RAG 的质量不能靠肉眼感受。你至少要把评测拆成两部分。

第一部分评测检索：

该召回的证据有没有召回？ 相关 chunk 是否排在前面？ 无关 chunk 是否污染上下文？ BM25、Embedding、Hybrid、RRF、Reranker 哪个环节带来了提升？ metadata filter 和 tenant filter 是否真的生效？

第二部分评测生成：

答案是否只基于证据？ 引用是否准确？ 是否遗漏关键限定条件？ 是否在证据不足时拒答？ 是否把多个来源中的冲突信息混成一个确定结论？ 是否能把“不确定”说清楚，而不是装作知道？

RAGAS 论文把 RAG 评测拆成多个维度，包括检索系统能否识别相关且聚焦的上下文、LLM 是否忠实利用这些上下文、生成质量如何等；LangSmith 的 RAG 评测教程也会评估 RAG 应用；OpenAI 的评测最佳实践也强调，evals 应该是面向具体应用的测试，用来衡量 LLM 应用表现。

这就是 RAG Eval 的价值。它不是为了做漂亮分数，而是为了定位系统坏在哪里。

如果 retrieval recall 低，说明证据根本没进上下文。 如果 context precision 低，说明召回内容太脏。 如果 faithfulness 低，说明模型拿到了证据但没有忠实使用。 如果 answer relevance 低，说明回答没有解决用户问题。 如果 citation accuracy 低，说明引用链不可信。 如果 abstention accuracy 低，说明系统不知道什么时候不该回答。

从这个角度看：

RAG Eval 不是上线后的评分表，而应该是 RAG 开发的导航系统。

没有 eval 的 RAG，只能叫 demo；有 eval 的 RAG，才开始接近工程系统。

重新定义 RAG：从“能回答”到“可验证”

以前我会说：

RAG = Retrieval-Augmented Generation，检索增强生成。

现在我更愿意说：

RAG 是一种把外部证据引入生成过程，并通过检索、重排、引用、拒答和评测机制约束模型输出的 AI 应用架构。

这个定义更长，但更接近真实工程。

因为真实业务要的不是“AI 能说”，而是：

它引用的是不是正确来源？ 它有没有越权拿到别人的数据？ 它有没有遗漏关键例外条款？ 它能不能承认证据不足？ 它的回答能不能被回放、检查和复盘？ 当知识库更新后，它能不能及时反映变化？

如果这些问题解决不了，RAG 就只是一个看起来更专业的聊天机器人。

如果这些问题解决了，RAG 才真正成为可信 AI 应用工程的底座。

接下来这个专题，我会按工程链路继续拆开写：

Embedding / Vector DB：语义表示和向量召回。 BM25 / Hybrid Search / RRF：降低只靠向量检索带来的漏召回。 Reranker：对候选证据重新排序。 Chunking：决定证据单元是否完整。 Metadata Filter / Tenant Filter：控制版本、权限和租户边界。 Citation / Faithfulness / Groundedness：判断答案是否真的被证据支持。 Abstention / RAG Eval：决定系统什么时候该拒答，以及如何证明它变好了。

但我不会把它们写成孤立概念。

每一个技术点都要回答同一个问题：

它能不能帮助 RAG 从“能回答”走向“可验证”？

我的目标不是证明“AI 能回答文档问题”，而是回答一个更硬的问题：

这个答案为什么值得被信任？

最后，用一张图把这篇文章的核心逻辑收束一下：

image.png

参考资料

[1] Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. [2] LangChain Docs, Retrieval / RAG. [3] Spring AI Reference, Retrieval Augmented Generation. [4] OpenAI Docs, Vector embeddings. [5] pgvector GitHub, Open-source vector similarity search for Postgres. [6] OpenSearch Docs, Keyword search / BM25. [7] Qdrant Docs, Hybrid Queries. [8] Cormack et al., Reciprocal Rank Fusion, SIGIR 2009. [9] RAGAS, Automated Evaluation of Retrieval Augmented Generation. [10] TruLens Docs, RAG Triad. [11] DeepEval Docs, Faithfulness Metric. [12] LangSmith Docs, Evaluate a RAG application. [13] OpenAI Docs, Evaluation best practices.

结语

下一篇，我会用类比讲透 RAG 的核心术语：Embedding、Chunk、Vector DB、BM25、Reranker 到底是什么。

我是 Ryan，一个专注于可信 AI 应用工程的开发者，个人技术博客：yanxai.com，研究如何让 AI 生成从“看起来对”走向“有证据、可追溯、可验证”。

AI
AI编程
8
17
分享
操作

相关专栏

RAG 从入门到实战

RAG 从入门到实战

本专栏系统拆解 RAG 从基础概念到工程落地的完整路径，包括 Embedding、Chunk、向量数据库、混合检索、Reranker、引用证据、Faithfulness 评测、Spring AI 实战和个人知识库搭建。 我不会把 RAG 只讲成“给 AI 接一个知识库”，而是把它拆成一套可检索、可引用、可追溯、可评测的证据链系统。适合想从普通大模型调用，进阶到生产级 AI 应用开发的 Java 后端和 AI 应用开发者。

评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2530
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
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 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300