这是一篇迟到的项目介绍，感觉把readme或者manual直接发出来不是很礼貌，于是有了这篇文章。
MPM-Coding 是开源项目，仓库最近重新提交过，在 GitHub：halflifezyf2680/MPM-Coding 详细文档见
docs/MANUAL.md
8 个月前，我给 AI coding 套了个Harness，可以节省大量的无效tokens消耗
不知不觉，用 AI 帮忙写代码已经快两年了，从一开始的网页对话粘贴、代码补全，到现在沟通基本靠嘴。
AI coding很不错，只要需求足够明确，丢过去就能拉一坨能跑的代码。但项目一大，问题就来了 —— LLM无法理解项目，开始乱读文件、改错地方、改完这头忘那头，有时候改着改着就把自己改迷路了。我明白这不是某个模型的问题，而是上下文工程的问题。
我尝试了各种开源项目，mcp、skill、prompts都上，感觉还是差了点什么。结果还是自己写了个MCP框架，叫 MPM-Coding，去年冬天的时候删了一半的tools，定版，一直用到现在。个人项目和工作项目都在用，感觉到现在也不算过时。它是一个从定位，到推理，到编排，最后记忆的全流程方法。
主要问题出在哪
AI 编程框架（不管是 Claude Code、Cursor 还是 Copilot 等等）在处理大型代码库时，都有一个共同的毛病：暴力扫描、范式输出。基于这点，构建代码库索引，和怎么去扫描利用方面一直都是重点关注对象，这里面Augment是第一个及格的，windsurf第二，cursor后来也赶上了。
但是公司项目都不准用，就算不说数据保密的事，作为一个坚定的唯物主义战士，Embedding和RAG这种玄学路子，我一直是绕着走的。我判断还是得走AST，不光要结构树，还要调用图，还要有影响分析，还要有链路追踪。
核心思路1：先给地图，再指路
MPM-Coding 的核心思路很简单——别让 AI 瞎逛，给它结构化的导航信息。
刚接手一个陌生项目，第一件事不是读代码，而是搞清楚目录结构。LLM默认的做法是 ls 或 Glob 跑好几遍，然后自己在脑子里拼图。在mpm里面，project_map 一条命令搞定，直接把注意力收窄到关键目录。
知道目录在哪了，下一步是找具体的东西。普通搜索工具（grep、ripgrep）是纯文本匹配，搜 handleMessages，注释里的、字符串里的、测试文件里的全都给你吐出来。code_search 走的是 AST 索引，它知道什么是函数、什么是类、什么是方法。搜 handleMessages，直接返回函数定义 + 22 个相关候选，带文件路径和行号。而且也有 ripgrep 兜底，带模糊查询机制不担心 0 返回。
每一步只给 AI 够它决定下一步看哪个文件的信息量
LLM 有个特长，它自己会根据名称猜这些目录是干啥的，真正的代码理解靠它自己去读目标文件。这不是什么高深的理论，就是一个工程取舍：少喂一点，但喂得更准。
为什么用 AST 不用 LSP？
LSP 解决的是编辑器和语言智能之间的 M×N 适配问题，服务对象是人类开发者的实时操作。MPM 要解决的是给 LLM 项目的结构化信息，服务对象是 AI 的上下文工程，是认知过程。 这是两回事。
核心思路2：推理与对齐
定位到了文件和函数，下一步是搞懂数据流动，以及人和 AI 的理解是不是在同一频道上。
理解业务逻辑最难的不是读单个函数，而是搞清楚数据从哪来、到哪去。以前的做法是手动跳转，读一个文件发现它调了另一个函数，再去读那个文件，或并行读 n 个文件或 n 行代码。flow_trace 自动追踪上下游。比如追踪 headless_claude.go 的前向依赖，直接输出完整调用链：runHeadlessClaudeTurn → ensureAgentMCPConfig → buildPrompt → resolvePermissionFlags → prepareTaskWorktree，7 个直接依赖一目了然。
人类 和 LLM 的沟通黑洞
人和人之间协作，最重要的不是谁更聪明，而是想法能不能对齐。结构化信息本质上是在做思维同步 —— 先把项目地图对齐了，后面的沟通才有基础。
顺着这个思路，我早期做过一个 prompt 增强工具，核心就是对齐人类和 LLM 的理解。其实就是一个 md 文档，先确认理解一致了再动手，返工率明显降低。但后来我发现一个 workflow 就能干同样的事，就从 MPM 里删掉了。指令是一句话：根据用户输入，结合已有信息，做更清晰的工程化解读，输出结构化目标给用户确认，不要直接执行。后来别人告诉我augment和trae对话框的小星星按钮就是这个功能。
核心思路3：编排——长任务不跑丢，改之前知道影响
定位准了，理解也到位了，接下来就是动手。
code_impact 在你改一个函数之前，直接输出风险等级和调用者列表。
task_chain 任务管理状态机，把任务拆成阶段，每个阶段有明确的目标和验收标准。支持门控（gate）机制——某个阶段完成后检查是否通过，不通过还可以自己改目标。支持断点续传，今天没做完明天接着来。
system_hook，可以理解为任务链里的"便利贴"。当 AI 执行到某一步发现被卡住了（比如需要用户确认、等外部依赖、信息不足无法继续），它可以贴一张便利贴挂起当前进度，记下"卡在哪、为什么卡住"。等你准备好了再释放这张便利贴，AI 就从断点接着往下走。用户也可以说：我想到一个问题（xxx），你分析我的意图，mpm hook挂起，过一会去处理。
核心思路4：记忆——改完必须留记录
这是我认为最重要但最容易被忽略的环节。
memo 每次改动都极简记录原因和上下文，支持批量原子级提交。
system_recall 自动根据需求召回历史，多维筛选过滤，宽进严出。
known_facts 自动将反复错误或者明显的坑点进行简洁记录，mpm自动或者蝇虎主动召回注意力。
time_line 一个可视化的开发历程，会弹出一个web窗口，程序化的，不用tokens。
有一次 LLM 搞坏了我本地 git 仓库。我打开 time_line 看着，叫 claude 拿出 system_recall，把那两天的代码重新写出来了。整个过程纯靠记忆层。感觉代码还更干净。
额外工具
早期 LLM 注意力机制不行的时候，我设计了 persona 工具，它通过强制注入角色约束来进行角色扮演，角色维持度下降也是我判断该不该 compact 的信号之一。现在注意力续接被 task_chain 接过去了，persona 作为 compact 判定信号已经作用不大。留着没删，是因为偶尔换成孔明风格还挺有意思的。persona也能自己管理角色，创建、编辑、删除都行，比如我说：
❯ 用mpm角色工具，创建一个海绵宝宝角色
● MPM-coding - persona (MCP)(mode: "create", name: "spongebob", new_name: "", display_name: "海绵宝宝", avatar: "🧽",
（中间省略）
⎿ ✅ 已创建人格: spongebob
实际表现
回到实际情况，我曾经让 claude code 审计一个 1300 文件的项目，它派几个 agent 去扫地，地推式读文件，token 烧得让人心慌。
盲测对比：拿同一个开源项目（opencode，4500+ 文件的 monorepo），先用通用 agent 审计，再用 MPM-Coding 审计。
通用 agent 那次，5 个 agent 并行跑了 35 分钟，产出了 86 条发现。看着很厉害，但仔细一看，很多 LLM 式的泛泛而谈和大惊小怪。
用 MPM-Coding 那次，默认行为很收敛，沿着 project_map → flow_trace → code_search → 精读关键文件 的路径走，最终产出 16 条发现。量少了很多，但是深度不一样，但每条都有精确的文件定位、代码片段、攻击场景和修复建议，甚至某些点可以直接和issue对上号。
少而精，比多而杂有用得多。
| 通用 Agent（5 个并行） | MPM 工具链 | |
|---|---|---|
| 耗时 | 35 分钟 | 约 15 分钟 |
| 发现数 | 86 条 | 16 条 |
| 有效发现 | 大量泛泛而谈，真正有深度的不多 | 每条都有文件定位、代码片段和修复建议 |
把 1000 多个文件一股脑堆到它面前，信息太多等于没有信息。
技术实现
- Go 写的 MCP Server，通过 StdIO 和 AI 客户端通信
- AST 索引用 Rust + Tree-sitter，支持多语言，多线程并发扫描
- 记忆层用 SQLite + WAL，所有操作记录可追溯
- 索引支持异步构建和增量更新，大项目也能跑
总结
MPM-Coding 解决的不是一个问题，而是AI coding 如何工程化问题。 如果你也在用 AI 编程，并且在大型项目中被"AI 失控"困扰过，可以试试这个思路。
MPM-Coding 是开源项目，仓库最近重新提交过，在 GitHub：halflifezyf2680/MPM-Coding 详细文档见
docs/MANUAL.md
