智能分析Skills架构演进：从三次重构中提炼的六大设计原则

当业务场景的复杂度超越了一个Prompt所能承载的边界，架构设计的价值便凸显出来。在面向本地生活业务的分析类Skill搭建过程中，我们经历了从V1到V3的三次架构重构，每次都是被真实问题逼出来的迭代。这篇文章完整复盘这个演进过程，提炼出六条可复用的Skill架构设计原则。

V2重构：从知识收拢到路由设计

初期的架构设计很容易陷入两个极端：要么把所有知识塞进一个越来越长的Prompt，要么借用传统软件工程的思路做分层解耦。我们最初选择了后者——将Skill拆分为K池（Knowledge）、A池（Analysis）、E池（Expression）三个独立的知识池，通过标准化的接口契约通信。这种架构看起来清晰合理，但运行两周后就暴露出三个致命问题：上下文窗口装不下跨文件拉取的知识碎片；LLM不是微服务，不需要序列化的数据包在层间传递；流水线假设不成立，真实分析过程中知识和结论是交织往返的。

六条设计原则与未来方向

V1的失败让我们意识到一个根本性问题：LLM的知识组织范式与传统软件架构根本不同。分层的目的是让模型在需要时能拿到完整的上下文，这与微服务架构里“每个服务只看自己数据”的理念正好相反。V2围绕三条原则展开重构：知识收拢（一个行业的知识不再分散到多个子目录）、按需加载（根据用户问题动态决定加载哪些文件）、做减法（砍掉接口契约、版本解析器等工程设施）。为实现按需加载，我们设计了一个承担三级路由职责的入口文件：域路由判断用户问的是哪个业务域，行业路由在域内映射到具体行业，问题分类决定加载哪些分析方法文件。这本质上是用路由逻辑换取context效率——用少量路由token换取大幅减少无效知识加载。

V2解决了知识碎片化问题，但只跑了一周就发现新问题：行业文件越写越胖。原来，收拢不等于把所有知识塞进一个文件——经营框架、核心公式等低频变更内容与策略打法、竞争格局、口径规则等高频变更内容混在一起，更新时极容易误改稳定内容，维护成本指数级增长。V3的核心决策是按变更频率分层：瘦行业文件只保留低频变更内容（百行级），主题文件按知识主题而非行业组织高频变更内容。这个设计背后有一个关键洞察：写入和读取的最优粒度不一样。维护者的视角是“一个文件改完所有行业”，LLM的视角是“只看一个行业的段落”。同一个物理文件，通过分段加载策略同时满足了两边需求。

方法层的教训同样深刻：V1的A池里有20多个分析方法平行陈列，但选项多不等于能力强——对LLM来说，每一次选择都在消耗推理能力，选项越多，用于真正分析的推理资源越少。V2把方法压缩到9个，并做了三件事：合并同类项降低一级决策选项数；建立路由优先级让模型顺着异常检测→归因→趋势→预测的顺序走；后置触发机制让模型分析到特定模式时再加载对应方法文件。核心原则是：让LLM的每一步决策都是少选项、强信号的。表达层同样如此：20多个模板被压缩为监控、诊断、预测、汇报四类框架，设计思路是「约束骨架，释放内容」——只定义一级骨架，二级让模型自由发挥。

知识生命周期管理

知识是有保质期的。代码的逻辑不会自己变，但业务知识会——口径变更、组织调整、策略刷新、行业政策出台。如果缺乏系统化的更新机制，Skill的输出质量会随时间持续下降，且用户不会告诉你“是因为知识过时了”，他们只会默默离开。我们设计了两套互补机制：评测驱动的更新闭环（评测→诊断→登记→校验→复测，把知识管理当代码管理来做）和反馈自演进机制（从用户对话中静默采集纠错、追问、放弃等信号，积累到候选区观察，多次确认后晋升为正式知识）。两者的区别在于前者是定期体检，后者是日常免疫系统。

如有侵权，请联系删除。