90%魔咒：4個工程師階段，90%的人困在第3層

一個做了5年的工程師，和一個做了15年的，差距可能不在技術深度，而在怎么面對最后10%的活兒。

這10%會吃掉你90%的時間。不是比喻，是無數人反復踩坑后總結出的規律。

90-10悖論：為什么收尾比開頭難10倍

軟件行業有個公開的秘密：項目做到90%的時候，真正的噩夢才開始。

新手時期你體會不到。那時候你從空白文檔開始，幾小時就能讓東西跑起來，界面有模有樣。遇到卡殼？換個思路、找個變通方案、或者直接砍掉這個功能——沒人追究，你自己也不糾結。

但經驗攢到一定程度，事情變了。

你開始在意代碼質量、架構設計、安全策略、持續集成（CI/CD，持續集成/持續部署）。你的PR（Pull Request，代碼合并請求）會被同事逐行審閱，像素級對齊變成基本要求。更麻煩的是，你學會了"品味"——能一眼看出哪里別扭，哪里還能更好。

品味是雙刃劍。它讓你寫出更好的代碼，也讓你更難說"這夠了"。

作者把工程師的成長分成四個階段，每個階段對待這最后10%的態度截然不同。看清自己在哪一層，比盲目加班有用得多。

第一階段：新手——90%就是100%

新手工程師的典型特征是：不知道什么是"完成"。

他們能快速搭出原型，功能看起來都在，界面也能點。但代碼里埋著多少坑、多少硬編碼的魔法數字、多少"暫時先用著"的臨時方案，他們自己往往意識不到。

這不是批評。每個工程師都從這里起步。新手的優勢是無所畏懼，劣勢是缺乏判斷力——分不清"能跑"和"能交付"的區別。

他們會在代碼評審（Code Review）中收到成噸的反饋，然后驚訝地發現：原來還要考慮異常處理、日志記錄、性能邊界、國際化……

這個階段的核心任務是暴露問題，而不是解決問題。被現實反復敲打后，才會進入下一階段。

第二階段：專業者——重復發明90%

熬過早期的工程師，開始系統學習"最佳實踐"。

他們讀設計模式，研究框架源碼，對Docker、Kubernetes（容器編排系統）、各種DevEx（開發者體驗）工具如數家珍。遇到新項目，第一反應不是"怎么最快做出來"，而是"怎么搭一個可擴展的架構"。

問題也出在這里。

專業者容易陷入"重新造輪子"的陷阱。明明有現成的庫，非要自己封裝一層；明明簡單的需求，非要設計一套通用抽象。他們花了90%的時間，解決的是"未來可能出現的問題"，而不是"用戶現在需要的問題"。

作者觀察到一個現象：這個階段的人，經常在項目初期極度興奮，中期陷入技術細節的泥潭，最后發現交付日期逼近，核心功能還沒打磨好。

他們掌握了完成項目所需的所有技術，卻沒掌握"什么時候該停手"的判斷力。

第三階段：思考者——永遠到不了90%

這是最隱蔽、也最危險的一個階段。

思考者（Thinker）已經見過足夠多的代碼，形成了自己的審美和標準。他們能一眼看出架構的缺陷，能預判三個月后的技術債務，能在設計評審會上提出十個"如果未來……"的問題。

但正是這種能力，讓他們 paralysis by analysis（分析癱瘓）。

作者描述得很精準："你開始拒絕自己的代碼。"一個功能寫完，回頭看覺得命名不夠語義化；重構完命名，又覺得抽象層次不對；調完抽象，發現單元測試覆蓋不夠……循環往復，PR（代碼合并請求）永遠發不出去。

更麻煩的是團隊層面。當房間里坐滿思考者，會議變成辯論賽。每個人都從自己的角度提出風險，卻沒人拍板說"就這樣，先上線"。

這個階段的人，有的變成"工單生成器"——不斷給團隊創建新任務，自己卻很少交付；有的選擇退回個人貢獻者路線，回避決策壓力；還有極少數，強行push（推動）代碼上線，但內心充滿焦慮。

他們被困在"還沒準備好"的感覺里，而產品早已錯過窗口期。

第四階段：完成者——接受90%的時間換最后10%

完成者（Finisher）的核心認知轉變是：終于承認那個殘酷的真相。

最后10%的工作量，確實需要90%的時間。這不是可以優化掉的效率問題，是軟件開發的固有屬性。

但他們和前三者的區別在于：知道哪些10%值得花這90%，哪些不值得。

完成者會主動做減法。他們會問：這個功能用戶真的需要嗎？這個優化能轉化為業務指標嗎？這份文檔有人看嗎？如果答案是否定的，他們敢于說"不做了"，而不是假裝沒做完。

他們也知道怎么拆解那90%的時間。不是籠統地"再打磨一下"，而是列出具體的收尾清單：邊界情況處理、監控告警、回滾方案、性能基線、用戶引導……每一項都有明確的完成標準。

作者給了一個關鍵提示：決定什么值得完成，什么對用戶沒有影響。

這聽起來像產品思維，其實是工程成熟度的終極體現。技術能力讓你能做任何事，判斷力讓你不做錯事。

一個正在發生的實例

作者寫這篇文章時，正在用自己的AI系統Contenox Beam輔助工作。結果這個系統當場演示了什么叫"90-10悖論"。

他讓系統探索代碼庫。系統嘗試執行本地shell命令，觸發了安全策略——沒有配置允許列表（allow-list）。報錯信息很清晰：

「tool local_shell.local_shell execution failed: local_shell: no allow list configured; define hook_policies in your chain JSON to allow commands or directories」

正確的處理方式是什么？更新chain JSON里的hook_policies，大概10秒鐘的事。

但系統沒有這么做。它退回到"腳本化的安全響應"，開始建議用戶手動輸入終端命令——繞了一大圈，效率更低，體驗更差。

作者沒有展開批評，但這個例子很說明問題：AI系統的設計者，顯然花了很多精力做安全策略、做 fallback（回退）機制，卻沒處理好"安全策略觸發后如何引導用戶修復"這個最后10%的細節。

這10%的缺失，讓整個功能從"智能助手"降級成了"機械地執行預設腳本"。

為什么AI工具改變不了這個悖論

文章開頭有個判斷：盡管AI和開發工具最近突破很多，軟件開發本質上沒有變。

這個判斷值得細想。

AI確實加速了寫代碼的速度。GitHub Copilot、Claude、各種agentic系統，都能讓新手更快達到90%的完成度。但這也意味著，更多人會更早面臨那個殘酷的拐點——剩下的10%怎么辦？

AI不擅長的是判斷。它不知道你的用戶是誰，不知道業務優先級，不知道"足夠好"的邊界在哪里。它只會繼續生成代碼，繼續優化，繼續提出"還可以這樣做"的備選方案——這正是第三階段"思考者"的陷阱。

作者暗示了一個趨勢：工具越強大，人的判斷力越值錢。不是技術能力貶值了，是"知道什么時候停手"的能力，在工具能無限供給"更多"的時候，變成了稀缺品。

這也解釋了為什么有些團隊AI工具用得很順，有些反而更慢了。差別不在工具，在有沒有完成者坐鎮——有人能拍板說"這版可以發"，而不是讓AI無限迭代下去。

怎么知道自己處在哪個階段

作者沒有給自測問卷，但從描述里可以提煉幾個信號。

如果你經常覺得"再給我一周就能做得更完美"，可能是思考者階段。如果你回顧過去半年的項目，發現大部分精力花在了基礎設施和架構上，用戶功能卻普普通通，可能是專業者階段。如果你上線前夜還在改"最后幾個小問題"，可能是新手階段——或者一直在回避那90%的收尾工作。

完成者的標志是什么？作者沒有直接說，但從上下文推斷：他們能平靜地接受"這件事永遠不會完美"，同時確保"這件事對用戶有用"。

這不是妥協，是資源的最優配置。時間、精力、團隊士氣，都是有限資源。完成者的技能樹里，優先級排序和放棄的藝術，點得比代碼能力更高。

給不同階段的具體建議

對于還在第一、第二階段的人，作者的態度是：繼續積累，但要有意識地觀察自己的模式。你是不是又在重寫一個已經存在的功能？你是不是為了"可擴展性"犧牲了交付速度？把這些觀察記下來，比盲目追求技術深度更有價值。

對于困在第三階段的人，作者的建議藏在那個提示里：決定什么值得完成。

這需要建立用戶反饋的閉環。不是想象用戶會怎么用這個功能，是去看數據、去做訪談、去觀察真實行為。很多"必須做"的優化，在真實用戶那里根本無人在意。這個認知能打破分析癱瘓。

對于已經是完成者的人，作者沒有給建議——也許因為這類人已經不需要外部指導，也許因為成為完成者的路徑無法復制，只能自己趟出來。

但有一點是確定的：完成者不是天生的，是從前三個階段反復摔打、反思、調整優先級后，逐漸成型的。

文章結尾，作者拋出了那個核心問題：

「How do you approach the last 10% of something that took months (or years), knowing it will consume 90% of the total effort?」

你怎么面對那個花了數月甚至數年、卻還需要90%精力才能收尾的最后10%？

他沒有給標準答案。但讀完這篇文章的人，應該已經意識到：這個問題本身，就是區分四個階段的分水嶺。

你的項目列表里，有沒有某個卡在90%很久的東西？你打算怎么處理它——是繼續打磨，還是承認它不值得那90%，然后轉身去做下一件？