题目重点：Nvidia AI Software 技术营销面经追问如何判断新功能真的改善开发者易用性；本文从任务完成、上手效率、可靠性与持续采用设计证据链。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练例设一个 AI 推理 SDK 的新部署向导，目标用户是首次部署模型的开发者；该 SDK、功能和所有数值都是合成示例。
- 先锁定同一个目标任务：从获取 SDK 到部署可请求的模型服务，并完成一次正确推理；同时区分首次使用者与已有用户，因为两组的阻力不同。
- 与旧版本或既有流程比较，固定模型、硬件、文档可见性和网络条件；若招募样本无法随机分组，结果只能作为观察证据并说明偏差。
解题路线
- 先问工程师功能到底减少了哪一步阻力：安装、配置、编译、诊断还是部署；要求可运行的旧/新流程、目标人群、支持平台、已知限制和失败案例。性能 benchmark 不能替代易用性证据，因为吞吐提高不保证用户更容易完成任务。
- 建立分层指标：有效性看任务完成率与输出正确率；效率看首次成功时间、人工步骤数、需要改动的代码量和求助次数；可靠性看崩溃、配置错误和失败恢复时间；满意度用访谈或量表解释痛点；采用看首次试用到成功、7/30 日持续使用和回退旧版的比例。每项先定义起止事件、排除规则和分母。
- 做小样本任务观察，记录屏幕和失败原因，发现流程中的真实阻塞点；再用更大样本的 A/B 或分批发布量测完成率、时间分布与持续采用。按新手/熟手、平台、模型大小、文档入口分组，避免总体均值掩盖某组明显变差。
- 发布文章时展示任务、环境、样本、旧新版步骤、主要结果及不确定性，并提供复现脚本和限制条件；只把显著改善且未损害正确率或安全性的指标写成主张。把尚未验证的‘开发者更喜欢’表述为假设或定性反馈。
手动走一遍
合成例：各招募 20 名首次接触 SDK 的开发者，随机分旧版与新向导，各完成同一个部署任务。旧版 7/10 成功、中位首次成功 45 分钟；新版 9/10 成功、中位 28 分钟，但有 2 人因错误提示模糊求助。这个小样本只提示方向，不能声称统计上确定的全体提升。下一步修错误提示，扩大样本并追踪一周内再次成功部署的比例。真实面经没有这些人数和结果。
规模与取舍
这是产品评估题，核心取舍是试验成本、代表性与因果可信度。单个用户任务观察需要人工时间，遥测可扩到大量用户但只能看到预先埋点的行为。首次成功时间常呈长尾，需看中位数及高分位；采用率要统一时间窗口和活跃定义，避免安装量、下载量或页面浏览量冒充真实使用。
易错点与追问
容易失分的边界
- 只报告推理延迟或编译吞吐，未观察开发者是否能成功完成任务。
- 把代码行数少当作易用性充分证据：隐藏复杂配置可能换来更差的可诊断性和恢复能力。
- 拿新版新手与旧版熟手比较，或同时更换文档与硬件，却把全部变化归功于新功能。
- 只看平均耗时，忽略失败者、长尾用户与平台差异；计时若只包含成功者也会产生幸存者偏差。
- 用 NPS 或周活跃人数单独证明易用性，没有任务、分母、用户分组和对照条件。
继续深挖
- 若功能是 profiler，易用性任务可改为定位一次性能瓶颈；怎样量测找到根因的准确率和时间，而非只看打开 profiler 的次数？
- 若没有 A/B 条件，能否做同一批用户的交叉任务、阶梯发布或匹配队列？如何说明学习效应和选择偏差？
- 如果新版首次上手更快但长期故障率上升，怎样制定发布门槛、回滚条件与文档改进计划？
- 与竞品比较时，如何保证同一任务、版本、硬件与公开可复现的方法，并经法务和保密审阅？题目把竞品比较作为另一问，本篇只把它列为相邻追问。
