真正會用 AI 編程的人，都會做需求抽象
整理版優先睇
需求抽象係AI編程嘅核心能力，但要避免過度抽象；從定製化需求中提煉通用性，先問自己三次再下手。
呢篇文章係一個有五年項目交付經驗、後來轉做行業通用產品嘅開發者嘅親身分享。佢透過一個將視頻文案改寫成多種語言嘅定製需求，講述點樣從表面需求發掘真正問題：客戶話要泰文加中文對照，但真正需要嘅係「理解非母語文案」嘅能力。呢個思考令佢停低，唔係立即改Code，而係問自己：「下一個用戶要英文點算？」
佢回憶自己頭五年純粹做項目交付，求快求效率，寫咗好多爛Code，但從中磨練出理解各行各業需求嘅能力。之後轉做通用產品，養成咗「產品潔癖」——任何需求都會諗能唔能夠覆蓋更多場景。AI編碼出現後，呢種思維變成巨大槓桿，因為可以將定製個案抽象成通用參數，例如將「語言」同「翻譯範圍」變成配置項。
文章亦提醒過度抽象嘅陷阱，舉例自己曾為咗未來可能支援多種文檔格式而設計插件系統，結果半年只用咗兩種，變成認知負擔。佢引用DRY原則（唔好重複自己）同YAGNI（你唔會需要佢），指出三次重複係抽象信號，一次就要忍住。而家有AI輔助（例如Claude Code）可以快速分析需求變體，但判斷邊個時候抽象仍然係人類嘅工作。
- 結論：真正會用AI編程嘅人，會從表面需求挖掘更深層嘅核心問題，例如「理解非母語文案」而唔係「生成泰文對照」。
- 方法：將變量如「目標語言」、「翻譯範圍」抽象成參數，而非寫死喺代碼入面，令後續都變成配置問題。
- 差異：定製化思維只解決眼前個案，產品思維思考可覆蓋多種場景嘅通用方案，呢個係AI時代嘅關鍵槓桿。
- 啟發：三次重複係信號，一次出現係噪音；DRY原則重要，但YAGNI原則提醒唔好為未發生嘅未來過早抽象。
- 可行動點：先用AI工具（如Claude Code）分析需求，列出所有可能變化，然後根據出現次數同判斷力決定是否通用化。
一個需求引發嘅思考
去年10月，作者接咗個將視頻文案自動改寫成多種語言嘅項目。客戶好快要求：「生成嘅泰文我睇唔明，可唔可以加個中文對照？」如果純粹做定製，直接改Prompt就得。但作者停低諗：「如果下一個用戶係英文、日文、越南文呢？係咪每種語言都要改一次？」
佢發現真正需要嘅係「幫我理解非母語文案」，唔關泰語事，關「睇唔明」有關係。
五年爛Code教會我嘅事
作者坦白講，呢種敏感度唔係天生。佢入行頭五年純做項目交付，客戶要乜就寫乜，求快求效率，Code寫得好爛。但呢五年俾咗佢一個能力：面對任何行業需求，都有心機去理解，然後變成軟件。呢個過程仲將佢由一個極度I人磨成喺熟悉領域可以暢所欲言嘅人。
後來轉做行業通用產品，養成咗「產品潔癖」：任何需求過嚟，唔止諗點解決眼前，仲諗能唔能夠覆蓋更多場景。
- 前五年：追求效率，寫爛Code但學懂理解需求。
- 轉型後：從項目到產品，思維從定製變成通用。
- AI編碼到來：呢種思維變成巨大槓桿，可以快速抽象。
會議紀要、PDF論文：抽象通用化實戰
作者分享咗兩個類似案例。一個係客戶要求「會議紀要自動發去飛書」，但下個客戶可能要用釘釘或企業微信。另一個係「PDF論文翻譯成中文」，之後有人要求翻英文或只翻摘要。
真正需求唔係某個特定工具或語言，而係「會議結束後自動推送結論到團隊協作平台」同埋「翻譯指定範圍嘅文本」。
- 1 將「發送到飛書」抽象成「推送至協作平台」，預留webhook配置。
- 2 將「翻譯成中文」抽象成「目標語言」同「翻譯範圍」兩個參數，之後所有變體都係改配置。
AI降低門檻，但判斷力始終係人嘅
而家有AI輔助（例如Claude Code），可以將需求描述輸入，叫佢分析核心問題、強綁定當前場景嘅設計同未來可能受限嘅地方，甚至連交互草圖都俾埋。通用化設計嘅門檻低咗好多。
但門檻低唔代表判斷力唔重要。咩時候通用化、咩時候忍住唔抽象，呢個分寸感依然係人類嘅工作。
- 用AI工具列舉所有可能場景，但最終決定權喺你手。
- 不要為從未出現嘅未來設計複雜抽象層，維護成本會反噬。
舊年10月，我接咗個定製化需求，要將影片文案自動改寫成多種語言版本。
功能做完咗，客好快就畀咗個優化意見。
「而家生成嘅泰文我完全睇唔明，可唔可以畀個中文對照我？」
如果齋企喺純定製嘅角度，呢個需求其實好好改。目標語言泰文，輸出格式泰文加中文對照，提示詞打返出嚟，件事就搞掂。
但我當時停咗一下。
我問自己一個問題，咁如果下個客係英文呢？再下個係日文、越南文呢？
係咪每嚟一種語言，我就要重新寫過成套邏輯？
呢個時候你會發現一件事，需求本身唔複雜，複雜嘅係佢未來嘅變化。
用戶真正需要嘅，係一種能夠幫佢理解非母語文案嘅能力。同泰文無關，同「睇唔明」有關。
我覺得呢種思維方式，喺AI編程呢個領域裏面，特別值得反覆諗清楚。
講真呢種敏感度唔係天生嘅。
我啱入行嘅前五年，純粹做項目交付，求快，求效率，客要咩我就寫咩。
啲代碼寫得爛唔爛？爛。
而家返轉頭睇，好多功能簡直睇唔過眼。
但嗰五年畀咗我一樣嘢，就係面對各式各樣嘅需求，就算係完全陌生嘅行業，我都有意願、亦有能力去理解佢，將佢變成軟件。
順便講多句，我原本係個極度I人，就係呢五年同客死磨爛磨嘅過程，將我磨成一個喺熟悉領域都可以暢所欲言嘅人。
後嚟誤打誤撞，我轉咗去做行業通用產品。
面向嘅唔再係一個項目，而係一羣客、一堆場景。
呢個轉變逼住我養咗一種產品潔癖，任何需求過嚟，我唔單止諗點樣解決眼前呢個，仲會諗佢可唔可以覆蓋我認知範圍內嘅更多場景。
等到AI編碼嚟咗，我發現呢種思維方式突然變成咗一個巨大嘅槓桿。
做咗一年多嘅AI產品開發，遇到過太多類似嘅場景。
有個客話「幫我將會議紀要自動發去飛書羣度」，你可以直接寫死一個飛書webhook。
但你停一秒諗下，下個客可能要發去釘釘，再下個要發去企業微信。
真正嘅需求唔係「發去飛書」，係「會議結束後自動將結論推送去團隊協作平台」。
再舉個例，有人叫我整一個「將PDF論文翻譯成中文」嘅功能。
做完咗，下個人話可唔可以翻成英文，再下個話可唔可以淨係翻摘要。你一開始如果將「中文」寫死喺代碼裏面，後面次次都要改。
但如果你一開始就將佢抽象成「目標語言」加「翻譯範圍」兩個參數，後面所有變體都係配置問題，唔係開發問題。
坦白講，呢種從個案中提煉通用性嘅能力，唔係AI時代先有㗎。
1880年代電力開始喺美國普及嘅時候，每個工廠主都喺度解決自己嘅「定製化問題」，我部紡織機要幾多馬力，我個車間要點樣佈線。
但真正改變歷史嘅，係嗰啲睇到通用性嘅人。佢哋意識到，所有工廠需要嘅唔係「一部適合我嘅發電機」，而係「一個標準化嘅電力網絡」。
從定製到通用，從自建電站到公共電網，呢個躍遷花咗差唔多四十年。
軟件工程裏面都有個經典講法，叫DRY原則，Don't Repeat Yourself。
Andy Hunt同Dave Thomas喺《程序員修煉之道》入面提出呢個概念嘅時候，核心思想就係，每一個知識片段喺系統中應該只有一個單一、明確、權威嘅表示。
你重複寫三次同樣嘅邏輯，就代表未來要改三個地方，漏咗一個就係bug。
但是。
我必須要講句「但係」。
過度抽象呢件事，同樣係個陷阱。而且係個更隱蔽嘅陷阱。
軟件工程裏面仲有另一個原則叫YAGNI，You Ain't Gonna Need It。
極限編程嘅核心人物Ron Jeffries反覆強調呢一點，唔好為你想象中嘅未來需求寫代碼。
你覺得「以後肯定會有人要呢個功能」，結果嗰個以後永遠冇嚟，你嘅代碼庫裏面多咗一堆冇人用嘅抽象層，維護成本反而升咗。
我自己都踩過呢個坑。
有一次做一個文檔處理嘅功能，我覺得未來肯定會支援各種格式，於是一嚟就設計咗一套插件化嘅架構，定義咗一堆接口。
結果呢？半年過去咗，淨係用到Markdown同PDF兩種格式。
嗰套精心設計嘅插件系統，變咗純粹嘅認知負擔。
而且講真，而家有AI輔助，通用化設計嘅成本比以前低好多喇。
你將需求描述掉畀Claude Code，叫佢幫你分析「呢個需求真正想解決嘅核心問題係咩」「邊啲設計係強綁定當前場景嘅」「未來可能受限嘅地方喺邊」，佢幾乎可以將所有可能嘅場景列成一張矩陣。
連對應嘅交互設計草圖都可以一併畀出嚟。
以前呢種通用性嘅設計，要靠自己諗，都幾食經驗。
而家AI將呢個門檻拉低咗。
但門檻低咗唔代表判斷力唔重要。
幾時應該通用化，幾時應該剋制住抽象嘅衝動，呢個分寸感，依然係人嘅功夫。
嗰五年爛代碼教識我嘅嘢，AI替代唔到。
但佢教會我嘅判斷標準，我可以分享畀你。
定製化需求背後隱藏住通用化嘅機會，呢個係真嘅。但唔係每個機會都值得而家就捉實。
三次重複係訊號，一次出現係噪音。
分清楚呢兩者，然後對訊號出手，唔好猶豫。
多謝你睇我篇文章，如果覺得唔錯，幫手點讚三連、轉發畀有需要嘅人啦～
去年10月，我接了一個定製化需求，把視頻文案自動改寫成多種語言版本。
功能做完了，客戶很快提了一個優化意見。
「現在生成的泰文我完全看不懂，能不能給我一箇中文對照？」
如果站在純定製的角度，這個需求其實很好改。目標語言泰語，輸出格式泰文加中文對照，提示詞敲出來，事情結束。
但我當時停了一下。
我問自己一個問題，那如果下一個用戶是英文呢？再下一個是日文、越南文呢？
是不是每來一種語言，我就要重寫一套邏輯？
這時候你會發現一件事，需求本身不復雜，複雜的是它未來的變化。
用戶真正需要的，是一種能夠幫助理解非母語文案的能力。跟泰語沒關係，跟「看不懂」有關係。
我覺得這個思維方式，在AI編程這個領域裏，特別值得反覆琢磨。
說實話這種敏感度不是天生的。
我剛入行的前五年，純做項目交付，求快，求效率，客戶要什麼我就寫什麼。
代碼寫得爛不爛？爛。
現在回頭看，很多功能簡直不忍直視。
但那五年給了我一個東西，就是面對各種各樣的需求，哪怕完全陌生的行業，我都有意願、也有能力去理解它，把它變成軟件。
順帶說一句，我原本是個極度I人，就是這五年跟客戶死磕的過程，把我磨成了一個在熟悉領域也能暢所欲言的人。
後來誤打誤撞，我轉去做行業通用產品。
面向的不再是一個項目，而是一羣客戶、一堆場景。
這個轉變逼着我養成了一種產品潔癖，任何需求過來，我不光想怎麼解決眼前這個，還會想它能不能覆蓋我認知範圍內的更多場景。
等到AI編碼來了，我發現這種思維方式突然變成了一個巨大的槓桿。
做了一年多的AI產品開發，遇到過太多類似的場景。
有個客戶說「幫我把會議紀要自動發到飛書羣裏」，你可以直接寫死一個飛書webhook。
但你停一秒想想，下一個客戶可能要發到釘釘，再下一個要發到企業微信。
真正的需求不是「發到飛書」，是「會議結束後自動把結論推送到團隊協作平台」。
再比如，有人讓我做一個「把PDF論文翻譯成中文」的功能。
做完了，下一個人說能不能翻成英文，再下一個說能不能只翻摘要。你一開始要是把「中文」寫死在代碼裏，後面每次都得改。
但如果你一開始就把它抽象成「目標語言」加「翻譯範圍」兩個參數，後面所有變體都是配置問題，不是開發問題。
坦率的講，這種從個案中提煉通用性的能力，不是AI時代才有的。
1880年代電力開始在美國普及的時候，每個工廠主都在解決自己的「定製化問題」，我的紡織機要多大馬力，我的車間要怎麼佈線。
但真正改變歷史的，是那些看到了通用性的人。他們意識到，所有工廠需要的不是「一台適合我的發電機」，而是「一個標準化的電力網絡」。
從定製到通用，從自建電站到公共電網，這個躍遷花了將近四十年。
軟件工程裏也有個經典的說法，叫DRY原則，Don't Repeat Yourself。
Andy Hunt和Dave Thomas在《程序員修煉之道》裏提出這個概念的時候，核心思想就是，每一個知識片段在系統中應該只有一個單一的、明確的、權威的表示。
你重複寫三遍同樣的邏輯，就意味着未來要改三個地方，漏一個就是bug。
但是。
我必須說但是。
過度抽象這件事，同樣是個陷阱。而且是個更隱蔽的陷阱。
軟件工程裏還有另一個原則叫YAGNI，You Ain't Gonna Need It。
極限編程的核心人物Ron Jeffries反覆強調這一點，不要為你想象中的未來需求寫代碼。
你覺得「以後肯定會有人要這個功能」，結果那個以後永遠沒來，你的代碼庫裏多了一堆沒人用的抽象層，維護成本反而上去了。
我自己也踩過這個坑。
有一次做一個文檔處理的功能，我覺得未來肯定會支持各種格式，於是一上來就設計了一套插件化的架構，定義了一堆接口。
結果呢？半年過去了，只用到了Markdown和PDF兩種格式。
那套精心設計的插件系統，變成了純粹的認知負擔。
而且說實話，現在有AI輔助，通用化設計的成本比以前低太多了。
你把需求描述丟給Claude Code，讓它幫你分析「這個需求真正想解決的核心問題是什麼」「哪些設計是強綁定當前場景的」「未來可能受限的地方在哪」，它幾乎能把所有可能的場景列成一張矩陣。
連對應的交互設計草圖都能一併給出來。
以前這種通用性的設計，靠自己去想，挺吃經驗的。
現在AI把這個門檻拉低了。
但門檻低了不代表判斷力不重要了。
什麼時候該通用化，什麼時候該剋制住抽象的衝動，這個分寸感，依然是人的活兒。
那五年爛代碼教我的事，AI替代不了。
但它教會我的判斷標準，我可以分享給你。
定製化需求背後藏着通用化的機會，這是真的。但不是每個機會都值得現在就抓。
三次重複是信號，一次出現是噪音。
分清這兩者，然後對信號下手，別猶豫。
謝謝你看我的文章，如果覺得不錯，幫忙點贊三連、轉發給需要的人吧~