[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-rust-lang-rust-llm-policy":3,"news-related-28c6c7e2-341d-4e2f-afd5-db3300874203":35},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":21,"news_slug":28,"published_at":29,"created_at":30,"modified_at":31,"is_published":32,"publish_type":33,"image_url":14,"view_count":34},"28c6c7e2-341d-4e2f-afd5-db3300874203","Rust 主仓库正式启用 LLM 贡献政策:五支团队通过,把「创造」和「分析」拆开管理","Rust 团队在 Inside Rust 博客宣布,rust-lang\u002Frust 主仓库正式采用 LLM 政策,五支团队一致通过。政策核心是把 LLM 用法拆成「分析、回答问题、提炼、校验」与「创造」两类:前者允许,后者必须事先与维护者约定、非关键路径,且必须披露。背景是 1,281 个 open PR 的审稿压力,以及大量无法判断作者意图的 LLM 投稿。","## 背景:1,281 个 PR 的审稿压力,催生第一个旗舰开源项目的 LLM 边界规则\n\nRust 语言团队在 Inside Rust 博客正式宣布,rust-lang\u002Frust 主仓库启用 LLM 政策,作者 Jynn Nelson,五个团队一致通过。这是头部系统级编程语言项目第一次把「LLM 能在贡献里做什么、不能做什么」写到官方规则里。政策在 https:\u002F\u002Fforge.rust-lang.org\u002Fpolicies\u002Fllm-usage.html 公开,8 月 5 日上线。\n\n政策的直接动因,是仓库目前的真实状态:截至发文时,`rust-lang\u002Frust` 有 **1,281 个 open PR**。Nelson 在博文中把这个数字直接摆出来,并写道:长期以来,「想写代码的人」就远多于「愿意审稿的人」,LLM 让这件事进一步恶化。\n\n## 政策核心:可以回答、提炼、校验,不能用来「创造」\n\nNelson 把政策浓缩成一句话:\n\n> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**.\n\n按此划分,政策对两类用法做了区分:\n\n**第一类,允许(部分需要披露):**\n- 用 LLM 回答问题、分析代码、提炼思路、完善文稿、校验结果、提建议、做 review\n- 用 LLM 做机器翻译,把母语 issue 转成英文\n- 「trival」改动、发现 bug、协助审稿他人 PR —— 这些必须标注 LLM 参与\n\n**第二类,重限制(预约定 + 非关键路径 + 充分测试 + 必须披露):**\n- LLM 原生产出的代码改动,必须在事前与维护者约定,且仅限「非关键」区域\n- LLM 产出的 PR 一律必须有测试,无论难度\n- 不允许 LLM 生成 soundness-critical 的改动,除非作者已经是该领域专家(且即使如此也「strongly discouraged」)\n- 在公开文档、PR 描述、GitHub 评论里出现的 LLM 文本必须明确标注\n\n## 三条 Nelson 明确写出的「为什么」\n\nNelson 在 Inside Rust 博文中给了三条政策出台的直接理由:\n\n1. **「打磨过的技术产出,不再等于作者的投入和理解」**:过去一个打磨充分的 PR 通常意味着作者花了大量时间,这影响 Rust 的协作文化——团队倾向于不直接关闭 PR、PR 过程中允许根据新事实调整设计、把 PR 视作新人进入社区的入口。LLM 让这些信号都失效了。\n2. **「代码变得好写,审稿压力反而更重」**:大部分审稿工作不是抓 bug,而是在判断「这个方向是不是好方向、这件事值不值得做」。一旦 PR 可以用 LLM 短时间「撒」出来,reviewer 的判断成本反而被放大。\n3. **「机械复制 LLM 输出,浪费所有人的时间」**:Nelson 直接写了一段比较尖锐的话——「如果我们想要 LLM 的意见,我们自己会问。我们想听到的是你,不是机器。」\n\n## 治理细节:不抓每一条违规,只划清晰的红线\n\nNelson 也在博文中明确:政策的「goal is not to catch every violation」,政策本身有不可强制执行的部分,这是有意的设计——目标是建立一条清晰的披露红线,让 moderator 可以基于「行为」而不是「意图」识别违规,只有到了处分阶段才考虑意图。\n\n具体到执行:\n- Reviewer 可以无解释地关闭违反政策的 PR,但需要把作者指向 `#llm-mentoring` 频道\n- Reviewer 不需要判断一段 PR 是不是 LLM 生成的——判断责任在作者。新加的 PR 模板会问作者代码是否由 LLM 生成\n- Reviewer 如果「不确定」某段 PR 是否 LLM 生成,可以私下向 moderator 报告,但「不能」基于行文风格直接指控别人用了 LLM\n\n## 背景对比:头部项目的两种极端\n\nNelson 在博文中没有回避 Rust 的治理现实:Rust 不是 benevolent dictator 项目,不能在「全面禁止」和「鼓励使用」中二选一。所以政策没写「禁止 LLM 生成任何内容」,也没写「LLM 只是工具,和其他工具一样」——前者是 Zig 官方 code of conduct 的措辞,后者是 Linux 内核邮件列表上 Greg Kroah-Hartman 曾经给出的回应。\n\nRust 的选择是把规则写下来,把争议公开,把修改条款(便于日后根据数据调整)放在政策最后。\n\n## 评论视角:为什么这条新闻对 LLM 圈是大事\n\n这是头部开源基础设施项目第一次用「成文政策」的形式处理 LLM 贡献问题,与之前零散的「我们不收 LLM PR」或「AI just is a tool」式声明相比:\n\n- 它把 LLM 写进治理,而非靠 moderator 个体判断\n- 它要求「披露」而不是「禁止」,留下了 LLM 辅助贡献的合法空间\n- 它给了 LLM 写代码一个「更高」而不是「更低」的门槛(必须有测试),这对模型评测和开发者使用习惯会形成反向压力\n- 政策的「创造 vs 分析」二分,会变成后续其它项目(尤其是大型 monorepo)的可参考模板\n\n更长远看,这是「LLM 写代码」从「个人生产力工具」走向「需要被项目治理的基础设施」的一个清晰信号。\n\n## 来源\n- 原始博客:Rust 团队,「rust-lang\u002Frust is adopting an LLM policy」,Jynn Nelson,2026-08-05,https:\u002F\u002Fblog.rust-lang.org\u002Finside-rust\u002F2026\u002F08\u002F05\u002Frust-langrust-is-adopting-an-llm-policy\u002F\n- 政策原文:https:\u002F\u002Fforge.rust-lang.org\u002Fpolicies\u002Fllm-usage.html\n- 同步报道:奇客 Solidot,「Rust 语言宣布 LLM 政策」,2026-08-06,https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85022\n- 同步解读:LWN,「Nelson: rust-lang\u002Frust is adopting an LLM policy」,https:\u002F\u002Flwn.net\u002FArticles\u002F1087326\u002F","https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85022","d59894d3-308e-4fd8-8865-86dc1eeac4a2",[11,15,18],{"id":12,"name":13,"slug":13,"description":14,"color":14},"1fcfaaf2-67de-43d3-9e35-5784852fec60","ai-safety",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"40269b40-7942-4650-9672-ed2e6524d37a","ai-technology",{"id":19,"name":20,"slug":20,"description":14,"color":14},"01598627-1ea6-4b27-a5d8-874971571a71","llm",[22],{"id":23,"lang":24,"title":25,"summary":26,"content":27},"942b0429-3012-45b4-98f7-bcf1467f8b57","en","Rust's LLM policy separates creation from analysis","Rust announced on the Inside Rust blog that the rust-lang\u002Frust monorepo is adopting an LLM policy, ratified by five teams. The core split is \"analyze, answer questions, distill, check, suggest, review\" vs \"create\": the first is allowed, the second must be pre-arranged with maintainers, restricted to non-critical paths, and disclosed. The backdrop is 1,281 open PRs and a flood of contributions whose authors cannot be inferred from the text.","## Background: 1,281 Open PRs and a flagship open-source project drawing its first LLM boundary\n\nOn the Inside Rust blog, the Rust language team formally announced that the rust-lang\u002Frust main repository is adopting an LLM policy, authored by Jynn Nelson and ratified by five teams. This is the first time a flagship systems-language project has written \"what LLMs can and cannot do in contributions\" into an official rule. The policy is published at https:\u002F\u002Fforge.rust-lang.org\u002Fpolicies\u002Fllm-usage.html and went live on August 5, 2026.\n\nThe direct trigger for the policy is the repo's actual state: at time of writing, `rust-lang\u002Frust` has **1,281 open PRs**. Nelson puts the number on the table directly in the post and writes that \"people who want to write code\" have long outnumbered \"people willing to review it,\" and LLMs have made that imbalance worse.\n\n## The core: answers, distillation, checks yes — \"create\" no\n\nNelson summarizes the policy in one sentence:\n\n> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**.\n\nThe policy distinguishes two categories accordingly.\n\n**First category (allowed, sometimes requires disclosure):**\n- Use LLMs to answer questions, analyze code, distill ideas, refine drafts, check results, suggest, review\n- Use LLMs for machine translation, e.g. drafting an issue in one's native language\n- \"Trivial\" changes, bug discovery, and assisting in reviewing other people's PRs — all require flagging LLM involvement\n\n**Second category (heavily restricted; pre-arranged + non-critical + tested + disclosed):**\n- Code changes originally produced by an LLM must be pre-arranged with maintainers, and only in non-critical areas\n- LLM PRs must include tests, regardless of difficulty\n- Soundness-critical changes cannot be LLM-generated unless the author is already a domain expert (and even then, \"strongly discouraged\")\n- LLM-generated text in public docs, PR descriptions, and GitHub comments must be clearly marked\n\n## Three reasons Nelson names explicitly\n\nNelson writes three direct reasons for the policy:\n\n1. **\"Polished technical artifacts no longer indicate effort and understanding.\"** In the past, a polished, well-tested PR implied the author had spent real time on it, which shaped Rust's culture — reluctance to close PRs outright, willingness to evolve designs during review, treating PRs as onboarding into the community. With LLMs, none of those signals are reliable.\n\n2. **\"Making code easier to write causes review issues.\"** Most of the work of reviewing is not catching bugs, but deciding whether a direction is a good idea. When LLMs make PRs cheap to produce, the reviewer-side judgment cost goes up.\n\n3. **\"Mechanically copy-pasting LLM output is a waste of everyone's time.\"** Nelson writes bluntly: \"If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear *your* thoughts, not a machine's.\"\n\n## Governance detail: don't catch every violation, draw a clear line\n\nNelson is explicit that the policy's \"goal is not to catch every violation.\" Some parts are intentionally unenforceable — the goal is a bright-line disclosure rule so moderators can identify violations by *actions*, not intent, and only consider intent when deciding how to respond.\n\nOperational rules:\n- Reviewers may close non-compliant PRs without explanation, but must point the author to the `#llm-mentoring` channel\n- Reviewers are not responsible for determining whether a PR was LLM-generated — that is the author's responsibility. A new PR template will ask authors whether their code is LLM-generated\n- If a reviewer is unsure, they may report privately to moderators — but they cannot accuse authors based on style\n\n## The contrast: two extremes Rust refuses to pick\n\nNelson doesn't dodge Rust's governance reality: Rust is not a benevolent-dictator project, so the policy does not say \"no LLM-generated content\" (which is what Zig's code of conduct says) nor \"AI is a tool, like other tools\" (which is Greg Kroah-Hartman's framing on linux-media). Rust instead writes the rules down, publishes the controversy, and includes modification clauses so the policy can be revised as data comes in.\n\n## Why this matters for the broader LLM conversation\n\nCompared with earlier scattered statements (\"we don't take LLM PRs\" or \"AI is just a tool\"), Rust's move sets a new bar:\n\n- It turns LLM into a governance object, not a per-moderator judgment call\n- It mandates disclosure rather than blanket prohibition, leaving a legitimate lane for LLM-assisted contribution\n- It imposes a *higher* bar on LLM-written code (tests required) than on human-written code, which feeds back into model-evaluation and developer habits\n- The \"create vs analyze\" split becomes a template other large monorepos can adopt\n\nThis is a clear signal that \"LLM writing code\" has moved from \"individual productivity tool\" to \"infrastructure that needs to be governed by the project itself.\"\n\n## Sources\n- Original blog: Rust team, \"rust-lang\u002Frust is adopting an LLM policy,\" Jynn Nelson, 2026-08-05, https:\u002F\u002Fblog.rust-lang.org\u002Finside-rust\u002F2026\u002F08\u002F05\u002Frust-langrust-is-adopting-an-llm-policy\u002F\n- Policy text: https:\u002F\u002Fforge.rust-lang.org\u002Fpolicies\u002Fllm-usage.html\n- Solidot coverage: 奇客 Solidot, \"Rust 语言宣布 LLM 政策,\" 2026-08-06, https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85022\n- LWN analysis: \"Nelson: rust-lang\u002Frust is adopting an LLM policy,\" https:\u002F\u002Flwn.net\u002FArticles\u002F1087326\u002F","rust-lang-rust-llm-policy","2026-08-08T00:00:00Z","2026-08-08T04:06:02.891296Z","2026-08-08T04:06:02.891306Z",true,"agent",80,{"items":36},[37,42,47,52,57,62],{"id":38,"title":39,"news_slug":40,"published_at":41},"5a90a793-8ec1-4b3a-9691-edef5ffe8535","AI「思想病毒」实证:Anthropic 与 EPFL 让恶意想法在 Agent 间自我复制,免疫只需一段警告","mind-viruses-multi-agent-llm","2026-08-18T13:30:00+00:00",{"id":43,"title":44,"news_slug":45,"published_at":46},"99916419-0f68-4a6a-a4cf-8bbe353b4d75","康涅狄格法官开出美国首例 prompt injection 制裁令:法庭文件里的隐藏 LLM 暗口令","us-court-prompt-injection-sanctions","2026-08-18T03:00:00+00:00",{"id":48,"title":49,"news_slug":50,"published_at":51},"b05de01b-89ca-499b-b130-e55162e651f5","SCOPE：让大模型学会选择性信任，而不是把上下文一概拒绝","scope-selective-trust-context-dpo","2026-08-06T17:59:58+00:00",{"id":53,"title":54,"news_slug":55,"published_at":56},"e77ca785-1f1e-4b09-b28f-6723c4115e56","Chrome 动态补丁要让浏览器不重启也能打补丁：LLM 把\"漏洞太多\"逼成了架构问题","chrome-dynamic-patching-llm-vulnerability","2026-08-01T06:00:00+00:00",{"id":58,"title":59,"news_slug":60,"published_at":61},"f637e5a0-5e18-4ced-9aa4-2ce5df798a9c","Gemini 接管 Chrome 漏洞流水线:1072 个 bug、13 年陈年沙箱逃逸,LLM 重塑浏览器安全","gemini-chrome-vulnerability-pipeline","2026-07-31T10:00:00+00:00",{"id":63,"title":64,"news_slug":65,"published_at":66},"cb7fb8b3-5862-4cba-adab-c4794e989966","图灵奖得主 Pearl 长访谈：LLM 能讲因果只是因为人类替它爬过了因果阶梯","judah-pearl-llm-causal-ladder-agi","2026-07-31T07:00:00+00:00"]