lightweight-design

name	lightweight-design
description	轻量设计方案 skill（用户级通用）。为单次局部修改任务编写"任务级 L5/L6"——用决策海拔锁死本次要改什么、怎么改的业务逻辑与关键技术取舍。它是用户审核层与施工期局部临时真值：用户在此拍板，AI 据此（或据此生成的施工蓝图）施工，完工后回补七层文档。

轻量设计方案

本 skill 是任务级详细设计的决策层，用户级通用，可跨项目使用。

它解决的问题：实际开发中大量任务是局部修改，不值得（也不应该）每次都重写整域的 L5/L6 文档；但只拿需求直接开工，AI 干着干着就会跑偏。轻量设计方案就是补在中间的那一层：

作用 = L5/L6 的任务切片版：钉死本次修改的业务逻辑与关键技术实现，人和 AI 都看得懂；用户在这一层审核拍板，施工期它就是局部真值，完工后回补七层。

与施工蓝图（construction-blueprint skill）的海拔分工：

轻量设计方案 ── 决策海拔 ── 人看的，用户审核拍板（本 skill）
      ↓
施工蓝图 ────── 代码海拔 ── AI 看的，开工前对抗评审
      ↓
   施工 → 回补七层文档

---

1. 什么时候用 / 不用

用（满足任一即考虑）：

1. 局部功能开发、局部重构、单链路改造，且存在需人拍板的决策点
2. 任务跨多个文件/模块，直接开工容易范围蔓延
3. 用户明确要求"先出设计方案再动手"

不用：

场景	改用
小改动（修 bug、加字段、单文件小改）	Claude Code 计划模式，零文档成本
整域级设计 / 新域立项	直接写七层正式文档（L1~L7）
纯执行、无决策点的机械任务	直接做
跨会话、多 agent 的超大任务	task-control-doc 总控 + 每个专题各自走"轻量设计 → 蓝图"

---

2. 生命周期（六态）

起草 → 冲突检查 → 用户拍板 → 施工期临时真值 → 完工回补七层 → 归档降级

阶段	硬规则
① 起草	输入 = 需求 / 聊天确认 / 现存七层文档 / 代码摸底
② 冲突检查	起草时必须与现存七层文档核对；发现不一致按 doc-layer-system §2 三级分级走人工裁决，禁止 AI 自行选边。轻量设计不得越权推翻 L1 / L2 / L3 正式真值
③ 用户拍板	唯一必经的人工闸。用户在此层验收设计，拍板后决策冻结；后续施工不得自行重裁
④ 施工期临时真值	施工 AI 只看本文档（或据它生成的施工蓝图），不需要翻整域七层文档；与七层冲突的部分以本文档为准（因为②已裁决过）
⑤ 完工回补	按文档内"影响面与回补清单"把正式承诺同步回七层（接口→L3、表→L4、核心决策→L5/L6、测试→L7）
⑥ 归档降级	回补完成后在文档头部显式标记"已回补，本文档失效"，防止与七层形成两套真值

---

3. 写作规范（直接继承 L5/L6 写作规范）

本 skill 的写作海拔与 doc-layer-system §5.5/§5.6 及其 references/L5L6写作指南.md 完全同源：

• 决策锁死三件套：每个决策点写清 选了什么 / 放弃了什么 / 为什么
• 海拔规则：只写到决策/意图海拔；判定句——"这句话删掉、读者直接看代码反而更准，它就超标了"
• 试金石：「不写下来的话，一个有能力的 AI 施工时，会不会做出一个看起来合理、但和已拍板结果不同的选择？」会 → 进文档；不会 → 不写
• 精炼 ≠ 含糊：每个决策点必须锁死到唯一选择，禁止"采用合适的策略"式模糊措辞
• 锚点制：标识符（类名/表名/字段名）每个论点至多一个，仅供定位
• 禁止：代码、伪代码、逐方法调用链复述——这些属于代码海拔，归施工蓝图

与 L5/L6 正式文档的唯一区别：范围是本次任务切片，不是整域；且生命周期是临时的（完工回补后失效），而 L5/L6 是长期真值。

---

4. 文档模板

# 轻量设计方案：{任务名}

> 状态：草稿 / 已拍板 / 施工中 / 已回补失效
> 真值基线：{依据的七层文档 / 用户决策 / 代码摸底}

## 1. 背景与意图（3 行内：为什么改、改成什么样）

## 2. 范围与非范围
   本次改：…
   本次明确不改：…（负面清单要硬，不许模糊）

## 3. 决策表 ★核心章节
   | 决策点 | 选定 | 放弃 | 为什么 |
   |---|---|---|---|
   （有几个需人拍板的点就写几行，不设上限；逐条过试金石）

## 4. 业务规则与状态流（如有）
   表格 / 状态图；规则用业务语言，不用字段清单代替

## 5. 关键技术实现（决策海拔）
   事务边界 / 缓存策略 / 幂等 / 同步异步 / 并发处理 等取舍
   每条至多一个代码锚点

## 6. 影响面与回补清单
   完工后要回补哪几层、哪几份文档（逐份点名）

## 7. 风险与待确认
   阻塞级（必须先决策，未决禁止进入蓝图/施工）vs 非阻塞（可延后）

---

5. 审核与下游衔接

• 拍板点：第 3 节决策表 + 第 2 节负面清单是用户审核的主靶面；用户确认即冻结
• 下游：拍板后据本文档生成施工蓝图（construction-blueprint skill）；蓝图的"验收映射"章节必须把本文档每个决策点映射到具体变更条目
• 施工中决策变更：施工中发现已拍板决策需要改 → 退回本层重新拍板，不允许在蓝图或代码里悄悄改

---

6. 项目补丁挂载点

以下内容由各项目的项目级补丁声明（如项目的七层补丁 skill 或项目 CLAUDE.md）：

挂载项	内容
存放路径	本文档与施工蓝图的统一任务目录
红线对照	项目工程红线 / 域边界规则，起草时逐条对照
死亡线升级	命中项目死亡线区域时的评审升级规则（如 ask-opus / adversarial-review）
回补钩子	完工后的文档同步规则与检查脚本

---

7. 质量自检清单

• 每个决策点都过了试金石（拿掉它 AI 真的会裁错）？
• 决策表逐条有"选定/放弃/为什么"，没有模糊措辞？
• 负面清单够硬（明确写了不改什么）？
• 阻塞级待确认已清零（或显式挂起整个任务）？
• 全文无代码/伪代码/调用链复述？
• 与现存七层文档的冲突已检查、已裁决？
• 回补清单逐份点名了目标文档？
• 一个不读代码的人能完全看懂并拍板？