• 请不要在回答技术问题时复制粘贴 AI 生成的内容
swananan
V2EX  ›  程序员

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

  •  
  •   swananan ·
    swananan · 20h 34m ago · 2822 views
    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 吧。
    24 replies    2026-08-12 05:47:08 +08:00
    cwcc
        1
    cwcc  
       20h 28m ago   ❤️ 9
    说实话如果是 compiler 类型的项目,我认为确实应该人类严格审核处理,每一行代码和文档都非常重要。用 compiler ( prompt->高级语言)去写 compiler (高级语言->低级语言),很难不出问题。这是项目特性决定的。因为 AI 写编译器的来源代码大概率就是这些编译器本身,要么会过拟合要么会欠拟合。
    nullyouraise
        2
    nullyouraise  
       16h 42m ago
    很合理,AI 写的文档一股味,哪怕是我自己的项目 99%代码都是 AI 写的,我不仔细看代码,也会逐行审查注释,并且文档都是手写的,有了 AI 之后提交 PR 的速度比以前快太多了,LLM 可以 24 小时不停地提交低质量内容
    MIUIOS
        3
    MIUIOS  
       16h 40m ago   ❤️ 2
    这种庞大的项目,不严谨难道随便 PR 吗? 随便一个 bug 都是灾难级别的, 这不叫守旧,这叫严谨。
    gumayusi
        4
    gumayusi  
       16h 20m ago   ❤️ 1
    你不用担心表达不准确,如果别人看不懂他们可以用 LLM 润色。你写文档的用 LLM 润色,相当于先把原始语料劣化一遍再发布,是完全多余的操作。B 站有过一个流行的话题,叫《 XXX 用谷歌翻译 20 遍》,可以看出,再标准的语料、再简单的任务,让 AI 多迭代几次就成泔水了。
    AutumnVerse
        5
    AutumnVerse  
       16h 11m ago
    非常赞成。我也是开源作者,一大堆 ai 写的 pr 、issuse ,根本没法处理,看了半天,然后问了半天,发现提 issuse 的人连自己说的什么都不知道,拿 ai 一通瞎 jb 搞就提交了。

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

    还有最关键的,这些 ai 写出来的 pr ,后续没人维护,提 pr 的人随便弄弄就提交,后续就不管了
    cellsyx
        6
    cellsyx  
       15h 58m ago
    个人认为正式项目的入库 PR 代码确实应该手写,AI 在此扮演的最佳角色是对提交的手写代码进行尽可能详细的测试,构造各种边界条件,设想各类极限状况。

    对于编译器或者是商业的生产环境这类严谨的项目,AI 能保证做到的是提升代码质量而不是交付速度。
    L4Linux
        7
    L4Linux  
       15h 54m ago
    这种项目应该官方出 skill ,不符合 skill 的直接拒绝,符合的再 review 。而不是直接拒绝 ai 写某些代码。比如,嫌 ai 生成的代码太多,可以出 skill 让 ai 一次改一小部分。
    hezp
        8
    hezp  
       15h 13m ago
    ai 写的泔水代码还是别参与到开源项目里来了,害人害己,拿去写写玩具 demo 还差不多
    noahliaszn
        9
    noahliaszn  
       15h 10m ago
    至少没否定 AI, 不如你看看其他的项目比如 Zig, 还有些项目直接抵制 AI, 可以 AI assisted 算不错了
    rb6221
        10
    rb6221  
       15h 1m ago   ❤️ 1
    外企的理念跟国内不一样,他们认为文档很重要,某种程度上甚至比代码重要,一个 case 被判定为 bug 还是 feature 很多情况下都是依据文档来的。code 可以有 bug ,但是文档不能有 bug
    所以就衍生出一个问题,你认为文档是边角料工作,正好适合交给 AI 做,那如果文档比 code 更重要呢?还是不是边角料?
    wengjin456123
        11
    wengjin456123  
       14h 55m ago
    rust 这种项目严格一点全是优点吧
    redbule
        12
    redbule  
       14h 53m ago
    其实跟 ai 无关,这都是高质量 pr 的要求罢了。

    就算你手写,烂代码和烂文档也不应该被接受。
    dianqk
        13
    dianqk  
       11h 42m ago via Android
    也可以结合 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
        14
    arischow  
       11h 39m ago via iPhone
    你的理解错误
    xtreme1
        15
    xtreme1  
       11h 34m ago
    编译器出问题, 真的难想到是编译器的问题
    pokstay
        16
    pokstay  
       11h 29m ago via iPhone
    这种底层代码出问题不是影响一两个人,尤其是现在动不动就几千行的 pr ,提 pr 的人都不知道 ai 改了什么
    CatCode
        17
    CatCode  
       11h 27m ago
    有还在读研/读博,或者做老师的?最近收到的审稿邀请里面,AI slop 还少了吗?
    jry
        18
    jry  
       6h 33m ago
    可以用 AI 辅助,来扫描人工写的是否有问题有缺漏,但这种底层项目确实不能直接 AI 写,它是基础设施,实在太重要了,错一点影响太大了。AI 毕竟有幻觉。
    night98
        19
    night98  
       6h 25m ago
    我觉得挺好的,毕竟现在 ai 时代尤其是小白真的很容易一键拉几千行,到时候直接就是 pr 轰炸了,这谁扛得住。
    TrackBack
        20
    TrackBack  
       6h 25m ago
    其实没人对 AI 有偏见,项目的 PR 要求本质上都是对高质量代码的要求,如果你用 AI 写的 PR 和文档别人审查/测试都分辨不了是 AI 生成的,那说明质量确实够好,你用 AI 提高的效率是你自己的收益
    如果某个 PR 一眼就能看出是 AI 生成的,那说明他本身也没在里面花多少功夫,装都不装了,那根本没有花费人力审查的必要
    mooyo
        21
    mooyo  
       5h 50m ago   ❤️ 1
    你自己都不愿意投入精力到这个 PR 上,为什么要求 maintainer 浪费更多的时间来 review 这堆 AI slop 的垃圾?是 maintainer 买不起 codex 和 Claude code 订阅么?
    xuhuanzy
        22
    xuhuanzy  
       4h 57m ago
    我现在就在维护一个使用 rust 的 lua 语言服务器. 对于这种项目修修小 bug 跟添加点小功能其实还是挺好用的, 但一旦稍微上升到小模块级的重构就需要高频人工介入甚至完全不可用, 计划文档写的再好也没用.
    而且现在只有 gpt-5.6-sol 的产出可以勉强看看, 但对这种规模的项目小模块局部调整一次完整循环就大几十刀额度, 我认为大多数 ai pr 不会舍得花费这么多的.
    docx
        23
    docx  
       3h 10m ago via iPhone
    文档手写是合理的,这样至少能让提交者把代码看过一遍了再来提交,不然审计压力全甩给维护者,包袱是很重的
    waldenlaker
        24
    waldenlaker  
       1h 17m ago
    @rb6221 这个就是 agentic coding 下我认为的,在一个 domain knowledge 里面,spec 比代码本身重要。详细准备的 spec 可以生成代码,但是代码本身代表不了这个 domain 里面的 knowledge 。所以,在一个 domain 里面深耕的 domain expert 在 agentic coding 的当下和未来,还是不可取代的。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1069 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 56ms · UTC 23:04 · PVG 07:04 · LAX 16:04 · JFK 19:04
    ♥ Do have faith in what you're doing.