[DataFlow-CV v0.6.2] Vibe Coding 实践与思考
2026 年，Vibe Coding 已经成为程序员的日常开发手段。我在 3 月份用 Claude Code + DeepSeek V3.2 进行了一次完整的 Vibe Coding 实践——没有手写一行代码，从零开发了 DataFlow-CV：一个跨平台的标签格式转换命令行工具。这篇文章记录整个过程和踩过的坑。
项目地址：https://github.com/zjykzj/DataFlow-CV
一、DataFlow-CV：这是什么，做成了什么样
DataFlow-CV 是一个命令行工具 dataflow-cv，核心功能是支持 LabelME、COCO 和 YOLO 三种标注格式的相互转换与可视化。跨 Linux、Windows 和 macOS 平台，同时提供 API 接口供其他项目调用。
开发过程经历了多轮完整重写——不是修修补补，而是全部推倒重来。每一轮重写的触发点都一样：工程架构逐渐混乱，文件职责不清、函数定义随意、参数传递失控，到了 Claude Code + DeepSeek 自己也修不回来的地步。一次 Vibe Coding 跑一个小时，最后还是一团乱麻，只能选择从头开始。
目前已经迭代到 v0.6.2，三种格式的互转和可视化主体功能已经跑通。但从转换精度和实现细节来看，仍有很多需要打磨的地方——这些是 Vibe Coding 目前还不擅长处理的边界情况。
二、Vibe Coding 踩过的坑
1. 上下文长度是硬天花板
DeepSeek V3.2 提供 127k 上下文窗口，看起来不小。但在实际开发中，随着工程文件增多、代码量膨胀，单次对话经常触及这个上限。一旦上下文不够用，模型就开始”遗忘”早期的设计决策，生成的代码与已有架构产生冲突，恶性循环由此开始。
127k 的上下文约束的不是你能写多少代码，而是你的工程复杂度上限。对于 DataFlow-CV 这种中等规模的工具，已经明显感受到压力。
2. 无规划开发 = 熵增陷阱
最初的做法很朴素：想到一个功能就写一段提示词，写好后再想下一个功能。这种”走一步看一步”的方式在小规模时还算可行，但功能累积到一定程度后，问题集中爆发：
- 文件职责混乱：一个文件里塞进了不该它管的功能
- 接口定义随意：函数签名随心所欲，不同模块风格不统一
- 依赖关系复杂：改一个地方牵出三四个地方跟着崩
到了后期，连模型自己也搞不清这套代码的来龙去脉。一次修复操作要跑一个多小时，整个过程需要人工关注——因为 Claude Code 在执行过程中会弹出确认选项，你不能完全走开。修到最后发现修不好，心态是非常崩溃的。
3. 重写次数 ≠ 渐进优化次数
这一点值得单独拿出来说。常规开发中，”重写”往往发生在积累了足够的认知之后，是有目的的架构升级。但 Vibe Coding 中的重写更像是一种被迫的”重启”——因为当前代码已经烂到没法继续了。这两者的区别在于：前者是在信息量增加后的主动选择，后者是在信息量失控后的被动逃生。
多轮重写的成本很高。每一轮从头开发都需要重新设计工程架构、重新安排开发步骤、重新验证功能。如果没有把上一轮的教训结构性地沉淀下来，重写就只是重复劳动。
三、Vibe Coding 的正确打开方式
1. 先设计，再开发——但设计不止于 Plan Mode
Claude Code 官方推荐的流程是先 Plan 后 Code，这确实比直接写提示词有效得多。但我感受更深的一点是：设计不只是在工具里跑一个 plan 流程，而是你在动手之前，对这个工程/产品本身要有足够清晰的理解。
具体来说，在启动 Vibe Coding 之前，至少要想清楚三件事：
- 工程架构怎么分：哪些模块、各自负责什么、模块之间的边界在哪
- 核心数据流怎么走：数据从哪进、经过哪些处理、从哪出
- 关键接口怎么定义：函数命名规范、参数设计原则、错误处理策略
这些东西不是模型能帮你决定的——或者说，模型帮你决定的结果大概率不是你想要的。只有你自己对这些有了清晰的认知，提示词才能写得准，模型的输出才不会偏离方向。
2. Spec Coding：让设计可复用
后续了解到 Spec Coding 的概念——把设计方案文档化，用规格说明书（Spec）来驱动开发。这不只是 Plan Mode 的升级版，更重要的是解决了”设计复用”的问题。
在 DataFlow-CV 的开发中，我经历了多轮重写。如果每一轮重写都有一个可复用的 Spec 文件，直接喂给 Claude Code 作为开发指令，重写的效率会高出很多。Claude Code 的 Plan Mode 更像是一次性的设计，Plan 完成后没有保存和复用机制。配合 superpowers 这类插件，或者干脆自己维护一套 Markdown 格式的工程 Spec，可以让多轮开发和重写更加可控。
3. 产品理解力决定 Vibe Coding 的天花板
这是我在整个实践中最深的一个感受。Vibe Coding 目前还处在”加速生产”阶段——它能让一个思路清晰的开发者更快地出活，但不能替一个思路不清的开发者理清思路。
你对功能的理解程度，直接决定了你能把模型指挥到什么程度。如果你说不清自己想要什么，模型也猜不对你想要什么。如果你对 CV 标注格式的转换边界情况（比如 LabelME 的 polygon 转 YOLO 的 bounding box 会有精度损失）没有概念，模型生成的转换逻辑就会出现你发现不了的问题。
四、Vibe Coding 是编程的革命，不是 CV 算法的革命
2026 年大模型 AI 百花齐放，从开发方式到算法领域都在被重构。但有几件事需要分清楚：
Vibe Coding 革命的是编程这个动作本身——你不再需要记忆各种编程语言的语法细节、不再需要手写样板代码、不再需要纠结代码风格规范。在编程这件事上，模型是你的”手”，省去的是”写”的时间。
但它替代不了 CV 算法工程师的核心能力。你还是需要理解计算机视觉领域的基础知识：图像处理、特征提取、目标检测、语义分割、标注格式的设计逻辑。你还是需要知道 COCO 格式和 YOLO 格式在框的表示方式上的差异，知道 polygon 和 bounding box 互转时的精度问题。这些是”脑子里的东西”，模型替代不了。
一句话总结：Vibe Coding 让你不用操心怎么写代码，但它没让你不用操心写什么代码——以及为什么要这么写。
五、没有落地场景，Vibe Coding 练不出来
从我的使用经历来看，Vibe Coding 的能力提升非常依赖实际落地场景。如果你只是拿它写一些玩具项目、Demo 功能，学到的就是皮毛。只有在真实的工程约束下——有明确的输入输出要求、有跨平台需求、有 API 接口设计标准、有测试覆盖要求——你才能感受到它的能力边界和正确用法。
从开发者成长的角度来说，想要把 Vibe Coding 能力真正练出来，需要接触各种有真实约束的落地场景。生产效率是在解决真实问题的过程中提升的，不是在玩工具的过程中提升的。
六、结语
3 月份的 Vibe Coding 经历整体来说是痛苦的——工程越完善，后续开发越慢，一次调试一个小时，中间还要盯着确认选项。如果一直是这种方式，多工程并行基本不可持续。
但也在这个过程中接触到了新的思路：Spec Coding、多 Agent 协作、辅助开发插件、Claude Code 的高级玩法。针对 DataFlow-CV 的后续开发，我打算用这些新的方式重新尝试。等有了结果，再写一篇。