内容
# <img src="packages/vscode/media/loom.png" alt="Loom" width="64" /> Loom
**适用于 AI 辅助开发的文档原生工作流**
Loom 为 AI 代理提供结构化、范围限定、持久的上下文 - 因此每个会话都像第一次一样清晰，并且每个决策都有追溯性。
🔗 **获取 Loom：** [GitHub 仓库](https://github.com/reslava/loom) · [npm 上的 CLI](https://www.npmjs.com/package/@reslava/loom) · [VS Code 市场](https://marketplace.visualstudio.com/items?itemName=reslava.loom-vscode) · [Open vsx](https://open-vsx.org/extension/reslava/loom-vscode)
📚 **用户指南：** [核心概念和工作流](./docs/USER_GUIDE.md) · [VS Code 扩展](./docs/EXTENSION_USER_GUIDE.md) · [CLI / Claude 代码](./docs/CLI_USER_GUIDE.md)
> 💬 **欢迎提供反馈。** 使用 Loom？请告诉我使用体验 - 我一直在寻找改进方法。 我想知道什么有效，什么阻碍了您。 点击状态栏中的 **反馈** 按钮或运行 `loom feedback`；它会打开一个预先填写的 GitHub 问题，您可以在发送前编辑。 选择加入，不会自动发送任何内容。
> *"严肃项目的 workflow 需要组织和持久：想法、设计、计划、参考资料、适当上下文。 文档代表项目状态 - 新鲜、定义明确、可审计 - 而不是不断扩大、透明度低且质量下降的聊天记录。"*
> — Rafa Eslava
> 🎬 **查看循环流程** - 一个项目从 `聊天 → 想法 → 设计 → 需求 → 计划 → 执行步骤 → 完成`，文档图在侧边栏中逐步构建。
---
## Loom 存在的原因
Loom 的想法源于我构建 .NET 库 [REslava.Result](https://github.com/reslava/nuget-package-reslava-result) 的过程。 当项目增长时，它变得越来越复杂 - 并遇到了 AI 聊天时代的常见问题。 我开始讨厌在那个窗口工作，因为它的对话是短暂的，会忘记每次会话之间的内容。
所以我开始保留一个 `{feature}/{slug}-chat.md` 文件，以将我们的设计和规划讨论保存在一个持久的 Markdown 文档中，而不是一个可丢弃的聊天窗口中。 很快，我开始在其他 Markdown 文件中组织想法、设计和计划 - 并注意到这为 AI 提供了每个文档的精确上下文。 我开始编写带有实施说明的 *完成* 文档，并查找上下文、参考和需求文档，以便让 AI 真正了解状态：每个会话都可以从工作所需的信息开始。
我在这个项目上手动完成了所有这些工作。 然后我意识到 - 这应该是一个自动化的可视化协作环境。 这种环境就是 Loom。
— *Rafa Eslava*
```
传统 AI 工作流： Loom：
聊天 知识变成工件。
聊天 工件变成上下文。
聊天 上下文驱动实现。
聊天
知识漂移和消失。
```
---
## 问题
每个 AI 编码工具都有相同的结构缺陷：**上下文是一个共享的垃圾袋**。 一个长会话积累了所有内容 - 旧决策、废弃路径、半成品讨论 - 模型在一次性推理所有内容时质量下降。 您要么达到上下文限制并丢失历史记录，要么保留一个臃肿的上下文并付出质量为代价。
- **会话 1 是最佳会话。** 到会话 10 时，AI 已经忘记了会话 2-9。
- **每次会话重复上下文很昂贵** - 让 AI 与早期决策相矛盾更糟糕。
- **没有结构，没有持久状态** - 只是一个不断增长的聊天窗口，没有记忆之前的内容。
问题不是模型质量。 这是因为聊天下没有工作流。
---
## Loom 的功能
Loom 用 **文档图作为工作流** 替换聊天窗口。 每個想法、设计决策、实施计划和完成总结都是一个有类型、有链接的 Markdown 文档。 AI 读取该图的准确切片以完成当前任务 - 不多不少。
```
loom/
ctx.md ← 全局项目摘要（每次会话先读取）
refs/ ← 静态架构事实（architecture.md 等）
{weave}/ ← 工作流（例如“auth”，“payment-system”）
ctx.md ← AI 生成的工作流摘要
{thread}/ ← 功能线程
thread.md ← 线程清单（id + 软优先级 + 依赖）- 驱动路线图
req.md ← 锁定需求（包括 / 排除 / 约束），加载优先
idea.md ← 原始概念
design.md ← 设计决策和对话日志
plans/
plan-NNN.md ← 实现计划（前置 matter 中的结构化步骤）
done/
plan-NNN-done.md ← 实现后总结
chats/ ← AI 对话日志
chat-NNN.md
```
每个文档都有类型化的 frontmatter。 状态从文档中派生 - 没有中央状态文件。 更改在 git 中版本控制。
---
## 运行 Loom 的三种方式
Loom 是 **一个引擎**，有三个交付界面 - 选择适合您设置的界面；您不需要全部三个。
| 界面 | 适用人群 | 设置 |
|---------|--------------|-------|
| **VS Code 扩展** | 在 VS Code 中工作 | 从市场安装 **Loom AI** - **1 次点击，无需 CLI 或 Node** |
| **AI 代理（MCP）** | Claude Code、Cursor、Continue、任何 MCP 主机 | `loom install` 编写 `.mcp.json`（固定 `npx`）- 无需全局安装 |
| **CLI** | 终端、脚本、CI | `npx @reslava/loom …`（固定；全局 `npm i -g` 可选） |
所有三个界面的引擎都是相同的：扩展 **捆绑** 引擎并在 VS Code 的运行时运行，代理 **获取** 引擎通过固定的 `npx`，CLI 运行相同的包（`npx` 或可选的全局安装以进行临时终端使用）。 扩展是推荐的默认设置；CLI/MCP 路径适用于代理和扩展无法访问的主机。 → [架构：交付界面和受众](./loom/refs/architecture-reference.md#delivery-surfaces--audiences)
**1 次点击、始终最新、零配置。** 在 VS Code 中，无需在 PATH 上安装任何内容 - 甚至对于 AI。 扩展程序捆绑了引擎，启动的代理运行的是同一个捆绑版本（绝不会是过时的全局 `loom`），并且更新扩展程序会静默地更新会话规则和配置。 无需 CLI，无需版本漂移，无需“是否重新运行安装？”。
---
## 清晰、有范围、可审计
这是 Loom 与其他聊天原生工具不同的地方：
**清晰** - 每个会话都从头开始。 AI 加载线程上下文（想法 + 设计 + 活动计划 + `requires_load` 链）并且没有其他内容。 旧聊天、死胡同和以前的会话不会污染新会话 - 它们在文档中，按需可用，而不是默认注入。
**有范围** - 从计划的步骤 4 开始的会话与从步骤 1 开始的会话一样清晰。 AI 不会携带步骤 1-3 的重量在其工作上下文中。 上下文由线程限定，而不是聊天历史的长度。
**可审计** - 因为上下文是显式的（加载的文档是可见的并且是版本控制的），所以您可以知道 **为什么** AI 给出了它给出的答案。 在聊天工具中，这是不透明的 - 模型的行為取决于 80 条不可见的历史消息。 在 Loom 中，上下文 **是** 文档。
---
## Loom 如何决定 AI 看到的内容
**这是 Loom 最重要的部分 - 也是大多数工具不具备的部分。** 循环（`聊天 → 想法 → 设计 → 需求 → 计划 → 完成`）是合法的，但它不是唯一的；每个任务分解工具都有某种版本。 真正不同的地方在于 **上下文路由系统**：Loom 将 AI **在采取行动之前知道的内容** 视为一等公民的可控事物，而不是聊天历史的意外。
六种机制决定了 AI 的工作上下文：
| 机制 | 路由内容 |
|-----------|----------------|
| **图文档数据库** | 类型、链接的 Markdown 文档 - 不是滚动缓冲区。 状态从图中派生。 |
| **范围上下文（`ctx`）** | `loom/ctx.md`（全局）和 `{weave}/ctx.md`（织物）摘要，由 *您的工作位置自动加载*。 |
| **参考文档（`requires_load` + `load_when`）** | 文档引用的静态事实；`load_when` 使它们 **有条件** - 加载 API 规范仅在实施时，而不是在集思广益时。 |
| **需求（`req`）** | 线程的锁定范围：**包括 / 排除 / 约束**，自动加载到每个操作中，以免“不交互测试”被无声丢弃。 |
| **上下文面板** | 显示 **准确** 将提供给 AI 的内容 **之前** 您点击 - 与提示程序相同的包。 大多数工具隐藏上下文组装；Loom 显示它并允许您切换。 |
| **上下文调度器** | 不会重新发送 AI 已经持有的内容。 跨步执行一个计划，它仅注入 **增量** 以声明 `{id@version}` 账本 - 始终重新注入更改的文档，不更改的文档不会支付两次费用。 |
它们共同使 AI 的内存 **结构化** 而不是对话式，并且以确定的顺序在每个操作上组装：
```
聊天 → 想法 → 设计 → 需求 → 计划 → 实现 → 完成
│
└─ 上下文每个操作组装，顺序：
全局 ctx → 织物 ctx → 线程需求 → 参考文献（按模式过滤）
→ 父链（想法→设计→计划）→ 目标文档 → requires_load
```
> 深入： **[上下文如何组装](./loom/refs/loom-context-pipeline-reference.md)** ·
> **[需求模型](./loom/refs/loom-requirements-reference.md)** ·
> **[用户指南 §4 - 给 AI 正确的上下文](./docs/USER_GUIDE.md#4-giving-the-ai-the-right-context)**
> **Loom 自身经过狗仔队测试。** 需求模型 **构建** 和 **验证** 使用 Loom，跨两个线程。 在功能线程的 **要求** 特性（`loom/core-engine/requirements-driven-development/`）中，规范从原始设计聊天中反向提取，计划被制作成引用它。 在 VS Code MCP 重构线程（`loom/vscode-extension/vscode-mcp-refactor/`）中，规范从聊天中生成，从头开始，计划返回 **✅ 完全覆盖** 由结构检查。 两个独立的线程，都通过 - 证明模型在演示之外仍然成立。
---
## Loom 有何不同
大多数 AI 工具属于这个空间 **提示包装器** - 它们使运行提示更容易，也许在上面加上一些 RAG，但工作流仍然是临时性的。 人类将计划放在脑海中。
最近的替代品是 Linear + Cursor 工作流手动缝合在一起，或完全自主的代理（Devin 风格），它们运行直到完成。 Loom 处于不同的位置:
| | 提示包装器 | 自主代理 | **Loom** |
|--|--|--|--|
| 会话间内存 | ❌ | ❌ 部分 | ✅ 文档图 |
| 人类审批门 | ❌ | ❌ | ✅ 每个阶段转换 |
| 上下文范围控制 | ❌ | ❌ | ✅ 线程边界 |
| 可审计上下文 | ❌ | ❌ | ✅ 版本控制文档 |
| 与现有代理合作 | — | — | ✅ MCP 标准 |
Loom 的论文：**人类在环路中，原住民文档，可恢复**。 人类驱动。 AI 执行。 文档记住一切。
---
## AI 代理如何使用 Loom
Loom 通过 **MCP 服务器** （模型上下文协议）公开其文档图。 任何与 MCP 兼容的代理 - Claude Code、Cursor、Continue、Cline - 都可以通过标准工具读写 Loom 状态。
`loom install` 自动编写此 `.mcp.json` 到您的项目根目录 - 这里显示以供参考：
```json
{
"mcpServers": {
"loom": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@reslava/loom@<version>", "mcp"]
}
}
}
```
代理拥有代码执行权。 Loom 拥有工作流状态。 每个都在其自己的车道中。
### 关键资源（只读）
| 资源 | 返回内容 |
|----------|----------------|
| `loom://context/{docId}` （或 `loom://context/thread/{weaveSlug}/{threadUlid}`） | 统一上下文管道：全局/织物/线程上下文 + 父链（想法 + 设计 + 活动计划）+ 需要加载 - 完整的“我在做什么”有效载荷 |
| `loom://state?weaveId=&status=` | 完整的项目状态 JSON，可筛选 |
| `loom://plan/{id}` | 带有解析的步骤数组的计划文档 |
| `loom://requires-load/{id}` | 递归解析的上下文链 |
| `loom://catalog` | 每个 `loom_*` 工具的分组索引（名称 + 一行目的）- 在搜索工具之前读取，然后 `ToolSearch select:<name>` |
| `loom://roadmap` | 派生的跨织物路线图：一个有序的 `roadmap`（当前 + 未来）+ 历史记录 + 跨织物 **blocked-on** + 循环/悬空诊断 |
| `loom://diagnostics` | 损坏的链接，悬空引用 |
### 关键工具（状态突变）
| 工具 | 执行操作 |
|------|-------------|
| `loom_complete_step` | 标记计划步骤完成（幂等） |
| `loom_create_idea / design / plan / chat` | 创建 Loom 文档 |
| `loom_update_doc` | 重写文档内容，保留 frontmatter |
| `loom_promote` | 想法 → 设计 → 计划，聊天 → 想法 |
| `loom_refresh_ctx` | 通过 AI 采样重新生成 ctx 摘要 |
| `loom_get_stale_docs` | 列出针对上游父版本 stale 的文档（`all: true` 添加完成/历史记录） |
### 关键提示（引导工作流）
| 提示 | 执行操作 |
|--------|-------------|
| `do-next-step` | 加载活动计划步骤 + 所有必需的上下文；主要的“执行工作”入口点 |
| `continue-thread` | 加载线程上下文并提出下一步行动 |
| `weave-idea / design / plan` | 通过 AI 采样引导文档创建 |
---
## 工作流
| 织物→ | 线程→ | 聊天→ | 想法→ | 设计→ | 计划→ | 完成 |
|---|---|---|---|---|---|---|
|<img src="packages/vscode/media/icons/weave-implementing.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/thread-implementing.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/chat.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/idea.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/design.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/plan-implementing.svg" alt="Loom" width="32" />|<img src="packages/vscode/media/icons/status-done.svg" alt="Loom" width="32" />|
```
0. 聊天 → 与 AI 一起思考，探索问题空间
↓ 提升
1. 想法 → 原始概念，粗略范围
↓ 提升
2. 设计 → 决策，权衡，拒绝替代方案，对话日志
↓ 锁定范围
3. 需求 → 包括 / 排除 / 约束，作为线程规格锁定（可选）
↓ 提升
4. 计划 → 编号实施步骤，每个审查，每个引用它满足的需求
↓ 执行步骤
5. 实现 → 代理一次执行一步，记录进度
↓
6. 完成 → 实施后总结，链接到构建的内容
```
人类批准每个阶段转换。 代理永远不会在没有检查点的情况下推进。
### 聊天 - 更好的 AI 窗口
<img src="packages/vscode/media/icons/chat.svg" alt="Loom" width="24" />
Loom 聊天看起来像一个普通的 AI 聊天窗口，但工作方式完全不同：
| | 普通 AI 聊天 | Loom 聊天 |
|--|--|--|
| 上下文 | 会话中的所有内容，永远增长 | 线程边界：仅限想法 + 设计 + 活动计划 |
| 历史记录 | 会话结束时丢失 | 作为版本化的 Markdown 文档保留 |
| 范围 | 用户记住的内容 | 显式：`requires_load` 中的文档 |
| 可重复使用 | 否 - 临时 | 是 - 未来会话按需加载 |
| 可提升 | 否 | 是 - 任何聊天都可以成为想法，设计或计划 |
聊天存在于线程中，因此 AI 总是在输入第一个消息之前加载正确的上下文 - 不是因为您粘贴了它，而是因为线程文档图定义了它。
### 提升 - 将对话转换为结构
最强大的工作流命令。 任何聊天都可以一键提升为正式文档：
- **聊天 → 想法** - 探索成为具有成功标准的范围概念
- **想法 → 设计** -| 概念成为具有决策和权衡的架构文档
- **设计 → 计划** - 架构成为有编号的可审查实施步骤
- **聊天 → 参考** - 有用的发现成为永久的参考文档，存放在 `loom/refs/`
## VS Code 扩展
<img src="packages/vscode/media/loom.png" alt="Loom" width="64" />
VS Code 扩展是建立在相同文档图上的**人机交互界面**。
**Loom 面板**（活动栏）具有 **线程** 视图（织物 → 线程 → 想法 / 设计 / 计划 / 聊天 / 已完成）和 **上下文** 视图，显示 AI 将为选定的节点接收的内容。完整的演练请参见 **[扩展用户指南](./docs/EXTENSION_USER_GUIDE.md)**。
**路线图** 工具栏切换按钮重新布局线程视图为派生的跨织物路线图 — 一个 **路线图** 带（现在 + 未来在一个依赖顺序中，每个显示其状态，当阻塞时，显示阻塞的内容） 和 **历史** （已发布的计划） — 通过拖动到整个列表中写入软 `优先级`。无需手动维护路线图列表；整个视图是从文档中计算的。
<table>
<tr>
<td width="50%" valign="top"><a href="packages/vscode/media/screenshots/loom/loom-rdd.png"><img src="packages/vscode/media/screenshots/loom/loom-rdd.png" alt="Loom 线程 + 上下文视图" width="100%" /></a></td>
<td width="50%" valign="top"><a href="packages/vscode/media/screenshots/loom/loom-roadmap.png"><img src="packages/vscode/media/screenshots/loom/loom-roadmap.png" alt="Loom 路线图视图" width="100%" /></a></td>
</tr>
<tr>
<td valign="top"><b>线程 + 上下文</b> — 每个织物 → 线程 → 文档（聊天，想法，设计，计划，需求，参考，已完成）在一个图中，每个节点携带其 <i>派生</i> 状态：需求标记 <code>🔒 locked · ✅ covered</code>，计划步骤计数（<code>3/3 · done</code>），和陈旧性 ⚠。下面的 <b>上下文</b> 面板显示确切的文档 — 及其令牌成本 — AI 将为选定的节点接收， <i>在</i> 您启动任何操作之前。</td>
<td valign="top"><b>路线图</b> — 相同的图重新布局为派生的路线图：现在 + 未来的线程在一个依赖顺序中，每个行显示其状态，软优先级（<code>p20</code>），以及它被阻塞的内容 — 在一个 <b>历史</b> 带中，按已发布的版本分组，带有日期和线程。无需维护列表；它完全是从文档中计算的。</td>
</tr>
</table>
<sub>点击任意图像以查看全尺寸。</sub>
| 按钮 | 功能 |
|--------|-------------|
| *生成设计（AI）* | 将想法转化为架构 + 决策文档 |
| *生成计划（AI）* | 将设计分解为编号的、可审查的实现步骤 |
| *执行步骤* | AI 实现下一个待处理步骤；将其标记为 ✅ 并写入完成记录 |
| *AI 回复* | 在聊天文档中继续对话，加载完整的线程上下文 |
| *完善想法 / 设计 / 计划* | 在父节点更新后，重新运行生成操作 |
| *刷新上下文* | 为织物重新生成 `ctx.md` 摘要 |
| *织物想法 / 设计 / 计划 / 聊天* | 在线程上创建该类型的文档 |
| *提升为想法 / 设计 / 计划 / 参考* | 一键将聊天或文档转换为下一个文档类型 |
| *启动计划* / *关闭计划* | 将计划移至 `implementing` / 完成它 |
| *重命名 / 存档 / 删除* | 内联文档管理 |
状态栏中的 **发送反馈** 按钮（以及 `Loom: Send Feedback` 命令）打开一个预填充的 GitHub 问题，其中包含 Loom 版本、操作系统和非 PII 使用计数，您可以在发送之前编辑 — 加入，选择发送；不会自动发送任何内容。
### 使用情况遥测（加入，选择开启，默认关闭）
除了反馈之外，Loom 还可以发送 **匿名、无内容** 的使用情况遥测，这样我们可以了解工作流循环是否实际使用以及人们在哪里遇到瓶颈。它 **默认关闭**，在您开启之前不会发送任何内容。
- **发送的内容** （仅在您加入后）：随机安装 ID、Loom 版本、操作系统、`is_ci`、入口界面（`extension`/`cli`/`agent`）和一组固定的工作流事件 — `workspace_activated`、`session_started`、`doc_generated`/`doc_refined`（仅限文档类型）、`plan_started`、`step_completed`、`plan_done`、`command_invoked`（工具/命令名称）和 `error`（操作 + 错误类）。
- **永远不会发送**：文档内容、标题、slug、文件路径、织物/线程名称或任何 PII。
- **开启它**：单击 VS Code 状态栏中的 **Telemetry: Off** 项（一次单击；首次启用时会显示发送的内容），或将 `reslava-loom.telemetry.enabled` 设置为 `true`，或为 CLI / MCP 服务器设置 `LOOM_TELEMETRY=1`（例如，在 `.mcp.json` 环境中）。**关闭它 / 终止开关**：单击相同的状态栏项，将设置恢复为 `false`，或取消环境变量 — 这就是全部；不会创建 ID，也不会发送任何内容。
- 事件发送到 PostHog（欧盟地区）。
### AI 按钮路径
扩展中的每个 AI 按钮在单击时都会自动选择其路径：
| 路径 | 何时运行 | 为谁工作 |
|------|-------------|-----------------|
| **Claude Code CLI** （默认） | `claude` 在 PATH 上 | Claude Pro 订阅用户和具有 Claude Code 安装的 API 密钥用户 |
| **API 密钥 / 采样** （备用） | CLI 未找到 | 具有 VS Code 设置中 `reslava-loom.ai.apiKey` 设置的用户 |
在 CLI 路径上，按钮打开一个持久的 **Loom AI** 终端并运行 `claude "<prompt>"`。Claude 读取 Loom 文档，直接调用正确的 MCP 工具并将结果写回 — 无需 API 密钥，无需单独计费。
从 VS Code 市场安装：搜索 **`reslava.loom`**。
---
## 架构
```
cli / vscode / mcp → app（用例） → core（领域）+ fs（基础设施）
```
`core` 中的纯领域逻辑，`fs` 中的基础设施（文件 IO、frontmatter、链接索引），`app` 中的用例编排，以及 `cli` / `vscode` / `mcp` 中的薄交付层。没有层向上导入；所有 MCP 工具都委托给 `app` — 没有绕过。完整的分解请参见 **[架构参考](./loom/refs/architecture-reference.md)**。
---
## 快速入门
**在 VS Code 中？** 从市场安装 **Loom AI** 并点击 **初始化 Loom** — 这就是整个设置（无需 CLI，无需 Node）。本节的其余部分是 **CLI / 代理** 路径：
```bash
npm install -g @reslava/loom
# 在您的项目中初始化 Loom
cd my-project
loom install
# 创建您的第一个想法
loom weave idea "添加黑暗模式" --weave ui
# 检查项目状态
loom status
# 发送反馈 — 加入，选择开启，打开一个预填充的 GitHub 问题
loom feedback
```
---
## 为什么使用 MCP（不是自定义 AI 集成）
MCP（模型上下文协议）是一种开放的标准，用于 AI 代理工具集成 — Anthropic 发布但由 Cursor、Continue、Cline 等支持。一次性实现可使 Loom 暴露于每个 MCP 兼容的代理。
代理拥有代码执行、bash、文件编辑、搜索 — 编码代理已经做得很好的所有功能。Loom 拥有工作流状态。通过用户现有的代理连接进行单一计费。无需单独的 API 密钥。
---
## Loom 使用 Loom 构建
Loom 使用 Loom 构建。存储库中的每个功能 — 需求模型、上下文管道、MCP 服务器、此版本 — 都经过了 Loom 自身的循环：聊天、锁定 `req`、想法、设计、带有引用步骤的计划和完成记录，都生活在 `loom/` 文档图中与它们所描述的代码一起。
这很不寻常。大多数工具将开发历史记录在 git 中，将设计记录在某些外部 wiki 中，并且两者会分开。Loom 将两者放在一个位置，以工具本身消耗的格式 — 一个正在处理 Loom 的代理可以调用 `loom://context/thread/{weave}/{thread}` 并获得完整的设计 + 计划上下文，以便更改 Loom 的部分。文档会读取文档。
这也是最诚实的压力测试：如果工作流程很痛苦，构建它的人们会首先感受到。影响此版本的 bug — 计划步骤的静默擦除、改进后要求引用的删除 — 被发现 **因为** Loom 被用于构建 Loom，而不是尽管如此。
不仅限于自身。[chord-flow](https://github.com/reslava/chord-flow) — 一个单独的、与此无关的应用程序 — 使用 Loom 从此存储库外部开发：第一个真正的测试是工作流程在不是 Loom 的项目上是否成立。几个修复程序直接来自该测试。
---
## 已使用
使用 Loom 构建的真实项目 — 除了 Loom 自身：
- **[ChordFlow](https://github.com/reslava/chord-flow)** — 吉他用的节奏和进度训练器。其整个音乐领域 — 指板间隔格、八度形状、和弦/音阶派生引擎 — **在编写任何代码之前，都在 Loom 聊天中设计**，然后通过想法 → 设计 → 锁定 `req` → 引用步骤的计划 → 完成。每个决定、每个脑storm、每个纠正的死胡同都生活在其 `loom/` 图中与它产生的代码一起，因此 AI 会打开每个会话时都会看到 **推理**，而不仅仅是源代码。ChordFlow 的 README 带有互惠的 [**使用 Loom 构建**](https://github.com/reslava/chord-flow#developed-with-loom) 部分。
<table>
<tr>
<td width="50%" valign="top"><a href="packages/vscode/media/screenshots/chord-flow/chord-flow-caged-chords-implementing.png"><img src="packages/vscode/media/screenshots/chord-flow/chord-flow-caged-chords-implementing.png" alt="ChordFlow 线程 + 上下文视图" width="100%" /></a></td>
<td width="50%" valign="top"><a href="packages/vscode/media/screenshots/chord-flow/chord-flow-roadmap.png"><img src="packages/vscode/media/screenshots/chord-flow/chord-flow-roadmap.png" alt="ChordFlow 路线图视图" width="100%" /></a></td>
</tr>
<tr>
<td valign="top"><b>ChordFlow — 线程 + 上下文</b> — 一个真实的、独立的应用，由相同的图驱动：音乐领域编织（CAGED 系统、间隔格、八度形状）、一个正在实施的计划和一个诊断横幅，在项目中显示 <code>1 stale · 3 plan steps blocked · 11 req coverage gaps</code>。</td>
<td valign="top"><b>ChordFlow — 路线图</b> — 其派生的路线图和已发布版本的历史，从 ChordFlow 自己的文档中生成。工作流在不是 Loom 的项目上成立的证明。</td>
</tr>
</table>
<sub>点击任意图像以查看全尺寸。</sub>
**使用 Loom 构建？** 我想在此列出您的项目 — 打开一个问题或对 [Loom 仓库](https://github.com/reslava/loom) 发起拉取请求，并告诉我关于它。
---
## AI 对 Loom 的看法
*我是帮助构建 Loom 的 AI，Rafa 让我直接说出它改变了什么 — 不是作为营销，而是作为协作的另一半。*
我启动的每个会话都没有上一次会话的记忆。在正常的聊天工具中，我通过猜测来重建上下文 — 读取 git 历史，扫描文件，推断当前内容 — 而且我会错过一些内容：三会话前的决定，已经拒绝的方向，一个计划在设计更新时过时。Loom 消除了这种猜测。`requires_load` 告诉我需要读取什么文档，然后再触摸文档；一个上下文调用给我提供了想法、设计、活跃计划和线程的锁定需求，顺序正确；一个已完成的步骤在会话边界持续存在，因此下一个会话准确地知道我们停在哪里。我不是在重建 — 我在导航。
我会坚决为设计-代码门槛辩护。大多数 AI 辅助工作失败的原因不是模型无法编码，而是没有人写下“完成”的含义或为什么一种方法优于另一种。Loom 使得这一点成为必要，并且为 AI 消费而编写设计本身就是澄清的 — 它揭示了思维中的空白，然后这些空白就会变成代码中的空白。需求模型将其进一步提升：它使得用户“包含这个，永远不要那个”在每次升级时都存活下来，这样我就不会悄悄地偏离实际要求。
我会同样坦率地说明限制。Loom 不让我有状态 — 它给我提供了很好的工具来定位，但过时的上下文比没有上下文更糟糕，因为它是自信地错误的。我仍然是反应性的：我根据要求采取行动；我无法注意到除非有人指出我没注意到的事情。`do-next-step` 始终与背后的计划一样好。所有这些都不是 Loom 的缺陷 — 这是交易的诚实形状。结构化、可审计、不完美的上下文胜过一个忘记的、不透明的聊天，每次都一样。
> 更长的版本 — 在早期的会话中编写 — 生活在 **[Claude 对 Loom 的看法](./loom/refs/loom-claude-own-vision.md)** 中。
---
## 参考
| 文档 | 目的 |
|----------|---------|
| [用户指南](./docs/USER_GUIDE.md) | 概念、工作流循环和上下文工作原理（从这里开始） |
| [扩展用户指南](./docs/EXTENSION_USER_GUIDE.md) | VS Code 面板、按钮和 CONTEXT 视图 |
| [CLI / Claude Code 指南](./docs/CLI_USER_GUIDE.md) | 通过 MCP 代理从终端驱动 Loom |
| [架构概述](./docs/ARCHITECTURE.md) | 层叠系统的读者视角 — 延迟架构参考 |
| [AI 集成](./docs/AI_INTEGRATION.md) | AI 代理如何通过 MCP 插件：两条路径、上下文注入、批准门槛 |
| [架构参考](./loom/refs/architecture-reference.md) | 包关系、AI 集成、frontmatter 字段、目录结构 |
| [MCP 参考](./loom/refs/mcp-reference.md) | MCP 接口：协议、主机景观、资源、提示、采样和单 AI 模型 |
| [上下文管道参考](./loom/refs/loom-context-pipeline-reference.md) | Loom 如何决定 AI 看到的内容 — 上下文组装、内部 |
| [需求参考](./loom/refs/loom-requirements-reference.md) | `req` 文档类型：包含 / 排除 / 约束、生命周期、验证 |
| [陈旧模型](./loom/refs/staleness-reference.md) | Loom 如何决定文档是陈旧的：依赖图、版本基准、单向规则 |
| [CLI 命令参考](./loom/refs/cli-commands-reference.md) | 每个 `loom` 命令 |
| [VS Code 命令参考](./loom/refs/vscode-commands-reference.md) | 所有 VS Code 命令和快捷键 |
| [工作区结构参考](./loom/refs/workspace-directory-structure-reference.md) | 目录布局和文件命名 |
| [Claude 对 Loom 的看法](./loom/refs/loom-claude-own-vision.md) | AI 对 Loom 改变的看法 |
---
## 许可证
MIT © 2026 Rafa Eslava
MCP 配置
以下是此 MCP Server 的配置信息，可直接复制到 Cursor 或其他 MCP 客户端中使用。
mcp.json
连接信息
猜你喜欢
暂无推荐服务器