方法
草稿与提纲：逐条核对每个回答是否到位
把提纲和草稿并排放在一起，为每个问题填一行：问题、草稿中对应的位置、结果。找不到具体位置就写缺失，不写“差不多”。
把提纲和草稿并排放在一起，为每个问题填一行：问题、草稿中对应的位置、结果。找不到具体位置，结果就写缺失，不写“差不多”。如果你要找的是“怎么测量AI可见度”，那是另一件事；这里做的是发布前对文本本身的检查。核对只看草稿里写了什么，不看某个引擎会怎么返回它。
方法：RankAI 提出的一种操作方式
这张表不是通用标准，只是一种工作方式：一行一行地让“草稿在哪里回答了、哪里没回答”变得可见。三种结果就够了：有，指存在一个直接回答该问题的位置；部分，指该位置触及了问题，但有一部分没有覆盖；缺失，指找不到任何可以指出的位置。部分和缺失的区别最有用：部分可以改，缺失需要写。
两行填好的例子
问题：“怎么核对草稿是否回答了提纲里的问题？”——对应位置：描述“问题／位置／结果”表格的那一段——结果：有。
问题：“如果某项可见度数据不可用，会怎样？”——对应位置：说明产品显示 N/A 的那句话——结果：部分，因为这个位置提到了这种情况，但没有把它和草稿核对联系起来。
为什么结果不能和测量混为一谈
这张表说明的是文本有没有回答，不是它将来会有多少可见度。要找“怎么测量AI可见度”的人需要知道，那是另一个问题，这里不处理。有一点值得记住：通过 API 从引擎返回的是 API 的回答，不是一个人在界面上看到的画面。所以对草稿的核对始终是对文本的检查，不是某个人将会看到什么的预览。
这篇文章的贡献是把三种结果的表格用在草稿上，并给出一条填写规则：任何一行都不能空着，任何结果都不能写“待看”。找不到对应位置，就写缺失，然后进入下一行；修改放在之后，不在填写过程中做。这样可以避免两个常见错误：只因为话题被提到就标成有；只因为答案分散在几处就标成缺失。后一种情况要把所有位置都指出来，结果保持部分，直到补上一个能收口的位置。表格只填一次，在发布之前，之后留作核对过什么的记录。
需要记住的边界
这张表核对的是草稿，不是引擎的回答：通过 API 返回的是 API 的回答，不是一个人在界面上看到的画面，这个检查填不上这段距离。关于我们看到的内容和用户看到的内容之间的分界，可以参考深入说明页，那里正是从 API 回答与界面画面的差别出发来描述这个边界的。另外，没有可见度数据时，产品显示为 N/A，不会把它写成零。