今日重点：💬 地道表达——读内核评审最容易犯的一个错， 不是看不懂英文，是分不清哪句必须改、哪句只是口味。 有的意见写着 must，有的是 I would prefer， 还有的看起来像随口一提、其实是在指出硬伤。 今天的材料来自 C-PHY 的两封评审（同一位评审者，前后相隔约 40 分钟）， 软硬两类信号都给全了。
📖 原文（真实邮件，逐字引用）
/ sectionI'm stating a preference of course but I think its better practice to define your constants with names that mean things as frequently we end up reusing constants all over the place.
This statement and how you go about using the data aren't consistent.
出处：Bryan O'Donoghue 的两封评审，均在 linux-media 的 C-PHY 讨论里。 一封是 Re: [PATCH 1/3] phy: core: add generic MIPI C-PHY configuration API（2026-10-18 07:00 北京）， 另一封是 Re: [PATCH RFC 0/6] phy/media: Add generic MIPI C-PHY support to CSI-2 stack（07:39 北京）。 每张卡片下方都给了对应的原文链接。
💬 软信号：怎么把意见降格成「口味」
/ column★ I'm stating a preference of course
原句 I'm stating a preference of course but I think its better practice to define your constants with names that mean things as frequently we end up reusing constants all over the place.
拆解 这一句里叠了三层降格：of course（自认这是主观的）、I think（限定为我的判断）、better practice（说的是「更好的做法」，不是「错误」）。三层叠下来，作者的意思很清楚：这条你可以不改，但我建议改。
顺带一提：原文里的
顺带一提：原文里的
its 应为 it's——内核列表上母语者也会打错字，拼写瑕疵不影响语义判读，别因为一个笔误就怀疑整句的意思。 怎么用 想表达「这只是我的口味」：I'm stating a preference of course / I think it's better practice to … / Personally, I'd prefer …。反过来，读评审时看到这三样中的任何一个，就可以判断：这是软信号，不改也能过。
溯源 原文
★ If possible I would prefer to …
原句 If possible I would prefer to contain 3ph CPHY and DPHY to one file as is done here
拆解 If possible 先把要求变成「如果办得到」；I would prefer 用虚拟语气，比 I prefer 更退一步。两句叠起来，等于说「我很希望这样，但要是不方便，我们可以谈」。prefer 是内核评审里最常用的软动词——它表达倾向而不构成否决。
怎么用 提倾向性建议：If possible I would prefer to … / It would be nice if … / Would it make sense to …? 这些都不构成 blocker。
溯源 原文
💬 硬信号：怎么表达「这条真的不行」
/ column★ This statement and how you go about using the data aren't consistent.
原句 This statement and how you go about using the data aren't consistent.
拆解 整句没有一个软化词：没有 I think、没有 maybe、没有 prefer。它甚至没有说「你错了」，只是陈述一件事——你的说法和你对数据的用法不一致。这在内核评审里就是最高级别的硬信号：不是口味问题，是逻辑矛盾，必须给出解释或修改。注意它仍然保持了礼貌：批评的对象是 statement 和 usage，不是人。
怎么用 指出硬伤时，把情绪删到零，只留事实：X and Y aren't consistent. / This doesn't match the code below. / The comment says A, but the loop does B. 句子里可以没有 must，但对方一定知道要改。
溯源 原文
★ One of you needs to pick up the patches from the other one.
原句 One of you needs to pick up the patches from the other one.
拆解 这是全场最硬的一句——needs to，主语明确（One of you），动作明确（pick up the patches），没有留任何余地。为什么这里可以这么硬？因为这是流程问题，不是技术分歧：两套竞争方案同时挂着，必须有一方放弃并接手对方的工作，否则谁也进不去。评审者在这类问题上通常会说得很直，因为含糊反而浪费所有人的时间。
怎么用 对流程性、不可回避的要求：X needs to … / Please do Y before …。对技术分歧则尽量别用——用 prefer / better practice 留出讨论空间。
溯源 原文
💬 限定知识边界：看起来软，其实是判断
/ column★ To my knowledge the C-PHY specification doesn't mandate …
原句 To my knowledge the C-PHY specification doesn't mandate adjacent LNx as required in a trio.
拆解 To my knowledge 是「据我所知」——它给自己留了一条退路（如果我说错了，你拿规范打我就是）。但这不等于这句话是软的：它后面紧接着就是一个明确的技术判断（规范并不要求 trio 里必须相邻）。读评审时这类句子要特别小心：形式上是限定，内容上是断言。
顺带看一眼同一个人的另一句：Whatever about how DPHY does this in upstream Linux, these values should be …——Whatever about X 是「不管 X 怎么样」，先把对方的先例挡在门外，再讲自己的要求。
顺带看一眼同一个人的另一句：Whatever about how DPHY does this in upstream Linux, these values should be …——Whatever about X 是「不管 X 怎么样」，先把对方的先例挡在门外，再讲自己的要求。
怎么用 不确定但很有把握时：To my knowledge … / I believe … / Unless I'm missing something, …。这三句的共同点是：把判断说出口，同时把纠错的权力交给对方——这是评审里非常成熟的一种姿态。
溯源 原文
💬 收尾：把决定权交回去
/ column★ I'd like the best of both series. Please work out between yourself and Anusha what's next.
原句 I'd like the best of both series. / Please work out between yourself and Anusha what's next.
拆解 两套竞争方案，评审者的处理方式值得学：先说想要什么（两个系列各取所长），再说由谁去定（你们俩自己商量下一步）。他不替两位作者做选择，也不放任他们各写各的——给出了明确的方向和明确的负责人。
怎么用 遇到两方各执一词：I'd like the best of both. + Please work out between yourselves what's next. 前一句定调，后一句定人。
溯源 原文
✨ 辅助彩蛋：trio —— C-PHY 里「三根线一组」
/ section★ lanes / data_lanes / lane_polarities 与 trio
原句 lanes specifies the number of pads in a trio / data_lanes specifies which pads are in those trios / lane_polarities specifies the polarity of each of the given pads
中文与语境 C-PHY 不像 D-PHY 那样按差分对（lane）走，而是三根线组成一个 trio（三线组），靠三相信号编码。所以本文讨论的核心正是：lanes 指的是「一个 trio 里的 pad 数」，data_lanes 指的是「哪些 pad 组成这些 trio」，lane_polarities 指的是「每个 pad 的极性」。这也就解释了为什么代码里会有
lanes % 3 这样的合法性检查——不是三条 lane，而是一个 trio 里的三根线。 记忆钩子 D-PHY 数对，C-PHY 数 trio。看到 C-PHY 代码里的 3，先想 trio，不要想「三条差分对」。
溯源 原文
✍️ 今日练习
/ column✍️ 用英文作答。下面两句出自同一封评审：① I'm stating a preference of course but I think its better practice to define your constants with names that mean things as frequently we end up reusing constants all over the place. ② This statement and how you go about using the data aren't consistent. 请分别判断哪句是「硬要求」、哪句是「个人偏好」，并把其中一句改写成相反的语气（软→硬 或 硬→软），说明你改了哪些词。
💡 显示答案
参考作答（仿写示范，非原文）：① is a preference, not a requirement -- it carries three demoters: I'm stating a preference of course, I think, and better practice. To harden it: These constants must be named meaningfully, because they get reused all over the tree. (I removed the preference marker and the hedge, and used must.) ② is a hard signal: it contains no hedge at all and simply states that the claim and the code disagree. To soften it: I'm not sure the statement matches how the data is actually used -- could you walk me through it? (I added I'm not sure, turned the assertion into a question, and asked for clarification instead of asserting inconsistency.)
📖 原文：I'm stating a preference of course but I think its better practice to define your constants with names that mean things as frequently we end up reusing constants all over the place. / This statement and how you go about using the data aren't consistent.
📎 原文引用 每日一句：In a review, the hard part is not the English — it is telling a requirement from a preference wearing the same polite coat.
仿写示范