开源项目的 README 里常有一张和同类工具的对比表。表很好读也最好误导。它通常是项目自己填的列的是它想强调的维度打勾标准也是它自己定的。没有测试方法、没有版本、没有日期的格子只能叫自述不能叫评测。读表时先做三步。第一步看缺了什么列。只比较有没有私有化不比较权限模型、审计日志和失败恢复表就会偏向把私有化当成优点的项目。第二步看同一行里它承认的短板。只引用绿格子、不引用红格子结论就已经被剪过。第三步把每个格子改写成可验证的句子。例如支持代码补全应变成在某个编辑器的某个版本里对某种语言有补全。改写不了的格子就不要拿去选型。还要看表的日期和对象。对比对象如果没有写版本今天的产品可能已经加上或去掉那项能力。表若只放在营销页、不放进会随版本更新的文档就更容易过期。读的时候把表头抄下来旁边加一列核实日期和证据链接。没有证据的格子保持未知不要为了填满表格而沿用原作者的勾。可以把格子分成三类再决定下一步。第一类能在文档或命令输出里复核例如有没有本地命令行、许可证是什么。第二类需要自己搭环境例如私有化部署是否真能离线完成构建。第三类没有定义例如团队协作好。前两类可以进核实清单第三类应退回给作者补定义不能直接计分。计分表如果把这三类加总排名就没有意义。MonkeyCode 的 README 对比表可以当练习材料。项目自述里它有需求与 SPEC 管理、云端开发环境、团队协作和私有化部署同时标明没有本地 IDE、没有本地 CLI、没有代码补全。只用前半句介绍它会把它说成全面领先把后半句一起读才知道它不覆盖本地补全。表里的其他产品格子同样是这家项目的填写不是那些产品自己的测试报告。所以对比表的正确用法是生成待核实清单而不是直接生成采购结论。把要核实的格子写成问题再去文档、发行说明或自己的环境里对。对不上的就保持未知。星标数和截图也不能补上这个缺口。2026-10-10 查阅该仓库时约 4.8k star这个数字会变也不能代替上面的核对。核实清单可以按周更新而不是每次选型都重读整张表。已经复核过的格子写下日期和证据过期的再打开。这样对比表从宣传材料变成工作列表。工作列表上的未知项不能在汇报里写成已支持或已不支持。如果必须转发这张表带上它是项目自述、不是第三方评测这一句。去掉这句读者会把格子当成测试结果。未知就是未知不要为了表格完整而沿用原作者的勾。没有证据的格子保持空白比填一个过期的勾更有用。