外观
生产级 AI 应用连环追问专题
定位｜ 本专题把“输入、幻觉、依据、数据库、业务接口、结构化输出、兜底、日志、成本”组织成一套可连续口述的面试回答。它是面试训练入口，不替代已有的系统设计、Agent 工程和 AI Engineering 正式主题。
目录
- 1. 面试结论
- 2. 这九问是否层层递进
- 3. 小白先这样理解
- 4. 两幅图看懂完整链路
- 5. 九个追问怎么回答
- 6. 连续口述稿
- 7. 工程证据与验收指标
- 8. 高频失分点
- 9. 自测练习
- 10. 相关知识与证据边界
- 11. 总结
1. 面试结论
1.1 30 秒专业短答
生产级 AI 应用不能只关注模型能否回答，而要同时治理输入、事实依据、工具权限、输出契约和运行风险。主链路是“输入校验 → 证据与工具 → 结构化验证 → 结果交付 → 失败兜底”，日志追踪和成本控制贯穿全程。我的原则是让模型负责理解与建议，让确定性服务负责权限、校验、执行、审计和最终验收。
1.2 面试官为什么问
这组追问在区分两类候选人：一类只做过模型 API Demo；另一类能把概率模型放进真实业务系统，并处理数据真值、外部副作用、故障恢复、可观测和成本约束。
2. 这九问是否层层递进
**整体递进，但不是九个完全串行的步骤。**更准确的结构是“四层主链路 + 两条治理平面”：</n+
| 层次 | 对应追问 | 核心问题 |
|---|---|---|
| 输入治理 | 用户输入是否完整 | 系统是否真正理解任务和约束 |
| 可信生成 | 是否幻觉、回答是否有依据 | 结论是否被可验证证据支持 |
| 工具执行 | 能否查数据库、调用业务接口 | 能否安全获得实时真值并执行动作 |
| 输出治理 | 能否结构化、失败如何兜底 | 下游能否稳定消费，异常能否收敛 |
| 可观测平面 | 日志如何追踪 | 每一步是否可定位、可重放、可审计 |
| 经济性平面 | 成本如何控制 | 在质量门禁内，单位成功任务是否可持续 |
自然过渡可以这样说：
用户说清楚了吗？说清楚后模型就一定正确吗？如果可能出错，依据从哪里来？静态资料不够时，怎样获得实时业务真值？工具执行后怎样稳定交付？外部依赖失败怎么办？失败怎样定位？整条链路可靠以后，成本是否可接受？
3. 小白先这样理解
3.1 场景：公司前台受理一笔退款
小林来到公司前台说“帮我把昨天那单退掉”。前台不会立刻操作：先确认订单号、退款原因和本人身份；经办人即使听懂了，也要查订单和支付记录，不能凭记忆判断；真正退款要走有权限、可审计的业务窗口；完成后开标准回执。系统故障时先查询退款状态，不能盲目再退一次；整张工单保留流水号，财务还会统计一次成功退款花了多少处理成本。
3.2 技术映射
| 生活场景 | 技术对象 |
|---|---|
| 核对订单号、身份和原因 | 输入 Schema、业务规则和澄清 |
| 经办人可能记错 | 模型幻觉和不确定性 |
| 查订单、支付记录 | RAG、只读数据库或查询 API |
| 有权限的退款窗口 | 受控业务接口、授权和人工确认 |
| 标准回执 | 结构化输出和服务端校验 |
| 先查状态再决定是否重试 | 错误分类、幂等、对账和补偿 |
| 工单流水号 | trace_id、审计日志和版本指纹 |
| 财务核算 | 单次成功任务成本和预算门禁 |
3.3 类比边界
真实 AI 系统可能同时调用多个模型、检索通道和外部服务，错误也不只来自某个“经办人”。人工确认不能替代权限校验，幂等不能自动保证跨系统事务，日志存在也不代表结论正确；最终仍要用评测集、契约测试、故障演练和业务指标验证。
4. 两幅图看懂完整链路
4.1 gpt-image-2 教学图
图：教学图｜生产级 AI 应用九层可信防线
替代文本： 用户请求从左到右经过输入完整、幻觉风险、证据依据、数据库、业务接口、结构化输出和失败兜底七个关卡；日志追踪位于上方、成本控制位于下方，作为横跨主链路的治理能力。
读图结论： 前七层解决一次请求怎样可信完成，日志与成本解决整条链路怎样被持续治理；不能把九问理解成九个互不相干的功能点。
本图使用 gpt-image-2 生成，并人工检查了中文标题、九个标签、编号顺序和主方向。图片负责建立空间直觉；权限条件、重试语义和失败分支以正文和下面的 Mermaid 为准。
4.2 Mermaid 调用流程
图：技术调用流程｜从输入澄清到证据化交付与失败收敛
替代文本： 请求先经过输入校验，缺少关键字段时澄清；完整请求进入模型规划，并按需访问知识库、只读数据库或业务接口。证据绑定后进行结构化校验，失败进入错误分类、有限重试、降级或人工处理；Trace 和成本预算横跨各阶段。
图表加载中…
读图结论： 模型只负责理解与规划；数据访问、权限、执行、校验和失败收敛必须由确定性运行时控制，且所有阶段共享同一个 Trace 与预算上下文。
5. 九个追问怎么回答
每一问都用同一结构回答：判断标准 → 系统动作 → 失败边界 → 验证证据。
5.1 用户输入是否完整
我不会让模型凭感觉判断完整性，而会先定义必填、可选和可推导字段。类型、范围和枚举由 Schema 校验，意图冲突、时间范围和业务前置条件由业务规则校验；关键字段缺失就追问，非关键字段只能使用可解释的显式默认值。验证时看无效输入拦截率、澄清率和误澄清率。
5.2 模型是否会幻觉
会，而且不能承诺彻底消除。除了事实幻觉，还要防引用幻觉、工具参数幻觉和“接口失败却声称成功”的结果幻觉；我会通过证据约束、服务端校验、拒答策略和固定评测集降低并发现它，而不是只依赖 Prompt。
5.3 回答有没有依据
依据要与关键结论绑定。稳定知识来自版本化知识库或权威资料，实时业务真值来自受控 SQL 或 API；证据不足时返回不确定或请求补充信息。验收不能只看答案流畅度，还要看正确性、引用支持率和无依据断言率。
5.4 能不能查数据库
可以，但模型不直接持有数据库凭据，也不自由执行任意 SQL。查询通过服务端工具完成，使用只读账号、租户与行级权限、参数化模板、表字段白名单、行数限制、超时和审计；涉及业务规则或写入时优先走业务 API。
5.5 能不能调用业务接口
可以，但必须把接口封装为类型化工具，定义参数、鉴权、超时、错误码和返回契约。查询接口可按错误类型有限重试；有副作用的写操作需要幂等键、状态校验和必要的人工确认，超时后先对账，不能直接重复执行。
5.6 输出能不能结构化
可以使用原生 Structured Output 或 Tool Calling 约束结构，但模型生成的结构仍不可信。服务端必须再次做 JSON Schema、字段语义和业务规则校验；失败时最多有限修复，仍失败就返回明确错误或降级结果，不能把“看起来像 JSON”当作契约通过。
5.7 失败了怎么兜底
我先区分可重试、不可重试和结果未知。瞬时网络错误可以限次退避重试；参数、权限和安全错误不能原样重试；结果未知的写操作先用幂等键对账。之后再选择备用模型或数据源、部分回答、明确拒绝或人工接管，任何情况下都不伪造成功。
5.8 日志怎么追踪
我会用统一的
trace_id或run_id串联输入校验、模型、检索、数据库和 API。Trace 至少记录输入脱敏摘要、模型与 Prompt 版本、证据 ID、工具参数摘要、状态码、耗时、重试、Token、成本和最终状态；密钥和敏感原文不能进入普通日志。
5.9 成本怎么控制
我关注的是单位成功任务成本，不只是单次模型价格。先按步骤归因 Token、检索、工具和人工成本，再通过大小模型路由、缓存、上下文裁剪、输出上限、批处理和预算门禁优化；所有降本都要经过正确性、工具成功率和人工接管率等质量门禁。
6. 连续口述稿
6.1 60～90 秒版本
我把这组问题理解为生产级 AI 应用的完整治理链路。入口先用 Schema 和业务规则判断必填字段、冲突和前置条件，关键内容缺失就澄清；即使输入完整，模型仍可能产生事实、引用、参数和执行结果幻觉，所以关键结论必须绑定知识库、只读数据库或业务 API 的证据。数据库和接口都通过受控工具访问，服务端负责权限、白名单、超时、幂等和必要确认。输出使用 Structured Output，但仍需服务端校验。失败时按可重试、不可重试和结果未知分类，再进行有限重试、对账、降级或人工接管。全链路用同一个 Trace 记录版本、证据、工具、耗时和错误，成本则按单位成功任务统计，并在质量门禁内用路由、缓存和上下文预算优化。
6.2 追问时的衔接句
- 输入完整以后，下一步不是直接生成，而是判断答案需要什么证据；
- 有证据不代表可以任意访问数据，数据库和接口还要受权限与副作用边界约束；
- 工具调用成功不代表结果可交付，仍要经过结构和业务语义校验；
- 外部依赖必然失败，所以兜底、Trace 和成本预算必须在设计阶段进入主链路。
7. 工程证据与验收指标
7.1 最小输出契约
json
{
"status": "success | partial | need_clarification | failed",
"answer": "面向用户的结果",
"evidence_ids": ["doc:policy-v3", "order:masked-id"],
"tool_runs": [{"name": "query_order", "status": "success"}],
"uncertainties": [],
"trace_id": "run_xxx"
}这个 Schema 只说明结果形状。evidence_ids 是否真正支持结论、工具是否越权、业务状态是否成功，仍需确定性代码和评测验证。
7.2 指标口径
| 环节 | 推荐指标 | 口径提醒 |
|---|---|---|
| 输入 | 无效输入拦截率、澄清率、误澄清率 | 按任务类型和必填字段缺失原因分桶 |
| 依据 | 引用支持率、无依据断言率 | 逐条检查关键结论是否被证据支持 |
| 工具 | 调用成功率、越权阻断率、结果未知率 | 查询和写操作分开统计 |
| 输出 | Schema 首次通过率、修复率 | “可解析”不等于业务语义正确 |
| 兜底 | 降级率、人工接管率、恢复成功率 | 区分主动降级和故障降级 |
| 观测 | Trace 完整率、版本指纹覆盖率 | 能否重放和解释失败比“有日志”更重要 |
| 成本 | 单位成功任务成本 | 总成本 / 通过成功标准的任务数 |
8. 高频失分点
| 失分回答 | 问题 | 更好的表达 |
|---|---|---|
| “优化 Prompt 就不会幻觉” | 混淆降低概率与消除风险 | 证据约束、校验、评测和拒答共同治理 |
| “让模型生成 SQL 直接查询” | 忽略凭据、ACL、注入和资源风险 | 只读受控工具、参数化模板、白名单和审计 |
| “接口失败就重试三次” | 没有错误分类，写操作可能重复 | 可重试才退避；结果未知先对账 |
| “要求模型返回 JSON” | Prompt 不是输出契约 | 原生结构约束加服务端 Schema 与语义校验 |
| “所有调用都记录日志” | 没有 Trace、版本和隐私边界 | 统一 Run 关联，记录必要证据并脱敏 |
| “换便宜模型降成本” | 忽略任务成功率和返工 | 按单位成功任务成本，并设置质量门禁 |
9. 自测练习
- 用 90 秒完整口述九问，要求每一层都包含一个确定性控制点；
- 设计一次“退款 API 超时但实际已成功”的故障演练，写出对账、幂等、补偿和 Trace 证据；
- 为一个客服问答任务定义引用支持率和单位成功任务成本，说明分母、统计窗口和失败样本分桶。
10. 相关知识与证据边界
- AI 应用系统设计：SLO、模型网关、RAG、Agent、容量与质量闭环；
- Prompt 与结构化输出：结构约束、校验、修复与安全边界；
- Agent 工程化与安全：权限、幂等、补偿、检查点和审计；
- Tool Calling 与工具系统设计：工具契约、授权和副作用；
- AI 应用可观测性与 LLMOps：Trace、版本、评测和发布闭环；
- 缓存、限流与成本治理：成本归因、缓存键、配额和预算。
证据边界｜ 本文给出框架无关的工程方法和故障演练口径，没有声称某个真实项目已经达到特定正确率、延迟、成本或业务收益。落地时需要用目标系统的代码、权限模型、契约测试、固定评测集、故障注入和线上指标验证。
11. 总结
一句话记忆： 输入要校验，结论要有证据，工具要受控，输出要验证，失败要收敛，全链路要可追踪，成本要按成功任务衡量。
- 九问是四层主链路与日志、成本两条治理平面，不是九个孤立功能；
- 模型负责理解和建议，确定性运行时负责权限、执行、校验、审计与验收；
- 数据库优先只读受控查询，业务写操作优先走带鉴权、幂等和确认的 API；
- 兜底从错误分类开始，结果未知的副作用先对账，不能盲目重试或伪造成功；
- 面试回答始终用“判断标准、系统动作、失败边界、验证证据”收口。