to-the-user（TTU）
用户看见的字和界面，只对使用者负责。实现约束用来遵守，不要写进产品；页面上的每一块，都要帮助用户理解、判断或行动。
判断：没见过这次讨论的人，能不能看懂这是什么、此刻该做什么。删掉一句话、一个模块或一层装饰，如果不影响理解、操作、必要后果或品牌识别，就删。不要为了显得完整，把空位填满。
留下：要填什么、会发生什么、去哪，以及做决定必须知道的后果（价格、计费单位、退款、谁扣款）。藏实现，不藏后果；减冗余，不减可理解性。
不对使用者说的：没选哪条链路、内部系统名、为什么这样实现、无关的竞品对比。技术名词如果就是用户的操作对象，要保留。
错：支付走本站微信或支付宝，不会跳到 RivalPay。
对：邮箱。微信支付。支付宝。
界面也按同一个判断做减法：
- 一块一个用途。 标题已经说清，就不再加同义眉题、副标题、说明和徽章；上下文已经交代，就不再做一张卡片重复。不要凑三列卖点或模块数量。
- 层级先靠布局。 先用留白、对齐、字号和分组组织信息；卡片、边框、分割线、阴影、渐变和动效，只有在帮助分组、识别或反馈时才加。不要每块内容都套框、每层都画线。
- 动作有主次。 当前任务的主要动作要明显；次要操作就近放，不反复铺入口，不把能直接完成的动作拆成多层弹窗。不要为了少一个按钮，反而让用户猜图标或多走一步。
- 信息随任务出现。 引导完成后让出空间；细节在需要时展开。恒定且已明确的信息不反复占格子，没有业务含义的“Ready”不做状态卡。加载、失败、禁用原因和必要后果不能当噪音删掉。
- 品牌有重点。 沿用一致的字体、色彩和控件语言，圆角按角色使用；识别性集中在有意义的位置，不把每个表单都做成品牌展板。小票适合解释账单，不必出现在登录页。
字怎么落在页面上也要对使用者负责。字和边要留空；最后一行只剩一两个字、窄栏里长句被拆得不成句，就调整文案和布局，不靠缩小字号、降低对比度或裁掉关键信息来塞下。桌面和窄屏都要看实际落版。
错：序号贴着左边框。第三行只剩“入。”。
对：字和边有空隙。准备度通过，不等于已被引用。也不等于已经产生收入。
简洁不是固定配色、禁用卡片或一律最少字。删后仍须看懂产品、找到操作、辨认状态、读清后果。不要把“已精简 / 已留空 / 已改短”写进产品。
把本原则放进 always-on（AGENTS.md、Claude、Cursor、Grok 的全局规则），不要做成按需 skill。按 TTU 检查 审查用户可见文案、信息结构、交互层级和视觉落版；按 TTU 检查并修掉 直接完成范围内修正。
接入与检查
将 rule.md 放进项目最近的 AGENTS.md 或客户端支持的 always-on 规则。安装 Skill 本身不保证所有客户端自动常驻；接入后应在生成界面前遵守。最小写法见 docs/adoption.md。
检查使用 rubric/v2.md。每个问题指出受众、位置、具体影响、证据和最小改法；证据不足用 needs_human。只有源码时不能声称桌面、窄屏或交互已验收。
scenarios/cases.json 保留 v1 的 18 个已知场景，包含人类确认与 seed 待确认案例。它们不代表 v2 设计判断已校准；Agent 不得把自己的判定写成已确认标签。维护规则见 docs/calibration.md。
prompts/pr-review.md 提供 advisory 审查提示词，不阻止合并。测试脚本与 GitHub Actions 模板见完整仓库。
