当 AI 助手开始管理多个项目：如何把“继续某项目”变成可联动机制

当 AI 助手开始管理多个项目：如何把"继续某项目"变成可联动机制

这不是一篇关于"怎么写 YAML"的文章，而是一篇关于如何让 AI 助手在多项目协作里不再靠猜的文章。

如果你也在用 AI 助手同时推进多个项目，这篇文章想解决一个很具体的问题：

为什么一句"继续这个项目"，经常会让助手进入错误上下文；
为什么"规划仓 + 代码仓"不能简单做成一对一绑定；
怎样用一层轻量的项目映射机制，把"继续某项目"变成一个可联动、可回写、可持续的动作。

前言：一句"继续这个项目"，为什么会把事情搞乱？

如果你已经开始让 AI 助手长期参与项目推进，你大概率会遇到一个很真实的问题：

当你说：

继续这个项目。

你心里以为自己说得很清楚，助手却未必真的进入了你想要的上下文。

最常见的错位有四种：

只进入代码仓，没有同步加载项目规划结论；
重新发散技术方案，重复讨论已经定稿的东西；
做完实现推进，却没有把阶段进展回写到项目记录；
项目一多，规划、执行、记忆三者开始越来越松散。

我最近就在一个真实项目里，完整踩到了这个坑。

后来我们发现，这不是简单的"记忆没跟上"，而是：

协作机制少了一层显式的项目映射结构。

于是，我们把"凭记性联动"改造成了"靠机制联动"。

如果你也在用 AI 助手推进多个项目，我认为这套思路值得尽早补上。

一、问题是怎么暴露出来的

当时我们正在推进一个正式项目：local-kb-assistant。

这个项目不是只有代码仓，它还有一套项目规划文档，放在一个专门的规划仓里。于是问题来了：

当我说"继续 local-kb-assistant 项目"时，助手虽然知道是在继续一个项目，但最开始它更容易直接落到代码实现层 ，而没有自然地把这个项目对应的规划上下文一起联动进来。

结果就是：

提到"继续某项目"时，助手不一定会优先读取这个项目的既有规划结论；
讨论技术方案时，容易脱离已定稿范围，再次发散；
代码推进之后，如果没有回写机制，规划仓和代码仓会逐渐失真；
项目一多，这种错位会越来越明显。

一开始看，这像是"助手没记住"。

但后来我们意识到，这不是记忆问题，而是模型里缺少一个显式的项目映射层。

二、最容易犯的错：把"项目联动"理解成"仓库绑定"

很多人第一次设计这件事时，会很自然地这么想：

一个规划仓，对应一个代码仓；
继续某项目时，就自动同时联动这两个仓。

这个思路一开始看起来很顺，但很快就会失败。

因为真实项目关系，往往根本不是一对一。

典型反例

1. 一个规划仓可能管理多个项目

例如一个 ai-project-incubator 仓，本身就可能同时记录多个正式项目的规划，而不是只服务某一个代码仓。

2. 有些代码仓根本不需要规划仓

比如临时实验、小工具脚本、一次性验证仓，它们可能只需要代码，不需要长期规划和阶段记录。

3. 有些项目目前只有规划，还没有代码仓

某个方向还处在孵化期，已经有规划文档，但还没真正开工。

4. 一个项目未来可能对应多个执行仓

例如一个正式项目后续拆成：

核心后端仓
UI / 桌面端仓
原型验证仓

如果你的机制默认"一个规划仓对应一个代码仓"，那它从一开始就不具备扩展性。

所以，问题的关键不是：

怎么把两个仓绑起来？

而是：

我们到底应该把什么当作联动的基本单位？

答案是：项目，而不是仓库。

三、正确抽象：联动的对象应该是 Project

真正合理的做法，是把联动的基本单位定义成 Project（项目）。

也就是说，一个项目应该有自己的结构化描述，而不是只靠一句名字和一个仓库路径来隐式表达。

一个项目至少需要包含这些信息：

项目 ID
项目名称与别名
是否受规划仓管理
如果受管理，对应的规划锚点在哪里
当前有哪些执行锚点（代码仓 / 实现目录）
当前联动级别是什么
用户说"继续这个项目"时，默认应该执行什么动作
哪些变化需要回写到规划记录中

一旦把这一层补上，原本很多混乱都会自动消失。

四、先看一个真实例子：`local-kb-assistant`

如果只从字面看，很多人会误以为：

local-kb-assistant = 一个代码仓

但在真实工作流里，更准确的结构应该是：

项目 ID ：local-kb-assistant
规划仓 ：ai-project-incubator
规划路径 ：projects/local-kb-assistant
代码仓 ：local-kb-assistant

换句话说：

local-kb-assistant 是一个项目名；
ai-project-incubator 是承载该项目规划的规划仓；
local-kb-assistant 目录是该项目当前主要的执行锚点。

这时，"继续 local-kb-assistant 项目"就不再等同于"切到某个目录开始写代码"，而应该理解为：

进入一个已经被登记过、具有规划上下文和执行上下文的正式项目状态。

五、项目联动机制应该满足哪些要求

当我们接受"联动对象是项目"这个抽象后，机制至少要满足以下几个要求。

1. 支持一个规划仓管理多个项目

不能把规划仓本身误当成某个单独项目。

2. 支持有些项目不受规划仓管理

不是所有代码仓都值得被纳入正式规划体系。

3. 支持一个项目对应 0～多个执行锚点

项目可以只有规划、只有执行，也可以同时拥有多个执行载体。

4. 支持默认联动行为可配置

继续项目时，有的项目应该：

只看规划；
只看执行；
规划 + 执行同时联动。

5. 支持重要变化回写

如果本轮推进发生了：

阶段进展
范围变更
技术路线调整

那规划记录就不应该继续停留在旧状态。

六、从口头约定到文件化机制：`project-map/`

为了把这套机制真正落下来，我们最终新增了一个专门的目录：

text 复制代码

project-map/

它的定位非常克制：

只放轻量、耐久、低噪音的项目映射元信息，不放项目实现代码。

目前它至少包含两类文件：

1. `projects.yaml`

项目注册表。

2. `README.md`

机制说明文档，用来解释：

为什么需要这层映射；
各字段代表什么；
当用户说"继续项目"时，应该如何解释与执行。

这样做最大的价值，是把原本"靠感觉理解"的事情，转成了"靠文件和规则解释"的事情。

七、一个最小可用的项目映射长什么样

下面是一个简化后的示例：

yaml 复制代码

projects:
  - id: local-kb-assistant
    name: 本地知识库助手
    aliases:
      - local-kb-assistant
      - 本地知识库助手
      - local kb assistant
    planning:
      managed: true
      repo: ai-project-incubator
      path: projects/local-kb-assistant
      key_docs:
        - 00-overview.md
        - 02-mvp-scope.md
        - 03-tech-options.md
        - 05-progress-log.md
    execution:
      repos:
        - name: local-kb-assistant
          root: /root/.openclaw/workspace/local-kb-assistant
          role: main-implementation
    linkage:
      level: strict
      continue_behavior: planning+execution
      writeback_rules:
        - stage_progress
        - scope_change
        - tech_decision_change

看起来它只是一个 YAML，但它其实补上了过去最关键的一层：

这个项目有没有规划锚点？
规划锚点在哪里？
它有哪些执行锚点？
用户说"继续项目"时，默认要联动到什么程度？

八、为什么 `linkage.level` 很关键

在整个结构里，我觉得最有用的字段之一是：

yaml 复制代码

linkage:
  level: strict

因为它不是在描述"有没有关联"，而是在描述：

继续该项目时，规划与执行应该被多强地联动起来。

我建议至少保留三档：

`none`

不默认联动。适合：

独立代码仓
一次性小工具
不纳入正式规划的实验仓

`light`

有关系，但不需要每次都做深联动。适合：

轻量项目
有规划，但联动频率不高的项目

`strict`

继续项目时默认联动规划 + 执行；重要变化要考虑回写。适合：

正式推进项目
需要长期跟踪和阶段记录的项目

对于 local-kb-assistant，当前设置成 strict 是非常合理的。因为它本来就是一个正式推进中的主线项目。

九、如果用 Mermaid 画出来，这套机制会更容易讲清楚

纯文字讲这件事会有点抽象，所以我建议公开博客里一定加图。Mermaid 就非常适合。

1. 结构关系图

用户说：继续 local-kb-assistant 项目
project-map/projects.yaml
项目 ID: local-kb-assistant
规划锚点

ai-project-incubator/projects/local-kb-assistant
执行锚点

local-kb-assistant/
联动级别

strict
继续行为

planning + execution

这张图能非常直观地说明：

"继续某项目"不是直接跳进某个仓，而是先经过项目映射层，再决定如何联动规划和执行。

2. 继续项目时的工作流图

否
是
planning-only
execution-only
planning+execution
否
是
用户发起：继续某项目
解析项目 ID / aliases
是否受规划仓管理?
进入执行上下文
读取联动级别
continue_behavior
只加载规划文档
先加载规划锚点，再进入执行锚点
本轮是否发生重要变化?
结束当前轮推进
回写规划记录

十、如果你想自己落一版，最小可复制模板可以这样写

如果你读到这里，最可能的问题是：

这个思路我懂了，那我能不能先抄一个最小版回去试？

可以。下面是我建议的最小模板。

1. 最小 `projects.yaml`

yaml 复制代码

projects:
  - id: demo-project
    name: 示例项目
    aliases:
      - demo-project
      - 示例项目
    planning:
      managed: true
      repo: planning-repo
      path: projects/demo-project
      key_docs:
        - overview.md
        - scope.md
        - progress.md
    execution:
      repos:
        - name: demo-project
          root: /path/to/demo-project
          role: main-implementation
    linkage:
      level: strict
      continue_behavior: planning+execution
      writeback_rules:
        - stage_progress
        - scope_change
        - tech_decision_change

2. 最小解释规则

你至少需要让助手理解下面几条：

继续某项目时，先按项目 ID / aliases 解析；
如果 planning.managed = true，不要只看代码仓；
如果 linkage.level = strict，默认联动规划 + 执行；
如果本轮发生阶段进展 / 范围变化 / 技术决策变化，要考虑回写规划记录。

就这么几条，已经能解决很多"继续项目却上下文错位"的问题。

十一、这套机制在真实协作里带来了什么收益

这不是一个"看起来设计很优雅"的抽象，而是一个真实能减少混乱的机制。

1. 项目上下文不再只靠临场记忆

规划锚点、执行锚点、关键文档、联动级别，都有了文件化记录。

2. 继续项目时不容易重新发散

助手会优先受到既有规划定稿的约束，而不是重新从"我建议这样做"开始起盘。

3. 规划仓和代码仓的职责更清楚

规划仓负责：想清楚、沉淀结论、阶段记录
代码仓负责：实现、验证、提交演化

4. 可以优雅地区分不同类型的项目

通过 managed 和 linkage.level，可以自然区分：

正式项目
独立代码仓
孵化期项目
多执行仓项目

十二、为什么还需要一个 workspace 元仓

在把项目联动机制文件化之后，很自然又会遇到另一个问题：

这些规则、映射、长期记忆到底放在哪里？

最终的做法是：专门维护一个 openclaw_workspace 元仓。

它不是整个工作区的备份仓，而是一个：

长效记忆 + 协作规则 + 项目机制 + 轻量元信息仓

它只同步少量高价值文件，例如：

AGENTS.md
SOUL.md
USER.md
TOOLS.md
MEMORY.md
project-map/

而不会去吞：

代码项目仓
缓存 / 日志 / 索引
运行时状态
.env 等敏感配置
高频噪音型日常流水

这一层其实也很重要。

因为如果没有稳定的持久化载体，项目联动机制最终还是会变回：

这次会话里说过；
下次又靠助手重新猜。

十三、这套方案适合谁，不适合谁

这篇文章对应的方案并不是那种"企业级万能方案"，它更像是一种适合 AI 助手长期协作场景的增强层。

适合

个人开发者
小团队协作
正在让 AI 助手长期参与多个项目推进的人
同时维护"规划文档 + 代码实现"的工作流

不太适合

一上来就要做成组织级项目管理平台的团队
完全没有长期规划层、只有临时问答场景的工作流
极度重型、流程全靠专用管理系统驱动的大型组织场景

换句话说，这更像是一种：

个人 / 小团队 / AI 助手协作增强机制

而不是一个通用企业级项目管理产品方案。

十四、我的结论

如果你也在让 AI 助手长期参与多个项目，我的建议很明确：

不要再把"继续某项目"理解成切换到某个仓库，而应该把它理解成进入一个有规划锚点、执行锚点和联动规则的项目上下文。

真正值得补上的，不是更多 prompt 技巧，而是这层项目级映射机制。

因为只有把这层补上，AI 助手才更像是在参与项目，而不是每次都从头猜上下文。

结语

这次最大的变化，不是多了一个 YAML 文件，也不是多了一篇 README，而是我们把一件过去很依赖"助手有没有记住"的事情，变成了一个有结构、有边界、有落点的机制。

一句话总结这次实践：

从"靠记忆联动"，走向"靠项目映射机制联动"。

如果你也在让 AI 助手深度参与项目推进，我认为这一步，迟早都要补。

如果你觉得这篇文章有价值，我建议你至少带走下面这三点：

不要把"继续某项目"理解成切换到某个仓库。
项目联动的基本单位应该是 Project，而不是 Repository。
先做一个最小可用的项目映射层，再谈更复杂的协作自动化。

对个人开发者、小团队、以及正在让 AI 助手逐步参与项目推进的人来说，这套方法不是最重的，但往往是很值得尽早补上的那一层。

使用：

附：

对话记录：

百度网盘：项目联动机制.docx

当 AI 助手开始管理多个项目：如何把“继续某项目”变成可联动机制