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