Linear：如何设计可信的 AI 工单分诊
How we built Triage Intelligence
01 · 先读这里
为什么推荐
这篇特别适合做复杂 B 端 Agent 的设计参考：AI 不在独立聊天框里展示聪明，而是在工单原有信息架构里给出建议，并解释“为什么”。它把来源区分、等待反馈、悬停理由、深入审查四个层次设计得非常具体，且交代了模型变慢之后界面如何取舍。
02
这篇讲什么
Linear 将工单分诊中的重复识别、关联推荐、标签与负责人建议嵌入原有 Triage 页面，而非另建聊天应用。建议模块复用既有字段语言，却明确区分模型建议和人工或规则设置的值；鼠标悬停可查看理由与替代建议。针对大模型多步推理的等待，模块显示思考状态与计时器；需要深入核验时，可展开 Thinking Panel 查看检索上下文、判断过程和额外指导。团队还支持以自然语言调整工作区或团队级建议行为。这个案例的核心不是模型有多聪明，而是如何把预测放入可审阅、可纠正的业务对象。
扩展评分
一句话带走
AI 的可信度，要在业务对象上设计，不靠一段“我认为”。
交互范式
交互到底改变了什么
- 原来的交互
- 人工检索重复工单、手动设标签和负责人，靠经验决定分派。
- Agent 带来的变化
- Agent 主动检索上下文并提出结构化建议，人仍负责审阅采纳。
- 用户的新成本
- 要辨别建议来源、理解较长等待、必要时检查依据。
- 关键交互机制
- 建议模块；来源区分；悬停解释；计时；推理面板；Additional Guidance。
- HCI 依据
- 原文未提供
- 团队设计信号
- 原文将模型架构选择与界面反馈设计串成同一问题。
设计策略
从具体设计中学习
01
将 AI 建议嵌入分诊对象，但与人工字段明确区分
- 看图重点
- 看建议是否与工单字段同处一屏，以及建议与既定属性的来源区分。
- 图像作用
- 官方产品 UI 截图
- 问题
- 分类、去重和分派依赖资深同事的隐性知识；AI 建议混进正式字段会造成来源混淆。
- 方案
- 在现有 Triage 页面放独立建议模块，沿用原有属性视觉语言，同时标识模型建议与人工/规则设置。
- 为什么这样做
- 无需跳转到独立聊天工具即可审阅建议；来源分离减少误把预测当事实的风险。
- 取舍
- 根据方案推断：独立建议模块增加密集页面的信息量，需控制默认展示密度。
原文依据与解读
The UI makes that distinction clear
- 译文
- 界面明确区分两种来源。
- 解读
- 可信度不是给 AI 加头像，而是让预测与已确认事实在对象层可辨。
可迁移规则凡是 AI 填写业务字段，必须区分“建议值、已采纳值、来源”。
02
先给轻量思考态和计时，再允许按需检查依据
- 看图重点
- 看底部状态、计时，以及其与建议结果的空间关系。
- 图像作用
- 官方产品 UI 截图
- 问题
- 多步推理比确定性操作慢，空白等待会让用户误以为系统卡住。
- 方案
- 在建议模块内显示思考态和计时；鼠标悬停建议可看简短理由与替代建议。
- 为什么这样做
- 让用户在等待时判断系统是否仍在工作，同时不必默认阅读冗长推理。
- 取舍
- 根据方案推断：计时提高等待透明度，也可能让用户更敏感地察觉延迟。
原文依据与解读
thinking state along with a timer
- 译文
- 思考状态和计时器。
- 解读
- 等待反馈和解释深度应分层，而非用一段长文本同时承担。
可迁移规则超过瞬时响应的 Agent：默认显示状态与耗时，解释按需展开。
03
把研究轨迹设计成审查面，而非默认塞满主界面
- 看图重点
- 看独立推理面板展示哪些来源、步骤和指导信息。
- 图像作用
- 官方产品 UI 截图
- 问题
- 仅有最终标签难以检查复杂工单的推荐依据。
- 方案
- 提供独立 Thinking Panel，呈现模型检索到的上下文、判断和额外指导如何影响结果。
- 为什么这样做
- 把深入核验留给需要判断争议建议的人，主流程保持快速。
- 取舍
- 根据方案推断：更深的解释增加阅读负担，也不代表模型结论必然正确。
原文依据与解读
full trace of the model’s research
- 译文
- 模型研究过程的完整轨迹。
- 解读
- 过程可见是审计线索，不应被误当作正确性的证明。
可迁移规则高风险 AI 建议应提供“结果→理由→证据轨迹”的渐进披露。
推理链
从问题到设计判断
- 问题
- 工单分诊依赖人工、建议难解释且推理慢
- 证据
- 原文记录小模型在复杂上下文判断中失效，且给出多张建议/计时/推理面板截图
- 判断
- AI 应进入原工作流，同时让建议来源、等待状态与审查依据可见
- 设计策略
- 独立建议模块＋来源区分＋计时＋按需推理轨迹
- 结果
- Triage Intelligence 作为产品功能发布；量化用户成效原文未提供
迁移原则
带回自己的项目
- AI 预测的负责人/标签必须与正式字段有可辨认的状态差异。
- 推理超过瞬时响应时，默认显示计时与状态，详细轨迹按需展开。
- 解释界面先给简短理由，再允许核对检索来源和替代建议。
03
它真正解决的问题
如何在高密度工单分诊界面中可信地呈现 AI 建议与推理过程。
04
作者用了什么依据
原文记载小模型在复杂上下文场景中受限，升级为可补充检索的 Agent；界面设计截图可核验。
05
核心设计洞察
把 AI 预测留在可辨认的候选态，并让依据按需展开。
06
具体做了什么
将 AI 建议嵌入分诊对象，但与人工字段明确区分；先给轻量思考态和计时，再允许按需检查依据；把研究轨迹设计成审查面，而非默认塞满主界面
07
为什么这样做
工单分诊依赖人工、建议难解释且推理慢 → 原文记录小模型在复杂上下文判断中失效，且给出多张建议/计时/推理面板截图 → AI 应进入原工作流，同时让建议来源、等待状态与审查依据可见 → 独立建议模块＋来源区分＋计时＋按需推理轨迹 → Triage Intelligence 作为产品功能发布；量化用户成效原文未提供
08
有什么关键取舍
默认信息密度与可解释性之间的取舍；更多推理深度带来更长等待。
09
最终有没有验证
原文未提供
从这篇学习
值得学什么
AI 建议要和已确认业务事实分层。
先显示候选，再按需展开理由与过程。
原文未提供
从模型等待与业务信任冲突倒推信息架构。
可解释性是来源、状态和证据的层级设计。
先说明模型限制，再展示对应的界面设计选择。
10 · 迁移
可以带走什么
业务字段的预测值不得伪装成已确认事实。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。