开源AI工具这两年井喷式爆发但真正能留下来、每天都会打开用一用的其实没几个。我自己的工具箱里长期躺着的来来去去就是那么三五个。最近一段时间有三个工具频繁出现在我的日常工作流里一个是把整个代码仓库打包成AI能直接吃的格式一个是专门给代码做审查的还有一个是给AI加上长期记忆的。它们分别解决的是喂AI查代码加记忆这三件事名字分别是Repomix、OpenCodeReview和Hindsight。这三个工具单独拿出来都能打组合起来用更是顺手得不行。不管你是刚接触AI辅助开发的初学者还是已经有一套自己工作流的老手这篇文章里的内容应该都能给你一些可以直接抄作业的东西。1. 三个工具到底解决什么问题1.1 先搞清楚喂AI这件事的痛点在哪用过ChatGPT或者Claude这类对话式AI写代码的人应该都有体会你贴一段代码进去它改得挺好但你贴一个项目进去它就开始胡说了。原因很简单AI的上下文窗口是有限的你不可能把几百个文件全部塞进去。就算窗口够大token费用也扛不住。更麻烦的是AI不知道你的项目结构。它不知道哪个文件引用了哪个文件不知道你的工具函数放在哪里不知道你的配置文件长什么样。你只给它一个utils.js它改出来的代码可能引用了根本不存在的模块。Repomix就是来解决这个问题的。它做的事情说起来很简单把你的整个代码仓库打包成一个结构化的文本文件AI可以直接读取。但这个简单背后有很多讲究——它要处理.gitignore、要排除二进制文件、要保留目录结构、要控制输出体积。这些细节做得好不好直接决定了AI能不能真正理解你的项目。1.2 代码审查为什么需要专门的工具代码审查这件事GitHub有PR reviewGitLab有merge request各种CI工具也能跑lint。但这些都是基于规则的检查它们能告诉你这行超过了120个字符但没法告诉你这个函数的错误处理逻辑有问题。大语言模型在这方面有天然优势——它能理解代码的意图能发现逻辑漏洞能提出重构建议。但直接用ChatGPT做代码审查有几个问题第一你得手动把代码贴进去费时费力第二它不知道你的项目规范给出的建议可能跟你的代码风格完全不搭第三每次审查都是独立的它记不住你之前告诉过它什么。OpenCodeReview这个工具就是冲着这些痛点去的。它把代码审查这件事做成了一个可以集成到工作流里的自动化环节而且专门针对代码审查场景做了优化。它支持中文这一点对国内开发者来说尤其友好很多审查意见用中文表达出来比英文更精准。1.3 AI的记忆为什么是个大问题跟AI聊过天的人都知道它的记忆是短暂的。这次对话里你告诉它我们项目用TypeScript不用any下次开新对话它又忘了。对于写代码这种需要长期上下文的任务来说这简直是灾难。Hindsight解决的就是这个问题。它给AI加了一层持久化的记忆让AI能记住跨会话的信息。你可以把它理解成给AI配了一个笔记本每次对话的重要信息都记下来下次对话的时候自动带上。这个思路其实不新鲜但Hindsight做得比较优雅的地方在于它的中文兼容性——很多记忆工具对中文的支持都很糟糕分词、检索、召回都有问题Hindsight在这方面下了功夫。这三个工具分别对应了AI辅助开发的三个关键环节输入喂AI、处理查代码、状态加记忆。把它们串起来就形成了一条完整的链路。2. Repomix把代码仓库变成AI能吃的格式2.1 它到底做了什么Repomix的核心功能一句话就能说清楚把整个代码仓库打包成一个AI友好的格式。但具体怎么打包里面有很多门道。它做的事情包括遍历你的项目目录按照.gitignore规则排除不需要的文件识别并跳过二进制文件保留目录结构信息最后输出成一个结构化的文本文件。这个文件通常包含三部分项目摘要、目录树、以及每个文件的内容。为什么这个格式对AI友好因为AI在处理文本的时候结构信息非常重要。如果你只是把一堆文件内容拼接在一起AI很难判断文件之间的边界在哪里。Repomix输出的格式有明确的分隔符和文件路径标注AI能清楚地知道这段代码属于哪个文件。2.2 安装和基本使用Repomix是基于Node.js的安装很简单npm install -g repomix或者你不想全局安装直接用npx也行npx repomix在项目根目录执行这个命令它就会在当前目录生成一个repomix-output.txt文件。这个文件就是打包好的结果你可以直接把它拖进ChatGPT或者Claude的对话框。但默认配置不一定适合所有项目。比如你的项目很大打包出来的文件可能有几十MB这时候就需要做一些过滤。Repomix提供了丰富的配置选项可以通过命令行参数或者配置文件来指定。2.3 关键配置项详解我整理了几个最常用的配置项这些是我在实际使用中反复调整过的配置项作用推荐值说明--include指定包含的文件模式src/**/*.ts只打包源码目录--ignore指定排除的文件模式**/*.test.ts排除测试文件--compress压缩输出开启用Tree-sitter提取关键代码结构--output输出文件名ai-context.txt自定义输出路径--style输出风格markdown可选xml、markdown、plain--top-files-len显示最大的N个文件10帮助识别体积大户--compress这个选项特别值得说一下。开启之后Repomix会用Tree-sitter解析你的代码只保留函数签名、类定义、导入导出这些关键结构把函数体内部的具体实现压缩掉。这对于让AI理解项目架构特别有用——AI不需要知道每个函数的具体实现它需要知道的是这个项目有哪些模块模块之间怎么调用的。我实测下来一个中等规模的TypeScript项目完整打包大概2MB左右开启压缩之后能降到300KB以内。这个体积差异直接决定了你能不能把整个项目塞进一次对话里。2.4 实操为一个真实项目生成AI上下文假设你有一个典型的Node.js后端项目目录结构是这样的my-project/ ├── src/ │ ├── controllers/ │ ├── services/ │ ├── models/ │ └── utils/ ├── tests/ ├── config/ └── package.json你想让AI帮你重构services目录下的代码但希望它能理解整个项目的上下文。这时候可以这样操作repomix --include src/**/*.ts --ignore **/*.test.ts,**/*.spec.ts --compress --output project-context.md --style markdown这条命令做了几件事只包含src目录下的TypeScript文件排除所有测试文件开启压缩模式输出为markdown格式保存到project-context.md。生成的文件大概长这样# Project Structure src/ ├── controllers/ │ ├── userController.ts │ └── orderController.ts ├── services/ │ ├── userService.ts │ └── orderService.ts ... ## File: src/services/userService.ts import { UserModel } from ../models/userModel; import { hashPassword } from ../utils/crypto; export class UserService { async createUser(data: CreateUserDTO): PromiseUser { // ... implementation compressed } ... }把这个文件贴给AI然后说帮我重构userService把密码加密的逻辑抽出来AI就能给出非常精准的建议因为它看到了整个项目的结构和其他相关文件。2.5 踩过的坑和注意事项第一个坑是输出文件被自己打包进去。如果你在项目根目录执行repomix生成的repomix-output.txt可能会被下一次执行时包含进去导致文件越来越大。解决办法是在.gitignore里加上这个文件名或者用--ignore参数排除。第二个坑是大项目的token爆炸。我试过一个有上千个文件的项目即使开了压缩输出还是有5MB以上。这种情况下更好的策略是分模块打包每次只处理一个子系统。第三个坑是敏感信息泄露。如果你的项目里有.env文件或者包含密钥的配置文件打包之前一定要确认这些文件被排除了。Repomix默认会读取.gitignore但如果你有些敏感文件没有加到.gitignore里就会被打包进去。我一般会额外加一层--ignore来确保安全。提示在把打包结果发给任何AI服务之前先打开文件扫一眼确认没有API密钥、数据库密码、内部地址这类信息。这个习惯能帮你避免很多麻烦。3. OpenCodeReview让AI帮你做代码审查3.1 为什么不用现成的lint工具有人可能会问ESLint、Pylint这些工具不够用吗答案是它们解决的是不同层面的问题。Lint工具检查的是语法层面的问题——缩进、命名规范、未使用的变量、潜在的空指针。这些是机械性的检查规则明确执行快速。但代码审查中真正有价值的部分——这个函数的职责是不是太杂了、这个错误处理是不是漏了某种情况、这个接口设计是不是合理——lint工具完全无能为力。OpenCodeReview走的是另一条路。它把代码交给大语言模型让模型从理解意图的角度来审查。它能发现的问题类型包括逻辑漏洞、边界条件遗漏、性能隐患、安全风险、可读性问题、架构层面的建议。3.2 核心工作流程OpenCodeReview的典型使用流程是这样的指定要审查的代码范围单个文件、一个目录、或者一个diff工具把代码和审查提示词一起发给大语言模型模型返回审查意见工具把意见整理成结构化的报告这个流程看起来简单但实际使用中有很多可以优化的地方。比如审查提示词的设计——你告诉模型审查这段代码和告诉它审查这段代码重点关注错误处理和并发安全得到的结果质量完全不同。3.3 中文兼容性的实际体验OpenCodeReview在中文兼容性上做得确实不错这一点值得单独拿出来说。很多代码审查工具的输出是英文的对于国内团队来说审查意见还需要翻译一遍才能用。OpenCodeReview支持中文输出而且不是那种机翻的中文是模型直接用中文思考和表达的结果。我对比过同一个代码片段用英文和中文审查的结果。英文审查意见通常更简洁但有时候会漏掉一些细节中文审查意见往往更详细会把为什么这么改解释得更清楚。这可能跟中文表达习惯有关——中文更倾向于把因果关系说透。另外中文兼容性还体现在对中文注释和中文变量名的处理上。有些工具遇到中文注释会乱码或者忽略OpenCodeReview能正常处理。3.4 实操审查一个真实的函数拿一个实际的例子来说。假设有这样一个函数def process_order(order_id, user_id): order db.query(fSELECT * FROM orders WHERE id {order_id}) if order.status pending: user db.query(fSELECT * FROM users WHERE id {user_id}) if user.balance order.amount: user.balance - order.amount order.status paid db.commit() return order把这段代码交给OpenCodeReview它给出的审查意见大概会包括SQL注入风险两处查询都用了字符串拼接应该用参数化查询事务边界问题余额扣减和订单状态更新应该在同一个事务里但这里没有显式的事务控制并发安全问题两个请求同时处理同一个用户的订单时可能出现超扣错误处理缺失数据库操作可能失败但没有try-catch业务逻辑问题没有检查订单是否已经被支付过这些意见里前三条是安全性和正确性问题第四条是健壮性问题第五条是业务逻辑问题。一个lint工具最多能发现第一条后面的都发现不了。3.5 集成到开发工作流OpenCodeReview可以集成到几个不同的环节本地开发时在提交代码之前跑一遍把明显的问题先修掉。这个环节适合审查单个文件或者最近的改动。CI流水线中在PR创建时自动触发审查把意见作为评论贴到PR上。这个环节适合审查整个diff。定期审查每周或每月对核心模块做一次全面审查发现积累的技术债。我自己的习惯是在本地开发时用第一种在团队协作时用第二种。第三种偶尔做一次主要是为了发现那些大家都知道有问题但一直没空改的地方。3.6 注意事项和常见问题审查意见不是圣旨。AI给出的建议有时候会过于理想化比如建议你把一个简单的函数拆成三个但实际上这个函数就是很简单拆了反而增加复杂度。审查意见要结合项目实际情况来判断。上下文很重要。如果你只给AI看一个函数它不知道这个函数被谁调用、调用频率如何、有没有性能要求。这些信息会影响审查意见的质量。所以尽量给AI提供足够的上下文比如相关的调用方代码、项目的架构文档。成本控制。代码审查会消耗token大项目全量审查一次可能花费不菲。建议的做法是只审查改动的部分而不是每次全量审查。注意OpenCodeReview的输出质量很大程度上取决于你用的底层模型。同一个工具接GPT-4和接一个小模型审查质量差距非常大。如果预算允许建议用能力强的模型来做审查。4. Hindsight给AI装上长期记忆4.1 AI记忆问题的本质大语言模型本身是无状态的。每次对话对它来说都是全新的开始它不记得上次你说了什么。这个特性在有些场景下是优点比如隐私保护但在需要长期协作的场景下就是缺点。解决这个问题有几种思路。一种是把历史对话全部带上但这样token消耗会线性增长很快就撑不住了。另一种是只带最近几轮对话但这样会丢失早期的重要信息。Hindsight走的是第三条路把重要信息提取出来存到一个外部存储里需要的时候再检索回来。这个思路跟RAG检索增强生成很像但Hindsight针对记忆这个场景做了专门优化。它不是简单地存储和检索文本而是会判断哪些信息值得记住、哪些信息已经过时、哪些信息之间有冲突。4.2 记忆的存储和检索机制Hindsight的工作流程大致是这样的提取从对话中识别出值得记住的信息比如用户偏好用函数式编程、项目使用PostgreSQL存储把提取出的信息存到向量数据库或者结构化存储里检索在新对话开始时根据当前话题检索相关的记忆注入把检索到的记忆作为上下文注入到提示词里这个流程里最关键的是第一步——提取。提取做得好不好直接决定了记忆的质量。如果提取太宽泛会存一堆没用的信息检索时噪音很大如果提取太严格会漏掉重要信息。Hindsight在提取这一步做了不少工作它会区分不同类型的信息事实性信息项目用什么技术栈、偏好性信息用户喜欢什么风格、任务性信息正在做什么事情。不同类型的信息有不同的存储和检索策略。4.3 中文兼容性的技术细节中文兼容性是Hindsight的一个亮点但很多人不知道这背后有什么技术挑战。第一个挑战是分词。中文没有空格分隔分词质量直接影响检索效果。比如机器学习模型这个词如果被分成机器、学习、模型检索学习模型的时候可能就匹配不上。Hindsight用了专门的中文分词方案来处理这个问题。第二个挑战是语义相似度。中文的表达方式比英文更灵活同一个意思可以有多种说法。这个函数有问题和这段代码不太对表达的是同一个意思但字面差异很大。Hindsight用的向量模型对中文语义的捕捉能力比较强能处理这种同义表达。第三个挑战是上下文理解。中文里省略主语、宾语的情况很常见一句话单独看可能不知道在说什么需要结合上下文才能理解。Hindsight在提取记忆的时候会考虑上下文避免提取出断章取义的信息。4.4 实操配置和使用HindsightHindsight的配置不算复杂但有几个关键参数需要根据实际情况调整memory: storage: vector # 存储后端可选vector或sqlite max_memories: 1000 # 最大记忆条数 retrieval_count: 5 # 每次检索返回的记忆条数 similarity_threshold: 0.75 # 相似度阈值低于这个值不返回 decay_days: 30 # 记忆衰减天数超过这个天数的记忆权重降低retrieval_count这个参数需要重点调。设得太小可能漏掉相关记忆设得太大会引入噪音而且消耗更多token。我一般从5开始试根据实际效果调整。similarity_threshold也很关键。设得太低会检索出一堆不相关的记忆设得太高可能什么都检索不到。0.75是一个比较平衡的值但具体要看你的向量模型。4.5 记忆管理的实践经验用了一段时间Hindsight之后我总结了几条经验定期清理记忆。记忆不是越多越好过时的记忆会干扰检索。比如你三个月前告诉AI项目还在用JavaScript现在项目已经迁移到TypeScript了这条旧记忆如果不清理会误导AI。分类存储。把不同类型的记忆分开存检索的时候可以按类型过滤。比如技术栈相关的记忆和代码风格相关的记忆分开检索怎么写这个函数的时候只查代码风格相关的。人工审核重要记忆。对于关键信息比如项目的核心架构决策建议人工确认一下记忆的内容是否准确。AI提取的时候可能会理解偏差。注意隐私。记忆里可能包含敏感信息比如内部API地址、数据库结构。如果用的是云端存储要确认数据的安全性。4.6 常见问题排查问题可能原因解决方法检索不到相关记忆相似度阈值太高降低similarity_threshold到0.6试试检索出无关记忆阈值太低或记忆太杂提高阈值清理过时记忆记忆内容不准确提取时理解偏差人工审核并修正关键记忆中文检索效果差分词或向量模型问题确认使用的是支持中文的向量模型响应变慢记忆条数太多减少max_memories定期清理5. 三个工具组合使用的实战方案5.1 一条完整的AI辅助开发链路把这三个工具串起来可以形成一条完整的链路用Repomix把项目打包成AI能理解的格式把打包结果和具体任务一起发给AI让AI理解上下文用OpenCodeReview审查AI生成的代码用Hindsight记住这次协作中的关键信息项目规范、用户偏好、架构决策这条链路的价值在于它让AI从一个每次都要重新解释背景的工具变成了一个越来越懂你项目的协作伙伴。5.2 具体场景重构一个模块假设你要重构一个用户认证模块。传统做法是打开文件读代码想怎么改动手改测试。用AI辅助的做法是先用Repomix打包认证模块相关的代码repomix --include src/auth/**/*.ts,src/models/user.ts,src/utils/crypto.ts --compress --output auth-context.md把auth-context.md发给AI说明重构目标把这个认证模块从session-based改成JWT-based保持现有的错误处理风格。AI给出重构方案后用OpenCodeReview审查生成的代码opencodereview --file src/auth/newAuthService.ts --focus security,error-handling --lang zh审查通过后把这次重构的关键决策记到Hindsight里认证模块已从session迁移到JWTtoken有效期24小时刷新token有效期7天。下次你再让AI改认证相关的代码时Hindsight会自动带上这些记忆AI就知道当前项目用的是JWT而不是session。5.3 团队协作中的配置建议如果是团队使用有几个额外的考虑统一Repomix配置。把配置写到一个共享的配置文件里确保每个人打包出来的格式一致。这样AI看到的项目结构是统一的。OpenCodeReview的审查规则。团队可以维护一份审查规则文档在调用OpenCodeReview时作为额外提示词传入。比如我们团队要求所有数据库操作必须有错误处理。Hindsight的共享记忆。团队可以共享一部分记忆比如项目架构、编码规范每个人也可以有自己的私有记忆比如个人偏好。5.4 性能与成本的平衡这三个工具都会消耗token组合使用的时候成本会叠加。几个控制成本的建议Repomix打包时尽量用--compress减少不必要的代码细节OpenCodeReview只审查改动的部分不要每次全量审查Hindsight的retrieval_count不要设太大5条左右通常够用根据任务重要性选择模型不是所有任务都需要用最强的模型我自己的做法是日常小改动用轻量模型加少量上下文重要重构用强模型加完整上下文。这样能在效果和成本之间找到一个平衡点。6. 我踩过的坑和最后分享几个技巧先说几个我实际踩过的坑。Repomix的输出文件一定要加到.gitignore里我有一次忘了加结果打包文件被提交到了仓库同事拉代码的时候一脸懵。OpenCodeReview的审查意见不要照单全收它有时候会建议你做一些过度设计比如把一个简单的工具函数拆成三个类这种建议要结合实际情况判断。Hindsight的记忆要定期清理我有一次发现AI一直在用三个月前的项目信息原因是旧记忆没有被清理掉新记忆的权重又不够高。再分享几个实用技巧。Repomix可以配合--top-files-len参数使用它会告诉你哪几个文件体积最大帮你识别出需要拆分的大文件。OpenCodeReview可以指定--focus参数来聚焦审查重点比如--focus security只关注安全问题这样审查意见会更集中。Hindsight支持导出和导入记忆团队协作的时候可以用这个功能来同步记忆。最后一个技巧是关于提示词的。不管你用哪个工具提示词的质量都直接决定输出质量。我的经验是在提示词里明确说明你是谁、你要做什么、输出格式是什么比笼统地说帮我看看效果好得多。比如用OpenCodeReview的时候与其说审查这段代码不如说你是一个有十年经验的Python后端工程师请审查这段代码重点关注SQL注入和并发安全问题用中文输出每条意见给出具体的修改建议。