我一直担心自己的自述文件与代码仓库不一致。因此，我开发了“自述文件线索”工具。

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

我编写了大量的自述文件（README）。我的代码发布速度快于文档更新速度。我与能在几秒钟内编写代码、在几分钟内生成自述文件的人工智能代理协作，而在首次提交与第三次重构之间的某个时刻，我在周二编写的自述文件就不再与我在周五编写的代码相匹配了。

安装命令显示为 npm start。而 package.json 文件中定义的是 start:prod。任何复制该命令的人都会立即失败，而我却无从得知。

这个周末，为了参加 Replit 十周年构建马拉松，我构建了 README Clew —— 一款用于审计你自己的 GitHub 仓库的工具，它能检查你的自述文件声称的内容与实际代码功能之间是否存在偏差。

仅提供发现结果。不重写内容。不进行评分。不保存任何数据。

README Clew 已部署 立即试用 →
GitHub 仓库 GitHub →

工作原理

粘贴一个公开的 GitHub 仓库 URL。README Clew 将：

1. 获取你的自述文件、package.json 文件以及部分文件树结构
2. 使用 Claude Sonnet 4.5 从自述文件中提取所有可核查的声明
3. 针对实际代码运行五个确定性验证器
4. 将发现结果分为四类返回

我检查的五个类别：

• 声明的依赖项 —— 你的自述文件是否声称“使用 X”，但 X 并未出现在 package.json 中？
• 代码与包覆盖范围对比 —— 你的代码是否导入了自述文件中从未提及的包？
• 安装和运行命令 —— npm start 是否确实作为一个脚本存在？
• 环境变量 —— 你的代码是否读取了自述文件中遗漏记录的环境变量？
• 文件和链接引用 —— 自述文件中指向的文件和 URL 是否真的能正确解析？

按显示顺序排列的四个类别：

• 已验证 —— 自述文件与代码一致（有据可查）
• 无法验证 —— 诸如“极速”或“85 个测试通过”之类的声明，虽然有效但无法通过静态方式检查（诚实的局限）
• 缺失 —— 代码执行了自述文件从未提及的操作（存在的缺口）
• 矛盾 —— 自述文件与代码不一致（存在的偏差）

功能特性

(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jprc7a5ffhpjdr4h4w1f.png)

我发布的功能超出了原计划：

• 深层链接 URL —— 每次扫描都有一个可共享的 ?repo= 查询参数。将其粘贴到任何地方，加载时即可运行扫描。
• 开放图谱卡片 —— 当你在社交媒体上分享扫描链接时，预览卡片会包含各类别的计数和综合摘要行。卡片本身即总结了审计结果。
• SVG 状态徽章 —— /api/badge?owner=...&repo=... 返回一个 SVG 图像，你可以将其粘贴到任何自述文件中。这类似于持续集成状态徽章，但用于体现文档的诚实度。
• 内存缓存 —— 最近的 50 次扫描结果被缓存，无需重新扫描即可快速生成开放图谱卡片和徽章。
• 复制链接 —— 一键复制当前扫描的 URL。
• 随处分享 —— 结果页面提供直接分享到 X、领英、Instagram 和 Dev.to 的按钮。
• JSON 导出 —— 以 JSON 格式导出完整扫描结果，便于自动化处理、归档或接入你自己的工具链。