为什么资深开发者讲不清自己的专业能力 · AI HOT
宝玉@dotey70
2026-05-15 09:25·49天前
AI 摘要资深开发者与业务团队存在根本认知差异。业务团队生活在“消除不确定性”的循环中，追求快速试错验证，核心是速度。而资深开发者身处“管理复杂性”的循环，核心职责是保障付费服务的长期稳定，因此对增加系统复杂性的行为极为警惕。沟通失败在于，开发者用“控制复杂性”的理由拒绝需求，却未回应业务端“消除不确定性”的迫切诉求。解决方案是，开发者应将其精简需求、复用代码等专业能力，包装成能帮助业务“更快获得答案”的方案，例如使用“我们能不能试个更快的办法？”这样的话术。尽管AI能快速生成代码，但资深开发者不可替代的价值在于为系统长期稳定“承担责任”。
宝玉@dotey · X 2026-05-15 09:25·49天前
在 X 看原推· x.comAI 摘要资深开发者与业务团队存在根本认知差异。业务团队生活在“消除不确定性”的循环中，追求快速试错验证，核心是速度。而资深开发者身处“管理复杂性”的循环，核心职责是保障付费服务的长期稳定，因此对增加系统复杂性的行为极为警惕。沟通失败在于，开发者用“控制复杂性”的理由拒绝需求，却未回应业务端“消除不确定性”的迫切诉求。解决方案是，开发者应将其精简需求、复用代码等专业能力，包装成能帮助业务“更快获得答案”的方案，例如使用“我们能不能试个更快的办法？”这样的话术。尽管AI能快速生成代码，但资深开发者不可替代的价值在于为系统长期稳定“承担责任”。
我们打算用两个"循环圈"来简化并解释一家公司的运作方式。
这是第一个循环圈；市场营销人员、销售人员、产品经理以及 CEO，他们都生活在这个圈里：
第一个循环：业务团队通过快速尝试、市场反馈和学习，持续降低不确定性。
这个循环的核心目标是尝试与学习。企业想要把产品推向市场，然后获取反馈，看看他们搞出来的东西到底有没有价值。
对于身处这个循环里的人来说，他们要面对的怪物是：不确定性 （Uncertainty）。
不确定性是残酷的，因为没有任何策略能保证百分之百奏效。当不确定性与时间交织在一起时（比如营销和销售的薪水、创始人的工资账单，或者产品经理急需的数据），你会感觉：在死线到来之前，尽可能快地把东西推向市场，似乎是降低不确定性的唯一途径。你推向市场的东西越多，得到的反馈就越多，你（潜在地）消除的不确定性也就越多。
这个循环--也是所有公司起步时的必经之路--追求的是纯粹的、原始的速度。
啊哈，现在，我们的第二个循环圈登场了。人们开始为服务付费了。
第二个循环：付费客户依赖现有服务，资深开发者通过控制复杂性来维持长期稳定。
很多资深开发者就身处这个循环圈中。这个循环的核心目标是：延续并保障服务的稳定。
保持系统运转，保持代码易读，保持问题可调试，保持故障可修复，保持架构可传授给新人，最重要的是，保持稳定。
资深开发者之所以操心稳定性，是因为他们肩负着让公司能够持续为客户提供服务的重任。
复杂性会让系统变得难以理解、难以调试、难以修复、难以交接，并最终导致系统变得极不稳定。
复杂性上升 = 稳定性下降 = 资深开发者失职 = 糟糕透顶，客户付款中断，所有人都愁眉苦脸。
所以，如果说第一个循环的目标是"消除不确定性"，那么第二个循环的目标就是"管理复杂性"。
因为一旦你有了客户，这两个循环圈就会同时运转。一家公司既需要探索新的可能性，又必须同时服务好现有的客户。
有客户之后，公司必须同时探索新可能，也必须守住现有客户。
好了，现在你可能已经猜到我对文章标题那个问题的答案了。
根据你把时间主要花在哪一个循环圈里，你对问题的认知框架是完全不同的（这也就是为什么我认为开发者在对待 AI 的观点上会产生分歧；有些人更多地在第一个循环里工作，而另一些人则在第二个循环里）。
同一个需求，两种解读：业务看到更快验证，开发者看到更多代码路径和维护成本。
业务端的故事：他们要的不是代码本身，而是更快知道答案。
但在第二个循环圈里的资深开发者，他们的故事却是这样的：
开发者的故事：真正的专业价值，是用更少复杂性换来更快确定性。
资深开发者接到的"新增功能"需求越多，他们就越想回怼："呃，不行……这太复杂了……维护成本太高……代码没法读了……后续开发速度会变慢……长期来看会拖累生产力……"。
但是，这些牢骚对于业务端"急需消除不确定性"的诉求来说，毫无帮助。
文案的诊断结果：你不能用你自己的烦恼，去搪塞别人的问题。
文案开出的处方：你必须把你的解决方案，包装成同样能解决他们问题的方案。
资深开发者之所以沟通失败，是因为他们总是在用"复杂性管理"的逻辑来表达自己的苦衷，而他们本该用"消除不确定性"的逻辑来推销自己的解决方案。
只要资深开发者能意识到公司其他部门真正渴望的是消除不确定性，他们就能利用自己的专业能力来提供帮助了。
那么，资深开发者最拿手的本领是什么？是不情愿去开发没必要的东西；是能够敏锐地发现复用现有代码的机会。
需要收集问卷数据？ 用 Google 表单就行了，宝贝。
需要开发一个新功能来做测试？ 你们有没有试过在现有的 UI 界面上加个假按钮，看看有没有人点？（也就是所谓的"画饼测试"或验证性测试）
需要一套新的数据分析服务？ 我们需要看数据来做出的最关键决策是什么？我们能不能只针对这一个决策，先做一个图表、看一个指标？
你想费劲给我烤个完整的生日蛋糕？ 算了吧，直接在我的三明治上插根蜡烛就行。
这就是资深开发者学到的生存之道：他们学会了如何利用现有的软件资源，巧妙地给别人想要的东西。
但是，你该如何沟通这一点，而不至于每次都要给别人写篇小作文呢？
文案们最喜欢把一堆复杂的信息浓缩成一句简短有力的话。所以，这里有一句每个资深开发者都必须背诵的魔法口诀："我们能不能试个更快的办法？"
用"更快 （quicker）"这个词，是承认并迎合了业务端真正的渴望（速度）；"办法 （something）"暗示了还有别的方式可以达成目标；而"试 （try）"则暗示了这个方案可能并不完美，但很可能已经足够好了。
这句话完美地切中了公司其他部门的核心需求--用速度来消除不确定性，同时也让资深开发者能够尽情施展他们的专业特长：精简功能、复用代码，如果老天保佑的话，完全避免开发。
就是这样。这就是我对文章标题的回答：当所有人都在为"不确定性"焦头烂额时，资深开发者却总是在把"复杂性"挂在嘴边。
现在的 AI 似乎让这一切都变得毫无意义了，不是吗？为什么还要精简？为什么还要复用？为什么还要避免开发？AI 可以在极短的时间内写出海量的代码。
唉，话虽如此，但有一件事 AI 至今还做不到，而这也正是资深开发者依然在坚持做的事。
承担责任 （Take responsibility）--背锅。
如果你是一位资深开发者，并且你已经玩过那些让人大开眼界的 AI 智能体、大模型以及各种花哨的 AI 技能，但你的直觉依然告诉你："大家都在宣扬程序员要失业了，这事儿听起来总觉得哪里不对劲"。那么在这篇文章里，我将尝试把你这种说不清道不明的直觉，用清晰的文字表达出来（这正是一个优秀文案该干的活）。
但是等一下！现在也有很多经验丰富的知名开发者在宣告"程序员已死"。
这又是怎么回事？到底谁的直觉是对的？是什么导致了这种分歧？
"我发现了一个新工具，简直太酷了……""某某公司（一家和我们业务完全不搭边的公司）就是这么干的，所以……""快看 HackerNews 上的这篇帖子，上面说这是最佳实践，我们也许应该……"
说实话，我不太喜欢这类资深开发者。他们往往有点自我保护欲，在行业里混了很久，可能人缘还不错。但我们就是不在一个频道上。
"我们真的需要那个功能吗？""如果我们不做这个，会发生什么？""我们能不能先凑合一下？也许等它变得更重要的时候再回过头来弄？"
啊，宝贝，这才是我的"梦中情怪"资深开发者。他们是回避者、精简者、废物利用者。他们想尽一切办法去避免写代码。
为什么？因为他们在专业的软件开发生涯中，毕生都在狩猎一只可怕的怪物：复杂性 （Complexity）。
各种特殊情况、一堆的 if 条件判断、新建的数据库表、全新的组件。这些全都是让人头疼的大麻烦（因为它们极大增加了系统维护和理解的难度）。资深开发者希望这些东西越少越好，他们会花大量时间去反复确认，是不是真的非写这段代码不可。
是的，是的，我承认这么说有些过于绝对了。当然有很多资深开发者擅长攻克未解难题，并提出富有创意的新架构。
但归根结底，如果你要对一个正在平稳运行的系统负责，你就会对复杂性感到恐惧。
那么，这到底是为什么呢？复杂性到底有什么坏处？又为什么其他人都无法理解这种恐惧呢？
我们打算用两个"循环圈"来简化并解释一家公司的运作方式。
这是第一个循环圈；市场营销人员、销售人员、产品经理以及 CEO，他们都生活在这个圈里：
第一个循环：业务团队通过快速尝试、市场反馈和学习，持续降低不确定性。
这个循环的核心目标是尝试与学习。企业想要把产品推向市场，然后获取反馈，看看他们搞出来的东西到底有没有价值。
对于身处这个循环里的人来说，他们要面对的怪物是：不确定性 （Uncertainty）。
不确定性是残酷的，因为没有任何策略能保证百分之百奏效。当不确定性与时间交织在一起时（比如营销和销售的薪水、创始人的工资账单，或者产品经理急需的数据），你会感觉：在死线到来之前，尽可能快地把东西推向市场，似乎是降低不确定性的唯一途径。你推向市场的东西越多，得到的反馈就越多，你（潜在地）消除的不确定性也就越多。
这个循环--也是所有公司起步时的必经之路--追求的是纯粹的、原始的速度。
啊哈，现在，我们的第二个循环圈登场了。人们开始为服务付费了。
第二个循环：付费客户依赖现有服务，资深开发者通过控制复杂性来维持长期稳定。
很多资深开发者就身处这个循环圈中。这个循环的核心目标是：延续并保障服务的稳定。
保持系统运转，保持代码易读，保持问题可调试，保持故障可修复，保持架构可传授给新人，最重要的是，保持稳定。
资深开发者之所以操心稳定性，是因为他们肩负着让公司能够持续为客户提供服务的重任。
复杂性会让系统变得难以理解、难以调试、难以修复、难以交接，并最终导致系统变得极不稳定。
复杂性上升 = 稳定性下降 = 资深开发者失职 = 糟糕透顶，客户付款中断，所有人都愁眉苦脸。
所以，如果说第一个循环的目标是"消除不确定性"，那么第二个循环的目标就是"管理复杂性"。
因为一旦你有了客户，这两个循环圈就会同时运转。一家公司既需要探索新的可能性，又必须同时服务好现有的客户。
有客户之后，公司必须同时探索新可能，也必须守住现有客户。
好了，现在你可能已经猜到我对文章标题那个问题的答案了。
根据你把时间主要花在哪一个循环圈里，你对问题的认知框架是完全不同的（这也就是为什么我认为开发者在对待 AI 的观点上会产生分歧；有些人更多地在第一个循环里工作，而另一些人则在第二个循环里）。
同一个需求，两种解读：业务看到更快验证，开发者看到更多代码路径和维护成本。
业务端的故事：他们要的不是代码本身，而是更快知道答案。
但在第二个循环圈里的资深开发者，他们的故事却是这样的：
开发者的故事：真正的专业价值，是用更少复杂性换来更快确定性。
资深开发者接到的"新增功能"需求越多，他们就越想回怼："呃，不行……这太复杂了……维护成本太高……代码没法读了……后续开发速度会变慢……长期来看会拖累生产力……"。
但是，这些牢骚对于业务端"急需消除不确定性"的诉求来说，毫无帮助。
文案的诊断结果：你不能用你自己的烦恼，去搪塞别人的问题。
文案开出的处方：你必须把你的解决方案，包装成同样能解决他们问题的方案。
资深开发者之所以沟通失败，是因为他们总是在用"复杂性管理"的逻辑来表达自己的苦衷，而他们本该用"消除不确定性"的逻辑来推销自己的解决方案。
只要资深开发者能意识到公司其他部门真正渴望的是消除不确定性，他们就能利用自己的专业能力来提供帮助了。
那么，资深开发者最拿手的本领是什么？是不情愿去开发没必要的东西；是能够敏锐地发现复用现有代码的机会。
需要收集问卷数据？ 用 Google 表单就行了，宝贝。
需要开发一个新功能来做测试？ 你们有没有试过在现有的 UI 界面上加个假按钮，看看有没有人点？（也就是所谓的"画饼测试"或验证性测试）
需要一套新的数据分析服务？ 我们需要看数据来做出的最关键决策是什么？我们能不能只针对这一个决策，先做一个图表、看一个指标？
你想费劲给我烤个完整的生日蛋糕？ 算了吧，直接在我的三明治上插根蜡烛就行。
这就是资深开发者学到的生存之道：他们学会了如何利用现有的软件资源，巧妙地给别人想要的东西。
但是，你该如何沟通这一点，而不至于每次都要给别人写篇小作文呢？
文案们最喜欢把一堆复杂的信息浓缩成一句简短有力的话。所以，这里有一句每个资深开发者都必须背诵的魔法口诀："我们能不能试个更快的办法？"
用"更快 （quicker）"这个词，是承认并迎合了业务端真正的渴望（速度）；"办法 （something）"暗示了还有别的方式可以达成目标；而"试 （try）"则暗示了这个方案可能并不完美，但很可能已经足够好了。
这句话完美地切中了公司其他部门的核心需求--用速度来消除不确定性，同时也让资深开发者能够尽情施展他们的专业特长：精简功能、复用代码，如果老天保佑的话，完全避免开发。
就是这样。这就是我对文章标题的回答：当所有人都在为"不确定性"焦头烂额时，资深开发者却总是在把"复杂性"挂在嘴边。
现在的 AI 似乎让这一切都变得毫无意义了，不是吗？为什么还要精简？为什么还要复用？为什么还要避免开发？AI 可以在极短的时间内写出海量的代码。
唉，话虽如此，但有一件事 AI 至今还做不到，而这也正是资深开发者依然在坚持做的事。
承担责任 （Take responsibility）--背锅。