用 Antigravity 写了个简单的仓库设计器，用Gemini写起来倒是很快，但有个功能一直有问题：3D预览中的物体坐标总是不对。
就如下图，左边2D编辑区的坐标是对的，但右边3D Live Preview里所有内容都堆在了原点。
就这么一个问题，我让AI反反复复改了两天，愣是没给我修好。
能用的模型和工具我基本都试了个遍，每个都不少于5次尝试。
- Google Antigravy (Gemini 3, Claude)
- Trae (Gimini, GPT 5.1)
- Claude Code (Glm 4.6)
你说让我把这部分代码删了重写吧，我还真有点儿舍不得。毕竟其他功能都挺好用的，而且发布之后，在另外一个菜单里同样的逻辑又是正常的。
这大概就是我迟迟下不了决心删除重写的原因。这事让我想起了《三国演义》里曹操那句经典台词：「食之无味，弃之可惜」。
我总觉得，这要是个正常人写的代码，凭经验分分钟就能定位修改好。可一旦习惯了让AI写，自己反而变得不想动手去调试、去修改了。
犹豫之间，我又让AI重构了很久，结果发布之后发现连数据都不对了，代码也不想回滚。得了，还是再让AI试试吧。
代码失控
任何工具，一旦你失去了对它的掌控，问题就接踵而至了。AI编程助手也不例外。
就拿这次写程序来说，AI生成的代码其实已经超出了我的掌控。更棘手的是，我不仅不能掌控它，我甚至不完全了解它。
我说的不是不了解AI本身，而是不了解AI写出来的这套程序。除了最初安装依赖包的时候我参与了一下，后续大部分时间我更像一个旁观者。整个流程基本是这样的：
- 我看着AI做功能设计；
- 我看着它列出开发计划（我很少去修改它的计划）；
- AI一个个页面、一个个功能区去实现代码；
- 我再来一个个功能点进行测试；
- 发现问题，把错误丢给AI让它修改；
- 然后不断重复上面这个过程。
其实我并不是现在才意识到自己对代码失去了掌控，但出于惰性，我一直放任AI继续“我行我素”。
关于失控
“失控”这件事，放在很多场景下道理都是相通的。
小到你桌面的整洁程度，大到人与人之间的关系、公司的管理，甚至国家的发展、国际关系，似乎都遵循着相似的逻辑。
总是从「看着还不错」，慢慢变成「感觉有点儿不对劲」，再到「他怎么变成这样了」，最后演变成一团乱麻。这个发展路径，出奇地一致。
这让我联想到我们的那句老话「从群众中来，到群众中去」，讲的似乎也是关于“参与”和“掌控”的道理。脱离了实践和深入了解，任何事都容易脱轨。
关于重构和重写
那么，对于AI写的代码，到底是应该修改、重构，还是干脆重写呢？
基本的处理原则，其实和我们传统软件开发工程中的经验是一样的。
首先，重构要趁早。不能等问题积重难返了再想着重构，因为那时的工作量可能不亚于重写。甚至对于AI来说，给出完整的新代码（重写）有时比理解并修改一堆旧逻辑（重构）更简单。
对于AI生成的代码，如果能直接修好，那当然没问题。如果同一个问题反复修改多次都无效，可以尝试换个AI工具、换个模型看看。如果仍然不奏效，那么重写往往是最简单的选择。与其在难以理解的“黑盒”代码里挣扎，不如让AI根据清晰的需求重新生成一份。
一点儿经验
我之前看过Claude母公司官网发布的关于使用Claude(Code)的最佳实践指南，现在看来，里面的建议一点都不过时。
果然还是他们内部的工程师最了解自家大模型到底是个什么“德行”。
最后补充一点个人心得：如果是在开发正经的产品，非常有必要仔细审视AI生成的每一段代码，看它是否符合你的架构设计和编码规范。
如果项目不那么复杂和严肃，至少你要能看懂代码、理解AI的设计意图。
如果是大型且严肃的产品，最好引导AI，让它生成的结果完全符合你的设计思路。这个过程本身，就是在重新建立你对代码的掌控感。关于AI辅助开发的更多利弊，你也可以在开发者广场和其他开发者一起交流探讨。
说到底，AI是强大的助力，但方向盘和地图，还得掌握在自己手里。想深入了解现代前端，包括复杂交互和3D渲染的实现，可以来云栈社区的前端技术板块逛逛。
发表于 1 小时前
|
查看: 2|
回复: 0
