构建正确的东西：产品工程

我在 @aiDotEngineer 大会第一天的笔记，主题是 AI 领域的产品工程。由 Kent Dodds 主讲。

核心论点

• 当 AI 代理（agents）拉平实现层面的竞争时，区分因素就变成了构建正确的东西。
• 实现被商品化；决定做什么才是稀缺且持久的技能。
• 软件工程师需要的“最后一项技能”：产品判断力。

箭头隐喻

• 过去工程师需要精准才能命中目标；现在代理让命中目标变得容易。
• 现在可触及的目标比以往多得多。
• 真正的问题是：哪个目标值得瞄准？
• 并非所有目标都平等；选择才是区分因素。

产品工程师 vs 产品经理

• 产品工程师身处代码之中，思考系统约束、原语和基础设施限制。
• 当收到请求时，他们会将其映射到现有架构，或识别需要扩展的地方。
• 关键区别：技术专长与用户理解相结合。
• 两个角色都需要，但在早期创业公司中，一人常身兼两职。
• “工程判断力来自技术经验与人本问题的结合。”

想法与功能验证（妈妈测试法）

• 不要请用户评价你的想法；他们会出于礼貌说好。
• 询问过去的行为，而非未来的意图：
  • “告诉我上一次发生这种情况是什么时候。”
  • “你当时做了什么替代方案？付出了什么代价？”
• 强信号：用户已经花时间或金钱在变通方案上。
• 弱信号：“嗯，听起来是个好主意。”
• Wayne 的警示故事：花 120 万澳元（约 90 万美元）建了一个没人用的高扩展系统。
  • 本可以用两周时间通过手动集成启动来测试市场。

待办任务框架

• 人们雇用产品来在特定情境中取得进展（Clayton Christensen）。
• 功能请求不是任务；始终要问“你想解决什么问题？”
• 任务陈述格式：“当[情境]时，帮助我[取得进展]以便我能够[期望结果]而无需[痛苦]。”
• 示例：“当有工作坊时，帮助我快速进入以便学习，而不错过前 20 分钟。”
• 将任务分解为三个维度：
  • 功能：它真的能做到吗？
  • 社交：用户使用时还有谁参与？
  • 情感：用户感受如何，包括当别人知道他们在使用时。
• 面部识别示例：理解任务后将解决方案转向 NFC 或并行排队。

Kano 模型：功能优先级排序

• 三个主要类别：
  • 基本需求：必需品；缺失会导致不满（例如：订单确认邮件、GPS 跟踪）
  • 性能：在某个点之前越多越好（例如：预计到达时间准确性、页面加载速度）
  • 惊喜点：创造惊喜的意外功能（例如：意外折扣）；缺失不会导致不满
• 功能在模型中只朝一个方向移动：惊喜 → 性能 → 基本需求
  • GPS 跟踪在 2015 年是惊喜点，现在已是基本需求
• 另有两个类别：
  • 无感：用户无所谓；移除它们以减少维护负担
  • 反向：用户主动反感的特性（例如：未经同意的面部识别）
• 对工程师的启示：
  • 基本：确保可靠性、完整性、所有权
  • 性能：衡量并达到最低阈值
  • 惊喜点：视作实验；在基本面稳固之前不要过度投入

用户反馈循环

• 观察用户使用你的软件；这令人谦卑，并能揭示明显的改进点。
• Don Norman：“不存在用户错误”——如果用户失败，那就是系统有问题。
• 持续反馈的策略：
  • Slack 频道聚合 Reddit、X 和支持讨论
  • 与高价值客户建立专属频道
• 闭环：早期采用者会容忍粗糙之处；主流用户不会。
• “大雇用” vs “小雇用”：一次性付费 vs 用户反复回来
  • 成功 = 重复进步，而非仅仅初始购买

持久技能与 AI 未来

• 即使通用人工智能（AGI）能做几乎所有事情，人类关于构建什么的判断仍然有价值。
• 产品工程师现在成为了他们能运行的任意数量代理的团队领导。
• 你的工作：保持系统（原语、架构、测试）整洁，以便代理能有效工作。
• 如果 AI 最终也学会了产品判断力：“我不知道我们该怎么办。”
• 推荐资源：
  • 《与运气竞争》（Clayton Christensen 著，待办任务理论）
  • 《设计心理学》（Don Norman 著）
  • 《妈妈测试》（书）
  • Kent C. Dodds 的 YouTube 频道 (youtube.com/@kentcdodds-vids)