如果你也赞同： 一直 vibe coding 上线要出事的。
注意这里有个前提就是本人喜欢可读性极强的代码，可扩展性高但不提前过度设计，耦合低等等等等......但是一口气 vibe coding 出来的代码风格始终达不到好的可读性效果，不知是不是加的约束不好。
跑原型做验证的时候，是不会花时间看代码的，现在想把一个东西做上线。
在现有的基础上改，相当于重构。
优点是不会漏功能，缺点是要先看懂理解 AI 的代码。可能存在很多过度设计的绕弯子，一个简单的东西给你搞好多类好多状态机，徒增复杂性。
根据现有的文档，从架构和技术选型开始重新出发。
优点是可维护性高，没有理解成本，而且后续的工作还是可以交给 AI 做。 缺点，可能会漏 AI 补充的小细节功能。
或者有其他更好的方式？
 |
1
xujinkai 18h 27m ago via Android
我目前的实践是持续重构，不断地问 AI 某一个模块的逻辑，然后给出你的重构方案，同时测试要跟上，其实和人写代码很像。
还有一种就是你这种先搞原型，都搞完了才想重构，如果代码太多，那我觉得不如先让 AI 总结出个功能文档，然后让另一个 AI 另起炉灶。主要问题就在于，另起炉灶的过程中，你还是得持续重构。我觉得目前不存在 AI 一锤子能干好的可能，除非项目很小。 |
 |
2
JasonYip 17h 28m ago
SDD 吧 不过对代码失去掌控以后很难再掌控回来。就好像古法时代一开始没有控制复杂度和耦合 后续复杂度上来了几乎没法下手
|
 |
3
ericguo 16h 55m ago
你都说是做的原型了，不看代码了，现在又想把这套代码改吧改吧上线，既要又要两头都要，可能也只有 Astra 能帮你了。
|
 |
4
sickworm PRO 我觉得 2 比较好，你需要一个干净的架构支撑你的代码质量，减缓代码腐化速度
|
 |
5
chjqpmain 11h 46m ago via iPhone
这个还是心理以及现实上的问题，
比如老板，或者 cto 管人就不会过于担心，因为人是可以承担对应的责任的， 而心理上完全由自己（自己让 ai 做，我感觉也还是自己），那么从 0 长出来总会希望它更优雅， 可不自己亲自审过的总是不放心， 模型也只能被说几句，真上线后出问题，和人是不一样的 |
 |
6
ttkit 8h 21m ago
实际业务中，功能模块不可能耦合在一起的，所以并不是你想象的那样很难维护。
如果是新项目，已开始把地基打好就行，比如开始的项目架构说明，工作流，每实现一个功能写文档，维护起来不是很简单？ |
 |
7
TirionHo 8h 15m ago
要相信后人（ AI ）能解决现在解决不了的问题
 说不定再过一年 AI 能直接一键梳理需求进行重构了呢 |
 |
8
milkleeeeee 7h 49m ago
我的项目已经全部 100% vibe coding 了快一年了好好的
|
 |
9
ReferenceError OP @milkleeeeee 牛，可以分享一下心得吗？
比如说，完全 vibe coding 后，增加一个新功能。code diff 的范围远超我们的常理可能性，怎么保证迭代质量？ |
|
10
milkleeeeee 7h 7m ago
@ReferenceError 我不看代码，ai 代码写完我也不会自己测，都是让 ai 自己起开发服务器、驱动浏览器测的，上线前再接入线上数据库让 ai 再测一遍，它说没问题我就上线
|
|
11
ReferenceError OP @milkleeeeee 可以参观下你的产品吗。
|
|
12
milkleeeeee 6h 44m ago
|
|
13
ReferenceError OP |
|
14
milkleeeeee 6h 8m ago
@ReferenceError 是的，用 ai 做就是会有很多瑕疵，代码风格也不能掌控，但是跟效率和开发舒适度的提升相比我觉得这些都不值一提了
|
 |
15
xiaomushen 6h 6m ago
别想那么多
无非就是 短期 vibe coding 变成 长期 vibe coding |
 |
16
linkopeneyes 2h 25m ago
一般还是要有可靠的模式下 vibe coding,我感觉只能一点一点的生成,并且检查每次生成的代码,我现在就是这样的
|
 |
17
Seamain 1h 52m ago
我思想上是这么想的，就是我每个开始的项目一般我都想给他作为长期项目去做，那么在这个应用刚开始能跑通的时候就要去规范里面的所有代码的规范。这样可读性和后期维护也可以是最大化的。
|
Select Language