先把地址放上，开源地址： https://github.com/yinshaojun001/projectbrain
最近做了一个小工具叫 Project Brain ，MVP 阶段，想发出来听听大家意见。
起因挺现实的：组里有同学要离职，我不得不接手一些支付相关的活儿，第一个需求就是在抖音支付的原有代码上做一整套流程修改。
接手之后才发现，真正麻烦的不是代码本身，而是代码背后的上下文。支付流程怎么走的、哪段代码对应哪份文档、某个字段为什么要这么传、历史上踩过哪些坑、改一个地方会不会牵连回调和退款链路……这些东西散落在各处：有些在代码里，有些在外部文档里，有些在历史经验里，还有一些可能只存在于上一个同学的脑子里。
我平时用 Codex / Claude Code 辅助写代码和定位问题，但这类工具有个很明显的问题：能读代码，不一定懂项目上下文。每次联调出问题，都得重新跟它解释一遍流程、字段含义、潜在影响面。既费 token ，也费时间。需求紧的时候，这种拖慢真的很容易背锅。
所以我迭代了两个版本，做出了个能用的 MVP 。
我想让 Project Brain 做的事情是：在 AI 编程助手开始干活之前，先把跟当前任务相关的上下文喂给它——代码位置、业务流程、关联文档、历史踩坑、人工补充的注意事项、这次修改可能波及哪些链路。不是单纯的代码搜索，也不是知识库，更像是夹在代码仓库、文档、人工经验和 AI 工具之间的一个"中间层"。
目前还很早期，只解决了我自己接手复杂业务时的一部分痛点，后面想慢慢把它打磨成真正能用的产品。现在用 brew 安装就可以，codex-brain 启动 codex
几个想聊的问题：
用 AI 编程助手时，有没有遇到过"AI 读完代码还是不懂在干什么"的情况？这种项目上下文中间层，你觉得最核心的能力是什么？代码事实、外部文档、人工经验、历史决策这几类信息，怎么组织比较合理？如果要往产品方向走，你觉得应该先做哪块？
欢迎拍砖，也欢迎 issue / PR 。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。