Case Study Writing Method：如何写项目复盘

Method Note · published · 2026-06-08

记录我如何把项目介绍转化为包含设计理由、决策路径和阶段影响的项目复盘。

Cover

Case Study Writing Method：如何写项目复盘 writing cover.

Why this matters

项目复盘是容易被低估的写作类型。大多数人做完项目后，要么不写总结，要么写成"项目介绍"——罗列功能、展示截图、宣布完成。

但项目介绍和项目复盘是两种完全不同的文本。项目介绍面向外部，目的是展示成果；项目复盘面向未来，目的是保留上下文、记录决策、分析影响，让未来的自己能理解"当时为什么这样做"。

我写这篇笔记的动机来自一个具体问题：conanxin-homepage 从 HP-1 到 HP-15，每个阶段都有明确的产出，但如果没有复盘，这些阶段就只是"做了很多事"，而不是"系统性地成长"。复盘把离散的动作连接成可理解的发展轨迹。

Core idea

项目复盘的核心不是"我做了什么"，而是"我为什么这样做""这个决策带来了什么影响""如果重来我会怎么做"。

一个好的复盘应该回答：

• Starting Point：项目开始时的问题和约束
• First Principles：支撑设计的基本假设
• Key Decisions：影响项目走向的关键选择
• Phase Timeline：阶段如何推进，为什么这样划分
• What Changed：过程中哪些假设被推翻
• What I Learned：可迁移的经验和方法论

这些问题的答案比功能列表更有长期价值。功能会过时，但设计理由和决策路径可以帮助未来的项目。

Notes

项目介绍和项目复盘的区别

| 维度 | 项目介绍 | 项目复盘 | |------|----------|----------| | 目的 | 展示成果 | 保留上下文 | | 读者 | 外部访问者 | 未来的自己 | | 内容 | 功能、截图、链接 | 决策、影响、学习 | | 时间 | 项目完成时 | 项目进行中 + 完成后 | | 价值 | 短期展示 | 长期参考 |

这个区分帮助我避免把复盘写成宣传页。当我写"这个项目有搜索功能"时，我停下来问自己："搜索功能是如何设计的？为什么选择实时搜索而不是预生成索引？这个选择带来了什么影响？"

设计理由是复盘的核心

每个项目都有无数设计决策，但复盘不需要记录所有。只需要记录那些"如果重做，可能会不同"的决策。

conanxin-homepage 的几个关键设计理由：

• 为什么选择静态 HTML 而不是框架：因为我想理解每个文件的作用，而不是依赖框架的抽象
• 为什么选择 Markdown 作为内容源：因为内容应该与展示分离，便于长期维护
• 为什么每个阶段要有报告：因为报告强制思考，防止"做了但不知道为什么"
• 为什么要有 Links & Availability：因为公开站点最容易出问题的是链接边界

这些理由在写的时候可能觉得"显而易见"，但半年后回看，它们解释了为什么系统是现在这个样子。

阶段时间线如何保留上下文

HP-1 到 HP-15 不是随机编号，每个阶段有明确的边界：

• HP-1~3：基础结构（HTML/CSS/JS、GitHub Pages、Cloudflare）
• HP-4~6：内容系统（Projects、Writing、Lab、Case Studies）
• HP-7~9：发现系统（Search、Tags、Map、RSS）
• HP-10~11：媒体与关系（Screenshots、Media、Relations）
• HP-12~14：深度内容（About、Writing Depth Pass）
• HP-15：演示系统（Demo Gallery）

这个时间线的作用：当我在 HP-20 回头看时，能清楚知道每个能力是什么时候建立的，为什么在那个时间点建立。

影响分析如何帮助未来项目

修改影响分析是复盘中最难的部分。它要求你诚实地面对"这个改动带来了什么副作用"。

HP-11 的一个例子：新增 Relations 系统时，我分析了涟漪效应：

• 直接影响：Map 页面可以展示内容关系
• 间接影响：Homepage 可以展示"强关系"预览
• 长期影响：未来项目可以复用关系数据，自动生成关联推荐
• 风险：关系数据需要维护，如果项目改名或删除，关系可能失效

这种分析在做的当下可能觉得"过度思考"，但它训练了一种习惯：每次改动前问自己"这个改动会影响什么"。

如何写一个可信的 case study

可信的复盘有几个特征：

• 承认不确定性："当时我认为..."而不是"显然应该..."
• 标记假设：明确哪些是事实，哪些是推测
• 记录失败：不只写成功，也写尝试了什么但没成功
• 量化当可能："搜索索引从 28 条增加到 34 条"比"搜索功能增强了"更具体
• 连接方法论：把具体经验上升到可迁移的方法

conanxin-homepage 的复盘遵循这些原则。例如 HP-13 的链接可见性整理，我记录了：

• 问题：项目档案中的链接管理混乱，有泄露风险
• 方法：建立五级可见性（public/private/internal/pending/unavailable）
• 结果：29 条链接被分类，17 条 public，7 条 private
• 学习：链接边界是公开作品集最容易被忽视的安全问题

How I use it

这套方法直接影响了 conanxin.com 的 Case Studies 系统：

• 标准化结构：每个复盘包含 11 个标准区块，确保不遗漏关键信息
• 阶段报告：每个 HP 阶段结束后写报告，形成连续记录
• 影响分析：重大改动前强制写出涟漪效应
• 设计理由优先：代码会过时，但"为什么这样做"有长期价值

Related

Next

• 把 Case Study 方法应用到更多项目
• 设计复盘模板的标准化检查表
• 建立"复盘 → 方法论 → 模板"的迭代循环