跨项目复用经验时，最容易出问题的地方，是把上一个项目的做法整段搬到新项目，却忽略了它当时为什么有效。团队规模、技术栈、工期与合规要求一旦变化，原本有效的做法可能立刻失效。本文给出一套可执行的方法：先判断两个项目的相似度，再把经验拆成结论、成立条件与可调参数，按差异做情境化改写，最后用小范围试点验证，让复用有依据、可复盘。
要点总览（TL;DR）
- 先判断相似性：从团队、技术栈、约束三个维度逐项比对，按高、中、低分级决定直接沿用、改写后沿用还是仅作参考。
- 把经验拆成结论、成立条件、可调参数、来源背景四栏，硬约束单独标出，实现方式标为可替换。
- 情境化改写按比对差异、定位冲突、改写方案、记录理由四步执行，每步留下可归档的产出。
- 改写方案先在小范围试点，偏差按原因反馈到经验条目或改写记录，五项检查全部完成才算闭环。
先判断相似性：经验能不能搬，看哪几个维度
复用经验前先做一次相似性判断，目的是确定“能搬多少”，而不是判断“能不能搬”。建议从团队、技术栈、约束三个维度逐项比对，每个比对项按高、中、低三级打分，再综合得出复用程度。判断由熟悉来源项目和新项目双方情况的人共同完成，产出是一张相似性判断表。
| 维度 | 比对项 | 高匹配 | 中匹配 | 低匹配 |
|---|---|---|---|---|
| 团队 | 人员规模、角色分工、技能水平、协作习惯 | 规模与角色结构接近，关键技能具备，协作方式相似 | 规模有差异，部分角色需兼任或补位 | 规模差距大，关键角色缺失，协作习惯明显不同 |
| 技术栈 | 框架、语言、基础设施、既有系统耦合 | 主流框架与基础设施一致，耦合方式类似 | 部分组件不同，需替换实现 | 语言或架构差异大，既有系统约束强 |
| 约束 | 工期、预算、合规与质量要求、外部依赖 | 节奏、质量门槛与依赖关系接近 | 某一项约束明显收紧或放宽 | 合规、工期或外部依赖构成硬性限制 |
分级结果对应三种复用程度：三个维度整体为高匹配时，可考虑直接沿用；存在中匹配项时，改写后沿用；出现低匹配项时，原经验仅作参考，需要重新设计方案。需要说明的是，只要有一个维度落在低匹配，就不宜整段照搬，哪怕其余维度都很接近。判断结论应写明依据，例如“团队规模从8人扩到20人，站会与评审的组织方式需要调整”，方便后续复核。
把经验拆成结论、成立条件与可调参数
整段经验难以复用，是因为做法、背景和效果混在一起。拆解的目标是把一条经验变成可判断、可调整的结构化条目。建议每条经验按四栏记录：结论、成立条件、可调参数、来源背景。
- 结论：做法本身，用一句话说清做了什么，例如“每两周做一次迭代评审，需求方必须到场”。
- 成立条件：这条做法当时为什么有效，包括团队条件、技术前提和外部约束，例如“需求方集中在一个办公区，评审能当场拍板”。
- 可调参数：可以随情境变化的部分，例如评审周期、参与角色、会议时长、输出物形式。
- 来源背景：来源项目的规模、技术栈、工期与关键约束，作为判断成立条件是否仍成立的依据。
拆解时还要区分两类内容：硬约束与实现方式。硬约束是合规要求、合同条款、平台限制这类不能改的条件；实现方式是工具选型、会议形式、文档模板这类可以替换的部分。把硬约束单独标出，改写时就不会误动；把实现方式标为可替换，改写时才有调整空间。拆解完成后，一条经验应能回答三个问题：当时做了什么、在什么条件下有效、哪些部分可以改。
情境化调整的操作步骤
情境化改写是把拆解后的经验落到新项目的过程，按四步执行，每步都有明确输入和输出。
- 比对差异：输入是相似性判断表和经验条目的来源背景，动作是逐项列出新项目与来源项目在团队、技术栈、约束上的具体不同点，输出是一份差异清单。差异要写到可操作的程度，例如“新团队无专职测试，测试由开发兼任”，而不是“团队情况不同”。
- 定位冲突：输入是差异清单和经验条目的成立条件，动作是找出原做法中依赖旧条件、在新情境下会失效的环节，输出是冲突环节列表。例如原做法要求需求方当场拍板，而新项目需求方分散在多个部门，这一环节就会失效。
- 改写方案：输入是冲突环节列表和可调参数，动作是保留结论、替换实现方式或调整参数，形成新项目版本，输出是改写后的方案。改写要说明改了什么、为什么改，例如“评审周期由两周改为一周，需求方改为提前书面确认”。
- 记录改写理由：输入是前三步的产出，动作是把差异点、冲突环节、改写内容和理由整理成一份改写记录，输出是可归档、可检索的文档。记录的作用是让下一次复用有据可查，也让复盘时能判断改写是否有效。
四步完成后，改写方案应能通过一个简单检验：把方案交给不了解来源项目的人，对方能看懂每条做法针对的是什么条件。如果某条做法说不清适用前提，说明改写还不充分，需要回到拆解环节补充成立条件。
角色分工与交付物
复用流程涉及四类角色，职责和交付物需要提前明确，避免判断和改写都落在一个人身上、缺少复核。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 经验提供者 | 补充来源项目的背景、成立条件与硬约束，说明当时有效的关键原因 | 结构化的经验条目（结论、成立条件、可调参数、来源背景） |
| 复用方（项目负责人或技术负责人） | 完成相似性判断，执行差异比对、冲突定位与方案改写 | 相似性判断表、情境化改写记录 |
| 评审角色 | 对改写后的方案做适用性确认，检查改写是否覆盖了关键差异 | 评审意见与适用性确认结论 |
| 知识管理角色 | 维护经验条目的结构化字段，归档改写记录与试点结论，保持条目可检索 | 更新后的经验库条目与复用记录 |
角色可以兼任，但判断与评审建议由不同人承担，减少“自己改自己审”带来的盲区。经验提供者不一定全程参与，但在拆解和冲突定位阶段应可被咨询，否则成立条件容易写空。
这些结构化条目和改写记录需要有承载的地方。ONES Wiki 可用于集中沉淀项目规范、复盘记录等需要长期保留的知识，支持页面树组织与版本记录，便于查找和更新；它也能与 ONES 的项目、任务等场景结合，让文档和项目工作保持关联。经验条目四栏模板、改写记录格式可以通过页面模板统一，使不同项目的记录口径一致。若团队需要按自定义字段检索经验条目，具体实现方式需结合所用版本确认。
示例：同一套迭代节奏搬到不同团队
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
来源项目背景与做法：一个8人团队，前后端同处一个办公区，采用两周迭代，每轮迭代第一天开计划会、最后一天做评审，需求方全程参与，评审当场确认下轮范围。经验条目记录为：结论是“两周迭代加需求方到场评审”；成立条件是“团队规模小、需求方集中、决策链短”；可调参数是迭代周期、评审参与角色、确认方式。
新项目差异：新项目团队20人，分为三个小组，技术栈增加了新的前端框架，工期压缩为十周，需求方分布在两个部门，无法每次到场。按相似性判断表，团队维度为中低匹配，技术栈为中匹配，约束为低匹配，整体结论是“改写后沿用，部分环节仅作参考”。
逐项判断：迭代周期可保留两周，但三个小组需要各自同步再汇总；评审到场要求与新情境冲突，需改为书面确认加定期集中评审；计划会的参与范围需按小组拆分。硬约束是工期十周，不能通过拉长迭代来缓解。
改写后方案与验证：迭代周期维持两周，各小组每日同步、每轮迭代末汇总一次；需求范围由需求方提前书面确认，每两周集中评审一次；计划会按小组召开，跨组依赖在汇总会上对齐。验证方式是在一个小组先运行两轮迭代，观察范围变更次数、评审确认时长和跨组阻塞数量，与预期对比后再推广到其余小组。
小范围试点与完成检查
改写方案是否成立，靠试点验证，而不是靠讨论达成一致。试点范围建议选择一个具备代表性的小组或一个迭代周期，范围过大反而难以判断偏差来源。观察指标应与改写时针对的冲突环节对应：如果改写的重点是评审确认方式，就观察确认时长和返工次数；如果重点是跨组协作，就观察阻塞数量和解决周期。
| 试点记录项 | 填写内容 |
|---|---|
| 试点范围 | 参与小组、时间跨度、覆盖的迭代轮次 |
| 观察指标与预期 | 指标名称、预期值、设定依据 |
| 实际结果 | 指标实际值、出现的异常情况 |
| 偏差分析 | 偏差来自改写不当、执行问题还是原经验条件判断有误 |
| 反馈动作 | 需要修订的经验条目字段或改写内容 |
试点结果与预期出现偏差时，要区分原因再反馈：如果是成立条件判断有误，回到经验条目修订来源背景和条件描述；如果是改写参数不合适，修订改写记录中的参数；如果是执行不到位，补充操作说明而非改动经验本身。反馈完成后，经验条目应更新为包含新情境验证结果的新版本，供后续项目参考。
复用流程完成时，逐项核对以下检查项：
- 相似性已判断：团队、技术栈、约束三个维度均有比对结论和复用程度分级。
- 经验已拆解：结论、成立条件、可调参数、来源背景四栏齐全，硬约束已单独标出。
- 改写有记录：差异点、冲突环节、改写内容与理由均已归档。
- 评审已确认：改写方案经过适用性确认，关键差异均有对应处理。
- 试点有结论：观察指标有实际结果，偏差已分析并反馈到经验条目。
五项检查全部完成，这次复用才算闭环。经验条目经过一轮真实项目的验证和修订，下一次被复用时，成立条件更清楚，改写起点也更高。
常见问题
如果新项目与来源项目只有一个维度差异很大，还能复用吗？
可以复用，但复用程度要按最低匹配的维度来定。团队、技术栈、约束三个维度中只要有一个落在低匹配，就不宜整段照搬，哪怕其余维度都很接近。此时原经验仅作参考，需要针对低匹配维度重新设计方案，其余部分可保留结论、替换实现方式。判断结论要写明依据，例如“合规要求从建议性变为强制审计，评审流程需重新设计”，方便后续复核。
经验提供者已经离职，成立条件补不全怎么办？
先利用现有材料还原背景：来源项目的立项文档、复盘记录、当时的方案评审意见，都能帮助推断做法为什么有效。若仍有关键条件无法确认，就把这条经验的成立条件标注为“待验证”，在复用时按低匹配处理，只作参考并重新设计。试点阶段重点观察这条经验在新情境下的表现，用实际结果补全条件描述，再更新经验条目。
试点结果不理想，应该改经验条目还是改改写方案？
先区分偏差来源再决定改哪里。如果是成立条件判断有误，例如原以为需求方集中办公、实际分散在多个部门，就回到经验条目修订来源背景和条件描述；如果是改写参数不合适，例如评审周期定得过短导致确认不充分，就修订改写记录中的参数；如果是执行不到位，例如会议开了但没人做书面确认，就补充操作说明，不改动经验本身。三类原因对应三类修订动作，混在一起改会让下一次复用失去依据。
小团队没有专职知识管理角色，复用流程怎么跑？
角色可以兼任，关键是判断与评审由不同人承担，避免自己改自己审。小团队可由项目负责人完成相似性判断与改写，由另一位熟悉来源项目的成员做适用性确认，经验条目的结构化字段和改写记录由项目负责人顺手维护。流程本身不必增加人手，但改写记录要归档到团队共用的知识库中，保证下一次复用时能查到差异点和改写理由。
经验条目和改写记录放在哪里，才能被后续项目找到？
建议放在团队共用的知识库中，按项目或业务线组织页面，经验条目使用统一的四栏模板，改写记录与对应条目放在同一页面树下。ONES Wiki 支持页面树方式组织页面，提供页面模板库，文档实时同步并记录页面版本，可用于集中沉淀项目规范、复盘记录等需要长期保留的知识，也能与项目、任务等场景结合，让文档和项目工作保持关联。若团队需要按自定义字段检索经验条目，具体实现方式需结合所用版本确认。
