为什么我无法做到全程 vibe coding 而不看代码

[JYii]

简中推上看到太多人 vibe coding ，gui 不行，cli 一把梭，起 n 个 agent 多需求并行等等。

我本人对于 AI 的使用还处于，基于需求与 AI 沟通出修改方案，执行后 review 生成的代码，这种半自动模式。
前端部分通常看个大概，确认文件位置和视觉效果没问题就过了。
后端部分对于修改和新增的文件严格 review ，着重看对原因逻辑修改的部分。

我不敢全程 vibe coding 的原因主要是害怕某些场景：

1.当其他同事来咨询、对接我的业务这块，当他提出某个需求，问我能不能实现，或现有实现如何，新需求能否兼容等等。由于代码是 AI 生成的，代码掌控力弱不能立即给出答复，只能回复他让我看看，然后我再问 AI ，我感觉自己就像个传话员。
2.万一更尴尬来我工位问我相关代码或进行线上问题查看，而我不能快速定位到相关代码逻辑，简直是公开处刑。

我能想到的解决方案是，每次 AI 生成代码后，同时梳理对当前系统影响，生成文档。但是就按今天的 AI 实现速度，文档也会看不过来。

[leeleehero]

你做的没错 兄弟

[434597545]

工作环境的代码还是要自己看得懂才行，只负责写代码，你才是真正为代码负责的人

[434597545]

@434597545 ai 只负责写代码

[ponder09]

这就是责任心

[123zouwen]

没毛病

[dongzhuo777]

你手上的项目 代码 尤其是业务相关的 这就是你的护城河，具体业务细节 实现怎么做的 你要是一点都不清楚，要你干嘛，万一某次生产事故炸了，AI 修复一顿胡说 你干直接拿到生产去修复吗

[kristofer]

至少目前阶段你这么做是没毛病的。这是专业性、负责任的体现。

你看的那些人，大多是网红、非技术人、远离一线开发的，当热闹看就行了。

[akakidz]

那些鼓吹全自动模式的，要么是业务非常简单，要么是对生产事故无所谓。
目前看相对靠谱的一种思路，是先用 vibe coding 生成代码，然后再用四五个不同的 ai 或者工具去跑测试，不过我自己还没有完整实践过这一套流程，抛砖引玉一下

[Satoshl]

被开除的时候 AI 可不会帮你跑路，你做的没错

[Vipcw95]

你能全自动不看代码，直接上生产，我敬你是汉子

[crysislinux]

看上面，要是需求是快，我就一把梭。。

[Tink]

我一开始完全做不到，后来发现 ai 有些地方写的比我好，我就不管了，直接放飞自我

[xmitman]

简中推上看看得了，他们玩的是产品快速上线，市场验证，验证失败，继续下一个产品，周期都是非常短的

[han0101]

失业的网红程序员，卖课的，产品经理，老一代的互联网创业老登。这些人哪类是需要考虑生产事故的？

[LabJo]

其实就是 plan 模式+人工 review ，这种现在甚至都要被归类到古法编程了...

[imagecap]

真正用在写代码的时间并不多，AI 充其量也就是相对精准的搜索引擎。AI agent 帮你节省了 copy/paste 的时间。仅此而已。ai 吹的人都是别有用心的

[bgm004]

因为不是个人项目啊。
我自己搞着玩的，我看都不看，输完要求就切 b 站去了。

[Hilong]

兄弟们还停留在大模型不靠谱的时代，我们这里已经全面铺开 claude code + opus4.6 了，基本没人手写代码了。生成出来的代码，说实话比手写的好，现在主要就是提示词工程师了

[ddonano]

所以我现在还在用 cursor ，ai 写完的代码 都要仔细比对才自己合入

[cvooc]

@Hilong 但提示词编写还是需要大量长时间调教的,适合项目维稳阶段介入, 我司传企项目, 需求三天两头一变, 时间从来都不是废在写代码上, 我尝试下来自己手写反而更快, 凭借记忆能迅速定位到该复制哪个组件, 哪个屎山不用动, AI 来做瞬间沉浸在我司项目屎山里出不来了, 一堆 bug 还是得 review.