- oil-ui-pro 升到 0.22.2:references 13→28 份(新增 16、删 imagery.md)、assets 增 cards/(22 组)与 fonts/、SKILL.md 顶层五步结构未改名。 - 升级路径:官方 `npx github:oil-oil/oil-cli update` 稳定失败(error=replace、报「检查目录权限」)。 真身为 EXDEV —— 解压在 os.tmpdir()(C 盘)、技能目录在 E 盘,Windows 上 rename 不能跨盘; CLI 的 catch 把非 CliError 原生异常一律兜底成 replaceFailed,真错误一个字不吐。 做法=借其 prepare() 只做下载+校验,再 cp 到同盘 stage、rename 交换;官方命令复验 up_to_date。 - 回归:product-planning 按名引用的 visual-review.md/tools.md/design-direction.md/style-explorer.md 全部健在;命名闸门 2061|0|27。 - session-mechanism/references/pitfalls.md 新增 P0-98(含通则:更新器把原生错误兜底成指错方向的人话)。
3.8 KiB
3.8 KiB
整理已有页面
用户对一页或一块区域不满意,但没说要改成什么样:“别扭”“不好看”“优化一下”“别改太多”。这时不出三个风格,在现有的视觉语言里修。要用户判断的是问题找得对不对:Agent 看得到页面,看不到页面背后的业务。一段看似多余的说明可能是法务要求,一个看似次要的按钮可能是每天都在用的。
范围是整个产品,或者是落地页这类不用和别的页面保持一致的独立页面时,先按 存量项目 的“推翻程度”判断要不要出三档。
第一轮:诊断,不改文件
-
找项目根目录和 docs 里的
DESIGN.md或同类设计文档,有就以它为准,它已经回答的前提不再问。 -
用 截图工具 在桌面和手机宽度各截一张整页,存进任务目录做基线。
-
写一句这页是干什么的、用户来了第一眼该看到什么。看不出来就放进要确认的问题里。
-
对着截图和样式代码逐项看下面几处,每项都看,不要只挑最显眼的:
- 窄屏下有没有文字挤出容器、被截断或折得难看;
- 同一列的左边缘、同一行的文字是否对齐;
- 同一种按钮、标签、输入框是不是长得一样;
- 有没有重复标题意思的说明,或者解释界面怎么用的话;
- 一屏里有几个实心主按钮,最该先看到的东西是不是最醒目;
- 键盘焦点看不看得见,悬停和按下有没有反馈;
- 长名字、空数据、出错时是什么样。
挑出最影响使用和观感的 3–5 个问题,按影响排序。用户说了哪里不舒服,第一条先说清是什么造成的。
-
每个问题归到一类:
- 直接修:文字溢出、没对齐、焦点看不见、同一种组件两种样子这类客观缺陷。
- 请确认:要靠业务和用户情况才能判断的,例如某段文字能不能删、某个按钮用得多不多、这么密算不算挤。把背后的猜测写出来,例如“我猜这个按钮很少用”。
-
问题的位置用文字说不清时,例如对齐、间距、某一块区域,诊断定稿后用截图工具的
--mark "1=选择器; 2=选择器" --full标出来,核对图上的编号和诊断一致。
把诊断发给用户,这一轮到此结束,不改任何文件,“直接修”的条目也等到下一轮再改。消息照这个样子写:
这页是……,用户来了先要看到……
1.【直接修】看到……,因为……,打算……
2.【请确认】看到……,我猜……,所以打算……
标注截图:<路径>(标了才写)
请按编号回复对不对,不对的说一下原因。
只有用户说了直接改,或者无人值守时,才不等回复,直接进入第二轮,把“请确认”的条目写进交付说明,标为假设。
第二轮:改
- 改“直接修”的条目和用户确认过的条目,按 存量项目 的“从源头修改”落到现有变量和组件上。不换字体、颜色和组件的样子。
- 用户否定的条目和理由,项目有设计规范文件时写进去,标用户确认。
- 纯口味的选择不按 SKILL.md 步骤 1 用文字问,在那一处做两个局部版本放进对比页。