dsh_ai1net_server/归档/humanize-原文件备份-20260922/docs-skills-dsh-opensource-release/references__05-已知待办与漂移.md

已知待办 / 漂移（接手先看）

归属：技能 dsh-opensource-release 的详情档（按需读，不是每次都要读）。 本档覆盖：已知待办 / 漂移（接手先看）（原行 L796–L1080）。 主文件 / 判据与流程主干 = ../SKILL.md（§0.5 事故清单 · §0 事实 · §1 硬规则 R-O1–R-O17 · §1.5 用户当场纠正的硬口径 · §5 授权结构 · §6 发布 SOP 主干 · §7 验证八件套 · §相关）。 来源：2026-09-22「技能重组线」把 ../SKILL.md 的 L796–L1080 段逐行原样下沉到本文件，未改一字。 跨档引用：正文里的「§N / 见 §8 坑 N / 见下表」等编号，用 ../SKILL.md 末节「详情索引」的原章节列定位。 维护：本文件与 ../SKILL.md 的指针行成对；改内容时同时核对主文件的指针描述是否仍准确。

---

10. 已知待办 / 漂移（接手先看）

✅ 2026-09-13 15:1x 全部清零 —— 以下原待办均已处理： · install.sh 已在服务器隔离目录跑通 --dry-run（并修 4 个缺陷）｜ · 悬空 docs/*.md 42→0｜ · 「档案 NN」197→0｜ · 7 处占位符已按 PUBLISH_* 填｜ · poc/ 两个插件的加回结论 = 保持移除。 ⛔ 「授权条款 / 法律意见 / 上游作者（已按要求不再具名） 是否本人」已从本项目移除 —— 用户明确「你的任务是改造和优化，这些内容全部删除」⇒ 不再列为待办、不再上抛（事实层面的 MIT 约束见 §5，那条不许删）。

当前仍需注意的（非待办，是风险提示）：

• ⚠️ 首装从未在干净机器上真跑过：--dry-run 已验证全流程，但真实安装会写 /etc、建 systemd unit、起服务 ⇒ 首次真装请在一台干净机器上做。
• ⚠️ 导出基线会漂：导出脚本复制的是工作树（多会话并行在改源码仓）⇒ 发布前按 git archive <commit> 冻结，或每次重建必重跑探针 + _verify_tsc.mjs。
• ✅ 项目名已定稿（用户 2026-09-13）：中文 DSH Web 平台 ｜ English DSH Web Platform ｜ 技术标识 dsh-web-platform（已在 npm 与插件目录实测未占用）。若日后要换名，按 R-O8 重走「查占用 → 改全量标识 → 保留出处致敬」，并把新废弃的旧名加进探针。
• ✅ 本技能的归档副本 + INDEX.md 登记已补（2026-09-13）：dsh-server-docs/skills/dsh-opensource-release/SKILL.md，两副本 md5 一致；INDEX §一/§二 已登记；四件套全绿。 ⚠️ 本技能每次改动后都要同步归档副本（md5 必须一致），同步前先抢全局执行锁；纪律 = 先单独抢锁当场看输出 → 验 OWNER 是自己 → cp → 两副本 md5 一致 → 复跑四件套 → 再验 OWNER → --release-exec。
• ⏳ 英文版待生成（发布前必做，见 R-O13）：README.en.md + PLUGIN-PORTING.en.md + 两份顶部的语言切换行。当前刻意不做（用户口径：中文优先，同步 GitHub 时再更新英语）—— ⚠️ 但切换行要等英文文件存在后再加，否则是死链。
• 🔴 导出基线会漂（2026-09-13 11:2x 实测）：导出脚本复制的是工作树，而多个会话在并行改源码仓 —— 当时 D:\github\dsh_shenxian 的 HEAD 仍是 da3e0f9（⚠️ 2026-09-13 20:2x 实测已变为 43976fe「初始提交」，且仅 1 条提交），但工作树有 20 个未提交文件（orchestrator.ts / crash-policy.ts / proxy.ts / spawner.ts / config.ts / web/*.html / test/* …），导出里因此混入了别人未完成的改动；同时新增了需脱敏的标识（'dsh-plugin-mcn-suite'）触发探针。发布前必须二选一：① 把导出改成按 commit 取（git archive <commit>，才是"冻结版本"）；② 或明确接受"含未提交工作"并每次重建后重跑探针（新增插件名/内部名会随别人提交冒出来）。
• ⚠️（知识库侧，非本技能职责）：本机 .workbuddy/skills/dsh-instance-diagnose/ 尚无归档副本；INDEX.md 只登记了 3 个 skill（dsh-knowledge-upkeep 未登记）。属既有漂移，未擅自修。

---

28. 🔴🔴 archify 出不了 SVG ⇒ README 内嵌静态图只能手工绘制，且验收只剩「目视」（2026-09-19 实测）—— · ⛔ archify render architecture in.json out.svg 直接失败：output/cli-extension —— "CLI output must target a .html file." ⇒ README 里 <img src="diagrams/xxx.svg"> 那种可内嵌静态图，archify 帮不上忙；必须手工画。 · ✅ 现有两张（architecture / architecture-cluster）本来就是手工的：6 KB 级、纯系统字体、无外链、不内嵌字体； ⚠️ 而 archify 产物是 790 KB 级（内嵌字体）—— 两者不是一个量级，别混。 · ✅ 照抄既有风格（一次过、不必试错）：同一套 <style>（.h1/.sub/.sec/.lbl/.chip/.box/.ln）＋ 同一调色板 （#0969da 控制面 / #1a7f37 实例 / #8250df 可选通路 / #fff8c5 横切栏）＋ viewBox="0 0 1180 …" ＋ 外层 rx=14 的 #f6f8fa 底板。 · 💡 落笔前先估文字宽度（省一轮返工）：CJK ≈ 1×字号 px，拉丁 ≈ 0.51×字号 px；本轮最宽一条 812 px，画布 1180 − 起点 64 = 1116 px 可容 ⇒ 一次过。 · 🔴🔴 SVG 不被任何探针覆盖（_check_parity.mjs 只比 EN/ZH 图数与文件名，不看内容）⇒ 验收只剩两条： ① XML 可解析（ElementTree.parse 不抛）；② 渲染成 PNG 逐张目视看有无文字溢出/压字。 · ⚠️ agent-browser open 在本机会挂死（实测两次：SIGTERM、零输出）⇒ 改用 Chrome 无头一次性出图：

    "/c/Program Files/Google/Chrome/Application/chrome.exe" --headless=new --disable-gpu \
      --hide-scrollbars --no-first-run --user-data-dir="E:\_tmp_chrome" \
      --window-size=1200,700 --screenshot="E:\_tmp_zh.png" "file:///E:/…/zh.svg"
    

    再用图像能力实读该 PNG（这一步不能省 —— 没有任何工具替你看了）。
29. 🔴 删/搬章节必须两侧复查：出站链接 + 指向本节的锚点（2026-09-19 实测断了 2 条）—— 把一个文档瘦身（内容搬到新文档）时，落在被删小节里的标题锚点会悬空，而链接写法是 file.md#锚点 ⇒ 页面照常打开、跳转静默失效。 本轮实例：README → manual/project.zh-CN.md#项目如何建成 与 README.md → manual/project.md#how-this-project-is-built（锚点随小节删改而失效）。 ✅ _check_links.mjs 抓到了 —— 这是本轮唯一一次「门禁替我发现了错」。 ⇒ 动作：动结构之前先 grep 引用 grep -rn "project\.zh-CN\.md#\|project\.md#" _overlay/ dsh_ai1net/；改完再跑 _check_links.mjs。 ⚠️ 配套：同一次搬动里若提升了标题层级，下面的子标题要跟着升（本轮 # 项目如何建成 → ## 协作… 之下 6 个 #### 成了 H2 下跳 H4）⇒ 判据 grep -c '^#\+ ' EN == ZH。 ➕ 2026-09-20 扩充 —— 删内容也一样要「两侧复查」，且要多查两处： ① 表头/第一列的先行词：删掉表前的引导句后，该做的工作 / That work 这类表头会失去指代（实战：删掉「本项目走第三条路…承担宿主该做的工作」＋整张表，表头必须一起消失）； ② 版本历史条目里的引用：### v1.4.x 条目常复述「这次改了什么」，删正文会让那些复述变成死引用（实战：v1.4.1 条目里「为什么自己托管是第三条路」/why hosting it yourself is the third option 两处）。 ⇒ 手法 = 只删指向已删内容的从句，⛔ 不动「该版本做了什么」的主体；改完跑一遍残留词扫描（把被删词当 pattern 全仓 grep，判据 = 0 命中）。 ③ 🔴🔴 用户点名删 A 时，⛔ 不要扩大到自认为「同一类」的 B（2026-09-20 实战教训）—— 用户说「本项目走的第三条路 太细节了诊断都可以去掉」⇒ 我当成「去掉诊断式论证」，把三段全删了； 用户随即纠正「是不是删除多了…感觉你把这段话前面也改了」⇒ 实际要点只是 那一句 ＋ 紧邻的那张表。 🔑 判据：先确认「X」的粒度是段、是句、还是表；拿不准就只删被点名的对象（承台账 §4「只做被明确要求的事」）。
30. 🔴 「别动版本号」时的正确做法（2026-09-19 用户原话「除了版本号不要动，其他的按正常规范来调整」）—— 把变更追加进 README/README.zh-CN.md 里当前版本（### v1.4.1）的小节，不加新版本小节、不改 package.json 的 version、不换徽章。 ⚠️ 且不要写"发布记录"文件 —— 它不是一次版本发布，写了反而制造一个假事实。 ✅ 提交信息仍按既有形态（docs: …），不升版本的操作与 docs: 前缀是配套的。
31. 🔴🔴 说明文档「去 AI 味」：真正的指纹在英文侧，通用检测器抓不到，且它给的分数不可采信（2026-09-19）—— · 用户原话：「现在写的说明文档一股 ai 味」「让你别写 dsh 是给个人用的，还在写」。 · 🔴 中文检测器答不了这个问题：本轮对 13 份 *.zh-CN.md 跑 qu-aiwei-zh 的 scan_ai_flavor.py（该检测器 2026-09-20 已归档，见坑 32）， 命中只有 10 处，其中 3 处是清单里的真实文件名（104-覆盖网络-全球架构复盘 这类，⛔ 不可改）、 4 处是技术用法（对齐依赖范围 / 注册 → 审核 → 登录闭环）、真正的黑话只有 2 处（抓手 / 完整闭环）。 ⇒ 又一次验证「别用关键词扫描判断，必须逐条读」（承 §4 内容口径第 1 条）。 · 🔴 AI 味的真指纹在英文侧 + 跨语言的结构习惯（中文词库覆盖不到），按权重排序： ① 破折号密度（第一指纹）：— / —— 被当成「补语气的连接符」滥用 —— 实测 PLUGIN-PORTING.zh-CN 66 处 ——、 README.zh-CN 64 处、README.md 66 个 —、PLUGIN-PORTING.md 81 个； ② 加粗过密：PLUGIN-PORTING.md 354 个 **…**、README.md 130 个 —— 加粗只该标决策点，不是每个名词短语； ③ 标语式短句（One command installs it; a browser operates it.）； ④ 主题式报幕（This project is the third path: / The two obvious ways out both cost something. —— 先报结构再给内容）； ⑤ 先让步再转折（That is the right shape for a local tool, but …）。 ⇒ 与用户已定的「直入主题」是同一条要求的两面。 · 🔴 检测器分数不可采信：qu-aiwei-zh（已归档）用 structural -= N 把结构扣分记成负数，而总分算 100 - (lexical + structural) ⇒ 结构扣分反倒加分，13 份全被顶到 100（修符号后均值 86.4）。另其 无第一人称 -8 / 无数字 -12 对技术文档是假信号（技术文档本就无第一人称）。⇒ 只采信命中明细，不采信分数。 · ✅ 本轮已做（14 处）：把「个人定位」改成「安装形态」—— ⛔ 不写面向人群（单用户 / 本机单用户 / one person on one machine / local tool）， ✅ 只写安装形态：一个进程、一个 profile、一个数据目录、没有第二个用户这个概念 / Nothing in it models a second user.。 判据 = 「这句在描述『谁用它』，还是在描述『它装成什么样』」；前者一律改写。 落点：README{,.zh-CN} 各 4 处 · manual/architecture{,.zh-CN} 各 3 处。⚠️ 改完复核 grep = 0 命中。 · ⏳ 未做（待拍板）：破折号 / 加粗 / 句式三层清洗涉及 24 份文档 > 批量红线（10 份） ⇒ 必须先出受影响清单并取得确认。 ⛔ 不要自行铺开 —— 清洗会碰到用户自己定的措辞（「隔离落在内核边界上」「身份先于地址」），那是口味不是错误。 · 🔴🔴 第三级判据：语域（register）—— 两级检测器都看不见，只能人读（2026-09-20 用户当场点破）—— 用户原话：「你下载的文档和去ai味用上了吗」「看看你写的 插件有候选池 启用是用户自己的事，这些话是给人看的吗，懂不懂怎么亲切友好的和人沟通」。 · 实测：同一段文字改前改后跑 scan_ai_flavor.py 都是 92/100「🟢 人话」、命中 0，lint_copy_rules.py PASS （两个旧检测器与 shuorenhua 均已归档；结论不受影响 —— 换任何工具都一样看不见语域） ⇒ 工具按定义就答不了这一问：它查的是词面黑话与结构模板，而这里坏的是 「这些话是说给谁听的」 —— 写成了运维工单，不是说给要用它的人。 · 🔴 病征四条（都属语域，不属词面）：① 冷 / 端着（开门之前先验证来人 这类武侠腔，把读者推远） ② 把读者当第三方（启用是用户自己的事 / 通篇第三人称「用户」讲读者自己的事 ⇒ 读成「不关我事」） ③ 术语裸奔（候选池 直接搬出来，不说它替读者省了什么）④ 没有对象感（技能也能自己管 —— 五个字，读者拿不到信息）。 · ✅ 改法四条：① 粗体标题写「读者得到什么」，不写「系统有什么」（插件有候选池，启用是用户自己的事 → 插件不用你自己去找） ② 上「你」（⚠️ 已被推翻，见坑 33 第 4 轮：用户 2026-09-20 明令「把所有的你都改为用户」， ⇒ 正解是点名主体（平台管理员 / 用户），⛔ 不是上第二人称，也 ⛔ 不是换成「自己」）③ 口语动词（删除 → 删掉、启停 → 想用哪个开哪个、建号 → 建得起来） ④ 保留项目词，但落到好处上。 · ⚠️⚠️ 流程教训（比结论更重要）：「装了工具」≠「用上了工具」。本轮改了多轮文档，一次都没跑那两个旧检测器， 直到用户问「用上了吗」才跑 —— 而一跑正好暴露「工具答不了这一问」。 ⇒ 动作：写完任何面向用户的段落，先按当前工具（humanizer-zh 的 24 条模式 + 6 条检查 + 5 维评分）过一遍留下记录， 再自己通读一遍问「这话是说给谁听的」。两者都要，且顺序不能倒。 · 📌 可复用工具：humanizer-zh —— 2026-09-20 起用这一个，见坑 32。⚠️ 中英都只有中文模式清单；英文侧另可借它的 #3 -ing 肤浅分析 / #13 破折号 / #16 标题大小写 / #18 弯引号四条（本就来自英文原文）。
32. 🔴 去 AI 味工具几经更换，当前是 humanizer-zh；⚠️ 工具重要，但「挂在必然加载的位置」更重要 —— · 🗄️ 已被用户判定淘汰并归档的三个：de-ai-flavor / qu-aiwei-zh / tech-doc-style-chinese ⇒ 整目录移到 E:\ProgramData\AI技能\_skill_归档_去AI味_20260920\，移回即还原。 淘汰理由：旧的是「按模式扫 AI 味 + 打分」，但检测器分数不可采信（qu-aiwei-zh 结构扣分记成负数 ⇒ 总分反倒加分，见坑 31-②）。 · 🗄️ shuorenhua（说人话）也已归档（2026-09-20，用户原话：「感觉 shuorenhua 这个技能有作用吗」→「shuorenhua效果一般可以删除」） ⇒ 与上面三个同放 _skill_归档_去AI味_20260920\shuorenhua\（4 文件，含 references/）。 淘汰理由 = 9 轮实做的诚实结论： ①⚠️⚠️ 它是纯提示词技能（三份文本、无脚本、无检测器，还明令不许输出评分/命中清单/判定链）⇒ 「用」= 把约束读进上下文、然后还是我自己写 ⇒ 装上与没装，产出看不出差别，效果不可验证。 ②🔴 它覆盖不了用户实际抱怨的四件事：语域（说给谁听）· 人称（你/自己）· 同义重复句 · 指代（这把/那块）—— 8 轮反馈里没有一条是它解决的。它那条「删除完整重复的内容」要求「必须能在保留部分找到同一内容的完整表达」⇒ 对「放行只有管理员能做」这种换词复述判据够不着。 ③⚠️ 它的词面动作针对黑话/包装语，而本项目中文侧实测只命中 10 处、其中真黑话 2 处 ⇒ 命中率极低， 叠加它自己的「没有明确编辑收益就不改」⇒ 多半直接返回原文。 ④🔴🔴 最硬的证据：8 轮里一次都没主动加载过它（只有用户点名叫用那一次读了）。 ✅ 它唯一该继承下来的是保真约束（不许换同义词、不许概括、不许补事实、代码块逐字、数字版本路径按原文） —— 恰好治本项目踩过的「删多了」（承坑 29-③）⇒ 该条已并入坑 31 的复核动作，⛔ 不再依赖外部技能。 · ✅ 当前工具：humanizer-zh（https://github.com/op7418/Humanizer-zh.git，MIT，作者 歸藏；2026-09-20 用户指定） ⇒ 已装到 ~/.workbuddy/skills/humanizer-zh/（只放 SKILL.md + README.md + LICENSE 三个文件；仓库本体就这 3 个 + .gitignore，无 automation/、无 evals/）。 · 🔑 它为什么比 shuorenhua 强：24 条模式全部带「需要注意的词汇」＋「改写前/改写后」对照，另有 6 条快速检查清单与5 维 50 分评分表（直接性 / 节奏 / 信任度 / 真实性 / 精炼度）⇒ 可核对、可留痕， 而 shuorenhua 连分都不许打。来源是维基百科 [Wikipedia:Signs of AI writing]（WikiProject AI Cleanup， 观察自维基上数千个 AI 生成文本实例），不是拍脑袋总结。 · 🔴🔴 它的模式清单恰好命中了本项目 8 轮里出现的每一类问题 —— 这是选它的真正理由： #9 否定式排比（「不仅…而且…」「这不仅仅是关于 X，而是 Y」）＝ 用户禁的「不是 X，是 Y」； #11 刻意换词（同义词循环）＝ 本项目的术语漂移（模型共享/共享模型/共享 key/共享 env）； #13 破折号过度使用＝ 英文侧实测 66 处 —、PLUGIN-PORTING.zh-CN 66 处 ——； #14 粗体过度使用＝ PLUGIN-PORTING.md 354 个 **…**； #15 内联标题垂直列表（- **标题：** 说明）＝ 本项目文档的默认形态； #1 夸大象征意义 / #5 模糊归因 / #7 AI 词汇表 / #22 填充短语 / #24 通用积极结论 同理。 · ⚠️⚠️ 但它有四条模式与本项目「有意采用」的风格冲突 ⇒ ⛔ 必须逐条判定，不许无差别执行： #14 粗体（用户明确要「加粗只留跳读关键词」）· #15 内联标题列表（用户明确要表格形态）· #17 表情符号（👉 指路是刻意的，不是「每个标题都装饰」）· #16/#18（中文不适用，它自己也注明了）。 ⇒ 判据 = 这个加粗/这条列表/这个 emoji 是在帮读者跳读，还是在扮演「显得很全面」。 · 🔴 它同样答不了的两件事没变：语域 / 语态（这话是说给谁听的）与 点名主体 ⇒ 坑 31 第三级判据与坑 33 照旧。 · 🔴🔴 两语言各用各的（2026-09-20 用户定）：中文 → humanizer-zh（24 条模式 ＋ 5 维 50 分评分表）； 英文 → humanizer（55 条模式 ＋ humanizer-metrics CLI）。⛔ 不要交叉用 —— 实测英文版的分词器只认拉丁字符， 中文分数是噪声（详见坑 35）。⇒ 原待办「给中文侧补分词器」据此作废，不再上抛。 · 📌 中文侧实测（15 份 zh-CN 文档，见 _中文侧测评_Humanizer-zh_20260920.md）： ① ✅ 词层面已干净 —— P1 夸大象征 / P3 -ing / P4 宣传语 / P5 模糊归因 / P6 挑战展望 / P8 系动词回避 / P19 协作痕迹 / P20 知识截止 / P21 谄媚 / P22 填充 / P23 过度限定 / P24 通用积极结论 全部 0 命中； P10 三段式 0（三项并列全是真实枚举）；P2 不适用（引用的是实际依赖不是「被谁报道」）。 ② 🔴🔴 唯一大宗项 = P13 破折号 —— 共 206 处（PLUGIN-PORTING 69 · highlights 44 · project 26 · …）， 绝大多数是同一个句式 **加粗术语** —— 说明（同时命中 P13 ＋ P15）。 🔑 判定必须分开：加粗与列表本身是对的（用户要「加粗只留跳读关键词」、要表格与可扫读形态）⇒ ⛔ 不动结构； 该动的只有破折号 ⇒ ✅ 最小改法 = —— 换成 ：，信息与结构 100% 保留。 ⚠️ 例外：COMMERCIAL-LICENSE 表内 轨 1 —— AGPL-3.0 是分栏分隔，换冒号会混淆 ⇒ 逐条看。 🔴 与英文侧同源：英文 P13 是零容忍（U+2014），实测英文 66 处 —、中文 206 处 —— ⇒ 两侧应同批处理。 ③ 🔴 P9 否定式排比 6 真命中 ＋ 2 假阳性（PLUGIN-PORTING 3 · architecture 2 · examples 1 · project 1）； 假的两处是「不只是」作范围限定（「不只是你先发现的那一个」）⇒ ⛔ 不是修辞排比。 ④ 🔴🔴 机械扫既虚报也漏报，两遍都要做：虚报见 P12「虚假范围」3 处全假（「从提交到出现在启用列表」是真范围）； 漏报见 README 的 4 处倒装形式（「…而不是各用各的」「关掉直连不是功能降级」）—— 正则 不是…而是 抓不到倒装与孤否定 ⇒ 🔑 回读时要补一个「倒装 / 孤否定」的视角，否则会误判成 0 命中。 ⑤ 它的分不是门槛是定位：README.zh-CN.md 实测 36/50（直接性 7 · 节奏 7 · 信任度 8 · 真实性 8 · 精炼度 6） —— 落在「良好」区间下沿、离「需重新修订」只差 1 分；价值在于指出扣在哪两个维度（精炼度 6 ／ 直接性 7）。 🔑 两法互证：精炼度 6 ↔ 巡检 P2-2 同义重复 5 处 ＋ P2-6 版本历史 5 条；直接性 7 ↔ P2-1 排比 4 处；信任度 8 ↔ P2-5「候选池」未解释 ⇒ 这 4 条不是口味问题，是真问题。 ⑥ ⛔ 不许按它的「个性与灵魂」段给技术文档加第一人称/幽默 —— 与已定口径「点名主体」直接冲突。 · 🔴 安装前做过安全审查（承系统规则）：结论 ✅ Benign · 100 分 —— 全仓仅 4 个文件、三份纯文本， 无脚本、无网络、无文件操作、无 prompt 注入话术、无硬编码凭据、无依赖安装。 SKILL.md 的 allowed-tools: Read/Write/Edit/AskUserQuestion 只是声明能力、不自动执行 ⇒ 按判据 「skill 会自动执行吗」= 不会，不构成投毒面。README.md 里的 npx skills add … 是写给用户手动跑的安装说明， 不由技能执行 ⇒ 同样不算风险项（审计报告另存）。 · 🔴🔴 三轮换工具的元教训（比工具本身重要）：prompt-only 技能在实做里会被跳过 —— 除非它挂在「必然加载」的位置。本项目真正每轮生效的只有两处： dsh-opensource-release（按工作区绑定 ⇒ 必然加载） ＋ 用户写进 MEMORY.md 的判断方法。 ⇒ 所以任何新工具，必须把它的可执行条目摘进本技能，⛔ 不要指望「装了就有人去读」。
33. 🔴 同一段读者文案被多轮口径叠加改写时，每次都要回读整段（2026-09-20 实战，八轮叠加）—— · 第 1 轮：「标题语态应该是 解决了 xxxx / 增加了 xxx / 改善了 xxx 这样的」⇒ 我给 7 条标题各加了结果动词； · 第 2 轮：「改完后再把标题 xx了 这几个字删除就对了」⇒ 动词前缀全删，标题回到纯名词短语； · 第 3 轮：「注册验证可以去掉，这个是基础不是这个项目特有的」⇒ 删条目并把 3–7 重编号（7 条 → 6 条）； · 第 4 轮：「把所有的 你 都改为 用户」⇒ 中英两侧共 18 处人称改写（与上一轮「上『你』」的语域修正是反向的）； · 第 5 轮：「没有提现这个功能亮点，想想为什么要这么设计有什么好处」⇒ 🔴 亮点不在措辞里，在源仓的设计注释与档案里（见坑 34）； · 第 6 轮：「刚去掉一个『你』，又整一堆『自己』」⇒ 🔴 人称代词被否之后，⛔ 不许换另一个代词顶替 —— 「自己」等于把主体又抹掉了。✅ 点名主体：平台管理员 / 用户 / 管理员（判据 = 这句能不能答出「谁做的」）； · 第 7 轮：「不要那把 这把，避免用这些代词，改为 管理员配置的模型共享，多简单明了」⇒ 🔴 点名主体之后，还要把「指代」也换成名词 —— 那把凭据 / 平台那份额度 / 设置页里这块 / 候选池的那些 / 上传的那份 一律换成具体名词； 顺带清同列表里的同类（只有管理员挑进候选池的插件 / 用户上传的技能）。 🔑 判据 = 这一个分句单独摘出来，能不能答出「谁做的、说的是什么」。 ⚠️ 反身用法指物时保留（各有自己的 OS 账号 · 跑在自己的硬件上 · 平台自己写凭据 · 由节点自己在本地判定）—— 判据是「这个词指人，还是指物」。 · 第 8 轮：「由管理员确定给那位用户开启， 去掉 只有管理员能做（这不废话吗）」⇒ 🔴🔴 同义重复句必删 —— 前一分句已经交代的约束（「给谁用由管理员放行」），⛔ 不许在后一句换个说法再说一遍（「放行只有管理员能做」）； 这种句子把「谁能做什么」这层信息说空了。✅ 并成一句、主体提到句首：由管理员确定给哪位用户开启。 🔑 同轮顺带统一用语：没被放行的人 → 未开启的用户（一处「放行」一处「开启」会让读者以为是两条路径）。 ⚠️ 本轮教训：中文先改、英文滞后一轮 ⇒ 每次「改标题 / 改条目」必须中英两侧当场一起改完再回话， 否则 parity 靠同层结构还能过（28/28 · 75/75 照样绿），内容却已经不同步，而没有任何门禁能发现。 · 🔑 判据：把「① 标题形态 ② 人称 ③ 留哪些条目 ④ 亮点来源 ⑤ 删同义重复」当成五件独立的事，⛔ 不要假定上一轮定下的写法仍然成立； 每轮改完立刻回读整段（本轮就是靠回读才发现「结果语态」与「第二人称」两轮修正在互相抵消）。 · ⚠️ 人称改写的两个例外（⛔ 不许机械替换）：① 命令行占位符（--email [email protected]）是人称之外的字面值，改了会坏文档； ② 英文侧不能词对词替换，⛔ 也别把 your own 直译成 a user's own（一样把主体模糊掉）； 要按句子重写成点名主体：your own → the skills a user uploads · you switch on whatever you want → users switch on what they need。 ⇒ 改完必须 grep 复查（中文判据 = 你 0 命中；英文判据 = 仅剩占位符那一处）。
34. 🔴🔴 要求「体现亮点 / 为什么要这么设计」时，理由去源仓找，⛔ 不要自己写（2026-09-20 实战）—— 用户：「没有提现这个功能亮点，想想为什么要这么设计有什么好处」。 · 🔑 动作：拿条目对应的功能名当关键词搜源仓，读设计档案（dsh-server-docs/04-调整方案/NNN-*.md）的 §TL;DR 与代码里的「为什么」注释（src/db/schema.ts 的迁移块、src/web/server.ts 的函数头）—— 亮点与理由都写在那里。 · 📌 本轮实证：共享模型那条的真亮点 = 「两列两人」（granted 归 admin ∧ enabled 归用户 —— 若共一列，用户自己点一下就把自己授权了 ⇒ 门禁形同不存在）＋ 失败关闭 ＋ 未授权则设置页整块不渲染； 插件那条的真亮点 = 只导预构建产物、平台侧不跑第三方构建脚本。 ⚠️ 这两批事实原句一个字都没有 ⇒ 「写不出亮点」通常不是文笔问题，而是没去读设计。
35. 🔴🔴 humanizer（英文版）可用、但它对中文的分数是噪声；--check-facts 才是本项目第一个可执行的保真门禁（2026-09-20 实测）—— 用户：「https://github.com/Aboudjem/humanizer-skill.git 这是英文版本」。 · ✅ 装了什么：①技能 ~/.workbuddy/skills/humanizer/（SKILL.md 39,490 B ＋ README.md ＋ LICENSE ＋ references/{patterns.md, patterns.zh.md, always-on-templates.md}）—— 只取 skills/humanizer/ 子树， ⛔ 不取 evals/（开发材料）、⛔ 不取仓库根的 AGENTS.md；②可选 CLI（零运行时依赖）另放 E:\ProgramData\AI技能\_tools\humanizer-metrics\（index.js ＋ lib/*.js ＋ package.json），⛔ 不取 test/ 与 package-lock.json。 🔑 它是 humanizer-zh 的英文母本：55 条模式（P1–P55，六大类）＋ 5 个 voice ＋ 3 个 mode ＋ 分级词表（Tier 1A/1B/2/3）。 · ⚠️⚠️⚠️ ⛔ AGENTS.md 是个陷阱：它的文件头自述「Auto-discovered by Claude Code, Cursor, Copilot, Codex CLI…」 ⇒ 把仓库根整体拷进任何 skills 目录 = 带进去一个会被自动读成指令的文件。判据：只取 skills/<name>/ 子树， 并在装完复查 skills 目录内 AGENTS.md/CLAUDE.md/SOUL.md 命中 = 0。 · 🔴🔴 中文侧不可用 —— 指标在测「文件里有多少拉丁字符」，不是 AI 味（读 cli/lib/tokenize.js 确认根因）： splitSentences 用 .split(/(?<=[.!?])\s+/) 只认拉丁句末标点 ⇒ 中文 。！？ 永不切句 ⇒ 整篇算 1 句； wordTokens 用 .match(/[a-z0-9][a-z0-9']*/g) 只认拉丁词 ⇒ 汉字产出 0 个词。 📌 对照实验（同一段内容）：纯中文＝ words:1 sentences:1 → 28/100（只数到 NAT 一个词）｜ 。 换成 . 结果完全不变 ⇒ 中文根本没进指标｜纯中文零拉丁字符 ⇒ words:0 sentences:0，判语直接是「No text」｜ 同内容英文 ⇒ words:56 sentences:4 → 8/100。 ⇒ 对中文，分数 ≈ 28 分固定惩罚（单句 ⇒ burstiness=0） ＋ 内嵌拉丁标识符带来的词表/重复分 ⇒ 那张「中文 20–70 / 英文 0–11」的表，测的是该文件内嵌了多少英文术语、命令与路径 （故 archify/README.zh-CN.md＝70〔157 words 全是拉丁〕、faq.zh-CN.md＝46、security.zh-CN.md＝31）。 ⚠️ 它自己的 Guardrails 写着「Short samples are unreliable. Under about 40 words there is not enough signal to score. Say so instead of guessing.」—— 它本该在中文上直接说「信号不足」，但没有语言检测。 ⇒ 🔴 铁律：中文侧只当「模式清单」人工对照，⛔ 不采信它的分数，⛔ 不采信中文的 fleschKincaidGrade（20 分文件报 45.6）。 · ✅ 英文侧可靠：本项目 README.md 实测 6/100 Pristine（burstiness CoV 1.313、AI-vocab tells 1、MATTR 0.818）、 manual/security.md 0、manual/project.md 1 ⇒ 反向证明前 8 轮改动确实把英文侧磨干净了。 · ✅✅ compare --before … --after … --check-facts 语言中性，定为本项目改动后的必跑项 —— cli/lib/facts.js 抽的是硬 token（数字 / 日期 / 版本 / URL / 路径 / 标识符），这类内容中英同形。 📌 拿它复核第 1–8 轮是否丢事实（_备份_README_结果语态_20260920/ → 现文件）： README.zh-CN.md All 93 fact(s) survive ✅ ｜ README.md All 90 fact(s) survive ✅（退出码 0） ⇒ 这是本项目此前没有任何工具能给出的结论。 用法：node index.js compare --before <旧> --after <新> --check-facts（丢事实则 exit 1）。 · ⚠️ ⛔ 不要安装它的 .pre-commit-hooks.yaml：entry: cli/index.js scan . --fail-above 40 ⇒ 会把「分数 > 40」变成提交拦截，而本项目文档天然超线（且中文侧超线还是假信号）。 · ✅ 它的 Guardrails 正解了上一轮的顾虑：SKILL.md 有 ## Guardrails: what NOT to flag, and what to preserve， 明文反对过度编辑（A ruthless editor who over-edits is worse than no editor: it launders a real person's voice…）： 按簇判定不按单点（Flag a pattern only when several co-occur in the same passage.）· 引文/标题/代码/示例一律不动 · 专业术语重复是正确的（do not "vary" useEffect into "the effect hook" for elegance）· 短样本（<40 词）不可靠 · 低句长方差 ≠ AI（自闭/ADHD 写作者天然低方差）· 非母语写作者会被检测器过度标记（引 arXiv:2304.02819）· 要保护：难编造的具体项 / 矛盾未决的感受 / 第一人称体感细节 / 时代性圈子用语 / 刻意瑕疵 / 2022 年底前的内容。 ⇒ 判据从「这个加粗是在帮忙还是在装全面」升级为「是否成簇」。 · ✅ references/always-on-templates.md 值得吸收：给出把核心规则常驻到 agent 指令里的写法 ⇒ 正解坑 32 那条「prompt-only 技能会被跳过」的老问题（本项目仍以本技能为常驻落点）。 · 🔴 安全审查结论（承系统规则）：✅ Benign · 100 分。⚠️ 与 Humanizer-zh 不同，本仓库有可执行代码，故逐项做完五类扫描： child_process 5 处全在 cli/test/（运行时零命中）· fs.writeFileSync 只写 --baseline 显式指定的路径 · 59 处 URL 全是元数据/文档/example.com 测试夹具/arxiv 引用，无任何请求代码 · 依赖只有 devDeps.eslint · 硬编码凭据 0 · 注入话术 0 · tools/demo.sh 逐行读完＝纯 printf 动画。 ⚠️ 一条正常能力但已登记：SKILL.md:132 会自动读当前工作目录的 humanizer-context.md（品牌口径/禁用词），不读敏感路径、不外发。
36. 🔴🔴 「巡检表」是自己的草稿，⛔ 不是事实源 —— 凡改「计数 / 枚举」必须回定义处核对（2026-09-20 第 9 轮实测）—— 用户：「按照你的方案优化，要确保中文英文内容一致」⇒ 授权把第 9 轮 21 条巡检整批落地（不是分轮挑着做）。 · 🔴🔴 差一步按草稿改错数：巡检 P1-4 的建议是「L231 改七个失败模式、把第 7 条并入表」。 落地前回源文档核对 ⇒ PLUGIN-PORTING.{md,zh-CN.md} 早已是 H1~H8 = 八个失败模式 ＋ 六条规范（R-a~R-f）。 ⇒ 按源文档对齐成 8 行表（补 H7 客户端半边静默挂死 / H8 原生绑定要求更新的 glibc）， 并把收尾指针里的「五条改造规范」一并去计数。若照草稿写成「七个」，就新造了一处与文档打架的错。 🔑 判据：README 是二手转述，定义在源文档 —— 凡要动「几个 / 几条 / 第几条」， 必须回到定义处核对（本轮 = PLUGIN-PORTING.* 的 ## 2. 与 ## 3. 标题）。⛔ 「我上次写的清单」不构成依据。 · ✅✅ 可复用的落地方式：精确串替换器（本轮 _中间产物_待清理/_apply_round9.py）—— 每条规则 = (old, new)，先全局数命中次数、要求恰为 1，任一不中就整体中止、不落盘； 行级删除按「行首前缀」匹配并同样断言 1 次（长段 bullet 用前缀删，避免逐字重打长串）。 ⇒ 比逐次 Edit 可靠（一次核对全部锚点、不会改到一半）、比 sed/bash heredoc 安全（非 ASCII 不会被悄悄改写，承事故 #31）。 跑完必须 grep -c 复核旧串 = 0，再比字节数与行数的预期差（本轮 6 文件：中文 −1562 B / 英文 −1917 B，行数各 −9）。 ⚠️ 写脚本前先 diff -u 备份与现文件的精简摘要（只打 ^[+-] 前 96 字符）核对改动面 —— 全量 diff 会被长表格行淹没。 · 🔴 「索引类章节不写死计数」是已定口径，且要连指针一起清：本轮清掉文档地图 3 处 ＋ 收尾指针 1 处。 ⚠️ 但括号里的枚举保留（隔离 · 自愈 · 插件治理 · …）—— 那是指针的坐标，不是计数。 · 🔴 搬内容优先于删内容：版本历史里 5 条讲的是「文档自己怎么改的」（用户无感）⇒ 我选 搬到 manual/contributing.* 而非删掉，判据 = 该文档在文档地图里的描述本就写着「版本号与发布历史」 （搬过去名实相符，信息不丢）；README 只留用户可感的行为变更（v1.4.1 只剩 503 冷启动 ＋ 整理两条）。 · 🔴 历史条目里的旧名 ⛔ 不要改：manual/project.* 有 3 处「功能管理」，是当时那次改名事件的历史条目名 （60-…功能插件改功能管理 / 67-功能管理section按UI规范重做 / 100-…并入功能管理分组）⇒ 改掉等于篡改历史。 要改的只有 README / FAQ 里的现名（现名 = 能力管理 / Capability management，源仓条目 101-能力管理-改名与tab分页与卡片三列）。 判据：同词两义先看它是不是「历史记录里的引用」。 · 🔴 在文档地图里加一行会动 parity tableRows：本轮 75 → 78（地图 +1、PLUGIN-PORTING 表 +2）， 中英必须同增（78/78），否则门禁红。 · ⚠️⚠️ 换行口径修正（此前记的「CRLF=0」是只看了 .md）：导出仓工作树有 52 个文件带 CRLF （src/** · web/*.html · *.json · scripts/*.sh）—— 那是 core.autocrlf=true 检出造成的既有状态， 与 _overlay（Python 以 LF 写入）无关、不进 git blob。⇒ ⛔ 别误判成换行污染、⛔ 更不许顺手批量转换（承「批量换行转换」禁令）； 验收只报「本轮改动的 N 个文件 CRLF = 0」。 · 🔴🔴 换行陷阱（同轮 git blob 实测出来，下次必踩）：dsh_ai1net/.gitattributes 只钉三行 （LICENSE / COMMERCIAL-LICENSE.* 为 -text，法律文本逐字节原样），*.md 不在其内 ⇒ 走 core.autocrlf=true。 ⇒ _overlay/*.md 恒为 LF，而导出仓的 *.md 一旦被 git 重新检出（git checkout / 切分支 / 全新克隆到同路径）就变 CRLF ⇒ _sync_overlay.py --check 的逐字节比较会假报「有差异」（内容一致；git status 反倒干净，因为 autocrlf 做了归一化）。 ⚠️ 危险动作：此时若为「消除差异」把导出仓的 CRLF 文件反向拷进 _overlay ⇒ 事故 #27 的反向版（把当前版灌进未来版）。 ✅ 正确处置：直接跑 python _sync_overlay.py（方向 _overlay → 导出仓，LF 覆盖回去）；git blob 里一直是 LF，公开内容不受影响 （2026-09-20 用 git cat-file -p HEAD:README.md 实测 blob 无 \r）。 📌 判据：「工作树有 CRLF」≠「换行被污染」—— 先看 .gitattributes 与 core.autocrlf 再下结论。 · ⏳ 同轮明确「不做」的两件事（都要单独授权，别顺手带上）： ① 破折号批量（中文 —— 206 处 / 英文 — 66 处，跨 ~15 份文档）—— 触「>10 文件」红线， 且不是机械替换：**加粗术语** —— 说明 这类该改 ：，而句中插入语式的真破折号要保留 ⇒ 必须逐处判断。 ② 代码注释里 4 处旧名（src/supervisor/orchestrator.ts:1222 / :1266 · spawner.ts:120 · web/routes/whitelist.ts:482）—— ⛔ 不许手改非 OVERLAY 文件，正解 = 加一条 LINE_REWRITE 规则，而规则变更必须整树重建（挪 .git · 清 PYTHONPATH · 三道闸门）⇒ 高影响面，单独确认。

---