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