前几天，有位老哥向开源项目OpenCut提交了一个12w行代码的pr，被人发现分享在国外的论坛，引发大量的围观，观摩地址
程序员看了这个pr都玩起了梗，高呼LGTM
LGTM是啥意思呢，就是类似我们的拼音缩写，完整为(Looks Good To Me)，意思是我看着很好，在PR审查也意味着可以合并。
这里也分享一些其他缩写：
- PR: Pull Request 代表拉取分支修改后的和合并请求
- CR: Code Review 代码审查
- CC: Carbon Copy 抄送
- RFC: Request For Comment 征求意见或评论
- SGTM: Sounds Good To Me 意思和LGTM差不多
- WIP: Work In Progress 意思我还在开发中，不要合并，你可以看看部分代码
- PTAL: Please Take A Look 请看一眼，请求维护者过来审核
- TBR: To Be Reviewed 提醒维护者审查代码
- TL;DR: Too Long; Didn't Read 太长了，别看了，提醒代码过长
- TBD: To Be Done 还没做，或者未完成
被围观了之后老哥还是很有热情，也开始删减自己的代码并且还在不断的提交代码
甚至有程序认真地看了这个pr并提出意见
从这里可以看到，老哥为啥会产生如此大的提交。老哥的代码都是通过Ai修改生成的，也是Vibe Coding（氛围编程），氛围编程主要由AI完成。开发者向AI提出需求，只要代码能正常运行，开发者便不经详细检查直接应用。当代码出问题时，要求AI修改。
有人统计了整个pr，总共包含12.8万行代码，但大部分是AI生成的文档（8.6万行，占 68%）。此外，它还包含9万行AI生成的测试代码（占 7%）。因此，实际代码只有3.2万行（占 25%）。并且文档也不是易懂，可能有很多的中文注释的原因。也存在一些bug。
当然，合并这个巨大的pr显然是不可能的，这个老哥也是在最后关闭了合并请求
这个老哥始终都是积极的，标题也是 "想帮忙但需要一些帮助"，大伙也是在积极的讨论，同时这件事也给了我们很多的思考：
如何正确的提交pr
- 查看贡献指南，一般都会有个
Contributing Guide的文档，了解具体的开发环境，操作步骤等 - fork仓库代码并创建一个修改的分支
- 对代码进行修改，一般是实现一个新功能或者修复一个bug，并添加相应的单元测试等代码
- 提交代码，使用规范的git commit message，可以参考Angular的规范
- 提交pr，等待维护者review和合并即可
提交的代码维护者都会进行审查，如果代码可读性很差或者代码很大无疑增加了审核的成本，所以也大大降低了合并通过的可能性，所以尽量保持小范围的修改和详细的文档和完整的单元测试。
该如何使用AI
前不久和朋友吃饭，他说领导叫他一天完成一个网站，他说一天完成不了，领导说你不会使用AI生成吗，他无奈的去用AI生成了，结果生成的代码并不能完整运行，最后还是自己完成。在现在的AI风潮下，确实很多人形成了有了AI我也可以随意开发的意识，我也看到很多文章"使用xxx一个小时/一天开发一个xxx"，无不提供一种有了AI开发应用就成了很简单的事情，但是一看无非也是一些小工具类的应用。这种小工具应用的可容忍程度还是比较高的，因为功能还是比较简单，并且有很多可替代方案，所以用AI去生成也是比较合适的，但我们还是得正确的认识AI。
AI不能完全的提高我们的编程质量，但可以提高我们的编程的效率。AI能做的是能够快速帮我提供一个思路与方向，我们应该把AI当做一个工具，而不是完全开发的替代。但是，这也是AI工具开发者的一种挑战，如何产出高质量代码应该是AI工具研发的主要方向。