项目经验沉淀记录模板通常包含五组字段：记录基本信息、背景与目标、问题或事件描述、决策依据与结果、可复用结论与适用边界。模板按“背景—问题—决策—结论—边界”的顺序组织，填写时把事实与判断分开，结论写成他人可直接引用的句子，边界写明结论失效的条件。下面给出一张可直接复制的空白表、逐字段填写口径、必填与选填对照，以及一条完整示例。
要点总览（TL;DR）
- 模板按“背景—问题—决策—结论—边界”五组字段组织，核心字段包括项目背景、问题描述、决策依据、可复用结论和适用边界。
- 必填项为记录编号、项目名称、记录人/日期、项目背景、问题描述、决策依据、可复用结论和适用边界；暂缺时标注“待补”并写明补录责任人与时间。
- 可复用结论要写成包含条件、动作和结果的句子，适用边界写明结论成立的前提和失效情形，防止被其他项目错误套用。
- 模板可按项目类型裁剪字段，建议每季度或每轮复盘后评审一次，保留版本号和变更说明，新记录按新版本填写。
- 记录填写后进入统一归档位置，按项目、阶段、问题类型建立检索入口，在后续项目启动或复盘时检索引用。
可复制空白模板：项目经验沉淀记录表
下表可直接复制到文档或表格工具中使用。表头保持固定，空行按项目实际填写；字段较多时可拆成两张表，第一张放基本信息与背景问题，第二张放决策、结论与边界，拆分后字段名称保持不变。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | |
| 项目名称 | ||
| 项目阶段 | ||
| 记录人 / 参与人 | ||
| 记录日期 / 更新日期 | ||
| 背景与目标 | 项目背景 | |
| 本阶段目标 | ||
| 约束条件 | ||
| 问题或事件 | 问题描述 | |
| 发生时间与场景 | ||
| 影响与证据 | ||
| 决策依据与结果 | 备选方案 | |
| 决策依据与取舍理由 | ||
| 结果与验证方式 | ||
| 结论与边界 | 可复用结论 | |
| 适用边界与不适用情形 | ||
| 关联资料与责任人 |
复制时保留“分组”列，它帮助填写人理解字段之间的逻辑关系；正式归档时可以隐藏该列，只保留字段名与内容两列。若团队使用在线文档，可把每个分组做成一个小节，字段名作为小节内的小标题，便于逐项填写和评论。
字段说明：每个字段记录什么、怎么写
字段说明的作用是让不同人填出的记录具备可比性。同一字段在不同项目里写法差异过大，后续检索和引用就会失效。以下按分组说明每个字段的记录对象和填写口径。
基本信息类字段
记录编号用于唯一标识一条经验，建议采用“项目缩写-年份-序号”的形式，便于在知识库中定位。项目名称写正式立项名称，避免使用内部简称造成检索困难。项目阶段写明记录发生在需求、设计、开发、测试、上线或复盘中的哪个环节。记录人与参与人分开写，记录人负责内容准确性，参与人提供事实来源。记录日期与更新日期都保留，更新日期用于判断内容是否仍然有效。
背景与问题类字段
项目背景用三到五句话说明项目要解决的问题、所处业务环境和关键约束，让未参与项目的人能读懂后文。本阶段目标写当时承诺达成的结果，用可观察的指标或交付物描述。约束条件记录时间、人力、预算、技术栈或合规方面的限制，这些限制往往是后续决策依据的来源。问题描述写清发生了什么、在什么条件下发生，只写事实，原因分析留到决策依据字段。影响与证据记录问题造成的实际后果，附上数据、日志、工单编号或会议纪要位置，证据要能被他人复核。
决策依据与结果类字段
备选方案列出当时考虑过的两到三个选项，包括最终未采用的方案，并简述各自代价。决策依据写选择某一方案的理由，区分事实依据（数据、测试结果、约束条件）和判断依据（经验、风险评估），判断部分注明是判断而非事实。结果与验证方式写决策执行后的实际结果，以及用什么方式确认结果，例如上线后的指标变化、测试通过率或用户反馈。结果不理想时同样如实记录，失败经验的可复用价值往往更高。
可复用结论与适用边界类字段
可复用结论写成一句或几句可以被其他项目直接引用的话，包含条件、动作和预期结果，例如“在接口联调阶段提前冻结字段定义，可减少返工”。适用边界写明结论成立的前提和失效情形，包括项目规模、技术环境、团队结构或业务类型的变化。关联资料与责任人记录相关文档、代码仓库、看板或会议记录的入口，以及该条经验的维护责任人，便于后续有人核对和更新。
必填与选填：哪些字段不能空
必填字段决定一条记录能否被他人理解和引用，选填字段用于补充上下文。必填项暂缺时不要留空，保留字段并标注“待补”，同时写明补录责任人和计划补录时间，避免读者把空白误读为“无此情况”。
| 字段 | 要求 | 理由或适用情形 |
|---|---|---|
| 记录编号 | 必填 | 用于唯一标识和检索 |
| 项目名称 | 必填 | 关联项目上下文 |
| 记录人 / 日期 | 必填 | 明确内容责任与时效 |
| 项目背景 | 必填 | 他人理解问题的前提 |
| 问题描述 | 必填 | 记录的核心对象 |
| 决策依据 | 必填 | 经验复用的关键，缺失则结论无法验证 |
| 可复用结论 | 必填 | 沉淀的目的所在 |
| 适用边界 | 必填 | 防止结论被错误套用 |
| 项目阶段 | 选填 | 跨阶段经验或阶段不明显时可省略 |
| 参与人 | 选填 | 单人项目或记录人即当事人时可省略 |
| 约束条件 | 选填 | 约束对结论影响不大时可省略 |
| 备选方案 | 选填 | 决策路径单一、无备选时注明“无备选” |
| 影响与证据 | 选填 | 问题影响轻微时可简述，但仍建议保留证据入口 |
| 关联资料与责任人 | 选填 | 无关联文档时可只写责任人 |
必填项暂缺的常见情形是决策依据在记录时尚未完全明确。此时在字段内写“待补：需确认XX数据”，并指定责任人和补录时间，记录仍可先归档，但要在评审时优先补齐。选填字段省略时，建议在字段内写“不适用”并简述原因，保持表结构完整，方便后续按字段批量检索。
填写示例：一条完整的项目经验记录
以下示例为演示情景，用于展示字段之间的对应关系和事实与判断分开的写法，不代表真实项目数据。
| 字段 | 示例内容 |
|---|---|
| 记录编号 | ORDER-2024-007 |
| 项目名称 | 订单中心重构项目 |
| 项目阶段 | 接口联调 |
| 记录人 / 参与人 | 张明 / 李华、王芳 |
| 记录日期 / 更新日期 | 2024-06-12 / 2024-06-20 |
| 项目背景 | 订单中心需在两个月内完成服务拆分，前端与三个后端服务并行开发，接口字段由各服务自行定义。 |
| 本阶段目标 | 完成订单创建、查询两条主链路的联调，接口通过率不低于95%。 |
| 约束条件 | 联调窗口只有两周，后端人力紧张，无法安排专人维护接口文档。 |
| 问题描述 | 联调第一周，订单创建接口的金额字段在前端显示为字符串，后端返回为数值，双方各自按自己的理解实现，导致对账失败。 |
| 发生时间与场景 | 2024-05-28，订单创建链路联调测试环境。 |
| 影响与证据 | 联调阻塞两天，涉及三个页面；证据为缺陷单 BUG-2317 与联调群聊天记录。 |
| 备选方案 | 方案一：前端做类型转换；方案二：后端统一返回字符串；方案三：联调前冻结字段定义并生成契约文档。 |
| 决策依据与取舍理由 | 事实：同类字段在历史项目中出现过三次类型不一致。判断：前端转换会掩盖契约问题，后端改类型影响面大；冻结字段定义能从源头减少返工，代价是需要提前半天对齐。最终选择方案三。 |
| 结果与验证方式 | 冻结字段定义后，剩余联调缺陷中类型类问题降为零，接口通过率在第二周达到98%；验证方式为缺陷单分类统计与联调报告。 |
| 可复用结论 | 多服务并行联调前，由接口提供方冻结字段名称与类型并生成契约文档，可显著减少类型不一致导致的返工。 |
| 适用边界与不适用情形 | 适用于两个以上团队并行开发、接口字段由多方定义的场景；单一团队内部接口或字段已由统一规范约束时，收益有限。 |
| 关联资料与责任人 | 契约文档见项目文档库“订单中心-接口契约”；责任人张明，负责后续补充其他链路的同类经验。 |
示例体现了三条填写规范：问题描述只写现象和证据，原因分析放在决策依据；决策依据中明确区分事实与判断；可复用结论包含条件、动作和结果，边界写明适用与不适用情形。照此写法，其他项目在遇到类似联调场景时可以直接引用该结论，并自行判断是否落在适用边界内。
模板的调整与维护方法
模板需要在团队实际使用中裁剪和更新，否则字段会越加越多、填写成本上升，最终被弃用。调整时以“是否影响他人理解和引用”为判断标准，维护时以固定节奏评审和版本记录为保障。
按项目类型裁剪字段
研发交付类项目保留全部字段，重点在决策依据和结果验证。运维故障类项目可强化问题描述、影响与证据，弱化备选方案。市场或运营类项目可增加效果指标字段，减少技术约束字段。裁剪的原则是：背景、问题、决策依据、可复用结论、适用边界五组字段建议保留，其余字段按项目类型增减。裁剪后的模板作为变体保存，注明适用项目类型，避免不同变体混用导致字段对不上。
新增字段的判断标准
新增字段前先问三个问题：现有字段能否承载这类信息；新增后是否会有超过一半的记录需要填写；缺少该字段是否真的导致记录无法被引用。三个问题都指向“需要”时再新增，并在字段说明中同步补充填写口径。仅为个别项目特殊需求增加的字段，放在记录末尾的“补充说明”中，不进入通用模板。
模板评审与版本更新
建议每季度或每完成一轮项目复盘后评审一次模板，检查字段是否仍被使用、必填项是否经常被标注“待补”、示例是否与当前实践一致。评审由知识管理负责人或项目管理部门牵头，收集填写人的反馈后形成修改意见，更新模板时保留版本号和变更说明，旧记录不强制回填，但新记录按新版本填写。
归档与复用入口
记录填写完成后需要进入统一的归档位置，并按项目、阶段、问题类型建立检索入口，否则模板填得再好也难以被复用。团队可以在 ONES Wiki 中建立项目经验页面组，将记录作为长期沉淀的文档管理，页面组关联对应项目，使需求与文档互相对应；ONES Wiki 提供页面模板库，可一键创建制式化文档模板，把本文的字段结构固化为团队统一模板，减少每次新建记录时的重复搭建。文档记录页面版本并支持查看与回滚，模板调整后旧记录仍可追溯。归档时同步登记责任人和更新日期，在后续项目启动或复盘时按问题类型检索引用，形成“填写—归档—检索—引用—更新”的闭环。
常见问题
项目经验沉淀记录和项目复盘报告有什么区别，能不能用复盘报告代替？
两者可以并存，但用途不同。复盘报告面向一次项目的整体回顾，覆盖过程、结果和团队协作；经验沉淀记录面向可被其他项目引用的单条经验，围绕一个具体问题写清背景、决策依据、结论和适用边界。用复盘报告代替沉淀记录时，常见问题是结论散落在长篇叙述中，其他项目难以检索和直接引用。建议在复盘报告之外，把其中可复用的判断单独整理成沉淀记录，一条记录对应一个可复用结论。
决策依据在记录时还没完全明确，这条记录还能先归档吗？
可以先归档，但要在决策依据字段内标注“待补”，写明还需要确认的数据或信息，并指定补录责任人和计划补录时间。记录评审时优先补齐这类字段。决策依据是经验复用的关键，长期缺失会让结论无法被验证，因此待补状态不宜持续太久，建议在下一轮模板评审时检查待补项是否已清理。
多个团队共用一套模板时，字段口径不一致怎么办？
先统一字段说明，再统一模板。字段说明中明确每个字段记录什么、事实与判断如何区分、结论写到什么颗粒度，各团队按同一口径填写。确有差异时，把差异做成模板变体并注明适用项目类型，避免在同一份记录里混用不同口径。定期抽取几条记录做交叉评审，检查同一字段在不同团队间的写法是否可比，发现偏差及时回到字段说明中修正。
沉淀记录归档后，怎么让后续项目真正用起来？
归档时按项目、阶段、问题类型建立检索入口，并登记责任人和更新日期。后续项目在启动、方案评审或复盘时，按问题类型检索相关记录，引用时核对结论的适用边界是否匹配当前场景。团队可以在 ONES Wiki 中建立项目经验页面组，将记录作为长期文档管理，页面组关联对应项目，使需求与文档互相对应；页面模板库可把字段结构固化为统一模板，减少每次新建记录的重复搭建。
失败项目的经验要不要按同一模板记录？
建议使用同一模板。失败经验的可复用价值往往更高，但填写时更要区分事实与判断：问题描述和影响证据如实记录，决策依据中写明当时掌握的信息和判断依据，避免用事后视角改写当时的决策逻辑。可复用结论可以写成“在什么条件下应避免某种做法”的形式，适用边界写明该结论依赖的前提，便于其他项目对照自身情况判断是否适用。
