gahow/ai-dist
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Gahow Wang
2026-07-20 15:26:30 +08:00
commit 5629342035
11 changed files with 1316 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
AGENTS.md Normal file
View File

@@ -0,0 +1,59 @@
# AI Distillate Agent Guide
## Goal
本目录用于持续蒸馏用户的 taste。每次学习都要同时满足两点：内容本身被可靠记录；其中可复用的判断信号能被未来 AI/Agent 快速读取。
默认使用中文；代码、专有名词或原始材料需要时保留英文。
## Routing
- 当前有效的长期偏好与判断原则：读取 `TASTE.md`。
- 某条偏好的证据、上下文或演变历史：读取 `learnings/` 中对应记录。
- 新增学习记录的格式：读取 `learnings/README.md`。
- 若任务涉及工程或研究工作流，可按需读取 `/Users/gahow/agentic-ctx/AGENTS.md`；不要复制其内容到本目录。
## Trigger: `学习：xxx`
收到以 `学习：` 开头的输入时，执行以下流程：
1. 先读 `TASTE.md`、`learnings/README.md` 和相关历史记录。
2. 建立 `learnings/YYYY-MM-DD-NNN-short-title.md`。编号为当日递增序号；标题应简短、稳定、可检索。
3. 忠实保存用户的原始指令。简短内容可以原文记录；长文件或可恢复材料使用路径、链接等可追溯引用，不无意义地复制全文。
- `sources` 只记录本次实际收到或查阅的直接来源；
- `references` 记录材料中提及但本次未必独立核验的作品或线索；
- 不得把“被提及”写成“已验证”或“用户赞同全部内容”。
4. 提炼核心内容，并区分：
- `明确偏好`：用户直接表达喜欢、不喜欢、应该或不应该；
- `推断信号`：Agent 根据示例推断的潜在 taste；
- `领域知识`：值得保留，但不能直接解释为用户偏好；
- `待验证项`：证据不足或与既有记录冲突。
5. 写明适用范围、边界、反例和可执行影响。若材料没有提供这些信息，标记未知，不要脑补。
6. 更新 `TASTE.md`：
- 明确偏好可直接加入，并链接学习记录；
- 单个示例产生的推断默认标记为 `暂定`；
- 纯领域知识留在学习记录中，除非它形成了可复用的判断原则；
- 与既有偏好冲突时保留两份证据，标注条件差异或时间演变，不静默删除旧结论。
7. 运行 `python3 scripts/validate.py`，检查记录结构和证据链接。
8. 向用户简短报告：学到了什么、更新了哪些文件、哪些结论仍是推断。
输入清楚时直接沉淀，不为格式细节打断用户。只有缺失信息会实质改变结论时才提问。
## Evidence Discipline
`TASTE.md` 中每个条目必须包含：
- 状态：`确认`、`暂定`、`有条件` 或 `已取代`；
- 适用范围；
- 一句话规则；
- 至少一个指向 `learnings/` 的证据链接；
- 必要时包含反例、冲突或未知项。
不要把“用户分享了某内容”等同于“用户赞同其中所有观点”。不要把描述性事实改写成规范性偏好。不得为了画像整洁而删除有意义的分歧和演变记录。
## Change Discipline
- 每次学习只修改该条记录、`TASTE.md` 中相关部分，以及确有必要的索引或说明。
- 不做无关重构或格式化。
- 使用可读的 Markdown 和相对链接，保证该目录脱离当前对话后仍可使用。
- 完成前运行 `python3 scripts/validate.py`，并人工检查结论强度与证据相符。

29
README.md Normal file
View File

@@ -0,0 +1,29 @@
# AI Distillate
这是一个长期维护的个人 AI 蒸馏目录。目标是持续学习我认可、欣赏或反对的内容，逐步形成可追溯、可修正、可被 AI/Agent 直接使用的 taste，使其判断、表达和行动越来越符合我的偏好。
## 使用方式
对话中使用以下格式提交学习材料：
```text
学习：xxx
```
`xxx` 可以是观点、案例、文本、链接、文件或对某个结果的反馈。Agent 会：
1. 在 `learnings/` 中保存一份可追溯的独立学习记录；
2. 提炼内容中的观点、偏好、边界、反例和可行动规则；
3. 仅把可跨任务复用的信号更新到 `TASTE.md`；
4. 明确区分用户直接表达的偏好和 Agent 的推断。
根目录的 `AGENTS.md` 定义具体工作流，`TASTE.md` 是当前有效画像，`learnings/` 是证据与历史。
## 原则
- 保留来源：摘要不能替代原始输入或可追溯引用。
- 忠于证据：一次示例不自动升级为普遍偏好。
- 允许演变：新旧偏好冲突时记录变化，不静默覆盖历史。
- 保留边界：记录什么场景适用，以及什么场景不适用。
- 面向行动：沉淀结果应能影响未来 Agent 的具体判断或输出。

158
TASTE.md Normal file
View File

@@ -0,0 +1,158 @@
# Taste Profile
这是用户当前有效 taste 的精炼视图。它是可修正的结论层，不是原始资料库；每条结论都应链接到 `learnings/` 中的证据。
## 使用约定
- `确认`：用户直接表达，或多份一致证据支持。
- `暂定`：由有限示例推断，需要后续学习验证。
- `有条件`：只在明确场景或约束下成立。
- `已取代`：历史上成立，但已被后续偏好更新；保留用于解释演变。
应用某条偏好前，同时检查其适用范围。发生冲突时，优先使用更明确、更近期且场景更匹配的证据。
## 条目格式
画像按领域组织，每条偏好使用以下格式：
```markdown
### 偏好标题
- 状态：确认 | 暂定 | 有条件 | 已取代
- 适用范围：这条偏好影响哪些任务或场景
- 规则：未来 Agent 应遵循的一句话规则
- 证据：[学习记录](learnings/YYYY-MM-DD-NNN-short-title.md)
- 边界：不适用场景、反例、冲突或未知项；没有则写“尚未发现”
```
同一条偏好获得新证据时，优先更新现有条目并追加证据链接；只有规则或适用范围实质不同才新建条目。
## 当前画像
### 科研选题 / 先问重要性，再寻找共性结构
- 状态：确认
- 适用范围：科研选题、问题定义、方法设计与研究方向判断
- 规则：先识别真正值得解决的问题，再从具体任务中抽象共性结构，并尽量设计对一类问题有普遍意义的解决方案；具体任务更适合作为理解共性问题的窗口，而不是研究的终点。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)，[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)，[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
- 边界：这是用户当前、明确但仍开放修正的工作定义；“好发文章”“可工业落地”“热门”、venue 或奖项都不能单独充当标准答案，抽象也必须有真实理解和科学价值支撑。外部认可可以提供反馈，但受时机、评审偏好和学术权力结构影响。
### 科研表达 / 用问题—窗口—方法—证据组织故事
- 状态：确认
- 适用范围：论文摘要、研究叙事、proposal、技术报告和结果表达
- 规则：先确定一个可用一句话复述的中心 idea，再从重要的共性问题出发，说明具体任务为何是观察该问题的 benchmark、方法如何尝试解决这类问题以及结果提供了什么证据；让段落、图和实验都服务这条主线，而不只报告“方法 A 在任务 B 上得到结果 C”。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)，[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)，[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
- 边界：更宏大的叙事不自动意味着更好的研究；问题、benchmark、方法和结果之间必须存在真实联系，不能用包装替代证据。“一个中心 idea”也不等于省略限制、反例、替代解释或会改变 claim 的必要实验。
### 科研评审 / 重视简洁、内在一致、启发性、必然性与适用范围
- 状态：确认
- 适用范围：研究问题、理论框架、实验结果、方法和抽象的质量判断
- 规则：好的研究应尽量简洁而不故弄玄虚，框架具有内在和谐，结果能引出新问题，方法与问题之间显得自然且有说服力，抽象能覆盖一类问题而非单个特例。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)，[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
- 边界：这些是启发式判断标准，不是可以机械打分的 benchmark；使用时仍需结合问题重要性、证据和领域语境。
### 科研价值 / 不以抽象之名贬低实际问题
- 状态：确认
- 适用范围：选题评价、论文评审、对工程型或应用型研究的判断
- 规则：区分真正的一般性科学价值与学术权力结构塑造的“高级感”；实际、可落地或具体的问题并不天然低级，应看研究者是否理解得足够深并能提炼出有意义的东西。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)，[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
- 边界：这不是否定科学对一般性的追求，而是要求对“高级/低级”的区分保持反思，避免把范式声望当成研究价值本身。
### 科研阅读 / 从理解走向评价与综合
- 状态：暂定
- 适用范围：论文阅读、文献调研、paper review、研究入门与选题准备
- 规则：阅读时先提炼问题与动机、贡献、证据和结论，再检查重要性、有效性、假设与历史语境，最后主动寻找替代解法、反方论证、迁移场景和开放问题；阅读的产物应是自己的判断，而不只是技术细节摘要。
- 证据：[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)，[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
- 边界：并非每篇论文都值得同样深读；可按 awareness、局部使用和准备延伸三个目的分配深度。真正影响当前 claim、实现或实验的论文需下钻到方法与证据细节；建立领域地图后仍要从 first principles 检查社区惯例，避免把独立思考误解为忽略 prior work。
### 科研发现 / 把异常当作待验证的机制线索
- 状态：暂定
- 适用范围：异常实验结果、复现失败、系统故障、经验研究与新现象判断
- 规则：结果不符合预期时，不立即把它归为 bug 或 discovery；先稳定复现并排除实现、测量和基线问题，再通过独立实现、真实样本、sensitivity 与跨场景迁移检验它是否来自可解释的共性机制。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)，[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
- 边界：大多数异常仍可能是普通错误、噪声或偶然相关；“异常值得查”不等于“异常值得发表”，一般化必须晚于排错和独立证据。
### 科研执行 / 先验证最大风险，再决定是否重投入
- 状态：暂定
- 适用范围：研究开项、原型实验、项目组合管理、论文执行与停止条件判断
- 规则：先用最小但有效的实验检验最可能失败的关键假设，并预先写清 success、failure 与 kill criteria；核心风险通过且 best-case 结论确有意义后，再围绕唯一中心 idea 为实现完整性和证据严谨性重投入，失败或意义不足时及时停止或降级交付。
- 证据：[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)，[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
- 边界：最小实验必须保留决定结论的 workload、规模和机制，不能因 prototype 失真而错误否定方向；长周期、基础性、复现、负结果和基础设施工作也可能有累积价值。停止或转向还要考虑合作者承诺、学生培养和已有 artifact，并防止用“避免 sunk cost”包装追逐新鲜感。
### 系统设计 / 先跑通简单闭环，再按真实约束演进
- 状态：暂定
- 适用范围：系统原型、研究实现、复杂工程、架构设计与从论文到生产的迁移
- 规则：先区分 Must-Have 与 Nice-to-Have，用最小机制尽快跑通端到端闭环并验证总体方向，再依据测量和真实需求迭代；演进时同时检查正确性、稳定性、扩展性、尾部行为、资源成本和可维护性。
- 证据：[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
- 边界：简单不是目标函数中的唯一维度，也不是牺牲安全、可靠性、兼容性或必要完整性的通行证；快速原型和生产系统承担的约束不同。
### GPU 服务器评审 / 从端口规格追到业务有效带宽
- 状态：确认
- 适用范围：GPU 服务器通信配置评审、硬件选型与验收、训练和推理网络瓶颈分析
- 规则：不要只看“几卡几网”和 NIC 标称速率；依次核算外部 NIC 聚合出口、PCIe 主机侧供给与共享上行、GPU 到 NIC 的 NUMA/PCIe/socket 路径、具体训练或推理通信需求，再用拓扑、NCCL、链路计数器和端到端业务指标验证实际可用能力。
- 证据：[GPU 服务器网络配置五步评审法](learnings/2026-07-20-001-gpu-server-network-review.md)
- 边界：聚合端口速率是以 bit/s 表示的理论上界，不等于应用有效吞吐；具体合格线依赖 workload、并行策略、规模和目标指标。该流程主要覆盖通信子系统，不能替代对算力、HBM、CPU 内存、存储、功耗、散热、可靠性和运维的评审。
### 科研培养 / 以独立判断而非论文数量为终点
- 状态：暂定
- 适用范围：导师—学生合作、研究团队建设、研究实习与长期技术培养
- 规则：按人的兴趣、能力、阶段和时间定制问题与风险，通过第一手实践、及时而建设性的反馈、同伴协作和逐步放权，最终让学习者能够独立选题、验证、表达和承担判断，而不是只执行论文任务。
- 证据：[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
- 边界：自主不等于放任，早期学习者通常需要更具体的支持；长期培养也不能以“坚持”为名忽视压力、退出选择、权力不对等或不健康的工作方式。
### 实验评测 / 自我比较不能代替独立基线
- 状态：暂定
- 适用范围：系统性能评测、论文 evaluation、baseline 选择、性能 claim 审计
- 规则：与自己的旧版本或内部变体比较，只能回答“这次改动对自己是否有帮助”；要证明结果的重要性、竞争力或实际价值，还必须选择与 claim 匹配的独立参照，例如公认标准、当前 SOTA、未扰动系统、理论最优值或硬件极限。
- 证据：[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md)
- 边界：自我比较对 regression、ablation、组件优化和开发过程仍然有价值；如果 claim 明确只描述内部增量，它可以是充分证据。需要外部基线时，基线类型必须由问题和 claim 决定，不能机械地一律要求同一种 competitor。
### 模型评测 / 不允许同一组假设闭环自证
- 状态：暂定
- 适用范围：仿真系统、解析模型、调度与资源模型、模型驱动的系统优化
- 规则：如果方法建立在一组简化假设上，不能只在编码了同一组假设的模型或模拟器中验证它；至少需要独立数据、不同假设下的 sensitivity，或真实系统的 reality check 来检验结论是否超出模型自身。
- 证据：[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md)
- 边界：受控模型和仿真适合隔离机制、做早期探索或计算不可直接实现的上界；问题在于用它们支持现实有效性或泛化 claim，而没有验证关键假设。
### 性能优化 / 先估算和测量，再决定复杂度预算
- 状态：暂定
- 适用范围：性能设计、热点优化、库代码、系统调优和性能 review
- 规则：先判断代码是否位于 hot path、调用规模和目标资源，再用 back-of-the-envelope estimation、profiling 和基准测量定位量级与瓶颈；只有预期收益与实测证据足够时，才为性能支付可读性、复杂度和维护成本。
- 证据：[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
- 边界：这不等于把性能问题全部推迟到 profiling 之后；若更快的设计不显著损害可读性或复杂度，应在最初设计时采用，尤其是广泛复用的 library API。估算中的操作成本只是量级直觉，必须按实际硬件和 workload 校准。
### 性能优化 / 优先减少总工作与数据移动
- 状态：暂定
- 适用范围：算法选择、数据结构、内存布局、热点循环、并发与低层代码优化
- 规则：优化时先寻找更高杠杆的变化：改善算法复杂度，消除不必要工作，批量化或把工作移出热点路径，减少 allocation、copy、cache line 和同步开销；确认这些结构性机会后，再做局部指令级微优化。
- 证据：[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
- 边界：fast path、cache、specialization、紧凑表示和 parallelism 都会交换内存、code size、尾延迟、通用性或维护复杂度；必须在固定 workload 下分别测量，不能把某个 C++ 示例机械推广到所有系统。
### 性能设计 / 用窄接口保留局部优化空间
- 状态：暂定
- 适用范围：公共 API、library、模块边界、数据所有权和并发接口设计
- 规则：优先让模块具有窄而稳定的接口，把数据结构和实现选择封装在内部；提供确有 workload 需求的 bulk、view 或复用型接口，以减少边界穿越、copy、allocation 和 lock 开销，同时避免承诺调用方并不需要、却会永久限制实现的特性。
- 证据：[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
- 边界：API usability、所有权清晰、线程安全和兼容性仍是约束；只有当调用模式和测量表明收益时才扩展性能 API，不能为了潜在优化预先增加公共表面积。
### AI 协作 / 把稀缺注意力放在判断而非操作上
- 状态：确认
- 适用范围：vibe coding、AI 辅助科研、Agent 的任务分工与输出重点
- 规则：充分利用 AI 完成实现、检索和文字处理，但把更多注意力投入问题是否值得解决、哪些文献真正重要、异常结果如何解释、研究故事如何成立，以及什么才算好的输出。
- 证据：[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)
- 边界：操作能力仍是验证想法和形成可靠证据的必要条件；AI 降低操作门槛，不等于实现质量、事实核查或实验正确性可以被忽略。

121
learnings/2026-07-18-001-research-taste-in-vibe-coding.md Normal file
View File

@@ -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-协作--把稀缺注意力放在判断而非操作上)

71
learnings/2026-07-18-002-do-not-benchmark-against-yourself.md Normal file
View File

@@ -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#模型评测--不允许同一组假设闭环自证)

104
learnings/2026-07-18-003-abseil-performance-hints.md Normal file
View File

@@ -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#性能设计--用窄接口保留局部优化空间)

303
learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md Normal file
View File

@@ -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#科研培养--以独立判断而非论文数量为终点)

110
learnings/2026-07-19-001-how-to-win-a-best-paper-award.md Normal file
View File

@@ -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#科研执行--先验证最大风险再决定是否重投入)

122
learnings/2026-07-20-001-gpu-server-network-review.md Normal file
View File

@@ -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-服务器评审--从端口规格追到业务有效带宽)

65
learnings/README.md Normal file
View File

@@ -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` 记录材料中提及、但本次未必独立核验的作品或线索。两者不能混用。

174
scripts/validate.py Executable file
View File

@@ -0,0 +1,174 @@
#!/usr/bin/env python3
"""Validate the structure and evidence links of the AI distillate."""
from __future__ import annotations
import re
import sys
from pathlib import Path
ROOT = Path(__file__).resolve().parent.parent
LEARNINGS = ROOT / "learnings"
REQUIRED_FILES = (
ROOT / "README.md",
ROOT / "AGENTS.md",
ROOT / "TASTE.md",
LEARNINGS / "README.md",
)
RECORD_NAME = re.compile(
r"^(?P<date>\d{4}-\d{2}-\d{2})-(?P<number>\d{3})-"
r"(?P<slug>[a-z0-9][a-z0-9-]*)\.md$"
)
RECORD_HEADINGS = (
"# ",
"## 原始输入",
"## 内容蒸馏",
"## Taste 信号",
"### 明确偏好",
"### 推断信号",
"### 领域知识",
"## 边界与反例",
"## 可执行影响",
"## 画像更新",
)
PROFILE_LABELS = ("状态", "适用范围", "规则", "证据", "边界")
PROFILE_STATUSES = {"确认", "暂定", "有条件", "已取代"}
EVIDENCE_LINK = re.compile(r"\]\((learnings/[^)#]+\.md)(?:#[^)]+)?\)")
def parse_front_matter(text: str) -> dict[str, str] | None:
if not text.startswith("---\n"):
return None
closing = text.find("\n---\n", 4)
if closing == -1:
return None
fields: dict[str, str] = {}
for line in text[4:closing].splitlines():
if ":" in line and not line.startswith((" ", "\t")):
key, value = line.split(":", 1)
fields[key.strip()] = value.strip()
return fields
def validate_record(record: Path) -> list[str]:
errors: list[str] = []
match = RECORD_NAME.fullmatch(record.name)
if match is None:
return [f"{record.relative_to(ROOT)}: 文件名不符合约定"]
text = record.read_text(encoding="utf-8")
fields = parse_front_matter(text)
if fields is None:
return [f"{record.relative_to(ROOT)}: 缺少完整的 YAML front matter"]
expected_id = record.name[:14]
required_fields = {"id", "date", "status", "tags", "sources", "references"}
missing_fields = sorted(required_fields - fields.keys())
if missing_fields:
errors.append(
f"{record.relative_to(ROOT)}: 缺少字段 {', '.join(missing_fields)}"
)
if fields.get("id") != expected_id:
errors.append(
f"{record.relative_to(ROOT)}: id 应为 {expected_id}"
)
if fields.get("date") != match.group("date"):
errors.append(
f"{record.relative_to(ROOT)}: date 应与文件名日期一致"
)
if fields.get("status") not in {"distilled", "needs-evidence"}:
errors.append(
f"{record.relative_to(ROOT)}: status 必须是 distilled 或 needs-evidence"
)
lines = text.splitlines()
for heading in RECORD_HEADINGS:
if heading == "# ":
if not any(line.startswith("# ") for line in lines):
errors.append(f"{record.relative_to(ROOT)}: 缺少一级标题")
elif heading not in lines:
errors.append(f"{record.relative_to(ROOT)}: 缺少标题 {heading}")
return errors
def validate_profile() -> list[str]:
profile_path = ROOT / "TASTE.md"
text = profile_path.read_text(encoding="utf-8")
marker = "## 当前画像"
if marker not in text:
return ["TASTE.md: 缺少‘当前画像’部分"]
current = text.split(marker, 1)[1].strip()
placeholder = "尚无通过 `学习：xxx` 沉淀的条目。"
if current == placeholder:
return []
if placeholder in current:
return ["TASTE.md: 已有画像条目时应删除空画像占位文字"]
starts = list(re.finditer(r"(?m)^### (.+)$", current))
if not starts:
return ["TASTE.md: 当前画像必须使用三级标题组织条目"]
errors: list[str] = []
for index, start in enumerate(starts):
end = starts[index + 1].start() if index + 1 < len(starts) else len(current)
title = start.group(1)
entry = current[start.end():end]
values: dict[str, str] = {}
for label in PROFILE_LABELS:
match = re.search(rf"(?m)^- {re.escape(label)}：(.+)$", entry)
if match is None:
errors.append(f"TASTE.md / {title}: 缺少‘{label}’")
else:
values[label] = match.group(1).strip()
if "状态" in values and values["状态"] not in PROFILE_STATUSES:
errors.append(f"TASTE.md / {title}: 状态值无效")
if "证据" in values and EVIDENCE_LINK.search(values["证据"]) is None:
errors.append(f"TASTE.md / {title}: 证据必须链接到 learnings/ 记录")
return errors
def validate_evidence_links() -> list[str]:
text = (ROOT / "TASTE.md").read_text(encoding="utf-8")
marker = "## 当前画像"
if marker in text:
text = text.split(marker, 1)[1]
errors: list[str] = []
for relative_path in EVIDENCE_LINK.findall(text):
if not (ROOT / relative_path).is_file():
errors.append(f"TASTE.md: 证据链接不存在：{relative_path}")
return errors
def main() -> int:
errors = [
f"缺少必要文件：{path.relative_to(ROOT)}"
for path in REQUIRED_FILES
if not path.is_file()
]
if errors:
for error in errors:
print(f"ERROR: {error}", file=sys.stderr)
return 1
records = sorted(
path for path in LEARNINGS.glob("*.md") if path.name != "README.md"
)
for record in records:
errors.extend(validate_record(record))
errors.extend(validate_profile())
errors.extend(validate_evidence_links())
if errors:
for error in errors:
print(f"ERROR: {error}", file=sys.stderr)
return 1
print(f"OK: {len(records)} learning record(s), profile structure is valid")
return 0
if __name__ == "__main__":
raise SystemExit(main())