最新

嗨，HN 社区，和许多人一样，我对软件工程目前的发展方向很感兴趣，尤其是在编码 LLM 变得越来越普遍的今天。虽然我们还没有达到“自然语言编程”的阶段，但新的抽象概念似乎已经开始形成。为了进一步探索这一点，我构建了 semcheck（语义检查器）。它是一个简单的命令行工具，可以在 CI 或 pre-commit 阶段使用，通过 LLM 检查你的实现是否与你的规范相符。 这个想法的灵感来自于我正在参与的另一个项目，该项目需要一个 GeoJSON 对象的的数据结构。我把 RFC-7946 的文本传递给 Claude，它给了我一个实现方案。之后我来回调整了好几次才满意，但这也意味着 RFC 已经超出了 LLM 的上下文范围。这就是为什么我再次要求 Claude 检查 RFC，以确保我们没有偏离规范太远。我意识到，有一个正式的方法来定义这类检查会很好，可以在 pre-commit 或合并请求流程中运行。 创建这个工具本身就是一次实验，尝试使用 Claude Code 进行“规范驱动开发”，这介于完全的即兴编码和传统编程之间。我的工作流程如下：要求 AI 编写规范和实现计划，手动编辑这些内容以符合我的喜好，然后要求 AI 一次执行一个步骤。小心谨慎，确保 AI 不会偏离我所认为的要求太远。我的第一个提交 [1] 是配置文件结构的规范和实现计划。 一旦 semcheck 能够自检，它就开始发现问题 [2]。我发现这种工作流程不仅能改进你的实现，还能帮助你同时完善你的规范。 除了规范之外，我还开始在我的规则中包含文档，确保我在 README.md 文件中的配置示例和 CLI 标志与实现保持一致 [3]。 最好的是，你可以将发现的问题直接放回你的 AI 编辑器中，进行快速迭代。 一些经验教训： * LLM 非常擅长发现差异，只要你传递给比较函数的文件的数量不是太大，换句话说，真阳性结果相当好。 * 假阳性：LLM 是一个无所不知的（字面意思）家伙，并且经常认为它更懂。LLM 渴望使用它自己的世界知识来发现错误。这既好又成问题。我经常遇到它抱怨我的 Go 版本不存在的情况，但这仅仅是因为它是在该模型的知识截止日期之后发布的。我专门提示 [4] 模型只查找差异，但它经常“选择”使用它的知识。 * 为了减少假阳性，我要求模型给我一个置信度分数（0-1），以表明它对它发现的问题在这种情况下是否实际适用的确定程度。模型总是超级自信，并且几乎只输出 > 0.7 的值。 * 一件确实能显著减少假阳性的事情是，要求模型在为发现的问题分配严重级别之前给出其推理。 * 在我的（粗略的）实验中，我发现像 O3 这样的“思考型”模型并没有在性能上带来多少提升，而且不值得额外的 tokens/时间。（可能是因为我已经要求它给出推理了） * 表现最好的模型是 Claude 4 和 GPT-4.1 如果你认为这在你的工作流程中很有用，请告诉我，以及你需要什么功能才能使其发挥作用。 \[1]: <https://github.com/rejot-dev/semcheck/commit/ce0af27ca0077fe158a179bae5f6258b8a1f73d9> \[2]: <https://github.com/rejot-dev/semcheck/commit/2f96fc428b551d9f48b8fe9bc5321838ac9139f2> \[3]: <https://github.com/rejot-dev/semcheck/blob/47f7aaf98811c54e231a81cb98b1bc9b25d9871d/semcheck.yaml#L26> \[4]: <https://github.com/rejot-dev/semcheck/blob/fec2df48304d9eff959c4eda3ee0d3a92295eb22/internal/checker/prompt_template.go>

日本以严苛的工作环境而闻名。 我保证这是真的，因为我是日本人，而且我几十年前也曾身处这种严苛的工作环境。曾经连续三天通宵工作。 我感到沮丧。这是很自然的。 在日本，很多人因为工作、职场欺凌和自杀而饱受痛苦。 我认为我们应该改变这种荒谬的环境。 可能在世界上，很多人也面临着类似的情况。 请告诉我你们的工作环境是怎样的。

嘿，想和大家分享一下我用 Lovable 在一天内构建并部署的应用程序。<p>作为一名创始人，我一直想有一个顾问，但预算总是有限。另一方面，我有 Paul 的创业建议文章，但我从没读过，因为我一直在忙着构建东西。<p>因此，我构建了这个产品，它同时兼顾了两者的优点，而且比其他选择更合理、更强大。 ps：它运行在一个推理模型上。 说实话，我从中获得了很多有价值的见解。<p>给 PG 的话：如果你看到了这个。我是你的忠实粉丝。感谢你所做的一切。

最近发现了这个超棒的项目——它是一个用 C 语言为 ESP32 设备编写的语音助手。它支持语音唤醒，并能实时流式传输回复。而且，它还有一个企鹅形状的界面！