8.2 KiB
id, date, status, tags, sources, references
| id | date | status | tags | sources | references | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-20-002 | 2026-07-20 | distilled |
|
|
|
从真实摩擦提炼缺失语义的研究推进法
原始输入
对 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 证据。 - 审查系统论文时追问：删去实现细节后，是否仍有可独立表述和复用的概念？删去概念命名后，实现是否只是已有工具的便利包装？两者的答案共同决定贡献强度。
画像更新
- 补充证据：科研选题 / 先问重要性，再寻找共性结构
- 新增：系统研究 / 从跨场景摩擦提炼缺失语义
- 补充证据并确认为直接偏好：实验评测 / 自我比较不能代替独立基线