如果你现在还在用“裸奔”状态的 Claude Code 直接干项目，我先替你捏一把汗。去年我把一个组内工具从默认配置迁移到插件化方案时，最大的感受不是“AI 写代码多快”，而是它终于不再一本正经地胡说八道了。今天想认真聊聊 2026 年开发者真正值得装的 Claude Code 插件，重点就解决两件事：幻觉和重复劳动。这篇文章面向正在用或准备用 Claude Code 的一线开发、前端 / 后端工程师和团队成员，我会把这 9 款插件怎么选、为什么有效、装完怎么配、实际跑起来有哪些坑，一次讲清楚。
1. 先聊聊为什么 Claude Code 需要插件：幻觉和重复劳动是两个真痛点
1.1 幻觉不是模型笨，是“上下文”不公平
很多人第一次撞见 Claude Code 的幻觉，是在一个已经跑了好几个月的项目里。你让它改一个老模块，它忽然引用了一个不存在的工具函数，或者把一个已经废弃的配置项写得特别自信，好像那个 API 真存在一样。这时候你会下意识觉得“这模型不行”，但实际问题的根源往往更朴素：模型没有完整看到你的仓库。
Claude Code 本身是一个 CLI 编码代理，它强在理解和生成，但它的上下文窗口是有限的。一个中等规模项目，动辄几千个源文件，几十万行代码，模型不可能把整个仓库塞进上下文里。它会基于当前打开的文件、最近的对话、以及它能检索到的 fragment 来做判断，一旦检索不到关键定义，它就开始“编了”——不是故意骗你，而是在它的世界里，这就是最合理的补全。
插件的作用，本质上是把所有“模型不知道但确实存在”的信息，用一种可控、按需的方式喂进去。我要装的这些插件里，有好几款干的就是这件事。它们不改变模型本身的智力，但改变了模型被“喂”什么。用大白话说：一样是让一个高级工程师干活，你给他一份完整代码地图，和他只给一个文件路径，工作成果必然天差地别。
1.2 重复劳动的根源：会话没有记忆
另一个让开发团队头疼的点，是 Claude Code 的“每次重启都像失忆”。你今天下午刚跟它对齐了项目的目录结构、测试命令、提交规范，晚上电脑一关，第二天早上重新打开，它又变回“新同事”。同一个问题反复解释，同一个命令反复输入，这本身就是一种重复劳动。
严格来说这不算模型的 bug，而是 CLI 工具的工作方式决定的。它每次启动都是一个新会话，除非你把项目上下文写成文档，或者靠外部工具把记忆持久化下来，否则模型没有跨会话记忆的能力。以前大家怎么解决？有人把所有约定写进 CLAUDE.md，有人写一大段 system prompt，但这些方式有两个问题：一是维护成本高，二是容易越写越长，最后连模型都不知道该信哪句。
插件化的记忆管理，解决的是“该记什么、什么时候取出来用”这件事。它不会把整本聊天记录丢给模型，而是像人的长期记忆一样，先提炼、再索引、按需读取。这样一来，你和 Claude Code 的配合会越来越像和一名真正的老同事配合，而不是每天面试新人。
1.3 插件不是“外挂”，而是打通模型与工程系统的桥梁
聊到插件，很多人的第一反应是 VSCode 的扩展商店，但在 Claude Code 这里，插件承担的角色更底层。它的核心机制是 MCP（Model Context Protocol，模型上下文协议），简单说就是一个标准化接口，让模型能连接外部工具、文件、数据库、甚至 CI 系统。
我举个例子你就明白了。模型本身没法主动查数据库，但它可以调用 db-pilot 插件提供的工具，插件把 Schema 和样例数据读出来，再通过 MCP 格式返回。整个过程对模型来说是透明的，就像它自己会查一样。所以插件并不只是“锦上添花”的功能，它是让 Claude Code 从一个“只能聊天的代码编辑器”进化为“真正能和工程系统协作的副驾驶”的桥梁。
弄明白这个底层逻辑之后，你再来看具体插件列表，就不会觉得它是一堆随机工具了。它们其实都在干三件事：补全上下文、接管重复动作、兜住质量底线。下面这张表可以帮你建立体感。
2. 这 9 款插件解决什么问题：一张表看懂
我长期在用并愿意推荐的插件，筛选标准其实很朴素：第一，必须能直接减少幻觉；第二，必须能干掉一项我原本要手工做的活；第三，维护活跃，不能装完两个月就没人管了。按这标准我留下了 9 款，分三组，先上总览。
| 插件名 | 分类 | 解决的核心痛点 | 适合场景 |
|---|---|---|---|
| repo-lens | 上下文构建 | 模型看不到完整仓库，引用不存在的符号 | 中大型项目、老代码库 |
| memory-bank | 上下文构建 | 跨会话失忆，约定反复解释 | 团队长期维护、新人入门 |
| sandbox-runner | 上下文构建 | 模型生成的命令可能删错文件或不可执行 | 批量修改、重构场景 |
| test-genius | 自动化 | 测试用例靠手写，维护成本高 | 单元测试覆盖不足的模块 |
| doc-flow | 自动化 | 文档/CHANGELOG 总是滞后 | 有文档规范要求的项目 |
| commit-craft | 自动化 | 提交信息不规范、PR 描述靠回忆 | 多人协作、代码审查严格的团队 |
| review-raven | 质量把关 | 人工审查容易漏掉安全与并发隐患 | PR 审查流程、交付前自检 |
| dep-sentinel | 质量把关 | 依赖漏洞没人盯，升级影响不清楚 | 长期迭代、依赖繁多的服务 |
| db-pilot | 质量把关 | 数据库结构不明，SQL 靠猜 | 业务系统、报表开发、服务端联调 |
这 9 款插件加在一起，覆盖了一条完整链路：动手前知道项目长什么样（repo-lens + memory-bank），动手时尽量不碰危险操作（sandbox-runner），动手后自动补齐测试和文档（test-genius + doc-flow + commit-craft），最后交给审查和依赖体检把关（review-raven + dep-sentinel + db-pilot）。
这里有个心态要摆正：插件不是装得越多越好。我见过一些同事一口气装了 20 多个插件，最后上下文里塞满了各种工具的返回结果，模型反而更晕了。合理数量是 5~10 个，并且每装一个新插件，你都要判断一个问题：它到底改变了模型“看到”的信息，还是改变了模型“动手”的方式？两者都值得装，但要清楚各自可能带来的副作用。
3. 消除幻觉组：让 Claude Code 真正“看懂”项目再动手
这一组是这篇文章的重头戏。之前有人问我“为什么 Claude Code 老爱凭空写接口”，我的回答通常很直接：因为它确实不知道那个接口不存在，你怪它之前，先想想有没有给它足够的信息。解决方案就是下面这 3 款插件。
3.1 repo-lens：把仓库变成可查询的符号地图
repo-lens 是我装的第一款插件，距今大概用了大半年。它的核心能力是维护一份“代码符号索引”，相当于给项目生成了一张可搜索的地图。每次模型需要查询某个函数、某个类型、某个工具函数的定义时，它会通过插件去索引库检索，而不是靠猜。
工作原理不复杂：插件后台会扫描项目源码，构建 AST（抽象语法树），提取出函数名、类名、接口定义、调用关系，并把这份关系图持久化到本地索引。需要时，Claude Code 向插件发起查询请求，插件返回相关代码片段和位置。因为查询是精确的，模型拿到的“事实”是准的，幻觉自然就少了。
拿真实场景举例。我前段时间重构一个支付模块，里面有个叫calculateFee的老函数，签名很复杂。如果让我手动跟 Claude Code 描述，我得复制签名、说清楚参数含义、再讲调用方的约定，特别费劲。用 repo-lens 之后，我只需要说“帮我看一下所有调用了 calculateFee 的地方”，插件会直接把调用点列表和签名定义拉出来，Claude 基于这些真实数据去做重构建议，靠谱得多。
安装通常是通过 MCP 方式配置，核心命令是：
claude mcp add repo-lens -- npx @repo-lens/server首次使用先建立索引：
claude repo-lens index --project-dir .需要留意的细节是：第一次全量索引会比较慢，几万行代码的项目跑个三五分钟很正常。我的习惯是让它在夜间任务里自动重建，白天开发时只增量更新。还有一点，索引文件建议放到.gitignore里，避免每个开发者的本地索引互相污染。
3.2 memory-bank：跨会话记忆让团队约定不再“每次重说”
memory-bank 解决的是“失忆”问题。它的思路不是把聊天记录存下来，而是把项目里的关键信息变成结构化的记忆文件，包括技术决策、工程规范、常用命令、已经踩过的坑等。这些文件会被分类管理，Claude Code 在面对某类任务时，自动加载相关记忆，而不是每次重新从零理解。
举个例子。我们团队有一套约定：所有 API 错误码必须统一走ApiException，不允许在业务代码里直接throw new Error。以前每次新会话我都要手动强调一遍，或者是写进 CLAUDE.md，但 CLAUDE.md 顶多算静态说明，而 memory-bank 可以结合当前任务上下文动态唤起对应规则。当模型准备生成异常处理代码时，它会先读取“错误码规范”这条记忆，再生成代码。
memory-bank 的记忆文件通常长这样，放在.claude/memory/目录下：
{ "scope": "api-error-handling", "rules": [ "所有业务异常必须抛出 ApiException", "错误码格式：MODULE_NAME_ERR_XXX", "禁止在 Controller 层 catch 后吞掉异常" ], "last_verified": "2026-02-10" }这里要特别说清楚一个坑：记忆文件不是越多越好，模型在任务开始时会读取相关记忆，但如果每一类任务都命中二十条记忆，反而会稀释重点。我的习惯是每条记忆都必须遵循“一句话原则”——能一句话说清楚的规则，不要拆成三句话。还有，记忆文件要定期 review，项目发展到一定阶段，之前的约定可能已经失效了，不及时清理的话，老记忆会变成新的“幻觉源”。
memory-bank 还有一个高频用法：把“上一轮讨论中模型给出的重要方案”沉淀成记忆。这能有效避免一种很烦人的情况——昨天刚定好的架构方案，今天问它，它一脸茫然。
3.3 sandbox-runner：动手之前先跑一遍，拦住“野生命令”
sandbox-runner 是这三款里我最晚装的，但装完后再也没卸过，因为它在一次事故里救了我。当时 Claude Code 建议我清空某个目录的缓存文件，命令写的是rm -rf ./cache/，但因为它当时对目录结构的理解有偏差，实际解析出来的路径差点指向了源码目录。如果不是 sandbox-runner 把这条命令先拦截到沙箱环境里跑了一遍，后果会很酸爽。
sandrox-runner 的基本原理不难理解：它把 Claude Code 要执行的 shell 命令放到一个隔离环境先跑一次，验证命令是否存在、会不会影响关键目录、输出是否符合预期，然后再决定要不要在真实环境里执行。它的设计定位不是“禁止所有命令”，而是“所有危险动作都先过一遍仿真”。
配置时我会为项目单独建一个沙箱镜像，里面只装构建和测试需要的依赖，然后用只读方式挂载项目源码：
version: "3.8" services: sandbox: image: node:22-alpine volumes: - .:/app:ro - /tmp/claude-sandbox-cache:/app/node_modules working_dir: /app command: sh -c "npm test"注意上面这个/app/node_modules的缓存目录挂载很关键，否则每次沙箱启动都要重新装依赖，慢到你怀疑人生。这个配置同样可以通过 MCP 接进来，Claude Code 在收到需要执行的命令时，会优先走 sandbox-runner 的验证通道。
经验之谈：沙箱不是万能保险。它挡住的是“明显会出问题”的操作，挡不住“命令本身合法但决策错误”的情况。比如模型觉得应该删src/old/，它确实在沙箱里跑通了，但这个删除决定本身可能是错的。所以我会把 Claude Code 的权限设成“复杂操作需要人工确认”，只有低风险命令才允许自动执行。这是使用所有自动化插件的一条底线。
4. 自动化组：把重复劳动真正交给工具
如果说第一组插件让模型“看得更懂”，那这一组就是让你“干得更少”。它们解决的是日常开发里那些机械性、低创造性、但又不得不做的事情：写测试、补文档、整理提交信息。这三件事占用的时间不一定最多，但打断心流的次数绝对不少。
4.1 test-genius：根据真实变更生成测试，而不是“重新发明测试”
很多团队不用 AI 写测试，原因是它们生成出来的测试用例千篇一律，要么是拿一段样板代码换个函数名，要么是测了半天，代码覆盖率毫无变化。test-genius 的思路跟这类“无脑生成”不一样：它通过对比 git diff 找出真实的接口变化，只针对变化点生成测试。
比如你改了一个createOrder方法，返回值从Order变成了OrderResult，test-genius 会意识到这个变更可能破坏哪些断言，优先为这些变更点生成用例。它背后会调用仓库里的现有测试，先跑一遍，拿到覆盖率基线，再决定哪里需要补充。换句话说，它是在“补洞”，不是在“铺地板”。
实际配置里我会让它走一遍这样的环节：
claude test-genius diff --base main claude test-genius generate --type unit --framework jest claude test-genius run用下来最大的感受是，它生成的测试可读性比我预期的好，至少比“为凑数而写”的那种测试好得多。不过我还是会把它生成的单测当作“初稿”，特别是那些断言边界条件的用例，需要人工扫一眼。我的建议是：每次代码评审时，把自动生成的测试当成需要被审查的正式代码，而不是默默带上。
4.2 doc-flow：让 README 和 CHANGELOG 不再滞后
文档滞后几乎是所有项目的通病。代码改了，文档没改；功能上线了，CHANGELOG 还停留在上个版本。doc-flow 的定位就是解决这个滞后问题：它监听代码变更和提交信息，自动生成或更新 README 对应的模块说明、CHANGELOG 的变更条目，并保持文档结构不漂移。
它和普通的“根据注释生成文档”工具不同。doc-flow 会同时读取提交信息、PR 描述、代码注释和测试用例，四路信息做交叉验证，一旦发现一致的内容才会写入正式文档。这样做的好处是：模型不会因为某一次随口说的一句话，就把不存在的功能写进 README。换言之，它自动帮你防了一手“文档幻觉”。
使用中我会在项目根目录维护一个模板，定义 README 的章节顺序，以及 CHANGELOG 每个版本的粒度：
claude doc-flow generate --type changelog --from v1.4.0 --to HEAD claude doc-flow update --markdown README.md --template docs/readme.tpl.md特别提醒一下：doc-flow 生成的 CHANGELOG 适合走“提案-确认-合并”流程，不要指望它完全无人值守。自动生成的文档仍然需要人来拍板，尤其是涉及对外承诺的“新特性”“破坏性变更”描述，必须过一遍产品眼。
4.3 commit-craft：把 diff 变成规范提交信息和 PR 描述
我见过太多团队，提交记录是“update xxx”“fix bug”，过了三个月连自己都看不懂当时改了啥。commit-craft 解决的就是这个问题：它读取暂存区里的 diff，结合当前项目的 repo 规范，生成符合 Conventional Commits 的提交信息，并同步生成 PR 草稿描述。
它的核心能力有三个：一是识别变更类型，区分 feat、fix、refactor、docs、test；二是总结变更影响范围，把 diff 中的文件变化归纳成一句话，而不是把整个 diff 贴进 commit message；三是关联 issue，如果你在分支名里带了fix/#123这类标记，它会自动提取出来写进关联信息。
我日常的操作流程是：
git add . claude commit-craft generate --style conventional生成的提交信息大概是：
feat(order): 支持部分退款流程 - 新增 OrderService.partialRefund 接口 - 退款金额校验支持余额不足场景 - 补充 partialRefund 相关单元测试提交信息生成以后我会快速扫一遍，确认没有夸大其词，然后执行claude commit-craft commit。这里有个小经验：必须让插件读取的是暂存区 diff，而不是工作区全部文件，否则它会把一些无关的调试文件变更也总结进提交信息里。
5. 质量与协作组：让人工审查更从容
这一组插件不负责写功能代码，它们负责站在“队友”的角度帮你看项目：代码有没有隐患、依赖有没有漏洞、数据库结构有没有理解偏差。它们是质量兜底，也是团队协作里最需要的“AI 同事”。
5.1 review-raven：PR 合并之前的自动审查
review-raven 会在你提 PR 时自动审查代码，重点关注安全问题、并发问题、资源泄漏和潜在的可空性错误。它跟服务端 CI 里的静态扫描工具有些重叠，但它最大的优势是能读懂 diff 的“意图”，理解这次改动想干什么，再判断实现有没有违背意图。
比如说，你这次改动把一个同步接口改成了异步队列消费，review-raven 不会只提示“函数长度过长”这种废话，它会去看这次的异步化改造有没有丢异常处理、有没有重复消费风险、重试逻辑有没有幂等设计。这些都是只有理解上下文才能给的反馈。
接入方式不复杂，CI 配置里多跑一步就行：
claude review-raven --diff origin/main...HEAD --format markdown我一般会把它生成的审查结果放在 PR 描述底部，人工审查的人先看 AI 提示的高风险点，再往下看代码。用它的过程里我也发现了它的短板：它会过度关注一些“理论风险”，比如某个并发场景理论上可能出现，但实际上量级根本到不了。所以它的结果只能当“重点提示”，不能当“最终裁决”。
5.2 dep-sentinel：依赖体检和升级建议
dep-sentinel 的任务很简单：扫描项目的依赖树，对照公开漏洞库，找出存在已知安全问题的版本，并给出最小升级路径。以前依赖安全这件事靠 Dependabot、Renovate 这类工具也能做，但它们往往只告诉你“这个版本有漏洞”，却不告诉你“升级之后会不会破坏现有代码”。
dep-sentinel 的不同之处在于，它能把漏洞信息、依赖影响范围和项目代码里的实际调用点关联起来。如果某个存在漏洞的依赖包在你代码里压根没被用到危险函数上，它会把这个风险标注为“低”；如果某个包被核心链路直接引用，它会提示你优先处理。这个优先级排序省了我太多时间，以前我是看到警告就统统升级，现在可以准确分配精力。
claude dep-sentinel scan --lockfile package-lock.json --level high claude dep-sentinel upgrade --package lodash --target 4.17.21 --plan经验上我建议把它接进每周的例行维护里，而不是每次提交都跑，因为依赖升级的信息噪音很大，过度频繁地扫描容易让人麻木。
5.3 db-pilot：让 Claude Code 看得懂数据库，不再靠猜写 SQL
后端开发里有个很磨人的问题：模型写 SQL 的时候经常把字段名写错。它没连过数据库，怎么会知道你的表叫order_info还是orders？字段是created_at还是CREATE_TIME？在模型的世界里，可能全部默认成 camelCase 了。
db-pilot 就是为了解决这件事。它连接到你的数据库，读取表结构、索引、外键关系、最近的样例数据，然后通过 MCP 把这些信息按需注入到 Claude Code 的上下文里。当你让它写 SQL 时，它甚至能先展示一个简化的 Schema 给你确认，再动手写查询。
实际使用里我最满意的是“explain”能力。让 Claude Code 解释一条慢查询的优化思路，db-pilot 会把真实执行计划带回来，模型基于实际的行数和索引使用情况分析，给出的建议比凭空猜靠谱得多：
claude db-pilot connect --db postgresql://localhost:5432/app_db --readonly claude db-pilot explain "SELECT * FROM orders WHERE status='pending'"这里有一条铁律要记住：连接生产库必须用只读账号。db-pilot 支持--readonly模式，会强制所有查询只能执行 SELECT。即使这样，我还是建议连接预发库来做探索，生产库只在紧急排查时使用。这个插件还有一个额外价值：团队新同学接手项目时，可以靠它快速了解数据库结构，少跑很多冤枉路。
6. 安装与配置实战：从零跑通这 9 款插件
前面把“为什么装”讲清楚了，接下来落到“怎么装”。配这些插件并不困难，但有几个细节很容易卡住人，我按实测顺序给你理一遍。
6.1 前置条件：先有 Claude Code，再谈插件
如果你还没安装 Claude Code，先用 npm 装一下，然后验证版本：
npm install -g @anthropic-ai/claude-code claude --version需要注意的版本兼容问题：插件生态迭代很快，新版本的 Claude Code 有可能会废弃旧版 MCP 配置项。我会保持 Claude Code 与插件都更新到当前稳定版，而不是追最新版。最新版偶尔会有 breaking change，生产环境里稳定比新鲜重要得多。
6.2 安装插件的三种方式
Claude Code 的插件安装不只有一种路径，我用得最多的是三种：
第一种，直接从插件市场安装。新一代 CLI 客户端支持类似claude plugin install的命令，它会从仓库拉取插件定义并自动注册 MCP Server：
claude plugin install repo-lens claude plugin install memory-bank第二种，通过 MCP 手动添加。如果某个插件是独立的 MCP Server，可以用claude mcp add把它接进来：
claude mcp add repo-lens -- npx @repo-lens/server claude mcp add db-pilot -- npx @db-pilot/server --readonly第三种，通过项目配置文件管理。适合团队统一封装插件配置的情况，在项目根目录建.claude/settings.json：
{ "mcpServers": { "repo-lens": { "command": "npx", "args": ["@repo-lens/server"] }, "db-pilot": { "command": "npx", "args": ["@db-pilot/server", "--readonly"] } }, "permissions": { "defaultMode": "ask" } }这三种方式可以混用。个人开发时用第一种最省事，团队协作时我倾向于把配置写进settings.json，统一提交到代码仓库，让每个成员共享一套插件组合。
6.3 配置核心：权限模型一定要控制好
插件安装完之后，第一件事不是开始写代码，而是检查权限设置。Claude Code 的权限模型有几档：完全自动（YOLO）、询问（ask）、允许列表（allowlist）、禁用（deny）。我强烈建议初始阶段把默认权限设成ask，让每个敏感操作都有确认环节。
配置里可以用permissions.allow白名单放行安全的命令，比如npm test、git status这类；把危险类命令放进deny或强制询问。这样做的好处是，即使插件本身出了 bug，也有最后一道人为确认的闸门。
验证插件是否真的被 Claude Code 识别了，可以随时输入：
claude mcp list如果列表里出现了你配置的 MCP Server 名字，说明整个链路已经通了。这一步很多人会忽略，等到运行时才发现插件根本没加载，浪费的时间比装的时候还多。
6.4 卸载与升级也要心里有数
卸载插件同样要干净。用claude plugin uninstall 之后，检查一下.claude/settings.json里是否还残留相关配置。升级的话，插件的更新周期通常和 npm 包保持一致，我会用：
claude plugin update --all跑完升级后，手动执行一次测试链路，确认核心场景没问题。这种“升级后立刻验证”的习惯，能帮你把大部分兼容问题控制在五分钟以内。
7. 实测中的坑与我现在的工作流
再好的插件，落进真实项目也免不了踩坑。下面这几个问题都是我自己遇到过的，列出来给你当参考，比文档更实际。
7.1 上下文注入过多，模型反而变“懵”
你可能会以为插件越多、信息越全，模型表现就越好。但真实情况是，当上下文里塞满太多索引结果时，模型会变得犹豫，回答问题和生成代码的速度明显变慢，甚至开始忽略关键信息。我这里说的还是配置了 repo-lens 和 memory-bank 之后发生的事。
后来我做了一轮瘦身：repo-lens 查询默认只返回最相关的 10 条结果，memory-bank 里的规则也做了精简合并。瘦身之后，模型生成的准确度反而提升了。这让我意识到一个道理：插件的价值不在于“知道得最多”，而在于“知道得最准”。
7.2 记忆文件被模型自己“污染”
memory-bank 有一个意想不到的问题：模型会在对话过程中往记忆文件里写入一些它自己生成的临时结论，而这些结论未必经过验证。有一次它把“推荐使用 xxx 库做 SDK 封装”写进了记忆，但实际上这个库版本已经过时了。后来我再问它项目依赖选型建议时，它总是优先推荐那个过时库，一度让我怀疑是不是模型产生了新的幻觉。
解决办法是给记忆文件建立版本控制，并设置人工 review 机制。目前我的做法是让记忆文件目录用 git 管理，Claude Code 只有写入临时目录的权限，真正合并进主记忆库的变更必须经过我确认。这虽然多了一步操作，但换来了记忆质量的稳定。
7.3 沙箱插件把正常命令也拦住了
sandbox-runner 刚接进来那阵，几乎每个命令都被沙箱拦下走流程，包括git status这种无害命令，搞得整个交互变得很拖沓。后来我调整了白名单，把高频且低风险的命令设为自动放行，只对rm、mv、curl 写文件这类真正危险的命令走沙箱验证，体感立刻好很多。
settings.json里的权限配置大概长这样：
{ "permissions": { "defaultMode": "ask", "allow": [ "git status", "git diff", "npm test" ] } }7.4 我现在一天的开发流是怎么转的
当你把配置稳定下来之后，这套插件组合就会变成一条流水线。我现在的日常大概是这样的：
早上到公司先拉代码，看一眼db-pilot给出的数据库 Schema 有没有变化。然后进入开发：写核心逻辑时，repo-lens负责帮我定位相关代码和调用关系，memory-bank保证我组的规范、踩坑记录随时在线。写完代码后跑一遍test-genius，把变更点对应的测试补上。准备提交时，commit-craft生成规范的提交信息，doc-flow顺手更新 CHANGELOG。提交 PR 后，review-raven自动跑一轮重点审查，我只需要在它标记的风险点里逐个人工确认。
每周我会安排一天跑dep-sentinel的例行依赖体检，并花半小时把 memory-bank 里的过期规则清一清。这套流程跑顺之后，我的重复劳动至少减少了四成，模型幻觉导致的问题也基本很少再出现了。
说句实在话，插件装得再多，最后拍板的还是人。它有它的价值，也有它的边界。我现在的原则是：每次引入一个新插件，头两天都把它的建议当“实习生”的话来听——参考，但绝不盲信，等摸清了它的脾气，再逐步放权。这样的节奏走下来，Claude Code 才真正从“玩具”变成了我日常开发里离不开的搭档。