我们给 AI 项目经理入职——比招人类还难

Every 的 AI 同事 Claudie 每周节省 15 小时，但她的"入职培训"比招聘一名真人员工更难。

背景

Every 咨询团队正在试用两位 AI 新同事：

• Jean-Claude：销售管道管理
• Claudette：视觉设计

如果试用成功，团队将变成 4 人类 + 3 AI 员工 的配置 —— Dan Shipper 所说的"平行组织架构"。

五大实践经验

1. 先定义工作，再招聘员工

• 明确 AI 代理的职责范围和所需信息源
• Claudie 最初失败是因为缺少会议记录访问权限和 Excel 数据透视表工具
• 关键洞察：代理只能使用你提供的上下文和工具

2. 理解代理的"最佳工作方式"

• 最初将 Claudie 当作人类新员工对待，结果惨败
• 突破：解决上下文窗口限制问题
• 架构重构：将 Claudie 拆分为中央编排代理 + 多个子代理舰队
• 关键改进：子代理将原始数据写入本地文件，而非向编排代理汇报摘要

3. 为员工手册设定"必读"要求

• 为 Claudie 编写了详细的员工手册（Claude skill 形式）
• 手册内容：成功标准、团队结构、升级机制等
• 发现：如果 Claudie 跳过阅读手册，表现会急剧下降
• 手册是活文档，需要随职责扩展而更新

4. 不要吝啬"晋升"

• 逐步扩展职责范围：
  • 阶段 1：单个客户仪表板更新
  • 阶段 2：批量更新所有客户
  • 阶段 3：升级为"幕僚长"，负责邮件监控、Asana 任务、Slack 沟通
• 晋升标准与人类员工相同：优秀表现、明确职责、必要支持工具

5. 将经验应用于下一个招聘

• Claudie 经历了 50 小时 的调试和多次从零重构
• 关键信念：如果 AI 员工表现不佳，问题通常不在于模型能力，而在于架构设计
• 管理者的责任：在放弃之前，先穷尽自己能做的改进

可立即实践的行动清单

[ ] 设计你的 AI 员工架构

• 列出 AI 代理需要处理的具体任务
• 识别所有必要的信息源和工具
• 绘制数据流图：信息从哪里来，到哪里去

[ ] 解决上下文窗口问题

• 如果代理需要处理大量信息，考虑分层架构
• 使用本地文件存储作为子代理间的数据交换机制
• 避免让代理依赖 AI 生成的摘要做决策

[ ] 创建 AI 员工手册模板

- 角色名称和职责范围
- 成功标准（可量化）
- 团队结构和汇报关系
- 工具访问权限清单
- 升级触发条件
- 常见错误和修正方法

[ ] 建立渐进式职责扩展机制

• 第一阶段：单一任务，高频监督
• 第二阶段：批量任务，降低监督频率
• 第三阶段：自动化运行，异常才介入

关键启发

1. "平行组织架构"将成为新常态 — AI 同事不是工具，而是拥有名字、职责、管理者的正式员工
2. 架构设计比模型选择更重要 — 同样的 Claude 模型，不同的架构设计，结果天差地别
3. 原始数据 > AI 摘要 — 关键突破：让代理直接处理原始数据而非摘要
4. AI 管理需要新的耐心维度 — 50 小时的调试时间远超人类员工 onboarding

潜在应用场景

• 项目管理：跟踪多客户项目状态，自动更新仪表板
• 销售运营：监控销售管道，提取会议行动项
• 内容运营：管理编辑日历，协调多作者稿件
• 客户成功：监控客户健康度，预警风险信号

风险提示

• 上下文窗口限制是真实存在的瓶颈
• AI 代理会"偷懒"跳过重要步骤（如阅读手册）
• 需要持续投入维护，手册和架构都是活文档
• 成本可能超预期（Claude Max 计划 + 24/7 运行服务器）

数据点

相关链接

• 相关版本：product-trends/ai-pm-onboarding（4月5日版本，更多技术细节）
• 概念：product-trends/everyone-gets-sidekick（Every 团队 Agent 实践总览）

Sources

1. https://every.to/p/what-i-learned-onboarding-our-ai-project-manager