Bab 14 — Komitmen, Tugas, dan Peristiwa Kontribusi

第十四章　承诺、任务与贡献事件

共同创造需要参与者，也需要能够承接行动的组织安排。身份与关系说明谁进入协作、代表谁以及可以做什么；承诺与任务进一步说明各方准备完成什么、需要哪些配合，以及怎样判断履行进展。实际行动发生之后，组织才有材料讨论贡献，而不能仅凭身份、意愿或任务名称，提前认定贡献已经成立。

从承诺走向贡献，并不是把一项计划的状态从“未完成”改成“已完成”那么简单。资源可能已经投入，交付仍未形成；交付可能已经通过验收，尚未进入实际使用；使用已经发生，长期效果仍然需要观察。如果系统只保留一个综合分数，就会把这些不同事实压缩在一起，使参与者难以理解确认依据，也难以对错误提出有针对性的异议。

本章把承诺、任务与贡献事件作为三个相互联系的对象。承诺表达面向未来的安排，任务组织履行过程，贡献事件则记录与贡献判断有关的实际行动及其联系。这里使用“贡献事件”这一名称，不预先表示贡献已经获得确认；记录所处的证据和确认状态，必须另行表达。

一、事前约定与贡献条件

事前约定的首要作用，是使参与者能够在行动之前理解组织将如何对待其投入。共同目标越抽象，越需要说明具体行动怎样与目标相连。否则，一方可能认为自己在履行明确义务，另一方却把同一行动理解为没有承诺回报的自愿尝试，分歧直到投入已经发生才显现出来。

承诺应当具有明确的相对方和事项。谁作出承诺，向谁作出，准备提供什么，以及需要什么条件配合，都会影响后续履行。承诺可以涉及劳动、资源、交付、使用、审核或支付，不宜只记录执行者必须做什么，而遗漏组织应当提供的条件和反馈。

意向、提议与已经成立的约定，需要保留不同状态。一个人提出愿意承担工作，不等于组织已经接受相应安排；管理者发布任务，也需要根据其权限和适用程序确定效力。系统应当能够查明哪些事项已经得到有权确认，哪些仍然等待协商。技术上的“创建成功”不能替代制度上的成立条件。

任务是对承诺履行的组织化表达。它可以把一个较大的目标分解为可协作的范围、阶段和交付要求，并明确依赖关系、责任人及协调机制。但任务分解并不意味着每个细小动作都要单独评价。分解的尺度应当足以支持交接和核验，同时避免把工作切成大量只为计数而存在的片段。

贡献条件则说明什么行动可以进入贡献判断，以及需要满足哪些要求。这些要求可能涉及真实发生、与共同目标有关、处于适当授权范围、达到约定质量或能够提供必要证据。不同贡献类型可以采用不同条件，但条件应当具有可理解性，不能只用“表现优秀”“价值突出”等词语代替全部判断依据。

这里需要区分进入记录、确认贡献和形成权益的条件。一个实际行动可以被记录，却尚不足以证明其构成所主张的贡献；贡献得到确认，也可能仍需满足组织吸收、持续使用或风险承担等条件，才进入某项资本安排。收益权和治理权的形成又有各自依据，不能由任务完成标记直接推导。

事前约定还应说明哪些结果可以由行动者控制，哪些依赖他人和环境。对可控制的交付质量作出承诺，与保证全部经营结果，是不同性质的要求。如果任务需要组织提供材料、权限或配套资源，这些依赖应当同时记录。配合条件未满足时，不能只在执行者一侧留下未完成的结论。

对于探索性活动，事前完全规定成果可能并不现实。组织可以约定研究范围、资源边界、阶段汇报和停止条件，并说明可接受的不确定性。没有达到最初期待的结果，不足以单独判断参与者没有履行约定；反过来，投入了时间也不自动证明探索方法适当或形成了有用知识。

持续维护、协调支持和风险预防同样需要适当的任务表达。这些活动的作用可能体现为运行条件得以维持，未必表现为一个显眼的新成果。制度若只认可新增交付数量，就可能遗漏维持共同能力所必需的工作。事前可以约定责任范围、观察期间和必要材料，为此类贡献保留可审查的入口。

证据要求也是约定的一部分。谁负责采集，何时形成记录，由谁保管，哪些信息可以向谁披露，应当尽量在行动前明确。证明负担需要考虑各方实际掌握材料的条件，不能要求执行者提供只有组织控制的资料，又不给予其获取或请求核验的途径。

确认职责与时限也应当同步安排。执行者按期提交后，接收方需要说明何时检查、何时反馈以及出现分歧怎样处理。逾期没有回应，应当触发约定的提醒、升级或其他处理；未经明确规则，不能任意把沉默视为全部认可，也不应允许沉默无限期阻断参与者的主张。

约定中的回报需要表达承诺的具体程度。确定的履约对价、满足条件后进入评议的资格，以及依赖未来可分配资源的安排，应当分别说明。把“有机会参加”写成“必然取得”，会使技术记录固定一项原本并未成立的预期；把已经承诺的事项事后改称一般激励，也会破坏合作的可预期性。

规则变化不可避免，但变更需要有明确程序。新增任务、扩大范围、改变质量口径或调整确认条件，都可能影响原有投入。系统应当保存原约定、变更内容、授权依据和生效范围，让参与者能够判断某次行动适用哪个版本。新规则是否影响已经发生的行动，需要经过相应制度处理，不能由配置更新悄然决定。

现实中也会发生未经完整事前安排的必要行动。紧急处置、临时协助和制度尚未覆盖的共同创造，不宜因缺少任务编号就被排除在记录之外。可以允许提出补充说明并进入专门审查，同时保留“事前未约定”的事实。补充确认不能把事后材料伪装成原本存在的承诺，也不能保证所有自发行动都获得请求的回报。

由此，事前约定既形成可检查的行动边界，也为无法完全预见的情况保留处理程序。它使参与者知道什么可以期待、什么仍待判断、什么变化需要重新讨论。制度技术可以固定这些安排及其版本，为执行提供依据；承诺是否合理、是否得到适当接受，仍需要组织治理作出判断。

二、投入、交付、使用与结果的分别记录

共同创造中的不同阶段，回答的是不同问题。投入说明哪些资源已经进入活动，交付说明形成了什么并向谁提供，使用说明交付怎样进入后续活动，结果说明在特定范围和期间观察到了什么变化。它们可以相互关联，却不应被当作同一个事实的不同名称。

投入首先需要区分承诺可用、实际提供和实际消耗。某项资源被列入预算，不说明资源已经到位；资源到位，也不说明已经投入相应任务。记录应当说明资源类型、数量或范围、提供主体、发生期间及用途。涉及共享资源时，还需要保留分配口径，避免同一资源在多个任务中都被按全部投入计算。

资源投入可以包括时间、资金、知识使用条件、设备能力和必要的协作支持，但这些项目不必立即折算为同一金额。工时可以描述投入长度，资金可以描述支付规模，设备占用可以描述使用条件。它们为贡献判断提供不同信息，不能只因都能计数，就直接相加为一个总贡献值。

交付记录需要指向具体对象或可核验的服务阶段，并保留版本、数量、质量要求和接收范围。材料已经上传，只能先说明完成了一次提交；接收方已经收到，不等于其确认全部符合要求。提交、接收、验收和要求补正，可以围绕同一交付分别形成关联记录。

交付还应当区分原始成果、修订成果和后续维护。对同一对象的修订可能只是修正原有缺陷，也可能形成新增能力，需要结合任务范围判断。改变文件名称或重新上传，不应自动形成一次新的实质交付；真正新增的工作，也不应因为仍然关联同一对象就被抹去。

使用记录说明某项交付是否进入后续协作。谁使用、用于什么活动、采用哪个版本以及持续多久，都会影响解释。获得访问权限与实际使用不同，下载材料与完成应用也不同。涉及服务和组织能力时，使用还可能体现为持续采用某种流程、方法或协作安排，而不只是读取一个数字文件。

来源追溯技术提供了组织这些联系的参考。W3C 的 PROV 数据模型区分实体、活动和承担有关责任的参与者，并表达生成、使用、衍生和代理等关系。这样的结构有助于描述某个成果从何而来、进入了哪些后续活动，但具体业务事实仍需相应证据支持。W3C：PROV 数据模型〔1〕

结果记录则需要明确观察对象、期间和口径。产出增加、质量改善、协作时间缩短或能力得以维持，都需要说明怎样观察和比较。变化发生在交付之后，不足以单独证明变化全部由该交付造成。其他人的投入、原有积累和环境变化，也可能共同影响结果。

这四类记录并不构成每项工作都必须逐级通过的单一通道。有的约定以合格交付作为履行条件，有的还要求支持使用，有的则关注一定期间的结果。判断任务是否完成，应当返回具体约定；长期效果尚未显现，不能自动成为拒绝已满足条件的阶段性确认的理由。

使用机会也未必由交付者控制。成果符合要求后，组织可能因优先次序、资源不足或方向调整而暂不采用。系统需要保留“不使用”的实际原因，而不能把所有未使用都解释为交付无效。与之相应，组织也不应为了满足记录指标而制造没有业务必要的形式使用。

延迟结果需要明确观察安排。任务结束后，可以继续形成与原交付关联的使用和结果记录，并说明哪些结论暂时未知。未知、尚未观察和已经观察到没有达到目标，应当分别表达。用空白值或零分混合这些状态，会使长期贡献受到不适当的即时评价。

失败与不利结果也应当被如实记录。探索没有达到期待目标，可能仍形成经过验证的知识，也可能暴露方法和履行中的缺陷；维持了运行，可能来自有效维护，也可能只是没有遇到风险。不能把失败自动美化为贡献，也不能仅因没有新增可见产出就否定全部作用。判断需要结合承诺、实际行动和可支持的结论。

对共同能力的记录尤其需要谨慎。能力可以通过持续活动和相关结果获得支持，但组织拥有某项能力，不意味着可以把成员的全部个人知识登记为组织所有。记录需要说明组织实际能够持续利用的条件，以及这些条件依赖哪些关系。能力形成与权利归属仍然应当分别表达。

分别记录还能够减少同一事实在多个阶段被累加计价的风险。投入、交付、使用与结果可以是同一创造过程的不同证据，不能先把投入记作全部贡献，再把交付和结果各按全部价值加一次。是否认可不同阶段的独立作用，应由计量和分配制度明确，而不是由记录条数自然决定。

因此，本书建议保留多维事实，再按具体目的进行评价。任务管理可以关注进度，履约确认可以关注条件，资本形成可以关注持续使用与组织吸收。不同目的读取相互关联的材料，但不必强迫所有事实一开始就变成同一种分数。这样才能为后续价值判断留下充分而清楚的依据。

三、贡献事件的结构与生命周期

贡献事件把持续发生的协作转化为可以指认、关联和复核的记录单元。它可以描述资源已经投入、交付已经提交、成果开始被使用，或者某个期间的效果已经得到观察。事件的划分应当服务于事实表达和责任判断，其粒度可以不同，不必把所有活动都压缩为某个瞬间发生的点击。

在建模时，首先需要区分现实发生的事项、关于事项的记录以及依据记录提出的主张。同一现实事项可以产生多份观察记录；一份记录也可以支持不同范围的判断。记录标题写着“贡献”，并不意味着其中陈述已被核实；记录中列明某个主体，也不意味着其已经取得全部所请求的权益。

任务与事件之间通常存在一对多或多对多的联系。一个任务可以产生多次交付和补正事件，一次协作活动也可能同时服务于多个任务。系统需要保存这些联系，并说明各个任务实际采用了什么。把任务编号当作唯一的事件编号，会混淆同一任务中的不同动作；为每个任务复制全部事件，又容易制造重复记录。

本书提出如下最小结构，用于表达贡献事件的制度含义。它是一种面向本书问题的模型建议，具体实现可以根据业务增减字段，不要求所有类型使用完全相同的表单。

事件标识首先解决识别问题，不能独自证明真实或唯一。不同系统可能给同一现实事项分配不同标识；同一个标识也可能因录入错误而被用于不同内容。除了编号，仍然需要对象、来源和业务联系支持判断。标识的作用是稳定引用，实际事项的对应关系需要核验。

时间信息尤其需要分别表达。行动可以持续一段时间，也可以在发生后很久才被记录。补录历史活动时，应当保留实际发生期间和补录时间，并说明时间依据。链上收录时间可以帮助判断记录何时进入相应账本，不能直接作为链下工作在同一时刻发生的证明。

主体与授权应当关联到有关行动所适用的期间。一个人提交记录时可能已不在原岗位，但其历史行动仍可能发生在有效任职期间。系统需要能够查阅当时的角色及授权依据，而不是以当前身份状态替代全部历史。代录人员与实际贡献者也应在事件结构中分别指明。

证据联系应当保留材料所支持的范围。可以在链下保存必要材料，在共同记录中保存引用、版本和完整性信息，并根据用途控制访问。事件不必向所有参与者公开全部工作细节，但有权核验者应当能够取得必要依据。没有有效获取路径的证据编号，难以支撑持续复核。

贡献事件的生命周期，主要指记录及其判断如何被处理，不是现实事实可以被程序任意改写。初始记录可以处于草拟状态，正式提交后进入待核验状态；核验过程中可以补充材料，结论形成后可以表达全部认可、部分认可或不予认可的范围。有异议时，再通过有权程序形成新的处理记录。

这些状态不应被写成必须单向通过的一条流水线。某一部分已经确认，另一部分可以继续等待材料；一个判断受到质疑，也不必使所有无关事实失效。记录可以包含分项结论和明确的适用范围，使后续系统知道哪些内容可以采用、哪些内容需要等待，而不被一个“通过”按钮遮蔽。

业务状态、确认状态和权益状态还应当各自维护。工作可能已经停止，事实核验仍在继续；贡献已经确认，资本形成条件可能尚未满足；某项收益处理完成后，后续效果仍可能继续被观察。三个过程通过明确的关联规则相互通知，不能用其中一个状态替代其他过程。

历史纠正可以采用保留原记录、追加更正及其关联的方式。事件溯源是一种利用事件序列表达状态变化的技术模式，其更正通常通过新增补偿事件记录，而不是覆盖原事件。这种模式可以在不采用区块链的系统中实现；区块链是否必要，仍取决于是否需要多方共同验证和维护有关记录。Microsoft：事件溯源模式〔2〕

用于贡献治理时，更正记录还需要说明由谁决定、为何更正、影响哪些内容，以及后续采用者怎样获知变化。补充一项遗漏事实，与撤销一项错误确认，具有不同含义。当前有效状态应当能够反映最新的有权决定，同时保留理解原判断所必需的历史联系。

记录状态的变化也不会自动消除已经发生的外部后果。如果此前确认已经进入计量、资本登记或支付安排，更正需要通知相关环节，并分别处理其影响。追加一条补偿记录可以表达应当调整的事项，但实际资源是否收回、主张是否改变，还要看有关授权、程序和履行条件。

系统还需要说明什么情况下可以结束处理。任务取消可以停止未来工作，却不应自动撤销已经完成的部分；主张人撤回某次申请，不必意味着其曾经提交的事实全部为假；材料暂时不足，也不应被标记为已经证实虚报。不同终止原因需要保留各自含义及后续可采取的行动。

结构版本同样需要管理。业务发展后新增字段、调整事件类型或改变口径，应当保留旧记录的解释方式。不能用新版本默认值填补旧记录缺失的信息，再让系统把推定值当作历史事实。跨系统交换时，还应说明相同事件名称是否具有一致含义。

事件结构的质量，最终体现为参与者能否从当前结论返回主体、行动、约定、证据和修订过程。链上记录获得技术确认，只说明其在相应协议下得到收录或形成有关状态，不代表所有业务争议已经结束。共同账本可以固定程序留下的轨迹，贡献结论则继续接受制度规定的复核与修订。

四、多方共同贡献与重复记录识别

共同创造往往由多方相互补充而成。资源提供、问题识别、实际执行、协调配合和成果采用，可能由不同主体承担。若系统要求每项成果只能归于一个人，就会把共同过程压缩为最后提交者的记录；若允许所有参与者各自申报全部成果，又可能重复确认同一总量。

适当的结构应当同时保留共同事项与个人或组织的具体行动。共同事项记录协作目标、整体交付及有关结果，参与者的事件记录则说明各自实际作出了什么。不同事件可以关联同一成果，并表明它们是提供条件、生成、修改、审核或使用等不同关系。

这种关联首先用于解释共同创造的过程，不立即等同于分配比例。一个主体提供必要条件，不说明全部结果由其单独创造；一个主体完成最后交付，也不说明其可以排除此前参与者。来源联系可以支持后续归因判断，但本身不是对经济价值份额的精确证明。

共同成果也未必能够无损拆分。有些作用只有在多人协作时才成立，单独观察某项行动无法表达其全部意义。在证据不足以支持精细比例时，可以先确认共同事项与参与范围，保留尚待评议的部分。本书不主张为满足自动计算而提前制造看似精确的个人份额。

重复识别需要先说明正在排除哪一种重复。消息被重复传送、同一事实被不同主体记录、同一成果被拆成相似条目，以及同一权益请求被重复提交，是不同层次的问题。只有把层次分开，才能在避免重复处理的同时，保留必要证据与合理主张。

消息重复通常发生在技术传输和重试过程中。CloudEvents 规范要求以事件来源与事件标识的组合区分事件，重发同一事件时可以保留同一标识，接收者据此识别重复。这为跨系统传递提供了一种约定，但依赖发送方正确维护标识，不能单靠它发现所有业务上的重复事项。CloudEvents：事件标识与来源规则〔3〕

接收系统还需要使同一有效请求的重复到达不重复产生业务后果。技术上通常称为幂等处理，其核心是在约定范围内让重复请求得到一致的处理结果。用于贡献治理时，需要明确这个范围对应哪项操作和哪个处理周期，不能让一次消息重试再次增加已确认数量或再次触发支付。

这种保障应当延伸到实际执行环节。系统记录了“已经处理”，但外部执行失败，与外部执行成功却未收到回执，是不同情况。有关环节需要通过明确的操作标识、处理状态和对账恢复确定结果。只在消息入口去重，不能保证所有下游动作自然只发生一次。

事实的多份记录则具有另一种意义。交付者的说明、接收者的回执和核验者的意见，可能都指向同一次交付。它们可以作为关联证据保留，而不各自被计算为新的交付。识别出指向同一事实，应当建立对应关系，并保留来源差异，不宜直接删除其中的记录。

多份记录之间也可能存在冲突。数量、时间或质量描述不同，需要查明各自观察范围和依据。较早上链的记录不因时间在先就自动更真实，较多账户重复同一说法也不自动形成更多独立证据。重复识别可以把有关材料放到一起，却不能替代下一章将讨论的证据审查。

对内容相似的记录，需要进一步判断其业务含义。相同文件可能在不同期间被实际使用，形成不同的使用事件；文件字节不同，也可能只是同一交付的格式转换。哈希可以帮助检查内容是否一致，但不能单独决定贡献是否重复。对象、版本、任务、行动类型和实际使用关系需要共同参与判断。

持续性工作还需要处理时间范围的重叠。按日、按阶段和按月分别记录的工作，可能存在包含关系。系统可以把阶段性汇总关联到原始事件，并说明汇总范围，使统计时选择适当层级。若同时把全部明细和全部汇总相加，就会重复计算同一活动。

共同任务与个人任务也需要同样的层级约束。整体完成数量和参与者的工作记录可以并存，分别服务于履约管理和贡献判断。它们不必被强制变成可以简单相加的同一单位。需要汇总时，应明确采用哪些记录、排除哪些重叠，以及共同作用如何保留。

重复主张则必须结合具体权利安排判断。同一事实可能支持履约对价、署名认可或另有依据的长期激励，这些主张是否可以并存，需要看各自规则。防止重复获得同一项权益，不意味着凡已获得一种回报就排除其他主张；也不意味着可以换一个名称绕过明确的重复领取限制。

跨组织协作需要进一步限定互认范围。同一事件可以被多个组织引用，各自承担不同的确认和结算职责。若涉及共享的限额或只能处理一次的请求，就需要共同标识、已处理状态或适当的对账安排。一个组织内部的去重规则，无法自动约束其他组织独立维护的记录。

自动识别可以帮助寻找编号重复、时间重叠、内容相似和异常关联，但识别结果应当表达证据强度。系统高度怀疑两条记录对应同一事项时，可以提示核查；证据不足时，应保留不同主张及说明。错误合并会使真实贡献消失，因此解除错误关联与补回遗漏，也应当属于模型支持的正常操作。

面向未来，本书提出一个需要检验的制度设计方向：在保持个人与组织行动可辨认的同时，以共享的事项、成果和使用关系连接分散记录。其目标是减少重复取证和重复计量，让共同作用能够被持续追踪。若这种结构把难以形式化的协调工作排除在外，或让掌握登记入口的一方垄断贡献解释，就需要调整记录尺度和确认程序。

承诺、任务与贡献事件由此把共同创造连接为可以讨论和检查的过程。约定提供预期与条件，任务组织行动，事件保存实际发生的事项及其联系。记录越清楚，越能够容纳多人共同作用、延迟结果和必要修订，而不必把复杂协作提前压缩为一项确定价值。

但记录结构本身仍不能完成贡献确认。证据来自哪里、能够证明什么、谁有权确认，以及异议怎样改变结论，需要进一步建立明确程序。下一章将围绕这些问题，讨论贡献证据与确认程序，使可记录的行动逐步成为具有适当依据的共同判断。

定稿补强：人员贡献中的劳动与知识产权边界

员工、承包人、研究者和合作伙伴的贡献记录，不能用来改写其不可放弃的法定权利或既有合同义务。工资、最低报酬、工时、社会保障、职务成果、作者或发明人权利、商业秘密和许可范围，需要先依据关系类型和适用法域确定。贡献权益可以作为另行安排，不能当然替代应付报酬或法定义务。

记录人员贡献时，应保留关系类型、工作任务、既有报酬、知识产权归属或许可、数据使用范围、退出后持续权利和争议渠道。组织以后把成果识别为资本，不能倒推贡献者已经放弃原有权利；贡献者获得某项权益，也不能被解释为其自动承担无限经营风险。

本章工具与图表

本章的制度关系可结合附录三、附录四使用。附录用于形成可填写、可核对的工作成果，不能把模板中的默认项视为已经生效的组织规则。

图14-1　从承诺、贡献到权益与回报。 每个箭头都是独立判断关口，不允许用一条记录跨越全部制度门槛

本章注释

1. [SRC-075] 万维网联盟（W3C）：PROV Data Model。原文或官方页面

   • 本章引证：W3C：PROV 数据模型。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：W3C：PROV 数据模型、W3C：PROV 数据模型中的衍生关系。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

2. [SRC-057] Microsoft：Microsoft：事件溯源模式。原文或官方页面

   • 本章引证：Microsoft：事件溯源模式。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：Microsoft：事件溯源模式。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。

3. [SRC-047] Cloud Native Computing Foundation／CloudEvents：CloudEvents：事件标识与来源规则。原文或官方页面

   • 本章引证：CloudEvents：事件标识与来源规则。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：CloudEvents：事件标识与来源规则。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。