企业官网建设流程全解析

把「决策」这件事从大模型里拆出来单独做，是我被大模型坑过好几轮之后才真正认同的方向，而Jev这个项目的核心就是这个——一个独立的System One模型。之前有一段时间，我几乎把所有需要做决定的环节都丢给大模型：工单分类让它分，紧急程度让它排，甚至要不要触发人工复核也让它拍板。小规模测试时感觉一切尽在掌控，但请求量上来后问题全暴露了：同样一句话换个说法，结论就变了；一次推理要几百毫秒，业务链路根本等不起；决策过程还是个黑盒，出事复盘只能靠猜。Jev想解决的就是这个问题：把判断交给一个又快又稳又看得懂的专用模型，让大模型专心做它擅长的事。

1. 被大模型"抢走"的决策权：问题到底出在哪

1.1 一次让我盯着日志怀疑人生的随机性事故

我最早意识到这个问题，是在一次工单分级相关的技术预研里。当时在测试集上跑得很开心，觉得大模型的分类能力完全够用。但到了真正联调时，我发现一个诡异的现象：同样是"账号无法登录"这类描述，上午跑出来的紧急度是"高"，下午用同一段文本再跑一次，结果变成了"低"。我把温度参数调低，把采样方式改成贪心解码，还是有零星的随机波动。

翻了很多调用日志之后我才确认，这跟模型能力无关，而是生成模型的工作机制决定的——它每次输出本质是对令牌序列做概率采样，"决策"只是生成过程的一个顺带产物，根本没有被当成一个独立的优化目标去设计。这件事让我彻底想明白：把一个需要稳定复现结果的判断题，硬塞给一个为自由生成而设计的模型，是在用错误的工具做错误的活。大模型能"说出一句看起来像答案的话"，但它并不保证每次都说同一句话。

1.2 速度、成本、一致性：大模型做决策的三个隐性成本

先说实测数量级，不同环境下数据会有差别，但量级可以作为参考。我这里列几个最常被忽略的成本：

• 延迟：通用大模型做一次决策，哪怕只要求返回一个单词，端到端也普遍要几百毫秒。输入一长、服务端负载一高，翻倍很常见。而一个决策点往往嵌在业务主链路里，每多几百毫秒，对峰值流量的影响都很直接。
• 成本：每次决策都是一次大模型调用。月请求量到百万级之后，这笔开销会比小模型方案高出两到三个数量级。一开始大家都觉得"一次调用没多少钱"，看到账单结算时才意识到架构选择有多重要。
• 一致性：这是最隐蔽的一项。不管温度怎么调，大模型的输出仍有非零概率波动。这不只是偶尔回错格式的问题，而是决策结果不可复现，回归测试、灰度对比、故障复盘全都无从下手。
• 可审计性：大模型给的解释通常是"根据上下文判断"，但到底用了哪些特征、每个特征权重是多少，拿不到。出了纠纷，连决策依据都说不清。

把这几项成本叠加起来，结论就非常直接：让大模型做高频、大批量、要求确定性结果的决策，不是能力问题，而是架构问题。它能做，但代价高到会让你重新考虑整套系统的设计方式。

1.3 哪些"决策"适合拆出来，哪些适合留给大模型

不是要一刀切地把所有决策都从大模型里抽走。我自己的判断框架很简单：高频、结果可枚举、判断标准相对清晰、可以用可解释特征建模的，趋向于放进System One；低频、开放式、需要深度语义推理、上下文复杂、结果本身是创造性内容的，继续留给大模型。

举个例子：如果你做的是内容审核里的风险拦截，命中某些关键词组合就必须直接拦截，这是典型的System One场景；如果让你判断一段投诉文本背后的真实诉求到底是情绪宣泄还是具体故障，那就更适合交给大模型。这个区分想清楚之后，后面所有设计和选型都会顺畅很多。

2. 快与慢的分工：Jev想要补齐的那块拼图

2.1 双系统理论在工程化环境下的读法

心理学里有个很经典的双系统模型，一套思考很快，自动、直觉、不费力，适合应对需要立即反应的事情；另一套思考慢，理性、费力、需要主动分配注意力，适合解决复杂题目。这个概念被工程化借鉴之后，我的理解是：它落到工程上的核心不在"直觉 vs 理性"这种心理层面，而在"任务的频率、确定性和资源成本"。

高频重复的判断适合用快系统来解决，低频高价值的推理适合用慢系统来解决。Jev里的System One模型，名字就是从这里来的——它在整个技术架构里扮演的正是那个"快、省、稳定"的角色。理解这层定位很重要：System One不是一个比大模型更强的模型，它是一个不同职能的组件，跟大模型之间是分工关系，不是替代关系。

2.2 Jev拆的不是模型，是职责边界

有人可能会问：让大模型多套几层提示词、多做几轮自我校验，不也一样能提高决策稳定性吗？能，但那是让同一个模型同时演两个角色，又慢又难维护。提示词稍微写偏一点，决策逻辑就可能跟着飘，而且不同版本之间很难对比。

Jev的思路不是给大模型打补丁，而是承认生成和决策是两种不同性质的任务，那就用两种不同的模型来干。这个关系有点像写作和审稿的分工——审稿人不会替你写完整篇文章，作者也不需要扮演审稿人来判断自己的稿子合不合格。把职责拆开，各自才能把擅长的事做到极致。这里要强调一点：Jev不是把大模型一脚踢开，而是通过拆分，把大模型从高频决策里解放出来，让它专注在真正需要生成和推理的场景里。

2.3 System One模型的三个底层特性：快、稳、可审计

那为什么不干脆写一堆if-else规则，还非要训练一个模型呢？因为规则会无限膨胀，覆盖面靠人工维护根本追不上，而且规则之间互相冲突的案例会越来越多。System One作为一个专项决策模型，训练完成后要满足三件事：

• 快：决策路径要短，特征计算、模型推理、阈值判断三步加在一起，也要控制在几十毫秒以内。这个特性决定了它能嵌在业务主链路上，不拖后腿。
• 稳：相同输入必须永远得到相同输出，不能有温度、采样这类随机环节参与。这是可回归测试的基础。
• 可审计：每个决策都能回溯到"用了哪些特征、每一维特征贡献了多少"，这是后续复盘和业务对口径的前提。

这三个特性合在一起，要求System One本身足够简单、足够专门化。它也意味着这套模型的开发逻辑、优化方式、评价指标体系，都跟大模型不是一回事，不能拿习惯了大模型的那套方法硬套。

3. 拆解方法：把"决策"从生成任务里抽出来的具体做法

3.1 把决策形式化成"特征-规则-动作"三元组

我习惯把一次决策先写成一个映射：输入特征 → 决策规则 → 输出动作。无论表层看起来多复杂的判断，落到工程实现上，都要先回答三个问题：

• 特征：要从原始输入里提取哪些信号来支持这个判断？文本关键词、数值指标，还是布尔标志？
• 规则：这些特征怎么组合才能得出结论？是线性阈值判断，还是非线性的树模型？
• 动作：决定做完之后，系统要执行什么？标记为某个类别、路由到某个队列，还是直接拦截放行？

一旦把决策拆成这三个问题，就发现大模型在这里并不是必需的——它擅长的是理解语义和生成文本，而不是稳定地执行一套从特征到动作的映射。把"让模型自由判断"变成"训练一个专门的评分器或分类器"，是整个拆分过程的转折点。

3.2 四类最常见的决策抽离方式

• 分类决策：判断输入属于哪个预定义类别，输出类别ID和置信度，典型如工单类型识别。
• 分级决策：把输入打到某个等级上，如紧急度、优先级，本质是有序输出，对阈值和序关系要求比较高。
• 路由决策：决定分给哪个团队、哪个模块、哪个队列，本质是分类的特例，但通常要叠加其他信息做组合判断。
• 拦截决策：决定放行、拦截、还是转人工，典型如内容审核和风控拦截，核心是在召回率和误伤率之间权衡。

我自己的经验是：先按这几类把要拆的决策归好类，再逐类定义特征和标签，比一上来就"训练一个分类模型"清晰得多，也更容易和业务方把需求对齐。

3.3 训练数据：让大模型当标注员，再人工纠偏

System One是个小模型，训练它最缺的往往是标签数据，因为业务方很难一下子提供大量历史标注。我的常规路线是"蒸馏式提标签"而不是纯手工标注，这也是一种业界比较通用的做法：

1. 拿一批真实历史样本，让大模型对每个样本给出分类结果和简短理由。
2. 每个样本重复跑3到5次，用多数表决把采样随机性压掉。
3. 把多次结果不一致的样本单独挑出来，人工复核。这类样本通常刚好落在决策边界上，价值比普通样本高得多。
4. 用复核后的数据训练System One，上线之后继续收集真实反馈回流，形成闭环。

要注意一个坑：大模型标注会有系统性偏好，比如它倾向于选择"看起来合理但业务上并不正确"的标签。所以人工复核阶段绝对不能省，尤其是决策边界上的样本。另外，起步阶段几千条样本就能训练出一个可用基线，并不需要一开始就追求很大的数据集，先把链路跑通、把反馈闭环做起来，比攒数据更重要。

4. 实操记录：用这套思路搭一个工单分级路由系统

4.1 场景规划：先列决策点，再定决策边界

我用一个模拟工单分流场景，把这套思路从头到尾走一遍。需求很朴素：进来的工单要根据内容自动判断属于哪一类问题，评出紧急程度，然后路由到对应的处理队列。按前文的框架，我先把决策点列出来：

• 拦截型决策：是否属于可自动处理范围，还是必须转人工（比如涉及风险、投诉等敏感场景）。
• 分类型决策：技术问题、账户问题、业务咨询，三个预定义类别。
• 分级型决策：紧急度分成低、中、高三级。
• 路由型决策：根据"类型+紧急度"决定进入哪个处理队列。

规划阶段我还会明确一个目标：让80%的工单能自动分流，剩下20%交给兜底机制。这个目标决定了后面置信度阈值怎么设、兜底链路怎么搭，直接影响整个系统的复杂度。

4.2 特征工程：不在复杂，而在有用

特征设计直接决定了System One模型的天花板。工单是文本输入，所以我主要用了三组特征：

关键词命中这类特征，每个类别维护一份种子词表，但注意不要让权重变成"人工定死"的，而是让模型在训练中自动学习每个词对结论的贡献。轻量向量主要用来兜住词表覆盖不到的表达，不用大模型嵌入是因为延迟扛不住。这里有一条硬约束：单次决策的特征提取时间要控制在10毫秒以内，算不完的特征直接弃用。决策快不快，很多时候不是模型推理慢，而是特征算得太重。

4.3 模型训练：先上基线，再迭代

这版任务首选的不是深度学习，而是梯度提升树模型。理由很实际：对特征缩放不敏感，能直接吃数值和类别特征，训练快，自带特征重要性，方便后续解释。如果数据量很小，更建议先上逻辑回归，它是更稳的基线，后面再逐步替换。参考代码逻辑如下：

model = GradientBoostedTreeClassifier( learning_rate=0.08, max_depth=6, n_estimators=500, subsample=0.8, early_stopping_rounds=50, ) model.fit(train_x, train_y, eval_set=(valid_x, valid_y))

这里真正重要的不是照抄参数，而是理解早停的意义：树模型迭代次数过多会过拟合，早停能帮我们在验证集上找到最佳停止点。训练完之后，我在验证集上统计每个类别的置信度分布，然后划两个阈值：高阈值对应"足够确定，直接出结论"，中等阈值对应"置信度不够，但还能让大模型救一下"。

4.4 和大模型的协作方式：置信度兜底链路

System One不是孤立运行的，它和大模型的配合在工程上很关键。我的做法是：预测时同时输出置信度，把决策分成三个区间，谁该出手谁出手。

def route_ticket(features): label, confidence = jev_model.predict_with_confidence(features) if confidence >= HIGH_CONF_THRESHOLD: return label_actions[label] # 直接执行，同步返回 if confidence >= MID_CONF_THRESHOLD: return llm_judge(features) # 交给大模型做二次判断 return human_review(features) # 低置信度转人工

这个链路最直接的价值是：Jev扛下了大多数简单清晰的工单，大模型只在边界模糊时介入，人工集中处理复杂和高危场景。相比全部丢给大模型，延迟、成本、一致性三项指标几乎同时得到改善，准确率还能靠兜底链路兜住。这套"先快后慢、逐级兜底"的结构，也让我后续加新场景时不用再担心链路被单一环节卡死。

5. 上线之后才会遇到的事：坑和调优记录

5.1 分类边界模糊怎么处理

真正上线后第一个冒头的问题，是大量工单天然横跨多个类别。比如"账号被锁定，但我想改绑手机号"，既是账户问题又带着安全验证的味道。在固定分类体系里，这类样本怎么切都会带来损失。

我后来用两个办法缓解：一是给模型增加一个"待定"类别，让它拿不准时明确承认拿不准；二是把单阈值改成双阈值，高于高阈值直接决策，低于低阈值转走，中间地带交给大模型或人工。表面看这只是工程细节，实际效果非常明显——系统不再被迫对每个输入都给出一个"看起来正确"的答案，准确率和人工兜底率都变得更可控了。这条经验后来也延续到了其他场景里：与其让模型硬猜，不如给它一个"说不知道"的权利。

5.2 特征漂移怎么发现

System One模型的特征空间是固定的，但用户的语言一直在变。上线几周后，我注意到某类工单的平均置信度在缓慢下降。查了一圈才发现，"登录不上去"这类旧表达在减少，"一直转圈""卡在验证码"这类新说法在增加，种子词表的覆盖率开始下降。

后来我加了三项按日统计的监控指标：特征命中率、类别分布、平均置信度。设定告警线，当平均置信度连续多日下降，或者某个类别的占比偏移幅度过大，就触发一次重新采样和训练。这套监控不用做得很重，一张按日聚合的指标表就够了，关键是能及时发现问题——模型还在用旧世界的词表解读新世界的文本。每一次特征漂移的复盘，其实也是重新理解用户表达习惯的好机会。

5.3 效果评估：别只盯着准确率

上线后如果只看准确率，很容易产生"一切都好"的错觉。结合这类系统的特点，我建议至少跟踪四类核心指标：

• 自动处理率：Jev直接决策的比例，理论上越高越好，代表系统真正扛住了多少请求。
• 兜底率：转大模型或人工的比例，需要控制在一个合理范围，太高说明Jev没扛住多少活。
• 端到端延迟：统计p95，包含特征计算、模型推理、结果返回的完整链路。
• 单位决策成本：由Jev与大模型的调用占比决定，直接反映拆分带来的收益。

评估的节奏建议是：上线一周看趋势，两周做第一次完整体检。自动处理率长时间上不去，优先检查置信度阈值是否设得过高、特征是否有区分度；准确率不稳定，优先排查边界样本有没有被持续采集回流。指标之间往往是连动的，单看哪一个都没意义。

6. 重新看待"拆决策"这件事

6.1 拆决策的第一步是列决策点，不是选模型

经过这个项目，我第一个沉淀下来的习惯是：拆决策之前先不讨论模型，把系统里所有需要"判断"的点列成一张清单，逐项标出请求频率、结果是否可枚举、判断是否有清晰标准、出错之后能不能复盘。分类完成后，哪些该进System One、哪些该留大模型、哪些必须转人工，就一目了然了。很多项目把这一步省了，直接跳到模型选型，做了大半年发现一半决策点根本不合适，再回来返工，成本高得多。

6.2 判断"该不该拆"的三连问

后来我只要遇到"这个判断是不是该交给大模型"的讨论，就会连问三个问题：这个判断每天会发生多少次？结果能不能用一个有限集合列出？出问题的时候能不能解释清楚？如果三个答案都是肯定的，它大概率应该归属System One而不是大模型。如果其中任何一个答案是否定的，那才考虑留给大模型，或者设计一条人工兜底的路。这三连问帮我挡掉了很多"看着应该可以用大模型做，但实际根本落不了地"的需求。

6.3 最直观的收益变化

把决策拆出来之后，我最直接的感受是：延迟降下去了，账单好看了，更重要的是每个决策都可以拿特征贡献解释来复盘，和业务方对口径时不用再靠一句"大模型觉得"来交差。Jev在这个系统里承担的远不只是"快"，它让整套架构从"什么都靠大模型一把梭"重新回到了分工理性的状态。这个方法不一定适合每一个系统，但如果你手上也有一堆高频、结果可枚举、需要稳定判断的场景，完全值得沿着这个方向试一次。