用自己的会话历史做成长复盘

代码审查是获得成长反馈的传统路径，但它有个内在缺陷：反馈是滞后的，而且依赖另一个人愿意花时间看你的代码。大多数时候，你在某段时间里反复卡在同一类问题上，根本没人告诉你——直到你自己意识到。

有一份原始数据其实一直躺在本地磁盘上没被用到：AI 编码助手的会话历史。你和它的每次交互，都隐含着你正在解决什么问题、哪里卡壳了、用了什么技术、最终怎么绕过去的。这些信息比 git log 更细粒度，比代码本身更能反映「解决问题的过程」。

从「用 AI 写代码」到「用 AI 看自己」

切换视角的关键在于：不把历史记录当作工作产出，而是当作行为数据。

具体做法是每隔一段时间（比如 24~48 小时），把这段时间的会话记录交给 AI 分析。它能识别出：

• 你反复触碰的技术领域——暗示你目前的核心工作方向；
• 同类问题出现的频率——一个问题被问了三次，大概率是盲区，不是偶发；
• 问题的解决路径长度——一次问到、两次问到、还是绕了很久才找到答案，差异很大；
• 处理问题的方式模式——喜欢先试错还是先查文档，遇到报错第一反应是什么。

这些观察放在一起，能形成一份比「我感觉自己最近进步了」更有依据的成长画像。

识别盲区比发现优势更有价值

复盘的最大用处不是确认你已经擅长的东西，而是找到那些「你不知道自己不知道」的部分。

这类盲区在会话历史里有一些典型信号：

• 同一个技术概念在不同项目的对话里被问到两次以上，但每次都像第一次遇到；
• 某类 bug 的修复过程很长，且对话里能看到多个错误假设被逐一推翻；
• 问题描述方式含糊——说明你还没建立这个领域的基本框架，不知道该问什么。

识别出这些信号后，行动方向也很具体：不是「多写代码」，而是「在这一个点上花几个小时补」。

把学习资源锚定到实际工作

通用的学习路线图有一个根本问题：它不知道你现在在做什么。「学好 TypeScript」和「你在最近三天的 API 设计里多次和类型守卫的边界问题搏斗」，指向的资源集合完全不同。

基于会话历史识别出盲区之后，可以做一个更有针对性的检索：拿具体的技术问题或技术模式去搜索相关讨论和文章。高质量技术社区上那些评论区活跃的帖子，往往能在两个小时内覆盖一个具体知识点的核心边界——远比通读一本书更直接。

这套路的本质是把「学什么」的决策权从「课程大纲」手里还给「你实际遇到的问题」。

节奏和频率的选择

每天做会太重，很快变成负担；每月做又太稀疏，信号都凉了。

比较合适的节奏是每周一次，花十分钟左右。不需要把报告里的每条建议都执行——选一个最扎眼的，接下来的几天里有意识地在相关场景里注意一下，往往就够了。

重要的不是报告有多完整，而是这个反馈循环的存在本身：你在持续地观察自己，而不是等别人来告诉你。

一句话心法

让历史记录替你做镜子——不是为了评判过去，而是为了让下一次遇到同类问题时，多走半步。