用 ai 写代码是不是该换种方式了

[PiersSoCool]

我现在总觉得 我实现一个需求 如果用 ai 完整实现 是一段代码

但是现在所谓的 MVC 或者 Spirng 这些框架 似乎都在妨碍 ai 写代码

首先文件要分布很多地方 并且 ai 学习框架工具还是有一定的难度 稳定性不如原生库

是不是应该有个 ai as a service 写好了直接 run 搞成很小的 ai 服务 全部交给 ai 代写

实际上 代码能跑就行 ai 写的代码很多冗余 很浪费资源 但能跑就行 这会不会挑战很多人的底线

不知道我说明白没有

[ztm0929]

能理解 OP 的意思😂不过个人（编程小白）觉得，这样的服务必须要朝着提升实际代码能力的目标开发，否则推广的可能性比较小。
从生产角度来看，资本的特性决定了老板们肯定需要利益最大化，尽可能地节省资源；
从爱好角度来看（也就是我自己这种编程小白的角度），“知其然而不知其所以然”的代码生成模式恐怕也不利于学习；

[cherryas]

类似流浪地球那种？ 整个代码完全是 ai 写的？

[corcre]

除非能完全满足需求而且维护/升级/修改这样的要求都给 AI 完成, 不然要人去改点啥那可真是要了老命了

[947347]

看看 gpt-runner

[makerbi]

大部分的 LLM 上下文长度也就 32k ，导致很难把一个完整的中型项目或者小型项目+文档放到上下文里，也就无从谈起跨文件理解架构和函数调用之类的需求。所以目前比较期待 Google 的 1M 上下文长度 Gemini 1.5 Pro 来实现完整理解代码项目。根据一些内测用户的反馈确实能够达到放一个完整代码项目进去然后实现新功能。

[PiersSoCool]

@ztm0929 这也是我最纠结的地方，如果破坏性变革，基本上很难推行，但是现在边生成边改也挺痛苦的（有时候

[PiersSoCool]

@cherryas 框架是 ai 编写的，人类最好在里面改改（监督）即可，省事

[PiersSoCool]

@makerbi 这个好！

[cutchop]

如果代码由 AI 维护，确实不需要设计模式了，什么 MVC 、MVVM 、MPV 、SUV 、UFO 都不需要了

[HXHL]

去年就思考过了
https://correctroadh.github.io/p/ai 是否会带来编程范式上的改变/
😂主要觉得 ai 就可以用可读性换性能了。

[HXHL]

@HXHL 奇怪，中文链接怎么没有办法打开呀，[链接]( https://correctroadh.github.io/p/ai 是否会带来编程范式上的改变/)

[HXHL]

@HXHL 这次应该可以🤔

https://correctroadh.github.io/p/ai%E6%98%AF%E5%90%A6%E4%BC%9A%E5%B8%A6%E6%9D%A5%E7%BC%96%E7%A8%8B%E8%8C%83%E5%BC%8F%E4%B8%8A%E7%9A%84%E6%94%B9%E5%8F%98%2F

[Haku]

我感觉直接把 AI 做成一个可自我解释的 Agent 这样就挺好的。
入口本身是一个对话，你需要什么东西，让 AI 自己写自己的插件，写完后入库登记相当于 AI 增加了一项新功能。

[mightybruce]

看了表示，你对 AI 理解太过肤浅。多看看大厂和国外公司具体 AI 结合代码的产品吧。

[zhouyg]

你说的这种就是现在说的 ai first 的编程理念，现在的 ai 编程其实都是机器人打算盘

[PiersSoCool]

@Haku 我也是这么想的，如果能直接部署就好了

[Leviathann]

为什么不用 ai 直接生成二进制？

[rocmax]

ms 有个 autogen ，就是用 chatgpt 模拟多个角色，互相协作来完成任务，可以让一个角色先设计架构，再把任务细分，然后另一个角色负责生成子任务的对应代码，再有另外一个角色测试，最后再组合。

[PiersSoCool]

@Leviathann 你还别说，算力增加 1000000000 倍的时候可以让他学习二进制？

[947347]

@makerbi 没记错的话 gpt4 是 128k 上下文，以及 4k 单次回复上限

[PiersSoCool]

@rocmax 感觉确实是这个方向

[hyperbin]

那还不如直接让 AI 机器码得了，一步到位

[YUyu101]

感觉 ai 更适合函数式编程，可以把注意力集中到一个函数让它去实现，而大型项目上下文过长，其他已实现的部分可以通过只提供函数签名和注释让 ai 获取到，用框架的话除非每次提供完整框架文档+所有依赖库+所有文件当作上下文，不然总感觉不完整。

[makerbi]

@947347 是的，但是目前大部分 LLM 特别是开源的 LLM 还是以 32k 为主，而且如果要自己部署生产环境的开源 LLM ，考虑硬件配置的话，32k 现阶段比较合适。

[NessajCN]

真正要实用的 ai 编程它就不该编成任何人类用的编程语言，而是要直接编机器码才对。

[maemolee]

@YUyu101 也就是说，工程师负责想好要有哪些函数，函数的入参出参，让 ai 实际写代码

[fwindcore]

是的，让 AI 写汇编就好了，用性能换取可读性。

[depeng]

@NessajCN 黑箱编程? 那么问题来了: 谁来监管 AI

[yule111222]

目前还达不到，等 AI 实现 AGI 了就可以了

[LDa]

https://github.com/unit-mesh/auto-dev 这个项目是一种可能性 上下文受限的情况下 框架不是整好控制代码的规模吗，再按功能开发

[NessajCN]

@depeng 为啥要监管？编出来机器码能跑通就行了呗，不然像现在似的生成一大堆人类编程语言还得编译了才能知道通不通，直接机器码不就能方便验证程序对错了吗

[rocmax]

换个角度想，所谓框架就是基础工具集，对程序员来说可以避免重复劳动提高效率。但是导入框架肯定也添加了一堆没使用的代码。
ai 可能不需要框架，直接生成功能代码即可。

[PiersSoCool]

@rocmax 是这样，但这种 break ，除非真的是 AGI 那种，目前看大多数情况必须需要修改

[cheneydog]

人应该只写需求文档，其他的都 AI 实现就对了。

[mxT52CRuqR6o5]

对人阅读困难编写困难代码，对 AI 来说也是更困难的

[xuanbg]

一句话需求 AI 也是爱莫能助

[param]

ide 的出现让编程语言适应 ide ，那么 llm 的出现也会让编程语言适应 llm

[prenwang]

这种担心完全多余， 你会发现那一天突然出现一个 模型， 名字可能叫做 SpringCodeX , 也就是基于开发框架微调的模型， 或者你会发现 github copilot 提供针对各种框架的加强，去看看最新的 github copilot 企业版的功能特性吧。

对于 AI 来说，Code 是最容易优化的特性，coding 不会为了爆流量写玩弄人性的鬼话， 向 github copilot 这种每时每刻大量反馈的场景， 无时不刻在增强 AI 的 coding 能力。

大模型的上下文长度已经在向无限制接近， 至少 2024 年 还会来几个大惊喜， 最新的 codellama 还没出来呢。

这些重要的 Code AI 每年都至少两次大更新， 在座的各位不要有什么幻想了， 大家都是奔着下岗去的， 这一天其实来的越早越好。

[LeoJ]

应该是人只要求输出结果和编写测试用例，实现过程都不管～ 哈哈

[luckycat]

面向 AI 编程

[PiersSoCool]

@prenwang 确实，无限上下文

[prenwang]

@LeoJ 哪里呀， AI 自己编程， 自己测试验证。

人只有提需求的， 检查需求是否实现， 动动嘴即可， 比如把界面换个颜色， 那个图标换个二次元头像。

真正实现人人都是产品经理