打开一份新的技术文档就像抵达一个陌生的城市。里面有街道、建筑和各种规则，但你没有地图。你该从哪里开始？直接冲向最显眼的摩天大楼，还是先找到制高点俯瞰全貌？

优秀的工程师在阅读技术规范时，会像侦探一样系统地分析线索。他们不会逐字逐句地线性阅读，然后期望能理解一切。相反，他们采用一种结构化的方法，确保既能看到森林，也能看清树木。这种方法的核心是“两遍扫描法”。

你的首要任务是理解文档的宏观结构和意图，而不是陷入细节的泥潭。在第一遍扫描中，你要像一个城市规划师，快速飞过整个区域，识别出主干道、关键区域和总体布局。你需要回答几个高层次的问题：

• 这份文档的核心目标是什么？ 它想解决什么问题，或者构建什么系统？寻找摘要、目标或背景介绍部分。
• 逻辑流向是怎样的？ 信息是如何组织的？是否存在从问题到解决方案的清晰路径？注意标题和章节顺序。
• 隐含的假设和约束是什么？ 作者认为哪些是你已经知道的？项目有哪些预算、时间或技术栈的限制？

在这一阶段，你要重点区分两种核心需求：功能性需求和非功能性需求。功能性需求描述了系统应该做什么，比如“用户能够上传个人头像”。它们是具体的功能点，是产品的核心特性。

非功能性需求则描述了系统应该如何表现，比如“页面加载速度必须在3秒以内”或“系统必须能同时处理1000个并发请求”。它们是系统的质量属性，如性能、安全性、可靠性。在第一遍扫描中，识别出这两类需求，可以帮助你建立对项目全貌的初步理解。

现在，你的地图已经画好，是时候深入城市的每个街区了。第二遍扫描是技术性的深潜。你的目标是验证细节、检查一致性并提出疑问。你需要戴上侦探的放大镜，仔细审视每一个“线索”：

• 术语一致吗？ 文档中是否将同一个概念称为“用户”、“客户”和“参与者”？术语不一致是逻辑混乱的危险信号。
• 流程完整吗？ 用户旅程或数据流中是否存在断点？例如，文档描述了用户如何注册，但提到了如何找回密码吗？
• 指令清晰吗？ 如果文档描述了一个API端点，它的请求参数、返回格式和错误代码都定义清楚了吗？

在这一阶段，采用[{<架构决策记录>]}(ADR)的思维模式尤其有用。ADR是一种记录重要架构决策及其背后原因的简单文档。虽然你不是在写ADR，但你可以用它的核心思想来审视文档：不仅仅关注“是什么”，更要追问“为什么”。

通过这种方式提问，你可以揭示文档中未明说的技术权衡和深层逻辑。这能帮助你发现潜在的设计缺陷，或者更好地理解现有设计的合理性。一个好的技术文档不仅会告诉你“我们这么做”，还会解释“我们为什么这么做”。如果解释缺失，你就需要主动去寻找答案。

通过这两遍扫描，一份原本复杂、令人望而生畏的技术文档，就变成了一张清晰的地图，指导你接下来的开发和协作工作。这不仅节省了时间，更重要的是，它从一开始就保证了你和团队在正确的轨道上前进。