品味 + 工程思維：AI 時代最難被替代的兩件事
整理版優先睇
AI時代最難被替代的是品味同工程思維，語法可以交AI，判斷力要自己練
呢篇文章係參考咗《ClawdBot 創始人 Peter：AI 是槓桿，不是替代品》嘅訪談，作者分享佢對 Peter Steinberger 觀點嘅理解同自身經驗。Peter 由 iOS 轉 TypeScript，用 AI 從零寫 Clawdbot，發現語言層面嘅痛苦被 AI 消除，但工程思維同品味先係真正嘅核心。作者認為品味係長期決策力，工程思維係結構化能力，兩者都唔可以靠 AI 取代。
品味唔係天賦，而係喺多個可行方案入面揀一個更貼目標、更省維護、更幫到用戶嘅判斷力。工程思維就係「把事情做穩、做可復現」，核心習慣包括拆分問題、全局視野同三問（邊界、故障、驗證）。AI 令寫 code 變平價，但同時令錯誤同複雜度變得更貴，所以更需要工程思維去控制。
最後作者提出培養工程思維嘅三個習慣：先拆分、先跑通再優化、常覆盤。具體行動係每次用 AI 之前，先寫「最小規格」：目標一句話、輸入輸出、必須對同可以湊合嘅部分、最容易出錯嘅位。堅持練習，就會慢慢掌握呢種氣質。
- AI 消滅語法痛苦，保留工程思維同品味：語言細節可以交 AI，但你要有能力判斷佢寫得啱唔啱。
- 品味係長期決策力：問三個問題——係咪貼近目標？係咪降低長期維護成本？係咪令用戶更容易成功？
- 工程思維係結構化能力：拆分大問題、全局唔只睇局部、三問（邊界、故障、驗證）令結果穩定可靠。
- AI 時代錯誤同複雜度更貴：AI 產出容易隱藏邊界問題、引入多餘依賴、只睇局部，你要用工程思維兜底。
- 培養方法：先拆分任務、先跑通再優化、常覆盤取捨；每次用 AI 前寫「最小規格」提升效率。
ClawdBot 創始人 Peter 訪談
Peter Steinberger 討論 AI 時代工程思維同品味嘅價值，原文英文，呢篇係中文整理。
內容片段
目標：寫一段 200 字的產品介紹，讓第一次聽說的人能理解輸入：產品的三個核心賣點 + 目標用戶是誰輸出：標題 1 個 + 正文 200 字左右必須對：不能誇大、不能有虛假承諾、要有具體使用場景可以先湊合：語氣風格可以之後再調最容易出問題：寫得像模板、沒有具體場景、賣點說得太抽象AI 消滅咗咩，保留咗咩
Peter Steinberger 用 AI 由 Objective-C 轉 TypeScript 寫咗 Clawdbot，佢最大感受唔係「AI 好強」，而係以前換語言要承受幾個月嘅痛苦，而家 AI 幫手抹平咗呢啲語法層面嘅摩擦。佢話：「語言不再重要了，我的工程思維才重要。」
AI 消滅嘅係語法層面嘅痛苦，保留嘅係工程思維同品味
但 AI 抹唔平嘅係你對項目設計嘅直覺、見到 code 覺得「唔對路」嘅嗅覺，同揀 library 嘅判斷力。Peter 叫呢樣嘢做「品味」（taste）。
品味係咩？可以點判斷
品味聽落好虛，其實好具體。佢唔係審美偏好或者天賦，而係「長期決策力」——喺多個可行方案入面，揀一個更貼近目標、更省長期維護、更令用戶少犯錯嘅方案。
品味係長期決策力
要判斷一個選擇有冇品味，可以問三個問題：
- 係更貼近目標，定係只係做得更複雜？
- 係降低長期維護成本，定係只係當下省事？
- 係令用戶更容易成功，定係只係令自己寫得爽？
三個問題判斷品味：貼近目標、維護成本、用戶成功
舉個例：用戶出錯時，提示「未知錯誤」定係「網絡斷咗，撳呢度重試」？後者要多寫幾行 code，但體驗差好遠。呢啲就係品味嘅體現。
工程思維係咩？三個核心習慣
品味係感性判斷，工程思維就係理性結構化能力。通俗啲講，係「將件事做穩、將結果做可復現」。唔係識寫 code 或者識好多 framework，而係一種將不確定性關進籠子嘅習慣。
作者總結三個核心習慣：
- 1 拆分：將大問題拆成小問題。新手好易俾一個大需求嚇親，有工程思維嘅人會自動拆開：先做咩後做咩，邊啲核心邊啲邊角，邊啲可以 hardcode 邊啲要做成可配置。
- 2 全局：唔只睇當前問題，要睇整體。諗嚇呢個方案同系統其他部分點配合？三個月後要改需求，呢個設計仲可以擴展嗎？防止「局部最優」。
- 3 三問：邊界、故障、驗證。邊界係做咩唔做咩，輸入輸出；故障係邊度會壞；驗證係點證明冇壞——測試、日誌、監控、可復現。
三問：邊界、故障、驗證
一句話講：工程思維係將「我覺得差不多」替換成「我知道佢喺呢啲條件下係啱嘅」。
點解 AI 時代更加需要工程思維
AI 令寫 code 變平價，但令錯誤同複雜度變得更貴。便宜嘅係語法、樣板、膠水 code；貴嘅係呢幾樣嘢：
- 錯得更隱蔽：AI 成日俾個「睇落好啱」嘅實現，邊界條件一嚟就露餡，仲會將錯收埋喺你唔多睇嘅角落。
- 複雜度更容易失控：AI 唔會肉痛，你叫佢加個功能，佢可能順手引入三層抽象、兩套依賴、五個配置項。
- AI 天然只睇局部：每次回答都係局部最優，解決 A 問題用一種方式，解決 B 問題用另一種方式，放埋一齊就打架。
AI 好擅長呃你入「完成感」，你覺得佢寫完，其實只係「能跑」，離「能用」仲有一段距離
前面講過條公式：AI 係乘數，你係被乘數。拆分、全局、三問就係個被乘數，決定咗 AI 可以將你放大到咩程度。
點樣培養工程思維
工程思維似肌肉，要靠反覆練先長出嚟。作者分享自己最受用嘅三個習慣：
- 1 先拆分：每次遇到任務，先問「呢個任務可唔可以拆成更細嘅任務？」例如叫 AI 寫產品介紹，拆成一句話定義、三個核心賣點、一段使用場景。
- 2 先跑通，再優化：先用笨辦法做出結果，再回頭揾更好方法。好多人都反轉嚟做，想一步到位結果兩頭唔到岸。
- 3 常覆盤：每次做完問自己三個問題——做咗咩取捨？如果出事最可能係邊度？如果重做會刪咗咩保留咩？
先跑通，再優化：唔好未跑通就想優化
長期練落去，你會越嚟越少俾「唔知從邊度入手」卡住，越嚟越多做拆解、取捨、驗證嘅決定。呢個就係工程思維喺發芽。
AI 時代，最難被取代嘅唔係「識唔識寫 code」，而係兩件事：做選擇嘅品味和將結果做穩嘅工程思維。
最近睇咗一個好典型嘅訪問《ClawdBot 創辦人 Peter：AI 係槓桿，唔係替代品；程式語言唔重要，重要嘅係我嘅工程思維》https://baoyu.io/blog/2026/02/01/peter-steinberger-interview。
Peter Steinberger 係 PSPDFKit 嘅創辦人，做咗 20 幾年 iOS 開發，舊年用 AI 由零寫咗一個大項目 Clawdbot，轉咗自己完全唔熟嘅語言。佢最大感受唔係「AI 太勁」，而係：
「由 Objective-C 同 Swift 轉到 TypeScript，問題唔係難，而係痛苦。每個細嘢都要查，你明明明所有概念，但就係唔知語法。慢到令人想放棄。」
「有咗 AI，呢啲痛苦全部消失咗。你仍然可以運用你嘅系統級思維、你對大項目嘅架構理解、你嘅品味。呢啲嘢依然有價值，而且你可以更容易噉將佢哋由一個領域遷移到另一個領域。」
佢總結話：「語言唔再重要，我嘅工程思維先係重要。」
呢句話需要一個邊界：唔係話你可以完全唔識，而係話語法細節可以交俾 AI，但你要睇得明佢寫嘅嘢、判斷到啱唔啱。
我嘅結論係：語法可以交俾 AI，但你要練出工程思維——將需求諗清楚、將系統設計清楚、將結果驗證清楚嘅能力。
AI 消滅嘅係乜嘢，保留嘅係乜嘢
Peter 嘅核心觀點係：AI 消滅嘅係語法層面嘅痛苦，保留嘅係工程思維同品味。
乜嘢係語法層面嘅痛苦？就係你明明知道要做乜，但唔知點樣喺呢個語言裏面寫出嚟。以前轉一門語言，呢種摩擦可以折磨你好幾個月。而家 AI 幫你抹平咗。
但 AI 抹唔平嘅係乜嘢？
係你腦入面嗰個「呢個項目應該點樣設計」嘅直覺。係你見到一段 code，感覺到「呢度唔對路」嘅嗅覺。係你選擇用邊個 library、唔用邊個 library 嘅判斷力。
Peter 叫呢樣做「品味」（taste）。
「嗰啲 AI 做唔到嘅嘢係乜？係品味。佢哋的確好聰明，但如果你唔好好引導佢哋，如果你冇一個清晰嘅願景，產出嘅往往係行到但唔好用嘅嘢。如果你唔問啱嘅問題，結果都唔會啱。」
我其實成日都有提：AI 好似能力倍增器，AI 係乘數，你嘅基礎能力係被乘數。如果被乘數係零，乘乜都係零。如果被乘數係 100，AI 可以幫你放大到 1000。
例如，我對影片製作能力幾乎係 0，就算藉助 AI，我用 AI 做影片都遠遠唔及汗青、海辛同阿文呢啲專業影片創作者做出嚟嘅效果。但係喺我擅長嘅編程領域，我可以藉助 AI 高效率噉完成複雜嘅任務。
乜嘢係「品味」
呢個詞聽落好虛，但其實好具體。
品味唔係審美偏好，亦唔係天賦。你可以將佢理解成長期決策能力——喺多個可行方案入面，揀一個更加貼近目標、更加慳長遠維護、更加令用戶少犯錯嘅方案。
點樣判斷一個選擇有冇「品味」？可以問三個問題：
• 係更加貼近目標，定係只係做得更複雜？ • 係降低咗長期維護成本，定係只係當下就手？ • 係令用戶更容易成功，定係只係令自己寫得爽？
Peter 描述咗佢做項目嘅方式：
「當我開始一個項目，我只有一個好粗略嘅想法。然後隨住我去構建佢、把玩佢、去感受佢，我嘅願景會越來越清晰。我會嘗試一啲嘢，有啲行唔通，然後我嘅想法會演變成佢最終應該成為嘅樣。下一個 prompt 係乜嘢，取決於我見到當前項目狀態之後嘅感受同思考。」
呢個就係品味：你可以感知到乜嘢係好，乜嘢係唔好。你可以判斷下一步應該向邊個方向行。
舉幾個更加具體嘅例子：
• 用戶出錯時，提示「未知錯誤」定係「網絡斷咗，㩒呢度重試」？後者需要寫多幾行 code，但體驗完全唔同。 • 一個功能可以用現成嘅 library，亦可以自己寫。用 library 就手，但引入咗一個你唔完全理解嘅依賴。你點揀？ • AI 俾你生成咗 200 行 code，行到。但你睇住覺得「怪怪哋」，講唔出邊度唔啱。你係直接用，定係停低搞清楚？
呢種判斷力唔止喺寫 code 時有用。換成日常場景：
• 同樣係 AI 幫你寫一段文案，係「睇落順」定係「似模板」？你分唔分辨到？ • 同樣係做一頁 PPT，係「資訊堆滿」定係「重點一眼睇明」？你點揀？ • 同樣係叫 AI 幫你寫 CV，係照單全收，定係覺得「呢個唔似我」然後調整？
品味就係喺呢啲時候做出判斷嘅能力。佢唔係天賦，係你踩過坑、見過好嘢之後生出來嘅直覺。
乜嘢係工程思維
品味係感性層面嘅判斷力，工程思維係理性層面嘅結構化能力。
工程思維，通俗啲講就係「將事情做穩、將結果做到可重複出現」。佢唔係「識寫 code」，亦唔係「識好多 framework」，而係一種將不確定性關入籠嘅習慣。
打個比喻。同樣係煮飯，隨手炒一碟菜，香唔香全靠靈感，呢個叫「行到一次」。開一間可以穩定出餐嘅餐廳，先叫工程。你要有備料標準、火候控制、出餐流程、衞生檢查、缺貨預案，仲要計成本。工程思維就係呢套「令結果穩定發生」嘅方法。
點樣令結果穩定發生？
我自己總結嘅三個核心習慣（唔係話得呢三個）：
第一，拆分：將大問題拆成細問題。
新手最容易被一個大需求嚇親，唔知從邊度入手。有工程思維嘅人會自動將佢拆開：先做乜嘢，後做乜嘢；邊啲係核心，邊啲係邊角；邊啲可以暫時寫死（hard code），邊啲一定要做成可配置。
拆分能力亦直接決定咗你可唔可以將 AI 用好——後面會詳細講。
第二，全局：唔淨係睇當前問題，要睇整體。
新手容易只係睇住眼前嘅問題，解決咗就算。有工程思維嘅人會諗多一步：呢個方案同系統裏面其他部分點樣配合？會唔會喺其他地方埋下炸彈？三個月後要改需求，呢個設計仲可以擴展嗎？
全局思維嘅反面係「局部最優」：A 問題用一種方式解決，B 問題用另一種方式解決，單獨睇都幾好，擺埋一齊就打交。
第三，三問：邊界、故障、驗證。
呢個係我判斷一個方案「工程唔工程」嘅三個問題：
• 邊界喺邊？ 做乜嘢，唔做乜嘢；邊度係輸入，邊度係輸出；邊啲一定要正確，邊啲可以暫時求其。 • 會喺邊度壞？ 現實裏面有斷網、超時、污糟數據、權限問題、並發衝突（多件事同時發生導致嘅問題）。有工程思維嘅人寫 code 時，個腦一路喺度行呢啲故障場景。 • 點樣證明冇壞？ 證明唔係自信，係驗證：測試、日誌（程式運行嘅記錄）、監控、可重複出現。你可以俾出一套令其他人也信服嘅驗證方式，呢個先叫「工程」。
一句話講：工程思維係將「我覺得差唔多」換成「我知道佢喺呢啲條件下係啱嘅」。
點解 AI 時代更加需要工程思維
AI 令寫 code 變得平咗，但令「錯誤」同「複雜度」變得更加貴。
平喺邊？語法、樣板、膠水 code，AI 寫得又快又多。你亦容易喺一日之內堆出一個看似完整嘅功能。
貴喺邊？
第一，錯得更隱蔽。 AI 經常俾你一個「睇落好似啱嘅」實現，行到，過到幾個手動測試，但邊界條件一到就穿崩。更麻煩嘅係，佢會將錯收喺你唔係好會睇嘅角落：出錯時點樣兜底、用完資源有冇釋放、多件事同時發生會唔會打架。
翻譯成生活場景：你約咗夜晚 8 點，對方手機顯示成朝早 8 點（時區問題）；你以為個個都可以開到連結，結果得你自己睇到（權限問題）；兩個人同時改同一個文件，最後邊個版本都唔啱（並發問題）。呢啲坑 AI 好容易漏咗。
第二，複雜度更加容易失控。 人手寫 code 時會肉痛，會自然剋制。AI 唔會肉痛。你叫佢「加一個功能」，佢可能順手引入三層抽象、兩套依賴、五個配置選項。你以為你喺度加功能，其實你喺度加未來嘅維護成本。
例如我最近合併 baoyu-skills PR 嘅時候發現，兩個幫 post-to-x 加功能嘅 PR，Claude Code 係共同作者（即係 AI 寫嘅），都選擇咗複製已有嘅邏輯 code，而唔係抽取出相同嘅 code 去重用，我只能夠合併之後重新抽簡咗一下。
第三，AI 天然只睇局部。 佢每次回答都係針對當前問題嘅「局部最優」——你叫佢解決 A 問題用一種方式，解決 B 問題用另一種方式，擺埋一齊就打交。佢可能為咗解決當前問題引入一個新依賴，但你知道項目入面已經有類似嘅 library。呢啲「整體視角」嘅判斷，只能夠你嚟做。
AI 好擅長將你呃入「完成感」，你覺得佢寫完咗，其實只係「行到」，離「用到」仲有一段距離。
仲記唔記得前面嗰條公式？AI 係乘數，你係被乘數。前面講嘅拆分、全局、三問，就係嗰個被乘數——佢決定咗 AI 可以將你放大到咩程度。
點樣培養工程思維
工程思維唔係聽明就有，佢更加似肌肉，要靠反覆練先可以生出來。
培養佢嘅方法有好多，我自己最受用嘅係三個習慣：先拆分、先行通、成日覆盤。唔一定適合所有人，亦唔一定係完整，但可以作為一個參考。
先拆分
每次遇到一個任務，先唔好諗住一次過做完，先問自己：呢個任務可唔可以拆成更加細嘅任務？
我最近喺度輔導一年級嘅細仔做數學，俾咗佢一條題：1+2+3+……+100 等於幾多？佢一睇就矇咗，唔知從邊度入手。
我冇直接教佢公式，而係引導佢先做一個更加細嘅問題：1+2+3+……+10 等於幾多？呢個佢識計，一個一個加，得出 55。
然後我叫佢計 11+12+……+20，佢又計到出嚟，係 155。
就係咁一段一段計落去，最後將十個細結果加埋，得到 5050。
呢個就係拆分：將一個令你發矇嘅大問題，拆成一堆你可以入手嘅細問題。
唔寫 code 嘅場景都一樣。例如你想叫 AI 幫你寫一篇產品介紹，與其話「幫我寫個產品介紹」，不如拆成：先寫一句話講清楚呢個係乜 → 再寫三個核心賣點 → 最後寫一段使用場景。拆開之後，每一步你都判斷到啱唔啱，AI 亦更加容易俾到你想要嘅嘢。
先行通，再優化
仲係嗰條數學題。細路用蠢方法計出 5050 之後，我帶佢返轉頭覆盤。
我哋由 1 到 10 開始，換一種算法：（1+10）+（2+9）+（3+8）+……每一對都係 11，一共 5 對，所以係 55。
佢喺我引導下發現咗規律。然後用同樣嘅思路計 1 到 100：（1+100）+（2+99）+……每一對係 101，一共 50 對，101×50=5050。比蠢方法快好多。
呢個就係「先行通，再優化」：先用蠢方法將結果做出嚟，再返轉頭揾更好嘅方法。
好多人嘅問題係反過嚟，未行通就想優化，結果兩頭都做唔好。先等佢行起嚟，就算樣衰啲、慢啲；行通之後再返轉頭睇，邊度可以做得好啲。
常覆盤
每次做完一件事，問自己三個問題：
• 今次我做咗邊啲取捨？點解咁樣揀？ • 如果出問題，最可能係邊度？ • 如果重做一次，我會刪咗乜嘢、保留乜嘢？
呢三個問題唔止可以幫你提升工程思維，亦可以幫你練品味。品味唔係天賦，就係靠呢種「做完咗再諗諗」嘅習慣慢慢生出來嘅。
一個可以即刻用嘅動作
下次叫 AI 做嘢之前，先花一分鐘寫幾行「最小規格」：
• 目標一句話 • 輸入係乜，輸出係乜 • 邊啲一定要啱，邊啲可以暫時求其 • 最容易出問題嘅地方係乜
舉個非技術嘅例子。假設你想叫 AI 幫你寫一段產品介紹：
目標：寫一段 200 字的產品介紹，讓第一次聽說的人能理解
輸入：產品的三個核心賣點 + 目標用戶是誰
輸出：標題 1 個 + 正文 200 字左右
必須對：不能誇大、不能有虛假承諾、要有具體使用場景
可以先湊合：語氣風格可以之後再調
最容易出問題：寫得像模板、沒有具體場景、賣點說得太抽象
將呢幾行 send 俾 AI，再叫佢開始寫。你會發現，生成嘅嘢比「幫我寫個產品介紹」好一大截。
好多時，「寫唔出來嘅規格」，本質上係你自己都未諗清楚要做乜嘢。
長期係咁練，你會明顯感覺到變化：你越來越少被「唔知從邊度入手」卡住，越來越多喺度做「拆解、取捨、驗證」嘅決定。呢個就係工程思維喺度發芽。
最後
Peter 喺訪問最後話：
「你要自己去探索，揾到自己嘅路。你需要時間先可以變好。你要犯自己嘅錯誤。呢個係你學習任何嘢嘅方式，學呢個都一樣。只不過呢個領域變化特別快。」
工程思維最後會變成一種氣質：你唔再追求「寫得出嚟」，而係追求「交付後仲可以穩定運行」。
唔知從邊度開始？
可以由今日就嘗試一下：下次叫 AI 做嘢之前，先同 AI 對話，一齊寫幾行「最小規格」。堅持幾次你會發現，AI 越來越聰明越來越明你，你越來越能夠掌控 AI。
AI 時代，最難被替代的不是"會不會寫代碼"，而是兩件事：做選擇的品味和把結果做穩的工程思維。
最近看了一個很典型的訪談《ClawdBot 創始人 Peter：AI 是槓桿，不是替代品；編程語言不重要了，重要的是我的工程思維》https://baoyu.io/blog/2026/02/01/peter-steinberger-interview。
Peter Steinberger 是 PSPDFKit 的創始人，做了 20 多年 iOS 開發，去年用 AI 從零寫了一個大項目 Clawdbot，換了自己完全不熟的語言。他最大的感受不是“AI 太強了”，而是：
“從 Objective-C 和 Swift 轉到 TypeScript，問題不是難，而是痛苦。每個小東西都得查，你明明理解所有概念，但就是不知道語法。慢得讓人想放棄。”
“有了 AI，這些痛苦全都消失了。你還是可以運用你的系統級思維、你對大項目的架構理解、你的品味。這些東西依然有價值，而且你可以更容易地把它們從一個領域遷移到另一個領域。”
他總結說：“語言不再重要了，我的工程思維才重要。”
這句話需要一個邊界：不是說你可以完全不懂，而是說語法細節可以交給 AI，但你得能看懂它寫的東西、能判斷對不對。
我的結論是：語法可以交給 AI，但你必須練出工程思維——把需求想清楚、把系統設計清楚、把結果驗證清楚的能力。
AI 消滅的是什麼，保留的是什麼
Peter 的核心觀點是：AI 消滅的是語法層面的痛苦，保留的是工程思維和品味。
什麼是語法層面的痛苦？就是你明明知道要幹什麼，但不知道怎麼在這個語言裏寫出來。以前換一門語言，這種摩擦能折磨你好幾個月。現在 AI 幫你抹平了。
但 AI 抹不平的是什麼？
是你腦子裏那個“這個項目應該怎麼設計”的直覺。是你看到一段代碼，能感覺到“這裏不對勁”的嗅覺。是你選擇用哪個庫、不用哪個庫的判斷力。
Peter 管這個叫"品味"（taste）。
“那些 AI 做不到的事情是什麼？是品味。它們確實很聰明，但如果你不好好引導它們，如果你沒有一個清晰的願景，產出的往往是能跑但不好用的東西。如果你不問對的問題，結果也不會對。”
我其實經常有提到：AI 像是能力倍增器，AI 是乘數，你的基礎能力是被乘數。如果被乘數是零，乘什麼都是零。如果被乘數是 100，AI 能幫你放大到 1000。
舉例來說，我對視頻製作能力就幾乎為 0，就算藉助 AI，我用 AI 做視頻也遠遠不及像汗青、海辛和阿文這些專業視頻創作者做出來的效果。但在我擅長的編程領域，我可以藉助 AI 高效的完成複雜的任務。
什麼是“品味”
這個詞聽起來很虛，但其實很具體。
品味不是審美偏好，也不是天賦。你可以把它理解成長期決策力——在多個可行方案裏，選一個更貼近目標、更省長期維護、更讓用戶少犯錯的方案。
怎麼判斷一個選擇有沒有“品味”？可以問三個問題：
• 是更貼近目標，還是隻是做得更復雜？ • 是降低了長期維護成本，還是隻是當下省事？ • 是讓用戶更容易成功，還是隻是讓自己寫得爽？
Peter 描述了他做項目的方式：
“當我開始一個項目時，我只有一個很粗略的想法。然後隨着我去構建它、把玩它、去感受它，我的願景會越來越清晰。我會嘗試一些東西，有些行不通，然後我的想法會演變成它最終應該成為的樣子。下一個 prompt 是什麼，取決於我看到當前項目狀態後的感受和思考。”
這就是品味：你能感知到什麼是好的，什麼是不好的。你能判斷下一步應該往哪個方向走。
舉幾個更具體的例子：
• 用戶出錯時，提示“未知錯誤”還是“網絡斷了，點這裏重試”？後者需要多寫幾行代碼，但體驗完全不同。 • 一個功能可以用現成的庫，也可以自己寫。用庫省事，但引入了一個你不完全理解的依賴。你怎麼選？ • AI 給你生成了 200 行代碼，能跑。但你看着覺得“怪怪的”，說不上來哪裏不對。你是直接用，還是停下來搞清楚？
這種判斷力不只在寫代碼時有用。換成日常場景：
• 同樣是 AI 幫你寫一段文案，是“看着順”還是“像模板”？你能分辨嗎？ • 同樣是做一頁 PPT，是“信息堆滿”還是“重點一眼看懂”？你怎麼選？ • 同樣是讓 AI 幫你寫簡歷，是照單全收，還是覺得“這不像我”然後調整？
品味就是在這些時刻做出判斷的能力。它不是天賦，是你踩過坑、見過好東西之後長出來的直覺。
什麼是工程思維
品味是感性層面的判斷力，工程思維是理性層面的結構化能力。
工程思維，通俗一點說就是"把事情做穩、把結果做可復現"。它不是“會寫代碼”，也不是“懂很多框架”，而是一種把不確定性關進籠子的習慣。
打個比方。同樣是做飯，隨手炒一盤菜，香不香全靠靈感，這叫“能跑一次”。開一家能穩定出餐的餐廳，才叫工程。你要有備料標準、火候控制、出餐流程、衞生檢查、缺貨預案，還得算成本。工程思維就是這套“讓結果穩定發生”的方法。
怎麼讓結果穩定發生？
我自己總結的三個核心習慣（不是說只有這三個）：
第一，拆分：把大問題拆成小問題。
新手最容易被一個大需求嚇住，不知道從哪下手。有工程思維的人會自動把它拆開：先做什麼，後做什麼；哪些是核心，哪些是邊角；哪些可以先硬編碼，哪些必須做成可配置的。
拆分能力也直接決定了你能不能把 AI 用好——後面會細說。
第二，全局：不只看當前問題，看整體。
新手容易只盯着眼前的問題，解決了就完事。有工程思維的人會多想一步：這個方案和系統裏其他部分怎麼配合？會不會給別的地方埋雷？三個月後要改需求，這個設計還能擴展嗎？
全局思維的反面是“局部最優”：A 問題用一種方式解決，B 問題用另一種方式解決，單獨看都挺好，放一起就打架。
第三，三問：邊界、故障、驗證。
這是我判斷一個方案“工程不工程”的三個問題：
• 邊界在哪？ 做什麼，不做什麼；哪裏是輸入，哪裏是輸出；哪些必須正確，哪些可以先湊合。 • 會在哪裏壞？ 現實裏有斷網、超時、髒數據、權限問題、併發衝突（多件事同時發生導致的問題）。有工程思維的人寫代碼時，腦子裏一直在跑這些故障場景。 • 怎麼證明沒壞？ 證明不是自信，是驗證：測試、日誌（程序運行的記錄）、監控、可復現。你能給出一套讓別人也信服的驗證方式，這才叫"工程"。
一句話說：工程思維是把"我覺得差不多"替換成"我知道它在這些條件下是對的"。
為什麼 AI 時代更需要工程思維
AI 讓寫代碼變便宜了，但讓“錯誤”和“複雜度”變得更貴了。
便宜在哪？語法、樣板、膠水代碼，AI 寫得又快又多。你很容易在一天裏堆出一個看似完整的功能。
貴在哪？
第一，錯得更隱蔽。 AI 經常給你一個“看起來很像對的”實現，能跑，能過幾個手工測試，但邊界條件一來就露餡。更麻煩的是，它會把錯藏在你不太會看的角落：出錯時怎麼兜底、用完資源有沒有釋放、多件事同時發生會不會打架。
翻譯成生活場景：你約的是晚上 8 點，對方手機顯示成了早上 8 點（時區問題）；你以為別人都能打開連結，結果只有你自己能看（權限問題）；兩個人同時改同一個文檔，最後誰的版本都不對（併發問題）。這些坑 AI 很容易漏掉。
第二，複雜度更容易失控。 人手寫代碼時會肉疼，會自然剋制。AI 不會肉疼。你讓它“加一個功能”，它可能順手引入三層抽象、兩套依賴、五個配置項。你以為你在加功能，其實你在加未來的維護成本。
比如我最近合併 baoyu-skills PR 的時候就發現，兩個給 post-to-x 添加功能的 PR，Claude Code 是共同作者（說明是 AI 寫的），都選擇了複製已有的邏輯代碼，而不是抽象相同的代碼去重用，我只能合併後重新抽象精簡了一下。
第三，AI 天然只看局部。 它每次回答都是針對當前問題的“局部最優”——你讓它解決 A 問題用一種方式，解決 B 問題用另一種方式，放一起就打架。它可能為了解決當前問題引入一個新依賴，但你知道項目裏已經有類似的庫了。這些“整體視角”的判斷，只能你來做。
AI 很擅長把你騙進"完成感"，你覺得它寫完了，其實只是"能跑"，離"能用"還有一段距離。
還記得前面那個公式嗎？AI 是乘數，你是被乘數。前面說的拆分、全局、三問，就是那個被乘數——它決定了 AI 能把你放大到什麼程度。
怎麼培養工程思維
工程思維不是聽懂了就有，它更像肌肉，得靠反覆練才能長出來。
培養它的方法有很多，我自己最受用的是三個習慣：先拆分、先跑通、常覆盤。不一定適合所有人，也不一定是完整的，但可以作為一個參考。
先拆分
每次遇到一個任務，先別想着一口氣做完，先問自己：這個任務能不能拆成更小的任務？
我最近在輔導一年級的小兒子做數學，給他出了一道題：1+2+3+……+100 等於多少？他一看就懵了，不知道從哪下手。
我沒有直接教他公式，而是引導他先做一個更小的問題：1+2+3+……+10 等於多少？這個他能算，一個一個加，得出 55。
然後我讓他算 11+12+……+20，他又算出來了，是 155。
就這樣一段一段算下去，最後把十個小結果加起來，得到 5050。
這就是拆分：把一個讓你發懵的大問題，拆成一堆你能下手的小問題。
不寫代碼的場景也一樣。比如你想讓 AI 幫你寫一篇產品介紹，與其說“幫我寫個產品介紹”，不如拆成：先寫一句話說清楚這是什麼 → 再寫三個核心賣點 → 最後寫一段使用場景。拆開之後，每一步你都能判斷對不對，AI 也更容易給出你想要的東西。
先跑通，再優化
還是那道數學題。孩子用笨辦法算出 5050 之後，我帶他回頭覆盤。
我們從 1 到 10 開始，換一種算法：（1+10）+（2+9）+（3+8）+……每一對都是 11，一共 5 對，所以是 55。
他在我的引導下發現了規律。然後用同樣的思路算 1 到 100：（1+100）+（2+99）+……每一對是 101，一共 50 對，101×50=5050。比笨辦法快多了。
這就是“先跑通，再優化”：先用笨辦法把結果做出來，再回頭找更好的方法。
很多人的問題是反過來的，還沒跑通就想優化，結果兩頭都沒做好。先讓它跑起來，哪怕醜一點、慢一點；跑通之後再回頭看，哪裏可以做得更好。
常覆盤
每次做完一件事，問自己三個問題：
• 這次我做了哪些取捨？為什麼這樣選？ • 如果出了問題，最可能是哪裏？ • 如果重做一次，我會刪掉什麼、保留什麼？
這三個問題不只能幫你提升工程思維，也能幫你練品味。品味不是天賦，就是靠這種“做完了再想想”的習慣慢慢長出來的。
一個可以馬上用的動作
下次讓 AI 幹活之前，先花一分鐘寫幾行“最小規格”：
• 目標一句話 • 輸入是什麼，輸出是什麼 • 哪些必須對，哪些可以先湊合 • 最容易出問題的地方是什麼
舉個非技術的例子。假設你想讓 AI 幫你寫一段產品介紹：
目標：寫一段 200 字的產品介紹，讓第一次聽說的人能理解
輸入：產品的三個核心賣點 + 目標用戶是誰
輸出：標題 1 個 + 正文 200 字左右
必須對：不能誇大、不能有虛假承諾、要有具體使用場景
可以先湊合：語氣風格可以之後再調
最容易出問題：寫得像模板、沒有具體場景、賣點說得太抽象把這幾行發給 AI，再讓它開始寫。你會發現，生成的東西比“幫我寫個產品介紹”好一大截。
很多時候，“寫不出來的規格”，本質上是你自己還沒想清楚要做什麼。
長期這樣練，你會明顯感覺到變化：你越來越少被“不知道從哪下手”卡住，越來越多在做“拆解、取捨、驗證”的決定。這就是工程思維在發芽。
最後
Peter 在訪談最後說：
“你得自己去探索，找到自己的路。你需要時間才能變好。你得犯自己的錯誤。這是你學習任何東西的方式，學這個也一樣。只不過這個領域變化特別快。”
工程思維最後會變成一種氣質：你不再追求“寫得出來”，而是追求“交付後還能穩定運行”。
不知道從哪開始？
可以從今天就嘗試一下：下次讓 AI 幹活之前，先和 AI 對話，一起寫幾行“最小規格”。堅持幾次你會發現，AI 越來越聰明越來越懂你，你越來越能掌控 AI。