企业官网建设流程全解析

MEX 是一款开源的"团队记忆"工具，面向工程师与他们的 AI 编程助手：它把团队的架构解释、技术决策、需求规格与任务交接沉淀为结构化的 Markdown，存放在 Git 仓库中，通过普通的 commit / push / pull 在队友与各自的 AI 助手之间共享。一句话概括它的核心思想——让原本承担代码协作的 Git，升级为 AI 助手共享记忆的中枢。

为什么团队和 AI 助手都需要"共享记忆"

用过 Claude Code、Codex 这类 AI 编程助手的人都有体会：

• 👤 一位工程师知道某个约束为什么存在，另一位工程师掌握着调试历史；
• 🤖 AI 助手在一次会话里发现了关键边界条件，但会话结束，这些认知就无人可读；
• 📉 下一位接手者（或下一个 AI 会话）只能从零开始"重新熟悉项目"。

MEX 要解决的正是这个问题：一位工程师和它的 Agent 学到的东西，应该变成下一位队友可以直接使用的上下文。

核心思想：Git 是共享记忆的中枢

MEX 最巧妙的设计，是把"要共享的记忆"与"检索记忆的工具"严格分开：

• 规范文件（Canonical Markdown）：带元数据、来源与代码锚点的结构化 Markdown，放在仓库的.mex/目录里，靠 Git 分发——就像代码一样走 commit、push、pull；
• 可重建的本地索引：Code Graph（代码图）和 Wiki 搜索索引都是本地 SQLite 视图，每人各建各的，可随时重建，永远不提交。

这意味着：没有 MEX 云服务、不需要 Docker、不需要账号——Git 本身就是记忆的分发层。仓库中 src/graph/ 与 src/wiki/ 分别实现了这两套本地索引。

图解架构：三层结构如何协同

整个系统可以看作三层：

1. 第一层 · 规范记忆层：结构化 Markdown 是唯一的共享事实源，人可读、可评审、可 diff；
2. 第二层 · 本地索引层：
   • Code Graph用内置的 Tree-sitter 语法把源码符号与关系映射进本地 SQLite，支持 TypeScript、Python、Rust 等语言（支持矩阵见 docs/code-graph-support.md）；
   • Wiki 索引为知识文档提供全文检索；
3. 第三层 · 访问入口层：人通过浏览器里的Project Hub探索与评审；AI 助手通过 CLI 和 templates/AGENTS.md、templates/ROUTER.md 注入的项目指令来检索与贡献。

Grounding（知识锚定）是两层之间的桥：一条 Wiki 声明可以指向确定性的代码节点。当代码变动后，锚点会标记为漂移（drift），提醒"这条解释需要复核"——漂移是评审信号，而不是对文身的宣判。

Inbox 与 Relay：两条人机协作流水线

MEX 给"记忆的生产"设计了两条显式流程，且都遵守同一条边界：AI 助手负责起草，人来批准。

Inbox：把会话里的结论变成团队知识

对 AI 助手说一句"用 MEX Inbox 把我们刚讨论的结论记下来"，它会先检索现有知识，再起草一条增补或修正提案。草稿留在本地，发布后生成 Markdown 提案供人评审；批准后，规范知识被更新，提案作为历史保留。

Relay：把"接力棒"交给下一位队友

换人接手工作时，AI 助手可以起草一张Relay 接力卡：改了什么、跑了哪些测试、还剩什么、下一步看哪里，外加发布时观察到的仓库状态（分支、HEAD、脏树标记）。发布者人工确认后，接力卡随 Git 共享给队友——它是一份持久的交接记录，不是聊天消息，也不替代 Jira。

两条流程的技能定义分别见 skills/mex-inbox/SKILL.md 与 skills/mex-relay/SKILL.md，核心实现位于 src/team/relay/。

Project Hub：团队记忆的本地"控制室"

运行mex hub后，Hub 在127.0.0.1上打开本地浏览器界面——它是只读浏览 + 显式操作的控制台，读取的是你自己的 checkout：

• Home / Search / Knowledge / Code：解释与实现证据放在一起，点一条知识就能看到它的代码锚点；
• Inbox / Relays：评审知识提案、领取团队交接；
• Members / Activity：谁参与了、MEX 记录了哪些工作流事件；
• Jobs / Health：索引状态与显式维护入口。

Hub 的技术细节（进程租约、一次性引导 token、CSRF 保护、只绑定回环地址）记录在 docs/design/project-hub-foundation.md 中，值得对"本地服务如何保持安全"感兴趣的读者一读。

如何快速开始：一条命令引入 MEX

前置条件：Node.js 22.5+ 和一个 Git 仓库。在仓库根目录执行：

npx mex-agent@0.8.3 setup

流程分三步：setup 会打开本地 Hub 完成脚手架搭建，可选的 Claude Code / Codex 会自动填充项目记忆，最后在 Hub 中审阅 setup 文件 diff 并提交。终端党可以用mex setup --cli，纯预览可用mex setup --dry-run。

日常维护很简单：mex check给出 0–100 的漂移分数，mex doctor诊断环境，索引落后时按提示执行mex graph refresh或mex wiki rebuild-index即可。

MEX 的边界：它明确不做什么

理解一个工具的边界和它的能力同样重要。MEX不是：

• ☁️ 云端托管 Hub 或托管知识同步——共享全靠你执行的 Git 操作；
• 🔔 实时通知、在线状态或聊天工具；
• 🔐 账号、认证或 RBAC——Members 只用于署名归属；
• 🧮 语义/向量搜索引擎——Wiki 检索是全文检索，Graph 检索是词法+结构检索；
• 🚀 自动 push / pull / 提交——每一次写入都需要人显式审阅。

隐私上，MEX 不上传任何规范记录、索引或草稿；默认有匿名化用量统计，可用mex telemetry disable关闭，详见 TELEMETRY.md。

小结

MEX 的核心思想可以浓缩成三句话：

1. 记忆是规范文件——结构化 Markdown 就是事实源，代码依然是最终权威；
2. Git 是中枢——记忆随 commit / push / pull 流动，没有额外的服务依赖；
3. 索引是本地可重建的——每个人和每个 AI 助手都在自己的 checkout 上高速检索，互不干扰。

当你希望 AI 编程助手不再是"每条会话都失忆的新人"，而是能站在团队积累的肩膀上工作时，把 MEX 引入仓库就是第一步。