产品设计规范落地宣贯文档（多项目集群管控方案）

文档用途：项目组会宣贯、设计侧接入执行、存量设计文档整改和后续验收依据适用对象：产品负责人、产品设计人员、架构师、前端/后端负责人、测试及相关协作人员工程载体：@agile-team/wl-skills-design 工程目录：D:\office-project\wl\wl-skills-design 下游协作：@agile-team/wl-skills-kit · @agile-team/wl-skills-bd · @agile-team/wl-skills-test 开源协议：Apache-2.0 当前核对版本：0.11.1（2026-08-15）

一、宣贯目标与核心结论

本次宣贯需要全员达成一个统一认识：

设计规范不是"写给人看的 Word 模板"，wl-skills-design 是设计规范的工程化执行载体；设计产出通过统一规范、统一 Skill、统一机械验证和统一交付契约落实"生成即合规、自检、可追溯"，不再依赖设计师个人素养和事后人工评审维持设计质量。

本次会议结束后，各产品和设计人员应明确以下事项：

为什么设计文档必须统一，以及当前问题对下游开发和测试的传导影响；
wl-skills-design 已经固化了哪些规范、10 个 Skill 各管什么、哪些内容仍需人工判断（[J] 语义项）；
从零新建、接入半成品文档、机械验证已有产物三种场景分别怎么用；
设计产出如何通过 design-model 与前端 kit / 后端 bd / 测试 test 契约对齐；
设计文档出现冲突或规范未覆盖时，如何反馈和归口解决。

一句话概括本方案：

一套设计规范、一个工程化事实源、双层资料供给、三步上手场景、四域机械验证、一条"生成→验证→修复"闭环。

版本演进速览（v0.8.0 → v0.11.1）

版本	落地能力	对使用者的意义
v0.8.0	`code-architecture` Skill + AC01-AC20；`validate-model` 只读校验；WL 交付兼容协议 v1	设计延伸到代码结构层；跨包握手有了统一 profile（`jh4j3-openapi3@1.0`）
v0.9.0	GB1–GB8 按钮级颗粒度基线；功能编码可选子域码；restore/uninstall 安全化	说明书逻辑写到"编号步骤"粒度，执行类活动与命令按钮一一对应；恢复操作本身可再撤销
v0.10.0	`[M]`/`[J]` 双轨验证标记；`verify spec/flowchart` 机械校验；`doc-intake` 半成品文档接入；开源治理	"机械先行、语义补充"——能脚本判定的不靠 AI 自觉；别人给的半成品文档可以差距分析后接入
v0.11.0	`verify db` / `verify api` 四域机械验证齐备；ESLint 9 门禁并入 verify 链；demo 升级为四域验证基准样例	数据库/接口标准中的 `[M]` 项全部 CLI 可执行；包内自带一份全部验证通过的活样例可直接参照
v0.11.1	README 三场景快速上手定版；使用指南补输入准备清单	新人按"从零到一 / 接入半成品 / 机械验证"三条路径即可上手

二、落地背景与现存问题

2.1 当前项目特点

平台采用多项目集群架构，需求来源多样：既有按团队规范从零编写的需求说明书，也有客户方、外包方、历史遗留的半成品设计文档；数据库设计、接口设计、原型标注往往由不同角色在不同工具（Word、draw.io、Axure、Excel）中分散产出，再由前后端各自"翻译"成代码。

2.2 主要问题

长期以来，设计质量主要依赖模板传阅、口头对齐和个人经验执行，容易产生以下问题：

同一个业务对象在说明书、数据库、接口三份文档里字段名各叫各的，评审时才发现对不齐；
说明书 IPO 表颗粒度参差：有人写到按钮级，有人只写"系统自动处理"，开发只能猜；
流程图泳道、起止节点、连线样式不统一，无法判断流程是否闭环；
数据库设计缺系统字段、索引无前缀规范、DDL 无 COMMENT，上线后运维排查困难；
接口设计 URL 风格混乱、必填枚举未标注、错误码清单缺失，前后端联调反复扯皮；
半成品文档接入全靠人肉通读，字段漂移、名称近似漂移无人能系统性发现；
变更影响分析靠记忆："改了这张表，到底影响哪几个页面和接口"没人说得全；
相同问题在多个模块重复出现，评审意见无法沉淀为可复检的规则。

2.3 根因判断

层面	过去的状态	需要建立的机制
规范	存在但分散在各类 Word 模板和口口相传	单一规范基线（9 条 `.md`）
生成	设计师自由发挥，评审事后补救	Skill 剧本 + 双层资料（模板+样例）
验证	人工逐项对照，看不全也记不住	`[M]` 机械 CLI + `[J]` 语义补充
接入	半成品文档人肉通读	doc-intake 采集归位 + 差距分析
追溯	页面/接口/表与设计文档无映射	design-model 稳定 ID + 跨包契约
演进	评审意见一次性消耗	规则化沉淀 + 版本化升级

三、方案定位与统一原则

3.1 方案定位

wl-skills-design 不是文档模板库，也不是替代产品经理的自动设计机。它是一套面向产品设计阶段的 AI 技能包，包含：

9 条设计规范（.github/standards/01~09）；
10 个原生 Agent Skill（.github/skills/）；
16 个 Copilot Prompt（create/validate 成对 + 集成评审 + 文档接入）；
verify 机械验证 CLI（spec / flowchart / db / api 四域）；
doc-intake 半成品文档接入与差距分析；
design-model 可选追踪模型与跨包兼容协议（jh4j3-openapi3@1.0）。

其核心目标是：让 AI 按团队规范做设计，产出物天然合规——机械项由 CLI 判定，语义项由 AI 对照样例自检，人工只处理真正的业务判断。

3.2 三层事实来源

优先级	事实来源	作用
1	9 条设计规范（`.github/standards/`）	流程图/说明书/原型/数据库/接口/评审/词典/变更/代码结构九域唯一基线
2	`wl-skills-design` 当前发布版本	将规范转化为 Skill 剧本、验证清单和机械 CLI
3	业务项目特殊约定	仅承载公共规范暂未覆盖且经确认的业务特例

设计文档不得绕过公共包自行形成第二套"局部模板"。

3.3 两种验证轨道（核心机制）

每份规范的验证清单逐项标注执行方式，这是本包区别于"纯文档模板"的关键：

轨道	标记	执行者	典型项
机械验证	`[M]`	`verify` CLI 脚本直接判定	表格形状、编码连续性、四节齐全、字段稳定 ID、清单↔字典↔DDL 三方一致
语义验证	`[J]`	AI 对照样例与规范判断	业务目标是否成立、异常文案是否贴切、颗粒度是否够深

验证流程统一为"机械先行、语义补充、同一编号合并"——[M] 项不过，不进入 [J] 讨论；同一验证项两种方式都执行时结论合并，避免重复报告。

3.4 双层资料供给

每个 Skill 目录下并排放两层资料，职责严格分离，两层都随包发布：

	`templates/` 默认模板	`examples/` 真实样例
角色	空白起点（脚手架）	质量标杆（参照系）
内容	纯结构 + `{占位符}`，零业务数据	真实场景填好的内容（匿名化处理）
AI 怎么用	复制后替换占位符开始写	生成后对照自检，且必须做得不低于它

模板告诉 AI"该有哪些结构"，样例告诉 AI"好到什么程度才算达标"。样例源自真实项目（如烟台华新数智化改造），规范升级时同步抬高。

四、整体工程架构

text

已评审业务事实 / 半成品文档 / 口述需求
        │
        ▼
9 条设计规范（唯一基线，index.md 门控）
        │
        ▼
10 个 Skill（意图识别 → manifest 路由 → 剧本执行）
    ├── requirements-flowchart      流程图（draw.io 泳道）
    ├── requirements-spec-doc       需求设计说明书（IPO / GB 颗粒度）
    ├── requirements-prototype      原型标注（D1–D3 深度）
    ├── data-database-design        数据库设计（ER / 清单 / 字典 / DDL）
    ├── api-interface-design        接口设计（RESTful / OpenAPI）
    ├── code-architecture           代码结构设计（AC01–AC20）
    ├── cross-glossary              术语字段词典（对齐锚点）
    ├── cross-change-impact         变更影响分析（补丁计划）
    ├── cross-design-review         设计集成评审（评分 / 追溯矩阵）
    └── doc-intake                  半成品文档接入（差距分析）
        │
        ▼
verify CLI（[M] 机械四域：spec / flowchart / db / api）
        │
        ▼
design-model（可选追踪增强：稳定 ID / 端点 / 字段映射）
        │
        ▼
跨包契约（kit page-spec / bd wl-contract / test 用例消费）

关键定位：design-model 是可选追踪增强，不是前后端生成的硬依赖——没有 design-model，kit/bd 各自可从已评审需求独立建契约；有了它，页面映射 screen.id、实体映射 table.id、字段映射 field.id，实现 1:1 追溯。

五、`wl-skills-design` 统一管控覆盖维度

5.1 业务流程图规范（01 · 20 项验证）

约束	规则
图形标准	draw.io 泳道图；活动/判定/起止节点样式统一
结构强制	三层 GROUP、起止节点齐全、连线样式规范、无几何重叠
编码体系	标准活动编码（如 `CAIG-A-01-E-01`），判定分支必须带「是/否」标签
机械验证	泳道色标、GROUP 层次、起止节点、连线样式、几何重叠、活动编码与占位符（`verify flowchart`）

5.2 原型标注规范（02 · 23 项验证）

约束	规则
三级深度	D1 布局级 → D2 交互级 → D3 开发就绪级（下游 prototype-scan 可达 95-100% 生成精度）
标注内容	交互模式、字段清单、组件选型、字典引用
双层资料	`templates/` 空白模板（7 区块）+ `examples/` 炼钢计划列表 D3 完整标注

5.3 数据库设计规范（03 · 34 项验证）

约束	规则
四节结构	ER 图 / DB 清单 / 数据字典 / DDL 齐全
命名机械项	表名/字段命名与后缀语义、保留字、索引前缀（A01–A08）；主键唯一与系统字段口径（B02/B06）
一致性机械项	索引清单与业务唯一覆盖（C02/C03）；四节齐全、ER↔清单、10 列字典、DDL COMMENT（D01–D04）；清单↔字典↔DDL 三方表集合与逐字段类型长度一致（E01/E02）；联动矩阵覆盖（X05）
执行方式	`verify db` 机械执行全部 `[M]` 项

5.4 接口设计规范（04 · 38 项验证）

约束	规则
编码与一致性	接口编码与 operationId 唯一、URI 风格、URL↔Method 一致（A01–A03）
字段表机械项	7 列字段表 + 字段稳定 ID、契约类型白名单、示例 JSON 可解析、必填枚举、RFC 3339 日期时间（B02–B10）
闭合机械项	总览 10 列接口清单；接口↔清单↔错误码三方闭合（D01–D05）
执行方式	`verify api` 机械执行全部 `[M]` 项

5.5 代码设计规范（05 · AC01–AC20）

模块边界、前后端分层、契约、依赖方向、测试和发布质量门——设计开发就绪的结构契约，不生成具体业务代码。核心条目：一个业务事实只能有一个数据所有者；模块必须声明职责/输入/输出/数据所有权/禁止依赖；validate-model 机械校验 design-model 的稳定 ID、引用完整性与 profile 版本。

5.6 需求设计说明书规范（06 · 43 项验证 + GB 颗粒度基线）

约束	规则
结构	权限矩阵、数据上报、七列活动说明表、五列 IPO（GB 风格步骤）、三句系统目标、标准角色/术语表
GB1–GB8 颗粒度基线	命令按钮处理逻辑按编号步骤书写，覆盖数据对象、字典稳定值、前置校验、审计履历、联动外同步、异常文案、展示规则与步骤可测性
一一对应	执行类活动与命令按钮一一对应（§5.1 按钮级覆盖）
功能编码	`[模块码][子域码][NNN]`，子域码可选，适配 10+ 功能的二级菜单模块
机械验证	结构、编码连续性、表格形状、IPO 空单元格、追溯闭合（`verify spec` 20 项）

5.7 设计集成评审规范（07 · D4 18 项联动）

自动采集 spec / DB / IF 三份 validate 结论，执行跨文档三角联动检查（D4）：字典值漂移、表名拼写漂移、活动↔命令端点、画面编码↔页面、字段跨文档一致性。输出综合评分报告：仪表盘 + P0 阻断清单 + 追溯矩阵。

5.8 术语字段词典规范（08 · 18 项验证）

中英文名、枚举、编码的统一锚点。推荐工作流：先建词典骨架 → 再做 spec/原型 → 推导数据库/接口（边做边登记词典）→ 变更时先跑影响分析 → 最后集成评审。词典先行，让"字段对不齐"在设计阶段就被拦下，而不是拖到评审时才发现。

5.9 变更影响分析规范（09 · 20 项验证）

逐域判断 spec / glossary / DB / API / prototype / review 受影响范围，输出 P0/P1/P2 补丁任务清单（复用变更影响补丁格式）+ 推荐复验顺序。

5.10 半成品文档接入（doc-intake · v0.10.0）

能力	说明
采集归位	半成品文档自动归类到对应设计域，未识别内容进"未归类区"
差距分析	机械 + 语义双轨；字典值漂移检测、名称近似漂移检测（如 `customNo` vs `custNo`）
补全计划	P0/P1/P2 任务清单；授权后补齐结构缺口
铸造	可 draft design-model，把散装文档变成可追踪模型

会议记录、截图、参照系统说明等零散素材也可直接交给它归档分析。

六、Skill 体系：10 个 Skill 全景

每个 Skill 标准形态：SKILL.md（AI 触发层）+ USAGE.md（人读说明）+ templates/ + examples/。AI 通过 _manifest.json 机器可读路由（触发词/状态/上下文/输出/闭环）自动调度，不需要记命令。

#	Skill	域	能力	触发示例
①	requirements-flowchart	需求	泳道流程图生成 + 20 项验证自修复	"帮我画废钢采购流程图"
②	requirements-spec-doc	需求	说明书骨架 + IPO 按钮级颗粒度展开	"为备件点检模块生成需求说明书骨架"
③	requirements-prototype	需求	原型标注（D1–D3 深度分级）	"标注订单列表页原型到 D3"
④	data-database-design	数据	ER / 清单 / 字典 / DDL 四节一体生成	"设计订单模块数据库表"
⑤	api-interface-design	接口	RESTful 接口设计 + 错误码清单	"设计订单状态变更接口"
⑥	code-architecture	代码	AC01–AC20 结构契约（不写业务代码）	"设计订单模块代码结构"
⑦	cross-glossary	跨域	术语字段词典：字段对齐中央锚点	"建订单模块术语词典"
⑧	cross-change-impact	跨域	变更影响矩阵 + 补丁计划 + 复验顺序	"订单状态新增退回，分析影响"
⑨	cross-design-review	跨域	集成评审评分 + D4 三角联动 + 追溯矩阵	"对三份设计文档做整体评审"
⑩	doc-intake	接入	半成品文档采集/差距分析/补全计划	"评估 docs/legacy 这批文档"

意图路由的工程保障（路由不是简单关键词匹配，有配套校验机制）：

路由语料 37 条，含歧义并列用例与纯负例，避免"触发词撞车"；
意图识别覆盖生成（create）/ 评估·审查·走查（review）/ 整理（maintain）；
manifest.intentPriority 与调度正文一致性门禁：doctor 机械校验"调度正文能力索引必须覆盖全部已发布 Skill"，防止索引漂移。

七、机械验证体系：verify CLI 四域

7.1 命令速查

bash

npx @agile-team/wl-skills-design verify spec       # 说明书 20 项机械检查
npx @agile-team/wl-skills-design verify flowchart  # 流程图几何/结构检查
npx @agile-team/wl-skills-design verify db         # 数据库 [M] 项全量
npx @agile-team/wl-skills-design verify api        # 接口 [M] 项全量
npx @agile-team/wl-skills-design validate-model    # 只读校验 design-model
npx @agile-team/wl-skills-design doctor            # 安装体检 + 隐私扫描 + 索引门禁

未覆盖项显式 skip，不静默放行。demo 目录本身是一份四域验证全部通过的基准样例——verify 对包内样例与 demo 必须全部通过、对故意破损的文件必须能检出（正反两个方向的回归测试保证）。

7.2 与人工评审的分工

环节	谁做	判定依据
结构/编码/一致性/闭合	`verify` CLI	`[M]` 项，机器判定，零遗漏
业务目标/异常文案/颗粒度深度	AI 对照样例	`[J]` 项，语义判断
业务事实正确性	产品 + 评审人	最终人工卡口

7.3 与下游包的契约对齐

对齐项	约定
交付 profile	统一 `jh4j3-openapi3@1.0`（kit/bd/design 三方同一快照）
前端映射	kit 页面 `externalId` 可选映射 design-model `screen.id`（可选增强，非硬依赖）
后端映射	bd 实体映射 `table.id`、字段映射 `field.id`
测试消费	说明书 IPO 与操作规则直接供 test 包 test-plan/test-case 生成

八、接入流程：三场景上手

场景 A · 从零到一生成设计文档（不需要任何既有文档）

对 Agent 说："为备件点检模块生成需求说明书骨架。模块范围：点检单从录入到归档；不含维修派工。业务目标：点检记录数字化、异常自动触发报修。"

然后按[输入准备清单]分层补事实：最小启动集（项目代号/模块范围/业务目标）→ 先出骨架、流程清单、关键问题清单 → 业务事实（岗位/业务对象/状态流/操作规则/报表需求）→ 展开到 IPO 按钮级、步骤级颗粒度 → 技术版镜像（数据库方案、接口契约）。缺失项自动标 【待补充】+Pending，Agent 每次只追问一个最关键的问题，绝不编造。

场景 B · 接入别人给的半成品文档

bash

# 对 Agent 说："评估 docs/legacy 下这批设计文档，输出差距报告和补全任务清单"
# doc-intake 自动：采集归位 → 机械+语义差距分析（含漂移检测）→ P0/P1/P2 补全清单

场景 C · 机械验证已有产物（纯只读，CI 可用）

bash

npx @agile-team/wl-skills-design verify db    # 对已交付的数据库设计文档跑 [M] 项
npx @agile-team/wl-skills-design verify api   # 对接口文档跑 [M] 项

日常管理

bash

npx @agile-team/wl-skills-design init                     # 安装（推荐 AGENTS.md 通用 profile）
npx @agile-team/wl-skills-design update                   # 更新（本地改动自动备份 .bak）
npx @agile-team/wl-skills-design restore --list           # 列出备份
npx @agile-team/wl-skills-design restore --id <backupId>  # 恢复（恢复前自动快照，可再撤销）
npx @agile-team/wl-skills-design uninstall --purge        # 彻底卸载

写入安全：安装/更新带锁文件（5 分钟过期自动清理）防并发互踩；覆盖现存文件前生成安全快照；状态文件原子替换；升级遇已停用编辑器 profile 自动降级并告警。

九、问题归属判断：改规范、改文档还是改工具

text

是否属于 9 条设计规范的通用要求？
  ├─ 否 → 评估是否为真实业务特例（如非标外部报文）
  └─ 是
      ↓
verify 是否已能机械判定？
  ├─ 是 → 先跑 CLI，报告即整改清单（文档侧修改）
  └─ 否
      ↓
是否在多个模块重复出现？
  ├─ 是 → 归口 wl-skills-design：升级规范 + Skill + 验证清单（新增项标注 [M]/[J]）
  └─ 否
      ↓
是否 AI 生成质量不达标（低于 examples 水准）？
  ├─ 是 → 抬高样例标杆 / 优化 SKILL 剧本（包侧修复）
  └─ 否 → 业务事实问题，人工补输入（使用侧修复）

判断原则：

能机器判定的不留给 AI 自觉，能确定性检测的不依赖人工走查；
规范升级必须同步抬高 examples/ 样例（样例即质量标杆）；
验证清单新增项必须标注 [M] 或 [J]，不接受"建议参考"式的模糊条款；
demo 与基准样例必须随规则升级同步更新并保持验证通过（回归测试强制）。

十、全员执行要求

10.1 必须执行

设计项目统一安装 @agile-team/wl-skills-design，版本升级同时更新锁文件；
新建设计文档一律从 Skill + templates/ 起步，不从空白文件自由发挥；
交付前必须通过对应域 verify（db/api 至少 [M] 项全部通过）；
字段命名先查术语词典，新字段先登记再使用；
变更先跑 cross-change-impact，出补丁清单后再动文档；
跨文档交付（spec + DB + IF）前跑 cross-design-review 集成评审；
半成品文档一律走 doc-intake 差距分析，不直接人工通读改写；
遇到规范未覆盖场景统一反馈，由公共包评估、修复、发版。

10.2 明确禁止

禁止绕过模板手工拼凑"看起来像"的文档结构；
禁止跳过 verify 直接交付（机械项红灯未清即进入评审）；
禁止同一业务对象在不同文档使用不同字段名而不登记词典；
禁止把"待补充"占位符留在交付版本中；
禁止在样例/模板中混入未匿名的真实业务数据（doctor 隐私扫描会拦截）;
禁止私自修改 .github/standards/ 形成项目局部规范。

10.3 允许但需评审

客户方强制要求的非标文档结构（doc-intake 接入后逐步对齐）；
外部系统报文等无法套用标准四节结构的场景；
与下游 kit/bd 交付口径冲突时的 profile 定制（须登记 profileId + protocolVersion）；
规范未覆盖的新图形/新组件形态。

十一、角色与职责

角色	主要职责
产品负责人 / 规范负责人	维护设计规范基线、公共包路线、版本策略和争议裁决
`wl-skills-design` 维护人员	规范更新、Skill/样例抬高、验证规则增强、机械检查项扩展、发版
产品设计人员	按 Skill + 模板产出设计文档，跑 verify，维护术语词典
架构师	code-architecture 结构契约、design-model 追溯关系确认
前端/后端负责人	消费 design-model 可选映射，契约握手问题反馈
测试人员	以说明书 IPO/操作规则为用例输入，颗粒度不足时反向推动补齐

十二、项目验收清单

12.1 接入验收

[ ] package.json 和锁文件中的 wl-skills-design 版本一致；
[ ] .github/standards/ 存在且包含 9 条规范；
[ ] .github/skills/ 存在且包含 10 个 Skill 与 _manifest.json；
[ ] .github/prompts/ 存在且包含 16 个 Prompt；
[ ] doctor 通过（安装完整性 + 隐私扫描 + 调度索引门禁）；
[ ] 本地修改未被 update 静默覆盖（有 .bak 备份记录）。

12.2 设计产物验收

[ ] 流程图：泳道/起止/连线/编码 20 项机械检查通过；
[ ] 说明书：43 项验证 + GB1–GB8 颗粒度（命令按钮步骤化）达标；
[ ] 数据库：E01/E02 三方一致（清单↔字典↔DDL 表集合与字段类型长度逐项对齐）；
[ ] 接口：D01–D05 三方闭合（接口↔清单↔错误码）；
[ ] 术语词典覆盖全部跨文档共享字段；
[ ] 无 【待补充】 占位残留。

12.3 交付验收

[ ] cross-design-review 评分报告已生成，P0 阻断清单清零；
[ ] design-model（如启用）通过 validate-model（稳定 ID/引用完整/profile 版本）；
[ ] 变更场景补丁计划齐备（P0/P1/P2 + 复验顺序）；
[ ] 与 kit/bd 契约握手通过（或显式声明独立 profile）。

十三、特殊场景反馈与持续迭代

13.1 反馈时必须提供的信息

text

项目/模块名称：
wl-skills-design 实际版本：
设计域：flowchart / spec / prototype / db / api / review / glossary / change / intake
涉及文档路径与章节：
verify 输出（如可执行）：
期望行为与实际偏差：
是否可稳定复现（附最小样例）：
是否涉及客户方强约束：

13.2 公共包修复要求

每次公共包修复必须做到：

先复现（构造通过的正例与必须被检出的负例），不以截图猜规则；
明确影响的设计域与验证项编号，新增项标注 [M]/[J]；
机械项必须同时提供正例（全部通过）与负例（必须被检出）回归测试；
样例与 demo 同步抬高，保持四域验证通过；
更新 README（双语）、使用指南与 CHANGELOG；
完成 lint + verify 链 + package-smoke（真实 npm 载荷冒烟：pack 白名单断言 + 全新目录安装 + CLI 全命令闭环）；
发布版本并向使用方提供升级说明。

十四、方案落地价值

设计即合规：产出物从第一稿就符合团队规范，评审从事后挑错转向业务把关；
机器兜底：四域 [M] 机械项 CLI 判定，人工记不住的规则不再遗漏；
跨文档一致性：E01/E02 三方对账 + D4 三角联动，字段漂移在交付前暴露；
半成品可接入：客户/外包文档不再需要人肉通读，差距分析 + 补全清单一步到位；
全链路追溯：design-model 稳定 ID 贯通设计→前端→后端→测试；
知识可沉淀：评审意见规则化进规范与验证清单，不随人员流动丢失；
AI 可控使用：模板定结构、样例定标准、验证定底线，AI 生成质量有下限保证。

十五、宣贯会议后建议输出

确认 9 条设计规范和 wl-skills-design 为设计侧统一事实来源；
确认各模块设计负责人名单；
确认设计项目接入台账与目标版本（≥ 0.11.1）；
确认第一批试点模块（建议 1-2 个新模块走场景 A 全链路 + 1 批存量文档走场景 B）；
确认 verify 纳入设计文档交付门槛的时间点；
确认术语词典的建立范围与维护责任人；
确认 design-model 追踪增强的启用模块（可选，不强制全量）；
确认规范缺口反馈通道与例会节奏。

附录 A：项目常用命令

bash

# 安装（推荐 AGENTS.md 通用 profile；也可指定编辑器与目标目录）
npx @agile-team/wl-skills-design init
npx @agile-team/wl-skills-design init --editor cursor --target ./my-project

# 预览 / 更新 / 恢复 / 卸载
npx @agile-team/wl-skills-design --dry-run
npx @agile-team/wl-skills-design update
npx @agile-team/wl-skills-design restore --list
npx @agile-team/wl-skills-design restore --id <backupId>
npx @agile-team/wl-skills-design uninstall --purge

# 四域机械验证
npx @agile-team/wl-skills-design verify spec
npx @agile-team/wl-skills-design verify flowchart
npx @agile-team/wl-skills-design verify db
npx @agile-team/wl-skills-design verify api

# 只读校验与体检
npx @agile-team/wl-skills-design validate-model
npx @agile-team/wl-skills-design doctor

附录 B：规范与工程能力对应关系

规范	内容	工程落地方式	验证项	当前状态
01	业务流程图	Skill + verify flowchart	20 项	已工程化
02	原型标注	Skill + D1–D3 深度 + 双层资料	23 项	已工程化
03	数据库设计	Skill + verify db（A/B/C/D/E/X 系）	34 项	已工程化
04	接口设计	Skill + verify api（A/B/D 系）	38 项	已工程化
05	代码设计	code-architecture（AC01–AC20）+ validate-model	AC×20	已工程化
06	需求说明书	Skill + verify spec + GB1–GB8	43 项	已工程化
07	集成评审	cross-design-review + D4 联动	18 项	已工程化
08	术语词典	cross-glossary + 字段锚点	18 项	已工程化
09	变更影响	cross-change-impact + 补丁计划	20 项	已工程化
—	半成品接入	doc-intake + 漂移检测	四域差距	已工程化
—	跨包追溯	design-model + jh4j3-openapi3@1.0	DM001–DM018	可选增强

十六、最终统一口径

设计规范统一不是要求每个人记住更多条款，而是通过 Skill 让正确结构成为默认产出，通过 verify 让机械偏差在交付前被机器拦下，通过词典和 design-model 让设计事实与代码、测试全程对齐。

从本次宣贯起，设计侧共同遵循：

规范基线看 9 条标准，工程实现以 wl-skills-design 为准；机械项 verify 说了算，语义项对照样例自检；公共问题归口公共包，业务特例必须显式评审；新文档不得绕过模板，存量文档按 doc-intake 差距分析分批接入。

产品设计规范落地宣贯文档（多项目集群管控方案） ​

一、宣贯目标与核心结论 ​

版本演进速览（v0.8.0 → v0.11.1） ​

二、落地背景与现存问题 ​

2.1 当前项目特点 ​

2.2 主要问题 ​

2.3 根因判断 ​

三、方案定位与统一原则 ​

3.1 方案定位 ​

3.2 三层事实来源 ​

3.3 两种验证轨道（核心机制） ​

3.4 双层资料供给 ​

四、整体工程架构 ​

五、wl-skills-design 统一管控覆盖维度 ​

5.1 业务流程图规范（01 · 20 项验证） ​

5.2 原型标注规范（02 · 23 项验证） ​

5.3 数据库设计规范（03 · 34 项验证） ​

5.4 接口设计规范（04 · 38 项验证） ​

5.5 代码设计规范（05 · AC01–AC20） ​

5.6 需求设计说明书规范（06 · 43 项验证 + GB 颗粒度基线） ​

5.7 设计集成评审规范（07 · D4 18 项联动） ​

5.8 术语字段词典规范（08 · 18 项验证） ​

5.9 变更影响分析规范（09 · 20 项验证） ​

5.10 半成品文档接入（doc-intake · v0.10.0） ​

六、Skill 体系：10 个 Skill 全景 ​

七、机械验证体系：verify CLI 四域 ​

7.1 命令速查 ​

7.2 与人工评审的分工 ​

7.3 与下游包的契约对齐 ​

八、接入流程：三场景上手 ​

场景 A · 从零到一生成设计文档（不需要任何既有文档） ​

场景 B · 接入别人给的半成品文档 ​

场景 C · 机械验证已有产物（纯只读，CI 可用） ​

日常管理 ​

九、问题归属判断：改规范、改文档还是改工具 ​

十、全员执行要求 ​

10.1 必须执行 ​

10.2 明确禁止 ​

10.3 允许但需评审 ​

十一、角色与职责 ​

十二、项目验收清单 ​

12.1 接入验收 ​

12.2 设计产物验收 ​

12.3 交付验收 ​

十三、特殊场景反馈与持续迭代 ​

13.1 反馈时必须提供的信息 ​

13.2 公共包修复要求 ​

十四、方案落地价值 ​

十五、宣贯会议后建议输出 ​

附录 A：项目常用命令 ​

附录 B：规范与工程能力对应关系 ​

十六、最终统一口径 ​

产品设计规范落地宣贯文档（多项目集群管控方案）

一、宣贯目标与核心结论

版本演进速览（v0.8.0 → v0.11.1）

二、落地背景与现存问题

2.1 当前项目特点

2.2 主要问题

2.3 根因判断

三、方案定位与统一原则

3.1 方案定位

3.2 三层事实来源

3.3 两种验证轨道（核心机制）

3.4 双层资料供给

四、整体工程架构

五、`wl-skills-design` 统一管控覆盖维度

5.1 业务流程图规范（01 · 20 项验证）

5.2 原型标注规范（02 · 23 项验证）

5.3 数据库设计规范（03 · 34 项验证）

5.4 接口设计规范（04 · 38 项验证）

5.5 代码设计规范（05 · AC01–AC20）

5.6 需求设计说明书规范（06 · 43 项验证 + GB 颗粒度基线）

5.7 设计集成评审规范（07 · D4 18 项联动）

5.8 术语字段词典规范（08 · 18 项验证）

5.9 变更影响分析规范（09 · 20 项验证）

5.10 半成品文档接入（doc-intake · v0.10.0）

六、Skill 体系：10 个 Skill 全景

七、机械验证体系：verify CLI 四域

7.1 命令速查

7.2 与人工评审的分工

7.3 与下游包的契约对齐

八、接入流程：三场景上手

场景 A · 从零到一生成设计文档（不需要任何既有文档）

场景 B · 接入别人给的半成品文档

场景 C · 机械验证已有产物（纯只读，CI 可用）

日常管理

九、问题归属判断：改规范、改文档还是改工具

十、全员执行要求

10.1 必须执行

10.2 明确禁止

10.3 允许但需评审

十一、角色与职责

十二、项目验收清单

12.1 接入验收

12.2 设计产物验收

12.3 交付验收

十三、特殊场景反馈与持续迭代

13.1 反馈时必须提供的信息

13.2 公共包修复要求

十四、方案落地价值

十五、宣贯会议后建议输出

附录 A：项目常用命令

附录 B：规范与工程能力对应关系

十六、最终统一口径