背景过去一个月我们在搭建一个面向本地生活业务的分析类 Skill让 AI 能像资深分析师一样做经营诊断、归因拆解和趋势预测。业务覆盖几十个行业每个行业有独立的经营框架和指标体系复杂度远超一个 prompt 能承载的范围。搭建过程中我们经历了三次架构重构V1 → V2 → V3每次都是被真实问题逼出来的。这篇文章完整复盘了这个演进过程最终提炼为六条 Skill 架构设计原则。如果你正在搭建领域知识密集型 Skill或正面临「prompt 越写越长但效果越来越差」的困境这篇文章或许能够提供一些思路。每章独立成节可按需跳读。01V1用软件工程思维设计 Skill踩了什么坑大部分团队搭建 Skill 的路径都类似大 prompt → 打补丁 → 越来越长 → 没人敢改。我们绕过了大 prompt但踩进了另一个坑那就是用软件工程思路做分层解耦结果过度工程化。Skill 的能力上限不取决于模型取决于你喂给它的知识架构。设计直觉我们面对的业务场景有几个特点覆盖几十个行业每个行业有独立的经营框架和指标体系分析方法涉及归因、趋势、预测、漏斗、分层等十几种输出形式从日报到诊断报告到决策备忘各不相同。一个 prompt 显然装不下。所以我们很自然地借用了软件工程的经典范式分层解耦把 Skill 拆成三个独立的知识池K 池Knowledge负责管理业务知识。行业概览、规则口径、运营抓手、关键事件、外部因素每个行业在 K 池下都有独立的子目录。A 池Analysis负责管理分析方法。从宏观的问题定性“这是什么类型的问题”到中观的分析框架“按什么维度拆解”再到微观的具体方法“用什么算法归因”分成三层。E 池Expression负责管理输出。按场景设计了 20 多个模板从异常告警到月报到诊断报告到决策备忘全部覆盖。层间通过标准化的接口契约通信——K 池组装好知识包给 A 池A 池产出分析结论包给 E 池。看起来架构清晰、职责分明。跑起来之后V1 上线跑了不到两周我们就发现了三个结构性问题上下文爆炸。一个行业的知识被打散到 K 池的多个子目录里一次分析要跨三层拉十几个文件context 窗口直接装不下。根因是知识碎片化LLM 需要在一个视野内看到连贯的行业知识才能做准确推理但 K/A/E 架构把它们分散在了几十个文件里。过度工程化。层间接口契约、版本解析器、schema 校验这些在传统软件工程中都是好实践但 LLM 不是微服务它不需要序列化的数据包在层间传递它需要的是在一个 context 里看到足够的信息做推理。流水线假设不成立。K→A→E 假设信息是单向流动的但真实的分析过程是交织的。分析到一半需要补充知识输出时发现结论要修正。流水线切断了这种交互。认知转变V1 让我们意识到一件事LLM 的知识组织范式和传统软件架构根本不同。传统软件追求模块化、接口标准化、关注点分离。这些原则在 LLM 场景下不是完全失效而是需要重新定义“正确的分离方式”。分层的目的是让模型在需要的时候能拿到完整的上下文这和微服务架构里「每个服务只看自己的数据」的理念正好相反。这个认知逼出了 V2 的重构方向知识收拢、按需加载、做减法。02V2知识收拢与按需加载重构原则V2 的重构我们围绕三条原则展开知识收拢。一个行业的知识不再分散到多个子目录而是收拢到一个独立的文件里业务模式、核心公式、经营框架、指标体系、诊断起点一个文件看全貌。LLM 加载一个文件就能获得足够的行业上下文。按需加载。不在启动时把所有知识全量灌入 context我们根据用户的问题动态决定加载哪些文件。一个简单的口径问题只需要加载行业文件一个复杂的归因分析才需要追加分析框架和方法文件。做减法。砍掉接口契约、版本解析器、schema 校验等工程设施。V1 的 100 多个文件被重新组织为 40 多个结构清晰的文件。工程复杂度大幅下降。路由层的诞生按需加载的前提是有一个可靠的路由机制Skill 需要先判断「用户在问什么」再决定「加载什么知识」。入口文件从 V1 的「三层 orchestrator」变成了单一路由入口承担三级路由职责域路由判断用户问的是哪个业务域。不同域有不同的分析框架和指标体系域判断是第一步。行业路由在域内映射到具体的行业。通过关键词匹配和歧义消解规则把用户提问映射到对应的行业知识文件。问题分类判断问题类型“是什么”知识类、“为什么”分析类、“怎么做”方法论类决定加载哪些 reference 文件。举个例子用户问“某行业 XX 指标为什么降了”三级路由依次命中业务域、具体行业、“分析类”问题于是加载行业文件 分析框架 归因方法而“XX 口径怎么定义的”只需要加载行业文件。路由层真正有技术含量的部分是处理歧义和兜底。几十个行业的关键词不可避免地会重叠我们的做法是先看上下文有没有行业锚点有就走行业路由没有就走横向职能还判断不了就询问用户。完全没命中时加载通用兜底文件作答。本质上路由层是用路由逻辑换 context 效率用少量路由 token 换取大幅减少无效知识加载按需组合替代全量灌入。这是 token 经济性的第一个体现。效果与新问题V2 上线后收拢解决了知识碎片化问题按需加载有效控制了 context 占用。分析质量明显提升。但只跑了一周左右新的问题就浮现了重构的保质期比我们想象的短得多。行业文件越写越胖。原因很直接。收拢意味着一个行业的所有知识都包含到一个文件里。经营框架是稳定的核心公式是稳定的但季度策略打法在变、竞争格局在变、运营抓手在变、关键事件在持续发生。这些内容不断追加到同一个文件中部分行业文件膨胀到了数百行。维护者的痛苦很具体改一个运营策略要翻完整个文件才能找到位置业务规划周期更新时不知道哪些该改哪些该保留几十个行业文件逐个检查更新效率极低。我们意识到收拢 ≠ 全塞一个文件需要找到更精细的组织方式。03V3稳定知识与时效知识的分离问题本质行业知识不是铁板一块我们仔细观察就会发现这些知识有着截然不同的变更频率稳定知识低频变更经营框架、核心公式、指标定义、业务模式。这些内容可能一两年才调整一次甚至更久。时效知识高频变更策略打法、竞争格局、运营抓手、关键事件、口径规则。这些内容每个季度甚至每个月都在变。V2 把它们塞进同一个文件导致了两个实际问题更新时效内容时容易误改稳定内容。维护者在一个几百行的文件里找某条策略可能不小心改动了旁边的经营框架定义。文件膨胀让维护者看不过来。一个行业的策略、竞争、事件、口径全堆在一起到底哪些是这次该改的、哪些不该动需要人肉判断。几十个行业乘以每次更新的判断量工作量指数级增长。分离方案V3 的核心设计决策是按变更频率分层把行业知识拆成两层存储瘦行业文件稳定层。每个行业一个文件只保留低频变更的内容经营框架、核心公式、指标定义、业务模式。精简到百行级打开就是这个行业的全景概要一眼看全貌。主题文件时效层。按知识主题而非按行业组织高频变更的内容。比如所有行业的策略打法放在一个主题文件里所有行业的竞争格局放在另一个主题文件里。每个主题文件内部按行业分段管理。这带来了三个直接收益写入效率更新某一类时效知识时比如全部行业的季度策略只需要打开一个主题文件逐段修改即可。不用打开几十个行业文件逐个翻找。维护清晰度行业文件瘦身超过 60%从 10000 多行压缩到 3000 多行。维护者能快速定位内容误改稳定内容的风险大幅下降。生命周期独立稳定内容和时效内容可以分别管理。策略刷新时只改主题文件不碰行业文件经营框架调整时只改行业文件不碰主题文件。加载策略的配套设计知识存储分了两层加载策略也要跟着调整关键设计在于跨行业集中管理但按行业分段加载。一个主题文件可能有几千行覆盖所有行业的策略打法。但单次请求时路由层只加载其中目标行业的那一个段落token 消耗控制在几百以内。大部分简单问题只需要加载瘦行业文件就够了只有涉及策略、竞争等时效性话题时才按需追加对应主题文件的对应段落。这个设计背后有一个关键洞察写入和读取的最优粒度不一样。维护者的视角是“一个文件改完所有行业”写入效率LLM 的视角是“只看一个行业的段落”读取效率即 token 效率。同一个物理文件通过分段加载策略同时满足了两边的需求。一个具体的例子此处我用一个虚构的行业来说明分离前后的差异。分离前V2 胖文件一个行业文件里混着以下内容——数百行混在一起。维护者要更新本季度策略需要跳过前面的稳定内容找到策略段落改完再小心翼翼地不碰到旁边的经营框架。分离后V3同一个行业变成两部分——瘦行业文件百行级只保留上面的“基础信息”和“经营框架”打开就是这个行业的全景概要。策略打法、竞争格局、关键事件、口径规则分别进入对应的主题文件。比如“策略”主题文件里所有行业的策略按段落排列——更新时打开这一个文件从头到尾逐行业改完即可。通用原则这不只是一个文件拆分技巧。背后的原则是变更频率不同的内容混在一起维护成本会指数级增长。这个原则对所有类型的 Skill 都适用。无论你做的是分析类、客服类还是运营类 Skill只要涉及领域知识就一定存在“稳定知识”和“时效知识”的区分。把它们分开管理是控制长期维护成本的关键。04把专家经验变成可调用的模块路由层和知识层解决了「知识怎么组织和调度」接下来看另外两个问题分析方法怎么结构化以及输出怎么标准化。V1 的“全家桶”问题V1 的 A 池里有 20 多个分析方法和 10 多个规则E 池里有 20 多个输出模板。看起来很完备但实际运行中暴露了三个问题路由错误频发。20 多个方法平行陈列LLM 在面对一个具体问题时需要从中选择最合适的。但方法之间的边界模糊「结构变化」该用分层方法还是结构迁移方法「趋势下滑」该用趋势分析还是异常检测模板维护成本高。20 多个输出模板之间有大量重复内容置信度声明、caveat 规范、多输出编排规则几乎每个模板都写了一遍改一处规范要改 20 多处而且很容易漏改。本质问题。这和给用户设计 UI 是一样的道理。选项多不等于能力强选项多只会增加决策错误的概率。对 LLM 来说尤其如此它的每一次选择都在消耗推理能力选项越多用于真正分析的推理资源就越少。方法层大幅做减法V2 把 20 多个方法压缩到了 9 个过程中做了三件事合并同类项。把多个细粒度方法合并为一个大类的子场景。比如因果推断领域的 DID、RDD、PSM、合成控制法对 LLM 来说都是「归因问题」的不同手段合并后模型先判断大类再在内部选具体方法一级决策的选项从 20 多个降到 9 个。建立路由优先级。9 个方法有标准顺序异常检测 → 归因 → 趋势 → 预测。LLM 顺着优先级往下走遇到匹配的信号就停下来不做全局选择题。后置触发机制在分析框架的知识文件里预埋触发标记。模型分析到某个维度、发现特定模式时比如“供给数量上升但单位产出下降”这是典型的结构迁移信号触发标记指示它按需加载对应的方法文件。决策点从“分析前选方法”变成“分析中遇到问题再加载”。核心原则是让 LLM 的每一步决策都是少选项、强信号的。从 token 经济性的角度看20 多个方法文件全量预加载 vs 9 个方法按信号触发按需加载token 占用差距是数量级的。信号消解减少选项还不够压缩到 9 个方法后方法之间的关键词仍然有重叠。比如用户说「结构变化」这可能触发分层分析识别不同群组的差异也可能触发结构迁移分析衡量结构占比变化对总指标的影响。我们为每对容易混淆的方法设计了消解规则关注“结构占比变化对总指标的影响有多大” → 结构迁移分析关注“哪些个体/群组贡献最大” → 分层分析两个信号同时命中时默认走结构迁移更聚焦因果归因分析过程中按需追加分层分析这说明减少选项是第一步消除选项之间的歧义是第二步。如果做过 NLU 意图识别的同学应该会有共鸣意图数量越少不一定越好意图之间的边界越清晰才越好。表达层从 20 个模板到 4 类框架输出层面V1 的 20 多个模板被压缩为 4 类输出框架监控 / 诊断 / 预测 / 汇报。设计思路是「约束结构释放内容」只定义一级骨架二级让模型自由发挥。比如诊断类输出的一级骨架是固定的诊断结论 → 定位路径 → 归因分析 → 建议行动。但每一步的具体表述、数据呈现方式、详略程度都由模型根据具体问题自行组织。这比 20 多个刚性模板灵活得多又比完全不限制可控得多。通用规则抽取。置信度声明、数据约束说明、受众适配规则从每个模板的重复段落中提取出来只写一次所有输出类型共享。改一处规范全局生效。受众适配内置。不是不同受众用同一个框架内置适配规则给高管看结论和数字给中层看趋势和行动项给执行者看操作细节一套框架覆盖所有受众。为什么不用 few-shot 示例很多人做 Skill 输出控制的第一反应是给模型塞几个 few-shot 示例——「参照这个格式输出」。我们试过效果不好。原因在于模型会过拟合到示例的表面形式用词、句式、段落长度都在模仿示例而不是学到结构约束。换一个行业、换一种问题类型输出又开始跑偏。「约束骨架但不约束填充内容」的框架式设计比 few-shot 更稳定。它告诉模型“必须有哪些部分”但不告诉模型“每个部分怎么写”给模型留出了根据具体场景灵活调整的空间。给 LLM 设计架构的反直觉方法层和表达层的共同教训可以总结为一组「反直觉」的经验Skill 架构设计是找到 「最少的约束产生最稳定的输出」的那个平衡点给 LLM 的架构要做减法给 LLM 的知识要做加法。05知识会过时 — 生命周期与自演进一个被忽视的问题搭建完成只是起点。V3 架构刚稳定下来我们就碰到了一个传统软件不存在的问题知识腐烂Knowledge Decay。代码的逻辑不会自己变但业务知识会包括口径变更、组织调整、策略刷新、竞争格局变化、行业政策出台。如果没有系统化的更新机制Skill 的输出质量会随时间持续下降。这比「功能不够」更为致命。功能不够用户会反馈“你能不能支持 XX”知识过时用户看到的是“分析结论不对”“数据口径对不上”“策略建议和现在的打法矛盾”。但他们不会告诉你“是因为知识过时了”他们只会默默离开不再使用。评测驱动的更新闭环为了解决知识腐烂我们设计了一套结构化的知识更新流程核心思路是把知识管理当代码管理来做。整个流程分为六步评测Eval。定期用标准化的测试题集验证 Skill 的输出质量。测试题覆盖各行业、各问题类型、各分析场景。评测产出一份结构化的差距清单哪些题答对了、哪些答错了、错在哪里。诊断Diagnose。基于差距清单生成修改计划。不是“哪里错了改哪里”是结构化地分析这个错误是哪个知识模块的问题影响范围有多大优先级如何预期修复后能提升多少分登记Register。这是最容易被忽略但最关键的一步。修改知识之前先登记即将变更的事实旧值是什么、新值是什么、在哪些文件中出现过。为什么因为同一个业务事实可能在多个文件中被引用。如果只改了一处、漏了另外两处就会出现同一个 Skill 内部版本不一致的问题这对分析类 Skill 来说是致命的。修改 校验Review。按计划执行修改完成后跑校验脚本扫描所有知识文件检查旧值是否已清除、新值是否已到位、是否存在被禁用的表述残留。零错误才允许提交。复测Re-eval。跑同一套评测题验证分数提升。如果分数没有提升或者出现了回归问题回到步骤 2 重新诊断。这套流程的核心理念在于知识更新是一个有登记、有校验、有复测的工程流程不只是「打开文件改一下」。它和代码的 CI/CD 是同一个思路只不过被管理的对象从代码变成了知识。反馈自演进让 Skill 自己变聪明评测驱动是「维护者主动巡检」定期体检发现问题修复问题。但还有一类信号来自用户使用过程中的隐式反馈。我们设计了一套静默反馈采集机制让 Skill 在日常使用中自动积累改进信号采集。在对话过程中自动识别多种反馈信号。用户纠错“不对应该是 XX”、追问补充“你漏了 XX”、重复提问同一个问题换个说法再问一遍、放弃对话问了一半不问了。采集过程完全静默不打断对话节奏用户无感知。候选区晋升。采集到的反馈不会立即生效。原因是单次反馈可能是个例用户可能记错了、问题可能有特殊上下文。如果一次纠错就改 Skill 的行为反而会引入新的错误。所以我们设计了候选区反馈先进入候选区观察同一类反馈被多次确认后才晋升到正式区开始影响 Skill 的行为。固化到知识库。命中次数足够高的反馈最终从运行时记忆固化到正式的知识文件中变成 Skill 的永久知识而非会话级记忆。这套机制有一个重要的设计约束那就是弱模型友好。所有操作包括采集时的信号识别、去重判断、晋升决策都用关键词匹配和规则判断来实现不依赖 LLM 的语义理解能力。为什么因为反馈机制本身运行在 LLM 的 context 里。如果它消耗太多推理能力来做语义分析就是在和主任务抢资源。反馈机制应该是轻量级的后台进程不是另一个推理任务。两套机制的关系评测闭环和反馈自演进解决的是同一个问题让 Skill 的知识保鲜。区别在于——评测闭环是定期体检系统化、全面、但有时滞反馈自演进是日常免疫系统实时、精准、但覆盖有限。两者互补缺一不可。大部分 Skill 的失败不是因为架构不好而是因为上线三个月后知识过时了既没有人定期评测也没有机制从用户行为中捕获退化信号。生命周期管理是 Skill 从「一次性交付」变成「持续运转的系统」的关键一步。06回到核心命题 — 架构决定上限演进复盘回顾整个演进路径每一次重构都对应一个关键的认知升级。一个月三次重构四次认知升级。这个节奏在传统软件开发中并不常见但在 Skill 搭建中可能会成为常态。因为你的「需求方」是 LLM 的行为模式而你对 LLM 行为模式的理解只有在实际运行中才能快速校准。落地效果截至目前这个 Skill 的落地规模如下。覆盖 20 个行业每个行业有独立的知识文件和经营框架内置 9 种标准分析方法归因、趋势、预测、异常检测、分层、漏斗、结构迁移、影响模拟、A/B 实验通过优先级路由和后置触发组合调度支持 4 类输出框架监控、诊断、预测、汇报覆盖从日常问答到正式报告的全场景知识更新闭环已跑通评测 → 诊断 → 登记 → 校验 → 复测配合反馈自演进机制持续迭代值得一提的是整个搭建过程本身也大量借助了 AI Coding 工具知识迁移、文件重构、校验脚本编写、评测执行很多重复性高但要求精确的工作交给了 AI 完成。一个月内完成三次架构重构、近万行知识重建没有 AI 辅助是很难做到的。待解决的问题诚实地说这套架构远不是终态。我们目前仍然面临几个挑战评测体系还不够系统化。我们有评测题集但覆盖面有限主要覆盖了高频的分析场景低频场景比如跨行业对比、长周期趋势判断的评测用例还很薄。评测题本身的质量也需要持续迭代——什么算“答对了”判断标准有时候依赖人工经验还没有完全自动化。反馈自演进的数据积累还在早期。机制搭好了但候选区里的反馈条数还不够多大部分还没达到晋升门槛。这套机制的真正价值需要更长的运行时间来验证。跨 Skill 的知识共享还没做好。我们目前有分析类 Skill 和查数类 Skill 两套体系部分知识比如指标口径、行业基础信息在两边都需要维护。理想状态是有一层共享的知识底座但目前还是各管各的偶尔靠手动同步。这些问题并不影响当前的使用效果但它们是下一阶段要解决的方向。六条设计原则从这些踩坑中我们提炼出六条 Skill 架构设计原则原则一收拢优于碎片化。一个分析场景需要的知识应该收拢到尽量少的文件中。LLM 需要连贯的上下文做推理不是碎片化的数据包拼装。原则二按变更频率分层。半年不变的知识和每个月都在变的知识不要放在一起。变更频率不同的内容混合存储维护成本会指数级增长。原则三选项少、信号强。给 LLM 的路由选择、方法选择、输出选择都要做减法。每一步决策都应该是低歧义的选项越少模型选对的概率越高。原则四约束结构释放内容。定义骨架让模型填充比穷举模板更稳定也更灵活。告诉模型“必须有哪些部分”不告诉模型“每个部分怎么写”。原则五知识保鲜靠机制不靠人。评测、登记、校验、复测没有更新机制的知识是有保质期的。原则六Token 经济性是架构的硬约束。每一个设计决策都要回答“这会消耗多少 context 窗口”。收拢是为了减少跨文件加载的 token 开销按需加载是为了只占用必要的 token主题文件按行业分段而非全量加载是为了精确控制 token 粒度。Skill 架构本质上是在有限的 token 预算内最大化知识密度。07写在最后模型会持续进化。今天的 context 窗口限制明天可能不再是瓶颈。但知识怎么组织、怎么路由、怎么更新这些架构决策的价值不会因为模型变强而消失。就像一个资深分析师换了更强的电脑他的分析质量并不会因此提升真正决定分析质量的是他脑子里的框架、方法和行业认知。Skill 的知识架构就是这个「脑子」。这套范式不只适用于分析类 Skill。任何需要领域知识驱动的 Skill都面临同样的问题。架构决定上限。
