detool

移除那些声称能超越其生成技术栈而长期有效的产物中偶然存在的工具耦合。

目标

持久产物应在 Agent、执行框架、操作系统、供应商、模型或工具链发生变化后，依然真实且可执行。detool 会查找可移植内容中的特定技术栈名词，并将其改写为底层机制，同时保留这些名词所支持的操作。

目标是可移植性，而非含糊其辞。改写后，读者仍应知道要检查、运行、测量、比较或验证什么。

工作流

1. 从头到尾阅读目标产物。
2. 先判断角色，再编辑：将整个产物，或混合内容中的各个部分，归类为持久／可移植内容、来源／操作记录，或关于具名工具的论断。
3. 扫查持久内容中的偶然耦合：执行框架路径、供应商 CLI 及其标志、被用作机制的模型或产品品牌、特定工具的环境变量、配额、界面操作步骤、缓存目录、会话文件，以及被当作永恒事实陈述的特定版本行为。
4. 描述机制，而非委婉其辞：将持久内容中的每处命中改写为能保留操作的中性机制。如果中性措辞会丢失操作，就将具体细节保留为该机制的示例，而不要假装它具有普遍适用性。
5. 保留具体的来源和操作内容。构建记录、运行环境封装、基准测试日志、安装指南、操作手册、针对特定工具的教程、命令记录和精确复现步骤，都应写明生成它们的技术栈。
6. 保留比较性论述和以工具为主题的论断中的具体内容。如果句子讨论的是某个具名工具、供应商、模型、漏洞、先前技术来源或测得的限制，那么该名称就是论述对象，而非偶然耦合。
7. 以使用不同技术栈的读者视角重新阅读：产物仍应真实、可移植，并能在承诺提供操作指导的地方实际执行。
8. 报告哪些内容已被中性化、哪些内容是有意保留的，以及每项保留背后的角色判断。

规则

• 先判断角色，再编辑。 在确定文本属于可移植内容、来源记录、操作说明还是以工具为主题的论断之前，绝不要清除具体内容。
• 描述机制，而非委婉其辞。 “使用会话执行日志并汇总用量记录”描述的是机制；“查看日志”则是丢失了具体操作的委婉说法。
• 保留可执行细节。只抽象化耦合，不要抽象化流程、证据、比较或限制。
• 精确保留来源和操作记录。记录已发生的事情或说明如何使用特定工具时，具体路径、命令、标志、版本、产品和界面操作步骤都应保留。
• 保留比较性论述或以工具为主题的论断中的名称。关于 CLI 的漏洞报告、与某个模型进行的基准测试、先前技术的引用或供应商特定的限制，都应保留具名对象。
• 如果某次检查未发现偶然耦合，就不要做任何改动。
• 采用安全的编辑方式：断言每个目标都存在，并在未命中时报告 MISS，而不是悄然不做任何更改；安全处理 Unicode；逐处替换，不要一概扫替；大规模结构调整应使用脚本。

验证

完成前，确认：

1. 每处已修改的命中都位于持久或可移植内容中。
2. 每处改写都保留了可执行机制。
3. 每个保留的工具名词都属于来源记录、操作说明，或其论断的主题。
4. 报告列出了已中性化的耦合、有意保留的内容，以及任何需要判断的事项。