技术选型中的隐形对话：身份认同如何主导企业决策

编者按： 技术选型，特别是编程语言的选择，常常被“性能”、“生态”、“开发效率”等技术词汇所装饰，被视为纯粹的理性讨论。然而，在这篇由经验丰富的技术领导者所写的文章中，作者通过自己亲身经历的两个相似案例——从早期初创公司因CTO坚持将PHP替换为Perl而失去市场机会，到后来在谷歌看到团队为了追求Rust而忽视更好选择——为我们揭示了技术决策背后不为人知的真相：很多时候，我们以为是在比较技术优劣，实际上是在为个人的身份认同、情感依赖和职业标志寻找合理化的理由。

这篇文章的核心价值在于，它准确地指出在每一次“可见”的技术辩论之下，都隐藏着一场更强大且“不可见”的自我对话。后者关乎“我是谁”、“我想成为谁”，它直接触动我们大脑中的防御机制，让理性天平悄然倾斜。

对于每一位技术决策者——无论是CTO、技术副总裁还是团队负责人——这篇文章都是一面必须面对的镜子。它迫使我们反思：我们自豪的技术决策，是基于客观事实，还是源于那个渴望被特定技术社区认可和定义的“自我”？在下一个价值数百万甚至数千万美元的技术选型会议开始前，这篇文章或许能提供一个关键的审视角度。

本文作者 Steve Francia 是一位在软件、产品和推广领域拥有27年深厚经验的技术领导者，长期专注于开源生态和开发者体验。他曾主导多个具有行业影响力的标杆项目，包括Go语言、MongoDB、Docker以及支撑全球10%商业互联网的Drupal内容管理系统。

此外，Steve还负责撰写了谷歌的开源战略，并牵头制定了谷歌云的开发者战略。

作为一名热爱编程的开源贡献者，他创建了多个广受欢迎的开源项目，如全球最流行的静态网站生成器Hugo、为超过5万个应用程序提供支持的Go CLI框架Cobra，以及Go语言配置框架Viper。这些成就也使他成为全球最受欢迎的开发者之一。

Steve也是一位活跃的技术布道者，经常受邀在各类会议、播客及用户组活动中发表演讲，其《Go语言——站在巨人的肩膀上》和《Drupal与我的成功秘诀》两场演讲深受业界好评。他还为O"Reilly撰写或合著了《Go语言中的强大CLI应用程序》、《Hugo实战》等多本技术书籍，并在其他多部著作中提供了建议与贡献。

新任CTO将PHP转为Perl，导致成本激增，错过机遇

编程语言是企业做出的成本最高的单项选择，然而我们却将其视为一场单纯的技术争论。目睹这一错误导致数十家公司破产、超过数百家公司受损后，我领悟到一个令人不安的事实：这类决策极少与技术本身相关。它们关乎身份认同、情感与自我，并且会以一种事后才察觉的方式，损害公司的发展速度与预算。

在我职业生涯早期，我曾任职于Takkle，这是一家前景良好的社交网络公司。由于一名高管突然离职，我从首席工程师晋升为工程副总裁，带领着一支12人的团队。尽管我们顺利达成了所有目标，但当时我才20出头，缺乏经验，董事会希望解决这一风险。他们向CEO施压，要求招募一位更具经验的CTO。我很期待能向这位新CTO学习——他在Perl社区颇具名气，入职时还带来了一摞O"Reilly出版的“骆驼书”（Perl编程语言经典教程）。

这位CTO上任后的首要举措之一，便是宣称我们当时使用的编程语言PHP是错误选择，并下令将其更换为Perl。在我看来，他此前对PHP和Perl进行的对比分析毫无意义，这场更换命令正是在此之后下达的。

我们的发展速度一落千丈。团队不仅要学习新的编程语言，还得从零开始重建系统，这导致产品上线时间推迟了9个月。为了弥补进度损失、搭建基于Perl的新系统，我们的团队规模扩大了一倍多，月度烧钱速度也从20万美元飙升至50万美元，公司的资金存续周期因此缩短了一半。

这位CTO确实兑现了部分承诺。我们搭建出一套出色的系统，我也真心为此感到自豪。但一切都为时已晚。当我们最终完成产品上线时，市场机遇早已消失。彼时Facebook已不再局限于高校用户，而我们的资金也即将耗尽。激增的开支让资金存续周期缩短一半，新网站又缺乏足够的发展势头来达成融资所需的里程碑，我们再也无法获得更多资金支持。

我时常会想：如果当初我们坚持使用PHP会怎样？我们原本的系统运行良好，发展也具备十足势头。那样一来，我们不仅能更早推出产品，成本还会大幅降低。PHP对Facebook而言都够用，为什么对我们就不行呢？

但真正困扰我的问题是：为何如此经验丰富的领导者，会犯下这样严重的错误？

惨痛教训重演：CTO一拍脑门决定采用Rust

无独有偶，我的职业生涯，又经历了一遍上述悲剧。

在谷歌担任编程语言产品负责人时，我所带领的团队涉及C++、Java、Go和Python四种语言。在MongoDB工作期间，我管理的团队使用着13种不同的编程语言。在这两家公司，我都看到过才华横溢的工程师们各执一词，他们手中的数据看似相互矛盾，实则每一份都真实可信，却又都不够全面。而在谷歌云部门，我发现客户们也面临着同样的难题。

距离Takkle事件已过去20年，我却再次经历了似曾相识的场景。当时，谷歌一位工程副总裁正向管理层汇报，说明他的团队为何需要用Rust语言搭建下一套系统。这场汇报与当年Takkle的经历惊人地相似——当年那位CTO为选择Perl给出的理由，几乎每一条用在当时的PHP上都更贴切；而如今，这位副总裁为选择Rust罗列的每一条理由，客观来看Go语言都更具优势。举个例子：他们称“易于构建和部署”是Rust的优点。诚然，这确实是Rust的强项，但在这一具体指标上，Go语言的即时跨平台编译能力和单一静态二进制文件特性，比编译速度极慢的Rust表现更出色。

我并非认为他们应该选择Go语言——事实上，结合他们的实际情况，Go或许是个错误选择，而Rust才是正确答案。但让我震惊的是，他们的推理过程漏洞百出。如果他们是在进行理性论证，理应会考虑Go语言；而按照他们汇报中提出的评判标准，他们早该发现Go更符合要求，至少也会重新调整评判标准。

会议结束后，我把这位副总裁拉到一旁，问道：“跟我说说你们是如何评估其他候选编程语言的？” 他顿时面露茫然，承认道：“我们…… 其实没考虑过其他语言。大家都在谈论Rust。” 真相就此揭开：一个价值5000万美元的决策，仅凭跟风炒作就要获批通过。

对我而言，这一刻如醍醐灌顶——我终于找到了职业生涯初期那个问题的答案。那场汇报根本不是在展示分析结果，因为他们从未做过分析；它只是为一个早已定好的选择寻找借口。这个决策，完全是基于炒作、情感和身份认同做出的。

为什么会出现这样现象？因为本质上，每一场技术争论，都是两场对话的交织。在每一次编程语言讨论中，都有两场对话在同步进行。

看得见的对话——“Rust具备内存安全性，且无需垃圾回收机制。”“Go语言编译速度更快，部署也更简便。”“Python拥有最丰富的机器学习生态系统。” 这类对话聚焦技术本身的特性，所有观点均以技术维度的事实为支撑。

看不见的对话——“我是一名Rust开发者。”“我想成为一名Rust开发者。”“我无法想象自己会是不选择Rust的人。” 这场对话隐藏在技术表述背后，核心是个人的身份认同、职业期待，以及对自我技术选择的心理维护。

如果你看到这里，心里在想“不对，我上次选编程语言时不一样，我当时很理性”，那说明你此刻正处于这场看不见的对话中——在你读这句话的同时，它已经在为你的选择辩护了。

我在Takkle公司时遇到的那位CTO，就深陷这场看不见的对话。他为选择Perl所做的技术分析，每一个观点从技术层面看都属实，但总让人觉得空洞，因为这些分析只是为了掩盖更深层的隐形对话。他并非在评估编程语言，而是在守护自己用十年时间建立起来的身份认同——Perl技术专家的身份。

我们公司每个月多花30万美元，并非为了更优的架构或更快的招聘速度。我们支付的，是让他能以“Perl首席技术官”而非“PHP首席技术官”自居的机会。这才是背后真正的“交易”，而重建系统不过是这场交易的“付款方式”。

谷歌那位副总裁关于Rust的汇报中，将“易于构建和部署”列为Rust的优势。从技术角度看这没错，但客观而言，Go语言在这一具体指标上表现更优。如果他们真的在认真进行那场“看得见的对话”，理应会发现这一点，至少会在分析中考虑Go语言。但他们没有。因为他们从头到尾都没在进行“看得见的对话”，却即将为这场“看不见的对话”投入5000万美元。

为何你永远无法察觉自身的偏见？

在过去二十年一项极具启发性的研究中，研究者试图探寻：为何人们即使面对压倒性的反证，仍会固执坚守某些信念？这项发现从根本上改变了我们对人类决策机制的认知。

研究人员先锁定每位参与者身份认同的核心信念——包括其核心立场、基本价值观等构成自我认知的根基。随后，在参与者接受fMRI脑部扫描时，研究者分别对其核心信念与非核心信念发起精准挑战。

脑部扫描结果显示：这两类挑战激活的神经通路截然不同。

当非核心信念受到质疑时，大脑推理中枢正常运转。参与者能够理性分析证据，权衡论点，甚至改变原有看法。

然而当核心信念遭遇挑战时，大脑反应如同遭受物理攻击。负责威胁识别的杏仁核立即激活——这与遭遇猛兽时的应激反应如出一辙；处理情绪痛苦与厌恶的脑岛皮层剧烈活动；最具启示性的是，维持自我认知的默认模式网络会立即进入防御状态，全力守护既存身份认同而非评估新信息。

换言之，此刻你的大脑并非在权衡证据，而是在抵御生存威胁。

研究结论一针见血：“若要接受不同观点，你必须构想另一个版本的自己。”

大脑无法客观评估对核心信念的挑战，因为这需要暂时解构定义“你是谁”的神经架构。这并非靠增强理性或加倍努力就能解决——偏见本身已侵蚀了你察觉偏见的能力。

这种现象在现实中如何显现？当工程师评估非擅长领域的编程语言时，其大脑实质上在自我对抗。他们不仅在分析技术权衡，更在直面一个充满威胁的“潜在自我”：Python开发者研读Go语言性能案例时，其杏仁核会将每个证据标记为待消除威胁；Rust拥护者审视相同问题时，其默认模式网络会构建“唯Rust能解”的叙事逻辑。

我们并非刻意欺骗——我们真诚相信自己的逻辑无懈可击。这正是身份认知思维既代价高昂又难以察觉的根源。

我们自称Pythonista、Gopher、Rustacean，将这些标签化作勋章（乃至实体徽章：T恤、贴纸等）。纵观历史，众多姓氏源于职业（陶匠、铁匠、酿酒师），昭示着“职业即身份”的深层逻辑。这些看似装饰性的标签，实则是潜意识的决策框架。

整个行业始终聚焦于表层对话：培训工程师进行技术辩论，建立功能矩阵决策框架，寄望于通过足够多的基准测试案例做出正确选择。

但潜意识的暗流才真正主导着决策走向：这解释了为何某CTO选择Perl，某副总裁钟情Rust。在您即将进行的语言选型中，这股暗流正在无声涌动。

当你雇佣Rust开发者评估编程语言时，结局早已注定——两百万美元的可行性研究，不过是为既定结论披上理性外衣的仪式。

真正的代价

问题不在于这种偏见是否存在——科学结论早已明确。真正该问的是：你承担得起让它左右决策的后果吗？

因为这场“看不见的对话”是要花钱的。行业研究显示，在产品生命周期内，技术栈的选择会占据总开发成本的40%到60%。Stripe的研究也发现，开发者有42%的时间都在处理技术债务。当你让“身份认同”主导决策时，本质上是在拿公司的发展速度、预算和资金存续周期做抵押，只为满足某个人的自我认知。

“看得见的对话”围绕技术展开，“看不见的对话”围绕身份展开，而最终赢的永远是后者。

既然“看不见的对话”总在拖后腿，我们该如何破局？答案是彻底转变对话的核心。

不要再问“哪种语言最好”，而要问“用这种语言会让我们付出多少成本”。这里的成本不只是薪资，还包括发展速度的损耗、技术债务的积累、招聘的难度、运维的复杂度——涵盖所有关乎公司能否存活的维度。

把技术层面的争论，重新定义为经济层面的考量。而且和“身份认同”不同，经济成本可以量化、可以对比、可以理性决策，不会威胁到任何人的自我价值。

选择编程语言，是公司要做的成本最高的单项经济决策。它会决定公司的技术文化、限制预算分配、影响招聘渠道、设定运维成本，最终还会左右你能否以足够快的速度抢占市场。

我们需要一个能让“隐性成本显形”的框架。这个框架要能引导我们讨论经济问题，而非纠结身份认同；无论你是第一次选语言，还是评估技术栈迁移，它都能发挥作用。

网友如何看待？

一直以来，关于编程语言的争论总是备受瞩目。Steve Francia的这篇文章在Hacker News社区中引发了诸多讨论。

有位ID名为bri3d的Hacker News用户表示并不认同这篇文章中的观点。该用户表示自己参与过很多编程语言重写项目，有成功的也有失败的，项目成功的不在于编程语言，而是取决于：项目团队成员的构成，以及项目架构师的能力。

“我参与过几十个重写项目，有成功的也有失败的，也见过各种规模的项目和产品，但我始终认为编程语言的选择并非决定产品成败的主要因素。即使将这个论点从语言扩展到框架和生态系统，尽管在这些领域或许能找到一些蛛丝马迹，但仍然无法展开有意义的讨论。项目成功的关键几乎总是取决于：项目团队成员的构成，以及项目架构师的能力。当然，我并不是说某些语言（尤其是小众语言）完全不重要——它们在一定程度上确实会影响招聘和员工类型，但这种影响远不及项目团队成员的构成和项目管理水平。”

有从事咨询工作的用户对于bri3d的观点表示认同。他表示：

“这是一个非常精辟的观察。在我从事咨询工作的过程中，也很快意识到企业面临的问题大多可以归为两类：一类是足以‘毁掉整个项目’的致命问题，另一类则是‘会给优秀工程师带来麻烦’的棘手问题。

以编程语言选择为例——这基本上总属于后者。就像我的团队虽然不精通Java，但若情势所迫，我们依然能用它完成开发。而真正属于前者的，往往是糟糕的管理体系或某个刚愎自用的人物。比如当持续集成流水线需要30分钟才能完成反馈循环，或者连本地开发环境都无法搭建时，项目才真正走到了生死存亡的边缘。”

ID名为WalterBright的用户也不赞同文章作者的观点。他终认为，编程语言的选择并非决定产品成败的核心因素。这一点在他的开发生涯中多次得到验证。

“我曾接手过一个庞大而复杂的宏汇编程序，由于原开发者离职且无人愿意维护，我主动提出用C语言进行重写。最终成果不仅显著提升了代码的可维护性，还成功实现了向公司多个目标平台的移植。

另一个例子是Optlink（一个Win32链接器）的移植尝试。虽然我致力于将其从汇编语言迁移到C语言，但由于Win32编程市场的整体萎缩，这个项目最终未能获得成功。

而我的《帝国》游戏开发经历更是生动的例证：这个项目最初采用BASIC语言实现，随后经历了FORTRAN、PDP-11汇编语言、PC平台的C语言，直至最终的D语言多次技术栈转型。每一次语言迁移都顺应了当时的技术环境，但产品的核心价值始终得以延续。

这些经历让我深刻认识到：真正决定项目命运的，是市场需求、架构设计和团队执行力，而非具体的编程语言选择。”

还有用户表示，在选择编程语言时，也不是所有决定都是一拍脑门做出来的，而是优先采用团队最熟悉的语言。唯有当所有成员一致认为另一门语言更契合项目需求，或存在其他令人信服的更换理由时，才应考虑改变。盲目追逐技术潮流、或通过行政命令强行推行某项技术——无论是Cucumber、GraphQL、微服务还是其他什么——往往会导致灾难性后果。

“就个人习惯而言，我自然倾向于使用自己最擅长的技术栈。但我清楚地意识到这种偏好可能存在局限，因此在实际工作中会主动提出其他可能性。若项目不由我主导，我非常乐意配合团队既定的技术方向。我始终认为，盲目追逐技术潮流、或通过行政命令强行推行某项技术——无论是Cucumber、GraphQL、微服务还是其他什么——往往会导致灾难性后果。

正确的做法应该是：首先精准定义你要解决的问题，并真正站在最终用户的视角思考体验；接着切换到运维支持者的角度评估可持续性；再以未来维护者的身份审视代码可维护性；最后，想象十年后的自己会如何评价这个技术决定。

如果有成熟的现成解决方案，就直接采购；若确实需要自主开发，则优先考虑将非核心模块外包。总而言之，我们应该用最简单、最直接的方式解决问题，这才是最明智的工作哲学。”

参考链接：

https://spf13.com/p/the-hidden-conversation/

https://spf13.com/about/