一句话定义：LLM-Assisted Patch Series 指的是在邮件列表驱动的开源协作中，让大语言模型（LLM）参与一整串补丁（patch series）的生成、拆分、说明与自查，但最终由人类开发者署名、并对代码负责的工作方式。
为什么是"系列"而不是"一个补丁"
在 Linux 内核、Git 这类项目里，一个功能很少一次性提交。惯例是拆成一串小补丁：先做不改变行为的小重构，再加功能，再补文档与测试，每个补丁都能单独编译通过。然后通过邮件列表（mailing list）发出，由维护者逐个审查（review），常常来回改好几轮。
LLM 能插手的环节很具体：把模糊需求变成初版 diff；把一大坨改动切成合理的几步；写提交信息（commit message）；自己先扮演审查者挑毛病；再根据 review 意见产出修改稿。
打个比方：这像装修。补丁系列就是把一次装修拆成水电、泥瓦、油漆几道工序，每道单独验收，出了问题能定位。LLM 是个出活飞快的实习生，能画图、能列清单，但业主（维护者）只会找设计师（署名者）追责。
和相邻概念的区别
| 概念 | 关注点 | 责任归属 |
|---|---|---|
| LLM 辅助补丁系列 | 一整套改动的拆分与迭代 | 人类署名者 |
| AI 代码生成 | 单段代码产出 | 使用者 |
| AI 代码审查 | 对已有改动挑错 | 维护者 |
| Vibe coding | 快速出可用结果 | 常常模糊 |
关键差别在流程和责任链，而不在"用了没用 AI"。
署名与责任边界
开源项目里常见 Signed-off-by 标签，它不是客套话，而是开发者原产地证书（Developer Certificate of Origin, DCO）式的声明：我有权提交这段代码，并愿意为它负责。代码主要来自 LLM 时，有两件事必须先想清楚：一是这些片段是否与训练数据高度相似、许可证是否清楚；二是"谁按键"和"谁负责"要分开写明。这也是社区讨论用 Assisted-by 之类标签标注 AI 协助、而把 Signed-off-by 留给人类的原因。
对从业者的实际意义
Linux 内核社区对 AI 辅助补丁的态度，大致是从排斥转向"可以，但走同样的评审流程、同样的署名规则"——Linus Torvalds 的公开表态大体是这个意思，细节以邮件列表原文和官方文档为准。信号不是"AI 能写内核了"，而是"流程能容纳 AI，前提是责任不变"。
对普通职场人也一样：AI 交活儿，人交责任。能写清楚"这一步为什么这么改"，比写出能跑的代码更值钱。