| name | construction-blueprint |
| description | 施工蓝图 skill(用户级通用)。在写代码之前,把一次任务的施工面做成"代码镜像 + 施工指南":逐文件变更清单、关键实现点、施工切片、验收映射。目的是限制施工范围,并让对抗评审发生在图纸上而不是已成型的代码上。一次性消耗品,施工完成即归档。 |
施工蓝图
本 skill 是任务级详细设计的施工层,用户级通用,可跨项目使用。
它解决的问题:直接从设计跳到代码,评审只能发生在代码写完之后——错误已扩散进几十个文件,大 diff 评审有疲劳和沉没成本,范围蔓延和漏改反而最难看出来。施工蓝图把评审前移:
作用 = 代码镜像 + 施工指南:开工前把"动哪些文件、按什么顺序、关键处长什么样"钉死,让对抗评审打在图纸上。蓝图评审拦"方向错",代码后检查拦"手抖错",两道闸缺一不可。
与轻量设计方案(lightweight-design skill)的海拔分工:
轻量设计方案 ── 决策海拔 ── 人看的,用户审核拍板
↓
施工蓝图 ────── 代码海拔 ── AI 看的,开工前对抗评审(本 skill)
↓
施工 → 回补七层文档
关键性质:一次性消耗品。 L5/L6 禁止代码镜像是因为它们是长期真值、代码一改就腐烂;蓝图施工完即归档,来不及腐烂,所以文件清单、方法签名、伪代码在本层全部合法。
1. 输入与何时用
输入(按优先级):
- 轻量设计方案(首选——已拍板的决策是蓝图的裁判标准)
- 七层正式文档(任务直接基于现存设计施工时)
- 需求 + 用户当轮聊天确认(必须在蓝图里显式登记为"真值来源")
用:中大任务施工前必经;凡是写了轻量设计方案的任务,默认接一份蓝图。
可跳过:
- 小改动(计划模式足够)
- 纯文档任务
- 轻量设计方案本身已足够简单、变更面只有一两个文件时(此时计划模式即蓝图)
2. 粒度铁律(防"代码写两遍"反模式)
蓝图写得太细 = 把代码写两遍,又慢又没增益。粒度卡死在:
| 内容 | 粒度 |
|---|
| 变更清单(主体) | 文件级:一文件一行,新增/修改/删除 + 一句"改成什么样" |
| 关键实现点 | 仅歧义点/风险点下沉到逻辑级(允许方法签名、伪代码) |
| 纯透传 / CRUD / 标准操作 | 只列文件,不展开 |
判定句:蓝图字数接近预估代码量 → 写过头了,砍。
3. 文档模板
# 施工蓝图:{任务名}
> 上游输入:{轻量设计方案路径 / 七层文档 / 用户决策}
> 状态:待评审 / 已评审通过 / 施工中 / 已归档
## 1. 任务边界
改什么 + 明确不改什么(负面清单,限制范围的主力)
## 2. 变更清单 ★代码镜像主体
逐文件三分类(含 DB migration、配置、脚本):
### 新增
- `path/to/NewFile`:一句意图
### 修改
- `path/to/File`:改哪部分、改成什么样(一句)
### 删除
- `path/to/OldFile`:为什么退出
## 3. 关键实现点(仅少数点,逻辑级)
对有歧义/有风险的点写到逻辑级;允许签名与伪代码
## 4. 施工切片
| 切片 | 内容 | 前置 | 完成判定 |
每片独立可编译/可验证;判定写得可执行,不写"完成即完成"
## 5. 历史资产退出(重构/替换类任务必写)
旧表 / 旧代码 / 旧格式 / 旧接口语义:删什么、何时删、是否留兼容层
## 6. 红线自检
项目分层方向 / 域边界 / 工程红线 逐条打勾(清单由项目补丁注入)
## 7. 验收映射 ★对抗评审主靶面
| 轻量设计决策点 | 落在哪条变更条目 |
有决策无落点 = 漏;有落点无决策 = 越权加戏
## 8. 验证与回归
编译 / 测试 / 接口脚本是否同步 / 是否需手工验证(逐项判断,不留空白)
## 9. 风险与回滚
最坏情况怎么退(一段话)
## 10. 可开工性结论
只许三种:可以 / 基本可以但差非阻塞补充 / 不可以+阻塞清单
4. 对抗评审协议(开工前的那道闸)
评审输入:蓝图 + 轻量设计方案 + 相关契约文档(接口/数据库层)。
三个靶面(恰好是代码评审最容易漏的):
| 靶面 | 评审问题 |
|---|
| 范围越界 | 变更清单里有没有不在任务边界内的文件?有没有动了不该动的域/模块? |
| 遗漏 | 该改的调用点列全了吗?接口改了,所有消费方都在清单里吗? |
| 方案性错误 | 关键实现点与已拍板决策一致吗?分层/事务边界/批量查询等是否违反项目规范? |
裁判标准:第 7 节验收映射表逐条核对——评审不是泛泛"看看方案好不好",而是拿轻量设计当裁判逐条对。
强度分档(具体升级条件由项目补丁声明):
- 常规任务:单评审(一个独立视角过三个靶面)
- 高风险 / 命中项目死亡线:
adversarial-review 多方对抗评审
评审结论处理:评审发现的问题改在蓝图上,改完可再评一轮;评审通过后蓝图冻结,进入施工。
5. 施工纪律
- 施工只能按蓝图执行——蓝图就是施工范围的合同
- 施工中发现必须偏离 → 先回改蓝图(小偏离:更新变更清单并说明原因)再继续写代码
- 偏离触及已拍板决策 → 退回轻量设计层重新拍板,不允许蓝图或代码里悄悄改
- 禁止"代码里偷偷扩张":完工后实际 diff 与变更清单的差异,就是验收时要解释的清单
6. 生命周期
起草 → 对抗评审 → 冻结开工 → 施工(偏离须回改)→ 完工归档
- 蓝图是任务资产,不是正式真值:不得混入七层正式文档目录冒充 L3/L4/L6
- 回补七层按轻量设计方案的"回补清单"执行;蓝图本身归档即终结
- 与七层文档冲突时听七层裁决链(经轻量设计层裁决过的除外),蓝图无裁决权
7. 项目补丁挂载点
| 挂载项 | 内容 |
|---|
| 存放路径 | 与轻量设计方案同任务目录 |
| 红线自检清单 | 项目工程红线 / 分层方向 / 域边界规则(注入模板第 6 节) |
| 死亡线升级 | 命中项目死亡线区域 → 评审升档规则 |
| 验证基建 | 项目的编译/测试/检查脚本命令 |
8. 质量自检清单