框架+细节：测试项目文档结构化写作的实践与验证

1. 一次“另起炉灶”的动机：为什么要动SKILL

做研发文档和技术验证的人应该都有同感：SKILL这个词在不同语境下的含义差出十万八千里——有人聊的是EDA环境里的扩展脚本语言，有人说的是AI Agent的能力单元，还有人把它当做事方法论的代称。抛开具体技术栈，我这次要记录的是对个人的“技能使用/知识沉淀方式”做的一次重构尝试。

以前做测试项目文档，我的习惯是“边想边写”，打开一个空白文档，想到哪写到哪。结果往往是这样：开头写需求背景，写到一半发现漏了环境依赖，回头补；补着补着又发现用例设计的数据流讲得不清楚，再往前翻调整。最后文档倒是写完了，逻辑也能看，但你让我两周后再维护，我经常要花不少时间重新“顺着思路爬一遍”，才能找到某个字段到底是在哪一节定义的。很累，而且文档质量完全取决于当时的状态。

后来我复盘这种同事间的经验分享，听到一个思路：写文档要像搭建筑，先立框架，再填细节。框架管“哪里有什么”，细节管“这里具体是什么”。这本来不是新鲜观点，但真正让我决定动手尝试的，是它对“写作顺序”提出的硬性约束——你要先逼自己把目录、章节用途、各部分之间的引用关系想清楚，然后才允许自己动笔填内容。对我这种习惯“先写再说”的人是反人性的。

这个标题里说的“改成框架+细节方式的实践及验证”，我选择的落地场景就是“编写测试项目文档”。原因很直接：测试项目文档包含大量需要来回引用的信息（需求、环境、用例、缺陷、报告），信息之间耦合度高、复用频繁，对这种文档做“先框架后细节”的改造，收益最明显，也最容易验证出方法论到底行不行得通。这篇博文就完整记录我从计划、搭框架，到填充细节、做验证的整条操作路径，顺便附上踩坑和最终结论。

如果你是测试岗、文档工程师，或者跟我一样需要长期维护技术类文档的人，这篇内容应该能给你一个可以直接抄作业的模板。

2. 整体思路：框架层与细节层分别解决什么问题

2.1 拆分“框架”与“细节”的边界

既然要做“框架+细节”的尝试，第一件事就是把这两个词在实际操作中的边界划清楚。我的划分标准是三条：

层级标准：框架解决“信息放在哪”，细节解决“信息是什么”。例如“测试环境”这一节属于框架层，“使用的数据库版本号、IP地址、账号权限说明”属于细节层。

稳定性标准：框架层的变更频率应该远低于细节层。需求不变的情况下，文档目录和章节结构不应该三天两头调整，而细节里的参数、截图、路径，可能每次迭代都会变。

引用关系标准：框架层允许被其他章节引用，细节层不主动定义引用源。通俗点说，框架是目录级的约定，细节是条目级的描述。

这里我想特别强调一下，为什么以前“边想边写”会乱。因为我在这个过程中把框架决策和细节决策混在了一起。我一边在思考“这一节放什么章、那一节放什么小节”，一边还要琢磨“这个用例的预期结果到底要不要把返回值也写上”。两条决策线同时跑，又没有先后次序，写出来的文档自然是跳跃感的——一会儿在高空俯瞰，一会儿又钻进地缝里看石头，读者（包括两周后的我）自然容易迷路。

2.2 为什么选择“测试项目文档”作为验证场景

我选测试项目文档，不是因为它最好写，恰恰是因为它难写、信息密度大、关系复杂。一个典型的测试项目文档通常要包含以下内容：

• 项目背景与测试目标
• 测试范围（含不测试范围）
• 测试环境与数据要求
• 测试进度计划
• 测试用例设计（功能、性能、兼容性等）
• 缺陷记录与跟踪
• 测试结果与风险评估
• 结论与建议

这个结构里，“测试环境”和“测试用例”之间存在强引用（环境变了，用例里的某些前置条件就要改）；“缺陷记录”和“测试结果”之间也存在引用（缺陷的修复状态直接影响风险评估）；“测试范围”又反过来约束“测试用例”的书写粒度。这些引用关系如果不在框架层面提前定义清楚，写细节的时候就会不停返工。

另一个原因是验证成本低。写完之后我可以通过三个动作来验证这次“框架+细节”的改造效果：

• 实测：按新方式从零写一份小型测试项目文档，记录总耗时、章节调整次数、返工次数。
• 演算：在第二周（记忆淡忘期）重新打开文档做一次维护任务，测自己能多快定位到指定字段。
• 对比：用另一份旧文档（边写边做法）做同样的维护任务，记录时间差。

比较下来，这个场景能比较客观地反映“框架先行”到底值不值得，不只是停留在“感觉上更清晰”。

2.3 预期收益与风险预判

动手之前我列了两个预期收益和一个风险点。

预期收益一：书写效率前低后高。前期花时间搭框架，感觉上写起来变慢了，但真正填充细节时，因为每个章节的边界已经锁定，不用反复跳转思考，单位时间产出文字量和有效信息密度都会上升。

预期收益二：文档可维护性显著提高。框架即目录，目录里有语义，读者接到任务（比如“把性能测试这部分的数据更新一下”）时可以直奔对应章节，不用全文通读。

风险点：框架搭得过度，把大量时间耗在“规划章节”上，导致前期的成本太高，高到盖过了后期的收益。这个风险在做大型文档时尤其明显——框架规划本身会变成一件“无限可细化”的事，容易陷入为了完美框架而迟迟不动笔的陷阱。我这次之所以选一个中等体量的测试项目文档（大概10个章节、40个信息点），就是想验证在成本可控的前提下，“框架先行”的收益是否依然存在。

3. 从零搭建“框架+细节”测试项目文档的全过程

3.1 前置准备：列出信息点清单，而不是直接写章节

这一步可能是整套方法里最容易被跳过，但也最关键的。很多人理解的“框架先行”就是先画目录、再填内容，其实不对。直接画目录仍然是凭感觉，你还是可能漏掉关键信息。我在实际操作中采用的做法是：先别管结构，动手列出这份测试项目文档“必须包含哪些信息点”，注意，是信息点，不是章节名。

比如我这次列信息点时，随手写下了这些：

• 客户名称、项目名称、起止日期
• 被测系统的模块清单
• 需要测试的功能点
• 不需要测试的功能点及原因
• 测试环境硬件配置
• 测试环境软件版本
• 测试数据构造方式
• 账号与权限矩阵
• 用例编号规范
• 优先级定义（P0/P1/P2）
• 用例覆盖需求的方式（需求追踪矩阵）
• 缺陷的严重级别定义
• 缺陷的优先级别定义
• 性能测试通过标准
• 兼容性测试矩阵
• 测试里程碑
• 人力分工
• 风险清单及应对策略

这个过程我大概花了15分钟。列完之后，我做的下一件事是给这些信息点分组。分组依据很简单：哪些信息点“天然应该待在一起”？比如“硬件配置”“软件版本”“数据构造方式”都描述的是测试执行时的物质基础，那就归到一类；“优先级定义”“严重级别定义”“通过标准”都是在说“怎么判断结果”，那也归到另外一类。

分组完成，章节结构其实就自己浮现出来了。它不是你先想好“我要有5个章节”，再往每个章节里塞条目；它相反——是从信息点的聚拢关系逆向推导出章节的边界。这个顺序是框架能反映真实信息结构的关键。

3.2 框架定型：10个章节的测试项目文档模板

根据上面的信息点分组，我最终把结构定成了10个章节。下面是每个章节的用途和它承担的在框架层里的职责：

这个框架里有几个值得解释的设计决策：

• 缺陷管理规范独立成章，而不是把缺陷记录直接塞到执行结果里。原因是缺陷的“级别定义”属于频繁复用的约定，一旦写得晚，前面用例里的“优先级”就没法精确标注，容易出现“用例里写P1，但P1是什么在文档里找半天才看到”的窘境。
• “不测试范围”放在第3章，紧跟着测试范围，而不是放到附录。因为它虽然内容少，但对“边界感”极其重要，越靠前读者越早建立边界意识。
• 附录放在最后，承担所有“为了完整性而存在、但通篇读会打断节奏”的信息。

3.3 细节填充：从框架到血肉的执行规则

框架搭好了，接下来是最容易“破功”的阶段——填充细节时，人很容易又陷入“边写边发现结构有问题”的状态。我的应对方法是三条执行规则：

规则一：填充时锁定章节边界。一旦框架通过评审（哪怕是自我评审），写第5章用例设计时就不要再想“这个信息要不要提到第4章去”。如果确实发现有交叉，先记在“待调整清单”里，不要当场改框架。当场改会造成框架层面的反复震荡，是效率的大敌。

规则二：先写依赖方，后写被依赖方。例如第4章测试环境是第5章用例设计的前置依赖，那我先写第4章；第2章项目概述是全部章节的上下文锚点，所以从第2章先写起。也就是说，填充顺序并不完全等于章节序号，而是根据依赖关系排优先级。实际操作中，我的填充顺序是：2 → 3 → 4 → 5 → 6 → 1 → 7 → 8 → 9 → 10。第1章“文档信息”反而排得很后，因为修订记录要等大部分内容写完才知道要记录什么。

规则三：细节的书写粒度要有“最小封闭”意识。什么意思？就是当细节里涉及一个专有名词、一个参数、一个路径时，要么首次出现时就写清楚，要么明确标注“见第X章”，不要留下一个“待补充”状态在心里想“后面回来填”。后续回填这件事，十有八九会漏，漏了就是一颗定时炸弹。

下面我给出一个“第5章 用例设计”的局部示例，展示框架+细节方式下，细节应该长什么样。这个示例节选自一份Web管理系统的功能测试，用例编号TC-5-001。

TC-5-001 用户登录-正确账号密码校验 前置条件： - 环境：测试环境TEST-ENV-01（见4.1节） - 数据：存在账号 admin_lucy / 初始密码已重置为 Aa123456!（数据构造方式见4.3节） - 系统：登录页面可正常访问，浏览器为 Chrome 126.0 步骤： 1. 打开系统首页，跳转至登录页。 2. 输入正确账号 admin_lucy，密码 Aa123456!。 3. 点击“登录”按钮。 预期结果： - 登录成功，进入系统主页面，右上角显示当前用户“admin_lucy”。 - 地址栏出现 /dashboard 路径。 - 无任何红色错误提示。 优先级：P0 关联需求：REQ-LOGIN-001（需求追踪矩阵见5.0节）

这段细节没有什么惊人之处，但它体现了框架先行带来的一个好处：写到第3步时，我不需要停下来想“这个环境配置在哪写过了”。因为框架已经锁定了“环境信息属于4.1节，登录相关需求应该在5.0节有索引”，我只需要在细节里放一个引用标记即可。这个“引用”动作如果放到边写边做的文档方式里，往往会被省略，因为当时你会觉得“反正环境配置就在前两页，不标也行”——但文档一长、时间一久，缺少引用的细节就断了链。

3.4 框架视角下的“需求追踪矩阵”

“需求追踪矩阵”这个细节单独拿出来讲，因为它非常能体现“框架+细节”方法的威力和坑。

需求追踪矩阵是一张表，左侧是需求编号，右侧是用例编号。它的作用是回答审计时最常问的问题：“你的每个需求都被用例覆盖了吗？”。边写边做风格下的矩阵表，通常是在所有用例写完之后回头补的，这时候补矩阵你只能从头翻用例，一边翻一边心算“这个用例对应哪个需求”，非常痛苦，而且容易漏。

在框架+细节方式下，做法完全不同。我在框架层就预置了“关联需求”这个字段，规定每条用例都必须填写。矩阵表只是这个字段的聚合视图，在文档写完的最后一个小时，我只需要把所有用例的“关联需求”字段做一次提取、排序、去重，矩阵表自动生成。这一步从“翻阅全部用例”变成了“按字段筛选”，效率提升极其明显。

代价是，每条用例在写的时候都要多花5秒钟去核对需求编号。这5秒钟在写单条用例时显得烦琐，但放到整个项目维度，它是对后续审计检查的“均摊投资”。这也是我对“框架先行会不会降低写作效率”这一质疑的实际回答：它在某些局部的确更慢，但把生命周期拉长，快得不是一点半点。

坑在哪？坑在于我一开始做字段规划时，漏了“需求版本”这个信息。第一次跑矩阵时发现有两条用例关联的需求是旧版本里的编号，新版本需求文档里已经合并了。这就是典型的框架层设计不足暴露出的问题——当时我只规划了“关联需求编号”字段，没规划“需求版本号”。后来我在框架里加了一个全局字段：需求版本基线，并在附录里建了一张“需求文档版本变更对照表”。如果你也要做类似文档，这个版本字段建议一开始就加，别省。

4. 实操过程复盘：一次完整的“框架+细节”写作实录

4.1 准备阶段记录：信息收集与目标设定

我用一个实际项目做了全流程验证。项目是“内部工单管理系统的功能测试与验收测试”，规模不大，但信息完整，适合当作方法验证的载体。

正式动笔前我做了这么多准备：

• 收集需求文档一份（共12条功能需求，4条非功能需求）
• 确认测试环境：测试服务器IP（内网）、数据库版本（PostgreSQL 14.2）、应用版本（v2.1.3）
• 排定里程碑：功能测试3天，性能测试1天，回归测试2天
• 人力安排：2名测试工程师，1名开发支持

这一阶段我明确记录了两个核心目标：

目标一：用框架+细节方式生成一份“可直接执行”的测试项目文档。所谓可直接执行，就是测试工程师拿到文档后，不需要再问“这个环境的密码是什么”“这个用例的边界条件是什么”，直接能跑。

目标二：记录全部写作过程中的框架调整次数和返工次数，用于后期与旧方式做对比。

4.2 框架搭建实况：章节、引用、信息索引的落地

有了第3章的规划，实际操作时的框架层很快就落地了。具体来说，我做了三件事：

第一，建好10个章节的标题框架，并为每个章节写了3~5句“用途说明”。这相当于给未来的自己留的便签——下次我再打开这个模板，我知道每个章节的职责，不会再出现“这个信息不知道塞哪一章”的犹豫。

第二，定义跨章节引用规则。我统一用“见X.Y节”而非“见上文”或“见后面”。比如第5章用例设计里会引用第4章的4.1节（环境信息）和4.3节（测试数据构造），第8章结果统计里会引用第6章的6.2节（缺陷优先级定义）。引用规则在框架层先定好，细节填充时只需要遵守，不需要再临时发明。

第三，做了信息索引草案。这一步可能比较个人化——我习惯在框架初期就为每个章节列出预计包含的小节标题，形成“二级目录”。例如第5章的小节规划：

• 5.0 需求追踪矩阵（放在章首，作为阅读向导）
• 5.1 用例编写规则与优先级定义
• 5.2 功能测试用例
• 5.3 性能测试用例
• 5.4 兼容性测试用例

不要小看这个草案，它决定了后面写用例时是按功能模块分还是按用例类型分。我当时斟酌了一下：如果按功能模块分，读者查某模块的用例很方便；如果按用例类型分，执行时批量跑回归方便。最终我选择按用例类型分，因为执行阶段的批量操作频率远高于按模块阅读的频率。这就是框架层决策对细节层效率产生直接影响的一个例子。

4.3 填充细节实录：第2章项目概述和第5章用例设计的先后关系

如前面所说，我填充细节的次序是2 → 3 → 4 → 5 → 6 → 1 → 7 → 8 → 9 → 10，这个顺序的合理性在实操中体现得淋漓尽致。

写第2章项目概述的时候，我定义了全局术语表，把“工单”“审批流”“超时自动关闭”这几个词在本文档内的固定含义锁死。别小看这个动作，不锁定术语，第5章用例里每处都写“等待系统超时后自动关闭工单”和“工单超过48小时未处理自动关闭”可能是同一个意思，但表述不一致，读者会误以为两个场景都测。锁定后统一写成“工单超时自动关闭（定义见2.4节）”，一致性大大提高。

接下来写第3章测试范围。我重点写了“不测试范围”，包括“不测试移动端适配”“不测试第三方支付接口（由合作方自测）”。这两条在最初列信息点的时候并没有想到，是在框架层审视第2章项目概述时发现“本项目不涉及这两块，但不写清楚，测试新人可能会困惑为什么用例里没有这些场景”。由此可见，框架层不但能组织已有的信息点，还能促使你提前发现“缺失但重要的信息点”。

写第5章用例设计时，我已经有了第2章术语定义、第3章范围边界、第4章环境数据支撑，写起来感觉像是在既定的轨道上填坑，基本没有出现过“这个前置条件到底放第4章环境说明还是放第5章用例描述里”的摇摆。这次尝试前，这类摇摆几乎每次都会出现。

为了让你感受更真实，我再放一段第5章性能测试用例的实际内容：

TC-PERF-001 用户并发登录-峰值并发100用户 前置条件： - 环境：性能测试环境PERF-ENV-02（见4.1节） - 数据：已准备100个有效账号，密码统一为 Perf@123456 - 工具：JMeter 5.6.3，脚本路径见附录A.2 步骤： 1. 在JMeter中配置线程组：线程数100，Ramp-Up时间10秒，循环次数1。 2. 配置HTTP请求默认值：协议HTTP，服务器地址10.20.30.41，端口8080。 3. 添加聚合报告监听器。 4. 执行测试，记录响应时间分布、错误率。 预期结果： - 事务成功率 ≥ 99.5% - 平均响应时间 ≤ 2秒 - 95%响应时间 ≤ 3秒 - 无内存溢出或服务崩溃

这条用例在旧方式下，我大概率会在步骤里写“配置并发100用户”，但不会写Ramp-Up时间，也不会写具体的服务器地址。原因是当时我“默认读者跟我一样知道这些细节”。但实测告诉我，半个月后我自己去看这条用例，也需要回忆当时压测的配置。框架+细节的强制引用规则，其实是在对抗“知识诅咒”——你越懂一个系统，越容易忽略新手（包括未来的自己）需要的信息。

4.4 验证阶段：三个维度的实测数据

写完文档后，我做了一组对比验证。用同一测试项目的两份文档——A文档是旧方式（边想边写）生成的，B文档是新方式（框架+细节）生成的，从三个维度做对比。

维度一：初次编写耗时。A文档耗时约7小时，B文档耗时约8小时20分钟。B文档多出的时间几乎全部消耗在框架规划和引用关系设计上。

维度二：细节返工次数（指写完后才发现需要大改某个章节的次数）。A文档返工3次：一次因为环境信息写漏，一次因为用例编号规范前后不一致，一次因为覆盖范围与需求文档对不上。B文档返工0次，但有一次“引用修正”——在第5章中发现4.3节的测试数据构造方式描述不够详细，导致用例里引用它时补了一段说明，最后回流到4.3节做了扩展。

维度三：两周后维护成本。我模拟了三个维护任务：修改测试环境中数据库的版本号、增加一条登录异常用例、统计P0用例数量。A文档完成三个任务共用时约40分钟，其中“找到需要修改的位置”花了约25分钟；B文档三个任务共用时约18分钟，其中“定位”花了约7分钟。B文档在维护效率上的优势相当明显。

这个结果跟我预期基本一致：框架+细节的核心收益不在“写得更快”，而在“活得更好”——即文档在生命周期里的可维护性大幅提升。对测试项目文档这种需要频繁更新的产物来说，这个收益是决定性的。

5. 常见问题与排查技巧实录

5.1 框架层规划过度，卡在“完美主义”里出不来

这是我在尝试过程中第一个遇到的实际问题。搭框架阶段，我一度觉得自己可以把所有引用关系全部设计到完美再动笔，结果越规划越觉得哪里还能更优化——小节顺序能优化，字段命名能优化，连“每章节是否都要有术语表”这种问题都开始纠结。

排查下来，问题出在我把“框架”当成了“一次性的完美产物”。实际上框架是动态的，好的框架允许在填充过程中做微调。我的解决方法是设了一条边界：只在“出现信息归属错误”时调整框架，不因为“觉得能更好”而调整。前者是纠错，后者是优化。纠错要及时，优化要克制。

5.2 章节之间的信息孤岛，没有引用关系

有一次我在写第7章执行计划时，需要引用第5章用例设计里的P0用例数量，但当时第5章还没写完（因为我填充顺序是2→3→4→5→6→1→7，第7章在第5章之后写，理论上不会有问题，但实际操作中我跳着写了一段）。

问题来了：第7章里的“P0用例约60条”这个数字，如果直接写死，到第5章填充完实际可能只有52条，数字就不准。如果写“见5.2节”，引用关系是建立了，但第7章当时阅读时看到的不是一个数字，而是一个指向性描述，不够直观。

我的支架方案是：在框架层定义“数据引用字段”，当某处数字可能随其他章节变化时，先写“见X.Y节”，并在这个位置打一个“待更新”标记（用文档批注对话框的黄色高亮提醒）。等第5章写完，我一次性根据第5章的实际数字更新第7章的引用描述。实际操作中，我反过来先提高了引用率，对整个文档而言，这个数据引用的最终一致性比局部直观更重要。

5.3 “框架+细节”在多人协作时遇到的同步问题

我自己单机写文档没有问题，但如果你在一个小团队里用这种方法，会遇到另一个坑：不同人的“框架感”不一样。有人觉得“测试范围”应该包括测试数据定义，有人觉得测试数据必须放“测试环境”里，争起来没完。

我的建议是：框架层由文档Owner一人定稿，细节层允许协作者自由发挥。框架是公共约定，不能一家人两套字典；细节是个人创作，鼓励大家按自己的表达习惯写。在实际项目里，这相当于给文档Owner一个更高的设计权重，也避免协作变成漫长的辩论赛。如果你对这种协作方式感兴趣，可以再进一步把框架层的章节职责描述放在团队Wiki里，让所有人都能一眼看到“哪些信息放哪里”，即使不是文档Owner也能自我对齐。

5.4 常见问题速查表

5.5 一个关于“细节粒度”的个人判断技巧

这是我自己在多次写作中总结出来的判断标准，分享出来供参考。当你拿不准某个细节要不要写进文档时，问自己一个问题：“如果读者不知道这个信息，能否完成任务？”如果答案是否定的，那这个信息必须写。如果答案是“可能能完成，但多花一点时间”，那看你的文档定位——参考手册类，写；速查类，可以不写。

还有一个更省力气的经验：凡是你在测试过程中曾经因为缺信息而中断过一次的事，这个信息就应该被写进文档。比如你今天执行用例时发现“数据库连接串原来在配置中心里，不在环境说明里”，你走了弯路才找到——这意味着文档缺信息。别只把这句话记在自己脑子里，直接打开文档，把这条信息补到对应章节。这个习惯能非常有效地让文档随着实际执行变得越来越完整，而不是越写越像空中楼阁。

6. 这次尝试带来的经验总结

6.1 框架+细节对测试项目文档的适配性分析

做了完整闭环的验证之后，我对“框架+细节”在测试项目文档上的适配性有一个比较明确的结论：非常适合。测试项目文档信息点之间天然存在依赖关系、版本关系和引用关系，而框架先行的方法就是让你在动笔前把所有关系画成“目录层面的图谱”，避免细节填充过程中的关系混乱。

但我也要说清楚：这个方法不是万能药。它对于一次性使用、阅后即焚类型的文档（比如临时备忘、会议记录）来说，成本太高，完全没必要。它的最佳应用区间，是那些会被反复阅读、频繁更新、多人协作的资产型文档。

6.2 模板复用与持续迭代

我把这次搭出来的10章节框架整理成了一个通用模板，保存在自己的模板库里。每次新建测试项目文档时，直接在模板上复用，按项目特性增删章节。复用了几次后，我的体验是：框架模板才是这份文档真正的生产力沉淀，第一次搭框架花掉的时间，会在第二次、第三次使用时被大幅度摊薄。

模板的迭代也很重要。每次项目结束后，我会花大约10分钟反思：这次项目有没有“某个信息的归属让我犹豫过”？如果有，说明框架层的边界还需要优化。这种迭代不要太频繁，一个项目周期一次，保持稳定。

6.3 如果重新来一次，我会改掉什么

如果有下一次尝试，我会在三件事上直接改变做法。

第一，我会在准备阶段就把“需求版本基线”和“需求变更记录”两个信息点加进去，而不是等到跑需求追踪矩阵时才暴露问题。

第二，我会把框架搭建的时间再砍掉20%。当前版本的时间盒是“总工时的15%”，实际执行下来框架规划时间约占18%，其实可以再压缩到12%左右。因为这次经验告诉我，框架不需要一次到位，只要框架层稳定，后续微调的成本是可控的。

第三，我会更早建立全文的“术语表”。这次是在第2章才建的，但实际第1章文档信息里就出现了“验收测试”和“冒烟测试”两个术语。虽然不影响阅读，但如果正式发布，术语表应该放在文档的第2章开头，先于所有使用术语的章节。

整体来说，这次从“边想边写”到“框架+细节”的尝试，对我个人最大的改变，不是文档结构变好看了，而是我在动笔之前的思考权重变高了。过去我的大部分精力花在“怎么写”上，现在更多精力花在“信息应该放在哪里、跟其他信息是什么关系”上。这个转变让文档变好的同时，也让写文档这件事变得不那么累了——听起来像是悖论，但如果你试一次就会明白：当每个信息点都有它的天然位置的时候，写作就变成了填空，而填空的难度，远低于在迷雾中硬造一条路出来。