星火X2.6 走端还是走云，先看两件事：这条任务的输入里有没有不能离开设备的数据，以及这条任务能容忍多长的延迟。把这两项写成可对照的数值，端云之争才有落点；跳过这一步直接比较「端侧省事」和「云侧效果好」，选型会一直摇摆。下面是一套可照着执行的划线流程，不依赖任何模型跑分或收益承诺，每一项都能用配置、日志或页面行为核对。

建议先把现有任务拆成条目，逐条标出输入里的数据类型和可接受延迟上限，再用一张二维表划成三块：含敏感字段且延迟宽松的留在端侧；输入可外发、延迟紧、质量要求高的走云侧；两类都不极端的先用端侧跑小范围灰度。灰度只看可观测的失败率和人工返工量，回退条件写死在配置里。边界情形（长文本又含敏感字段）默认整条走端侧、不拆分，除非能确认脱敏后任务仍成立。

把现有任务列全，逐条标出输入里含哪些数据

隐私判断要从抽象原则落到具体对象：同一句「数据敏感」，在录音转写、工单摘要、代码补全三类任务里指向的字段完全不同。先建一张任务台账，列名固定下来，后续所有讨论都对着这张表说话。

• 任务ID、任务名、触发入口（哪个页面或哪个按钮触发）
• 输入来源（用户手输、上传文件、设备采集、其他系统推送）
• 输入字段清单、输出形态（文本、结构化 JSON、文件）
• 下游消费方（只回显给用户，还是落库、还是会转发给第三方）
• 失败后果（可忽略、需人工重试、影响业务）

数据项按字段标注，不按任务标注——同一个任务的不同入口，输入内容可能完全不同。标签用固定枚举，便于后续写规则：公开、内部、个人信息、凭证类、设备与位置。含敏感字段的任务单独打一个标记 S，只在有内部数据时标 I，输入全为公开内容时标 P。

标记规则建议写成可被程序复用的字段匹配表，而不是靠人肉记忆。字段名对不上时，用采样日志回捞真实输入再补，别凭字段名猜。

# 字段敏感标签匹配规则（示例，按实际字段名替换）
sensitive_rules:
  - level: S
    match_fields: [id_card, phone, address, bank_card, password, token, cookie]
  - level: S
    match_content: ["身份证", "银行卡", "住址"]   # 自由文本命中的关键词
  - level: I
    match_fields: [employee_id, order_id, internal_doc]
  - level: P
    default: true   # 未命中以上规则的字段

给每条任务写一个可接受的延迟上限

「快不快」不能靠感觉，要给每条任务写一个数值区间。数值来源是自身场景的预期，不是模型宣传的推理速度：交互式输入框留白要求短，后台批处理可以长，用户点了按钮之后盯着看，和关了页面等结果，容忍度差很多。

记录方式建议每条任务写三项：首字或首屏出现的时间目标、完整结果返回的时间目标、是否含网络往返。测量口径必须写清楚，是「从用户触发到结果落到页面」，还是「从请求发出到模型返回首包」，两种口径混着对比会得出错误结论。暂时估不准的写区间并标注「待确认」，后面用日志补。

把敏感级别和延迟上限并到同一张表里，就得到可直接分流的三列清单：

表里的具体数值按自己的场景填，不建议直接抄别人的数字；填完后回头检查一遍，是否存在「敏感级别为 S 但延迟要求很紧」的任务——这类任务最容易在后期被逼着偷偷改成上云。

做二维决策表，划出必须走端侧、必须走云侧、两边都行的三块

行列设计很简单：行是敏感级别 S / I / P，列是延迟上限「紧 / 宽」。两两交叉后划出三块，判据写死，不用每次开会重议。

• 必须走端侧：敏感级别为 S，且任务失败代价高或下游会落库。凭证类字段尤其如此，一旦进入请求体就等于出网。
• 必须走云侧：敏感级别为 P 或 I，但延迟紧、输出质量要求高，或输入规模超出端侧可承载范围。
• 两边都行：I 与 P 且延迟宽松的任务，以及 S 但输入可脱敏、脱敏后不改变任务语义的任务。

边界情形要提前定：长文本且含敏感字段，默认整条走端侧、不做「截取敏感段后上云」的拆分，因为拆分点一旦判断错，敏感内容还是出去了。确实需要上云的，先确认脱敏规则在页面上可见、可回放，并且脱敏后任务结果仍然可用，否则按必须走端侧处理。

对“两边都行”的部分先小范围跑端侧

「两边都行」的任务不要一次性切端侧，先拿最少代价验证端侧是否够用。灰度范围按入口分批，不建议随机全量：选一个入口、一类设备或一个用户群，跑一段时间看日志，再决定是否扩大。

观察指标只取可从日志核对的项：端侧推理失败次数、超时次数、输出校验不通过次数、用户重问或人工改写次数、端侧耗时分布（看尾部而不是平均值）。这些指标在灰度期每天都应能看到，看不到说明埋点没打全，先补埋点再谈结论。

回退触发条件写进配置而不是写进文档，避免实现方各自理解。通用的回落骨架如下，字段名可替换：

{
  "task_id": "doc_summary_v1",
  "route": "on_device",
  "fallback": {
    "target": "cloud",
    "on": ["model_load_failed", "infer_timeout", "output_check_failed", "memory_not_enough"],
    "consecutive_failures": 3,
    "cooldown": "按需设置"
  },
  "log_fields": ["route", "latency_ms", "fallback_reason", "input_tokens", "sensitivity"]
}

回退发生时要在页面上可感知——至少让上层知道这次结果是云端产出的，否则出问题时无法定位是端侧还是云端链路。回退本身是保底手段，不要当成性能方案来宣传。

把结论写成一句话规则，交给后续实现

决策做完后，交付给实现方的不能是一堆讨论记录，而是一句可执行的规则。模板建议这样写：

当 任务=<任务名> 且 敏感级别=<S/I/P> 且 延迟上限=<紧/宽> 时，走 <端侧/云侧>；前置检查（脱敏、长度、设备能力）不满足时，回落 <指定路线>。

同步给实现的字段清单需要一次给全，避免后面反复对齐：任务ID、敏感级别、延迟上限与测量口径、目标路线、回退目标、回退触发条件、是否强制脱敏、输入长度上限、超时阈值、需要记录的日志字段。字段清单建议随台账一起维护，任务新增时同步补一行，规则句从同一份数据生成，减少口头传达的偏差。