# 编辑边界

这里处理容易误改的情况。通用要求和输出方式以 [SKILL.md](../SKILL.md) 为准；没有这些疑问时不必读取。

## 删除之后，还剩原来的意思吗

“值得注意的是，缓存已经失效”可去掉提示语；“缓存已经失效”不能因为简短或没给日志而删掉。“完成了对配置的检查”可改成“检查了配置”，但不能补出检查结论。判断重复时比较完整含义：数据结果不替代作者对意义或能力的评价，功能不替代目标，性能不替代成本收益。即使这些评价像宣传，也只能清理表达，不能整条删去。

修饰与概括默认保留，只有保留部分完整表达同一内容时，才按重复处理。给了指标，不等于其他背景、评价或作用已被覆盖，也不能说它没有指标支撑。作者对性质、作用强度和主次的判断都是内容。系统性重塑不改成泛泛调整，质的变化不降为普通改善，关键因素不补成“也有作用”。无法确定动作实际所指时，保留原说法，不替作者在定位、解决或控制风险等解释中选一种。已经改善、仍有风险、可能失败、起决定作用等关系不能跟着删。“不是因为权限不足”只排除一种失败原因，不能改成“权限充足”；否定词约束哪个事实或原因要一起保留。

进度和次数也算信息。“接下来检查”不能自行写成“再检查一轮”；已完成的核对不能改成仅仅可以核对。

主动语态不是硬要求。原文没写执行者，不要为了“谁做了什么”补成团队或作者做的。代词与重复词能让指代稳定，不需要每句换一种称呼。

## 客套与交付动作

“让我来详细解释”可能只是正文前的预告，可以在已有正文中删除；如果整段只有预告而没有答案，不续写不存在的答案。

无依据地说“你已经是资深专家”是对读者的身份认证；“得到负责人批准后，我可以提供草案”有交付者、条件、动作和能力情态。前者可按去套话请求清理，后者保留，即使草案内容尚未展开。不要把它改成“请先提供需求”。

作者陈述自己不舒服、拿不准、反复试过，是个人表达；“你只是太久没被理解”是在代替对方解释心理。审稿时可以指出后者的心理预设，但默认改写先保留；用户明确要求删除这类陈述时再处理，不与身份认证混为一类。

## 同一个词，不同用途

“闭环控制”“依赖注入”“问题根因”等可有准确的技术含义。保留定义、系统主语和故障状态；不要因为周围有宣传语就一并替换，也不要因为旁边有代码就放过宣传语。

如果“赋能”是标题、引文、界面文字、术语定义或被讨论的用词，按它的用途保留。正文中即使不够具体，它也可能表达帮助某个对象获得能力的目标或作用；只说面向谁并不等义。没有足够上下文支持替换时，保留这层关系和原词，只改周围赘语，不自造功能。

## 引号里是什么

引号是标点，不构成保护标记；要看它圈住的内容起什么作用。

引他人原话作为依据，引文献、规范、界面文字，或正在被定义和讨论的词，按原文保留，也不要改写成概述再塞回引号。书名号里的标题、书名、报告名同样保留。

案例、复盘、访谈里记录的人物讲话是叙述材料。可以按用户的编辑要求清理其中的口头语、填充词和重复，保留说话人、他讲的事实与判断。“可能”“我觉得”“大概”这类不确定表达跟着保留，清掉口头语不等于让这个人把话说得更肯定。不合并不同人的话，不替他补没说过的内容。用户要求保留口述原貌，或这段话本身就是被讨论的对象时不动。

正常句子里用引号标出的关键词，引号只是作者的强调或标示。词照常审查，不因为带引号就跳过。

需要保留引号内容时，保护范围到引号为止；引号外的句子和所在段落照常编辑。

## 长文、列表与作者语气

先看用户要保留什么。列表方便查步骤、表格方便比较时可以保留；有意的短句、反问、重复和转场也可能有用。不能只因句式整齐或连接词密集就判模板。

`bounded` 的删除建议引用原句，不把新补的解释伪装成原文；正文暂保留该句。`in-place` 下遇到难以安全改写的整句，可以保留，不必硬改成空泛的同义句。用户要求保长度时，检查完整稿，不用短摘要代替。

## 文档与公开表达

README 保留实际用途、适用范围与限制，不自作主张加用户群、产品能力或使用案例。Release Note 只改已有变更，不编版本、修复、测试或升级命令。Issue 回复不能补排期、复现结论或要求用户做原文没有的操作。

FAQ 的执行前条件与警告要留在操作之前；不能为了“先给答案”把它们挪后，也不能把真实的事后检查变成前提。API 文档里的 method、endpoint、参数、返回值和限制按原文保护。

公开文本缺来源时，不用“大家都知道”“据我了解”替代原归属，也不把未来判断改成已经发生。是否删论断取决于用户指定的来源处理方式；审稿提示不等于已经核实该论断。