vlm-code-context-mcp

一个完整的 AI 工程团队。一个 npm 包。零上下文浪费。

📖 入门指南 — 新手？从这里开始！

产品负责人。架构师。QA。安全专家。两名开发人员。Scrum Master。经理。首席开发人员。 全部运行真实的冲刺（Sprint）。全部与你的代码库对话。全部都在一个 SQLite 数据库中。

npm install vlm-code-context-mcp
npx code-context-mcp setup .
npx code-context-dashboard ./context.db

为什么存在这个项目

每个 AI 编码工具都会遇到同样的瓶颈：模型在做任何有用的事情之前，就已经耗尽了上下文窗口来阅读你的代码库。然后会话结束，下次又得从头开始。

第二个问题更严重——没有流程。你得到一个能力很强的 AI，但它不知道该构建什么、按什么顺序构建，或者为什么要构建。

vlm-code-context-mcp 解决了这两个问题。它将你的整个项目预先索引到一个结构化的 SQLite 数据库中，以便代理查询元数据而不是原始源代码——在 224 个文件的代码库中，Token 减少了 25 倍，数据量减少了 26 倍。 它将这种智能封装在一个完整的虚拟 Scrum 团队中，通过 81 个 MCP 工具运行真实的冲刺仪式，包括阶段门禁、回顾、速率跟踪和一个实时的 React 仪表板。

这不是一个附加了 Claude 的任务跟踪器。它是 AI 驱动开发的操作系统。

60 秒内你能得到什么

Step 1/4 — Indexing files into context.db...
  Indexed 25 files, 142 exports, 87 dependencies

Step 2/4 — Loading scrum schema...
  Created 10 scrum tables

Step 3/4 — Importing team from .claude/agents/...
  Loaded 9 agents, 3 sprints, 24 tickets

Step 4/4 — Writing .mcp.json...
  Configured MCP server entry

=== Setup complete! (my-project) ===

然后打开仪表板：

npx code-context-dashboard ./context.db
# Opens at http://localhost:3333

就是这样。 你的 AI 团队准备就绪。无需 API 密钥。无需外部服务。无需云依赖。一切都存在于 context.db 中。

团队成员

每个代理都有明确的角色、系统提示词、针对其职责范围的工具访问权限，以及根据工单负载和回顾情绪得出的心情评分。系统会跟踪跨冲刺的倦怠信号。

冲刺流程

冲刺通过 10 个强制阶段运行，并带有自动门禁检查：

preparation → kickoff → planning → implementation → qa → refactoring → retro → review → closed → rest

门禁是真实的。在工单被分配和估算之前，冲刺不会进入 QA 阶段。在记录回顾结果之前，冲刺不会关闭。速率会在每个冲刺中自动跟踪，并显示在仪表板中。

仪表板

6 个页面。68 个组件。实时 SSE 更新。

每一次变更——工单状态更改、代理心情更新、冲刺阶段转换——都会通过 SQLite WAL 监控触发即时的仪表板刷新。无需轮询。无需手动刷新。

• 冲刺看板 — 看板、计划视图、QA 门禁跟踪器、燃尽图

• 代码浏览器 — 文件树、依赖图、导出/导入映射、变更历史

• 项目管理 — 甘特图时间轴、里程碑跟踪器、发现管道、愿景编辑器

• 团队 — 代理健康卡、心情趋势、工作负载分配

• 回顾 — 按类别分类的发现、跨冲刺模式分析、行动跟踪

• 市场营销 — 发行说明、定位、Remotion 愿景动画

📸 [此处截图]
📸 [此处截图]

桥接层

代理工具中最困难的问题是双向通信——让 UI 和 AI 真正实时地相互对话。

src/bridge/ 实现了一个 PreToolUse 钩子，将 Claude Code 连接到仪表板。UI 中排队的动作由正在运行的 Claude Code 会话处理。这就是让团队感觉像活的一样，而不是像一个静态看板的原因。

这部分仍在加固中。欢迎提交 PR。

上下文效率

基于本项目自身的代码库（224 个文件，54K 行，2.1 MB）测量：

方法论：“理解并修改功能”任务——定位相关文件，理解导出/导入/依赖项，审查最近的变更。不使用 MCP 时，代理读取约 20 个原始文件（平均每个 9,200 字符）。使用 MCP 时，它通过 search_files、find_symbol 和 get_file_context 查询结构化元数据——摘要、导出列表和依赖图，而不是原始源代码。

首次索引成本较高——必须读取文件以生成元数据。随后的每次查询成本降低 25 倍。使用一次后即可回本。节省的成本随代码库大小而扩展：25 个文件的项目减少 3 倍，这个 224 个文件的项目减少 25 倍。

一览表

项目历史

完全通过其自身的 Scrum 流程构建。虚拟团队已完成 22 个里程碑、69 个高效冲刺 和 211 个工单，总计 534 个故事点，滚动速率约为每冲刺 20 点。

19 个冲刺的回顾发现

做得好的地方（主要模式）：

• 发现优先的方法始终消除了浪费的实现。在编写代码之前对 3-4 种方法进行探究（Spiking）节省了数天的返工时间（S59, S65, S68）。

• 并行代理执行显著缩短了实现时间。4 个代理同时处理独立工单，同时由主线程进行协调（S59, S65, S67）。

• 先研究后编码尽早发现了死胡同。S68 在几小时内而不是几天内排除了 3 种候选桥接方法（命名管道、Unix 套接字、MCP 资源订阅）。

• 模式迁移模式（schema_versions 表）使增量数据库变更变得安全且可重复。在 7 次模式添加中实现了零回归（S53, S55）。

• 并行安全审计在任何代码发布前捕获了 2 个高危发现（S68）。与实现同步运行审计，而不是事后运行，是正确的模式。

做得不好的地方（主要模式）：

• 测试在未运行的情况下被标记为完成。 代理编写了测试但无法执行它们——在标记为完成之前必须进行构建验证（S61, S65, S66）。

• 预先存在的测试失败产生了干扰，掩盖了真正的回归。旧模式变更导致的陈旧测试不断出现（S53, S67, S68）。

• 发现速率具有误导性。 S56 提交了 46 个故事点，但所有工单仅为文档。发现点应与实现点分开跟踪。

• 通用的工单标题且没有描述或验收标准，使得 QA 变得不可能。每个工单都需要具体的范围（S53）。

• 前端技术债务积累——800+ 行代码的组件，850+ 行内联样式，零测试。应该更早解决这个问题（S59）。

下次尝试（主要行动项）：

• 在每个代理完成后、标记工单完成前运行 npm run build（S65, S66, S67）。

• 在创建时为每个工单添加验收标准（S55）。

• 在创建修复工单前验证当前状态——有些工单已经解决了（S58）。

• 每个新的 write-MCP-tool 都必须触发 SSE 通知——添加为检查清单项（S53）。

• 在 API 稳定后，为真正的基于推送的桥接信号实现通道（S68）。

• 将发现点与实现速率分开跟踪（S56）。