最新

我们在记录成本方面不断遇到相同的模式： - CloudWatch / GCP Logging / Datadog 告诉你哪个日志组/索引很昂贵 - 但并没有告诉你代码中具体哪些日志语句是导致成本高的原因 因此，回应总是： - 调整保留策略/层级 - 添加过滤器和采样 ……而且通常要到很久之后你才会发现，问题出在某几行 DEBUG 代码、冗长的 HTTP 跟踪，或者循环中的有效负载转储。 在某个时刻，我们想要一个简单的答案： > “对于当前已部署的代码，哪些日志调用位置消耗了最多的预算？” ——— ### LogCost 的功能 LogCost 是一个小型的 Python 库 + 命令行工具，它： - 封装了标准的日志模块（可选打印） - 跟踪每个调用位置的指标： {文件, 行, 级别, 消息模板, 计数, 总字节数} - 应用提供商定价（例如 GCP/AWS）来估算成本 - 定期导出聚合统计信息（不包含原始日志负载） - 可以发送 Slack 通知，列出最昂贵的前 N 行日志 它旨在作为当前部署的快照：在正常负载下运行，查看哪些行主导了成本，修改它们，重新部署，重复此过程。 ——— ### 工作原理（高层次） - 它封装了 logging.Logger._log，并使用文件、行和级别记录每个调用位置的关键。 - 消息大小是根据格式化字符串的长度加上可配置的每个事件开销来估算，并按调用位置累积。 - 后台线程定期将聚合数据刷新到磁盘上的 JSON 文件中。 - 命令行工具读取该 JSON 并打印： - 成本摘要（基于当前提供商定价），以及 - 每个调用位置的“主要成本驱动因素”表。 根据设计，它从不存储原始日志负载，只存储像这样的聚合数据： { "file": "src/memory_utils.py", "line": 338, "level": "DEBUG", "message_template": "Processing step: %s", "count": 1200000, "bytes": 630000000, "estimated_cost": 315.0 } 这样做部分是出于隐私考虑，部分是因为这旨在补充你的日志平台，而不是替代它。 ——— ### 示例输出 报告可能会显示： - 提供商：GCP，货币：美元 - 总字节数：900,000,000,000 - 估算成本：450.00 主要成本驱动因素： - src/memory_utils.py:338 [DEBUG] Processing step: %s → $157.50 - src/api.py:92 [INFO] Request: %s → $73.20 - … Slack 通知只是相同数据的格式化版本，按可配置的时间间隔发送（可选的提前“测试” ping 以便你验证连接）。 ——— ### 范围和状态 - 目前仅支持 Python（Flask/FastAPI/Django / K8s sidecar 示例） - MIT 许可，无需后端服务 - 导出格式为简单的 JSON，因此如果需要，可以后续供中央聚合器使用 代码库： https://github.com/ubermorgenland/LogCost 我希望能听到那些调试过“神秘”日志账单的人的反馈： - 你是否已经以更简洁的方式解决了这种映射（账单 → 具体日志位置）？ - 在你的设置中，逐行聚合是否真的有用，还是与更好的日志组约定相比，这种方法显得过于复杂？

嗨，HN！我想分享一个我进行的小实验：我尝试看看能否通过一个提示构建并部署一个完整的 Rust 应用程序，使用 Claude Opus 4.5 和 Shuttle。 我请 Claude 构建一个个人财务跟踪器，使用 Axum 和 SQLx，编写迁移，生成前端，并进行部署。我原本预期会在某个地方出错……但实际上它生成了一个干净、可工作的 Rust 应用程序，成功编译、迁移并部署。 这是我的提示： 构建一个个人财务跟踪器网页应用，满足以下要求： *后端（Rust + Axum + SQLx）：* - 使用 Rust 和 Axum 网络框架 - 使用 SQLx 进行 PostgreSQL 数据库操作 - 在整个过程中使用 SQLx 的编译时检查查询宏（query!、query_as! 等），不使用原始查询 - 数据库运行在 localhost:5432 - 使用 `sqlx migrate add` 命令创建适当的数据库迁移 - 实现迁移以创建必要的表（交易、类别、预算等） - 自动运行迁移或提供明确的说明 - 在部署前运行 `cargo sqlx prepare` 以生成离线编译所需的查询元数据 - 创建 RESTful API 端点，用于： - 添加/编辑/删除交易 - 对交易进行分类 - 按类别/时间段获取支出摘要 - 预算管理 *前端（HTML/CSS/JS）：* - 使用原生 HTML、CSS 和 JavaScript 创建现代、简洁、流畅的用户界面 - 使其响应式并适合移动设备 - 包含数据可视化（按类别支出的图表、随时间变化的趋势） - 使用良好的配色方案和现代设计模式 - 将所有前端资源放在 `dist/` 目录中 *部署：* - 部署到 Shuttle - 配置 Shuttle.toml 以包含前端资源 - 使用 Shuttle MCP 服务器处理部署 - 如果需要，也可以使用 Shuttle MCP 服务器搜索 Shuttle 文档 *要实现的功能：* - 交易管理（添加、编辑、删除收入/支出） - 自动和手动分类 - 预算设置和跟踪 - 使用图表提供支出洞察（饼图、柱状图、折线图） - 日期范围过滤 - 摘要统计（总支出、按类别、每月趋势） 将其构建为一个完整的、生产就绪的应用程序，具备适当的错误处理、验证和精致的用户体验。 我尝试这个的原因： - 我想知道 AI 是否能够处理真实的 Rust 工作流程，而不仅仅是代码片段 - Rust 应用中的样板代码（迁移、路由、设置）仍然繁琐 - 我很好奇模型会在哪些地方出错——语法、库、SQL、构建步骤、部署 最终它构建了整个应用，出乎意料地只需很少的修正。这让我思考：如果这变得正常，我们能发布多少个副项目？当提示成为起点时，“编写软件”是什么样子？ 如果你想了解所有细节，比如哪些地方出错、哪些地方有效，以及最终构建的结果，所有信息都在上面的博客中。希望能得到其他开发者尝试类似事情的反馈。

我在过去的七年里一直在购买二手/新款的联想和戴尔笔记本电脑，最近我注意到新型号的做工质量令人担忧。 联想：前公司在2019年给我了一台全新的Carbon X1，但电池使用时间不到一年！另一方面，我从同一家公司购买了一台2017年的二手470S，增加了内存，没有动过任何部件，包括SSD，现在我仍在日常编程中使用它。上个月我买了个新电池，所以从技术上讲，旧电池的使用寿命大约是7-8年。 戴尔：我从戴尔翻新店购买了3台笔记本电脑和1台台式机（所以质量应该是稳定的）。其中2台笔记本和1台台式机是旧型号，1台是我去年12月购买的Precision 5550（2021款）。一切运作正常，除了5550，它的电池出现了问题（电量从31%迅速降到4%），而且（更严重的是）充电端口（时不时不充电）。即使我在2021年买的是全新产品，我也会对它只用了4年多感到惊讶。 另一个问题是5550使用USB-C端口。我怪自己在购买前没有仔细检查。我真的很讨厌这些端口。为什么大家都在模仿Mac？ 我该怎么办？我实在无法为一台新笔记本电脑 justify 2000加元以上的价格，尤其是如果它的使用寿命不到5年。我更倾向于一台配备32GB内存的“低端”工作站，但由于价格原因，我只能负担得起一台16GB的非工作站型号。我不再玩游戏，但仍然希望有一款好的集成显卡。我无法承担Framework和其他Linux笔记本的费用，因为它们价格昂贵，而且通常在加拿大无法使用，所以运费也很贵。 上个月我从我现在的公司购买了一台二手Macbook Pro M1 16GB（2021款）。我还没有使用它，但我相信硬件是好的。问题是我不太喜欢它的软件，所以我意识到我仍然需要一台Linux电脑。 你找到什么好的选择了吗？

我创建了aipatch，因为我在使用AI编码工具时遇到了反复出现的问题，这些工具最终无法正确应用补丁或忽略部分指令。它们经常会执行我没有请求的操作，尤其是在上下文稍微不寻常的时候。 我想要一个更简单、更明确的工具：一个我可以完全控制输入到大型语言模型（LLM）提示中的内容的工具，并且模型以确定性的搜索/替换块进行响应，这些块可以自动应用。 aipatch的主要理念是： - 你手动选择上下文（来自一个或多个项目）。 - 你将其发送给你喜欢的任何LLM。 - 模型输出结构化的补丁块。 - aipatch将它们应用到代码库中并记录所有内容。 对我来说，最有用的部分是多项目提示。我经常需要同时更新后端、前端和文档，或者比较两个git提交，或者将一个小原型的功能移植到一个更大的代码库中。现有工具对此处理不佳，因此aipatch允许你为每个项目分配一个唯一的ID，并将它们合并为一个单一的提示。 我还发现，最佳的“提示”往往是另一个已经按你希望的方式运行的工作项目。在上下文中包含一个小原型或参考代码库，可以给LLM一个明确的示例，从而生成比尝试用普通文本描述所有内容更准确的补丁。 这里有一个简短的演示视频（“我使用aipatch改进了aipatch”）： <a href="https://youtu.be/xho0pMKPu14" rel="nofollow">https://youtu.be/xho0pMKPu14</a> GitHub： <a href="https://github.com/axife/aipatch" rel="nofollow">https://github.com/axife/aipatch</a> 这是一个用Python编写的命令行工具，适用于任何LLM，不需要编辑器集成或账户。我非常欢迎任何从事LLM辅助开发或多代码库工作流程的人的反馈。