為什麼資深開發者講不清自己的專業能力

你對下面呢句說話有咩感覺？

「AI智能體 (AI agents) 係軟件開發嘅未來。我哋以後唔使再要啲拖慢業務進度嘅開發人員喇。」

如果你係一位資深開發者，而且認同呢句話，咁我可能要對你嘅專業水平打個問號（我會解釋原因，我唔係專登撩交嗌）。

但係如果你不是資深開發者，卻認同呢句話，我覺得你大概率係啱嘅。

咦？呢件事到底係點樣？

廣告文案 (Copywriting) 嘅本質，其實就係令資訊精準匹配佢嘅受眾。

所以，喺我呢個文案工作者眼中，呢度發生嘅事係：同一句說話，喺兩類唔同嘅受眾聽起上嚟，有截然唔同嘅意思。

如果你係一位資深開發者，而且你已經玩過啲令人大開眼界嘅 AI 智能體、大模型同埋各種花巧嘅 AI 技能，但你嘅直覺依然話俾你聽：「大家都係度宣揚程序員要失業喇，呢件事聽起上嚟總係覺得唔對路」。咁喺呢篇文章入面，我會嘗試將你這種講唔清道唔明嘅直覺，用清晰嘅文字表達出嚟（呢正係一個優秀文案應該做嘅嘢）。

但係等陣！而家都有好多經驗豐富嘅知名開發者喺度宣告「程序員已死」。

呢件事又係點樣？到底邊個嘅直覺係啱？係咩導致咗呢種分歧？

當我加入一個團隊嗰陣，通常會遇到兩類資深開發者。

第一類會講咁樣嘅說話：

「我發現咗一個新工具，簡直太勁喇……」

「某某公司（一間同我哋業務完全唔關事嘅公司）就係咁做，所以……」

「快啲睇 HackerNews 上面呢篇帖，上面話呢個係最佳實踐，我哋或者應該……」

講真話，我唔係好鐘意呢類資深開發者。佢哋通常有啲自我保護慾，喺行業入面做咗好耐，可能人緣都幾好。但我哋就唔喺同一個頻道。

跟住係第二類資深開發者：

「我哋真係需要嗰個功能咩？」

「如果我哋唔做呢樣嘢，會發生咩事？」

「我哋可唔可以先是但住先？或者等佢變得更重要嘅時候再返轉頭搞？」

啊，寶貝，呢個先係我嘅「夢中情怪」資深開發者。佢哋係迴避者、精簡者、廢物利用者。佢哋想盡一切辦法去避免寫 code。

點解？因為佢哋喺專業嘅軟件開發生涯入面，成世都在狩獵一隻可怕嘅怪物：複雜性 (Complexity)。

各種特殊情況、一大堆嘅 if 條件判斷、新開嘅數據庫表、全新嘅組件。呢啲全部都係令人頭痛嘅大麻煩（因為佢哋極大增加咗系統維護同理解嘅難度）。資深開發者希望呢啲嘢越少越好，佢哋會花大量時間去反覆確認，係咪真係非寫呢段 code 不可。

因為幫系統做加法，就代表增加咗複雜性嘅風險。

係嘅，係嘅，我承認咁講有啲太過絕對。當然有好多資深開發者擅長攻克未解難題，並提出富有創意嘅新架構。

但係歸根結底，如果你要對一個正在平穩運行嘅系統負責，你就會對複雜性感到恐懼。

咁，呢件事到底係點解呢？複雜性到底有咩壞處？又點解其他人都無法理解呢種恐懼呢？

我哋打算用兩個「循環圈」嚟簡化並解釋一間公司嘅運作方式。

呢個係第一個循環圈；市場營銷人員、銷售人員、產品經理同埋 CEO，佢哋都生活喺呢個圈入面：

第一個循環：業務團隊透過快速嘗試、市場反饋同學習，持續降低不確定性。

呢個循環嘅核心目標係嘗試同學習。企業想將產品推向市場，然後獲取反饋，睇下佢哋搞出嚟嘅嘢到底有無價值。

對於身處呢個循環入面嘅人嚟講，佢哋要面對嘅怪物係：不確定性 (Uncertainty)。

不確定性係殘酷嘅，因為冇任何策略能保證百分百奏效。當不確定性與時間交織喺一齊時（比如營銷同銷售嘅薪水、創始人嘅工資賬單，或者產品經理急需嘅數據），你會覺得：喺死線到嚟之前，盡可能快啲將啲嘢推向市場，似乎係降低不確定性嘅唯一途徑。你推向市場嘅嘢越多，得到嘅反饋就越多，你（潛在地）消除嘅不確定性亦都越多。

呢個循環——都係所有公司起步時嘅必經之路——追求嘅係純粹嘅、原始嘅速度。

但係，當一間公司開始有客戶時，會發生咩事呢？

啊哈，而家，我哋嘅第二個循環圈登場喇。人們開始為服務俾錢喇。

第二個循環：付費客戶依賴現有服務，資深開發者透過控制複雜性嚟維持長期穩定。

好多資深開發者就身處呢個循環圈中。呢個循環嘅核心目標係：延續並保障服務嘅穩定。

保持系統運轉，保持 code 易讀，保持問題可調試，保持故障可修復，保持架構可傳授俾新人，最重要嘅係，保持穩定。

資深開發者之所以操心穩定性，係因為佢哋肩負住令公司能夠持續為客戶提供服務嘅重任。

而咩會威脅到呢一切？

複雜性。

複雜性會令系統變得難以理解、難以調試、難以修復、難以交接，並最終導致系統變得極唔穩定。

複雜性上升 = 穩定性下降 = 資深開發者失職 = 糟到極點，客戶付款中斷，所有人都愁眉苦面。

所以，如果話第一個循環嘅目標係「消除不確定性」，咁第二個循環嘅目標就係「管理複雜性」。

但呢個點解會導致溝通上嘅失敗呢？

因為一旦你有了客戶，呢兩個循環圈就會同時運轉。一間公司既要探索新嘅可能性，又要同時服務好現有嘅客戶。

有客戶之後，公司必須同時探索新可能，亦都要守住現有客戶。

好喇，而家你可能已經估到我對文章標題嗰個問題嘅答案。

根據你將時間主要花喺邊一個循環圈入面，你對問題嘅認知框架係完全唔同嘅（呢個亦即係點解我認為開發者喺對待 AI 嘅觀點上會產生分歧；有些人更多咁喺第一個循環入面工作，而另一些人則喺第二個循環入面）。

同一個需求，兩種解讀：業務睇到更快驗證，開發者睇到更多 code 路徑同維護成本。

喺第一個循環圈入面嘅人，佢哋嘅故事係咁樣：

業務端嘅故事：佢哋要嘅唔係 code 本身，而係更快知道答案。

但喺第二個循環圈入面嘅資深開發者，佢哋嘅故事卻係咁樣：

開發者嘅故事：真正嘅專業價值，係用更少複雜性換嚟更快確定性。

呢兩種故事根本搭唔上調。

資深開發者接到嘅「新增功能」需求越多，佢哋就越想回嗆：「呃，唔得……呢個太複雜喇……維護成本太高……code 冇辦法讀……後續開發速度會變慢……長遠嚟睇會拖累生產力……」

但係，呢啲牢騷對於業務端「急需消除不確定性」嘅訴求嚟講，毫無幫助。

文案嘅診斷結果：你唔可以用你自己嘅煩惱，去敷衍人哋嘅問題。

文案開出嘅處方：你一定要將你嘅解決方案，包裝成同樣能夠解決佢哋問題嘅方案。

資深開發者之所以溝通失敗，係因為佢哋總係用「複雜性管理」嘅邏輯嚟表達自己嘅苦衷，而佢哋原本應該用「消除不確定性」嘅邏輯嚟推銷自己嘅解決方案。

只要資深開發者能夠意識到公司其他部門真正渴望嘅係消除不確定性，佢哋就能夠利用自己嘅專業能力嚟提供幫助。

咁，資深開發者最拿手嘅本領係咩？係唔情願去開發冇必要嘅嘢；係能夠敏鋭咁發現重用現有 code 嘅機會。

需要收集問卷數據？ 用 Google 表單就得啦，寶貝。

需要開發一個新功能嚟做測試？ 你哋有冇試過喺現有嘅 UI 界面上加個假按鈕，睇下有冇人㩒？（亦即係所謂嘅「畫餅測試」或驗證性測試）

需要一套新嘅數據分析服務？ 我哋需要睇數據嚟做出嘅最關鍵決策係咩？我哋可唔可以淨係針對呢一個決策，先做一個圖表、睇一個指標？

你想費事俾我焗個完整嘅生日蛋糕？ 算啦，直接喺我嘅三文治上面插支蠟燭就得。

呢個就係資深開發者學到嘅生存之道：佢哋學識咗如何利用現有嘅軟件資源，巧妙地俾人哋想要嘅嘢。

但係，你應該如何溝通呢一點，而唔使每次都俾人寫篇小作文呢？

文案們最鐘意將一堆複雜嘅資訊濃縮成一句簡短有力嘅話。所以，呢度有一句每個資深開發者都必須背誦嘅魔法口訣：「我哋可唔可以試個更快嘅辦法？」

用「更快 (quicker)」呢個詞，係承認並迎合咗業務端真正嘅渴望（速度）；「辦法 (something)」暗示咗仲有別嘅方式可以達成目標；而「試 (try)」則暗示咗呢個方案可能唔完美，但可能已經足夠好。

呢句話完美咁切中咗公司其他部門嘅核心需求——用速度嚟消除不確定性，同時亦令資深開發者能夠盡情施展佢哋嘅專業特長：精簡功能、重用 code，如果老天爺保佑嘅話，完全避免開發。

就係咁樣。呢個就係我對文章標題嘅回答：當所有人都在為「不確定性」搞到頭都大時，資深開發者卻總係將「複雜性」掛喺嘴邊。

但係！重大嘅轉折嚟喇！

而家嘅 AI 似乎令呢一切變得毫無意義，唔係咩？點解仲要精簡？點解仲要重用？點解仲要避免開發？AI 可以喺極短時間內寫出海量嘅 code。

唉，話雖如此，但有一件事 AI 到而家仲做唔到，而呢個正係資深開發者依然喺度堅持做嘅事。

承擔責任 (Take responsibility)——孭鑊。

你對下面這句話有什麼感覺？

“AI 智能體 (AI agents) 是軟件開發的未來。我們再也不需要那些拖慢業務進度的開發人員了。”

如果你是一位資深開發者，並且認同這句話，那我可能要對你的專業水平打個問號了（我會解釋原因的，我並不是在故意找茬）。

但如果你不是資深開發者，卻認同這句話，我覺得你大概率是對的。

咦？這到底是怎麼回事？

廣告文案 (Copywriting) 的本質，其實就是讓信息精準匹配它的受眾。

所以，在我這個文案工作者看來，這裏發生的事情是：同一句話，在兩類不同的受眾聽來，有着截然不同的含義。

如果你是一位資深開發者，並且你已經玩過那些讓人大開眼界的 AI 智能體、大模型以及各種花哨的 AI 技能，但你的直覺依然告訴你：“大家都在宣揚程序員要失業了，這事兒聽起來總覺得哪裏不對勁”。那麼在這篇文章裏，我將嘗試把你這種說不清道不明的直覺，用清晰的文字表達出來（這正是一個優秀文案該乾的活）。

但是等一下！現在也有很多經驗豐富的知名開發者在宣告“程序員已死”。

這又是怎麼回事？到底誰的直覺是對的？是什麼導致了這種分歧？

當我加入一個團隊時，通常會遇到兩類資深開發者。

第一類會說這樣的話：

“我發現了一個新工具，簡直太酷了……”

“某某公司（一家和我們業務完全不搭邊的公司）就是這麼幹的，所以……”

“快看 HackerNews 上的這篇帖子，上面說這是最佳實踐，我們也許應該……”

說實話，我不太喜歡這類資深開發者。他們往往有點自我保護欲，在行業裏混了很久，可能人緣還不錯。但我們就是不在一個頻道上。

接着是第二類資深開發者：

“我們真的需要那個功能嗎？”

“如果我們不做這個，會發生什麼？”

“我們能不能先湊合一下？也許等它變得更重要的時候再回過頭來弄？”

啊，寶貝，這才是我的“夢中情怪”資深開發者。他們是迴避者、精簡者、廢物利用者。他們想盡一切辦法去避免寫代碼。

為什麼？因為他們在專業的軟件開發生涯中，畢生都在狩獵一隻可怕的怪物：複雜性 (Complexity)。

各種特殊情況、一堆的 if 條件判斷、新建的數據庫表、全新的組件。這些全都是讓人頭疼的大麻煩（因為它們極大增加了系統維護和理解的難度）。資深開發者希望這些東西越少越好，他們會花大量時間去反覆確認，是不是真的非寫這段代碼不可。

因為給系統做加法，就意味着增加了複雜性的風險。

是的，是的，我承認這麼說有些過於絕對了。當然有很多資深開發者擅長攻克未解難題，並提出富有創意的新架構。

但歸根結底，如果你要對一個正在平穩運行的系統負責，你就會對複雜性感到恐懼。

那麼，這到底是為什麼呢？複雜性到底有什麼壞處？又為什麼其他人都無法理解這種恐懼呢？

我們打算用兩個“循環圈”來簡化並解釋一家公司的運作方式。

這是第一個循環圈；市場營銷人員、銷售人員、產品經理以及 CEO，他們都生活在這個圈裏：

第一個循環：業務團隊通過快速嘗試、市場反饋和學習，持續降低不確定性。

這個循環的核心目標是嘗試與學習。企業想要把產品推向市場，然後獲取反饋，看看他們搞出來的東西到底有沒有價值。

對於身處這個循環裏的人來說，他們要面對的怪物是：不確定性 (Uncertainty)。

不確定性是殘酷的，因為沒有任何策略能保證百分之百奏效。當不確定性與時間交織在一起時（比如營銷和銷售的薪水、創始人的工資賬單，或者產品經理急需的數據），你會感覺：在死線到來之前，儘可能快地把東西推向市場，似乎是降低不確定性的唯一途徑。你推向市場的東西越多，得到的反饋就越多，你（潛在地）消除的不確定性也就越多。

這個循環——也是所有公司起步時的必經之路——追求的是純粹的、原始的速度。

但是，當一家公司開始擁有客戶時，會發生什麼呢？

啊哈，現在，我們的第二個循環圈登場了。人們開始為服務付費了。

第二個循環：付費客戶依賴現有服務，資深開發者通過控制複雜性來維持長期穩定。

很多資深開發者就身處這個循環圈中。這個循環的核心目標是：延續並保障服務的穩定。

保持系統運轉，保持代碼易讀，保持問題可調試，保持故障可修復，保持架構可傳授給新人，最重要的是，保持穩定。

資深開發者之所以操心穩定性，是因為他們肩負着讓公司能夠持續為客戶提供服務的重任。

而什麼會威脅到這一切？

複雜性。

複雜性會讓系統變得難以理解、難以調試、難以修復、難以交接，並最終導致系統變得極不穩定。

複雜性上升 = 穩定性下降 = 資深開發者失職 = 糟糕透頂，客戶付款中斷，所有人都愁眉苦臉。

所以，如果說第一個循環的目標是“消除不確定性”，那麼第二個循環的目標就是“管理複雜性”。

但這為什麼會導致溝通上的失敗呢？

因為一旦你有了客戶，這兩個循環圈就會同時運轉。一家公司既需要探索新的可能性，又必須同時服務好現有的客戶。

有客戶之後，公司必須同時探索新可能，也必須守住現有客戶。

好了，現在你可能已經猜到我對文章標題那個問題的答案了。

根據你把時間主要花在哪一個循環圈裏，你對問題的認知框架是完全不同的（這也就是為什麼我認為開發者在對待 AI 的觀點上會產生分歧；有些人更多地在第一個循環裏工作，而另一些人則在第二個循環裏）。

同一個需求，兩種解讀：業務看到更快驗證，開發者看到更多代碼路徑和維護成本。

在第一個循環圈裏的人，他們的故事是這樣的：

業務端的故事：他們要的不是代碼本身，而是更快知道答案。

但在第二個循環圈裏的資深開發者，他們的故事卻是這樣的：

開發者的故事：真正的專業價值，是用更少複雜性換來更快確定性。

這兩種故事根本搭不上調。

資深開發者接到的“新增功能”需求越多，他們就越想回懟：“呃，不行……這太複雜了……維護成本太高……代碼沒法讀了……後續開發速度會變慢……長期來看會拖累生產力……”。

但是，這些牢騷對於業務端“急需消除不確定性”的訴求來說，毫無幫助。

文案的診斷結果：你不能用你自己的煩惱，去搪塞別人的問題。

文案開出的處方：你必須把你的解決方案，包裝成同樣能解決他們問題的方案。

資深開發者之所以溝通失敗，是因為他們總是在用“複雜性管理”的邏輯來表達自己的苦衷，而他們本該用“消除不確定性”的邏輯來推銷自己的解決方案。

只要資深開發者能意識到公司其他部門真正渴望的是消除不確定性，他們就能利用自己的專業能力來提供幫助了。

那麼，資深開發者最拿手的本領是什麼？是不情願去開發沒必要的東西；是能夠敏鋭地發現複用現有代碼的機會。

需要收集問卷數據？ 用 Google 表單就行了，寶貝。

需要開發一個新功能來做測試？ 你們有沒有試過在現有的 UI 界面上加個假按鈕，看看有沒有人點？（也就是所謂的“畫餅測試”或驗證性測試）

需要一套新的數據分析服務？ 我們需要看數據來做出的最關鍵決策是什麼？我們能不能只針對這一個決策，先做一個圖表、看一個指標？

你想費勁給我烤個完整的生日蛋糕？ 算了吧，直接在我的三明治上插根蠟燭就行。

這就是資深開發者學到的生存之道：他們學會了如何利用現有的軟件資源，巧妙地給別人想要的東西。

但是，你該如何溝通這一點，而不至於每次都要給別人寫篇小作文呢？

文案們最喜歡把一堆複雜的信息濃縮成一句簡短有力的話。所以，這裏有一句每個資深開發者都必須背誦的魔法口訣：“我們能不能試個更快的辦法？”

用“更快 (quicker)”這個詞，是承認並迎合了業務端真正的渴望（速度）；“辦法 (something)”暗示了還有別的方式可以達成目標；而“試 (try)”則暗示了這個方案可能並不完美，但很可能已經足夠好了。

這句話完美地切中了公司其他部門的核心需求——用速度來消除不確定性，同時也讓資深開發者能夠盡情施展他們的專業特長：精簡功能、複用代碼，如果老天保佑的話，完全避免開發。

就是這樣。這就是我對文章標題的回答：當所有人都在為“不確定性”焦頭爛額時，資深開發者卻總是在把“複雜性”掛在嘴邊。

但是！大大的轉折來了！

現在的 AI 似乎讓這一切都變得毫無意義了，不是嗎？為什麼還要精簡？為什麼還要複用？為什麼還要避免開發？AI 可以在極短的時間內寫出海量的代碼。

唉，話雖如此，但有一件事 AI 至今還做不到，而這也正是資深開發者依然在堅持做的事。

承擔責任 (Take responsibility)——背鍋。