大约六年前，媒体曾热议强大的 IDE 是否意味着 Vim、Emacs 已经过时。彼时文章引发激烈争论：有人批评作者不懂开发者的工作方式，有人则坚持为 Emacs 摇旗呐喊。但真正有价值的讨论，最终指向了一个更本质的问题——这些工具为何真正有用。
趁手的工具，是手指的延伸
对于初学者，Vim 和 Emacs 看起来像是一堆需要死记硬背快捷键的终端程序。但对资深用户而言，其操作感已经接近本能。《程序员修炼之道》的作者 David Thomas 和 Andrew Hunt 指出，开发者（或者说曾经的工匠）需要的是"趁手的工具"——握在手中如同手指的延伸。Vim 与 Emacs 凭借极高的可定制性，可以被塑造成完全贴合个人习惯与工作流的样子。投入时间建立对工具的熟练度和信任感，回报极为深远。
AI 编程助手：更快，却更难信任
进入智能体工程时代，"终端"变成了可以用自然语言对话的工具。AI 编程助手生成完整应用的速度远超人类，但输出的代码是否可信，这个问题至今仍在回响。Stack Overflow 开发者调查显示，使用 AI 的开发者比例从 76% 升至 84%，但信任度却从 40% 跌至 29%——用得越多，信得越少。
工具本身是新的，能力也在持续变化。正如一把不断改变形状、重量和刀刃的菜刀，每次使用都要重新适应，这样的工具很难建立信任。这也暴露了一个更深层的问题：不是工具本身，而是使用工具的方式和围绕它的流程存在缺陷。你对 IDE、画笔或任何趁手工具的信任，实际上是对一整套使用流程的信任。
工具是流程的一部分
开发者工具与软件开发整体同步演化，也与个体开发者的成长路径紧密相关。如果从终端起步学习编程，那么对"写代码"这件事的理解天然包含终端和文本编辑器。切换到 IDE，不只是学一个新工具，而是要重构整个编码流程。
"我犹豫接受 AI 编程工具的原因之一，是我在 IDE 中效率更高，因为我对它足够熟悉，"开发者效能布道师 Tricia Gee 说，"我见过同样情况：当人们把 Vim 和 Emacs 用到炉火纯青时，让他们去用 IntelliJ IDEA 的重构功能，他们会回答'是的，但那有学习曲线，我用现在的工具已经很久了，手指知道该怎么做'。无论什么工具，深入理解它都会形成大量无意识的肌肉记忆。" 传统开发工具——IDE、容器化工具、静态分析器——边界清晰，各司其职，不会越界。但 AI 正在渗透软件开发生命周期（SDLC）的每一个环节。开发者对 AI 的整体不信任，也因此蔓延到整个流程。代码产出更快了，但验证代码、确保其不会在生产环境引发代价高昂的事故，往往需要更长时间。
工具编码流程，但无法修复流程
智能体编程工具改变了软件开发的本质属性。围绕上一代流程构建的工具——代码检查器、自动化单元测试、CI/CD 等——可能无法以当前形式继续运作。
这些工具编码了流程，但它们本身不是流程。好的 CI/CD 工具不等于更快发布；好的 IDE 不等于写出更好的代码；有故事点的需求跟踪系统也不等于精确的工作量估算。流程的某部分以文化形态存在，表现为团队中构建软件的人的行为规范和共识。新工具往往意味着要改变组织文化。
这一现象对规模稍大的工程团队来说并不陌生：无论新工具承诺了什么，当它们无法融入现有文化和流程时，往往走向失败。好工具需要以开发者能够接受和理解的方式，推动文化与流程的转变——毕竟工程师热爱的是建造和解决问题，无法帮助你更好地完成这些事的工具，终将被束之高阁。
智能体编程的快速普及，源于它让开发者能更快解决问题。但当代码生成变得近乎 trivial，大量既有流程缺陷也随之暴露。需求不清、反复变更的问题一直存在，但现在要解决问题，就必须先对"问题"和"解决"本身做出严格定义。
AI 写代码几乎零成本，但验证代码却成了新的瓶颈。Code Review 正在取代曾经的 PR 合并速度玩笑，成为 AI 编程时代最昂贵的环节。LLM-as-a-judge 作为一种可扩展方案正在兴起，但要建立对"AI 审核&查验 AI 写的代码"这一流程的信任，仍需大量工程投入。
同样，代码跑起来也并非免费。云原生时代，基础设施成本取决于应用消耗的计算、内存和流量规模，还要加上托管依赖项和 API 的费用，以及失败成本——这是最难预算的部分：停机、安全漏洞和机会成本。如果工具产出的软件不考虑这些代价，它可能根本不值那个价，反而会拖累原本用于生产可靠软件的整个流程。
流程出了裂缝，工具能补吗？
对很多人来说，SDLC（软件开发生命周期）因智能编码工具的出现而显得千疮百孔。自然而然，人们指望新一代工具来修复这些裂痕：AI SRE、自动化代码审核&查验、记忆与上下文管理器、控制平面与测试框架改进……这些确实是 AI 加持的软件组织中扎实的工具补充。但仅靠工具本身无法解决问题——尤其是在团队文化和流程保持原样的情况下。用更好的工具（而且人们可能根本不用）去修补一个破碎的流程，流程依然是破碎的。
用更好的流程重建信任
传统 SDLC 中，产品经理依据调研、客户对话和竞品理解来提出功能需求；架构师基于多年经验和对现有技术栈的掌握来设计软件；工程师根据代码逻辑和对代码库的了解来构建和审核&查验提交；QA 依据软件如何出错的经验来审核&查验和尝试击破软件；上线后，DevOps 和 SRE 凭借过往经验来监控和管理性能与资源消耗。
在这套体系中建立信任，靠的是人与人之间的协作、对彼此思维方式的理解，以及限制任何个人或工具失控、造成系统性灾难的可能性。在 AI 加持的 SDLC 中重建信任，同样需要这些要素：让人真正承担责任、共享工作流程并持续迭代、最小化出错概率。
关键第一步是明确人类为责任主体，同时标注 AI 做出的贡献。人人都在说 Human-in-the-loop，但正如 Honeycomb CTO Charity Majors 所指出的："Human-in-the-loop 听起来像是一种施舍式的邀请。是我创建了这个循环，我拥有这个循环，这个循环存在完全是因为我。这是我的该死的循环！"推送提交的人拥有那段代码，批准 PR 的人拥有那个批准。以前在 AI 出现之前搞垮生产环境，你不会怪罪自己的 IDE；现在出了问题，板子也不该打在 Agent 上——问题出在键盘和椅子之间。
协作方式的根本变化
AI 时代的协作可能更加艰难和陌生。 Agent 让"全栈开发者"的边界大幅扩展——从产品需求到 DevOps，编码 Agent 统统能搞定。 开发者极容易退化成一个人的孤岛。" 你不必去和设计师确认设计，因为你可以让 Agent 直接生成设计；也不必去找特定领域的工程师了解他们的代码库，因为直接问 Agent 就行。" Slack CPO Jaime DeLanghe 如此描述，"你可以沿着这条路一直走下去，最终制造出一个巨大的 PR。"
有人建议在共享空间中提示 Agent，让所有人能评论和修改流程。 还有人建议每个 PR 都附上提示过程的完整记录。 这种对 Agent 对话过程的透明化，甚至可能让人更深入地理解代码是如何生成的。" 能够在打开 PR 时，真正看到开发者是如何思考、如何解决问题的，这太酷了。" Cloudflare CTO Dane Knecht 如是说。
减少代码写出之前的侥幸
传统流程靠访问控制、审计日志与 diff 记录、CI/CD 检查来限制任何错误的爆炸半径，而新流程需要在代码写出之前就消除侥幸。 这意味着确保你想让代码做的事都在 prompt 中明确声明。 可以用 spec.md 文件来实现，但任何未明确指定的内容都可能被构建出来。" 如果你把任何事交给运气，运气就真的会来光顾你。" Microsoft 开发者社区 VP Scott Hanselman 分享了他的经历，"我想做个环形灯应用，目标平台是 x64。
我需要它也能在 ARM 上运行，所以我得明确告诉它'给我做一个 ARM 版本'。 如果我没说，这事就不会发生。" 当然，你不可能把所需的一切都塞进一个精巧的 prompt 里（也不应该）。 否则你会不断重复自己，而且公司中那些心照不宣的隐性知识几乎肯定会有所遗漏。 很多人正在思考如何为 Agent 提供更好的上下文——赋予它们长期和短期的记忆。 诀窍在于给 Agent 正确的上下文——你的代码真正需要的那种上下文。 正常情况下，这是资深开发者经过时间沉淀才能获得的"调味品"。
但 Agent 需要你把这些知识捕获到某处（例如 Stack Overflow 内部平台），加以验证，然后在需要时将正确的部分作为上下文输出。
别让 AI 重复造轮子：DRY 原则在 Agent 时代的挑战
Bar-Ilan 是 Bit 首席科学家，她指出，业界奉为圭臬的 DRY 原则（Don't Repeat Yourself）在 AI 时代正遭遇根本性挑战："AI 本质上是 WET 的——Write Everything Twice。开发者让它'生成一个按钮'，它欣然照做；另一个团队的开发者提出同样需求，又会生成另一个按钮，代码库里就这样多出了重复组件。" 这与传统的组件复用思路背道而驰。AI 生成的内容若未经系统性沉淀，团队每次都需要重新"造轮子"，既浪费资源，也增加了代码库冗余。
何时该对 AI 说"不"
最大的信任技巧，或许是知道什么时候根本不该用 AI。Dash 直言："我们总试图用非确定性系统去解决那些本该用确定性代码处理的问题。LLM 不擅长这些，为什么还要把它们当作锤子，去敲所有的钉子？"他举了个例子：那个默默运行了六年的朴素 Bash 脚本，能用、好用、够用，就别换。
AI 的概率特性决定了其输出存在波动——今天的生成结果未必与昨天一致。若现有方案已经稳定运行，明确的确定性方案往往比 AI 介入更可靠。
信任曾来自可预测性
传统开发中，信任来自可预测性：你了解工具和同事的能力边界，知道他们的优缺点，周一和周二的使用体验基本一致。这种稳定性让团队信任流程、信任工具。
AI 的概率特性，加上迭代速度之快，把这套确定性逻辑打破了。要重建信任，需要在流程层面做出努力：更审慎的工作流设计、更明确的人类判断保留机制。
评论