@chinhae/atw-cli 0.4.0 → 0.6.0

package/dist/templates/common/bundled-skills/atw-prototype/references/design-direction.md

@@ -1,8 +1,38 @@
 # 设计方向
 
-模型不被推一把时，会给出让所有人都能接受的平均答案。“做得独特一点”“随机一点”推不动它，它只会换几处装饰。这里的方法都是在给模型一个具体的推力：先定调性，再用生成引擎起方向，最后用可检验的规则逼出真正的差异。
+## 目录导航
 
-本文件以方法为主，偶尔给的例子只示意要具体到什么程度，不是风格清单。方向里的题材、材质、场景、字体和配色，每次都从当前产品的内容、受众和使用场合里推出；想到的方向如果和常见的“网红风格”撞上，要能说出来自这个产品的理由，否则重选。
+- [认品类，拆标杆](#认品类拆标杆)
+- [先定调性，再求差异](#先定调性再求差异)（含 [模糊词翻译](#模糊词必须翻译)）
+- [用生成引擎起方向](#用生成引擎起方向)
+- [定色彩](#定色彩)
+- [定首屏骨架](#定首屏与工作区骨架)（[说服型骨架](direction-persuasion.md)）
+- [方向卡](#方向卡)
+- [差异检验](#差异检验)
+- [北极星与呼应](#北极星与呼应)
+- [让人记住的一刻](#让人记住的一刻)
+- [参考怎样转为设计决定](#参考怎样转为设计决定)
+- [小样、选择与品味](#小样选择与品味)
+
+方向的目标是“这个品类里最好的团队会这样做，而且做出了这个产品自己的样子”；只是“和模型的默认不一样”还不够。高级感来自一套语言的完整和细节，不来自题材少见。
+
+方向里的题材、材质、场景、字体和配色，每次都从当前产品的内容、受众和使用场合里推出；想到的方向和常见的“网红风格”撞上时，要能说出来自这个产品的理由，否则重选。
+
+## 认品类，拆标杆
+
+动手前先认清这是什么品类的产品，再看这个品类里做得最好的产品是怎么做的。这一步给出地板：用户已经习惯的结构，以及一线产品的完成度。后面的调性和生成引擎，是在这块地板之上找这个产品自己的东西。
+
+按三步做，每一步都写下来：
+
+1. **说出品类和标杆。** 这是什么品类的产品，例如“语言学习 App”“组件库官网”“项目管理工具”“作品画廊”。这个品类里风格最鲜明的两三家是谁。选风格最鲜明的，不一定是最有名的。
+2. **拿到真实画面，再拆其中一家。** 用宿主的浏览器或搜索，取到这两三家标杆的首屏和一个关键控件的真实画面，存进任务目录的 `references/`，对着图拆，不凭记忆写：记忆里的产品常常是它几年前的样子。某一家的页面打不开或者是 404，换一个地址再试一次，还不行就换一家；拿到两家的真实画面就够，打不开的页面不算参考。拆成 6–10 条看得见的要素，每条写两件事：它是什么样，它为什么这样做。按这几层去拆：控件的形状和手感、字体、颜色、图标和插画、状态与反馈、动效、文案语气、首屏放了什么。要拆到能照着做的程度：写出形状、尺寸关系、状态怎样变化，以及它服务的使用场合。拆出来只有“干净、留白、一种强调色”，说明没拆到位，换一家重拆。确实拿不到画面时，在方向卡“标杆与取舍”开头写明“未看图，凭记忆”，并把字体、色彩、主视觉三栏标为待验证：这三栏最容易凭记忆写成模型默认。
+3. **决定留什么、换什么。** 拿本产品的受众、内容和使用场合逐条对照：理由同样成立的留下，理由不成立的换掉，换掉的部分由后面的生成引擎给出替代。结果写进方向卡的“标杆与取舍”。
+
+拆的时候分清三样东西：
+
+- **基线**：用户已经期待的结构，例如画廊里作品先行、筛选在顶部，商店里购物车在右上角。沿用它，用户不用重新学。
+- **套路**：这个品类人人都在用的默认版式。一轮方向里至少一个要打破它，见“差异检验”。
+- **撞脸**：字体、配色、主视觉和图标都和某个标杆一样，只换了名字。任何方向都不允许。
 
 ## 先定调性，再求差异
 
@@ -16,7 +46,7 @@
 | 分量 | 轻 ↔ 重 | 字重、色块面积、阴影硬度 |
 | 严肃度 | 活泼 ↔ 庄重 | 圆角、插画语言、动效幅度 |
 
-例如“地下现场演出社区 → 喧闹、粗粝、密”，“冥想陪伴 → 安静、精致、疏”。两种都完全成立，失败的是没有依据的默认：
+取值写成“这个产品是什么 → 五个刻度各取哪一端”，依据来自它的受众、内容和使用场合。刻度两端的任何组合都可以完全成立，失败的是没有依据的默认：
 
 - 证据指向喧闹粗粝，交付的却是米色卡片、柔和阴影和大留白。这是最常见的失败，设计被磨回了模型默认的“安静高级”。
 - 反过来，为了显得有趣，给一个本该安静的产品硬加颗粒、撕纸边和粗边框。
@@ -39,67 +69,68 @@
 
 翻译不出可观察决定的词，从理由里删掉。
 
+动效与交互上的模糊词同样必须翻译为具体模式：
+
+| 动效模糊词 | 翻译成什么 |
+| --- | --- |
+| 滚的时候动起来 | 先分清是滑动触发还是滑动驱动，见 [滚动叙事](../../atw-ui/references/scroll-narrative.md) 的“滚动交互的两种模式”；未明确时按单向一次性处理 |
+| 切页面丝滑一点 | 选定转场模式：遮罩式、交叠式还是共享元素，取舍和时长见 [动效](../../atw-ui/references/motion.md) 的“整页转场的稳定性取舍” |
+| 背景有立体感 | **分层视差**：前后景的速度差和哪些层不做视差，按 [滚动叙事](../../atw-ui/references/scroll-narrative.md) 的“视差与一镜到底” |
+| 首屏要有冲击力 | 明确首屏单一主角（大字排版、一件实物、核心 3D 或视频），不堆砌次要修饰；进场时长见 [动效](../../atw-ui/references/motion.md) 的“时长和幅度” |
+
 ## 用生成引擎起方向
 
-每个方向都从一个具体的引擎出发，而不是从形容词出发。不同方向最好用不同的引擎：
+每个方向都从一个具体的引擎出发，而不是从形容词出发，不同方向最好用不同的引擎。引擎的内容来自这个产品的证据：受众、内容、使用场合和品牌已有的资产。
 
-- **材质 × 环境**：一种材质放在一个具体的环境里，比如“湿陶土 × 午后的工作室”。由材质推出光照、深度、边缘的处理和动效的阻尼。
-- **一个具体场景**：一个有时间、地点和光线的场景，比如“凌晨两点的便利店”。由场景里的光线、声音、材料和节奏推出色彩、质感和动效速度。适合情绪型工具。
-- **角色原型**：给产品一个性格，比如“一丝不苟的档案管理员”，让性格决定字体、色彩和动作。
+- **材质 × 环境**：一种材质放在一个具体的环境里。由它推出光照、深度、边缘的处理和动效的阻尼。
+- **一个具体场景**：一个有时间、地点和光线的场景。由场景里的光线、声音、材料和节奏推出质感和动效速度。适合情绪型工具。
+- **角色原型**：给产品一个具体的性格，让性格决定字体和动作。
 - **一场设计运动或文化语法**：选一个和产品的题材、受众或地域有真实联系的设计运动或视觉传统，借用它的语法，而不是贴它的图案。
-- **其他领域的整套表现形式**：把另一个领域的媒介或器物的表达方式借过来，比如把行程做成一张登机牌。只借它最有辨识度的一两个手法，页面本身仍是原来的体裁；不把那个媒介的部件一件件搬来，那会变成道具堆砌。
+- **其他领域的整套表现形式**：把另一个领域的媒介或器物的表达方式借过来。只借它最有辨识度的一两个手法，页面本身仍是原来的体裁；不把那个媒介的部件一件件搬来，那会变成道具堆砌。
 - **有意打破常规**：激进的非对称版式、不和谐的配色与字体、让人不安的留白，但整体仍然好看、功能完整。
 
-感受词从这个品牌出发，而不是从行业出发。“美味、温暖、有食欲”会把每个食品应用都推向橙色；“深夜治愈、独处、温柔”才属于某一个品牌。行业惯用色可以用，前提是理由来自这个品牌；如果理由只是“这个行业都这么用”，就换掉。
-
-写方向卡之前，先在心里把方向想厚：用起来是什么感觉，让人联想到什么表面和物件，页面怎样流转，在讨好哪一类人。卡片是从这些思考里提炼出来的。跳过这一步，卡片只剩三十个字的空壳，后面做出的页面也会是平的。
+引擎决定结构、手感、质感和动效；颜色按下一节单独定。
 
-随机种子也是一种引擎：让脚本生成一串随机字符，从中联想配色、布局和字体，种子不进入界面。它适合陷入重复时破局，但不如上面几种引擎可解释。
+## 定色彩
 
-## 先定首屏骨架，再写文案
+颜色不直接取生成引擎里那种材质或场景的固有色：隐喻一落到材质，颜色就跟着材质走，不同的产品最后会落在同一组颜色上。产品自己的实物、内容和品牌资产是颜色的正当来源，主视觉就是产品实物时，主色可以从实物里取。其余按四步定：
 
-模型最顽固的习惯是左右分栏：一边大标题，另一边说明、按钮或一张图。换字体、换配色、换材质都改变不了它，因为它在写文案之前就定下来了：先想好标题、一段说明、一个按钮，把它们摆好，自然就是左右两栏。所以骨架要在写任何文案之前决定。
+1. 先写两行，几个方向共用：不看这个产品、只凭品类会顺手给出的那套配色，写出底色和强调色；拆过的标杆各占了哪个色相和明暗。
+2. 每个方向从这两者之外选一个色相家族和明暗，或明确的黑白，用一句写它来自这个产品的什么：内容、受众或品牌资产。行业惯用色可以用，前提是理由来自这个品牌。
+3. 写出至少三层：底色、主强调，以及由它们派生的选中底、描边和禁用态。
+4. 自检：去掉所有发光和模糊后，配色是否还成立；它是从这个产品推出来的，还是一组放在哪个产品上都不出错的安全色。是后者，回到第 2 步。
 
-每个方向先从下表选一个首屏骨架，再用 3–5 个方框画出首屏线框：每块是什么、占首屏多大面积、阅读从哪里开始。
+黑白灰加一种强调色，甚至完全不用彩色，也是完整的色彩身份，这时颜色交给内容：产品截图、用户的照片、一张画。几个方向之间不按明暗分：头号失败是“一个亮、一个暗、一个暖”，每个方向要有自己的色相家族或材质感，明暗只是结果。
 
-| 骨架 | 首屏长什么样 |
-| --- | --- |
-| 满版图像压字 | 一张图占满首屏，标题和动作压在图的安全区里 |
-| 居中单一物件 | 一个物件或一句话居中，四周是大面积空白 |
-| 画面即界面 | 首屏就是产品界面或一件实物本身，标题、导航和按钮都长在它上面 |
-| 满版文字 | 文字本身就是画面，字大到占满首屏、跨过边缘或被裁切 |
-| 通栏上下堆叠 | 通栏大标题横跨整个宽度，下面紧接内容 |
-| 网格拼贴 | 多块内容同时出现，按网格或拼贴排列，没有单一主角 |
-| 纵排或斜向 | 文字竖排、斜切或旋转，打破从左到右的阅读 |
-| 左右分栏 | 文字一侧，画面一侧。这是模型的默认，一轮最多一个方向使用，并写出为什么非它不可。另一侧必须是跨越结构的图像、色块或图形装置，不能是装在卡片里的产品界面 |
-
-规则：
-- 同一轮的方向，骨架互不相同。
-- 左右分栏最多出现一次。所谓“大标题九栏、说明三栏”同样算左右分栏。
-- 骨架定好之后再写文案。文案去适应骨架，不让骨架去适应“标题 + 说明 + 按钮”的组合。
+## 定首屏与工作区骨架
 
-构图的大胆程度和调性无关。安静精致的产品，一样可以把一句话放在空白首屏正中，或让纵排标题贯穿整屏，或让界面本身占满首屏。调性决定音量，骨架决定结构；不要因为调性偏安静，就退回左右分栏。
+写文案之前先定骨架，文案去适应骨架。先回答一个问题：**用户来首屏是看什么、做什么？**
 
-每一轮至少有一个方向让你自己觉得有点冒险：放在同类产品里会显得格格不入，但仍然好看，功能完整。模型只有被明确要求时才会这样做。如果你心里想的是“这不可能行得通”，通常说明方向是对的，做出来往往比预想好。
-
-最常见的模板核心不是左右分栏本身，而是“左边标题和两个按钮，右边一张装在圆角卡片里的产品界面”。那张卡片几乎总是该删的：要么让产品界面本身占满首屏，要么换成一张跨越版面结构的图、一个色块或一个图形装置。
+- **来听一句话、看一张画、被说服的页面**（落地页、品牌页、产品发布页、展览页）：
+  从 8 种首屏骨架里选，跳出左右分栏默认模板。详见 [说服型页面首屏骨架](direction-persuasion.md)。
+- **来看内容、挑东西或处理对象的页面**（画廊、商店、信息流、文档、作品集、工具和后台）：
+  首屏就是第一排内容本身或工作区。导航、标题和筛选合起来不超过一两行，第一排内容要完整出现在首屏。不放首屏口号，也不放解释这个页面是干什么的段落。按用户最常做的动作安排内容，例如浏览就让内容铺满，处理就让当前对象和动作挨在一起。
+- **两种都有时**（例如商店首页顶上有活动横幅）：以用户最常来做的事为准，横幅可以留，但不能把第一排内容推出首屏。
 
 ## 方向卡
 
-每个方向写一张方向卡，每项都填具体选择，不填形容词：
+每个方向写一张方向卡，每项都填具体选择，不填形容词。出三个首屏的那一轮，调性和标杆与取舍几个方向共用一份（候选分布在不同调性上时，调性各填各的），每个方向只填北极星、生成引擎、首屏骨架、字体、色彩、主视觉、图标和控件语法；其余各栏在方向选定后、做完整页面之前补齐。派生版式时，每个版式变体只重写首屏骨架、页面结构和主视觉三栏：
 
 | 字段 | 要写到的程度 |
 | --- | --- |
 | 北极星 | 一句能指导取舍的体验意图：用起来像在什么地方、做什么事 |
 | 调性 | 五个刻度的取值及依据 |
+| 标杆与取舍 | 品类是什么，拆的是哪一家，对着哪几张真实画面拆的（写存放路径；没看图就写“未看图，凭记忆”）；沿用了哪几条、换掉了哪几条，各自为什么 |
 | 生成引擎 | 用了哪一种，具体是什么，来自这个产品的什么证据 |
-| 首屏骨架 | 从骨架表里选的哪一种，附 3–5 个方框的首屏线框：每块是什么、占多大面积、阅读从哪里开始 |
+| 首屏骨架 | 先写用户来首屏看什么。内容页写首屏能看到几个对象、页头占几行；说服型页面写从骨架表里选的哪一种，附 3–5 个方框的首屏线框：每块是什么、占多大面积、阅读从哪里开始 |
 | 页面结构 | 首屏以下怎么组织，例如单列沉浸滚动，或导航、内容、详情三栏 |
 | 各区块的形式 | 首屏以下每个主要区块（产品实样、功能、价格、隐私、结尾等）在这个方向里长成什么东西。形式从生成引擎推出，不是同一个模块换颜色 |
 | 字体 | 具体字族、字重和尺度关系：展示、正文、数字各用什么，相差多大 |
-| 色彩 | 用到的十六进制色值及用途，说清这个方向的色彩身份；黑白灰加一种强调色也是完整的答案 |
+| 色彩 | 按“定色彩”写：十六进制色值及用途，至少三层，再加一句它来自这个产品的什么 |
 | 主视觉 | 哪张图或哪个图形承担情绪与识别，来自复用、生成还是排版本身 |
 | 图标 | 用哪一套、什么描边粗细和端点，或者不用图标、改用字符和编号 |
+| 控件语法 | 按钮、输入、选中、标签、状态和动效共用的一套形状和手感，用一句话写清，例如圆角多大、描边多粗、按下时怎样变化 |
+| 动效 | 手感用“一个拟声词 + 一个实物的动作”来写，实物从这个产品的领域里找；三处基本动效各怎么动、怎样彼此呼应；落地页类页面再写滚动分镜（区块出场、选了哪种滑动驱动的叙事），见 [滚动叙事](../../atw-ui/references/scroll-narrative.md)；有没有一处从产品里找到的巧思。见 [动效](../../atw-ui/references/motion.md) |
 | 结构性突破 | 改变首屏结构的那一处偏离常规，以及它怎样放大北极星。手写批注、质感按钮、划线这类局部细节不算 |
 | 记忆点 | 集中发力的一两处：在哪个时刻或位置，用什么材质、动作或画法，见“让人记住的一刻” |
 | 放弃什么 | 这个方向主动不要的常见做法 |
@@ -108,63 +139,65 @@
 
 ## 差异检验
 
-方向卡写完、做小样之前，逐条检验：
+方向卡写完、做首屏之前，逐条检验。基于选定方向派生版式，或用户已经给了品牌规范时，字体和配色是共用的，下面关于字体和色彩的几条不适用，骨架、主视觉和页面结构仍要各不相同：
 
 - **比线框，不比描述**：把各方向的首屏线框并排放在一起比。方向的描述可以各不相同，线框却可能都是“左边大标题，右边小块”。线框相似就是同一骨架，重选骨架。
 - **四项至多一项相同**：首屏骨架、字体、色彩、主视觉四项里，任意两个方向至多一项相同；否则就是同一方向的变体，换一个生成引擎重写其中一个。
-- **不按明暗分方向**：头号失败是“一个亮、一个暗、一个暖”。每个方向要有自己的色彩身份：不同的色相家族、不同的材质感，或者干脆是黑白。明暗是色彩身份的结果，不是区分方向的依据。
-- **黑白也是一种色彩身份**：黑白灰加一种强调色，甚至完全不用彩色，常常是最高级的选择。这时颜色交给内容：产品截图、用户的照片、一张画。它和多色方案同样算拉开了差异；不要为了显得特别，去找一组少见的颜色。
-- **结构也要不同**：不同方向可以有不同的页面组织。三个方向页面结构完全相同、只是颜色和质感不同，就还没有拉开差异。候选只需共享核心内容和主要任务。
-- **至少一个走到极端**：至少一个方向在各项上都取明确的一端，不做折中；折中的取值最多出现在一个方向里。
-- **至少一个打破品类套路**：在同一调性内，至少一个方向不用这个品类的默认版式。常见套路如下：
+- **不按明暗分方向**：每个方向有自己的色相家族或黑白，见“定色彩”。
+- **结构也要不同**：填了“页面结构”的几个候选（版式变体，或都要做成整页的方向），页面组织不能完全相同、只换颜色和质感。候选只需共享核心内容和主要任务。
+- **至少一个走到极端**：在证据允许的调性范围内，至少一个方向在构图、色彩和主视觉上都取明确的选择，不做折中；折中的方向最多一个。
+- **至少一个打破品类套路**：在同一调性内，至少一个方向不用这个品类的默认版式。打破套路不等于抛弃基线。常见套路如下：
   - 后台：左侧栏、顶栏加卡片网格。
   - 电商：大横幅、商品网格加页脚。
   - 社交：底部标签栏、信息流加悬浮按钮。
   - 落地页：主视觉、特性、用户评价，最后一个行动按钮。
   - 聊天：左侧联系人，右侧消息。
+  - AI 与开发者工具：黑色背景、紫蓝发光弥散圆晕、浮空粒子与千篇一律的胶囊按钮。
+- **不撞脸**：把每个方向和它拆过的标杆并排看，撞脸就重做，定义见“认品类，拆标杆”。沿用基线不算撞脸。
 - **盲看**：遮住名字和说明只看画面，仍能说出每个方向带给人的不同感受。
 
-小样做出来后再比一次实际画面：在对比页并排看首屏，眯起眼睛只看明暗块面。块面的分布如果相似，比如都是左边一大块、右边一小块，即使字体和颜色都不同，也回到骨架表重做，不靠换装饰补救。首屏之后，再按区块逐一比较整页。
+首屏做出来后再比一次实际画面：在对比页并排看首屏，眯起眼睛只看明暗块面。块面的分布如果相似，比如都是左边一大块、右边一小块，即使字体和颜色都不同，也回到骨架表重做，不靠换装饰补救。
 
 ## 北极星与呼应
 
-北极星选定后，转成少量相互支持的关系：摄影的空旷与标题的留白呼应；窄字形与纵向画面呼应；低饱和环境色与唯一的行动色形成反差。每个方向明确主角、陪衬、重复的节奏和一处结构性突破。
+北极星选定后，转成少量相互支持的关系：图像的尺度和标题的留白怎样呼应，字形的比例和画面的比例怎样呼应，哪一处用反差。每个方向明确主角、陪衬、重复的节奏和一处结构性突破。
 
-突破要改变结构，例如首屏的骨架、比例或阅读顺序，而不是多加一个装饰；它应增强主题或引导关键动作。精修时不要把有辨识度的选择修平。新增元素不能强化同一意图时，优先省略。大胆的方案也必须可读、可用。
+结构性突破要动的是结构，例如首屏的骨架、比例或阅读顺序，而不是多加一个装饰；它要么让主题更强，要么把人引向关键动作。精修的时候，别把有辨识度的选择磨平。新加的元素如果不能加强同一个意图，就不加。
 
 ## 让人记住的一刻
 
-模型做的页面常常处处及格，却没有一处让人记住。惊艳很少来自整页都用力，而是来自一处做到极致：通常是一个组件的一次动作，结果、材质、光影、手感和节奏都做到位。每个方向选一两处集中发力，其余保持安静。
+每个方向选一两处集中发力，其余保持安静。记忆点通常是一个组件的一次动作：结果、材质、光影、手感和节奏都做到位。
 
 去哪里找：
 
 - **用户会做的动作。** 点按、拖动、切换、提交，比滚动更容易成为记忆点。
 - **关键时刻。** 付款成功、第一次完成任务、升级、删除、上传、等结果。这些时刻情绪最强，一个小动画的回报最高。
 - **边角页面。** 404、空状态、加载、页脚。没人期待，风险又低，最容易出彩。
-- **AI 在工作的时候。** 把过程按顺序展开：步骤一个个亮起，日志一行行流进来，做完的一步收起，正在做的一步展开。白底黑字照样成立，不需要材质和发光。
+- **AI 在工作的时候。** 让过程看得见，进行中和做完的区别落在画面上。白底黑字照样成立，不需要材质和发光。
 
 怎么想：
 
-- **让结果当场发生。** 状态切换不只换一个图标，而是让被影响的东西当场变化：打开深色模式，整页像拉下遮光帘一样暗下去；拖动时间，画面的天色跟着走。用户看到的是结果，不是控件在表演。
-- **把数字画成看得见的量。** 百分比、时长、余额，先问能不能画成一个量：点亮的格子、填满的长度、一格代表一天的网格。数字只是标签，量才是画面。
+- **让结果当场发生。** 状态切换不只换一个图标，而是让被影响的东西当场变化。用户看到的是结果，不是控件在表演。
+- **把数字画成看得见的量。** 百分比、时长、余额，先问能不能画成面积、长度或个数。数字只是标签，量才是画面。
 - **给抽象的状态一种材质。** 先问“这个状态如果是一个实物，会是什么”，答案从产品所在的领域里找。
-- **借物件的动作交付结果，物件从用户手上找。** 选这个领域的用户本来就拿在手上的东西：旅行产品用登机牌成立，作品集用登机牌只是借梗。票据、打印机、卡带、老游戏机这类复古实物在灵感站上已经泛滥，用之前先问：这个产品自己的实物是什么。
+- **借物件的动作交付结果，物件从用户手上找。** 选这个领域的用户本来就拿在手上的东西。票据、打印机、卡带、老游戏机这类复古实物在灵感站上已经泛滥，用之前先问：这个产品自己的实物是什么。
 - **给控件物理和性格。** 拖动有弹性和重量，按下有光影变化，拉过头会不情愿地弹回来。
-- **画法要说得出来源。** 点阵、字符画、像素、粒子、写实材质这类画法，只有能说出它来自产品做的事时才选：把数据渲染成点阵的研究工具用点阵，长在终端里的工具用字符画。说不出来源就不选；选了就从主视觉一路用到加载、图标和空状态。
-- **一张画面垫底时，界面要退后。** 有情绪的摄影或绘画铺满，界面缩到只剩一行导航和一句话，排版严格；底图虚化或压暗，保证文字可读。
+- **画法要说得出来源。** 点阵、字符画、像素、粒子、写实材质这类画法，只有能说出它来自产品做的事时才选。说不出来源就不选；选了就从主视觉一路用到加载、图标和空状态。
 
 ## 参考怎样转为设计决定
 
-先说明参考用途：借鉴视觉关系、建立质量基线，还是精准还原。实际看过图片再描述它的视觉。借鉴时提取关系，例如“标题占主要视觉重量，图像提供情绪，辅助信息压低对比”，再用当前内容重新组织；不要照搬参考的业务模块、标识和文案。隐喻要转译成界面决策，不做成妨碍操作的仿真外壳。
+先说清这份参考拿来做什么：借它的视觉关系，把它当质量的底线，还是照着它精准还原。看过图再描述它长什么样。借鉴时取的是关系，例如“标题最重，图负责情绪，辅助信息压得很淡”，再拿当前的内容重新组织；不照搬参考里的业务模块、标识和文案。借来的隐喻要落成具体的界面决定，不做成一层妨碍操作的仿真外壳。
+
+参考里没有的东西也是决定。参考的首屏没有标题区和说明段，就不要替它补上；参考没有用的装饰，也不要加回去。
 
 ## 小样、选择与品味
 
-先用几句话比较设计意向，再给有希望的方向做代表性小样，不一开始就做多套完整产品。单个页面的小样通常是首屏加最能体现方向的一两个区块；用户明确要完整页面时照做，评审深度仍按探索阶段。方案数量按任务定，窄小的任务不强求多方案。
+方向只做首屏，不一开始就做多套完整产品；轮次和数量见 [界面原型](../UI.md) 的“第一段：选方向”。
 
-挑能暴露方向优缺点的代表性页面：含复杂表单的产品不能只做封面，长页面的小样要包含关键内容结构。
+首屏选能暴露方向优缺点的那一页：含复杂表单的产品不能只做封面。
 
-介绍产品的页面，必须让用户看到产品真正交付的东西：一张生成好的报表、一份导出的合同、一段处理后的真实数据，而不是只用文字承诺“能做什么”。这个实样往往比功能列表更有说服力，也最容易成为页面的第二个主角。需要实际比较多个小样，或由 Agent 自行选定方向时，先使用 [风格对比页](style-explorer.md) 生成对比页留档，再选定方向。
+介绍产品的页面，必须让用户看到产品真正交付的东西：一张生成好的报表、一份导出的合同、一段处理后的真实数据，而不是只用文字承诺“能做什么”。这个实样往往比功能列表更有说服力，也最容易成为首屏以下某一段的主角。
 
-比较任务适配、辨识度、内容承载、可读性和实现代价，主 Agent 给出推荐依据，由用户选定。选定后请用户用具体的话补充品味：想要什么感受，不要什么、为什么不要，哪些地方要保留。用户只说“再高级一点”时，用上面的翻译表追问，或拿两张小样让用户比较。
+推荐理由从任务适配、辨识度、内容承载、可读性和实现代价里比出来。请用户补充品味时，问想要什么感受、不要什么和为什么、哪些地方要保留。用户只说“再高级一点”时，用上面的翻译表追问，或拿两张小样让用户比较。
 
 把选定方向和品味写进设计说明，作为后续判断基线。评审提出新风格时，先判断它是否解决原目标；只有当前方向确实不适配，或用户改变目标时，才重新探索。

package/dist/templates/common/bundled-skills/atw-prototype/references/direction-persuasion.md

@@ -0,0 +1,25 @@
+# 说服型页面首屏骨架
+
+落地页、品牌页、产品发布页、展览页等以说服、传递理念为主的页面，按本规范选定首屏骨架（整体设计方向流程见 [设计方向](design-direction.md)）。
+
+模型最顽固的习惯是左右分栏，它在写文案之前就定下来了：先想好标题、一段说明、一个按钮，摆好就是左右两栏。所以骨架要在写任何文案之前决定。
+
+每个方向先从下表选一个首屏骨架，再用 3–5 个方框画出首屏线框：每块是什么、占首屏多大面积、阅读从哪里开始。
+
+| 骨架 | 首屏长什么样 |
+| --- | --- |
+| 满版图像压字 | 一张图占满首屏，标题和动作压在图的安全区里 |
+| 居中单一物件 | 一个物件或一句话居中，四周是大面积空白 |
+| 画面即界面 | 首屏就是产品界面或一件实物本身，标题、导航和按钮都长在它上面 |
+| 满版文字 | 文字本身就是画面，字大到占满首屏、跨过边缘或被裁切 |
+| 通栏上下堆叠 | 通栏大标题横跨整个宽度，下面紧接内容 |
+| 网格拼贴 | 多块内容同时出现，按网格或拼贴排列，没有单一主角 |
+| 纵排或斜向 | 文字竖排、斜切或旋转，打破从左到右的阅读 |
+| 左右分栏 | 文字一侧，画面一侧。这是模型的默认，一轮最多一个方向使用，并写出为什么非它不可。另一侧必须是跨越结构的图像、色块或图形装置，不能是装在卡片里的产品界面 |
+
+规则：
+- 同一轮的方向，骨架互不相同。
+- 所谓“大标题九栏、说明三栏”同样算左右分栏。
+- 骨架定好之后再写文案。文案去适应骨架，不让骨架去适应“标题 + 说明 + 按钮”的组合。
+
+构图的大胆程度和调性无关。安静精致的产品，一样可以把一句话放在空白首屏正中，或让纵排标题贯穿整屏，或让界面本身占满首屏。调性决定音量，骨架决定结构；不要因为调性偏安静，就退回左右分栏。

package/dist/templates/common/bundled-skills/atw-prototype/references/style-explorer.md

@@ -75,7 +75,7 @@ macOS/Linux 通常使用 `python3`，Windows 通常使用 `py -3`；执行前确
 
 生成器根据本轮项目和候选内容生成 `fingerprint`。候选内容变化后会形成新一轮存储身份，避免把旧选择误用于新作品。点“选择”时同时复制一句简短的文字：轮次、编号和方向名，有备注时再附一行，例如“<轮次>：选 03 <方向名>”，并在底部提示已复制的内容。改完备注后再点一次“已选择”重新复制；选另一个方向会直接替换当前选择。
 
-用户粘贴复制的结果或直接说出选择后，Agent 按轮次和编号对照当前 manifest，确认对应本轮，再把选择与备注更新到项目设计说明，继续实现。浏览器本地保存不代表已经写回项目文件，也不会自动向 Agent 发送消息。
+用户粘贴复制的结果或直接说出选择后，Agent 按轮次和编号对照当前 manifest，确认对应本轮，再把选择与备注更新到设计说明，回到 [界面原型](../UI.md) 第一段接着做。浏览器本地保存不代表已经写回项目文件，也不会自动向 Agent 发送消息。
 
 ## 检查实际结果
 

package/dist/templates/common/bundled-skills/atw-tickets/SKILL.md

@@ -67,6 +67,8 @@ Publish the approved tickets. **How** depends on the tracker this repo uses —
 - **File-based trackers** → consult the tracker doc's "When a skill says publish to the issue tracker" section for the directory and naming convention; write one file per ticket, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on — always written in the file, even where a mirror also draws native edges on a remote tracker, because tooling reads the line. Use the per-ticket file template below — one ticket per file, never a single combined file. **If the tracker doc defines extra ticket fields, add them on top of the template.**
 - **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. If the source was an existing issue, make each ticket its sub-issue (tracker doc's operation). Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
 
+Mark a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision — as `ready-for-human` instead (the tracker doc's `Status:` line, or the triage label): `/atw-implement-all` will not dispatch it, and `/atw-implement` asks the user before doing it in their place.
+
 Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
 
 Do NOT close or modify any parent issue.

package/dist/templates/common/bundled-skills/atw-ui/SKILL.md

@@ -7,7 +7,7 @@ description: "按已选定的设计方向实现、精修和评审网站、App、
 
 以明确的设计北极星组织界面，让构图、字体、色彩、素材和交互相互呼应，形成有辨识度的表达。克制是保留最有力量的选择、删除无贡献的元素，不是把所有风格磨成中庸。视觉表现与任务完成分别验收。
 
-方法和评审协议均在本目录内，直接使用宿主提供的文件、浏览、看图、生成与隔离执行能力。相对链接以本文件所在目录解析。
+方法、评审协议和截图工具均在本目录内，工具用法见 [工具](references/tools.md)；其余直接使用宿主提供的文件、浏览、看图、生成与隔离执行能力。相对链接以本文件所在目录解析。
 
 ## 在 ATW 里使用
 
@@ -17,7 +17,7 @@ description: "按已选定的设计方向实现、精修和评审网站、App、
 | --- | --- |
 | discover | 不用本技能。选方向用 atw-prototype，结论写进任务目录的 `ui-direction.md` |
 | implement | 只在 `/atw-implement` 的流水线里使用：工单涉及界面时，界面部分按本技能步骤 1–3 和 5 完成，业务逻辑仍按流水线测试先行。不在流水线之外单独用本技能写实现代码 |
-| accept | 只读。按步骤 4 的“给已有界面评审”，对照需求文档里的界面验收标准和设计规范取证；发现的问题记成新工单或后续任务，不当场修改 |
+| accept | 只读。按步骤 4 的“存量已有界面润色评审”，对照需求文档里的界面验收标准和设计规范取证；发现的问题记成新工单或后续任务，不当场修改 |
 | 没有 ATW 任务的小改动 | 直接使用本技能 |
 
 实现阶段发现方向缺失或与需求文档矛盾时，停下来告诉用户，按 ATW 的回退规则处理（回到 specify 或重新探索），不在工单里临时发散新方向。
@@ -51,16 +51,17 @@ description: "按已选定的设计方向实现、精修和评审网站、App、
 | 当前范围 | 路径 |
 | --- | --- |
 | 单个元素、一处间距、文案或颜色这类小改动 | 直接改，在目标视口看改动处和相邻元素，交付时一两句话说明；不盘点现状、不启动评审 |
-| 方向还没定，或明确要求重新探索、比较多个风格 | 交给 atw-prototype 的界面原型，选定方向后再回到这里 |
+| 方向还没定，或明确要求重新探索、比较多个风格（存量项目改流程或加新功能、单个组件打磨，没有 `ui-direction.md` 也不算方向还没定，走下面各自的一行） | 交给 atw-prototype 的界面原型，选定方向后再回到这里 |
 | 已有选定方向（`ui-direction.md` 或用户给定）的新界面 | 按步骤 1–5 执行 |
 | 已有方向的深化或局部优化 | 保留方向，从步骤 2 进入，只检查受影响的区域与状态 |
-| 存量项目里的精修、局部重构或改版 | 先盘点现有页面、设计变量和共享组件，留基线截图，从源头修改 |
-| 截图还原 | 按 [布局与视口](references/layout-and-viewport.md) 的“精准还原”，以参考图为视觉基线，确定参考视口与布局约束后进入步骤 2，不发散新风格 |
-| UI/UX 评审 | 按问题读取对应参考，只执行步骤 4 的诊断并交付证据与建议；评审现有界面、不要求重新设计时，用步骤 4 的“给已有界面评审” |
+| 单个组件，要打磨到极致或做出辨识度 | 按步骤 1–5 执行，范围只是这个组件，只做一个方向，不交给 atw-prototype 比较：先定一个视觉主角，从它取色，力气集中在主操作那一刻 |
+| 存量项目里优化 UI、改流程或加新功能 | 先分清用户要哪一种：优化 UI 可以重新决定偶然形成的视觉默认值，品牌资产保留；改流程和加新功能沿用现有视觉，不交给 atw-prototype 做方向探索。盘点现有页面、设计变量和共享组件，留基线截图，从源头修改 |
+| 截图还原 | 按 [布局与视口](references/layout-and-viewport.md) 的“精准还原”，以参考图为视觉基线，确定参考视口与布局约束后进入步骤 2，不发散新风格；每轮修改后用截图工具的 `--compare` 和参考图比对 |
+| UI/UX 评审 | 按步骤 4 派评审者，只要诊断，不做修正；交付证据与建议 |
 
 ## 1. 确认方向
 
-读 `ui-direction.md` 或用户给定的方向，确认北极星、方向卡、记忆点、用户的喜欢与不喜欢都还适用。方向缺失、彼此矛盾，或用户改变了目标时，回到 atw-prototype 选方向，不在实现中途悄悄换风格。
+读 `ui-direction.md` 或用户给定的方向，确认北极星、方向卡、记忆点、用户的喜欢与不喜欢都还适用。方向缺失、彼此矛盾，或用户改变了目标时，回到 atw-prototype 选方向，不在实现中途悄悄换风格。范围表里不交给 atw-prototype 的两类不算方向缺失：存量项目改流程或加新功能，现有视觉就是方向；单个组件打磨，在这里定下唯一的方向，写进设计说明。
 
 atw-prototype 第二段留下的纯逻辑模块和原型页面是参考，不是要提升的代码：逻辑模块可以搬进正式代码，页面按项目的组件和规范重新实现。
 
@@ -68,18 +69,21 @@ atw-prototype 第二段留下的纯逻辑模块和原型页面是参考，不是
 
 ## 2. 建立视觉与交互结构
 
-根据当前决策按需读取，不预先加载全部参考：
+先按页面类型读一组，其余按需，不预先加载全部参考。落地页、品牌页、发布页和展览页开工前读视觉语言、素材、动效和滚动叙事；产品界面开工前读视觉语言、素材和动效。表里其余几行，页面里出现了左列的东西再读：
 
 | 要解决的问题 | 参考 |
 | --- | --- |
 | 视觉层级、字体、色彩、空间、图标、风格统一或减法精修 | [视觉语言](references/visual-language.md) |
-| 素材选择、视频与 3D | [素材](references/media.md) |
-| 生成配图：让图承担意思、写提示词、和页面接成一体 | [配图](references/imagery.md) |
-| 动效手感、界面过渡、首屏动画与滚动叙事、时长与检查 | [动效](references/motion.md) |
+| 图从哪来、承担什么：选素材、生成配图与写提示词、让图和页面接成一体、实时 3D 与视频 | [素材](references/media.md) |
+| 三处基本动效与呼应、动效手感、界面过渡、首屏动画、时长与检查 | [动效](references/motion.md) |
+| 小游戏、抽奖、计时养成和强手感操控 | [游玩](references/play.md)（含素材与渲染，按其中链接读素材） |
+| 落地页、品牌页、发布页、展览页的滚动动效：区块出场、滑动驱动的叙事（首屏景深、一镜到底等）与动效库 | [滚动叙事](references/scroll-narrative.md) |
 | 精准还原、视口与溢出检查 | [布局与视口](references/layout-and-viewport.md) |
 
 新产品同时交代主要内容的视觉层级和关键操作链；不要只完成漂亮的默认状态。营销页面可以表达情绪与品牌，高频工具优先识别效率和操作稳定性。
 
+新界面和改动了操作流程时，按 [动效](references/motion.md) 做出三处基本动效；落地页、品牌页、发布页和展览页还必须读 [滚动叙事](references/scroll-narrative.md)，用成熟的动效库做区块按内容出场和至少一段滑动驱动的叙事，手法按页面挑。两者都写进方向卡的“动效”一栏，改流程和加新功能时写进设计说明；小改动不加。
+
 交互、表单、状态、弹窗和响应式的实现规则，项目或宿主已有相应规范时照用。
 
 在构图阶段按 [素材](references/media.md) 判断图像能否承担主信息或情绪重心，包括后台、工具和内容产品。需要关键素材时先选定或制作它，再围绕其主体、留白与裁切安排文字和操作；不等布局填满后再补图。
@@ -88,36 +92,47 @@ atw-prototype 第二段留下的纯逻辑模块和原型页面是参考，不是
 
 ## 3. 制作并取得实际证据
 
-- 先完成代表性页面或关键操作链，检查后再延展到其他页面。只做局部修改时直接完成相关改动。
-- 素材有明确表达作用时才制作；文字、控件与业务信息保持可编辑。生成图片中的界面仅作为视觉样本。
-- 示例内容按真实产品的样子写。哪些是模拟数据、生成图片、未接入的动作，写在交付说明里，不写进界面：画面上不出现“示例”“待核实”“示意图”“概念稿”“按钮未接入”这类制作说明。不伪造业务成功、客户评价或产品指标。
-- 在相关目标视口运行并查看结果。记录截图对应的页面、状态、视口与版本；长页检查整体节奏和关键局部，不能只看首屏。
-- 在实际阅读尺寸检查中文多行标题、正文、控件和窄屏换行。文字重叠、被裁切或靠大量小字才装得下时，回到内容和布局修复，不以缩放预览或装饰精修掩盖。
-- 同一批相关修改集中检查，复用已有会话和证据。截图保存成功不等于已经看过；构建成功不等于视觉或操作已验证。
+- 先做完最有代表性的一页或关键的操作流程，检查过再往其他页面铺开。
+- 示例内容按真实产品的样子写。模拟数据、生成图片、未接入的动作写在交付说明里，不写进界面：画面上不出现“示例”“示意图”“按钮未接入”“仅保存在本机”这类制作说明。不伪造业务成功、客户评价或产品指标。
+- 在目标视口运行并查看。平时看效果只截当前这一屏，攒一批改动再截；送评审前和交付前，才用 [工具](references/tools.md) 里的截图工具取齐证据，一条 `--evidence` 命令就能出齐状态图、200% 局部和录屏，落地页再录一段从头滚到底。录屏自己按正常速度看一遍：该动的地方没动就补上，不逐帧核对。
+- 截图工具每次都会列出“默认做法提示”，在取证那一次统一处理：可读性提示按 [工具](references/tools.md) 里的分组处理，标为要改的必须改；眉标、单侧色条、卡片套卡片这类模型默认做法，改掉，或在交付说明里逐条写出理由。
+- 在实际阅读尺寸检查中文多行标题、正文和窄屏换行。文字重叠、被裁切或靠大量小字才装得下时，回到内容和布局修，不靠缩放掩盖。长页要检查整体节奏，不能只看首屏。截图保存成功不等于已经看过。
 
 ## 4. 独立评审与修正
 
-新页面、整体改版或影响主要构图和任务流程的变更，在初版稳定后按 [视觉评审协议](references/visual-review.md) 进行一轮独立评审，报告评分和剩余差距。局部、低风险修改由主 Agent 检查，不为每个间距调整启动评审者。
-
-已有界面按它自己的规范评审。在已有项目里润色了一整页或多页、做完局部重构，或用户要求评审现有界面而没有要求重新设计时，用 [视觉评审协议](references/visual-review.md) 的“给已有界面评审”：标准是仓库现有的设计规范，没有成文规范时以现有实现和组件为准；怎样做得更好看，照常用视觉语言里的判断。只做一轮，不打分。单个元素的小改动不评审。
+按改动选评审方式，交接规则见 [视觉评审派发协议](references/visual-review.md)，评审者按 [评审手册](references/reviewer-manual.md) 执行：
 
-- 主 Agent 保持设计方向与集成责任。具备隔离和看图能力时，派发无历史上下文的视觉评审子 Agent；缺少任一能力时改为主 Agent 自检，并标明未独立评审。
-- 在 `/atw-implement` 流水线里不自行派发评审者：独立视觉评审由流水线的审查步骤（atw-code-review）负责，把截图、对应的页面、状态和视口交给它。审查步骤不支持视觉评审时，主 Agent 按 [视觉评审协议](references/visual-review.md) 自检，并在交付说明里标明未独立评审。
-- 评审者看当前画面、任务、约束和必要参考，不看制作历史、代码或旧评分。记忆点是动效时，交给评审者一段录屏或开始、中间、结束三帧，静态截图看不出它。评审以“这一体裁里顶尖设计团队会怎么做”为参照指出最大差距，并按 10 分制给出当前画面离那个标准有多远。主 Agent 按反馈修正并重新取证，不把评审偏好自动当成用户要求。
-- 风格开始漂移、意见反复、收益不清楚或到达用户预算时，保留当前最合适的版本并说明具体取舍；未解决的必需功能仍如实列出，不能以停止美学迭代代替任务完成。
+| 改动 | 评审 |
+| --- | --- |
+| atw-prototype 方向探索阶段的对比页 | 先交给用户；三个首屏和版式变体不派评审，用户要求时再评 |
+| 新界面、整体改版，选定方向之后 | 初版稳定时评审，10 分制，报告评分和剩余差距 |
+| 已有界面润色一整页以上，或只要求评审现有界面 | 按“存量已有界面润色评审”，一轮，不打分 |
+| 小改动、局部低风险修改 | 主 Agent 自己看，不派评审者 |
+
+- 有隔离、能看图的执行者时，派一个没有历史上下文的评审者；没有就自检，并标明未独立评审。评审者只看当前画面、任务和约束，不看制作过程和代码。
+- 在 `/atw-implement` 流水线里不自行派发评审者：独立视觉评审由流水线的审查步骤（atw-code-review）负责，把截图、对应的页面、状态和视口交给它。审查步骤不支持视觉评审时，主 Agent 按 [评审手册](references/reviewer-manual.md) 自检，并在交付说明里标明未独立评审。
+- 风格开始漂移、意见反复时，保留最合适的版本并说明取舍；没完成的必需功能照实列出。
 - 用户对实现出来的设计反复不满意，怎么调都不对时，说明问题可能出在方向本身，建议回到 atw-prototype 重新比较方向，而不是继续在细节上打转。
 
 需要并行制作时，按独立页面、素材或区块划分所有权，给执行者相同的任务约束与设计说明；要求保留他人改动。只有阶段依赖已满足且主 Agent 同时有独立工作时才并行，不能让多个执行者同时改同一共享样式。没有并行能力时顺序完成。
 
 ## 5. 验证与交付
 
-检查深度跟着改动走：新页面、改版和局部重构做下面全部检查；精修和基线做前后对比，再做受影响区域的细节检查，润色了一整页以上时加一轮步骤 4 的已有界面评审；小改动只看改动处和相邻元素，不做减法轮、不写评审记录。
-
-- 对照用户任务与选定方向检查真实内容、代表性视口和改动涉及的状态。交互从真实入口走到可观察结果；保存后重新读取，失败后检查输入和当前位置是否保留。
-- 使用现有相关检查及项目必需门禁。普通样式或文案调整以实际结果验证，不为一次检查新建长期测试体系。
-- 修正已发现的可用性、溢出、内容和视觉问题，复查受影响部分。按视觉语言做减法，同时保留识别对象、理解规则和完成操作所需的信息。
-- 单独做一次减法：一页只有一个主角，其余安静；逐区块删一轮文字，只放回删了会影响理解的。减法只删装饰和重复，对象名称、判断依据、当前状态和主动作必须留下。在 100% 和 200% 缩放下看关键区域。
-- 交付请求范围内的文件或预览，说明选定方向、关键变化、实际验证和剩余项。评审记录里写明评分和删掉了哪些文字。某一步没做，就写没做和原因，不省略不提。设计说明、素材、截图及评审记录放在 ATW 任务目录（截图放在 `screenshots/`，文件名写明页面、状态和视口，供审查和验收取证），复用已有组织方式，不写进技能安装目录。
+检查深度跟着改动走：小改动只看改动处和相邻元素；精修和基线做前后对比；新页面、改版和局部重构做下面全部检查。
+
+- 交互从真实入口走到可观察结果；保存后重新读取，失败后检查输入和当前位置是否保留。会保存东西的界面（收藏、草稿、购物车、计时、游戏进度），验证脚本至少覆盖刷新后读回和保存失败；有次数或余额限制时，再测用完。
+- 项目或任务目录里有检查交互或功能的验证脚本时，交付前由主 Agent 自己连续跑 3 次，3 次都通过才算通过，交付说明写出每次结果；生成页面、截图和取证用的脚本不在此列。动画和异步状态的检查等可观察的状态，不靠固定延时；评审引用的报告不能替代这一步。
+- 在 `/atw-implement` 流水线里，测试、类型检查和门禁按流水线执行。流水线之外只跑项目的类型检查和 lint，不跑生产构建和全量测试，用户要求时除外；构建失败、接口报错、依赖链接这类和画面无关的环境问题，在交付说明里记一行后绕过，不排查、不改项目配置。
+- 单独做一次减法：每一屏只有一个主角，其余安静；逐区块删一轮文字，只放回删了会影响理解的。减法只删装饰和重复，对象名称、判断依据、当前状态和主动作必须留下。在 100% 和 200% 缩放下看关键区域。
+- 交付前对一遍，交付说明里逐项写到：
+  - 选定的方向和理由；
+  - 改了什么，哪些没做、为什么；
+  - 做了哪些动效；
+  - 评审了几轮、用的哪种评审：打分的附每轮分数，不打分的写问题怎样处理；没有评审时写明；
+  - 删掉了哪些文字；
+  - 证据文件在任务目录的哪里。
+
+  设计说明、素材、截图和评审记录放在 ATW 任务目录（截图放在 `screenshots/`，路径写明页面、状态和视口，供审查和验收取证），不写进技能安装目录。
 
 ## 能力边界
 

package/dist/templates/common/bundled-skills/atw-ui/references/layout-and-viewport.md

@@ -2,14 +2,16 @@
 
 ## 精准还原
 
-先记录参考图的逻辑视口或已知像素尺寸、完整范围和固定区域。图像像素不等于逻辑视口；无法确定时说明假设。
+先记下参考图对应的视口尺寸或已知的像素尺寸、画面的完整范围，以及哪些区域是固定不动的。图片的像素数不等于视口尺寸，例如 2 倍图要除以 2；确定不了时，写明你是按什么假设的。
 
-测量主区域比例、共享对齐线、文字尺度、图片裁切与间距关系。先对齐整体几何与字体，再处理边框、阴影和细节；不因还原任务重新探索风格。
+量出主要区域各占多大比例、哪些元素共用一条对齐线、文字多大、图片怎么裁、各处间距之间是什么关系。先把整体的位置、比例和字体对上，再处理边框、阴影和细节；还原任务不重新探索风格。
 
-用与参考相当的视口和内容检查差异。参考没有展示的窄屏与状态根据内容约束补充，并区分“参考还原”与“合理延展”。
+用和参考图一样的视口、差不多的内容来比差异。参考图里没有的窄屏和其他状态，按内容的需要补上，并标明哪些是照着参考还原的，哪些是自己合理延伸的。
+
+自己判断还原得像不像，结论通常偏乐观；只看一张整页缩略图，也看不出字号、间距和对齐差了多少。每轮修改后用截图工具的 `--compare` 出对比图（见 [工具](tools.md)），先修差异最大的那几格，再在叠加图里核对对齐线、字号和图片裁切；不凭印象宣布“已经还原”。
 
 ## 验证重点
 
-实际检查长内容、空内容和当前改动相关状态。移动端注意视口变化、输入面板与安全边距，主操作不能被键盘或固定区域遮挡。
+实际看一遍内容很长、内容为空，以及这次改动涉及的各个状态。手机上留意视口高度的变化、弹出的键盘和屏幕的安全边距，主操作不能被键盘或固定的栏挡住。
 
-检查页面是否意外横向溢出、滚动是否发生在预期区域、焦点与菜单是否可见，以及缩放或重排后阅读和操作顺序是否仍然清楚。
+再检查：页面有没有意外地横向溢出，滚动是不是发生在该滚的那一块，焦点和菜单看不看得见；放大或重新排版以后，阅读和操作的顺序是否还清楚。