# 让 Claude Code 越用越强：一套可落地的持续改进工作流 > 来源：Towards Data Science《How I Continually Improve My Claude Code》 > 作者：Eivind Kjosbakken > 原文链接：https://towardsdatascience.com/how-i-continually-improve-my-claude-code/ > 提炼目标：把文章观点整理成一套可分享、可执行、可复盘的 Claude Code / AI coding agent 持续改进教程。 ## 0. 核心结论 Claude Code 的效率提升，不只来自模型升级，也来自你能否让它从过去的使用记录中学习。 最小可落地闭环是： ```text 回顾最近会话 → 找出重复错误和低效操作 → 生成改进建议 → 沉淀到项目上下文/技能/脚本 → 下一次任务自动复用 ``` 一句话：**不要只使用默认 Claude Code，要建立一个让 Claude Code 每天复盘、修正、沉淀经验的反馈循环。** --- ## 1. 这套方法解决什么问题？ 很多人使用 Claude Code 时，会反复遇到这些问题： - Claude 重复犯同样的错误； - 工具调用太多，绕远路； - 每次都要重新解释项目约定； - agent 缺少测试、构建、部署等验证入口； - 多个 agent 并行时，人类跟不上上下文； - Claude 频繁停下来问一些本可以自己判断的问题。 这些问题的本质不是模型不够强，而是**没有把使用过程中的教训转成下一次可复用的规则**。 本文的做法是：让 Claude Code 定期回顾自己的历史表现，把问题转成明确的改进项。 --- ## 2. 你最终会得到什么？ 落地后，你应该得到 5 类产物： 1. 一条每日或每周执行的复盘任务； 2. 一份 AI coding 会话复盘报告； 3. 更新后的 `AGENTS.md` / `CLAUDE.md` / 项目说明； 4. 针对重复问题创建的技能、脚本或检查清单； 5. 一套多 agent 并行管理规则。 这些产物会让 Claude Code 更懂你的： - 技术栈； - 项目结构； - 偏好命令； - 常见踩坑； - 禁止操作； - 验证标准。 --- ## 3. 适用场景 适合： - 经常使用 Claude Code / Codex / Gemini CLI 改代码； - 同时维护多个仓库； - 经常让 agent 执行长任务； - 希望减少重复解释； - 希望把个人工作流沉淀成项目规则； - 团队准备规范 AI coding agent 的使用方式。 不适合一上来就自动化的情况： - 你还没有稳定使用 AI coding agent； - 会话记录不可访问； - 涉及敏感代码和隐私日志，不能自动读取； - 没有人工审查机制，容易把错误经验写进长期规则。 安全原则：**复盘可以自动，规则落地要审查。** --- ## 4. 第一步：创建“过去表现复盘”提示词 先写一个固定复盘 prompt。可以保存为 `review-past-performance.md`： ```markdown # Review Past Performance 请回顾我最近 24 小时与 Claude Code / coding agent 的交互记录。 重点检查： 1. 我在哪些任务上卡住了？ 2. agent 是否做了错误假设？ 3. agent 是否进行了不必要的工具调用？ 4. 哪些上下文本该提前提供？ 5. 哪些错误重复出现？ 6. 哪些验证步骤缺失或太晚执行？ 7. 哪些问题适合沉淀到 AGENTS.md / CLAUDE.md？ 8. 哪些问题适合做成脚本、skill、pre-commit hook 或测试命令？ 9. 哪些经验是跨仓库通用的？哪些只适用于当前仓库？ 请输出： ## 今日主要问题 - 问题： - 证据： - 影响： ## 可立即修复的流程问题 - 修复项： - 应写入哪里：AGENTS.md / CLAUDE.md / skill / script / test / docs - 风险： ## 不应沉淀的内容 列出只适用于一次性任务、可能过期、或证据不足的内容。 ## 建议补丁 只给出建议，不要直接修改文件，除非我明确授权。 ``` 这段 prompt 的关键不是“让 AI 总结”，而是让它把复盘结果分成： - 问题； - 证据； - 可修复项； - 不应沉淀项； - 建议写入的位置。 --- ## 5. 第二步：手动跑一次复盘，不要急着自动化 在建立 cron 之前，先手动执行 2-3 次。 目的：确认它输出的是有用建议，而不是泛泛而谈。 你可以这样要求 Claude Code： ```text 请根据 review-past-performance.md 的规则，只读回顾最近的 coding agent 会话。 不要修改任何文件。 输出可执行建议，并标注每条建议应该进入 AGENTS.md、CLAUDE.md、skill、script、test，还是不应沉淀。 ``` 人工检查时重点看： ```text [ ] 是否引用了具体问题，而不是空泛建议？ [ ] 是否区分了临时任务和长期规则？ [ ] 是否避免保存敏感信息？ [ ] 是否没有把一次性路径、PR 号、临时错误写成长期规则？ [ ] 是否给出了明确落点：文档、技能、脚本、测试？ [ ] 是否包含回滚或删除过时规则的建议？ ``` 只有当手动结果稳定有用后，再考虑定时化。 --- ## 6. 第三步：把复盘结果沉淀到正确位置 复盘建议不能都塞进一个文件。推荐这样分层： ### 写入 `AGENTS.md` / `CLAUDE.md` 适合： - 项目结构； - 构建/测试命令； - 禁止修改区域； - 代码风格； - 项目内固定工作流； - agent 开始任务前必须阅读的文件。 示例： ```markdown ## Agent Rules - 修改数据库执行逻辑前，必须先阅读 `core/db_executor.py` 和相关测试。 - 新增功能必须补 mock 测试。 - 提交前运行 `pytest tests/ -v`。 - 不要修改 `.env`，只更新 `.env.example`。 ``` ### 做成 skill / workflow 适合： - 多步骤、可复用的任务； - 经常需要同样检查的流程； - 有固定验证门槛的操作； - 需要独立审查或分阶段执行的任务。 示例： ```text 当用户要求修改生产 SQL 执行流程时： 1. 先读配置和测试； 2. 禁止改事务核心逻辑； 3. 写计划； 4. 补 mock 测试； 5. 跑完整测试； 6. 输出风险说明。 ``` ### 做成脚本 适合： - 重复命令； - 容易漏掉的验证； - 格式检查； - 项目健康检查； - 测试命令组合。 示例： ```bash #!/usr/bin/env bash set -euo pipefail python -m ruff check . python -m pytest tests/ -v git diff --check ``` ### 不应沉淀 不要保存： - 一次性任务进度； - 临时路径； - PR 编号； - 某次会话的中间失败； - 可能一周内过期的状态； - 未验证的个人猜测； - 密钥、token、内部地址。 --- ## 7. 第四步：设置定时复盘 当手动复盘稳定后，可以设置 cron。 Linux 示例： ```bash crontab -e ``` 加入： ```cron 0 2 * * * /home/you/bin/review-claude-code-performance.sh >> /home/you/logs/claude-code-review.log 2>&1 ``` 示例脚本 `review-claude-code-performance.sh`： ```bash #!/usr/bin/env bash set -euo pipefail cd /path/to/your/workspace # 伪命令：按你的 Claude Code / CLI 环境替换 claude-code run \ --prompt-file /path/to/review-past-performance.md \ --readonly \ --output /path/to/reviews/$(date +%F)-review.md ``` 如果你的工具不支持这样的 CLI 参数，也可以保留为“每日手动运行”。重点不是 cron 本身，而是**固定频率复盘**。 建议节奏： - 重度使用：每天一次； - 普通使用：每周 2-3 次； - 团队场景：每周一次，并人工评审后合并规则。 --- ## 8. 第五步：建立“规则升级”审核门槛 不要让 AI 自动把所有建议写进长期上下文。建议使用三档处理： ```text A. 立即沉淀 - 重复出现 2 次以上； - 有明确证据； - 对未来任务有帮助； - 不含敏感信息； - 不依赖临时状态。 B. 观察 - 只出现 1 次； - 可能是偶发问题； - 适用边界不清楚； - 需要再验证。 C. 丢弃 - 一次性任务状态； - 很快会过期； - 没有证据； - 可能误导未来 agent； - 含敏感信息。 ``` 推荐在复盘报告末尾加一个表述： ```text 请不要直接修改长期规则。 先把建议分成“立即沉淀 / 观察 / 丢弃”，并说明理由。 ``` --- ## 9. 第六步：优化多 agent 并发管理 文章里作者提到一个经验阈值：同时运行超过 7 个 agent 后，人类容易失去控制。 这个数字不是通用标准，但提醒很重要：**并发 agent 的瓶颈通常是人的注意力，不是机器数量。** 建议这样管理： ### 同一仓库 - 一个终端 tab； - 多个 split panes； - 每个 pane 只跑一个 agent； - 每个 agent 任务边界清楚； - 任务之间尽量低耦合。 ### 多个仓库 - 每个仓库一个 tab； - tab 名称使用项目名； - 每个项目保留一个状态文件，如 `agent-status.md`； - 避免同一时间跨太多项目切换。 ### 人类侧状态管理 每个 agent 都应该能回答： ```text 你现在在做什么？ 已经完成什么？ 卡在哪里？ 下一步是什么？ 需要我决策什么？ 验证结果是什么？ ``` 如果工具有 recap / summary 功能，开启它。没有的话，就要求 agent 每轮关键节点输出短 recap。 --- ## 10. 第七步：让 agent 自主推进，只在必要时问你 长任务里，低效交互通常是这样的： ```text 人：下一步做什么？ AI：我建议先看文件。 人：那你看吧。 AI：我看完了，建议修改。 人：那你改吧。 AI：改完了，要不要测试？ ``` 这会把人变成“确认按钮”。 更好的 prompt 是： ```text 请尽可能自主完成实现、测试和验证。 不要因为普通中间步骤停下来问我。 只有在以下情况才向我提问： 1. 缺少关键业务信息； 2. 存在不可逆或高风险副作用； 3. 多个方案会显著影响架构方向； 4. 需要访问我没有提供的外部凭据或系统； 5. 继续执行可能破坏数据或生产环境。 每完成一个阶段，请给出： - 已完成事项； - 修改文件； - 验证命令和结果； - 下一步计划。 ``` 这个 prompt 的目标是让 agent 从“问答机器人”变成“可监督执行者”。 --- ## 11. 第八步：给 agent 自我验证能力 如果你希望 agent 独立运行更久，就必须给它验证路径。 至少提供： ```markdown ## Verification - 单元测试：`pytest tests/ -v` - 格式检查：`ruff check .` - 类型检查：`ty check .` - 构建：`npm run build` - 白盒检查：`git diff --check` ``` 没有验证命令，agent 就只能靠“看起来对”。 推荐在 `AGENTS.md` / `CLAUDE.md` 里写清楚： ```markdown ## Before declaring done 1. Run the narrowest relevant test first. 2. Then run the project-level validation command if the change is broad. 3. Report exact commands and outcomes. 4. If tests fail, fix or explain why the failure is unrelated. ``` --- ## 12. 第九步：每周清理一次上下文债务 持续沉淀也会带来副作用：规则会变多、变旧、互相冲突。 所以需要定期清理： ```text [ ] 哪些规则已经过期？ [ ] 哪些规则太细，应该删除？ [ ] 哪些规则重复？ [ ] 哪些规则是一次性任务残留？ [ ] 哪些规则应该从全局下沉到项目？ [ ] 哪些规则应该从项目升级成通用 skill？ ``` 记住：**上下文不是越多越好，而是越准确越好。** --- ## 13. 可直接复制的复盘模板 ```markdown # AI Coding Agent Daily Review ## Scope 回顾最近 24 小时的 AI coding agent 会话。只读分析，不直接修改文件。 ## Look for - 重复错误 - 错误假设 - 缺失上下文 - 不必要工具调用 - 没有验证就宣布完成 - 反复询问本可自主判断的问题 - 多 agent 并发导致的人类上下文切换问题 ## Output ### 1. Repeated mistakes - Mistake: - Evidence: - Proposed prevention: - Where to store: AGENTS.md / CLAUDE.md / skill / script / test / discard ### 2. Missing context - Missing context: - Where it should be documented: - Suggested text: ### 3. Tooling opportunities - Repeated manual step: - Candidate script/hook/test: - Risk: ### 4. Agent autonomy improvements - Where agent stopped too early: - What prompt/rule would prevent it: ### 5. Do not preserve - Temporary or stale facts that should not become long-term context: ``` --- ## 14. 可直接复制的 agent 自主执行提示词 ```text 你是 coding agent。请尽可能自主完成任务，不要把我当成每一步的确认按钮。 工作规则： 1. 先阅读项目上下文文件，如 AGENTS.md、CLAUDE.md、README、测试说明。 2. 明确任务边界和风险。 3. 使用最小必要修改。 4. 自己运行相关测试和验证命令。 5. 遇到失败先尝试定位和修复。 6. 只有遇到关键业务歧义、不可逆副作用、生产数据风险、凭据缺失或架构方向选择时，才停下来问我。 完成时输出： - 修改了什么； - 为什么这样改； - 运行了哪些验证； - 结果是什么； - 是否还有风险或后续建议。 ``` --- ## 15. 最小落地版本 如果你只想今天开始，不要做复杂系统。先做这 4 步： 1. 写一个 `review-past-performance.md`； 2. 每周手动让 Claude 回顾最近会话； 3. 只把重复出现、证据明确的规则写进 `AGENTS.md` / `CLAUDE.md`； 4. 给 agent 加一句自主执行 prompt： ```text 请尽可能自主完成实现、测试和验证；只有遇到关键业务歧义、不可逆副作用或生产风险时才停下来问我。 ``` 做到这一步，就已经能减少大量重复解释和低价值确认。 --- ## 16. 常见坑 ### 坑 1：自动把复盘建议写进长期规则 不要这样做。AI 总结出来的是候选建议，不是事实。 ### 坑 2：把一次性任务状态沉淀下来 例如“某 PR 已提交”“某 bug 已修好”“今天测试失败”不应进入长期上下文。 ### 坑 3：只增加规则，不删除规则 长期上下文会腐化。必须定期删掉过时规则。 ### 坑 4：并发 agent 越多越好 并发上限取决于人的注意力。超过你能管理的数量，只会增加混乱。 ### 坑 5：让 agent 自主执行，但不给验证命令 没有测试和验证，自主执行会变成自主猜测。 --- ## 17. 总结 这篇文章真正值得带走的不是“凌晨 2 点跑一个 cron”，而是一种 AI coding 的复利机制： > 每次 AI coding 的失败和低效，都应该变成下一次更少出错的规则、脚本或上下文。 落地路径很简单： 1. 复盘最近会话； 2. 找重复错误； 3. 区分长期规则和临时噪音； 4. 写入合适的上下文层； 5. 给 agent 自主执行和自我验证能力； 6. 定期清理过时规则。 当你开始同时管理多个 AI coding agent 时，真正的瓶颈会从“模型会不会写代码”变成“你能不能管理好这些 agent 的上下文、节奏和验证闭环”。