项目经验沉淀记录表按“一条经验一行记录”填写，核心字段分为基本信息、背景与问题、过程与决策、结论与边界、证据与维护五组。填写时先交代项目背景和触发问题，再写候选方案与决策依据，把结论写成他人能直接照做的动作，最后补齐适用边界、证据链接和维护人。本文提供可直接复制的空白表格、逐字段填写口径、必填项划分和一条完整示例，拿到即可照着填。
要点总览（TL;DR）
- 记录表按“一条经验一行记录”组织，字段分为基本信息、背景与问题、过程与决策、结论与边界、证据与维护五组，共22个字段，可直接复制使用。
- 填写顺序建议为：先写项目背景与问题，再列候选方案与决策依据，然后把结论写成带触发条件和动作的句式，最后补齐适用边界、证据链接与维护人。
- 必填项包括标题、项目名称、记录人、日期、经验类型、项目背景、问题描述、候选方案、决策依据、可复用结论、适用条件、不适用情形、证据材料与维护人；暂时无法填写的用“待补充＋原因＋计划时间”标注。
- 可复用结论要写成他人能直接照做的动作，适用条件与不适用情形成对出现，防止经验被错误套用。
- 模板需按团队情况裁剪字段并设定复审节奏，失效经验标注原因后归档，模板调整时记录版本号与变更说明。
可复制空白模板：项目经验沉淀记录表
下表按五组字段排列，字段编号与后文字段说明一一对应。复制到 Word、在线文档或表格工具时，建议保留编号列，便于团队讨论时直接引用“F07 怎么写”这类问题。一条经验占一行；如果一条经验包含多个独立结论，拆成多条记录，不要在一行里塞进多个主题。
| 组别 | 编号 | 字段名 | 填写内容 |
|---|---|---|---|
| 基本信息 | F01 | 记录标题 | |
| F02 | 项目名称 | ||
| F03 | 记录人 | ||
| F04 | 记录日期 | ||
| F05 | 经验类型 | ||
| F06 | 关联阶段 | ||
| 背景与问题 | F07 | 项目背景 | |
| F08 | 触发情境 | ||
| F09 | 问题描述 | ||
| F10 | 影响范围 | ||
| 过程与决策 | F11 | 候选方案 | |
| F12 | 决策依据 | ||
| F13 | 关键取舍 | ||
| F14 | 验证结果 | ||
| 结论与边界 | F15 | 可复用结论 | |
| F16 | 适用条件 | ||
| F17 | 不适用情形 | ||
| F18 | 前置依赖 | ||
| 证据与维护 | F19 | 证据材料 | |
| F20 | 关联文档 | ||
| F21 | 维护人 | ||
| F22 | 复审周期 |
如果团队使用在线表格，可以把上表转置为“字段名做列、每条经验做行”的宽表；如果使用文档承载，则每条经验单独一节，按五组小标题组织。两种形态的字段内容一致，选择取决于团队检索习惯：需要按类型、阶段筛选时用表格，需要保留叙述细节时用文档。
字段说明：每个字段填什么、怎么表述
字段说明解决“知道有这一栏，但不知道写什么”的问题。下面按五组逐项给出填写口径，并说明写到什么程度算合格。
基本信息类字段（F01–F06）
- 记录标题：用“情境＋动作＋对象”概括，例如“跨团队接口联调延期时的排期重排方法”。标题要能让人不点开正文就判断是否与自己相关，避免“项目复盘”“经验总结”这类无法检索的写法。
- 项目名称：写团队内部通用叫法，必要时附项目编号，便于回溯。
- 记录人：写具体姓名或可识别的角色账号，便于后续追问细节。
- 记录日期：写经验形成或整理完成的日期，用于判断时效。
- 经验类型：从团队约定的枚举值中选择，如技术决策、协作问题、进度风险、质量处理、需求变更。类型决定后续必填项的松紧。
- 关联阶段：标注经验发生在需求、设计、开发、测试、上线、运维中的哪个阶段，帮助读者判断迁移场景。
背景与问题类字段（F07–F10）
这一组的目标是让没参与项目的人也能理解“当时为什么必须做决定”。项目背景写规模、周期、团队构成等约束条件，两三句即可；触发情境写是什么事件让问题暴露出来，例如一次延期、一次线上故障或一次评审分歧；问题描述写清现象与判断，避免只写情绪化结论；影响范围写问题波及的模块、角色和时间窗口。四栏合起来应能回答：在什么条件下，发生了什么，严重到什么程度。
过程与决策类字段（F11–F14）
候选方案至少列出两个，包括最终未采用的方案，并各写一句优缺点；决策依据写当时掌握的信息、约束和判断标准，例如工期、人力、兼容性要求；关键取舍写清楚放弃了什么、换取了什么；验证结果写决策之后的实际表现，包括未达预期的部分。这一组是记录表中最容易被写空的部分，合格标准是：读者能理解“为什么选这个而不是另一个”，并能判断自己的场景是否相似。
结论与边界类字段（F15–F18）
可复用结论写成带触发条件和动作的句式，例如“当接口联调延期超过三天时，先冻结非关键需求，再按依赖关系重排联调顺序，最后同步给相关方确认”。适用条件写规模、阶段、角色等前提；不适用情形写清哪些场景套用会出问题；前置依赖写结论生效需要哪些工具、权限或流程配合。结论与边界必须成对出现，只写结论不写边界，经验就容易被误用。
证据与维护类字段（F19–F22）
证据材料以链接或附件编号记录，如评审纪要、监控截图、数据报表；关联文档指向需求文档、设计稿或复盘记录；维护人写具体角色而非部门名称，确保有人对内容准确性负责；复审周期写建议的复核间隔，如每季度或每次同类项目结束后。证据和维护信息决定了这条经验日后还能不能被信任。
必填与选填：哪些字段不能空
必填项的判断标准是：缺少该字段，读者无法判断这条经验是否适用于自己，或无法验证其真实性。按此标准，以下字段为必填：F01 记录标题、F02 项目名称、F03 记录人、F04 记录日期、F05 经验类型、F07 项目背景、F09 问题描述、F11 候选方案、F12 决策依据、F15 可复用结论、F16 适用条件、F17 不适用情形、F19 证据材料、F21 维护人。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| F01–F05 | 必填 | 缺少基本信息，记录无法被检索和追溯 |
| F06 关联阶段 | 选填 | 跨阶段经验可留空或标注“多阶段” |
| F07 项目背景 | 必填 | 没有背景，结论无法判断迁移条件 |
| F08 触发情境 | 选填 | 问题由长期积累形成时可省略 |
| F09 问题描述 | 必填 | 记录的核心对象 |
| F10 影响范围 | 选填 | 影响面小或难以量化时可简述 |
| F11 候选方案 | 必填 | 至少两个方案，含未采用方案 |
| F12 决策依据 | 必填 | 结论可信度的主要来源 |
| F13 关键取舍 | 选填 | 方案差异明显时建议填写 |
| F14 验证结果 | 选填 | 经验形成时尚未验证可标注“待观察” |
| F15 可复用结论 | 必填 | 记录的价值所在 |
| F16 适用条件 | 必填 | 与结论成对出现 |
| F17 不适用情形 | 必填 | 防止经验被错误套用 |
| F18 前置依赖 | 选填 | 依赖工具或权限时填写 |
| F19 证据材料 | 必填 | 至少一条可核对的链接或附件 |
| F20 关联文档 | 选填 | 有对应文档时补充 |
| F21 维护人 | 必填 | 写具体角色 |
| F22 复审周期 | 选填 | 默认按团队统一节奏 |
确实暂时无法填写的必填项，用“待补充＋原因＋计划补充时间”标注，例如“F14 验证结果：待补充，上线两周后回填”，不要留空白，空白无法区分“忘了填”和“不适用”。按经验类型可调整必填松紧：技术决策类强化 F11–F14，协作问题类强化 F08、F10 和 F17，进度风险类强化 F07、F16 和 F18。调整规则由团队在模板说明中写明，避免每条记录各自解释。
填写示例：一条完整记录长什么样
以下为演示情景，用于说明各字段如何落到具体文字，不代表真实项目数据。
| 编号 | 字段名 | 填写内容 |
|---|---|---|
| F01 | 记录标题 | 跨团队接口联调延期时的排期重排方法 |
| F02 | 项目名称 | 订单中心改造项目 |
| F03 | 记录人 | 项目负责人（示例） |
| F04 | 记录日期 | 2025-03-14 |
| F05 | 经验类型 | 进度风险 |
| F06 | 关联阶段 | 开发与联调 |
| F07 | 项目背景 | 项目涉及三个团队，联调窗口为两周，依赖方接口文档在联调开始后才定稿 |
| F08 | 触发情境 | 联调第三天发现两个核心接口字段不一致，原定联调计划无法继续 |
| F09 | 问题描述 | 接口字段定义分歧导致联调阻塞，若按原计划推进，测试阶段将被压缩 |
| F10 | 影响范围 | 影响订单创建与支付回调两条链路，涉及三个团队的六名开发人员 |
| F11 | 候选方案 | 方案A：暂停联调，等接口文档统一后重启；方案B：先冻结非关键字段，按已确认字段继续联调；方案C：由一方临时适配另一方字段 |
| F12 | 决策依据 | 联调窗口只剩七天，方案A会直接压缩测试时间；方案C会引入临时适配代码，增加上线后维护成本；方案B能在保留关键链路验证的同时争取时间 |
| F13 | 关键取舍 | 放弃一次性完成全部字段联调，换取核心链路按期验证；非关键字段的联调顺延到测试阶段 |
| F14 | 验证结果 | 核心链路按期完成联调，非关键字段在测试阶段补齐，未影响上线日期；但测试阶段多出两天联调工作量 |
| F15 | 可复用结论 | 当跨团队联调因接口定义分歧阻塞超过一天时，先冻结非关键字段，按已确认字段继续联调，同时指定接口负责人当天完成分歧字段定稿，最后在测试计划中预留补齐时间 |
| F16 | 适用条件 | 多方参与、联调窗口固定且核心链路可独立验证的项目 |
| F17 | 不适用情形 | 接口分歧涉及资金或权限等不可拆分字段时，应暂停联调先统一定义；项目处于合规审查阶段时，字段变更需走审批流程 |
| F18 | 前置依赖 | 需要各团队指定接口负责人，并有可用的联调环境 |
| F19 | 证据材料 | 联调问题记录链接、接口字段对照表、调整后的联调计划 |
| F20 | 关联文档 | 接口设计文档、测试计划 |
| F21 | 维护人 | 项目负责人（示例） |
| F22 | 复审周期 | 每季度复核一次，同类项目结束后补充验证结果 |
示例中 F15 的写法值得注意：它包含触发条件（阻塞超过一天）、动作顺序（冻结、继续、定稿、预留时间）和责任对象（接口负责人），读者可以直接照做。F17 则明确了两类不适用情形，避免他人把这条经验套用到资金类接口或合规审查场景。整条记录与空白模板的字段编号完全对应，团队可以按同一结构批量整理历史经验。
调整与维护：按团队情况改字段并保持可用
模板拿到团队后需要做两件事：按业务特点裁剪字段，按时间节奏维护内容。裁剪的原则是保留“判断是否适用”和“验证真实性”所需的字段，删减重复或长期空置的栏目。常见做法包括：小团队合并 F03 与 F21，由同一人负责记录与维护；以文档为主的团队把 F19、F20 合并为“相关材料”一栏；经验类型较单一的团队去掉 F05，改在目录层级区分。每次增删字段都要同步更新字段说明和示例，避免模板与说明脱节。
记录入库后，维护人负责在复审周期内核对结论是否仍然成立。复审时重点看三处：适用条件是否因团队规模或流程变化而失效，证据链接是否还能打开，验证结果是否有新数据可以补充。确认失效的经验不要直接删除，改为标注“已失效＋失效原因＋替代记录链接”后归档，保留历史判断的来龙去脉。模板本身也需要版本管理：字段调整时记录版本号和变更说明，旧记录按原版本保留，新记录使用新版本，避免历史记录被批量改写后失去可比性。
记录表填写完成后需要有稳定的存放和复用位置。ONES Wiki 支持使用模板库一键创建制式化文档，团队可以把记录表做成页面模板，新建记录时直接套用；页面组可关联项目，需求与文档互相对应，便于从项目回到对应经验记录；文档实时同步并记录所有页面版本，支持随时查看与回滚，适合承载会持续复审更新的经验内容；同时支持为不同角色配置读写权限，并可从回收站恢复误删除页面。将记录表放入这类文档与知识管理环境后，维护人、复审周期和关联项目都能随记录一起保留，经验复用时有据可查。
常见问题
一条经验里包含多个结论，应该拆成多条记录还是写在一行里？
建议拆成多条记录。记录表以“一条经验一行记录”为基本单位，一行对应一个可独立判断是否适用的结论。如果一条经验包含多个独立结论，写在一行里会让适用条件和不适用情形互相纠缠，读者难以判断哪条结论适用于自己的场景。拆分时可以在记录标题上做区分，例如同一项目下分别记录“排期重排方法”和“接口字段定稿流程”，并在关联文档字段互相引用。
必填项在记录形成时确实拿不到，能先空着以后补吗？
可以补，但不建议留空白。空白无法区分“忘了填”和“不适用”，复审时也无从判断。建议用“待补充＋原因＋计划补充时间”的格式标注，例如“F14 验证结果：待补充，上线两周后回填”。维护人应在复审周期内核对这些待补充项，补齐后去掉标注。如果某项长期无法补充，应在团队模板说明中明确该字段的降级处理方式，避免每条记录各自解释。
技术决策类和协作问题类的记录，必填项要不要区别对待？
可以按经验类型调整必填松紧，但调整规则要写在模板说明里统一执行。常见做法是：技术决策类强化候选方案、决策依据、关键取舍和验证结果；协作问题类强化触发情境、影响范围和不适用情形；进度风险类强化项目背景、适用条件和前置依赖。调整只影响个别字段的必填要求，标题、问题描述、可复用结论、适用条件、不适用情形、证据材料与维护人这些判断适用性和真实性的核心字段仍应保留。
记录入库后由谁负责复审，复审时重点看什么？
由记录表填写的维护人负责，在复审周期内核对内容是否仍然成立。复审重点看三处：适用条件是否因团队规模、流程或工具变化而失效；证据链接是否还能打开；验证结果是否有新数据可以补充。确认失效的经验不要直接删除，改为标注“已失效＋失效原因＋替代记录链接”后归档，保留历史判断的来龙去脉。团队可以把复审周期设为每季度一次，或在同类项目结束后触发补充验证。
记录表放在文档里还是在线表格里更合适？
取决于团队的检索习惯。需要按经验类型、关联阶段筛选和统计时，用在线表格更顺手，可以把字段名做成列、每条经验做成行；需要保留叙述细节和上下文时，用文档承载更合适，每条经验单独一节，按五组小标题组织。两种形态的字段内容一致，也可以组合使用：文档承载完整记录，表格维护索引。若使用 ONES Wiki，可将记录表做成页面模板，新建记录时直接套用，页面组关联项目，文档版本可随时查看与回滚，便于承载会持续复审更新的经验内容。
