跳到主要内容

参考答案

核对日期：2026-05-13。

1. 阶段练习参考方向​

1.1 调用封装练习​

模型调用接口应让业务层不感知具体 provider：

type ModelUsage = {
  inputTokens: number;
  outputTokens: number;
  totalTokens: number;
};

type ModelResult<T> = {
  content: T;
  usage: ModelUsage;
  providerRequestId: string;
  model: string;
  finishReason: string;
};

错误分类至少包含：认证失败、限流、超时、内容安全拦截、schema 校验失败、上游不可用、预算不足和未知错误。

1.2 Streaming 练习​

设计要点：

  • 服务端按 delta 推送，而不是等完整答案。
  • 用户取消后停止上游生成并标记状态。
  • 部分输出可保存为草稿，但不能当作已完成结果。
  • 流中断时允许重试或转异步任务。
  • 前端状态要区分 generating、partial、cancelled、failed、completed。

1.3 异步任务练习​

任务表字段应支持恢复和幂等：

字段作用
task_id幂等键和追踪
statusqueued/running/succeeded/failed/cancelled
progress前端展示
input_file_id输入对象
result_id输出对象
error_code失败分类
retry_count重试控制
created_at / updated_at排查和超时处理

幂等策略：同一用户、同一文件、同一 prompt version 可生成 idempotency key；重复请求返回同一任务或明确创建新版本。

1.4 成本账本练习​

成本日志至少包含：

  • user_id / tenant_id。
  • feature。
  • prompt_version。
  • model / provider。
  • input_tokens / output_tokens。
  • estimated_cost。
  • latency_ms。
  • cache_hit。
  • fallback_reason。
  • request_id / trace_id。

这些字段能回答用户、功能、版本、模型、fallback 和延迟的成本问题。

1.5 前端体验练习​

参考状态流：

idle -> submitting -> generating -> partial -> completed
                         |             |
                         |             -> user_editing -> confirmed
                         -> failed -> retrying
                         -> cancelling -> cancelled

每个状态都要定义用户能否取消、编辑、重试、提交反馈和离开页面。

2. 项目评分样例​

高分 AI Web 应用应具备：

  • 服务端封装模型调用，不暴露 API key。
  • 前端有生成中、取消、失败、重试、完成和编辑确认。
  • 有 prompt version、usage、trace、成本和错误日志。
  • 有基础 eval 样例和线上反馈入口。
  • 有限流、缓存、降级和预算设计。
  • 输出进入业务前需要用户确认或校验。

不合格表现：

  • 前端直接调用模型服务商 API。
  • 只实现聊天框，没有任务流和状态机。
  • 不记录 token 和成本。
  • 模型失败时只显示“出错了”。
  • 没有 eval，靠人工感觉上线。

3. 验收题参考答案​

  1. AI 应用和普通 Web 应用在工程上有哪些关键差异？

AI 应用引入不确定输出、token 成本、模型延迟、流式响应、内容安全、评测集、Prompt 版本和供应商风险。普通 Web 更偏确定性业务逻辑。

  1. 为什么前端不能直接持有模型 API key？

前端密钥可被用户提取，导致滥用、账单风险和数据泄漏。模型调用应走服务端，统一鉴权、限流、日志和预算。

  1. Provider adapter 应该统一哪些字段和错误？

统一输入消息、输出内容、结构化结果、usage、model、request id、finish reason、错误类型、重试建议和安全拦截信息。

  1. Streaming 和异步任务分别适合什么场景？

Streaming 适合用户等待中的增量文本生成；异步任务适合长文档、批处理、耗时工具链和用户可离开页面的任务。

  1. 流式响应中断时应该如何处理用户体验和数据状态？

标记为 failed 或 interrupted，保留部分草稿但不当作完成结果，提供重试、继续生成或重新提交，并记录上游错误和 trace。

  1. AI 缓存 key 为什么必须包含权限和版本信息？

同一问题在不同用户权限、文档版本、Prompt 版本、模型或参数下可能答案不同。缓存 key 缺少这些字段会造成越权或旧答案。

  1. 成本账本至少应该记录哪些字段？

用户、租户、功能、模型、provider、prompt version、输入/输出 token、费用估算、延迟、cache hit、fallback、request id 和 trace id。

  1. 模型调用失败应如何分类和恢复？

分类为认证、限流、超时、上游不可用、内容安全、schema 校验、预算不足和未知错误。恢复方式包括重试、降级、排队、转人工、提示用户修改输入或回滚版本。

  1. AI 输出为什么通常需要用户确认或可编辑机制？

模型输出可能不完整、不准确或不符合上下文。用户确认和编辑能降低错误进入业务系统的风险，尤其是对外发送、工单、合同和资金相关场景。

  1. 线上 AI 功能如何形成评测闭环？

线上收集 trace、用户反馈、采纳率、失败样例和成本数据，定期回流到 eval 集。Prompt、模型或 RAG 变更必须通过回归评测和灰度。