看完了 Rust 开源社区新出的 LLM 政策，感觉差不多是接近 AI Ban 了

[swananan]

https://forge.rust-lang.org/policies/llm-usage.html#llm-usage-policy

这里面有两点，我觉得比较严格，一个是文档必须手写，不能 LLM 直接生成，第二个是 LLM 生成代码想要进，有非常多的限制，包括不能修改核心代码、需要找到愿意 review 的维护者等等。

我感觉我其实已经有点守旧了，比如在非娱乐项目里面提 pr ，pr 描述以及和别人交流，都是自己手写的，有时候担心表达不准确，也是先写了，再用 LLM 润色下。

另外，pr 的 commit 、文档以及代码，我都会一行一行过，不断的让 LLM 调整，直到我满意为止。但文档这玩意，我其实用英文写，还是有点吃力= =，没想到这也得自己写。

当然，我也没给 Rustc 贡献过，只是好奇关注。前两天想尝试提第一个 PR ，优化某个 API 文档的，看到这个新出的政策，默默的删掉了代码😂，等过段时间，我忘记 LLM 生成的文档内容，我重新自己手写，再尝试提交 PR 吧。

[cwcc]

说实话如果是 compiler 类型的项目，我认为确实应该人类严格审核处理，每一行代码和文档都非常重要。用 compiler （ prompt->高级语言）去写 compiler （高级语言->低级语言），很难不出问题。这是项目特性决定的。因为 AI 写编译器的来源代码大概率就是这些编译器本身，要么会过拟合要么会欠拟合。

[nullyouraise]

很合理，AI 写的文档一股味，哪怕是我自己的项目 99%代码都是 AI 写的，我不仔细看代码，也会逐行审查注释，并且文档都是手写的，有了 AI 之后提交 PR 的速度比以前快太多了，LLM 可以 24 小时不停地提交低质量内容

[MIUIOS]

这种庞大的项目，不严谨难道随便 PR 吗？ 随便一个 bug 都是灾难级别的， 这不叫守旧，这叫严谨。

[gumayusi]

你不用担心表达不准确，如果别人看不懂他们可以用 LLM 润色。你写文档的用 LLM 润色，相当于先把原始语料劣化一遍再发布，是完全多余的操作。B 站有过一个流行的话题，叫《 XXX 用谷歌翻译 20 遍》，可以看出，再标准的语料、再简单的任务，让 AI 多迭代几次就成泔水了。

[AutumnVerse]

非常赞成。我也是开源作者，一大堆 ai 写的 pr 、issuse ，根本没法处理，看了半天，然后问了半天，发现提 issuse 的人连自己说的什么都不知道，拿 ai 一通瞎 jb 搞就提交了。

另外 ai 提的 pr ，我也不想看，动不动改几百上千行。洋洋洒洒写了几千字的文档，硬着头皮看完，发现跟没写一样。

还有最关键的，这些 ai 写出来的 pr ，后续没人维护，提 pr 的人随便弄弄就提交，后续就不管了

[cellsyx]

个人认为正式项目的入库 PR 代码确实应该手写，AI 在此扮演的最佳角色是对提交的手写代码进行尽可能详细的测试，构造各种边界条件，设想各类极限状况。

对于编译器或者是商业的生产环境这类严谨的项目，AI 能保证做到的是提升代码质量而不是交付速度。

[L4Linux]

这种项目应该官方出 skill ，不符合 skill 的直接拒绝，符合的再 review 。而不是直接拒绝 ai 写某些代码。比如，嫌 ai 生成的代码太多，可以出 skill 让 ai 一次改一小部分。

[hezp]

ai 写的泔水代码还是别参与到开源项目里来了，害人害己，拿去写写玩具 demo 还差不多

[noahliaszn]

至少没否定 AI, 不如你看看其他的项目比如 Zig, 还有些项目直接抵制 AI, 可以 AI assisted 算不错了

[rb6221]

外企的理念跟国内不一样，他们认为文档很重要，某种程度上甚至比代码重要，一个 case 被判定为 bug 还是 feature 很多情况下都是依据文档来的。code 可以有 bug ，但是文档不能有 bug
所以就衍生出一个问题，你认为文档是边角料工作，正好适合交给 AI 做，那如果文档比 code 更重要呢？还是不是边角料？

[wengjin456123]

rust 这种项目严格一点全是优点吧

[redbule]

其实跟 ai 无关，这都是高质量 pr 的要求罢了。

就算你手写，烂代码和烂文档也不应该被接受。

[dianqk]

也可以结合 https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ 看，我个人认为这不是 AI Ban ，使用 LLM 做各种调研，代码理解辅助我认为完全可以，也很合适。我个人理解这里的重点是：PR 背后的作者是真的认认真真编写这个 PR ，理解自己的修改。我相信每个 Reviewer （包括我）都是真的很认真看 PR 的，但 PR 对面的作者随便糊弄一下确实不太合适。本质上这也是一个社区人们的沟通交流。另外，欢迎提 PR 改进有问题/不合适的地方啊。

[arischow]

你的理解错误

[xtreme1]

编译器出问题, 真的难想到是编译器的问题

[pokstay]

这种底层代码出问题不是影响一两个人，尤其是现在动不动就几千行的 pr ，提 pr 的人都不知道 ai 改了什么

[CatCode]

有还在读研/读博，或者做老师的？最近收到的审稿邀请里面，AI slop 还少了吗？

[jry]

可以用 AI 辅助，来扫描人工写的是否有问题有缺漏，但这种底层项目确实不能直接 AI 写，它是基础设施，实在太重要了，错一点影响太大了。AI 毕竟有幻觉。

[night98]

我觉得挺好的，毕竟现在 ai 时代尤其是小白真的很容易一键拉几千行，到时候直接就是 pr 轰炸了，这谁扛得住。

[TrackBack]

其实没人对 AI 有偏见，项目的 PR 要求本质上都是对高质量代码的要求，如果你用 AI 写的 PR 和文档别人审查/测试都分辨不了是 AI 生成的，那说明质量确实够好，你用 AI 提高的效率是你自己的收益
如果某个 PR 一眼就能看出是 AI 生成的，那说明他本身也没在里面花多少功夫，装都不装了，那根本没有花费人力审查的必要