开发者依赖工具，因为工具承载着信任

# 开发者对工具情有独钟，因为工具编码了信任 来源：https://stackoverflow.blog/2026/07/29/developers-are-attached-to-tools-because-tools-encode-trust 大约六年前，我们发表过一篇关于 IDE 的文章（https://stackoverflow.blog/2020/11/09/modern-ide-vs-vim-emacs/），大意是 IDE 已经变得非常强大和全能，以至于还有人像穴居人一样使用 Vim 或 Emacs，简直是个奇迹。没错，这是一篇带有挑衅性的文章，也确实让不少开发者大为光火。评论来自双方：一边是抨击文章根本不了解开发者如何工作的人，另一边是整天宣扬 Emacs 福音的开发者。但最重要的是，大家围绕“这些工具为什么真的有用”展开了一场精彩的讨论。 对于新手来说，Vim 和 Emacs 看起来就像是反直觉的终端程序，需要记住一堆秘密按键才能使用（并且还要知道如何退出（https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/)）。但对于有经验的用户来说，它们用起来就像思考一样自然。有一条评论提到了 David Thomas 和 Andrew Hunt 所著的*《程序员修炼之道》*（https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/），书中解释说，开发者——这些工匠（或者说曾经是工匠的人）（https://stackoverflow.blog/2026/05/28/artisans-and-builders/）——需要“锋利的工具”，感觉就像自己手的延伸。Vim 和 Emacs 拥有无限的定制能力，可以被塑造成完全贴合你的手型和工作流程。花时间去熟练掌握工具、建立对工具的信任，并把它们改造成适合自己的样子，会带来丰厚的回报。 在这个智能体（agentic）工程的时代，新工具是你用自然语言与之对话的终端。编码智能体缺乏开发者编写精良代码时的那种精确性和具体性，但它能在极短的时间内输出整个应用程序。直到今天仍然回响的问题是：这些输出能否被信任。我们上一次的开发者调查（https://survey.stackoverflow.co/2025/ai#sentiment-and-usage）发现，开发者使用 AI 越多，对它的信任就越少——使用率从 76% 上升到 84%，但信任度却从 40% 下降到 29%。 这些工具本身是全新的，它们的能力也在不断变化。如果你的厨房刀一直在改变形状、重量和刀刃，你就得每次重新适应它；这样的工具很难建立信任。但这也指出了你使用该工具的方式、围绕它的流程，以及工具如何强化流程方面存在的缺陷。你信任自己最喜欢的刀、IDE、画笔或其他任何东西，是因为你与它建立了信任，也因为围绕它的流程。 在本文中，我们将探讨工具如何构建值得信赖的流程、工具变化如何暴露（但无法修复）有缺陷的流程，以及工具与文化如何协同作用以建立新的信任。 开发者工具与整个软件开发一起运作和演进，也与单个开发者共同演进。如果你是在终端里开始工作和学习的，也许是在 IDE 或图形界面都不存在的年代，那么你理解“编写代码”的方式本身就包含了那些终端和终端文本编辑器。加入一个 IDE 不仅需要学习一个新工具，还需要重构你写代码的整个流程。 如果从终端迁移到 IDE 是一次艰难的流程转变（或者像有些人说的，毫无必要），那么从两者中的任何一个迁移到智能体编码工具则更加困难。“我对拥抱某些 AI 编程有所保留的原因之一是，我在我的 IDE 里更快，因为我知道它怎么运作，”开发者生产力倡导者 Tricia Gee（https://stackoverflow.blog/2026/06/12/developers-are-emotionally-attached-to-their-tools/）说道。“我和那些非常精通 Vim 和 Emacs 的人共事时也看到过同样的情况。你可以用 IntelliJ IDEA 里的重构工具。他们会说，是的，但那需要学习曲线。我已经花了那么长时间使用某个工具。我的手指知道该怎么做。无论是什么工具，真正深入地理解它，会变成大量无意识的胜任能力。” 建立这种肌肉记忆、这种关于软件在代码层面如何运作的隐性知识，让开发者能够信任自己的工具来帮助产出和改进代码。与此同时，AI 智能体则更快、更不透明、更不可预测。你用的是含混的语言来创建软件，而不是代码。“代码是对解决方案的精确陈述，”C++ 的创造者 Bjarne Stroustrup（https://stackoverflow.blog/2026/04/07/he-designed-c-to-solve-your-code-problems/）说。“英语是一种糟糕的语言，不适合表达必须毫无歧义的东西。”一个值得信赖的工具是可预测、可靠的。你不需要反复和 Emacs 或 Vim 来回折腾。 对于大多数开发者工具，比如 IDE、容器化工具或静态分析器，你知道它们的边界在哪里。它们有自己的角色，不会越界。但 AI 正在渗透到 SDLC 工具链的各个部分。这意味着开发者对 AI 降低的信任（https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/）适用于整个流程。代码可能更快地产生，但验证它、让它达到开发者可以信任它不会导致代价高昂的生产事故的程度，往往需要更长时间。 智能体编码工具改变了软件开发流程的本质。围绕旧流程诞生的一套工具——linter、自动化单元测试、CI/CD 等等——在这种改变的流程下，可能无法继续以目前的形式发挥作用（https://www.linkedin.com/pulse/sdlc-we-know-does-survive-agentic-workloads-rick-clark-hzfte/）。 这些工具编码了流程，但它们本身并不是流程。一个出色的 CI/CD 工具并不意味着你交付更快。一个出色的 IDE 并不意味着你写出了更好的代码。一个带有故事点的 issue 跟踪系统并不意味着你估算工作量很准。流程的某些部分是以文化的形式存在的，即构建软件的人的行为和规范。新工具往往意味着改变组织文化（https://stackoverflow.blog/2023/05/10/how-do-we-get-a-tech-team-to-make-a-big-technical-change/）。 在规模不小的工程组织里工作过的人，对这个故事都不会陌生。新工具，无论承诺多美好，如果无法融入现有的文化和流程，就可能失败。成功的工具需要以开发者能够接受和理解的方式，推动文化和流程发生转变。你们都喜欢构建东西和解决问题，所以那些不能帮助你更好地做到这一点的工具，会被无视。 智能体编码之所以被迅速采用，是因为它让开发者能更快地解决问题。但当代码变得几乎微不足道地容易创建时，它也暴露了现有流程中的许多缺陷。需求不明确且不断变化的问题（https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/）一直存在，但现在解决一个问题需要严格定义（https://stackoverflow.blog/2023/12/29/the-hardest-part-of-building-software-is-not-coding-its-requirements/）“问题”和“解决”到底意味着什么。 代码可能（几乎）免费，但验证它并不免费。新的瓶颈变成了代码审查。老笑话是：如果你想让一个 PR 快速通过，就改动 100 行代码。编码智能体瞬间就能改动几百行代码，然后把巨大的 diff 丢给人类去审查（或者盖章放行）。LLM-as-a-judge（https://stackoverflow.blog/2025/10/09/who-watches-the-watchers-llm-on-llm-evaluations/）正在演变为一种可扩展的解决方案，但要建立一套工程方法来信任 AI 能审查 AI 写的代码，需要大量工作。 同样地，运行代码也不是免费的。你有基础设施的成本——在云原生时代，这取决于你的应用程序消耗的计算、内存和流量。你有托管的依赖和 API 的成本。还有故障的成本——这是最难预算的部分：停机、安全漏洞和机会成本。那些生产出不考虑（或无法考虑）这些成本的软件的工具，可能并不值得。而且它们会给那个曾经生产出可信赖、可靠软件的流程带来压力。 对很多人来说，由于智能体编码，SDLC 已经开始看起来像是坏了。很自然地，这些人正在寻找新的工具来修补这些裂缝：AI SRE、自动化代码审查、记忆与上下文管理器、控制平面与护栏改进，等等。这些都是 AI 赋能的软件组织中工具链的可靠补充。但仅仅靠工具并不会解决问题，尤其是当文化和流程保持不变时。一个糟糕的流程配上更好的工具（而人们可能根本不用这些工具），依然是糟糕的流程。 在旧的 SDLC 中，产品经理会基于他们的研究、客户访谈和对竞争对手的理解，提出特性和功能需求。架构师会根据他们多年的经验和对现有技术栈的理解，来设计软件规格。工程师会根据他们对代码逻辑和现有代码库的了解来构建代码并审查提交。QA 会根据他们关于软件如何出错的经验来审查并尝试破坏软件。一旦软件部署到生产环境，DevOps 和 SRE 会根据他们过往的经验来监控和管理性能与资源使用。 你通过与人合作、理解他们的思维方式，并限制任何一个个人或工具可能失控并摧毁系统的可能性，来建立对这个系统的信任。在一个 AI 赋能的 SDLC 中建立信任（https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/）需要同样的东西：与人合作，确保他们承担责任和问责；共享工作流程并持续迭代；并尽可能减少出错的机会。 第一步是确保我们把人类置于责任方，并标记出 AI 在哪些地方做出了贡献。每个人都在谈论“human-in-the-loop”，但正如 Honeycomb 的 CTO Charity Majors 指出的那样（https://www.linkedin.com/posts/charity-majors_human-in-the-loop-sounds-like-a-pity-invite-activity-7461153516628197377-lHZ9/），“human-in-the-loop 听起来像是一个怜悯性的邀请。我创造了这个 loop，我拥有这个 loop，我是这个 loop 存在的唯一原因。这是我他妈的 loop！”提交代码的人拥有那段代码。批准那些 PR 的人拥有那次批准。如果你在 AI 时代之前的周五弄挂了生产环境，你不会去怪你的 IDE。如果你现在弄挂了，问题不在于智能体；问题在于键盘和椅子之间。 在 AI 时代，协作可能变得更困难、更奇怪。智能体让你扩展了“全栈开发者”的概念——你可以用一个编码智能体完成从产品需求到 DevOps 的一切。开发者很容易变成一个“一个人的孤岛”。“你不必和设计师确认设计，因为你刚让一个智能体把设计做出来了，”Slack 的首席产品官 Jaime DeLanghe（https://stackoverflow.blog/2026/05/20/pack-your-agentic-stack-in-slack/）说，“你也不必和某个领域的另一个工程师合作去理解他们的代码库，因为你直接问智能体就行。你可以沿着这条路一直走下去，然后搞出一个巨大的 PR。” 有人建议在一个共享房间里提示（prompt）智能体，这样每个人都能评论并修改过程。还有人建议每个 PR 都附带提示过程的完整记录。这种对与智能体对话的查看，甚至可能让你更深入地了解那段代码是如何产生的。“能打开一个 PR，真正看到开发者是怎么思考、怎么解决问题的，这太酷了，”Cloudflare 的首席技术官 Dane Knecht（https://stackoverflow.blog/2025/06/19/my-job-is-going-to-change-in-a-dramatic-way-exploring-the-future-of-the-internet-with-cloudflare/）说。 旧流程使用访问控制、审计日志和 diff、以及 CI/CD 检查来限制任何错误的爆炸半径，而新流程则需要在代码编写之前就消除偶然性。这意味着确保你想要代码完成的一切都在提示词中明确写出。你可以为此使用 spec.md 文件，但任何没有被明确指定的东西，现在都可能被构建出来。“如果你把任何事留给偶然，那它就会是偶然的，”微软开发者社区副总裁 Scott Hanselman（https://stackoverflow.blog/2026/01/13/vibe-code-anything-in-a-hanselminute/）说。“我有个小环形灯应用要构建，我在 x64 上。我希望它在 ARM 上也能跑，所以我需要告诉它：‘给我做一个 ARM 版本。’如果我不说，它就不会做。” 当然，你不可能把所有需要的东西都塞进一个巧妙的提示词里（也不应该这么做）。你会发现自己不断重复，而且几乎肯定会漏掉一些作为公司隐性知识而存在的东西。很多聪明人正在思考如何为你的智能体提供更好的上下文，给它们短期和长期记忆。关键在于给智能体提供你的代码所需要的正确上下文。通常，这会是资深开发者随着时间积累起来的“调味料”。但智能体需要你把那些知识捕捉到某个地方（比如 Stack Internal（https://stackoverflow.co/internal/?utm_medium=referral&utm_source=blog&utm_campaign=content-funnel&utm_content=tools-encode-trust)），验证它，并在需要时把正确的部分作为上下文提供给智能体。 现在你有了世界上最好的提示词。你给了智能体正确的上下文，它构建的东西通过了同行评审，并被推到了生产环境。你对系统的下一个检查点是：永远不要再构建那个功能。你已经有了一个非常好的软件组件；别丢了它，要复用。“DRY（不要重复自己）原则是我们的主要原则，”Bit 的首席科学家 Laly Bar-Ilan（https://stackoverflow.blog/2025/04/18/generating-components-not-tokens/）说。“今天的 AI 本质上是 WET（写两次）。这个开发者告诉它，‘好，生成一个按钮’，它高兴地照做了，然后另一个团队的另一个开发者又来问它，结果代码库里又多了一个按钮。” 然而，与 AI 智能体建立信任的最大技巧，或许是知道什么时候不要使用它们。即使你的流程上有了上面所有的护栏，由于 AI 的天性，它仍然带有一定的“掷骰子”成分。如果你已经有一个完全够用的确定性解决方案，何必多此一举重造轮子？“我们正试图把非确定性系统应用到很多本应使用确定性代码的场景中，”Anil Dash 说。“LLM 不擅长那件事，那我们为什么非要把它当作锤子，去敲那些根本不是钉子的东西？那个已经跑了六年的朴素 bash 脚本，挺好的。” 过去，由于我们共事的人和使用的工具，信任是内置的。那种信任来自可预测性：你知道他们能做什么，你知道他们的长处和短处在哪里，并且你可以预期周一对他们的体验，会与周二对他们的体验一致。AI 的概率性质，以及改进和变化发生的速度，把这一切都抛到了窗外。流程改进可以帮助把信任重新工程化到开发中。 在美好的旧时光里，我们围绕人来构建流程，我们信任这些流程，是因为我们信任与我们共事的人。我们构建了信任的工具来管理流程，它们成为了我们自己以及我们共事之人的延伸。 有了 AI，我们能够自动化很多这样的流程。好消息是工作完成得更快了。坏消息是，当工作完成时，我们并不信任它。工具是新的，人们正在向更高层次的岗位移动，而流程……