最新

嗨，HN， 我在2024年中期使用大型语言模型（LLM）构建了我的第一个项目。从那时起，我一直很兴奋。但当然，最终一切都会变得复杂。 你看，软件是一个错综复杂的细节交织体。好的软件能够处理许多细节，并且在增加功能时不会出现退步。 我自筹资金的初创公司ApprovIQ（[https://approviq.com](https://approviq.com)）正在努力进入一个成熟的市场，面临多个功能齐全的竞争对手。我需要把细节做好：最低可行产品（MVP）的质量是无法销售的。因此，我选择了测试驱动开发（TDD），经典的红灯/绿灯/重构方法。编写失败的测试，然后使其通过，迫使你在测试中记录下代码中的每一个决策。这使得构建软件成为一种通用的方法。使用TDD，你不需要在脑海中保持关于事物应该如何工作的上下文。你的软件可以复杂得随心所欲，同时仍然能够抵御回归。如果第三方依赖出现bug？只需获取一个失败的测试，然后使其通过。任何撤销你修复的人都会看到测试失败。 在与Claude Code进行TDD的同时，我还发现代理会遵循面前的**所有**指令！我开始添加超级高级的代码检查：强制执行架构指南、遍历代码库抽象语法树（AST）的脚本以强制执行我的架构，甚至添加了一个只允许我们品牌颜色的检查。这一检查非常棒，因为它防止代理在前端选择丑陋的“AI通用”颜色。由于这个检查会阻止使用丑陋颜色的提交，我们的产品看起来更像是人类构建的，而不是完全由AI完成的。 随着时间的推移，我不再关注代理构建的细节，而主要监督TDD过程，同时它实现我们的产品。一旦这变得乏味，我也将其自动化为一个状态机。 现在让我能够高质量构建的所有想法都在这个代码库中。 这不是一个周末的随意项目。我花了几个月时间来完善这个框架。虽然还有一些粗糙的边缘，但它总比藏起来等到完美要好。 希望这里的一些想法能对你或你的代理有所帮助。我建议你克隆它，让你的代理看看！如果你想贡献，请随时联系我，联系方式在我的个人资料中。 感谢你的关注。

我创建VeryBot是因为我厌倦了将ChatGPT、Trello、定时任务和Slack机器人作为独立工具来使用。我希望有一个能够自托管的助手，能够真正完成工作，而不仅仅是回答问题。 它的功能包括： - 与AI助手聊天，能够根据对话创建任务、团队和日程 - 可由助手填充和更新的看板 - 定时自动化（定期提醒、跟进），无需外部定时任务 - 操作手册：保存工作流程（入职、事件处理、发布清单）并重新运行 - 连接Telegram、Discord、Slack或WhatsApp作为渠道 - 移动友好的用户界面，桌面和手机使用相同的界面 所有数据都保留在本地，位于~/.verybot。采用MIT许可证。Node.js版本>=22。 ```bash npm install -g verybot && verybot ``` 打开http://localhost:28789，在设置 > 代理中选择一个模型提供者，然后尝试：“为启动规划设置团队和初始任务。” 欢迎提问，也期待听到您觉得缺少的功能。

MachineAuth 是一个自托管的 OAuth 2.0 服务器，用于对 AI 代理和机器进行身份验证。<p>在这个上下文中，什么是 AI 代理？它是一个软件机器人（如 OpenCLAW、Claude Code 等），通过 API 调用访问受保护的资源。您的代理可以使用 OAuth 2.0 客户端凭证进行身份验证，而无需共享长期有效的 API 密钥，并可以获得短期有效的 JWT 令牌。<p>为什么要这样做？<p><pre><code> 不再共享 API 密钥 短期有效的令牌（可配置） 简单的凭证轮换 行业标准的安全性</code></pre>

嗨，HN，我构建了 eth.zig——一个完全用纯 Zig 编写的以太坊客户端库，零依赖（没有 C 绑定，没有系统库，仅使用 zig build）。<p>它涵盖了 ABI 编码、RLP、secp256k1 ECDSA、Keccak-256、BIP-32/39/44 HD 钱包、ERC-20/721 封装、JSON-RPC（HTTP + WebSocket）、ENS、EIP-712 和 Multicall3。<p>有趣的是：在 26 个基准测试中，它在 19 个测试中超过了 Paradigm 的 alloy.rs（Rust）。ABI 编码速度快 1.92 倍，u256 除法速度快 4 倍，Keccak-256 速度快 1.37 倍。alloy.rs 在 secp256k1 签名（预计算的 EC 表）和一些 Rust 的 sol! 宏生成专用代码的路径上获胜。<p>这一切的实现得益于 Zig 的 comptime——函数选择器和事件主题在编译时计算，运行时成本为零。整个加密栈（secp256k1、Keccak-256、BIP-32/39/44）都是纯 Zig。<p>文档：<a href="https://ethzig.org" rel="nofollow">https://ethzig.org</a> 代码库：<a href="https://github.com/StrobeLabs/eth.zig" rel="nofollow">https://github.com/StrobeLabs/eth.zig</a> 基准测试：<a href="https://github.com/StrobeLabs/eth.zig/blob/main/bench/RESULTS.md" rel="nofollow">https://github.com/StrobeLabs/eth.zig/blob/main/bench/RESULTS.md</a><p><pre><code> 非常希望能收到反馈，特别是来自 Zig 和以太坊开发者的意见</code></pre>

快速背景：我正在构建后台作业自动化，并不断遇到以下模式： 1. 作业调用外部 API（Stripe、SendGrid、AWS） 2. API 调用成功 3. 作业在记录成功之前崩溃 4. 作业重试 → 再次调用 API → 产生重复 示例：处理退款，发送电子邮件通知，然后崩溃。重试时再次执行这两个操作。客户收到重复的退款电子邮件（或者更糟，重复的退款）。 我看到几种解决方案： 选项 A：在数据库中存储已处理的 ID 问题：“检查数据库”和“调用 API”之间的竞争仍然可能导致重复。 选项 B：使用 API 幂等性键（Stripe 支持此功能） 问题：并非所有 API 都支持（遗留系统、第三方）。 选项 C：构建去重层，首先检查外部系统 问题：额外的延迟，额外的复杂性。 在生产环境中你会怎么做？接受一些重复？只使用支持幂等性的 API？还是其他方案？ （我为选项 C 构建了一些东西，但想了解这是否是一个足够普遍的问题，还是我在过度设计。）