按用户旅程比较同类产品
Persona-grounded peer benchmarking
先确定用户和起止边界，再比较步骤与证据；估算、未知和待选择目标分别记录。
以下产品、记录、时间和输出均为虚构教学材料，不代表真实产品或实际上手测试。
使用场景
团队准备改进 Python SDK 的快速开始文档，想知道应该缩短哪些步骤。目标读者是会写 Python、首次使用该 SDK 的应用开发者。比较起点是打开快速开始文档并使用干净的环境；终点是完成第一次对自己函数的评估，并理解返回结果。
教学材料包含三份记录：
| 产品与材料 | 起点 → 终点 | 步骤 | 时间与证据类型 |
|---|---|---|---|
本产品，notes/our-sdk.md |
干净环境 → 评估自己的函数并理解结果 | 阅读、安装、配置、编写函数、运行并解释结果 | 6 分钟，教学估算；尚未观察真人操作 |
同类 A，notes/peer-a.md |
已安装并配置 → 运行预置演示 | 复制示例、运行、看预置结果 | 2 分钟，教学记录中的演示报告；不包含安装与配置 |
同类 B，notes/peer-b.md |
干净环境 → 评估自己的函数并理解结果 | 阅读、安装、配置、编写函数、运行并解释结果 | 未知，材料没有给出时间 |
这些文件名是材料出处标识，不是网络链接。实际应用时用你查阅的文档位置、版本和记录替换它们。
具体做法
- 写明目标用户、计时起点和“首次有用结果”的具体终点，包含阅读、安装、配置和结果理解所需的工作。
- 对本产品与每个同类产品记录步骤、起止边界、时间、证据类型、资料出处及有影响的设计选择。
- 先核对边界是否一致。边界不同的记录不做耗时倍数排名，转而说明设计差异；缺失时间保持未知。
- 把真人首次上手与自动执行脚本的时间分开。估算一直标为估算，直到有对应的实际观察。
- 展示比较结果和可能的改进方向，再让用户选择目标。尚未选择时保留待选择状态，不替用户确定目标或改写实施计划。
反例
用上面同样的三份记录作比较：
把 Python SDK 上手速度排个名。本产品要 6 分钟，同类 A 只要 2 分钟，所以 A 快 3 倍。同类 B 没写时间，就按没有等待算。直接把我们的目标定为 2 分钟，并据此改写实施计划。
它把本产品的估算和 A 的预热演示相除，还把未记录的时间当作零，并替用户选择了目标。
改进写法
面向首次使用 SDK 的 Python 应用开发者，比较从打开快速开始文档、使用干净环境，到评估自己的函数并理解结果的旅程。
使用给定的本产品、同类 A、同类 B 三份教学记录，列出步骤、起止边界、时间、证据类型、出处和设计选择。
本产品的 6 分钟保留为估算；A 的 2 分钟是预热后的预置演示，不与本产品做倍数排名；B 的时间保持未知。
人工首次上手与自动脚本执行分别记录。指出可比较的流程设计，以及需要补采的数据。
展示结果后询问用户：先优化安装配置、优先让结果易理解，还是先做真人上手测量？说明各方向的条件与缺失证据。
在用户选择前，把目标标为待选择，不修改实施计划。
替换读者、边界和材料后再用这份指令。教学输出可以是：A 减少了演示前的准备，但不能证明首次上手更快；B 与本产品的边界接近，却缺少时间证据；本产品应先确认安装配置和结果理解分别占多少时间。目标：待用户选择。
为什么这样改
固定读者与边界后，比较关注的是同一种工作。步骤与出处让差异可追查，证据类型避免把估算包装成测量。最后的选择点把“观察到什么”和“团队决定优化什么”分开，防止比较者替用户作出未表达的目标决定。
如何验证
检查比较表是否包含本产品、同类产品、步骤、边界、时间类型和出处。每个耗时比较的起点与终点必须一致；上面的 A 不应出现“快 3 倍”的结论，B 不应被填成零，本产品应始终标为估算。
检查输出是否将真人操作和自动执行分列。目标未回答时仍为待选择；只有收到用户答案后，才把选定目标和依据带入后续计划。若开展真实测量，要保存完整计时范围和操作记录，再更新证据类型。
适用边界
文档描述不等于真实用户表现；一次试用也不能代表所有开发者。不同账号状态、环境和任务终点会破坏可比性。同类文档没写某个步骤，不代表该步骤不存在；未知用时不能推成零。本方法整理比较依据，不保证 SDK 的性能或产品效果。