AI 编程的上限是代码行数，还是需求复杂度？

有人成功用 AI 写过 百万行代码的大项目吗？

目前感觉主要还是需求复杂度，不过最终决定上限的肯定是代码行数

一个人能完成百万行级代码么？项目复杂度上去了，并不是一个人就搞定的，需要流水线完成各项分支作业，要不为什么有软件工程这个概念呢。

人工智能一样啊，复杂大工程拆分成小功能，每个功能用 VibeCoding 实现。所以关键还是有各种岗位的 AI ，什么需求分析 AI 、系统架构 AI 、代码 AI 、测试 AI 。。。。

最后什么都不是上限相比人有上限：团队能力，人力成本，时间周期等

复杂度啥的，主要受限就是上下文也就是代码行数，等上下文能完整塞进你的全部代码或者说有另一种不是上下文的完整记忆系统出现，什么复杂度的不能完成。

结合上面的观点，针对大型项目，主要是如何合理拆分模块，而不是将全部代码直接塞给 AI 处理。
如何正确引导 AI ，让 AI 每次会话能够智能的处理只和此次会话相关的内容，确保上下文不爆。

你用不用 ai 不做合理工程化人脑更没戏啊

个人的话做了几个，基本 10w+行级别，估计迭代迭代也就最多几十万行不得了了，百万行以上的确实需要更多不断精力 的投入，不是 AI 一会功夫就能搞定的

这个无所谓

真到那么大了, 必然可以拆成可完成的小项目或模块的

对 AI 来说, 每次能完成的任务在能力范围内就行, 几万行我认为足够

真正的上限是上下文窗口，大项目拆模块成自广是必要的，这个其实和人类写代码一样。清晰边界的模块手工 review 一下再给 AI ，效果能上去很多。

@James369 直接泥巴厂的全部给复刻了不就知道了

我觉得在这个方面，确实要考虑多把 LLM 当成人来看待。

作为一个大型项目，不可能有人能对项目功能了解的很细致。所以才需要由多个人负责不同的模块，同时暴露出良好的接口，让模块之间能够相互调用并进行扩展设计。

让 LLM 在设计系统的时候才能够通过只获得接口的 context 来保证良好的构建.

@James369 #1 openclaw 吗？不知道有没有百万

我觉得上限应该是自己的钱包……

AI 能提速，但不能无中生有，上限在于工程

一个项目的工程做的好的话，用 AI 能事半功倍

AI+人永远比纯 AI 更有用

可能是我火星了，但目前为止没看过 prod 项目是纯 AI 写，去年一直在吹（ RPI - Read Plan Implement),今年基本上都回归阅读代码。

当然，很多个人项目是纯 vibe ，不能评价好不好，能用就行，不能用也没人找你，开源项目最多被嘴两句

甚至不是需求复杂度，而是需求特异度

代码复杂度本来就不能用行数来衡量。

AI 的上限是使用 AI 的人，有些指令和代码的思路，算法还是需要人为提示的，如果使用者没有把握大工程的能力，AI 也完成不了大工程

本质上还是上下文，你把人脑想象成一个无穷上下文就好了

@James369

钱包的鼓涨程度。AI 编程的上限是你有多少 token 能用。

有啊，今天我就看到一个人发了项目。小黑盒，不会写代码的开发者做的 CRM 系统。100 万行代码。已经开始出售盈利了。

AI 的上限取决于 AI 能否真正实际感知到程序的运行结果

比如 带 UI 的产品, AI 是否能准确测试并感知到改动的效果, 其实是很难的, 静态的 UI 还能截图多模态分析,做一些稍微有点动态效果的就无法完成 编码->验证效果 的闭环了

所以对纯后端 API 似乎是最好用的. 因为可以闭环验证. 其他都容易退化成需要人来辅助,这时候就变成作为辅助的"人"的效率不够好,描述/反馈不够准确的问题了

我认为，对于通常（不超过 AI 知识上限）的项目而言，AI 编程的上限是项目含量
参考文献：Software Fundamentals Matter More Than Ever

依赖于使用者：化繁为简的能力

我在用 AI 维护一个 300W 行代码的项目，并非整个项目一开始就用 AI 做的，而是这个项目运行了几年后，去年下半年开始引入 AI 。我的看法是 AI 阅读理解代码的能力强无敌

- Full Attension 带来的是针对每一个词都倾注了同等的注意力，类比人类就是每个字都认真看
- Prefill 是并行填充的，也就是看同样的内容，人只能一个一个看，LLM 可以并行看

每个字都认真 + 并行看，实现了 AI 阅读理解已有代码的能力强无敌的现状

所以只要代码不是特别烂，AI 要研究很多东西才能最终确认实现细节，只要人给 AI 一个方向，就能收集好当前的设计细节了。再基于这些信息去做 Spec ，或者直接 Vibe （根据要改动的问题复杂度），基本能实现对 Coding 的提效