编程，演进：AI 编程助手时代的经验与观察

核心要点：如果你是一名软件工程师，无论什么级别，选择一个模型并将其塑造成你最好的结对编程伙伴。这一情感推广到软件工程之外。

2025 年 12 月草案（v1），2026 年 1 月修订（v2）

我已使用 Copilot、Cody 和 Cursor 大约一年半。今年早些时候发布后不久，我也开始使用 Claude Code、Codex 和 Gemini。使用这些工具，我为团队编写代码和调试问题，并为自己、朋友和家人编写更多代码。这是过去约 18 个月的经验和观察的简要总结。

首先让我定义一些术语。

软件工程 vs. 编程

我喜欢 Titus Winter 对软件工程的定义。软件工程是编程、人员和时间的一个函数。编程是一个人为解决他们知道的问题而使用代码的追求。当你将时间、团队和权衡添加到编程时，就是软件工程。软件工程是一项团队运动。软件工程一直关乎与人员协作以学习和理解问题，编写代码解决问题，发现和修复错误，并随着问题的演变而发展解决方案。

编程经历了几个主要演进。语言从机器代码发展到低级和高级语言，后来发展到面向对象和函数式范式。编程环境从打孔卡发展到行编辑器、屏幕编辑器，最终发展到集成开发环境。在每个阶段，偶然的复杂性被剥离，将编程提炼到其本质：逻辑的组织。这种提炼降低了进入门槛，扩大了程序员库，并使每一代人能够解决比上一代更广泛、更复杂的问题类别。

它正在再次发生，并且比以往任何演进都更广泛、更迅速地发生。我们正处于编程的寒武纪大爆炸之中。

智能体 vs. 助手

我不打算在已经广泛的智能体定义列表中添加另一个定义。相反，为了本文档的清晰度，我将区分智能体和助手。Claude Code 和 Codex 是由多个智能体协同工作的编程助手。编程助手和智能体围绕模型构建。

经验与观察

在过去 12 个月中，编程助手在三个维度上有了显著改进：

1. 模型质量提升：为分布中的语言（即 Python、TypeScript、Rust、Go 等）生成更高质量的代码
2. 更贴近代码库：生成更多基于它们正在工作的代码库的代码，而不是它们训练过的代码库
3. 长时间工作的可靠性：得益于围绕模型构建的硬件创新，编程助手现在可以长时间可靠地处理问题，同时产生连贯的输出

编程助手非常擅长解决已知问题。你不会让它们一致性地一次性完成一个经过良好优化的渲染器或 RL 算法，但作为一个平均程序员，它们可以比我更快更好地编写普通的业务逻辑。当我同时优化生产速度和质量时，它们获胜！

用户界面开发的挑战

它们在生成功能前端和高质量前端代码方面的能力还有改进空间。根据我使用编程智能体开发 Web UI 和 TUI 的经验，我可以说它们在生成美观、功能良好的用户界面以及符合惯用法的代码方面存在困难。

当前模型在 Tailwind 方面表现不佳，在 Ink 方面表现不佳，在 Textual 方面表现不佳，在 Ratatui 方面还可以。不清楚这是采样问题，还是 UI 框架中的繁重抽象使它们绊倒。这些抽象肯定也会让我绊倒。

对于 Web 和移动 UI，我从 Google Stitch 的设计模型开始；Stitch 尚无法为 TUI 生成模型。我认为在模型训练和更好地引导模型构建更高质量 UI 的硬件方面都有工作要做。

模型个性与引导

模型的默认“个性”是尽可能快地解决眼前的问题并获得你的赞美。这种倾向导致它们做出次优决策。例如，我曾发现 Opus 4.5 试图通过让进程“休眠 2 秒”来解决死锁问题。这种个性可以通过适当的引导来改变。

例如，我依赖的一个捷径是在提示中使用“符合惯用法”这个词 - “想出一个符合惯用法的解决方案”或“这是解决这个问题的最符合惯用法的方式吗？”同样，在编写测试或审查测试时，我会在这里和那里加上“被测试函数的意图”，这使模型输出更好的测试。如果你看看 Claude Code 的硬件，他们使用类似的技巧来保持模型在轨道上。

卓越的 bug 发现能力

这些模型，特别是 Opus 4.5 和 GPT 5.2，是卓越的 bug 发现者。我可以指向一个症状，它们可以阅读代码，并发现 bug。然后我要求它们向我解释为什么 bug 发生，并跟随代码查看解释是否正确。我尚未遇到它们未能识别的 bug。它们可以找到死锁和饥饿问题，然后你需要引导它们找到一个好的修复方案（见上文）。

有时，如果我知道某个特定组件有 bug，我要求它们首先为自己创建一个心智模型，然后它们可以找到一些棘手的 bug。

[2026 年 1 月更新] 这并不总是有效。这些模型都未能发现的一个 bug 是 Ghostty 中的这个内存泄漏。我仍在尝试构建它们的心智模型，看看它们是否可以通过修复前的提交的静态分析来发现 bug。

代码质量 vs. 产品质量

代码质量不足以创建产品质量。然而，它是维持产品质量的必要成分。根据我的经验，即使在最佳硬件条件下，主要由编程智能体生成的代码库的产品质量半衰期更短。当你采用编程助手时，请确保也创建围绕助手的健壮技能以提高代码质量。对开源编程助手的代码质量研究将很有启发性。

心智模型的重要性

就像写日记一样，编写软件的过程实际上为你提供了正在构建内容的心智模型。我发现这种心智模型在两种情况下很有用：在做出发展软件的决策时，以及在调试问题（尤其是在事件期间）时。

当编程助手编写大部分软件时，我持有的心智模型的保真度迅速下降。与其对抗这种新常态，我一直在尝试创建方法，使用模型作为工具来按需查询和发展心智模型。这不尽相同，但我认为这将成为一个新的常态。我们需要这个领域的工具，我们可能还需要定期培训软件工程师关于他们系统的故障模式，就像航空业培训其飞行员一样。

从编辑器到“编辑者”的角色转变

多年来，我肯定花了数百小时微调我的终端和编辑器，使其感觉恰到好处。我正在使用那个编辑器编写这个文档，它是我的编辑器。我不再像以前那样在编辑器中花那么多时间了。

现在，我是我的编程助手（Claude Code、Codex 和 OpenCode）的“编辑者”。所以，我花在学习它们上的时间与花在教它们新技巧、技能和命令上的时间一样多。我构建 Catsyphon 和 Aiobscura 只是为了审查和学习我们的交互。此列表中的许多经验教训都来自这样的审查。我将这视为一个成长和指导我的结对编程伙伴的机会。

采用建议

如果你迄今为止一直避免采用编程助手，也许将它们融入的最佳方式是开始使用它们来处理你的繁琐工作。它们擅长理解堆栈跟踪、糟糕编写的代码、总结文档、查询文档以获取具体细节等。它们应该成为你工具包的一部分。

编程助手带有沙箱。然而，沙箱往往会干扰组成助手的智能体。因此我依赖外置沙箱；编程助手外部的沙箱。我现在使用 sandbox-exec 来包含我的会话，并关闭了编程助手中的沙箱。不推荐给所有人，但只是知道你有选择。

手工编程的乐趣

手工编写代码有很多乐趣、美感和愉悦。你仍然可以手工制作代码。只是不要期望这是你的工作。这是你的激情。

文档来源：Programming, Evolved: Lessons & Observations原始发布日期：2026 年 1 月（修订版）

本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处