“专家”不是给模型换一个更响亮的头衔，而是把人设、方法论和工具链组合成稳定的任务视角。一个产品经理专家应该知道如何澄清目标、拆解需求和定义验收，而不是只在回答里多说几次“从产品角度看”。
专家适合解决什么
专家最适合有明确领域、需要稳定判断框架的单点任务，例如：
- 从用户、业务和实现约束审查需求。
- 按固定框架分析经营数据。
- 以品牌口吻检查一篇内容。
- 评估代码方案的边界和风险。
- 为一份汇报提出结构与叙事建议。
如果只是需要执行一个确定动作，优先 Skill；如果需要多人角色分工，考虑专家团。
在专家中心做第一次选择
进入左侧“专家”，先按行业或关键词查找。不要只看名称，重点阅读三类信息：擅长领域、任务示例、配备的工具。
选择时问四个问题：
- 我的任务是判断、创作、分析还是执行？
- 这个专家展示的方法是否与任务一致？
- 它是否需要我没有准备的文件或数据？
- 它配置的 Skill 或外部工具是否会扩大权限？
例如“写一份竞品报告”可能更适合市场研究专家，而“把已有报告排成 PPT”更接近文档或设计专家。任务名相似，真正需要的方法可能不同。
用同一小任务做对照
先把一个 10 分钟内可验收的小任务分别交给普通模式和候选专家。保持输入、模型、输出格式和时间要求一致，再比较：
| 维度 | 检查方式 |
|---|---|
| 结构 | 是否主动使用了合适框架 |
| 事实 | 是否区分材料事实与推断 |
| 可执行性 | 建议能否变成下一步动作 |
| 冗余 | 是否因为角色设定而过度表达 |
| 成本 | 质量提升是否值得额外轮次 |
如果专家版本没有明显提升，不必为了“专业感”强行使用。
召唤专家时仍要写清任务
专家不会自动知道你的项目背景。输入仍应包含目标、材料、受众、约束和交付物：
请以产品评审专家的视角检查这份需求草案。
受众是研发、设计和业务负责人；重点检查目标、范围、依赖、异常流程和验收标准。
请先引用草案中的具体内容，再列出问题与修改建议；不要补造不存在的数据。
输出为“严重问题 / 待澄清 / 可优化”三组清单。“你是资深专家，请深度分析”并不能替代具体上下文。
创建自定义专家
当你已经反复使用同一种判断方法，可以在“我的专家”中创建自定义角色。建议配置包含：
- **职责：**它负责哪些问题，不负责哪些问题。
- **方法：**处理任务时遵循的步骤和框架。
- **输入：**必须提供的材料与缺失信息处理方式。
- **输出：**固定结构、格式和质量标准。
- **工具：**确实需要的 Skill、MCP 或连接器。
- **边界：**哪些结论必须标记不确定，哪些操作需要确认。
避免写“精通所有行业、能够解决任何问题”。范围越宽，结果通常越难验收。
不要把专业意见风险交给角色名称
WorkBuddy 专家是 AI 辅助角色，不等于具备法定资质的医生、律师、会计师或投资顾问。涉及医疗、法律、投资、合规和重大商业决策时：
- 要求标明信息来源和不确定性。
- 不输入无权处理的个人或商业敏感信息。
- 把输出作为准备材料，不直接替代专业人士判断。
- 重要动作保留人工审批。
迭代专家配置
每次只根据真实失败修改一处。例如结果过长，就明确输出上限；总是忽略约束，就把约束放进方法和验收；频繁使用无关工具，就移除工具，而不是继续增加提示词。
保留三到五个固定测试任务。专家配置更新后重新跑一遍，可以防止“修好一种场景，却破坏另一种”。
完成检查
- 你能解释专家、Skill 和专家团的区别。
- 已用同一任务比较普通模式和专家结果。
- 自定义专家有职责、方法、输入、输出和边界。
- 只配置了实际需要的工具。
- 重大专业判断仍保留人工复核。