一个做了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%，然后转身去做下一件？
热门跟贴