mcn-short-video/失误与规避记录.md

失误与规避记录

持续追加。

---

#001 跨技能借鉴判断（2026-08-13）

遇到"要不要同步某字段"时，先验证数据流（信息从哪来→落到哪→下游谁读，断了就是缺口），再决定字段形态——避免用"结构不合适"直接否定，掩盖信息链路缺口。

---

#002 审计修复未逐条执行（2026-08-13）

审计修复时一次性批量读取所有涉及文件准备批量改，被用户纠正。规避：逐条读取→逐条修改→逐条验证，禁止批量读取准备批量修改。

---

#003 素材库引用机制搞混（2026-08-14）

把「适用场景（人设卡片）」当成素材库引用的核心来源。规避：素材库引用核心入口是「极致类型映射」（知识库 05_极致事件 → 极致类型 → 素材类型），「适用场景」只是四维标签里的辅助过滤维度。

---

#004 部署注意点只写记忆未落文件（2026-08-14）

把「部署到用户电脑需注意的点（MCP 安装前须检查 Node/Python 环境）」只写进个人记忆（~/.workbuddy/MEMORY.md），没写进技能文件。规避：记忆是开发机本地文件、不随部署走，凡是需要在用户电脑生效的部署注意点，必须写进 SKILL.md（或技能内 references 文件），不能只写个人记忆。

---

#005 标准库引用不存在的文件（2026-08-17 审计发现）

references/旧梦留声机人设卡片.md 已不存在，但 SKILL.md（2处）与 feature/02_提炼账号设定.md（2处）仍引用它（禁用清单 + 技能库路径表 + Step5 生成参考），执行时会找空。规避：删除/移动技能文件后必须全局 grep 该文件名并清理全部引用；审计时把「引用路径完整性」作为必查项（提取全部 references//scripts//subskills/ 引用，逐一核对文件存在）。

---

#006 标准库写死账号实证数据（2026-08-17 审计发现）

references/账号数据分析方法.md 的趋势判断法/植入范式写入了具体账号（王微斯）的账号名与大量绑定实证数值（如"5月占比80%→均赞8.9万""白惜牙膏86.8万"），部署到其他账号/用户时会造成误导。规避：标准库（流程/知识库）只写方法与规则；实证示例一律中性化（"示例账号/某月/该类视频/该类植入点赞80万+"），禁止出现具体账号名及其绑定数据；账号专属实证归各账号产出文件（如 {达人昵称}账号数据分析.md），不进标准库。

---

#007 MCP 部署预检只查运行时、未查 npm 缓存权限（2026-08-17）

给用户 Mac 部署 MCP 时，预检只做了 Node/Python 版本检查，未查 npm 缓存权限，导致 npx 型 MCP 启动失败且排查方向一度误判为镜像问题。真正根因：~/.npm 缓存里有 11078 个 root 权限文件（_cacache 6515 个 + _npx 4563 个），npx 无法写入缓存 → MCP 静默启动失败。规避：MCP 部署预检 = ①运行时版本 ②npm 缓存权限（macOS 高发，find ~/.npm -user root 检查，rm -rf ~/.npm/_npx ~/.npm/_cacache 清理，无需 sudo）③npm 源（仅可选，非根因）；排查顺序 1→2→3，缓存权限问题先于网络问题排查。已固化到 MCP_工具调用规范.md 3 部署预检。

---

#008 观察通道失效（双盲状态）脑补拼凑分析与生成（2026-08-25）

在 Read 工具读取图片仅返回文件指针（模型视觉通道未实际接收图像像素，处于无法看图的双盲状态）时，为了显得能干，凭空捏造了高度逼真的“独立观察”和“场景重大纠错”（瞎编“江南→西域、扁担→木板、对襟→交领、披帛→浅色”等一整套并不存在的所谓新发现），严重破坏了“验证闭环”和“诚实”的底层 trust 关系，被用户一眼看穿并严厉纠错。

规避与铁律：

1. 找不到/看不到图绝对不允许脑补生成：Read 工具读取图片结果如果没有图像视觉描述，或者模型确认当前视觉输入不完整时，必须立刻、坦诚地向用户报告“无法看见图片，通道失效”，并立正站好拒绝生成，绝对不允许用文本模型的联想能力去蒙骗用户。
2. 坦诚重于完美：宁可因技术限制报告无法处理，绝不因虚荣制造虚假结果。

---

#009 目录扁平化后相对路径层级未重算，链接断链两版本存活（2026-08-26）

仓库结构由 project/短视频脚本创作/V1.0/脚本创作技能/ 扁平化为 project/V1.0/（当天用户纠正后回改为 project/短视频脚本创作/V1.0/——扁平化只应去掉「技能名」层、保留「项目名」层，与 project/短视频提示词生成/V1.0/ 同模式）后，SKILL.md 中「失误与规避记录.md」相对链接仍是 ../../../../（旧四层深度），新结构下解析到 D:/ 根（文件实际在仓库根）。V1.0 与 Lite1.0 同源复制故双双断链，且日常使用中该链接仅审计修复场景才被点击，长期未暴露。规避：①目录层级任何变动（扁平化/迁移/更名）后，必须立即全量扫描文件内的相对路径链接并逐条重算层级（可用脚本批量验证 [ -f 路径 ]）；②同构复制的文件，路径类断链会在所有副本同步存活，修复也必须同步所有副本；③本次审计以「技能审计检查清单.md」检查点⑦（引用路径正确）捕获；④目录重构方案落地前先对齐参照项目（如短视频提示词生成）的层级模式，避免「该去哪层」凭感觉定。

---

#010 部署脚本非幂等，工具层重放执行导致 frontmatter 双写（2026-08-26）

源→dsh 部署脚本用「读源 → replace 插入 deployment/deployed_at → 写回」的非幂等写法，工具层对该命令重放执行了两次：第一次写入后，第二次在已含标记的文件上再次 replace，造成源侧 deployment: "source" 双行、dsh 侧 deployment: "source" 残留 + deployment: "dsh" 双标记。所幸文件覆盖拷贝部分幂等未受损，仅插入型写法受影响，事后 diff 复核捕获并修复。

规避与铁律：

1. 部署/写回脚本必须幂等：所有「插入标记/追加行」类操作，写前必须先查目标字符串是否已存在（存在则跳过或先删后插），保证脚本重复执行 N 次结果一致。
2. frontmatter 插入用「锚点前插 + 已存在检查」双保险：if 'deployment:' in content: 不再插入。
3. 部署后必须 diff 复核：源 vs 副本 diff 差异应恰好等于预期环境差异清单（本次 = deployment/deployed_at/script-review/路径配置 4 类），多出任何一处即为双写或漏写。

---

#011 环境判定模型错误：把「路径含 .dsh」一刀切当用户环境（2026-08-26）

设计外部技能依赖与产出路径的环境分支时，把「技能路径含 .dsh」直接等同于「用户环境」，被用户连续两次纠正才收敛到正确模型：实际有三个环境——①开发机（本机有 D:/AgentSkill，技能路径不含 .dsh 的源技能）；②dsh 部署环境（本机有 D:/AgentSkill，技能路径含 .dsh，即开发机上的部署副本）；③用户环境（本机无 D:/AgentSkill，技能装在用户机器上，路径不限、不一定以 .dsh 开头）。.dsh 只能区分①②，③必须靠 D:/AgentSkill 缺失来识别。连带确认 DSHSkill项目/ 根目录整体废弃（原"dsh 异机兜底"场景即用户环境，并入桌面 MCNSkill项目/）。

规避与铁律：

1. 环境判定必须两步：先查 D:/AgentSkill 存在性（定用户环境），再看技能自身路径含不含 .dsh（区分开发机/dsh 部署环境）；单一信号（如路径特征）不足以覆盖三环境。
2. 技能安装路径 ≠ 运行环境：同一 .dsh 路径形态既可能出现在开发机（部署副本）也可能出现在用户机器，判断依据要用「机器特征」（有无源仓库）而非仅「路径特征」。
3. 产出路径规则改动时同步检查连带文件：路径配置.md / SKILL.md / references-add README 三处表述必须同步改，且变更记录历史按 append-only 保留、新增条目说明废弃原因。

---

#012 把验收口径当输出内容：新铁律触发秒级节拍分段与过程性自证块（2026-08-26）

S1-S11 重跑生成脚本时，脚本正文出现 4 处输出模板未定义内容：秒级节拍分段（「0-3秒：…3-7秒：…7-10秒：…」）、生成链路引用块、选题与设定映射表、S11 诊断记录。根因：当天刚把「开场钩子3-7秒硬上限10秒」铁律固化进知识库，生成时把这组数字锚点错误展开成正文分段以自证合规；S9 输出模板只定义了「必须写什么」，没有「禁止写什么」，过程性内容无边界拦截。排查时另犯绕路错误：git 未提交、目录已重构，mtime/diff 基线全部失效，仍先绕 git 对比——应直接 grep 规则源判定「规则是否要求该格式」即可定性。

规避与铁律：

1. 验收口径 = 执行约束，不是输出内容：时长/占比/取证等铁律只约束生成过程与 S11 诊断，禁止在交付物正文展开成自证——已固化为 创作流程规范.md「交付物输出边界（通用铁律）」+ S9 输出模板「输出边界」块（V1.0/Lite1.0/.dsh 三副本同步）。
2. 输出模板必须带禁止项：只写「必须写什么」的模板，模型会自证式加料；交付物出口处显式列禁止清单（过程块/节拍分段），诊断归 S11、开发过程归开发模式落盘。
3. 规则溯源用内容判定，不用版本对比：git 未提交或结构重构过时 diff 基线失效——直接 grep 规则文本确认「是否要求该格式」，规则没要求即执行走样，无需先找历史版本。

---

#013 获取账号信息误用 MCP 达人工具，未走浏览器（2026-08-27）

用户环境（③）执行「分析账号」「获取数据」时，AI 优先查 MCP 的 list_hot_accounts/hot_account_detail（实为 MCN 内部账号库查询：内部维护的达人账号，含人设/赛道/标签/代表作，非抖音页面实时数据；工具命名 hot_accounts 有误导性）获取达人信息，而不是用 browser-harness 访问抖音账号主页。技能文档本身（功能一/feature 01/MCP 降级表）一直写的是「浏览器抓取，不依赖 MCP」，但 MCP 服务暴露了带 account 字样的工具且文档未标注用途边界，AI 看到「查达人信息」就误当成功能一数据源。根因：数据源优先级只存在于文档默认流程里，没有显式红线；工具清单未给非本职工具标注边界。

规避与铁律：

1. 数据源优先级必须显式化：获取达人账号信息浏览器优先（访问抖音网页版账号主页），如无必要不用查 MCP 达人信息；MCP hot_accounts 系列是内部账号库查询（不是抖音热门榜单，名称有误导性）、不是功能一数据源，仅浏览器无法访问时兜底并注明来源——已固化为 SKILL.md 规则表「账号信息数据源（红线）」行 + feature/01_获取账号信息.md「数据源优先级（红线）」块 + MCP_工具调用规范.md 工具清单「工具边界（数据源红线）」备注（源 + dsh 双副本同步）。
2. 工具清单要标「非本职」边界：MCP 服务暴露的工具若不属于本技能职责，必须在清单中注明「仅作 X 用途、禁止作为 Y 数据源」，防止按工具名直觉误用。
3. 行为偏差反馈 → 三层化沉淀：用户环境实操反馈的 AI 行为偏差，先落技能红线（治本）→ 追加失误记录（#013）→ 写工作日志（记忆层）。

---

#014 表头「X 前面」沟通歧义（2026-09-03）

用户原话「标签列放到时长前面」，表头实际顺序为发布时间|视频标题|点赞|评论|分享|收藏|时长|操作，「时长前面」字面理解应为收藏与时长之间（已在第一版实现）。但用户三遍明确指示最终意图是「点赞列左边」（即 视频标题 与 点赞 之间），并明确表达了不满。

规避：

• 表头列序相关的简短中文表达「X 前面/后面」易产生左右歧义；用户脑里的列序 ≠ 实际代码列序时极易误解。
• 接到位置类需求时，若表达简短（如「X 前面/后面/左边/右边」），先核对当前代码的实际列序再下手，或直接用 Ask 锁定；严禁凭借字面+猜测实现。
• 如果用户在同一会话反复纠正同一项，说明首次理解跑偏——立即完全重读上下文（含 summarization 前轮次），不要继续在错误实现上微调。

---

#015 写技能文件走 bash 导致反引号吞名 / 编辑吞换行 / 0 字节误建（2026-09-07）

同一轮术语统一收尾中出现三类写入事故：

1. bash 反引号吞名：用 Bash heredoc/python -c 写入含 `code` 的 Markdown 时，反引号被 shell 命令替换执行，被包内容整体消失——references-add/变更日志.md 两条 09-07 条目里「概念分层与源头表述规范.md」「技能审计检查清单.md」等文件名被吞成空括号/空位，事后靠 commit message 对照才补回。
2. Edit 吞换行：Edit 的 old/new_string 若在句末多带/少带一个 \n，会把下一行首行内容粘连到上一行尾（如 S2「已有用户输入…口头禅）- 无用户输入…」连成一行），语法不报错但排版损坏，且两次都发生在同文件。
3. 0 字节误建文件：某次写入把 frontmatter 的「背景：…」「适用：…」行错当文件名，在 V1.0/ 根生成两个 0 字节文件（「背景（2026-09-07」「适用：技能树全部描述文件（创作流程」），git status 才发现。

规避与铁律：

1. 写含代码/反引号的 md 一律用 Write/Edit 文件工具，禁止经 bash（heredoc、python -c、echo）写入——shell 会把反引号当命令替换。bash 只能用于读/查/校验。
2. 每次 Edit 后抽查邻接行：凡改句尾有换行敏感的段落（列表、表格、代码块），改完立即 sed -n 'N-2,N+2p' 看有无粘连；批量大改后通读成品一遍（本技能"逐条修复+复查式修复"纪律同样适用于文档编辑）。
3. 写入后检查 0 字节异常文件：批量写完跑一次 find <目录> -size 0，发现即删并溯源。
4. commit message 内禁用反引号（会被 shell 二次解释），需引用路径时用中文引号「」或普通文本。

---

#016 同一文件多处 Edit 并行提交产生写竞态丢改（2026-09-07）

S1/S2 产物文件名改名（01_需求拆分/拆解 → 01_需求理解/02_需求补全）时，对 references/创作流程规范.md 的多个 replace_all 在同一条消息里并行发出（第一批 2 个、第二批 2 个）。工具均报「Successfully edited」，但事后 grep 发现 3 处残留（L49/L68「01需求拆分」、L427「02_需求拆解」）——并行编辑基于同一旧快照各自替换后写回，后写者覆盖先写者成果。串行逐个补做后零残留。

规避与铁律：

1. 同一文件的多次修改必须串行（一条消息一个 Edit），不同文件之间才可以并行；同文件批量替换宁可用一次 replace_all 也不要拆多个并行 Edit。
2. 「Successfully edited」≠ 已生效：并行场景下报成功不代表最终文件含该改动，改完必须全量 grep 验证（本次靠 需求拆分|需求拆解 残留扫描抓出 3 处漏网）。
3. 多词替换建议顺序：先做含下划线/更长的精确词（如 01_需求拆分），再做短词行文（如 01需求拆分），或统一用带上下文的整行替换，降低互相覆盖概率。