Prompt Request 比 Pull Request 更适合 AI 协作

在 AI 编程场景里，传统 Pull Request 会遇到一个新问题：PR 可能越来越大，但作者对代码的真实理解并没有同步增加。

一个 PM、设计师或初级工程师可以让 Agent 生成大量代码，然后把 diff 发给维护者。维护者面对的不是一个清晰表达意图的变更，而是一堆已经被实现细节固化的结果。此时 review 很累，因为你既要判断需求是否合理，又要判断 Agent 的实现是否符合项目风格，还要猜哪些代码是必要的、哪些只是模型补出来的。

因此访谈中提到一个有意思的想法：与其直接给 Pull Request，不如给 Prompt Request。

Prompt Request 的重点不是“这是我写好的代码，请合并”，而是“这是我想完成的事情、上下文、约束和尝试过的方向，请你在合适的工程上下文里重新生成或改写”。

它把 review 的重心从结果代码前移到意图表达。维护者可以拿到 prompt，调整约束，放进自己的本地环境，让 Agent 按项目真实风格和边界重新实现。这样既保留了非工程师参与创造的能力，又避免把一大坨未经治理的 AI 代码直接推给主干。

当然，Prompt Request 不是要完全取代 Pull Request。生产代码最终仍然需要 diff、测试、验证和 review。但在 AI 协作里，Prompt Request 可以作为 PR 之前的一层：先审意图，再生代码，再审 diff。

一个好的 Prompt Request 至少应该包含：

• 想解决的问题，而不是只描述想改的代码。
• 相关上下文：页面、接口、用户场景、已有约束。
• 不希望破坏的边界：性能、安全、兼容性、设计风格。
• 验收标准：怎样才算完成，怎样验证。
• 原型或截图：如果有，可以作为意图证据，而不是生产实现。

这对团队文化也有改变。过去贡献的最小单位是代码 diff；AI 时代贡献的最小单位可能变成“清晰的问题表达”。因为代码越来越容易生成，真正稀缺的是把问题讲清楚、把边界讲清楚、把验收讲清楚。

所以，Prompt Request 的价值不是让人少写代码，而是让 AI 生成的代码不要过早进入工程系统。它让想法先被理解，再被实现。

相关：非工程师参与工程流程之后，真正稀缺的是护栏、Mario 的日常 AI 编程工作流、AI Coding Agent 的两派：全自动黑箱 vs 人类主导