Prompt Review 会取代 Code Review？ -- 读《当代码不再稀缺：程序员真正稀缺的是判断力》
## Prompt Review 会取代 Code Review
周末看到[原贴](https://www.v2ex.com/t/1227624)，产生了一些思考：
原文中写到
在开源社区中，学徒制更多体现在 Code Review 的过程中。新人提交代码尝试解决问题，维护者给出反馈。在反复沟通的过程中，整个社区的技术偏好和维护风格得以传承。
这种方式当然很有价值。
但我也在想，随着 AI 开发越来越普及，传统的「学徒制」大概率会被逐渐淘汰。
至少在商业开发团队里，除了交付压力的原因，AI 开发带来的效率提升逐渐成为老板们的预期，会让开发排期进一步缩短。
最终导致留给资深开发者逐行阅读新人代码、反复给出修改意见的时间会越来越少。
以真实例子来说，我们团队因为大部分代码都已经是由 AI 完成编写和测试，已经很少进行传统意义上的逐行 Code Review。在这种工作方式下，团队成员之间的交流，也开始从代码变成 AI 任务本身。
我们内部使用的 AI 开发工具上，项目成员可以看到其他人发起的 AI 任务，包括提示词、上下文、完整对话和执行记录。
一个任务做到一半，其他同事可以直接接着补充，不需要重新从头解释背景。
看一个新人怎么写提示词，也很容易判断他是否真正理解了业务：
- 他有没有说清楚为什么要做这个功能？
- 有没有考虑已有系统的约束？
- 有没有设计测试和验收标准？
- 当 AI 给出一个看起来合理的答案时，他是直接接受，还是会继续追问和验证？
对于一些重要功能，资深同事会先完成问题拆解和第一轮任务设计，确认整体方向后，再交给其他同事继续推进。
新人可以沿着完整的 AI 对话，看到前面的人是怎么理解问题、补充上下文、否定错误方案，以及一步步得到最终结论的。
这有点像以前由架构师先把框架代码搭好，再让其他同事在框架上实现业务。只不过过去传递的是代码结构，现在传递的更多是问题的理解方式、判断过程和验收标准。
所以我感觉，AI 时代的学徒制未必会消失。它可能只是从“看资深同事怎么写代码”、“接受 leader 评审代码”逐渐变成：看其他同事怎么定义问题、怎么指挥 AI，以及怎么判断 AI 到底有没有做对。
### 再深入聊一下逐渐代替 Code Review 的 “Prompt Review”
Pull Request 和 Issues 在以前的开发协作中提供了一套非常成熟的机制。
新人一方面可以提交代码，让资深工程师提出修改意见；另一方面也能主动的阅读其他人写的代码，了解已有的业务逻辑和实现方式。
但代码其实只是思考过程的最终产物。正如原文所说的“缄默知识”：很多真正有价值的经验，很难仅仅通过最终代码完整地表达出来。
虽然我们也可以通过写文档补充这些信息，但从古至今工程师写文档一直是一件很痛苦的事情。文档需要额外维护，而且经常在代码修改后迅速过期。
即使现在可以让 AI 帮忙生成文档，它通常也是根据已经完成的代码、或者是提示词进行二次总结，仍然可能丢失最初的思考过程。
现在每个使用 AI 开发的工程师，都必须不断向 AI 描述自己的需求、业务背景、系统限制、实现目标和验收标准。
这些开发者亲手编写的提示词、上下文、追问、纠正和验收记录，是非常有价值的第一手思考痕迹。
团队成员应该正如以往能够看到相互的代码一样，了解更多：
- 其他人如何向 AI 描述问题；
- 给 AI 提供了哪些业务和技术上下文;
- AI 提出过哪些方案；
- 哪些方案被否定了;
- 最后通过什么方式测试和验收。
除了业务和技术判断，团队还可以共享操作 AI 的方法，例如使用了哪些 Skills、MCP 服务或外部工具。
未来的开发工具，应该不会只局限于代码版本管理和 Issues 管理。
它还需要帮助团队共享成员之间的思考过程，让 AI 深度参与协作，并尽可能减少代码、文档和上下文在人与人之间反复手工传递的成本。（统一管理团队的 token 账号、网络配置也是国内的开发团队需要考虑的问题）
这也是我们内部开发工具的原因：我们希望团队共享的不只是最终代码，还包括任务上下文、完整对话、执行记录和验收过程。
预计月底前开源。有兴趣的话，可以关注后续，也可以翻一下我之前介绍它的帖子。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228509)
周末看到[原贴](https://www.v2ex.com/t/1227624)，产生了一些思考：
原文中写到
在开源社区中，学徒制更多体现在 Code Review 的过程中。新人提交代码尝试解决问题，维护者给出反馈。在反复沟通的过程中，整个社区的技术偏好和维护风格得以传承。
这种方式当然很有价值。
但我也在想，随着 AI 开发越来越普及，传统的「学徒制」大概率会被逐渐淘汰。
至少在商业开发团队里，除了交付压力的原因，AI 开发带来的效率提升逐渐成为老板们的预期，会让开发排期进一步缩短。
最终导致留给资深开发者逐行阅读新人代码、反复给出修改意见的时间会越来越少。
以真实例子来说，我们团队因为大部分代码都已经是由 AI 完成编写和测试，已经很少进行传统意义上的逐行 Code Review。在这种工作方式下，团队成员之间的交流，也开始从代码变成 AI 任务本身。
我们内部使用的 AI 开发工具上，项目成员可以看到其他人发起的 AI 任务，包括提示词、上下文、完整对话和执行记录。
一个任务做到一半，其他同事可以直接接着补充，不需要重新从头解释背景。
看一个新人怎么写提示词，也很容易判断他是否真正理解了业务：
- 他有没有说清楚为什么要做这个功能？
- 有没有考虑已有系统的约束？
- 有没有设计测试和验收标准？
- 当 AI 给出一个看起来合理的答案时，他是直接接受，还是会继续追问和验证？
对于一些重要功能，资深同事会先完成问题拆解和第一轮任务设计，确认整体方向后，再交给其他同事继续推进。
新人可以沿着完整的 AI 对话，看到前面的人是怎么理解问题、补充上下文、否定错误方案，以及一步步得到最终结论的。
这有点像以前由架构师先把框架代码搭好，再让其他同事在框架上实现业务。只不过过去传递的是代码结构，现在传递的更多是问题的理解方式、判断过程和验收标准。
所以我感觉，AI 时代的学徒制未必会消失。它可能只是从“看资深同事怎么写代码”、“接受 leader 评审代码”逐渐变成：看其他同事怎么定义问题、怎么指挥 AI，以及怎么判断 AI 到底有没有做对。
### 再深入聊一下逐渐代替 Code Review 的 “Prompt Review”
Pull Request 和 Issues 在以前的开发协作中提供了一套非常成熟的机制。
新人一方面可以提交代码，让资深工程师提出修改意见；另一方面也能主动的阅读其他人写的代码，了解已有的业务逻辑和实现方式。
但代码其实只是思考过程的最终产物。正如原文所说的“缄默知识”：很多真正有价值的经验，很难仅仅通过最终代码完整地表达出来。
虽然我们也可以通过写文档补充这些信息，但从古至今工程师写文档一直是一件很痛苦的事情。文档需要额外维护，而且经常在代码修改后迅速过期。
即使现在可以让 AI 帮忙生成文档，它通常也是根据已经完成的代码、或者是提示词进行二次总结，仍然可能丢失最初的思考过程。
现在每个使用 AI 开发的工程师，都必须不断向 AI 描述自己的需求、业务背景、系统限制、实现目标和验收标准。
这些开发者亲手编写的提示词、上下文、追问、纠正和验收记录，是非常有价值的第一手思考痕迹。
团队成员应该正如以往能够看到相互的代码一样，了解更多：
- 其他人如何向 AI 描述问题；
- 给 AI 提供了哪些业务和技术上下文;
- AI 提出过哪些方案；
- 哪些方案被否定了;
- 最后通过什么方式测试和验收。
除了业务和技术判断，团队还可以共享操作 AI 的方法，例如使用了哪些 Skills、MCP 服务或外部工具。
未来的开发工具，应该不会只局限于代码版本管理和 Issues 管理。
它还需要帮助团队共享成员之间的思考过程，让 AI 深度参与协作，并尽可能减少代码、文档和上下文在人与人之间反复手工传递的成本。（统一管理团队的 token 账号、网络配置也是国内的开发团队需要考虑的问题）
这也是我们内部开发工具的原因：我们希望团队共享的不只是最终代码，还包括任务上下文、完整对话、执行记录和验收过程。
预计月底前开源。有兴趣的话，可以关注后续，也可以翻一下我之前介绍它的帖子。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228509)
· 0 个赞