主题
13 - 复盘与资产化
把一次项目沉淀成下一次项目的起点
目标
复盘不是简单写一句“这次做得不错”,资产化也不是把所有文件原样打包归档。
本章的目标是:
- 把这轮项目中真正有效和无效的决策写清楚
- 把 prompt、脚本、模板、检查表、失败案例和数据处理套路整理成可复用资产
- 把“这次项目依赖谁记得”转成“下次项目可以直接拿来用”
- 输出
RETROSPECTIVE.md与ASSET_INDEX.md - 为后续 worked example、skill 沉淀和下一轮项目启动提供稳定输入
本章回答的问题是:
这轮项目到底学到了什么,哪些东西值得复用,哪些错误不该再犯?
完成标准
完成本章,不等于“项目结束后开了个会”,而是至少做到:
- 你有一份经过人类复核的
RETROSPECTIVE.md - 你有一份经过整理的
ASSET_INDEX.md - 你明确记录了成功决策、失败决策、未解决风险和下一步建议
- 你把可复用内容从“散落在仓库里”提升成“可检索的资产”
- 你能明确说出下次研究项目应该直接继承什么
输入与标准产物
输入
建议直接使用 01-12 章的最终产物:
| 输入 | 作用 |
|---|---|
PROBLEM_NOTE.md | 回看项目最初想解决的问题 |
NOVELTY_REPORT.md | 回看最初的 novelty 判断是否准确 |
EXPERIMENT_PLAN.md | 对照原计划与实际执行偏差 |
PILOT_LOG.csv | 回看哪些早期信号是对的、哪些是误判 |
ANALYSIS_REPORT.md | 汇总已确认的 findings、边界和失败模式 |
REVIEW_LOOP_LOG.md | 回看修复链路和 unresolved issues |
SUBMISSION_PACK.md | 记录最终投稿判断与剩余风险 |
| 项目代码、脚本、模板、提示词、日志、补充材料 | 作为可资产化对象 |
标准产物
| 产物 | 作用 | 后续会在哪用到 |
|---|---|---|
RETROSPECTIVE.md | 记录项目目标、实际结果、关键决策、错误和下一步 | 下个项目启动、worked example、团队复盘 |
ASSET_INDEX.md | 索引可复用 prompt、脚本、模板、checklist、失败案例和 skill 候选 | skill 提炼、模板库、项目启动 |
这些 artifact 的统一命名、建议路径和状态定义见:附录 E
人类-智能体协作
| 阶段 | 智能体适合做什么 | 人必须负责什么 | 常见风险 |
|---|---|---|---|
| 素材归档 | 汇总实验、日志、脚本、prompt、版本差异 | 判断哪些内容真正有复用价值 | 把所有文件都当资产 |
| 复盘草拟 | 按阶段整理成功点、失败点和决策偏差 | 对关键判断和教训签字 | 写成表面总结,回避真实错误 |
| 资产清单整理 | 给 prompt、模板、脚本和 checklist 建目录 | 决定哪些资产值得长期维护 | 没有边界地积累“收藏夹” |
| skill 候选提炼 | 把高复用流程压缩成输入输出契约 | 决定是否值得升格为 skill | 把一次性脚本误当通用 skill |
本章默认的工作方式是:
智能体负责整理、索引和归纳;人类负责判断哪些经验值得被制度化复用。
复盘与资产化不是什么
这一章不是:
- 给项目写一段漂亮总结就结束
- 把所有 prompt 和脚本原封不动丢进附录
- 只记录成功经验,不记录错误和误判
- 把一次性技巧误包装成稳定方法
本章真正要做的是:
把项目过程中的判断、失败和可复用结构,从个人记忆中抽离出来。
工作流
Phase 0: 冻结复盘包
复盘前先确定这一轮的输入版本:
- 最终稿版本
- 最终
SUBMISSION_PACK.md - 最终图表与附录版本
- 最终实验日志和关键脚本版本
否则后续会混入不同时间点的信息。
Phase 1: 先回答“结果相对于起点发生了什么”
复盘的第一步不是讲感受,而是对照起点与终点:
| 起点 | 终点 |
|---|---|
| 原始问题是什么 | 最终真正回答了什么 |
| 原始 novelty 假设是什么 | 最终哪些 novelty 站住了 |
| 原始实验计划是什么 | 最终哪些实验真正有用 |
| 原始投稿预期是什么 | 最终实际状态和风险是什么 |
如果这一步写不清,后面的“经验总结”通常会很空。
Phase 2: 分离三类经验
建议把经验至少拆成三类:
| 类别 | 你在总结什么 |
|---|---|
Worked | 哪些做法稳定产生了正向结果 |
Failed | 哪些做法反复失败或带来误导 |
Fragile | 有时有效,但依赖强假设或环境 |
这比笼统写“经验教训”更利于复用。
Phase 3: 识别可资产化对象
不是所有输出都值得资产化。优先考虑:
- 多次复用的 prompt 结构
- 多个项目都要用的表格模板和 checklist
- 反复出现的数据处理或评估脚本
- 一再出现的 reviewer objection 与答复模板
- 值得避免重犯的失败案例
可以使用下面的判断:
如果这项内容在下一个项目里大概率还会用到,而且输入输出边界清楚,它就值得资产化。
Phase 4: 把资产分级,而不是平铺收集
建议至少分四级:
| 级别 | 含义 |
|---|---|
reference | 有参考价值,但不建议直接复用 |
template | 可作为下次起点的模板 |
checklist | 可直接重复执行的检查单 |
skill_candidate | 已有清晰输入输出,适合升格为 skill |
这样可以避免资产库变成杂物间。
Phase 5: 写成 RETROSPECTIVE.md
RETROSPECTIVE.md 的作用不是“项目结题报告”,而是清楚说明:
- 我们以为会发生什么
- 实际发生了什么
- 为什么偏差出现
- 下次应直接继承什么,直接避免什么
一个可选的资产化流程图(LaTeX/TikZ)
如果你想在本章放一张“从项目结果到资产沉淀”的图,可以直接使用下面的 LaTeX 代码:
使用时需要:
latex
\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}RETROSPECTIVE.md 模板
markdown
# Retrospective
## Project Snapshot
- Original question:
- Final answered question:
- Final status:
## What Worked
1. ...
2. ...
## What Failed
1. ...
2. ...
## Fragile Lessons
1. ...
2. ...
## Decision Review
- Best early decision:
- Worst early decision:
- Most misleading signal:
- Most valuable negative result:
## Reuse Decisions
- Keep doing:
- Stop doing:
- Needs stronger guardrail:
## Next Project Suggestions
1. ...
2. ...ASSET_INDEX.md 模板
markdown
# Asset Index
| Asset Name | Type | Source | Reuse Rule | Status | Notes |
|------------|------|--------|------------|--------|-------|
| pilot-checklist-v1 | checklist | docs/06 | reuse as-is for ML pilot | active | |
| novelty-claim-card | template | docs/04 | use before experiment planning | active | |
| review-issue-table | template | docs/08 | use for rebuttal prep | active | |
| failed-long-run-heuristic | failure_case | project logs | avoid full-scale run before pilot | active | |
| paper-claim-matrix | skill_candidate | docs/09 | promote when used in 2+ projects | draft | |工具接入建议
这一章更适合吸收 附录 D 里“skill 契约、状态持久化、经验抽取”的来源:
| 工具 / 来源 | 更适合做什么 | 不要直接拿来做什么 |
|---|---|---|
| ARIS skills / stateful workflow | 提炼阶段产物、复盘状态和流程骨架 | 把一次性项目细节误写成通用规则 |
| Anthropic Skills | 判断哪些经验适合升格为 skill contract | 把未稳定的方法直接产品化 |
| AI-research-SKILLs | 提供可复用 research task 单元的写法 | 用 skill 包装不清晰的输入输出 |
| The AI Scientist | 观察多轮实验分支和日志组织方式 | 直接把自动探索记录等同于高质量资产 |
这里强调的是从已有自动化科研系统和 skill 框架中提炼“如何沉淀经验”,而不是传统项目结题式总结。
质量控制
1. 必须记录失败和误判
只记录成功经验,资产库会系统性误导后续项目。
2. 资产化对象必须有复用边界
没有输入输出边界的经验,不适合直接升格为模板或 skill。
3. 一次性技巧不要假装通用
如果它强依赖某个项目、数据集或个人习惯,就先停留在 reference。
4. 负结果是高价值资产
清楚解释“为什么这条路不值得再试”的失败案例,往往比成功 prompt 更可复用。
5. 资产库必须可检索
如果未来找不到、看不懂、用不上,就不算真正资产化。
常见错误
错误 1:只做情绪总结,不做决策复盘
表现:复盘里全是“时间很紧”“过程很辛苦”。
解决:重点记录判断、偏差、信号和决策质量。
错误 2:把所有文件都收进资产库
表现:仓库里任何东西都算资产。
解决:按 reference / template / checklist / skill_candidate 分级。
错误 3:不记录失败模式
表现:保留成功模板,但失败案例完全消失。
解决:为高成本误判单独保留 failure case。
错误 4:没有复用规则
表现:知道某个 prompt “挺有用”,但不知道什么时候用、怎么用。
解决:在 ASSET_INDEX.md 里写清 reuse_rule。
错误 5:复盘不回看起点
表现:只看最后结果,不对照原始问题和原始计划。
解决:先写“起点 vs 终点”,再写经验。
检查清单
完成本章后,你应至少能回答:
| 问题 | 状态 |
|---|---|
| 我是否对照了原始问题、计划与最终结果? | [] |
| 我是否区分了 worked、failed 和 fragile 经验? | [] |
| 我是否把可复用对象分级整理了? | [] |
| 我是否记录了关键失败案例和误判? | [] |
| 我是否为资产写清了复用规则? | [] |
小结
复盘与资产化的关键不是“给项目收尾”,而是:
- 回看起点与终点的偏差
- 把经验分成 worked、failed 和 fragile
- 挑出真正值得复用的 prompt、脚本、模板、checklist 和 failure case
- 产出
RETROSPECTIVE.md与ASSET_INDEX.md - 为下一轮项目、worked example 和 skill 提炼准备输入
至此,这本手册从问题定义、投稿,到项目沉淀形成了完整闭环。接下来最值得做的是选一个真实 AI/ML 项目跑通整条链,验证每章 contract 的清晰度。
引用 ARIS:本章的阶段化产物、状态持久化和经验沉淀思路主要来自 ARIS 的 skill 化 workflow。
扩展来源:这一版还吸收了 Anthropic Skills、AI-research-SKILLs 和 The AI Scientist 中关于 task contract、经验复用和分支结果沉淀的可执行经验。完整来源见:附录 D