跳到主要内容

如果 2026 还继续做 AI，先补这三块基础设施：Trace、评测集和回放系统

· 阅读需 6 分钟
一介布衣
一介布衣
全栈开发者

如果让我给还打算继续做 AI 的团队只留三项投资建议，我不会先选更复杂的 Agent 框架，也不会先选更花哨的工作台。我会先问三个很现实的问题：线上某次异常到底发生了什么，最近一次改动到底是变好了还是变差了，三周前那次事故今天还能不能重放出来。如果这三个问题答不上来，后面所有“持续迭代”都很容易变成盲飞。

做了几轮项目以后，我越来越觉得真正拉开团队成熟度的，不是会不会接模型 API，而是这三条底层线有没有先立住：Trace、评测集、回放系统。它们听起来都不像功能，偏偏每次功能出问题时，第一个想找的又都是它们。

为什么偏偏是这三块先变贵​

很多团队早期也会知道这些东西重要，但总觉得可以等“功能再稳定一点”再补。现实通常正好反过来：功能一旦变多，没补这三块的代价会迅速放大。

  • 没有 Trace，线上问题只能靠口供和猜测排查。
  • 没有评测集，每次改 Prompt、换模型、改路由都只能看感觉。
  • 没有回放系统，事故复盘永远只能停留在“我记得那天好像不是这样”。

这三样东西都不直接提高首屏演示效果，但它们决定了系统出事以后团队能不能迅速重新掌握现场。

第一块先补 Trace，因为它负责把现场串起来​

我现在说 Trace，已经不再只是“多打一层日志”了。真正有用的 Trace 至少要把一次请求在前端、BFF、工作流、模型和工具调用之间的轨迹串起来。否则某个步骤一慢、某次工具调用一重试，大家就又会回到“到底是哪一层先坏的”这种原始状态。

我更愿意把一条关键事件做成下面这种结构：

{
  "traceId": "tr_7f12",
  "requestId": "req_3321",
  "stepId": "rewrite.summary",
  "toolCallId": "tool_18",
  "scene": "content-review",
  "model": "gpt-4.1",
  "latencyMs": 842,
  "retryCount": 1,
  "handoffToHuman": false,
  "releaseId": "rel_20251208_02"
}

这类结构最重要的不是字段多少，而是让一次事故不再碎在五个系统里。你至少能先把“谁触发了什么、在哪一层慢了、有没有重试、吃的是哪一版发布”拉成一条线。

第二块先补评测集，因为感觉不能替代比较​

团队最容易在这里吃亏。某次改动上线以后，所有人都隐约觉得效果“好像还行”，或者“最近好像有点飘”，但谁也拿不出一组稳定样本说明变化到底发生在哪。时间一长，产品判断、模型选择和 Prompt 讨论就会重新退回印象派。

我现在更愿意把第一版评测集做得很小，但很像工程资产：

{
  "caseId": "eval_102",
  "scene": "title-generation",
  "inputSnapshotId": "snap_882",
  "expectedLabel": "specific_and_searchable",
  "failureRisk": "high",
  "owner": "content-platform",
  "notes": "容易退化成空泛标题"
}

第一版评测集不需要追求覆盖一切，它最该优先收的，是那些已经真的出过错、争议过、返工过的样本。只要样本能稳定复跑，很多关于“到底该不该切模型”“这版 Prompt 是否值得放量”的争论都会立刻具体很多。

第三块先补回放系统，因为事故不能只留下记忆​

Trace 负责告诉你发生了什么，评测集负责告诉你改动前后怎么比，回放系统则负责把“那次执行”重新拉回眼前。很多团队会保存请求和结果，但这还不够。你真正需要的是能把当时生效的上下文版本一起带回来。

像下面这样的回放句柄，我现在会觉得非常值钱：

{
  "replayId": "replay_551",
  "releaseId": "rel_20251208_02",
  "requestId": "req_3321",
  "promptVersion": "title-gen@2025-12-08.2",
  "toolPolicyVersion": "tool-policy@1.4",
  "inputSnapshotId": "snap_882",
  "toolSnapshotIds": ["tool_18_out"],
  "outputSnapshotId": "out_71"
}

有了这一层，事故复盘终于不只是“再跑一下当前代码看看”，而是能更接近地回答“当时为什么会给出那个结果”。这对 Prompt 回滚、模型路由调整和误杀复盘都特别关键。

为什么我把它们排在更多功能前面​

很多看起来更性感的能力，最后都要站在这三块基础设施上才能稳。比如：

  • 你想做多模型路由，但没有评测集，就不知道路由是不是越改越糟。
  • 你想做复杂工具链，但没有 Trace，就很难知道是哪一步把结果拖坏。
  • 你想做自动补偿和恢复，但没有回放系统，很多故障只能靠人工猜测复现。

所以我现在对“下一年应该先补什么”这个问题的答案反而越来越保守。不是因为功能不重要，而是因为只要底层三条线没补上，功能越多，黑箱越大，返工也越贵。

我真正想保留的结论​

如果 2026 还继续做 AI，我最想先补的不是更多页面，不是更多链路，也不是更多“智能”包装，而是三条能把系统重新拉回可解释状态的基础线：Trace、评测集、回放系统。它们共同解决的是一件事: 出了问题以后，团队还能不能迅速掌握事实。只要这件事做不到，后面的模型升级、Prompt 调整和 Agent 化都会越来越像在雾里开车。

我更愿意先补的机制​

  • Trace 让每次请求的模型调用、工具调用和人审动作可以被串起来排查。
  • 评测集把“产品感觉”变成可以稳定比较的样本资产。
  • 回放系统让回归验证和事故复盘不再依赖临时手工复现。

如果今天重新把这条链路接起来​

我会优先把异常样本、关键指标和回退动作放进同一条观测链路里，而不是把监控、运营和补偿拆给不同模块各自维护。问题真正发生时，团队需要看到的是同一份上下文，而不是几张互相对不上的表。

我真正想保留的结论​

没有这三块基础设施，后面的模型升级、Prompt 调整和 Agent 化都会越来越像黑箱。