看好几个人在论坛说自己公司的项目用 ai 出问题了，问 ai 代码如何审查的问题， 经常看到有人回答“你们公司没做好边界吗”这种话，意思就是做好边界真的能完全解决这些问题吗？现在有没有一个比较大的项目是所谓的那种“做好边界，完全 ai 写出来的”项目？
 |
1
bunai 2 days ago
能骗到钱就行
有 ai 了谁还管这个事，那都是领导自己想去，一句话我让 ai 看看 |
 |
2
lkk 2 days ago
让另外一个 AI 做攻击审查，再找一个 AI 做三方审查。不给配额是公司的事，再出了问题那已经尽力了。
|
 |
3
yyttrr 2 days ago
微服务抽象和 devops 搞得好的话,用 ai 还是很简单安全的
|
 |
4
ldx78203199 2 days ago  2
大项目这种 vibe 中后期太痛苦了，前期看起来很爽一波输出，调试+修问题+各种中间对话，成本其实更高 而且会不可控
|
 |
5
aru 2 days ago
开个 OPC ，项目代码都是 vibe 出来
|
 |
6
Essaim 2 days ago
傻逼产品做了个独立项目，RPC 自动化一些页面流程，觉得自己天下无敌了。
现在期望推开发的纯 vibe ，质问他上线出了问题谁负责，他说团队责任。 |
 |
7
emSaVya 2 days ago
有的。线上项目 100%是 AI 在迭代开发了
|
 |
8
TomatoCLI 2 days ago 4
有的人的已经上线 N 次了，vibe 了 N 个大项目了。有的人还在那里怀疑。
|
 |
9
HappyAndSmile 2 days ago
@TomatoCLI 你就说 vibe 的那些大项目是不是一堆 bug
|
 |
10
loveumozart 2 days ago
字节跳动现在很多代码都是 AI 写的了，我问还在字节的朋友说，他们已经 AI 写代码很久了
|
 |
11
bojue 2 days ago
@HappyAndSmile 也不一定，开发过程做好边界和测试，基本上和手动挡没区别，我已经一年没写过代码了
|
 |
12
seven777 2 days ago via iPhone
能准确解释下“边界”吗？
|
 |
13
happinessnch 2 days ago
Vibe Coding 是从去年下半年开始流行的吧。
到现在才不到一年，从 0 开始的“大”项目不到一年是上不了线的， 我理解的大项目 20+开发人员，开发 2 年以上（ AI 时代，游戏项目）。 用 SDD 可以提高 AI 的边界感，但不能完全解决。 |
 |
14
redbule 2 days ago
害怕 ai 出 bug 的有没有想过一个问题，人写的就没 bug ？
以前人要几周的工作量，现在 ai 几天就做好了，多的时间迭代改 bug 不更好么。 |
 |
15
xue777hua 2 days ago via iPhone
|
 |
16
wu00 2 days ago
管理层要求 100% AI Coding
SDD 已经干了大半年了，vibe 和表演各占一半把  |
|
17
HappyAndSmile 2 days ago
@bojue 你是不是说的是本来已存在的大项目，后来才通过完全 AI 开发的？我自己也是啊，这种还好，我回应他的是从 0 到 1 完全是 AI 出来的大项目，我自己有一个内部日志平台，就是这样的，完全不可能再人工 review 和开发了，bug 也很多，都是自己做实际测试弄出来去修复
|
|
19
emSaVya 2 days ago 3
@xue777hua v 站程序员的水平连 claude sonnet 3.7 都比不上。哪来的自信 “人出的 bug 人能改。AI 出的 bug 到后期 谁都搞不定”
|
 |
21
lwfre 2 days ago
大项目没有，小项目有。AI 前后端一块写，速度很快，还不用沟通...
|
 |
22
xooass 2 days ago 1
完全 vibe 了一个电话 crm 系统 目前给菲律宾客服部门在用 nodejs 的 稳定了几个月了
|
|
23
TomatoCLI 2 days ago 1
@HappyAndSmile 复盘的时候发现，测试阶段 bug 量比之前纯人工还少。只是严重的 Bug 占比更多。。。其他 vibe 不 vide 的，反正用户认可就是好的开发方式。
|
 |
24
Tink 2 days ago
这种项目上线之后，后期怎么维护呢？也靠 AI？
|
 |
27
WashFreshFresh 2 days ago 4
咋说呢，纯 vibe 出来的项目，就是把压力全给到了测试。如果测试没测好，上线出了问题，全部人都在看你傻乎乎的对着聊天界面贴日志，描述问题...
|
 |
28
zsmile 2 days ago
大项目有再弄，但是越复杂的项目，你对整体越失控，现在就是频繁靠 agent 审阅返修
|
|
29
HappyAndSmile 2 days ago
@TomatoCLI #23 你的这个我也认同，我也是同样现象，总体 bug 数量少了，但严重的和低智的比例确实多了；现在我就是两条路线走，原有的旧项目迭代，还是需要认真 review 代码，尽可能增量式兼容式修改，而纯 AI 代码的项目，就已经不会再 review 多一行，让它改完再测，再改再测。。
|
 |
30
tiiis 2 days ago
整个项目的没有，一个项目全新重构模块用 AI 还不错，不过已经算是黑盒了，迭代太快大部分代码都没打开看过，唯一能保证的就是能通过外部老模块去验证
|
 |
31
SanjinGG 2 days ago
@emSaVya #19 人能改的意思是，人写的代码，他烂你也能一眼看出烂，但还是能理解大致意思。ai 却会存在微积分算加法的情况，你在拆解过程中能还原意图嘛？真受不了你们喜欢跟模型比的，我很好奇你又能够得上哪个梯队的模型？你在其他人眼中不照样是个豆包
 |
 |
33
aoyi 2 days ago
换一个问题：你们多久没有手写代码了？
|
|
35
bojue 2 days ago
@HappyAndSmile #17 一部分吧，之前我们走低代码方案
1. 后端 ORM+JSON 化配置 2. 前端低代码 JSON 配置+通用组件 很好的解决了幻觉问题 bug 主要是业务 bug ，感觉技术本身的 bug 不多,如果有测试用例的话，弱智的 bug 问题估计可以解决，但是杜绝不了 还是要 review ，有时候冒烟测试都有问题 |
|
39
SanjinGG 2 days ago
@emSaVya #36 我以为你清华毕业的能读懂我这种底层人的意图的
 ，真是太让我伤心了。原来头部公司做的东西都是行业标杆啊，国内那卡的 tm 自己都不愿意用的软件你也能舔，你真是这个👍。还 100%模型生成，除了趁机降本，我也没看到使上 ai 增加了什么营收，还是说在本来的屎山上加了个 ai 入口，给你这种无脑 ai 的整高潮了？要不你细说？ |
 |
41
shilianmlxg 1 day ago via iPhone
感觉到后面需求膨胀了，你必须得非常熟悉需求，如果是 ai 头脑风暴出来的需求和页面，到后面会有失控感
|
 |
42
nofishing 1 day ago
现在还有不 vibe coding 的公司吗？
|
 |
43
xAI 1 day ago
claude 和 openai 好多都是 AI 写的代码
|
 |
44
onikage 1 day ago via iPhone
手上有一个工业小项目已经和老系统并行试运行快一个月了，另外一个计划月底上线。全程没写过一行代码。
|
 |
45
whyrookie 1 day ago via Android
还是古法编程，和 AI 不断讨论设计，确保每段代码都看过并且理解可以随时定位问题
|
 |
46
wu67 1 day ago
有个项目这样上了, 不过还没最终交付, 只能说能跑. AI 出需求 AI 写, 主打一个能用.
而且我现在也不想打开来看代码, 我知道里面有不少能直接几行代码能解决的逻辑、它非要写一大坨来处理的大段代码... |
 |
47
zhangyunan 1 day ago
看情况，有些项目完全让 AI 写，毕竟 AI 用的语言我也不会，更不要提 review 了，不过有些问题我感觉用我熟悉的语言几分钟就搞定的，AI 写的半天还没有解决
|
 |
48
cleveryun 1 day ago via Android
@TomatoCLI 我的感觉是，很多程序员的水平比 AI 还差，但是 AI 又没到那种资深开发的水平。技术差的开发，AI 能提高代码质量，但是因为效率上去了，技术债积累的速度也快起来了。技术债对人还是对 AI ，都是负面内容。难搞的大 bug 变多主要是技术债积累太快了。
|
|
49
TomatoCLI 1 day ago
@cleveryun AI 写代码的上限跟使用者自身水平成正比， 使用者越厉害 AI 的上限就越高。你说的也对，但是不用 AI 也要面对技术债，只是面对的方式不一样。
边界问题，不只 vibe coding 会出现，你多人协作，多模块协作也会有。 年龄上我是个老古董保守派了，但 vibe coding 这件事我反正是愿意接受变化的。 |
 |
50
enpitsulin 1 day ago
对于本身开发流程清晰、代码质量过硬、工程师能力在线的公司，完全 vibe coding ，有大量的处编码工作之外的保证，我相信没问题。
但是缺少任何一环，绝对不可能在持续迭代之后还能保持一定质量和可维护性，这是工程问题，不是产出效率或者是能力之类的问题。 |
|
51
enpitsulin 1 day ago
@enpitsulin 当然，同理去掉 vibe coding 这个逻辑实际上也成立，只不过 vibe coding 带来的效率会让后者的问题快速地显现，并且范围扩大
|
|
52
xue777hua 1 day ago
@redbule 自己仔细去读 https://www.anthropic.com/engineering/building-c-compiler 认真读 你就能读出猫腻。
|
|
53
xue777hua 1 day ago
@jonty
1. AI 的训练数据全部都来自古法编程。 2. AI 尚未超越古法编程的水平。 3. AI 生成的结果依然需要人作为最后的审核者。 4. AI 只是生成的速度快，而不是说生成的质量高，至少在我这里频繁翻车。一直用的是最顶级的模型。 |
|
54
xue777hua 1 day ago
"I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality."
https://www.anthropic.com/engineering/building-c-compiler |
|
56
xue777hua 18h 38m ago via iPhone
|
 |
57
jonty 10h 4m ago
@xue777hua #56 “就像以前，只需要测试人员能找出开发写的 bug 即可，如果频繁出 bug ，就能一定程度证明这个开发者水平一般。” 牛头不对马嘴，你的逻辑是真的堪忧。你如果真想和我讨论，请你先回答我的问题。 你是古法编程集大成者吗？ AI 是否超越了你？你的作品有什么？
|
Select Language