bb 是一个开源、Local-first（本地优先）的 AI 开发环境，它提出了 Loop-Driven Development（LDE，循环驱动开发） 的理念。与传统 IDE 只负责编辑代码不同，bb 将 AI Agent、自动化任务、工作线程（Thread）和开发流程整合到同一个环境中，希望让 AI 能持续执行开发循环，而不仅仅是回答一次问题。
Loop-Driven Development（LDE）
LDE 可以理解为 AI 不断重复执行下面这个循环：接收任务 → 分析代码 → 修改代码 → 运行测试 → 检查结果 → 继续修复
而不是像普通聊天机器人一样，一次回答后就结束。
这种模式更适合：
- Bug 修复
- 大规模重构
- 自动生成文档
- 持续代码维护
- 长时间开发任务
适用场景
bb 更适合以下开发模式：
- AI 驱动的软件开发
- 多 Agent 协作开发
- 自动化软件维护
- 持续重构大型代码库
- 自动处理 Issue 和 PR
- 长时间运行的开发任务
你写代码的时候，AI 是不是永远只回答一次就装死？
那玩意儿不叫开发，那叫高级问答。真正的开发，是让 AI 像实习生一样赖在你电脑里不走，修完 Bug 测代码，测出问题再修，直到你下班它还在跑。这个叫 bb 的东西，就是把 AI 从“顾问”变成“牛马”的那个开关。
AI 写代码已经不稀奇了，稀奇的是 AI 能自己开个分支、改完代码、跑通测试、然后等你验收，全程不需要你盯着。更离谱的是，你可以命令它给自己加功能，它加完功能之后变得更强大，然后用更强的能力继续给自己加功能——这不是开发工具，这是你养了个会下蛋的鸡，而且鸡蛋孵出来还是鸡。
你把 AI 当聊天框，它把 AI 当循环
大部分程序员打开 ChatGPT 或者 Claude，贴一段报错，复制回解决方案，再贴回终端。这个流程叫“复制粘贴式开发”，本质上跟 1999 年上论坛问问题没区别。你问一次，AI 答一次，然后你手动执行下一步。问题是，修 Bug 从来不是一步到位的事——你改完 A，测试挂了 B，修好 B，CI 又报 C。正常人类在这套循环里来回切上下文，脑子都快烧了。
bb 做了一件事：它把这个循环直接内嵌进环境里。官方管这个叫 Loop-Driven Development，缩写 LDE。翻译成人话就是：AI 接收任务之后，自己分析代码、自己改代码、自己跑测试、自己看结果、如果测试没过就自己接着改，直到任务完成为止。整个过程不依赖你手动触发第二次。
这个模式对三类任务尤其有效。第一类是修 Bug，尤其是那种老项目里的隐晦 Bug，AI 能翻日志、查调用链、反复试错。第二类是重构，把一个 2000 行的老类拆成模块，AI 可以分步骤执行，每一步都跑测试验证。第三类是那种“脏活累活”，比如给全项目补文档、统一 import 风格、批量改 API 调用方式——这些事人不想干，AI 干着干着就跑偏，但 LDE 的循环机制能把它拽回来。
你可能会问，这和 GitHub Copilot 的自动补全有什么区别？Copilot 是你写一行它补三行，本质是“输入法增强版”。LDE 是你说“把登录模块换成 JWT”，然后 AI 自己去翻路由、改中间件、更新测试用例、跑通全部流程，最后告诉你搞定了。前者是给你递砖头，后者是你画个图纸它就给你盖个厕所。
线程不只是聊天记录，是独立的开发沙盒
你平时用 IDE，左侧是文件树，右侧是代码。bb 左侧是线程列表，每个线程相当于一个独立的 AI 工作区。你启动一个线程说“修 CI”，bb 背后干的第一件事是调用 Git Worktree 创建一个全新的目录，在那个目录里自动切出一个新分支，然后 AI 在那个独立环境里干活。改坏了？直接删掉这个 Worktree，主分支毫发无损。
这个机制带来一个很反直觉的结果：你可以在同一个项目上同时开十几个线程，每个线程跑着不同的 AI Agent，有的在修 Bug，有的在写测试，有的在重构老代码，它们互相不打架。传统 IDE 里你切换分支都要 stash 暂存，在这里你连 stash 命令都懒得敲了。
那为什么要这么设计？因为 AI 犯错是常态，不是例外。你让 AI 改一段核心逻辑，它有 30% 的概率改炸。如果它直接在 main 分支上动手，你事后得手工回滚。但 Worktree 把每次改动都隔离成独立的目录，改炸了就直接扔，像虚拟机快照一样干净。这个设计本质上承认了“AI 会频繁犯错”这个现实，然后用工程手段把错误的影响降到最低。
更有意思的是，bb 允许一个线程启动另一个线程。比如 Claude Code 线程发现重构涉及三个模块，它可以分别启动三个 Codex 线程并行处理，等三个都跑完再汇总结果。这种递归式的任务分解，在传统 IDE 里你只能靠手动切窗口来实现，在 bb 里是原生支持的。
每个安装都不一样，因为你自己说了算
大多数软件打开第一眼长什么样，你用到倒闭那天还长什么样。bb 的默认界面很简单：左侧线程列表，右侧主面板，没了。但你让它加个任务管理系统，它就给你加一个完整的 GUI，用来建 Issue、筛任务、指派 Agent。你再让它加个 Markdown 编辑器，它就能变成一个 Obsidian 风格的知识库，你和 AI 可以同时在里头写文档。
Sawyer Hood 那条推文里展示了一个离谱案例：有人在自己的 bb 里克隆了一个 Linear——就是那个知名的项目管理工具——相当于在 IDE 内部又长出了一套完整的项目管理系统。更离谱的是，这套系统不是预置功能，是用户直接跟 bb 说“给我建个任务管理界面”，bb 自己调用 Agent 写出来的。
这背后的机制叫“吃自己狗粮”：bb 的扩展系统本身就和开发它的系统是同一套 API。你可以让 bb 给自己写一个新插件，写完插件自动加载，然后你就可以用这个新插件继续拓展 bb。这个循环一旦启动，你的 bb 会和隔壁同事的 bb 长得完全不一样——他可能装了一堆自动化测试插件，你的全是文档生成和音乐制作工具。
那这套设计对普通开发者意味着什么？意味着你不再需要等软件厂商给你发布新功能。你想要什么，当场让它自己造。这就像你买了个毛坯房，开发商给了你水泥和砖头，然后说“你自己想盖成什么样都行”，但关键是这堆砖头里有机器人，你说“给我砌个壁炉”，它就连夜给你砌好了。
它跟 Claude Code、Cursor 压根不是一码事
很多人一听“AI 开发环境”就联想到 Claude Code 或者 Cursor，以为又是那种侧边栏里塞个聊天框的编辑器插件。Claude Code 是 Anthropic 出的命令行工具，你问它问题，它帮你生成代码或者改文件，然后等你下一步指令。Cursor 是 VS Code 的分支，把 GPT 内嵌到编辑器里，你选中一段代码让它解释或者重写，它给你一个 diff 就完事。这两者的核心模式都是“你问一次，它答一次”，区别只是回答得准不准、快不快。
bb 的玩法完全不同。它不是等着你问问题，而是主动把“改代码—跑测试—看结果—再改”这个闭环自动化了。你给它一个目标，比如“修复登录超时 Bug”，它自己会循环执行上述步骤，直到测试全部通过或者你手动喊停。Claude Code 和 Cursor 不会主动去跑你的测试套件，也不会在测试失败后自动回溯修改，它们只负责生成代码片段，剩下的验证工作全得你手工操作。
更本质的区别在于多 Agent 协同和工作树隔离。Cursor 里你只能一次调用一个 AI，想同时让两个模型协作？没门。bb 原生支持同时跑多个 Agent，而且它们能互相调用。Claude Code 本身是单线程的，你开两个终端跑两个实例，它们互相不认识，更别说分工了。Worktree 方面，Cursor 你切换分支还得手动 git checkout，bb 是每次新线程自动建一个独立目录，连 stash 都不用操心。
还有自动化能力。Claude Code 和 Cursor 都是交互式工具，你要坐在电脑前跟它们一来一回。bb 可以把 Agent 挂成定时任务，比如每晚三点自动扫描 Issue 并生成 PR，你睡觉的时候它在工作。这种“无人值守”的开发模式，那俩工具根本没想过要支持。所以别再拿 bb 跟编码助手比了，助手是帮你写字的笔，bb 是替你把整篇文章写出来还顺便校对三遍的机器人。
代码全部归你，跑在本地，不收模型调用费
bb 采用 MIT 协议开源，你可以 Fork、改 UI、加 Agent、部署内网版本，随便折腾。所有 AI 服务走你自己的订阅——Claude、OpenAI、Codex，你原来付给谁现在还付给谁，bb 不在中间抽成。
更重要的是，自动化任务全部跑在你本地机器上。你可以设一个定时任务，每天凌晨三点扫描 GitHub 新 Issue，AI 自动分类、打标签、甚至直接生成修复 PR。这一切在你自己的电脑上完成，代码和配置文件不出内网。对于有数据安全要求的团队，这个 Local-first 属性比云端方案更有吸引力。
那它到底解决了什么本质问题？传统开发里，“写代码”只占一半时间，另一半时间花在“理解上下文”上——这个 Bug 是哪个版本引入的？这个函数被谁调用了？CI 报错是因为环境问题还是代码问题？bb 的 LDE 循环把“理解—修改—验证”打包成一个原子操作，AI 替你跑完这个闭环，你只需要看结果。
开发者视角的冷峻观察：这不是 IDE，这是 Agent 的 App Store
回到最开始那个问题：AI 写代码已经不稀奇了，稀奇的是什么？是 AI 能持续不断地给自己加功能，然后你什么都不用做，它就越来越好用。
bb 的架构拆开看就三层：最底层是 Git Worktree 提供的隔离环境；中间层是 Thread 系统管理的独立上下文；最上层是插件系统，允许 AI 通过同一套接口扩展自身功能。这三层叠加出来的效果是：你的开发环境会随着使用次数增加而自我进化。今天你让它修了个 Bug，明天它修 Bug 的速度就比今天快，因为它在修 Bug 的过程中给自己加了一套自动化诊断工具。
从语言策略上看，bb 的宣传材料大量使用“agent orchestrator”和“loop-driven”这两个对立词组——前者暗示控制，后者暗示重复。这种配对方式让读者在“AI 被控制”和“AI 主动循环”之间产生认知摩擦，恰好是 Sawyer Hood 那条推文能拿到 10 万次查看的原因。句式上，推文里短句为主，平均每句 12 到 15 个词，描述功能时切换到长句拉出技术细节，这种节奏切换让普通读者能看懂“能干什么”，专业读者也能捕捉到“怎么实现的”。
反常识的点不在技术，而在所有权：以前软件是厂商卖给你一个成品，现在 bb 给你一个能自己改造自己的空壳。你买的不是功能，是“长出功能”的能力。这就像买车和买机床的区别——前者把你送到目的地，后者让你自己造车，而且造出来的车还能继续造车。
回到现实层面：现在就去 GitHub 上把 bb 克隆下来，跑起来，然后让它给自己加个你一直想要但没人做的功能。你会发现最难的不是代码，是忍住不笑——因为你刚教会了工具怎么给自己升级，而它升级完之后的第一件事，就是问你“还要加点什么”。
总结
bb 是让 AI 持续循环“改代码—测代码—再改”的开发环境，把问答升级为自动闭环。自动修 Bug、重构、写测试、生成文档，AI 能无人值守跑完整个开发循环。
这属于AI 辅助软件开发和 Agent 编排，本地优先的自进化开发工具。
总之，bb 并不是另一个 AI IDE，而是试图把 AI 从“代码助手”升级为“持续工作的开发成员”。它围绕 Loop-Driven Development 构建，将 AI Agent、Git Worktree、自动化任务和多线程协作整合在一起，使 AI 能够持续执行“分析—修改—测试—验证”的开发循环。
如果你关注 AI Agent、多 Agent 协作或 Software Factory 方向，bb 展示了一种不同于传统 IDE 的开发范式。