代码库审计
审计的价值在于排名和证据，而非长度。没有文件路径、查询结果、PR编号或行数的发现是假设——将其标记为假设。
将审计立足于代码和生产，而非文档
项目笔记、计划和状态文档是检查点，而非权威。从它们入手来了解声称的内容，然后对照现实进行验证：当前提交、数据库状态、PR检查、分支头部。
当文档与代码不一致时，这种不一致本身就是一条发现——通常是审计中最有价值的一条。
关于生产的声明需要进行针对生产的查询。将此技能与验证门技能结合以完成具体操作。
结构
# <范围> 审计 (YYYY-MM-DD)
## 概要
<最重要的三件事，以及你会首先做什么。>
## 第一部分——你没看到的东西（盲点，按排名）
## 第二部分——缺失的能力（按排名，每个附有粗略的工作量估算）
## 第三部分——需要改进的现有能力（按排名）
## 第四部分——架构变更（按排名，用通俗语言描述）
## 第五部分——如果我来掌控接下来的30天
## 验证清单（审计过程中发现的差异）
**对所有内容进行排名。**一个未排名的40条发现列表就是40条无法行动的发现。
在估算前检查是否存在休眠脚手架
为每个缺口附上粗略的工作量估算，并说明使其低成本或高成本的原因。
最有价值的审计发现通常是这个：**大多数高价值的“缺口”只需要几天的工作量，而非数周，因为脚手架已存在于仓库中，只是没有调用者。**一个已完成了80%的功能与一个完全没有开发的功能，决策完全不同。
在声明某物缺失之前，先 grep 查找。零调用者的函数是典型情况——代码存在，但没有任何调用，而所有状态文档都描述该功能为缺失。
验证清单
每次审计都以无法解决的差异结尾。每个条目包括：
- 声称的内容
- 观察到的内容
- 哪种查询或检查可以解决它
**这是后续会话真正会使用的部分。**即使内容很短，也请务必写出。
明确表示不值得做的部分
说明你检查过并有意拒绝的内容，附上原因。
只会在待办清单上增加内容的审计会让待办清单变得无用。一个你查看过并驳回的发现比一个你从未提及的发现更有价值，因为它能阻止下一次审计再次提出相同问题。
保留项不是缺口
任何已明确标记为有意推迟、或等候人为决策的内容，都是有目的地保留的。不要将其列为缺口。
将一个有意保留项作为发现重新提出，会导致保留的决策被意外执行。
输出
将审计结果写在项目保存审计的地方。如果它取代了之前的审计，需说明哪个审计被取代以及什么发生了变化——审计文件夹应保持按顺序可读，而非堆积。