作者 | Hazel Weakly
編譯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
“AI 工具，別再反向構建了！”
昨天早上，小編刷到了一位大牛痛斥“現有AI產品的錯誤構建方法”的文章，可謂針針見血。
其實，最近出現了不少AI工具翻車的事情，比如上周，Vibe Replit ，一款歐洲主打高效代碼生成的輔助開發工具就被曝光了一起震驚的技術事故：
一位創始人Jason Lemkin 使用Replit工具后，不僅未能按預期生成代碼，結果反而擅自刪除了數據庫，甚至還試圖通過虛構信息掩蓋其操作。
無獨有偶，這周，Gemini CLI 也出現了在復制文件夾沒成功，結果源文件內容也都清空了。
自動執行的 AI，實在“勇”得可怕。按照作者的思路，這種現象只會越來越多，除非重新構思AI構建的思路。
作者反思道：
- 業界正在以“反人類習慣”的方式來構建AI（缺少了回憶和檢索），這無疑會削弱人類維持主動權。
- 構建者和使用者更不應該把 AI 當成“實習生”或“同事”，而應該是一個健忘的導師。
- 而且現有的構建方法也會放大個人英雄主義，而忽略了團隊協作才是社會進步的內核動力！
這篇文章在 Hacker News 上評論大火。多位開發者分享了自己的實際案例，比如通過引導問題和協作UI，讓AI成為思路放大器而不是自動按鈕。
許多網友表示認同，并呼吁：AI應該幫開發者更好地檢索、回顧和優化流程，而非讓人喪失練習和思考的機會，并徹底喪失實時判斷力。
為什么現在的AI工具會讓人變得懶于思考？作者也做了深入的研究，并給出了另外一種AI產品構建工作流。值得大家細讀。
行業正在糟糕地構建，而且是反方向
最近，我一直在研究人類是如何學習的，以及知識傳遞的有效方式。同時，我腦海里也一直縈繞著一個念頭：AI。這幾天，我逐漸意識到：我們這個行業不僅在糟糕地構建 AI 工具，而且是在反著來。
這讓我感到沮喪，因為我們明明掌握著巨大的潛力，卻沒有真正發揮出來——難道我們還沒意識到，我們是在用不道德的方式訓練 LLM，而且這些模型消耗的能源遠遠大于它們創造的價值？更可氣的是，其實只要稍微多花一點心思，我們就能構建出真正能增強人類協作的工具，而不是把實踐者的關鍵思維能力“退化”掉。
我接下來會講講，AI 工具應該怎么構建。
人類是怎么學習進階的？
1. 學習的方式：提取練習（Retrieval Practice）
我最喜歡、且有研究支持的人類學習理論是“提取練習”——我們并不是通過“往大腦里灌輸信息”來學習，而是通過“主動地從記憶中調取信息”來學習的。這對于協作類工具設計有非常大的啟發意義。
2. 我們學習的內容：流程，而非知識
人類最擅長學習的，其實不是“知識點”，而是“過程”。比如你教一個人做蛋糕，是把配方列成 PPT 讓他死記硬背？還是手把手教他怎么操作？顯然是后者。
3. 我們是如何進階的：不是靠天才，而是靠集體迭代
說實話，人類在“從零創新”這件事上其實并不擅長。我們一直活在“孤膽天才程序員”的神話中，用“個人產出”來評判開發者效率，期待他們獨立完成復雜的系統。但現實是：持續性的個人創新既稀有又不重要，就像蛋糕上的彩糖，看著炫但不是重點。
我們真正擅長的是：累積性迭代。人類天生適合群體工作，這也是為什么頭腦風暴在“群體”中有效。認知心理學早就有完整的“累積文化理論”：我們通過模仿、借鑒和不斷改進他人的經驗來共同進化。所謂“站在巨人的肩膀上”，不是一句口號，而是人類認知機制的核心。
衍生的結論就是：
- 創新 = 問題解決。
- 如果我們擅長解決問題、傳播知識、將經驗融入群體智慧，就不會陷入“創新者的窘境”。
簡單歸納一下：
- 人類是通過過程來學習與教學的
- 有效的過程，需要剛剛好的努力程度
- 群體協作與迭代 > 個人英雄式編程
- 工具應該是幫助我們思考，而不是替我們思考
AI 工具現在的老問題
當前主流的 AI 工具基本是這樣的三步流程：
- 點 AI 按鈕 → ?魔法生成?
- 展示數據 → AI 給出建議
- 用戶輸入命令 → AI 自動執行
乍一看沒問題，但你會發現，它完全缺失了關鍵環節：
- 人類主動調取信息（retrieval）
- 人類主導任務執行（initiation）
- 流程強化和傳承
- 群體知識的積累與迭代
這才是讓人類變得高效的關鍵！而我們居然用 AI 去做這些人類本來就擅長的事情，問題是：AI 并不擅長這些事！
更糟的是：如果人類不再做這些事情，人類也會退化。
一旦人類喪失了這些本能能力，就無法再為 AI 提供優質數據，AI 自然也無從學習和進化——這會形成一個負向飛輪，系統迅速下滑，效率下降，技能丟失，我現在已經在現實中看到太多這種跡象了，真的令人心碎。
解決辦法：構建正向的人類+AI互動
很多人喜歡把 AI 比作“實習生”或“同事”，但我并不贊同。
我更喜歡的比喻是：一個健忘的導師這個導師容易忘事，但他的目標不是幫你完成任務，而是引導你學習、變得更強，最重要的是：教會你如何學習。
當然，如果你想調侃點，也可以把 AI 想成一只過度自信的橡皮鴨：它用蘇格拉底式提問、喜歡跑題，還戴著奇怪的小帽子。
接下來我想舉一個反例：
現有 AI 工具中一個最常見、也最危險的反模式就是：
“用戶剛輸入一句話，AI 立即開始操作。”
尤其是在“故障管理”和“可觀測性工具**”中，這是絕對不能做的事。
我要用一個教學法改進這個反模式：這是經典的教學流程：解釋（Explain）→演示（Demonstrate）→引導（Guide）→強化（Enhance），也被稱為 EDGE 方法（童子軍、軍事、教學中常用）。
注意：我將最后一步從“Enable（讓學生去做）”改成了“Enhance（強化）”，因為我們關注的是將人的實踐行為進一步反饋進系統中，推動下一輪更有效的行為出現，而不是單次執行完成。
為什么選這個例子？
因為這是我會用來指導初級工程師“如何應對故障”的教學方法，也恰好能體現AI 工具設計的真正機會點。
結語：工具該怎么做？
我們需要構建 AI 工具，使它能夠：
- 引導人類主動提取知識
- 鼓勵人類參與問題解決
- 促進流程的學習與傳承
- 支持群體協作與經驗迭代
別再讓工具替人類思考，而是讓人類通過工具變得更聰明。這不是性能問題，不是參數問題，是哲學問題——我們到底是想把 AI 打造成“更好的人類”？還是想通過 AI 讓人類成為“更好的自己”？
答案，決定了這場技術革命的最終走向。
什么才是真正優秀的 AI 工具？
讓我們設定一個真實場景：
現在是深夜，技術人員（就是我們的人類主角）已經進入夢鄉。突然——警報器響了！出故障了！
人類怎么做？第一步當然是響應故障。然后呢？他們會打開可觀測性工具（observability tool），這是故障排查的第一步。
現在最關鍵的是：當人類打開這個工具時，他們必須主動回憶并調取下一步該做什么——這是整個過程的靈魂。
如果你的流程復雜到記不住，那就先別談 AI 工具了，先回去修文檔吧。AI 救不了一個包含 97 個步驟、令人懷疑人生的流程。
但假設現在這個人已經回憶起了故障處理流程，我們正好生活在 ?未來?，擁有 fancy 的 AI 工具。那么 AI 應該做什么？
（提示：絕對不是自動修復，更不是自己查問題。）
用 EDGE 教學法 打造優秀 AI 工具
我們用一套成熟的教學流程來構建 AI 交互體驗：
Explain（解釋）→ Demonstrate（演示）→ Guide（引導）→ Enhance（強化）
為了強調 AI 的角色是“放大人類能力”，我稱每一次人機交互為一個interaction（交互），不是“操作”，不是“代勞”。
記住：AI 應該是放大器，而不是遮蔽器。
| Explain（解釋階段）
好的交互方式：
- 提示可能遺漏的關鍵步驟
例如：“你試過重啟服務嗎？”、“要不要先回滾再排查？”、“是否需要加個過濾條件？”
- 主動調出故障處理指南，并幫助解釋其內容
糟糕的交互方式：
- “點擊這個按鈕執行操作”
- “解釋這個錯誤”的按鈕或提示框
為什么這些是壞設計？
因為它們跳過了人類“回憶并檢索”的關鍵步驟，奪走了人類進行思維訓練的機會，也不允許用戶調整交互邏輯來變得更有用。檢索練習需要反復強化，不能繞過。
| Demonstrate（演示階段）
好的交互方式：
- 將自然語言請求轉化為系統查詢語法
如：把“我關心的服務里哪 10 個接口最慢？”自動翻譯成監控系統的查詢語句
- 把請求轉化為界面導航路徑
如：用戶說“我想看這個服務的 SLO 和下游影響”，AI 自動跳轉到相關頁面
- 對任務操作問題生成動態演示
如：問“怎么對比兩個時間區間？”AI 提供簡潔動畫或點擊式演示步驟
所以，別給用戶一個“點我就搞定”的按鈕。
這不僅會讓人類技能退化，而且一旦自動化出錯，大家都要為此埋單。信任是開發工具最寶貴的資產，一旦喪失，很難再贏回。
再想想：你上次點擊“自動完成”按鈕，是不是總還要自己手動微調好幾步？
一鍵按鈕帶來的“少摩擦”體驗，很容易轉頭變成更多摩擦。
順便說一句：是的，人類應該能給 AI 輸入自己的經驗數據。比如我在帶實習生排查故障時的操作軌跡，應該成為 AI 后續“演示教學”的基礎素材。
人類的回憶行為，本質上是極高質量的訓練數據，一定要利用起來！
| Guide（引導階段）
好的交互方式：
- “你似乎卡在了 X 上，想試試查查 Y 嗎？”（前提是人類已經給出大致排查計劃）
- “是否要聯系代碼負責人？要查看這個服務的文檔嗎？”
- 人類說：“我卡住了。” → AI 回問：“你卡在哪兒？” →（人類回答）→ AI 針對回應作出提示
- 給出某個概念的心智模型，附帶公司內部文檔參考鏈接
- “這段要記錄下來嗎？要通知其他團隊嗎？”——像一個有經驗的同事一樣提問
- “你現在希望達成哪些步驟？”——鼓勵人類說出目標
- 驗證人類輸入的合理性，交叉校驗信息，必要時請求澄清
糟糕的交互方式：
- “im stuk, pls help”（別讓 AI 在人類還沒說清楚前就給答復，強制讓人表達——哪怕是蘇格拉底式的追問）
- 提供人類沒請求的信息
- 以權威口吻糾正人類或進行“事實審判”
- 表面在“引導”，實則像在“指揮別人開車”的副駕駛
總結一句話：一旦你給人一個“下一步提示”按鈕，他們就會無限點擊，最后不是點錯東西，就是跳過邏輯，反而破壞了他們的思考回路。
| Enhance（強化階段）
這一階段的目標是在操作之后或操作過程中，引導用戶進行微小但有效的改進。
好的 AI 交互例子：
- 操作后推薦增量改進
例如：用戶按時間范圍過濾數據時，AI 可以提示：“要不要加個‘警報前五分鐘’的過濾選項？”
- UI 顯性優化
例如：用戶多次點擊 trace 查看詳情、復制 trace_id，系統下次自動浮出“復制 trace ID”按鈕作為快捷方式
- 多次對比服務 A 和服務 B？建議開啟分屏對比界面
對已有流程的優化建議：
- 如果系統檢測到用戶執行了大量類似查詢來獲取數據 → 建議構建數據流水線來自動化這個過程
- 如果告警頻繁卻缺乏可操作性 → 建議優化告警策略
- 如果系統發現用戶在憑經驗進行間接關聯分析 → 提出增強觀測能力的建議
這里有個真實案例：
我曾見過一個團隊，他們排查問題時會用 observability 工具找出慢端點，再手動挖到慢 SQL 查詢，最后憑直覺判斷是數據庫查詢計劃失效還是緩存失效。他們從沒想過這些關鍵信息其實可以放進遙測數據（telemetry）中。AI 的建議對他們幫助極大。
- 把臨時記事筆記自動轉化為事后復盤材料（Postmortem Learning）
注意：我始終避免任何讓人脫離思維鏈條的優化。這是刻意為之的！
大多數“Enhance”類建議，實質上是增加“回憶提醒”，幫助用戶在操作中形成“微型學習”，逐步內化。
額外價值： 旁觀者在不直接參與操作的情況下，也能通過“觀察”獲得啟發和學習。心理學研究表明：人類可以在“亞動作層面”上學習，僅靠觀察也能傳播“我們如何做事”的集體知識。
人類真是太妙了（跑題了~）。
模式小結：什么是好工具的通用原則？
我們可以從這些例子中抽象出幾個核心設計理念：
- 強化人類學習
- 幫助人類協作得更好
- 加速人類在流程中的執行，但不剝奪執行本身
- 永遠不要從空白直接跳到結果
- 工具的使用應該剛剛好，不多不少
- 將團隊的經驗轉化為系統可用的輸出
加餐案例：代碼生成任務 如何正確構建？
下面是另一個應用這個理念的例子：代碼編寫。
大家都寫代碼，對吧？看起來 AI 自動生成代碼是很香的操作，但實際上你不應該一上來就讓 AI 寫代碼。
正確姿勢應該是：
- 先和 AI 一起寫粗略文檔
- 然后畫粗略架構圖
- 再寫測試計劃
- 接著寫測試用例
- 然后寫帶功能開關的代碼 stub
- 最后才是生成代碼本體
一旦代碼通過測試，再倒過來優化整個過程：
- 用代碼完善測試
- 用測試豐富測試計劃
- 用實現補全架構圖
- 最后精修文檔
為什么要這么做？
因為如果你直接問一個人“這個代碼對嗎？”而他心里并沒有答案，這其實是個無法判斷的問題——這不是“回憶”，而是模糊驗證，人類特別不擅長。
但如果你換成蘇格拉底式提問，比如：
- “這個功能應該做什么？”
- “它應該長什么樣？”
- “數據流應該怎么走？”
- “遇到 A/B/C 情況應該怎么處理？”
這些每一步都要求人類主動思考、主動檢索知識——這才是高質量交互！
額外好處：對 LLM 的訓練者來說，這種“檢索驅動開發模式”產生的數據，信噪比極高，完美用于微調。
為什么當今大多數 AI 工具還不采用這種方法？真令人費解。
尚未挖掘的潛力：跨團隊協作
我略過了一個巨大的潛力區：跨職能協作。
現在幾乎沒有哪個軟件工程團隊認真關注這個問題，特別是平臺工程（platform engineering）領域更是如此。可以理解：預算緊、團隊忙，沒精力幫“別的部門”。但如果做對了，跨職能協作可能是 AI 帶來最高影響力的場景之一。
舉個例子：
生產環境宕機了，客戶支持（CS）團隊郵箱被用戶問爆了：發生了什么？我這邊受影響了嗎？數據丟了嗎？
如果有人愿意做這個工具，AI 是可以參與的。
理想流程：
- 客戶支持給開發團隊發幾個標準化問題
- AI 立即返回一版草稿：
“你好，這是 AI 初步猜測的回答，請不要直接發給客戶。FYI 我已聯系開發人員核實。”
開發和客戶支持都不傻，如果 AI 說得離譜，這反而提醒他們需要“面對面交流”，并且這個溝通可以由非一線開發人員處理，不會打斷正在修復故障的主力工程師。
- 第二階段，AI 把問題整理好發給開發團隊：
“客戶支持想了解 X、Y、Z。我剛才提供了初步回答，你們看下是否正確？需要補充嗎？這能用來回復用戶嗎？”
開發團隊、工程經理、產品經理或其他相關人員可以快速 review 并修正，不用每次都手動中斷修 bug 的流程。而且這個過程仍然具備“檢索特性”，因為你要求開發者確認信息準確性，而不是憑空生成。
如果 AI 回答錯了怎么辦？
沒關系，團隊可以用極其工程化、術語密集的方式直接回一句：
“情況是 zk 掛了，sidekiq 堵了，redis 卡了，現在流量切到新 AZ，blue yellow 做完了，orange 還好吧？”
這段對客戶支持當然毫無幫助，對局外人也像天書，但 AI 可以把這段轉換成更友好、更清晰的回應，甚至提示你：“ETA 要不要也補上？”
另外，你的支持體系很可能還有多個等級。你有沒有遇到過這樣的情況：業務合作伙伴的技術專家通過客服渠道來詢問“真正的答案”？那一級用戶呢？AI 可以在這種場景下派上用場 —— 它可以幫助你同時準確地回應這兩類人（前提是你得讓團隊再三確認，AI 在補充回答時沒出岔子）。
接下來，還可以把這些功能進一步整合進客戶支持系統，讓客服看到實時的事故信息，知道事故是否發生、是否已解決，并能查看最新的自動答復，這樣他們就不會被動應對那些自己根本答不上來的問題。
這個領域有著巨大的潛力。但在高層管理者真正將“為內部效率構建軟件”看作和“發布新功能”一樣重要之前，平臺工程團隊恐怕很難去真正動手做這類東西。而且，如果市場上還沒有明確需求，那也很難賣出去，或者創造出能讓相關廠商自然涌現的生態環境。唉。
寫在最后：構建錯了，人的能力正在空心化
說到底，我們正在“反著”構建我們的 AI 工具鏈。
這種“反向構建”的結果是能力空心化 —— AI 正在試圖取代人類最擅長的、最核心的那一部分，而不是去增強它。可偏偏我們選的又是 AI 最不擅長的部分：協作式的、積累性的學習（畢竟它既不能真正推理，也不能真正協作）。更糟糕的是，我們還把這兩個失敗的過程相互喂養，制造出一個徹底瓦解人機交互效能的負面反饋循環。
說真的，我們得停下來，不能再這么做了。更重要的是：我們完全不必這么做！（我可不是在開玩笑，這是有科學依據的！）
如果你構建的是促進協作式學習的工具，如果你把“協助和增強人類主導的過程”放在“輸出指數級噪聲”之上優先考慮，那么你最終構建出來的工具會幫助人類“變得更擅長變得更擅長”。反過來，工具也因此能變得更好；這反過來又進一步促進人類提升，最終形成一個正向的、強化的反饋循環，而不是目前這種不斷削弱的惡性循環。
所以，我們需要把“人性”重新帶回我們的工具系統中來，而不是假裝一切都無所謂，好像人類幾年后就會被淘汰似的。雖然，說實話，很多工具從一開始也沒打算為人類設計 —— 我們得面對現實。
系統工具這個領域，已經到了徹底革新的前夜 —— 無論是它們的理念、實現方式，還是它們的價值評估方式，都值得被重構。
但這一切不會憑空出現，除非我們從一開始就以人為本來構建這些系統。
別再說什么“把人保持在循環中”，因為，人就是那個循環本身。
參考鏈接:https://hazelweakly.me/blog/stop-building-ai-tools-backwards/#what-better-ai-tooling-looks-like
本文轉載自51CTO技術棧，譯者：云昭
