绿然智老照片修复器
58.03M · 2026-02-12
作者 | kulesh
编译 | 岳扬
TL;DR: 如果你是一名软件工程师，无论资历深浅，选一个模型，并把它打造成你最得力的结对编程伙伴。这一理念同样适用于软件工程之外的领域。
过去约一年半的时间里，我一直在使用 Copilot、Cody 和 Cursor。今年早些时候，Claude Code、Codex 与 Gemini 发布后[1]，我也很快开始尝试。借助这些工具，我不仅与团队协作完成代码编写和问题调试，也为我自己、朋友和家人开发了更多项目。本文简要记录了我在过去约 18 个月中的心得与观察。
首先，让我明确几个术语定义。
我认同 Titus Winters 对软件工程的定义[2]：软件工程是由 programming（编程）、people（团队协作）和 time（随时间不断演进）这三个要素共同决定的。编程是一个人运用代码解决已知问题的过程；而当我们在编程中引入时间、团队协作和各种权衡取舍时，就变成了软件工程。软件工程的核心始终在于：与团队协作来深入理解问题的本质，编写代码将解决方案落地，排查并修复 Bugs，同时随着问题的变化持续迭代优化方案。
编程技术经历了数次重大的演变。编程语言从机器码发展到低级语言和高级语言，再到后来的面向对象和函数式编程。编程环境也从打孔卡演进到行编辑器、全屏幕编辑器，最终发展为集成开发环境（IDE）。在编程发展的每个阶段，那些与问题本质无关的、因技术限制而产生的额外复杂性都被逐步消除，使得编程活动越来越聚焦于其最核心的任务 —— 即“逻辑的组织与构建”。 这种精炼过程降低了编程的入门门槛，扩大了程序员群体，也让每一代开发者能够解决比上一代更广泛、更复杂的问题。
如今，这种变革正在再次发生，而且比以往任何一次演进都更加广泛、更加快速¹。我们正身处一场编程领域的“寒武纪大爆发”²。
我并不打算在已然繁多的智能体定义[3]中再增添一条。相反，为使本文内容表述清晰，我将对“智能体”（agents）和“编程助手”（assistants）加以区分。Claude Code 和 Codex 是由多个协同工作的智能体组成的编程助手。编程助手和智能体都是围绕核心模型构建的。
1）在过去 12 个月里，编程助手在以下三个维度上取得了显著进步：
2）编程助手非常擅长解决已知问题。你不太可能让它们一次性写出高度优化的渲染器或强化学习算法，但就常规业务逻辑而言，它们写得比我这样的普通程序员更快、更好。当我需要同时兼顾开发速度和代码质量时，它们完胜！
3）不过，它们在生成可运行的前端界面和高质量前端代码方面仍有提升空间。 根据我使用编程智能体开发 Web UI[4] 和 TUI[5] 的经验，它们很难生成既美观又功能完善、且符合惯用写法的用户界面。当前的模型对 Tailwind、Ink、Textual 支持很差，对 Ratatui 表现尚可。目前尚不清楚这是一个采样问题（sampling problem），还是 UI 框架中大量抽象层让模型“卡壳”了 —— 这些抽象层确实也常让我头疼。对于 Web 和移动端 UI，我会先用 Google Stitch[6] 生成设计稿，不过目前 Stitch 尚不支持为 TUI 生成原型。我认为，无论是在模型训练还是控制/编排框架层面，都需要进一步改进，以更好地引导模型生成高质量 UI。
4）模型默认的“性格”是尽快解决眼前的问题，以赢得你的称赞。这种倾向导致它们会做出次优的决策。 例如，我曾发现 Opus 4.5 试图通过让进程“sleep 2 秒”来解决死锁问题。但这种性格可以通过适当引导加以调整。我常用的一个技巧是在提示词中加入“idiomatic”（惯用的）一词 —— 比如“给出一个惯用的解决方案”或“这是解决该问题最惯用的方式吗？”同样，在编写或审查测试时，我会时不时提到“被测函数的预期行为”，这能让模型输出更高质量的测试。如果你查看 Claude Code 的控制/编排框架[7]，会发现他们也用了类似的技巧[8]来约束模型行为。
5）这些模型（尤其是 Opus 4.5 和 GPT 5.2）在寻找 Bug 这方面表现惊人。只要指出一个“症状”，它们就能阅读代码并定位出 Bug。 接着我会让它们解释 Bug 产生的原因[9]，并对照代码检查解释是否正确。截至目前，我还没遇到它们无法识别的 Bug³。它们能发现死锁和资源匮乏问题，但你需要引导它们找到好的修复方案（见上文）。有时，如果我知道某个组件有 Bug，我会先让它们构建一个“心智模型（mental model）”，然后它们就能找出一些非常棘手的 Bug。不过这一方法并非总是有效。例如，Ghostty 中的一个内存泄漏问题[10]，这两个模型（Opus 4.5 和 GPT 5.2）都没能识别出来。我仍在尝试通过搭建更有效的“心智模型”，看它们能否通过静态分析，在修复方案提交之前的代码中发现该 Bug。
6）代码质量不足以保证产品品质，但却是维持产品品质的必要条件。 据我观察，即使有最好的提示词工程支持，主要由编程助手生成的代码库，其产品品质的“半衰期”也更短。因此，在开始使用编码助手后，你必须同时培养一套驾驭、管理和监督助手的扎实技能[11]，以确保代码的质量。对开源编程助手所生成代码的质量进行系统性研究，将会很有启发性。
7）正如写日记一样，编写软件的过程实际上能让你对所构建的东西形成一个良好的心智模型。我发现这个心智模型在两种场景下很有用：一是决定软件如何演进时，二是在调试问题时（尤其是在故障处理期间）。当编程助手承担了大部分编码工作时，我所持有的心智模型的保真度便会迅速下降。我没有试图对抗这种新常态，而是一直在探索各种方法，将模型作为一种工具，按需查询和构建思维模型。这与亲自构建软件产品不同，但我认为这将是一种新常态。我们需要为此开发新工具，也可能需要像航空行业培训飞行员那样，定期培训软件工程师了解其系统的故障模式。
8）多年来，我花了几百个小时精心调校我的终端和编辑器[12]，以期达到完美手感。我现在正用这个编辑器撰写本文 —— 它是“专属于我的”编辑器。但我现在花在编辑器里的时间不再像以前那么多了。相反，我成了自己编程助手（Claude Code、Codex 和 OpenCode）的“编辑器”。我花同样多的时间去了解它们，也花同样多的时间教它们新技巧、新技能和新命令。我开发了 Catsyphon[13] 和 Aiobscura[14]，就是为了能回顾我们的交互并从中学习。这份清单中的许多经验，正来自这些复盘。我把这看作一次成长的机会，也是在培养我的结对编程伙伴。
9）如果你至今仍未使用过编程助手，或许最好的上手方式就是从让它们帮你处理繁琐重复的任务开始。 它们擅长理解堆栈跟踪、梳理混乱代码、总结文档、以及针对具体问题查询文档等。它们理应成为你工具包的一部分。
10）编程助手自带沙箱（sandbox），但这个沙箱往往会妨碍组成编程助手的各种智能体的正常工作。因此我转而使用外部沙箱 —— 一个独立于编程助手之外的沙箱。我现在使用 sandbox-exec 来隔离会话[15]，并关闭了编程助手内部的沙箱功能。这不一定适合所有人，但至少你要知道：你有选择。
11）亲手编写代码蕴含着独特的乐趣、美感与成就感。你依然可以选择像工匠一样亲手打磨代码。只是别指望这还能是你的职业饭碗。这纯粹应当是你的热爱所在。
1 这一演变正在加速，因为分发渠道已经成熟，技术栈的大多数层级如今都由软件构成，并且从业者网络规模庞大、联系紧密。
2 将此称为软件工程（而非编程）的“寒武纪大爆发”或许听上去有些宏大，但方向上是正确的。最终的定论，且留待对 2026 年的回顾时再下。
3 此后我遇到了一个反例：Opus 4.5 将系统不稳定的原因归咎于 macOS 虚拟化层，而根本原因其实是连接池耗尽。我最终让它对代码进行二分查找才发现了这个问题；而在那之前，它已经把 vz 替换成了 Qemu :-)
END
本期互动内容
当你把 70% 的编码工作交给AI后，你发现自己最重要的技能变成了什么？
文中链接
[1]github.com/kulesh/dotf…
[2]www.you@tube.com/watch?t=472…
[3]simonwillison.net/tags/agent-…
[4]github.com/kulesh/cats…
[5]github.com/kulesh/aiob…
[6]stitch.withgoogle.com/
[7]www.anthropic.com/engineering…
[8]medium.com/@outsightai…
[9]x.com/kulesh/stat…
[10]mitchellh.com/writing/gho…
[11]github.com/kulesh/dotf…
[12]github.com/kulesh/dotf…
[13]github.com/kulesh/cats…
[14]github.com/kulesh/aiob…
[15]github.com/kulesh/dotf…
原文链接：
github.com/kulesh/dotf…
