当大模型替我们写完整个系统，开发者还剩下什么？
一次大模型全量生成前端项目的成功实践，却暴露出“代码黑盒化”的深层风险。本文从开发者角色危机出发，探讨人机协作中“效率”与“系统掌控感”的失衡，并借“基因”与“一沙一世界”隐喻，提出核心契约锚定与分形生成等开放实验方向——不为给出答案，只为引发技术管理者对AI时代工程本质的再思考。
上周，我做了一次“大胆”的尝试：把一份系统需求文档和前端详细设计文档直接喂给大模型，让它生成整个前端项目。
18个文件，10多分钟，项目居然跑起来了——在修复几个编译错误之后。
听起来很高效，对吧？但有一个细节让我后背发凉：在生成过程中，大模型先创建了 src/types/index.ts，随后又“优化”了它，结果覆盖了之前定义的关键类型，导致大量引用报错。幸好我有 Git 提交记录，回滚后问题消失。可那一刻我意识到：这些代码对我而言，已经成了“黑盒”。
如果按照我以往的经验–使用大模型作为辅助，同样的工作量，我初步估计至少得1天。当然，如果从项目的生命周期角度来看，这10分钟的结束并不代表项目的结束。因此，我不是在这里吹嘘大模型的应用会让程序员消失，而是在重新审视程序员在实现生产目标这个过程中的位置和作用。
这和我以往的使用方式截然不同。过去，我会先搭好框架——定义好 API 层、stores、composables、组件结构——再让大模型在既定轨道上“填空”。我知道每一块代码该长什么样，也知道它为何存在。那种模式下，AI 是助手，我是导演。
但这次，我把导演权交了出去。大模型不仅写逻辑，还设计架构、划分模块、定义类型。效率确实高，可我对系统的“感知”却近乎为零。更令人不安的是：如果连我都看不懂这个系统是如何从需求一步步演化而来的，那我的价值在哪里？
这让我想到一个有趣的类比：项目经理通常也不懂代码细节，但他们通过需求、排期、验收来把控项目。如今，开发者面对大模型生成的全量代码，竟也陷入了类似的“认知盲区”——我们是否正在经历一场角色的悄然迁移？
或许，未来的开发者不再需要亲手写每一行代码，而是要成为系统基因的定义者。
什么是“基因”？就是那些不可妥协的核心契约：类型定义、API 接口、状态流转规则。它们应该由人明确写出，并作为“不可变锚点”锁定，再交由大模型在其约束下自由生长。否则，一旦这些根基被AI随意修改，整个系统就会像沙堡一样，在潮水（复杂度）涌来时瞬间崩塌。
这也让我联想到“一沙一世界”——能否通过定义局部规则（如组件模板、数据流范式），让系统在有限上下文中自组织出复杂结构？毕竟，大模型的上下文长度再长（哪怕218K），也无法真正理解一个大型系统的全貌。真正的可扩展性，或许不在于喂更多上下文，而在于设计可递归、可组合的生成单元。
这又让我想起了同样来至于佛陀的一个成语“盲人摸象”，对于我们人类自己，其能理解的上下文也是有限的，哈哈哈。
当然，这次尝试是成功的。但成功不等于可复制。下一个项目可能更复杂，依赖更多外部系统，交互更微妙。那时，大模型会不会在我们看不见的地方埋下更深的隐患？
为此，我想邀请各位技术管理者和开发者一起探索几个小实验：
- 【契约锚定实验】：人工预先定义并锁定
types和api contracts，再让大模型生成其余代码，观察错误率与可控性是否提升； - 【分形生成实验】：将系统拆为多个自治子模块（如每个页面独立生成），再通过统一规范集成，测试是否能规避上下文长度限制；
- 【认知映射实验】：在AI生成后，要求开发者绘制系统架构图并与原始需求对照，量化“理解偏差”程度——这或许能成为衡量“黑盒化”风险的新指标。
这些问题没有标准答案。但正因如此，才值得我们停下脚步，认真思考：
当AI能生成一切，人类工程师的不可替代性，究竟藏在哪里？
——也许，就在那些我们坚持亲手定义的“基因”之中。
我在进行编程智能体的开发与研究，希望能与各项目团队展开合作。
📩 联系方式：请通过 CSDN 私信或项目原仓库（cli_assistant）留言，我会尽快与你联系。
相关阅读：
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
16
0- 0
已为社区贡献8条内容
所有评论(0)