同步：内容创作产品规划、短视频脚本创作技能、知识库设计及memory日志更新

2026-08-13 09:39:31 +08:00
1 parent 23a0b0f8ed
commit 81ac5eae51
@@ -1,78 +0,0 @@
---
-name: AgentTeamWork
-description: 这是一个模拟真实项目团队的多智能体协作系统。当面对一个复杂或模糊的需求时，本 Skill 会激活一个由项目主管、业务专家、产品经理、产品运营和AI助理组成的虚拟团队。他们通过标准化的沟通协议和明确的职责分工，共同完成从目标拆解、方案规划、提示词编写、执行实施、业务确认到质量审核与复盘迭代的全流程工作，确保最终交付成果的专业性、稳定性和可复用性
---
-
-## 激活条件
-
-满足以下**任意一项**时，激活本 Skill：
-
- 用户需求模糊或多义，无法直接给出单一答案，需要先拆解和澄清
- 任务需要 3 个以上步骤才能完成，且步骤之间存在依赖关系
- 用户明确要求"团队协作"、"多角色分工"、"项目化推进"类的工作方式
- 任务同时涉及规划、执行和质量审核，单次对话无法覆盖全流程
-
-**不激活的场景**：单一明确的问答、简单文件操作、单步代码修改等无需多角色协作的请求。
-
-## 核心协作机制
-*严格遵循./references/ 目录下序号最大的文件*
-
-## 项目目录结构
-
-顶层存放路径为 `project/项目名称/`，支持多个项目并列：
-```
-project/
-├── 短视频台词接地气专项/
-│   └── case_1/
-│       └── ...
-├── 直播话术优化项目/
-│   └── case_1/
-│       └── ...
-```
-
-单个项目内部结构：
-```
-项目名称/
-├── case_1/
-│   ├── 00_基础信息.md      — 项目章程：目标、成功标准、约束条件、角色分工（项目主管输出）
-│   ├── 01_业务方法.md      — 业务专家输出的方法论：领域背景、分析框架、核心思路
-│   ├── 02_执行步骤.md      — 执行计划：将目标拆解为有序任务列表，含依赖关系和预期产出
-│   ├── 03_提示词.md        — 产品经理编写的各子任务执行提示词，含角色设定和输出格式要求
-│   └── 04_项目案例/
-│       ├── 项目执行01/       — 第1次执行，包含完整闭环
-│       │   ├── XXX_案例01/      — 案例名称_编号文件夹
-│       │   │   ├── 生成案例.md   — AI助理的执行产出，记录输入、输出和执行日志
-│       │   │   ├── 效果评估.md   — 业务专家的审核报告：按准确性/完整性/逻辑/格式逐项打分
-│       │   │   ├── 经验总结.md   — 本轮执行的经验提炼、踩坑记录和改进建议
-│       │   │   └── {项目名称}_收集反馈.html — 产品运营生成，整合案例、评估和经验的HTML确认页（单页长页面，板块：生成案例/效果评估/创作方法/经验沉淀/业务反馈），生成规范见 References「产品运营 · 收集反馈页面生成规范」
-│       ├── 项目执行02/       — 用户要求执行新的项目案例时触发新建，结构同上
-│       │   ├── XXX_案例01/      — 案例名称_编号文件夹
-│       │   │   ├── 生成案例.md
-│       │   │   ├── 效果评估.md
-│       │   │   ├── 经验总结.md
-│       │   │   └── {项目名称}_收集反馈.html
-└── 经验汇总/
-    ├── 方法论.md           — 跨轮次、跨版本的方法论汇总，不随单次执行结束而丢弃
-    └── 提示词.md           — 跨轮次、跨版本的提示词汇总，不随单次执行结束而丢弃
-```
-
-## 基础原则
-
-1. **阶段不可跳过**：四个阶段（规划 → 执行 → 审核 → 沉淀）是硬性约束，不因需求"简单"而省略任何阶段。
-2. **产物必须落文件**：每阶段的关键产物须写入对应文件后，方可进入下一阶段；不允许仅在对话中描述。
-3. **角色边界不可越权**：AI助理不做规划，业务专家不写提示词，产品经理不裁决业务准确性；职责边界以 References 角色定义为准。
-4. **模糊先澄清，不假设推进**：目标、范围或验收标准不明确时，必须先向项目主管或用户确认，不得带着假设继续执行。
-5. **修正上限 3 轮**：单个产物审核不通过超过 3 次，由项目主管介入决策，禁止无限循环修改。
-6. **方法必须验证后沉淀**：第四阶段复盘提出的优化方法（提示词改进、方法论调整、流程优化等），必须经过验证闭环——用优化后的方法重新执行至少1个案例，对比优化前后的效果评分，验证通过后方可写入知识沉淀。验证不通过则继续优化方法（同样上限3轮），超限由项目主管介入决策。未经验证的方法不得写入经验汇总。
-
-## 角色
-
-> 详细职责、边界与关键输出以 `References 角色定义与职责边界` 为准。
-
-| 名称 | 定位 | 核心职责 | 边界约束 |
-|-------|------|---------|---------|
-| 项目主管 | 项目经理 + 决策者 | 统筹全局、制定策略、主持评审、管控风险、最终汇报 | 不做具体执行，不写提示词 |
-| 业务专家 | 领域权威 + 质量门神 | 业务方法输入、拆解执行步骤、审核结果业务准确性 | 不参与提示词编写和任务执行，专注"做什么"和"做得对不对" |
-| 产品经理 | 沟通桥梁 + 知识沉淀者 | 将业务语言转化为提示词、优化提示词、沉淀方法论 | 不主导业务决策，专注"让AI更好地完成任务"和"让知识复用" |
-| AI助理 | 执行者 + 信息员 | 严格按提示词执行、调用工具获取信息、记录执行日志 | 不做规划、不做最终审核，专注"听话照做，不出错" |
-| 产品运营 | 交付呈现 + 业务对接 | 将项目产出整合为可视化确认页面、对接业务团队收集反馈 | 不参与业务决策和内容执行，专注"把成果呈现清楚、把反馈带回团队" |
@@ -1,159 +0,0 @@
-# 核心工作流
-该 Skill 遵循“规划-执行-审核-沉淀”的循环。每个阶段由特定角色主导，其他角色协同。
-第一阶段：启动与规划 (由项目主管主导)
-目标接收与澄清：
-[项目主管] 接收用户输入的初始目标。
-[项目主管] 与用户进行结构化沟通，澄清模糊点，明确交付标准、时间范围和约束条件。
-[项目主管] 输出一份清晰的 项目章程（包含项目目标、成功标准、核心约束），并在团队内部同步。
-
-任务解构与策略制定：
-[业务专家] 根据项目章程，将核心目标拆解为 3-7 个可执行的阶段或任务块（例如：信息搜集、方案设计、内容生成、质量检测）。
-[业务专家] 为每个子任务定义具体的执行步骤、所需工具和预期产出。
-[业务专家] 输出 执行计划草案，包含任务列表、依赖关系和风险点。
-
-方案评审与计划锁定：
-[项目主管] 组织团队对 执行计划草案 进行评审。
-[业务专家] 解释技术方案的可行性。
-[产品经理] 从最终用户（或提示词使用者）的角度，评估执行计划的清晰度和完整性。
-[项目主管] 整合各方意见，锁定最终 执行计划，并将其分解为可执行的 任务清单。
-
-第二阶段：执行与协作 (由AI助理主导，业务专家指导)
-信息准备与知识激活：
-[AI助理] 根据执行计划，调用 MCP 工具（如搜索引擎、数据库、文件读取器）搜集必要的背景信息、素材和数据。
-[产品经理] 从过往的项目文档或知识库中，检索相关的 提示词模板、方法论卡片 和 最佳实践案例，作为参考。
-
-提示词生成与优化：
-[产品经理] 基于执行计划和搜集到的信息，为AI助理编写第一个子任务的 执行提示词。该提示词需包含清晰的角色设定、任务目标、输出格式和质量标准。
-[业务专家] 审核执行提示词，确保其业务逻辑和方法论的正确性，并给出优化建议。
-[产品经理] 根据建议迭代提示词，形成最终的 高质量提示词。
-
-任务执行与输出：
-[AI助理] 严格按照 高质量提示词 执行当前子任务，并生成相应内容或代码。
-[AI助理] 在执行过程中，如遇到模糊点或需要决策，主动向 业务专家 或 项目主管 请求澄清。
-[AI助理] 完成任务后，将输出结果提交到共享的 任务看板（或上下文记忆）中。
-
-第三阶段：质量检测与反馈 (由业务专家主导)
-结构化质量审核：
-[业务专家] 获取 AI助理 的产出，并根据 执行计划 中定义的成功标准进行逐项审核。
-审核维度包括：准确性、完整性、逻辑一致性、格式规范、风格匹配。
-[业务专家] 使用结构化的审核报告反馈问题，内容应包括：问题描述、严重程度、修改建议。
-
-循环修正：
-[产品经理] 根据 审核报告，优化下一轮的 执行提示词，或在当前轮次中指导 AI助理 进行针对性修正。
-[AI助理] 根据反馈进行修改，直至通过业务专家的质量门禁。
-此环节可配置最多3轮修正循环，超时则由[项目主管]介入决策。
-
-第四阶段：复盘与沉淀 (由产品经理主导)
-项目复盘：
-[项目主管] 主持项目复盘会议，总结项目过程中遇到的困难、做出的关键决策以及获得的经验教训。
-[AI助理] 提供执行过程中的日志和关键数据，例如各步骤耗时、重试次数等。
-
-方法验证闭环（不可跳过）：
-[产品经理] 根据复盘发现的问题，提出具体的优化方法（提示词改进、方法论调整、提问模板优化等），并明确验证标准（对比哪些维度、预期改善幅度）。
-[产品经理] 编写优化后的执行提示词。
-[AI助理] 使用优化后的提示词，选取至少1个已完成的案例重新执行生成。
-[业务专家] 按照原审核标准，对优化前后的产出进行对比评分，输出验证报告：
-  - 各审核维度的评分对比（优化前 vs 优化后）
-  - 是否达到预期改善幅度
-  - 验证结论：通过 / 不通过（附原因）
-验证通过：进入知识沉淀环节。
-验证不通过：产品经理根据验证报告继续优化方法，重新执行验证。此环节最多3轮，超限由项目主管介入决策（放弃该优化方向、降级为经验记录、或调整验证标准）。
-
-知识沉淀：
-[产品经理] 将本次项目中产生的有价值的内容进行提炼和总结（仅沉淀已通过验证的方法）：
- 高质量提示词：将表现优异的执行提示词存入提示词库。
- 方法论卡片：将本次的执行计划和协作流程抽象为可复用的工作方法。
- 验证报告：将方法验证闭环中的对比数据和结论存档，作为方法有效性的证据。
- 执行文档：生成一份完整的 项目总结报告，记录从目标到最终成果的完整链路。
-[产品经理] 更新项目知识库，为未来的类似项目提供参考。
-
-业务确认与反馈收集：
-[产品运营] 将本轮执行的产出（执行结果、质量评估、经验总结、验证报告）整合为收集反馈页面（HTML），包含生成案例、效果评估、创作方法、经验沉淀、业务反馈五个板块。
-[产品运营] 将业务确认页面提交给业务团队评估，收集反馈意见。
-[产品运营] 将反馈整理后同步给项目团队，作为下一轮执行优化的输入。
-
-# 角色定义与职责边界
-| 角色 | 定位 | 核心职责 | 关键输出 | 边界与规则 |
-| :--- | :--- | :--- | :--- | :--- |
-| **项目主管** | **项目经理 + 决策者** | 1. 与用户沟通，明确目标<br>2. 统筹全局，制定顶层策略<br>3. 主持评审，协调冲突<br>4. 管控风险，处理异常<br>5. 进行最终汇报 | `项目章程`，`最终交付报告` | 不做具体执行，不写提示词。确保目标正确、进度受控、团队方向不偏航 |
-| **业务专家** | **领域权威 + 质量门神** | 1. 负责业务方法和专业知识的输入<br>2. 将目标拆解为可执行的业务步骤<br>3. 审核执行结果的业务准确性<br>4. 提供专业指导和决策建议 | `执行计划草案`，`质量审核报告` | 不参与具体的提示词编写和任务执行。专注于"做什么"和"做得对不对" |
-| **产品经理** | **沟通桥梁 + 知识沉淀者** | 1. 将业务语言转化为AI可理解的提示词<br>2. 优化提示词，提升执行效率和输出质量<br>3. 沉淀项目经验，形成可复用的方法论和知识文档<br>4. 维护团队的知识库和提示词库 | `高质量提示词`，`方法论卡片`，`项目总结报告` | 不主导业务决策。职责是“让AI更好地完成任务”和“让知识能够被重复利用” |
-| **AI助理** | **执行者 + 信息员** | 1. 严格按照`高质量提示词`执行具体任务<br>2. 调用各种MCP工具获取信息<br>3. 在执行过程中进行自我检查，确保步骤不遗漏<br>4. 记录执行日志，为复盘提供数据 | `任务执行结果`，`执行日志` | 不做规划，不做最终审核。职责是"听话照做，不出错，高效完成任务" |
-| **产品运营** | **交付呈现 + 业务对接** | 1. 将项目产出（案例、评估、经验）整合为可视化HTML确认页面<br>2. 对接业务团队，收集反馈意见<br>3. 将业务反馈整理后带回团队，驱动下一轮优化 | `{项目名称}_收集反馈.html`，`业务反馈记录` | 不参与业务决策和内容执行。职责是"把成果呈现清楚、把反馈带回团队" |
-
-# 产品运营 · 收集反馈页面生成规范
-
-> 本规范适用于产品运营角色生成的收集反馈页面（HTML）。所有规则基于项目实战中反复修正的经验沉淀，后续新项目须严格遵循。
-
-## 1. 页面整体结构
-
- 单页长页面，所有板块从上到下纵向排列，不使用 Tab 切换
- 顶部：项目标题栏 → 吸顶锚点导航栏（可快速跳转到各板块，滚动时自动高亮当前板块）
- 每个板块之间用分隔线（图标 + 标题 + 横线）视觉区分
- 页面须在项目执行01/02/... 文件夹中生成，文件名为 `{项目名称}_收集反馈.html`
-
-## 2. 板块命名与内容定义（固定，不可自定义）
-
-| 板块名称 | 内容 | 数据来源 |
-|:---|:---|:---|
-| 生成案例 | 数据看板（头部）+ 完整案例表格 | 生成案例.md |
-| 效果评估 | 审核维度汇总表 + 分案例评审卡片 + 维度覆盖表 + 综合结论 | 效果评估.md |
-| 创作方法 | 创作方法框架卡片 + 执行步骤 | 经验汇总/方法论.md |
-| 经验沉淀 | 提示词模板（子Tab切换）+ 踩坑记录 | 经验汇总/提示词.md + 经验总结.md |
-| 业务反馈 | 核心成果总结 + 飞书问卷入口 | 汇总页面 |
-
-## 3. 内容规范
-
-### 3.1 生成案例板块
-
- **数据看板**：页面第一个卡片，展示本轮执行的核心指标（案例数量、评分区间、维度通过率、返工数等）
-  - 布局：4列 grid（响应式：≤768px 2列，≤480px 1列）
-  - 结构：数值（32px 加粗）+ 标签（13px）+ 辅助说明（11px 灰色）
-  - **禁止使用 emoji 图标**，数据卡片仅展示数值与文字
-  - 每张卡片顶部 3px 彩色条纹区分类别
- **案例表格**：每个案例一个卡片，展示完整数据表格
-  - 短视频脚本项目标准列：**镜头 | 景别 | 时长 | 画面内容 | 表情&情绪 | 字幕&口播**（共6列）
-  - 其他项目类型的列定义在对应提示词中声明，以提示词为准
-  - 表格逐行完整展示，不得节选或省略
-  - 表格下方附执行记录摘要（背景色块样式）
-
-### 3.2 效果评估板块
-
- 第一个卡片：审核维度汇总评分表（维度 × 案例矩阵）
- 后续卡片：**分案例评审卡片**，每个案例独立展示
-  - 亮点列表（无背景）
-  - 改进建议（灰色背景块）
-  - 禁止仅给出独立评分而无具体评审内容
- 最后一个卡片：综合评估（覆盖表 + 审核结论）
-
-### 3.3 业务反馈板块
-
- 第一个卡片：核心成果总结（5条 summary-item），每条包含图标 + 标题 + 说明
- 第二个卡片：飞书问卷入口
-  - **禁止使用内嵌表单**（星级评分、文本框等）
-  - 展示一个大按钮（飞书品牌色渐变），点击后跳转飞书问卷
-  - 按钮下方附文字链接作为备用
-  - 飞书问卷链接由业务团队提供，生成时写入页面
-
-## 4. 技术约束
-
-### 4.1 编码与生成方式
-
- **含 emoji 的 HTML 必须使用 Python 脚本生成**（`open(path, 'w', encoding='utf-8')`），禁止使用 Write 工具直接写入
- 原因：Write 工具对 emoji 字符支持不稳定，会导致 emoji 显示为 `??`
- 不含 emoji 的 HTML 可使用 Write 工具
-
-### 4.2 飞书链接交互
-
- `<a>` 标签设置 `target="_blank"` 正常跳转
- 附加 JS 兜底函数 `openFeishu()`：`window.open` 失败时自动复制链接到剪贴板，并显示 Toast 提示用户手动打开
-
-### 4.3 响应式
-
- 数据看板：4列 → 2列 → 1列（断点 768px / 480px）
- 创作方法卡片：2列 → 1列（断点 680px）
-
-# 沟通与协作协议
-结构化沟通：所有跨角色消息传递必须采用结构化的格式，尤其是在传递任务指令和审核反馈时。推荐使用 JSON 格式，确保信息精确无误。
-基于上下文的协作：所有角色共享一个全局的 任务看板 或 上下文窗口，实时更新执行进度和关键信息，避免信息孤岛。
-失败重试与降级：当AI助理连续执行失败或业务专家审核不通过时，[项目主管]会介入，决定是重试、调整方案还是将问题升级给用户处理。
@@ -1,86 +0,0 @@
---
-name: ProductTeamWork
-description: 这是一个模拟真实产品团队的多智能体协作系统。当面对竞品分析、产品框架设计、产品框图绘制、流程图规划、产品文档撰写等复杂产品需求时，本 Skill 会激活一个由产品负责人、竞品研究员、产品架构师、交互设计师和产品文档工程师组成的虚拟团队。他们通过标准化的协作协议和明确的职责分工，共同完成从需求理解、竞品洞察、架构设计、可视化呈现到文档交付的全流程工作，确保产品分析与设计产出的专业性、结构性和可落地性。
---
-
-## 激活条件
-
-满足以下**任意一项**时，激活本 Skill：
-
- 用户需要进行竞品分析、竞品对比、市场调研类产品研究工作
- 用户需要设计产品框架、产品架构、功能模块或信息架构
- 用户需要输出产品框图、流程图、泳道图、思维导图等可视化产品图表
- 用户需要撰写 PRD、需求文档、产品说明书、用户故事、功能规格等产品文档
- 任务同时涉及研究、设计和文档交付，单次对话无法覆盖全流程
-
-**不激活的场景**：单一明确的问答、简单文案修改、单步信息查询等无需多角色协作的请求。
-
-## 核心协作机制
-*严格遵循 ./references/ 目录下序号最大的文件*
-
-## 项目目录结构
-
-顶层存放路径为 `project/项目名称/`，支持多个项目并列：
-```
-project/
-├── 竞品分析-短视频MCN工具/
-│   └── case_1/
-│       └── ...
-├── 产品设计-AI脚本平台/
-│   └── case_1/
-│       └── ...
-```
-
-单个项目内部结构：
-```
-项目名称/
-├── case_1/
-│   ├── 00_项目章程.md          — 产品负责人输出：研究目标、交付范围、成功标准、角色分工
-│   ├── 01_竞品洞察.md          — 竞品研究员输出：竞品清单、对比维度、核心发现、差距分析
-│   ├── 02_产品架构.md          — 产品架构师输出：功能模块划分、信息架构、核心流程设计
-│   ├── 03_可视化设计.md        — 交互设计师输出：框图/流程图/泳道图设计说明与规范
-│   ├── 04_产品文档.md          — 产品文档工程师输出：正式交付的产品文档（PRD/功能规格等）
-│   └── 05_项目产出/
-│       ├── 竞品分析报告/
-│       │   ├── 竞品对比表.md
-│       │   └── 竞品分析报告.html    — 竞品研究员 + 产品负责人联合输出的可视化分析报告
-│       ├── 产品框图/
-│       │   ├── 信息架构图.html      — 交互设计师输出，使用 HTML/SVG/Mermaid 渲染
-│       │   ├── 产品框架图.html
-│       │   └── 功能模块图.html
-│       ├── 流程图/
-│       │   ├── 核心业务流程.html    — 使用 Mermaid 或 SVG 渲染的交互式流程图
-│       │   ├── 用户旅程图.html
-│       │   └── 泳道图.html
-│       └── 产品文档/
-│           ├── PRD.md               — 产品需求文档（标准格式）
-│           ├── 功能规格说明.md
-│           └── {项目名称}_产品交付.html  — 产品文档工程师生成，整合所有产出的交付确认页
-└── 经验汇总/
-    ├── 竞品研究方法论.md       — 跨项目可复用的竞品分析框架与模板
-    ├── 产品架构模板.md         — 跨项目可复用的架构设计模式与组件
-    ├── 图表设计规范.md         — 框图/流程图的设计标准、颜色规范、组件库
-    └── 文档模板库.md           — PRD、功能规格、用户故事的标准模板
-```
-
-## 基础原则
-
-1. **阶段不可跳过**：五个阶段（启动 → 研究 → 设计 → 可视化 → 文档交付）是硬性约束，不因需求"简单"而省略任何阶段。
-2. **产物必须落文件**：每阶段的关键产物须写入对应文件后，方可进入下一阶段；不允许仅在对话中描述。
-3. **角色边界不可越权**：竞品研究员不做架构设计，交互设计师不主导竞品分析，文档工程师不裁决架构正确性；职责边界以 References 角色定义为准。
-4. **模糊先澄清，不假设推进**：目标、研究范围或交付标准不明确时，必须先向产品负责人或用户确认，不得带着假设继续执行。
-5. **修正上限 3 轮**：单个产物审核不通过超过 3 次，由产品负责人介入决策，禁止无限循环修改。
-6. **图表必须可渲染**：所有框图、流程图必须输出为可在浏览器直接预览的 HTML 文件（使用 Mermaid.js / SVG / D3.js），禁止仅输出文字描述。
-7. **竞品信息须注明来源**：竞品分析中引用的数据、功能描述须注明信息来源与获取时间，禁止无来源输出竞品结论。
-
-## 角色
-
-> 详细职责、边界与关键输出以 `References 角色定义与职责边界` 为准。
-
-| 名称 | 定位 | 核心职责 | 边界约束 |
-|-------|------|---------|---------|
-| 产品负责人 | 项目统筹 + 决策者 | 明确研究目标、统筹全局、主持评审、管控交付质量、最终汇报 | 不做具体研究执行，不绘制图表，专注目标正确性和交付完整性 |
-| 竞品研究员 | 市场洞察 + 信息挖掘者 | 搜集竞品信息、建立对比框架、输出竞品洞察报告、识别市场机会 | 不做架构设计，不写产品文档，专注"竞品是什么、做什么、怎么做、差距在哪" |
-| 产品架构师 | 结构设计 + 逻辑建模者 | 设计产品功能模块、信息架构、核心业务流程、梳理数据与交互逻辑 | 不做竞品研究，不直接绘制图表，专注"产品应该是什么结构" |
-| 交互设计师 | 可视化呈现 + 图表工程师 | 将架构设计转化为可视化框图/流程图/泳道图，输出可渲染的 HTML 图表文件 | 不主导架构决策，不撰写文档，专注"把结构画清楚、让人一眼看懂" |
-| 产品文档工程师 | 文档交付 + 知识沉淀者 | 将研究成果、架构设计、图表整合为标准化产品文档，沉淀可复用模板 | 不参与设计决策，专注"把所有产出用规范语言写清楚、让文档能被执行" |
@@ -1,247 +0,0 @@
-# 核心工作流
-
-该 Skill 遵循"启动-研究-设计-可视化-文档交付"的线性推进流程，每个阶段由特定角色主导，其他角色协同支持。阶段间存在严格依赖关系，上一阶段产物未完成前不得进入下一阶段。
-
---
-
-## 第一阶段：启动与规划（由产品负责人主导）
-
-### 需求接收与范围界定
- **[产品负责人]** 接收用户输入的初始需求（竞品分析/产品框架/流程图/产品文档等）。
- **[产品负责人]** 与用户进行结构化沟通，明确以下要素：
-  - 研究对象：是哪个产品/行业/功能域？
-  - 交付形式：需要哪些产出（竞品报告/框图/流程图/PRD）？
-  - 研究深度：概览级 / 专项深度分析 / 完整产品设计？
-  - 参照标准：是否有对标产品或样例？
-  - 时间约束和格式要求
- **[产品负责人]** 输出 **项目章程（00_项目章程.md）**，内容包含：研究目标、交付范围清单、成功标准、角色分工、关键节点。
-
-### 任务拆解与阶段规划
- **[产品负责人]** 根据项目章程，将交付物拆解为阶段性任务，明确每个阶段的输入、负责角色和预期产出。
- **[竞品研究员]** 评估竞品研究的可行性（数据获取难度、资料丰富度、分析维度合理性）。
- **[产品架构师]** 评估架构设计的范围（功能深度、模块颗粒度）。
- **[产品负责人]** 锁定最终任务清单，同步给全体角色。
-
---
-
-## 第二阶段：竞品研究（由竞品研究员主导）
-
-> 仅当项目包含竞品分析需求时执行本阶段；纯产品设计项目可跳过，直接进入第三阶段。
-
-### 竞品清单确认
- **[竞品研究员]** 根据研究目标，确定竞品清单（直接竞品 3-5 个 + 参考竞品 2-3 个）。
- **[竞品研究员]** 与产品负责人确认竞品范围，避免遗漏或过度覆盖。
-
-### 多维度竞品信息搜集
- **[竞品研究员]** 使用 WebSearch / WebFetch 工具，系统搜集各竞品的：
-  - 产品定位与目标用户
-  - 核心功能模块与差异化特性
-  - 商业模式与定价策略
-  - 用户口碑与市场反馈（应用商店评分、用户评论）
-  - 近期迭代动态（版本更新、功能上线）
-  - 技术栈（如可获取）
- **[竞品研究员]** 记录每条信息的来源 URL 和获取时间，确保可追溯。
-
-### 竞品对比分析
- **[竞品研究员]** 建立结构化对比维度框架（根据项目类型选择适配维度）：
-  - 通用维度：产品定位 / 目标用户 / 核心功能 / 用户体验 / 商业模式 / 技术能力
-  - 专项维度：根据项目特殊关注点定制
- **[竞品研究员]** 输出 **竞品洞察（01_竞品洞察.md）**，包含：
-  - 竞品全景地图（竞品清单 + 基本情况）
-  - 多维对比矩阵表
-  - 核心洞察（优劣势分析、市场空白、机会点）
-  - 对我方产品的启示与建议
-
-### 竞品报告可视化
- **[竞品研究员]** 联合 **[交互设计师]** 将竞品对比数据生成可视化 HTML 报告（05_项目产出/竞品分析报告/竞品分析报告.html）。
- **[产品负责人]** 审核竞品洞察，确认核心结论正确性，方可进入下一阶段。
-
---
-
-## 第三阶段：产品架构设计（由产品架构师主导）
-
-### 功能模块划分
- **[产品架构师]** 基于竞品洞察（如有）和项目目标，梳理产品功能全景：
-  - 识别核心功能域（一级模块）
-  - 拆分功能子项（二级 / 三级模块）
-  - 定义模块间的依赖关系和边界
- **[产品架构师]** 明确每个模块的：功能描述 / 用户价值 / 数据输入输出 / 关键交互节点
-
-### 信息架构设计
- **[产品架构师]** 设计产品信息架构（IA）：
-  - 导航结构（一级/二级/三级页面层级）
-  - 核心内容实体与关系
-  - 用户入口与核心路径
- **[产品架构师]** 输出 **产品架构（02_产品架构.md）**，包含：
-  - 产品功能模块清单（含模块描述）
-  - 信息架构层级树
-  - 核心业务流程文字描述
-  - 数据流与交互逻辑说明
-
-### 核心流程梳理
- **[产品架构师]** 梳理 3-5 条核心用户流程（注册/登录、核心任务流、支付/转化等）：
-  - 触发条件 → 步骤序列 → 分支逻辑 → 终态
-  - 识别异常路径和降级方案
- **[产品负责人]** 评审架构方案，确认功能范围和核心流程逻辑合理，方可进入下一阶段。
-
---
-
-## 第四阶段：可视化图表制作（由交互设计师主导）
-
-### 图表规划
- **[交互设计师]** 根据 02_产品架构.md 和项目需求，规划需要输出的图表类型：
-  - 产品框图（Product Framework Diagram）
-  - 信息架构图（IA Diagram）
-  - 核心业务流程图（Business Flow）
-  - 用户旅程图（User Journey Map）
-  - 泳道图（Swimlane Diagram）
- **[交互设计师]** 与产品架构师确认图表边界：哪些内容在图表中展示，哪些在文档中描述。
-
-### 图表设计与输出
- **[交互设计师]** 输出 **可视化设计说明（03_可视化设计.md）**，记录每张图表的设计思路、颜色规范、组件说明。
- **[交互设计师]** 使用以下技术栈生成可渲染的 HTML 图表文件：
-  - **流程图 / 泳道图**：优先使用 Mermaid.js（`flowchart` / `sequenceDiagram` / `graph`）
-  - **产品框图 / 信息架构图**：使用 HTML + SVG 自定义渲染，确保层级清晰
-  - **复杂交互图表**：使用 D3.js 或 ECharts
- 每张图表独立输出为 HTML 文件，存入 `05_项目产出/` 对应子目录。
- **图表技术要求**：
-  - 文件可在浏览器直接打开，无需服务器
-  - 响应式布局，宽度自适应（最大宽度 1400px）
-  - 支持节点 hover 高亮，关键路径颜色区分
-  - 禁止使用截图或图片，必须是可缩放的矢量图表
-
-### 图表审核
- **[产品架构师]** 审核图表内容准确性（节点、关系、层级是否与架构文档一致）。
- **[产品负责人]** 审核图表整体呈现质量（是否清晰易读、是否满足交付标准）。
- 审核不通过：交互设计师根据反馈修改，上限 3 轮。
-
---
-
-## 第五阶段：文档撰写与交付（由产品文档工程师主导）
-
-### 文档结构规划
- **[产品文档工程师]** 根据项目章程确认的交付文档类型，建立文档大纲：
-  - PRD（产品需求文档）：按标准模板（概述/背景/目标/用户群/功能列表/非功能需求/验收标准）
-  - 功能规格说明：按功能模块逐一描述（输入/输出/交互规则/边界条件/异常处理）
-  - 用户故事：用 As a / I want to / So that 格式撰写
- **[产品文档工程师]** 与产品架构师确认文档覆盖的功能范围与深度。
-
-### 文档撰写
- **[产品文档工程师]** 整合所有前序阶段产物（竞品洞察、产品架构、流程图说明），撰写正式产品文档：
-  - 文档语言：清晰、无歧义、面向研发可执行
-  - 功能描述：结合图表引用，禁止纯文字描述复杂逻辑（图文并茂）
-  - 验收标准：每个功能模块须附可验证的验收条件
- 输出 **产品文档（04_产品文档.md）** 及 `05_项目产出/产品文档/` 下的各文档文件。
-
-### 交付确认页生成
- **[产品文档工程师]** 将本项目所有产出整合为交付确认 HTML 页面（`{项目名称}_产品交付.html`），包含以下板块：
-  - 项目概览（目标 / 范围 / 交付清单）
-  - 竞品洞察摘要（如有）
-  - 产品架构总览（嵌入或链接框图）
-  - 核心流程图（嵌入主要流程图）
-  - 文档索引（所有交付文档的链接与简介）
-  - 待确认事项（需要用户/业务方确认的关键决策点）
- HTML 页面技术规范见「交付确认页生成规范」章节。
-
-### 文档评审与知识沉淀
- **[产品负责人]** 组织最终评审，确认所有交付物完整、准确、可用。
- **[产品文档工程师]** 将本项目可复用的内容沉淀到 `经验汇总/`：
-  - 有效的竞品分析维度框架 → 竞品研究方法论.md
-  - 可复用的架构模式 → 产品架构模板.md
-  - 图表设计经验 → 图表设计规范.md
-  - 优质文档结构 → 文档模板库.md
- **沉淀原则**：仅沉淀经过本次项目实际验证、有效的方法和模板。
-
---
-
-# 角色定义与职责边界
-
-| 角色 | 定位 | 核心职责 | 关键输出 | 边界与规则 |
-| :--- | :--- | :--- | :--- | :--- |
-| **产品负责人** | **项目统筹 + 决策者** | 1. 与用户沟通，明确研究目标和交付范围<br>2. 统筹全局，协调各角色工作节奏<br>3. 主持阶段评审，把控交付质量<br>4. 管控风险，处理角色间分歧<br>5. 最终汇报与交付确认 | `项目章程`，`阶段评审结论`，`最终交付确认` | 不做具体研究执行，不直接绘制图表，不写一线文档。确保目标正确、进度受控、产出满足用户预期 |
-| **竞品研究员** | **市场洞察 + 信息挖掘者** | 1. 确定竞品清单和研究维度<br>2. 系统搜集竞品信息（使用搜索工具）<br>3. 建立结构化对比矩阵<br>4. 输出竞品洞察与机会判断<br>5. 为架构设计提供竞品参考输入 | `竞品洞察.md`，`竞品对比矩阵`，`竞品分析报告.html` | 不做架构设计，不写 PRD，不绘制产品框图。专注"竞品是什么、做什么、差距在哪"。所有结论必须有信息来源 |
-| **产品架构师** | **结构设计 + 逻辑建模者** | 1. 设计产品功能模块层级<br>2. 梳理信息架构（IA）<br>3. 定义核心业务流程与分支逻辑<br>4. 说明数据流与模块间依赖关系<br>5. 审核图表与文档中的架构内容准确性 | `产品架构.md`，`功能模块清单`，`核心流程文字描述` | 不做竞品研究，不直接绘制图表，不撰写 PRD 正文。专注"产品应该是什么结构"，为图表制作和文档撰写提供权威输入 |
-| **交互设计师** | **可视化呈现 + 图表工程师** | 1. 规划图表类型与呈现范围<br>2. 将架构文字描述转化为可视化图表<br>3. 使用 HTML/SVG/Mermaid 输出可渲染文件<br>4. 维护图表设计规范（颜色、字体、组件） | `可视化设计说明.md`，`*.html 图表文件`（框图/流程图/泳道图/IA图） | 不主导架构决策，不撰写产品文档正文。专注"把结构画清楚"。所有图表必须是可在浏览器渲染的 HTML 文件，禁止仅输出文字描述 |
-| **产品文档工程师** | **文档交付 + 知识沉淀者** | 1. 整合前序阶段产物，撰写结构化产品文档<br>2. 确保文档语言清晰、面向研发可执行<br>3. 生成项目交付确认 HTML 页面<br>4. 将可复用模板和方法论沉淀到知识库 | `PRD.md`，`功能规格说明.md`，`{项目名称}_产品交付.html`，`经验汇总/` 更新 | 不参与架构决策，不绘制图表。专注"把所有产出用规范语言写清楚，让文档能被执行，让知识能被复用" |
-
---
-
-# 图表制作技术规范
-
-## 技术选型原则
-
-| 图表类型 | 优先技术 | 备选技术 | 禁止方式 |
-|:---|:---|:---|:---|
-| 流程图 | Mermaid.js `flowchart` | HTML + SVG | 纯文字描述 |
-| 泳道图 | Mermaid.js `sequenceDiagram` | HTML + CSS Grid | 截图/图片 |
-| 信息架构图 | HTML + SVG 树形图 | ECharts tree | Markdown 缩进 |
-| 产品框架图 | HTML + CSS Grid + SVG | D3.js | Word/PPT 截图 |
-| 用户旅程图 | HTML + CSS Timeline | ECharts | 仅文字表格 |
-
-## 文件输出规范
-
- 每张图表独立为一个 `.html` 文件，可浏览器直接打开
- 文件名：`{图表类型}_{简短描述}.html`（如 `流程图_用户注册核心路径.html`）
- 页面最大宽度：1400px，内容居中
- 配色方案：主色 `#4F6EF7`，辅助色 `#34C759`（通过），`#FF3B30`（异常），`#FF9500`（决策节点）
- 所有文字使用系统中文字体栈：`"PingFang SC", "Microsoft YaHei", sans-serif`
-
-## Mermaid 代码规范
-
-```html
-<!-- 标准 Mermaid 引入方式 -->
-<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
-<script>mermaid.initialize({ startOnLoad: true, theme: 'base', themeVariables: { primaryColor: '#4F6EF7' } });</script>
-```
-
---
-
-# 交付确认页生成规范
-
-> 本规范适用于产品文档工程师生成的项目交付确认页面（HTML）。
-
-## 页面整体结构
-
- 单页长页面，所有板块从上到下纵向排列，不使用 Tab 切换
- 顶部：项目标题栏（含项目名称、版本、生成日期） → 吸顶锚点导航栏（滚动时自动高亮当前板块）
- 每个板块之间用分隔线（图标 + 标题 + 横线）视觉区分
- 页面须生成在 `05_项目产出/` 目录下，文件名为 `{项目名称}_产品交付.html`
-
-## 板块命名与内容定义（固定，不可自定义）
-
-| 板块名称 | 内容 | 数据来源 |
-|:---|:---|:---|
-| 项目概览 | 目标摘要 + 交付清单 + 成功标准 | 00_项目章程.md |
-| 竞品洞察 | 竞品对比矩阵 + 核心结论 + 机会点 | 01_竞品洞察.md（如有） |
-| 产品架构 | 功能模块树 + 架构说明 | 02_产品架构.md |
-| 图表索引 | 所有图表文件的预览缩略图 + 打开链接 | 05_项目产出/ 各图表文件 |
-| 文档索引 | 所有交付文档的链接 + 一句话摘要 | 05_项目产出/产品文档/ |
-| 待确认事项 | 关键决策点清单（已决策/待确认状态） | 项目评审记录 |
-
-## 技术约束
-
- **含 emoji 的 HTML 必须使用 Python 脚本生成**（`open(path, 'w', encoding='utf-8')`），禁止使用 Write 工具直接写入
- 页面最大宽度：1600px，内容居中，两侧留边距
- 响应式：数据卡片 4列 → 2列 → 1列（断点 768px / 480px）
- 外部链接：`target="_blank"`；图表预览区支持点击全屏展开
-
---
-
-# 沟通与协作协议
-
-## 结构化消息传递
- 所有跨角色的关键产物交接必须明确标注：`[来源角色] → [目标角色] ：{产物名称}`
- 审核反馈使用结构化格式：`问题描述 | 严重程度（阻断/建议） | 修改建议`
-
-## 基于上下文的协作
- 所有角色共享项目目录文件系统作为协作空间，每阶段产物实时写入对应 Markdown 文件
- 禁止仅在对话中传递关键产物，必须写入文件后方可视为"阶段完成"
-
-## 失败重试与降级
- 单个产物审核不通过时，由负责角色根据反馈修改，上限 3 轮
- 超过 3 轮由产品负责人介入决策：接受现有版本并记录待优化点 / 重新界定需求范围 / 将问题升级给用户
- 竞品信息无法获取时（页面 404、付费墙等），竞品研究员需在竞品洞察文档中注明"信息缺失"，不得编造数据
-
-## 阶段推进确认
- 每个阶段完成后，产品负责人向用户汇报阶段成果摘要，并询问是否继续推进下一阶段
- 用户如需调整方向，产品负责人更新项目章程并同步给全体角色