一个关于ai总结何时需要更新的想法

[cyb233]

添加相应过滤器条件，根据README.md是否被修改，可以由用户筛选并考虑是否需要更新这些ai总结，因为README变动可能意味着项目功能增加等情况，先前的总结可能不够完善

用户星标仓库总量较多是常见现象，需要考虑速率限制，可以考虑获取star时根据pushed_at时间是否更新初步筛选，或者考虑从REST API更换为使用GraphQL API？

[AmintaCCCP]

感谢 @cyb233 的建议！这个想法非常务实，我仔细分析了一下，和你探讨几点：

可行性

这个功能的数据基础已经完备——pushed_at 和 analyzed_at 两个字段在全栈（TypeScript 类型、SQLite schema、API 路由、UI 展示）中都已完整追踪，但目前没有任何代码将它们做比较。实现核心功能只需添加比较逻辑，零数据模型改动。

关于 README 变化检测

你提到的「检查 README.md 是否被修改」是关键点，但这里有一个精度问题需要权衡：

pushed_at 反映的是任意文件的最近推送时间，不是 README 的修改时间。一个仓库可能频繁提交代码但 README 从未改动，此时 AI 总结无需更新。纯粹用 pushed_at 会产生大量误报。

建议采用分层策略：

1. 第一层（零成本）：pushed_at <= analyzed_at → 跳过（确定未变化）
2. 第二层（低成本）：pushed_at > analyzed_at → 检查 README 的 SHA 或 git log 中 README 的最后修改时间
3. 第三层（高成本）：README 确实变了 → 拉取内容并重新分析

关于 GraphQL 迁移

你提到的 GraphQL 建议很有远见。当前 REST API 在逐仓库检查时确实消耗大量 rate limit。GraphQL 的优势在于可以用单次请求查询多个仓库的 README 信息（比如 SHA），显著减少 API 调用次数。

不过迁移成本不小——当前 githubApi.ts 全部是 REST 风格，需要重写认证、错误处理、速率限制追踪等。建议作为长期优化目标，短期先用 REST + SHA 检查的方式实现。

关于 README 变化 ≠ 需要更新总结

有些 README 变化只是修了个 typo、换了 badge、改了 license 说明，不影响核心内容。可以考虑：

• 设置 README 变化阈值（diff 超过一定字符数才触发）
• 或者直接让用户决定（UI 上显示「检测到 README 变化，是否重新分析？」）

实施优先级建议

优先级	任务	工作量
P0	比较 pushed_at 和 analyzed_at，标记过时仓库	小
P1	UI 展示「总结过时」标记 + 筛选器	中
P1	批量「重新分析过时总结」操作	小
P2	README SHA 精确检测（减少误报）	中
P3	GraphQL API 迁移	大

大家怎么看这个分层策略？特别是 README 变化检测的精度问题，是用 SHA 比对还是直接让用户决定更好？