资深开发者为何难以讲清专业价值 ✍ 宝玉🕐 2026-05-15📦 11.0 KB 🟢 已读 𝕏 文章列表 本文探讨了资深开发者常面临的沟通困境。作者通过“业务消除不确定性”与“开发管理复杂性”的双循环模型,指出两者目标错位导致了沟通隔阂。文章强调,资深开发者应学会转换视角,用业务能听懂的语言(如“能不能试个更快的办法”)来推销其简化复杂性的专业方案,而非单纯抱怨技术债。最后指出,即便AI时代,承担责任依然是开发者的核心价值。 资深开发者团队协作沟通技巧业务思维复杂度管理 # 为什么资深开发者讲不清自己的专业能力 **作者**: 宝玉 **日期**: 2026-05-15T01:25:39.000Z **来源**: [https://x.com/dotey/status/2055097242755706984](https://x.com/dotey/status/2055097242755706984) ---  作者:Tuhin Nair 原文:Why senior developers fail to communicate their expertise 你对下面这句话有什么感觉? > “AI 智能体 (AI agents) 是软件开发的未来。我们再也不需要那些拖慢业务进度的开发人员了。” 如果你是一位资深开发者,并且认同这句话,那我可能要对你的专业水平打个问号了(我会解释原因的,我并不是在故意找茬)。 但如果你不是资深开发者,却认同这句话,我觉得你大概率是对的。 咦?这到底是怎么回事? 广告文案 (Copywriting) 的本质,其实就是让信息精准匹配它的受众。 所以,在我这个文案工作者看来,这里发生的事情是:同一句话,在两类不同的受众听来,有着截然不同的含义。 如果你是一位资深开发者,并且你已经玩过那些让人大开眼界的 AI 智能体、大模型以及各种花哨的 AI 技能,但你的直觉依然告诉你:“大家都在宣扬程序员要失业了,这事儿听起来总觉得哪里不对劲”。那么在这篇文章里,我将尝试把你这种说不清道不明的直觉,用清晰的文字表达出来(这正是一个优秀文案该干的活)。 但是等一下!现在也有很多经验丰富的知名开发者在宣告“程序员已死”。 这又是怎么回事?到底谁的直觉是对的?是什么导致了这种分歧? 当我加入一个团队时,通常会遇到两类资深开发者。 第一类会说这样的话: > “我发现了一个新工具,简直太酷了……”“某某公司(一家和我们业务完全不搭边的公司)就是这么干的,所以……”“快看 HackerNews 上的这篇帖子,上面说这是最佳实践,我们也许应该……” 说实话,我不太喜欢这类资深开发者。他们往往有点自我保护欲,在行业里混了很久,可能人缘还不错。但我们就是不在一个频道上。 接着是第二类资深开发者: > “我们真的需要那个功能吗?”“如果我们不做这个,会发生什么?”“我们能不能先凑合一下?也许等它变得更重要的时候再回过头来弄?” 啊,宝贝,这才是我的“梦中情怪”资深开发者。他们是回避者、精简者、废物利用者。他们想尽一切办法去避免写代码。 为什么?因为他们在专业的软件开发生涯中,毕生都在狩猎一只可怕的怪物:复杂性 (Complexity)。 各种特殊情况、一堆的 if 条件判断、新建的数据库表、全新的组件。这些全都是让人头疼的大麻烦**(因为它们极大增加了系统维护和理解的难度)**。资深开发者希望这些东西越少越好,他们会花大量时间去反复确认,是不是真的非写这段代码不可。 因为给系统做加法,就意味着增加了复杂性的风险。 是的,是的,我承认这么说有些过于绝对了。当然有很多资深开发者擅长攻克未解难题,并提出富有创意的新架构。 但归根结底,如果你要对一个正在平稳运行的系统负责,你就会对复杂性感到恐惧。 那么,这到底是为什么呢?复杂性到底有什么坏处?又为什么其他人都无法理解这种恐惧呢? 我们打算用两个“循环圈”来简化并解释一家公司的运作方式。 这是第一个循环圈;市场营销人员、销售人员、产品经理以及 CEO,他们都生活在这个圈里:  第一个循环:业务团队通过快速尝试、市场反馈和学习,持续降低不确定性。 这个循环的核心目标是尝试与学习。企业想要把产品推向市场,然后获取反馈,看看他们搞出来的东西到底有没有价值。 对于身处这个循环里的人来说,他们要面对的怪物是:不确定性 (Uncertainty)。 不确定性是残酷的,因为没有任何策略能保证百分之百奏效。当不确定性与时间交织在一起时(比如营销和销售的薪水、创始人的工资账单,或者产品经理急需的数据),你会感觉:在死线到来之前,尽可能快地把东西推向市场,似乎是降低不确定性的唯一途径。你推向市场的东西越多,得到的反馈就越多,你(潜在地)消除的不确定性也就越多。 这个循环——也是所有公司起步时的必经之路——追求的是纯粹的、原始的速度。 但是,当一家公司开始拥有客户时,会发生什么呢? 啊哈,现在,我们的第二个循环圈登场了。人们开始为服务付费了。  第二个循环:付费客户依赖现有服务,资深开发者通过控制复杂性来维持长期稳定。 很多资深开发者就身处这个循环圈中。这个循环的核心目标是:延续并保障服务的稳定。 保持系统运转,保持代码易读,保持问题可调试,保持故障可修复,保持架构可传授给新人,最重要的是,保持稳定。 资深开发者之所以操心稳定性,是因为他们肩负着让公司能够持续为客户提供服务的重任。 而什么会威胁到这一切? 复杂性。 复杂性会让系统变得难以理解、难以调试、难以修复、难以交接,并最终导致系统变得极不稳定。 复杂性上升 = 稳定性下降 = 资深开发者失职 = 糟糕透顶,客户付款中断,所有人都愁眉苦脸。 所以,如果说第一个循环的目标是“消除不确定性”,那么第二个循环的目标就是“管理复杂性”。 但这为什么会导致沟通上的失败呢? 因为一旦你有了客户,这两个循环圈就会同时运转。一家公司既需要探索新的可能性,又必须同时服务好现有的客户。  有客户之后,公司必须同时探索新可能,也必须守住现有客户。 好了,现在你可能已经猜到我对文章标题那个问题的答案了。 根据你把时间主要花在哪一个循环圈里,你对问题的认知框架是完全不同的(这也就是为什么我认为开发者在对待 AI 的观点上会产生分歧;有些人更多地在第一个循环里工作,而另一些人则在第二个循环里)。  同一个需求,两种解读:业务看到更快验证,开发者看到更多代码路径和维护成本。 在第一个循环圈里的人,他们的故事是这样的:  业务端的故事:他们要的不是代码本身,而是更快知道答案。 但在第二个循环圈里的资深开发者,他们的故事却是这样的:  开发者的故事:真正的专业价值,是用更少复杂性换来更快确定性。 这两种故事根本搭不上调。 资深开发者接到的“新增功能”需求越多,他们就越想回怼:“呃,不行……这太复杂了……维护成本太高……代码没法读了……后续开发速度会变慢……长期来看会拖累生产力……”。 但是,这些牢骚对于业务端“急需消除不确定性”的诉求来说,毫无帮助。 文案的诊断结果:你不能用你自己的烦恼,去搪塞别人的问题。 文案开出的处方:你必须把你的解决方案,包装成同样能解决他们问题的方案。 资深开发者之所以沟通失败,是因为他们总是在用“复杂性管理”的逻辑来表达自己的苦衷,而他们本该用“消除不确定性”的逻辑来推销自己的解决方案。 只要资深开发者能意识到公司其他部门真正渴望的是消除不确定性,他们就能利用自己的专业能力来提供帮助了。 那么,资深开发者最拿手的本领是什么?是不情愿去开发没必要的东西;是能够敏锐地发现复用现有代码的机会。 需要收集问卷数据? 用 Google 表单就行了,宝贝。 需要开发一个新功能来做测试? 你们有没有试过在现有的 UI 界面上加个假按钮,看看有没有人点?(也就是所谓的“画饼测试”或验证性测试) 需要一套新的数据分析服务? 我们需要看数据来做出的最关键决策是什么?我们能不能只针对这一个决策,先做一个图表、看一个指标? 你想费劲给我烤个完整的生日蛋糕? 算了吧,直接在我的三明治上插根蜡烛就行。 这就是资深开发者学到的生存之道:他们学会了如何利用现有的软件资源,巧妙地给别人想要的东西。 但是,你该如何沟通这一点,而不至于每次都要给别人写篇小作文呢? 文案们最喜欢把一堆复杂的信息浓缩成一句简短有力的话。所以,这里有一句每个资深开发者都必须背诵的魔法口诀:“我们能不能试个更快的办法?” 用“更快 (quicker)”这个词,是承认并迎合了业务端真正的渴望(速度);“办法 (something)”暗示了还有别的方式可以达成目标;而“试 (try)”则暗示了这个方案可能并不完美,但很可能已经足够好了。 这句话完美地切中了公司其他部门的核心需求——用速度来消除不确定性,同时也让资深开发者能够尽情施展他们的专业特长:精简功能、复用代码,如果老天保佑的话,完全避免开发。 就是这样。这就是我对文章标题的回答:当所有人都在为“不确定性”焦头烂额时,资深开发者却总是在把“复杂性”挂在嘴边。 但是!大大的转折来了! 现在的 AI 似乎让这一切都变得毫无意义了,不是吗?为什么还要精简?为什么还要复用?为什么还要避免开发?AI 可以在极短的时间内写出海量的代码。 唉,话虽如此,但有一件事 AI 至今还做不到,而这也正是资深开发者依然在坚持做的事。 承担责任 (Take responsibility)——背锅。 ## 相关链接 - [@dotey](https://x.com/dotey) - [11K](https://x.com/dotey/status/2055097242755706984/analytics) - [Why senior developers fail to communicate their expertise](https://nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:25 AM · May 15, 2026](https://x.com/dotey/status/2055097242755706984) - [11.3K Views](https://x.com/dotey/status/2055097242755706984/analytics) - [View quotes](https://x.com/dotey/status/2055097242755706984/quotes) --- *导出时间: 2026/5/15 12:08:05*
G Games People Play for Product Managers 本文将Eric Berne的交互分析心理学理论应用于产品管理,识别了会议中常见的“心理游戏”,如“为什么不,是的但是”和“法庭”,并提供了基于成人自我状态的理性应对策略,以打破无效循环,提高决策效率。 职场 › 管理 ✍ George from prodmgmt.world🕐 2026-07-23 产品管理沟通技巧心理学交互分析职场游戏会议管理冲突解决自我状态决策效率团队协作
J Jack Dorsey's Buzz: Clearly Explained Buzz 是一款集成了智能体的团队聊天工具,允许用户切换底层模型并保留对话记忆,支持本地共享计算。文章探讨了其 Agents 团队协作、Git 工作流及数据控制优势,适合小团队快速迭代。 技术 › Agent ✍ The Startup Ideas Podcast (SIP)🕐 2026-07-29 BuzzJack DorseySlackAgent本地模型团队协作开源
麦 麦肯锡金字塔原理:让每封邮件无法被忽视的4个提示词 文章介绍了麦肯锡金字塔原理,这是一种由 Barbara Minto 发明的写作方法。通过将结论置于最前,支撑论据居中,数据在后的金字塔结构,可以显著提升沟通效率。文章提供了 4 个针对 Claude 的提示词,帮助用户将这一方法论应用到日常写作中,解决信息被忽略的问题。 职场 › 沟通 ✍ Nav Toor🕐 2026-07-24 金字塔原理写作技巧Claude提示词职场效率沟通技巧SCQA麦肯锡
F Forward Deployed Engineer (FDE): Skills and Complete 90 Day Roadmap 文章深入解析了 Forward Deployed Engineer (FDE) 这一职位的本质,指出其本质是传统的解决方案架构与专业服务的结合,但在 AI 时代被重新定义。文章详细阐述了 FDE 所需的沟通、工程及评估技能,并针对不同背景(SA、Pro Serv、SWE)的从业者提供了 60 至 120 天的转型路线图。 职场 › 职业发展 ✍ Priyanka Vergadia🕐 2026-07-21 FDE职业规划AI工程沟通技巧转型路线图技能提升面试简历
怎 怎样写好一篇推特文章:从读者的时间线出发 本文从读者视角出发,提出了撰写高质量推特文章的核心原则。文章强调写作应始于“阅读承诺”,通过降低理解成本、展示论证过程、提供可带走的价值(如清单或框架)来吸引读者。作者还分享了具体的写作结构模板,帮助作者在碎片化的信息流中有效传达观点并促进传播。 职场 › 沟通 ✍ Mr Panda🕐 2026-07-13 写作推特内容创作沟通技巧方法论读者视角社交媒体
A AIGC 博主张咋啦最新演讲:AI Native 时代的六个反常识工作方式 本文总结了 AIGC 博主张咋啦关于 AI Native 工作方式的六个核心观点:1. 停止人工整理知识库,将会议作为 AI Agent 的输入流;2. 将 Agent 视为团队成员以提升组织效率;3. 为上下游同事定制 Skills 以突破协同瓶颈;4. 利用 AI 提升审美和可视化沟通能力;5. 将产品嵌入用户的高频场景中;6. Builder 最核心的素质是主观能动性、品味和分发能力。 技术 › Agent ✍ 小树🕐 2026-07-13 工作流团队协作效率提升张咋啦AI Native知识管理产品设计品味与审美职场思考
当 当“写代码”被解决之后:Anthropic 内部的 7 件怪事与未来启示 文章基于 Anthropic 工程负责人访谈,探讨了当编码能力不再稀缺时,公司内部发生的结构性剧变。核心观点是“瓶颈只会搬家”,从“产出”转移到了“验证”与“判断”。文中剖析了路线图失效、中间层消亡、努力崇拜崩塌及工程师孤独感等现象,指出在生成成本归零的时代,人的注意力、判断力和认知协作将成为唯一的稀缺资源。 技术 › LLM ✍ DataDan🕐 2026-06-29 AnthropicClaude职场工程管理瓶颈理论验证判断力团队协作未来趋势认知升级
O OpenAI Codex 精通指南:构建可持续进化的 AI 工作系统 本指南旨在帮助读者从熟练用户进化为 Codex 精通者,核心是掌握从“用工具”到“建系统”的思维跃迁。文章详细阐述了如何通过封装 Skill、维护知识库和自动化复盘构建复利飞轮;并深入讲解了利用 Sub Agents 进行大规模遗留代码现代化、建立自动化安全审计体系、以及优化 Automation 性能与成本的高级实战技巧,最终助你搭建个人 AI 操作系统。 技术 › Codex ✍ MuscleMan | AI × Investing🕐 2026-06-11 Codex工作流自动化代码重构安全审计Sub Agents提效系统设计技能封装团队协作
把 把自己“重做”一遍:一队 AI 同事帮我重塑个人 IP 本文作者分享了利用 AI 团队协作工具 Helio,仅用 2 小时便完成了原本需耗时 3 天的个人 IP 重塑(含 Banner、Bio 及视觉体系)。通过配置品牌策略师、设计师和文案 AI 角色,作者仅需提供素材并在关键节点审核,Agent 团队便自动完成了分工协作与交付,展示了多 Agent 协作在提升个人生产力方面的巨大潜力。 技术 › Agent ✍ 劳伦斯🕐 2026-05-27 AI AgentHelio个人IP工作流效率团队协作提示词工程AIGC个人生产力复盘自动化
如 如何使用 Claude 构建你的首个 AI 团队(完整教程) 这是一篇关于如何不写代码、仅利用 Claude 的 Cowork 功能构建 AI Agent 的完整教程。文章首先澄清了 AI Agent 与普通聊天机器人的区别,指出构建 Agent 是目前高价值的技能。随后,教程将 Agent 拆解为角色、指令、工具和记忆四个核心组件,并以“内容研究 Agent”为例,手把手演示了从定义角色到测试优化的全过程。最后,文章展示了如何将多个具有不同角色的 Agent(如研究员、大纲师、撰稿人)组合成一个高效的“内容生产团队”,实现工作流自动化。 技术 › Agent ✍ Khairallah AL-Awady🕐 2026-05-23 ClaudeAI Agent零代码自动化教程Cowork工作流提示词工程团队协作AIGC
C Claude Code 工程化指南:高效组织 .claude/ 目录 本文旨在探讨如何像管理代码一样管理 Claude Code 的配置目录 .claude/。文章首先指出了混乱的目录结构会随着项目增长导致维护困难,随后提出了一套包含 CLAUDE.md、settings.json、rules/、hooks/、commands/、skills/ 和 agents/ 的标准化目录蓝图。接着,文章详细阐述了核心原则,包括顶层设计的轻重分离、规则模块化、自动化脚本与复用工作流的区别,以及团队与个人配置的边界。最后提供了从简单到复杂的渐进式成长路径,帮助开发者构建可预测、可维护且易于团队协作的 AI 辅助开发环境。 技术 › Claude Code ✍ Vince 聊开发🕐 2026-05-20 Claude Code工程化目录结构最佳实践DevOpsAgent技能工作流配置管理团队协作
S Shopify 工程师团队的 Claude Code 配置与实战策略 文章详细介绍了 Shopify 23,000 名工程师如何通过 Claude Code 实现 96% 的代码自动化。核心策略包括:构建统一的 LLM 代理层以控制成本,并行运行多个 Agent 处理不同模块,利用 MCP 服务器集成内部文档与 API,以及将 CLAUDE.md 纳入版本控制。工程师角色正从代码编写者转向架构审查者,通过护栏机制保障安全。 技术 › Claude Code ✍ darkzodchi🕐 2026-05-19 AI编程ShopifyAgentMCP工程效率自动化LLM架构最佳实践团队协作