生产级 AI 应用连环追问专题

定位｜ 本专题把“输入、幻觉、依据、数据库、业务接口、结构化输出、兜底、日志、成本”组织成一套可连续口述的面试回答。它是面试训练入口，不替代已有的系统设计、Agent 工程和 AI Engineering 正式主题。

1. 面试结论

1.1 30 秒专业短答

生产级 AI 应用不能只关注模型能否回答，而要把一次请求拆成“入参校验 → Prompt 构造 → 模型推理 → 结果校验”四个可观测、可失败、可降级的阶段。每一阶段都要定义输入输出契约、Deadline、错误分类和终止状态，Trace 串联证据、工具、模型与版本。我的原则是让模型负责理解与表达，让确定性服务负责权限、事实、校验、审计和最终验收。

1.2 面试官为什么问

这组追问在区分两类候选人：一类只做过模型 API Demo；另一类能把概率模型放进真实业务系统，并处理数据真值、外部副作用、故障恢复、可观测和成本约束。

2. 这九问是否层层递进

**整体递进，但不是九个完全串行的步骤。**更准确的结构是“四层主链路 + 两条治理平面”：

层次	对应追问	核心问题
输入治理	用户输入是否完整	系统是否真正理解任务和约束
可信生成	是否幻觉、回答是否有依据	结论是否被可验证证据支持
工具执行	能否查数据库、调用业务接口	能否安全获得实时真值并执行动作
输出治理	能否结构化、失败如何兜底	下游能否稳定消费，异常能否收敛
可观测平面	日志如何追踪	每一步是否可定位、可重放、可审计
经济性平面	成本如何控制	在质量门禁内，单位成功任务是否可持续

自然过渡可以这样说：

用户说清楚了吗？说清楚后模型就一定正确吗？如果可能出错，依据从哪里来？静态资料不够时，怎样获得实时业务真值？工具执行后怎样稳定交付？外部依赖失败怎么办？失败怎样定位？整条链路可靠以后，成本是否可接受？

3. 小白先这样理解

3.1 场景：公司前台受理一笔退款

小林来到公司前台说“帮我把昨天那单退掉”。前台不会立刻操作：先确认订单号、退款原因和本人身份；经办人即使听懂了，也要查订单和支付记录，不能凭记忆判断；真正退款要走有权限、可审计的业务窗口；完成后开标准回执。系统故障时先查询退款状态，不能盲目再退一次；整张工单保留流水号，财务还会统计一次成功退款花了多少处理成本。

3.2 技术映射

生活场景	技术对象
核对订单号、身份和原因	输入 Schema、业务规则和澄清
经办人可能记错	模型幻觉和不确定性
查订单、支付记录	RAG、只读数据库或查询 API
有权限的退款窗口	受控业务接口、授权和人工确认
标准回执	结构化输出和服务端校验
先查状态再决定是否重试	错误分类、幂等、对账和补偿
工单流水号	`trace_id`、审计日志和版本指纹
财务核算	单次成功任务成本和预算门禁

3.3 类比边界

真实 AI 系统可能同时调用多个模型、检索通道和外部服务，错误也不只来自某个“经办人”。人工确认不能替代权限校验，幂等不能自动保证跨系统事务，日志存在也不代表结论正确；最终仍要用评测集、契约测试、故障演练和业务指标验证。

4. 两幅图看懂完整链路

4.1 `gpt-image-2` 教学图

图：教学图｜生产级 AI 应用九层可信防线

替代文本： 用户请求从左到右经过输入完整、幻觉风险、证据依据、数据库、业务接口、结构化输出和失败兜底七个关卡；日志追踪位于上方、成本控制位于下方，作为横跨主链路的治理能力。

生产级 AI 应用九层可信防线

读图结论： 前七层解决一次请求怎样可信完成，日志与成本解决整条链路怎样被持续治理；不能把九问理解成九个互不相干的功能点。

本图使用 gpt-image-2 生成，并人工检查了中文标题、九个标签、编号顺序和主方向。图片负责建立空间直觉；权限条件、重试语义和失败分支以正文和下面的 Mermaid 为准。

4.2 Mermaid 调用流程

图：技术调用流程｜从输入澄清到证据化交付与失败收敛

替代文本： 请求先经过入参校验，缺少关键字段时澄清；完整请求按事实时效性访问知识库、只读数据库或业务接口，再在 Token 预算内构造 Prompt。模型超时、上下文超限或输出校验失败都进入统一错误分类，最终返回成功、部分结果、需澄清或失败状态；Trace 和成本预算横跨各阶段。

图表加载中…

读图结论： 入参、Prompt、推理和结果不是一个不可分的“模型调用”；它们是四个独立故障边界，必须由确定性运行时统一控制并共享 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 和成本预算必须在设计阶段进入主链路。

6.3 CSGO 饰品智能平台的 2 分钟项目化回答

在 CSGO 饰品智能平台里，我不会把一次问答当成“拼个 Prompt 调模型”，而是拆成四个独立故障边界。第一步是请求入参：服务端校验用户身份、意图、饰品实体、币种、时间范围和 Deadline。“龙狙多少钱”如果缺少可唯一映射的饰品名或价格口径，就进入澄清，不让模型自己猜。
第二步是 Prompt 构造：稳定的饰品知识和交易规则走 RAG，当前行情和个人库存走受控 API，再将引用、报价和不确定性组成结构化 Evidence Pack。构造时做 ACL、去重、新鲜度、证据冲突和 Token 预算检查；证据不足就澄清或拒答，报价过期就重查工具，不把历史向量当实时价格。
第三步是模型推理：统一网关传递剩余 Deadline，区分限流、网络瞬断、服务端错误和上下文超限。只有明确的瞬时且无副作用错误才在 Retry Budget 内退避重试；预算不足时降级候选模型或返回部分结果，不无限重试。
第四步是结果校验：先验 JSON Schema，再验饰品身份、引用支持、权限和价格语义。价格回答至少要有 amount、currency、as_of、source 和 quote_id；工具失败时不能生成“查询成功”。最终只返回 success、partial、need_clarification 或 failed，并用同一个 trace_id 记录入参摘要、Prompt/模型/索引版本、证据 ID、工具状态、阶段耗时、重试和降级原因。

CSGO 链路的异常处理可以用下表快速复习：

阶段	典型异常	确定性处理	用户可见结果	关键 Trace 证据
请求入参	缺少饰品身份、币种冲突、越权库存范围、请求过大	Schema + 业务规则 + ACL；可修正字段归一化，关键缺失则澄清，越权 Fail Closed	`need_clarification` 或 `failed`	脱敏入参摘要、Principal、校验错误码
Prompt 构造	RAG 无证据、报价过期、多源价格冲突、Context 超预算	重查实时工具、按优先级裁剪、保留冲突和不确定性；无安全证据则拒答	`partial` 或 `need_clarification`	候选与最终 Evidence ID、新鲜度、截断原因、Prompt 版本
模型推理	429、5xx、超时、流式中断、上下文超限	剩余 Deadline + Retry Budget；仅瞬时错误有限重试，再按能力契约降级模型或停止	`partial` 或 `failed`	模型、供应商 request ID、尝试次数、Token、各次耗时
结果校验	JSON 不合法、引用不支持结论、报价缺币种或时间、工具失败却声称成功	服务端 Schema + 语义断言 + 引用检查；最多一次受限修复，仍失败则拒答	`partial`、`need_clarification` 或 `failed`	原始输出脱敏哈希、校验错误码、修复次数、最终状态

证据边界： 简历已能确认多平台数据接入、RAG 与实时接口分流、文档解析到 Rerank 的检索链路，以及检索来源、工具调用和接口耗时记录。上表中的错误矩阵是基于这些事实补齐的生产设计与故障演练口径；在没有代码、Trace 和故障注入证据前，面试中应说“我会这样设计和验证”，不能说成已在线上稳定运行。

6.4 CSGO 中什么是稳定知识，什么是实时信息

30 秒项目回答： 我不会只按“变化快慢”分类，而是同时看时效性、精确性、用户作用域和权威数据源。饰品术语、属性解释、收藏品背景和交易规则等可版本化、可引用的内容属于稳定知识，适合走 RAG；当前挂牌价、求购价、库存、交易锁和订单状态属于实时业务事实，必须走受控 API 或 SQL 并带来源和时间。如果一个问题同时问“为什么值得买”和“现在多少钱”，就并行获取 RAG 知识与实时报价，最后在 Evidence Pack 中合并。

分类	CSGO 典型内容	权威来源与获取方式	回答时的必要证据
稳定解释性知识	磨损等级、稀有度、涂装、收藏品、贴纸等术语解释；饰品选择方法；版本化的平台规则与 FAQ	版本化文档、官方资料或经审核的知识库，通过 RAG 检索	`document_id`、来源、版本、生效时间和引用位置
慢变但需权威的配置或主数据	饰品规范名、跨平台别名映射、当前费率规则、支持币种、平台状态	配置中心、主数据库或业务 API；解释文本可同步进 RAG，但计算以当前配置为准	配置版本、`effective_at`、映射 ID 与数据来源
实时市场信息	当前挂牌价、求购价、成交价、深度、成交量、汇率和市场可用性	行情服务、交易平台 API 或行情快照库，按请求查询	`amount`、`currency`、`as_of`、`source`、`quote_id` 和新鲜度状态
当前用户与交易状态	个人库存、`steam_id + assetid`、具体资产磨损与贴纸、可交易状态、交易锁到期时间、挂售或订单状态	带 Principal 和 ACL 的库存、交易或订单 API；不从长期 Memory 或向量库恢复为当前事实	用户作用域、资产 ID、状态版本、查询时间与工具状态

更准确的分流判断是：

问“是什么、为什么、怎么理解”，且允许引用某个已知版本，优先走 RAG；
问“现在、我的、多少钱、能否交易、订单怎么样”，必须走实时工具；
要求精确数字或结构化历史事实，即使该事实已不再变化，也应查 SQL/API 或数据仓库，不让向量检索猜精确值；
混合问题分路执行：知识检索负责解释，实时工具负责当前真值，最终回答必须分别带引用和报价时间。

类比边界： 稳定知识像饰品百科，实时信息像交易所行情屏；但“已定格的历史价格”虽然不再变化，仍然应从行情库精确查询，不能因为它“稳定”就放进 RAG 作为数字真值。

6.5 意图识别要部署小模型，还是直接调 LLM

30 秒项目回答： CSGO 意图识别不建议一开始就为了技术栈单独部署小模型。我会先用规则和实体槽位承接“价格、库存、订单、知识”等高置信 Fast Path，歧义、多意图和复合任务再让 LLM 输出可校验的结构化路由。当真实请求量、标注样本、成本或延迟已经证明 LLM 路由成为瓶颈时，再把已稳定的高频意图下沉到小分类模型，低置信样本继续回退 LLM 或追问用户。

CSGO 意图不应只设计一个单选标签，至少要支持：

knowledge_qa：饰品术语、规则、收藏品与选择方法；
realtime_price：当前挂牌、求购、成交和多平台比价；
user_inventory：当前用户库存、具体资产和可交易状态；
historical_market：历史价格、成交量和趋势结构化查询；
mixed_analysis：同时需要 RAG 知识和实时或历史数据；
high_risk_action：挂售、购买或交易等高风险动作，必须再进行权限、幂等和人工确认。

方案	优点	缺点与风险	CSGO 适用条件	结论
确定性规则 + 实体槽位	延迟低、无模型调用成本、可解释、易测试	口语、省略、指代和多意图容易漏判，规则过多后维护成本上升	“现在多少钱”“查我的库存”等高置信请求	作为第一层 Fast Path，不单独承担全部路由
直接调 LLM 做结构化路由	几乎不需要训练数据，能处理口语、上下文、多意图和新表达	增加延迟、Token 成本和外部依赖；输出存在随机性，不能决定最终权限	交易量尚未证明需要专用模型，或意图仍快速变化的早期阶段	现阶段作为歧义与混合问题的主路由器，必须结构化输出并由代码复核
自部署小分类模型	单次推理延迟和边际成本可更低，版本固定时输出更稳定，可在内网运行	需要标注集、训练/评测、服务部署、容量与漂移监控；新意图和复合表达需重新适配	高频、标签稳定、已有代表性标注数据，且低延迟、隐私或单位成本目标明确	作为第二阶段优化，必须先证明收益大于模型运维成本

推荐的路由顺序是：

text

确定性安全与硬规则
→ 高置信关键词/实体 Fast Path
→ LLM 结构化多意图分类
→ 服务端 Schema、ACL 和风险规则复核
→ RAG、行情、库存、历史数据或人工确认链路

LLM 路由结果可以统一为：

json

{
  "intents": ["knowledge_qa", "realtime_price"],
  "entities": {"market_hash_name": "待规范化饰品名"},
  "required_sources": ["rag", "market_api"],
  "risk": "read_only",
  "needs_clarification": false
}

confidence 不建议直接使用模型自述的“我有 90% 把握”。应在固定标注集上按意图类型计算 Precision、Recall、F1、混淆矩阵和误路由成本，再校准分流阈值。小模型上线前应先影子运行，与当前 LLM/规则路由结果对比；权限、交易风险和高风险动作继续由确定性代码判断，不论用哪种模型都不能越过。

证据边界： 当前仓库能证明 CSGO 平台需要在稳定知识、实时价格、用户库存和复合问题之间分流，但尚没有可核验的真实请求量、意图标注集、路由延迟和成本对比。因此现阶段只能推荐“规则 + LLM 结构化路由”作为可验证基线，不能声称已证明自部署小模型更优。

6.6 Query 是否重写，以及关键词是否需要分词

30 秒项目回答： 意图识别前可以做轻量规范化，但不要先把 Query 大幅改写，否则“现在、我的、挂售”等决定实时性、用户作用域和风险等级的信号可能被改丢。我会保留 raw_query，用规范化文本、会话摘要和实体结果共同识别多意图；意图确定后，再分别为 RAG 生成检索 Query、为行情或库存工具生成结构化参数。关键词分词不是所有链路的必选项：规则和 BM25 需要词法处理，LLM 与向量检索不要求业务层先分词，但饰品规范名、别名、编号和 market_hash_name 必须优先做词典与实体匹配。

三种容易混淆的处理应分开：

处理	时机	可以做什么	不能做什么
输入规范化 `normalized_query`	意图识别前	Unicode/全半角统一、空白清理、大小写与常见币种写法归一、明显错别名映射	删除“现在、我的、不要、挂售”等语义和风险信号
意图与实体解析	规范化之后	结合原始 Query、有限会话上下文、实体字典识别多意图、资产、时间和用户作用域	只返回一个标签，或让模型直接决定 ACL 和交易权限
下游 Query 构造	意图确定后	RAG 扩展术语和别名；API 组装类型化参数；混合问题拆成多个子查询	用一个被改写的自然语言 Query 同时代替检索词、行情参数和库存身份

例如用户问“我这把蝴蝶 P2 现在值多少，为什么这么贵”：

原始文本必须保留“我”“现在”“为什么”，它们分别表示私有库存、实时行情和知识解释；
实体解析把“蝴蝶 P2”规范到候选 market_hash_name，无法唯一确定时先澄清；
意图输出为 user_inventory + realtime_price + knowledge_qa；
RAG 子查询可改写为“蝴蝶刀多普勒 Phase 2 稀有度与价格影响因素”；
行情与库存不依赖这句检索文本，而使用 steam_id + assetid、规范饰品 ID、币种和报价新鲜度等结构化参数。

下面的伪代码体现了“先保真分流，再按数据源改写”的边界：

python

def recognize_and_route(request):
    raw = validate_and_trim(request.query)
    context = load_bounded_context(request.session_id)

    # 只做不改变语义的规范化；raw 永远保留，便于审计和回放。
    normalized = normalize_text(raw)
    entities = entity_resolver.match(
        raw_query=raw,
        normalized_query=normalized,
        dictionaries=[item_aliases, market_hash_names, currencies, time_terms],
    )

    # 权限、提示注入和交易动作属于确定性安全判断，不交给分类模型。
    safety = deterministic_safety_check(raw, request.principal)
    if safety.blocked:
        return RouteResult(status="failed", reason=safety.reason)

    # 精确规则只承接无歧义 Fast Path，例如“查我的库存”或“XX 现在多少钱”。
    fast = rule_router.match(raw, normalized, entities, context)
    if fast.is_exact and not fast.has_multiple_meanings:
        intents = fast.intents
    else:
        candidate = llm_route_with_schema(
            raw_query=raw,
            normalized_query=normalized,
            context_summary=context.summary,
            recognized_entities=entities,
            allowed_intents=ALLOWED_INTENTS,
        )
        intents = validate_and_merge_route(candidate, fast, safety)

    missing = required_slots(intents) - entities.confirmed_slots
    if missing:
        return RouteResult(
            status="need_clarification",
            missing_slots=missing,
            raw_query=raw,
        )

    tasks = []
    if "knowledge_qa" in intents:
        tasks.append(RAGTask(
            query=rewrite_for_retrieval(raw, context, entities),
            lexical_terms=extract_exact_terms(raw, entities),
        ))
    if "realtime_price" in intents:
        tasks.append(PriceAPITask(
            item_id=entities.item_id,
            currency=entities.currency or request.default_currency,
            max_quote_age_seconds=PRICE_FRESHNESS_SLO,
        ))
    if "user_inventory" in intents:
        tasks.append(InventoryAPITask(
            principal=request.principal,
            asset_id=entities.asset_id,
        ))

    return RouteResult(
        status="success",
        intents=intents,
        entities=entities,
        tasks=tasks,
        raw_query=raw,
        normalized_query=normalized,
    )

关键词是否需要分词，要看它服务哪一层：

使用位置	是否需要业务层分词	CSGO 项目建议
确定性规则 Fast Path	不一定；短语、正则和实体词典通常更可靠	优先匹配“现在多少钱”“我的库存”“挂售”等短语，以及完整饰品名和 ID
BM25/倒排召回	需要词法分析，但通常由搜索引擎 Analyzer 完成	维护饰品自定义词典、别名和专有短语，避免把完整 `market_hash_name` 错切
Dense Embedding 向量召回	不需要在业务代码中预先分词	将规范化文本直接交给 Embedding 模型；模型内部仍有自己的 Tokenizer
LLM 意图识别	不需要预先分词	输入原始文本、规范化文本、实体和有限上下文，以结构化 Schema 输出多意图
传统小分类模型	取决于特征方案	TF-IDF 需要分词或字符 n-gram；Transformer 分类器使用自己的 Tokenizer

因此不要把“分词”作为整条链路的统一前置步骤。更稳妥的顺序是：保留原文 → 轻量规范化 → 实体/短语识别 → 意图路由 → 按下游分别做词法检索、向量检索或 API 参数组装。评测时至少记录原始与规范化 Query、改写 Query、实体命中、意图、规则版本、Prompt/模型版本和最终数据源，并用固定样本检查意图 F1、实体准确率、改写前后 Recall@K、误路由率以及澄清率。

证据边界： 上述内容是与现有 CSGO RAG、实时工具分流相容的生产设计和伪代码，不代表仓库中已经存在对应实现。是否启用分词器、具体改写策略和阈值，应由真实查询集与离线评测决定。

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 证据；
为一个客服问答任务定义引用支持率和单位成功任务成本，说明分母、统计窗口和失败样本分桶；
为 CSGO 行情问答注入“RAG 无证据、报价 API 超时、模型输出缺少币种”三个故障，验证系统是否返回正确的终止状态并保留 Trace 证据。

10. 相关知识与证据边界

AI 应用系统设计：SLO、模型网关、RAG、Agent、容量与质量闭环；
Prompt 与结构化输出：结构约束、校验、修复与安全边界；
Agent 工程化与安全：权限、幂等、补偿、检查点和审计；
Tool Calling 与工具系统设计：工具契约、授权和副作用；
AI 应用可观测性与 LLMOps：Trace、版本、评测和发布闭环；
缓存、限流与成本治理：成本归因、缓存键、配额和预算；
王佳鹏简历高频面试题一问一答：CSGO 饰品智能平台的 RAG、实时工具、Agent Harness 与证据边界。

证据边界｜ 本文给出框架无关的工程方法和故障演练口径，没有声称某个真实项目已经达到特定正确率、延迟、成本或业务收益。落地时需要用目标系统的代码、权限模型、契约测试、固定评测集、故障注入和线上指标验证。

11. 总结

一句话记忆： 输入要校验，结论要有证据，工具要受控，输出要验证，失败要收敛，全链路要可追踪，成本要按成功任务衡量。

九问可归纳为入参校验、Prompt 构造、模型推理和结果校验四个故障边界，日志与成本是两条横跨主链路的治理平面；
模型负责理解和建议，确定性运行时负责权限、执行、校验、审计与验收；
保留原始 Query，只做轻量规范化后识别意图与实体，再按 RAG、行情或库存数据源分别重写检索词或组装结构化参数；
兜底从错误分类开始，结果未知的副作用先对账，不能盲目重试或伪造成功；
面试回答始终用“判断标准、系统动作、失败边界、验证证据”收口。

生产级 AI 应用连环追问专题 ​

目录 ​

1. 面试结论 ​

1.1 30 秒专业短答 ​

1.2 面试官为什么问 ​

2. 这九问是否层层递进 ​

3. 小白先这样理解 ​

3.1 场景：公司前台受理一笔退款 ​

3.2 技术映射 ​

3.3 类比边界 ​

4. 两幅图看懂完整链路 ​

4.1 gpt-image-2 教学图 ​

4.2 Mermaid 调用流程 ​

5. 九个追问怎么回答 ​

5.1 用户输入是否完整 ​

5.2 模型是否会幻觉 ​

5.3 回答有没有依据 ​

5.4 能不能查数据库 ​

5.5 能不能调用业务接口 ​

5.6 输出能不能结构化 ​

5.7 失败了怎么兜底 ​

5.8 日志怎么追踪 ​

5.9 成本怎么控制 ​

6. 连续口述稿 ​

6.1 60～90 秒版本 ​

6.2 追问时的衔接句 ​

6.3 CSGO 饰品智能平台的 2 分钟项目化回答 ​

6.4 CSGO 中什么是稳定知识，什么是实时信息 ​

6.5 意图识别要部署小模型，还是直接调 LLM ​

6.6 Query 是否重写，以及关键词是否需要分词 ​

7. 工程证据与验收指标 ​

7.1 最小输出契约 ​

7.2 指标口径 ​

8. 高频失分点 ​

9. 自测练习 ​

10. 相关知识与证据边界 ​

11. 总结 ​