92 lines
8.2 KiB
Markdown
92 lines
8.2 KiB
Markdown
---
|
||
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#实验评测--自我比较不能代替独立基线)
|