开发者分享AI编码实践中降低心智负担的实用方法

分享几个我最近正在实践的，用 AI Coding 时降低心智负担的方法。

1. 尽可能避免并发任务，减少频繁切换上下文
人的大脑其实很像 CPU。任务切换得越频繁，就越需要不断重新加载上下文，很容易累。
所以我现在最多只让两个任务同时跑，最好其实只有一个。

等待 Agent 完成任务的时候，我也尽量不再开启新的工作，而是去阅读或者看视频。比如我会用 SentiaRead 把之前保存的英文文章、书籍认真读一读，一边积累词汇，一边从内容里获得新的启发。
我发现，相比不停切换任务，大脑专注于阅读和思考时，反而会更放松，也更愉悦。

2. 尽可能避免不停折腾工具
工具越多，需要做的选择也越多。

我现在基本只使用 Claude、Codex 和 Cursor，并且给每个工具划分相对固定的使用场景。
Claude 主要用来做产品方案、原型和 UI 开发；Codex 用来修 Bug，以及运行一些固定的自动化任务；Cursor 则负责日常迭代开发，还有平时突然冒出来的想法，我也会直接丢给它的 Cloud Agent 去调研。

每个工具负责自己擅长的事情，用久之后形成习惯，就不用每次开始任务之前都重新纠结该用什么。

3. 固定使用几个模型，减少“这个任务到底该用谁”的决策
模型也是一样。

比如在 Cursor 里，我默认使用 Fable 5 做编排和 Review，GPT Sol 5.6 负责编码。调研、评估、想法讨论和方案设计，也大多交给 Fable 5。
换到 Claude 里，整体分工逻辑差不多，只是编码模型会换成 Opus。

解决问题时，我通常先用 GPT Sol。遇到比较难解决、需要更多推理和分析的问题，再交给 Fable 5。
核心目的其实很简单：减少选择。
每多做一次“到底该用哪个模型”的判断，都会额外消耗一点注意力。
想得太多，就累。

4. 避免不停开新坑，用心打磨一两个真正需要的产品
过去我也很容易被新的想法吸引。
这个东西可能会火，那个方向可能有流量，别人做了一个产品，我也会觉得自己是不是也能做。

现在我越来越倾向于只认真打磨一两个软件和工具，而且最好是自己真正需要、自己愿意长期使用的东西。
因为真正需要的产品，你才会愿意不断优化细节。
然后再通过真实用户的使用反馈和付费获得正反馈，形成一个持续迭代的循环。
这种反馈，比追逐一个又一个“可能会火”的新项目稳定得多。

5. 在产品设计和程序设计上多花时间，减少后期不断救火
最近几个月，我反思自己做得不够好的一个地方，就是在 program design 上投入的精力还不够。

产品方向和整体架构其实都比较清晰，但继续往下拆，很多模块设计、接口设计、数据流、状态流转，以及具体调用流程，还没有做到足够清楚。
结果就是，功能虽然可以快速往前推进，但在迭代过程中，我有时候还是会觉得累，也会有一点不放心。

一旦前期设计不够细，后面很容易变成不断修 Bug，像打地鼠一样，一个问题解决了，另外一个地方又冒出来。
背后的原因其实也很简单。
有时候总想着再快一点，功能早点上线，问题早点解决，产品就能早点增长。
这个出发点没有问题，只是需要找到一个平衡。
有些时候，前面多花几个小时甚至一天把设计想清楚，反而会让后面的开发快很多，也轻松很多。

--------------

题外话，我回头想了一下，自己使用 AI 编程状态最好的时候，其实是 2024 年底。
那时候的模型没有现在这么强，Agent 能力也远不如现在。
我主要使用 Cursor Composer 推进开发。

虽然我几乎已经不怎么手写代码了，但除了产品和架构设计之外，我还会关注具体的模块设计、接口设计，以及每一层之间的调用流程。
所以那时候，我对整个产品和代码库其实非常熟悉。

当客户或者测试反馈一个问题时，我经常可以先在脑子里把调用链走一遍，大致判断问题最可能出现在哪个模块，然后把具体的背景、怀疑点和排查方向告诉 AI，让它继续分析、修复和验证。
这种状态其实非常舒服。

现在越来越流行完全不看代码，同时开很多 Agent 并发开发。我反而越来越觉得，人依然需要保持对产品、架构和关键代码路径的理解。
你不需要自己写每一行代码，也不需要人工检查每一个实现细节。
但你需要知道这个系统为什么这样设计，各个模块之间怎样协作，数据从哪里来，又会流向哪里。

当这些东西都在脑子里形成一张清晰的地图之后，AI 才真正变成了你的执行层。
这种开发方式，在我看来依然是目前效率最高、心智负担最低，同时也是最让我感到愉悦的一种状态。

思考本身是让人愉悦的。
拥有掌控力是让人愉悦的。
看到清晰的架构、干净的代码，以及一个自己真正理解的系统，同样也是让人愉悦的。
只有进入这样的状态，生产力才更容易长期保持，软件也更容易真正做好。