最新

嗨，HN，和许多人一样，我对软件工程在编码大型语言模型（LLMs）普及后所走的方向感到兴趣。虽然我们还没有完全实现“自然语言编程”，但新的抽象概念似乎已经开始形成。为了进一步探索这一点，我构建了 semcheck（语义检查器）。这是一款简单的命令行工具，可以在持续集成（CI）或预提交时使用，检查你的实现是否符合规范，利用 LLMs 进行验证。 这个灵感来源于我在另一个项目中需要为 GeoJSON 对象设计数据结构时。我将 RFC-7946 的文本传给 Claude，它给出了一个实现方案。经过几轮的修改后，我才对这个实现感到满意，但这也意味着 RFC 对 LLM 来说失去了上下文。因此，我再次请 Claude 检查 RFC，以确保我们没有偏离规范。这让我想到，应该有一种正式的方式来定义这些检查，以便在预提交或合并请求流程中运行。 创建这个工具本身就是一个实验，旨在尝试使用 Claude Code 进行“规范驱动开发”，这是一种介于完全依赖直觉编码和传统编程之间的中间方式。我的工作流程如下：请求 AI 编写规范和实施计划，手动编辑这些内容以符合我的要求，然后逐步请求 AI 执行每一步。要小心 AI 不会偏离我认为所需的内容。我的第一个提交是配置文件结构的规范和实施计划。 一旦 semcheck 达到可以自我检查的状态，它就开始发现问题。我发现这种工作流程不仅改善了你的实现，还帮助你同时完善了规范。 除了规范，我还开始在我的规则中包含文档，确保我在 README.md 文件中的配置示例和命令行标志与实现保持一致。 最好的地方是，你可以将发现的问题直接放回你的 AI 编辑器中，进行快速迭代。 一些经验教训： - LLMs 在发现差异方面非常有效，只要你传递给比较函数的文件数量不是太大，换句话说，真正的正面结果相当不错。 - 假阳性：LLM 是个“万事通”（字面意思），常常认为自己知道得更多。LLM 渴望利用自己的世界知识来发现错误，这既有好处也有问题。我常常听到它抱怨我的 Go 版本不存在，但那只是因为它在该模型的知识截止日期之后才发布。我特别提示模型只找出差异，但它往往还是“选择”使用自己的知识。 - 为了减少假阳性，我要求模型给出一个置信度评分（0-1），以指示它对发现的问题在该场景下是否适用的确定性。模型总是非常自信，输出的值几乎都大于 0.7。 - 一件显著减少假阳性的方法是要求模型在为发现的问题分配严重性等级之前先给出其推理。 - 在我的（初步）实验中，我发现“思考型”模型如 O3 在性能上并没有显著提升，不值得额外的代币/时间。（可能是因为我已经要求推理了） - 表现最佳的模型是 Claude 4 和 GPT-4.1。 如果你觉得这对你的工作流程有用，请告诉我，并告诉我你需要什么功能来使其正常运作。

日本以其严酷的工作环境而闻名。我可以保证这是真的，因为我是一名日本人，几十年前我曾在恶劣的工作环境中工作。连续工作了三天的夜班。我感到沮丧，这很自然。在日本，许多人因工作、骚扰和自杀而痛苦。我认为我们应该改变这种荒谬的环境。可能在世界各地，很多人面临着类似的情况。请告诉我你的工作环境。

嘿，我想和大家分享一个我用Lovable在一天内构建并部署的应用程序。 作为创始人，我一直想要一个顾问，但我的预算总是有限。另一方面，我有保罗关于创业建议的文章，但因为忙于开发项目，我从未阅读过。 因此，我构建了这个产品，它在合理性和能力上都比其他选择更具优势。 顺便说一下，它运行在一个推理模型上，老实说，我从中获得了相当不错的见解。 给PG的备注：如果你看到这个，我是你的忠实粉丝。感谢你所做的一切。

最近偶然发现了这个令人惊叹的项目——这是一个为ESP32设备编写的C语言语音助手。它支持语音唤醒，并能够实时流式传输响应。此外，它还具有一个企鹅形状的界面！