最新

嗨，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语言语音助手。它支持语音唤醒，并能够实时流式传输响应。它还具有一个企鹅形状的界面！