> ## Content Index
> Fetch the complete content index at: https://andybase.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Vibe coding 之踩坑记
- URL: https://andybase.com/vibe-coding--e4-b9-8b-e8-b8-a9-e5-9d-91-e8-ae-b0/
- Published: 2026-02-05T05:09:33.000Z
- Updated: 2026-02-05T05:09:33.000Z
- Author: andy
- Tags: Uncategorized, #Migrated-1784083136856, #wp, #wp-post, #Import 2026-07-15 02:38

> 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的工作。