Initial commit

2026-07-20 15:26:30 +08:00
commit 5629342035
11 changed files with 1316 additions and 0 deletions
--- a/learnings/2026-07-18-001-research-taste-in-vibe-coding.md
+++ b/learnings/2026-07-18-001-research-taste-in-vibe-coding.md
@@ -0,0 +1,121 @@
+---
+id: 2026-07-18-001
+date: 2026-07-18
+status: distilled
+tags: [research-taste, vibe-coding, abstraction, research-judgment, ai-assisted-research]
+sources: [user-provided essay]
+references:
+  - "Pierre Bourdieu, Distinction: A Social Critique of the Judgement of Taste"
+  - "Richard Hamming, You and Your Research"
+  - "Paul Graham, Taste for Makers"
+---
+
+# Vibe coding 时代的科研品味
+
+## 原始输入
+
+> vibe coding 出来之后，科研效率确实提升了不少。之前科研能力大概可以分成两部分，一部分是操作能力，能迅速实现 idea，查文献，写代码，论文写作。另一部分是科研 taste，阅读文献，提出问题，把控方向，解读结果。现在 vibe coding 基本上把前一部分跑通了，那对大部分人来说，拥有好的科研品味就变成了更重要的事。
+>
+> 那么什么是好的科研品味呢？
+>
+> 这个问题我最近一直在想。当你看到一个结果不符合预期，这到底是 bug，还是说你发现了一个新的现象？这个结果是有问题的还是有意义的？什么算好的科研品味呢，是好发文章的，还是可以工业化落地的，还是现在最热门的？这些问题都没有标准答案，但又实实在在地影响着每一个研究者的选择。
+>
+> 之前看过一个博主说的，同一个实验有两种摘要写法。第一种是，用 AAA 方法在 BBB 任务上取得了 CCC 效果。第二种是，DDD 是 EEE 一个重要的共性问题，BBB 任务可以作为 DDD 问题的一个 benchmark，基于 BBB 任务，我们验证了解决 DDD 问题的一个有效方法 AAA，并且取得了 CCC 效果。第二种写法显然彰显着更好的科研品味。
+>
+> 但仔细想想，这种差距到底在哪？第一种写法只是在报告一个事实，方法 A 用在任务 B 上，得到结果 C，事情就结束了。第二种写法其实在讲一个故事，它从一个共性问题出发，把具体任务当成理解这个问题的窗口，把方法当成解决这类问题的尝试。同样一个实验，两种写法指向的是两种很不一样的研究思路。一种是解决一个具体问题就完事了，另一种是通过这个具体问题去触碰一个更大的东西。
+>
+> 到目前为止，我觉得好的科研品味就是把一系列问题抽象成一个共性问题，然后提出一个方法来解决这一类共性问题。但我的认识肯定是浅显而又片面的。
+>
+> 从抽象这个角度，我又想到，科研品味和审美可能又是一样的，它没有一个明确的 benchmark，但总会被分出是否高级。这个想法让我去查了一些资料，也重新读了一下 Bourdieu 的 Distinction: A Social Critique of the Judgement of Taste。
+>
+> Bourdieu 那本书讲的是法国社会的文化品味。他的核心观点挺让人不舒服的：品味从来就不是纯粹个人的事，它总是和阶层纠缠在一起。他用大量数据表明，上层阶级偏好抽象的、形式化的艺术，中层阶级追求那些看起来有文化但又够得着的东西，下层阶级倾向于实用的、功能性的审美。这种分层看起来像是天然的，但实际上是被社会再生产机制不断强化的。品味在这里变成了一种区分工具，标榜某些东西为高级，另一些东西为低级，从而维护特定群体的地位。
+>
+> 科研品味有没有类似的逻辑？我觉得是有的，但又不太一样。能从具体问题中抽象出共性规律的研究，确实比只报告特定场景结果的研究有更高的科学价值，这背后有科学本身的内在要求在起作用，科学追求的就是一般性。但同时我们也得警惕，当某些研究范式被标榜为高级，某些方向被贬低为工程性工作的时候，这种区分到底是因为它真的更有科学价值，还是因为学术权力结构在起作用？一个刚入门的研究者选了一个实际的、可落地的问题，这本身没什么可指摘的，只要他对这个问题的理解足够深，能从中提炼出有意义的东西。
+>
+> Bourdieu 给我的一个提醒是，不要把品味当成某种天然的、与生俱来的东西。品味是在特定条件下被塑造出来的。认识到这一点，也许能让我们更清醒地看待自己的科研品味，看看它有多少是基于真正的理解，又有多少是被某种隐性的学术等级制度影响的。
+>
+> 那么品味到底怎么培养？
+>
+> Richard Hamming 在他那个很有名的演讲 You and Your Research 里讲过一个事。他在午餐时间反复问同事，你们领域最重要的问题是什么？然后追问，你为什么不去解决它们？这种追问看起来简单，但我觉得它本质上是一种品味训练，它逼你从日常的技术细节里抬起头来，去想什么是真正重要的。Hamming 还强调了勇气。品味不只是知道什么是好的，还得有胆量去追求好的。很多人其实能分辨哪些问题更重要，但他们选了安全的、好发的、风险小的课题。品味和勇气大概是绑在一起的。
+>
+> Paul Graham 在 Taste for Makers 里提了几个好品味的特征，简洁、对称、启发性、必然性、适用范围。我觉得这些虽然说的是设计和编程，但放在科研里也成立。一个好的研究问题应该简洁，不故弄玄虚。一个好的理论框架应该有某种内在的和谐。一个好的实验结果应该能引发新的问题。一个好的方法应该让人觉得，解决这个问题就该是这个路子。一个好的抽象应该能覆盖一类问题，而不是只对一个特例管用。
+>
+> 至于怎么培养，我自己的体会大概是这样：先大量读经典论文，主要不是为了获取信息，而是为了感受什么是好的研究。然后试着复现这些工作，在复现的过程中理解作者的每一个选择。接着在自己的领域里模仿这种选择的风格。等到经验积累到一定程度，大概会慢慢长出自己的判断标准。这个过程和学画画、学写作、学音乐可能没什么本质区别，都得先看大量好的东西，然后动手模仿，最后才可能有自己的风格。
+>
+> vibe coding 出来之后，我觉得对科研品味的要求其实是更高了，而不是更低。当操作能力的门槛降低，进来的人变多，竞争加剧，判断能力的权重就更大了。这有点像摄影术发明之后，绘画并没有死掉，反而走向了印象派和抽象艺术。当记录现实变得廉价，表达和判断就变成了更稀缺的东西。
+>
+> AI 工具可以帮你写代码，但它很难告诉你应该解决什么问题。它可以帮你检索文献，但它很难告诉你哪些文献是真正重要的。它可以帮你润色论文，但它很难告诉你你的研究故事该怎么讲。而且更有意思的是，AI 工具本身也需要品味来驾驭。一个好的 prompt 和一个平庸的 prompt 之间的差距，某种意义上就是品味的差距。你知道什么是好的，你才能引导 AI 去做出好的东西。
+>
+> 写到这里，回到最初的问题，什么是好的科研品味？
+>
+> 我想了想，大概就是能识别出哪些问题值得被解决，能从这些问题里抽象出共性结构，能设计出有普遍意义的解决方案，能用一种开放的、有启发性的方式把这个研究故事讲出来。这些能力加在一起，大概就是我理解的科研品味。
+>
+> 当然，我的理解肯定是片面的。Bourdieu 说品味是被社会建构的，Hamming 说品味需要勇气来支撑，Paul Graham 说品味有可以讲出来的内在标准。这些角度放在一起，也许能帮我们看得更清楚一些。在 vibe coding 时代，操作能力被民主化了，判断能力变得越来越重要。而判断能力的深度，大概取决于我们对什么才是真正重要的问题的理解，以及我们有没有勇气去解决它们。
+
+## 内容蒸馏
+
+这篇思考把科研能力区分为两层：一层是实现 idea、检索文献、写代码和写论文等操作能力；另一层是选择问题、把控方向、解读结果和组织研究叙事的判断能力。vibe coding 显著降低了前一层的门槛，因此后一层——科研 taste——变得更稀缺、更能决定研究差异。
+
+用户当前对好科研品味的工作定义包含四个连续动作：识别值得解决的问题，从具体问题中抽象共性结构，设计具有普遍意义的解决方案，并以开放、有启发性的方式讲清研究故事。具体任务不是孤立终点，而是观察和验证更大共性问题的窗口。
+
+文中同时拒绝把“抽象”未经反思地等同于“高级”。科学确实追求一般性，但研究范式的声望也可能受学术权力结构塑造。实际、工程性或可落地的问题并不因此低级；关键在于理解是否足够深入，以及能否从中提炼出有意义的认识。
+
+文中借三组思想扩展了这一判断：
+
+- Bourdieu：品味会被社会条件和阶层结构塑造，因此需要反思自己的判断究竟来自理解还是隐性的等级制度。
+- Richard Hamming：持续追问领域中最重要的问题，并有勇气承担风险去解决它；品味不仅是分辨能力，也需要勇气支撑。
+- Paul Graham：简洁、对称或内在和谐、启发性、必然性和适用范围，可以作为科研 taste 的启发式特征。
+
+培养路径是“经典输入—动手复现—理解选择—模仿风格—形成自己的判断标准”。AI 可以放大操作效率，但不能自动替代对重要性、意义和质量的判断；驾驭 AI 本身也需要先知道什么是好的。
+
+## Taste 信号
+
+### 明确偏好
+
+- 好科研首先要能识别值得解决的问题，而不是只追逐好发表、可落地或当前热门中的某一个标签。
+- 好研究应从一系列具体问题中提炼共性问题，并尝试提供对一类问题有普遍意义的方法。
+- 研究叙事应把具体任务放在更大的共性问题中解释：问题为何重要、任务为何能作为 benchmark、方法解决了什么、结果说明了什么。
+- 评价研究时重视简洁、内在一致、启发性、必然性和适用范围。
+- 不把实际、可落地或工程型问题天然视为低级；更看重理解深度以及能否提炼出有意义的认识。
+- 对研究范式的“高级感”保持反思，区分真实科学价值与学术等级制度造成的区分。
+- 科研品味需要通过经典论文、复现、理解作者选择、模仿和长期经验来培养，并需要勇气去选择真正重要而非仅仅安全的课题。
+- 在 AI 降低操作门槛后，应把更多注意力放在问题选择、方向、结果解释、重要文献识别和研究叙事等判断任务上。
+
+### 推断信号
+
+- Agent 辅助科研时，应主动暴露问题选择、抽象层次、结果解释和叙事结构中的关键判断点，而不只是把实现任务做完。
+- 面对违反预期的结果，不应凭直觉立即归类为 bug 或新现象；应先验证实现和实验不变量，再判断它是否揭示了值得研究的现象。
+- 评审“共性问题”叙事时，应检查它是否由证据和真实机制支撑，防止用宏大包装冒充一般性贡献。
+
+### 领域知识
+
+- 文中把科研能力分析为操作能力与科研 taste 两部分，并判断 vibe coding 已显著压低前者的门槛。
+- 文中使用 Bourdieu 对文化品味与阶层再生产的分析，解释科研 taste 也可能受到社会结构和学术权力影响。
+- 文中使用 Hamming 对重要问题与勇气的追问，以及 Paul Graham 对 maker taste 的特征，构成科研品味的训练与评价框架。
+- 上述外部作品内容来自用户在本次输入中的转述，本记录未独立核验原著。
+
+## 边界与反例
+
+- 用户明确说明这是当前且可能片面的理解，应作为可演进的工作定义，而不是封闭的最终标准。
+- 抽象和适用范围更广通常具有科学价值，但不能仅凭更宏大的措辞判断研究更好；需要验证抽象是否真实、方法是否解决了对应问题、结果是否提供足够证据。
+- 具体或工程性工作并非反例。只要对问题理解足够深，并能产生有意义的认识，它仍然可以体现好的科研品味。
+- “好发表”“能落地”“热门”可能是合理约束或目标，但文中不把任何一项单独视为好 taste 的充分条件。
+- 文中提出了“异常结果是 bug 还是新现象”的关键问题，但没有给出通用判定流程；后续需要用实际案例继续学习。
+
+## 可执行影响
+
+- 在选题或 review 前先回答：问题为什么重要？它是否超越单个任务？具体 workload 或 benchmark 如何代表共性问题？
+- 在设计方法时检查：方法解决的是一个特例，还是可解释的一类问题？适用范围与失败边界是什么？
+- 在解释异常结果时先做正确性核验，再比较替代解释；证据不足时标记 `NEEDS EVIDENCE`，不急于把异常包装成发现。
+- 在组织摘要、proposal 或论文故事时使用“共性问题—具体窗口—解决方法—结果证据”的主线，同时避免超出证据的 claim。
+- 在评价工程型研究时同时检查端到端价值、理解深度和可迁移认识，不因其可落地或具体而降低评价。
+- 使用 AI 时让其承担可验证的操作工作，并要求它显式呈现选题、抽象、文献重要性、结果解释和研究叙事中的判断及其依据。
+- 培养 taste 时优先深读经典、复现并解释作者的选择，再模仿其决策方式；定期追问本领域真正重要的问题以及为何尚未解决。
+
+## 画像更新
+
+- 新增：[科研选题 / 先问重要性，再寻找共性结构](../TASTE.md#科研选题--先问重要性再寻找共性结构)
+- 新增：[科研表达 / 用问题—窗口—方法—证据组织故事](../TASTE.md#科研表达--用问题窗口方法证据组织故事)
+- 新增：[科研评审 / 重视简洁、内在一致、启发性、必然性与适用范围](../TASTE.md#科研评审--重视简洁内在一致启发性必然性与适用范围)
+- 新增：[科研价值 / 不以抽象之名贬低实际问题](../TASTE.md#科研价值--不以抽象之名贬低实际问题)
+- 新增：[AI 协作 / 把稀缺注意力放在判断而非操作上](../TASTE.md#ai-协作--把稀缺注意力放在判断而非操作上)
--- a/learnings/2026-07-18-002-do-not-benchmark-against-yourself.md
+++ b/learnings/2026-07-18-002-do-not-benchmark-against-yourself.md
@@ -0,0 +1,71 @@
+---
+id: 2026-07-18-002
+date: 2026-07-18
+status: distilled
+tags: [benchmarking, baseline, self-comparison, simulation, research-validity]
+sources: ["https://gernot-heiser.org/benchmarking-crimes.html#self"]
+references: []
+accessed: 2026-07-18
+---
+
+# 不要只和自己做 benchmark
+
+## 原始输入
+
+> 学习：https://gernot-heiser.org/benchmarking-crimes.html#self
+
+- 直接来源：[Gernot Heiser, Systems Benchmarking Crimes — Only evaluate against yourself](https://gernot-heiser.org/benchmarking-crimes.html#self)
+- 访问日期：2026-07-18
+- 学习范围：以 `#self` 锚点对应的小节为主，并读取相邻的 proper baseline 段落以确定上下文。
+
+## 内容蒸馏
+
+“Only evaluate against yourself” 是 improper comparison of benchmark results 的一种。只证明当前系统比自己的旧版本更快，说明内部取得了进步，但没有给读者一个足以判断该进步是否重要、是否有竞争力、是否接近合理上界的外部参照。
+
+正确 baseline 不是固定答案，而是由 claim 决定。它可能是公认标准或当前 state of the art，也可能是理论最优值、硬件极限，或没有受到新机制扰动的原始系统。关键不是“多放一个 competitor”，而是选择读者真正需要的参照来判断 claim。
+
+更隐蔽的问题是“模型和自己比较”：先用若干未充分验证的简化假设建立模型，再为该模型设计方案，最后在包含完全相同假设的模拟系统中评价方案。这个闭环可以产生漂亮结果，却没有检验假设是否对应现实，因此无法支持现实有效性或预测能力。
+
+这条原则的深层含义是：评测必须给方法留下被独立证伪的机会。只在自己定义的问题、假设和评价器中胜出，可能证明内部一致性，但不能自动证明外部有效性。
+
+## Taste 信号
+
+### 明确偏好
+
+- 无。用户提供了学习链接，但没有直接声明对原文措辞或全部判断的赞同程度。
+
+### 推断信号
+
+- 不接受仅与作者自己的旧版本比较，就宣称方法重要、领先或有普遍意义。
+- baseline 应从研究 claim 反推：它必须让读者判断真正关心的差距，而不是选择最方便或最有利的参照。
+- 对仿真和模型结果保持独立性要求：不能用相同假设构造问题、方法和 evaluator，再把内部一致性写成现实有效性。
+- benchmark 的目标不只是产生好看的数值，还要提供 reality check 和可证伪性。
+
+### 领域知识
+
+- Heiser 将 only evaluate against yourself 归为 improper comparison 的一种，并认为显著性需要与 accepted standard 比较。
+- 相邻的 proper baseline 小节列出多种可能参照：SOTA、理论最优或硬件极限，以及未扰动系统。
+- 原文区分了明显的“只和自己旧版本比”与更隐蔽的“模型在包含同样假设的模拟器中验证自己”；后者缺少基本现实校验。
+- 本次只精读 `#self` 及其 baseline 上下文，没有把整篇 benchmarking crimes 列表都视为本次确认内容。
+
+## 边界与反例
+
+- 自我比较并非没有价值。它适合 regression testing、ablation、定位单次改动收益和追踪开发进展；问题是让它承担超出其证据范围的 headline claim。
+- “独立基线”不总是另一个可运行系统。对于某些 claim，理论上界、硬件极限或未扰动系统可能是更正确的参照。
+- 仿真或简化模型在真实系统难以构建、机制需要隔离或上界需要估算时仍然必要；但必须说明假设，并用独立数据、sensitivity 或真实系统进行适当校验。
+- 原文使用了强烈的评审措辞。本次沉淀其研究有效性原则，不自动继承其修辞强度。
+- 用户仅提供链接，因此新增画像条目标记为 `暂定`，等待后续直接反馈或更多一致证据。
+
+## 可执行影响
+
+- 审计 evaluation 时先写清 headline claim，再逐项问：当前 baseline 能否判断该 claim，还是只能证明系统比自己以前更好？
+- 对每个对比标注 baseline 角色：accepted standard、SOTA、unperturbed system、theoretical optimum、hardware limit 或 internal ablation。
+- 内部 baseline 可以保留，但不能替代与当前外部标准的公平比较；若外部比较不可行，需要明确限制并收窄 claim。
+- 对模型或模拟器检查“假设闭环”：问题定义、方法和 evaluator 是否共享了未经现实验证的同一假设？
+- 若存在闭环，要求至少一种独立校验：真实系统测量、未参与建模的数据、不同模型的交叉验证，或关键假设的 sensitivity analysis。
+- review 时把“只有自我比较且支撑 headline claim”标为 `NEEDS EVIDENCE`；若导致核心结论无法判断，则升级为 `Blocking`。
+
+## 画像更新
+
+- 新增：[实验评测 / 自我比较不能代替独立基线](../TASTE.md#实验评测--自我比较不能代替独立基线)
+- 新增：[模型评测 / 不允许同一组假设闭环自证](../TASTE.md#模型评测--不允许同一组假设闭环自证)
--- a/learnings/2026-07-18-003-abseil-performance-hints.md
+++ b/learnings/2026-07-18-003-abseil-performance-hints.md
@@ -0,0 +1,104 @@
+---
+id: 2026-07-18-003
+date: 2026-07-18
+status: distilled
+tags: [performance, profiling, estimation, algorithms, memory, api-design]
+sources: ["https://abseil.io/fast/hints.html"]
+references:
+  - "Donald Knuth, Structured Programming with go to Statements (quoted by source)"
+  - "Profiler, microbenchmark, API-design, and further-reading links collected by the source (not independently reviewed)"
+accessed: 2026-07-18
+---
+
+# Abseil Performance Hints
+
+## 原始输入
+
+> 学习：https://abseil.io/fast/hints.html
+
+- 直接来源：[Jeff Dean and Sanjay Ghemawat, Performance Hints](https://abseil.io/fast/hints.html)
+- 页面版本：original 2023-07-27；last updated 2025-12-16
+- 访问日期：2026-07-18
+- 来源边界：文章讨论 single binary 的一般性能调优；作者明确说明不覆盖 distributed systems 或 ML hardware tuning。本文大量例子来自 C++ 和 Google 内部代码，但高层原则可用于其他语言。
+
+## 内容蒸馏
+
+文章反对两种极端：一是到处做没有证据的 micro-optimization，二是以“premature optimization”为理由在设计阶段完全忽略性能。更稳健的原则是：如果更快的选择不会显著增加可读性或复杂度，就尽早采用；一旦优化涉及实质 tradeoff，则先估算、测量和定位，再决定值得支付多少复杂度。
+
+### 1. 建立量级直觉
+
+先区分 test code、单一 application 的代码和被广泛复用的 library code，并判断 setup path 与 hot path。用 back-of-the-envelope calculation 估算磁盘 seek、网络 round trip、数据传输、内存访问和分支等昂贵操作的次数与粗略成本，先排除量级上不合理的设计。估算用于形成假设，不替代真实测量；并发还会使资源成本和 latency 不再简单相加。
+
+### 2. Measurement 是优化工作的主工具
+
+在做有复杂度代价的优化前，使用 production-like build、profile、microbenchmark 和 performance counters 获取证据。microbenchmark 能缩短迭代、验证局部变化并防止 regression，但可能不代表完整系统。profile 很平时不意味着没有机会：可以寻找调用栈上层循环、结构性改动、过度通用的代码、allocation 热点和硬件计数器信号，也可以用稳定 benchmark 逐一累积小收益。
+
+### 3. 先找高杠杆的结构变化
+
+文章把算法复杂度改善视为最关键的机会。除此之外，常见高杠杆方向包括：
+
+- 通过 bulk API 摊薄函数边界、锁和逐项维护数据结构的成本；
+- 用 view 或调用方提供的 buffer 避免 copy、allocation 和重复计算；
+- 设计紧凑数据表示、优化 hot/cold layout、减少 cache line 与 memory bandwidth；
+- 减少 allocation、copy 与临时对象，必要时 reserve 或复用；
+- 消除不必要工作：common-case fast path、precompute、hoist、defer、specialize、cache；
+- 关注生成代码体积、inlining、template expansion、hot-path logging 和统计收集；
+- 在资源允许时利用 parallelism，同时减少 lock acquisition、critical section、contention、false sharing 和 context switch。
+
+这些方向的共同点不是“使用某个更快容器”，而是减少程序在目标 workload 上真正执行的工作、搬运的数据和付出的协调成本。
+
+### 4. API 决定未来优化空间
+
+广泛使用的接口一旦承诺额外语义，就可能迫使所有调用方永久支付成本。文章建议用功能深、接口窄的模块隐藏实现，让数据结构与算法可以在封装边界内演进；bulk APIs、view types、预分配参数，以及根据常见调用方式选择 thread-compatible 或 thread-safe，都属于减少不必要通用性成本的手段。
+
+### 5. 性能是多维约束
+
+runtime 之外，memory footprint、cache footprint、memory bandwidth、binary/code size、compile/link time、instruction cache、contention 和 context switches 都可能成为关键成本。并行化也不是自动收益：如果没有空闲 CPU 或 memory bandwidth 已饱和，它可能无效甚至变慢。因此每种技巧都必须落到具体 bottleneck 和 workload 上验证。
+
+## Taste 信号
+
+### 明确偏好
+
+- 无。用户提供了学习链接，但没有逐条声明对页面内容的赞同程度。
+
+### 推断信号
+
+- 性能意识应进入早期设计，但优化复杂度必须由量级估算、profile 和可复现测量支撑。
+- 比起孤立的 micro-optimization，更偏好减少算法工作量、数据移动、allocation 和同步等结构性改进。
+- 性能不是单一 latency 数字；memory、code size、带宽、contention 和维护复杂度都应进入 tradeoff。
+- API 应避免无需求的强保证和通用性成本，并把未来优化尽量留在封装边界内。
+- microbenchmark 适合局部迭代与 regression，不能自动支撑 end-to-end 性能 claim。
+
+### 领域知识
+
+- 文章作者为 Jeff Dean 和 Sanjay Ghemawat；当前页面标注最后更新于 2025-12-16。
+- 页面将技巧组织为 estimation、measurement、API、algorithm、memory representation、allocation/copy、unnecessary work、compiler/code size、parallelization/synchronization、Protocol Buffers 和 C++-specific advice。
+- flat profile 可能意味着成本分散。此时可以积累多个独立小优化，也应后退到调用栈上层寻找结构变化，而不是只盯最热 leaf function。
+- compact layout 能减少 cache miss 和 memory traffic，但也可能增加 cache-line contention；parallelism 受 CPU、memory bandwidth 和协调开销约束。
+- 页面中的低层操作耗时表和具体性能数字依赖其测量年代、硬件与 workload，不能作为当前机器上的常量使用。
+
+## 边界与反例
+
+- 本文主要针对 single-binary performance。distributed system、GPU kernel、ML hardware 和端到端 serving 还需要通信、调度、排队、尾延迟与资源共享分析。
+- “尽早考虑性能”不等于在未知 hot path 上增加复杂代码。无显著复杂度成本的快设计可以早选；有 tradeoff 的优化必须先估算或测量。
+- microbenchmark 可以可靠回答一个局部操作的问题，但不能独自代表完整 workload；需要与 end-to-end benchmark 或 production profile 形成证据链。
+- many small wins 只有在 benchmark 稳定、变化分别验证且没有隐藏回归时才可累积，不能把多项变化打包后归因。
+- cache 用内存换计算，specialization 和 inlining 可能增加 code size，紧凑布局可能引入 false sharing，parallelism 可能增加 contention 或尾延迟。
+- bulk、view、preallocation 和 thread-compatibility 会影响 API 易用性、生命周期与安全性，不能脱离调用方需求机械采用。
+- C++ 和 Abseil 的具体类型是案例，不是跨语言强制规则。
+
+## 可执行影响
+
+- 优化前固定目标 metric、workload、环境和 correctness baseline；区分 latency、throughput、memory、code size 与资源成本。
+- 先做量级估算：列出关键操作次数、粗略单次成本、可并行部分和潜在主导资源，形成可证伪的 bottleneck 假设。
+- 用 production-like build/profile 建立 baseline；为局部热点建立稳定 microbenchmark，同时保留 end-to-end 或真实 workload 验证。
+- 按杠杆顺序排查：算法复杂度 → 无用工作 → batching/hoisting/defer → allocation/copy/layout → code size/synchronization → 指令级技巧。
+- 每次只验证一个主要假设，记录 before/after、方差、正确性和其它维度的回归；flat profile 下的小收益也应分别归因。
+- API 变更前说明调用频率、摊薄机制、所有权和兼容性；优先把优化隐藏在已有封装内，只有可测收益需要时才扩大接口。
+- 并行化前检查 spare CPU、memory bandwidth 和任务粒度；测量同步、contention、context switch 与 tail latency，而不只看平均吞吐。
+
+## 画像更新
+
+- 新增：[性能优化 / 先估算和测量，再决定复杂度预算](../TASTE.md#性能优化--先估算和测量再决定复杂度预算)
+- 新增：[性能优化 / 优先减少总工作与数据移动](../TASTE.md#性能优化--优先减少总工作与数据移动)
+- 新增：[性能设计 / 用窄接口保留局部优化空间](../TASTE.md#性能设计--用窄接口保留局部优化空间)
--- a/learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md
+++ b/learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md
@@ -0,0 +1,303 @@
+---
+id: 2026-07-18-004
+date: 2026-07-18
+status: needs-evidence
+tags: [research-taste, systems, paper-reading, paper-writing, research-method, mentoring, academia]
+sources:
+  - "https://zhaoxiahust.github.io/blog/index.html"
+  - "https://www.usenix.org/legacy/events/samples/submit/advice_old.html"
+  - "https://zhaoxiahust.github.io/blog/reading-paper.pdf"
+  - "https://www.ie.tsinghua.edu.cn/__local/E/49/D3/DC2FDCE5B1CE93A12B9DBF58C83_64034E68_D7B4D.pdf"
+  - "https://pfind.ict.ac.cn/people/hesimin/Chinese/ztxm/202504/P020250421631708297530.pdf"
+  - "https://www.cnblogs.com/albertwang/p/3346000.html"
+  - "https://blog.csdn.net/celestialwy/article/details/2766402"
+  - "https://medium.com/@hitony/hit-cs-3bb5a774f754"
+  - "https://mp.weixin.qq.com/s/1swWWZmkyY2eK32KcwzZwg"
+  - "https://medium.com/digital-diplomacy/how-to-look-for-ideas-in-computer-science-research-7a3fa6f4696f"
+references:
+  - "Richard Gabriel, The Rise of Worse is Better (由《系统设计黄金法则：简单之美》引用，未在本次独立精读)"
+  - "David Patterson, Your Students Are Your Legacy (本次已读索引所附英文 PDF)"
+  - "Philip W. L. Fong, How to Read a CS Research Paper? (本次已读索引所附 PDF)"
+  - "Philip J. Guo, The Ph.D. Grind (本次通过同版高校镜像 PDF 阅读)"
+accessed: 2026-07-18
+---
+
+# 赵霞研究与系统文章清单：逐篇学习记录
+
+## 原始输入
+
+> 学习：https://zhaoxiahust.github.io/blog/index.html（这是一个 list，遍历学习其中的 articles）
+
+- 清单来源：[Xia Zhao — Articles](https://zhaoxiahust.github.io/blog/index.html)
+- 访问日期：2026-07-18
+- 范围约定：只遍历 `Articles`，不含页面上单列的 3 个视频。
+- 计数口径：主页共有 25 个文章条目；同一条目中的中文 slides、英文原版或上下篇视为补充材料，不重复计数。
+
+## 内容蒸馏
+
+### 覆盖率与证据状态
+
+本次先从主页解析出 25 项清单，再逐项读取。结果为：
+
+- 完整正文：18/25。
+- 可验证片段或相关材料，但不是原文全文：3/25。
+- 已访问但正文当前不可恢复：4/25。
+- 遍历状态：25/25 均已处理；因此“遍历”已经完成，但由于 4 篇缺少正文，本记录保留 `needs-evidence` 状态。
+
+“相关材料”不会被当作原文摘要；缺失项也不根据标题补写观点。
+
+| # | 文章 | 本次证据状态 |
+|---:|---|---|
+| 1 | [How (and How Not) to Write a Good Systems Paper](https://www.usenix.org/legacy/events/samples/submit/advice_old.html) / 中文 slides | 完整：网页原文与 47 页中文 slides |
+| 2 | [How to Read a CS Research Paper?](https://zhaoxiahust.github.io/blog/reading-paper.pdf) | 完整：4 页 PDF |
+| 3 | [THE PH.D. GRIND](http://www.pgbovine.net/PhD-memoir/pguo-PhD-grind.pdf) | 完整：原站 TLS 失效，改读高校托管的同版 115 页 PDF；封面、版本与原始出处一致 |
+| 4 | [一名系统研究者的攀登之路](https://zhaoxiahust.github.io/blog/%E4%B8%80%E5%90%8D%E7%B3%BB%E7%BB%9F%E7%A0%94%E7%A9%B6%E8%80%85%E7%9A%84%E6%94%80%E7%99%BB%E4%B9%8B%E8%B7%AF.pdf) | 完整：5 页 PDF |
+| 5 | [计算机系统会议论文是如何评审的](https://zhaoxiahust.github.io/blog/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%B3%BB%E7%BB%9F%E4%BC%9A%E8%AE%AE%E8%AE%BA%E6%96%87%E6%98%AF%E5%A6%82%E4%BD%95%E8%AF%84%E5%AE%A1%E7%9A%84.pdf) | 完整：5 页 PDF |
+| 6 | [与学生合作开展研究的体会](https://www.weibo.com/p/1001603919869526563233) | 完整替代：微博登录墙；找到《CCCF》同版 5 页 PDF |
+| 7 | [对计算机体系结构研究的一点认识](https://zhaoxiahust.github.io/blog/%E5%AF%B9%E8%AE%A1%E7%AE%97%E6%9C%BA%E4%BD%93%E7%B3%BB%E7%BB%93%E6%9E%84%E7%A0%94%E7%A9%B6%E7%9A%84%E4%B8%80%E7%82%B9%E8%AE%A4%E8%AF%86.pdf) | 完整：4 页 PDF |
+| 8 | [印度 Bangalore 之 HPCA/PPoPP-2010 与会小记](https://zhaoxiahust.github.io/blog/%E5%8C%85%E4%BA%91%E5%B2%97HPCA-PPoPP-2010-final.pdf) | 完整：15 页 PDF |
+| 9 | [ISCA-2014 与北美学术之旅](https://zhaoxiahust.github.io/blog/ISCA-2014%E4%B8%8E%E5%8C%97%E7%BE%8E%E5%AD%A6%E6%9C%AF%E4%B9%8B%E6%97%85.pdf) | 完整：6 页 PDF |
+| 10 | [PACT-2015 PC 讨论会记录](https://zhaoxiahust.github.io/blog/PACT-2015%20PC%E8%AE%A8%E8%AE%BA%E4%BC%9A%E8%AE%B0%E5%BD%95.pdf) | 完整：9 页 PDF |
+| 11 | [博士五年总结](https://zhaoxiahust.github.io/blog/five_year_summary_of_PhD.pdf) | 完整：12 页 PDF |
+| 12 | [系统设计黄金法则：简单之美](http://blog.sciencenet.cn/blog-414166-562616.html) | 完整替代：原页被作者设限；读取注明作者与原文链接的全文转载 |
+| 13 | [你的学生就是你的财富](http://blog.sciencenet.cn/blog-414166-302397.html) / [Your Students Are Your Legacy](https://zhaoxiahust.github.io/blog/your_student_legacy.pdf) | 完整：中文页失效，读完索引附带的英文原文 4 页 PDF |
+| 14 | [ISCA08见闻](http://blog.sciencenet.cn/blog-414166-302386.html) | 部分：原页失效；只找到被引用的原文片段和另一作者的同期参会记录，不视为全文 |
+| 15 | [与新晋图灵奖得主的虚拟对话](http://blog.sciencenet.cn/home.php?mod=space&uid=414166&do=blog&id=1110558) | 缺失：只核实到作者、题名和后续论文引用，正文不可得 |
+| 16 | [关于“国家重点实验室应该追求什么”的讨论](http://blog.sciencenet.cn/blog-414166-1136799.html) | 缺失：原页被作者设限，未找到可信全文镜像 |
+| 17 | [SOSP 2013 Analysis](https://www.douban.com/note/315357927/) | 缺失：豆瓣接口明确返回 `private_note`，无可用存档 |
+| 18 | [OSDI, SOSP 与美国著名计算机系的调查](https://blog.csdn.net/celestialwy/article/details/2766402) | 完整：网页全文 |
+| 19 | [HIT CS 科班对计算机专业领域的汇编](https://medium.com/@hitony/hit-cs-3bb5a774f754) | 完整：网页正文；外链仅作历史索引，未逐个复核 |
+| 20 | [Prolific System Scholars (to 2013)](https://zhaoxiahust.github.io/blog/zips-2013.pdf) | 完整：1 页统计表 PDF |
+| 21 | [ASPLOS 系列专访—Mark D. Hill](https://zhuanlan.zhihu.com/p/26502720) | 部分：知乎原文/API 均拦截，存档回放是反爬挑战；仅保留一份 Mark Hill 后来的相关公开演讲作背景，不代替原文 |
+| 22 | [ASPLOS 系列专访—Shan Lu](https://zhuanlan.zhihu.com/p/26832780) | 部分：原文不可得；读取芝加哥大学对其真实并发 bug 研究的官方回顾，不代替原访谈 |
+| 23 | [ASPLOS 系列专访—李涛](https://zhuanlan.zhihu.com/p/27112516) | 缺失：原文/API 被拦截且无可用存档；不采纳未经完整上下文核对的二手转述 |
+| 24 | [研究是一种生活方式：Onur Mutlu（上）](https://mp.weixin.qq.com/s/1swWWZmkyY2eK32KcwzZwg) / [下](https://zhaoxiahust.github.io/blog/1909-%E4%BA%BA%E7%89%A9%E4%B8%93%E8%AE%BF%E6%96%87%E7%AB%A0%E5%88%9D%E6%8E%92%E7%89%88.pdf) | 完整：微信正文与 5 页 PDF |
+| 25 | [How to Look for Ideas in Computer Science Research](https://medium.com/digital-diplomacy/how-to-look-for-ideas-in-computer-science-research-7a3fa6f4696f) | 完整：网页全文 |
+
+### 逐篇提炼
+
+#### 1. How (and How Not) to Write a Good Systems Paper
+
+- 好系统论文的中心不是“花了很多功夫”，而是明确的重要问题、原创而可解释的想法，以及可信的真实实现和证据。
+- 论文应交代假设、设计选择、替代方案、失败尝试、适用边界和可迁移的经验；读者最终应该学到超出这个原型本身的东西。
+- 写作不是研究结束后的包装。尽早写摘要能迫使作者说清问题、贡献和结果；聚焦、清晰与诚实会直接暴露研究是否站得住。
+
+#### 2. How to Read a CS Research Paper?
+
+- 理解一篇论文先回答四个问题：研究问题与动机是什么、贡献是什么、作者如何支撑 claim、最后真正学到了什么。
+- 阅读还包括评价：问题和贡献是否重要，实验、证明、benchmark 与泛化是否有效，claim 是否足够克制。
+- 最后一层是综合：寻找替代解法、更好的验证、反方论证、可迁移场景和开放问题。用自己的话写“摘要—评价—综合”是训练研究判断的有效方式。
+
+#### 3. THE PH.D. GRIND
+
+- 这是一份有强烈个体条件的六年博士回忆录，不是可普遍照搬的成功指南；作者也主动指出资助、学校和自主权带来的特权。
+- 有方向的产出优于无目的的信息消费；想法来自既有想法、真实摩擦、持续展示工作和与人协作，而不是闭门等待灵感。
+- “聪明地 grind”包括识别坏的默认项目、知道何时退出、从失败恢复、及时求助、反复讲述与推销工作的意义；只有勤奋而没有方向判断，可能只是更快地耗尽自己。
+- 这份材料同时提醒：研究训练可能带来成长，也可能造成倦怠。不能把痛苦、过劳或论文数量浪漫化为科研价值本身。
+
+#### 4. 一名系统研究者的攀登之路
+
+- 系统研究要求想法、原型与长期验证同时成立，周期常以年计；临近 deadline 从零拼一篇顶会论文通常不现实。
+- 关键能力包括极度批判性地追问“为什么非要这样做”、扎实的系统基本功、从 A→B 和方法 1→方法 2 的发散迁移，以及在一段时间内保持专注。
+- 写作质量体现思维质量；拒稿和“撞车”不自动使问题失去价值，比较差异、把工作做得更彻底，反而可能产生新发现。
+
+#### 5. 计算机系统会议论文是如何评审的
+
+- 系统顶会通过多轮、多人和面对面讨论降低单个审稿人的随机性，但评审仍不可完全消除品味差异和偶然性。
+- 文中归纳的评价链条是：重要问题、有趣且有力的方法、实用性与有效性、恰当总结、明确说明做了什么、清晰标出创新。
+- 好论文至少要传递一个可复述的关键信息，并用设计、实现和实验围绕它闭环；隐藏限制、挖坑不填、只给理论跳过落地细节都会破坏信任。
+- 投稿不是把不成熟项目丢给审稿人调试。被拒后应真正解决问题，而不是只改措辞或换会碰运气。
+
+#### 6. 与学生合作开展研究的体会
+
+- 导师—学生更像共同承担风险、共享成果、彼此学习的长期合伙关系；指导必须按学生能力、兴趣、阶段和可用时间定制。
+- 选题可从 mini-survey 加“让手弄脏”开始：加入现有项目、开发或评测真实系统，以第一手经验估计问题的重要性、难度和风险。
+- 导师的介入应从早期战术支持逐渐转向后期宏观判断与科研素养，让学生获得独立研究能力，而不是永久替学生做决定。
+- 团队需要互助、期望与压力管理、及时而建设性的反馈，以及多轮写作和报告训练。培养本身不可机械扩展。
+
+#### 7. 对计算机体系结构研究的一点认识
+
+- 好研究至少来自两类价值之一：重要问题，或对有挑战问题的新颖解法；更好的工作往往同时具备两者。
+- 深读不是记住叶子节点的差异，而是回溯作者为何选择这条分支、现有方案的假设为何成立，从更接近“根”的位置寻找新的解法。
+- 广泛阅读有助于跨领域迁移方法，但持续研究还需要兴趣。论文则要做到一个好想法足以打动人，同时没有严重漏洞。
+- 结果无论好坏都应检查合理性并解释；只在结果差时找原因，是明显的确认偏误。
+
+#### 8. 印度 Bangalore 之 HPCA/PPoPP-2010 与会小记
+
+- 联合会议让体系结构与并行编程相互暴露问题和方法，体现跨社区交流的价值；系统教育也不能把原理与动手实践割裂。
+- 当时的前沿议题包括极大规模计算的能耗、可靠性、编程与异构化。一个重要判断是：并行软件应以“用最少资源达到所需性能”为目标，而不只是让所有核忙起来。
+- 报告后的尖锐问题、备用 slides 和现场讨论是证据链的一部分；参会前了解人物与工作、会后复盘材料，能把“出席会议”变成真正的学习和合作。
+- 具体技术预测和人物格局属于 2010 年的历史截面，不应直接当作当前结论。
+
+#### 9. ISCA-2014 与北美学术之旅
+
+- workshop 中的持续质疑不是礼仪失败，而是把粗糙想法磨细、检查研究与实验方法的过程。
+- 文章所述项目从应用需求、操作系统资源管理到微体系结构建立适度耦合，并用真实多核系统和近两年数据收集验证，体现跨层抽象必须落到长期证据。
+- 一篇论文经历上百次讨论和版本，说明写作承担的是重新理解和组织研究的工作，不只是英文润色。
+- 工业界能暴露真实约束，但企业问题可能过于特定，学术方案也可能因生产配置而失去意义；关键是从真实需求中抽象可推广问题，同时保留稳定性和成本约束。
+
+#### 10. PACT-2015 PC 讨论会记录
+
+- PC 讨论会中，原始高分可能因一个技术缺口被推翻；新颖想法与不完整实验之间的取舍会被具体讨论，而不是机械按分数排序。
+- 论文提交前应尽可能让核心 claim、例外、实现和实验经得住同行追问；成熟度和严谨表达不是次要装修。
+- 与企业合作应“看需求，勿照搬”：生产系统可能更关心可扩展性、稳定性、人员维护成本和硬件扩容成本，而不是实验室 benchmark 上的峰值性能。
+- 学界适合承担高风险、长期和抽象研究，企业拥有真实工作负载与产品约束；合作的价值来自互补与持续沟通，不是把论文方案硬塞进产品。
+
+#### 11. 博士五年总结
+
+- 长期项目首先需要静下来、保持内在动机，并在失败中总结方法；决心本身不够，选题、调查、优先级、建模、验证和细节管理都需要刻意训练。
+- 想法应随手写下；阅读则抓住少数关键论文和主线，用预测作者路数的方式建立领域模型，避免无目的地把每篇都读到同样深。
+- 论文不是按时间顺序列技术步骤，而要解释为什么这样做、适用条件和局限，并建立统一、自洽、能给前人定位的图景。写作组织会反过来促进研究理解。
+- 演讲应只有一条可记忆主线，细节是否保留取决于它是否服务中心 claim；计划要宽松、简洁、可复盘，并给睡眠和运动留出空间。
+- 其中一些“高远立意”“世界观”表达容易滑向过度包装；只有在证据与真实联系支撑时才有价值。
+
+#### 12. 系统设计黄金法则：简单之美
+
+- KISS 的核心不是少写几行代码，而是在不确定性必然累积的复杂系统中，让每个阶段和子任务尽量简单。
+- 文中总结的工程习惯包括自动化失败恢复、准备替换当前可用组件、使用合适工具、适当缓存，以及显式选择一致性和可用性的取舍。
+- 用 Must-Have / Nice-to-Have 缩小第一版，快速把端到端链路跑通，再回头优化；过早追求中间步骤完美，可能阻止验证总体方向。
+- “简单”不意味着忽略正确性、安全性或长期维护，也不意味着 New Jersey 式取舍在所有场景都优于完整设计。
+
+#### 13. 你的学生就是你的财富 / Your Students Are Your Legacy
+
+- 学生应主动探索、挑战假设并反过来教育导师；导师的任务是提供能培养研究 taste 的环境，而不是只分配工作。
+- 多学科团队、研究 retreat、外部反馈和开放协作空间让学生通过项目、同伴与真实批评学习如何识别关键问题和有影响力的解法。
+- 具体指导包括及时而频繁的反馈、真实而不伤害信心的表扬与批评、公开演讲训练、稳定会面、可信赖的咨询和以身作则。
+- 核心价值判断是：导师的长期学术遗产主要是被培养的人，而不是论文数量；指导关系也不应在毕业时突然结束。
+
+#### 14. ISCA08见闻（证据不完整）
+
+- 目前只能核实一段被后文引用的选题观察：与追逐当时最热的功耗主题相比，有研究者选择 process variation 作为突破口并形成连续工作。
+- 另一作者的同期参会记录可证明会议背景和部分讨论主题，但不是索引所列原文，不能用来重建作者的完整观点。
+
+#### 15. 与新晋图灵奖得主的虚拟对话（缺失）
+
+- 已核实题名、作者包云岗及其被后续《CCCF》文章引用的书目信息。
+- 正文不可得，本次不从标题推断对话对象、问题或结论。
+
+#### 16. 关于“国家重点实验室应该追求什么”的讨论（缺失）
+
+- 原科学网页面目前被作者设置访问限制，精确题名检索未找到可信全文镜像。
+- 不根据题名猜测其对基础研究、国家需求、评价制度或实验室治理的具体立场。
+
+#### 17. SOSP 2013 Analysis（缺失）
+
+- 豆瓣公开接口明确返回“仅作者本人可见”，且没有可用网页存档。
+- 因此未提炼论文分布、研究热点或机构统计；这些内容若未来补回，应与第 18 项的历史调查分开记录。
+
+#### 18. OSDI, SOSP 与美国著名计算机系的调查
+
+- 文章用当时可得的 OSDI/SOSP 历史数据观察机构、作者、合作关系和主题变化，显示顶尖系统研究长期集中于少数高校与工业实验室，跨机构合作逐渐增加。
+- 它的更大价值是提供“人—组—学校—方向”的发现地图，帮助新研究者追踪学术谱系和代表工作。
+- 数据主要截止到 2006 年左右，作者也承认统计有限；会议篇数、机构排名和师承网络不能替代对论文思想与证据的判断。
+
+#### 19. HIT CS 科班对计算机专业领域的汇编
+
+- 这是一份 2014 年左右的个人化学习地图，强调兴趣、基础、时间管理和动手实践，并按编程语言、算法、操作系统、编译、软件工程、数据库等领域汇集资源。
+- 它反复体现“原理 + 真系统/真代码”的学习方式，例如 Linux、xv6 和编译器实践，而不是只背课程定义。
+- 这份材料适合作为发现索引，不适合作为今天唯一的课程方案：篇幅和观点高度个人化，部分链接、工具与技术判断已经过时。
+
+#### 20. Prolific System Scholars (to 2013)
+
+- 这是一张按多个系统相关会议统计高产学者、再聚合到机构的历史表，可用于发现研究者、会议社区和机构强项。
+- 它没有解释作者口径、时间窗、同名处理、合作贡献和质量权重；“高产”只是一种计数属性，不等同于研究 taste、原创性或影响力。
+- 最稳妥的用法是把它当阅读入口，而不是把榜单本身变成研究目标。
+
+#### 21. ASPLOS 系列专访—Mark D. Hill（原文缺失，只有相关背景）
+
+- 原访谈正文无法恢复，因此不对标题所说的“中国从跟随者到创新领导者”做细化转述。
+- 一份 Mark Hill 2024 年的公开演讲提供了相邻但独立的观点：体系结构中的一些根本问题长期存在，应用和技术变化会改变答案，研究者的任务是识别变化。该材料只作背景，不能冒充 2017 年访谈内容。
+
+#### 22. ASPLOS 系列专访—Shan Lu（原文缺失，读取了官方回顾）
+
+- 芝加哥大学 2022 年官方回顾确认：她早期没有依赖人工注入 bug，而是系统收集 MySQL、Apache、Mozilla、OpenOffice 中 100 多个真实并发 bug，建立分类并影响后续检测与修复研究。
+- 这种“先观察真实故障，再决定研究什么”的经验方法后来被她迁移到更多 bug 类别；它支持“研究应领先产品，但问题来源应扎根真实世界”的理解。
+- 上述是后来的官方回顾，不是索引中的 2017 年中文访谈，不能据此还原访谈的完整问答。
+
+#### 23. ASPLOS 系列专访—李涛（缺失）
+
+- 原文、公开 API 和存档均不可用。
+- 搜索中出现的二手转述缺少完整上下文，且夹杂与文章无关的后续事件；本次不把这些内容写成作者观点，也不用于更新画像。
+
+#### 24. 研究是一种生活方式：Onur Mutlu（上、下）
+
+- 选题先找重要且可能产生根本影响的问题，再提出好想法，用正确实现和评估证明它；论文只是传播手段，不是最终目的。
+- Rowhammer 的发现不是单点灵感：先有不同存储介质的跨域类比，再有原本为其他问题搭建的 FPGA 测试基础设施，最后加上学生实习和工业合作，才把异常变成可验证的新现象。
+- 指导强调根本问题、学生自由、独立性、创造力、韧性和相互协作；学术界的吸引力还包括长期培养学生与教学，而不是职位标签。
+- 跨领域合作可以把体系结构方法带入基因组分析。对论文评审则主张基于科学价值而非“厂商永远不会采用”之类不可证伪的判断，并要求提高审稿问责。
+
+#### 25. How to Look for Ideas in Computer Science Research
+
+- 产生 idea 是可单独训练的能力；读论文的目标之一是形成判断什么重要、什么优雅的 taste，而不是平铺式记忆所有技术细节。
+- 常见模式包括：把问题按维度展开后补空白、扩展现有方法、先造出独特 hammer 再寻找合适 nail、从小观察逐步 generalize、复现前人工作、从工业与新闻中的真实问题出发。
+- 小观察值得放大通常有几个信号：结果令人意外、触及根本机制、不是一次性偶然。复现失败也可能是新问题入口，但必须先严肃排除自身错误。
+- 广泛阅读、写 review、听报告、与同行争论和维护同伴网络，都是持续生成与筛选 idea 的基础设施。
+
+### 跨文章共同结构
+
+这份清单不是单一作者的一套教条，但完整可读的材料反复出现了七个共同结构：
+
+1. **研究从重要问题开始，以可迁移的 lesson 结束。** 方法、原型和数字位于中间；只报告“做了什么”不足以形成研究价值。
+2. **好的抽象来自对根节点、假设和设计选择的深入理解。** 它不是先写一个宏大名词，再把具体任务塞进去。
+3. **异常结果是机制线索，不是自动的 discovery。** Rowhammer、真实并发 bug 和复现失败都说明：先排除实现与测量错误，再用独立基础设施、真实样本和跨场景迁移检验是否存在共性机制。
+4. **写作、演讲和评审是研究过程的一部分。** 它们迫使作者找出唯一中心 claim、补齐证据链、暴露逻辑跳跃，并把细节放回正确层级。
+5. **系统之美是约束下的简单。** 快速完成端到端原型、减少非必要机制、自动化失败恢复并迭代演进；进入真实环境后，还必须面对稳定性、扩展性、尾部行为和维护成本。
+6. **科研培养的终点是独立判断。** 个性化选题、动手获得第一手经验、及时反馈、团队互助与逐步放权，比把学生变成论文执行器更重要。
+7. **榜单、顶会与机构统计是导航信息，不是价值函数。** 它们能帮人发现论文、学者与社区，但受时间、样本、声望结构和计数口径影响。
+
+## Taste 信号
+
+### 明确偏好
+
+- 无。用户要求学习整份清单，但没有声明对其中每篇文章或每个观点都赞同。
+
+### 推断信号
+
+- 偏好把科研 taste 落到一套可操作的判断链：问题重要性、共性机制、设计选择、真实实现、可信证据和普遍 lesson。
+- 对“异常是 bug 还是新现象”的回答应是证据流程，而不是直觉标签：先复现和排错，再验证是否跨实现、跨 workload 或跨介质成立。
+- 偏好读论文时越过技术细节，主动提取问题、贡献、证据、结论、假设和替代方案，并通过评价与综合形成自己的判断。
+- 偏好简单、可演进的系统设计，但这种简单必须接受正确性、稳定性、规模、尾延迟和维护成本等真实约束。
+- 倾向把写作与讲故事理解为研究思维的显化和校验，而不是用宏大叙事掩盖薄弱证据。
+- 倾向把科研训练看成培养独立研究者和长期协作关系，而不是最大化短期论文产量。
+- 对 venue、机构、人物榜单和论文计数保持工具性态度：用来导航，不用来替代质量判断。
+
+### 领域知识
+
+- 系统论文常被按重要性、创新、实现可行性、实验有效性、清晰度和可迁移 lesson 共同评价；其中任何一项都不能由实现工作量替代。
+- 高质量阅读可以组织为 comprehension、evaluation、synthesis 三层；综述和 reviewer 视角能训练研究 taste。
+- 系统研究中的 discovery 经常依赖长期积累的测试基础设施、真实工作负载、跨领域类比和工业合作，而非一次实验的偶然偏差。
+- PC 多轮评审能降低但不能消除随机性。论文应减少严重漏洞并争取至少让一位专家清晰看到其核心价值，同时诚实披露边界。
+- 工业落地的目标函数通常还包含稳定性、可扩展性、成本、人员流动和维护；学术 benchmark 上的性能提升不能自动覆盖这些维度。
+- 2010—2017 年的会议见闻、机构统计和课程资源具有显著历史性，使用时必须重新核对当前技术、人物、链接与社区结构。
+
+## 边界与反例
+
+- 这是一份个人收藏清单，不是系统综述；不同文章的年代、文体、领域和作者立场差异很大，不能把交集之外的观点强行合并成一套统一哲学。
+- 4 篇原文缺失，3 篇只有片段或相关材料。任何涉及这些文章的结论都保留低置信度，未来找到原文后应重新蒸馏。
+- “一般化”不是必然优于具体研究。一个明确、真实、重要的局部问题可能比脱离证据的宏大框架更有价值。
+- “简单”不是降低正确性标准的通行证；安全、可靠性、兼容性或法规要求高的系统可能必须承担额外复杂度。
+- “坚持”和“grind”不能用来正当化无止境项目、过劳或不健康的导师关系。知道何时退出、求助和保护身心同样是研究判断。
+- 多篇材料来自顶会成功者，存在明显幸存者偏差；顶会流程、美国名校网络和论文数量也会放大特定学术权力结构。
+- 会议和榜单统计受样本范围、作者归属、合作计数与时间窗影响，只适合做探索性地图。
+
+## 可执行影响
+
+- 今后评价研究想法时，优先写出五项：重要问题、相对现有工作的结构性新意、关键假设、独立证据、可迁移 lesson；缺一项就明确标为待验证，而不是用实现量或热门度补位。
+- 遇到反常结果时，按“复现 → 最小化 → 排除实现/测量错误 → 更换基线或独立实现 → sensitivity → 跨场景验证 → 提炼机制”的顺序处理。
+- 阅读论文时形成一页式记录：问题与动机、贡献、证据、结论、最强反驳、开放问题；只有真正相关的论文再下钻全部技术细节。
+- 做系统原型时先区分 Must-Have 与 Nice-to-Have，尽快跑通最小端到端闭环；随后在固定 workload 下逐项验证稳定性、规模、尾部行为、资源和维护 tradeoff。
+- 写论文、proposal 或汇报时先确定唯一中心 claim，再按“问题—现有缺口—关键洞见—设计选择—证据—边界—lesson”组织；宏大叙事必须能逐段回指证据。
+- 使用顶会、机构、导师与高产学者清单时，把它们转成待读论文和待了解研究组列表，不把排名本身写进质量结论。
+- 如果任务涉及带学生或协作研究，按阶段匹配风险与自主度，提供快速、具体、建设性反馈，并把“能否独立判断和表达”作为成功标准。
+- 对不可访问来源保留 URL、访问状态和替代来源级别；不让搜索摘要、同主题文章或标题替代原文。
+
+## 画像更新
+
+- 补充证据：[科研选题 / 先问重要性，再寻找共性结构](../TASTE.md#科研选题--先问重要性再寻找共性结构)
+- 补充证据：[科研表达 / 用问题—窗口—方法—证据组织故事](../TASTE.md#科研表达--用问题窗口方法证据组织故事)
+- 补充证据：[科研评审 / 重视简洁、内在一致、启发性、必然性与适用范围](../TASTE.md#科研评审--重视简洁内在一致启发性必然性与适用范围)
+- 补充证据：[科研价值 / 不以抽象之名贬低实际问题](../TASTE.md#科研价值--不以抽象之名贬低实际问题)
+- 新增：[科研阅读 / 从理解走向评价与综合](../TASTE.md#科研阅读--从理解走向评价与综合)
+- 新增：[科研发现 / 把异常当作待验证的机制线索](../TASTE.md#科研发现--把异常当作待验证的机制线索)
+- 新增：[系统设计 / 先跑通简单闭环，再按真实约束演进](../TASTE.md#系统设计--先跑通简单闭环再按真实约束演进)
+- 新增：[科研培养 / 以独立判断而非论文数量为终点](../TASTE.md#科研培养--以独立判断而非论文数量为终点)
--- a/learnings/2026-07-19-001-how-to-win-a-best-paper-award.md
+++ b/learnings/2026-07-19-001-how-to-win-a-best-paper-award.md
@@ -0,0 +1,110 @@
+---
+id: 2026-07-19-001
+date: 2026-07-19
+status: distilled
+tags: [research-taste, problem-selection, research-execution, paper-writing, collaboration, impact]
+sources:
+  - "https://nicholas.carlini.com/writing/2026/how-to-win-a-best-paper-award.html"
+references:
+  - "Richard Hamming, You and Your Research（由原文提及，本次未独立核验）"
+  - "Timothy Gowers, The Two Cultures of Mathematics（由原文提及，本次未独立核验）"
+  - "Stephen King, kill your darlings（由原文借用，本次未独立核验其原始出处）"
+accessed: 2026-07-19
+---
+
+# How to Win a Best Paper Award：把奖项看作分布的一次抽样
+
+## 原始输入
+
+> 学习：https://nicholas.carlini.com/writing/2026/how-to-win-a-best-paper-award.html
+
+- 原文：[How to win a best paper award (or, an opinionated take on how to do important research that matters)](https://nicholas.carlini.com/writing/2026/how-to-win-a-best-paper-award.html)
+- 作者：Nicholas Carlini
+- 发布日期：2026-03-09
+- 访问日期：2026-07-19
+
+## 内容蒸馏
+
+标题以“如何获得最佳论文奖”为入口，正文真正讨论的是如何提高产出重要研究的概率。作者最后把奖项定义为一次不可控的抽样：时机、同年竞争者、审稿人与评奖委员会都会改变结果；研究者能控制的不是某次是否获奖，而是自己工作质量的分布。目标因此不是奖项或论文计数，而是让研究准确地推进知识，并且足够清楚、可接近，能被他人理解和使用。
+
+### 1. Idea：taste 是尽早做对高杠杆选择
+
+- 好 taste 同时发生在宏观和微观层面：宏观上选择将会重要的问题，微观上选择更可能成立的路径。它最有价值的时刻是项目早期，因为此时一个判断能避免数月无效投入。
+- 文献阅读应由目的决定深度：多数论文只需知道“一句话的新东西”；与当前任务相关的论文要抽取所需方法或实验设计；真正准备延伸的少数论文才需要批判性通读到可以复现，并追问隐含假设、错误和开放问题。
+- 了解文献之后仍要摆脱路径依赖。领域惯例、名家论文和早期工作中的任意选择都可能形成错误锚点；独立思考有助于发现被惯性遮蔽的解法，但必须防止重复发明已知或已被否定的方案。
+- 研究应以 interesting、important、new 为目标，paper 是结果而不是起点。没有好 idea 时，做较小项目练习技艺是合理的；但不能把“刚好够投一篇”当长期价值函数。
+- 研究者应寻找“重要问题 × 比较优势”的交叉点：独特的技能组合、跨领域连接、数据、基础设施或对某个错误范式的清醒认识，都可能形成别人暂时难以复制的先手。协作者的价值则是尽早指出错误、否决坏想法并补齐能力，而不是简单分摊劳动。
+- 机会仍高度随机。taste 不能消除运气，只能提高选中丰饶路径、识别偶然线索并及时利用它的概率。
+
+### 2. Execution：先去风险，再把严谨性做满
+
+- 大多数看起来很好的 idea 接触现实后会失败；更努力不能让错误命题变真。作者建议先做最可能失败的关键子问题，用最小 prototype 检验核心假设，而不是先打磨已经知道怎么做的部分。
+- 项目即使技术上能完成，也可能达不到预期影响。此时应区分“可写成论文”和“值得继续投入”，避免 sunk cost；可把残余价值转成 workshop、blog 或复用 artifact。若出现显著更重要的方向，也可以重排优先级，但要警惕新 idea 天然更兴奋造成的 shiny-object bias。
+- 一旦核心 idea 经过去风险且确实重要，就应投入“不合理程度的努力”把证据做扎实：重复试验、控制 confounder、提前回答怀疑者会问的问题。这里的重点是证据精度，不是无边界地增加工时。
+- 一项研究应围绕一个可用短句表达的中心 idea。每个实验、段落和图都应服务它；同时论文应达到局部最优，不留下读者显然会追问的关键缺口。聚焦不等于删掉必要证据，完整也不等于穷举所有相关实验。
+
+### 3. Writing：让一个真实 claim 被目标读者准确接收
+
+- 易读性本身能产生长期影响：具体算法的 SOTA 地位会过时，但一篇清楚定义问题、建立共同语言的论文可能成为领域入口。
+- 写作前要确定唯一中心 idea 和具体目标读者。background 的作用是把更多人教到能够成为目标读者，而不是堆引用；标题首先要准确，难以命名有时是研究焦点过多的症状。
+- 摘要可以按“主题—问题—方法—结果—意义”或“claim—evidence—impact”组织，必须具体、真实，并让读者知道能获得什么。
+- 引言是认知路径：从读者当前相信的世界出发，建立问题语境，再让贡献出现。面对尚未成为共识的未来问题，需要解释其为何会重要；面对违反社区直觉的结论，应按证据组织论证，让读者能够自行到达结论，而不是用修辞强压。
+- 图应尽量 self-contained，每张有一句话 takeaway。结论不是把摘要改成过去时，而是回答 “so what”。作者甚至会在研究前先写 best-case conclusion：如果所有实验都成功，仍只能说数字提高一点且没有更大的 lesson，这就是提前停止项目的信号。
+- 所有写作规则都服从信息能否准确传递。朗读、text-to-speech、检查歧义和理想读者反馈，是发现作者盲区的实用方法。
+
+### 4. Afterwards：拒稿、时机和奖项不能反向定义价值
+
+- 好工作可能太早，以至于审稿人尚不接受它依赖的前提；也可能太晚、被别人抢先，或恰好不符合当届委员会的取向。这些随机性无法被写作和执行完全消除。
+- 拒稿可以帮助作者发现社区尚未被说服之处并补强论证，但“作者知道自己是对的”不能成为免检理由；修改仍需回到 claim、证据和清晰度。
+- 最终标准是研究是否准确地推进知识、是否足够 approachable，而不是是否获得某个奖。奖项若出现，只是有人注意到了这条质量分布中的一次高样本。
+
+## Taste 信号
+
+### 明确偏好
+
+- 无。用户要求学习这篇文章，但没有声明赞同其中全部观点。
+
+### 推断信号
+
+- 倾向把科研目标设为可持续地产出重要、正确、可理解的知识，而不是最大化论文数、venue 或奖项；奖项至多是高噪声的滞后反馈。
+- 倾向把研究 taste 理解为早期资源分配能力：尽快识别值得解决的问题、最脆弱的假设和更可能成功的技术路径。
+- 偏好“risk-first”执行：先用最小有效实验攻击最大不确定性；通过后才为完整实现和严谨证据支付高成本，失败或意义不足时及时停止。
+- 偏好用一个可复述的中心 claim 统摄论文，让每个实验、段落和图都能回指该 claim，同时补齐所有会实质影响结论的关键问题。
+- 倾向按阅读目的分配注意力，在 awareness、局部借鉴和可复现的深读之间切换；既利用文献，也防止被领域默认做法锁定。
+- 倾向在重要问题与个人比较优势的交叉处选题，并通过有实质前置工作的合作请求补足能力，而不是只凭声望建立关系。
+
+### 领域知识
+
+- 作者把高影响研究流程分成 idea、technical research、writing 和 publication/award aftermath 四段，并给出来自机器学习与计算机安全研究的个人经验。
+- “奖项是分布的一次抽样”区分了可控的研究质量与不可控的评奖结果，可避免用单次外部认可反向定义研究价值。
+- 作者自述开始的项目约为最终完成项目的五倍，也用个人案例说明获奖论文经常先被拒；这些是个人经验，不是经独立统计验证的普遍比例。
+- 文章中的论文案例、Hamming、Gowers、Stephen King 等外部线索，本次未逐项独立核验，因此只用于理解作者论证，不作为额外来源。
+
+## 边界与反例
+
+- 这是一位高成功率的机器学习与安全研究者的第一人称方法论，作者也明确限定“在我的领域”。它可能包含幸存者偏差，不能把其个人项目组合、速度和风险偏好机械复制到理论研究、湿实验、硬件、长期基础设施或强监管领域。
+- “影响力”很难在研究完成前准确预测，也容易被热门度、引用、名家与社区权力结构污染。冷门、复现、负结果、数据集、工具维护和扎实的增量研究都可能有重要的累积价值，不能因为不够“获奖型”就自动舍弃。
+- fail fast 只有在最小实验仍能有效检验关键假设时才成立。若 prototype 改变了决定性 workload、规模或机制，它可能产生错误否定；长周期研究也需要阶段性证据和耐心，而不是频繁追逐新鲜 idea。
+- 停止项目和重排优先级应预先写清 success、failure 与 kill criteria，并考虑合作者承诺、学生培养、资助和 artifact 价值。否则“不要受 sunk cost 影响”很容易退化成 shiny-object bias。
+- “每篇论文一个 idea”是传播和证据聚焦原则，不意味着复杂现象只能有一个原因，也不允许省略会改变 claim 的负面结果、限制和替代解释。
+- “投入不合理的努力”应解释为对通过筛选的重要问题做异常严谨的执行，而不是浪漫化过劳。投入仍受身心健康、机会成本和边际证据价值约束。
+- 拒稿后的坚持必须由可复查的证据支持。把审稿人不理解一律解释成“工作太超前”，会强化确认偏误；有时拒稿揭示的确是错误 claim 或不充分实验。
+- 研究故事的目标是帮助读者理解真实证据，而不是操纵读者。引言可以改变认知顺序，但不能隐瞒动机、限制或不利结果。
+- 更自由地分享 idea 依赖安全、隐私、知识产权、竞争环境和合作者权益；文章中的开放策略不是所有项目的默认规则。
+
+## 可执行影响
+
+- 开项时先写一页 research brief：重要问题、唯一中心 claim、为什么是现在、已有证据、个人或团队比较优势、最大不确定性、最小判别实验、success/failure/kill criteria。
+- 先执行最可能否定项目的有效测试。只有关键风险通过后，才扩展工程完整性、实验矩阵和论文写作；失败时保留可复用代码、数据、负结果或 blog，而不是为了投出一篇继续堆工作量。
+- 在决定是否继续项目前先写 best-case conclusion，并追问：如果一切成功，除了“指标提高”还能改变什么理解或实践？如果答案为空，重新定义问题或停止。
+- 为论文写一句不可再压缩的中心 claim；逐项检查每个实验、图、段落是否提供必要背景、机制、证据、边界或 lesson。删除旁枝，但补齐能改变结论的 obvious question。
+- 阅读前标记目的：`awareness` 只提取一句新意，`use` 精读所需技术，`extend` 深读到能复现、质疑假设并找开放问题；形成领域地图后，再刻意从 first principles 重新审视默认方法。
+- 摘要优先呈现 `claim—evidence—impact`，引言从目标读者的已有认知建立问题世界，图提供独立 takeaway，结论明确回答 “so what”。
+- 复盘研究时把问题质量、关键假设命中率、证据强度、可理解性和实际后续影响，与接收、引用和奖项分开记录；后者可作信号，但不充当价值函数。
+
+## 画像更新
+
+- 补充证据并收紧规则：[科研选题 / 先问重要性，再寻找共性结构](../TASTE.md#科研选题--先问重要性再寻找共性结构)
+- 补充证据并加入唯一中心 idea：[科研表达 / 用问题—窗口—方法—证据组织故事](../TASTE.md#科研表达--用问题窗口方法证据组织故事)
+- 补充分层阅读方法：[科研阅读 / 从理解走向评价与综合](../TASTE.md#科研阅读--从理解走向评价与综合)
+- 新增：[科研执行 / 先验证最大风险，再决定是否重投入](../TASTE.md#科研执行--先验证最大风险再决定是否重投入)
--- a/learnings/2026-07-20-001-gpu-server-network-review.md
+++ b/learnings/2026-07-20-001-gpu-server-network-review.md
@@ -0,0 +1,122 @@
+---
+id: 2026-07-20-001
+date: 2026-07-20
+status: distilled
+tags: [gpu-server, network, pcie, numa, nccl, training, inference]
+sources: [user-provided instruction]
+references:
+  - "nvidia-smi topo -m（用户提及，本次未独立核验）"
+  - "NCCL logs and nccl-tests（用户提及，本次未独立核验）"
+---
+
+# GPU 服务器网络配置五步评审法
+
+## 原始输入
+
+> 学习：以后评审 GPU 服务器配置，不要只问“几卡几网”。
+> 建议按五步算。
+>
+> 第一步：算外部网卡出口
+> 比如：
+> 8 张 400G NIC = 3.2T 网络出口。
+> 4 张 400G NIC = 1.6T 网络出口。
+> 注意是 bit，不是 byte。
+>
+> 第二步：算 PCIe 主机侧带宽
+> 看每张 NIC 是：
+> PCIe 4.0 x16
+> PCIe 5.0 x16
+> PCIe 5.0 x8
+> 是否共享 PCIe Switch 上行
+> 如果 PCIe 主机侧喂不满，网卡端口标多大都没用。
+>
+> 第三步：算 GPU 到 NIC 路径
+> 看：
+> 是否同 NUMA
+> 是否同 PCIe Switch
+> 是否跨 socket
+> 是否共享上行
+> 是否 Socket Direct
+> 是否拓扑一致
+>
+> 第四步：算业务通信需求
+> 训练要看：
+> AllReduce / ReduceScatter / AllGather
+> MoE All-to-All
+> 通信占 step 比例
+> 多机规模
+> bucket / overlap
+> checkpoint 干扰
+> 推理要看：
+> 多机 TP
+> KV Cache 迁移
+> P/D 分离
+> TTFT / p99
+> Decode 热路径
+>
+> 第五步：验证 NCCL 是否真能用起来
+> 看：
+> nvidia-smi topo -m
+> NCCL 日志
+> nccl-tests
+> HCA 利用率
+> 每条 rail 流量
+> slow rank
+> CNP / ECN / PFC
+> step time
+
+## 内容蒸馏
+
+评审 GPU 服务器通信配置不能停留在 GPU 和 NIC 的数量或端口标称速率，而应沿着“外部出口—主机侧入口—GPU 到 NIC 路径—业务需求—运行时实测”逐层核算。每一层都可能成为约束，前一层的峰值规格只有在后续路径、拓扑、workload 和软件运行时都能承接时才有意义。
+
+五步方法如下：
+
+1. **外部网卡出口**：先把 NIC 数量乘以单端口速率，得到聚合标称出口。示例中，8 张 400G NIC 对应 3.2 Tbit/s，4 张对应 1.6 Tbit/s；这里的单位是 bit/s，不是 byte/s。
+2. **PCIe 主机侧带宽**：逐卡确认 PCIe 代际和 lane 数，例如 PCIe 4.0 x16、PCIe 5.0 x16 或 PCIe 5.0 x8，并检查多张设备是否共享 PCIe Switch 上行。若主机侧路径无法持续供给端口速率，NIC 的标称带宽不是可达带宽。
+3. **GPU 到 NIC 路径**：检查 GPU 与 NIC 是否处于同一 NUMA node 或 PCIe Switch，是否跨 socket、共享上行、采用 Socket Direct，以及各 GPU/NIC 路径是否对称一致。不能只看单个器件规格而忽略端到端拓扑。
+4. **业务通信需求**：训练侧结合 AllReduce、ReduceScatter、AllGather、MoE All-to-All、通信占 step 比例、多机规模、bucket 与 overlap、checkpoint 干扰来评估；推理侧结合多机 TP、KV Cache 迁移、P/D 分离、TTFT、p99 和 Decode 热路径来评估。硬件是否合适由具体通信模式和服务目标决定。
+5. **NCCL 与端到端验证**：使用 `nvidia-smi topo -m`、NCCL 日志和 `nccl-tests` 检查拓扑识别与通信能力，同时观察 HCA 利用率、每条 rail 的流量、slow rank、CNP / ECN / PFC 信号和最终 step time，确认理论配置是否在真实运行时兑现。
+
+## Taste 信号
+
+### 明确偏好
+
+- 以后评审 GPU 服务器配置时，不接受只问“几卡几网”或只复述端口标称规格。
+- 建议固定按五层核算：外部 NIC 聚合出口、PCIe 主机侧带宽、GPU 到 NIC 拓扑路径、训练或推理的实际通信需求、NCCL 与端到端运行指标。
+- 带宽计算必须明确 bit 与 byte，避免单位混淆。
+- 纸面规格必须通过拓扑、通信库、链路计数器和业务指标验证，不能直接当成应用可用带宽。
+
+### 推断信号
+
+- 偏好用端到端瓶颈链路而非器件清单评审系统：任何共享上行、跨 socket 路径或拓扑不一致都可能使聚合规格失真。
+- 偏好把硬件配置判断绑定到 workload；训练 collectives、MoE 和推理的 TP、KV Cache、P/D 分离具有不同通信模式，不能用同一峰值数字代替分析。
+- 偏好同时观察平均能力、路径均衡和尾部异常；slow rank、每 rail 流量、p99 与 step time 都是验收信号。
+
+### 领域知识
+
+- NIC 数量乘以每端口标称速率可得到聚合线速上界，但该结果使用 bit/s，且不等于应用有效吞吐。
+- PCIe 代际、lane 数和 Switch 上行共享关系决定主机侧能否承接 NIC 线速。
+- NUMA、PCIe Switch、socket、共享上行、Socket Direct 和路径对称性会影响 GPU 到 NIC 的通信路径。
+- 训练通信评审需要覆盖 collective 类型、MoE All-to-All、规模、overlap 和 checkpoint；推理通信评审需要覆盖多机 TP、KV Cache 迁移、P/D 分离与延迟热路径。
+- 拓扑命令、NCCL 日志与测试、HCA/rail 计数器和端到端业务指标共同构成从配置到实际效果的证据链。
+
+## 边界与反例
+
+- 聚合 NIC 线速是理论入口，不是验收结论；协议开销、传输方向、消息大小、并发、路由、拥塞和软件栈都可能使实际吞吐低于标称值。
+- 五步法主要评审 GPU 服务器的通信子系统。算力、HBM 容量与带宽、CPU 内存、存储、功耗、散热、可靠性和运维仍需另行检查。
+- 不同 collective、模型并行策略和服务目标需要不同指标与 workload，不能只用 `nccl-tests` 峰值替代训练 step time、TTFT 或 p99。
+- 列出的 PCIe 形态和观测项是检查维度，不构成固定的合格阈值；材料没有给出 oversubscription、利用率或延迟的通用判定线。
+- Socket Direct、同 NUMA 或路径对称通常是重要拓扑信号，但单一特征不能脱离整机布线、路由策略和实测结果独立判定优劣。
+
+## 可执行影响
+
+- 收到 GPU 服务器 BOM、拓扑图或采购方案时，先建立五层表格，分别记录理论上界、共享关系、潜在瓶颈、待核验信息和实测证据。
+- 所有带宽数字显式标注 `bit/s` 或 `byte/s`；做换算时写出倍率，区分聚合端口线速与有效 payload 吞吐。
+- 为每张 NIC 记录 PCIe generation、lane width、Switch/CPU 上行及共享设备；为每组 GPU-NIC 记录 NUMA、PCIe Switch、socket、rail 和路径对称性。
+- 在给出“配置足够”的结论前，先固定训练或推理 workload、并行策略、多机规模和目标指标，再估算通信量及可 overlap 部分。
+- 验收时组合静态拓扑、NCCL 路径日志、微基准、链路/拥塞计数器和端到端指标；若它们不一致，优先定位 slow rank、rail 不均衡、跨 socket 或共享上行等具体约束。
+- 报告中区分纸面上界、基准可达值和业务实测值，并明确尚未获得的证据，不用“几卡几网”替代结论。
+
+## 画像更新
+
+- 新增：[GPU 服务器评审 / 从端口规格追到业务有效带宽](../TASTE.md#gpu-服务器评审--从端口规格追到业务有效带宽)
--- a/learnings/README.md
+++ b/learnings/README.md
@@ -0,0 +1,65 @@
+# Learning Records
+
+本目录保存每次 `学习：xxx` 的独立记录，是 `TASTE.md` 的证据层和历史层。
+
+## 命名
+
+```text
+YYYY-MM-DD-NNN-short-title.md
+```
+
+- `NNN` 是当日从 `001` 开始的递增序号。
+- `short-title` 使用简短、稳定、可检索的英文或拼音 slug。
+
+## 记录模板
+
+```markdown
+---
+id: YYYY-MM-DD-NNN
+date: YYYY-MM-DD
+status: distilled
+tags: []
+sources: []
+references: []
+---
+
+# 标题
+
+## 原始输入
+
+用户原文，或文件/链接等可追溯引用。
+
+## 内容蒸馏
+
+材料的核心观点、方法、审美特征或案例。
+
+## Taste 信号
+
+### 明确偏好
+
+- 没有则写“无”。
+
+### 推断信号
+
+- 每条说明推断依据；没有则写“无”。
+
+### 领域知识
+
+- 值得保留但不应直接解释为用户偏好的内容。
+
+## 边界与反例
+
+- 适用场景、例外、冲突证据或未知项。
+
+## 可执行影响
+
+- 未来 Agent 在判断、写作、设计或实现时应如何具体调整。
+
+## 画像更新
+
+- 链接本次新增或更新的 `TASTE.md` 条目；没有则说明原因。
+```
+
+`status` 通常使用 `distilled`；若材料尚未读完或关键信息无法获得，使用 `needs-evidence` 并明确缺口。
+
+`sources` 记录本次实际收到或查阅的材料；`references` 记录材料中提及、但本次未必独立核验的作品或线索。两者不能混用。