你對下面這句話有什麼感覺？
“AI 智能體 (AI agents) 是軟件開發的未來。我們再也不需要那些拖慢業務進度的開發人員了。”
如果你是一位資深開發者，並且認同這句話，那我可能要對你的專業水平打個問號了（我會解釋原因的，我並不是在故意找茬）。
但如果你 不是 資深開發者，卻認同這句話，我覺得你大概率是對的。
咦？這到底是怎麼回事？
廣告文案 (Copywriting) 的本質，其實就是讓信息精準匹配它的受衆。
所以，在我這個文案工作者看來，這裏發生的事情是：同一句話，在兩類不同的受衆聽來，有着截然不同的含義。
如果你是一位資深開發者，並且你已經玩過那些讓人大開眼界的 AI 智能體、大模型以及各種花哨的 AI 技能，但你的直覺依然告訴你：“大家都在宣揚程序員要失業了，這事兒聽起來總覺得哪裏不對勁”。那麼在這篇文章裏，我將嘗試把你這種說不清道不明的直覺，用清晰的文字表達出來（這正是一個優秀文案該乾的活）。
但是等一下！現在也有很多經驗豐富的知名開發者在宣告“程序員已死”。
這又是怎麼回事？到底誰的直覺是對的？是什麼導致了這種分歧？
當我加入一個團隊時，通常會遇到兩類資深開發者。
第一類會說這樣的話：
“我發現了一個新工具，簡直太酷了……”
“某某公司（一家和我們業務完全不搭邊的公司）就是這麼幹的，所以……”
“快看 HackerNews 上的這篇帖子，上面說這是最佳實踐，我們也許應該……”
說實話，我不太喜歡這類資深開發者。他們往往有點自我保護欲，在行業裏混了很久，可能人緣還不錯。但我們就是不在一個頻道上。
接着是第二類資深開發者：
“我們真的需要那個功能嗎？”
“如果我們不做這個，會發生什麼？”
“我們能不能先湊合一下？也許等它變得更重要的時候再回過頭來弄？”
啊，寶貝，這纔是我的“夢中情怪”資深開發者。他們是迴避者、精簡者、廢物利用者。他們想盡一切辦法去避免寫代碼。
爲什麼？因爲他們在專業的軟件開發生涯中，畢生都在狩獵一隻可怕的怪物： 複雜性 (Complexity) 。
各種特殊情況、一堆的 if 條件判斷、新建的數據庫表、全新的組件。這些全都是讓人頭疼的大麻煩 （因爲它們極大增加了系統維護和理解的難度） 。資深開發者希望這些東西越少越好，他們會花大量時間去反覆確認，是不是真的非寫這段代碼不可。
因爲給系統做加法，就意味着增加了複雜性的風險。
是的，是的，我承認這麼說有些過於絕對了。當然有很多資深開發者擅長攻克未解難題，並提出富有創意的新架構。
但歸根結底，如果你要對一個正在平穩運行的系統負責，你就會對複雜性感到恐懼。
那麼，這到底是爲什麼呢？複雜性到底有什麼壞處？又爲什麼其他人都無法理解這種恐懼呢？
我們打算用兩個“循環圈”來簡化並解釋一家公司的運作方式。
這是第一個循環圈；市場營銷人員、銷售人員、產品經理以及 CEO，他們都生活在這個圈裏：
第一個循環：業務團隊通過快速嘗試、市場反饋和學習，持續降低不確定性。
這個循環的核心目標是嘗試與學習。企業想要把產品推向市場，然後獲取反饋，看看他們搞出來的東西到底有沒有價值。
對於身處這個循環裏的人來說，他們要面對的怪物是： 不確定性 (Uncertainty) 。
不確定性是殘酷的，因爲沒有任何策略能保證百分之百奏效。當不確定性與時間交織在一起時（比如營銷和銷售的薪水、創始人的工資賬單，或者產品經理急需的數據），你會感覺：在死線到來之前，儘可能快地把東西推向市場，似乎是降低不確定性的唯一途徑。你推向市場的東西越多，得到的反饋就越多，你（潛在地）消除的不確定性也就越多。
這個循環——也是所有公司起步時的必經之路——追求的是純粹的、原始的速度。
但是，當一家公司開始擁有客戶時，會發生什麼呢？
啊哈，現在，我們的第二個循環圈登場了。人們開始爲服務付費了。
第二個循環：付費客戶依賴現有服務，資深開發者通過控制複雜性來維持長期穩定。
很多資深開發者就身處這個循環圈中。這個循環的核心目標是： 延續並保障服務的穩定 。
保持系統運轉，保持代碼易讀，保持問題可調試，保持故障可修復，保持架構可傳授給新人，最重要的是，保持穩定。
資深開發者之所以操心穩定性，是因爲他們肩負着讓公司能夠持續爲客戶提供服務的重任。
而什麼會威脅到這一切？
複雜性。
複雜性會讓系統變得難以理解、難以調試、難以修復、難以交接，並最終導致系統變得極不穩定。
複雜性上升 = 穩定性下降 = 資深開發者失職 = 糟糕透頂，客戶付款中斷，所有人都愁眉苦臉。
所以，如果說第一個循環的目標是“消除不確定性”，那麼第二個循環的目標就是“管理複雜性”。
但這爲什麼會導致溝通上的失敗呢？
因爲一旦你有了客戶，這兩個循環圈就會同時運轉。一家公司既需要探索新的可能性，又必須同時服務好現有的客戶。
有客戶之後，公司必須同時探索新可能，也必須守住現有客戶。
好了，現在你可能已經猜到我對文章標題那個問題的答案了。
根據你把時間主要花在哪一個循環圈裏，你對問題的認知框架是完全不同的（這也就是爲什麼我認爲開發者在對待 AI 的觀點上會產生分歧；有些人更多地在第一個循環裏工作，而另一些人則在第二個循環裏）。
同一個需求，兩種解讀：業務看到更快驗證，開發者看到更多代碼路徑和維護成本。
在第一個循環圈裏的人，他們的故事是這樣的：
業務端的故事：他們要的不是代碼本身，而是更快知道答案。
但在第二個循環圈裏的資深開發者，他們的故事卻是這樣的：
開發者的故事：真正的專業價值，是用更少複雜性換來更快確定性。
這兩種故事根本搭不上調。
資深開發者接到的“新增功能”需求越多，他們就越想回懟：“呃，不行……這太複雜了……維護成本太高……代碼沒法讀了……後續開發速度會變慢……長期來看會拖累生產力……”。
但是，這些牢騷對於業務端“急需消除不確定性”的訴求來說，毫無幫助。
文案的診斷結果： 你不能用你自己的煩惱，去搪塞別人的問題。
文案開出的處方： 你必須把你的解決方案，包裝成同樣能解決他們問題的方案。
資深開發者之所以溝通失敗，是因爲他們總是在用“複雜性管理”的邏輯來表達自己的苦衷，而他們本該用“消除不確定性”的邏輯來推銷自己的解決方案。
只要資深開發者能意識到公司其他部門真正渴望的是消除不確定性，他們就能利用自己的專業能力來提供幫助了。
那麼，資深開發者最拿手的本領是什麼？是不情願去開發沒必要的東西；是能夠敏銳地發現複用現有代碼的機會。
需要收集問卷數據？ 用 Google 表單就行了，寶貝。
需要開發一個新功能來做測試？ 你們有沒有試過在現有的 UI 界面上加個假按鈕，看看有沒有人點？ （也就是所謂的“畫餅測試”或驗證性測試）
需要一套新的數據分析服務？ 我們需要看數據來做出的最關鍵決策是什麼？我們能不能只針對這一個決策，先做一個圖表、看一個指標？
你想費勁給我烤個完整的生日蛋糕？ 算了吧，直接在我的三明治上插根蠟燭就行。
這就是資深開發者學到的生存之道：他們學會了如何利用現有的軟件資源，巧妙地給別人想要的東西。
但是，你該如何溝通這一點，而不至於每次都要給別人寫篇小作文呢？
文案們最喜歡把一堆複雜的信息濃縮成一句簡短有力的話。所以，這裏有一句每個資深開發者都必須背誦的魔法口訣：“我們能不能試個更快的辦法？”
用“更快 (quicker)”這個詞，是承認並迎合了業務端真正的渴望（速度）；“辦法 (something)”暗示了還有別的方式可以達成目標；而“試 (try)”則暗示了這個方案可能並不完美，但很可能已經足夠好了。
這句話完美地切中了公司其他部門的核心需求——用速度來消除不確定性，同時也讓資深開發者能夠盡情施展他們的專業特長：精簡功能、複用代碼，如果老天保佑的話，完全避免開發。
就是這樣。這就是我對文章標題的回答：當所有人都在爲“不確定性”焦頭爛額時，資深開發者卻總是在把“複雜性”掛在嘴邊。
但是！大大的轉折來了！
現在的 AI 似乎讓這一切都變得毫無意義了，不是嗎？爲什麼還要精簡？爲什麼還要複用？爲什麼還要避免開發？AI 可以在極短的時間內寫出海量的代碼。
唉，話雖如此，但有一件事 AI 至今還做不到，而這也正是資深開發者依然在堅持做的事。
承擔責任 (Take responsibility)——背鍋。