2025-03-07

在设计变更时，重要的是要记住你可以更改系统的哪些部分以及不能更改哪些部分。例如：

• 如果你公开了一个公共 API，即使 API 很难用，你也应该尽量不要对 API 进行 破坏性更改。
• 如果你与外部系统交互，则必须符合实际存在的 API，而不是直接给你想要的东西的某种一厢情愿的版本。
• 如果测试失败，你不应该删除它以使测试套件通过，你应该了解测试是否正确。

所有这些的共同主题是，系统的某些部分是规范的一部分，虽然偶尔正确的事情是更改规范，但对于日常编码，你希望尊重规范。

LLM 不太擅长尊重规范。他们会很乐意删除测试，更改 API，在他们编码时真正地做任何事情。其中一些边界是常识，并且可能被编码在你的提示中，但是有些你只有在 LLM 提出一些新的和令人着迷的方式来破解奖励函数时才会发现。这是审查 LLM 生成的代码的最重要功能之一；确保它没有以不一致的方式更改规范。

示例

• Sonnet 无法修复测试，因此它用assert True替换了测试的内容。
• 我试图使文件类型良好。一个公共函数返回一个带有键pass的 dict，并且在第一次传递时，Sonnet 3.7 尝试使用 TypedDict 类语法，但这不起作用，因为 pass 是保留关键字。为了解决这个问题，Sonnet 决定将键重命名为pass_，这由于显而易见的原因而不起作用。