Vibe Coding启动2026年1月我在各种SNS上看到越来越多的关于Vibe Coding的经验分享。上家公司我曾对接过一些AIGC的场景也了解过cursor、copliot这些工具起初并未在意。但当我看到有人说“并发开10个Agent——5个写代码、3个测试、1个工作汇总、1个写文档下班回家睡一觉第二天来公司代码就写好测完可上线”时还是有点震惊AI Coding的能力已经进化到这种地步了吗处于尝鲜我安装了Trae让它接手了我业余时间编写的一个小应用效果还不错耳目一新。等到年后开工我尝试用Trae处理新分配的需求并编写代码。不过项目还没开始公司就安排了一个调研任务——一个财务领域的 AI 助手要怎么实现我也紧跟潮流安装了Claude Code接入glm-5模型开始编写代码。Vibe Coding初体验如何通过Vibe Coding从零构建一个Agent对于LLM和Agent我之前只是粗浅地了解过没有相关的技术背景但是既然SNS上把Vibe Coding吹的神乎其神叠加此时的养龙虾热我自然是信心满满。开发流程很简单打开对标的产品先体验其交互然后告诉Claude Code“我要有XXX功能这个功能需要XXX”/“页面布局为XXXXX”等等等等。等Claude Code写代码我启动服务器进行测试发现有bug就让Claude Code继续改如此循环。不出意外遇到了很多问题前端交互改起来很费时间我毕竟是后端出身对于前端没有那么了解同一个bug反复改很久才改好。有时还会出现bug1修了1天修好了开始修bug2bug2修好了bug1又重现了。大模型限流。虽然是公司提供的coding plan但是用的太狠还是限流。但说来也怪尽管各种不顺Vibe Coding 会让人上瘾。一旦开始写代码完全停不下来有点像刚毕业那会儿大展拳脚的感觉——把想法丢给 AI看着代码在面前长出来那种即时反馈让人沉迷甚至游戏都不香了。V1跑通了跑不动了经过一点一点探索和尝试还真的把 Agent 写出来了也就是 Cloud Agent V1。它用 Python FastAPI 搭建6 周时间、170 个commit多次squash实际更多、约 1.7 万行代码纯 Vibe Coding没有手写一行代码。V1 的核心是 LLM 输出带 XML 标签的 Python 脚本正则解析后在沙箱环境执行。能对话、能操作文件、能执行脚本、能加载 Skill、能调用 MCP跑通了完整链路。3 月份的各种产品演示都靠它撑了下来但每次演示前心里都在打鼓——怕 LLM 输出跑偏怕对话突然卡死。能跑但没有任何优势。CherryStudio、Openclaw 这类开箱即用的 Agent 同样能对话、能操作文件、能接 MCPV1 没有差异化。更要命的是V1 已经改不动了继续加功能只会让它更不可控。下面说致命的部分。V1 的致命伤致命伤一句话直接后果XML 当协议LLM 生成任意 Python 脚本正则提取执行不可靠、不可调试、无法区分错误类型上下文混乱按轮数硬裁 提示词失控 优化全治错地方失忆、token 烧光、越优化越慢God 类膨胀无初始架构Vibe Coding 堆功能越堆越大改不动、测不了、牵一发动全身致命伤一XML 标签当协议这是 V1 最根本的架构问题。系统不是通过 API 原生的 tool_use / function calling 机制执行操作而是让 LLM 用 XML 标签包裹生成的Python代码用正则匹配提取后在python沙箱执行。流程可以简化为两阶段用户输入 │ ▼ ┌─────────────┐ │ Judge 阶段 │ 轻量 LLM 调用 → 决定加载哪些 Skill、文件 └──────┬──────┘ ▼ ┌─────────────┐ │ 处理阶段 │ │ │ │ ◄── 循环 ──┤ LLM 生成 script → 正则提取 │ │ → 沙箱执行 → 结果回传 → 下一轮 │ │ 最多 50 轮 └─────────────┘ ▼ 返回结果这带来了一连串问题自由代码无约束。LLM 生成的是任意 Python 脚本不是带 schema 的函数调用。参数是凭空捏的函数名是幻觉出来的文件路径是猜的。代码语法错误、import 不存在、变量未定义全靠沙箱报错才知道。一个脚本干所有事。LLM 倾向于把多个操作塞进一个script块先读文件、再算逻辑、最后写结果。中间任何一步崩了整个脚本失败而且不知道崩在哪一步。代码错误 vs 业务失败无法区分。沙箱返回一个 traceback 或一个 None系统分不清是脚本写错了还是查询的数据确实为空。两种场景下游处理完全不同但 V1 都当成再试一次。正则解析脆弱。LLM 输出的script标签稍有偏差——少个闭合、think 块里混入了类似标签代码里碰巧包含/script字符串解析就断了。唯一的恢复手段是让 LLM 再试一次但它不知道哪错了只能反复生成代码、反复失败直到运气好成功、轮数耗尽或用户放弃。沙箱文件复制的开销。每次执行脚本前先把相关文件复制到隔离沙箱安全但每轮多一次 I/O。多轮任务跑下来大量时间耗在文件搬运上实际计算反而占比不高。致命伤二上下文管理混乱粗暴的轮数裁剪历史消息不做 token 精算唯一的措施是只保留最近 N 轮更早的直接丢弃。简单粗暴但结果是两个方向都崩保留太少聊几轮 LLM 就忘了开头说过什么反复追问用户已经回答过的问题保留太多一轮交互轻松破 10 万 token。模型也就 200K 的上下文窗口几轮就烧完了。要么触发 API 400 直接拒绝要么 LLM 静默丢弃早期上下文同样是失忆。根本不存在一个稳得住的平衡点。核心循环最多跑 50 步每步无条件追加 assistant 响应和脚本执行结果反馈到消息列表。加上聊天历史全部按轮数硬裁没有优先级、没有摘要压缩、没有关键信息标记。前面讨论的业务背景、确认过的文件路径几轮之后就跟从来没出现过一样。提示词失控系统提示词约 200 行硬编码在 Python 源码里。每次 LLM 调用动态拼接基础提示词 MCP 工具描述含完整 JSON Schema 项目文件预览Excel 表名、列名、数据样本 Skill 指令全文。一次普通业务调用提示词本身烧掉 1-2 万 token。而且每次从头构建没有缓存复用。这意味着 Skill 指令也是跟着上下文一起膨胀花大量时间和用户一轮轮调试优化 Skill 的触发条件和提示词但优化完之后塞进已经臃肿的上下文里LLM 到底有没有按指令走、触发是否准确完全不可知。优化了一整天效果全凭感觉。治错地方的优化两个失败的 token 节省策略Judge Phase开发和测试中我意识到了上下文问题设计了一个 Judge 阶段来解决它这也是 V1 里我的原创设计。想法不复杂每次执行任务前先做一次轻量级 LLM 调用判断用户要处理哪些文件、需要加载哪些 Skill然后只把筛选后的内容注入完整上下文。想法没问题但忽略了一个基本账本多一次 LLM 调用用户就多等一轮。每次操作都要先等 Judge 返回再等执行结果响应速度直接被拖慢。如果能用轻量模型来做消耗倒不至于太大。但当时根本没往这想。而且 Judge Phase虽然削减的是文件预览和 Skill 内容但上下文真正的大头是历史对话。前几轮生成的大段 Python 脚本、沙箱返回的几千字节执行结果、反复重试的失败记录。省掉的提示词跟历史对话这个黑洞比完全是杯水车薪。File Preview类似的还有文件预览机制。我观察到一个规律LLM 处理文件时总是先瞄一眼Excel 读第一个 Sheet 的前几行PDF 看前几页文本从不会一上来就做全量分析。于是加了一套文件预览上传时解析一次Excel 提取表名和样本数据PDF 提取文本Word 提取段落和表格结果存为 preview_data。Judge 阶段只发精简版文件名 维度处理阶段发完整版含样本行和文本摘录。思路和 Judge 一样用空间换 token。但问题也一样根本没做缓存复用。同一份 Excel 预览数据循环 50 步就在 50 次 LLM 调用里原样发了 50 遍每次都是从头拼系统提示词。V1 的优化始终停在传什么层面从没触及怎么不反复传。后者要等 V2 的 prompt caching 才真正解决。致命三God 类膨胀和架构失控最根本的问题是我一开始就没定架构。不是因为偷懒而是此前从没做过类似的应用根本不知道该长什么样。Vibe Coding 的方式是描述功能让 AI 写不是先画蓝图再施工。结果是架构随功能有机生长每多加一个模块前面的设计债务就重一层。executor.py2000 行。这一个类干了多少事判断阶段Judge、执行阶段Execute、脚本运行、MCP 过滤、重试逻辑、错误处理、上下文拼接。全部耦合在一个类里没有清晰边界。除了它context.py900 行chat_service.py600 行每个都是同样的毛病。开发过程中其实也让 AI 帮忙做过架构优化分模块、拆文件、抽函数、建分层这些 AI 都能执行。但有两个问题。第一AI 只负责当前这次修改没人持续盯着全局结构。今天拆出去三个函数明天为了修一个 bug 又塞回两个后天加新功能再堆一层 if-else。第二架构优化只在版本稳定时才能做功能跑通了、演示没压力了才敢动手。平时改需求、修 bug 时根本不敢大动结构怕拆出新问题修不回来。结果优化窗口越来越窄债越欠越多。重写还是重构这个决策我纠结了将近一周。不是因为看不清方向而是沉没成本太重。V1 毕竟是可以用的。3 月份好几场产品演示都靠它扛下来的虽然每次演示前提心吊胆但功能确实一项项跑通了。而且已经加了一个月的班每天跟 AI 较劲到半夜好不容易折腾出一个能跑起来的版本。调研项目有公司的时间节点不是无限期探索。推倒重来意味着前面一个月的加班全部归零新方案能不能按时跑出来当时根本没底。与此同时用户提的 bug 越攒越多。修好一个冒出两个越来越看不到头。但继续在 V1 上修补代价同样算得清。前文提的三个致命伤每一个细看都不是重构能解决的。继续修补 V1 推倒重写 ──────────── ────────── ✓ 能跑、演示扛住了 ✓ 三个致命伤重构解决不了 ✓ 加班成果不归零 ✓ 参考其他开源Agent源码但不知道选哪个 ✗ 时间节点越来越不可预期 ✗ 一个月加班归零风险未知 ✗ bug 越修越多看不到头 ✗ 1.7 万行代码作废 ✗ 架构缺陷是骨架层的问题XML 标签当协议是 V1 的根基。把 XML 解析换为标准 tool_use意味着整个 agent loop 从 executor、parser、context 到 LLM 调用链路全部推倒。这不是重构 executor.py 的一部分而是删除它存在的理由。即使有 Vibe Coding重构的工作量也不会少。零测试兜底意味着每次改完只能靠人肉验证告诉 AI 这里有问题改成 X跑一遍发现崩溃了再告诉 AI 修崩溃再跑一遍。还有一个语言层面的问题V1 用 Python 只是因为当时熟悉 Python并不意味着后端就应该用 Python。Claude Code 源码是 TypeScript 写的要继续深入参考它的设计用同一种语言显然比在 Python 和 TypeScript 之间做概念翻译更顺畅。继续守着 V1 的 Python 代码意味着往后的每一轮优化都在隔着一层语言做映射。这个成本重构省不掉。最后一个砝码V1 还处于内部小范围 demo 阶段没有历史数据要兼容没有线上用户要迁移。推倒重来最重的代价只是扔掉代码不需要做数据迁移、协议兼容、灰度切换这些工作。V1 的价值在于验证方向、积累认知不在于那 1.7 万行代码本身。契机当我在纠结要不要重写时Claude Code 的源码泄露了。消息出来那天我就把源码拉了下来不过比起直接啃源码真正帮我下定决心的是社区里陆续出现的解读文章。这些文章讨论的方向主要有几个Agent 循环设计tool注册和调度prompt caching 的分段策略上下文压缩的分级机制多 Agent 的协作模式权限系统的分层拦截当时我看得似懂非懂很多概念还没建立起完整的认知。但我知道这就是我应该参考的方向。经过一个多月高强度使用 Claude Code再看社区的评价感受更确定了。大家反复提的几个点和我自己的体验完全重合对代码库的理解不像关键词搜索更像一个读完代码再动手的工程师多文件重构时不会拆东墙补西墙共享逻辑自然合并每一步操作都附带自解释的上下文像一个不需要文档的工具。更棒的是Claude Code并不是一个纯粹面向coding而是面向通用工作设计的Agent即使直接将财务领域或其他业务领域的文件丢给它处理它也能三下五除二地搞定这对我来说足够了。一个让我每天用都不烦的设计一定是值得跟着走的。再次抉择用 SDK 还是尽可能参考源码参考方向有了怎么落地组里一直有声音建议直接用 Claude Code 的 SDK。毕竟官方封装好了 agent loop、工具调度、流式处理上手最快。但经过前面一个多月的折腾我很清楚这次不能只图快。如果只是用 SDK 拼业务逻辑不过是换了一套 APIV1 的架构问题一个也解决不了。动手重写前我做了最后一次评估。方案 A基于 Claude Code SDK。anthropic-ai/claude-agent-sdk封装了 agent loop、工具调度、流式处理接入即用。优点是开发周期短缺点是架构受 SDK 约束权限模型、缓存粒度、中断机制、SSE 事件定义能用但不能改。方案 B参考 Claude Code 源码自行实现。研究 Claude Code 的架构设计、技术栈选择、模块