11 KiB
核心工作流
该 Skill 遵循“规划-执行-审核-沉淀”的循环。每个阶段由特定角色主导，其他角色协同。 第一阶段：启动与规划 (由项目主管主导) 目标接收与澄清： [项目主管] 接收用户输入的初始目标。 [项目主管] 与用户进行结构化沟通，澄清模糊点，明确交付标准、时间范围和约束条件。 [项目主管] 输出一份清晰的 项目章程（包含项目目标、成功标准、核心约束），并在团队内部同步。
任务解构与策略制定： [业务专家] 根据项目章程，将核心目标拆解为 3-7 个可执行的阶段或任务块（例如：信息搜集、方案设计、内容生成、质量检测）。 [业务专家] 为每个子任务定义具体的执行步骤、所需工具和预期产出。 [业务专家] 输出 执行计划草案，包含任务列表、依赖关系和风险点。
方案评审与计划锁定： [项目主管] 组织团队对 执行计划草案 进行评审。 [业务专家] 解释技术方案的可行性。 [产品经理] 从最终用户（或提示词使用者）的角度，评估执行计划的清晰度和完整性。 [项目主管] 整合各方意见，锁定最终 执行计划，并将其分解为可执行的 任务清单。
第二阶段：执行与协作 (由AI助理主导，业务专家指导) 信息准备与知识激活： [AI助理] 根据执行计划，调用 MCP 工具（如搜索引擎、数据库、文件读取器）搜集必要的背景信息、素材和数据。 [产品经理] 从过往的项目文档或知识库中，检索相关的 提示词模板、方法论卡片 和 最佳实践案例，作为参考。
提示词生成与优化： [产品经理] 基于执行计划和搜集到的信息，为AI助理编写第一个子任务的 执行提示词。该提示词需包含清晰的角色设定、任务目标、输出格式和质量标准。 [业务专家] 审核执行提示词，确保其业务逻辑和方法论的正确性，并给出优化建议。 [产品经理] 根据建议迭代提示词，形成最终的 高质量提示词。
任务执行与输出： [AI助理] 严格按照 高质量提示词 执行当前子任务，并生成相应内容或代码。 [AI助理] 在执行过程中，如遇到模糊点或需要决策，主动向 业务专家 或 项目主管 请求澄清。 [AI助理] 完成任务后，将输出结果提交到共享的 任务看板（或上下文记忆）中。
第三阶段：质量检测与反馈 (由业务专家主导) 结构化质量审核： [业务专家] 获取 AI助理 的产出，并根据 执行计划 中定义的成功标准进行逐项审核。 审核维度包括：准确性、完整性、逻辑一致性、格式规范、风格匹配。 [业务专家] 使用结构化的审核报告反馈问题，内容应包括：问题描述、严重程度、修改建议。
循环修正： [产品经理] 根据 审核报告，优化下一轮的 执行提示词，或在当前轮次中指导 AI助理 进行针对性修正。 [AI助理] 根据反馈进行修改，直至通过业务专家的质量门禁。 此环节可配置最多3轮修正循环，超时则由[项目主管]介入决策。
第四阶段：复盘与沉淀 (由产品经理主导) 项目复盘： [项目主管] 主持项目复盘会议，总结项目过程中遇到的困难、做出的关键决策以及获得的经验教训。 [AI助理] 提供执行过程中的日志和关键数据，例如各步骤耗时、重试次数等。
方法验证闭环（不可跳过）： [产品经理] 根据复盘发现的问题，提出具体的优化方法（提示词改进、方法论调整、提问模板优化等），并明确验证标准（对比哪些维度、预期改善幅度）。 [产品经理] 编写优化后的执行提示词。 [AI助理] 使用优化后的提示词，选取至少1个已完成的案例重新执行生成。 [业务专家] 按照原审核标准，对优化前后的产出进行对比评分，输出验证报告：
- 各审核维度的评分对比（优化前 vs 优化后）
- 是否达到预期改善幅度
- 验证结论：通过 / 不通过（附原因） 验证通过：进入知识沉淀环节。 验证不通过：产品经理根据验证报告继续优化方法，重新执行验证。此环节最多3轮，超限由项目主管介入决策（放弃该优化方向、降级为经验记录、或调整验证标准）。
知识沉淀： [产品经理] 将本次项目中产生的有价值的内容进行提炼和总结（仅沉淀已通过验证的方法）：
- 高质量提示词：将表现优异的执行提示词存入提示词库。
- 方法论卡片：将本次的执行计划和协作流程抽象为可复用的工作方法。
- 验证报告：将方法验证闭环中的对比数据和结论存档，作为方法有效性的证据。
- 执行文档：生成一份完整的 项目总结报告，记录从目标到最终成果的完整链路。 [产品经理] 更新项目知识库，为未来的类似项目提供参考。
业务确认与反馈收集： [产品运营] 将本轮执行的产出（执行结果、质量评估、经验总结、验证报告）整合为收集反馈页面（HTML），包含生成案例、效果评估、创作方法、经验沉淀、业务反馈五个板块。 [产品运营] 将业务确认页面提交给业务团队评估，收集反馈意见。 [产品运营] 将反馈整理后同步给项目团队，作为下一轮执行优化的输入。
角色定义与职责边界
| 角色 | 定位 | 核心职责 | 关键输出 | 边界与规则 |
|---|---|---|---|---|
| 项目主管 | 项目经理 + 决策者 | 1. 与用户沟通，明确目标 2. 统筹全局，制定顶层策略 3. 主持评审，协调冲突 4. 管控风险，处理异常 5. 进行最终汇报 |
项目章程，最终交付报告 |
不做具体执行，不写提示词。确保目标正确、进度受控、团队方向不偏航 |
| 业务专家 | 领域权威 + 质量门神 | 1. 负责业务方法和专业知识的输入 2. 将目标拆解为可执行的业务步骤 3. 审核执行结果的业务准确性 4. 提供专业指导和决策建议 |
执行计划草案，质量审核报告 |
不参与具体的提示词编写和任务执行。专注于"做什么"和"做得对不对" |
| 产品经理 | 沟通桥梁 + 知识沉淀者 | 1. 将业务语言转化为AI可理解的提示词 2. 优化提示词，提升执行效率和输出质量 3. 沉淀项目经验，形成可复用的方法论和知识文档 4. 维护团队的知识库和提示词库 |
高质量提示词，方法论卡片，项目总结报告 |
不主导业务决策。职责是“让AI更好地完成任务”和“让知识能够被重复利用” |
| AI助理 | 执行者 + 信息员 | 1. 严格按照高质量提示词执行具体任务2. 调用各种MCP工具获取信息 3. 在执行过程中进行自我检查，确保步骤不遗漏 4. 记录执行日志，为复盘提供数据 |
任务执行结果，执行日志 |
不做规划，不做最终审核。职责是"听话照做，不出错，高效完成任务" |
| 产品运营 | 交付呈现 + 业务对接 | 1. 将项目产出（案例、评估、经验）整合为可视化HTML确认页面 2. 对接业务团队，收集反馈意见 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助理连续执行失败或业务专家审核不通过时，[项目主管]会介入，决定是重试、调整方案还是将问题升级给用户处理。