我第一次被 vibe coding 折腾到失眠是在三个月前。项目跑得好好的我想让 AI 顺手加一个导出报表的功能它倒好悄无声息重构了三层目录结构还顺手升级了两个底层依赖。第二天项目起不来了git log 里全是一模一样的“feat: 导出功能”我盯着屏幕根本分不清哪一次提交才是罪魁祸首。那一刻我突然意识到vibe coding 带来焦虑的从来不是“AI 会不会写代码”而是整个流程彻底失去了控制感。后来我花了三个月把日常开发里所有关键环节都换成了开源工具最终沉淀出一条固定工作流AI 负责生成我负责掌控节奏正好对应 9 个应用。它们解决的其实是同一个问题——不可见。每一次改动都可回滚AI 手里有一张项目地图每一笔模型调用都有据可查。这篇文章不聊大模型选型只聊这 9 个工具是怎么组合起来把我从焦虑里拉回来的。1. 失控的根源vibe coding 的焦虑不是 AI 造成的是流程缺位1.1 三个让我睡不着觉的真实场景第一个场景上下文失忆。项目进行到第三轮对话时AI 已经定了用 service 层封装业务逻辑的约定可到了第五轮它完全忘了这件事直接在 controller 里写了一大坨业务代码。仓库里同时出现两套风格连我自己都分不清哪一种才是当前意图。每次开新会话都像重新认识一个新同事这种消耗真的会让热情迅速蒸发。第二个场景改错后无法回滚。有一次 AI 帮我把回调改写成 promise 写法结果一个函数里的 this 指向全变了另一个页面跟着崩掉。我打开 git log 一看连续七八条提交全部叫 “update”连哪次改了什么都不敢确定。想 revert 都不敢只能人肉开着 diff 逐行排查花了一整天才缓过来。第三个场景费用失控。vibe coding 上头那阵子我什么需求都扔给大模型一个项目聊了上百轮。月底对账单的时候我完全说不清这一个月烧掉的额度花在哪些功能上只知道很多对话都浪费在重复澄清需求上。想省都不知道从哪省起那种心里没底的憋屈感比写不出代码还难受。这三个场景分别对应可控性、可观测性、可追踪性。说到底vibe coding 把“写代码”这个动作变得太轻了但该有的工程护栏一个都不能少。1.2 开源工具治焦虑的逻辑让一切不可见的东西变得可见我自己总结了一句话焦虑来自不可见。AI 改了什么不可见token 流向哪里不可见技术决策为什么这么做不可见。开源工具恰好擅长解决“可见性”git diff 让改动可见trace 让调用可见Markdown 文档让意图可见。下面是我现在固定使用的 9 个开源应用先给一张总表后面逐个拆。工具定位主要治疗的焦虑Aider终端里的 AI 结对工具改乱、无法回滚ClineVS Code 里的开源 AI 代理AI 越权乱改代码OpenHands自主 AI 软件工程师想放手又怕失控AppFlowy本地优先的笔记与项目管理上下文丢失、没有项目地图NocoDB开源 Airtable 替代后端接口迟迟没有LangfuseLLM 可观测性平台token 和成本失控Dify开源 LLM 应用平台AI 回答不靠谱、知识分散Continue开源 AI 代码助手日常补全风格不稳TermuxAndroid 开源终端手机上看状态、改代码这不是一个单纯的清单而是一条链路先解决“改乱了能救回来”再解决“AI 知道自己在哪”最后才是“让 AI 更自主”。顺序很重要很多人一上来就玩高级 Agent反而更焦虑。2. 让每次 AI 改动都可回滚Aider 和 Cline 的“钢印组合”2.1 Aidergit 原生工作流AI 每改一步都有一个后悔按钮Aider 是终端里的开源 AI 编程工具它最大的特点不是能改代码而是把 git 纪律融入灵魂。你只要在一个 git 仓库里运行aider它对文件的每一次修改都会自动生成一个 commit提交信息由模型生成。改坏了怎么办一条/undo命令直接回滚最近一次 AI 修改文件回到修改前的状态。这个机制让我在 vibe coding 时第一次有了“安全带”的感觉。实操非常简单三行命令就能跑起来pip install aider-chat cd /path/to/your/project aider --model gpt-4o进入交互界面后几个命令是关键/add 文件名把指定文件加入当前会话的上下文/diff查看 AI 即将做的修改/undo撤销最近一次 AI 修改并自动回滚文件/commit手动触发一次干净的提交/run在终端里执行命令让 AI 看到运行结果。我经常这么用先/add几个最相关的文件然后用自然语言描述需求AI 给出改动并提交我看一眼/diff没问题继续下一轮有问题/undo重来。这种“小步提交 随时回滚”的节奏和手动写代码时的安全感几乎一样。Aider 还有一个很聪明的设计叫 repo map。它会自动扫描项目结构把相关文件的定义和函数签名作为上下文拼给模型让 AI 不需要把所有代码都读一遍也能知道要去哪个文件动手。你只管往里加文件它自己找路。2.2 Cline先出计划再动手文件级审查让 AI 不能越权如果说 Aider 适合快节奏的终端迭代那 Cline 就适合“需要肉眼确认”的场景。Cline 是 VS Code 里的开源 AI 编码代理界面友好核心是它的三种工作模式Plan 模式AI 先读代码、查资料输出一份改动方案不碰任何文件Act 模式按照方案实际改代码组合使用时的人工确认机制AI 每改动一个文件右侧 diff 面板都会标清楚新增了什么、删了什么、移动了什么你可以逐个文件批准或拒绝。我现在的固定动作是涉及多文件重构时一律先切 Plan 模式让它给方案。AI 说“我打算把认证逻辑抽到 auth.ts同时修改三处调用点”我看到这句话后如果觉得不对劲直接打断不让它动手。这就把大多数“越权重构”掐死在萌芽阶段。Cline 的规则文件也建议从一开始就建好。项目根目录放一个.clinerules文件写清代码风格、禁止事项、测试要求比如- 不要修改公共接口签名除非先列出所有调用方 - 新增函数必须写类型注解 - 修改完必须运行 npm test 并给出结果 - 不要为了通过 lint 重写别人的逻辑。全局规则放在 Cline 设置里项目专属规则放进.clinerulesAI 基本不会再跑偏。2.3 这个组合怎么用才不会被工具本身拖垮我踩过两个坑提醒一下。第一个坑同时让多个 AI 工具操作同一个目录。Aider 刚提交完一版Cline 又基于旧缓存改了同名文件冲突率非常高。现在我的约定是一个仓库同一时间只允许一个 AI 工具在动。Cline 做重活时就别开 Aider反过来也一样。第二个坑不限制上下文范围。AI 默认会读很多文件token 消耗事小关键是把无关文件牵扯进来后改动范围会失控。我现在会在.clinerules里显式写“只允许修改 src/ 目录测试文件修改前先确认”给 AI 划一道清晰的物理边界。这套组合拳解决了我最焦虑的“改错了怎么办”。有了这个底后面才敢慢慢把更多自主权交给 AI。可回滚带来的是一种心理复利你知道一切都能撤销自然就敢让 AI 多做一点。3. 想放手又怕失控把 OpenHands 关进沙箱再让它干活3.1 沙箱为什么是“自主执行”的底线vibe coding 焦虑的另一个高频来源是AI 太蠢的时候你烦AI 太能的时候你又怕。等任务拆到足够清楚比如“把仓库里所有 TODO 注释整理成 issue 列表”或“给支付模块补上超时重试逻辑”这种明确指令其实没必要一轮轮手把手喂干脆派一个自主 Agent 去干。我的选择是 OpenHands。OpenHands 是一个开源 AI 软件工程师项目它和 Cline、Aider 的本质区别是任务级你把一个仓库连同一个任务描述丢给它它会自己规划步骤、自己打开终端、自己装依赖、自己改代码、自己跑测试全程在 UI 里展示操作日志。最关键的是它默认跑在 Docker 沙箱里文件系统被隔离网络和系统命令都有边界。就算它理解错了也只是把沙箱里的项目改坏不会波及宿主机。这就是我敢“放手”的原因失控的代价被锁在一个可丢弃的容器里。3.2 我的一次真实任务派发记录最典型的一次是朋友丢给我一个开源前端仓库说移动端登录页错位。我没有自己开编辑器而是把仓库拉到本地然后在 OpenHands 里新建任务任务修复 login 页面在移动端375px 宽度显示错位的问题。 验收标准 1. 先在本地启动项目复现问题 2. 定位到具体样式或结构原因 3. 完成修复并确保桌面端不受影响 4. 用项目自带的测试跑一遍登录相关用例。注意我特意写了“验收标准”这非常关键。如果不写AI 大概率改完样式就跑根本不会去验证“桌面端是否被影响”。OpenHands 拿到任务后在沙箱里依次执行了 npm install、启动 dev server、用脚本模拟移动端宽度、定位到 flex 布局问题然后修改 CSS 并跑了相关测试。我全程盯着它的命令输出发现它在装依赖时卡在某个版本上还自己切换 registry 重试。最终给我的报告里写清了根因、修改文件、测试结果。3.3 哪些任务不要交给它我的判断标准把话说回来OpenHands 不是万能的我在实践中碰过几次壁。适合委派的任务特征是目标明确、验收标准可量化、影响范围可控。反过来下面这几类我从不丢给它需要主观审美判断的任务比如“把页面做得更有高级感”涉及多个服务联调的流程它会改完一个服务就去测根本等不到另一个服务就绪涉及生产环境密钥、数据库迁移、线上配置的任务。另外还有一个经验给 OpenHands 的任务描述里尽量用“先…再…最后…”的步骤式写法。它虽然是自主 Agent但规划能力没有想象中强你的步骤描述越明确它的执行路径就越稳。如果任务本身太模糊它会把时间浪费在探索上看起来像在摸鱼实则是目标缺失。把 OpenHands 想象成一个很能干但需要清晰工单的远程实习生工单写得越好它交付得越靠谱。沙箱是安全网验收标准是方向盘。4. 给 AI 装一张项目地图AppFlowy 和全局 Markdown 文档4.1 vibe coding 的“金鱼记忆”只能靠文档根治我见过很多 vibe coding 选手包括我自己早期最大的痛点不是代码写不出来而是 AI 每次都像金鱼。对话一长前面定的技术选型、目录约定、命名规范全忘干净。模型上下文窗口再大也扛不住几十轮对话里的信息稀释。后来我在一个开源社区看到有人讨论 vibe coding 全局 md 文档的做法瞬间被点醒与其让 AI 每次都在对话里现猜不如把项目的关键信息落到一份持久化的 Markdown 文档里。每次开新会话先让 AI 读这份文档再开始干活。文档就是 AI 的项目地图地图在手哪怕换了新对话它也知道自己在这个仓库里应该遵守什么规则。这份文档不需要长篇大论但要把下面这些说清楚项目目标这个项目解决什么问题服务谁技术栈前端、后端、数据库、部署方式分别是什么目录结构哪些目录能改哪些目录是生成出来的别碰接口约定API 的鉴权方式、错误码规范、通用响应格式决策记录为什么选 A 不选 B避免 AI 下次又提议 C踩坑清单之前反复出问题的地方比如“不要动 global.css否则样式会崩”。4.2 用 AppFlowy 管理这套文档比散落在各处的 .md 更顺手文档方案听起来简单但光靠一堆零散的 .md 文件很快也会乱。我把它们收进 AppFlowy 统一管理。AppFlowy 是开源、本地优先的 Notion 替代品数据默认存在自己电脑上不用担心第三方平台锁死。Markdown 能直接导入导出跨工具迁移也不费劲。我的做法是在 AppFlowy 里给每个项目建一个 Workspace里面固定放几页首页项目目标 当前状态 最近改动摘要技术架构目录结构、技术选型、关键依赖数据模型所有表和字段的说明接口文档API 列表和几个完整示例任务看板用 AppFlowy 的数据库视图管理开发任务前端、后端、测试分列。AppFlowy 的 database 视图对我帮助很大。vibe coding 的项目通常需求变化快任务状态一天改三遍用表格视图拖拽一下就能更新比维护一个又大又全的文档高效得多。下面是我一份标准的 context 模板你复制就能用# 项目名 ## 项目目标 一句话说清楚解决什么问题。 ## 技术栈 前端React TypeScript Vite 后端FastAPI 数据库PostgreSQL ## 目录结构 - src/app业务代码可改 - src/generated生成代码不要手动改 - docs/项目文档 ## 接口约定 - 鉴权Authorization: Bearer token - 统一响应{ code, message, data } ## 决策记录 - 为什么用 PostgreSQL团队熟悉、生态成熟2025-03-05 - 为什么不用 MongoDB当前业务事务复杂 ## 踩坑清单 - 不要改 global.css会影响整体样式 - 定时任务只能在 worker 进程执行4.3 让 AI 每次先读文档的三个姿势文档建好只是第一步关键是怎么让 AI 真的去读。我目前有三种姿势按工具不同分开做Aider在项目根目录放AGENTS.md或CONVENTIONS.mdAider 启动时会自动读取并作为默认上下文Cline在.clinerules里写一行“每次开始任务前先读取 docs/context.md并在回答中引用你读到的内容”其他聊天式工具在系统提示词里直接说“你是这个项目的开发助手首先阅读以下文件docs/context.md再回答问题”。如果你用的是同一套文档我强烈建议把“踩坑记录”也写进去。有一次我在文档里写了“cron 任务必须在 worker 进程运行不能放进 API 进程”后来 AI 每次想动任务调度时都会主动引用这句话再没犯过之前重复犯的错误。文档不只是写给队友看的更是写给“下一轮 AI 的自己”看的。5. 数据层焦虑NocoDB 十分钟搭出业务后台不等后端磨洋工5.1 原型期最磨人的不是前端是“后端接口还没好”vibe coding 的节奏很快前端页面一天能出三版但一碰到数据就卡住数据库表没建、接口没写、做不了增删改查整个项目卡死在半空中。以前我都是手写一个 FastAPI 后端虽然不算难但流程长特别打断节奏。后来我把这个环节交给了 NocoDB。它是一个开源 Airtable 替代品核心能力是连接一个数据库SQLite、MySQL、PostgreSQL 都行自动生成可视化的表格界面同时自动提供 REST API 和 GraphQL API。也就是说你建好表不用写一行后端代码前端就能直接调接口。5.2 实操建表、配权限、让前端调 API启动 NocoDB 非常简单Docker 一条命令docker run -d -p 8080:8080 -v ./nocodb:/usr/app/data nocodb/nocodb打开http://localhost:8080创建项目新建一张表比如就叫tasks字段类型随便拖标题、描述、状态、优先级、截止日期。填几条测试数据之后在项目设置里生成一个 API Token然后你就能用标准的 REST 请求来增删改查了。前端把它当后端用几分钟就接上。调用大概长这样const res await fetch(http://localhost:8080/api/v1/meta/tables/xxx/records, { headers: { xc-token: 你的API_TOKEN } }); const tasks await res.json();具体路径以 NocoDB 自己生成的 OpenAPI 文档为准但思路完全一样。我通常还会让 AI 直接读 NocoDB 的 Swagger 地址来写调用代码把 OpenAPI 文档链接丢给 Cline 或 Aider说“根据这个 API 文档生成 tasks 页面的增删改查代码”。AI 拿到标准文档后生成的前端代码非常稳定很少瞎猜字段名。这个流程把“等后端”的焦虑直接干掉了。权限方面也要花两分钟设置。NocoDB 默认把 API Token 和表权限分成不同角色至少要做到匿名用户只能读公开数据修改操作必须带 token。尤其是把项目共享给同事临时看数据时不要图方便给所有人开全部权限。5.3 使用边界它是个“临时后台”不是生产数据库NocoDB 的便利也带来一个陷阱太方便了容易让人真把它当生产系统用。我的建议是项目原型期、内部工具、演示 Demo 用 NocoDB 非常合适一旦涉及线上大量并发、复杂事务、严格的数据迁移就该换成正经后端加数据库。我见过有人拿它存了几个月生产订单后来要按复杂条件报表时查询慢到页面超时才后悔当初没早点迁移。给一个判断标准如果项目还处在“每天改表结构、加字段、字段类型说变就变”的阶段NocoDB 是绝配如果已经进入“并发在涨、数据不能丢、权限要细分”的阶段就要果断迁移。vibe coding 的节奏讲究快速验证只要记得它是“临时后台”用完就换就不会被它反噬。6. token 焦虑Langfuse 自托管之后每一笔模型调用都有了账本6.1 让人心里发虚的是不知道钱花在哪vibe coding 的另一大焦虑来源是“钱”。每次对话都在调大模型 API单看一两次没什么感觉月底看账单却心里发虚不知道是哪些功能在烧钱哪一个 prompt 特别贵哪一次调用失败后还在反复重试浪费。我的解法是自托管 Langfuse。Langfuse 是一个开源 LLM 可观测性平台可以把每一次模型调用记录成 trace包括输入输出、token 数量、费用估算、延迟、模型名、是否报错。它是自托管应用数据都在自己手里完整链路自己掌控用 Docker Compose 就能拉起一套。6.2 接入并不复杂两条路都试过第一条路在代码里直接接入 SDK。比如你的 Python 服务里调模型只需要在原有调用外面包一层from langfuse import Langfuse langfuse Langfuse() langfuse.observe() def generate_chat(prompt): # 你原来的调用逻辑 return call_llm(prompt)跑几条请求之后Langfuse 界面里就能看到对应的 traceprompt 是多少字、输出多少 token、花了多少钱、耗时多久。这套接入方式适合自己手写的后端服务。第二条路如果你用了 Dify 这类 LLM 应用平台Langfuse 也有现成集成。在 Dify 的观测设置里填上 Langfuse 的地址和密钥之后你在 Dify 里跑的每个工作流、每个 Agent 调用都会自动上报。我用得最多的是这条路因为 Dify 里的工作流往往包含多次模型调用Langfuse 能把整条链路的每一步都串起来看。6.3 从 trace 里挖出的三个真相接入三个月Langfuse 帮我发现三个之前完全没意识到的问题。第一某个功能的 prompt 在不知不觉中膨胀了 5 倍。最初只是一句话要求后来每次迭代都往 prompt 里塞示例最后每次请求都要消耗大量 token费用高得离谱。看到 trace 里的 token 曲线我才明白开始约束“prompt 里最多只能保留两条示例”。第二很多应用把整份文档作为上下文反复传入。这是典型的不了解 token 用法。其实应该用检索或摘要而不是每次都把所有内容塞进去。调完架构之后同一个功能的单次 token 消耗差不多降了一半。第三某个后台任务失败率高达 3%因为模型配置里的 timeout 太短高峰时频繁超时重试。之前我一直没发现因为只在“失败日志”里看从来没有统计过失败率。Langfuse 的 trace 界面把失败集中显示一眼就看出规律。有了这些数据之后vibe coding 不再是一笔糊涂账。每个功能都有明确的成本标签。焦虑来源于未知数据到位了情绪自然就稳了。7. 把散落的经验收进 Dify让 AI 少说胡话、多翻资料7.1 团队越用 vibe coding越需要一个“项目知识库”当你有好几个人同时在 vibe coding会出现一种新的焦虑大家问 AI 的姿势不一样得到的答案五花八门。有的问“怎么启动项目”AI 给的是旧命令有的问“为什么这里用 Redis”AI 开始现场编理由。开源项目可以查源码但每个人的提问效率太低。一个更干净的做法是搭建私有知识库。我用的是开源 LLM 应用平台 Dify它支持你上传项目文档、架构说明、接口约定、FAQ然后基于这些资料构建一个“项目助手”。同事有问题可以直接问它它会先到你上传的文档里检索再组织答案而不是凭空发挥。7.2 RAG 一次讲清Dify 三步搭建Dify 背后的核心技术是 RAGRetrieval-Augmented Generation检索增强生成简单理解就是三个步骤把知识文档切碎向量化后存进向量数据库用户提问时先在向量库里检索出最相关的几段内容把检索结果和问题一起打包给大模型让它“看着资料回答”。这样做的好处是不用把整个文档库塞进上下文省 token 还更准。大模型不需要把一百页手册全都背下来检索到哪段它就能引用哪段。在 Dify 里搭一个项目问答助手实际操作很快自托管 Dify用 Docker Compose 拉起创建知识库上传 Markdown 文档或网页内容设置分段大小和检索方式创建“聊天助手”应用关联知识库调一下提示词模板发布成 Web 应用或者通过 API 接回自己的项目。我一般直接把我前面用 AppFlowy 维护的 docs/ 文件夹导出成 Markdown定期同步到 Dify 知识库里。文档更新后点一下“重新索引”助手拿到的资料就是最新的。7.3 实际效果和一条最重要的维护提醒搭好之后我观察到两个变化。新人问“这个项目怎么在本地跑起来”助手会给出完整步骤还会提醒“先安装依赖再设置环境变量”比我自己答得还全。另一个是“为什么订单状态不能直接改”这类问题助手能引用当时写的决策记录给出理由而不是 AI 现场编一套。不过有一点必须提醒知识库是需要维护的。过期的文档比没有文档更危险AI 一旦检索到旧内容就可能导致错误决策。我现在把“每周更新一次 docs 并同步到 Dify”写进了项目周计划。宁可知识库内容少一点也不能存着又旧又错的结论。8. 日常体验的最后两块拼图Continue 规则文件和 Termux 移动端8.1 Continue 用规则文件把 AI 的“随手发挥”摁住前面几个工具主要管大动作日常写补全和小修改也有焦虑AI 自动补全时经常不按项目风格来比如别的文件都用单引号它突然给你来双引号别的函数都写类型注解它补了一个裸 JavaScript 函数。Continue 是开源 AI 代码助手装在 VS Code 里提供补全、聊天、内联编辑。它和商业 Copilot 最大的区别是高度可控你可以通过规则文件告诉它代码风格。我在项目根目录放了一个.continuerules内容大概是- 所有新建函数必须写类型注解 - 字符串优先使用单引号 - 修改公共接口前先搜索所有调用方并通知我 - 生成代码必须包含对应的单元测试 - 不要为了通过 lint 重写不相干的代码。这些规则会被带进 Continue 的补全和聊天上下文。实际体验是AI 生成的代码风格稳定了很多不再是那种“一眼看出是 AI 写的”乱糟糟状态。日常小改动不必再频繁打断去纠正它焦虑感少了一大截。8.2 Termux通勤路上也能看日志改一行不慌张最后一块拼图是手机端。vibe coding 最大的副作用之一就是心态被绑在电脑上只要服务没看住总觉得要出事。我现在手机上装 Termux一个开源终端模拟器能安装 Python、Node.js、Git、SSH 客户端等常用工具。建议直接去 F-Droid 或 GitHub Releases 获取别用商店里那个多年不更新的老版本。我的日常使用方式很简单pkg install git openssh python nodejs装上基础环境用 SSH 连到服务器tail -f看日志确认发布是否正常偶尔手边没有电脑时直接 pull 代码改一个字符commit 之后再 push配合 AppFlowy 手机端随手标记任务进度、更新踩坑记录。不过要诚实说一句手机终端的体验毕竟有限不适合做大量代码编辑更适合“看状态、做小修、不焦虑”。它对我的价值更多是心理上的任何时候都能确认系统是活的问题出现也能第一时间看到日志不用干着急。8.3 别急着一次上全套建议按这个顺序切入写到最后我想给刚开始接触这套工作流的朋友一句实在话9 个工具不要一次性全部上工具太多本身就会变成新的焦虑源。我推荐的顺序是先用 Aider 或 Cline把“每次改动都能回滚”这件事建立起来再花半天把 AGENTS.md 和 docs/context.md 写出来给 AI 一张地图项目开始涉及数据交互时再上 NocoDB 这类快速后台等到调用规模上来再上 Langfuse 做观测最后才考虑 OpenHands 这类自主 Agent 和 Dify 知识库。这套顺序的核心逻辑是先保命再看路最后才上车。工具本身不是目的目的是让 vibe coding 从“开盲盒”变成“开着仪表盘开车”。我个人现在最深的体会是vibe coding 的本质不是让 AI 替你当工程师而是换一种方式当工程师。AI 负责节奏你负责方向和边界。这套开源工具链没有一个能“装了就立刻提升代码质量”但它们组合在一起把最让人焦虑的不可控感降到了可以接受的范围。如果你也被 vibe coding 折磨得睡不好觉我的建议是先别急着换更强的模型先把“回滚 文档 观测”这个最小闭环搭起来。试一试大概率你会回来谢谢这几个开源项目。