夜雨聆风
大家好，我是王胖纸，Atlasnote 的独立开发者。
这一切听起来很美。
我尝试用 /goal 模式做了一个语音输入法。很简单：设定一个 prompt，给它一个目标，最后它跑出了一个还不错的结果。
然而对我而言，在这个过程中，我唯一的体验是，这个 /goal 功能到底能做到什么程度。内心却有一种很严重的失落感：我失去了对这个项目的所有判断和把控，它还算是我的项目吗？
而在日常开发中，我们更容易滑入的是另一种模式：打开 Codex、Cursor 或者 Claude，把报错信息一粘贴，模型几秒内吐出修复方案，点击接受，bug 消失，功能上线，整个过程行云流水。
只有一个问题：关掉编辑器的那一刻，你其实并不知道刚才发生了什么。
在这个循环里，曾经最重要的一个环节悄悄消失了：我们和问题之间那场搏斗。
单看一次，好像没什么。但如果这件事发生了上千次，上万次，我们的能力在一点点萎缩。最终，我们或许会退化成一双只会按 Enter 键的机械手。
在 AI 使用越来越系统、越来越顺手的当下，我不得不停下来问自己一个问题：我们到底该怎么用 Agent？
第一部分：判断哪些部分的工作值得保留
Agent 时代不是要回到手搓时代。关键是分清楚：哪些工作可以让渡给 AI，哪些必须留给自己。
可以放心交给 AI 的，是那些重复性场景。它们本身没有太多新的学习价值，或者我们已经通过自己写的 Skills，把这些场景编排成了稳定流程。之后的每一次都是调用这个模块工作，而模块本身，是你所熟悉并且参与创造的。
比如我之前写好的公众号排版 Skills、Epub 电子书 Skills、LLMs wiki 等等。再比如语音输入输出模块在不同产品中的重复调用。
这些工作真正重要的部分，已经发生在我们设计流程、拆解步骤、验证结果的时候；后续重复执行，就可以交给 Agent。
第二部分：把主动学习意图装回工作流
既然前提条件是，你是否带着主动学习意图，那就在日常的工作流中，把主动学习意图放在前面。
一、修 bug 之前，先写下自己的判断
比如在让模型修 bug 之前，先用两三句话写下你认为问题出在哪。然后让模型来验证你的假设，而不是替你思考。甚至在这个过程中，可以相互多轮互动，直到你知道为什么这是正确答案。
二、进入陌生领域之前，先问原理，权衡之后自己做决策
进入每一个陌生领域，不是直接让 Agent 去做，而是一起探讨方案，让它解释一下：这是怎么工作的？有哪些替代方案？各自的权衡是什么？理解了概念，再写代码。
三、把 AI 的输出当成初级同事的 PR 来 review
把 AI 的输出当成初级同事的 PR 来 review，读它、质疑它、反驳它。
四、让模型解释它为什么这么做
可以在模块中开启注释模式，让 Agent 对代码进行注释，让模型反过来教你，为什么它这么做。
我们之前讨论过我写的一个 atlasrules，这是一个纠正我英文语法以及 prompt 表达的 rules。同样，我们也可以写一个新rules，让Agent交付工作时，必须详细说明它为什么这么做。
这里不得不提的是，复刻也是一种非常好的学习方式。你可以让 Agent 先生成一版，然后自己手动重推一遍，把它生成的东西重新内化成你自己的东西。
五、用 /side 做学习复盘。
在主 session 中让 Agent 执行任务，同时可以启动 /side 命令，对当前 session 展开讨论和复盘：刚才的关键判断是什么？模型做了哪些技术选择？哪些地方我没有看懂？如果重新来一遍，我应该先学哪几个概念？
换句话说，Agent 不应该只是你的执行器。它也应该成为你的教练、审稿人和反方辩手。
每天问自己一次的问题
回到开头那个让我失落的瞬间：/goal 跑完之后，我不知道这个项目还算不算是我的项目。
如果不是，宁肯从第一步开始，一步一步慢慢搭建，或者将一个完整的代码架构从头研究一遍，而不是急于交付。
因为那看起来不是自己的作品，创造的乐趣，一方面来自结果，另一方面则来自于我们的认知边界的拓展。
结语
我们不需要在“用 AI”和“学习”之间二选一，但我们必须主动选择一种能兼顾两者的工作流。
因为产品的默认设置不会替你做这个选择。Agent 默认会接管一切，包括那些本该由你来拓展自己认知的部分。
它可以让你变成只会按 Enter 键的机械手，也可以让你变得更敏锐。区别只是：你打算怎么用它。
如果你对Atlasnote 感兴趣，可以到官网：atlasnote.ai 下载免费试用。也可以参考这篇Atlasnote使用指南。
AtlasNote 完整使用指南 v1.0：从零构建你的专属知识地图
如果你是一个AI新手，想要进阶了解更多AI知识，可以了解一下我的AI新手进阶65课：