他們會這樣考你
實戰 · 從 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 到產品這段路。講不順的地方，點關聯課程頁回去補上。