用途：在继续开发前，先用一句具体的话描述对象（产品、API、工具或设计），并把它当作审计工具。句子要写明对象、动词和范围，不用营销词，不写“灵活处理”“统一体验”之类表述。必须把句子显式写出来，让读者看到描述与实际之间的差距；若句子反复漂移，说明设计尚未收敛，应先指出歧义。
两种应用：A 自洽性审计（自上而下），对象是设计、规格或界面（命令、端点、选项、表），句子即论点，逐项检查每个界面是否服务于该句、删除后句子是否仍成立、是否有动词缺少对应界面、是否有界面冗余、是否有小功能迫使出现第二句产品描述，并检查是否存在“拒绝10%到20%功能以消除80%到90%复杂度”的非对称收益机会。B 增值审计（自下而上），对象是单个工具、包装器、标志、端点或配置项，按顺序做三步归约：先忽略名称、JSDoc、README，只读代码体，用“这个函数______”写出机制；再按实际使用的默认配置特化，被非默认选项保护的功能不计入；最后检查调用方是否真的需要默认配置版本，若不需要则说明工具、默认值或包装器不匹配。
适用场景：设计讨论即将结束、规格各节互不相关、命令或端点列表超过约5项、两位贡献者对同一系统描述不同、准备新增界面却无法清晰论证、用户问“这是什么”或“一句话说明”；以及评估抽象是否值得保留、审查包装器、为过度文档化的东西写文档、在推荐包装或扩展前、审查自己刚写的抽象、代码与文档不一致时。
限制：这不是命名练习，也不是营销标语，更不是完整规格；它只是写规格前的自洽性关卡或抽象落地前的嗅探测试。若无法用一句具体的话说明对象，或诚实结论是“其实没什么价值”，则设计或抽象不值得保留。资料未提供具体安装命令、代码示例或收费信息。