55 lines
3.8 KiB
Markdown
55 lines
3.8 KiB
Markdown
|
# 「说人话」改写存档 · 被 `1d7d31a` 覆盖掉的那一批（2026-10-08）
|
|||
|
|
|
|||
|
|
## 这是什么
|
|||
|
|
|
|||
|
|
`product-planning` 技能包在 2026-10-08 22:22 被提交 `1d7d31a`（作者 `maogeigei`）**整文件覆盖**过一轮，理由是「说人话新稿按合并落地（141 处措辞替换）」。核查后发现它并不是"合并"，而是**用一份基于较早版本写成的新稿覆盖了整包** —— 那一批「说人话」措辞改写本身有价值（2026-10-07 用户定案：一切落盘文字都要过说人话），所以在此存档，供将来重新叠加时取用。
|
|||
|
|
|
|||
|
|
整包已回退到 `44d42b0`（2026-10-08 第八轮收口版，闸门 `2060 ｜ 0 ｜ 27` 全过）。
|
|||
|
|
|
|||
|
|
## 文件
|
|||
|
|
|
|||
|
|
1、`改动对照.diff` —— `44d42b0` → `1d7d31a` 的全量 diff（2445 行）。要叠加说人话时对着它逐块看。
|
|||
|
|
|
|||
|
|
2、`说人话版全文/` —— `1d7d31a` 版的 7 个文件全文，照原目录结构放：
|
|||
|
|
|
|||
|
|
- `SKILL.md`
|
|||
|
|
- `references/stage-delivery/SKILL.md`
|
|||
|
|
- `references/stage-delivery/references/execution-runbook.md`
|
|||
|
|
- `references/stage-delivery/references/layouts-tooling.md`
|
|||
|
|
- `references/stage-discovery/SKILL.md`
|
|||
|
|
- `references/stage-requirements/SKILL.md`
|
|||
|
|
- `references/stage-requirements/references/create-prd.md`
|
|||
|
|
|
|||
|
|
## 怎么用（关键：只取措辞，不取结构）
|
|||
|
|
|
|||
|
|
在 `44d42b0` 基线上逐块比对，**只采纳措辞层面的改写**。下面这些**⛔ 一律不要采纳**，它们不是措辞问题，是那次覆盖造成的结构损坏：
|
|||
|
|
|
|||
|
|
1、**四处「单一可信源」声明**被删（`44d42b0` 有 5 处，覆盖后只剩 1 处）—— 其中 `stage-delivery/SKILL.md` 的 `## 供给（唯一权威处 · 改供给只改这一块）` **整节标题连同六行供给表一起被换成了另一种三列表**。这是用户 2026-10-08 定的口径，必须保留原样。
|
|||
|
|
|
|||
|
|
2、**供给口径被翻转** —— 用户定案是「默认主线 ＝ `oil-ui-pro`（基础层），`open-design` 只是随段携带的**可选件**、选了才用」；覆盖版写的是「`open-design` ＝ 本段默认主线」。⛔ 不要采纳。
|
|||
|
|
|
|||
|
|
3、**`execution-runbook.md` §7 完成标准丢了两条勾选项** —— 「供给能力边界已核对」（含反 AI 味 / 无障碍 / 动效纪律 / 表单校验四项记为证据缺口）与「页型已判…每条都要附取值记录」（含"给不出取值的条目改写为本条无机检"）。
|
|||
|
|
|
|||
|
|
4、**`3c` 子步改名** —— 覆盖版把「3c GPT 参考版」改成「3c GPT 会诊」（总入口四段表、`stage-delivery` 详情、`runbook` 三处），但没同步 `scripts/check_naming.py` 的 `STAGES` 表，直接让闸门报 FAIL。回退版三处一致，是自洽的。
|
|||
|
|
|
|||
|
|
5、**复述与旧路径** —— 覆盖版让 9 条「复述」类 FAIL 与 2 条废路径（`strategy/`、`ux/`）重新长回来，因为权威声明一被削弱，复述就不再被视为违规。回退版没有这些问题。
|
|||
|
|
|
|||
|
|
## 一个可复现的判据
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
cd E:/ProgramData/.workbuddy/skills
|
|||
|
|
for c in 44d42b0 1d7d31a; do
|
|||
|
|
rm -rf /tmp/pp-$c && mkdir -p /tmp/pp-$c
|
|||
|
|
git archive $c product-planning | tar -x -C /tmp/pp-$c
|
|||
|
|
printf "=== %s ===\n" "$c"
|
|||
|
|
(cd /tmp/pp-$c/product-planning && \
|
|||
|
|
E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe \
|
|||
|
|
scripts/check_naming.py --root . --ws "E:/ProgramData/AIProject/contentm_agent" 2>&1 | tail -2)
|
|||
|
|
done
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
`44d42b0` ⇒ 全过；`1d7d31a` ⇒ `失败 12`。判据脚本 `check_naming.py` 在该区间**零改动**，所以差异只能来自内容。
|
|||
|
|
|
|||
|
|
## 教训
|
|||
|
|
|
|||
|
|
「新稿落地」时不做三方合并、直接整文件覆盖，**必然丢掉晚于新稿编写时点的改动**。这类操作前应先比对新稿的编写时点与被覆盖文件的最新修改时点；反过来，收到覆盖性提交后，第一件事是拿「唯一权威处」这类结构标记计数做体检（`git grep -c "唯一权威处" <rev> -- product-planning`），而不是只看闸门绿不绿。
|