Vibe coding 之踩坑记
Vibe coding 对于程序员的技能要求反而比之前高了
先讲一个故事。
我这几天突然被隔壁组叫去，帮他们解决一个支付系统的问题。
简单来说，我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所，然后机构可以统一管理下属场所的账单，支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树，让父结点能看到子节点的账单，并支付。
问题就出在这个关系树上。因为我们之前用过一个另外的支付系统，所以有一部分老客户是从之前的系统迁移过来的。
这个老系统给每个客户创建了一个独特的id，但是这个id 和我们内部使用的id 并不一致，所以我们需要自己把客户的id 和他们的支付账户连接起来。然而：
- 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明，用客户的last-name 属性存储了我们的id
- 第一个雷：用户的last-name是可以由用户自行修改的。如果他们修改了，我们的对应关系就乱套了。
- 但是这个id A存错了，应该存储机构的id，A存成了下属场所的id
- 第二个雷：在A根据新创建的下属场所归属的机构id 来查找机构时，要么查找到同id 的下属场所，要么找不到。就算找到了，找到的机构也是错的。
结果显而易见：我们的客户关系乱成一团麻了。没有任何关系的下属机构之间能看到相互之间的账单；有关系的机构和下属机构变成最熟悉的陌生人了。
我急忙忙的出了个方案，花了10几个小时修好了逻辑和数据。
在复盘整个事件时，最初的设计一眼看去就是vibe coding生成的。然后A又没有去验证方案的正确性，一路回车按下去，导致最后生成了一套四不像的方案。A接着无脑就照着这套方案去做了，完全没意识到有任何问题。
后续的修复方案，加上数据修复所花的时间其实比推倒重做还费时。奈何已经在生产环境的支付系统不允许我全推倒重做，只能一步步修复数据，然后改实现，测试，然后部署。
就这个简单的例子来看，vibe coding确实在生成方案时极大的提升了工程师的效率。就是“我有个想法，你看着实现“，AI就能生成一个九成真一成假的方案。但是最要命的也就是那一成假，可能把整个系统带到沟里去。后续修复的人力成本也比早期多花一些时间论证项目可行性高很多。
vibe coding 时，看着AI不知疲倦的生成方案是真的很爽。但是各位工程师们，切记要验证方案的可行性啊！不然小心你花20块雇claude code，一路无脑tab，最后claude code让你丢200k的工作。
