终于吃上细粮了：Claude Sonnet 5.5 重构网站核心数据实录

Claude Sonnet 5.5 模型详情

Jumohub 这个网站，两大主力分别是：GLM-5.3 flash（前期，智谱半夜大放送）、Space Bunny（我已写过几篇文章）。前前后后使用过不下 20 个模型，也用过 GPT-6.1 Sol，用下来感觉还是 GLM 和 Bunny 顺手。

这几天尝试 Claude 的 Haiku 5.5，感觉还行，用得少没特别体会，渐渐地想用贵点的模型。

找啊找啊，终于找到了 Kiro 家，一看有 Claude 的可以试用，立马注册了，然后看了半天网站的升级计划，发现付款金额居然是 0！！！

这种机会对于我来说怎么能错过，于是马上订阅，1000 个 credits 到手，到月底结束。

那么接下来的事只有一个，在项目中使用 Claude Sonnet 5.5 对核心数据管线进行了一次大规模重构，也是一次实测点评，正所谓一箭三雕：薅羊毛，重构项目，实测点评。

一、从两个问题开始

Jumohub 运行一段时间后，逐渐暴露出两个问题。

一是模型库的基础资料不够完整。部分模型缺少关键参数，价格信息也存在偏差，不同渠道获取的数据经常不一致。

二是数据采集流程不够完善。部分数据仍依赖人工处理，自动化程度不足，维护成本较高。

我最初只是让 Sonnet 5.5 审查项目，分析问题并提出解决方案。

它没有立即修改代码，而是先把项目文档、现有代码和数据处理流程过了一遍，一口气连调了十几个工具。检查完，它把问题摊在桌面上：一部分采集任务没有完全自动化；不同渠道采集的模型资料可能互相冲突；还有些早期任务已经没什么实际价值，却仍然参与每日运行。

然后它把关键决策整理成几个选择题交给我。例如：已有数据与新采集数据冲突时，是只补缺失字段，还是多方对比后生成差异报告？评测数据是先接入自动抓取，还是先留着？每道题都给了选项，由我决定采用哪一种。

这一点很重要：它没有急于动手，而是先把问题和边界理清楚。

二、重构不是推倒重来

确定方案后，我要求它创建独立分支，把不同的采集任务拆开，先完成数据获取和分析，暂时不要触碰后续的评分逻辑。

Sonnet 按照这个方向调整了代码结构，将原本耦合的任务拆成独立模块。

过程中有两次必要的干预。

第一次是采集范围。最初采回来的数据范围太大，混入了大量网站根本不需要的内容。我要求它只处理系统已经收录的厂商和模型，避免无意义的数据堆积。它随即调整了采集逻辑，并补了一套离线测试——断网也能跑的那种，专门检查过滤规则和数据补全流程是否正常。

第二次是数据合并。我不希望它看到两个不同的价格，就自行判断哪个正确，于是要求：所有冲突数据必须保留差异记录，不能擅自修改已经核对过的基础资料。

两次调整之后，采集流程才基本符合预期。这里有一个明显的特点：Sonnet 能够较好地执行边界约束，但边界仍然需要人来定。如果最初不限制采集范围，它完全可能把一堆没有实际用途的数据也认真处理完。

整个重构没有出现为了重构而重构的情况，基本保持了原有项目的设计方向。

三、最重要的是保护已有数据

这次重构有一条明确要求：

已经人工核对的数据不能随意覆盖，新数据只用于补充缺失字段。

不同来源的数据发生冲突时，系统应该记录差异，等待进一步确认，而不是擅自选择一个结果写入数据库。

Sonnet 按照这一原则完成了数据处理逻辑，并把待复核清单整理得清清楚楚：原有数据与抓取值不一致的、多方来源冲突的、可以直接补的缺失项，各归一类。我按清单逐组喂给它人工核实的真值：有上下文长度，有输入、输出价格，还有类似「离峰输入 $0.15、高峰输入 $0.30 每百万 token」这种分时段计费。

Sonnet 拿这些信息更新基础资料后并没有就此停手：它重新运行了相关构建，确认派生的网页用的也是更新后的数据，最后列出了这次改动的具体范围，交给我确认。

这部分工作并不复杂，但非常考验 Agent 的执行纪律。

因为对数据类网站来说，错误数据被自动化流程反复传播，往往比缺少数据更加危险。

四、清理历史遗留问题

重构过程中，Sonnet 还发现了一些早期遗留的采集逻辑。

部分接口已经没有太大价值，却仍然会在日常任务中执行，造成额外的网络等待和超时问题。

我让它确认这些接口的实际用途，以及删除后会不会影响现有功能。

完成依赖排查后，它清理了不再需要的任务，同时保留了仍在使用的功能。

这也是我比较满意的地方。

它并不是单纯按照指令增删代码，而是能够结合当前系统的实际状态，判断哪些历史逻辑已经没有保留的必要。

五、真正让我满意的是上线验证

前面的重构虽然涉及不少代码，但最能体现 Sonnet 工程能力的，是最后的上线过程。

完成修改后，我要求它先提交代码——这次重构累计 9 个提交，除了采集代码，还有基础数据、生成的页面数据、测试和相关文档——然后合并到主分支，但暂时不要推送。

随后又让它检查远程更新，确认没有冲突后才允许正式发布。

临近结束时，我提醒了一句：

「这个改动很多，你要冒烟的。」

Sonnet 没有简单检查首页能否打开，而是现场手写了一套多线程并发测试脚本，直接对生产环境做穿透式抽样。

第一步是把线上 sitemap 和本地构建的页面索引对齐：两边都是 560 条，一对不差。

然后从这 560 个页面里分层抽了 136 页：70 个模型详情页、15 个模型对比页，23 个排行榜页面全部覆盖，外加盖价格页、费用计算器和文章页。检查结果：

测试并不只是看 HTTP 状态码。它还给每一页做了内容扫描，专门找空值、无效数字和没有正确渲染的模板残留。

136 页里发现的 1 处疑似异常，来自一篇文章页面，里面出现了一段看起来像模板没处理干净的字符串。

Sonnet 没有直接认定页面出错，而是回头翻这篇文章的 Markdown 源文件，最后确认：那段内容本来就是正文里的 JSON 配置示例，属于检测规则误报。

随后它又补了两轮验证。一轮不再看页面结构，直接核对本次修改入库的关键数据：Claude Sonnet 4.6 的百万上下文、MiMo-V2.5-Pro 的输入 $0.435/M 输出 $0.87/M，线上渲染结果与本地完全一致；综合榜线上前五名的分数，也和本地计算产物逐项比对通过。

最后，它还核对了生产环境的部署版本，确认本次修改已在生产环境生效。

整个测试结束，没有发现本次改动引起的结构性问题。

最值得注意的是，它没有因为测试出现异常就直接宣布失败，也没有忽略异常，而是继续追查到源文件。

这比单纯跑出一个全部通过的测试结果更有价值。

当然，这不代表 560 个页面的所有功能都经过了完整测试。实际做内容抽样的是 136 页，其余页面是通过索引一致性等方式覆盖的。

六、139 Credits，究竟值不值？

这次任务让我对 Claude Sonnet 5.5 的工程能力有了更具体的认识。

它给我留下最深印象的，并不是代码写得多快，而是三个方面。

第一，能够理解已有工程。

面对历史代码，它会先梳理依赖关系和数据流，再决定修改范围，而不是随意推倒重写。

第二，能够接受约束。

从独立分支、数据保护到采集范围控制，我提出的限制基本都能落实到实际执行中。

第三，具备较强的自主验证意识。

尤其是最后的生产环境测试，它能够根据改动范围自行设计验证方法，并对发现的异常继续追查。

当然，这次验证并不意味着所有问题都已经解决。

生产环境的抽样测试已经通过，但新的自动化流程还需要经过后续定时任务的实际运行，才能确认长期稳定性。

Sonnet 5.5 的表现目前看来比较中规中矩，风格也是我喜欢的，跟 GLM-5.5 flash 以及 Space Bunny 有点像，都是自己确认问题，最后给出结论，给出几个选项让我选择，不给开放式问题。处理过程也是非常让人放心。

说到这，今天 GPT-6.1 Sol 又花了我 $1.5，在开发过程中调用 API 来实测，等我看到的时候，几百个请求发出，还好只是调的 Haiku，这已经不是第一次犯了，已被我永久打入冷宫。

最后

17 轮交互，139 Credits，数小时运行。

如果只看积分消耗，这确实不是一次便宜的任务。

但这次我几乎不需要逐行指导它写代码，更多时候只需要明确目标、决定方案、划定边界，然后检查交付结果。

对 Coding Agent 来说，真正重要的不是能写多少代码，而是能不能把一件复杂的事情可靠地做完。

至少在这次 Jumohub 的核心数据管线重构中，Claude Sonnet 5.5 展现出了相当成熟的工程协作能力。