admin
e03465c398
用户令逐字：「E:/ProgramData/.workbuddy/skills 提交仓库是指的这里」—— 即本目录就是仓库（2026-10-07 已在本目录建仓，见当日日志 §22），本轮把余下未纳管的 9 个技能一并提交。 本次入库（9 个技能，46 个文件）： 1、`AI HOT` 2、`draw-ui` 3、`dsh-diagnose` 4、`dsh-knowledge` 5、`dsh-local-env` 6、`dsh-opensource-release` 7、`dsh-workflow` 8、`oil-motion` 9、`skills-security-check` 提交前核对： · **凭据类扫描**（`*.env` / `*token*` / `*.key` / `*secret*` / `*.pem`）⇒ **零命中** ✓； · 体积合计约 20 MB（`draw-ui` 12M ＋ `oil-motion` 6.5M 是大头，形态为配图/素材 —— 仓库 `.gitignore` 里明写「`assets/*.png` 是内容不是产物」⇒ 属刻意入库）； · 运行产物仍按既定规则排除（`__pycache__` / `logs/` / `tmp/` / `.venv/` / `*.egg-info` / `uv.lock` / `.workbuddy/`）。
77 lines
8.9 KiB
Markdown
77 lines
8.9 KiB
Markdown
---
|
||
name: dsh-knowledge
|
||
description: DSH 平台**项目知识与架构资产**的维护总入口 —— 覆盖两半：① **知识库 / 文档维护与纠偏**（「文档与现状不符」「同一事实多处打架」「知识越积越碎」「AI 忘了某条规则」「要收敛或重构知识库结构」，以及定期体检；**说话能"这么多技能会不会挑不对 / 技能太多不好维护"时的技能集体检**）② **过程文档与架构定稿的分层机制**（要**写架构级设计**、要**把推演结论定稿**、要判断**某份文档该放过程还是定稿**、要查「**现在的架构到底是什么样**」、或发现**同一架构有多处互相矛盾的表述**）。核心 = 六层知识结构 L0–L5（含 **L0.5 架构定稿层**）＋ **分层判据（实体 vs 指针）** ＋ Lint 四件套（可接 CI）＋ 漂移处理 SOP 五步 ＋ **§9 技能集可用性体检（10 层取证法）** ＋ **§10 技能重组：千行技能拆分（主干 + references）** ＋ **两个目录的唯一分工判据** ＋ 定稿命名约定 ＋ 收敛五步 ＋ 冲突仲裁 ＋ 过时档案只加状态块 ＋ 定稿三道验收。判据实体在主干，**全文在 `references/`（2 档）**。
|
||
version: 1.0.0
|
||
updated_at: 2026-09-28
|
||
last_change: 【2026-09-28】**由 `dsh-knowledge-upkeep`（v1.0.0）＋ `dsh-architecture-lifecycle`（v1.0.0）合并而成**（两个原名退役）。按 `dsh-knowledge-upkeep §10`「主干 + 详情档」形态落地（**用本技能自己的方法重组自己**）：判据实体留主干、全文下沉 `references/`（**内容守恒：逐行 0 丢失**，含原 frontmatter 变更历史）。合并理由：两者是同一域的两半 —— 一个管「**知识怎么不变错**」，一个补「**L0.5 定稿层与收敛流程**」（前者的 §1.1 已显式引用后者）。另：`knowledge-upkeep` 的文档库版独有「🔵 作用域 ＋ 宿主落点对照（DSH ← WorkBuddy）」块，**已并入**（那张表是本技能跨宿主可用的关键）。⛔ 未删任何判据。
|
||
agent_created: true
|
||
---
|
||
|
||
# dsh-knowledge — 项目知识与架构资产维护
|
||
|
||
> ## 🔴 第 0 步：先分诊
|
||
>
|
||
> | 情形 | 去哪 |
|
||
> |---|---|
|
||
> | 文档与现状不符 / 同一事实多处打架 / 知识越积越碎 / 定期体检 | **§1** |
|
||
> | 「这么多技能会不会挑不对 / 技能太多不好维护」 | **§1 → 技能集体检（10 层）** |
|
||
> | 某个技能已到千行级、加载太吃上下文 | **§1 → 技能重组（主干 + references）** |
|
||
> | 写架构级设计 / 把推演结论**定稿** / 判断某文档放过程还是定稿 | **§2** |
|
||
> | 查「现在的架构到底是什么样」/ 发现架构表述互相矛盾 | **§2 → 冲突仲裁（**以定稿为准**）** |
|
||
|
||
---
|
||
|
||
## 1. 知识库 / 文档维护与纠偏
|
||
|
||
🔴 **判据的对象是「`description` 的区分度」**（技能按 description 匹配、按需加载）—— ⛔ 不是"正文写得好不好"。
|
||
|
||
**六层知识结构 L0–L5**（含 **L0.5 架构定稿**，见 §2）：`L0 工作区规则` / `L0.5 架构定稿` / `L1 索引` / `L2 状态层` / `L3 交接与接续` / `L4 过程档案` / `L5 过程只增不改`。
|
||
|
||
🔴 **分层判据（决定"写实体还是留指针"）**：
|
||
> **不看会导致「违规 / 事故」的 ⇒ 必须写实体；只让人"更慢更绕"的 ⇒ 给指针。**
|
||
（对应本技能 §9 的口径：**判据常驻 > 行数目标**；判据密集的技能，`≤350 行`可能**结构上不可达** ⇒ 达不到就**如实报数字**，⛔ 不许把硬规则降级成指针去凑行数。）
|
||
|
||
**漂移处理 SOP 五步**（发现 → 收敛）：定位 → **判新旧（分水岭）** → 按结构重组 → 标回溯 → **标未决（🔴 红线：未决项必须显式）**。
|
||
|
||
**技能集可用性体检（10 层取证法）** —— 每层一个脚本、**落盘跑，⛔ 别用 `python -c`**（含反引号会被 shell 吃掉 ⇒ 静默无效果）：
|
||
1 description 全量 ＋ 探针词重叠｜2 **精确提取引号内触发短语**（零重复＋零包含＝健康）｜3 真实说法→命中谁（**期望技能不在命中集＝❌ 真缺陷**，比"撞"严重）｜4 三处一致性/引用/版本/体量｜5 引用上下文逐条看（**必须看原文语境**，插件名/工作区名全是假阳性）｜6 自然说法覆盖率｜7 **用历史会话原话做验证集**（最强）｜8 盲区二分＋补漏词重跑｜9 **用户明确定过的规则是否接得住**（最容易漏、后果最重）｜10 frontmatter 结构校验（**字段唯一性** ＋ 版本 x.y.z）。
|
||
|
||
🔴 **两条最容易自我误导的**：
|
||
- **判据漏词会伪装成"技能盲区"** ⇒ 报盲区前**必须先用目标技能的 description 原文核验一遍**，确认不是自己的关键词表不全。⛔ 不许把"我判据里补的词"当成"技能已覆盖"。
|
||
- **不是所有"撞"都要消**：**良性撞**（分工互补）多加载一个是好事 ⇒ ⛔ 不要为了"看起来干净"去削；只消**恶性撞**（撞了但**偏向错误的一方**）。修法＝补缺的说法 ＋ 给两边都加**「⚠️ 与对方的边界」（双向指认）**。
|
||
|
||
**技能重组（千行拆分）**：`SKILL.md` 留**判据＋流程主干＋命令骨架**，长表/案例/实测/历史 ⇒ `references/<两位序号>-<主题>.md`，原位只留一行指针。**四条硬约束**：① **内容守恒**（可机械校验；⛔ 不许借机删任何判据/命令/事故事实）② **判据实体常驻** ③ 每档自包含（头写「覆盖哪些原章节＋原行段」）④ **三处同步 ＋ 登记跟改**。
|
||
**四项验收**：① 守恒 ② 三处 md5 一致 ③ 原**每一个标题**在新结构可寻址 ④ frontmatter 唯一、`version` 递增。
|
||
🔴 **下沉必带的副作用**：正文里 `见 §8 坑 9` / `见下表：X` 这类**编号引用会断头**（实测一次抓到 5 处）⇒ 主干末节加一张「详情档 × 覆盖原章节 × 原行段」表定位。
|
||
🔴 **落盘前必查两条**：`diff -rq` **只比内容**、**查不出「脚本里写着旧工作区绝对路径」**这种路径级引用；三处同步时**服务器上也有根登记副本**（`README.md`/`INDEX.md`），登记行**按行首单元格匹配**（⛔ 别用"技能名出现在这一行里"判命中）。
|
||
|
||
📂 **全文 ⇒ `references/00-知识库维护与纠偏.md`**（含 Lint 四件套细节、漂移 SOP 完整版、**§8.6 注入预算**（长文件后半段等于不存在）、§9 十层脚本清单与实测数据、§10 执行四步与 `split_skill.py`、§11 归档镜像治理、反例与自检清单）
|
||
📂 **拆分器 ⇒ `references/dsh-knowledge-upkeep/split_skill.py`**（`--spec <json>`，声明式规格＝纯搬运）
|
||
|
||
---
|
||
|
||
## 2. 过程文档与架构定稿的分层机制
|
||
|
||
🔴 **两个目录、一个判据**（本技能的核心）：**过程答「怎么想的」／定稿答「该做成什么样」**。
|
||
|
||
**定稿命名约定**：`<对象>-<架构名>.md` —— **⛔ 无编号前缀 · 一个目录装全部**。
|
||
**收敛五步（过程 → 定稿）**：定位 → **判新旧** → 按架构重组 → 标回溯 → **标未决**。
|
||
🔴 **冲突仲裁**：过程与定稿打架 ⇒ **以定稿为准**，且**必须写进两边**。
|
||
🔴 **过时档案只加「状态块」，⛔ 不改正文**（改写历史记录＝造假）；且**⛔ 不要在两处同时改**。
|
||
**定稿的三道验收**：① 可独立读懂（不依赖过程档案）② 可照此施工 ③ 可回溯（能指回过程）。
|
||
|
||
📂 **全文 ⇒ `references/01-过程与定稿分层.md`**（含为什么需要它、唯一判据落到每一份文件、冲突仲裁细则、收敛五步的每一步、状态块纪律、定稿目录 README 要求、与既有技能的分工、自检、真实反例、一屏速查）
|
||
|
||
---
|
||
|
||
## 3. 详情档索引（跨档引用按此表定位）
|
||
|
||
| 档 | 覆盖的原技能 | 原章节 |
|
||
|---|---|---|
|
||
| `references/00-知识库维护与纠偏.md` | `dsh-knowledge-upkeep`（v1.0.0，全文，**含文档库版独有块**） | §0 为什么需要 / §1 六层结构与单一来源（含 §1.1 L0.5）/ §2 分层判据 / §3 Lint 四件套 / §4 漂移 SOP / §5 自动化的边界 / §6 反例 / §7 自检 / §8 无效信息与高价值写法（含 §8.6 注入预算）/ §9 技能集体检 10 层 / §10 技能重组 / §11 归档镜像治理 |
|
||
| `references/01-过程与定稿分层.md` | `dsh-architecture-lifecycle`（v1.0.0，全文） | §0 为什么需要 / §1 两个目录一个判据 / §2 命名约定 / §3 收敛五步 / §4 过时档案处理 / §5 定稿三道验收 / §6 目录 README / §7 与既有技能分工 / §8 自检 / §9 反例 / §10 判据速查 |
|
||
| `references/dsh-knowledge-upkeep/` | 原附属档 | `10-技能重组-千行技能拆分.md` · `split_skill.py` |
|
||
|
||
🔴 **两个原名已退役**（`dsh-knowledge-upkeep` / `dsh-architecture-lifecycle`）⇒ 别处见到按本技能对应档读。
|
||
⚠️ **就绪提示**：本技能可以**用自己重组自己** —— §1 的技能重组四步 ＋ 各项验收，就是它自身这一形态的依据。
|