那么生成的代码看起来是什么样的呢？我发现虽然<插入你最喜欢的LLM>可以快速生成几乎能运行的C++代码，但之后我不得不花费10倍的时间去修改它，使其看起来至少有点像样的代码。不管我怎么告诉它，在项目或全局配置文件中它是一个“精通现代C++的资深10倍开发者，是斯特劳斯特鲁普的再世”，它仍然不断生成同样糟糕的大问题（比如在应该使用RAII的地方使用手动内存管理， 在构造函数体中初始化字段而不是使用初始化列表， 在类中使用手动初始化/清理方法而不是正确的构造函数/析构函数设计来确保对象始终处于一致状态，以及其他各种反模式等）和小问题（比如在将指针传递给delete/free之前检查nullptr，手动实例化对象作为shared_ptr构造函数的参数而不是使用make_shared，不断来回转换各种类型而不是正确设计数据类型等）。
源讨论自动编程原帖 241 条评论 · 导入时统计我有30多年的行业经验，最近在工作中大量采用以规格为导向的开发方法，这真是一个巨大的改变。我热爱编程，现在我可以在一个更高的层次上进行编程：规格层面。 我花数小时在规格上，与Claude Code合作首先生成并迭代所有需求，然后使用Claude中的自我审查来检查这些需求，先使用Opus 4.5，然后使用CoPilot的GPT-5.2。自我审查是提示，用于从它认为合适的所有角色和视角来审查规格。这个自我审查过程至关重要，真正完善了需求（我通常会进行7到8轮的自我审查）。 一旦需求完善并解决了利益相关者的所有问题，我再次使用Claude Code来创建一个非常详细且分阶段的实施计划，包括完整的代码，所有内容都在规格中（如果需要，使用新的文件作为需求文档）…
完整原文把你的经验，加入这段讨论。
这可能是一种特定于语言的失败模式。C++对人类来说也很困难，而且现有的训练代码质量参差不齐（大部分是C++11之前的，很多是由非专业人员编写的，用于非常特定的目的）。 另一方面，LLM在Go语言上表现很好，因为Go是为大规模的普通工程师设计的，而LLM的行为就像快速的普通工程师。Go作为一种语言被设计成支持最少的巧妙之处（做事的方式有限，而且抽象是受限制的）。这种一致性对LLM训练来说非常有吸引力。
完整原文我同意。我觉得Hacker News上的观点非常二元。对我来说，我使用LLM的经验和你描述的一样。任何超出通用任务的东西都会惨败。我真的很想知道人们是怎么让它这么顺利工作的。
完整原文与其要求它写出好代码，为什么不写一个编码标准文档，明确说明并将其引用到你的计划中呢？
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。