VibeProject

很多人一谈 AI 开发，马上想到的都是执行层：编辑器、代码生成、自动化、代理协作。但我后来越来越在意的，反而是更靠前的一层：一个项目在进入执行之前，究竟有没有被整理成一个 AI 和人都能真正接住的对象。

我后来越来越确定，项目协作里很多混乱并不是发生在执行阶段，而是发生在执行之前。项目看起来已经开始了，实际上还没有被定义清楚。文档分散在不同地方，规范有人知道但没有被收起来，远端路径靠口头约定，项目骨架没有被持续维护，AI 会话也不知道应该从哪里进入。人自己接手一个项目时都要花很多时间重新拼上下文，交给 AI 以后，这个损耗只会更明显。

所以 VibeProject 关心的，不是“AI 怎样多写一点代码”，而是“项目有没有先被组织成一个可以被理解、被接手、被继续推进的对象”。在我看来，这件事比自动执行更靠前，也更关键。

一、为什么我会觉得这里比执行界面更值得先做

很多人谈 AI 开发协作，第一反应都是编辑器、代码生成、自动执行。这些方向当然重要，但我后来越来越觉得，真正更值得优先重做的，是项目定义界面。

原因很简单。执行这件事再强，如果项目本身还是松散的，AI 也只能围绕碎片做推断。它可能知道当前一段文档，知道一个目录，知道某个需求片段，但它并不知道项目整体到底是什么、规范从哪里来、真实路径在哪、当前阶段到了哪里。没有这些东西，所谓自动执行很容易建立在不稳定的前提上。

也正因为如此，我更关心的是项目在进入执行之前，能不能先被整理成一个像样的对象。只有这个对象先成立，后面的 AI 协作、远端初始化、任务推进、AIDevOps 才有稳定起点。

二、为什么项目混乱的本质是上下文没有被组织起来

我最常见到的问题，不是“没有文档”，而是文档和上下文没有被组织起来。

有些东西在文档里，有些在目录里，有些在远端机器上，有些在某个人的习惯里，还有些在团队默认约定里。AI 不知道这些隐性关系，人自己换个阶段回来看也要重新适应。

这件事在 AI 时代会更明显。因为 AI 不像人那样能自动从长期经验里补足模糊地带。它更依赖显式上下文。项目目标是什么，规范在哪里，目录怎么组织，远端路径在哪，真实文件状态是什么，当前到底应该从哪个入口开始，这些都需要被明确组织起来。

如果这些东西分散着存在，项目就只是“被讨论过”，而不是“被定义过”。

三、为什么规范、路径、文档和使用习惯必须被收在一起

VibeProject 里最重要的一个判断是：项目定义从来不只是文档问题，而是一组对象关系。

项目目标、规范来源、项目骨架、远端路径、真实文件状态、项目文档、AI 会话入口、个人使用习惯，这些东西本来就属于同一个问题域，只是长期以来被不同工具切碎了。

这一点和个人工作习惯也有关系。就像远端工作里的窗口组织方式因人而异一样，项目使用习惯也不是统一的。有人先看 PRD，有人先看目录，有人从远端路径进入，有人依赖规范清单，有人需要先知道部署和运行方式。人是这样，AI 也是一样，它如果不知道这些入口之间的关系，就很难真正配合好。

所以我理解的“项目定义界面”，不是一个单纯的文档页，而是把规范、结构、路径、文档和使用入口重新收在一起，让项目先形成一个稳定的上下文容器。

四、为什么这件事会直接影响后面的 AIDevOps

如果后面想继续走向 AIDevOps，这一步几乎绕不过去。

因为 AIDevOps 不是单靠模型能力就能成立的。它需要大量上下文：项目规范、运行要求、目录结构、环境信息、历史文档、任务状态，甚至还包括不同人的使用习惯和团队默认方式。只有这些东西被持续收集、组织并保持可读，AI 才有可能和开发、运维、交付这些动作真正配合起来。

如果前面这层没有做好，那么后面的 AIDevOps 很容易变成局部自动化拼接，而不是一个真正可靠的协作系统。也就是说，项目定义不是前置文档工作，而是整个 AI 协作链条的地基。

五、为什么它要同时承接“规范模式”和“真实模式”

项目在不同阶段，事实来源并不完全一样。

有时候项目还在梳理阶段，很多东西更接近规范和设计；有时候项目已经进入真实执行，重点就会落到远端目录、真实文件状态和运行环境上。如果系统只能承接其中一部分，用户最后还是得在“文档世界”和“真实世界”之间来回切换。

所以 VibeProject 想做的，不是替代其中一边，而是把这两边接起来。让项目既能在规范层被组织，也能在真实执行层被接住。这样项目从想法、定义、落地到后续演进，才是一条连续链路，而不是多个分裂入口。

六、为什么它首先适合运开场景

我现在会觉得，VibeProject 最先适合的不是泛化意义上的所有项目角色，而是更偏运开这类场景。

因为这类人天然要同时面对文档、结构、远端路径、运行环境、部署要求和实际文件状态。他们既要理解项目是什么，也要知道项目怎么跑、怎么接、怎么继续维护。项目如果没有被先整理清楚，这类角色会最先感受到上下文损耗。

而 AI 一旦开始参与这类工作，对“项目有没有先被定义好”的要求只会更高。它不是只看一份文档就够了，而是要知道项目边界、目录落点、规范来源和执行入口。对运开来说，这个问题不是抽象概念，而是每天会遇到的实际摩擦。

七、为什么我仍然觉得这条线值得做

VibeProject 的核心逻辑其实很简单：在 AI 时代，项目如果还只是散落的信息集合，就很难被稳定协作；只有先被定义成一个可理解、可接手、可继续推进的对象，后面的执行和自动化才真正有基础。

所以它不是一个“项目记录页”，也不是一个普通文档工具，而更像一个把项目整理到可协作状态的界面层。

我真正想解决的，也不是“怎么多生成几份方案”，而是“怎么让项目在进入执行之前，先拥有一个可靠的上下文容器”。这件事如果不先成立，后面的 AI 协作、远端开发和 AIDevOps 都很难真正做好。