开发者为什么离不开熟悉的工具？因为工具承载着信任

原文来源：Stack Overflow Blog — Developers are attached to tools because tools encode trust — 开发者对工具的依恋本质是对可预测性的信任；AI 时代工具快速变化、输出不确定，信任被打破，需要用流程把信任重新工程化回来。

Stack Overflow 六年前发过一篇挑事的文章，大意是：IDE 都这么强大了，怎么还有人像原始人一样用 Vim 和 Emacs？评论区照例吵翻了天。但吵到后来，讨论反而沉淀出一个共识：工具不只是工具，它们是开发者工作流的延伸，承载着多年积累的信任。

2026 年，这个问题以更尖锐的形式回来了。Stack Overflow 的新文章《Developers are attached to tools because tools encode trust》把这个共识往前推了一步：工具之所以让人离不开，是因为工具编码了信任——而信任来自可预测性。

信任从哪来：可预测性

文章用了一个很贴切的比喻：如果你的厨房刀一直在变形状、变重量、变锋利度，你就得每次都重新适应它——这样的刀很难建立信任。

Vim 和 Emacs 用户为什么对编辑器有近乎宗教般的忠诚？不是因为它们功能最强，而是因为"手指已经知道该按什么"。这种肌肉记忆，是长期使用沉淀下来的隐性能力。Tricia Gee（开发者生产力倡导者）在文章里说得很直接：她比 AI 编程工具更快，是因为她太熟悉自己的 IDE 了，熟悉到成为无意识的能力。

这里的关键词是边界。传统开发者工具——IDE、静态分析器、容器化工具——都有明确的职责边界，你知道它不会越界。信任建立在"我知道它能做什么、不能做什么、周一的表现和周二一致"之上。

AI 打破了两样东西

Agentic 编程工具正在系统性地打破这个信任基础。

第一，工具在快速变化。你的厨房刀每天都在变形状。模型升级、行为漂移、新特性层出不穷，你今天掌握的用法下个月可能就变了。开发者没法积累"肌肉记忆"，因为对象一直在动。

第二，输出不可预测。Bjarne Stroustrup 那句话被反复引用："代码是对解决方案的精确陈述，而英语是表达需要无歧义事物时的糟糕语言。"你用自然语言驱动 agent 生成代码，得到的是一个概率分布，而不是确定的结果。Stack Overflow 自己的开发者调查显示了一个矛盾的数据：AI 使用率从 76% 升到 84%，信任度却从 40% 掉到 29%——用得越多，越不信任。

更麻烦的是，AI 正在渗透 SDLC 的每一个环节。传统工具不会越界，但 AI 出现在需求、编码、测试、运维的每个角落，"信任赤字"就被放大到了整个流程。

工具不是流程本身

文章最锋利的一个观点在这里：旧工具编码了流程，但工具不是流程本身。

一个伟大的 CI/CD 工具不意味着你交付变快，一个伟大的 IDE 不意味着你写出更好的代码，带 story points 的 issue 系统不意味着你会估时准确。流程的一部分存在于文化里，存在于做软件的人的行为规范中。

Agentic 编码之所以快速被采用，是因为它让开发者更快解决问题。但代码变得几乎免费之后，现有流程的缺陷全被暴露了：需求模糊不清的问题一直都在，只是以前"写代码"这件事本身就消耗了大量精力，掩盖了上游的混乱；现在代码瞬间生成，"问题"和"解决"的定义反而成了真正的瓶颈。

代码近乎免费，但验证代码不免费。编码 agent 一瞬间改几百行代码，把巨大的 diff 扔给人类 review——新的瓶颈变成了代码评审。LLM-as-a-judge 正在成为规模化解决方案，但"如何信任一个 AI 评审 AI 写的代码"本身就需要工程投入。

运行代码也不免费。基础设施、托管依赖、API 的成本，还有最难预算的失败成本：停机、安全漏洞、机会成本。不考虑这些成本的工具，反而会给原本能产出可信软件的流程增加压力。

怎么把信任工程化回来

文章给出的路径不是"等工具变好"，而是用流程重建信任：

人始终是责任主体。 Charity Majors 那句吐槽被引用了："Human-in-the-loop 听起来像是一种怜悯式邀请。是我创造了这个 loop，我拥有它，我是它存在的唯一原因。这是我的 loop！"推代码的人拥有那段代码，批准 PR 的人拥有那个批准。周五搞挂了生产，以前你不会怪 IDE，现在也别怪 agent——问题在键盘和椅子之间。

显式地界定需求。 让一切都要代码做的事都明确写进 prompt。Scott Hanselman 的例子很生动：他让 agent 做了一个环形灯应用，但忘了说 ARM 版本，于是它真的没做。"如果你把任何事交给运气，它就会被交给运气。"

把隐性知识显性化。 资深开发者多年的"调味料"——上下文、约束、公司惯例——现在需要被捕获、验证，并在合适的时候喂给 agent。这正是各种 memory 和 context 管理工具在做的事。

组件复用，别让 AI 重复造。 Bit 首席科学家 Laly Bar-Ilan 的观察：AI 天生是 WET（write everything twice）的——一个团队让 agent 生成按钮，另一个团队又让它生成一次，代码库里冒出无数个按钮。DRY 原则在 agent 时代反而更需要制度化。

知道什么时候不用 AI。 Anil Dash 说得最实在："我们正试图把非确定性系统用在大量应该用确定性代码的场景。LLM 不擅长那个，为什么非要用它当锤子敲所有不是钉子的东西？那个跑了六年的 bash 脚本挺好的。"

我的一点延伸思考

这篇文章的深层价值，是它把"开发者对 AI 的抵触"重新框定了。以前我们习惯把这种抵触解释为保守、习惯、学习成本；Stack Overflow 的框架给出了更准确的说法——抵触的根源是信任缺失，而信任缺失的根源是不可预测性。

这个框架能解释很多现象。为什么有的团队 AI 用得如鱼得水，有的团队用两周就弃了？差别往往不在工具本身，而在流程成熟度：前者有清晰的 spec 文化、严格的 review 流程、明确的验收标准，AI 的不确定性被流程兜住了；后者把这些都交给运气，于是每一条生成的代码都成了赌注。

也可以解释为什么"提示工程"会逐渐让位于"上下文工程"：与其在 prompt 里堆砌指令，不如把组织知识结构化地喂给 agent。信任不是靠祈祷模型稳定，而是靠让模型在受限的、可验证的轨道上运行。

文章最后那句话值得记住：成功的团队不会是生成代码最多的团队，而是建立反馈回路、沉淀黄金标准知识、让工具与工作流对齐的团队。 在 AI 让代码变得廉价的年代，真正稀缺的不是生成能力，而是信任能力——而这恰好是流程和文化的领域，不是模型的领域。