编写或审查跨栈长期有效文档时去工具耦合：把便携内容中的偶然工…

当工件声称会比当前 agent/harness/OS/vendor/model/toolchain 更长寿时，消除便携内容中的偶然工具耦合，同时保持出处、运行手册和工具主题断言具体。

适用场景

解决思路

1. 按 Goal 判断结果：durable artifact 应在 agent、harness、OS、vendor、model 或 toolchain 变化后仍真实且可执行。
2. 在 portable content 中查找 stack-specific nouns，并把它们改写为底层机制，同时不删除它们所支持的动作。
3. 保持改写目标是可移植而非含糊：读者在改写后仍应知道要 inspect、run、measure、compare 或 verify 什么。
4. 从头到尾读完目标工件。
5. 编辑前先定角色：将整个工件分类；若内容混合，则按各节分类为 durable/portable content、provenance/operational record 或关于具名工具的断言。
6. 在 durable content 中扫描偶然耦合：harness paths、vendor CLIs 与 flags、被当作机制使用的 model 或 product brands、tool-specific environment variables、quotas、UI steps、cache homes、session files，以及被表述为永恒真理的 version-pinned behavior。
7. 机制而非委婉语：对每个 durable-content 命中，替换为能保留动作的中立机制；如果中立措辞会丢失动作，就把具体细节保留为该机制的示例，而不是假装它可泛化。
8. 保持 provenance 和 operational content 具体：build records、capsules、benchmark logs、install guides、runbooks、tool-targeted how-tos、command transcripts、exact reproduction steps 本来就应写明产生它们的 stack。
9. 保持 comparative 和 tool-subject claims 具体：如果句子是在讲具名 tool、vendor、model、bug、prior-art source 或 measured limit，那个名字是主语，不是偶然耦合。
10. 以处于不同 stack 的读者身份重读：工件在承诺可执行之处仍应真实、可移植、可执行。
11. 报告哪些被中立化、哪些被有意保留，以及每次保留背后的角色判断。
12. Rule：Role before edit。在判断文本是 portable content、provenance、operational instruction 还是 tool-subject claim 之前，绝不清洗。
13. Rule：Mechanism, not euphemism。"Use the session execution log and sum usage records" 是机制；"check the logs" 是会丢失工作的委婉语。
14. Rule：保留可执行细节。只抽象耦合，不抽象 procedure、evidence、comparison 或 constraint。
15. Rule：保持 provenance 和 operational records 精确。当 concrete paths、commands、flags、versions、products、UI steps 记录发生了什么或解释如何驱动特定工具时，保留它们。
16. Rule：保留 comparative/tool-subject names。关于 CLI 的 bug report、针对 model 的 benchmark、prior-art citation 或 vendor-specific limit 保留具名主语。
17. Rule：如果一次扫描没有发现偶然耦合，就什么都不改。
18. Rule：以 edit-safety 方式修改：断言每个目标存在，并用 MISS 报告而不是静默 no-op；unicode-safe 编辑；按 occurrence 替换，绝不 blanket sweep；对大型结构移动使用 script。
19. Verification：确认每个被修改的命中都位于 durable 或 portable content。
20. Verification：确认每个改写都保留了可执行机制。
21. Verification：确认每个保留的 tool noun 都是 provenance、operational instruction 或其所断言之物。
22. Verification：确认报告列出了被中立化的 couplings、deliberate keeps 和任何 judgment calls。

适用边界 · 注意事项

• 不要用于 provenance/operational record：build records、capsules、benchmark logs、install guides、runbooks、tool-targeted how-tos、command transcripts、exact reproduction steps 应保持具体，写明实际 stack。
• 不要用于 comparative/tool-subject claims：关于具名 tool、vendor、model、bug、prior-art source 或 measured limit 的句子中，名字是主语，不应被中立化。
• 若中立化会丢失可执行动作，不要为了去耦合而抽象掉 procedure、evidence、comparison 或 constraint；应把具体细节作为机制示例保留。