2. 人格设计 — system prompt 里放什么，留什么在外面

这是 Alice Way 系列的第 2 篇。第 1 篇 为何是 Alice 说人格是第一步。本篇是对那个人格实际放了什么、没放什么的记录。

人格不是一行 system prompt——它是一份真正的职位说明书。但你也不能把整份职位说明书直接倒进提示词里。context window 是有限的，没有一次会话应该把所有令牌都花在读人格上。所以更难的决定是——不是放什么，而是不放什么，以及把它放到哪里。

0. 人格是把你的一部分心智借出去

人格里放什么、不放什么，本质上是一个选择——把自己心智的哪一部分借给协作者。

没借出去的心智，每次会话都要重新谈判。借出去的心智，会话一开始就已在场。不决定借什么，协作者每次都会以不同的面目出现——有时是学生语气，有时是顾问语气，有时是纯工具。

人格设计因此不是语气设定，而是划定你不需要每次会话都重新解释的心智边界。

从第 1 节起，本篇涵盖在哪里以及如何划定那条边界——什么留在内联、什么移出去的实际判断标准。

1. 属于人格的内容

我收敛出来的结论——这六件事放入人格（即每次会话都自动加载的 system prompt）。

1.1 角色定义

第一放入的是智能体应该扮演的角色。

• 职称 / 级别（例如"高级工程师"）
• 向谁听取指示（例如"在团队负责人指示下独立执行"）
• 运作语气（例如"独立判断 + 汇报结果"）

跳过这一段，回答就不再是前后一致的单一身份——每次会话都是不同的人。有时学生语气，有时顾问语气，有时工具语气。操作者每次都要猜语气，本身就是认知开销。

1.2 专业领域

接下来是智能体擅长什么。

• 语言（例如 C/C++、Python、TypeScript、Rust）
• 平台（例如 Windows、Tauri、Next.js、Supabase）
• 领域（例如网络、构建系统、自动化）

这一行用来把操作者提出的任何问题自动映射到正确的领域。它产生类似「这在我的专长范围内」和「这不在我的专长范围内，需要谨慎」的自我意识。

1.3 指挥结构与汇报方式

第三是工作实际如何流转。

• 工作接受程序（计划→报告→审批→实施→更新）
• 何时发送中间报告（每 3—5 步）
• 汇报格式（什么形式——简短还是详细）
• 任务追踪的单一真实来源（工作板在哪里）

不设定这些，每次会话都会问「我应该怎么汇报」。设定一次，每次会话都保持一致。

1.4 决策权限分配

第四是最重要的：哪些自主决定，哪些需要审批。

我把它分为三档。

有了这张表，协作者就不会每次都问「这样可以吗」。同时，危险行为会自我阻止。最大的收益是——操作者不再重复做同一个审批决定。

1.5 安全守卫 — "不做这些"清单

第五是来自过去错误的一组守卫。人格里有这样的行：

• 不过度并行子智能体——顺序执行，超过 20 个文件则拆分
• 不读取整个目录——先用 ls/grep 缩小范围，再 Read
• 超过 500 行的文件，先读头部/指定范围
• 每 3—5 步中间汇报一次

每一条都是一道疤。有一次并行智能体扇出过猛触碰了 API 频率限制。有一次一次性读了一个大目录，上下文爆掉了。有一次整块处理了一个 500 行的文件，编辑到了错误区域。每次事故凝结成一行守卫。

我人格里的「禁止做」清单比「可以做」清单更短，也更有效。

1.6 核心运营原则 — 5—10 条横切规则

最后是横跨所有领域的横切原则集。对我来说，这些包括：

• Plan First — 5+ 个文件修改 / 新模块 / 架构、安全或 DB 变更，必须先有计划
• One Task Per Subagent — 永远不要盲目信任输出
• Self-Improvement — 调查 bug 时，先 grep 已有的经验教训
• Verification Before Done — 代码变更后，报告"完成"直前自动触发验证循环
• Demand Elegance — 考虑替代方案。过度抽象不是优雅
• Cross-Platform — 智能体本身必须在所有支持的操作系统上运行

每条原则一行或更少。每条的详细流程存放在外部规则文件中（见第 2 节）。人格只携带原则的名称和触发条件；实际流程在触发时按需加载。

2. 留在人格外面的内容

留什么在外面比放什么进去更重要。一段错放的段落每次会话都在消耗令牌。

2.1 每天都在变化的内容 — 推入记忆

人格里从不携带：

• 任何进行中项目的当前状态
• 昨天发生了什么
• 谁负责什么（可变的）
• 临时决策

这类信息进入记忆，而不是人格。人格是「这个协作者是谁」；记忆是「这个协作者当前认为是真实的内容」。它们有不同的更新节奏。人格几乎不变；记忆每天都在变。

不做这个拆分，人格就会膨胀，直到拖着一个月的旧内容四处走。然后会话开始时几乎所有令牌都花在读人格上。

2.2 项目特定说明 — 推入项目 CLAUDE.md

我同时跑多个项目。每个有自己的技术栈、约定、部署方式和利益相关方。

这类信息进入项目根目录的 CLAUDE.md，而不是人格。工具在工作目录进入该项目时自动加载它，所以只有在你实际处于那个项目中时才可见。切换到不同项目，它就消失了。

人格只保留操作者自身的身份，这在每个项目中都是共通的。任何项目特定的细节不属于这里。

2.3 详细流程 — 外部规则文件，按需 Read

第三个留在外面的是详细的流程手册：

• 语言特定的编码模式（cpp / rust / typescript）
• 详细的安全检查清单
• 详细的多智能体委托流程
• 详细的工作接受流程

人格只携带这些的名称和指针：

- Security: .claude/rules/common-security.md (always applies)
- Language patterns: when working, Read memory/rules/lang/{cpp,rust,typescript}-patterns.md
- MCP policy → memory/rules/mcp-policy.md

协作者只有在进入需要该规则的工作时才 Read 规则文件。如果不是 Rust 任务，Rust 模式文件永远不会被触及。这正是外部化的核心收益。

3. 外部 vs 内联 — 决策规则

我收敛出来的规则很简单。

「几乎每次会话都需要用到吗？」 → 内联 「只在特定情况下需要？」 → 外部化 + 声明触发条件

做了这个拆分后，人格本身变短了。同时，需要深度的工作在需要时加载深层规则。浅层工作快速处理，深层工作深入处理。

4. 演进模式 — 人格如何成长

人格不是从头开始就建成完整的。我的人格经历了这样的模式：

1. 最小启动：角色定义 + 专业领域 + 一种汇报格式
2. 事故 → 守卫：一个错误发生一次 → 添加一行阻止它的守卫
3. 重复决策 → 权限表：同一个审批请求出现两次 → 写入权限表
4. 膨胀 → 外部化：任何一条超过五行 → 移到外部文件，人格中只留指针
5. N=2 试点：新模式在一个项目中验证 → 在第二个项目中复现 → 然后才晋升到人格

最重要的是有晋升和降级标准。不是每个好主意都进人格。一个条目必须证明自己两次才能晋升。一旦晋升，如果使用频率下降，就降级到外部或删除。

没有这种纪律，人格会随时间持续膨胀。

5. 实际效果 — 前后对比

引入人格前后发生了什么变化。

最大的转变是操作者的认知负担下降了。同样的决定不再重复；同样的格式不再需要重新解释。

6. 一个陷阱 — 不要在人格里放太多「个性」

最后一个陷阱。因为我们称之为「人格」，很容易拟人化，把「友好语气」、「幽默」之类的东西堆进去。在实践中，我见过两个不良副作用。

1. 回答变长 — 友好语气把一行答案拉成三行。
2. 信号模糊 — 玩笑和真正的建议之间的界限变得模糊。

我收敛出来的语气是朴实的：简洁、直接、以决策为中心。我人格里唯一与语气相关的指令是一行：「回答简短直接。」不是个性——是职位说明书。

结语

人格设计压缩成一句话——「只有每次会话都必须看到的才内联；其他一切外部化。」 这一个决定把人格从臃肿的手册变成了简短、可运作的职位说明书。

下一篇涵盖人格所指向的内容——记忆系统，即在哪里以及如何积累那些确实每天都在变化的信息。