From 561612bb3f0f0d416bc97386894b7486da462e7b Mon Sep 17 00:00:00 2001 From: Gahow Wang Date: Mon, 20 Jul 2026 16:00:43 +0800 Subject: [PATCH] learn --- TASTE.md | 16 +++- ...02-semantics-first-research-progression.md | 91 +++++++++++++++++++ 2 files changed, 103 insertions(+), 4 deletions(-) create mode 100644 learnings/2026-07-20-002-semantics-first-research-progression.md diff --git a/TASTE.md b/TASTE.md index 30a847a..354b74d 100644 --- a/TASTE.md +++ b/TASTE.md @@ -34,9 +34,17 @@ - 状态：确认 - 适用范围：科研选题、问题定义、方法设计与研究方向判断 - 规则：先识别真正值得解决的问题，再从具体任务中抽象共性结构，并尽量设计对一类问题有普遍意义的解决方案；具体任务更适合作为理解共性问题的窗口，而不是研究的终点。 -- 证据：[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) +- 证据：[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)，[从真实摩擦提炼缺失语义的研究推进法](learnings/2026-07-20-002-semantics-first-research-progression.md) - 边界：这是用户当前、明确但仍开放修正的工作定义；“好发文章”“可工业落地”“热门”、venue 或奖项都不能单独充当标准答案，抽象也必须有真实理解和科学价值支撑。外部认可可以提供反馈，但受时机、评审偏好和学术权力结构影响。 +### 系统研究 / 从跨场景摩擦提炼缺失语义 + +- 状态：确认 +- 适用范围：系统研究选题、问题归纳、抽象设计、scope 界定、实现定位与 evaluation 设计 +- 规则：从多个场景反复出现的真实摩擦中提炼最小 capability set，明确现有系统缺失的 semantics，再定义可独立复用的系统抽象；及早声明 non-goal，以现有机制实现也可以，但必须产生可解释的新语义，并让每项 design requirement 对应可回答它的 metric 与 baseline。 +- 证据：[从真实摩擦提炼缺失语义的研究推进法](learnings/2026-07-20-002-semantics-first-research-progression.md) +- 边界：跨场景相似性必须落实为同一个可检验的语义缺口，不能用新命名包装普通工具集成；概念优先不削弱实现、正确性和实验证据的要求。不同研究可有不同 non-goal，requirement 与 metric 也不必机械一一对应，但必须可追踪且足以支撑 claim。 + ### 科研表达 / 用问题—窗口—方法—证据组织故事 - 状态：确认 @@ -111,10 +119,10 @@ ### 实验评测 / 自我比较不能代替独立基线 -- 状态：暂定 +- 状态：确认 - 适用范围：系统性能评测、论文 evaluation、baseline 选择、性能 claim 审计 -- 规则：与自己的旧版本或内部变体比较，只能回答“这次改动对自己是否有帮助”；要证明结果的重要性、竞争力或实际价值，还必须选择与 claim 匹配的独立参照，例如公认标准、当前 SOTA、未扰动系统、理论最优值或硬件极限。 -- 证据：[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md) +- 规则：与自己的旧版本或内部变体比较，只能回答“这次改动对自己是否有帮助”；要证明结果的重要性、竞争力或实际价值，还必须选择与 claim 匹配的独立参照，并明确每个 baseline 回答哪个研究问题，不能把不同角色都混成一个 speedup。 +- 证据：[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md)，[从真实摩擦提炼缺失语义的研究推进法](learnings/2026-07-20-002-semantics-first-research-progression.md) - 边界：自我比较对 regression、ablation、组件优化和开发过程仍然有价值；如果 claim 明确只描述内部增量，它可以是充分证据。需要外部基线时，基线类型必须由问题和 claim 决定，不能机械地一律要求同一种 competitor。 ### 模型评测 / 不允许同一组假设闭环自证 diff --git a/learnings/2026-07-20-002-semantics-first-research-progression.md b/learnings/2026-07-20-002-semantics-first-research-progression.md new file mode 100644 index 0000000..c2d28b0 --- /dev/null +++ b/learnings/2026-07-20-002-semantics-first-research-progression.md @@ -0,0 +1,91 @@ +--- +id: 2026-07-20-002 +date: 2026-07-20 +status: distilled +tags: [research-method, systems-research, abstraction, semantics, evaluation, baseline] +sources: [user-provided research note] +references: + - "Semisolate / Try（用户提供的论文与系统案例，本次未独立核验原文）" + - "OverlayFS、Docker、native dry-run 与 Linux primitives（案例中提及的技术与 baseline，本次未独立核验）" +--- + +# 从真实摩擦提炼缺失语义的研究推进法 + +## 原始输入 + +> 对 research 最值得学习的推进方式 +> +> | 研究阶段 | 这篇论文怎么做 | 可复用的经验 | +> |---|---|---| +> | 观察 | 收集 LLM、dry-run、dependency、third-party hook 等案例 | 不要从技术开始，从反复出现的真实摩擦开始 | +> | 归纳 | 提炼 I/A/S/M 四项共同需求 | 将案例压缩成最小 capability set | +> | 定位缺口 | 分析 direct execution、sandbox、container、dry-run 的不足 | 明确已有系统缺的是哪一种 semantics | +> | 提出抽象 | 定义 Semisolate，而不是直接提出 OverlayFS 工具 | 好论文先贡献概念，再贡献实现 | +> | 限定范围 | 面向 accidental effects，不面向主动恶意程序 | 及早声明 non-goal，避免 claim 失控 | +> | 实现 | 组合现有 Linux primitive 实现 Try | Novelty 可以来自组合后的新语义 | +> | 验证 | 分别验证 control、equivalence、performance | Evaluation metric 应逐一对应 design requirement | +> | 审查 | 与 vanilla、Docker、native dry-run、人工 specification 比较 | 每个 baseline 回答不同问题，不要混成一个 speedup | +> +> 最关键的研究方法是： +> 先发现多个领域看似不同的问题共享同一种缺失能力，再把这项能力提升为一个有清晰语义、可独立复用的系统抽象。 +> +> 这也是 Semisolate 比“一个更方便的 OverlayFS wrapper”更像研究贡献的原因。它的实现并不神秘，但它把 effect inspection、delayed propagation、stacking 和 selective application 放进了一个统一的 conceptual model。 + +## 内容蒸馏 + +这份方法把系统研究推进组织为一条可审查的证据链，而不是从已有技术反推问题：先跨场景收集反复出现的真实摩擦，再把表面不同的案例压缩为最小 capability set；随后比较现有执行模型，指出它们缺失的具体 semantics，并把该缺失能力定义为有清晰边界、可独立复用的系统抽象。实现是抽象的落地，不是贡献叙事的起点。 + +这条路线也明确区分概念创新与底层机制发明。系统可以组合已有 Linux primitives；只要组合产生了此前缺失、可说明且可复用的新语义，novelty 就不依赖某个神秘的新机制。相反，仅给已有工具增加便利封装，而没有新的语义模型、适用范围或可检验能力，不足以自动形成研究贡献。 + +scope 与 evaluation 必须和抽象同时成立。及早声明只处理 accidental effects、不处理主动恶意程序，可以阻止 claim 滑向未经验证的安全保证。评测则不能把所有结果压成一个 speedup：control、equivalence、performance 等 design requirements 应分别获得对应 metric；vanilla、Docker、native dry-run、人工 specification 等 baseline 也应分别回答不同问题。 + +在用户给出的案例解释中，Semisolate 的研究性来自统一 effect inspection、delayed propagation、stacking 和 selective application 的 conceptual model，而不只是成为更方便的 OverlayFS wrapper。案例还以 `I/A/S/M` 指代四项共同需求，但本次输入没有展开缩写与上述四项能力的精确对应关系，因此不补写映射。 + +## Taste 信号 + +### 明确偏好 + +- 研究应从多个真实场景反复出现的摩擦出发，而不是先选技术再寻找用途。 +- 应把跨领域案例压缩为最小 capability set，并明确指出现有系统缺少的具体 semantics。 +- 好的系统论文应先贡献一个语义清晰、可独立复用的概念抽象，再说明如何实现它。 +- 机制本身可以复用已有 primitives；只要组合产生新的、可解释的系统语义，仍可构成有意义的 novelty。 +- 应及早声明 non-goal，防止适用范围和 claim 失控。 +- Evaluation metric 应逐项对应 design requirement；不同 baseline 应回答不同研究问题，不能被混写成单一 speedup。 + +### 推断信号 + +- 相比底层机制是否炫目，更看重一项工作是否发现了此前未被命名的共性能力，并为它建立统一 conceptual model。 +- 判断“抽象”是否像研究贡献时，可能会检查它能否同时解释多个场景、提供清晰操作语义，并支持独立实现与复用，而不只看命名或包装。 +- 偏好让问题观察、能力归纳、语义缺口、实现机制和评测问题逐层对应，避免研究故事在中间发生偷换。 + +### 领域知识 + +- 用户提供的案例把 Semisolate 的目标范围限定为 accidental effects，而非主动恶意程序。 +- 案例称 Try 通过组合现有 Linux primitives 落地 Semisolate，并将 effect inspection、delayed propagation、stacking 和 selective application 放入统一模型。 +- direct execution、sandbox、container 和 dry-run 被作为现有方案类别；vanilla、Docker、native dry-run 和人工 specification 被赋予不同 baseline 角色。 +- 以上 Semisolate、Try、技术机制与 baseline 的具体描述均来自用户本次输入，本次未查阅论文或 artifact 独立核验。 + +## 边界与反例 + +- 从多个案例抽象共性能力，前提是它们确实共享同一语义缺口；表面相似或都能被同一技术处理，不足以证明存在统一抽象。 +- “最小 capability set”不能为了叙事整齐而删掉决定正确性、可用性或适用边界的能力；最小性仍需由案例覆盖和反例检验。 +- 先贡献概念不代表实现与证据次要。抽象必须能落地、与既有系统形成可解释差异，并由对应实验验证。 +- 组合已有 primitives 只有在产生可辨认的新语义、接口或能力时才形成 novelty；便利封装、重新命名或普通工程集成不自动成为研究贡献。 +- “accidental effects 而非主动恶意程序”是该案例的 scope，不应泛化为所有系统研究的默认 non-goal；安全场景需要威胁模型和相应证据。 +- design requirement 与 metric 应逐项可追踪，但不必机械地一项只用一个数字；一个 requirement 可能需要多种 workload、metric 或 failure case 才能充分验证。 +- 本次只收到方法总结，未收到论文链接或原文；`I/A/S/M` 的展开、系统实现细节和实验结论均保持未核验状态。 + +## 可执行影响 + +- 启动系统研究时先建立 `friction log`：记录跨领域案例、共同受阻动作、现有 workaround 和重复发生条件，再判断是否存在共性缺失能力。 +- 用一张 capability table 压缩案例：行为需求、最小能力、必须保持的不变量、反例与未知项；若某项只服务单个案例，暂不提升为核心抽象。 +- 比较已有系统时，不只列 feature matrix；明确每类方案的执行语义、可观察效果、传播时机、组合方式和适用边界，写出缺失的那一种 semantics。 +- 在实现前写清抽象的操作语义、scope、non-goal 和最小接口，再说明每个底层 primitive 如何实现这些语义；避免由工具名称定义研究贡献。 +- 建立 evaluation matrix：`design requirement → claim → metric/workload → baseline → pass criterion`。每个 baseline 标注它回答的问题，性能数字不能替代 control 或 equivalence 证据。 +- 审查系统论文时追问：删去实现细节后，是否仍有可独立表述和复用的概念？删去概念命名后，实现是否只是已有工具的便利包装？两者的答案共同决定贡献强度。 + +## 画像更新 + +- 补充证据：[科研选题 / 先问重要性，再寻找共性结构](../TASTE.md#科研选题--先问重要性再寻找共性结构) +- 新增：[系统研究 / 从跨场景摩擦提炼缺失语义](../TASTE.md#系统研究--从跨场景摩擦提炼缺失语义) +- 补充证据并确认为直接偏好：[实验评测 / 自我比较不能代替独立基线](../TASTE.md#实验评测--自我比较不能代替独立基线)