花了 200 亿 Token 用 CodeX 把一个英文计算器站推上线后，我发现公式反而最省心

最近总算把一个拖了挺久的项目放到线上了： https://calculatorqueen.com

我之前想做一个工具平台，帮助用户解决各种问题，同时也让用户通过每个页面学到这个计算器所算的东西。前后下来开了 3 个 Codex 20X 的账号，正好碰上最近重置多，每天都用尽全力蹬，总共用了 200 亿左右的 Token 。

最后做出来的平台叫 CalculatorQueen ，是个英文在线计算器站。金融、健康、数学、日期、建筑、单位换算这些常见分类都有。我不希望它只是扔给用户一个答案，所以大部分页面都会尽量把单位、公式、计算步骤、假设和限制一起写清楚。至少算出一个奇怪结果时，用户还能顺着步骤看看是哪里出了问题。

有几个页面比较能说明我想做的方向。比如 Grams to Cups Converter，它不是拿一个固定比例硬换算，而是按 110 多种食材分别计算；Chinese Zodiac Calculator 也不是简单按 1 月 1 日切换生肖，而是用了香港天文台的农历新年边界数据。还有一个偏程序员趣味的 Calculator Infinity Trick，可以实际看看 overflow 、undefined 、error 和 infinity 有什么区别；做视频或动画的也可以试试 FPS Calculator，它能把总帧数、真实时长和 non-drop timecode 对起来。

最开始我以为最难的是公式。真正准备上线才发现，公式反而挺“听话”：输入是什么，输出就是什么，错了还能写测试抓出来。更磨人的其实是另外一些事情：

预览环境会不会不小心被搜索引擎抓走；
正式环境会不会继续带着 noindex ；
旧地址到底由 Worker 还是静态资源负责跳转；
查询参数和尾斜杠会不会让同一个页面出现好几个版本；
页面虽然能打开，但内容是否真的准备好进入搜索结果。

这次我没有把所有页面一股脑塞进 sitemap 。目前有 325 个计算器页面允许索引，也已经进入 sitemap ；另外 63 个页面仍然可以正常访问，但因为内容意图有重叠，或者还需要继续人工检查，所以暂时保持 noindex 。还有一个测速页面，确认不适合当前的平台能力后就直接拿掉了。

这次让我印象很深的一点是：“页面能访问”和“页面现在值得被搜索引擎收录”，其实是两回事。 noindex 页面也不能顺手在 robots.txt 里挡掉。搜索引擎得先抓到页面，才能看到 noindex 。以前看文档时觉得这是个小细节，真做几百个页面时，才发现这种小细节一旦搞错就是批量出问题。部署用的是 Cloudflare Worker + Static Assets 。

这个组合整体挺轻，但 run_worker_first 给我上了一课。它不只是一个听起来很普通的配置项，而是真的会决定请求先交给谁处理。如果重定向规则一部分放在 Worker 、一部分又交给静态资源，同一个旧地址就可能在不同层被截住。轻一点是多跳或者参数丢失，严重一点还能绕出重定向循环。

最后的处理方式反而很朴素：让一层明确负责重定向，然后把旧地址、尾斜杠、查询参数、404 和不同域名组合全部实际请求一遍。很多线上问题并不是代码本身写错了，只是请求走的路线和脑子里想的不一样。

上线前还是不放心，最后又把整套 4800 个测试跑了一遍。测试全绿不代表产品一定没有问题，但至少比“我本地随便点了几下，感觉应该没事”踏实得多。这次开发和排查过程中 Codex 参与了不少，主要帮我处理重复检查、测试、对账和线上核验。页面该不该发布、公式范围怎么定、哪些内容先不收录，最后还是由我自己检查和决定。站点现在肯定谈不上完成，更像是终于把门窗、水电和地基收拾好了，可以开始认真听反馈。

如果你愿意帮忙看看，我现在最想知道的是：

输入和默认单位是否容易理解；
手机上的操作顺不顺手；
计算步骤能不能让人看明白；
你熟悉的公式有没有边界值、舍入或者文案错误；
有没有两个页面看起来其实是在解决同一件事。

如果发现问题，直接回复“具体页面 + 输入值 + 你预期的结果”就非常有帮助。不求帮顶，能帮我找到一个可以稳定复现的问题就已经很值了。