方法
接受修订前，先看清 diff 里改了什么
diff 只回答“文本哪里变了”，不回答“内容是否更容易被看到”。接受修订前，逐行核对改动是否对应需求，并记录你的判断。
接受修订前，diff 里只看一件事：和上一版相比改了什么，这些改动是否对应需求。diff 是修改检查，不是可见度测量。它不说明内容在搜索引擎里有多显眼，只说明哪些行被动了。同事提交页面修改时，打开 diff，先读删除的行，再读新增的行，逐行问自己：这一行对应哪条明确指令？如果某行改了，却找不到需求里的依据，先讨论，再决定是否接受。
diff 为什么不是可见度测量
做内容的人容易把两种检查混在一起。diff 回答的是“文本哪里变了”；可见度回答的是“搜索的人看到这段文本时是什么样”。这是两个独立观察，不能互相替代。AI 可见度怎么测，也属于第二种检查，读 diff 读不出来。RankAI 把这两层分开，因为混在一起，就容易凭印象接受修改，而不是靠核对。
RankAI 提出的操作清单
下面是 RankAI 的操作建议，不是通用标准，目的是让 diff 检查可以重复。每一步都有可验证的标准，决定不靠个人口味。
- 先读删除的行，再读新增的行。标准：每一条删除，你都要能指出需求里哪句话支持它。找不到，就说明超出范围，要标出来。
- 确认每处新增都能在需求里找到依据。标准：新增行不得引入需求没有提到的说法、数字或名称。出现未要求的数据，要么删掉，要么明确说明理由。
- 检查标题、开头和正文是否一致。标准：修改不能改变开头相对标题的含义。标题承诺一件事，新文本却说另一件事，即使每一行单看都没错，整个 diff 也不一致。
- 把非文本改动单独隔开。标准：空格、格式和换行要和内容改动分开看。diff 里视觉噪音太多，会盖住真正的改动，读之前先清理。
- 记录决定。标准：接受之后，对每个改动块，你都要能说出它是被接受、拒绝还是推迟。重建不出这张图，检查就没有结束。
常被忽略的一点是：diff 不是质量文件，它是差异的快照。一处修改可以技术上很干净，只动了几行，格式也没错，但相对编辑目标却是错的。所以我们的建议把两个判断分开：读 diff 是机械的，可以逐行验证；评估内容则要了解需求和页面背景。只看绿色或红色就接受修订，等于跳过第一个判断，假装做了第二个。读得好的 diff 会留下痕迹：你知道哪些行变了、为什么变、你做了什么决定。让修订可接受的，是这种可追溯性，不是“我全读过了”的感觉。缺了它，继续之前要重新打开修订。
一个要记住的边界
diff 只显示两个版本之间变了什么：它不说修改是否让页面对读者更好，也不说文本会不会出现在某个引擎里。那些问题需要别的检查，要分开问。没有可见度数据时，我们显示 N/A，不会写成零：数据缺失不是负面数据。diff 也一样：需求里没有某一行，不等于可以替它编一个理由。
想了解 RankAI 怎么分开处理这些检查，见深入说明页。