跳转至

第一性原理

第一性原理

第一性原理在本专题中指：把问题拆到目标、事实、约束和假设，再从必要条件重新构造方案。它适合检查“过去一直这样做”是否被误当成需求或约束。

第一性原理不是从零发明，也不是拒绝经验。经验可以提供假设、边界和候选解，最终判断仍要回到目标、证据和可验证结果。

先拆分问题

类型要写清的内容常见混淆
目标希望改变的结果、用户行为或业务指标把方案名称当成目标
事实已观察到的行为、数据、能力或约束把推测写成事实
假设尚未证实但影响决策的判断把团队共识当成证据
约束时间、预算、合规、技术和组织的真实限制把历史流程当成不可变约束
惯例过去的做法、模板、架构或流程认为“不这样做就不专业”

使用步骤

flowchart LR
    A[写出目标] --> B[列出事实与约束]
    B --> C[标记假设与惯例]
    C --> D[提取必要条件]
    D --> E[重构候选方案]
    E --> F[设计最小验证]
    F --> G[根据结果调整判断]
  1. 把目标写成结果，而不是“做一个功能”或“上线一个 Agent”。
  2. 收集当前基线、用户行为、成本、时延、模型能力和合规要求。
  3. 把每个判断标为事实、假设、约束或惯例。无法追溯来源的“必须”先按假设处理。
  4. 问清目标真正需要的必要条件，删除只服务于旧流程的中间步骤。
  5. 从必要条件出发形成多个候选方案，不以熟悉程度决定唯一方案。
  6. 用真实样本和最小成本实验验证关键假设，再决定是否扩大投入。

AI 产品案例

团队提出“做一个能够自主处理全部工单的 Agent”。拆分后可能得到：

  • 目标是降低首次分派耗时，同时保持错误分派率和合规风险在可接受范围内。
  • 事实是工单类型有限，历史日志中存在重复分类，部分类别的标注质量不足。
  • 约束包括人工责任、数据权限、模型延迟、调用成本和低置信度时的兜底。
  • “必须自主规划并执行”更像惯例或方案假设，不是目标本身。

因此，最小候选可以是“分类建议 + 置信度 + 人工确认”。先用历史工单评测准确率、低置信度比例、人工修改率和 P95 延迟，再决定是否扩大代理权。模型具备某项能力，不代表用户需要完全自动化。

常见误用与边界

  • 把复杂问题简化成一句口号：拆解必须保留真实目标、约束、失败代价和责任边界。
  • 把第一性原理当成反经验：成熟方案和行业经验可以作为候选与先验，但不能替代当前场景的验证。
  • 把重新推导当成最终结论：第一性原理只生成更清楚的假设和方案，仍需研究、实验、评测和上线数据。
  • 只拆技术，不拆用户价值：AI 产品要同时检查用户任务、业务结果、模型能力、成本、权限和风险。

相关内容

来源说明

来源说明

本页把第一性原理写成产品决策的拆分法：目标、事实、假设、约束、惯例分开记录，再用最小实验验证。这是工作方法，不是从公理重新发明产品。

相关讨论见站内Anthropic 产品经理访谈笔记；需求侧的假设与证据纪律见需求分析。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用