用交接契约串技能，而不是连续转发草稿
一家面包店要改进预订订单的取货说明。顾客把“备货中”理解成可以取货，店员则担心提醒发早后反复解释。PM 希望把反馈、数据和需求连起来，而不是每周重新整理同一批资料。本例用合成留言、访谈摘录和练习订单事件，定义三份交接文件：研究发现表、指标与决策记录、PRD 和周报交付包。
每份文件都写版本、负责人、输入范围、证据位置、未决项和验收条件。下游只读取已确认版本；来源不足的结论保留为问题，不因为经过多个代理就变成事实。下面是教学流程，不代表已经访问店铺系统、联系顾客或发送提醒。
第一段交接：把评论和访谈整理成需求证据
先收集明确允许使用的反馈导出，记录渠道、时间范围、筛选条件和缺失部分。公开可见不等于可以任意批量抓取或向外传输；没有合适授权时只用提供的本地样本。移除姓名、订单号、电话等可识别信息，用研究编号关联材料。相同记录的重复导出可以去重，内容相近但来自不同人的反馈不能随意合并。
把研究任务拆成具体问题：顾客在哪一步判断可以取货，用什么线索选择到店时间，遇到等待后怎样处理。对留言做主题初分，但每个主题必须带支持编号和不适用例子；抽查后才统计样本内频次。不要把“没看见提醒”直接归类为通知失败，也可能是提醒尚未发送、渠道不同或文案没说明下一步。
访谈表用不同列保留原话、行为、需求层级、使用情境、决策路径、动机假设与待验证问题。这些维度帮助提问，不是必须填满的心理画像。忙于通勤的顾客和替家人取货的人可能关注不同信息，分层应由证据支持；不知道的动机留空，不替受访者补台词。
第一份交接的验收是：每条需求可回到片段，反例没有被删除，样本边界明确，问题有负责人。例如发现 F3 为“备货中与可取货的区别不清”，候选需求是显示状态说明，而不是立即承诺增加短信。缺失真实渠道覆盖时，注明结论只适用于练习材料。
第二段交接：先检查数据，再写指标
列出当前能够获得的数据：订单创建、备货、可取货、完成交付事件，以及其时间、版本和来源。确认字段定义与时区，区分订单、事件和访问次数。重复导出、缺少完成时间、测试订单、取消与跨天取货都要单独约定，不能让工具为了图表好看静默删除。
Exploratory Data Analysis 用在这里：检查获准的本地 CSV 的字段、缺失和聚合异常，产出数据质量摘要。核心命令需要 Python 3.11 以上，完整可选环境要求更多依赖；按固定版本 SKILL.md 确认支持范围。限制输入目录和输出位置，保留原数据，不输出可识别行；不支持的格式应停下说明。它不是自动化看板连接器，也不证明实验有因果效果。
指标不要只列名字。激活可以暂定义为首次查看取货说明后完成一次练习确认的有效订单比例；留存若业务需要，应先定义观察单位与周期，低频顾客不能用每日回访简单衡量。展示规范写清分子分母、排除规则、延迟、筛选条件和数据负责人。先拿十条人工可核对的合成记录算一遍，确认结果与规则一致，再考虑扩大。
实验记录先写假设：明确“备货中尚不可取”的提示，可能减少提前到店。确定分配单位、主要指标、观察窗、护栏和停止条件，并检查是否存在同一顾客跨组、节日备货差异或漏记。样本不足时输出描述和缺口，不让代理把两组小数差异写成显著提升；统计判断需要合适的方法和负责人审核。
决策记录怎样变成优先级
把候选方案放在同一张表：改状态文案、显示预计时间、增加外部提醒。比较证据强度、影响范围、成本、风险和依赖。本例先做文案与状态解释，因为能在不增加外部通信渠道的情况下验证理解；预计时间的准确数据还未准备好，外部提醒也需要另外确认前提。
决定记录必须包含选择理由、没有选择的方案、仍未证实的假设和复查条件。代理负责整理，不凭下载量替团队决定。由负责人确认范围后，再拆为任务：先统一状态词；再写正常、延迟和失败文案；再做样本走查；最后决定是否试点。每项有负责人、依赖、完成证据和验收规则，不能用“尽快完成”当排期。
第三段交接：PRD 与周报引用同一证据链
PRD 读取已确认的 F3 发现和决策版本，写目标用户、问题、范围、状态流程、权限、异常、验收与开放问题。示例规则是：备货中不出现“现在到店”，可取货状态才出现取货动作说明；状态获取失败时显示未知并提供咨询方式，不能回退成可取货。所有状态均为练习，真实系统映射需工程与门店负责人确认。
用输入状态、预期文案、允许动作、禁止动作四列定义验收样本。把文字改动与真实发送逻辑分开，本轮不发送任何消息。需求变更时同时更新样本和引用记录，让评审者可以从规则回到研究原因，避免 PRD 和周报讲两个版本。
周报由任务与验收记录生成：已完成项引用记录，未完成项说明阻塞及负责人，下周计划写成待执行行动。不要把生成草稿写成上线，不要把拟定指标写成已有看板。按读者角色调整重点：门店看操作变化，工程看依赖与失败条件，负责人看证据和下一步决定，但不能给不同读者编不同事实。
Writing Guidelines 可以用于这一步的技术表述走查：提供目标文档、受众和读取链接写作手册的条件，获得带位置的修改建议，再按团队语言调整。它不替代事实核对、系统登录、取数或 Word 导出。需要格式化 Word 时使用适合的导出工具并重新打开检查表格、链接和分页；没有检查的格式不能说已验收。
安装与报告流水线的前提
先检查 SkillPI Skill Finder 是否已安装，缺少时按 官方说明 安装，再以交付物找技能，逐一核对版本、来源、许可证和执行条件。GitHub 的 PM Skills 方法库 可用于参考分阶段产物，不把它冒充成已关联的本站卡片。Codex 的调用机制参考 官方技能文档，同名描述可能重叠，不能承诺永不冲突。
自动周报还涉及业务系统访问、字段口径、格式转换和交付对象，每一步都应单独核验。有授权才使用相应系统；本例从本地样本开始，没有经过验证的连接器时保留人工导出，不猜测系统登录步骤。安装一个技能不会自动赋予账号或数据权限。
从第一周开始检验是否值得继续
先选一段重复工作，用同一组资料对比人工和代理的总用时、纠正次数、遗漏、有效发现及实际费用。后续改规则只保留有理由的变更，并用旧样本回归。新技能进入 SkillPI 后，也用这份交接契约测试用途是否更匹配，再刷新关联。
传统行业能用吗？来源、口径、决策与验收的方法可以迁移，业务规则必须由领域负责人提供，不能直接套用互联网留存指标。多个技能会冲突吗？可能存在重复描述、依赖或输出格式差异，显式规定每步读什么、写什么、谁接手。开始最需要什么？一份允许使用的样本和明确的验收任务，比一次装齐六个名字更有助于发现真正的瓶颈。