在 AI 这个行业已经十多年了。我的工作是用 AI 技术来开发各种 AI 产品。也就是说，我每天绝大部分时间都在和"AI 编程助手"（Code Agents）打交道。
这个领域变化非常快，几乎每天都有新工具、新框架、新方法出现。很多人会告诉你：必须马上跟上、全部采用。但当我认真回头看，真正让我长期保持高效的，其实并不是那些花哨的新工具，而是一些非常朴素、朴实无华的做法。今天我想分享我每天都在坚持的五个习惯。正是它们，让我能够持续专注、稳定输出。
1. 整理好你的背景信息（Context）------记录、记录、再记录
这是我能保持高效率最关键的一点，所以我把它放在了第一位。
我会实时记录我的决策过程------把它们当作可以反复使用的背景资料，方便之后提供给我的助手参考，并基于这些内容展开讨论。我会录音并转写通话内容，这样，在会议或通话中做出的决策不会随着通话结束而消失，而是会沉淀为我随时可以查阅的上下文信息。
对于任何技术主题，我都会维护两种不同层级的文档：
- 一种是架构决策记录（ADR），用来记录比较宏观、影响范围较大的决策。
- 另一种是技术决策日志，用来记录更细节、更具体的技术选择。
我非常重视这些文档的结构。我会认真通读它们，并和我的智能助手一起反复打磨、持续改进。这样做的结果是：随着项目不断推进，这些文档的质量也始终保持在一个很高的水平。
这带来的好处非常明显------每当我开始开发一个新功能时，我都能迅速找到相关背景，而不是重新思考一遍"当初为什么这么设计"。
一个小建议：文档一定要保持简洁、结构清晰，方便快速阅读。
这其实是一个巨大的优势。过去，记录本身是一件非常耗时耗力的事。但现在有了 AI，记录变得异常简单，很多环节甚至可以自动完成。既然成本已经大幅降低，为什么不把这件事做到极致呢？
这是一个"复利型"的习惯：我记录的每一个决策，都会让下一次与智能体的对话更加精准、高效。因为它从一开始，就站在一个扎实、完整的背景之上。
2. 聪明地管理你的"会话上下文"（也就是 AI 的记忆库）
这一点讲的是：在和 AI 协作时，你该如何管理它的"记忆区间"（即上下文窗口）。我每天能省下这么多时间和精力，很大程度上都归功于这一招。不过，我也是摸索了挺长时间，才学会像现在这样有意识、有条理地去管理它。
下面是几个对我很有帮助的方法：
- 关注上下文的使用情况，并在合适的时候交接会话。
在 Code 里，我会使用 /context 查看当前用了多少上下文空间，以及哪些内容占了主要位置。这样可以在上下文变得臃肿之前就及时处理。我的经验法则是：当上下文使用超过 60% 时，输出质量往往会开始下降------这时候，我通常会把任务交接到一个全新的干净会话中继续。
- 在对话分支变得过多之前就进行交接。
当一个工作会话开始不断"长出分支"------比如冒出一个值得单独深入的新想法------我会让智能体为这个分支写一份交接说明（handoff），并附上一个用于新会话的启动提示（starter prompt），指向这份交接内容。Claude Code 自带 handoff 功能，可以直接使用。通过复制粘贴启动提示，就能非常顺畅地开启新的会话继续工作。
- 把重要上下文存储在不会因重启而丢失的地方。
正如第 1 点提到的，我会把整理好的关键上下文放在文档系统（Slite）里。这样即使电脑重启、会话结束，也不会丢失；而且在开启新的智能体会话时，可以很方便地直接引用。当然，你也可以把这些内容放在代码仓库里，或者简单地存在本地文件系统中。
- 保持全局
CLAUDE.md尽量精简。
我的 CLAUDE.md 非常简洁，基本遵循 Karpathy 风格的"四条规则"。所有和具体仓库相关的内容，都放在它们该在的位置：例如编码规范和架构说明，写在对应仓库的 CLAUDE.md 或 architecture.md 里，而不是堆在全局配置文件中。
3. 快速做出原型，但上线前必须严格把关代码
AI 已经让写代码变得像买白菜一样简单，人人都能上手。有了 AI 编程助手的帮忙，现在想要快速验证一个想法，简直易如反掌。
我自己就是这个方法的死忠粉------每次有了新点子，我都会第一时间动手。先用 AI 快速拼凑出一个粗糙的雏形（也就是大家常说的"凭感觉写代码"），看看这个核心创意到底行不行。如果测试效果不错，我才会开始开发正式上线的版本。在这个阶段，虽然我依然会用 AI 智能体（Agent）来帮我写代码，但我会全程紧盯，深度参与。因为我必须清清楚楚地知道，自己到底把什么代码送上了线。
审查代码（Code Review）本身是一个环环相扣的过程。
- 第一步，也是最重要的一步： 我会和 AI 反复推敲功能的整体方案。这一步其实挺花时间的，因为必须把所有重要的细节都理清楚，防止 AI 瞎猜脑补。
- 第二步： 方案定好后，我会让 AI 把大任务拆解成一个个小模块，确保每个模块小到可以让人类轻松看懂。
- 第三步： 每一个小模块都是独立的，对应一个单独的合并请求（PR）。这样我才能真正看得懂、想得透，底气十足地把它们合并到主代码库里。
现在网上有很多声音在吹捧"全自动编程"------让 AI 自己去跑，写出什么就直接上线什么。他们认为，只要项目有完善的测试和安全防线，这就完全行得通。这话听起来有道理，对于某些边缘任务也确实管用。但我还是坚持要亲自审查那些真正上线的代码，因为这直接关系到用户对我们的信任，容不得半点马虎。
4. 限制同时进行的工作量
现在大家对"让多个 AI 助手同时干活"这件事感到兴奋不已------比如一次性跑好几个任务，用各种高级工具（比如 git worktrees）同时往一个代码库里提交不同的新功能，感觉自己一个人就能顶起一个团队。我也曾跟风尝试过这种做法，但说实话，但发现这对我们团队来说行不通。
当我同时处理太多不同的任务时，我的精力就会被严重分散，结果每件事的质量都跟着下滑。我的脑容量实在有限，根本没办法在脑子里同时装下那么多问题的细节，也就无法做出明智的决定。所以，我现在严格限制同时进行的任务数量，最多只留两三个，并且像守护阵地一样死守这个上限。
因为整个工作流程中，最关键的瓶颈依然是我个人的注意力。多开几个 AI 助手并不能解决这个瓶颈，反而只会让我的精力绷得更紧、更吃力。
5. 控制工具数量，不要什么都装
我绝不会在所有地方把所有工具都装一遍。我只保留一小套我真正会用到的"技能"（skills）和"连接器"（connectors）。只有在确实有硬性需求时，我才会添加新东西。
拿连接器和 MCP 服务器来说，我留下的都是每天必用的：比如我们的项目清单和个人文档系统，基本就这俩。你每多加载一个服务器，不仅增加了出错的概率，还会让 AI 的"脑容量"（上下文窗口）变得臃肿和混乱。
技能方面也是一个道理------我只用一套精挑细选出来的工程技能，它们必须是我信任、亲自测试过且表现优秀的。比如，我很喜欢 Matt Pocock 写的那套很有名的《真·工程师技能》（顺便说一句，这些技能其实超级简单），尤其是其中那个叫 grill-with-docs（用文档"拷问"你）的技能，它能逼着你把架构设计的每一个细节都想得清清楚楚。
写在最后
好了，以上就是让我每天工作都能保持高效的 5 个小习惯。
它们大部分其实都没什么高大上的，甚至有几个还显得有点"反潮流"、不跟风。
但这恰恰是关键所在：各种工具和技术会一直变，但只要守住这些习惯，我就能以不变应万变，永远不掉队。