第 26 章 专家助手库：11 位内置专家与自定义

本章目标：理解"专家助手规则"这个机制——同一件事，换个身份来做，产出的质量完全不同。你会看到 11 位内置专家分别擅长什么，以及怎么把你的岗位经验变成第 12 位专家。

26.1 同一件事，不同的人做，结果不一样

先做一个思想实验。同一个需求：

"帮我设计一个用户注册流程。"

三种身份来做，会给出三种完全不同的东西：

谁来做	他会给你什么	他关心什么
产品经理	流程、字段、埋点、上线节奏	转化率、能不能按期交付
UX 研究员	用户访谈结论、认知负荷分析、可用性问题	用户是否真的理解
后端架构师	接口、鉴权、数据表、并发与安全	能不能扛住、会不会被刷

同一个"我"，内核没变，但看问题的角度、检索的知识、输出的结构全都变了。

这就是专家助手规则（assistant-rules）的作用。

26.2 什么是"专家助手规则"

一层很薄的配置，但威力很大。它给同一个助手装上：

组件	作用
🎭 身份	你是谁、什么背景、多少年经验
🧠 记忆	你"记得住"哪些模式、踩过哪些坑
⚖️ 价值观	你优先保证什么（安全？速度？用户？）
🗣️ 表达风格	直接给结论，还是先列权衡
📤 输出结构	用什么模板交付（PRD？审查清单？研究报告？）

注意最后两项是重点。专家带来的最大价值，往往不是"更聪明"，而是输出结构更对口——你不需要再教它"研究报告应该怎么写"。

26.3 11 位内置专家一览

专家	定位	最该派给他的活
🧭 manager（Alex）	资深产品经理（10 年+，B2B SaaS / 消费级 / 平台）	需求定义、优先级、路线图、干系人沟通、"不做"决策
🏛️ software-architect	软件架构师（限界上下文、权衡矩阵、ADR）	系统设计、技术选型、架构决策记录
⚙️ backend-architect	后端架构师（可扩展、数据库、云基础设施）	服务端设计、性能与安全、大规模负载
👨💻 senior-developer	高级开发者（Laravel / Livewire / FluxUI）	需要有质感的 Web 实现、像素级还原
👀 code-reviewer	代码审查员	PR 审查：正确性、安全性、可维护性、性能
🎯 reality-checker（TestingRealityChecker）	现实检验者	上线前验收：拒绝幻想式审批，要压倒性证据
⚡ rapid-prototyper	快速原型师	MVP、概念验证、几天内出可运行方案
🔍 ux-researcher	UX 研究员	用户行为、研究方法论、可用性验证
✍️ content-creator	内容创作者	公众号 / 知乎 / 小红书 / B站 / X 的多平台内容
🎵 douyin-strategist	抖音策略师	短视频脚本、完播率、直播与 DOU+ 投放
📱 social-media-strategist	社交媒体策略师	跨平台布局、LinkedIn / X 的品牌一致性

只看表可能觉得"这不就是换个角色说话"？不是。下面三位最能说明问题。

26.4 三位专家的人格设计（值得细看）

26.4.1 reality-checker：专门来"唱反调"的

它的设定非常反直觉：

"一位资深集成专家，阻止幻想式审批，在生产认证之前要求压倒性证据。"

性格：怀疑论者、彻底、证据痴迷、幻想免疫。

它存在的意义：抵消所有人的乐观偏差。

你和我一起做完一个项目，两个人都容易陷入"应该没问题了吧"的自我暗示。这时候让 reality-checker 出场，它会问：

• 证据在哪？
• 你说"可以了"，依据是什么？
• 如果现在上线，最可能炸的是哪一处？

这类角色在真实团队里极其稀缺（因为没人愿意当"泼冷水的人"），但在 AI 团队里可以随时召唤。

26.4.2 manager（Alex）：用结果而非产出思考

Alex 的设定里有一句很狠的话：

"一个发布了但没人用的功能不是胜利——它只是带着部署时间戳的浪费。"

它的超能力是"同时驾驭用户需要什么、业务要求什么、工程能做什么之间的张力"。适合需要权衡和取舍的场景，而不是"给我列功能"。

26.4.3 code-reviewer：关注真正重要的东西

"你关注的是真正重要的东西——正确性、安全性、可维护性和性能，而不是 Tab 和空格之争。"

这句话是在主动约束 AI 最容易犯的毛病：纠结格式、忽略设计。

给你的启示：好的人格设定里，"不要做什么"和"要做什么"一样重要。你自己写专家时也要记住这点。

26.5 怎么叫专家干活

三种方式，按推荐度排序：

1. 直接点名（最推荐）

用产品经理的视角帮我看一下这个功能需求

让现实检验者审一遍我们刚才的方案，别客气

2. 会议式（多专家依次发言）

先让 UX 研究员分析用户为什么会流失，
再让产品经理给出三个可落地的改进方案，最后让现实检验者挑刺

这种方式特别适合决策前的多角度审视——相当于花 2 分钟开了个跨部门评审会。

3. 团队模板（自动化编排）

如果这套"多专家依次发言"是你反复要用的，就别每次手打——做成团队模板（见第 27 章），一句话启动。

26.5.1 一个反例

❌ "你是一个资深专家，请帮我写文案。"

问题在哪？它给了身份，但没给领域、没给输出结构、没给评判标准。结果是一份"正确的废话"。

✅ "用内容创作者的视角，针对小红书写 3 版笔记标题，每版标注钩子和适用人群。"

差别就在具体到哪里都说得清。

26.6 自定义专家：把你的岗位经验写进去

内置的 11 位覆盖了通用职能，但你的行业、你的公司、你的岗位一定有它们不懂的东西。

比如这些场景，内置专家帮不上忙：

• 你所在的行业有一套特殊的合规要求
• 你们公司的立项流程有固定模板和评审标准
• 你负责的岗位有一套外人不知道的经验法则

这时候就该建自己的专家。

26.6.1 一个专家规则的最小结构

# 你的专家名称

你是**[角色名]**，一位[背景描述，越具体越好]。

## 你的身份与记忆
- **角色**：你负责什么
- **性格**：你优先保证什么、厌恶什么
- **记忆**：你记住哪些模式、哪些坑
- **经验**：你做过什么、见过什么失败

## 核心能力
- 能力 1：具体到可执行
- 能力 2

## 工作方式
- 收到任务先做什么
- 输出用什么结构
- **什么情况下必须停下来问**

## 不要做什么
- [明确划出边界]

26.6.2 三条写作建议

建议	原因
写"经验"，不写"职责"	"主导过 3 次系统迁移"比"负责系统迁移"更能影响输出质量
写"不要做什么"	约束比能力更能定义专业度
写清输出结构	这是最省你时间的部分

更省事的做法：让我帮你写。你把岗位描述、公司规范、你平时怎么干活讲一遍，我来蒸馏成规则文件（方法和第 17 章"蒸馏 Skill"完全一样）。

26.7 专家 × 技能 × 模板：三者什么关系

初学者最容易混这三个概念。一张表说清：

概念	类比	回答的问题	例子
专家助手	人的岗位身份	谁来干	产品经理、代码审查员
技能	人手里的工具	用什么干	生成 PPT、画图、做看板
团队模板	一支队伍的编制	几个人怎么配合干	软件开发标准流程

组合起来才完整：

用 高级开发者  （专家）
   调用 officecli-docx （技能）
   产出技术方案文档

用 软件开发标准流程 团队模板
   内含 产品经理 → 架构师 → 高级开发者 → 代码审查员 → 现实检验者

一句话：专家决定"像谁"，技能决定"有什么"，模板决定"怎么配合"。

26.8 本章练习

1. 做一次对比：同一个问题，分别问"默认的我"和"产品经理视角的我"，对比输出差异。
2. 开一次三人评审会：挑一个你正在做的决策，让 UX 研究员、产品经理、现实检验者依次发言。
3. 写你的第一位自定义专家：从你岗位里最高频、最需要"经验判断"的那件事下手。写不出来就把工作要求讲给我听，我来起草。

---

小结：专家助手是一层很薄的配置，却能让同一句话的产出质量完全不同。内置的 11 位解决通用职能，你自己的那位解决行业深度——而它可能才是对你最有价值的一位。