系统智能化升级

一句话：能力已经上线了，接下来怎么把它做得好用、用得住、该退时能退。

本技能只处理上线之后这一段：量效果 → 定根因 → 改动作 → 扩场景 → 升版本 → 保回归 → 建反馈闭环 → 定退出标准。

它不做首次接入类的工作：不做能力选型与立项（那在方案阶段）、不做需求规格说明与技术规格说明、不设计挂载点与嵌入策略、不做数据与口径的首次兼容改造、不写业务代码。这些前提在本技能开始前应当已经存在；缺了就先回去补齐，不要在升级阶段重复讨论。

升级类工作最常见的三种失败方式，本技能专门避免：

与相邻技能的分工：成熟度定级与整体演进路径、能力选型与立项、需求/技术规格说明、首次接入的挂载点与数据兼容，都不在本技能范围内——遇到这些诉求交回对应阶段处理。本技能只在"能力已经在线"这个前提下工作。

这个技能产出什么

何时用 / 何时不用

用：能力已上线一段时间想知道到底有没有用；上线了但用的人少、用几次就不用了；效果时好时坏说不清原因；要给现有能力做一次版本迭代；要决定某个能力继续投入还是下线。

不用：能力还没上线、正要选型立项写规格说明（接入与方案阶段的事）；从零新建业务系统；只要一段示例代码或修一个 bug；纯界面视觉改版。

第 0 步 · 升级前置：先把三样东西找齐

没有这三样，后面的度量全是猜。

先问后做：如果用户无法提供以上任一项，不要凭经验假设一个数字往下推。明确写出"这一项缺失，本次结论的置信度受限"，请用户确认后继续。

第一步 · 效果评估与基线（确认门 1）

四类指标，两类看"好不好"，两类看"值不值"。度量口径、取数方式与陷阱见 references/effect-measurement.md。

基线三条（按优先级取第一条能拿到的）：

1. 上线前人工口径：同一件事之前靠人工做要多久、错多少，用真实工时或工单记录做基线；
2. 首两周内部基线：上线最初两周（用户还在新鲜期、行为最接近理想）作为自身基线，后续与本基线比；
3. 同类场景对照：同一能力在另一个部门/角色的表现做横向对照。

判定铁律：

• 没有口径的指标不得进结论。只有印象、没有分母的"感觉不太准"只能进待验证清单。
• 样本量不足不下结论：单周期触发次数少于 30 次时，只描述趋势与现象，不写"提升/下降 N%"。
• 每次评估同时给出分母，不留只有比率的行。

确认门 1：输出效果评估表，问用户："这份效果评估与你的实际观察是否一致？有哪些指标你认为口径不对？"选项：一致，进入问题归类 / 口径需要修正 / 先补取数。口径需要修正时，先改口径再往下。

第二步 · 问题归类（五类根因）

把现象落到五类根因之一。一条问题只归一类，主责唯一；归不到一类的，写"待取证"并列出下一步取证动作，不得硬塞。

归类顺序（取证成本从低到高）：数据 → 口径 → 交互 → 提示词 → 场景选错。
先排除低成本的，再动高成本的，避免"一上来就调提示词"这种最常见的时间浪费。

产出：根因归类表（问题描述 → 根因类别 → 证据 → 影响的能力与用户面 → 建议处置）。
证据一栏必须写清取证方式与样本量；写不出证据的条目留在"待取证"，不进优化清单。

第三步 · 优化动作设计（确认门 2）

按 references/iteration-and-release.md 里每类根因的改法清单，逐条设计动作。每个动作三要素齐全才算成立：

单次升级的动作数上限建议为 5 个，且优先选择能分别归因的动作；超过上限就拆成两个版本。一锅端会让下一轮评估无法判断是哪一个改动起了作用。

确认门 2：输出优化清单（含每条的根因、动作、区间、验证方式），问用户："这版先做哪几项？"选项：按清单全部做 / 只做前 N 项 / 调整动作。得到明确答复后才进入版本方案。

第四步 · 能力扩展判定

能力稳定之后才会面对"要不要扩到相邻场景"。用四个复用判据先算复用度，再看顺序。

扩展顺序（复用度从高到低，先易后难）：

1. 同数据 · 同交互（最像的相邻场景，风险最低）；
2. 同数据 · 异交互（数据现成，只改呈现）；
3. 异数据 · 同交互（交互复用，先解决数据）；
4. 异数据 · 异交互（默认不做，它其实是新建一项能力，回到接入流程）。

反判据：只要"数据"与"口径"两项都落在低复用列，就不要称它为"扩展"——按新建能力走首次接入流程，不要用升级的方式硬塞进来。

第五步 · 版本升级与灰度（确认门 3）

升级范围按四个维度圈定，逐个写明放开节奏与放行判据：

写法要求与回滚条件、回滚动作清单见 references/iteration-and-release.md。三条硬要求：

1. 保留上一版快照：提示词、规则阈值、配置项在改动前留一份可整版回退的快照，回退步骤必须是能照着执行的序列；
2. 回滚条件可量化：如"准确率连续 2 天低于升级前 X 个百分点"，不写"视情况回滚"；
3. 灰度期禁止混合变量：灰度期内不改别的配置，否则放行判据失去意义。

确认门 3：把"升级方案 + 放行判据 + 回滚条件"摆给用户，选项：按此升级 / 缩小范围 / 暂缓。由用户决定，不替用户拍板。

第六步 · 回归验证清单

升级最容易伤到"原来好用的部分"。按 assets/upgrade-plan-template.md 的清单逐条勾选，未勾选项即为未验证项，必须在方案里明确写出，不得默认通过。

五类必查：

固定回放集是这一步的前提：从上版本积累 20~50 条真实问题固化成一个回归集，每次升级都重放一遍，才能证明"没有变差"。

第七步 · 用户反馈驱动的迭代机制

效果指标告诉你"发生了什么"，反馈告诉你"为什么"。两者都不能省。

三条机制要求：节奏固定（T+1 归集、每周处理一次、每月一次效果复盘，公布后按节奏走）；每条反馈必须有回执（不回执等于没收集，下一轮就没人再提）；高频未采纳问法优先（日志里"问了但没得到有用答案"的高频问法，是下一版优化清单最可靠的输入来源）。

第八步 · 退出标准：什么时候该下线

退出的四个信号（命中任一即启动评估，命中两个以上建议下线）：

退出流程（不得"悄悄下线"）：

1. 降级：隐藏入口或改为只读，保留能力本体，观察一个周期确认无人依赖；
2. 公告：向原使用人群说明下线时间、替代做法、找谁求助；
3. 下线并留档：保留配置与提示词快照、数据留存策略、以及"为什么下线"的一句话结论（下次别重复立项），与验收材料放在一起。

产出物规格

所有数字必须标来源与假设；来源不明的标"待核实"，且不得作为结论支撑。同一指标的口径在整个升级周期内必须唯一。

质量红线（禁止事项）

• 不编造数字：触发数、采纳率、耗时、满意度，用户没提供就标"待核实"并去取数，不得用行业均值或经验值顶替。
• 不无口径下结论：没有分母、没有定义、没有样本量的指标不得写成结论。
• 不给单点承诺：预期改善一律用区间 + 假设；禁止"升级后一定提升 N%"。
• 不混合升级：一个版本内的改动项要能分别归因；超过建议上限就拆版本，禁止用一次大改掩盖归因不了的事实。
• 不把口径问题当模型问题：口径未定死之前，不得通过反复调提示词去"对齐"口径。
• 不悄悄下线：任何能力退出都要走降级 → 公告 → 留档，不得直接隐藏或删除。
• 不越界写别的阶段的内容：不产出能力选型结论、立项方案书、需求/技术规格说明、挂载点设计——那些属于接入与方案阶段。
• 不跳过确认门：三个确认门必须逐一获得用户明确答复才能继续。

参考文件索引

• references/effect-measurement.md —— 四类效果指标的度量方法与基线设定、低采纳率的五类根因诊断、指标看板搭建要点
• references/iteration-and-release.md —— 优化动作设计与预期改善幅度、能力扩展判据与顺序、灰度范围与回滚条件、回归验证清单、反馈迭代机制、能力下线标准与退出流程
• assets/upgrade-plan-template.md —— 版本升级方案 + 优化清单 + 回归验证清单模板（可直接复制）

关于产品（可选接入）

本技能自包含、可独立使用，不依赖任何外部系统，也不要求接入任何特定平台。

同一套方法在「Smartware」中另有产品化承载：能力清单、模板与规则可直接作为配置与验收的依据；是否接入、如何接入由团队按自身环境决定。