如何使用这项资源方法
- 用途
- 从事实核对、经验记录、限定范围试用到日常采用，说明制度、规则与方法怎样获得依据，以及现行版本怎样继续、修订或停用。
- 使用条件
- 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。
- 方法
- 步骤、输入与完成条件
- 依据与验证边界
- 文中案例用于演示分析和操作。应用时请用实际业务记录替换示例条件，再核对判断和结果。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。
- 版本
- R1 · 修订 2026-11-04
这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。
CC BY-NC-ND 4.0 · 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。
一项工作做成了，团队往往会把过程写下来，希望以后照着做。过一段时间，文件还在，遇到相同的问题，大家却又开始找原来那个人。
中间缺了什么？
我觉得，要继续追问：当时为什么做成，哪些做法值得再试，别人能不能使用，以及用过以后由谁回来检查。这几件事接上了，一次工作的经验才有机会成为组织以后可以依靠的能力。
“动作、结果、沉淀”可以作为一条思考主线。哪些经验值得留下，要经过选择和验证，留下后还要有人持续维护。
一、先核对这次发生了什么，再讨论留下什么
工作完成后，可以先把三件事分开。
动作，回答实际做了什么。谁在什么条件下，使用什么资料和资源，采取了哪些步骤，遇到例外时怎样处理。
结果，回答发生了什么变化。交付物是否符合要求，下一个环节能否接着工作，花了多少时间和成本，还有什么责任没有完成。与客户和经济结果有关的工作，还要回到对应的业绩链，核对需求、成交、履约、回款等相关结果。
沉淀，回答其中哪些内容值得进入下一次工作。可能是一条更清楚的判断规则、一种可重复的方法，也可能是一个需要避免的条件。
这三件事不能直接画等号。客户接受了一次报价，可能与需求迫切、竞争条件、关系基础有关。某位负责人临时调动资源把交付赶上，也不能直接说明原有流程已经可靠。
反过来，一次失败也可能留下有用的认识：某种供货条件下不能承诺原来的时间，某项资料缺失时应当先停下来确认。前提是把事实核清，保留适用情境，不急着把一个解释写成通用结论。
如果业绩没有达到预期，要先找到业绩链上的问题，再决定改哪一层工作。增加检查表、细化动作，只有与实际问题对应，才值得安排。
二、一项经验可以分四种状态来看
为了便于工作中判断，我建议把一项经验按下面四种状态记录。这是本篇提出的使用方法，状态名称本身不代表验证结论。
| 状态 | 目前能够说明什么 | 还要继续核对什么 |
|---|---|---|
| 本次工作已完成 | 这一次的交付和结果已经核对 | 为什么出现这个结果，是否存在偶然条件 |
| 经验已经记录 | 情境、动作、观察和原因假设有据可查 | 哪一部分可能复用，怎样检验 |
| 方法在限定范围内可用 | 相应条件下的试用支持采用这项做法 | 他人能否使用，换一种条件是否仍然有效 |
| 已进入日常工作 | 相关角色能找到现行做法，具备使用条件，并有实际使用和维护记录 | 效果是否持续，环境变化后是否需要修改或停止 |
从前一个状态走到后一个状态，需要新的依据。不能因为文件被上传、培训已经开过，就把它登记为组织已经掌握的能力。
尤其要留意一种情况：所谓“方法”，实际仍靠原来那位熟练者补充大量判断。试用时他一直在旁边提醒，结果看上去不错；他一离开，工作又无法继续。此时应把必要的经验判断讲明，安排训练、辅助工具或例外支持，并如实保留仍需熟练人员介入的范围。
有没有形成组织能力，要回到实际工作中看。记录、流程、工具和训练提供支持；还要检验，在约定条件下，团队能否持续完成任务、处理例外。
可左右滑动查看图示，也可打开大图。
三、把复盘中的判断，改写成可以试用的做法
复盘时说“下次提前沟通”，下一次仍然很难执行。什么时候算提前，与谁沟通，需要确认什么，出现分歧交给谁，都还没有说清楚。
一项值得试用的经验，至少可以交代六件事：
- 问题和情境：哪类任务反复出现什么问题，哪些条件会改变判断。
- 依据和解释：记录了什么，尚有哪些不确定，为什么认为这个改动可能有帮助。
- 拟采用的做法：从什么条件开始，具体做什么，交出什么，怎样判断完成。
- 例外和边界：什么情况下不能照用，何时暂停，交由谁处理。
- 试用安排：谁来试，在什么范围内试，谁提供资源，什么时候复核。
- 观察办法：预期改善什么，怎样比较，同时留意哪些额外成本和影响。
资料不必写成长篇。接手的人能看懂、能试用，复核的人能回查依据，就可以先开始。
这里可以借鉴计划、执行、研究、行动（PDSA）的学习思路。Deming Institute 对 PDSA 的说明强调，把实际结果与预期比较，并允许据此修改做法和原来的解释。[1] IHI 的试行指南进一步提出，先从可行的小范围开始，观察意外影响，再在不同条件下继续检验；没有带来改善的做法可以停止试行。[2]
这些资料为试行设计提供参考，并不证明本篇方法已经在各类企业中取得效果。企业仍要按自己的业务和失败代价，确定需要怎样的验证。
四、用“报价前确认供货期”试一下
下面是一个虚构例子，用于说明操作方法，没有对应企业的成效数据。
一家设备服务团队曾经赶在客户要求的时间前报出方案。回头核对，发现最终供货期是负责人临时协调出来的，销售准备报价时，拿到的仍是供应伙伴较早提供的参考时间。
这次结果可以确认，做法却还有疑问。如果把“负责人协调”写成每次都要走的流程，负责人会成为新的等待点，供应条件也未必次次允许。
可以先提出一个较小的改进假设：对于需要承诺交期的定制订单，报价前确认本次供货条件，并标明确认日期、有效范围和待解决事项，可能减少后续交期调整。
接着把试用安排说清楚。
| 试用要点 | 具体安排 |
|---|---|
| 适用范围 | 先选供货方式和复杂程度接近的一类定制订单；常规现货订单另行判断 |
| 执行动作 | 销售提出本次需求，供应协作角色确认条件；条件不足时标为待确认，并交由有权决定的人处理 |
| 交付内容 | 可引用的供货期、所依赖条件、确认人与日期；报价发生关键变更后重新确认 |
| 使用者 | 安排另一位具备必要业务知识的同事试用，记录哪些地方仍需额外解释 |
| 观察结果 | 看报价后因供货期发生的调整，同时看报价用时、供应伙伴的确认负担和客户体验 |
| 复核决定 | 到约定的复核点，决定继续观察、调整步骤、缩小范围，或停止本次试行 |
试用前还要确定比较口径。订单类型、复杂程度、供应条件差异很大时，不能把前后变化都归因于这张确认记录。业务量少，也不能因为暂时没有再发生问题，就宣布已经验证。
没有统一的“成功几次就可以固化”的次数。影响范围越大，出错后果越难挽回，需要的核验和试行就应越充分。有些条件不能放进真实业务中试错，可以先用历史任务、模拟情境或专业复核检验。
这个例子希望留下的，是一项经过限定、可以继续检查的做法。它是否改善成交或经济结果，还要结合客户需求、价格、竞争条件等因素继续观察。
五、按问题的性质，决定沉淀成什么
试用结果支持这项做法后，还要决定用什么形式留下来。
| 承载方式 | 主要说明什么 | 在上述例子中可能对应什么 |
|---|---|---|
| 制度 | 谁拥有相应职责和决定权限，争议、资源与例外怎样处理 | 谁可以确认交付承诺，超出条件的承诺由谁决定 |
| 规则 | 碰到什么条件，必须满足什么要求或进入什么处理路径 | 报价引用的供货条件发生关键变化时，需要重新确认 |
| 方法 | 怎样把一项任务做出来，包括步骤、判断、工具和交付标准 | 供货期确认步骤、记录表、例外说明与检查办法 |
这样区分，是为了方便使用；实际文件可以按业务需要安排。一个简单问题，可能只需改一句说明或一项表单；涉及权限和责任的变化，则需要相应的授权决定。没有必要把每条经验都升为制度。
决定采用的做法，要放到大家实际会用的位置：相应的标准作业流程（SOP）、价值贡献角色的工作手册、培训练习或辅助工具。使用者应当知道从哪里开始，遇到什么情形需要参考它。
AI 可以协助汇总记录、比较版本、整理步骤和检查遗漏。事实、适用条件和采用决定，仍要由了解业务且具有相应责任的人核对。需要形成 AI 执行指南（Skill）的内容，可以在稳定的方法基础上继续设计，并明确输入、输出、适用边界和人工验收要求。
六、现行版本要有人维护，也要能够停用
采用以后，最容易漏掉的是后续安排。
建议每项现行方法至少明确：适用范围、版本与生效日期、维护责任、相关工作入口，以及下一次复核的时间或触发条件。业务条件变化、反复出现同类例外、代价明显上升，都可以成为提前复核的理由。
复核后，可以有三种决定。
继续使用：目前的证据仍支持在原范围内使用，保留复核记录，并明确下一次检查安排。
修订再试：问题仍值得解决，但条件、步骤或例外处理需要调整。新版本先标明试用范围，检验后再作采用决定。过渡期间要讲清哪些任务用哪个版本。
停止使用：做法没有带来预期改善，额外代价无法接受，或适用条件已经消失。撤下日常使用入口，标明停止原因和生效时间，告知受影响的角色；需要继续处理的任务，给出替代办法或升级处理路径。
旧版本可以按实际管理需要留存，以便追溯当时的依据。归档处应清楚显示已经失效，避免历史材料被再次当成现行要求。已经发生的承诺和责任，也要单独安排交接，不能随着文件停用一并消失。
可左右滑动查看图示，也可打开大图。
七、谁来把经验带回日常工作
在资源、运管、客户、资本四个生态中，不同角色都可能主动提出改进，也可能响应实际需求。谁来参与、怎样参与，要放到具体业务中说清楚。
执行和协作角色说明实际操作、困难和例外；接收成果的角色检验交付是否便于继续使用；客户和合作方的反馈帮助看清改动对外部造成的影响。精干运管负责相应决策、规则、资源安排，以及价值生产、销售渠道和客户关系之间的协调。涉及专门知识时，应安排相应人员复核。
维护人可以负责整理、跟进试行和推动更新，但不能靠一个人替所有角色判断。某项改动如果减少了内部工作，却增加了客户填写或合作方确认的负担，复核时也要一起看。
贡献记录也可以保留：谁发现问题，谁提供证据，谁参与试用，谁完成有效改进。涉及评价或权益时，按实际业务事先明确的制度处理；一份经验记录本身不自动产生某项权益，更不构成收益承诺。
美国 GAO 在 2002 年对 NASA 经验学习机制的审查中指出，已有经验收集和共享程序，仍不足以保证经验用于后续任务。[3] 这是特定时期的历史审查，但它提醒我们，经验库建设与实际使用需要分别核对。
所以，检查沉淀时，除了看留下多少文件，还应抽取一项真实任务：使用者有没有找到现行做法，是否知道适用条件，能否完成工作，出现例外后有没有回到维护和决策环节。
可以先从一个反复发生、影响清楚的问题开始。把这一次的事实核对好，提出一项有边界的改动，交给合适的人试用，再回来作决定。下一次工作能用上什么，哪里仍然需要人判断，哪些做法应当撤掉，都留下明确答案。
参考来源
- The W. Edwards Deming Institute：PDSA Cycle。用于说明预测、观察和修正解释之间的关系；本文的四种状态及六项记录内容为本篇方法建议。
- Institute for Healthcare Improvement：Testing Changes。来源为质量改进方法资料，本文借鉴小范围试行、不同条件检验及停止无效试行的思路。
- U.S. GAO：NASA — Better Mechanisms Needed for Sharing Lessons Learned，GAO-02-195，2002-01-30。文中仅援引其历史审查结论，不描述 NASA 当前状况。
延伸阅读（可选）
- 一次交易之后，企业还能留下什么？：理解交易后的关系、协作与能力积累。
- 企业内容体系，怎样做到统一表达、持续更新？：进一步处理知识采用后关联物料的维护。
研究说明：本文延续早期“动作—结果—沉淀”的研究线索，并参考《SOP梳理设计方法论》中关于试行、反馈、迭代与版本维护的安排，提出供实践检验的方法。文中示例为虚构，图示为建议机制，尚无本篇方法的直接企业验证数据。