写给愿意改变工作方式的知识工作者

我写这个系列，不是因为 Agent 这个词很热。

真正的原因是：AI 已经实实在在改变了我的工作方式。尤其是在写代码这件事上，我现在的工作比以前快了很多，而且质量不是靠运气维持的。

这件事对我很重要。

因为很多人对 AI 的感受是：它有时候很聪明，有时候又很不靠谱。它能写出一段漂亮的话，也可能编出不存在的信息；它能帮你打开思路，也可能把关键约束忘掉。

但在 coding 领域，我已经看到了另一种状态：AI 不只是一个聊天框，而是可以进入真实工作流的协作者。

原因不是程序员更会写 prompt，也不是代码领域有什么魔法。更重要的是，写代码天然有一整套外部约束：文件、项目结构、测试、类型检查、lint、git diff、日志、脚本、review、自动化流程。

AI 负责生成，人负责判断方向，而很多细节可以交给程序和规则检查。

所以在代码工作里，AI 可以被“管住”。它不是完全自由发挥，而是在一个有结构、有边界、可检查、可回滚的环境里工作。

我真正感兴趣的是：这套方法，为什么只能属于程序员？

知识工作者每天也在处理复杂任务：写报告、做方案、整理会议、分析客户、设计课程、研究资料、输出文章、维护知识库。

这些工作同样需要材料、判断、结构、流程和检查。只是过去我们很少把它们设计成 AI 容易参与的样子。

所以这个系列想做的事情很简单：把 coding 领域已经验证过的 AI 工作方法，翻译成知识工作者也能用的方式。

我不会教你追逐 fancy 概念，也不会把重点放在“神奇 prompt”上。我的关注点是实用 AI：怎么用材料、结构、规则、工具和校验，让 AI 在真实工作里变得更可靠。

这个系列也不是写给所有人的。

如果你期待的是一个万能 prompt，复制以后所有任务都自动变好，那这里可能不适合你。

但如果你已经感觉到 AI 有用，同时也愿意稍微改变自己的工作方式：把材料整理清楚，把任务边界说清楚，把结果拆成可检查的结构，把重要判断留给人，把重复检查交给程序，那么我觉得你会适合读下去。

很多 AI 问题，表面上看是“模型不够聪明”或者“prompt 没写好”，但真正的问题是：你还没有判断清楚这个任务到底是什么任务。

它需要哪些上下文？这些上下文是在聊天里临时给，还是来自你的长期资料、历史记录和工作习惯？

它是一个简单生成任务，还是一个需要多步推进、反复检查、持续迭代的任务？

它能不能让 AI 自己做完，还是必须在人类判断、规则约束、工具校验之间来回配合？

我会先用这些问题帮你定位任务坐标。坐标清楚以后，再看这个任务为什么需要 memory，为什么需要 subagent，为什么需要 skill，为什么需要工具和校验。

这样，这些概念就不是凭空冒出来的新名词，而是从真实任务里长出来的解决办法。

后面的文章，我会尽量从实际案例开始，不先堆概念。

比如一个任务做到什么时候，需要让 AI 记住长期偏好和历史材料；一个任务复杂到什么程度，需要拆成多个阶段甚至多个工作区；一套方法重复到什么程度，值得沉淀成 skill；一个结果重要到什么程度，必须加上规则、脚本或校验器。

我希望读者看完以后，不只是记住几个 agent 术语，而是能自己判断：我手上的这个知识工作任务，应该怎么交给 AI，哪里该补上下文，哪里该拆阶段，哪里该让人把关，哪里该用程序和规则兜底。

如果某一篇让你感觉解释跳得太快，或者少了前置知识，也欢迎直接告诉我。

这个系列本来就不是写给已经懂这些黑话的人，而是写给愿意改变工作方式的知识工作者。