姚顺宇说 AI 不太需要“脑子”：从 Role Copilot trace schema 看企业 AI 为什么更需要靠谱

姚顺宇说 AI 不太需要"脑子"：从 Role Copilot trace schema 看企业 AI 为什么更需要靠谱

说明：本文从一段采访观点出发，结合我最近在研究的 Role Copilot trace schema，讨论企业 AI 系统里"靠谱"到底应该如何工程化。这里的重点不是评价个人观点，而是借这个入口解释一个工程问题：AI 如何在证据、判断和行动之间保持边界。

我最近看到姚顺宇在采访里提到一个很直白的观点，大意是：AI 这个事，本来也不太需要"脑子"。相比某种极端聪明，AI 研究和工程更需要的是靠谱、系统、细心、有责任心。

这句话第一次看会有点反直觉。AI 不是最前沿的技术方向吗？为什么会说"不太需要脑子"？

但如果把这个观点放到企业 AI 里看，会发现它其实很准确。企业 AI 最难的地方，不是让模型表现得更聪明，而是让它在真实业务系统里做事足够可靠。

我最近在研究 Role Copilot trace schema，越来越感觉到：企业 AI 的"靠谱"不能只停留在价值观里，它需要被设计成一套可审计、可复核、可执行约束的工程结构。

1. 企业 AI 的常见风险：从相关证据直接跳到最终结论

人类在业务判断里经常会自然跳跃。

例如 HR 场景：

候选人简历里写了"参与推荐系统召回服务开发，并参与 A/B test 指标分析"。很多人会自然联想到：这个人可能懂推荐算法。

再看 DevOps 场景：

一次发布后线上 timeout 增多，diff 里刚好看到 timeout 从 5s 改成了 1s。有经验的工程师很容易判断：大概率就是这个配置导致的。

这些判断不一定错。很多专家的价值，正来自这种经验压缩。

问题在于，经验判断的中间链路通常不可审计：

• 当前证据到底证明了什么？
• 哪些只是相关，不是证明？
• 哪些结论还不能下？
• 下一步只是建议验证，还是可以直接执行？
• 哪些动作必须让人确认？

人类可以把这些步骤压缩在脑子里，但 AI 系统不能简单继承这种跳跃。否则它会把"相关证据"包装成"已证明结论"，再把"建议动作"滑向"自动执行"。

这就是企业 AI 里更危险的一类幻觉。

它不是完全编造事实，而是对真实证据做了过度外推。

2. 为什么普通输出不够，需要 trace schema

很多 Copilot 输出看起来是这样的：

{
  "result": "候选人具备推荐算法能力",
  "reason": "候选人参与过推荐系统开发和 A/B test 分析",
  "action": "推荐进入下一轮"
}

或者：

{
  "root_cause": "timeout 配置变更导致线上故障",
  "action": "回滚配置"
}

这种输出的问题是：它把证据、判断和行动压在一起了。

看起来简洁，但缺少关键边界：

• 证据是什么？
• 证据强度如何？
• 证据最多能支持什么判断？
• 哪些判断还不能支持？
• 建议动作是什么？
• 是否需要人工复核？
• 是否允许自动执行？

如果这些边界没有显式表达，Copilot 就很容易"看起来专业"，但实际上不可审计。

Role Copilot trace schema 要解决的就是这个问题。

它不是为了让系统多输出几个字段，而是为了让 Copilot 的每一次判断都留下证据链、边界和责任位置。

3. 一个最小 Role Copilot trace schema

下面是一个简化版结构：

target_judgment: Copilot 试图判断什么

evidence:
  - source: 证据来源
    observed_fact: 可证明事实
    citation: 引用或定位
    strength: weak | medium | strong

supported_judgment:
  - 当前证据可以支持的判断

unsupported_judgment:
  - 当前证据不能支持的判断

recommended_action:
  - 下一步建议动作

human_review:
  required: true | false
  reason: 为什么需要或不需要人复核

auto_execute_allowed:
  allowed: true | false
  reason: 为什么允许或不允许自动执行

这套 schema 的核心不是字段本身，而是它强制 Copilot 经过一条判断链：
#mermaid-svg-ULofP9criHmi3iK7{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ULofP9criHmi3iK7 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ULofP9criHmi3iK7 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ULofP9criHmi3iK7 .error-icon{fill:#552222;}#mermaid-svg-ULofP9criHmi3iK7 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ULofP9criHmi3iK7 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ULofP9criHmi3iK7 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ULofP9criHmi3iK7 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ULofP9criHmi3iK7 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ULofP9criHmi3iK7 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ULofP9criHmi3iK7 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ULofP9criHmi3iK7 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ULofP9criHmi3iK7 .marker.cross{stroke:#333333;}#mermaid-svg-ULofP9criHmi3iK7 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ULofP9criHmi3iK7 p{margin:0;}#mermaid-svg-ULofP9criHmi3iK7 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-ULofP9criHmi3iK7 .cluster-label text{fill:#333;}#mermaid-svg-ULofP9criHmi3iK7 .cluster-label span{color:#333;}#mermaid-svg-ULofP9criHmi3iK7 .cluster-label span p{background-color:transparent;}#mermaid-svg-ULofP9criHmi3iK7 .label text,#mermaid-svg-ULofP9criHmi3iK7 span{fill:#333;color:#333;}#mermaid-svg-ULofP9criHmi3iK7 .node rect,#mermaid-svg-ULofP9criHmi3iK7 .node circle,#mermaid-svg-ULofP9criHmi3iK7 .node ellipse,#mermaid-svg-ULofP9criHmi3iK7 .node polygon,#mermaid-svg-ULofP9criHmi3iK7 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ULofP9criHmi3iK7 .rough-node .label text,#mermaid-svg-ULofP9criHmi3iK7 .node .label text,#mermaid-svg-ULofP9criHmi3iK7 .image-shape .label,#mermaid-svg-ULofP9criHmi3iK7 .icon-shape .label{text-anchor:middle;}#mermaid-svg-ULofP9criHmi3iK7 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-ULofP9criHmi3iK7 .rough-node .label,#mermaid-svg-ULofP9criHmi3iK7 .node .label,#mermaid-svg-ULofP9criHmi3iK7 .image-shape .label,#mermaid-svg-ULofP9criHmi3iK7 .icon-shape .label{text-align:center;}#mermaid-svg-ULofP9criHmi3iK7 .node.clickable{cursor:pointer;}#mermaid-svg-ULofP9criHmi3iK7 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-ULofP9criHmi3iK7 .arrowheadPath{fill:#333333;}#mermaid-svg-ULofP9criHmi3iK7 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ULofP9criHmi3iK7 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ULofP9criHmi3iK7 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ULofP9criHmi3iK7 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-ULofP9criHmi3iK7 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ULofP9criHmi3iK7 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-ULofP9criHmi3iK7 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ULofP9criHmi3iK7 .cluster text{fill:#333;}#mermaid-svg-ULofP9criHmi3iK7 .cluster span{color:#333;}#mermaid-svg-ULofP9criHmi3iK7 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ULofP9criHmi3iK7 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-ULofP9criHmi3iK7 rect.text{fill:none;stroke-width:0;}#mermaid-svg-ULofP9criHmi3iK7 .icon-shape,#mermaid-svg-ULofP9criHmi3iK7 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ULofP9criHmi3iK7 .icon-shape p,#mermaid-svg-ULofP9criHmi3iK7 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-ULofP9criHmi3iK7 .icon-shape .label rect,#mermaid-svg-ULofP9criHmi3iK7 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ULofP9criHmi3iK7 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-ULofP9criHmi3iK7 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-ULofP9criHmi3iK7 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Evidence

收集证据
Supported Judgment

可支持判断
Unsupported Judgment

不能支持的判断
Recommended Action

建议动作
Human Review

人工复核
Auto Execute Boundary

自动执行边界

这条链路的价值在于：它阻止 AI 从"看起来相关"直接跳到"可以执行"。

4. HR Copilot case：A/B test 指标分析不等于算法建模能力

假设 HR Copilot 要判断：

候选人是否具备推荐算法建模能力？

候选人简历里写：

参与推荐系统召回服务开发，并参与 A/B test 指标分析。

一个不够稳的 Copilot 可能会输出：

候选人具备推荐算法经验。

但更靠谱的 trace 应该这样拆：

target_judgment: 候选人是否具备推荐算法建模能力

evidence:
  - source: resume
    observed_fact: 候选人参与推荐系统召回服务开发
    strength: medium
  - source: resume
    observed_fact: 候选人参与 A/B test 指标分析
    strength: medium

supported_judgment:
  - 候选人参与过推荐系统相关工程开发
  - 候选人接触过推荐效果评估或实验指标分析
  - 候选人可能理解推荐系统上线后的效果验证流程

unsupported_judgment:
  - 候选人具备推荐算法建模能力
  - 候选人做过特征工程
  - 候选人训练过推荐模型
  - 候选人做过排序算法调优

recommended_action:
  - 面试追问候选人在 A/B test 中负责的是指标分析、工程埋点、实验设计，还是算法策略调整
  - 追问是否调整过召回策略、排序特征、模型参数或实验分桶策略

human_review:
  required: true
  reason: 当前证据只能支持推荐系统工程和效果评估相关经验，不能直接支持算法建模能力

auto_execute_allowed:
  allowed: false
  reason: 不能基于当前证据自动给出最终能力定级

这里的关键点是：Copilot 没有否定候选人的价值。

它只是把"已经证明的能力"和"还需要追问的能力"分开了。

这就是靠谱。

5. DevOps Copilot case：强嫌疑根因不等于自动回滚

再看一个 DevOps 场景。

目标判断是：

是否可以确认 timeout 配置变更导致线上支付回调故障，并自动回滚？

Copilot 收集到：

• 发布后 payment gateway timeout 增多
• 监控显示错误率上升
• diff 显示 timeout 默认值从 5s 改成 1s
• 历史上支付回调超时曾引发重复扣款告警

不够稳的输出可能是：

根因已确认，建议自动回滚。

更稳的 trace 应该是：

target_judgment: 是否可以确认 timeout 配置变更导致故障并自动回滚

evidence:
  - source: logs
    observed_fact: 发布后 payment gateway timeout 增多
    strength: medium
  - source: monitoring
    observed_fact: 发布后错误率上升
    strength: medium
  - source: git_diff
    observed_fact: timeout 默认值从 5s 改成 1s
    strength: strong
  - source: incident_history
    observed_fact: 支付回调超时曾引发重复扣款告警
    strength: medium

supported_judgment:
  - timeout 配置变更是强嫌疑根因
  - 支付回调链路存在高风险相关性
  - 需要优先验证该配置变更的影响

unsupported_judgment:
  - 根因已经唯一确认
  - 回滚一定能恢复
  - 系统可以自动修改生产配置

recommended_action:
  - 自动整理日志、监控、diff 和影响范围
  - 补充支付回调链路验证
  - 准备 rollback plan
  - 提交人工确认
  - 确认后走灰度和监控观察

human_review:
  required: true
  reason: 该操作涉及生产支付链路，当前证据只支持强嫌疑，不支持自动改变生产状态

auto_execute_allowed:
  allowed: false
  reason: 高风险生产动作需要人工确认或审批

这里 auto_execute_allowed=false 不是 Copilot 没价值。

相反，它说明 Copilot 知道自己的边界：可以自动整理证据和建议下一步，但不能直接改变生产状态。

6. 可支持判断、不能支持判断、建议动作的区别

这三个字段很容易混在一起。

字段	作用	常见错误
supported_judgment	当前证据可以支持的判断	把相关经验直接写成最终能力结论
unsupported_judgment	当前证据不能支持的判断	不写不能判断的部分，导致结论看起来过满
recommended_action	下一步建议做什么	把建议动作直接升级成自动执行
auto_execute_allowed	是否允许系统自动行动	把强嫌疑当成执行许可

一个简单判断规则是：

如果当前证据只能支持"相关""强嫌疑""部分满足"，那它通常只能进入 recommended_action，不能直接进入自动执行。

只有当证据、权限、风险等级、回滚能力、审批策略都满足条件时，才可能允许 auto_execute_allowed=true。

7. 一个可复用 checklist

设计 Role Copilot 时，可以用下面几个问题检查输出是否靠谱：

• 是否明确写出了 target_judgment？
• 是否把原始事实和推断结论分开？
• 是否说明了证据来源？
• 是否写出了当前证据能支持的判断？
• 是否写出了当前证据不能支持的判断？
• 是否把下一步建议和自动执行分开？
• 是否说明哪些动作需要 human_review？
• 是否说明为什么 auto_execute_allowed 为 true 或 false？
• 是否避免把"强嫌疑"写成"根因已确认"？
• 是否避免把"相关经验"写成"能力已证明"？

这个 checklist 看起来朴素，但很关键。

企业 AI 的风险往往不来自某一个字段写错，而是来自证据、判断、行动之间的边界消失。

8. 回到"靠谱"这件事

现在再回头看姚顺宇那句话，就更容易理解了。

AI 不是不需要能力，也不是不需要聪明。

但在企业场景里，"聪明"如果没有边界，很容易变成不可控。

一个真正可用的企业 AI，不只是能快速给出答案，还应该能说明：

• 我看到了什么证据
• 这些证据能支持什么
• 这些证据不能支持什么
• 我建议下一步做什么
• 哪些动作需要人复核
• 哪些动作允许自动执行

这就是把"靠谱"工程化。

Role Copilot trace schema 对我来说，不只是一个输出格式，而是一种企业 AI 的基本约束：让系统在每一次判断里，都能把证据、结论、建议和执行边界讲清楚。

总结

企业 AI 真正要进入工作流，不能只追求"看起来聪明"。

它必须能在复杂业务里保持边界感。

具体到 Role Copilot，就是要把输出拆成：

• evidence
• supported_judgment
• unsupported_judgment
• recommended_action
• human_review
• auto_execute_allowed

这套结构的目的，不是让 Copilot 输出更复杂，而是让它更可靠。

聪明的系统能很快给出答案。

靠谱的系统知道答案的边界在哪里。

企业 AI 也是一样。