动手实战 · 从能跑的 Demo 到能用的产品
实战 · 从 Demo 到产品 · 30 道灵魂拷问
每题附考察意图、答题框架与加分点：Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单
本页解决的问题
先给结论「实战 · 从 Demo 到产品 · 30 道灵魂拷问」要解决的关键问题是什么？
每题附考察意图、答题框架与加分点：Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单
判断标准
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
下一步
写下一个问题：试完这个方法后，你能用什么证据回答它？
常见误区
结论听起来很完整，却没有检查最关键的假设。
怎么用这一页
每道题都标注了提问者。他们问同一块知识，想听的东西却不一样。
🎙 面试官想验证你是真做过，还是只看过 Demo
👔 老板要的是解释、方案和一个能兑现的承诺
🛠 技术同事在试探你会画多大的饼、懂多少代价
每题给出三层：对方在考察什么 → 答题框架 → 加分点。答不上来的环节，点末尾的课程页回去补。
Q1面试官
「假设你们团队一天就调通了生图 API，Demo 演示效果很好。你觉得离真正上线还差多远？差在哪？」
🎯 对方在考察什么
这是判断你有没有真的把 AI 功能推上线过的分水岭题。只玩过 Demo 的人会说「再打磨一下就能上」；上过线的人知道，调通 API 只是 10%，剩下 90% 全是产品化工作，能一条条数出来。
🧭 答题框架
- 先给结论：调通 API 只是 10%。真实案例里从调通到上线花了三个月，差的东西可以按四个维度盘点。
- 体验层：生成进度反馈、失败一键重试、多张结果供选择、历史记录可回看。Demo 里用户干等 30 秒没人管，产品里不行。
- 质量层与工程层：质量靠 Prompt 优化（用 LLM 把用户的人话翻译成生图模型能懂的描述）加角色一致性锚定；工程靠多模型降级链、超时重试、成本限额、结果持久化。模型一定会挂，挂了之后的体验才是产品。
- 安全层：输入输出双重内容审核、版权风险、用户参考图的隐私策略。Demo 可以裸奔，产品裸奔会出事故。
⭐ 加分点点一句这张清单的通用性：换成任何 AI 功能，从 Demo 到 Production 都是体验、质量、工程、安全四个维度。面试官听到你有方法论，比听到你背清单印象深得多。
Q2老板
「用户反馈说 Agent 转了半个小时还没停，最后啥也没给出来。怎么回事？你打算怎么让这种事以后别再发生？」
🎯 对方在考察什么
老板要的是根因解释加防护承诺，两样都要。只会说「模型抽风了」的人露馅：说明你既讲不清卡死的模式，也拿不出让它自己停下来的机制。答「我让技术加个超时」也只算半分，那只是最粗的一层。
🧭 答题框架
- 先解释根因：生产环境的 Agent 卡死有四种典型模式：同参数死循环（反复用相同参数调同一工具）、收益递减（跑了 50 轮全是边缘动作）、文本复读（上下文过长后开始车轱辘话）、工具连续失败雪崩（一个工具挂了拖垮整条链路）。先定位这次是哪种。
- 给防护方案：防呆是三层网。硬限制兜底：迭代上限、总超时、单工具调用次数上限，无条件刹车。检测预警：同参数检测、同工具名检测、收益递减检测，发现异常模式就上报。
- 降级续命：检测到异常先温柔纠正，注入一条「你已经重复了 3 次，请换一种方法」的提示、暂时禁用故障工具、强制总结当前进度带着半成品返回。对用户来说，带着半成品回来比空手而归好得多。
- 补体验层承诺：就算 Agent 在跑长任务，用户也要看到进度感，展示当前在做什么，可以随时手动停止。用户骂的其实是「等了半小时还不知道它在干嘛」。
⭐ 加分点补一句「用户从来不会报告 Agent 死循环了，他只会说这 AI 怎么这么慢、这么蠢」。能把技术故障翻译成用户视角，老板会觉得你是能兜住这件事的人。
Q3面试官
「你们的 AI 助手对话越长越贵、越长越笨。上下文压缩你会怎么设计？什么能删、什么绝对能不动？」
🎯 对方在考察什么
考你有没有一套压缩的决策框架，以及知不知道那条红线。答「找个模型做摘要就行」的人露馅了：既没算过摘要本身的成本，也没意识到删错东西的后果是用户当场发现「我明明说过，你怎么忘了」。
🧭 答题框架
- 先说为什么必须压：每一轮对话都要把全部历史重新发给模型。对话越长，费用越高、注意力越分散、离窗口上限越近，三个问题逼着你管理上下文。
- 给分级框架：可以删的：旧的工具调用结果、已处理完的中间步骤。可以压缩的：AI 的长篇回复、搜索结果，压成一句摘要。绝对能不动的：用户的原始消息、System Prompt、关键偏好设定。
- 点出红线：用户的话是圣物。宁可删 AI 自己说的 1000 字，也别动用户说的 10 个字。压缩优先级从高到低：工具输出、AI 回复、用户消息永不触碰。
- 说清手段的成本：本地压缩（截断、规则替换）零成本但粗糙，LLM 摘要精准但本身要花钱。正确顺序是先免费后花钱：先用本地手段砍掉明显的废话，剩下的再考虑 LLM 摘要。
⭐ 加分点主动提用户体感：压缩做得好用户毫无感知，做得差用户会觉得 AI「失忆」了。把压缩当成一个体验指标去做评测，超越纯粹的省钱视角，这个角度很少有人给。
Q4面试官
「产品要做『让 AI 记住用户』。你打算怎么设计这套记忆系统？所有对话都存下来吗？用户改了主意怎么办？」
🎯 对方在考察什么
连环三问，考你对记忆系统的完整设计能力：存什么、怎么更新、怎么用。把「记忆」和「上下文」混为一谈的人第一句就露馅；说「全存下来慢慢查」的人，在成本和噪声这关也过不去。
🧭 答题框架
- 先分清两套系统：上下文窗口是白板，写满就擦、对话结束就清空；长期记忆是笔记本，写下的东西下次打开还在。做记忆功能的前提是承认白板靠不住。
- 设计守门员：用户每天几十上百条消息，「嗯」「好的」「哈哈」占大半，值得记的偏好和事实只有几条。写入前要有一层筛选逻辑，判断这条信息有没有长期价值。
- 处理记忆冲突：用户上月说喜欢咖啡、这月说改喝茶了，四种策略按场景选：明确替换就覆盖更新；信息互补就合并扩展；无法确定谁对就标记冲突待确认；临时状态（最近太累总睡懒觉）直接跳过不存。
- 算注入的账：记了 1000 条，每次全塞进 System Prompt 简单但贵且噪声多，按需检索省钱但可能漏。要按记忆规模和场景选注入策略，这是个成本决策。
⭐ 加分点点出「记忆系统的核心能力是更新，光会追加的记忆系统用两个月就变成谣言库」。大部分人只设计了写入，没设计过期和纠错。
Q5技术同事
「你 PRD 里写了要上多 Agent 协作，还画了个挺酷的架构图。咱们真需要这么多 Agent 吗？一个搞不定吗？」
🎯 对方在考察什么
技术同事在试探你是真想清楚了还是在追热点。多 Agent 意味着更多协调成本、更多出错可能，他们要为这些复杂度买单。答不出「为什么一个 Agent 做不到」，这个需求大概率会被打回来。
🧭 答题框架
- 先认账：默认立场就是一个 Agent 够用，很多所谓需要多 Agent 的场景，其实是 Prompt 没写好。加第二个 Agent 之前要过三问：一个真做不到吗？复杂度值得吗？有没有更简单的方案（比如工具并行调用）？
- 给三种真需要的场景：并行加速，5 个来源同时搜比串行快 5 倍；角色分工，Writer 写、Reviewer 审，角色隔离让审查真正有效；风险隔离，子 Agent 解析 PDF 失败了只汇报「这个文件有问题」，主任务不受影响。
- 对号入座：回到 PRD 里的具体场景，说清它命中的是哪一种。命中了就保留，没命中就当场砍掉，这比守着架构图硬辩好看得多。
- 展示并发常识：就算上了多 Agent，也要懂「看」可以并行、「改」必须排队。判断一个操作能否并发，关键就一条：它是只读的吗？
⭐ 加分点主动说「如果这三种场景一个都不命中，我就改回单 Agent」。技术同事最怕的是为 PPT 架构买单的 PM，你先把退路说出来，信任立刻就建立了。
Q6面试官
「MCP 现在很火，你说说它和普通的 API 调用有什么区别？对你们产品来说意味着什么？」
🎯 对方在考察什么
考你对 MCP 的理解停在哪一层。只答「让 AI 调外部工具的协议」的人，和看了一篇科普文的人没区别。真正理解的人会讲双向：你的产品既能消费别人的能力，也能把自己变成别人的工具。
🧭 答题框架
- 先给一层理解：作为 Client，产品通过 MCP 消费外部能力：日历、邮件、数据库、浏览器，接入一个协议就能用一片生态，省掉逐个对接 API 的成本。
- 再给关键的第二层：MCP 是双向的。产品也能作为 Server 把自身能力暴露出去，让 Cursor、Claude Desktop、自动化脚本来调用你。单向集成只是工具调用，双向意味着你的 AI 能成为别人的工具。
- 说产品含义：当多个 Agent 能互相调用，生态就自然形成了。这是从工具到平台的关键跨越，也是产品定位层面的决策，得由 PM 来拍。
- 补工程常识：接了 10 个 MCP 服务，启动时全连一遍？3 个挂了启动就卡住。注册和连接要分开，用到再连（懒连接）。更进一步，Agent 运行时发现缺工具，可以自己发现并配置新的 MCP 连接。
⭐ 加分点用一句话收尾：「MCP 对 AI 产品的意义，类似当年开放平台对移动互联网的意义，先想清楚自己是接入方还是被接入方。」把协议问题抬到生态站位问题，面试官会记住你。
Q7老板
「这个月 API 账单比上个月翻了三倍，用户量才涨了 20%。钱都烧哪去了？下个月能降下来吗？」
🎯 对方在考察什么
考你懂不懂 Agent 产品的成本结构。以为成本和消息条数成正比的人，解释不了账单为什么跑得比用户量快。能把账单拆到轮次和上下文长度这一层的人，才有资格谈怎么降。
🧭 答题框架
- 先纠正计量单位：用户发一句话，底层可能跑 10+ 轮循环、几十条 API 消息，而且每一轮都要重发全部历史。成本跟任务复杂度挂钩，随复杂度指数增长，所以账单跑得比用户量快是正常现象，失控才是问题。
- 排查典型的成本刺客：定时任务复用旧会话，上下文越滚越长，一个选择就能让月账单差 10 倍；卡死的循环空转烧钱；长对话没做压缩，每轮都在为陈年历史付费。
- 给降本组合拳：定时任务改成每次新建会话；上线循环防呆掐掉空转；上下文压缩砍掉不该重发的 token；按用户和时段设成本限额，监控异常调用。
- 给量化承诺方式：建立单次任务平均成本的监控看板，把「下个月能不能降」转化成「单任务成本降到多少、异常调用清零」，按周汇报。
⭐ 加分点补一句「涨价的另一面是省着用会变笨，压缩过头体验会掉」，主动把成本和体验的权衡摆到桌面上，说明你在做产品决策，没有单纯当会计。
Q8面试官
「我们产品要加生图功能。文生图和垫图你打算怎么选？别说都试试，给我几个具体场景。」
🎯 对方在考察什么
考你知不知道这是生图产品的第一个分岔口。文生图和垫图是两种完全不同的产品策略，答「哪个效果好用哪个」的人，说明没在真实产品里做过生图决策。
🧭 答题框架
- 先讲核心区别：文生图是从无到有，模型每次对角色的想象都不一样；垫图是拿参考图当锚，外貌锁死，只变场景和动作。
- 给场景对照：纯背景图、食物物品特写、创意发散，用文生图，自由度高还便宜；角色出镜、角色换装（脸不变衣服变）、多场景系列图，必须垫图，否则用户会发现「怎么每张长得都不一样」。
- 给判断口径：就问一句「这张图有没有『必须还是同一个人』的约束」。有，走垫图；没有，文生图更灵活。
- 补产品含义：选垫图意味着要先建标准参考图这套素材资产，这是排期里要算进去的产品侧工作量。
⭐ 加分点点破「有没有参考图，决定的是两条完全不同的产品策略」，差的不只是出图效果，是整条素材管线和成本结构。
Q9面试官
「用户输入『画个夕阳下的猫』，直接把这句话发给生图模型不行吗？为什么你们中间还要过一道 LLM，多花一次钱？」
🎯 对方在考察什么
考你理不理解生图产品的核心架构：Prompt 二次翻译层。这一层看起来多余，其实是出图质量的命门。答不出「为什么必须翻译」的人，做出来的生图功能就是抽卡机。
🧭 答题框架
- 先给结论：用户想的和生图模型需要的是两种语言，中间必须有一层 LLM 做翻译，把一句话扩写成几百 token 的精确视觉描述。
- 给三个理由：用户不会写生图 Prompt，没人会主动打出 golden hour lighting 这种词；模型理解不了模糊意图，「发呆」对它来说根本没画面；每个生图模型方言还不同，Midjourney、DALL-E、Stable Diffusion 偏好各异，得按目标模型定制。
- 举个例子：「示例系统 在阳台发呆」经过翻译层，会变成站姿、神态、灯光、发型、标志性项链、构图俱全的英文长描述，出图才稳定。
- 给架构定位：这层翻译写进生图的产品化清单里，是固定架构，省掉它省的是小钱，赔的是出图质量。
⭐ 加分点补一句：翻译层还是统一注入角色特征（发型、项链这些锚点）的地方，它和角色一致性策略天然长在一起。
Q10技术同事
「你提的这个 bug『IP 形象每次生成都长得不一样』，我调调温度、固定一下种子就行了吧？没多大事。」
🎯 对方在考察什么
技术在试探你是把角色一致性当调参问题还是产品设计问题。你要是点头说好，过两周这个 bug 会原样回来，还多了一句「参数已经调过了」。
🧭 答题框架
- 先定性：这是生图产品最难的问题之一，调参数解决不了。纯文字描述连续生成四次，脸型、发型、体态、画风全在漂，文字锁不住视觉身份。
- 给方案：为 IP 制作标准化角色参考表（Character Reference Sheet），每次生图把参考图一起发给模型，让模型「看着画」，用垫图锚定。
- 说锚定什么：脸型体型（五官比例、身材轮廓）、表情风格（预先备好多种表情变体）、穿搭（标志性服装，换装场景只换衣服不换脸）。
- 补边界：降级链里有的备选模型不支持垫图，切过去会退化成纯文生图，一致性会掉，这个损失要在降级方案里预先声明，别到时候当事故处理。
⭐ 加分点主动认领产品侧工作量：参考图资产的制作和维护是 PM 要推动的事，别让技术觉得你只会提要求。
Q11面试官
「你们生图依赖第三方模型。哪天 Gemini 超时了、Seedream 又限流了，你的产品怎么办？讲讲你的降级设计。」
🎯 对方在考察什么
考你有没有「模型一定会挂」的工程兜底思维。答「等它恢复」或者「弹个错误提示」的人，没被凌晨的告警电话叫醒过。
🧭 答题框架
- 先走一遍链路：模型 A 超时 15 秒触发熔断，自动切模型 B；B 限流，继续切 C；C 成功出图。全程用户只看到「正在画」，感知不到后面换了三个模型。
- 给三个机制：优先级加白名单，角色出镜用一致性最好的模型，纯背景用便宜快的；探活，定时检测各模型健康状态，确认宕机的直接跳过，恢复了自动回来；垫图降级，备选模型不支持垫图就退化成文生图，质量降一档但图能出。
- 给全挂兜底：所有模型都挂时，给友好文案「服务繁忙，已加入队列，完成后通知你」，永远不给冷冰冰的报错页。
- 收一句原则：用户不关心哪个模型挂了，只关心图能不能出来。降级设计的目标是把故障翻译成体验损耗最小的等待。
⭐ 加分点说降级链的验收标准是「最差体验」：设计得好，最差也只是多等几秒或收到一句友好提示，这才叫产品化。
Q12面试官
「你简历上写熟悉 Agent。那你说说 Agent 循环呗，就是『想、做、看』三步转圈，对吧？」
🎯 对方在考察什么
这是道陷阱题，考你是背过教科书还是见过生产环境。顺着点头说「对」的人直接掉坑里，面试官等的是你把教科书省略的部分讲出来。
🧭 答题框架
- 先接住：教科书的 ReAct 确实是 Think、Act、Observe 三步，这是骨架，没错但远远不全。
- 再展开：生产环境里一轮循环实际要跑 11 步左右，多出来的包括上下文裁剪和 token 预算检查、系统指令注入、权限校验和参数合规、并发调度、超时监控和错误兜底、结果回写、安全审计日志。
- 点本质：多出来的这些步骤才是工程量大头，Agent 能不能稳定、安全、可用，靠的正是教科书里没有的部分。
- 举一个说透：权限校验这一步决定这个工具当前用户能不能调、参数合不合法，缺了它，Agent 上线第一天就是安全事故。
⭐ 加分点补一句排期视角：真实 Agent 每转一圈要做的事比教科书多 5 倍，评估工作量时要按 11 步算，按 3 步算的排期一定爆。
Q13面试官
「一个工具调用要在后台跑 30 秒。这 30 秒，用户屏幕上应该有什么？给我讲讲你的方案。」
🎯 对方在考察什么
考你的AI 产品交互功底。只答「加个 loading 动画」的人，没琢磨过等待体验。面试官想听的是一套完整的进度感设计。
🧭 答题框架
- 先给原则：用户能忍受等待，不能忍受不知道在等什么。进度感三原则：让用户看见过程、让进度可感知、让输出渐进出现。
- 给手段清单：状态文案（「正在搜索」「正在分析」）；把正在调用的工具名直接展示出来；逐 token 流式输出；阶段标记（第 1 步 / 共 3 步）；先给中间产物，比如先出大纲再填细节。
- 给对比画面：同样等 30 秒，一边只有转圈动画，用户在怀疑卡死；另一边是滚动的状态流「找到 3 条结果」「已分析 2/5 个文件」，用户在阅读。体感完全是两个产品。
- 补一层控制感：长任务要给随时可点的停止按钮，能叫停的等待才不焦虑。
⭐ 加分点点破「进度感 ≠ 进度条」：AI 任务时长本来就没法精确预估，核心是让用户觉得 AI 在认真干活，流式输出本身就是最好的进度条。
Q14技术同事
「你 PRD 里写着『单次任务成本控制在 5 美分以内』。你知道用户发一句『帮我重构这个模块』，底层实际烧掉多少 token 吗？」
🎯 对方在考察什么
技术在试探你 PRD 里的成本数字是算过账还是拍脑袋。报不出量级的 PM，写的成本指标没人当真。
🧭 答题框架
- 直接报量级：查天气这种简单任务，2 轮循环 6 条消息，约 1000 token，成本 $0.003；分析 PDF 要 6 轮，约 5700 token，$0.02；重构代码要 12 轮、二十多条消息、近 8000 token，$0.08。任务复杂度不同，成本差几十倍。
- 指出成本大头：System Prompt 每一轮都重发；工具返回的长文本（整个文件内容、整页搜索结果）是隐形大户；上下文滚雪球，后面每一轮都要带上前面所有消息。
- 修正指标写法：成本上限按任务类型分档设定，配上单任务成本监控，别一刀切一个数。
⭐ 加分点点出 Agent 成本最反直觉的地方：它随轮次滚雪球，增长超越线性，和传统「一次调用一次计费」的 API 直觉完全不同。
Q15面试官
「用户反馈你们的 AI 聊到后面越来越蠢，之前说过的要求老是忘。这是用户的错觉，还是真有机制上的原因？」
🎯 对方在考察什么
考你懂不懂长上下文的三重代价。答「可能是模型不稳定」的人，说明没理解上下文机制，这个锅模型不背。
🧭 答题框架
- 先给结论：不是错觉，是三个机制叠加。费用递增：每轮要重发全部历史，第 8 轮的单次成本能到第 1 轮的 20 倍；注意力衰减：模型对上下文两头热中间冷，第 3 轮提的重要需求到第 8 轮很可能被忽略；窗口溢出：128K 窗口写满后，最早的消息直接被丢掉，AI 是真的看不到了。
- 区分表现：「变蠢」主要来自注意力衰减和窗口溢出，「变贵」来自费用递增，两个症状一个根因：上下文无节制变长。
- 给动作：上下文管理是必答题，上压缩策略，同时把用户偏好这类关键信息单独保全，不跟着长对话一起稀释。
⭐ 加分点点出最反直觉的一条：用户以为 AI 忘的是最早说的话，其实注意力最低的是对话中段，中间那轮提的需求才是最危险的。
Q16技术同事
「上下文压缩我打算直接调个模型来做摘要，反正效果好。每轮都压一遍，你看行吗？」
🎯 对方在考察什么
他拿着锤子看什么都是钉子。考你知不知道压缩是条流水线，先免费后花钱，顺序反了就是拿钱换懒。
🧭 答题框架
- 摆两种手段的账：本地压缩靠正则、截断、模板替换，零成本、延迟不到 1 毫秒，但粗糙；LLM 压缩让另一个模型读一遍写摘要，精准保语义，但每次都是一笔 API 钱、1 到 5 秒延迟。
- 给正确顺序：四步流水线。先本地截断，删工具输出、砍超长 JSON；再模板替换，重复结构换占位符；然后检查还超不超窗口；实在压不下去，最后一步才请 LLM 精炼。
- 按内容分工：工具输出、JSON 结果、重复内容交给本地压缩就够了；多轮对话摘要、复杂上下文浓缩才值得花 LLM 的钱。
- 下结论：每轮都跑 LLM 摘要，等于给每次对话加一笔固定税。两种手段是流水线上的先后环节，用不着二选一。
⭐ 加分点提醒他压缩优先级：先删工具原始输出，再压 AI 自己的回复，用户的原话永远不碰。压缩手段再省钱，删了用户的话就是负分。
Q17面试官
「你们的记忆系统存了 1000 条用户记忆。每次对话，这 1000 条是全塞给模型，还是怎么处理？」
🎯 对方在考察什么
考你有没有算过记忆注入的成本账。答「全塞进去保险」的人没算过钱，也不知道噪声会把模型淹死。
🧭 答题框架
- 先否掉全量注入：它只在记忆很少时可行。1000 条全塞进 system prompt，每次调用都为这堆 Token 付费，绝大多数还和当前问题无关，纯噪声，AI 反而找不到重点。
- 给推荐链路：用户发消息后先做语义检索，从记忆库里捞出最相关的 3 到 10 条，只把这几条注入 system prompt，再让模型回复。
- 点出核心原则：记忆的价值在于每次能拿出最相关的几条，存了多少条本身不重要。随着记忆增长，按需检索是唯一可扩展的方案。
- 用类比收尾：好的记忆系统像称职的秘书，从不把整个档案柜搬进会议室，只提前把今天要用的三份文件放在桌上。
⭐ 加分点补一句取舍：按需检索的代价是可能漏召回，所以检索参数要留给产品调，宁可多召回两条，也别让用户发现「我上次明明说过」。
Q18面试官
「你们的 System Prompt 现在多长？谁在维护？改一句话要不要全量回归测试？」
🎯 对方在考察什么
三连问全指向一个点：你的 System Prompt 是一坨文本还是一个工程。说不出结构的人，产品稍微复杂一点就会陷进「改一处坏三处」的泥潭。
🧭 答题框架
- 先给结构：生产级 System Prompt 分四层管理。身份层管我是谁，名字、性格、能力边界，几乎不变；环境层管现在什么情况，用户语言、系统状态，每次会话可能不同；工具层管能用什么，随功能迭代增删；行为层管怎么行动，输出格式、决策优先级、安全护栏，迭代最频繁。
- 讲分层的收益：改一层不影响其他层，加工具只动工具层，调风格只动行为层；产品、工程、运营各改各的文件，Git 合并不冲突。
- 回答回归问题：A/B 测试只替换行为层，其他三层不动，变量单一；出问题按层排查，是人设错了、环境过时、工具描述有误还是规则冲突，一层层看。
⭐ 加分点点出频率差异是分层依据：身份层几年不动，行为层每周在改。变化频率不同的东西混在一个文件里，就是把稳定的东西反复暴露在手抖风险下。
用这些课程页组织答案 →
System Prompt 不是一坨文本
Q19技术同事
「咱们工具越加越多，马上到 100 个了。工具描述全在 System Prompt 里，一次请求光描述就几万 Token，你说怎么办？」
🎯 对方在考察什么
考你知不知道按需加载这个解法，以及它省的远不只是钱。工具一多，全量塞的不止是 Token 账单，还有模型选错工具的概率。
🧭 答题框架
- 先确认账单：课程里的估算，100 个工具全量加载约 3.4 万 Token，按需加载只要约 2800，省 90% 以上。这笔钱是每次请求都在花的。
- 给三步方案：首轮只给名字列表，工具名加一句话说明，让 AI 知道有这个能力；AI 决定调用时，系统再动态注入完整描述和参数格式；用完就收回，下一轮回到只有名字的状态。
- 点出第二重收益：AI 和人一样，给太多信息反而找不到重点。按需加载在省钱之外还提高了选工具的准确率。
- 用类比讲给团队听：公司通讯录不放每个人的完整简历，只放名字和职位，真要合作再看详细资料。
⭐ 加分点把这题和缓存串起来：工具描述如果放在 System Prompt 前缀里频繁增删，还会把 KV Cache 一起打废，按需加载等于一石三鸟。
Q20面试官
「System Prompt、Tool、Skill，这三样东西分别管什么？为什么不把 Skill 的内容直接写进 System Prompt？」
🎯 对方在考察什么
考你能不能把 Prompt 体系讲出职责边界。这三样混着用的产品，行为没法迭代也没法追溯，考官在看你有没有把 Prompt 当资产管理的意识。
🧭 答题框架
- 一句话分工：System Prompt 管我是谁，全局身份，很少改；Tool 管我能做什么，能力菜单，中频改；Skill 管遇到某件事怎么一步步做好，特定任务的流程指引，高频迭代、独立版本。
- 拆 Skill 的结构：触发条件定什么时候加载；允许的工具列表用白名单控风险；执行流程写清从确认需求到交付的每一步；输出格式要求保证每次产出质量一致。
- 回答为什么不进 System Prompt：System Prompt 是全局的，改了影响所有场景；Skill 按需加载，只在匹配任务时注入，不污染其他任务。而且文件即配置，谁改了什么 Git 里一目了然。
- 落到运营价值：Skill 让 Prompt 可复用、可迭代、可追溯，改文件就是改行为，这是把 Prompt 当代码管的起点。
⭐ 加分点补一个生命周期视角：编写、注册、触发、迭代四步，每个任务一个文件。面试时能画出这个闭环，比背三个名词强得多。
Q21技术同事
「我把 Skill 的内容直接拼进 System Prompt 了，实现最简单。最近账单有点涨，跟这个有关系吗？」
🎯 对方在考察什么
考你懂不懂 KV Cache 的前缀命中规则，以及能不能把一个实现细节和账单涨幅挂上钩。这是产品经理少有的能直接指出工程省钱点的机会。
🧭 答题框架
- 先讲规则：缓存对 System Prompt 算指纹，前缀一模一样才命中，差一个字全部重算。这不只是时间戳的问题，任何动态内容插进前缀都一样。
- 指出问题：Skill 拼进 System Prompt，切换 Skill 就是换前缀，缓存立刻作废。课程里的模拟，这种注入方式命中率只有 20% 左右。
- 给修法：Skill 作为独立消息追加在 System Prompt 之后，前缀永远不变，命中率能到 90% 左右。用户 ID、Session 标记这些变化的东西同理，全部后置。
- 给原则：别动前缀。所有可能变化的内容放到 System Prompt 之后，让前缀永远稳定。
⭐ 加分点接上Harness 核心篇的经典反例：动态时间戳毁缓存只是特例，这一课的结论更广，所有动态注入前缀的内容都是缓存杀手。
Q22面试官
「多 Agent 系统里，哪些操作可以同时跑、哪些必须排队？给我一条能落地的判断规则。」
🎯 对方在考察什么
考你能不能把并发这个工程概念压缩成一条产品可执行的规则。答得出规则还能说出例外，才算真理解。
🧭 答题框架
- 给出那条规则：这个操作执行完，世界有没有变？没变就可以并行，变了就必须排队。搜索、读文件、查 API 是只读，10 个一起跑互不影响；写文件、发邮件、支付会改变外部状态，两个同时改一个文件就是数据覆盖。
- 算收益：课程里的例子，3 次搜索加 1 次写入，并行编排约 4 秒，全串行约 8 秒。搜索并行跑、写入排最后，时间省一半。
- 补上例外：两个写操作改的是不同的东西，不同文件、不同表，也可以并行。冲突只发生在多个操作改同一个资源时。
- 落到设计动作：设计多 Agent 系统的第一步，就是把工具分成读和写两类，这个分类是产品要给工程的输入。
⭐ 加分点把规则说成一句话记忆点：看可以一起看，改必须排队改。面试官记住的往往就是这一句。
Q23面试官
「让三个 AI 讨论同一个问题，和把问题问三遍，有区别吗？你要是做脑暴功能，怎么保证它不是自欺欺人？」
🎯 对方在考察什么
考你懂不懂脑暴模式的关键机制。做错了，三个 Agent 互相附和，产出和问一遍没区别，还多花三倍钱。
🧭 答题框架
- 先给机制：同一个问题扔给多个 Agent，各自从不同角色出发独立回答，比如产品视角、数据视角、用户视角，最后由主持人 Agent 整合。
- 点出铁律：每个 Agent 必须独立思考，不能看到别人的答案。和人类脑暴「先各自写，再一起讨论」同一个道理，B 看了 A 的答案就会被带偏，脑暴就废了。这就是和问三遍的本质区别，问三遍是同一个上下文里的三次采样，视角没变。
- 讲产出物：主持人汇总的不只是共识，还要标注分歧。三个 Agent 意见一致说明方向明确；有分歧说明这个问题值得更深入讨论，分歧本身就是价值。
- 补效率账：思考类任务天然可并行，三个 Agent 同时想，总耗时等于最慢那个，时间不会翻三倍，钱会，所以只把它用在值得多视角的问题上。
⭐ 加分点点出角色设定是产品活：给三个 Agent 分别写什么人设，决定了视角差异的质量，这比「多跑几个」重要得多。
Q24老板
「咱们让 AI 每小时整理一次舆情，功能挺好，但我看这项的成本一天比一天高，月底账单吓我一跳。这是怎么回事？」
🎯 对方在考察什么
「一天比一天高」是关键线索，指向定时任务复用会话的成本雪球。你要能从账单形状反推出实现问题，并给一个立刻见效的修法。
🧭 答题框架
- 说出根因：定时任务复用了旧会话，上下文每次都在累积。第 1 次执行约 2000 Token，第 10 次约 2 万，第 24 次约 4.8 万，每次请求都在为全部历史付费，所以账单逐日爬坡。
- 给修法：每次执行新建会话，从零开始。第 24 次的成本和第 1 次一模一样。课程里的对比，跑 7 天每天 24 次，复用会话约 50 美元，新建会话约 5 美元，差 10 倍。
- 回答为什么可以这么改：大多数定时任务不需要记忆，每次整理当前的舆情就够了，用不着知道昨天整理过什么。真需要延续的信息，摘要存外部、下次带进去，别拖着完整历史。
⭐ 加分点给老板一个巡检习惯：凡是成本曲线随时间上翘的 AI 功能，先查是不是上下文在累积。这个模式一眼能认。
Q25面试官
「你们产品里的 AI，权限是怎么定的？所有功能一个标准，还是分开定？依据是什么？」
🎯 对方在考察什么
考你有没有把权限当成一条光谱来设计，别当成一个开关。答「我们要求都确认」或「我们信任 AI」的人，都还没入门。
🧭 答题框架
- 先立光谱观：从完全自主到每步审批是一条光谱，中间还有多档。全部放权 AI 可能搞砸一切，每步审批用户会疯掉，产品要做的是给每类操作找到光谱上的位置。
- 给三个定位维度：操作的可逆性，发消息不可逆、读文件可逆；出错的代价，删数据代价高、搜索代价低；用户的信任度，新用户谨慎、老用户放权。
- 回答分不分开：同一个产品里，不同功能用不同的权限模式。读日历自动执行，发邮件要确认，这才是正常形态，一刀切才是偷懒。
- 收到本质：给 AI 多大自由，本质是在回答一个产品问题：这件事出错了，谁来负责？
⭐ 加分点补一句动态性：权限位置可以随信任演化，用户用了三个月、确认了一百次没出过事，可以给他一个「以后这类不用问我」的选项。
Q26面试官
「用户投诉确认弹窗太多，砍掉之后又出了误删事故。弹窗这个度，你怎么拿捏？」
🎯 对方在考察什么
考你会不会用风险分级跳出「弹与不弹」的二选一。这是 Agent 产品最常见的体验与安全冲突，几乎每场面试都会换个皮问一遍。
🧭 答题框架
- 破题：问题出在无分级。每步都弹，用户点 5 次允许就想卸载；全不弹，删错文件没人兜底。答案是低风险自动执行、高风险必须确认。
- 给分级线：读文件、搜索、查日历这类不改变状态的操作不弹窗；删除文件、发送消息、支付、改权限这类不可逆或影响大的操作必须确认。
- 回答谁来定级：三个选项。产品经理在设计阶段预定义每个工具的风险等级，最常见；让 AI 根据上下文判断这件事要不要问人，更灵活但不一定准；用户自定义，最灵活但有配置成本。可以组合用，底线档永远人工定。
- 升华一层：好的权限设计不是要不要弹窗的二选一，是对什么时候弹、弹什么的精细控制。
⭐ 加分点提到弹窗文案也是分级的一部分：高危弹窗要说清这个操作不可逆、影响什么，让用户做的是知情决策，而点掉一个烦人的框不算。
Q27老板
「用户说 Agent 在后台跑了三分钟才出结果。这三分钟它到底在干什么，你能给我说清楚吗？」
🎯 对方在考察什么
老板问的是一次，背后要的是随时都能回答这类问题的能力。答不上来，说明产品是个黑盒，黑盒没法优化成本、排查故障、改善体验。
🧭 答题框架
- 诚实定性：今天答不精确，说明缺可观测性。要能回答这三分钟调了几个工具、跑了几轮循环、花了多少 Token、中间有没有出错，靠的是事件流和执行报告，不是猜。
- 说清要建什么：给 Agent 装仪表盘。执行时间线、工具调用统计、Token 消耗分布，每次任务一份执行报告。
- 讲对两边的价值：对开发，定位哪一步出问题、发现无效循环和浪费的 Token；对产品，理解用户真实使用路径、量化每个功能的成本、给下一版迭代提供数据。
- 给类比：没有仪表盘的 Agent 像没有仪表盘的车，不知道油量、不知道转速、不知道什么时候抛锚。这是产品化的基本功，不是锦上添花。
⭐ 加分点把这次投诉转成立项理由：这三分钟里哪怕只有 30 秒是无效循环，乘上调用量就是实打实的账单，可观测性的建设费用自己就能挣回来。
Q28技术同事
「产品要接 10 个 MCP 服务，我打算启动时全连一遍，保证随时可用。最近用户反馈启动变慢了，跟这个有关吗？」
🎯 对方在考察什么
考你知不知道懒连接这个设计，以及能不能看出「全连一遍」在可用性上的隐患。启动慢只是表象，真正的问题是故障会传染。
🧭 答题框架
- 先确认因果：10 个服务启动全连，只要有几个超时，启动就被拖住。课程里的真实数据，启动时全连要 30 秒，改懒连接后 0.2 秒，用户感受是秒开。
- 给三个原则：注册不等于连接，启动时只声明有哪些工具可用，不建网络连接；首次使用时才连，大多数工具可能一整天都用不到；故障隔离，某个服务挂了只影响那一个工具，其他照常。
- 点出产品含义：这不只是技术优化，是稳定性的基本设计。全连模式下任何一个第三方服务出问题都会拖累整个产品，懒连接把爆炸半径锁在单个工具里。
⭐ 加分点补一个体验细节：连不上的工具要在用户真正用到时给出清晰提示加重试入口，别在启动时就把失败摊给所有用户看。
Q29老板
「我看到个演示，用户说帮我查日历，AI 发现没配日历工具，自己就去装了一个。这也太智能了，咱们能做吗？会不会有风险？」
🎯 对方在考察什么
老板一半兴奋一半担心，你要两头都接住：讲清自配置的机制和它必须配的四道安全设计，既不泼冷水也不无脑吹。
🧭 答题框架
- 先讲机制：传统做法是报错说不支持，用户得自己去设置页找 MCP 配置项、填参数、测连通，大多数人根本不会。自配置是 Agent 根据需求匹配到候选工具，问用户一声，同意后自动完成配置，门槛从会配置降到会说话。
- 给四道安全设计：能力发现，Agent 只能从工具注册中心或预定义候选列表里挑，来路不明的不装；用户授权，必须告知要连接什么服务、等明确同意，AI 不能偷偷连，这是信任底线；即时生效，配置完热加载，当前对话无缝继续；安全边界，敏感工具比如数据库必须管理员手动配，不进自配置范围。
- 给结论：能做，而且值得做。自配置不是让 AI 随意装插件，是把复杂的配置过程自动化，决定权留在用户手里。
⭐ 加分点一句话总结给老板：最好的工具管理是 AI 自己管理自己的工具箱，但要用户点头才行。风险的答案就在后半句里。
Q30老板
「竞品两周就上了个 AI 助手，咱们做了俩月还没上线。人家不也是接个模型加个聊天框吗，咱们慢在哪？」
🎯 对方在考察什么
老板在拿套壳的速度逼问你产品化的价值。答不好就是效率低，答好了这是一次把整章内容打包讲给老板听的机会。
🧭 答题框架
- 先承认表象：接个模型加聊天框确实两周能上。用户看到的就是冰山水面上那一角：聊天界面、智能回复。
- 再讲水面之下：卡死了怎么停、上下文怎么压、用户的话删不删、记忆怎么筛、权限怎么分级、Agent 干了什么看不看得见、第三方服务挂了怎么办。这些是水面下的产品决策，套壳产品一个都没做。
- 给出差距的量纲：聊天套壳和真正的 Agent 产品之间，差的是用户看不见的地方上百个正确的产品决策。同一个 Loop 支撑 N 种场景，差异不在代码，在决策。
- 把时间换算成风险：竞品省掉的两个月，会在上线后以卡死、账单失控、误删事故的形式一笔笔还回来。我们可以砍范围先上核心场景，但水面下的底线决策不能省。
⭐ 加分点主动给一个折中方案：列出哪些决策是上线前必须做完的（安全、成本、兜底），哪些可以上线后迭代（记忆、多 Agent），把「慢」变成一张有优先级的清单。
最后一个建议
这 30 题的共同底色是算账和兜底：卡死了怎么停、上下文怎么压、账单怎么控。能把这些讲顺，说明你真的走过了从 Demo 到产品这段路。讲不顺的地方，点关联课程页回去补上。
「实战 · 从 Demo 到产品 · 30 道灵魂拷问」为什么能找到相关内容
「每题附考察意图、答题框架与加分点：Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「每题附考察意图、答题框架与加分点：Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
- 先给结论： 调通 API 只是 10%。真实案例里从调通到上线花了三个月，差的东西可以按四个维度盘点
- 体验层： 生成进度反馈、失败一键重试、多张结果供选择、历史记录可回看。Demo 里用户干等 30 秒没人管，产品里不行
- 质量层与工程层： 质量靠 Prompt 优化（用 LLM 把用户的人话翻译成生图模型能懂的描述）加角色一致性锚定；工程靠多模型降级链、超时重试、成本限额、结果持久化。模型一定会挂，挂了之后的体验才是产品
先区分找得到和找得准
把「每题附考察意图、答题框架与加分点：Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从这个例子继续往下看
这篇内容先从「先给结论： 调通 API 只是 10%。真实案例里从调通到上线花了三个月，差的东西可以按四个维度盘点」展开，再把问题推进到「体验层： 生成进度反馈、失败一键重试、多张结果供选择、历史记录可回看。Demo 里用户干等 30 秒没人管，产品里不行」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「实战 · 从 Demo 到产品 · 30 道灵魂拷问」：先给结论： 调通 API 只是 10%。真实案例里从调通到上线花了三个月，差的东西可以按四个维度盘点
- 「继续往下看」：体验层： 生成进度反馈、失败一键重试、多张结果供选择、历史记录可回看。Demo 里用户干等 30 秒没人管，产品里不行
- 「最后的要点」：先解释根因： 生产环境的 Agent 卡死有四种典型模式：同参数死循环（反复用相同参数调同一工具）、收益递减（跑了 50 轮全是边缘动作）、文本复读（上下文过长后开始车轱辘话）、工具连续失败雪崩（一个工具挂了拖垮整条链路）。先定位这次是哪种
最后的「最后的要点」把讨论落到「先解释根因： 生产环境的 Agent 卡死有四种典型模式：同参数死循环（反复用相同参数调同一工具）、收益递减（跑了 50 轮全是边缘动作）、文本复读（上下文过长后开始车轱辘话）、工具连续失败雪崩（一个工具挂了拖垮整条链路）。先定位这次是哪种」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
标记为已学完 阅读进度会自动记录
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。