Pencil.dev 设计 → 规格 → 代码 → 校验

常见误区三件事：

你的目标是：让 Pencil.dev 产出"可验证的一致性"，而不是"像"。

一句话中心论点：输入统一，输出才可能统一。

建议你把输入分成三层，按顺序喂给 Pencil.dev（或在项目空间里固定下来）：

A. 设计源（Design Source）
- Figma 链接/文件（如果你们用 Figma）
- 页面只选 1--2 个代表性页面：列表页、表单页最优先
- 重点不是页面多，而是状态全（hover/active/disabled/loading/empty/error）
B. 设计规范（Spec）
- 色彩、字号、间距、圆角、阴影、栅格
- 组件清单：Button/Input/Select/Modal/Table/Toast...
- 文案口径：按钮动词、错误提示语气
C. 工程目标（Code Target）
- 技术栈：React/Vue/Next.js、Tailwind/Styled-components、组件库（如 MUI/AntD）
- 目录结构与命名：components/、features/、pages/
- 约束：不改现有主题、不新增依赖、TypeScript 必须通过

在 Windows 上的实际动作：把这些内容整理成一个项目根目录的"协作包"，例如：

一句话中心论点：一致性来自组件，不来自页面。

推荐工作流（Windows 上也一样适用）：

先生成/对齐 UI Tokens
- 颜色（primary/secondary/success/warn/danger）
- 字体层级（H1/H2/body/caption）
- spacing（4/8/12/16/24/32...）
- radius、shadow
  然后让 Pencil.dev 在生成代码时"只引用 token"，不要写死 #1677ff、14px 这种散弹。
再做组件映射（Design Component → Code Component）
- 设计里的 Button = 代码里的 <Button variant="primary" size="md" />
- Input、Select、Modal 同理
  你要的是"对照表"，有了这个，页面拼起来才不散。
最后才拼页面
- 页面只做布局与数据绑定
- 视觉细节尽量回到组件里改，别在页面里补丁式修样式

一句话中心论点：能复现的通道，才配叫通道。

你可以用三招把复现做实：

固定生成指令模板 （写在 pencil-rules.md 里）

例：
- 输出必须为 git diff
- 仅修改 src/components 与 src/pages/xxx
- 禁止新增依赖
- 必须通过 npm test 与 npm run lint
- 样式必须使用 tokens + 现有组件，不允许随意新建 class
小步提交

一次只让它做一个组件或一个页面区块（Header、Filter bar、Table 区），别让它"一次写完整页"。
回归样例页

做一个 UI Playground 页面，把所有组件状态都摆出来。之后每次生成/修改，都用它对比。

一句话中心论点：节省的是沟通轮次与 UI 对齐轮次。

Windows 场景里很常见的是：设计师在 Figma，工程师在 VS Code，来回截图标注。你可以把成本压下去：

一句话中心论点：设计到代码打通以后，权限要更谨慎，而不是更随意。

建议最少做到：

一句话中心论点：顺手的环境配置，会直接影响一致通道能否持续跑。

建议配置组合：

Windows Terminal + WSL2（推荐） ：在 WSL 跑 node、lint、test，减少环境差异
VS Code Remote - WSL：编辑体验顺滑，命令行一致
Git 工作流固定：
- main 只合 PR
- pencil/* 分支专门接 Pencil 输出
- 每次生成前先 git status 干净，生成后立刻跑 lint/test
截图与标注工具：Windows 自带截图 + 标注，用于把"差异点"快速喂回规则文档（不是喂到聊天里就完事）

如果你们不想上 WSL，也行，但要统一：Node 版本、包管理器、字体渲染（会影响视觉对比），否则"你机子上对我机子上不对"会反复出现。

快速测评清单（你照着跑一次，就知道是不是"真正打通"）