起因：sitemap 看起来简单，真正落地并不简单
起因很直接：公司的 SEO 需求里，sitemap.xml 需要真正落地。
表面上它只是一个 XML 文件，实际上它可能包含很多隐藏风险：
- 格式不合法，搜索引擎无法正确解析
urlset、sitemapindex、RSS、Atom 混用后出现兼容问题- 某些 URL 返回 3xx、4xx、5xx，导致可收录性下降
- 大型站点需要递归检查 sitemap index，手工验证成本很高
- 一旦验证中断，重新跑一遍既浪费时间，也不利于排查问题
我想要的是一个更实用的工具：不仅能检查 sitemap 协议合规性，还能继续验证 URL 可达性，并且支持中断后恢复。更重要的是，我希望它不是一个只能单独跑的脚本，而是一个可以同时服务两类场景的产品：
- 工程项目：作为二方包依赖，被接入到具体业务代码和发布流程里
- Agent 工作流：作为 CLI 工具，直接提供给 coding agent 调用
于是就有了这个项目：
- GitHub: zegging/sitemap-verify
这个项目是什么
sitemap-verify 是一个基于 Python 3.10+ 的工具和库，用来验证 sitemap 协议合规性，并检查发现 URL 的可达性。
它同时提供两种使用方式：
- Async Library API：
validate_target(...) - CLI：
sitemap-verify check <target>
我比较在意的是，它不是一个只会“扫一下 XML”的小脚本，而是一个能真正用于日常工作流的验证工具。
它支持的能力
- 支持 XML
urlset - 支持
sitemapindex - 支持 text sitemap
- 支持 RSS、支持 Atom
- 结合协议语义验证检查细节问题
- 递归遍历 sitemap index，并提供深度和数量保护
- 对发现的 URL 做可达性检测
- 用 SEO 视角定义严重级别
- 通过 SQLite 持久化
- 支持断点恢复
为什么选择 Codex
这次项目最特别的地方是：它是完全由 Codex 创建的。
我自己主要做的事情，严格来说是两类：
- 写需求说明
- 维护实现 markdown 文档
也就是说，我没有亲自把每个模块一行行写出来，而是把目标、约束、行为边界和验收方式描述清楚，让 Codex 去把它落到代码里。
这次体验最直观的感受是在功能明确、结构清晰、能够进行端到端测试的场景下，Coding Agent 的开发效率和准确率是非常惊人的。核心功能在半小时之内就完全搭建完成了，剩下新功能的增加在项目资料维护的很好的情况下异常的顺利，不论是 Sqlite、断点恢复、Github 构建和发布，没有什么特别的坑，以致于一些看过的 Vibe Coding 奇技淫巧完全没有机会施展。
- 先把需求收紧
- 输入可以是本地文件、远程 URL、domain
- 输出要适合人工查看，也要适合机器消费
- 验证不能只停留在 XML 语法层面，还要包含协议和可达性
- 长任务必须支持恢复
- 再拆成可执行模块
- 解析 sitemap 输入
- 做协议与结构校验
- 对 URL 做 reachability probe
- 把运行状态写入 SQLite
- 提供 CLI 参数和输出格式
- 用测试锁定行为
- 解析不同 sitemap 类型
- 检查错误输入
- 递归深度和数量限制
- HTTP 状态码的严重级别映射
- SQLite 存储与恢复流程
Coding Agent 开发不是“少思考”，而是“把思考前置”
- 实际上，真正省时间的地方是我把约束、目标和边界提前整理好了，后续迭代才不会反复返工。
- 文档本身就是交付的一部分
一个最小示例
python -m pip install --index-url https://pypi.org/simple sitemap-verify
python -m sitemap_verify.cli check https://www.coohom.com/sitemap-news-category.xml --mode url --format json --probe-method get --output result.json 3 --log-file log_ --show-progress --verbose --timeout 200当需求边界清晰、验证标准明确时，Coding Agent 可以把一个真实项目从想法推进到可用状态，而且速度非常快。 如果你也在考虑把某个重复、繁琐、但规则明确的工程任务交给 agent，这类项目会是一个很好的起点。