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

這10%會(huì)吃掉你90%的時(shí)間。不是比喻，是無(wú)數(shù)人反復(fù)踩坑后總結(jié)出的規(guī)律。

90-10悖論：為什么收尾比開(kāi)頭難10倍

軟件行業(yè)有個(gè)公開(kāi)的秘密：項(xiàng)目做到90%的時(shí)候，真正的噩夢(mèng)才開(kāi)始。

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

但經(jīng)驗(yàn)攢到一定程度，事情變了。

你開(kāi)始在意代碼質(zhì)量、架構(gòu)設(shè)計(jì)、安全策略、持續(xù)集成（CI/CD，持續(xù)集成/持續(xù)部署）。你的PR（Pull Request，代碼合并請(qǐng)求）會(huì)被同事逐行審閱，像素級(jí)對(duì)齊變成基本要求。更麻煩的是，你學(xué)會(huì)了"品味"——能一眼看出哪里別扭，哪里還能更好。

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

作者把工程師的成長(zhǎng)分成四個(gè)階段，每個(gè)階段對(duì)待這最后10%的態(tài)度截然不同?？辞遄约涸谀囊粚樱让つ考影嘤杏玫枚?。

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

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

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

這不是批評(píng)。每個(gè)工程師都從這里起步。新手的優(yōu)勢(shì)是無(wú)所畏懼，劣勢(shì)是缺乏判斷力——分不清"能跑"和"能交付"的區(qū)別。

他們會(huì)在代碼評(píng)審（Code Review）中收到成噸的反饋，然后驚訝地發(fā)現(xiàn)：原來(lái)還要考慮異常處理、日志記錄、性能邊界、國(guó)際化……

這個(gè)階段的核心任務(wù)是暴露問(wèn)題，而不是解決問(wèn)題。被現(xiàn)實(shí)反復(fù)敲打后，才會(huì)進(jìn)入下一階段。

第二階段：專(zhuān)業(yè)者——重復(fù)發(fā)明90%

熬過(guò)早期的工程師，開(kāi)始系統(tǒng)學(xué)習(xí)"最佳實(shí)踐"。

他們讀設(shè)計(jì)模式，研究框架源碼，對(duì)Docker、Kubernetes（容器編排系統(tǒng)）、各種DevEx（開(kāi)發(fā)者體驗(yàn)）工具如數(shù)家珍。遇到新項(xiàng)目，第一反應(yīng)不是"怎么最快做出來(lái)"，而是"怎么搭一個(gè)可擴(kuò)展的架構(gòu)"。

問(wèn)題也出在這里。

專(zhuān)業(yè)者容易陷入"重新造輪子"的陷阱。明明有現(xiàn)成的庫(kù)，非要自己封裝一層；明明簡(jiǎn)單的需求，非要設(shè)計(jì)一套通用抽象。他們花了90%的時(shí)間，解決的是"未來(lái)可能出現(xiàn)的問(wèn)題"，而不是"用戶(hù)現(xiàn)在需要的問(wèn)題"。

作者觀(guān)察到一個(gè)現(xiàn)象：這個(gè)階段的人，經(jīng)常在項(xiàng)目初期極度興奮，中期陷入技術(shù)細(xì)節(jié)的泥潭，最后發(fā)現(xiàn)交付日期逼近，核心功能還沒(méi)打磨好。

他們掌握了完成項(xiàng)目所需的所有技術(shù)，卻沒(méi)掌握"什么時(shí)候該停手"的判斷力。

第三階段：思考者——永遠(yuǎn)到不了90%

這是最隱蔽、也最危險(xiǎn)的一個(gè)階段。

思考者（Thinker）已經(jīng)見(jiàn)過(guò)足夠多的代碼，形成了自己的審美和標(biāo)準(zhǔn)。他們能一眼看出架構(gòu)的缺陷，能預(yù)判三個(gè)月后的技術(shù)債務(wù)，能在設(shè)計(jì)評(píng)審會(huì)上提出十個(gè)"如果未來(lái)……"的問(wèn)題。

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

作者描述得很精準(zhǔn)："你開(kāi)始拒絕自己的代碼。"一個(gè)功能寫(xiě)完，回頭看覺(jué)得命名不夠語(yǔ)義化；重構(gòu)完命名，又覺(jué)得抽象層次不對(duì)；調(diào)完抽象，發(fā)現(xiàn)單元測(cè)試覆蓋不夠……循環(huán)往復(fù)，PR（代碼合并請(qǐng)求）永遠(yuǎn)發(fā)不出去。

更麻煩的是團(tuán)隊(duì)層面。當(dāng)房間里坐滿(mǎn)思考者，會(huì)議變成辯論賽。每個(gè)人都從自己的角度提出風(fēng)險(xiǎn)，卻沒(méi)人拍板說(shuō)"就這樣，先上線(xiàn)"。

這個(gè)階段的人，有的變成"工單生成器"——不斷給團(tuán)隊(duì)創(chuàng)建新任務(wù)，自己卻很少交付；有的選擇退回個(gè)人貢獻(xiàn)者路線(xiàn)，回避決策壓力；還有極少數(shù)，強(qiáng)行push（推動(dòng)）代碼上線(xiàn)，但內(nèi)心充滿(mǎn)焦慮。

他們被困在"還沒(méi)準(zhǔn)備好"的感覺(jué)里，而產(chǎn)品早已錯(cuò)過(guò)窗口期。

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

完成者（Finisher）的核心認(rèn)知轉(zhuǎn)變是：終于承認(rèn)那個(gè)殘酷的真相。

最后10%的工作量，確實(shí)需要90%的時(shí)間。這不是可以?xún)?yōu)化掉的效率問(wèn)題，是軟件開(kāi)發(fā)的固有屬性。

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

完成者會(huì)主動(dòng)做減法。他們會(huì)問(wèn)：這個(gè)功能用戶(hù)真的需要嗎？這個(gè)優(yōu)化能轉(zhuǎn)化為業(yè)務(wù)指標(biāo)嗎？這份文檔有人看嗎？如果答案是否定的，他們敢于說(shuō)"不做了"，而不是假裝沒(méi)做完。

他們也知道怎么拆解那90%的時(shí)間。不是籠統(tǒng)地"再打磨一下"，而是列出具體的收尾清單：邊界情況處理、監(jiān)控告警、回滾方案、性能基線(xiàn)、用戶(hù)引導(dǎo)……每一項(xiàng)都有明確的完成標(biāo)準(zhǔn)。

作者給了一個(gè)關(guān)鍵提示：決定什么值得完成，什么對(duì)用戶(hù)沒(méi)有影響。

這聽(tīng)起來(lái)像產(chǎn)品思維，其實(shí)是工程成熟度的終極體現(xiàn)。技術(shù)能力讓你能做任何事，判斷力讓你不做錯(cuò)事。

一個(gè)正在發(fā)生的實(shí)例

作者寫(xiě)這篇文章時(shí)，正在用自己的AI系統(tǒng)Contenox Beam輔助工作。結(jié)果這個(gè)系統(tǒng)當(dāng)場(chǎng)演示了什么叫"90-10悖論"。

他讓系統(tǒng)探索代碼庫(kù)。系統(tǒng)嘗試執(zhí)行本地shell命令，觸發(fā)了安全策略——沒(méi)有配置允許列表（allow-list）。報(bào)錯(cuò)信息很清晰：

「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秒鐘的事。

但系統(tǒng)沒(méi)有這么做。它退回到"腳本化的安全響應(yīng)"，開(kāi)始建議用戶(hù)手動(dòng)輸入終端命令——繞了一大圈，效率更低，體驗(yàn)更差。

作者沒(méi)有展開(kāi)批評(píng)，但這個(gè)例子很說(shuō)明問(wèn)題：AI系統(tǒng)的設(shè)計(jì)者，顯然花了很多精力做安全策略、做 fallback（回退）機(jī)制，卻沒(méi)處理好"安全策略觸發(fā)后如何引導(dǎo)用戶(hù)修復(fù)"這個(gè)最后10%的細(xì)節(jié)。

這10%的缺失，讓整個(gè)功能從"智能助手"降級(jí)成了"機(jī)械地執(zhí)行預(yù)設(shè)腳本"。

為什么AI工具改變不了這個(gè)悖論

文章開(kāi)頭有個(gè)判斷：盡管AI和開(kāi)發(fā)工具最近突破很多，軟件開(kāi)發(fā)本質(zhì)上沒(méi)有變。

這個(gè)判斷值得細(xì)想。

AI確實(shí)加速了寫(xiě)代碼的速度。GitHub Copilot、Claude、各種agentic系統(tǒng)，都能讓新手更快達(dá)到90%的完成度。但這也意味著，更多人會(huì)更早面臨那個(gè)殘酷的拐點(diǎn)——剩下的10%怎么辦？

AI不擅長(zhǎng)的是判斷。它不知道你的用戶(hù)是誰(shuí)，不知道業(yè)務(wù)優(yōu)先級(jí)，不知道"足夠好"的邊界在哪里。它只會(huì)繼續(xù)生成代碼，繼續(xù)優(yōu)化，繼續(xù)提出"還可以這樣做"的備選方案——這正是第三階段"思考者"的陷阱。

作者暗示了一個(gè)趨勢(shì)：工具越強(qiáng)大，人的判斷力越值錢(qián)。不是技術(shù)能力貶值了，是"知道什么時(shí)候停手"的能力，在工具能無(wú)限供給"更多"的時(shí)候，變成了稀缺品。

這也解釋了為什么有些團(tuán)隊(duì)AI工具用得很順，有些反而更慢了。差別不在工具，在有沒(méi)有完成者坐鎮(zhèn)——有人能拍板說(shuō)"這版可以發(fā)"，而不是讓AI無(wú)限迭代下去。

怎么知道自己處在哪個(gè)階段

作者沒(méi)有給自測(cè)問(wèn)卷，但從描述里可以提煉幾個(gè)信號(hào)。

如果你經(jīng)常覺(jué)得"再給我一周就能做得更完美"，可能是思考者階段。如果你回顧過(guò)去半年的項(xiàng)目，發(fā)現(xiàn)大部分精力花在了基礎(chǔ)設(shè)施和架構(gòu)上，用戶(hù)功能卻普普通通，可能是專(zhuān)業(yè)者階段。如果你上線(xiàn)前夜還在改"最后幾個(gè)小問(wèn)題"，可能是新手階段——或者一直在回避那90%的收尾工作。

完成者的標(biāo)志是什么？作者沒(méi)有直接說(shuō)，但從上下文推斷：他們能平靜地接受"這件事永遠(yuǎn)不會(huì)完美"，同時(shí)確保"這件事對(duì)用戶(hù)有用"。

這不是妥協(xié)，是資源的最優(yōu)配置。時(shí)間、精力、團(tuán)隊(duì)士氣，都是有限資源。完成者的技能樹(shù)里，優(yōu)先級(jí)排序和放棄的藝術(shù)，點(diǎn)得比代碼能力更高。

給不同階段的具體建議

對(duì)于還在第一、第二階段的人，作者的態(tài)度是：繼續(xù)積累，但要有意識(shí)地觀(guān)察自己的模式。你是不是又在重寫(xiě)一個(gè)已經(jīng)存在的功能？你是不是為了"可擴(kuò)展性"犧牲了交付速度？把這些觀(guān)察記下來(lái)，比盲目追求技術(shù)深度更有價(jià)值。

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

這需要建立用戶(hù)反饋的閉環(huán)。不是想象用戶(hù)會(huì)怎么用這個(gè)功能，是去看數(shù)據(jù)、去做訪(fǎng)談、去觀(guān)察真實(shí)行為。很多"必須做"的優(yōu)化，在真實(shí)用戶(hù)那里根本無(wú)人在意。這個(gè)認(rèn)知能打破分析癱瘓。

對(duì)于已經(jīng)是完成者的人，作者沒(méi)有給建議——也許因?yàn)檫@類(lèi)人已經(jīng)不需要外部指導(dǎo)，也許因?yàn)槌蔀橥瓿烧叩穆窂綗o(wú)法復(fù)制，只能自己趟出來(lái)。

但有一點(diǎn)是確定的：完成者不是天生的，是從前三個(gè)階段反復(fù)摔打、反思、調(diào)整優(yōu)先級(jí)后，逐漸成型的。

文章結(jié)尾，作者拋出了那個(gè)核心問(wèn)題：

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

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

他沒(méi)有給標(biāo)準(zhǔn)答案。但讀完這篇文章的人，應(yīng)該已經(jīng)意識(shí)到：這個(gè)問(wèn)題本身，就是區(qū)分四個(gè)階段的分水嶺。

你的項(xiàng)目列表里，有沒(méi)有某個(gè)卡在90%很久的東西？你打算怎么處理它——是繼續(xù)打磨，還是承認(rèn)它不值得那90%，然后轉(zhuǎn)身去做下一件？