dogfooding

内部试用

范围

涵盖

• 设计并运行内部试用循环，让产品团队像真实用户一样使用产品
• 如果产品面向创作者，则制定“创作者承诺”（例如，发布播客、交付工作流、运行每周报告）
• 将问题记录为可复现的材料（而非主观感受）：日志、严重程度、决策、负责人和后续跟进

适用情况

• “为我们的产品团队搭建内部试用计划／内部试用冲刺。”
• “我们很快就要发布了——确保大家每天都在使用产品，并修复最棘手的问题。”
• “这是为创作者打造的产品；我们的团队需要成为创作者，才能理解整个工作流。”
• “制定内部 Beta 计划和每周内部试用报告模板。”

不适用情况

• 你需要验证市场需求，或弄清客户是谁／问题是什么（应先开展探索）
• 如果没有代理参与，产品团队就无法真实代表该工作流（例如，受监管的岗位、硬件限制）
• 你想用它替代用户研究（内部试用可以补充外部用户反馈，但不能替代）
• 唯一目标是“全面 QA”（应使用 QA／测试计划；内部试用关注的是体验 + 价值 + 真实的工作流）

输入

最低要求

• 产品简介 + 目标用户画像（面向谁；解决什么任务）
• 1–3 个需要进行内部试用的核心工作流（端到端）
• 时间范围 + 频率（例如，1 周冲刺；每天 20 分钟；每周分类处理）
• 参与者（角色）+ 所需的任何“创作者承诺”
• 环境限制（生产环境还是预发布环境；数据／隐私限制；访问限制）

缺少信息时的处理策略

• 从 references/INTAKE.md 中最多提出 5 个问题。
• 如果无法获得答案，则明确列出假设并标注未知信息。提供 2 种范围选项（精简版与全面版）。

输出（交付内容）

以 Markdown 形式生成内部试用包（在聊天中提供；或按要求提供文件）：

1. 背景摘要（产品、用户画像、工作流、限制、时间范围）
2. 内部试用章程（目标、参与者、规则、频率、定义）
3. 场景图 + 例行安排（每日／每周任务 + “创作者承诺”）
4. 内部试用日志 + 分类处理看板规范（字段、严重程度等级、决策规则）
5. 每周内部试用报告（洞察、决策、已发布的修复、下一轮实验）
6. 风险／待解决问题／后续步骤（必须包含）

模板：references/TEMPLATES.md

工作流（7 个步骤）

1) 明确内部试用目标（关注体验，而不只是 Bug）

• 输入： 产品简介；预期成果；references/INTAKE.md。
• 操作： 明确本轮的“成功”标准（例如，“团队无需绕过流程即可在 10 分钟内完成工作流 A”）。设定限制（环境、数据、访问权限）。
• 输出： 背景摘要 + 明确的成功标准。
• 检查： 成功标准可衡量，且与真实的工作流成果相关（而不是“感觉更好”）。

2) 定义有代表性的场景 + “创作者承诺”

• 输入： 目标用户画像 + 工作流。
• 操作： 创建 3–8 个代表真实用户目标的场景。如果产品面向创作者，则制定发布频率（例如，“每位 PM 每周发布 1 个作品”）。
• 输出： 场景图 + 例行计划。
• 检查： 至少有 1 个场景覆盖“从零开始 → 交付／发布”的完整端到端流程。

3) 设置问题记录系统（日志、严重程度、分类处理）

• 输入： 现有工具（Jira/Linear/Notion/Sheets）或“无”。
• 操作： 定义内部试用日志结构、严重程度等级和分类处理规则。确定用于将问题关联到场景和工作流步骤的标签。
• 输出： 内部试用日志 + 分类处理看板规范。
• 检查： 任何问题都能通过明确的“复现步骤 + 预期结果与实际结果对比 + 证据”进行复现。

4) 开展日常内部试用（限时进行）

• 输入： 场景图 + 日常流程。
• 操作： 每位参与者每天运行 1–2 个场景，立即记录摩擦点，并附上证据（屏幕截图、日志、时间戳）。记录“使用的变通方法”。
• 输出： 每日日志条目 + 持续更新的“主要痛点”列表。
• 检查： 条目内容具体（包含复现步骤），并按其对完成工作流的影响排序。

5) 每周分类处理：决策、分配并保障专注

• 输入： 日志 + 主要痛点。
• 操作： 开展分类处理：合并重复项，归类（Bug/UX 技术债/缺口/文档），指定负责人，并决定“立即修复/安排计划/不予修复（说明原因）”。如果场景图不切实际，则进行更新。
• 输出： 排定优先级的待办事项 + 决策记录。
• 检查： 排名前 3–5 的问题与受阻/进展缓慢的场景直接对应，且都有负责人 + 后续行动。

6) 发布循环：再次通过内部试用验证修复（发布门槛）

• 输入： “立即修复”事项 + 发布计划。
• 操作： 对每项修复，端到端地重新运行场景。采用简单的门槛：“在选定环境中，无需隐藏的变通方法即可完成场景。”
• 输出： 已验证的修复列表 + 所有回归问题。
• 检查： 门槛依据是能否完成场景，而不只是关闭工单。

7) 报告 + 质量门槛 + 下一周期计划

• 输入： 最终日志 + 分类处理结果。
• 操作： 编写每周报告。运行 references/CHECKLISTS.md 中的检查清单，并使用 references/RUBRIC.md 评分。添加风险/待解决问题/后续步骤，并提出下一轮内部试用的重点。
• 输出： 最终内部试用资料包。
• 检查： 报告包含决策（有哪些变化），并展示有证据支持的经验总结（而不只是 Bug 列表）。

质量门槛（必需）

• 使用 references/CHECKLISTS.md 和 references/RUBRIC.md。
• 务必包含：风险、待解决问题、后续步骤。

示例

示例 1（创作者产品）：“我们正在开发一款播客创作工具。请制定一个内部试用计划，让整个团队每周发布 1 集短节目，并提供每周报告模板。” 预期：从“创意 → 已发布节目”出发的场景、创作者承诺、日志架构、分类处理频率，以及与发布挂钩的发布门槛。

示例 2（B2B 工作流产品）：“为我们的 AI 会议纪要工具安排一场为期 2 周的内部试用冲刺，重点关注‘录制 → 总结 → 分享 → 行动项’。” 预期：场景图、日常流程、严重程度量表、分类处理规则、每周报告，以及已验证的修复列表。

边界示例：“对这个尚未开发的想法进行内部试用。” 回复：内部试用需要有可用的产物；建议先进行探索 + 原型/可用性测试，待有可端到端运行的内容后，再开展内部试用冲刺。