cross-functional-brainstorming

## Source Metadata Original cangjie-skill frontmatter from the distillation run: ```yaml 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