AI 求职每日一课 · 2026-09-12
AI JOB COURSE · WEEK 1 · DAY 6

输出层设计：让状态可解释、可恢复●

把不稳定的模型调用翻译成稳定的用户体验、错误边界和可观测状态。

02

为什么今天学这个

模型 API、Prompt 合同、Structured Outputs 和 Schema 校验解决了“能不能读懂结果”；输出层继续解决“用户现在看到什么、失败后怎么办”。
03

三个核心要点

状态完整：区分 submitting、streaming、success、partial、error 和 needs_review。
流式可追踪：记录 request、chunk、结束原因和可恢复位置，不能把断连接当成功。
业务有门禁：结构合法不等于业务正确，权限、资源和副作用仍需服务端校验。
04

最小可运行示例

type ViewState =
  | { kind: "idle" }
  | { kind: "streaming"; requestId: string; received: number }
  | { kind: "success"; requestId: string; answer: string }
  | { kind: "error"; requestId: string; retryable: boolean };

function canRetry(state) {
  return state.kind === "error" && state.retryable;
}
05

生产环境会怎么翻车

  • 把所有等待都显示成无限转圈：用户不知道系统处于模型、工具还是网络阶段。
  • 连接断开就展示半截答案：应记录结束原因，标记 partial 并提供恢复或重试。
  • Schema 通过就当业务成功：还要校验枚举、权限、资源存在性和跨字段规则。
06

动手练习

为一个流式问答页补齐 submitting、streaming、partial、error 四种状态；每种状态写出用户提示、可执行动作和日志字段。
07

面试表达

30 秒回答

我会把输出层设计成显式状态机：请求、模型流、工具执行、校验和展示各自有状态；失败时保留 request ID、模型版本、结束原因和可恢复位置，高风险结果在完整校验或人工确认后才展示。

08

今日自测

为什么不能只用 isLoading？
查看答案因为工具执行、流式生成、重试和人工审核的动作不同。
部分答案能否直接展示？
查看答案低风险文本可标记生成中；医疗、财务、写入或发布场景应等待校验。
重试按钮要带什么？
查看答案明确错误原因、request ID 和副作用检查边界。
09

来源与明日

明日：继续把工具调用和输出状态接到完整业务流程。
按 P 切换投影