最新

在专业环境中从事大型语言模型（LLM）开发的开发者们，规格驱动开发（Spec Driven Development, SDD）真的是LLM编码代理的未来方向吗？ 在过去的几个月里，我一直在努力尝试拥抱SDD。在试用了SpecKit和GSD之后，我最终选择了OpenSpec作为我偏好的规格生成器。 然而，我还没有完全放弃理解LLM生成的实际代码。 为了帮助我保持对生成代码的理解，我尝试了几种不同的方法，例如为更细粒度的功能生成更小的规格，并在每个主要任务块后暂停以审查代码。通过“/ospx-apply 运行直到任务 3.5 完成，然后暂停审查”的方式，我能够审查生成的代码并根据需要进行更正。但说实话，我遇到的主要问题是，即使加载了适当的AGENTS.md和技能，代码风格和良好的代码卫生仍然常常缺失（通常是多个辅助方法、命名不一致等问题）。 我不禁想知道，开发者们在工作场所是如何做的？SDD是否真的被用作开发者工具集的一部分？是我试图对代码进行过多的控制，而应该让LLM在规格的范围内自由发挥来指导它？还是我应该放弃SDD，寻找其他途径来确保生成的代码至少能够长期维护？

和大家一样，我这几天一直在大量使用 Fable。我的看法已经形成：它非常强大，但有时会以非常错误或奇怪的方式运用它的“智慧”。 举个例子，我让 Fable 修复了一个包含多个子模块、符号链接以及其他乱七八糟东西的仓库（请勿评判）。随着我给予它更大的自由度，它最终输出了以下内容： > .git 已被删除。这是我的操作，而且看起来确实是那种典型的错误：在 shell 的工作目录被重置到仓库根目录后，执行了一个相对路径的 rm -rf 命令，而没有事先重新检查 pwd。 这并不是说这个错误无法挽回或非常关键，它还好，但如果在没有适当防护措施的生产系统上，它可能会造成更糟糕的后果。这表明，不仅要保护你的系统免受 AI 代理的侵害，也要保护 AI 代理免受它们自身的侵害，因为它们也会出现一些“哎呀”的时刻。

学生们需要计算设备，请考虑帮助下一代。