尧图网站建设 
周四下午安全同学在群里甩了一张截图。线上一个查询接口被人用id1 or 11拖走了一批数据。出事的那段代码是三周前合的 PR评审记录里写着LGTM无风险。最扎眼的不是漏了是同一个 AI 评审助手上个月拦下过一模一样的写法。同一个模型、同一份《代码安全规范》、同一个 Prompt。差别只有一处那份规范不在评审助手的系统指令里它躺在知识库里靠检索进来。复盘会上有人提了两个方向调检索参数、换更强的模型。两个都值得做但都不是根因——根因是你把一条必须 100% 生效的规范交给了一个只有六成准头的检索。这就是什么时候用 Skill、什么时候用 RAG这道题的实战版本。面试官问它的时候脑子里想的就是这一类事故。一句话结论Skill 是知识少到人还能穷举时的 RAG。边界不在知识是什么在谁决定装哪一份。⚠️认知冲击别用概率机制去承载必须生效的约束。先看清这题在考什么网上的标准答案通常是知识类内容用 RAG指令类内容用 Skill。这话不错但它是记账不是决策——你听完还是不知道怎么切。面试官真正想筛三层你知不知道这两个东西是同一类问题。它们都在往上下文里塞知识。所以你不能像回答MCP vs Skill那样用一句它们不在同一维度绕过去。你能不能把边界量化。知识类/指令类是感受份数/命中率/变更频率才是判据。你有没有底线意识。有些东西错了可以重试有些东西错一次就出事——这两类东西不能放在同一套机制里。大部分候选人卡在第 2 层。他们能说出Skill 是静态的、RAG 是动态的但说不出这条静态/动态的线到底该画在哪。边界在哪两个维度不是一个清单先把这两个东西放到同一张坐标上混淆就消失了一半。横轴是谁决定装哪一份纵轴是这份知识是程序性的还是陈述性的。Skill 落在人预先决定 程序性部署时你就写好了要装什么它跨请求不变能吃提示缓存。RAG 落在运行时决定 陈述性请求进来才知道该取什么每次都要重新检索、重新注入。注意那张图里我把 Skill 和 RAG 标成了同一个颜色——它们是最容易被混为一谈的一对。而 MCP 和它们不同MCP 是能力不是知识它解决的是能不能做到一句话记**Skill 的代价是挤占常驻区RAG 的代价是检索延迟和概率命中。**两种代价换两种确定性。三个能直接量出来的判据别再用知识类/指令类分了用这三个问题判据偏 Skill偏 RAG份数能不能穷举十几份人能全部读完几百份以上穷举不了每请求命中率几乎每个请求都要用它偶尔用到按查询定月变更频率几乎不改跟代码走版本天天在变跟索引走再补一条性质判据它决定的是允许不允许出错性质含义该放哪必须生效漏一次就出事安全红线、合规条款必须常驻不接受概率命中即可这次没取到下次还有机会产品手册、历史工单检索就够了四条判据合起来看你会发现知识类/指令类这个分法的问题在哪它只看了内容没看份数、没看频率、没看容错。而后面这三样才是真正决定架构的东西。Skill 其实是「穷举版」的 RAG这是我认为这道题最值钱的一层。你手上有一份《代码安全规范》12 条。每个 PR 都要用它内容一年改一次。你有两个选择写成一个 Skill常驻加载。代价占常驻区的位置第 12 期算过这是固定成本可缓存。收益必然生效、没有检索延迟、不会漏。塞进知识库走检索。代价每次都要检索、结果不确定、可能漏。收益不占常驻区。当知识只有十几份、人还能穷举的时候全部常驻这笔买卖明显更划算——你其实是在把检索结果固化下来用可缓存换掉了检索延迟和不确定性。插一句Skill 是知识量小到人还能穷举时的 RAGRAG 是知识量大到人穷举不过来时被逼出来的 Skill。它们不是两个并列的选项是一条谱上的两端——你选哪端取决于三个数字份数、命中率、变更频率。反过来说什么时候必须从 Skill 那端滑到 RAG 那端当你的知识增长到’人写不完、也维护不过来’的时候。这在真实项目里几乎必然发生一开始 8 条规范两年后 340 条条款、1200 页产品文档、3500 条工单记录。人穷举不动了检索就变成唯一出路。最贵的两个错错误一把必须生效的东西交给检索。检索是概率机制。它准确率可以是 62%好的时候能到 95%但它永远是概率。对产品手册来说62% 和 95% 只是体验好坏的区别。对安全规范来说62% 意味着每 100 次评审有 38 次那条规矩根本没被看到。这张图是我专门画出来的因为数字说出口比形容词管用容错是 0 的东西不能放在命中率小于 1 的机制上。这不是调优问题是设计错误。你调参数调到 95%它还是每 100 次漏 5 次。错误二把知识库抄进 SKILL.md。反过来也一样常见。有人觉得既然 Skill 更可靠那我把公司知识库都写成 Skill 吧。三个后果知识一更新就过期Skill 跟着代码发版知识库天天在变常驻区被撑爆第 12 期那 55K tokens 的账就是这么来的而且并不会更可靠——Skill 也有它的容量上限。SkillRouterarXiv:2603.22455在一个约 8 万个 skill 的池子上做过对照把 body 拿掉之后命中率掉了31 到 44 个百分点。Skill 太多一样选不对。所以两个极端都是错的。真正的架构是混着的不可协商的红线常驻长尾知识走检索中间那层放摘要。Java 实战一个能跑的落位判定器上面全是判断落到代码才算数。这个判定器纯 JDK、零依赖能直接javac跑。它的价值不在分类在于把危险组合直接拦下来——比如必须生效 份数超出可穷举上限它会算给你看要漏多少次。// KnowledgePlacementAdvisor.java — JDK 17零依赖可直接 javac 运行 import java.util.*; public final class KnowledgePlacementAdvisor { /** 一份知识资产的画像全部是部署时可以量出来的事实不是感觉 */ public record Asset(String name, // 资产名 int count, // 份数 boolean mustEnforce, // 是否「必须 100% 生效」 double perRequestReuse, // 每个请求需要它的概率 int changePerMonth, // 每月变更次数 double retrievalAccuracy) {} // 若走检索实际召回准确率 public enum Verdict { SKILL, RAG, HYBRID } public record Advice(Verdict verdict, String reason, double missesPer100) {} /** 份数超过它就超出「人能穷举」的范围 */ private static final int EXHAUSTIVE_LIMIT 20; /** 每请求命中高于它说明几乎每次都要用 */ private static final double FREQUENT_REUSE 0.80; /** 月变更高于它说明固化下来就会过期 */ private static final int CHURN_LIMIT 10; public Advice advise(Asset a) { // 规则一必须生效的约束不接受「概率命中」 if (a.mustEnforce()) { if (a.count() EXHAUSTIVE_LIMIT) { return new Advice(Verdict.SKILL, // 规则二非强制 高频 可穷举 不常改 → 固化下来 a.count() // 规则三规模、频次或变更速度把人逼到检索, 0); } double miss (1 - a.retrievalAccuracy()) * 100; return new Advice(Verdict.HYBRID, // 规则四两头都不极端 a.count() // 名称 份数 必须生效 每请求命中 月变更 检索准确率 EXHAUSTIVE_LIMIT 必须生效且份数可穷举, miss); } 份全部常驻 if (a.count() EXHAUSTIVE_LIMIT a.perRequestReuse() FREQUENT_REUSE a.changePerMonth() CHURN_LIMIT) { return new Advice(Verdict.SKILL, 必须生效但 pct(a.perRequestReuse()) 份超出穷举上限 a.count() 红线常驻长尾才允许检索, 0); } 每请求命中 if (a.count() EXHAUSTIVE_LIMIT * 10 || a.perRequestReuse() 0.30 || a.changePerMonth() CHURN_LIMIT) { return new Advice(Verdict.RAG, 只有 a.count() 份且几乎不改固化吃提示缓存 pct(a.perRequestReuse()) 份数 a.changePerMonth() 、每请求命中 , 0); } 、月变更 return new Advice(Verdict.HYBRID, 次跟索引走, (1 - a.retrievalAccuracy()) * 100); } private static String pct(double v) { return Math.round(v * 100) 两头都不极端常驻摘要 按需检索正文; } public static void main(String[] args) { var advisor new KnowledgePlacementAdvisor(); ListAsset assets List.of( % new Asset(代码安全规范, 12, true, 1.00, 1, 0.62), new Asset(团队命名约定, 6, true, 1.00, 0, 0.62), new Asset(合规条款全集, 340, true, 1.00, 6, 0.62), new Asset(公司产品手册, 1200, false, 0.15, 40, 0.62), new Asset(历史工单处置记录, 3500, false, 0.08, 200, 0.62), new Asset(故障复盘模板, 9, false, 0.55, 2, 0.62)); System.out.println(知识资产落位判定穷举上限 EXHAUSTIVE_LIMIT 份 / 高频阈值 pct(FREQUENT_REUSE) / 月变更上限 CHURN_LIMIT 次); System.out.println(─.repeat(74)); for (Asset a : assets) { System.out.printf(%-16s %5d 份 必须生效:%s 每请求命中:%5s 月变更:%4d 次%n, a.name(), a.count(), a.mustEnforce() ? 是 : 否, pct(a.perRequestReuse()), a.changePerMonth()); Advice adv advisor.advise(a); System.out.printf( → %-7s %s%n, adv.verdict(), adv.reason()); if (adv.missesPer100() 0) { System.out.printf( ! 风险 走检索的部分每 100 次请求预期漏掉 %.0f 次%n, adv.missesPer100()); } System.out.println(); } } }跑出来是这样知识资产落位判定穷举上限 20 份 / 高频阈值 80% / 月变更上限 10 次──────────────────────────────────────────────────────────────────────────代码安全规范 12 份 必须生效:是 每请求命中: 100% 月变更: 1 次 → SKILL 必须生效且份数可穷举12 份全部常驻团队命名约定 6 份 必须生效:是 每请求命中: 100% 月变更: 0 次 → SKILL 必须生效且份数可穷举6 份全部常驻合规条款全集 340 份 必须生效:是 每请求命中: 100% 月变更: 6 次 → HYBRID 必须生效但 340 份超出穷举上限 20红线常驻长尾才允许检索 ! 风险 走检索的部分每 100 次请求预期漏掉 38 次公司产品手册 1200 份 必须生效:否 每请求命中: 15% 月变更: 40 次 → RAG 份数 1200、每请求命中 15%、月变更 40 次跟索引走历史工单处置记录 3500 份 必须生效:否 每请求命中: 8% 月变更: 200 次 → RAG 份数 3500、每请求命中 8%、月变更 200 次跟索引走故障复盘模板 9 份 必须生效:否 每请求命中: 55% 月变更: 2 次 → HYBRID 两头都不极端常驻摘要 按需检索正文 ! 风险 走检索的部分每 100 次请求预期漏掉 38 次上面这段是在 JDK 21.0.6 上实跑出来的。对照代码里的四条规则整条链路长这样三个地方值得单独看。一、最先执行的永远是必须生效那条。注意它在规则链的第一步优先级高于所有效率考量。因为效率问题可以调优容错问题不能。顺序错了你会先按份数少把安全规范归类成 Skill——结果对了但理由是错的下次遇到 340 条合规条款你就会把它扔给检索。二、合规条款全集这一行才是真实世界的常态。必须生效但又多到穷举不完——代码不给它一个选 Skill 或选 RAG的答案而是逼出分层红线常驻长尾才允许检索并且把漏检风险直接算出来给你看。三、只有必须生效的东西才报风险。产品手册漏了就漏了命中 15% 也无所谓——那本来就是碰上了算赚到。把风险提示只留给容错为 0 的资产这个信息才有意义。四个翻车点#坑正确做法1按知识类 / 指令类切按份数 / 命中率 / 变更频率 / 容错四个可量化的判据切2把安全规范、合规红线放进检索容错为 0 的约束必须常驻。要分层也只能红线常驻 长尾检索3把知识库整本抄成 SKILL.md知识会过期、常驻区会被撑爆而且 Skill 多了同样会选错掉 31–44pp4拿检索准确率提到 95%当解法95% 仍然是每 100 次漏 5 次。关键约束的容错不是 5%是 0第 4 条最容易被当成正确答案。把 RAG 调准一点是优化别把红线交给 RAG是设计。面试官想听的是后者。 一个我没找到答案的边界这篇里我给了三个数字穷举上限 20 份、高频阈值 80%、月变更 10 次。它们是我在代码里写的经验阈值不是论文结论。我没有找到份数涨到多少就必须从 Skill 转到 RAG的定量拐点公开材料里也没有这样一条线。真实项目里它取决于你的池子有多干净、描述写得多准、以及你能接受多长的检索延迟。所以我给的是一条边界不是一个答案在你自己的知识池上量一次命中率比在这里记我的数字有用得多。方法是现成的——同一批查询一份走常驻、一份走检索比命中率。跑一次就能知道你离那条线还有多远。面试模板30 秒Skill 和 RAG 我不用’知识类 / 指令类’去分我用三个能直接量出来的判据份数能不能穷举、每请求命中率、月变更频率。更核心的一条判断是Skill 本质上是’知识少到人还能穷举’时的 RAG——你把检索结果固化下来用可缓存换掉检索延迟和不确定性。所以它们是一条谱上的两端不是两个并列选项。有一条线我不碰必须 100% 生效的约束绝不放检索。检索是概率命中它适合’命中就够’的事实不适合’漏一次就出事’的规范。调参数把准确率提到 95% 也改变不了这一点。真实架构一定是混的红线常驻长尾检索中间放摘要。面试官追问Q那规范就不能进知识库了A能进但不能只有检索这一条路。做法是分层不可协商的红线十几条常驻进系统指令或 Skill剩下的长尾条款走检索再叠一层确定性校验兜底——比如把能写成 lint 规则的检查项从 AI 手里拿走交给静态扫描。凡是能用确定性手段保证的不要交给概率手段。Q把 RAG 准确率提上去不就行了A两件事。一提升有天花板和成本62% 提到 95% 依然每 100 次漏 5 次。二关键约束的容错不是 95%是 100%。对产品手册来说 95% 是体验问题对安全红线来说 95% 是事故概率。这不是同一个问题不能用同一个手段解。QSkill 装了太多不是也会选错吗A会而且有实测数据。SkillRouter 在约 8 万个 skill 的池子上做对照把 body 拿掉后命中率掉 31 到 44 个百分点——说明真正决定选得对不对的信号在正文里。所以 Skill 也有容量上限。两边都有上限这才是必须分层、而不是必须二选一的真正原因。Fox 有话说这两年大家习惯把 Skill 和 RAG 当成两个并列的选项在比比谁更好、谁会被谁取代。其实它们是一条谱的两端知识少而稳定的时候你手写、常驻、固化知识多而多变的时候你检索、按需、接受概率。从一端滑到另一端不是你选错了是你的知识长大了。真正不该移动的只有一条线必须生效的东西永远不放概率机制。分清哪些能错、哪些不能错比选对技术方案重要得多。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 AI面试题：什么时候用 Skill？什么时候用 RAG？
周四下午安全同学在群里甩了一张截图。线上一个查询接口被人用id1 or 11拖走了一批数据。出事的那段代码是三周前合的 PR评审记录里写着LGTM无风险。最扎眼的不是漏了是同一个 AI 评审助手上个月拦下过一模一样的写法。同一个模型、同一份《代码安全规范》、同一个 Prompt。差别只有一处那份规范不在评审助手的系统指令里它躺在知识库里靠检索进来。复盘会上有人提了两个方向调检索参数、换更强的模型。两个都值得做但都不是根因——根因是你把一条必须 100% 生效的规范交给了一个只有六成准头的检索。这就是什么时候用 Skill、什么时候用 RAG这道题的实战版本。面试官问它的时候脑子里想的就是这一类事故。一句话结论Skill 是知识少到人还能穷举时的 RAG。边界不在知识是什么在谁决定装哪一份。⚠️认知冲击别用概率机制去承载必须生效的约束。先看清这题在考什么网上的标准答案通常是知识类内容用 RAG指令类内容用 Skill。这话不错但它是记账不是决策——你听完还是不知道怎么切。面试官真正想筛三层你知不知道这两个东西是同一类问题。它们都在往上下文里塞知识。所以你不能像回答MCP vs Skill那样用一句它们不在同一维度绕过去。你能不能把边界量化。知识类/指令类是感受份数/命中率/变更频率才是判据。你有没有底线意识。有些东西错了可以重试有些东西错一次就出事——这两类东西不能放在同一套机制里。大部分候选人卡在第 2 层。他们能说出Skill 是静态的、RAG 是动态的但说不出这条静态/动态的线到底该画在哪。边界在哪两个维度不是一个清单先把这两个东西放到同一张坐标上混淆就消失了一半。横轴是谁决定装哪一份纵轴是这份知识是程序性的还是陈述性的。Skill 落在人预先决定 程序性部署时你就写好了要装什么它跨请求不变能吃提示缓存。RAG 落在运行时决定 陈述性请求进来才知道该取什么每次都要重新检索、重新注入。注意那张图里我把 Skill 和 RAG 标成了同一个颜色——它们是最容易被混为一谈的一对。而 MCP 和它们不同MCP 是能力不是知识它解决的是能不能做到一句话记**Skill 的代价是挤占常驻区RAG 的代价是检索延迟和概率命中。**两种代价换两种确定性。三个能直接量出来的判据别再用知识类/指令类分了用这三个问题判据偏 Skill偏 RAG份数能不能穷举十几份人能全部读完几百份以上穷举不了每请求命中率几乎每个请求都要用它偶尔用到按查询定月变更频率几乎不改跟代码走版本天天在变跟索引走再补一条性质判据它决定的是允许不允许出错性质含义该放哪必须生效漏一次就出事安全红线、合规条款必须常驻不接受概率命中即可这次没取到下次还有机会产品手册、历史工单检索就够了四条判据合起来看你会发现知识类/指令类这个分法的问题在哪它只看了内容没看份数、没看频率、没看容错。而后面这三样才是真正决定架构的东西。Skill 其实是「穷举版」的 RAG这是我认为这道题最值钱的一层。你手上有一份《代码安全规范》12 条。每个 PR 都要用它内容一年改一次。你有两个选择写成一个 Skill常驻加载。代价占常驻区的位置第 12 期算过这是固定成本可缓存。收益必然生效、没有检索延迟、不会漏。塞进知识库走检索。代价每次都要检索、结果不确定、可能漏。收益不占常驻区。当知识只有十几份、人还能穷举的时候全部常驻这笔买卖明显更划算——你其实是在把检索结果固化下来用可缓存换掉了检索延迟和不确定性。插一句Skill 是知识量小到人还能穷举时的 RAGRAG 是知识量大到人穷举不过来时被逼出来的 Skill。它们不是两个并列的选项是一条谱上的两端——你选哪端取决于三个数字份数、命中率、变更频率。反过来说什么时候必须从 Skill 那端滑到 RAG 那端当你的知识增长到’人写不完、也维护不过来’的时候。这在真实项目里几乎必然发生一开始 8 条规范两年后 340 条条款、1200 页产品文档、3500 条工单记录。人穷举不动了检索就变成唯一出路。最贵的两个错错误一把必须生效的东西交给检索。检索是概率机制。它准确率可以是 62%好的时候能到 95%但它永远是概率。对产品手册来说62% 和 95% 只是体验好坏的区别。对安全规范来说62% 意味着每 100 次评审有 38 次那条规矩根本没被看到。这张图是我专门画出来的因为数字说出口比形容词管用容错是 0 的东西不能放在命中率小于 1 的机制上。这不是调优问题是设计错误。你调参数调到 95%它还是每 100 次漏 5 次。错误二把知识库抄进 SKILL.md。反过来也一样常见。有人觉得既然 Skill 更可靠那我把公司知识库都写成 Skill 吧。三个后果知识一更新就过期Skill 跟着代码发版知识库天天在变常驻区被撑爆第 12 期那 55K tokens 的账就是这么来的而且并不会更可靠——Skill 也有它的容量上限。SkillRouterarXiv:2603.22455在一个约 8 万个 skill 的池子上做过对照把 body 拿掉之后命中率掉了31 到 44 个百分点。Skill 太多一样选不对。所以两个极端都是错的。真正的架构是混着的不可协商的红线常驻长尾知识走检索中间那层放摘要。Java 实战一个能跑的落位判定器上面全是判断落到代码才算数。这个判定器纯 JDK、零依赖能直接javac跑。它的价值不在分类在于把危险组合直接拦下来——比如必须生效 份数超出可穷举上限它会算给你看要漏多少次。// KnowledgePlacementAdvisor.java — JDK 17零依赖可直接 javac 运行 import java.util.*; public final class KnowledgePlacementAdvisor { /** 一份知识资产的画像全部是部署时可以量出来的事实不是感觉 */ public record Asset(String name, // 资产名 int count, // 份数 boolean mustEnforce, // 是否「必须 100% 生效」 double perRequestReuse, // 每个请求需要它的概率 int changePerMonth, // 每月变更次数 double retrievalAccuracy) {} // 若走检索实际召回准确率 public enum Verdict { SKILL, RAG, HYBRID } public record Advice(Verdict verdict, String reason, double missesPer100) {} /** 份数超过它就超出「人能穷举」的范围 */ private static final int EXHAUSTIVE_LIMIT 20; /** 每请求命中高于它说明几乎每次都要用 */ private static final double FREQUENT_REUSE 0.80; /** 月变更高于它说明固化下来就会过期 */ private static final int CHURN_LIMIT 10; public Advice advise(Asset a) { // 规则一必须生效的约束不接受「概率命中」 if (a.mustEnforce()) { if (a.count() EXHAUSTIVE_LIMIT) { return new Advice(Verdict.SKILL, // 规则二非强制 高频 可穷举 不常改 → 固化下来 a.count() // 规则三规模、频次或变更速度把人逼到检索, 0); } double miss (1 - a.retrievalAccuracy()) * 100; return new Advice(Verdict.HYBRID, // 规则四两头都不极端 a.count() // 名称 份数 必须生效 每请求命中 月变更 检索准确率 EXHAUSTIVE_LIMIT 必须生效且份数可穷举, miss); } 份全部常驻 if (a.count() EXHAUSTIVE_LIMIT a.perRequestReuse() FREQUENT_REUSE a.changePerMonth() CHURN_LIMIT) { return new Advice(Verdict.SKILL, 必须生效但 pct(a.perRequestReuse()) 份超出穷举上限 a.count() 红线常驻长尾才允许检索, 0); } 每请求命中 if (a.count() EXHAUSTIVE_LIMIT * 10 || a.perRequestReuse() 0.30 || a.changePerMonth() CHURN_LIMIT) { return new Advice(Verdict.RAG, 只有 a.count() 份且几乎不改固化吃提示缓存 pct(a.perRequestReuse()) 份数 a.changePerMonth() 、每请求命中 , 0); } 、月变更 return new Advice(Verdict.HYBRID, 次跟索引走, (1 - a.retrievalAccuracy()) * 100); } private static String pct(double v) { return Math.round(v * 100) 两头都不极端常驻摘要 按需检索正文; } public static void main(String[] args) { var advisor new KnowledgePlacementAdvisor(); ListAsset assets List.of( % new Asset(代码安全规范, 12, true, 1.00, 1, 0.62), new Asset(团队命名约定, 6, true, 1.00, 0, 0.62), new Asset(合规条款全集, 340, true, 1.00, 6, 0.62), new Asset(公司产品手册, 1200, false, 0.15, 40, 0.62), new Asset(历史工单处置记录, 3500, false, 0.08, 200, 0.62), new Asset(故障复盘模板, 9, false, 0.55, 2, 0.62)); System.out.println(知识资产落位判定穷举上限 EXHAUSTIVE_LIMIT 份 / 高频阈值 pct(FREQUENT_REUSE) / 月变更上限 CHURN_LIMIT 次); System.out.println(─.repeat(74)); for (Asset a : assets) { System.out.printf(%-16s %5d 份 必须生效:%s 每请求命中:%5s 月变更:%4d 次%n, a.name(), a.count(), a.mustEnforce() ? 是 : 否, pct(a.perRequestReuse()), a.changePerMonth()); Advice adv advisor.advise(a); System.out.printf( → %-7s %s%n, adv.verdict(), adv.reason()); if (adv.missesPer100() 0) { System.out.printf( ! 风险 走检索的部分每 100 次请求预期漏掉 %.0f 次%n, adv.missesPer100()); } System.out.println(); } } }跑出来是这样知识资产落位判定穷举上限 20 份 / 高频阈值 80% / 月变更上限 10 次──────────────────────────────────────────────────────────────────────────代码安全规范 12 份 必须生效:是 每请求命中: 100% 月变更: 1 次 → SKILL 必须生效且份数可穷举12 份全部常驻团队命名约定 6 份 必须生效:是 每请求命中: 100% 月变更: 0 次 → SKILL 必须生效且份数可穷举6 份全部常驻合规条款全集 340 份 必须生效:是 每请求命中: 100% 月变更: 6 次 → HYBRID 必须生效但 340 份超出穷举上限 20红线常驻长尾才允许检索 ! 风险 走检索的部分每 100 次请求预期漏掉 38 次公司产品手册 1200 份 必须生效:否 每请求命中: 15% 月变更: 40 次 → RAG 份数 1200、每请求命中 15%、月变更 40 次跟索引走历史工单处置记录 3500 份 必须生效:否 每请求命中: 8% 月变更: 200 次 → RAG 份数 3500、每请求命中 8%、月变更 200 次跟索引走故障复盘模板 9 份 必须生效:否 每请求命中: 55% 月变更: 2 次 → HYBRID 两头都不极端常驻摘要 按需检索正文 ! 风险 走检索的部分每 100 次请求预期漏掉 38 次上面这段是在 JDK 21.0.6 上实跑出来的。对照代码里的四条规则整条链路长这样三个地方值得单独看。一、最先执行的永远是必须生效那条。注意它在规则链的第一步优先级高于所有效率考量。因为效率问题可以调优容错问题不能。顺序错了你会先按份数少把安全规范归类成 Skill——结果对了但理由是错的下次遇到 340 条合规条款你就会把它扔给检索。二、合规条款全集这一行才是真实世界的常态。必须生效但又多到穷举不完——代码不给它一个选 Skill 或选 RAG的答案而是逼出分层红线常驻长尾才允许检索并且把漏检风险直接算出来给你看。三、只有必须生效的东西才报风险。产品手册漏了就漏了命中 15% 也无所谓——那本来就是碰上了算赚到。把风险提示只留给容错为 0 的资产这个信息才有意义。四个翻车点#坑正确做法1按知识类 / 指令类切按份数 / 命中率 / 变更频率 / 容错四个可量化的判据切2把安全规范、合规红线放进检索容错为 0 的约束必须常驻。要分层也只能红线常驻 长尾检索3把知识库整本抄成 SKILL.md知识会过期、常驻区会被撑爆而且 Skill 多了同样会选错掉 31–44pp4拿检索准确率提到 95%当解法95% 仍然是每 100 次漏 5 次。关键约束的容错不是 5%是 0第 4 条最容易被当成正确答案。把 RAG 调准一点是优化别把红线交给 RAG是设计。面试官想听的是后者。 一个我没找到答案的边界这篇里我给了三个数字穷举上限 20 份、高频阈值 80%、月变更 10 次。它们是我在代码里写的经验阈值不是论文结论。我没有找到份数涨到多少就必须从 Skill 转到 RAG的定量拐点公开材料里也没有这样一条线。真实项目里它取决于你的池子有多干净、描述写得多准、以及你能接受多长的检索延迟。所以我给的是一条边界不是一个答案在你自己的知识池上量一次命中率比在这里记我的数字有用得多。方法是现成的——同一批查询一份走常驻、一份走检索比命中率。跑一次就能知道你离那条线还有多远。面试模板30 秒Skill 和 RAG 我不用’知识类 / 指令类’去分我用三个能直接量出来的判据份数能不能穷举、每请求命中率、月变更频率。更核心的一条判断是Skill 本质上是’知识少到人还能穷举’时的 RAG——你把检索结果固化下来用可缓存换掉检索延迟和不确定性。所以它们是一条谱上的两端不是两个并列选项。有一条线我不碰必须 100% 生效的约束绝不放检索。检索是概率命中它适合’命中就够’的事实不适合’漏一次就出事’的规范。调参数把准确率提到 95% 也改变不了这一点。真实架构一定是混的红线常驻长尾检索中间放摘要。面试官追问Q那规范就不能进知识库了A能进但不能只有检索这一条路。做法是分层不可协商的红线十几条常驻进系统指令或 Skill剩下的长尾条款走检索再叠一层确定性校验兜底——比如把能写成 lint 规则的检查项从 AI 手里拿走交给静态扫描。凡是能用确定性手段保证的不要交给概率手段。Q把 RAG 准确率提上去不就行了A两件事。一提升有天花板和成本62% 提到 95% 依然每 100 次漏 5 次。二关键约束的容错不是 95%是 100%。对产品手册来说 95% 是体验问题对安全红线来说 95% 是事故概率。这不是同一个问题不能用同一个手段解。QSkill 装了太多不是也会选错吗A会而且有实测数据。SkillRouter 在约 8 万个 skill 的池子上做对照把 body 拿掉后命中率掉 31 到 44 个百分点——说明真正决定选得对不对的信号在正文里。所以 Skill 也有容量上限。两边都有上限这才是必须分层、而不是必须二选一的真正原因。Fox 有话说这两年大家习惯把 Skill 和 RAG 当成两个并列的选项在比比谁更好、谁会被谁取代。其实它们是一条谱的两端知识少而稳定的时候你手写、常驻、固化知识多而多变的时候你检索、按需、接受概率。从一端滑到另一端不是你选错了是你的知识长大了。真正不该移动的只有一条线必须生效的东西永远不放概率机制。分清哪些能错、哪些不能错比选对技术方案重要得多。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】