这是一个创建于 303 天前的主题，其中的信息可能已经有所发展或是发生改变。
我现在总觉得 我实现一个需求 如果用 ai 完整实现 是一段代码
但是现在所谓的 MVC 或者 Spirng 这些框架 似乎都在妨碍 ai 写代码
首先文件要分布很多地方 并且 ai 学习框架工具还是有一定的难度 稳定性不如原生库
是不是应该有个 ai as a service 写好了直接 run 搞成很小的 ai 服务 全部交给 ai 代写
实际上 代码能跑就行 ai 写的代码很多冗余 很浪费资源 但能跑就行 这会不会挑战很多人的底线
不知道我说明白没有
 |
1
ztm0929 303 天前 via iPhone
能理解 OP 的意思😂不过个人（编程小白）觉得，这样的服务必须要朝着提升实际代码能力的目标开发，否则推广的可能性比较小。
从生产角度来看，资本的特性决定了老板们肯定需要利益最大化，尽可能地节省资源； 从爱好角度来看（也就是我自己这种编程小白的角度），“知其然而不知其所以然”的代码生成模式恐怕也不利于学习； |
 |
2
cherryas 303 天前
类似流浪地球那种？ 整个代码完全是 ai 写的？
|
 |
3
corcre 303 天前  2
除非能完全满足需求而且维护/升级/修改这样的要求都给 AI 完成, 不然要人去改点啥那可真是要了老命了
|
 |
4
947347 303 天前 via iPhone 1
看看 gpt-runner
|
 |
5
makerbi 303 天前
大部分的 LLM 上下文长度也就 32k ，导致很难把一个完整的中型项目或者小型项目+文档放到上下文里，也就无从谈起跨文件理解架构和函数调用之类的需求。所以目前比较期待 Google 的 1M 上下文长度 Gemini 1.5 Pro 来实现完整理解代码项目。根据一些内测用户的反馈确实能够达到放一个完整代码项目进去然后实现新功能。
|
 |
6
PiersSoCool OP @ztm0929 这也是我最纠结的地方，如果破坏性变革，基本上很难推行，但是现在边生成边改也挺痛苦的（有时候
|
|
7
PiersSoCool OP @cherryas 框架是 ai 编写的，人类最好在里面改改（监督）即可，省事
|
|
8
PiersSoCool OP @makerbi 这个好！
|
 |
9
cutchop 303 天前
如果代码由 AI 维护，确实不需要设计模式了，什么 MVC 、MVVM 、MPV 、SUV 、UFO 都不需要了
|
 |
10
HXHL 303 天前
|
|
11
HXHL 303 天前
@HXHL 奇怪，中文链接怎么没有办法打开呀，[链接]( https://correctroadh.github.io/p/ai 是否会带来编程范式上的改变/)
|
|
12
HXHL 303 天前 1
|
 |
13
Haku 303 天前
我感觉直接把 AI 做成一个可自我解释的 Agent 这样就挺好的。
入口本身是一个对话，你需要什么东西，让 AI 自己写自己的插件，写完后入库登记相当于 AI 增加了一项新功能。 |
 |
14
mightybruce 303 天前
看了表示，你对 AI 理解太过肤浅。多看看大厂和国外公司具体 AI 结合代码的产品吧。
|
 |
15
zhouyg 303 天前 1
你说的这种就是现在说的 ai first 的编程理念，现在的 ai 编程其实都是机器人打算盘
|
|
16
PiersSoCool OP @Haku 我也是这么想的，如果能直接部署就好了
|
 |
17
Leviathann 303 天前
为什么不用 ai 直接生成二进制？
|
 |
18
rocmax 303 天前 via Android 1
ms 有个 autogen ，就是用 chatgpt 模拟多个角色，互相协作来完成任务，可以让一个角色先设计架构，再把任务细分，然后另一个角色负责生成子任务的对应代码，再有另外一个角色测试，最后再组合。
|
|
19
PiersSoCool OP @Leviathann 你还别说，算力增加 1000000000 倍的时候可以让他学习二进制？
|
|
21
PiersSoCool OP @rocmax 感觉确实是这个方向
|
 |
22
hyperbin 303 天前 via Android 1
那还不如直接让 AI 机器码得了，一步到位
|
 |
23
YUyu101 303 天前 1
感觉 ai 更适合函数式编程，可以把注意力集中到一个函数让它去实现，而大型项目上下文过长，其他已实现的部分可以通过只提供函数签名和注释让 ai 获取到，用框架的话除非每次提供完整框架文档+所有依赖库+所有文件当作上下文，不然总感觉不完整。
|
|
24
makerbi 302 天前
@947347 是的，但是目前大部分 LLM 特别是开源的 LLM 还是以 32k 为主，而且如果要自己部署生产环境的开源 LLM ，考虑硬件配置的话，32k 现阶段比较合适。
|
 |
25
NessajCN 302 天前
真正要实用的 ai 编程它就不该编成任何人类用的编程语言，而是要直接编机器码才对。
|
 |
27
fwindcore 302 天前
是的，让 AI 写汇编就好了，用性能换取可读性。
|
 |
29
yule111222 302 天前
目前还达不到，等 AI 实现 AGI 了就可以了
|
 |
30
LDa 302 天前
https://github.com/unit-mesh/auto-dev 这个项目是一种可能性 上下文受限的情况下 框架不是整好控制代码的规模吗，再按功能开发
|
|
32
rocmax 302 天前 via Android
换个角度想，所谓框架就是基础工具集，对程序员来说可以避免重复劳动提高效率。但是导入框架肯定也添加了一堆没使用的代码。
ai 可能不需要框架，直接生成功能代码即可。 |
|
33
PiersSoCool OP @rocmax 是这样，但这种 break ，除非真的是 AGI 那种，目前看大多数情况必须需要修改
|
 |
34
cheneydog 302 天前
人应该只写需求文档，其他的都 AI 实现就对了。
|
 |
35
mxT52CRuqR6o5 302 天前
对人阅读困难编写困难代码，对 AI 来说也是更困难的
|
 |
36
xuanbg 302 天前
一句话需求 AI 也是爱莫能助
|
 |
37
param 302 天前 via Android
ide 的出现让编程语言适应 ide ，那么 llm 的出现也会让编程语言适应 llm
|
 |
38
prenwang 302 天前
这种担心完全多余， 你会发现那一天突然出现一个 模型， 名字可能叫做 SpringCodeX , 也就是基于开发框架微调的模型， 或者你会发现 github copilot 提供针对各种框架的加强，去看看最新的 github copilot 企业版的功能特性吧。
对于 AI 来说，Code 是最容易优化的特性，coding 不会为了爆流量写玩弄人性的鬼话， 向 github copilot 这种每时每刻大量反馈的场景， 无时不刻在增强 AI 的 coding 能力。 大模型的上下文长度已经在向无限制接近， 至少 2024 年 还会来几个大惊喜， 最新的 codellama 还没出来呢。 这些重要的 Code AI 每年都至少两次大更新， 在座的各位不要有什么幻想了， 大家都是奔着下岗去的， 这一天其实来的越早越好。 |
 |
39
LeoJ 302 天前
应该是人只要求输出结果和编写测试用例，实现过程都不管～ 哈哈
|
 |
40
luckycat 302 天前
面向 AI 编程
|
|
41
PiersSoCool OP @prenwang 确实，无限上下文
|
Select Language