Vibe Coding 近四个月有感
### 01 - 缘起
在 AI 编码还处在 Copilot 阶段，Cursor 这种工具的前提是你必须有代码要写，而要写什么基本上都是你自己定，AI 只是辅助。
虽然那时也提到了 Vibe Coding，但总感觉缺少了点什么火候。
Claude Code 的横空出世，让我感受到一种全新的体验，可以直接面向代码交付的结果，而不仅限于编码的项目构建过程。
这样的改变将程序员从繁琐的代码输入中解放出来，许多想法也得以更容易实现，所谓的提效。在科技领域内部跨领域的过程中，比如从系统架构到移动端开发，拥有科技领域的基础知识后，技能迁移也变得更加简单。
### 02 - 羁绊
在学校学习软件工程时，有一个经典的瀑布流开发模式，即需求分析、产品设计、软件设计、测试和部署上线。
大公司对稳定性的要求极高，所以在软件研发阶段，很多时间花费在设计文档上。
这部分的技术选型、思考与折衷需充分讨论，代码的组织和构建方式、核心抽象成分在这个阶段基本已定形。测试的方式、部署上线验证的内容也都清晰明了。
实际上，整个项目中，真正对着编辑器写代码的时间可能也就占20-30%左右。
有一个前提假设，或许也是实践经验：前期考虑越多，后期返工耗时越少，整体效率越高。同时也不允许在服务上线后出问题再返工，因为那时公司的收入会直接受影响。
### 03 - 磨合
手握 Vibe Coding 工具，业务背景也从搜索广告转向了 Web 技术栈。
**Round 1 - 初探：用大厂旧规矩套新工具（不够快）**
用大厂的工作流应用于新场景，这个过程中与其说是在 Vibe Coding，不如说是在 Vibe Learning。
代码都写出来了，但看不懂。为什么会选择这个？我一直在和 Claude 讨论。
从结果的直观感受来看，这样做并不够快。
同时我也一直纠结，如果继续考虑设计，AI 只是辅助的提效工具，似乎并没有更好地利用 Harness Coding Agent 的能力。
**Round 2 - 尝试：全权甩手给 AI （在屎山里刨屎的灾难）**
不再纠结前端不熟悉的选型，直接交给领域工程师，自己专注于相对熟悉的后端。
产品的 PRD 直接交给 Claude，让它自行实现代码，提供好上下文。
优点是速度快，缺点是修改时无从下手，甚至不知道内部逻辑对不对。后来在尝试 Workbuddy 的过程中，直接给我 Mock 了假数据，我到很后面才发现，这种感觉真的让人觉得没必要白费力。
直接翻译的业务逻辑代码面向过程，想调试和修改时，脑子完全混乱，依旧无从下手。难忍在屎山中刨屎。
因为我不是前端，无法直接从结果上看是否正确。
**Round 3 - 初悟：Vibe Coding 的灵魂在于“定规矩”**
第一次认真搞复杂的 Web 服务后端，代码框架没有经验，无法一开始就设定好设计规则来让 AI 跟随。那么，就只能在这里努力了。
我开始仔细查看代码，将重复的代码让 AI 提取出来...... 简而言之，就是合并同类项、抽象出框架、组件、工具包，这样当下与后续的开发就能专注于业务本身，头脑不至于爆炸，上下文也不至于撑垮。
当然，除了工程框架抽象，在过程中也有对业务的思考与抽象、对数据模型的建模。
这下想要定位问题的地方，迅速、清晰、明了。服务出了问题，我可以说是心中有数，完全不会慌。
科技新闻中常说，Vibe Coding 的好坏在于你如何定规矩。突然我意识到，原来我才是那个定规矩的人。
去掉业务逻辑，这部分代码确实可以成为下一个 Agent 后端项目的模板。后来看到他人也有类似模板，扩展了部署等功能，直接拿去卖了。
**Round 4 - 反思：商业视角的降维打击（代码只是业务的耗材）**
代码本质上是工具，服务于业务。
多年来在稳定业务中沉浸，老一辈程序员传递的思想属于软件工程时代，设计上考虑扩展性，业务若有调整，框架也不会大变，设计时非常注重高内聚低耦合，我依然还在这个惯性里。
大厂的要求仍然是稳定，而初创公司关注的核心就是速度。若业务无法持续发展，代码根本不需存在，代码的好坏也就无所谓了。所谓，皮之不存，毛将焉附。
这种思想转变源于公司的 AI 员工，作为教练，它给了我们战略、决策、沟通上的反馈。这部分内容可以专门再写一篇。
结论是，在初创公司等业务稳定后，后期改架构的成本是可以接受的，不必过多担忧前期。
屎山代码确实影响到业务开发，可以适度调整，其他可以不去管。在这个过程中，积累代码素养的想法也不要想了，优先服务于业务。当屎山代码对业务的影响变得无法容忍时才需要关注，在此之前，速度才是最重要的。
**Round 5 - 再试：理智上的放手与情感上的“百爪挠心”**
搭建工作台后，Vibe Coding 生成的内容又进入了我不熟悉的工作栈，MJS 后缀的代码，感觉更麻烦了。
所幸工作台内部使用的复杂度低，数据库也不需要连接，并发也无需考虑，服务挂了影响也不大。与 AI 沟通几轮它实现的逻辑，差不多能跑起来，就算是完成了。代码完全不熟悉。
这一部分让我心中百爪挠心的，是对黑盒和未知的天然好奇。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235223)
在 AI 编码还处在 Copilot 阶段，Cursor 这种工具的前提是你必须有代码要写，而要写什么基本上都是你自己定，AI 只是辅助。
虽然那时也提到了 Vibe Coding，但总感觉缺少了点什么火候。
Claude Code 的横空出世，让我感受到一种全新的体验，可以直接面向代码交付的结果，而不仅限于编码的项目构建过程。
这样的改变将程序员从繁琐的代码输入中解放出来，许多想法也得以更容易实现，所谓的提效。在科技领域内部跨领域的过程中，比如从系统架构到移动端开发，拥有科技领域的基础知识后，技能迁移也变得更加简单。
### 02 - 羁绊
在学校学习软件工程时，有一个经典的瀑布流开发模式，即需求分析、产品设计、软件设计、测试和部署上线。
大公司对稳定性的要求极高，所以在软件研发阶段，很多时间花费在设计文档上。
这部分的技术选型、思考与折衷需充分讨论，代码的组织和构建方式、核心抽象成分在这个阶段基本已定形。测试的方式、部署上线验证的内容也都清晰明了。
实际上，整个项目中，真正对着编辑器写代码的时间可能也就占20-30%左右。
有一个前提假设，或许也是实践经验：前期考虑越多，后期返工耗时越少，整体效率越高。同时也不允许在服务上线后出问题再返工，因为那时公司的收入会直接受影响。
### 03 - 磨合
手握 Vibe Coding 工具，业务背景也从搜索广告转向了 Web 技术栈。
**Round 1 - 初探：用大厂旧规矩套新工具（不够快）**
用大厂的工作流应用于新场景，这个过程中与其说是在 Vibe Coding，不如说是在 Vibe Learning。
代码都写出来了，但看不懂。为什么会选择这个？我一直在和 Claude 讨论。
从结果的直观感受来看，这样做并不够快。
同时我也一直纠结，如果继续考虑设计，AI 只是辅助的提效工具，似乎并没有更好地利用 Harness Coding Agent 的能力。
**Round 2 - 尝试：全权甩手给 AI （在屎山里刨屎的灾难）**
不再纠结前端不熟悉的选型，直接交给领域工程师，自己专注于相对熟悉的后端。
产品的 PRD 直接交给 Claude，让它自行实现代码，提供好上下文。
优点是速度快，缺点是修改时无从下手，甚至不知道内部逻辑对不对。后来在尝试 Workbuddy 的过程中，直接给我 Mock 了假数据，我到很后面才发现，这种感觉真的让人觉得没必要白费力。
直接翻译的业务逻辑代码面向过程，想调试和修改时，脑子完全混乱，依旧无从下手。难忍在屎山中刨屎。
因为我不是前端，无法直接从结果上看是否正确。
**Round 3 - 初悟：Vibe Coding 的灵魂在于“定规矩”**
第一次认真搞复杂的 Web 服务后端，代码框架没有经验，无法一开始就设定好设计规则来让 AI 跟随。那么，就只能在这里努力了。
我开始仔细查看代码，将重复的代码让 AI 提取出来...... 简而言之，就是合并同类项、抽象出框架、组件、工具包，这样当下与后续的开发就能专注于业务本身，头脑不至于爆炸，上下文也不至于撑垮。
当然，除了工程框架抽象，在过程中也有对业务的思考与抽象、对数据模型的建模。
这下想要定位问题的地方，迅速、清晰、明了。服务出了问题，我可以说是心中有数，完全不会慌。
科技新闻中常说，Vibe Coding 的好坏在于你如何定规矩。突然我意识到，原来我才是那个定规矩的人。
去掉业务逻辑，这部分代码确实可以成为下一个 Agent 后端项目的模板。后来看到他人也有类似模板，扩展了部署等功能，直接拿去卖了。
**Round 4 - 反思：商业视角的降维打击（代码只是业务的耗材）**
代码本质上是工具，服务于业务。
多年来在稳定业务中沉浸，老一辈程序员传递的思想属于软件工程时代，设计上考虑扩展性，业务若有调整，框架也不会大变，设计时非常注重高内聚低耦合，我依然还在这个惯性里。
大厂的要求仍然是稳定，而初创公司关注的核心就是速度。若业务无法持续发展，代码根本不需存在，代码的好坏也就无所谓了。所谓，皮之不存，毛将焉附。
这种思想转变源于公司的 AI 员工，作为教练，它给了我们战略、决策、沟通上的反馈。这部分内容可以专门再写一篇。
结论是，在初创公司等业务稳定后，后期改架构的成本是可以接受的，不必过多担忧前期。
屎山代码确实影响到业务开发，可以适度调整，其他可以不去管。在这个过程中，积累代码素养的想法也不要想了，优先服务于业务。当屎山代码对业务的影响变得无法容忍时才需要关注，在此之前，速度才是最重要的。
**Round 5 - 再试：理智上的放手与情感上的“百爪挠心”**
搭建工作台后，Vibe Coding 生成的内容又进入了我不熟悉的工作栈，MJS 后缀的代码，感觉更麻烦了。
所幸工作台内部使用的复杂度低，数据库也不需要连接，并发也无需考虑，服务挂了影响也不大。与 AI 沟通几轮它实现的逻辑，差不多能跑起来，就算是完成了。代码完全不熟悉。
这一部分让我心中百爪挠心的，是对黑盒和未知的天然好奇。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235223)
· 0 个赞