docs: 产品运营方向文档修订

docs/product-operations/product-analysis.md

@@ -0,0 +1,37 @@
+---
+title: 产品分析
+status: unread
+direction: product-operations
+---
+
+# 产品分析
+
+产品分析的目的，是通过拆解现有产品学习需求、交互逻辑和商业价值，为新的产品决策提供输入。
+
+## 选择对象
+
+优先选择结构清晰、自己实际使用过、能在一周内完成分析的产品。不要只罗列功能，应围绕一个具体用户和场景展开。
+
+## 分析框架
+
+1. 用户：目标人群、核心场景和高频任务。
+2. 问题：用户为什么需要它，替代方案是什么。
+3. 体验：首次使用、核心流程、异常状态和反馈。
+4. 信息架构：页面层级、导航和内容组织。
+5. 数据与增长：激活、留存、转化和分享路径。
+6. 竞争与取舍：它做得好的地方、成本和局限。
+7. 建议：按影响和成本排序，写出可验证的改进。
+
+## 分析输出
+
+每个结论都应有截图、数据、访谈或可复现的操作作为依据。建议把“事实”“推断”和“建议”分开写，避免把个人偏好当成用户需求。
+
+## 练习
+
+- [ ] 选择一个校园产品，画出首次完成核心任务的流程图。
+- [ ] 记录两个让你不舒服的交互，并说明问题、原因和改进方案。
+- [ ] 推荐两个小众工具，分别写清楚它解决的具体问题。
+
+## 学习衔接
+
+将本页发现的问题带回[需求分析、调研与验证](product-research-validation.md)，再用[UML 建模](uml.md)表达关键流程。

docs/product-operations/product-feedback-growth.md

@@ -0,0 +1,44 @@
+---
+title: 产品推广、反馈与增长
+status: unread
+direction: product-operations
+---
+
+# 产品推广、反馈与增长
+
+产品发布后，需要让目标用户知道它、愿意尝试它，并把使用中的问题带回下一轮迭代。先完成[需求分析、调研与验证](product-research-validation.md)，再结合实际项目实践。
+
+## 制定推广计划
+
+先写清目标人群、他们在哪里接触信息、希望完成的动作，以及如何衡量效果。线下宣传品、电子屏、公众号推文或视频适合的场景不同，选择渠道时应考虑覆盖人数、制作与审批成本、发布时间和用户的实际使用习惯。
+
+一份最小推广策划可包含：项目背景、目标用户、核心信息、渠道与时间、负责人、预算、预期效果和应急预案。文案先讲用户能解决的问题，再说明具体使用方式。不要只用曝光量评价效果，还要看访问、激活和后续留存。
+
+## 收集并整理反馈
+
+主动收集可用访谈、定向问卷或页面内提示；被动收集可用反馈入口、邮件、群聊或 Issue。主动提问应尽量选对用户和时机，避免打扰；被动渠道应明显、易用，并说明预计处理方式。
+
+收到反馈后，保留用户原话，同时按产品、版本、用户群、场景和问题类型编码。常见类型包括使用疑问、Bug、改进建议、新功能建议和正负面评价。编码帮助团队找出重复问题，但不能替代阅读原始描述。
+
+| 类型 | 首要动作 | 交给谁 |
+| --- | --- | --- |
+| 使用疑问 | 解释流程，检查引导是否清楚 | 运营与产品 |
+| 可复现 Bug | 收集环境、版本、步骤、预期和实际结果 | 测试与研发 |
+| 需求或改进建议 | 追问使用场景、频率和替代办法 | 产品 |
+| 情绪反馈 | 尊重回应，寻找可进一步确认的事实 | 运营 |
+
+不要要求用户在公开渠道提供密码、令牌或不必要的个人信息。转交 Bug 时，优先写清复现步骤和必要条件，而不是只说“无法登录”。处理后告知用户结果，并把高频问题沉淀到 FAQ。
+
+## 用数据指导迭代
+
+围绕“看到推广 → 开始使用 → 完成核心任务 → 再次使用”设定少量指标。对不同渠道和用户群分别观察，避免只看总量。对每项改进记录假设、基线、发布时间、观察窗口和结果；同时结合访谈判断指标变化的原因。
+
+## 练习
+
+- [ ] 为自己的项目写一页推广策划，说明目标人群、渠道、时间、负责人和衡量指标。
+- [ ] 把至少五条模拟反馈分类，选出一条 Bug 写成可复现的 Issue。
+- [ ] 设计一个从反馈到修复、回复用户、更新 FAQ 的处理流程。
+
+## 学习衔接
+
+- 回到[产品运营路线](产品运营方向.md)查看下一轮迭代；需要定位技术问题时参考 HTTP、API 与爬虫（暂未上线）。

docs/product-operations/product-introduction-prd.md

@@ -0,0 +1,68 @@
+---
+title: 产品经理概论与 PRD
+status: unread
+direction: product-operations
+---
+
+# 产品经理概论与 PRD
+
+产品工作从发现问题开始，经过目标和方案定义、设计评审、开发测试、上线和复盘，持续验证是否为用户创造了价值。
+
+## 产品经理概论
+
+求是潮产品经理的工作可以概括为三个要素：需求、策划、运营。
+
+围绕这些工作，需要具备几类基本能力：
+
+1. 用户调研：设计问卷、开展访谈，知道过程中该记录什么、注意什么。
+2. 表达与说服：具备基本的PPT演示与讲演能力。
+3. 沟通与组织：与团队成员对齐信息，组织主持小组会议。
+4. 文档写作：掌握 Markdown ，了解常见产品文档的组成部分。
+5. 原型设计：掌握 Figma 等原型工具的基本操作。
+
+产品运营工作流程：
+
+1. 预备阶段：调研目标用户提取需求，脑暴补全并按优先级排序，进而竞品分析，最终产出 PRD。
+2. UI ：先完成低保真原型，包含页面、页面功能、跳转逻辑与大致文案；再进一步细化。
+3. 技术实现与测试：开发过程中定期跟进研发进度。
+4. 产品上线与运营：以产品反馈群为主，回答用户问题、记录需求，等待后续迭代。
+
+[产品经理概论内训PPT](assets/产品经理概论.pptx)。
+
+## PRD 是什么
+
+一份可执行的需求文档（PRD）至少要说明：
+
+1. 背景与问题：谁在什么场景遇到了什么问题。
+2. 目标与指标：希望改变什么，如何判断成功。
+3. 用户与范围：目标用户、使用边界和不做什么。
+4. 用户流程：主流程、异常流程和状态变化。
+5. 功能需求：页面、字段、交互、权限和校验。
+6. 原型与验收标准：低保真原型、输入输出和可测试条件。
+7. 风险与依赖：技术、数据、合规和上线风险。
+
+需求描述要让设计、开发和测试对同一行为有相同理解。避免“体验更好”“尽快优化”这类无法验收的表达。
+
+## PRD 模板
+
+```md
+## 需求背景
+## 目标与指标
+## 用户故事
+## 页面与交互
+## 数据与权限
+## 异常情况
+## 验收标准
+## 版本计划
+```
+[PRD内训PPT](assets/PRD内训.pptx)
+
+## 练习
+
+- [ ] 为训练文档站新增“学习进度筛选”功能写一页 PRD。
+- [ ] 绘制至少两个页面的低保真原型，并标注点击、返回和错误状态。
+- [ ] 把一个模糊需求改写成可测试的验收标准。
+
+## 学习衔接
+
+先阅读[产品运营路线](产品运营方向.md)；完成需求框架后进入[需求分析、调研与验证](product-research-validation.md)，带着证据再回到本页写 PRD。

docs/product-operations/product-minus-one-to-zero.md

@@ -0,0 +1,55 @@
+---
+title: 产品从-1到0
+status: unread
+direction: product-operations
+---
+
+# 产品从-1到0
+
+什么是产品思维？
+这是一份求是潮产品方向传承下来的讲义：[产品从-1到0（PDF）](assets/product-minus-one-to-zero.pdf)。讲义成稿于 2021 年前后，具体示例偏旧，产品运营思路历久弥新。
+
+## 学习路径
+
+### 第一阶段：产品与体验「前言」「UX」「UI」「Interaction Design 交互设计」
+
+- 产品与产品经理：互联网产品是功能与服务的集成；“产品”偏向产品的创生，“运营”偏向产品的迭代。
+- UX：好体验的三要素 Useful、Usable、Desirable；五个更具体的评价指标 Learnability、Efficiency、Memorability、Error Rate、Satisfaction。
+- Error Control：错误与目的有关。交互过于相似、高频功能与易错功能过近、错误触发过于容易，是三类常见的错误来源。
+- UI：设计感（简洁明快、潮与惊喜）、基础布局（TabBar、侧滑菜单 / 抽屉、瀑布流、卡片）、组件细节（z轴与阴影、颜色模型与配色原则、尺寸、动效、icon）。
+- 交互设计：五个维度 Words、Visual representations、Physical objects or space、Time / Animation、Behavior；四条原则 Discoverability、Consistency、Learnability、Readability；以及 Fitts' Law 与最小点击区域。
+
+**阶段产出：** 挑一个你每天在用的 App，用 UX 五个指标和交互四条原则写一页评价。并尝试按“影响 ÷ 成本”排序列出改进建议。
+
+### 第二阶段：产品思维与平台常识「产品思维」「产品迭代」「具体的平台开发」「求是潮产品线」
+
+- 需求导向：一个需求是否值得做，先看它是否是个例、是否要求紧迫、能否适当满足。
+- 边界意识：知识产权与监管（如icon、代码、设计思路的使用许可，平台与商店规则）、信息安全与用户隐私。
+- 数据驱动：用埋点记录用户行为，用数据而不是感觉指导迭代；埋点需要精心设计。
+- 平台差异：App、网页、插件、微信小程序各自的成本与完成方式。
+- 求是潮产品线：历史产品的兴衰成败（问答堂、Bubble、Share、Notice 等）留下的启示。
+
+**阶段产出：** 写一份文档判断产品是否值得做，说明用户场景、现有替代方案、发生频率与影响，并给出推进或拒绝的理由。
+
+### 第三阶段：工作流与交付物（「工作流」「技术背景知识」「扩展」）
+
+- 调研：先确认需求和竞品，再决定是否调研潜在用户。
+- PRD（Product Requirement Document）：“概念化”（产品定位、竞品分析，可用 $APPEALS 等多维框架）+ “图纸化”（业务逻辑、页面逻辑、数据通路）。
+- 原型：先用低保真原型梳理流程，常用工具有 Figma、墨刀等。
+- 研发、测试、推广、运营与迭代：测试要覆盖误触等异常路径；推广先讲用户能解决什么问题；运营要建立反馈与迭代的闭环。
+
+**阶段产出：** 为一个真实的小需求写一份 PRD 草稿（至少写清背景、目标、范围、主流程和验收标准），并画出其中一条关键流程。
+
+## 练习
+
+- [ ] 用 UX 的五项指标为一个校园产品打分，每项写一句证据。
+- [ ] 找两处让你不舒服的交互，分别说明问题、原因与改法，思考它与哪条交互原则相悖。
+- [ ] 用“个例 / 紧迫 / 能否满足”三个问题判断一个你想到的需求的实现可行性。
+- [ ] 找出一个产品里的埋点痕迹（如“猜你喜欢”“继续观看”），推测它记录了哪些行为、用来做什么。
+- [ ] 为一个小项目写一页 PRD 草稿，喂给AI制作，评价其完成度，记录心得。
+
+## 学习衔接
+
+回到[产品运营方向](产品运营方向.md)按阶段推进。
+
+为进一步理解 PRD 中的页面与数据怎样落地，可配合阅读[技术研发方向](../technical-development/技术研发方向.md)中的[HTML 与 CSS](../technical-development/frontend-html-css.md)和[数据库、MySQL 与 Prisma](../technical-development/backend-database-mysql-prisma.md)。

docs/product-operations/product-research-validation.md

@@ -0,0 +1,40 @@
+---
+title: 需求分析、调研与验证
+status: unread
+direction: product-operations
+---
+
+# 需求分析、调研与验证
+
+## 从现象到需求
+
+用户提出的功能往往是解决方案，而不是需求本身。先描述场景、目标和阻碍，再确认问题是否普遍、是否值得解决。
+
+可以用以下问题拆解：
+
+- 谁遇到了问题？频率和影响有多大？
+- 现在如何解决？替代方案的成本是什么？
+- 哪些证据支持这个问题，而不是个别意见？
+- 解决后希望哪个行为或指标发生变化？
+
+## 调研方法
+
+访谈适合了解动机和流程，问卷适合收集较大样本的现状，日志和数据适合验证实际行为，可用性测试适合发现交互障碍。问题应中立、具体，避免暗示答案。
+
+访谈记录应区分“用户原话”“观察到的行为”和“研究者解释”。涉及个人信息时只收集必要内容，并取得合适授权。
+
+## 验证方案
+
+把假设写成可证伪的句子，预先确定样本、周期、指标和通过标准。原型测试可以先验证理解和流程，灰度发布再验证真实使用和长期留存。
+
+[需求分析、调研和验证 内训PPT](assets/需求分析、调研和验证.pptx)
+
+## 练习
+
+- [ ] 为“学习者不知道哪些内训节点已完成”提出三个可验证假设。
+- [ ] 设计一份 5 题以内的产品调研问卷。
+- [ ] 给出一个原型测试计划：目标、对象、任务、观察点和结论标准。
+
+## 学习衔接
+
+回顾[产品经理概论与 PRD](product-introduction-prd.md)，接着阅读[产品分析](product-analysis.md)；涉及接口可行性时参考 HTTP、API 与爬虫（暂未上线）。

docs/product-operations/uml.md

@@ -0,0 +1,41 @@
+---
+title: UML 建模
+status: unread
+direction: product-operations
+---
+
+# UML 建模
+
+UML 是统一建模语言，用图形描述系统结构、角色和行为。它帮助产品、设计和技术在实现前建立共同语言。
+
+## 常用图
+
+- **类图**：类、属性、方法及其关系。
+- **用例图**：系统外部角色与系统提供的功能。
+- **活动图**：业务流程、分支和并发。
+- **状态机图**：一个对象在生命周期中的状态和转换条件。
+- **时序图**：多个对象按时间顺序交换消息。
+
+## 常见关系
+
+关联表示对象之间长期存在的联系；继承表示“是一个”；实现表示类遵守接口；依赖表示临时使用；聚合和组合表示整体与部分。多重性可写成 `0..1`、`1..*` 等。
+
+## 建模步骤
+
+1. 从需求文字中找出角色、实体、动作和状态。
+2. 为实体补充必要属性和行为。
+3. 画出关系和多重性。
+4. 用一个具体场景走通流程，删除不必要的细节。
+5. 让图和 PRD、API、数据库模型保持一致。
+
+例如待办系统可先画“用户创建待办”的用例图，再用时序图描述浏览器、API、服务层和数据库的交互。
+
+## 练习
+
+- [ ] 为内训项目画一张用例图。
+- [ ] 为“创建待办”画一张时序图。
+- [ ] 为待办状态 `未完成 → 已完成 → 已归档` 画一张状态机图。
+
+## 学习衔接
+
+把[产品分析](product-analysis.md)的结论画成流程，接着进行项目验证；类与接口的技术实现可参考后端面向对象（暂未上线）。

docs/product-operations/产品运营方向.md

@@ -12,8 +12,10 @@ status: unread
 ## 内容概览
 > 由于26秋冬为第一次实行该套内训系统，该部分可能会随时更新
 
-- 产品从-1到0
-- 产品经理概论与 PRD
-- 产品推广、反馈与增长
-- 需求分析、调研与验证
-- 软件工程
+- [产品从-1到0](product-minus-one-to-zero.md): 从产品定义、UX/UI 与交互，到产品思维和工作流的入门讲义。
+- [产品经理概论与 PRD](product-introduction-prd.md): 产品经理的工作，以及如何撰写 PRD 。
+- [产品推广、反馈与增长](product-feedback-growth.md): 如何不断推广产品。
+- [需求分析、调研与验证](product-research-validation.md): 如何进行产品调研，判断产品生命力。
+- [产品分析](product-analysis.md): 如何整体拆解一项产品。
+- [UML建模](uml.md): 如何绘制协作流程图。
+- 软件工程