Ask HN：你如何审查由生成式 AI 编写的代码？
4 分•作者: captainkrtek•5 个月前
我在几个评论中提出了这个问题，但想发起一个更大的讨论。<p>有些人认为，使用 LLM 编写代码就像工程师们在使用一种新的高级语言。然而，这会导致代码审查时出现脱节，因为被审查的代码是生成它的过程的产物。如果我们现在通过自然语言来表达自己（提示、规划、编写，作为新的“编程语言”），但只将生成的产物（实际代码）提交审查，我们如何完整地审查它？<p>我感到困惑的是，如今似乎缺少了关键的一环，即缺乏关于更改是如何产生的背景信息，包括计划、提示等，以便理解工程师是如何得出这个特定代码更改结果的。他们是一次性完成的吗？他们仍然花费了数小时进行提示/迭代等吗？还是介于两者之间？<p>PR 中的摘要通常会说明更改是什么，但没有包含完整的对话或我们如何得出这个特定更改（权衡、备选方案等）的过程。<p>鉴于此，您在您的组织中如何审查 PR？您实施了任何规则/自动化等吗？
查看原文
I've posed this in a couple comments, but want to get a bigger thread going.<p>There are some opinions that using LLMs to write code is just a new high level language we are dealing in as engineers. However, this leads to a disconnect come code-review time, in that the reviewed code is an artifact of the process that created it. If we are now expressing ourselves via natural language, (prompting, planning, writing, as the new "programming language"), but only putting the generated artifact (the actual code) up for review, how do we review it completely?<p>I struggle with what feels like a missing piece these days of lacking the context around how the change was produced, the plans, the prompting, to understand how an engineer came to this specific code change as a result. Did they one-shot this? did they still spend hours prompting/iterating/etc.? something in-between?<p>The summary in the PR often says what the change is, but doesn't contain the full dialog or how we arrived at this specific change (tradeoffs, alternatives, etc.)<p>How do you review PRs in your organization given this? Any rules/automation/etc. you institute?