less 是做什么的？
少，但更好。只保留有理由存在的东西。
测试
对于每个元素（句子、警示、标题、要点、注释、函数、参数、选项），问一句：这个有明确的理由存在吗？ 如果没有，就删除它。清晰胜过简洁。不确定时就保留。判断一段内容在上下文中的作用，而不是看它是否符合某个固定短语。阅读周围的文字：一个限定词可能影响后面的句子。保持未被确认要删除的句子和代码区域不变；只允许那些删除所需的局部修补。
何时使用
仅在用户请求或出现明确提示时使用，而不是在起草或写新代码时。删除不必要的材料；只允许保持结果语法正确或可执行所需的局部编辑（例如内联一个多余的辅助函数）。不进行独立的风格或语气改写、翻译、固定长度摘要、事实核查、算法替换或性能优化工作。
不适用
返回原始输入并在末尾添加一行说明原因的标注：
- 法律、合同或其他逐字文本；引用和转录。
- 用户未指明的代码、配置或命令。
只修改用户指明的代码。用户设置的长度或格式不是排除理由：在其约束内工作。
删除顺序
首先对照“永不删除”检查每个候选项，尤其是用户自己的问候和结尾。
文本：
- 你添加的开场白、重复的问题和问候（“好问题！”）。
- 你添加的结尾总结和提议，或结束 PR 描述、提交信息或文档的内容（“希望这有帮助”、“你想让我...”）。
- 不改变任何信息的模糊词汇和填充词。
- 重复的观点（保留最清晰的）。
- 未请求的警示和替代方案，且不改变读者行为。
- 对长度约为 5 句以下的回答的装饰：标题、加粗、要点。
- 合并并缩短其余内容，保持完整的句子。在编辑用户文本时，不要合并或改写句子；只修复因删除而直接影响的语法。
代码：
- 重述代码的注释。
- 不必要的抽象：辅助函数、包装器、接口、工厂。单次使用本身不是抽象不必要的证据。
- 未请求的选项、标志、配置。
- 针对从可见代码中证明不可能发生的情况的防御性代码。否则保留。
在删除代码或选项之前，检查可用的调用方、导出和相关的测试。除非用户明确要求更改，否则保留外部使用的签名和行为。在代码编辑后运行相关现有检查；如果无法确定用法或行为，则保留候选项。
文档：逐节应用测试。保留读者导航所需的结构：标题、目录和锚点、其他地方引用的编号步骤、承载数据的表格。只有当整个部分未通过测试时才删除整个部分。除非整个部分被删除，否则保留每个标题及其目录条目；切勿将一部分合并到简介中。
设计：对于用户指明的 UI 代码，对元素和样式应用测试。仅在对 references/design.md（删除顺序和永不删除列表）进行检查后才删除。那里提到的“未请求的内容”指的是代理添加的内容，而不是用户写的内容。只修改标记和样式；不添加新美学。不用于构建新 UI、截图或 Figma 文件。
永不删除
- 正确性：数字、单位、日期、条件、异常、否定。
- 主张强度：不确定性、近似值、范围、因果关系和义务。保留承载意义的限定词，如“大约”、“一些”、“最多”、“可能”和“必须”；缩短不能加强或削弱主张。
- 必要的上下文：读者行动所需的信息（前提条件、步骤、版本）。
- 安全性：数据丢失、安全、金钱、法律、不可逆操作警告。
- 用户的要求：请求的内容、格式、长度、约束。
- 归属和引用。
- 编辑用户文本时保留用户自己的语气。不要重写风格。
- 在写给其他人的消息（电子邮件、聊天、信件）中，用户写的问候、签名和请求回复或提问的语句（“如果还有不清楚的地方请告知。”）。例如，“请随时联系我，如果仍然有任何不清楚的地方。”保留；你可以删减“随时”和“仍然”。只有问候和结尾受保护：用户文本中的其他填充词（“基本上”、“实际上”、“只是”）仍然会被删除，但保留其语气。
- 礼貌用语：존댓말/敬語 形式、様、问候、签名。其中的堆叠软化词和强调词（정말, 혹시, 大変, 誠に, 何卒）只是候选者：只有当它们承载不确定性或社交意图时才保留。
- 代码：行为（输出、副作用、错误）；在真实边界（I/O、网络、用户输入）的错误处理；“为什么”注释、约束、安全说明；除非被要求，否则保留公共 API 和签名；影响类型检查或运行时的类型注解；仅用于测试的钩子和接缝。
- 任何你无法确定其用途的东西。
停止
当每个元素都通过测试时，或者下一次删除会损害含义或需要猜测时，停止。将结果与源材料比较，检查主张强度是否有变化，以及对周围好的材料是否有非预期的编辑。永远不要为了达到目标长度而删除。如果用户要求缩短他们的文本，那么未通过测试的填充词会被删除；未更改的部分需要有理由。
输出
只输出精简后的文本或代码，保持相同的格式和语言。例外：在“不适用”场景下输出一行解释原因。不要对被删除的内容进行评论，除非用户要求；如果用户要求，则列出被删除的内容。如果没有变化，则原样返回。