他們會這樣考你
實戰 · 從 Demo 到產品 · 30 道靈魂拷問
動手實戰篇學完了，你已經知道 Demo 和產品之間隔著什麼。這 30 個問題來自三個真實場景，先自己開口回答，再看框架。
怎麼用這一頁
每道題都標註了提問者。他們問同一塊知識，想聽的東西卻不一樣。
🎙 面試官想驗證你是真做過，還是只看過 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 偏好各異，得按目標模型客製。
- 舉個例子：「Alice 在陽臺發呆」經過翻譯層，會變成站姿、神態、燈光、髮型、標誌性項鍊、構圖俱全的英文長描述，出圖才穩定。
- 給架構定位：這層翻譯寫進生圖的產品化清單裡，是固定架構，省掉它省的是小錢，賠的是出圖品質。
⭐ 加分點補一句：翻譯層還是統一注入角色特徵（髮型、項鍊這些錨點）的地方，它和角色一致性策略天然長在一起。
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 到產品這段路。講不順的地方，點關聯課程頁回去補上。