2026年 AI开发讨论 | JIANTAO.dev
← 技术文章
7 分钟

2026年 AI开发讨论

讨论在2026年使用AI辅助软件开发的优势、限制与程序员角色的变化

AI开发讨论笔记

问题

现在越来越多公司使用 AI 提高开发效率。过去一个网站或软件可能需要多名程序员协作完成，而现在，一个程序员借助 AI 就能完成过去需要多人完成的部分工作。因此经常能看到一种说法：一个程序员加上 AI，等于三个程序员。这是真的吗？

OpenAI 还曾进行过一个更加极端的实验：他们从一个空的 Git 仓库开始，让 Codex 编写项目中的代码、测试、CI 配置、文档、内部工具等内容。项目早期由 3 名工程师驱动 Codex，后来团队扩大到 7 名工程师。五个月后，整个代码库规模达到约一百万行，并合并了大约 1,500 个 Pull Request。OpenAI 团队估计，这个项目所花费的时间大约只有传统人工开发方式的十分之一。这是否意味着，以后软件公司不再需要那么多程序员，甚至最终不需要程序员了？

个人经历

我使用过免费版 ChatGPT 开发网站，也使用过 ChatGPT Plus 辅助开发。 在 Lexicon AB 学习网页开发时，导师们也提到，现在使用 AI 快速开发已经非常普遍，很多公司会默认开发者具备使用 AI 工具的能力。因此，我后来的项目基本都会使用 AI 辅助开发。在这个过程中，我明显感受到了开发速度的提升。

以前遇到一个陌生的问题，我可能需要不断通过 Google 搜索：

  • 这个错误是什么意思？
  • 有没有类似的 Stack Overflow 问题？
  • 官方文档在哪里？
  • 哪一种解决方案适合现在的项目？

现在很多情况下，我可以直接把问题、代码和报错交给 AI，让它先给出可能的解决方案。一个结构不复杂的项目，在 AI 的帮助下，一两天就有可能做出一个可以实际运行的 Prototype。不过，AI 开发并不是“输入一句话，然后软件自动完成”。在我的实际使用中，AI 同样会制造很多新的问题。

上下文带来的错误

我使用免费版时，经常遇到 AI 忘记之前代码结构的问题。例如：AI在后续回答时突然生成一些新的架构，放进项目以后会与已有代码冲突，然后需要把之前的架构修改。在复杂项目中，这种问题会越来越明显。

相比之下，我使用付费版时，这类问题出现得相对少一些。但却更容易留下“代码垃圾”。例如：AI在后续回答时会出现以前的已经弃用的架构的代码。好消息是放进项目以后不会与已有代码冲突。它只是在那里占位置。就算你建立代码规范，在多次回答之后他会忘了然后用生成一些不规范的代码。例如：AI每次生成tailwind的classname都是一个class一行，导致一个classname直接七八行代码。因此，我创建了代码规划：一个classname一行。之后在多次回答后，AI又变回了一个classname七八行代码。

久而久之，项目里会积累大量不规范代码和一堆已经没人使用的函数。对于一个小项目，这可能只是看起来比较乱。但对于一个长期维护的大型项目，这就可能变成技术债务。OpenAI 在自己的 Agent 项目中也遇到了类似问题。他们提到，Codex 会不断模仿代码库中已经存在的模式，包括不好的模式。团队曾经需要花固定时间清理所谓的 “AI slop”。后来，他们没有选择让工程师一直人工清理，而是把好的工程原则写成规则，再让其他 Agent 定期扫描代码、发现问题并自动提交重构。

这说明 AI 不只是提高了“生成代码”的速度，同时也可能提高“制造技术债务”的速度。

AI真的等于多个程序员吗？

我觉得它是对的。一个熟练使用 AI 的程序员可完成过去两三个人才能完成的代码量。

OpenAI 的实验真正值得关注的地方是，在他们的实验中，程序员的工作已经从“亲自写代码”逐渐变成了“设计一个让 AI 能可靠工作的环境”。工程师不再把主要时间花在亲自实现每一个函数，而是开始负责：

  • 定义任务；
  • 设计系统架构；
  • 建立测试；
  • 建立代码规范；
  • 建立反馈机制；
  • 让 AI 可以读取日志和监控；
  • 判断最终结果是否符合需求；
  • 当 Agent 失败时，分析系统缺少了什么能力。

也就是说，AI 能完成“单纯按照明确要求生产代码”的工作了。

潜在风险

对 AI 服务产生依赖

体验过快速开发以后，确实很难完全回到以前纯手写代码的开发方式。这会产生新的依赖问题。如果未来高性能 AI：

  • 提高价格；
  • 改变使用限制；
  • 减少 Context；
  • 某些功能只开放给更高价格的企业版本；

那么高度依赖 AI 开发的个人和公司可能不得不承担这些成本。过去的软件公司主要依赖云服务器、数据库、开发框架和第三方 API。未来可能还会多出另外一种基础设施：

AI 推理能力。

程序员可能失去处理复杂问题的能力

现在如果我想在项目中尝试一个新的框架，可以直接让 AI 生成一个简单项目。这是非常好的事情。因为以前可能需要学习几天甚至几个星期以后，才发现这个框架根本不适合我的项目。现在可以先让 AI 生成 Prototype，快速判断这个技术到底适不适合。但这里也存在一个陷阱：能让 AI 写出来，不等于自己真的会。 程序员很容易产生一种错觉：

“我已经用过 React。”

“我已经用过 Docker。”

“我已经用过这个数据库。”

但实际上可能只是 AI 帮自己生成了代码，而自己并不了解它为什么这样工作。简单项目没有问题。真正发生复杂故障时，问题就会暴露出来。如果程序员无法理解 AI 写出的系统，那么他也很难判断：

  • AI 为什么错了；
  • 错误发生在哪一层；
  • 哪一个修改会影响其他功能；
  • AI 给出的解决方案是否只是表面修复。

因此，我认为未来一个很重要的能力不是“会不会让 AI 写代码”，而是：

能不能判断 AI 写的代码到底对不对。

AI 会非常自信地回答错误答案

AI 生成的回答并不一定正确。OpenAI 在《Why Language Models Hallucinate》中讨论过一个有意思的问题：很多现有训练和评测方式，会在某些情况下奖励模型“猜答案”，而不是奖励模型“承认自己不知道”。假设一个模型只有 40% 的概率知道答案。

如果：

  • 正确回答：1 分
  • 错误回答：0 分
  • 回答“不知道”：0 分

那么从得分角度来说，最合理的策略就是猜。因为“不回答”一定是 0 分，而猜至少还有机会得到 1 分。这也是 AI 开发中一个危险的地方。AI 很可能给出一个非常完整、非常合理的解释。但“解释得很像真的”和“这个解释是真的”完全是两件事情。如果程序员本身没有足够知识判断，就很容易继续按照错误方向修改代码。

AI 开发最大的风险可能不是 Bug

Bug 其实并不可怕。因为 Bug 通常可以：

  • 测试；
  • 发现；
  • 重现；
  • 修复。

更加危险的是：软件可以正常运行，但程序员并不知道它为什么能够运行。这种系统表面上可能完全没有问题。但随着项目越来越复杂，团队对系统的理解越来越少，而越来越依赖 AI 对系统进行解释和修改。最终可能形成：

当 AI 也无法解决问题的时候，没有人能理解这个系统。

权衡

即使存在这些风险，我仍然认为公司几乎没有理由拒绝 AI 开发。

原因很简单：

时间就是成本，而上市速度本身也是竞争优势。

如果两家公司同时发现一个市场机会：

A 公司花六个月完成产品；

B 公司借助 AI，两个月就推出可以使用的版本。

那么即使 B 公司的代码不是最漂亮，它也可能提前：

  • 获得用户；
  • 收集反馈；
  • 验证商业模式；
  • 修复产品方向；
  • 抢占市场。

在这种情况下，很多低概率、长期才出现的问题，公司可能确实会选择暂时接受。这并不是因为这些问题不存在，而是因为商业环境会迫使企业进行权衡。

总结

AI 开发的速度是真的快。即使加上修 Bug、重新解释需求、清理错误代码所花费的时间，很多情况下使用 AI 仍然比完全不用 AI 开发快得多。也意味着市场不再需要那么多只负责写代码的人，但会更加需要能够定义问题、设计系统、判断结果和控制 AI 的工程师。

OpenAI 的实验展示的其实也是这种未来。他们并不是让7个完全不懂软件开发的人用AI开发软件，然后五个月以后软件就自动完成了。相反，这些工程师花了大量精力设计开发软件的系统。换句话说：AI 写了代码，但人类设计了一个让 AI 能够持续正确写代码的系统。

因此，在未来，一个优秀程序员的重要能力可能逐渐变成：

我能让 AI 持续、可靠地生产高质量软件，并且我知道什么时候不能相信它。

参考资料