03 — 工作台
它长什么样
下面全部是真实运行中的界面截图，不是效果图。
判断被压缩成「点两下、写一句」之后，它才第一次真正脱离了书桌： 既能在通勤路上完成，也能交给一个从不打开代码仓库的人完成。
当 AI 已经能写代码、修 bug、跑测试，人在软件里剩下的贡献收敛成一件事：判断—— 要做什么、两个方案选哪个、这样对不对。这两个项目在做同一件事：把每一个「需要人拍板的时刻」 变成网页上的一张卡片。于是判断可以在手机上完成，也可以交给你之外的人。
01 — Why
「你只需要告诉他最终的目的、衡量指标、约束条件。最重要的是评估。」
「当你纠结在他具体怎么做的时候，你已经错了。路径不重要，方法不重要，结果和约束条件才重要。」
—— 项目的核心哲学：把信送给加西亚
这句话决定了整个系统的形状：人不做过程审查。人只做两件事—— 低频地把目标、衡量指标、约束条件写清楚；以及在真正没有标准答案的时候拍板。 其余全部交给一套自动打分的验证机制，和一个对照目标做评估的 AI 裁判。
真实的体感是：从「我明确知道要什么」那一刻起，后面的活——写、改、修 bug、验证—— AI 基本都能干，而且越来越好。人剩下的贡献不是敲键盘的速度，而是 判断：要不要做这个功能、两版设计哪个更好、这个体验对不对、 这个 bug 值不值得现在修。
Cursor、Claude Code、Codex，本质上都还是命令行加一个对话框。你必须坐在电脑前， 读一段一段的文字，用打字来回答。可是「这两个界面哪个更好」这种判断， 本来就不适合用文字问答来完成——更不该要求做判断的那个人，首先得是个会用终端的程序员。
让 AI 把要问的事渲染成一页图文：低保真原型、架构图、可勾选的方案对比、可以就地改写的文档。 你在浏览器里（包括手机）点一点、在图上圈一下、写两句话，判断就完成了， AI 立刻被唤醒接着干。
既然判断已经变成网页上的一次点击，做判断的人就不必是全职员工。 内测用户贡献「这里坏了」的判断；领域专家按小时受聘，贡献产品、交互、架构上的判断。 他们看不到源代码，只看到产品形态和被渲染出来的决策上下文——知识产权天然隔离。
创始人出愿景和例外裁决，5–10 位顾问出领域判断，约 100 位内测用户出测试判断， 云端一组各司其职的 AI 干掉其余全部。理论上任何产品，只要用户能测、顾问能判断， 都可以套这套框架，不需要招任何全职员工。
02 — What
一个解决「人和 AI 怎么对话」，一个解决「一群人怎么共同驱动 AI」。 前者可以单独用；后者的每一个人机触点，都长成前者的样子。
今天的 coding agent 都是「对话式」的——所有东西塞进一条聊天流， 决策点淹没在文字里，你只能打字回应，AI 断了就是黑洞。
工作台把它改成 对话 + 文档 的双形态：左边仍然是对话流， 右边是可视化的内容区，分成「决策」和「文档」两块。AI 每一轮的思考被渲染成一个共享工件—— 原型图、架构图、勾选题、可以就地改写的文档——你在上面直接操作，提交后 AI 被异步唤醒续跑。
一句话：它想成为下一代的 Cursor / Claude Code。
把「报 bug → 分诊 → 修复 → 验证 → 评估 → 分级合并 → 复验关单」整条链路自动化， 人只在两个地方出现：定义意图，和例外裁决。
它规定了谁在什么时候被叫出来做判断、判断如何回到代码、什么样的改动可以自动合并、 什么样的必须有人点头。它是一套可以套在任何 git 项目上的通用框架，不绑定具体产品。
一句话：它是把判断分发给一群人的那套架构。
它们是包含关系。
工作台可以单独使用——这个项目本身的全部设计讨论，就是用工作台跑完的（吃自己的狗粮）。 而 vibeloop 长期不该有第二套界面：它需要人判断的每一处，都渲染成工作台的一次会话。
03 — 工作台
下面全部是真实运行中的界面截图，不是效果图。
04 — 闭环
这是已经在真实产品上跑通的路径。整条链路里，只有第 3 步遇到「没有标准答案」时， 和第 6 步碰到高风险改动时，才会把人叫出来。
在产品里点「反馈」，系统自动附上版本、系统、日志
有效吗？信息够吗？（不够就追问）和已有工单重复吗？
在独立分支里改；遇到没有标准答案的取舍，停下来出决策卡找人
跑项目自己声明的验证命令：测试、构建、断言
另一个 AI 对照项目宣言里的目标和约束，评估这次改动
低风险自动合并；碰到保护路径或高风险，强制人工审批
通知报告者，他说「确实好了」才关单；没好就重开
合并不是终点，报告 bug 的那个人才是最后一道验证。
这是和「AI 自己觉得修好了就合进主线」最大的区别。 自动化的置信度上限，等于项目自己写的验证命令有多严格——所以这套框架逼你先把「怎么算做对了」说清楚。
05 — 角色
这是最容易被误解的一点：既然是「让用户和顾问参与 vibe coding」， 那他们在哪里写代码？答案是——他们不写。
| 参与者 | 做什么 | 在哪里 | 碰代码吗 |
|---|---|---|---|
| 内测用户 | 报 bug、补充信息、修好后复验关单 | 任意设备的浏览器 | 否 |
| 顾问 | 裁决指派到自己领域的决策卡；也能以超级用户身份直接提需求 | 手机或电脑浏览器 | 否 提案由 AI 实现 |
| 创始人 | 维护目标与约束、例外裁决、发起新的开发意图 | 电脑深度共创 + 手机高频拍板 | 通常否 |
| 云端 AI | 分诊、写代码、跑验证、评估、合并、通知 | 代码所在的那台机器上 | 是 唯一执行者 |
这个平台上，唯一写代码的是 AI。
「顾问来参与开发」实际发生的是：顾问的判断直接驱动 AI 去写代码，顾问本人自始至终待在网页上。 同理，「在手机上 vibe coding」不是把 IDE 搬上手机，而是把发指令和做判断搬上手机。
06 — 东西放在哪
一句话：你在哪都能参与，AI 在代码所在的地方干活。
报 bug 的页面、决策队列、对话、文档库，都住在云服务器（东京）上。任何人、任何设备、任何时间都能进来——这是顾问和用户能随时参与的前提。
每个项目有唯一一份权威代码副本，AI 就在它旁边改。网站类项目住云服务器；需要 Mac 工具链的项目住 Mac Studio；将来 Windows、安卓项目同理。
GitHub 只是镜像和灾备，权威在服务器上。你自己电脑上那份，默认只用来同步查看。要改代码，走流程让 AI 改。
为什么不干脆全搬上云？ 因为个人的工具链、编译环境、各种登录凭证很难、也不该搬进云端沙盒。 让 AI 去代码所在的地方干活，比把一切搬到 AI 所在的地方，现实得多。
07 — 场景
同一套框架，落到不同的人和场景上。
一个创始人 + 5–10 位兼职顾问 + 约 100 位内测用户 + 一组云端 AI。 任何产品，只要用户能测、顾问能判断，都可以套这套框架跑起来，不需要招全职员工。
不招人。找该领域判断力最强的专家，每天抽一小时。 你买的是他的时间、判断、注意力和经验，不是他的工时——因为他不需要动手做任何事。
顾问访问不到源代码，只看到产品形态和被渲染出来的决策上下文， 每个人只在其中一块上反馈。不存在「请了外脑，泄露了核心」这个矛盾。
发起一个新想法、看 AI 的进度、随手拍板，全程不开电脑。 代码始终在服务器上由 AI 编写，手机上流动的只有意图和判断。
对不会配环境的人来说，他们缺的只是一套跑得起来的 AI 开发环境。 平台方在云端替他们搭好——这本质上就是「云端的 vibe coding 平台」。
同事在自己电脑上用产品，发现问题直接报；提的需求可以直通修复队列。 他既是测试者，也是判断的贡献者，不需要任何额外身份。
08 — 现状
诚实地分成两栏：已经被真实跑通的，和还只是设计的。
09 — 意义
软件的生产关系会变一次。过去要做一个产品，要么你自己会写代码， 要么你雇一群会写代码的人。以后可能是：你有清晰的判断力， 加上一笔购买别人判断力的预算，就够了。
写代码不再是门槛。会判断——知道要做什么、知道什么是好的、 知道在没有标准答案时该怎么选——变成了唯一的门槛。 这对「有想法但不会编程」的人是一次实打实的松绑； 对已经会编程的人，则是把注意力从「怎么实现」挪回「到底该做什么」。
所以这两个项目值得慢慢做对。它们不是又一个「写代码更快」的工具， 而是在试一种新的组织方式：一个人能调动的产能， 第一次不再由他能雇多少人来决定。