用途：Unbury 把冗长、AI 风格的技术解释改写为工程沟通。目标读者是技术能力足够但尚不了解情况的工程师，每次编辑只服务于一个衡量标准：读者多快能建立正确的心智模型。它并非“让文字听起来不像 AI”，也不是“写得随意”，而是像一名优秀工程师向另一名优秀工程师清晰说明问题。目标是降低认知负担，而非压缩字数；改写可能更短、相近甚至偶尔更长，只要读者更快建立正确模型且决策关键事实全部保留，就不以压缩百分比为目标。
主要能力与工作流：先读完整原文，按信息层级列出所有断言，并标注为源文支持、源文声称或无法核实，作为改写的准确性契约。再识别产物类型与读者（PR 描述由审阅者读来决定是否批准，Slack 更新由读者决定是否行动，设计文档由读者判断方案是否成立），并保持该格式。首句用可观察的具体行为说明发生了什么，框架名、类型层级与线格式放在读者能想象行为之后。其余内容按层级排序：发生了什么、本应如何、为何发生、改了什么、如何验证、实现细节与关键边界。优先具体例子而非抽象，能在同样简短时优先字面技术陈述而非比喻。
处理衍生结论：当源文既定事实按因果顺序重组后，可显式呈现“直接衍生”的隐含结论，措辞与源文确定性一致（如“therefore”“appears to”）；需要额外领域知识或假设的“外部推断”不得写入正文，只在交付备注中标记。
取舍规则：删去重复、不会促使读者行动的测试机制、无人会提的替代方案、重复论证的证据、过程叙述等；延后放置提醒、行为变更、兼容性说明、未验证环境等；保留改变事实成立的限定、明确未做与未验证的内容、消费者必须知道的行为与兼容性变更、非显而易见后果、多处改动差异说明、读者验证所需的关键数字或名称、可搜索标识符（提交哈希、issue/PR 编号、错误字符串）以及作者本人表述的不确定性。若保留评价性措辞，须保留支撑它的事实。
风格规则：对比结构、三连与对称句式、比喻、破折号与括号、断续短句等，只在拖慢理解时编辑；标题须帮助读者导航或表明独立部分，否则删除；因果链不适合用项目符号，并列独立项适合。
边界：不得改变技术断言的含意、把保留语气强化为确定、删掉已声明的限制；不得编造事实、数字、测试结果或理由。机器与流程必需文本（关闭 issue 行、任务清单复选框、来源署名、变更日志指令、模板标题、自动化标记、必须精确的标识符与命令）视为功能内容，不得改写、移动、合并或删除。不得删除承载信息的作者口吻。不得简化技术内容本身，只简化通往内容的路径。交付时给出改写正文及交付备注，列出删去、刻意保留、已标记但未写入的后果，以及无法核实但需区分的断言；核实免责声明放在备注而非正文。
适用场景：PR 描述、Slack 更新、设计文档、变更日志等技术沟通产物。限制：官方资料未提供具体安装命令、平台、收费与价格信息，暂未提供。