如何使用这项资源模型
- 用途
- 先把过程目的、交付要求和上下游接口说清楚，再写岗责、工作手册和绩效考核。六张图说明怎样用同一套结果标准衔接工作和评价。
- 使用条件
- 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。
- 模型
- 要素、关系与假设
- 依据与验证边界
- 用于梳理过程、设计岗位文件和复核评价。应用效果要拿实际交付和经营结果来验证。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。
- 版本
- V1.0 · 修订 2026-11-11
这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。
CC BY-NC-ND 4.0 · 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。
同一项工作，岗责写着要交一个结果，手册教人做的是另一件事，到考核时又换了个标准。真遇到这种情况，我会把三份文件放到一起，问一遍：这项工作交给谁，拿到以后做什么，做到什么程度，下一环节才用得上？
把这几个问题说清楚，岗责写谁承担，手册写怎样完成，考核写按什么证据判断。三份文件各有用途，共用同一套结果要求和版本依据。这就是我说的同源。
一、先把业务怎么往前走说清楚
总图上半部分是业务。一个过程接到有效输入，做完工作，交出结果。拿结果看这个过程的目的有没有实现，再验证下一过程能不能接。流程走到最后，还有一件事要确认，交付有没有带来原先要的客户和经营结果。
我看一段工作，通常问四句。做完了没有？交付合格吗？下游用上了吗？整条流程要的结果出来了吗？这四件事分别记，复盘时才知道卡在哪。图里用三个过程把关系画出来，业务上有几个过程、要不要并行、哪里需要回头，看实际情况。
总图下半部分是岗位。先找到承担工作的岗位，再往下分成岗位职责、职责内容和具体动作，最后落到动作结果。岗位职责要说清楚交什么。职责内容说明做到哪儿。动作写到对象和操作，做完要能找到相应的结果和依据。
两条线在交付的地方接上。设计时，从流程目标往回找过程和岗责。执行时，从动作结果往前看，交给了谁，对方怎么验，用它做成了什么。
二、一个过程有目的，整条流程有目标
我这里说的“过程”，是一段有明确目的的工作。先看进来什么，谁来做，怎样配合，最后交什么。输入除了材料和数据，还有依据、权限和资源。目的回答这段工作为什么要做，结果告诉我们这段工作起没起到作用。
“流程”把多个过程接在一起。每一段能交付，前后也接得上，再看这些局部结果合起来有没有支撑整体目标。图里的目的 1、目的 2、目的 3 各有自己的验证依据。走到流程终点以后，客户价值和经营结果还要单独核实。
四向 SOP 按工作和结果的范围来分。
| SOP | 看哪一段工作 | 需要说明什么 |
|---|---|---|
| 业绩 SOP | 整条关键链路 | 哪些过程一起支撑客户价值和经营结果 |
| 业务 SOP | 一个业务过程 | 为什么做，谁协作，接什么，交什么 |
| 职能 SOP | 岗位职责和任务交付 | 一个角色要承担什么成果，落实到哪些可交付任务 |
| 动作 SOP | 具体对象和操作 | 按什么输入、步骤和标准做出动作结果 |
工作手册负责把要求带进执行，绩效考核负责判断结果。用四向 SOP 去找哪一层的工作和结果，手册与考核就能引用这一层已有的要求。
三、交付过了，下一步还要看什么
开工前先说好谁提供、谁接收、交什么、什么时候交、按什么验、由谁验。异常或有争议，找谁处理，也在这里定下来。这几项写清楚，岗责、手册和考核就有了共同的交接依据。
先验这次交付。 过程 A 提交结果、证据和版本。接收方按约定核对，合格就记录结论。哪里缺，哪里要返工，说具体，再按同一个标准重新提交。
再看过程 B 能不能开工。 确认结果可以用，还要核对授权、资源、其他输入和依赖。条件齐了就开工，缺哪项就去补哪项。需要等、需要协调、需要上报，按事情归到能处理的人。前一步已经交得合格，就把问题落在下一步缺的条件上。
交接时我会留三份记录。结果包写交付物、证据、版本和状态。验收记录写接收人、标准、结论和时间。启动条件记录哪些有效输入、授权、资源和依赖已到位。最后一次交付也照样核实，流程目标另看实际结果。
四、三份文件从同一条结果要求写起
同源要先把三件事定下来。这个过程的目的是什么，交什么结果算合格，上下游怎样交接。再写使用者、责任人、验收人，配哪些权限和资源，出了例外找谁。然后从这组要求里写三份文件。
- 岗责说明写承担什么。 把成果责任写到能交付的程度。谁负责，范围到哪里，从谁那里接、交给谁，需要哪些权限和资源，什么情况必须反馈，都要有人说清楚。
- 工作手册写怎样完成。 任务怎么进来，开工前查什么，做哪几步，遇到不同情况怎么判断，什么结果可以提交，怎样记录和交接，异常时谁接管。工作换人以后，照着手册也能判断下一步。
- 绩效考核规则写怎样判断。 先确定评的是动作、职责、过程还是业绩。再看质量、时效、成本和风险，约定证据从哪儿来，谁评价，怎么复核和处理争议。岗位可控的范围、上下游的依赖和见效时间，都要一起考虑。
过程 ID、职责或任务 ID、结果 ID、标准版本，把三份文件指到同一项工作。人看手册，AI 用 Skill，查到的验收要求应是同一个版本。标准改了，把引用它的职责、手册、考核和 Skill 一起核对。
我通常倒过来查一遍。考核要的结果，手册里有办法做出来吗？岗位要对这个结果负责，它手上有相应的资源和权限吗？如果这两处对不上，先回到实际工作，把要求和条件定清楚。
五、给人和 AI 配能力，先把条件核实一遍
管理者先把这次任务说清楚，包括过程目的、交付物、动作要求、SOP 版本、验收规则、时限和资源。再看需要哪些岗位能力、AI 能力和协作方，把能用的数据、工具和权限核实一遍。审批、异常反馈和接管入口也一起确定。
人用工作手册做专业操作、判断和沟通，在授权范围内确认、验收和接管。AI 用适合的 Skill、工具和数据做检索、生成、分析和核对，交出结果和依据。哪条指令需要人确认，什么异常要交回去，写进这次任务。能力不足就补能力或转人工，权限不清先暂停核实，执行失败按约定报告、接管或终止。
提交时，把结果和记录放在一起。任务 ID、谁执行、用的输入和标准版本、工具或 Skill 版本、依据、异常、耗时以及人工确认，都应该能查到。交给下一步时，人做的和 AI 做的都按同一要求验收，再确认接收方具不具备启动条件。
六、评价要一步一步找证据
早期的岗责、工作手册、SOP 和绩效考核图上写过 POW。我当时借用了比特币工作量证明里“可以核实工作依据”的想法。这版把企业里实际要核实的事情分开讲。
| 要判断什么 | 要找什么证据 |
|---|---|
| 执行事实 | 谁做了什么，输入、版本、状态和执行记录能否对上 |
| 结果验收 | 交付是否达到约定标准，结论和复核依据在哪里 |
| 业务承接 | 下游实际怎样使用结果，它在交接和协作里起了什么作用 |
| 流程目标 | 客户与经营结果怎样，在哪个周期观察，有哪些其他影响因素 |
前一步的记录可以作为下一步的输入，每一步还是要有自己的证据。看职责和任务时，问交付质量、时效、判断和异常反馈。看过程协作时，问下游用没用、等了多久、返工或协调过几次。看经营时，回到整体目标、价值、成本、风险和持续性。
如果要再往个人贡献或薪酬走，还要弄清责任可控范围、协作依赖和时滞，保留复核和异议处理。早期图里的基本工资、岗位工资和结果考核可以作为后续讨论的入口。评价结论先作为参考，薪酬、激励或分配按另行约定和审批的规则决定。
七、拿一段正在做的业务试一遍
可以从一次经常卡住的交接开始。先画清这段工作为哪个目标服务，前后各交什么。把验收和启动条件列出来，再分到相关岗位和动作上。从同一组结果要求写岗责、手册和考核，选一项实际任务走一遍，看看条件缺在哪、结果怎么被使用、哪条证据还找不到。
最后从两个方向再查。一个目标往下追，有哪些过程、职责和动作在支撑？一项职责往前追，它的结果交到哪个过程，帮业务做成了什么？拿不到证据的地方先记下来，把过程接口、执行安排或评价口径改到具体工作上。成本、业绩和能力积累有没有变化，等实际运行后再看。
这套模型沿着早期岗责、工作手册、SOP 与绩效考核的关系展开，V1.0 用一张总图和五张分图，把交接的两个判断、三份文件的共同依据、人机授权与接管、评价和复核写到可检查的程度。要继续看岗位怎样发现、能力怎样组织，可以接着读 岗责—流程—人机协同模型说明。