TLDR

  • 选最强模型
  • 既然做简单任务成功率越来越高，那就把复杂任务拆分成简单任务
  • 面向复杂性管理的工程能力依然人类占优，高工程能力能更准确描述需求去挖掘 AI 的潜力
  • 高质量的文档有利于高质量输出，尤其是项目自己的文档

雇佣 AI 程序员的一年里，我一直在寻找在复杂项目中，更高强度的 AI 代替人类程序员的使用方式。

这是 2025 年 2 月的观察进度表和最佳实践。

选最强模型

目前的最强编码模型依然是 o1 pro。我猜测原因是延长 reasoning 的时间和 o1 本身底子好。

o1 pro 很慢，但不算缺点。因为写代码本来也是想得慢写的快。正确和合理相比速度更重要一些。

简单任务最高

在展示大模型编程实力的时候，经常会让大模型编写一个完整的简单任务，例如 ToDo 这样的 App，贪食蛇这样的小游戏。

这样的任务边界清晰，几乎没有与外部系统交互的需求，而且都不是 zero shot，因此完成得非常好。

所以要利用这一优势：一是使用能用到的最强模型；二是描述需求时严格确定边界，用简单任务组合复杂任务。

关于第二点，就是把每一个模块当作第三方：内部逻辑封装；通过接口对外提供服务；依赖的外部资源通过约定的协议获取。嗯，本来也是软件工程的实践目标，所以遵循这个原则的话，也是在提升工程质量。

例如一次典型的开发需求，她的 prompt 可能是这样的：

implement a golang module, here are requirements:
- requirement 1...
- requirement 2...
- ...

here are interfaces:
- method 1...
- method 2...
- ...

here are dummy functions you may needs:
- function 1
- function 2
- ...

here are criteria:
- criterion 1
- criterion 2
- ...

把 prompt 给到 o1 pro，可以得到目前最好的结果。

工程管理得人类进行

现在大模型在应对最高级工程任务和最低级工程任务的任务时表现很好。最低级就是上面说的「简单任务」。

最高级指对整个架构的抽象，角色是一个接受咨询的架构师，向它提出问题，然后得到一些选择，作为参考，可以说很有帮助。

但是连接二者的中间的部分的工程任务，用过 Devin 和 Cursor 的 Agent，现在的大模型处理复杂工程中间的部分依然不太行。

我理解应该有两个问题：一是关于工程的隐含知识没有体现在代码和文档上，方案和架构的选择上也不存在最优解，有很多脏活；二是模型的接受的内容多了以后，缺少明确的边界，幻觉变得严重。

第二个问题的话，可能需要在工程上做更多工作，比如结合静态分析的结果（猜的，我不是语言分析方面的专家），或者别的东西，目的是缩小问题的规模。

第一个问题的话，本质上代码和文档一样的。如果第二个问题不好解决的话，可能光靠补充知识还不行。

IDE 的话，我觉得无论是 vscode, cursor, windsurf 没有本质的差别。毕竟模型能力有限，如果 IDE 最后给出错误的预测，肯定不如 o1 pro 一次成型来得好。

高质量的文档

虽然代码是自解释的，但是有高质量的文档会提升模型对项目的理解和感知。

这一点如果是 mono repo 会很有优势，因为文档本身就在 repo 里，在 IDE 里指定一个 markdown 文件就够了。

基于这个原因，我现在逐渐开始以项目为单位组织 mono repo 了。

替代人类程序员的可行性

同意的 Sahil Lavingia 的看法：

No longer hiring junior or even mid-level software engineers.

而且我也做了类似 antiwork 的事情。比如类似 Helper 的 AI 机器人，类似 Iffy 的反垃圾。

我的实践经验有：

  • 能力强的工程师运用 AI 得当，得到 5 到 10 倍的产出完全没问题。也就意味着，如果公司是以输出技术能力作为盈利方式，那么在需求量不变的前提下，裁减 50%~80% 的人力是没问题的。
  • 复杂度切分得当，在优秀的工程师监督下，AI 持续迭代中等规模的项目是没问题的（以 Quaily 为例，后端部分核心代码大约 1M token）
  • 好消息是不管 AGI 能不能来，LLM 能力的上界足够改变很多很多很多事情。
    • 坏消息是它的下界比很多人类的上界还要高。
      • 更坏的消息是，所有对好消息理解不到位的人，都在坏消息的影响范围内。