今日重点：💬 地道表达——补丁写得再漂亮，也得先过评审这一关。今天四条线程里，四位维护者 其实都在做同一件事：把「不行」说得让人愿意改。这四句真实原话，就是内核社区的「说不」话术。
💬 地道表达：四句「说不」
/ section★ 接受也是表达：一行结束 40 帖
真实原句 Thanks, I've updated mm.git's mm-unstable branch to this version.
中文理解 「谢谢，我已经把 mm.git 的 mm-unstable 分支更新到这个版本了。」——一个 40 帖的大系列，维护者的全部回应 就这么一行。内核社区的「接受」是这个分量：不夸、不复述、不寒暄，一句话交代他做了什么 （updated ... to this version），而不是「你这个补丁写得真好」。
用法 维护者收下补丁的标准句式：
Thanks, I've updated <tree>'s <branch> to this version. 关键在动词——updated ... to this version 是精确的、可核对的动作，比 Looks good, merged. 更有信息量。作者看到这句就知道该去哪个分支找自己的补丁了。 🔗 原文
★ 最软的否定：This sounds a bit overkill
真实原句 This sounds a bit overkill. Also, this series still leaves O(N * C) loops.
中文理解 「这听着有点杀鸡用牛刀。而且这个系列还是留着 O(N * C) 的循环。」——一句话里叠了三个软化装置：
sounds（我只根据读到的判断，不敢断言）、a bit（程度压到最小）、 overkill（用俚语式批评替代生硬的 wrong）。说完立刻补一条技术事实， 把「我的感觉」和「你的问题」分开——批评归批评，依据归依据。 用法
This sounds a bit <形容词> 是否定的最低起手式，常用词还有 heavy / broad / much。注意它只说「听着如何」， 不否定人——留出作者自证的空间。后面那句 still leaves ... 才是真正的技术论点， 两句配合，就构成了「客气 + 有据」的标准评审。 🔗 原文
★ 不赞同做这个功能：I'm not sure I'd bother with ...
真实原句 I'm not sure I'd bother with this !CONFIG_MMU support, tbh
中文理解 「我不确定我会为这个 !CONFIG_MMU 支持费这个劲，说实话。」——
I'm not sure 先给自己留退路， I'd bother with 是「值不值得花力气」的地道说法（不是「我不喜欢」，而是「性价比不划算」）， 句尾 tbh（= to be honest）是邮件里常见的口语收尾，把整句从「评审意见」拉回「同事聊天」的语域。 用法 想说「这个功能不值得做」：
I'm not sure I'd bother with ...；想让对方删代码： 同一封里他写的是 no need to explicitly define them, please drop——no need to 给理由（本来就有，不必重复定义），please drop 提要求。比一句 Remove this. 礼貌得多，但同样是明确的要求。 🔗 原文
★ 长评审先挂摘要：tl;dr + 星号留白
真实原句 tl;dr: I spent way too long looking at this. I think my conclusion is "Hm, this makes some cases of missed Makefile deps on generated files harder to find, but there don't *appear* to be any obviously wrong instances of this in the tree."
中文理解 「太长不看版：我在这上面花了太多时间。我的结论是『嗯，这会让生成文件的 Makefile 依赖漏配更难被发现， 但树里似乎没有明显配错的实例。』」——三处值得学：
tl;dr 是作者给自己 长评审装的「摘要按钮」；I spent way too long looking at this 是自嘲式铺垫（我认真看了， 所以下面的结论值得信）；don't *appear* to be 用星号把 appear 顶出来， 等于说「我没找到反例，但不敢打包票」。 用法 写长评审时先给一行
tl;dr:，让维护者/作者能先抓住结论。要表达「我查过了，但结论留余地」用 there don't appear to be any ...；想更明确一点就把程度副词换成 I couldn't find any ...——后者只声明我找过，不声明「不存在」，这是内核评审 里非常重要的分寸。 🔗 原文
✨ 辅助彩蛋（阅读）
/ section★ 把四句排成一条「软化梯度」
串读 真接受（
Thanks, I've updated ... to this version.）→ 怀疑但留余地 （This sounds a bit overkill.）→ 不赞同做（I'm not sure I'd bother with ...） → 查过但留白（there don't *appear* to be any ...）。注意：没有一句是祈使句， 四句全在描述「我看到了什么」+「我倾向什么」，而不是「你去做什么」。 可学点 真需要作者动手时，他们才换语气——同一位维护者（Kuniyuki Iwashima）在同一封里写的是
Could you try this change ? (only compile-tested)：问句 + 括号里主动交代「我只编译测过」， 既提了要求，也替作者划清了风险边界。陈述用来说服，问句用来请托——这条分界线， 就是内核评审的语感。 🔗 原文
✍️ 今日练习
/ section✍️ 用今天的四个句式，给一个假设的补丁回复写 4 句英文：① 表示接受并说明你做了什么（Thanks, I've updated ...）； ② 觉得某处用力过猛（This sounds a bit ...）；③ 认为某个功能不值得做（I'm not sure I'd bother with ...）； ④ 请作者试一个改动，并交代你的验证程度（Could you try ... (only compile-tested)）。
💡 显示答案
参考（仿写示范，非原句）：Thanks, I've updated the mm tree's mm-unstable branch to this version. This sounds a bit heavy for a fix that only affects one driver. I'm not sure I'd bother with the extra fallback path, tbh — the existing error handling already covers it. Could you try folding this into the first patch ? (only compile-tested)
📖 原文：This sounds a bit overkill. Also, this series still leaves O(N * C) loops. Given unregistering a single device is less common than destroying netns, I think the right approach should be to make the route flush once in cleanup_net() + outside RTNL. Could you try this change ? (only compile-tested)
📎 原文引用 "I'm not sure I'd ..." gets further than "You must ...".
内核英语 · 每日一篇