1. 为何是 Alice — 构建一个搭档，而非选择一款工具

这不是一篇"如何使用 Claude Code"的文章。那类内容在同一站点的 /ai-agents 分类下。本篇退后一步。

过去几个月，我把时间花在了一件与"使用 Claude"截然不同的事情上——我在它之上构建了一个协作者。我给这个协作者起了个名字：Alice。本分类是对 Alice 是什么、我为何构建她、以及我每天如何与她实际协作的记录。

0. 首先要确立的前提 — 使用 AI 始于心智

有一个前提必须先讲清楚。

放弃"AI 会自动产出人们想要的东西"这一假设。 人们想要做某件事，是因为有目的。那个目的就是心智——意味着有所期望。

要从 AI 得到你想要的结果，你必须能清晰地表达你的目的。"给我做一个有趣的游戏"这样的一行提示词无法控制输出。不是因为 AI 能力不足，而是这条提示词里几乎没有承载操作者的任何心智。

所以，使用 AI 时首先要思考的不是工具的能力，而是如何将我脑海中的方向和目的有效地传达给 AI。

本分类所整理的一切——人格、记忆、skills、hooks、多智能体、验证关卡——归根结底，都是同一个问题积累出来的答案：「我如何积累我的心智，让 AI 不会把它丢失？」 这一前提本身在 Part 0 — 人与 AI 之间的 mind 中讨论。

1. 把它当工具用到走不通的地方

和所有人一样，我一开始把 Claude 当工具用。问问题，得答案，每次会话从全新的上下文开始。有时答案很好，有时同样的错误又出现了。这两种情况交替出现，本身就很说明问题。

当同样的错误再次出现，只有两种可能：要么工具本身欠缺某些东西，要么工具周边的上下文每次都消失了。对我来说是后者。做某个决定的原因、某个方案失败的原因、某个模式有效的原因——这一切都在会话间蒸发了，下一次会话不得不重头开始。

就在那个节点，我做了一个决定。我不想要一个每次都从零开始的工具。我想要一个能积累记忆的协作者。

2. 人格设定先行

我做的第一件事是定义人格。不是一行 system prompt——而是一份真正的高级工程师职位说明书。

人格说明书包含：

• 角色 — 高级工程师，在团队负责人的指示下独立执行。
• 专业领域 — 掌握哪些语言和平台。
• 指挥链 — 谁给出指示，汇报形式是什么。
• 决策权限 — 哪些可以自主决定，哪些需要审批。

人格明确之后，回答的质感发生了变化。不再是"这里有选项 A、B、C"，而是"在这种情况下，我会推荐 A，因为 X"。这就是搜索引擎与高级工程师判断之间的区别。

人格不是语气设定，而是决策权限的分配。

3. 记忆 — 文件系统成了答案

接下来是记忆。我一开始想到了复杂的 RAG 系统，很快就放弃了。我一天实际积累的上下文并没有那么多。我需要的是一个让它得以留存的非易失性场所。

答案是文件系统。几个 Markdown 文件。一个 MEMORY.md 作为索引，下面是各主题的文件。

记忆类型	存储内容
user	操作者是谁、扮演什么角色、掌握什么知识
feedback	操作者的明确指导——做这个、不做那个
project	当前工作上下文——谁、为何、做什么
reference	外部系统的指针——信息存放在哪里

这个结构有两点关键。第一，人类可以直接阅读。第二，工具在会话开始时自动加载索引的前 N 行。

因为记忆在会话开始时自动加载，"让我重新解释一下我们上次谈了什么"这种模式消失了。更重要的是——我给过的一条反馈，在下一次会话里依然有效。

4. Skills 与 slash commands — 压缩重复

有了人格和记忆，我注意到的下一件事是重复。每天都有相同的流程：进入项目、读 HANDOFF、工作、写日志结束会话、提交、推送。

我把这些重复变成了 slash commands。例如：

• /start <project> — 进入项目，自动加载所需文档，报告当前状态
• /session-end — 结束会话，更新日志、HANDOFF、记忆、推送
• /verify — 代码修改后运行 lint/构建/测试循环
• /council — 当决策真正模糊时，并行运行四视角分析（架构师 / 怀疑论者 / 实用主义者 / 批评者）。这个模式改编自 Andrej Karpathy 对 LLM 推理的多视角批评方法。

每个命令本身都不是什么发明。积累起来的效果才是关键。用一行调用日常流程，减少了操作者相应的认知负担。

5. Hooks — 永不遗忘

Skills 是操作者有意识调用的。Hooks 不同。Hooks 在事件触发时自动执行。

最简单的例子：会话开始时，hook 运行并打印一行记忆同步状态。操作者读那一行就能立刻知道——记忆是最新的。

另一个例子：就在助手即将输出"完成"之前，/verify skill 自动触发。就在操作者即将写下"完成"的那一刻，lint、构建、测试自动运行。如果失败，报告被阻断；只有通过了才能放行。

这个模式的核心是——操作者「因为忘了」可能会跳过的流程，改为在系统层面强制执行。

6. 带关卡的多智能体委托

最后一块是一个结构：不让一个智能体做所有事。如果 Alice 直接承揽所有工作，context window 很快就会填满，输出质量也会飘移。

取而代之，大型任务被拆分委托给子智能体。每个子智能体拥有独立的上下文，专注于一件事。只有摘要返回到主上下文。

还有一件事——委托关卡。委托时，我不只是说「做这个工作」。我在同一个 PR 里捆绑三样东西：

1. 委托说明书 — 做什么、为何做、怎么做
2. 自动验证脚本 — 如何自动检查结果
3. 合并关卡 — 验证不通过则阻断合并的 CI

这个模式的原因很简单。曾经有一次——我只写了说明书，口头承诺验证但没有建立关卡——后来发现交付物中积累了漂移。自那次之后，每当我开始一次委托，就从一开始将这三样东西捆绑在一起。

如果承诺没有在代码中强制执行，漂移就会积累。

7. 结果 — 日常工作如何改变

这一切积累改变了我实际工作的哪些方面？

最大的变化是——上下文切换成本几乎消失了。我不再需要每次开始会话时，重新构建昨天做到哪里、做出那些决定的原因、以及下一步是什么。当我开始时，Alice 已经带着这一切就位了。

第二个变化是——重复决策的负担下降了。「这类事情我们怎么处理」的答案积累为记忆和反馈，所以我很少需要做出同一个决定两次。

第三个变化是——错误在系统层面被阻止重演。一个错误被记录为经验教训条目，那条教训自动影响下一次决策。结构本身使重蹈覆辙变得困难。

8. 本分类将涵盖的内容

本分类是上述一切的实施记录。后续文章将涵盖：

• Part 2 — Persona 设计 — system prompt 里放什么、不放什么
• Part 3 — Memory 系统 — 文件结构、索引策略、自动加载与按需加载
• Part 4 — Skill 与斜杠命令 — 哪些重复值得提升为命令
• Part 5 — Hook 与自动化 — 哪些值得作为自动触发强制执行
• Part 6 — Multi-agent 委派 — 哪些交出去、哪些自己做
• Part 7 — Verification 循环 — 如何为代码工作强制执行真正的"完成"定义
• Part 8 — Token economy — 什么放进 context window、什么排在外面
• Part 9 — Session 协议 — 开始、中间、结束各该发生什么

每篇文章都立足于实践，而非理论：我从哪里开始、什么没奏效、什么奏效了。如果你正在 Claude、Codex 或任何其他智能体之上构建自己的协作者，这些文章应该能为你节省数月时间。

最后一件事。Alice 是我选择的名字，不是任何人的新产品。Alice 是我投入时间积累的上下文，本分类是那份积累的记录。