cross-functional-brainstorming

name	cross-functional-brainstorming
description	当用户需要启动AI项目的创意发现阶段，组织跨职能团队寻找AI应用场景时使用。 用户在问"我们该做什么AI项目"、"怎么找到AI落地场景"、"brainstorm AI ideas"时激活。 不适用于: 组织完全没有AI专业知识（无内外部顾问可用）、问题已明确定义无需创意探索的场景。

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

name: cross-functional-brainstorming
description: |
  当用户需要启动AI项目的创意发现阶段，组织跨职能团队寻找AI应用场景时使用。
  用户在问"我们该做什么AI项目"、"怎么找到AI落地场景"、"brainstorm AI ideas"时激活。
  不适用于: 组织完全没有AI专业知识（无内外部顾问可用）、问题已明确定义无需创意探索的场景。
source_book: 《给所有人的AI入门课》 吴恩达 (Andrew Ng)
source_chapter: p14, p24
tags: [ideation, cross-functional, brainstorming, project-selection]
related_skills:
  - slug: automate-task
    relation: composes-with
  - slug: triple-due-diligence
    relation: composes-with

跨职能头脑风暴 — AI专家×领域专家的交集

R — 原文 (Reading)

"我常组建包含AI知识专家及业务领域专家的团队共同探讨，以便共同识别两个集合的交集项目。"

— 吴恩达, p14

---

I — 方法论骨架 (Interpretation)

高质量的AI项目创意来自两个圆的交集： 第一个圆是"AI 能做什么"——这由 AI 专家掌握，他们了解当前技术的能力边界和可行任务类型。 第二个圆是"什么创造业务价值"——这由业务领域专家掌握，他们了解哪些流程成本高、哪些环节是瓶颈、哪些改进能带来最大回报。 单独让 AI 专家脑暴，会产生技术上可行但业务上无用的项目；单独让业务团队脑暴，会产生有价值但技术上不可行的想法。 只有当两类专家坐在一起，在"可行"和"有价值"的交集处寻找项目，才能找到真正值得投入的AI应用场景。 这个方法论的核心洞察是：AI项目的失败往往不是技术失败，而是"解决了错误的问题"。

---

A1 — 书中的应用 (Past Application)

案例 1: 呼叫中心

• 问题: 如何用AI改进呼叫中心效率
• 方法论的使用: AI专家知道"邮件自动分类"技术上可行 + 领域专家知道"邮件处理是呼叫中心最大工作量来源"
• 结论: 交集项目 = 邮件自动分类与路由
• 结果: 成为呼叫中心AI化的经典切入点

案例 2: 放射科

• 问题: 如何帮助放射科医生提高效率
• 方法论的使用: AI专家知道"X光片解读"技术上可行 + 领域专家知道"读片是放射科医生最耗时的任务"
• 结论: 交集项目 = X光片AI辅助诊断
• 结果: 医学影像AI成为最活跃的AI医疗应用领域

---

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. 企业刚成立AI团队，需要找到第一批AI落地项目
2. 组织想启动AI转型，但不知道从哪个业务场景切入
3. 技术团队和业务团队各自为政，需要一种协作机制对齐AI方向
4. 咨询顾问在帮客户规划AI战略，需要结构化的创意发现流程

语言信号 (用户的话里出现这些就应激活)

• "我们该做什么AI项目"
• "怎么找到AI落地场景"
• "brainstorm AI ideas"
• "AI应用场景"
• "AI能从哪些地方帮我们"

与相邻 skill 的区分

• 与 automate-task 的区别: 自动化任务框架是"如何把一个方向拆解成具体任务"，跨职能头脑风暴是"谁来参与创意发现"——前者关注HOW，后者关注WHO。
• 与 ml-feasibility 的区别: 可行性双因素是评估具体项目是否可行，跨职能头脑风暴是在找到项目之前的创意生成阶段。
• 与 ab-mapping 的区别: A→B 映射是把问题形式化，跨职能头脑风暴是在形式化之前的创意探索。

---

E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. 识别AI专家资源

   • 向用户提问："你们内部有AI技术专家吗？如果没有，是否考虑聘请外部顾问？"
   • 完成标准: 用户能明确可用的AI专家资源（内部团队或外部顾问）
   • 判停条件: 若用户完全没有AI专家资源且无法获取，建议先解决人才问题再启动项目

2. 识别业务领域专家

   • 向用户提问": "哪些业务线最了解痛点和价值？谁是那些领域的资深专家？"
   • 完成标准: 用户能列出2-3个关键业务领域及相关专家

3. 组织结构化头脑风暴

   • 建议用户按以下流程进行：
     • 第一轮：AI专家分享"当前AI能做什么"（列出可行任务类型）
     • 第二轮：业务专家分享"哪些环节最有价值/最痛点"
     • 第三轮：双方共同寻找交集，列出候选项目清单
   • 完成标准: 用户得到一份候选项目清单，每个项目都标注了"AI可行性"和"业务价值"两个维度

---

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 组织完全没有AI专业知识，也无法获得外部顾问支持（此时应先解决人才问题）
• 问题已经明确定义，需要的是执行方案而非创意探索
• 组织内部部门壁垒严重，无法实现真正的跨职能协作
• 决策层已有明确方向，头脑风暴只是走形式

作者在书中警告的失败模式

• AI专家和业务专家使用不同"语言"，导致沟通效率低下
• 头脑风暴产生大量想法但没有后续评估机制，最终无法落地
• 领域专家对AI能力预期过高或过低，导致项目选择偏差

作者的盲点 / 时代局限

• 方法论假设你能组建跨职能团队——现实中部门壁垒、知识鸿沟、权力结构可能阻碍真正的协作
• 书中未提供具体的头脑风暴 facilitation 技巧——实际操作中需要结构化的引导方法
• 方法论假设AI专家和业务专家能平等对话——现实中AI专家可能主导讨论，压制业务视角
• 未讨论远程/分布式团队的协作方式

容易混淆的邻近方法论

• 与"设计思维"的区别: 设计思维更关注用户体验和同理心，跨职能头脑风暴聚焦于AI技术与业务的匹配
• 与"敏捷开发"的区别: 敏捷是项目管理方法，跨职能头脑风暴是项目选择方法

---

相关 skills

• automate-task (composes-with): 头脑风暴找到方向后,用任务分解框架拆解具体可执行任务
• triple-due-diligence (composes-with): 头脑风暴产出候选项目后,用三重尽职调查深度评估

---

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• 测试通过率: 待测试
• 蒸馏时间: 2026-06-29