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技术与业务的匹配
与"敏捷开发"的区别: 敏捷是项目管理方法，跨职能头脑风暴是项目选择方法

审计信息

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

cross-functional-brainstorming

Installation

Summary

Stronger alternatives

Similar popular skills

Also in this package

Agent compatibility

Repository health

Package contents

History

SKILL.md