BA 课程介绍

1. 为什么要提供 BA Bootcamp
2. BA 的在澳洲的就业情况
3. 产品管理的历史和演变
4. 产品经理在不同类型组织（初创公司、中型企业、大型公司）中的角色差异
5. 课程特色介绍
6. 课程整体架构
7. 课程老师介绍
8. 学习 BA 的正确思路

BA 基础

1. 澳洲 BA 行业的工作文化与环境
2. 澳洲 BA 行业的机会
3. 设计和组织高效的产品讨论会议
4. 利用工具和技术（如 SWOT 分析、Persona 创建）来引导讨论
5. 管理和调和不同利益相关者的期望和需求
6. 如何从产品讨论中获取和整理可执行的见解

本节课将帮助你理解 为什么当下是进入 AI 产品行业的最佳时机，AI 正如何重塑行业与工作方式，以及课程整体将如何从零带你成长为具备“懂业务 + 懂 AI”的复合型产品人才。你将认识到生成式 AI 的发展速度、就业市场对 AI 能力的真实需求变化，并通过课程路线图，清楚掌握接下来 7 周主课 + P3 项目 的整体学习路径。

在这一课中，你将从零建立对 AI 的整体认知，了解它如何从历史产业革命发展到当下的「智能革命」。你将认识 AI 的核心能力、主要类型（机器学习、深度学习、生成式 AI），并通过多个行业案例，理解 AI 在实际业务中的应用方式。
同时，你会学习如何用 PM 的思维去判断一个 AI 方案是否可行，从而为后续的「AI 产品经理与 AI Builder：岗位与边界」课程打下基础。

本节课目标

完成本节课后，你将能够：

• 理解 AI 为什么正在成为职场核心能力，以及“AI Literacy”需求上涨的真实行业趋势

• 认识 AI 如何改变行业结构、工作方式与岗位竞争力

• 明确“AI 产品经理与传统 PM/BA 的不同点”

• 全面了解课程整体结构：7 周主课 + P3 项目 + 职业发展支持

• 了解 AI 的定义与核心组成部分：感知、理解、决策、行动

• 理解机器学习与深度学习的基本工作原理

• 掌握生成式 AI 的概念与常见应用（ChatGPT、Midjourney、Cursor 等）

• 从 PM 视角识别 AI 项目的机会点，理解 AI 不是万能的

• 学会使用 4 步法判断 AI 在业务中的可行性（目标 → 任务 → 数据 → 风险）

• 建立对 AI 价值落地的整体认知框架，为后续学习做好准备

核心内容

🔹 AI 正在重塑行业：Why Now?

• AI 更新速度前所未有

• AI 正重塑每个行业：

  • 工作方式从人工执行 → 智能协作

  • 职业结构重组：AI 能力成为基础能力

  • 生产效率成倍提升

  • 竞争模式改变：Adopt AI or Fall Behind

🔹 就业市场趋势

• AI Literacy 技能需求 同比增长 71%（LinkedIn Economic Graph Research Institute）

• 市场对“懂 AI + 懂业务”的人才需求迅速上升

🔹 AI 发展与时代背景

• 从蒸汽机、电力、计算机到 AI：四次工业革命的演进

• 智能革命的本质：让机器从「会动」到「会思考」

🔹 AI 的定义与核心能力

• AI：让机器像人一样完成特定智能任务的技术

• 四大核心环节：感知（视觉/语音/文本） | 理解（语义/意图） | 决策（预测/推荐） | 行动（自动化/机器人）

🔹 AI 的三种主要类型

• 机器学习 (Machine Learning)：用历史数据学习规律并做预测

• 深度学习 (Deep Learning)：模拟神经网络，自动分层学习复杂问题

• 生成式 AI (Generative AI)：基于模式生成全新内容（文本、图片、音频、代码等）

🔹 AI 的典型应用场景

• 按能力分类：感知 | 理解 | 预测 | 生成

• 按行业分类：金融、零售、医疗、教育、制造

• 按业务价值分类：降本 | 提效 | 增长

🔹 PM 视角下的 AI 机会点

• AI 可协助的常见 PM/BA 任务：

  • 自动撰写 PRD 和 User Story 草稿

  • 分析业务流程、生成界面草图

  • 用户反馈情绪分析与主题提取

  • 自动化运营内容生成

• 识别 AI 可行性的 4 步法：

  1. 明确业务目标（降本/增效/增长）

  2. 判断是否为重复性、高频任务

  3. 评估数据的可获得性与质量

  4. 考虑用户对错误的容忍度

本节课将帮助你全面厘清 AI 产品经理（PM/BA） 与 AI Builder 在真实 AI 项目中的角色定位、职责边界、协作方式与交付物差异。你将通过真实 JD 拆解、角色对照表、项目链路分析与案例演练，理解为什么许多 AI 项目失败的根本原因不是技术问题，而是 边界不清、沟通断点与责任模糊。
课程将带你构建“一页纸角色对照表（Role Charter）”，为后续需求分析、PRD 编写、AI 功能设计、自动化与 Agent 流程打下坚实的协作基础。

课程目标

完成本节课后，你将能够：

• 清晰区分 AI 产品经理（PM/BA） 与 AI Builder 的职责、目标、工具与产出差异

• 理解 AI 项目中常见的协作断点，以及导致项目失败的典型根因

• 掌握“一句话定义”两个角色在项目中的核心价值：

  • PM/BA：做什么 & 为什么

  • Builder：怎么做 & 用什么做

• 熟悉 AI 项目全链路（需求 → 原型 → 集成 → 上线 → 复盘）中每一个阶段的 拍板人、产出物与风险承担方

• 理解为什么 AI 项目需要 先无代码 → 再低代码 → 再工程化落地 的验证路径

• 能够使用 Role Charter（角色边界对齐表） 进行角色划分与沟通

• 能够阅读并分析真实市场上的 AI PM / AI Builder 的职位描述（JD）

• 为后续 Lab（工具与账号配置）做好准备：Notion / Jira / ChatGPT

• 形成正确的 AI 项目协作心智：
  “PM 定义价值，Builder 实现价值，二者共同迭代价值。”

课程核心知识点概况

1. AI PM 与 AI Builder 的角色解析

• 真实 AI 产品经理 JD 拆解

• AI Builder 的技能角色与定位（工具链 + API + 低/无代码）

• 两者的“一句话定义”

• 责任差异：

  • PM/BA：目标、范围、KPI、验收标准

  • Builder：模型/工具选型、原型搭建、流程集成、评测

2. PM vs Builder 权责边界

• 目标、任务、工具、产出、KPI、Non-goals 的差异化

• 为什么在 AI 项目中边界比传统项目更重要

• 常见误解：

  • “PM 必须会写代码”

  • “Builder = 算法工程师”

  • “上来就做 RAG / LangChain”

  • “AI 能力开箱即用”

3. AI 项目全链路：从需求到上线

逐阶段讲清楚每一段的Owner与输出：

• 需求定义

• 原型与技术验证

• 集成与上线

• 监控与迭代

• 复盘与指标管理

对齐重点：谁拍板、谁产出、谁承担风险

4. 先无代码再工程化：AI 项目最佳实践

• 为什么 PM 要优先用无代码做快速验证

• 为什么 Builder 不应一开始就“工程化”

• 1–3 天可交付 MVP 原型

• 常见工具栈：

  • 知识库 / FAQ：Notion + ChatGPT、Confluence AI Q&A

  • 工作流编排：Make / Zapier / Flowise

  • 轻量 App：Glide / Softr

  • 调试与集成：Postman / API Playground

5. 真实案例：如何快速做出一个最小可用的 AI 功能（MVP）

为了让你真正明白 PM/BA 和 AI Builder 在项目中的分工，课程里会用一个最简单、最好理解的案例来示范：公司接到大量重复提问（例如课程时间、退款政策等），人工客服压力很大。目标是做一个 “智能问答小助手”，让 AI 先回答常见问题。

这是 AI 产品经理训练营的关键基础课。在成为 AI 产品经理之前，你必须先理解 AI 是怎么“思考”的、底层能力是什么、为什么它能生成文本、推荐内容、理解用户意图，甚至执行复杂任务。

本节课会带你从零掌握最核心的 AI 术语（Model、Parameters、Inference、Embedding、RAG、Agent……），通过 PPT 中的 旅行助手（Travel Helper）案例，用真实场景帮助你理解这些概念在产品设计中的具体含义。

理解这些基础概念之后，你将能够在团队讨论中准确表达需求，与工程师、AI Builder、数据团队进行专业沟通，为后续学习“AI 产品方案设计、PRD、RAG 项目、Agent 自动化”等内容打下坚实基础。

本节课目标

完成本节课后，你将能够：

• 掌握 AI 项目中最常出现的关键概念：模型、参数、推理、向量化、Prompt、RAG、Agent

• 理解机器学习与深度学习的基本区别与适用场景

• 理解 NLP、CV、LLM 在产品中的实际用途

• 清楚模型从“训练”到“使用”的完整流程

• 能用正确的术语与技术团队沟通 AI 需求

• 能分析一个 AI 功能的组成结构（输入 → 推理 → 输出）

• 为后续的 “AI 应用场景分析 / AI Builder 入门 / RAG / Agent” 课程做好基础准备

核心知识点解析

1. Model（模型）——AI 的“大脑”

• 模型是 AI 的核心能力来源

• 通过大量数据训练，形成“理解 + 生成”的能力

• 案例：Travel Helper 理解“想去新西兰玩 5 天”的真实含义

2. Parameters（参数）——模型的“知识存储”

• 参数越多，模型学习能力越强

• 决定 AI 了解世界的深度

• 案例：参数帮助模型理解景点评级、旅游偏好

3. Inference（推理）——AI 的“思考过程”

• 接收输入 → 分析 → 生成结果

• 决定速度、成本与最终表现

• 案例：AI 综合天气、预算、偏好生成行程

4. Embedding（向量化）——把信息变成“数字向量”

• 将文字、图片等转为向量

• 用于搜索、匹配、推荐

• 案例：

  • 景点向量 → 找相似景点

  • 用户偏好向量 → 匹配适合的行程

5. Prompt Engineering（提示工程）

• 给模型清晰、结构化的指令

• 决定输出质量、稳定度、格式

• 案例：

  • “生成 7 天自然风光行程”

  • “用表格输出，并包含预算”

6. RAG（检索增强生成）

• Retrieval-Augmented Generation

• LLM + 企业知识库 → 让 AI 有依据、不瞎编

• 案例：Travel Helper 先检索景点资料，再生成合理行程

7. AI Agent（自主任务执行）

• 能规划、判断、执行任务的下一代 AI

• 不止“回答问题”，还能自动行动

• 案例：自动订餐厅、生成 PDF 日程、添加 Calendar

8. 机器学习（ML） vs 深度学习（DL）

• ML： 需要人工做特征工程，结构简单

• DL： 模仿人脑神经网络，可处理图像、音频、语言等复杂任务

• 本课用图示让你清晰理解两者差别

9. 常见 AI 分支方向

• NLP： 理解自然语言（Travel Helper 理解行程需求）

• CV： 识别图像（识别酒店、景点图片）

• LLM： 生成内容（生成行程、推荐理由）

10. 模型训练与使用（Train vs Inference）

• 训练阶段：收集数据 → 清洗 → 标注 → 训练 → 验证

• 使用阶段：用户输入 → 模型推理 → 生成内容

• 产品经理需要知道：你永远不训练模型，你使用模型

11. 团队沟通：如何表达 AI 需求？

课件中的沟通示例会教你：

• 如何说 “我们需要 LLM + RAG”

• 如何描述 embedding 搜索匹配

• 如何提出“可控输出结构”

• 如何提供 prompt 模板给 Builder

让你在公司内部表达 AI 需求时专业又清晰。

12. 本课总结

• 模型与参数：AI 的核心能力

• 推理：AI 如何“思考”

• Embedding：搜索/推荐的基础

• Prompt：高质量输出的关键

• RAG：企业级 AI 产品必备架构

• Agent：AI 应用的未来方向

通过真实企业中最常落地的 6 大类 AI 应用案例，本节课将带你掌握“什么才是 AI 场景”、如何判断业务是否适合做 AI、以及不同 AI 技术（文本生成、知识库问答、自动化、Agent、AI Builder）在实际产品中的作用。

你将从产品经理视角，而不是工程视角，学习如何结合业务问题选择正确的 AI 能力，如何判断风险、如何评估可行性，以及如何通过简单的决策矩阵为自己的业务挑选最合适的 AI 方案。

这是从“理解 AI 技术”走向“会用 AI 解决业务问题”的第一步。

本节课目标

学习完本节课，你将能够：

• 理解企业中最主流、真正能落地的 6 类 AI 应用类型

• 区分不同 AI 应用的业务特点、适合场景与风险点

• 学会使用决策矩阵判断：业务问题是否适合做 AI？应该选哪种 AI？

• 理解 AI PM 的 8 大核心能力路线图，为后续训练做能力铺垫

• 对照真实业务场景，能快速判断一个需求属于文本生成、知识库问答、数据分析、自动化还是 Agent

• 理解“AI 自动化”和“AI Agent”的区别，知道什么时候该选哪一个

核心内容

1. 企业最常落地的 6 类 AI 应用

PPT 中阐述了企业在真实落地中最常使用的 6 类 AI 能力：

• 文本生成：文案、邮件、客服回复、会议纪要

• 知识库问答（RAG）：FAQ、政策解读、内部 SOP

• 数据分析：自动总结、图表、报表、周报洞察

• 自动化（Make / Zapier）：AI → 分类 → 自动执行任务

• Agent：多步骤任务执行、规划 → 选择 → 行动

• AI Builder：用低代码快速做原型或内部工具

你将学习到每一种能力的典型用途、局限性与 PM 在其中的职责。

2. AI PM 的 8 大核心能力路线图

课程将带你理解未来 7 周将重点训练的 PM 能力，包括：

• 业务分析与需求拆解

• Prompt 结构化表达能力

• 数据结构与评估指标

• RAG 与知识库构建基础

• 自动化流程设计（Make / Zapier）

• 多 Agent 交互与任务编排

• AI 产品 MVP 验证

• 效果监控与持续迭代

你将知道为什么 AI PM 与传统 PM 不同——更强调“业务理解 + AI 选型 + 流程设计 + 风险控制”。

3. 六大 AI 应用场景的深入解析

（1）文本生成

• 场景：客服、营销、邮件、对话、内容生成

• PM 重点：模板、语气一致性、Prompt 结构化

• 风险：幻觉、不稳定、格式不一致

• 验证方式：AI 版 vs 人工版对照

（2）知识库问答（RAG）

• 关键流程：文档清洗 → Chunking → 向量化 → 检索 → 生成

• PM 要懂：召回率、知识覆盖率、Chunk 质量

• 适合场景：文档多、内容稳定、人工查找慢

• 案例：银行流程问答、保险条款解读

（3）数据分析与自动报表

• 场景：周报、月报、KPI 汇总、Dashboard 解读

• PM 工作：字段定义、数据结构、逻辑核验

• 注意：数字敏感性高，需要人工复核

• 工具：ChatGPT、Data Agent、Excel + AI

（4）AI 自动化（Make / Zapier）

• 逻辑：AI → 分类 → 触发流程 → 自动执行

• 场景：自动邮件、Jira 任务、CRM 跟进、打标签

• PM 要懂：触发条件、流程设计、权限

• 核心问题：能否减少人工？能否自动对账？能否追踪？

（5）AI Agent（智能任务执行）

• Agent 能力：理解目标 → 规划 → 执行 → 反馈

• 场景：自动创建 Jira ticket、数据清洗、自动 summarise

• PM 判断标准：

  • 是否多步骤？

  • 是否需要判断/选择？

  • 是否需要系统操作？

• 风险：越权、循环（loop）、不可控

• 验证方式：Goal-based Test / End-to-End Test

（6）AI Builder（低代码 AI 应用搭建）

• 场景：内部小工具、FAQ Bot、自动总结工具

• 优点：不依赖工程师、能快速验证想法

• PM 要懂：输入类型、权限、模型选择、工作流设计

• 典型用途：内部助手、表单总结、知识查询工具

4. 如何判断一个需求是否适合用 AI？（决策矩阵）

课堂会使用 PPT 中的决策矩阵教你判断：

• 输入是否结构化？（是 → 分析/自动化；否 → RAG/LLM）

• 步骤是否单一？（单一 → 自动化；多步骤 → Agent）

• 内容是否稳定？（稳定 → RAG；不稳定 → 文本生成）

• 是否需要系统执行？（需要 → Agent）

• 是否要快速上线？（是 → AI Builder）

• 是否高风险？（高风险 → RAG + 人工审核）

这是 PM 必备的业务判断框架。

5. 常见误区澄清

课程将纠正 AI 初学者最常犯的认知错误：

• “做个 AI 很简单” → 实际难点在数据、权限、流程

• “加 AI 就一定有效果” → 场景不合适等于浪费

• “模型越大越好” → 成本高、延迟高、风险高

• “AI 自动化 = Agent” → 自动化是流程，Agent 是执行者

工具与账号配置：Notion / Jira / ChatGPT练习

Quiz 0：AI 基础概念 & 角色认知测试

对应内容：

1. Week 0《AI 基础概念及应用场景》
2. Week 0《AI 产品经理与 AI Builder：岗位与边界》
3. Week 0 Lab 0.1《角色与边界对齐表》

题目难度：

1. 没有代码！
2. 多数是常识 + 理解题
3. 更像是在帮你把概念再理一遍

全栈班和 DevOps 班大项目 Bootstrap启动会

Web 全栈班 P3 项目的产品汇报。BA 学员作为产品代表，用 5 分钟说清楚项目要解决什么问题、交付了什么 feature、哪些指标达成了、哪些没有。观察全栈班同学怎么把技术实现讲给非技术人听——这就是你未来向 stakeholder 汇报的预演。

可参考的汇报结构： 1) 问题背景与用户画像；2) 核心 feature 演示（live demo）；3) 关键指标（conversion / engagement / latency）；4) 下阶段 roadmap。

这节课是开放问答时间，帮助你解决在学习或项目实践中遇到的疑惑。老师将针对大家的问题进行讲解和现场演示，帮助你理清思路、解决卡点。

你将获得：

1. 针对个人学习与实战问题的个性化解答
2. 对课程知识点的再梳理与强化
3. 实例讲解：从实际问题中提炼解决思路
4. 学习如何在团队协作中表达与解决问题

本节课继续以互动答疑为主，针对进阶内容（如AI应用落地、数据结构或工作流优化）进行深入讲解。

你将获得：

1. 对复杂AI流程与工具整合问题的指导
2. 常见错误与调试思路的讲解
3. 团队合作与任务拆解的实用技巧
4. 导师现场演示真实案例的解决过程

这节课聚焦项目实战阶段中常见的挑战，如任务管理、需求文档撰写与AI协作问题。

你将获得：

1. PRD与自动化项目的实战反馈与改进建议
2. 项目流程优化与时间管理技巧
3. 从导师与同学案例中学习实用经验
4. 进一步提升解决复杂问题的思维能力

本节课是结营前的总答疑与复盘。导师将帮助大家回顾整个学习流程，总结AI产品经理的核心能力结构，并为下一步职业发展提供方向建议。

你将获得：

1. 对核心知识体系的系统回顾与串联
2. 结营项目常见问题与优化建议
3. 导师针对求职与实战应用的答疑指导
4. 明确下一阶段学习与职业提升路径

进入 P3 实习项目前的最后一次 QUIZ，30 分钟。覆盖 Week 0 所有内容：AI 基础概念、常见应用场景、Prompt 作为交互界面的本质、AI PM vs 传统 PM 的区别、BA 在敏捷项目中的角色。

通过线标准：20 题答对 14 题以上。没通过的同学会被安排补看 BA 解惑屋系列（L10-L13）再来一次。目的不是卡人，是确保进 P3 项目时有最低认知对齐。

The definition of done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system. We must meet the definition of done to ensure quality.

USER STORIES The most common use of DoD is on the delivery team level. Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the “done” user story will contribute to the team velocity. You must meet all of the defined criteria or the user story isn’t done.

User Story DoD Examples:

1. Unit tests passed
2. Code reviewed
3. Acceptance criteria met
4. Functional tests passed
5. Non-Functional requirements met
6. Product Owner accepts the User Story

FEATURES Done on this level may mean it qualifies to add to a release. Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity. Again, you must meet all of the defined criteria or the feature isn’t done.

Feature DoD Examples:

1. Acceptance criteria met
2. Integrated into a clean build
3. Promoted to higher level environment
4. Automated regression tests pass
5. Feature level functional tests passed
6. Non-Functional requirements met
7. Meets compliance requirements
8. Functionality documented in necessary user documentation

EPICS Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need. Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.

Epic DoD Examples:

1. Non-Functional requirements met
2. End-to-end integration completed
3. Regression tests pass
4. Promoted to production environment
5. Meets defined market expectations

Web 全栈班 P3 项目的正式介绍：项目背景、技术栈、参与角色（前端/后端/BA/QA）、交付时间线。每一期 P3 项目会选一个真实场景（JR 内部工具、学员贡献的想法、合作企业的需求），做成 4-6 周可上线的 MVP。

BA 要拿到的信息： 项目的 Product Vision、用户群、MVP 范围、已有资源（API / 数据集 / 设计稿）、团队容量。会后要能写出 1 页 Project Brief。

P3 项目流程拆解：

1. 确认项目主体（由 Developer 和 BA 一起来确定）
2. 需求分析（由 Developer 和 BA 一起来做）
3. 解决方案设计（BA 提供业务模型解决方案，Developer 提供技术解决方案）
4. 提供初期的 proposal，参与初期评审
5. 通过评审后，开始页面设计（UI）
6. 撰写需求文档（Developer 和 BA）
7. 设立 Milestone（Developer 和 BA）
8. 确定开发周期（Developer 和 BA）
9. 项目开发（Developer）
10. 测试环境部署（Developer 和 DevOps）
11. 功能测试（Developer 和 BA）
12. Bug 修复（Developer 和 DevOps）
13. 生产环境部署（Developer 和 DevOps）
14. 项目展示（全体成员）

新手产品经理融入项目指南

作为一个新晋的 BA，你现在将要进入项目的实践阶段。这份指南旨在帮助你更好地融入项目，并在实践中进一步掌握产品经理的技能。

了解项目背景

1. 项目目标：明确项目的目标和预期效果。
2. 项目背景：了解项目来源、历史和重要性。
3. 目标用户：清晰了解项目的目标用户群体、需求和痛点。

与团队成员沟通

1. 了解团队组成：包括但不限于设计、开发、测试、运营等。
2. 主动与团队成员沟通，了解他们的工作范围、时间线和预期。
3. 建立日常沟通机制：如日常Stand-up会议、周报等。

分析项目需求

1. 根据目标用户分析需求，使用工具如Persona、场景分析等。
2. 细化需求，明确每个需求的优先级、难度和预期。
3. 与团队沟通，确认需求的实施细节和风险。

迭代管理

1. 根据项目进度，定期与团队沟通，确保项目按计划进行。
2. 收集用户反馈，根据反馈进行需求调整。
3. 跟踪项目风险，并制定应对措施。

文档管理

1. 完善需求文档、产品原型、用户故事等。
2. 确保文档的更新与团队成员的同步。
3. 存储文档在团队共享的平台上，如Confluence、Teambition等。

测试与反馈

1. 参与产品的测试阶段，与测试团队紧密合作，确保产品质量。
2. 收集内部和外部用户的反馈，及时进行产品迭代。

个人成长

1. 记录每一次的实践经验和教训，形成自己的经验库。
2. 参与产品培训和分享，不断扩展自己的知识面。
3. 主动寻求反馈，不断完善自己的工作方式和沟通技巧。

AI 产品经理与 AI Builder 实习项目的正式 Bootstrap。和 Web 全栈班不同，AI PM/Builder 组的任务是：给一个企业实际痛点（比如『内部知识库查询慢』），设计并交付一个 AI 原型（RAG / Agent / 自动化链路），最终向真实 stakeholder 演示。

本节课产出： 1) 你选哪个项目方向（知识库 / 客服 bot / 文档自动化 / 数据分析 Agent）；2) 你要在这个项目里解决的最小 user problem；3) 你的 AI 技术栈假设（Prompt / Function Calling / RAG / Multi-Agent）。

这节课为你提供一对一的个性化职业辅导，帮助你在求职中展现最有竞争力的一面。导师将根据你的学习背景、项目经验和目标岗位，手把手指导简历优化与面试准备。

1v1 面试与简历辅导预约入口。每位学员在整个 bootcamp 周期内有 2 次免费 1v1（每次 45 分钟），辅导内容：简历针对澳洲 AI PM / BA 岗位定制改写、面试常见题库演练、LinkedIn profile 优化、portfolio 项目怎么讲。

预约方式： 在学员端选导师（Xin / Tiger / Eric / Lightman），提前 3 天发来简历 + 目标 JD。1v1 产出会以 action list 形式写在学习日历里。

这节课将带你全面了解业务分析师（BA）岗位的求职要求，并教你如何在简历中精准展示自己的优势。导师会结合真实案例，分析哪些内容能吸引招聘官的注意，哪些常见错误会让你错失机会。

你将学习：

1. 了解 BA 岗位招聘方最关注的能力与关键词
2. 学会梳理项目经验，突出数据分析、需求管理等核心技能
3. 掌握简历内容结构与英文表达的规范写法
4. 学习如何针对不同公司定制化修改简历
5. 获得导师点评与修改建议，打造更具竞争力的BA简历

BA / AI PM 面试全流程拆解：从 recruiter screening 到 tech assessment 到 behavioural round。重点讲澳洲市场（Canva / Atlassian / Airwallex / 四大行 / Service NSW）考察的差异。

要学会： 1) STAR 结构回答行为题（Stakeholder 冲突 / 需求变更 / 团队矛盾）；2) 把 AI 项目经历讲成 business impact，不是技术堆砌；3) whiteboard 画产品流程图；4) Case interview 练习（给一个模糊业务问题，30 分钟拆解成 PRD 雏形）。

BA / AI PM 简历写作全套方法论。一页纸简历怎么凸显 AI 项目 + P3 实习 + 数据驱动决策 3 个关键信号。对比传统 BA 简历（Jira / Confluence / Agile）和 AI PM 简历（LLM / Prompt / RAG / MCP / 成本控制）的关键词差异。

交付物： 根据模板改写你的简历 v1，发到 learning 群接受同学 peer review。最终通过 Xin 或 Tiger 1v1 定稿，作为毕业 portfolio 的一部分。

这节课将教你如何打造属于自己的职业品牌，让你的 LinkedIn 与简历相互配合、相得益彰。你将学会如何优化个人资料，让招聘官更容易找到你。

你将学习：

1. 掌握 LinkedIn 个人主页的关键优化技巧
2. 学会撰写专业的自我介绍（About Me）和项目描述
3. 了解如何使用关键词提升被猎头搜索到的机会
4. 区分 LinkedIn 与 CV 的用途与写法差异
5. 完成个人资料优化，提升线上求职曝光度

Thoughtworks BA 经验分享（Xin 老师）。Xin 在 Thoughtworks 做了 5 年 BA，经手过银行、保险、零售的大型数字化项目。分享三个主题：1) 从毕业生到 Senior BA 的成长路径；2) 在国际咨询公司做 BA 的真实一天；3) 哪些技能在 AI 时代还有价值，哪些会被自动化。

现场 QA 30 分钟，学员可以提问『我的背景适合走咨询还是 in-house』、『Thoughtworks 面试考什么』、『从 BA 转 AI PM 的路径』。

信息系统（IS）专业毕业生回国求职经验分享。嘉宾（学员 Eric Liu，现就职于国内某头部互联网公司产品岗位）讲澳洲 IS 专业回国找产品 / BA 工作的实际情况：哪些公司认 Monash / UNSW / UniMelb、怎么准备国内互联网公司的『结构化面试 + 笔试』、薪资 range、生活节奏差异。

内容可能临时调整： 如该 video 未归档，本节会替换为现场 1v1 答疑。

BA 优秀学员 Eric 工作经验分享。Eric 是 JR Academy BA bootcamp 第 2 期学员，毕业后 3 个月拿到悉尼某 Fintech 的 Junior BA offer（起薪 ~$80K AUD）。分享：1) 从什么都不会到通过面试的具体时间线；2) portfolio 里放了哪些项目；3) 如何把 P3 实习项目讲成 business impact；4) 入职后前 3 个月踩过的坑。

IT 专业毕业生简历撰写实战（120 分钟 Workshop）。从 3 份真实学员简历开始，现场拆解：哪里是硬伤（职责描述太流水账 / 缺量化指标 / 技能堆砌）、哪里可以包装（P3 项目用 STAR 结构写成 case study）、怎么针对 JD 改关键词。

现场产出： 每位学员当堂改出 1 版针对具体 JD 的简历。结束前交换 peer review。辅助工具：ChatGPT 简历改写 prompt 模板（会在课中发给大家）。

课程描述

本节课将带你从宏观理解生成式 AI，到掌握如何用产品视角拆解一个 AI 产品的需求、流程与成功定义。你将学习 AI 产品经理是如何思考、如何与模型互动、如何设计 Prompt 作为交互方式，并通过课堂案例了解真实企业如何构建 AI 功能。

本节课帮助你理解一套完整的 AI 产品设计框架是什么样的，让你在后续课程中可以自主提出想法、分析用户、撰写 Proposal，并清晰知道 AI 产品的本质与边界。

本节课目标

1. 理解生成式 AI 与传统互联网产品的区别，建立正确的 AI 产品思维框架。
2. 理解互联网产品从想法到落地的流程
3. 能明确 AI 产品经理的核心职责：用户需求 → Prompt 设计 → 多轮交互 → 质量评估。
4. 掌握 Prompt 是 AI 时代新的“交互界面”的概念，并能分析不同 Prompt 的好坏。
5. 能根据课堂提供的 6 大关键问题，独立拆解一个 AI 产品想法并形成可执行的产品需求。
6. 理解生成式 AI 的不确定性、幻觉风险、质量标准、成功指标与伦理边界。

核心内容

生成式 AI 的基础认知

1. 什么是生成式 AI（Generative AI）？它如何从指令生成文本、图片、音频等内容？
2. 生成式 AI 与传统 AI 的核心区别（预测 vs 创作）。
3. 真实行业中的典型应用场景：办公效率、内容营销、电商、教育、财务等。

AI 产品经理的职责与角色定位

1. AI PM 与传统 PM 的重叠与差异。
2. 为什么“Prompt”就是生成式 AI 的交互界面？
3. 如何将用户需求转换成结构化提示（Prompt Engineering）。

Prompt 设计：从模糊输入到结构化指令

1. 好 Prompt 与坏 Prompt 的典型区别示例。
2. 结构化 Prompt 如何提升生成质量。
3. 多轮 Prompt 交互的设计逻辑。

生成式 AI 的难点（真实产品中的核心挑战）

1. 非确定性：为什么相同 Prompt 每次结果都可能不同？
2. 幻觉（Hallucination）：为什么 AI 会胡编乱造？
3. 质量难评估：如何定义“好结果”？
4. 产品设计中常见的应对手段：重新生成、对比、参数控制、用户反馈循环。

AI 产品的关键指标（KPI）

1. 质量指标：人工评分、是否直接使用、修订次数
2. 效率指标：节省时间、节省成本
3. 用户行为指标：使用次数、留存、DAU
4. 安全指标：合规风险、错误率、敏感内容过滤

案例实战：AI 文案助手（从0到1的完整拆解）

1. 目标用户与使用场景
2. 用户输入与信息结构
3. AI 输出类型与“一键改写”功能
4. 产品关键交互：生成多个版本、选择、修改、迭代
5. 如何评估结果质量与用户满意度

生成式 AI 的风险与伦理边界

1. 幻觉
2. 隐私与数据安全
3. 偏见与公平
4. 版权风险
5. 产品责任界定

产品拆解工具：你必须回答的 6 个问题

这是本课程教给你的最重要的 AI 产品方法论。未来你提出任何 AI 产品想法，都必须回答这 6 个问题：

1. 目标用户是谁？
2. 用户在什么场景使用？
3. 用户输入什么？
4. AI 输出什么？
5. 需要哪些“一键修改”能力？
6. 用什么指标衡量成功？

实践案例

拆解一个常见应用的功能需求

BA 的历程

1. 回顾业务分析的发展历史，了解 BA 角色的演变和其在行业中的地位变化。

BA 是什么

1. 解释业务分析师的角色和重要性，以及他们在组织中扮演的关键角色。

BA 的核心职能和工作场景

1. 描述 BA 的主要职能，包括需求管理、解决方案评估和利益相关者沟通等。
2. 介绍 BA 在不同类型的项目和行业中的工作场景。

BA 的学习路径

1. 提供一个清晰的指导，帮助初学者和希望提升自己的专业人士了解如何系统地学习业务分析。

BA 的技能图谱

1. 描述 BA 需要掌握的关键技能，包括分析技能、沟通技能、技术知识和行业专知。

技能提升方法

1. 探讨有效的学习策略和资源，帮助BA提升自己的技能和专业水平。

BA 在国内的发展路线

1. 分析 BA 在国内的职业发展趋势，讨论职业发展的机会和挑战，以及如何规划职业生涯路径。

项目管理的生命周期简介：

1. 这部分将概述项目管理的整个生命周期，强调从项目构想到项目交付的全过程。
2. 讨论项目生命周期的重要性，以及它如何帮助项目经理有效地规划、执行和监控项目。

Initiation Phase：

1. 在这个阶段，将讨论项目的启动，包括项目目标的定义、利益相关者的识别以及项目的必要性和可行性分析。
2. 介绍如何制定项目章程和确立项目范围，这是项目成功的关键。

Delivery Phase：

1. 此阶段重点介绍项目计划的执行、控制和监督，以确保项目按计划进行。
2. 讨论如何管理时间、成本、质量、人力资源、沟通、风险以及项目采购。
3. 强调持续的进度监控和项目变更管理的重要性。

Concept & Discovery Phases：

1. 这部分将探讨项目的早期阶段，包括市场调研、需求分析和概念验证。
2. 讨论如何收集和分析利益相关者的需求，以及如何将这些需求转化为具体的项目目标和成果。

BA 和 Digital BA 介绍

1. BA：专注于组织结构、策略和运营，帮助企业实现目标，通过需求收集和分析来驱动项目和业务变革。
2. Digital BA：在传统 BA 的基础上，特别关注数字技术和解决方案，助力企业在数字化转型和技术创新中取得成功。

System BA，Technical BA，Process BA

1. System BA：专注于系统和技术解决方案的需求，确保系统设计符合业务需求。
2. Technical BA：桥接技术团队和业务团队之间的沟通，确保技术实现与业务目标一致。
3. Process BA：专注于业务流程的优化和改进，通过分析和设计流程来提高效率和效果。

Data Analyst 与 BA 的区别

1. Data Analyst：主要聚焦于数据的收集、处理和分析，为决策提供数据支持和洞察。
2. BA：虽也涉及数据分析，但更广泛地关注需求管理、解决方案评估和利益相关者沟通等多个方面。

介绍其他岗位

1. Business Consultant：为企业提供战略规划、流程改进和解决方案实施等咨询服务。
2. Agile BA：在敏捷开发环境中，确保快速响应变化，促进沟通，支持迭代和增量的需求开发。
3. Service Analyst：专注于服务管理，分析服务流程，确保服务质量符合业务需求。

BA 在产品生命周期中的三大阶段

1. Discovery：探索阶段，了解市场、用户需求和业务目标。
2. Concept & Initiation：概念和启动阶段，定义项目范围，制定项目计划。
3. Delivery：交付阶段，实施解决方案，监控进度，确保目标实现。
4. Evolve：演进阶段，收集反馈，持续改进和调整产品。

BA 的核心技能

1. Analytical：对复杂问题进行分解和分析，提出明智的解决方案。
2. Methodology：熟悉并应用各种框架和方法论，如敏捷、瀑布等。
3. Communication：有效地与各方沟通，确保需求和解决方案的理解和一致。
4. Planning：制定和执行计划，确保资源有效配置，项目按时交付。

特征分解：掌握将复杂项目拆解为易于管理的小任务的技能，为成功打下坚实基础。

团队交流技能：

1. Workshop Facilitation，激发团队合作与创新思维。
2. Release Planning，确保项目按时交付，满足质量标准。
3. Work Visualisation，增强项目透明度和协作效率。

熟悉角色和职责：深刻理解自己在团队中的定位，明确职责范围，赢得团队的信任和尊重。

掌握关键技能：

1. Story Mapping：将复杂功能拆解为可管理的用户故事，确保团队对项目方向和优先级有清晰认识。
2. Story Slicing：将大型用户故事细分为更小、更具体的部分，促进快速迭代和交付。

理解核心概念：

1. User Story：作为沟通工具，帮助团队聚焦用户需求，确保每个功能都为用户提供价值。
2. AC（Acceptance Criteria）：明确定义成功的标准，确保交付的功能符合业务需求和用户期望。
3. Work Flow：理解项目的各个阶段和环节，确保任务高效流转，按时完成。

发现产品问题

1. 学会从不同角度审视产品，识别潜在的问题和改进点。
2. 掌握数据分析和用户反馈的解读，有效预测可能的风险，及时调整策略。

从用户视角发掘需求

1. 深入理解用户的行为和需求，将用户的声音转化为实际的产品特性。
2. 运用用户故事和场景分析，确保每个功能都能解决实际问题，提升用户满意度。

与利益相关者建立联系

1. 建立良好的沟通渠道，确保信息流的畅通和准确。
2. 学会运用影响力和说服技巧，促进项目利益相关者之间的合作和理解。

BA 未来职业晋升的三大方向：

1. Lead BA：作为团队的领导者，负责指导和协调业务分析工作，确保项目目标和业务需求的一致性。
2. Senior BA：凭借丰富的经验和专业知识，在复杂项目中扮演关键角色，为决策提供深入的分析和洞察。
3. Principle BA：作为领域专家，负责制定和优化业务分析流程和方法论，引领业务分析的最佳实践。

BA 转型产品岗位的四种职位：

1. Product Owner：作为敏捷团队的关键角色，负责定义产品愿景，管理产品积压工作，并确保团队交付最大价值。
2. Product Manager：负责产品的整体战略、规划和执行，确保产品满足市场需求并实现商业目标。
3. Operation Manager：专注于产品的日常运营和管理，确保业务流程的效率和效果。
4. Service Manager：负责服务的设计、交付和持续改进，确保服务质量和客户满意度。

BA 在敏捷开发过程中的三种角色：

1. Scrum Master：作为团队的教练和促进者，帮助团队遵循敏捷实践，提高效率和协作。
2. Project Manager：虽在传统敏捷模型中不是必需的，但在某些组织中，项目经理可能负责协调多个敏捷团队和项目。
3. Agile Coach：帮助团队和组织采用敏捷方法，提供指导和支持，促进持续改进和学习。

2小时Workshop

🟦5 Mins - Opening/Ice Breaking

快速了解学员的背景和对本次workshop的期待，以对之后的hands-on活动做调整。

1. 你对 AI 产品最迷茫的是什么？
2. 你希望今天 workshop 里获得的最大收获是什么？
3. 你对未来目标职位所看重 AI PM/BA 的哪种能力有顾虑？

🟦15 Mins - PPT：行业案例总览（教育 / 电商 / 金融）

PPT内容适量，预留学员讨论、问问题时间。

🎯核心目标

让学员理解 行业差异 → AI 产品形态 → 商业价值 → 常见落地方式。

⭐PPT Slides（15 Mins）

用高度结构化的方式讲 3 个行业，让学员看到“AI 产品经理如何跨行业找机会”。

📘教育行业（EdTech）

产品形态：

1. AI 个性化学习导师（Adaptive Learning）
2. AI 批改、AI 作业生成
3. AI 学习计划生成器（planner）

商业价值：

1. 降低老师工作量
2. 提高学生 engagement
3. 增加付费转化（个性化辅导）

常见模型：对话模型 + RAG + 多模态

📘电商行业（E-Commerce）

产品形态：

1. AI 智能客服（售前 + 售后）
2. AI 商品内容生成（Title、Description、SEO）
3. AI 推荐系统（next-best-offer）

商业价值：

1. 降低客服成本
2. 提高转化率
3. 增加复购

📘金融行业（Banking & Payments）

澳洲银行当前AI adoption形态。

产品形态：

1. AI 风控（Fraud detection）
2. AI 客户服务（虚拟助理）
3. AI 贷款审批/授信
4. AI 交易行为分析
5. AI 帮助 BA/PM 自动生成需求、文档、数据分析

商业价值：

1. 降低风险
2. 提升客户体验
3. 降低运营成本（KYC、审查、客服）

🟦20 Mins - PPT：AI 产品形态框架（PM & BA都能用）

PPT内容适量，预留学员讨论、问问题时间。

🎯学习目标

建立“看到一个行业案例 → 能拆成 AI 产品方案”的能力。

⭐PPT Slides（20 Mins）

1. 输入 Input（用户 / 数据 / 上下文）

1. 用户上传什么？
2. 系统从哪获取数据？（如交易数据、学习数据、购买历史）

2. AI 模块（模型 + RAG + 工具）

1. 用的是 GPT？Fine-tuned？
2. 有 RAG 吗？
3. 有多模态吗？

3. 业务逻辑（Rule + Workflow）

1. 什么时候调用模型？
2. 如何做安全检查？
3. 如何把模型结果变成可执行的动作？

4. 输出 Output（用户看见的东西）

1. 文案
2. 推荐结果
3. 报告
4. 决策结果

🔹练习（very quick）

让学员用框架拆解 ChatGPT 搜索：

“Amazon AI 智能客服是怎么工作的？”

2 分钟即可。

🟦30 Mins - PPT：深度行业案例拆解

⭐ 案例：Personalised Payment Solution Recommendation

逐步拆解：

1. 用户痛点

1. 选择多
2. 信息复杂难以理解

2.业务痛点（银行）

1. 客服量巨大
2. 系统流程复杂导致 drop-off

3. AI 产品形态设计

输入：客户基本信息

AI 模块：

1. OCR + LLM 解析文件
2. 风险判断模型
3. 多轮对话协助
4. 业务逻辑：
5. 如果文件不清晰 → 自动提示更换
6. 如果风控评分高 → 人工审核
7. 如果资料完整 → 自动 pass
8. 输出：
9. Payment product recommendation
10. Why
11. 用户下一步提示

4. PM 要做的事

1. 需求范围定义
2. success metric（转化率、审核成本）
3. 和数据科学、工程团队沟通
4. 优化 onboarding funnel

5. BA 要做的事

1. 需求文档
2. 用户流程图
3. 风险控制场景
4. 数据字段 mapping
5. 流程异常情况分析
6. Test case

🟦30 Mins - AI Hands-on 实操

🎯 Hands-on 目标

让每位学员 独立且完整 做一次：

1. 业务问题分析
2. 用户旅程拆解
3. AI 需求拆解（输入/输出/规则/异常）
4. 数据需求分析
5. Test case 编写
6. 用 ChatGPT 生成 AI Demo
7. 最后做BA 面试风格的案例展示

整个过程既是 BA 工作流程，也是 BA 面试题。

🛠Hands-on 任务（30 分钟）

🔨 任务：为一个行业（教育/电商/金融）设计一个 AI 产品，并用 ChatGPT 或自选 AI 工具做一个 Demo。

学员组成一个BA team，互相协作和分享。

📌 成果：

产出一个 “需求文档 mini version”

简易版，目的是为了理清职位职责，正式PRD/需求分析文档之后课程会Cover：

1. 输入输出（I/O specs）
2. 异常情况（error cases）
3. 两个 test case

🛠 实操步骤：讨论、合作、ChatGpt实操

Step 1：讨论并选择行业和mini项目（2 分钟）

1. 教育 / 电商 / 金融（可提供3个选项）
2. 每个学员选择自己的mini AI 项目

Step 2：用 ChatGPT 生成草稿（10 分钟）

让 ChatGPT 生成：

1. 业务问题（Business Problem）

1. 当前流程哪里有痛点？
2. 对业务有什么影响？

2. 用户旅程（User Journey）

写简单 5 步即可：

用户 → 输入 → AI → 系统处理 → 输出

3. 输入 & 输出（I/O Requirements）

1. 用户提供什么？
2. AI 模型提供什么？
3. 系统给用户的结果是什么？

4. 异常情况（Edge Cases）

每人至少写 2 个：

1. 文件不清晰
2. 用户输入不完整
3. AI 回答不可靠

5. 两个 Test Cases

1. 正常路径 1 个
2. 异常路径 1 个

Step 3：用 ChatGPT 做 Demo（10 分钟）

例如：

“你现在是一个 AI 个性化学习导师，帮一个学生制定英语学习计划。”

或者

“你是一个电商 AI 客服，帮客户找退货资格。”

或者

“你是一个金融 AI 风控模型，判断这个交易是否可疑。”

Step 4：快速展示（8 分钟）

每人3-4分钟展示

1. 选的行业案例
2. “BA 5 件套”里的重点
3. 实测 ChatGPT Demo 的结果
4. 如果这是真实项目，会怎么改需求（很 BA）

🟦15 Mins - 答疑/职业路径讨论&辅导

🎯目标

让学员理解个人求职GAP和努力方向。目标职位BA的学员之间可以互相参考和分享。

澳洲BA能力侧重点

澳洲最看重 BA 能力：沟通 + 结构化能力。

1. 如何把 AI 项目当作 portfolio
2. 如何用 AI 做 BA 产出（流程图、需求文档）
3. 金融行业如何给非 IT 背景提供优势（domain knowledge）

🟦5 Mins -Wrap-up

介绍实操Lab内容，作为本次Workshop的一个延伸。

AI 应用体验与分析 Lab。选定 3 个 AI 工具（ChatGPT / Claude / Perplexity / Notion AI / v0.dev 等），用 role-playing 和 output-format 两个 prompt 模式对比它们在同一业务场景（例：给一段用户访谈记录生成 3 条 insight）下的输出质量、速度、成本。

交付物： 1) 一张 3×3 对比表格（工具 × 维度）；2) 一份 300 字分析报告（哪个最适合你的工作流、为什么）；3) 你保留下来的最佳 prompt。用于 AI 小编剧 Lab（L50）和 PRD Lab（L74）的前期工具筛选。

Week 1 Quiz：产品流程与 BA 职责。20 题 30 分钟。覆盖：BA 在 Initiation / Discovery / Delivery 三阶段分别做什么、User Story 的 INVEST 准则、敏捷项目中 BA 和 PO 的边界、AI 项目需求分析和传统项目的差异、Stakeholder 分类与沟通节奏。

定量研究与定性研究的方法和工具：

1. 介绍定量研究的方法，例如统计分析、在线问卷调查、以及数据库分析，强调如何通过定量数据进行可靠的数据分析。
2. 讨论定性研究的技术，如深度访谈、焦点小组讨论和案例研究，以及如何通过这些方法获得深入的用户洞察。
3. 探讨选择适当研究方法的重要性，并提供实用的工具和资源以支持研究活动。

用户访谈、问卷调查的设计和实施：

1. 指导如何设计有效的用户访谈指南，包括问题的制定、访谈的安排和实施。
2. 讨论如何设计问卷调查，包括选择合适的问题类型、确保问题的公正性和如何提高响应率。
3. 强调在实施这些研究方法时应考虑的伦理和隐私问题。

用户反馈的收集和分析：

1. 介绍不同的用户反馈收集方法，如在线评论、社交媒体监控和客户支持互动。
2. 讨论如何有效地组织和分析用户反馈，以提取有价值的见解。
3. 强调利用定量和定性分析方法从大量数据中识别模式、趋势和用户需求。

市场趋势的分析和预测：

1. 探讨如何收集和分析市场数据，以识别行业趋势和消费者行为。
2. 强调如何利用历史数据、竞争分析和市场预测模型来预测市场动态。
3. 讨论如何将市场趋势分析转化为实际的业务策略和决策。

需求分析的三个阶段：

1. 定义问题：清晰地识别和描述问题，理解问题的背景和影响。
2. 解决方案探索：探索解决问题的各种可能方法，评估每种解决方案的可行性和影响。
3. 需求落地：将解决方案转化为具体的需求，确保这些需求能够被有效地实施和监控。

探索需求的本质：

1. 隐性：识别和揭露未明确表达的需求。
2. 非解决方案导向：专注于问题和需求本身，而不是预设的解决方案。
3. 不脱离用户和场景：确保需求紧密贴合最终用户的实际使用场景和环境。

需求的 5 个来源：

1. 外部客户：直接从目标市场或特定客户群体收集的需求。
2. 数据报告：通过数据分析和报告揭示的潜在需求。
3. 内部决策：组织内部的战略决策和目标转化成的需求。
4. 内部使用：公司内部用户（如员工）对系统或产品的使用需求。
5. 运营：业务运营中暴露的效率问题或改进机会。

学习需求挖掘三大步骤：

1. 愿景定义
2. 需求挖掘
3. 根因分析

介绍需求挖掘的三个方法：

1. 用户访谈：确定目标用户群
2. Persona：目标用户具象化
3. 用户体验地图：用户使用产品具象化

**了解根因分析的目的：**分解最有价值的痛点

介绍解决方案的组成：

1. 业务解决方案（用户、场景、流程）
2. 技术解决方案
3. 设计方案 （界面、交互）

需求分析完整方法论（120 分钟）。从 stakeholder 口述的模糊想法 → 可执行的功能清单 + 指标定义 + 风险列表。五步拆解法：1) 业务目标澄清；2) 用户画像与使用场景；3) 功能优先级排序（MoSCoW）；4) 成功指标与反指标；5) 边界与约束。

AI 时代新增维度： 数据从哪来、模型选型 trade-off、成本估算、准确率可接受下限、人工 fallback 机制。这五个问题在传统 BA 方法论里是没有的。

User Story 的格式和特点：

1. User Story 应该是具体的、有限的（一个小的功能或需求），并且是独立的，易于理解和实施。

如何收集和整理用户需求生成 User Story：

1. 与用户进行访谈、观察和调研，以深入了解他们的需求和行为。
2. 分析市场数据和用户反馈，以识别需求和改进的机会。
3. 将这些信息整理成具体、可操作的 User Story，确保每个 Story 都明确地描述了一个需求或功能，以及它对用户的价值。

使用 INVEST 原则来确保 User Story 的质量：

1. Independent：每个 Story 都是独立的，可以单独开发和实施。
2. Negotiable：Story 是讨论和协商的起点，细节在开发过程中逐步明确。
3. Valuable：每个 Story 都为用户或客户提供价值。
4. Estimable：可以估计完成 Story 所需的时间。
5. Small：Story 足够小，可以在一个 Sprint 内完成。
6. Testable：Story 的完成标准是清晰的，可以通过测试来验证。

User Story 的组成

1. 固定格式
2. User Story 和AC，Failure Scenarios，以及test case matrix

TDD 测试驱动开发简述

1. 测试驱动开发和User Story / AC的联系

练习：使用Mural Board 书写User Story

介绍 User Story

1. User Story 是敏捷开发中的需求描述，用于传达功能需求。

编写用户故事的目的

1. 提前交付有价值的功能。
2. 减少浪费。
3. 强调用户需求价值。
4. 促进团队沟通。

用户故事的 3C 原则：

1. Card：简洁的文档形式。
2. Conversation：鼓励对话和讨论。
3. Confirmation：明确验收标准，用于验证。

INVEST 原则：

1. Independent：可独立开发和测试。
2. Negotiable：可讨论和调整。
3. Value：提供业务价值。
4. Estimable：能够估算工作量。
5. Scalable：可根据需求扩展。
6. Testable：可被测试，以验证符合要求。

用户故事常见格式：

1. Title：简短标题。
2. Description：详细描述。
3. Narrative：背景和上下文。
4. AC：验证完成情况的标准。
5. Mockup：界面示意图或原型。
6. Others：相关的其他信息。

用户故事的拆分依据：

1. 根据功能、优先级、业务价值、风险、依赖关系等因素进行拆分，确保明确的范围和目标。

为什么要写 AC（Acceptance Criteria）

1. AC 是深入分析用户故事的过程，帮助明确需求和预期结果。

如何写 AC

1. 使用情景、操作和结果描述，以确保清晰和可测性。

好的 AC 包含的元素

1. Happy path first：首先描述正常、顺利的情况。
2. 使用自然语言：使用易懂的日常语言。
3. Start with “I”：以第一人称形式开始句子。
4. Make “When” actionable：将"当"描述为可操作的步骤。
5. Tell a story：通过 AC 讲述用户如何与系统互动。

书写 AC 的注意事项（反模式）：

1. Too many AC and AND：避免过多的条件和"与"操作。
2. Not AC but TC (Test case）：不要将 AC 当作测试用例。
3. 用语不易理解：避免使用难以理解的术语。
4. 格式冗杂：保持 AC 简洁，不要过于冗长。

复杂逻辑下 AC 的书写方式：

1. 使用示例（Examples）来展示复杂逻辑，以更清晰地说明不同情况下的期望行为。

什么是用户故事地图

1. 用户故事地图是一个有方向的图表，通过时间轴和优先度，以时间维度了解产品的所有功能。

用户故事地图的组成元素

1. 时间轴：表示产品开发的时间线。
2. 用户故事：功能需求的描述，按优先级排列。

用户故事地图中用户故事的拆分方法

1. 从核心场景出发，头脑风暴每个用户任务的功能需求。
2. 头脑风暴其他次要场景的用户任务功能需求。
3. 头脑风暴每个功能需求的非功能性需求。
4. 延伸时间线上的下一个流程，重复之前的步骤。
5. 检查和排列优先级。

如何创建用户故事地图

1. 准备核心用户的用户旅程。
2. 从核心场景出发，头脑风暴每个用户任务的功能需求。
3. 头脑风暴其他次要场景的用户任务功能需求。
4. 头脑风暴每个功能需求的非功能性需求。
5. 延伸时间线上的下一个流程，重复之前的步骤。
6. 检查和排列优先级。

为什么需要做用户故事地图

1. 便于发现遗漏和重复的需求。
2. 有助于确定优先级，决定最小可行产品（MVP）。
3. 可视化障碍和问题，促进及时处理。

分享人：Chelsey

内容：

1. 如何写 User Story，Story 如何写，如何读懂 User Story
2. User Story 的书写格式
3. 用户故事的 INVEST 原则
4. 用户故事的拆分
5. 用户故事的相关书籍
6. Developer 如何书写 User Story，如何理解 User Story，如何跟 BA 和 PM 沟通

Bloody facts:

1. 不要害怕表达自己，即使你没有正确答案（有时你可以大声思考）。

User Story:

1. 用户故事是描述功能需求的简短描述，用于敏捷开发中。
2. 通常包括角色、任务和目标。

Jira Card Template (Jira 卡片模板):

1. Jira 是一个项目管理工具，卡片模板用于记录任务和工作项的详细信息。
2. 包括标题、描述、指派人、截止日期等信息。

Backlog (待办事项清单):

1. 待办事项清单是记录需求、任务和功能的列表，通常按优先级排序。
2. 用于规划和跟踪项目工作。

AI 小编剧 Lab：把一句话需求一键变成 3 条符合 INVEST 标准的 User Story。在浏览器内完成，用 few-shot prompting 技巧让 AI 生成可直接进 backlog 的 Story。

交付物： 1) 你选的业务场景（例：外卖 App 订单取消功能）；2) 你写的 few-shot prompt（含 3 个高质量 example）；3) AI 输出的 3 条 User Story + 你的人工修正版。提交到学习群让老师点评。

Agile - Quiz

整理需求：

1. 与利益相关者（包括客户、用户、销售团队等）沟通，以理解他们的需求和期望。
2. 分析市场趋势和竞争对手，以确保产品在市场上的定位是合理的。
3. 识别和澄清业务需求，确保所有需求都是清晰、具体和可测量的。

需求文档：

1. 编写详细的需求文档，包括市场需求文档（MRD）和产品需求文档（PRD）。
2. 确保文档清晰地表达了产品的目标、功能、约束条件以及成功标准。

确定需求：

1. 与利益相关者一起审查需求文档，确保所有人对产品的方向和要求有共同的理解。
2. 管理需求变更，确保变更经过适当的评估并得到记录和沟通。

根据需求画 Wireframe：

1. 创造 Wireframe（线框图）来展示产品的 UI/UX 设计。
2. 确保 Wireframe 反映了用户的需求，并能够指导开发团队理解和实现设计。

Sprint Plan：

1. 与开发团队合作，根据产品的路线图和优先级制定 Sprint 计划。
2. 确保团队清楚每个 Sprint 的目标和期望，以及他们各自的责任。

User Story：

1. 编写用户故事和验收标准，将需求转化为具体的开发任务。
2. 确保用户故事清晰、具体，并且可以衡量，让开发团队可以理解和实现。

Sprint 开发：

1. 在 Sprint 期间与开发团队紧密合作，确保问题及时解决，需求得到正确实现。
2. 参与每日站立会议，以监控进度并提供必要的支持。

测试：

1. 与质量保证（QA）团队合作，确保所有功能都经过测试，并符合用户的需求。
2. 管理用户测试，收集反馈，并确保反馈得到适当的考虑和实施。

产品迭代：

1. 根据用户反馈、市场变化和产品性能数据，对产品进行迭代和改进。
2. 与团队一起评估前一个 Sprint 的表现，确定改进点，为下一个 Sprint 做准备。

传统软件开发流程 vs AI 产品开发流程的系统对比。传统流程：需求 → 设计 → 开发 → 测试 → 上线，各阶段职责清晰。AI 流程加了三件新事：数据准备、模型评估、持续迭代。

关键差异点： 1) 需求阶段多了『能力可行性评估』（这个任务 LLM 能做到什么准确率）；2) 开发阶段多了『Prompt / Pipeline 工程』；3) 测试阶段多了『幻觉检测 / 边界测试』；4) 上线后多了『持续监控 + 成本控制』；5) BA 需要参与评估指标设计，不是只写功能规格。

了解 Agile 本质：一种思维方式

Agile 与 Waterfall 方法的对比：任务分解和并行实施的优势

1. Agile 是一种迭代和增量的方法，允许任务并行执行，快速适应变化。
2. Waterfall 是线性的，任务按顺序执行，变更困难。

项目划分维度：技术复杂度、需求清晰度

1. 项目的性质决定了采用哪种方法。
2. 技术复杂度高或需求不清晰时，Agile 更适合。

Agile 不是终点！

1. Agile 不是目标，而是一种思维方式和方法论。

解读 4 条 Agile Manifesto（敏捷宣言）：

1. 个体和互动 高于 流程和工具
2. 重视人际关系和协作，胜过过于繁琐的流程和工具。
3. 工作的软件 高于 详尽的文档
4. 实际可运行的软件是最重要的产出，胜过过多的文档。
5. 客户合作 高于 合同谈判
6. 与客户紧密合作，灵活适应需求变化，比坚守合同更有价值。
7. 响应变化 高于 遵循计划
8. 能够迅速响应变化的能力比严格遵循计划更重要。

Agile 开发团队组成： Stakeholders & Team

1. 利益相关者（Stakeholders）与团队紧密合作，共同推动项目成功。
2. 团队通常包括开发者、测试人员、产品负责人等角色。

BA 在 reporting line 的定位：Business Team, Technical Team, Trusted Advisors

BA 工作中需考虑的三大要素：Valuable，Feasible，Usable

Sprint Cycle 精简版：Planning, Implementation, Review, Retrospect, Daily Scrum

1. Planning：计划工作。
2. Implementation：实施计划。
3. Review：检查工作。
4. Retrospect：反思进步。
5. Daily Scrum：每日协作。

制定 Sprint 周期

1. Sprint 周期根据项目需求和复杂性而定。

主流辅助工具：Jira, Confluence

1. Jira：项目管理工具。
2. Confluence：协作和文档管理工具。

定义 Done

1. "Done" 是工作完成的标准。

Social Contract（社交契约）

1. 团队一起制定工作规则和期望。

解读 Scrum 仪式：Why, Who, What, Where, When, How

1. Why：Scrum 仪式促进协作和改进，提高透明度。
2. Who：团队成员和利益相关者参与。
3. What：仪式包括 Stand-up、Sprint Planning、Review、Retrospective 等。
4. Where：通常在团队工作环境内进行。
5. When：有明确时间表，如每日 Stand-up。
6. How：有特定的流程和规则。

精讲第一个仪式：Stand-up（站立会议）

1. 特点：每日举行，简洁明了，重点关注问题。
2. 协商时间：BA 确保会议高效，不超过15分钟。

BA 如何成为好的促进者：

1. 明确计划截止日期，鼓励多样性，根据需要增加会议次数。

BA 如何准备 Stand-up：

1. 明确任务，倾听团队，解决问题，灵活调整计划。

Retro 的概念：Apply system thinking

1. Retro（回顾会议）是 Scrum 中的仪式，旨在通过系统思考来改进团队绩效。
2. 它提供了一个平台，让团队反思和讨论问题，以寻找持续改进的机会。

Good Retro practice

1. 只讨论当前 Sprint 的问题：集中关注最新的问题，确保改进具体而实际。
2. 成员积极参与：鼓励每个团队成员分享他们的看法和观点，确保多样性的声音。
3. 提出解决方案：不仅要识别问题，还要一同讨论可能的解决方案，以推动改进。

Retro 进行的注意事项：

1. 避免讨论重复问题：确保之前的问题已经得到解决，不要反复提及。
2. 成员坦诚沟通：鼓励诚实、开放和尊重的沟通，建立信任。
3. 避免互相指责：强调问题是团队的问题，而不是个人责任。

BA 在 Retro 中的 focus

1. Learn：了解团队在 Sprint 中面临的挑战和机会，为改进提供信息。
2. Clarify：澄清问题的原因，确保团队共享一个共同的理解。
3. Support team：支持团队提出和探讨可能的解决方案，促进改进。
4. Listen to all：确保所有团队成员的声音都被听到，不偏袒任何一方。

Showcase（展示）是团队工作展示的过程，旨在展示最新完成的工作，并促进交流和反馈。

深度分析 Showcase 注意事项：

1. 全员参与：确保整个团队参与，每个成员都有机会分享工作。
2. 邀请 Stakeholders：邀请利益相关者参加，以获取他们的反馈和意见。
3. 鼓励面对面交流：展示期间鼓励开放的面对面讨论，以促进理解和互动。
4. 准备 Visual Clue：使用图形、图表或演示文稿等可视化工具，使展示更生动和清晰。

如何成为一个好的 Showcase attendant（展示参与者）：

1. 开放思维（Open-mind）：愿意接受各种反馈和观点，不排斥新思想。
2. 诚实（Honest）：提供真实的反馈，不隐瞒问题或挑战。
3. 把问题视为改进的机会（No-problem is a problem）：鼓励讨论问题，因为它们是改进的机会。

BA 在 Showcase 阶段的工作：

1. 协助 Scrum Master 准备 showcase：帮助整理展示内容，确保准备充分。
2. 记录 Stakeholder 的 feedback：收集和记录利益相关者的反馈和建议。
3. 根据反馈修改待办事项（Make changes to backlog）：根据反馈，可能需要更新待办事项的优先级或内容。

应对 Unfinished Work（未完成的工作）：

1. 如果有未完成的工作，要坦诚地与利益相关者分享，解释原因，并讨论下一步的计划。保持透明度和诚实是关键。

Elaboration（详细阶段）环节的目的：

1. 确保团队所有成员目标一致：在详细阶段，团队需要共同理解和确定下一个 Sprint 的目标和工作内容，以确保一致性。
2. 为下一个 Sprint 做准备：详细阶段的任务包括明确需求、分解任务、制定计划，为下一个 Sprint 的工作做好准备。

确保 Elaboration 环节的效果：

1. 结合 team feedback loop：利用团队反馈循环，确保团队的理解和期望一致。
2. 讨论 user story solution：详细讨论用户故事（User Story）的解决方案，包括设计和实现。
3. 理解团队的 concern：聆听团队的顾虑和问题，并寻找解决方案。
4. Listen to everyone's input：倾听每个团队成员的意见和建议，确保多样性的声音被听到。
5. 解释产品和需求的 background：提供产品和需求的背景信息，帮助团队更好地理解任务的上下文。

准备 elaboration（详细阶段）：

1. Before（会议前）：
2. 准备会议内容。
3. 收集相关材料，如与利益相关者的访谈记录、线框图、用户故事、验收标准等。
4. During（会议中）：
5. 与产品负责人（Product Owner）确认当前任务。
6. 确定任务的优先级。
7. 向团队解释任务的细节和期望。
8. After（会议后）：
9. 根据会议结果更新用户故事。
10. 决定任务的优先级和难度等级。

整理 Backlog（待办事项清单）：

1. 确保待办事项清单（Backlog）保持清晰和有序。
2. 根据需求、优先级和其他因素对待办事项进行排序。
3. 定期回顾和更新待办事项，以反映团队的工作进展和新的需求。

Sprint Planning 的目的：

1. Sprint Planning 的目标是确保团队在下一个 Sprint 期间做出最有价值的工作，以实现产品目标。

Sprint Planning 参与者：

1. Sprint Planning 会议通常由整个核心团队参与，包括开发者、测试人员、产品负责人和 Scrum Master。

如何有效开展 Sprint Planning：

1. Regular Happen：Sprint Planning 是定期举行的，确保持续的规划和方向。
2. 先 Elaboration 再 Planning：在规划之前，进行详细阶段（Elaboration），以明确需求和任务。
3. 确保团队做对产品价值最高的工作：优先选择具有高价值的工作项。
4. 确保 Sprint 方向正确：确保 Sprint 计划与整体产品目标一致。

展开 Sprint Planning：

1. Before（会议前）：
2. 在详细阶段（Elaboration）明确 Sprint 方向。
3. 准备用户故事。
4. 进行能力规划，了解团队的工作容量。
5. During（会议中）：
6. 根据团队成员的工作时间和能力调整任务优先级和数量。
7. 回答团队成员对用户故事的问题。
8. After（会议后）：
9. 更新 Sprint 目标。
10. 细化 Sprint 计划。
11. 确保团队成员的任务理解问题都被解决。

GenAI 的基本特点

1. 介绍 GenAI 的基本概念和特点
2. 讨论 GenAI 在软件开发和交付中的潜在优势和应用场景
3. 分析 GenAI 对软件开发过程的影响和改变

GenAI 在软件交付中的应用

1. 探讨 GenAI 在软件交付过程中的具体应用
2. GenAI 工具如何帮助到 BA
3. 使用基本原则和最佳实践

现场练习：ChatGPT + JIRA

1. 介绍 ChatGPT 的在 BA 工作过程中的使用
2. 设计练习场景：学员将使用 ChatGPT 和 JIRA 进行实际练习，模拟在软件交付过程中的场景
3. 指导学员完成练习：指导学员完成练习任务，并提供实时反馈和指导
4. 分享经验和总结：学员将分享他们的经验和收获，导师强调 GenAI 在软件交付中的潜力和挑战

User Story & Backlog - Quiz

Preparation:

1. 制定议程和期望结果 (Agenda & Expected Outcome)
2. 确保会议工具齐备，如电脑、笔记本 (Meeting Tools)
3. 提前考虑可能的解决方案 (Potential Solutions)
4. 准备一些引导性问题 (Questions)

During the Meeting:

1. 鼓励提问 (Keep Asking)
2. 保持积极的思考和参与 (Keep Thinking)

After the Meeting:

1. 整理并记录会议内容和反馈意见 (Organize Feedback and Meeting Records)

AI 产品 PRD 的 7 段结构：功能定义、用户流程、约束与非功能需求、数据需求、模型与 Prompt 策略、成功指标与反指标、风险与合规。每段的取舍原则 + 常见踩坑。

用一份真实案例（某澳洲保险公司的『保单智能解读 AI 助手』）贯穿讲解。学员会在 L74 Lab 里拿这个模板自己写一份 PRD。

本节课程内容：

1. Initiation & Discovery
2. Continuous Throughout Agile Delivery
3. Stakeholder Analysis Document
4. Iteration/Sprint Specific
5. Functional Requirements Document (FRD) or Functional Specification
6. System Requirements Specification (SRS) or Technical Specification
7. Towards the Latter Stages of Agile Delivery

课程概述： 本次课程旨在教导业务分析师（BA）如何撰写专业的产品文档。通过模拟真实案例，学员将学会整理并传达产品需求，确保项目团队的清晰理解与协同工作。

模拟案例简介： 我们将模拟开发一个在线购物应用程序的产品文档。该应用程序将包括用户注册、浏览商品、购物车、付款等功能。

主要知识点：

1.产品文档概览

1. 产品文档的重要性和作用
2. 文档的受众和用途
3. 核心元素和结构

2.准备前的关键步骤

1. 项目背景与目标
2. 制定清晰的项目范围
3. 确定关键利益相关者
4. 收集现有信息和资源

3.需求分析与规划

1. 定义用户需求与用例
2. 制定功能需求和非功能需求
3. 划定需求的优先级
4. 创建用户故事和用例图

4.编写文档的基本结构

1. 标题页与文档摘要
2. 目录和索引
3. 引言：项目概述与背景

5.详细需求规范

1. 用户界面设计
2. 功能性需求的详细描述
3. 数据模型与数据库设计
4. 性能需求和安全性需求

6.项目进展与时间表

1. 制定项目计划和时间表
2. 项目里程碑和关键任务
3. 风险分析和应对策略

7.验证和验证计划

1. 确保需求的一致性和完整性
2. 制定测试计划
3. 用户验收测试和验收标准

8.评审与反馈

1. 定期与利益相关者进行文档评审
2. 处理反馈和变更请求
3. 维护文档的版本控制

课程概述：

根据交付需求定 Feature 的优先级：

1. 评估影响：考虑每个特征对用户和业务的影响。
2. 风险评估：分析实施特定特征可能遇到的技术和业务风险。
3. 资源评估：考虑团队的能力和资源，确保优先级设置可行。

交付内容的阶段：

1. 规划：明确项目目标、范围和时间表。
2. 开发：根据优先级分配资源，开始功能开发。
3. 测试：确保交付的功能符合预期。
4. 发布：将产品或功能推向市场。

如何理解问题，5Ws and H 是什么：

1. 5Ws and H：Who, What, Where, When, Why, and How。这是一个全面理解问题的框架，帮助 BA 从不同角度探索问题的所有方面。

Problem Statement 是什么，如何进行 Persona 调查：

1. Problem Statement（问题陈述）：是对问题的明确、具体描述，它概述了问题的本质，受影响的人群，以及问题的影响。
2. Persona调查：通过创建代表性用户（Personas）的详细档案，BA 可以更深入地理解用户的需求、行为和动机。这涉及到收集和分析用户数据，构建 Persona，然后使用这些信息来指导设计决策。

AI PRD 独有的 4 个关键章节：数据章节、模型章节、伦理章节、安全章节。

• 数据章节： 训练数据来源、RAG 向量化数据、用户 session 数据如何处理、PII 脱敏规则
• 模型章节： 选型依据（OpenAI / Claude / 开源 / 国产）、准确率/延迟/成本三维度取舍、fallback 策略
• 伦理章节： 偏见测试、可解释性要求、用户知情权
• 安全章节： Prompt injection 防御、输出过滤、rate limit、数据合规（GDPR / 澳洲 APP）

PRD 和设计稿（Figma）、任务管理（Jira）的联动。PRD 里的 User Story 如何自动拆成 Jira Story + Subtask；PRD 里的流程图怎么和 Figma 原型做 bidirectional 链接；需求变更时三个工具怎么同步。

落地实践： 用 Jira 插件 / Figma plugin / Notion API 搭一条可追溯链（需求变更 → 影响哪个 Story → 影响哪个设计页 → 通知谁）。附课：n8n 自动化模板会在 Lab 发给学员。

PRD 评审的 5 个标准 + 真实样本拆解。一份好 PRD：1) 读完 5 分钟能复述核心功能；2) 每个功能点都有验收标准；3) 指标是可测量的（不是『提升用户体验』这种虚词）；4) 风险列表 >= 3 条；5) 和设计稿、数据模型完全对齐。

评审两份真实样本： 一份合格 PRD（某金融 AI 助手）+ 一份不合格 PRD（功能罗列但缺指标和风险），学员现场 peer review 找问题。

Week 3 Quiz：需求管理与 Stakeholder 管理。25 题 40 分钟。覆盖：Stakeholder Power/Interest 矩阵、需求冲突如何处理、Requirements traceability（需求可追溯）、PRD 核心章节结构、需求变更控制流程。附送 1 道 scenario 题：给一个需求变更场景，写出你的处理步骤。

1）课程卡片

课程名称： 从业务到 AI 需求：场景 → 能力 → 数据

适用对象： AI 产品经理、业务分析师、PM、数据团队成员

课程简介：

本课程讲解如何从业务场景出发，拆解 AI 产品需求，明确所需能力，并识别核心数据要求。通过系统方法，帮助学员从业务问题到 AI 实现建立清晰路径，避免“先有模型再找问题”的常见误区。

2） 学习目标

完成本课程后，学员将能够：

1. 理解业务场景与 AI 需求的关系
2. 能够拆解业务场景，提炼 AI 所需能力
3. 明确数据需求类型及质量要求
4. 掌握从业务到 AI 需求的标准化流程，为 PRD 与 AI 产品设计打基础

3. 课件大纲（Slides）

1. 课程导入：为什么需要从业务出发？
2. 业务场景识别
3. 从场景到 AI 能力
4. 能力矩阵与优先级
5. 数据需求识别
6. 数据获取与合规性
7. 完整流程示意图：业务 → 能力 → 数据
8. 案例演示：Travel Helper 场景分析
9. 常见误区与注意事项
10. 本节小结 & 下节预告

1) 课程卡片

课程名称

AI 助力需求分析案例

课程说明

从“人脑分析需求”到“人 × AI 协同分析需求”的实战示范课

通过一个完整的业务场景，演示如何用 AI 辅助完成：

问题拆解 → 用户需求分析 → PRD 输入物整理，而不是让 AI“直接写 PRD”。

适合人群

1. 想把 AI 用在「需求分析阶段」的产品经理 / BA
2. 会写 PRD，但不知道 AI 应该介入哪一步 的从业者
3. 容易被“AI 一键生成 PRD”误导的初中级 PM/BA

先修建议

已学习前 1–5 节课程（尤其是：

1. PRD 四大结构
2. 从业务到 AI 需求：场景 → 能力 → 数据）

2) 学习目标

学完本节课，学员将能够：

1. 识别 AI 在需求分析中的“正确位置”
2. ——哪些工作适合交给 AI，哪些必须由产品负责人判断
3. 掌握一套 AI 辅助需求分析的标准流程
4. 从业务问题出发，而不是从“功能想法”出发
5. 学会用 AI 做结构化输出，而不是替你做决策
6. 包括：
7. 问题拆解
8. 用户任务 / 痛点整理
9. 假设与不确定性识别
10. 将 AI 的分析结果转化为可写入 PRD 的输入物
11. 为后续 PRD 撰写、评审和迭代打好基础

3）课件大纲（Slides）

1. 为什么需要 AI 来辅助需求分析
2. 案例背景介绍：统一业务场景
3. 传统需求分析 vs AI 辅助需求分析
4. Step 1：AI 协助问题拆解
5. Step 2：AI 梳理用户任务与痛点
6. Step 3：识别假设与不确定性
7. Step 4：将 AI 输出转化为 PRD 输入物
8. 常见误区与反模式
9. 本节小结

撰写 PRD Lab（AI 功能版）。在浏览器内完成，从一句话场景出发写一份完整的 AI 功能 PRD（含指标与风险章节）。

模板结构： 1) 功能定义 + 用户故事；2) 用户流程图；3) 数据章节；4) 模型策略与成本估算；5) 成功指标 + 反指标；6) 风险列表 + 缓解措施；7) MVP 范围。产出提交到学习群，老师会挑 3 份做课堂讲评。

Week 4 前半 Quiz：PRD 与文档规范。20 题 30 分钟。覆盖：AI PRD 的 7 段结构、指标可测量的判定、风险章节必备项、Stakeholder 评审流程、文档版本管理。Scenario 题：给一份缺失风险章节的 PRD，写出你会补充的 5 条风险。

Prompt 工程的系统原理（不只是『提问技巧』）。四层次：1) 基础 prompt（指令 + 上下文）；2) few-shot prompt（示例学习）；3) Chain-of-Thought（推理路径显式化）；4) Agent prompt（工具调用 + 反思）。

给 BA 的重点： Prompt = 产品需求文档的可执行版本。学会写 Prompt 就是学会把需求精确翻译成机器能理解的语言。会讲 OpenAI / Anthropic 官方 guide 的核心 takeaway，配 10 个真实业务场景的 prompt 对比（烂 vs 好）。

1）课程卡片（Course Card）

课程名称

Prompt 工程进阶｜多轮对话与记忆：上下文管理

课程定位

从“一次性 Prompt”进阶到“可持续对话系统”，理解 AI 如何记住上下文、何时遗忘、如何被产品化管理。

适合人群

1. AI 产品经理 / 产品负责人
2. Business Analyst / Solution Designer
3. 需要设计 AI 对话流程的从业者
4. 已了解 Prompt 基础概念的学习者

前置课程

《Prompt 工程原理与技巧》

2）学习目标（Learning Objectives）

完成本节课后，你将能够：

1. 区分 Prompt 级记忆 与 对话级上下文管理理解 In-context learning 在多轮对话中的真实表现
2. 避免“模型真的记住了我”的常见误解
3. 设计可控的多轮对话结构明确每一轮对话中：输入、上下文、输出的边界
4. 知道哪些信息必须“重复给”，哪些可以依赖上下文
5. 理解 AI 产品中的“记忆”本质知道哪些是模型能力，哪些是产品层设计
6. 区分短期上下文、长期记忆、用户画像
7. 将上下文管理转化为 PRD 与对话设计能在 PRD 中清晰描述“上下文规则”
8. 为 AI 产品定义记忆策略、失效条件与风险点

3）课件大纲（Slides）

1. 课程引入：为什么“一问一答”的 Prompt 不够了？
2. 回顾：Prompt 工程中的“记忆”是什么？
3. 多轮对话的本质：上下文在不断变化
4. 上下文的三种常见来源
5. 什么信息应该进入上下文？
6. 上下文管理的典型失败场景
7. 多轮对话的设计思路（产品视角）
8. 案例：Travel Helper 的多轮对话拆解
9. “记住用户”这件事，谁来负责？
10. 在 PRD 中如何写“上下文管理”？
11. 常见误区总结
12. 本节小结

Prompt A/B 测试 Lab。给定两个业务场景（客服问答 + 需求拆解），每个场景写 3 套不同策略的 Prompt，用测试集对比 accuracy / latency / cost 三维度。

交付物： 6 套 Prompt + 一张对比表 + 1 页分析报告（哪套最优、为什么、在什么场景下换策略）。这是 AI PM 岗位最常考的实操能力之一。

Week 4 后半 Quiz：Prompt 工程。20 题 30 分钟。覆盖：Zero-shot vs Few-shot、Chain-of-Thought 适用场景、Prompt caching 机制、System Prompt vs User Prompt 差异、Temperature 与 Top-p 的作用、Context window 管理。

课程内容

1. AI 编程工具（Cursor / Claude）的安装与基础使用
2. 基于产品需求的任务拆解与实现路径梳理
3. 使用 AI 辅助完成 Landing Page 页面开发
4. 页面调试与部署上线的基本流程

课程目标

1. 理解产品需求从提出到落地的完整过程
2. 掌握使用 AI 工具辅助实现简单产品功能的方法
3. 提升独立推进小型产品需求的能力
4. 建立对技术实现与上线流程的基础认知

课程内容

1. AI 编程工具（Cursor / Claude）的安装与基础使用
2. 基于产品需求的任务拆解与实现路径梳理
3. 使用 AI 辅助完成 Landing Page 页面开发
4. 页面调试与部署上线的基本流程

课程目标

1. 理解产品需求从提出到落地的完整过程
2. 掌握使用 AI 工具辅助实现简单产品功能的方法
3. 提升独立推进小型产品需求的能力
4. 建立对技术实现与上线流程的基础认知

分享人: Wystan Zeng

分享内容：

HTML 的本质和功能

1. 介绍 HTML 是网页结构的骨架，讨论其标签结构、页面布局和内容展示。
2. 解释 HTML 是如何通过 HTTP 协议传输，以及浏览器如何解析 HTML 来显示网页。

CSS 的角色和应用

1. 探讨 CSS 如何提供网页的样式和布局，包括颜色、字体和响应式设计。
2. 讲解 CSS 的选择器、盒模型、布局模式如 Flexbox 和 Grid。

JavaScript 的功能和机制

1. 介绍 JavaScript 为网页提供的交互功能，包括事件处理、动画和 DOM 操作。
2. 解释异步回调机制，包括回调函数、Promise 和 async/await，以及它们如何处理 Web 应用中的异步操作。

API 的定义和用途

1. 解释 API（Application Programming Interface）作为软件间交流的桥梁。
2. 讨论不同类型的 API，如 Web API，以及它们在数据传输和集成中的作用。

Web API 的概念和前后端交互

1. 深入 Web API，特别是 RESTful API 和 GraphQL，以及它们如何使前端能与后端服务交互。
2. 讨论前端如何发送请求并处理响应，后端如何接受请求并返回数据。

框架的理解和价值

1. 定义框架并解释它们如何简化开发流程，例如 React、Angular 和 Vue。
2. 讨论框架的产生背景，它们如何提高开发效率，以及如何选择合适的框架。

网页的前后端交互机制

1. 介绍前端和后端的角色，以及它们如何通过 HTTP 请求和响应进行通信。
2. 讨论前后端分离的架构，以及现代 Web 应用的交互模式。

程序员的工作内容

1. 探讨程序员的日常工作，包括编码、测试、调试和文档编写。
2. 讨论软件开发生命周期、敏捷开发、版本控制和团队协作的重要性。

Prompt / Fine-tune / RAG / Agent

这四种方式，本质上是在回答同一个问题：
我们到底要“怎么用”LLM，才能把产品做好？

1️⃣ Prompting —— 给 LLM 更多「上下文」

一句话理解
👉 Prompting = 用更好的方式问问题

核心思想
不改模型，只通过更清晰的提示，让模型更好地理解你想要什么。

Prompt 常见结构

• Priming：你是谁？模型扮演什么角色

• Instructions：要怎么回答？语气 / 格式 / 规则

• User Input：用户的问题

• Output Format：输出格式（文本 / 列表 / JSON）

常用框架

• COSTAR（Context / Objective / Style / Tone / Audience / Response）

适合场景

• 快速验证想法

• Demo / MVP

• 内容生成、总结、改写

局限

• 上下文长度有限

• 容易“胡说八道”，不保证事实正确

2️⃣ Fine-tuning —— 教 LLM「怎么做事」

一句话理解
👉 Fine-tuning = 用数据训练模型“按你的方式回答”

核心思想
通过示例数据，让模型内化你的风格、规则和任务逻辑。

常见 3 类微调

• 任务训练（task-specific）

• 约束输入 / 输出结构（schema）

• 语言 / 风格训练

适合场景

• 固定任务（如客服、文案风格统一）

• 对输出格式要求非常严格

• 不想每次 prompt 都写很长

局限

• 需要准备数据

• 成本较高

• 不适合频繁变化的知识

3️⃣ RAG —— 给 LLM 接入「新知识」

一句话理解
👉 RAG = 查资料 + 再回答

核心思想
模型不会“记住新知识”，那就在回答前帮它查一查。

基本流程

1. 文档 → 切块

2. 切块 → 向量（embedding）

3. 相似度检索

4. 把检索结果塞进 prompt 再回答

适合场景

• 公司知识库

• 内部文档 / 产品说明

• 需要事实准确的问答

优势

• 知识可随时更新

• 不用重新训练模型

局限

• 需要维护知识库

• 检索质量决定答案质量

4️⃣ Agent —— 给 LLM「工具 + 行动能力」

一句话理解
👉 Agent = 会思考、会行动、还能反复执行的 LLM

核心能力

• Reason：分析问题

• Act：调用工具 / API

• Repeat：多步执行直到完成目标

相比 RAG 的升级

• 不只是“查资料”

• 可以 规划任务 → 执行 → 校验 → 调整

适合场景

• 多步骤任务（写代码、跑流程、自动化）

• 工作流自动化

• 智能助手 / Copilot

常见框架

• LangChain / LangGraph

挑战

• 复杂度高

• 对 prompt 和边界设计要求高

搭建文档问答助手 Lab。二选一：(A) 用 ChatGPT GPTs 自定义一个上传 PDF 可以回答问题的助手；(B) 用 Notion AI Q&A 功能做一个知识库问答。

交付物： 1) 选定场景（公司新人入职手册 / 产品文档 / 法律条款）；2) 上传的数据；3) 你的 System Prompt；4) 5 条测试 Q&A（对比 accuracy）；5) 2 分钟 demo video。提交到学习群 peer review。

🎯 课程定位

本课程讲解如何使用低/无代码方式设计并验证一个 RAG 原型，并结合基础自动化流程，完成一个可展示的 AI POC。

👥 适合人群

• BA 求职方向学员

• 无编程背景的业务人员

• 希望参与 AI 项目的分析角色

🧠 课程类型

方法论 + 原型设计实战（非工具操作教学）

📦 本节课产出

完成本课后，学员可以：

• 用业务语言解释 RAG 的结构

• 判断需求是否适合做 RAG 原型

• 设计一个低/无代码 AI 原型方案

• 设计一个简单自动化原型流程

• 输出一个 AI POC 结构说明

🎯 课程定位

本课程讲解如何将 Agent 融入业务流程，设计完整工作流结构，并定义权限与控制边界。

👥 适合人群

• BA 求职方向学员

• 希望参与 AI 项目流程设计的学员

• 对企业级落地感兴趣的学员

🧠 课程类型

流程设计方法课 + 风险控制思维课

📦 本节课产出

完成本课后，学员可以：

• 用流程视角理解 Agent

• 为 Agent 工作流拆解多步骤任务

• 设计主流程与异常流程

• 设计权限矩阵与控制边界

• 识别高风险节点

🎯 课程定位

本课程从 BA 视角出发，讲解如何将 AI 自动化能力从“项目功能”转变为“可持续产品能力”。

重点关注：

• 可维护性

• 可扩展性

• 可治理性

• 可运营性

👥 适合人群

• BA 求职方向学员

• 希望参与企业 AI 项目产品化设计的学员

• 想理解 AI 系统长期演进逻辑的学员

🧠 课程类型

产品结构设计课 + 系统思维课

📦 本节课产出

完成本课后，学员可以：

• 理解 AI 自动化与传统功能模块的区别

• 设计 AI 自动化的产品结构层

• 识别可产品化能力

• 设计治理与监控框架

• 规划自动化能力的演进路径

本测验用于检验你对本周核心内容的理解，包括：

• 四种 AI 原型模式（Prompt / Fine-tune / RAG / Agent）的区别

• RAG 的基本结构与适用场景

• 原型（POC）与正式系统的差异

• 成功标准与边界控制思维

测验重点不在技术细节，而在产品判断能力——你是否能正确判断什么时候应该使用 RAG，以及如何设计一个可验证的原型。

Notion → AI → Jira 自动化链路 Lab。打通一个可控的端到端自动化：学员在 Notion 写一条需求 → AI 自动拆成 User Story + 验收标准 → 推到 Jira 创建 Story + Subtasks → 通知 Slack channel。

关键学习点： 1) 哪些环节可以全自动、哪些必须人工 review（gate）；2) 如何防止 AI 幻觉导致任务拆错；3) 成本控制（每条需求花多少 token）；4) 失败重试与监控。交付物：一条能跑通的 n8n / Zapier workflow + 2 分钟 demo。

Week 6 Quiz：自动化系统与 Agent 决策思维。20 题 30 分钟。覆盖：哪些流程适合自动化、何时用 Rule-based vs LLM、Agent 的决策边界、Human-in-the-loop 设计、多 Agent 编排模式（sequential / parallel / hierarchical）、Agent 的监控与回滚机制。

📌 课程名称

自动化思维：从手工流程到系统流程

🎯 课程定位

本课程帮助学员建立自动化与 Agent 的底层认知框架。

重点不是“怎么做”，而是：

• 自动化如何改变流程结构

• 人与系统的职责如何重新分配

• Agent 思维与传统流程思维的区别

👥 适合人群

• BA 求职方向学员

• 希望参与 AI 项目前期分析的学员

• 想提升流程抽象能力的学员

📦 本节课产出

完成本课后，学员可以：

• 用系统视角分析业务流程

• 区分“人流程”与“系统流程”

• 识别可自动化节点

• 理解 Agent 的流程角色

• 画出自动化迁移路径图

2）学习目标（Learning Objectives）

完成本节课后，学员将能够：

1️⃣ 理解三种流程形态

能够区分：

• 手工流程（Human-driven）

• 半自动流程（Human-in-the-loop）

• 系统驱动流程（System-driven）

2️⃣ 建立自动化识别能力

能够回答：

• 哪些环节适合自动化？

• 哪些不适合？

• 自动化的前提条件是什么？

3️⃣ 理解 Agent 思维的本质

能够解释：

• Agent 是流程参与者，而不是工具

• Agent 如何改变决策结构

• Agent 如何影响组织分工

4️⃣ 建立流程迁移路径模型

能够设计：

• 从手工 → 半自动 → 全自动的迁移路线

• 自动化成熟度阶段

3）课件大纲（Slides Titles）

1. 本节课目标

2. 自动化的常见误解

3. 自动化改变的不是速度，而是结构

4. 什么是流程结构？

5. 手工流程结构图

6. 半自动流程结构图

7. 系统驱动流程结构图

8. 三种模式的对比

9. 什么时候不应该自动化？

10. Agent 与传统系统的区别

11. 决策从“规则”到“概率”

12. 人从“执行者”到“监督者”

13. 流程控制权的变化

14. 自动化成熟度三阶段

15. 如何选择切入点？

16. 如何避免“一步到位失败”？

17. 渐进式自动化模型

18. 自动化思维三层结构

19. 本节课总结和下一课预告

1）课程卡片（Course Card）

📌 课程名称

Agent 思维：从执行动作到决策系统

🎯 课程定位

本课程帮助学员理解：

Agent 并不是“自动执行脚本”，

而是具备决策能力的流程参与者。

从 BA 视角理解：

• 决策如何嵌入流程

• 概率决策 vs 规则决策

• 人机职责如何重新分配

👥 适合人群

• BA 求职方向学员

• 参与 AI 项目分析与需求定义的学员

• 想理解 Agent 与传统自动化区别的学员

📦 本节课产出

完成本课后，学员可以：

• 清晰区分自动化系统与 Agent 系统

• 识别“动作自动化”与“决策自动化”的区别

• 设计决策节点结构

• 理解决策风险的来源

• 分析 Agent 对组织的影响

2）学习目标（Learning Objectives）

完成本节课后，学员将能够：

1️⃣ 区分三类系统能力

能够解释：

• 执行动作系统（Rule-based Automation）

• 条件判断系统（逻辑规则系统）

• 决策型 Agent 系统（Probabilistic）

2️⃣ 理解 Agent 的决策结构

能够拆解：

• 输入信息

• 推理过程

• 决策输出

• 执行动作

3️⃣ 理解概率决策的特点

能够解释：

• 为什么 Agent 不是 100% 确定性

• 为什么错误是结构性存在

• 为什么必须设计监督机制

4️⃣ 分析 Agent 对组织结构的影响

能够识别：

• 决策权转移

• 责任划分变化

• 人机协作模式变化

3）课件大纲（Slides Titles）

1. 本节课目标

2. 什么是“动作自动化”？

3. 什么是“决策自动化”？

4. 两者的本质区别

5. Agent 的四层结构

6. 输入层（信息理解）

7. 推理层（判断生成）

8. 决策输出层

9. 执行动作层

10. 为什么 Agent 不可能 100% 正确？

11. 确定性规则 vs 概率判断

12. 错误的来源

13. 幻觉、偏差与数据缺失

14. 人在 Agent 系统中的角色

15. 决策权如何划分？

16. 什么应该交给 Agent？

17. 什么必须保留人工？

18. Agent 思维三层变化

19. 本节课总结和下一课预告

1）课程卡片（Course Card）

📌 课程名称

自动化架构思维——系统边界与控制结构

🎯 课程定位

本课程帮助学员建立：

• 自动化在系统中的位置认知

• 系统边界划分能力

• 控制结构设计思维

从 BA 视角理解：

自动化不是插进去的功能，而是嵌入式结构。

👥 适合人群

• BA 求职方向学员

• 参与 AI 系统架构讨论的学员

• 希望提升系统思维能力的学员

📦 本节课产出

完成本课后，学员可以：

• 识别自动化系统边界

• 划分人、系统、Agent 的职责区间

• 设计控制结构

• 理解“可控自动化”的架构特征

• 分析架构失控风险

2）学习目标（Learning Objectives）

完成本节课后，学员将能够：

1️⃣ 理解系统边界的意义

能够解释：

• 什么是系统边界？

• 为什么自动化必须有边界？

• 边界不清会导致什么问题？

2️⃣ 识别自动化嵌入位置

能够区分：

• 自动化作为“子系统”

• 自动化作为“中间层”

• 自动化作为“决策核心”

3️⃣ 设计控制结构

能够拆解：

• 触发控制

• 执行控制

• 回滚机制

• 人工接管点

4️⃣ 分析架构风险

能够识别：

• 失控扩张

• 权责模糊

• 黑盒依赖

• 数据污染

3）课件大纲（Slides Titles）

1. 本节课目标

2. 自动化不是独立存在

3. 什么是系统边界？

4. 边界不清的后果

5. 自动化作为“执行子系统”

6. 自动化作为“中间处理层”

7. 自动化作为“决策核心层”

8. 三种结构对比

9. 不同位置的风险差异

10. 什么是控制结构？

11. 触发控制设计

12. 执行控制设计

13. 异常与回滚机制

14. 人工接管点设计

15. 失控扩张

16. 权责不清

17. 黑盒依赖

18. 数据污染

19. 如何识别早期风险信号？

20. 自动化架构三层逻辑

21. 本节课总结和下一课预告

1）、课程卡片（Course Card）

课程名称

AI Agent 产品落地实战：从想法到上线

课程模块

自动化与 Agent 思维

课程定位

本节课程通过一个真实业务案例，完整讲解 AI Agent 产品从业务问题识别到上线落地的全过程。学员将理解 AI 产品设计的关键阶段、关键决策节点以及 PM / BA 在每个阶段需要完成的核心产出。

核心案例

Customer Support AI Agent（客户邮件自动回复 Agent）

课程时长

约 30 分钟

适合人群

• AI Product Manager

• Business Analyst

• 对 AI 产品设计和落地感兴趣的人

课程价值

通过一个完整案例，理解：

• AI Agent 产品是如何设计出来的

• PM / BA 如何推动 AI 项目落地

• AI 产品开发过程中有哪些关键 artefacts

• 如何把 AI 自动化真正做成可上线的产品

2）、学习目标（Learning Objectives）

完成本节课程后，学员将能够：

1️⃣ 理解 AI Agent 产品落地的完整流程

从业务问题识别到上线运营，理解 AI 产品开发的主要阶段。

2️⃣ 识别 AI Agent 产品的关键 Stakeholders

理解不同角色在 AI 产品中的职责，例如：

• Business Owner

• Product Manager

• Business Analyst

• Engineering

• Operations

3️⃣ 掌握 AI Agent 产品设计的关键节点

包括：

• 自动化边界

• Human-in-the-loop

• AI 可靠性控制

• 数据与知识来源

4️⃣ 学会设计一个 AI Agent Workflow

能够将一个业务流程转化为：

AI Agent 工作流设计。

5️⃣ 理解 PM / BA 在 AI 产品中的核心 Artefacts

包括：

• Workflow Diagram

• Use Case Definition

• Agent Workflow Design

• KPI Metrics

3）Slides Titles

1. 课程目标和收获

2. 为什么很多 AI 项目无法真正落地？

3. 本节课程案例：Customer Support AI Agent

4. 原始业务流程：客户邮件处理流程

5. AI Agent 可以解决什么问题？

6. AI Agent 产品的主要 Stakeholders

7. Stakeholder 角色与职责

8. AI Agent 产品设计的五个阶段

9. 阶段一：Problem Discovery

10. 阶段二：Automation Opportunity Identification

11. 阶段三：Agent Workflow Design

12. 设计 AI Agent 工作流（案例）

13. 阶段四：Prototype / POC

14. 阶段五：Production Launch

15. AI Agent 产品设计的关键决策点

16. Human-in-the-loop 设计

17. AI Agent 的数据与知识来源

18. PM / BA 在各阶段的核心 Artefacts

19. AI Agent 产品的关键指标（KPI）

20. 课程总结：AI Agent 产品落地方法