24小时热榜

大家好！我正在使用一个内存安全的浏览器发布这个消息：WebKitGTK MiniBrowser，使用Fil-C编译，并且所有依赖项也都是用Fil-C编译的。<p>仍在处理一些遗留的错误，其中一些看起来像是过于激进的优化，导致指针功能丧失（引发了filc panic）。不过它的运行效果还不错，我可以在这里说声“你好”。

第一次在运行 Chatter.Plus（我正在开发的一个工具，用于汇总来自 Discord、GitHub 和论坛的社区反馈）一天后查看使用成本时，我看到的费用是 2.30 美元。算了一下，按月算是 70 美元，按年算是 840 美元。仅仅是一个实例，感觉非常糟糕。 我之前做过粗略的计算，所以知道这可能是个 bug，但仍然感到不安。结果发现这只是部分是 bug，其余的则是我需要重新思考我构建这个工具的方式。 接下来的几天我花时间拆解它，进行调整，使用实时数据进行测试，检查结果，再次尝试。我发现我发送 API 请求的频率太高，并且没有优化我发送和接收的数据。 以下是我所做的改进，按影响程度从大到小排列（除了那个每天花费我一美元的 bug）： - 完全放弃了 Claude Sonnet - 在相同数据上测试了两个模型，Haiku 实际上以三分之一的成本表现更好。 - 开始对所有请求进行批处理 - 每小时调用一次简直就是在烧钱。 - 在 AI 处理之前进行过滤 - “哈哈”和“谢谢”是很多在线聊天内容。我在花钱让 AI 告诉我这些不是反馈。尽管如此，我仍然会处理像“+1”和“我也是”这样的协议。 - 输出更简短 - 使用“H/M/L”代替“高/中/低”，推荐 40 个字符的标题。 - 在处理之前剔除代码片段 - 只是重复问题，导致请求膨胀。 到周末时：每天只需几分钱，质量依然如故。 我并不是在构建一个可以亏损运营多年的风险投资支持的应用。我失业了，正在尝试构建一些可能也能支付房租的东西。这个数学模型必须从第一天起就能奏效。 好处是：这些节省让我可以将定价层级限制提高三倍，并增加间歇性的质量检查。这是我原本无法获得的余地。 欢迎提问。