跳转至

PRC：问题—根因—对策

PRC：问题—根因—对策

PRC 的缩写在不同领域可能有不同展开。为避免把一种口径伪装成通用标准，本站在问题诊断语境中采用：P = Problem、R = Root Cause、C = Countermeasure，即问题、根因、对策。

PRC 用于回答“哪里偏离了预期、为什么偏离、下一步验证什么”。它要求把问题事实、根因假设和对策动作分开记录，不能用一个流畅的解释替代证据。

三个部分

部分要回答的问题产出
Problem 问题预期与实际差多少，影响谁、何时、何处可量化的问题陈述和基线
Root Cause 根因哪些机制或条件造成偏差，证据是什么根因假设、证据和排除记录
Countermeasure 对策改变哪个条件，如何验证有效，失败如何止损最小对策、指标、负责人和复查点

使用步骤

flowchart LR
    A[描述预期与实际偏差] --> B[限定影响范围与基线]
    B --> C[提出多个根因假设]
    C --> D[用数据或样本验证根因]
    D --> E[选择最小对策]
    E --> F[设指标与复查点]
    F --> G{偏差是否收敛}
    G -->|否| C
    G -->|是| H[沉淀规则与复盘]
  1. 写 Problem：用对象、场景、时间范围、预期、实际、影响和基线描述偏差，避免“体验不好”这类无法验证的句子。
  2. 列 Root Cause 假设：从数据、流程、产品设计、模型、工具、权限和组织协作等层面提出多个可能原因。
  3. 验证根因：对照日志、评测样本、用户反馈、流程记录或实验结果，区分相关现象和真正机制。
  4. 定 Countermeasure：针对已验证或置信度最高的根因设计最小改变，写清负责人、成本、风险和回滚方式。
  5. 检查结果：比较同一口径的基线与改进结果，若偏差未收敛，回到根因假设，不直接追加更多功能。
  6. 沉淀闭环：把有效对策转成产品规则、数据修复、评测样本、监控指标或流程约束，并记录剩余风险。

AI 产品案例

某知识库问答功能的“回答看似相关但引用错误”可以这样拆解：

PRC示例
Problem在内部知识库问答中，近 30% 的抽样回答引用了过期文档；目标是不超过 5%，影响客服查找政策
Root Cause文档更新没有触发索引刷新；召回结果缺少版本过滤；回答生成没有拒答过期来源的规则。分别用文档更新时间、检索日志和评测样本验证
Countermeasure先接入版本字段和更新触发索引，增加过期文档样本与引用准确率评测；未通过时展示资料不足并转人工

对策验证至少要同时看引用准确率、覆盖率、转人工率、延迟和成本。修复一个示例不等于根因已经解决。

输出模板

1
2
3
Problem：在 [对象/场景] 中，[指标] 从 [预期/基线] 变为 [实际]，影响 [用户/业务]，时间范围是 [范围]。
Root Cause：假设 1 [原因]，证据 [来源]，置信度 [等级]；假设 2 ……
Countermeasure：针对 [已验证原因] 执行 [最小改变]，负责人 [人]，检查 [指标/样本]，时间 [节点]，失败时 [回滚或降级]。

缩写变体与边界

PRC 不是所有组织都使用的统一标准。其他来源可能把 R 写成 Reason，或对 C 使用不同的词。引用外部材料时保留原始释义；在本站新增内容时，应在首段声明采用的展开，不把不同变体的步骤混在一起。

PRC 也不替代：

  • 因果实验、统计分析和领域专家判断；
  • 需求价值、优先级和资源分配决策；
  • 5W2H1R 对责任、节点、资源和结果的行动澄清。

相关内容

  • 思维模型总览：查看 PRC 与第一性原理、MoSCoW、5W2H1R 的组合方式。
  • 数据分析入门：指标、基线、拆解和归因验证。
  • 管理决策：分离事实与解释、检查概率和设置复盘条件。
  • 需求分析：把问题、假设、证据和验收标准写入产品需求。

来源说明

来源说明

本站在问题诊断语境中把 PRC 展开为 Problem、Root Cause、Countermeasure，要求问题、根因证据和对策分开记录。这是本站约定，不是跨组织的统一标准；其他材料可能把 R 写成 Reason。

根因验证仍依赖日志、评测样本和实验，方法见数据分析入门与管理决策。

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