| 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?
- 企业刚成立AI团队，需要找到第一批AI落地项目
- 组织想启动AI转型，但不知道从哪个业务场景切入
- 技术团队和业务团队各自为政，需要一种协作机制对齐AI方向
- 咨询顾问在帮客户规划AI战略，需要结构化的创意发现流程
语言信号 (用户的话里出现这些就应激活)
- "我们该做什么AI项目"
- "怎么找到AI落地场景"
- "brainstorm AI ideas"
- "AI应用场景"
- "AI能从哪些地方帮我们"
与相邻 skill 的区分
- 与
automate-task 的区别: 自动化任务框架是"如何把一个方向拆解成具体任务"，跨职能头脑风暴是"谁来参与创意发现"——前者关注HOW，后者关注WHO。
- 与
ml-feasibility 的区别: 可行性双因素是评估具体项目是否可行，跨职能头脑风暴是在找到项目之前的创意生成阶段。
- 与
ab-mapping 的区别: A→B 映射是把问题形式化，跨职能头脑风暴是在形式化之前的创意探索。
E — 可执行步骤 (Execution)
当 skill 被激活后, agent 应按以下步骤执行:
-
识别AI专家资源
- 向用户提问："你们内部有AI技术专家吗？如果没有，是否考虑聘请外部顾问？"
- 完成标准: 用户能明确可用的AI专家资源（内部团队或外部顾问）
- 判停条件: 若用户完全没有AI专家资源且无法获取，建议先解决人才问题再启动项目
-
识别业务领域专家
- 向用户提问": "哪些业务线最了解痛点和价值？谁是那些领域的资深专家？"
- 完成标准: 用户能列出2-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
