先保留功能描述原句
读到神圣计划软件某项功能时，先记录原句和出处，不急着改成自己的结论。原句可以揭示作者究竟承诺了什么，也能避免转述时无意扩大范围。比如“可整理记录”与“自动整理所有格式记录”就不是同一项承诺。
接着划出需要解释的词：什么叫自动、处理哪些对象、支持范围多大、什么时候触发。若材料没有定义，应标为待确认，而不是根据常见软件的习惯补全。功能名称相同，也可能对应完全不同的实现条件。
把功能拆成输入与输出
一个具体问题最好包括输入、动作和输出。例如讨论“导出”时，需要知道输入是什么记录，输出是什么格式，字段是否完整，以及是否保留时间信息。这里是核对方法，不代表已经确认目标产品具有导出能力。
假设资料只展示一份表格文件，最多能说明作者展示过这种结果。要进一步确认生成过程，应有对应操作说明或完整演示；如果文件来自其他工具，就不能将结果直接归功于被讨论的软件。
分清三种证据状态
页面自述证明作者提出了某项说法；演示证明某个示例过程被展示；实际验证则需要记录自己的环境、输入和结果。三者都可以有价值，但不能在写作中相互替换，尤其不要把看到一张结果图写成“本人已经验证”。
记录卡可使用“材料称”“演示可见”“在某条件下观察到”三种表述。若没有操作过软件，只需要诚实写清依据属于前两类，这并不妨碍分析资料的完整程度，也能让读者知道下一步还缺什么。
验证范围比一句成功更重要
即便某项操作在一个样本上完成，也需要说明样本规模、设备条件和结果检查方式。小文件正常不能推出大文件同样正常，一次连接成功也不能证明长时间服务状态。结论应和测试覆盖范围保持一致。
例如一份假设记录写“用十条演示数据生成文件，核对十条均存在”，比“导出稳定可靠”更有判断价值。若发现字段缺失，还要保留原始文件与检查规则，避免只留下一个无法复核的评价。
用对照表支持后续阅读
对照表可以设为功能原句、适用条件、已有材料、验证状态和未覆盖项五栏。每次得到新资料，只更新对应一格；发现宣传范围与示例范围不同，就把差异单独列出，而不是强行合并成肯定结论。
最后优先回答当前真正需要的功能问题，不必为了让介绍看起来全面而罗列未经证实的能力。具体、有限且能回到证据的说明，往往比一长串形容词更能帮助读者理解这款软件的资料现状。
- 把“支持某格式”拆成能够读取、能够处理和能够输出三个问题，检查资料究竟覆盖哪一项。
- 把“自动”后面的触发条件写出来，区分需要人工发起与无需人工确认的含义。
- 把观察结果与预期结果并列保存，差异本身就是后续核验需要补充的材料。