最新

嗨，HN，我是Pranav（创始人）。我设计硬件时发现了一个奇怪的分歧： 工程师们不信任AI来设计完整的PCB（隐藏的假设、层叠、制造限制、电磁干扰/回流路径，以及稍有偏差的成本 - 这就是为什么像Flux这样的工具仍然没有被广泛信任用于完整设计的原因）。 但客户们却不断要求ChatGPT“审核”电路板。他们粘贴截图/ Gerber文件，并期望得到真正的签字。结果往往听起来没问题，但它可能会产生幻觉或遗漏实际导致重新设计的原因。 在这个过程中我学到的教训是：困难的部分不是更多的AI，而是具有明确假设的确定性、可重复的检测，AI仅用于解释发现并建议修复方案。 我非常希望得到反馈：哪些问题值得在制造前捕捉，哪些问题太嘈杂，以及什么能让你信任这个作为发布的门槛。

一个小周末项目，制作这个是为了在学习歌曲时能够直接在钢琴上暂停、播放和倒带。

在最新一期的Weaviate播客中，Doug Turnbull解释了为什么像grep这样的简单词汇工具对智能体如此有效：透明的输入输出关系使得智能体能够推理出结果匹配的原因，调整其策略，并规划下一个查询。

嘿，HN！<p>我发现自己经常需要将复杂的代码库传递给大型语言模型（LLM），用于生成产品需求文档（PRD）等。每次我将代码库粘贴到Claude中时，我都要为模型不关心的文件支付代币。但如果我只粘贴相关文件，模型就会失去对整体结构的理解。这真是一个令人烦恼的权衡。<p>llmdoc是一个小型命令行工具，它为每个文件添加简短的LLM摘要，并在哈希值变化时智能更新这些摘要。<p>llmdoc annotate # 为每个文件添加摘要（遵循.gitignore，你可以配置它忽略更多文件）<p>llmdoc dump # 生成一个方便的“快速概览”摘要，以便提供给LLM，确保你代码库的完整上下文。<p>还有llmdoc check用于持续集成（CI）——如果任何注释过时或缺失，则返回1，不需要API密钥。<p>它支持Anthropic和OpenAI，兼容50多种语言，遵循.gitignore，并且有一个--dry-run标志，可以在实际操作之前估算成本。<p>一个已知问题是LLM提供商的速率限制，但由于一切都基于哈希，你可以多次重新运行以使其正常工作。<p>告诉我你的想法！