Nuxt AI 应用开发 · 高级项目面

Nuxt AI 功能如何做灰度、评估门禁和可回滚发布？

考察 AI 功能发布中的 Prompt、模型、工具和前端版本协同。

适合阶段：高级 / 资深前端 · AI 应用面 / 架构面核心能力：Nuxt · Nitro · AI 工程化 · 生产治理

面试官想考什么

• 能否先定义 AI 场景和 Nuxt 的边界？
  考察 AI 功能发布中的 Prompt、模型、工具和前端版本协同。
• 能否讲清端到端链路？
  重点考察：candidate config -> offline eval gate -> canary cohort -> online quality/cost/error metrics -> expand or rollback; run records preserve all version ids。
• 能否说出工程取舍？
  重点考察：一次性全量发布简单但风险集中，灰度增加配置和观测复杂度；AI 质量指标滞后，必须结合技术指标和业务反馈。
• 能否处理线上风险？
  重点考察：发布记录 releaseId、promptVersion、model、toolVersion 和 feature flag，异常按 cohort 对比，回滚不能只切前端而忽略缓存和后台任务。

一句话回答

AI 发布单元不只是前端 bundle，还包括 Prompt、模型路由、工具 schema 和评估集版本；灰度按用户或租户进行，指标恶化时可以独立回滚策略和前端版本。

面试回答详解

这道题的核心不是“会不会调用模型”，而是能否把 Nuxt 的页面和 Nitro 服务端能力放进 AI 应用的完整闭环：输入、上下文、模型或工具、流式结果、持久化、权限、观测和失败恢复。

1. 问题边界

考察 AI 功能发布中的 Prompt、模型、工具和前端版本协同。 一次性全量发布简单但风险集中，灰度增加配置和观测复杂度；AI 质量指标滞后，必须结合技术指标和业务反馈。

2. 核心链路

candidate config -> offline eval gate -> canary cohort -> online quality/cost/error metrics -> expand or rollback; run records preserve all version ids。

用户交互 -> Nuxt 客户端状态 -> Nitro/BFF -> AI 编排
        -> 模型/RAG/工具 -> 结构化或流式结果
        -> 持久化、观测、评估和恢复

3. Nuxt 项目落地

发布记录 releaseId、promptVersion、model、toolVersion 和 feature flag，异常按 cohort 对比，回滚不能只切前端而忽略缓存和后台任务。

• 服务端边界：模型密钥、provider 选择、权限、工具执行和成本控制放在服务端；客户端只拿到最小必要结果。
• 状态边界：区分页面状态、会话状态、run 状态和持久化数据，避免刷新、重连或多标签页时串话。
• 协议边界：流式事件、结构化输出和错误响应要有版本化契约，不能让组件猜测 provider 的原始格式。
• 安全边界：用户输入、RAG 文档、工具结果和模型输出都可能不可信，必须做权限、校验、脱敏和审计。

4. 工程取舍

一次性全量发布简单但风险集中，灰度增加配置和观测复杂度；AI 质量指标滞后，必须结合技术指标和业务反馈。

成熟答案要明确哪些工作适合同步请求，哪些必须进入队列或工作流；哪些数据可以缓存，哪些属于用户私有数据；哪些失败可以重试，哪些副作用只能人工恢复。

5. 生产风险与验证

发布记录 releaseId、promptVersion、model、toolVersion 和 feature flag，异常按 cohort 对比，回滚不能只切前端而忽略缓存和后台任务。 方案上线前至少覆盖正常、超时、限流、断流、取消、重复请求、权限变化、provider 故障和版本回滚。用 trace、指标、评估集、组件测试和 E2E 验证，不把“本地能显示回答”当作完成。

可直接背诵的 30 秒回答

我会先把 AI 功能拆成输入、上下文、模型或工具、结果传输、持久化和观测几层。AI 发布单元不只是前端 bundle，还包括 Prompt、模型路由、工具 schema 和评估集版本；灰度按用户或租户进行，指标恶化时可以独立回滚策略和前端版本。 在 Nuxt 中，页面负责交互和状态展示，Nitro 负责鉴权、模型代理、流式协议和服务端数据访问，长任务进入可恢复的任务系统。最后我会补齐权限、成本、失败恢复、评估和灰度回滚，确保它不只是一个 Demo。

扩展知识

AI 应用通用链路

Auth -> Input Validation -> Context/RAG -> Model/Tool
     -> Stream/Structured Output -> Persistence -> Trace/Evaluation

Nuxt 中常见的职责分配

• 页面与 composable：输入、消息列表、连接状态、重试、取消和可访问反馈。
• Nitro server/api：认证、限流、模型代理、流式协议、数据访问和错误归一化。
• 后台任务：文档索引、批量生成、长 Agent、转码和重试。
• 外部系统：模型 provider、向量库、对象存储、队列、数据库和观测平台。

常见误区

• 把 AI SDK 或模型 SDK 直接导入 Vue 页面，泄露密钥和业务边界。
• 只实现 token 流，不处理断开、取消、重复、乱序和最终一致性。
• 把 RAG 文档、工具结果和用户记忆当成可信指令。
• 只看回答是否“看起来不错”，没有 Prompt/模型/检索/工具版本和评估集。

面试官追问链

追问一：Prompt 回滚为什么可能需要清缓存？

• 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
• 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

追问二：如何定义 AI 功能的门禁指标？

• 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
• 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

追问三：灰度期间用户看到不同回答如何解释？

• 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
• 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

推荐阅读

• ../advanced/11-nuxt-如何设计灰度发布feature-flag-和-ssr-一致性-interview
• ../../agent/engineering/ai-application-testing-evaluation-interview.md
• Nitro 官方文档