最新

我的一位同事花了三天时间写了一个提示词给 Claude，让 Claude 生成一份产品需求文档（PRD）。 Claude 生成了令人惊叹的 12 页 Notion 文档，其中包含图表、模式定义、预期行为等等。 我通读了所有内容，并就他决定的架构提出了一些疑问，因为他选择了与我们讨论的不同方向，但这也没关系。他大部分的回答是：“哦，那个忽略掉，是 Claude 加的。” 我们到底在做什么？同样的三天时间，本可以用来手写这份 PRD。当然，它可能不像前者那样光鲜亮丽，但至少是准确的！这正是我对大型语言模型（LLM）感到痛苦的地方，它们会生成大量文本，看起来效率很高。而真正的效率在于用最少的文字来描述功能。 我真的不知道该如何处理这个领域的问题，这与我们写东西的整个前提背道而驰。

一年前就已讨论过。 https://news.ycombinator.com/item?id=44235467

我真的厌倦了到处都是与人工智能相关的内容。 当我打开 Hacker News 时，近一半的置顶文章都与人工智能有关。社交网络上的情况也是如此。 我怀念那些需要花费时间和精力去理解的技术内容的时代。 如今，发现这些内容变得非常困难。在 HN 上，我看到很多技术文章都无法登上首页，所以有时我只能在提交的文章中搜索它们。不仅内容变少了，需求也在下降。我猜人们宁愿读另一篇关于大型语言模型的文章，这些文章几乎不教任何东西，也无法激发他们的好奇心。对我来说，作为读者和作者，这都令人感到悲伤。 那么，还有什么地方的人们仍然关心并分享深入的技术内容呢？我想继续锻炼我的思维。我受够了“脑残”内容。

五年前，我们在 HN 上推出了 Infracost（[https://news.ycombinator.com/item?id=26064588](https://news.ycombinator.com/item?id=26064588)），我们的 CLI 可以为基础设施即代码生成成本估算，例如“这个 Terraform PR 会增加每月 400 美元”。其理念是将云成本（FinOps）左移，以便工程师在部署前就能了解成本情况并做出更明智的决策。 今年早些时候，我们在日志中开始看到代理流量，看起来像是编码代理在调用我们的 CLI。但该 CLI 的设计并未考虑到编码代理。我们深入探讨了一个哲学性的问题，即鉴于 Claude、Copilot 等工具已经遵循最佳实践，CLI 是否还有必要。最终，我们决定从头开始创建一个新的 CLI，并考虑到编码代理，原因有两个： 1. 我们针对代理调用者优化了 CLI，与纯 Claude 基线相比，Claude 的输出 token 使用量减少了高达 79%，API 成本减少了高达 67%。我们撰写了一篇博客，记录了我们在设计 CLI 时优化用户 token 使用量的经验，例如使用谓词标志，这样代理就不会组合 jq | python | wc 管道，以及输出格式会去除 JSON 中冗余的字段名。博客地址是：[https://www.infracost.io/resources/blog/we-cut-claude-s-token-usage-79-by-redesigning-our-cli-for-agents](https://www.infracost.io/resources/blog/we-cut-claude-s-token-usage-79-by-redesigning-our-cli-for-agents) 2. 在云成本方面，精度至关重要。告诉编码代理“优化此 Terraform 的成本”可能会非常昂贵且信息丢失。您会消耗 token 来加载代码和策略上下文到每次对话中。您的代理可能会编造一个价格，而您却不知道，因为很难在 AWS、Azure 和 Google 大约 1000 万个价格点之间进行验证。CLI 会对代码进行静态分析，使用云供应商的最新价格，并将该上下文传递给编码代理。 因此，今天我们推出的是 Cost.dev：[https://cost.dev/](https://cost.dev/)。 * 它在本地运行。您的代码永远不会离开您的机器，您可以获得快速的反馈循环，并且在您想要获取价格时不会消耗按字符计费的 API 调用。 * CLI 负责确定性的工作。获取价格点、扫描代码、验证修复。编码代理负责自然语言部分。您不必相信 LLM 会记住规则，并且可以验证它是否调用了正确的 CLI 命令。 * 它在您使用的每个工具之间提供了一致的规则层。通过一次安装，即可在您的 IDE 和编码代理中获得成本估算。我们支持 Claude Code、GitHub Copilot、Cursor、Windsurf、OpenAI Codex、Gemini CLI，以及 VS Code 和 JetBrains 等 IDE。 在继续朝这个方向发展之前，我想在 HN 上进行一次健全性检查：是否真的存在“代理在生产环境中编写 IaC”的情况，还是我正在押注一个仍需一年才能实现的未来？我知道软件开发人员正在大量使用编码代理，但平台/基础设施人员是否也在为生产环境使用它们？另外，如果您对 Cost.dev 有任何反馈，我非常乐意听取。

据我观察，它分为三个层面： 第一层：个人（记忆 MCP 工具，个人 *.md 文件） 第二层：代码库（CLAUDE 或 AGENTS.md，代码库内文档） 第三层：组织级（Unblocked、Glean 或类似工具） 大多数人在第一层和第二层有很强的看法。第三层似乎投入不足。 我想知道，您认为第一层和第二层是否会让第三层变得多余，或者一个强大的第三层是否会让您停止/减少对第一层和第二层的维护？