半导体股权投资尽职调查

概述

半导体行业股权投资尽职调查 Skill

【版权与使用条款 · 请先阅读】

• 创作者：依然飯特矽　|　反馈联系：fcg_ww@qq.com
• 本 Skill 版权归创作者 依然飯特矽 所有（© 2026），保留一切权利（All Rights Reserved）。
• 仅授权在 WorkBuddy 官方技能市场安装后"使用"：不得复制、导出、再分发源文件；不得修改、反编译或基于本 Skill 制作派生作品。
• 使用过程中遇到任何问题、Bug 或改进建议，欢迎通过邮箱 fcg_ww@qq.com 反馈给创作者。
• 欢迎投稿脱敏案例：如果你在使用中积累了有价值的 DD 案例，欢迎按脱敏规则（隐去真实公司名/人名/非公开数据，用"公司A/竞品X"泛化）整理后发送至 fcg_ww@qq.com，一经采纳将纳入后续版本案例库，帮助更多使用者。
• 未经创作者书面授权，禁止将本 Skill 或其任何部分用于二次分发或商业转售。

⚠️ 最高优先级规则：HTML报告格式强制统一（不可覆盖）

背景：2026年6月，某芯片设计项目DD报告v2与标准模板出现严重格式偏差——CSS完全不同、封面/目录格式不同、章节标题层级不同、SFFRS网格不同、红旗样式不同、缺少关键组件（page-break/verdict-box/interview-card等）、附录结构不同。根本原因是未使用标准模板生成。

修复：v3版完全按标准模板重建，17章/10 SFFRS/17红旗/3 SVG/3竞品对比表/6附录全部通过自动验证。

规则1：强制从标准模板生成（不可绕过）

绝对禁止从零创建HTML报告。所有DD报告必须从 templates/dd-report-template.html 开始，以"填充模板内容"的方式生成。

规则2：标准模板的CSS/HTML结构不可修改

以下CSS类名和HTML结构在标准模板中是标准且经过验证的，禁止自行创建变体：

⚠️ 铁律（v2.5.8 沉痛教训）：凡自创 class 必裸渲染。HTML 不会因 class 未定义而报错——浏览器只是默默地用默认样式渲染，于是「结构看着像样、样式全部丢失」。故 ① 封面/摘要等结构化区块一律照抄模板的 class 名与嵌套层级；② 生成后由检查项 1.37 机械校验「封面用到的每个 class 在 <style> 中确有 .类名 定义」。历史产物可用 python scripts/refresh_cover.py <报告.html> 一键回修封面与样式。

⚠️ 铁律（v2.9.8 沉痛教训）：程序化替换模板结构块时，锚点必须落在该块自身的闭合行。典型反例是封面 cover-meta 的整块替换写成 .*?</div>s*(?=</div>)：.*? 取最短匹配，而「</div> 紧跟 </div>」这个前瞻条件在模板里并不在块尾成立——cover-meta 闭合之后还有一层 cover-confidential，两个相邻的 </div>（cover 与 container）出现在密级声明之后。于是正则在「报告用途」那一行的 </div> 处就收口，块自身的闭合标签被留在替换结果之外。多出来的那一个 </div> 顺序关掉 .cover 与 .container，CONFIDENTIAL 被挤出封面，目录起的全篇正文成为 <body> 的直接子元素——max-width:1100px 居中与 40px 60px 内边距双双失效，网页版左右页边距归零。该缺陷 div 配平、标签闭合全对、DOCX 转换完全正常，仅仅因为浏览器不认 CSS 版心才暴露，属「只影响呈现、不影响校验」的盲区（同 1.26）。故 ① 优先只替换块内的内容行（如逐行替换 cover-meta 里的 meta-value），不要整块吃掉容器标签；必须整块替换时，锚点用「换行＋缩进＋</div>」这样的块自身闭合行（如 .*?n </div>），禁用「相邻 </div>」前瞻——相邻关系的成立位置可能远在块外；② 替换后断言该块在产物中恰好出现一次，且父容器仍在；③ 装配脚本自带「版心容器完整性＋div 配平」自检，div 计数前须先剔除 <style>／<script> 与 <!-- -->（模板 CSS 注释里有字面标签举例，浏览器不解析但字符串计数会误判）；④ 由检查项 1.63 机械兜底。教训可追溯到某先进封装标的 C-97（2026-11-08）用户第三次返工反馈。

规则3：生成后强制执行自动验证

报告生成后，必须执行 scripts/delivery_check.py（各项目复制为 run_check.py 后运行；v2.6.11 起不再引用 delivery-checklist.md §七内嵌副本——那份内嵌副本与源码双份维护且已陈旧，已下线）。任一项未通过则不得交付。检查项 1.1—1.63（62 项编号规模；脚本实跑打印 ✅ 行数随项目浮动（v2.8.1 实测全闭环样本 43 行）（含 v2.7.2 新增 1.44、v2.7.3 新增 1.45、v2.7.6 新增 1.46、v2.7.7 新增 1.47/1.48、v2.7.8 新增 1.49、同版追加 1.50、v2.7.9 扩 1.49 密度/结构档（联动件完整独立报告纪律）；行数随报告的软警告／跳过分支浮动——1.46 在清单缺失或决策非 approved 时跳过）：1.10 由 1.1 覆盖、1.6—1.9 为对齐实现、1.19 空缺、多子项合并为一行输出），验证项包括：17章节、SFFRS 恰好 9 个、红旗 ≥8 个、SVG ≥3、YoY标注、竞品对比表、附录 appa–appf、Ch2竞争格局文字分析（1.22 · v1.11.5起）、Ch2目录↔正文h2一致性（1.23 · v1.11.6起·根因修复）、Ch2图表存在性（1.44 · v2.7.2起）、红旗清单结构完整性（1.45 · v2.7.3起）、收口后执行方式必请示（1.46 · v2.7.6起）、目录↔正文h1一致（1.47 · v2.7.7起）、执行摘要编号形态（1.48 · v2.7.7起）、DOCX图表部件健全（1.50 · v2.7.8同日追加），1.51—1.54（v2.8.3／v2.8.4 新增：语义槽位唯一／比较关系真值／相邻段重复／渲染源新鲜度）、1.55—1.59（v2.8.5 同版补强：材料时效量化下移／SFFRS 低于下限拆解／政策双栏方向／材料受限影响清单／增速口径断裂）、1.61（v2.9.1 新增：三级小节孤号／跳号·硬阻断）、1.62（v2.9.2 新增：长正文断点缺失／（n）断点孤号跳号·软警告），以及 1.24—1.50 各项。

规则4：附录结构固定

附录A-F的标题和顺序不可更改：A三支柱验证矩阵、B证据索引表、C数据请求清单、D访谈纪要、E财务附表、F可比公司数据。

规则5：报告章节框架契约（目录与正文强一致·单一事实源）

模板的「目录(li.sec)」与「各章 h2 小节脚手架」是报告框架的唯一事实源（已互相校验一致）。 任何 fill_template.py 生成/填充时，正文每章 h2 的编号与核心标题词必须与目录严格一致，规则如下：

1. 编号集合相同：目录声明的 C.N 小节，正文必须全部存在；正文不得出现目录未声明的同级 h2（编号不得增删）。
2. 核心标题词一致：允许在核心标题后追加「企业专属副标题」后缀（如 2.2 细分行业分析：企业级SSD、9.1 红旗汇总表（17项：…）），但不得更改/替换核心标题词（如不得把 2.3 竞争格局与竞品深度对比 改成 2.3 营业收入成长性）。
3. 强制模块归入 h3 + 交付标题禁含内部检查标注：阶段5/7、退出LP、政策催化、断供等强制模块，一律以 h3 子小节归入对应的 h2（如 5.5.1 财务引擎联动/7.5.1 断供压力测试/8.2.1 政策催化估值建模/8.2.2 严谨估值推导（equity-valuation 协同）/9.4.1 退出情景表/9.4.2 LP约束检查项 已是 h3 合规）；若确有需要新增 h2（如 8.5 交易条款风险），必须同步加入目录 li.sec 与正文，否则判定错配。交付报告的小节标题不得出现 skill 内部检查编号文字（如「强制模块 1.11」「强制模块 1.12」等）——这类编号仅供交付检查使用，不属于客户交付物；检查项（1.11/1.12/1.13/1.21）只校验内容（政策调整列、裸估值/含政策估值双栏、断供四步法、equity-valuation 引用），不看标题文本。编号连贯纪律（铁律A/B · 与 FA 模板同源）：强制模块 h3 须在所属 h2 内连续编号（如新增断供类须续接 7.5.2 而非跳 7.5.3、新增退出/LP 类须续接 9.4.3…），禁止跳号；禁止把单一强制模块升格为 h2 孤号（如 ## 7.6 断供压力测试 单块）。

★三级小节编号纪律（v2.9.1 从本段末尾一句话升格为独立条目 · 检查项 1.61 硬阻断）：同一 X.Y 前缀下带编号的 h3 不得只有 1 个（孤号 X.Y.1），且末位须 1..N 连续（禁跳号）。孤号的害处不在美观——编号是读者的检索索引，写成 1.1.1 就等于承诺存在 1.1.2；读者循号检索会落到 1.2，而编号所承诺的层级根本不存在。若同一份报告里既有「h2 直挂内容」的一批小节，又有「h2 只挂一个 h3」的另一批，读者只会判定编号坏了。处置按优先级三选一：① 删除该 h3，内容直挂 h2（首选，本例 12 处即此法）；② 改为无编号的描述性小标题；③ 补足一个标题确有区分度的第二子节——不得为凑号而注水拆节。此条此前仅为本段末尾的一句附则，未编号、未进 references/delivery-checklist.md、CHANGELOG 无记录，因此从写下那天起一次也没有被执行过：全库 70 份 DD 报告 42 份（60%）含孤号，359 个三级组中 91 个（25%）是孤号，templates/dd-report-template.html 自身还留着 2.1.1 孤号（v2.9.1 已改）。教训与 v2.8.8 同源：纪律要能拦住执行，落点必须「正文独立条目 + 检查项编号 + 模板示范」三件齐备，缺一件等于没写。 ★正文断点纪律（v2.9.2 · 检查项 1.62 软警告）：h2／h3 直挂的叙事正文超过约 600 字时，须用 <h4>（1）…</h4> 切分并列重点，每个断点下 2—4 段。载体只能是 h4——这不是风格偏好，是两条硬约束推出的唯一解：generate_dd_docx.py 的 collect_toc() 只收 h1／h2／h3，对 h4 走 add_heading(level=3) 且不打书签，故用 h4 作断点，目录条目、书签队列与 1.23／1.47／1.46 的锚点体系全不受影响；而 1.61 只认 h3 的 X.Y.Z 形态，h4 不会被误判为孤号。反过来，若用 h3 承载「（1）（2）（3）」，既不带编号锚点、又和 X.Y.Z 的编号语义打架。粒度分两层：并列的「大块判断」用 h4 编号（如「（1）主体沿革」「（2）基础信息核对」）；一个大块内部的「几点支撑」不编号，改为分行段落并以粗体短语领起（如「注册资本与实缴情况决定…」「历史融资轮次与投资方决定…」）。全报告只保留一种内部序号：（1）（2）（3）；禁用「第一，第二…」「其一，其二…」「关于估值。」多套并存——三种形态出现在同一份报告里，本身就是读者判定「编号坏了」的直接原因。（n）须自 1 起连续，且不得只有（1）一项：这是 1.61 孤号问题在新载体上的复发口，1.62 一并判。与 R8 的分工：R8 治「同一段落内『其一…其N』超 3 项」的机械堆砌；（1）（2）（3）是分行断点，不受 3 项限制，但超过 5 项通常说明该改表格或升一层小标题。卡片式小节不受本条约束：红旗清单、SFFRS 九宫格、结论卡、图表块自带断点，1.62 已排除。列表化须留总述段（与 1.33 联动）：把段内「其一…其N」改成分行 <ol> 之后，若该节只剩短条目罗列，1.33 会判「碎片化罗列」——列表只承担并列项，须另留一段 ≥40 汉字的连贯总述（事实＋阐释）在列表前后收口。某GaN机器人芯片公司 9.4.2 即此形态：五项保护条款转 <ol> 后条目平均 27 字，靠补一段「五项与三处缺陷一一对应」的总述才过 1.33。枚举改列表不是纯结构操作，它会把原本靠长句承载的阐释一并删掉。

1. 根因警示：v1.11.5 及更早报告（某 NAND 闪存原厂/芯原/某边缘 AI 芯片设计公司）出现「正文被全量重写、自行发明 h2 标题、静态 TOC 未同步」的系统性错配——编号相同但含义完全不同、prescribed 小节(供应链与地缘政治/技术风险评估/SFFRS/关键成功因素等)整节消失、正文与目录对不上。自 v1.11.6 起，交付检查 1.23 强制阻断此类错配。
2. 生成器纪律：推荐做法——fill_template.py 直接填充模板现成的 h2 槽位（仅替换 <h2>…</h2> 与内容，不改标题）；若必须自定义标题，须同步改写目录 li.sec，或调用统一 scripts/gen_toc.py 由同一章节映射生成目录，杜绝双源漂移。
3. 注入 marker 锚点约定（v1.11.13 新增护栏）：模板各章节用 HTML 注释锚点 <!-- ========== 第N章 XXX ========== -->（短名，如「第1章 公司概况」「第3章 技术DD」「第7章 供应链分析」），与 TOC/标题的长名（如「第1章 公司概况与基础信息」）故意不同。generate_report.py 的注入 marker 字典 必须严格使用模板短名，误用长名会导致章节静默 fallback 到模板空占位、整章丢失（某 SiC 衬底标的缺陷复盘）。强烈建议调用 scripts/fill_template.py::fill_report(template, sections, required) 做注入——它从模板自动提取真实锚点，并在 (a) sections 含模板不存在的锚点、或 (b) 必填章节注入后为空 时直接抛 ValueError 响亮报错，而非静默丢章。
4. h1 章标题契约与执行摘要编号形态（v2.7.7 新增）：① 目录 li.ch 条目是正文 h1 的唯一权威源——正文 <h1 id="chN"> 须与 li.ch 文本逐字一致（含「第N章」前缀），自拟章名 = 检查项 1.47 硬阻断（根因：1.23 只覆盖 h2 层，四轮执行三种形态——某 VCSEL 光芯片标的全无前缀/某军品射频 SiP 标的·某引线框架标的半对齐/某 BLDC 驱控芯片标的全无前缀且 7 处章名自拟，门禁次次全绿，2026-10-10 用户指出后回溯发现）。② 执行摘要（ch0）章内 h3 小节编号形态为「1、2、3、」（禁用「0.x」——第 0 章语境的 0.x 不合中文报告习惯）；正文引用执行摘要小节一律写「本章第 N、节」（如「0.3 前置第 1 项」应写「本章第 3、节前置第 1 项」）；形态偏差 = 检查项 1.48 软警告（存量报告 ≤v2.7.5 全为 0.x，硬阻断将全量 FAIL，铁律 2 先标定）。
5. DOCX 图表部件契约（v2.7.8 同日追加）：DOCX 是双格式标准交付物，图表必须以位图内嵌（渲染器以 Edge headless 将内联 SVG 截图为 PNG 后 add_picture，落 HTML 同目录 _docx_assets/），禁止「（图表：见 HTML 版）」占位或 SVG 文本逃逸形态交付。渲染器历史缺陷：① 占位分支因 svg 被 <p> 包裹走内联路径永不可达，iter_inline 兜底递归把 SVG 内部 <text> 抽成正文乱码；② 门禁 46+ 项无一覆盖 DOCX 侧——某 BLDC 驱控芯片标的（v2.7.6）/某前道量检测设备标的（v2.7.8）两轮 DOCX 均零图片而门禁全绿，2026-10-11 用户目检发现。检查项 1.50（硬阻断，对齐 IR 契约 H）：DOCX <w:drawing> 数 ≥ HTML 内联 <svg> 数。Edge 不可用环境：渲染器降级占位文本并 stderr 告警，1.50 将 FAIL——属环境缺依赖，须补 Edge 或改用有 Edge 的机器出 DOCX。

规则6：图表-章节语义对齐与编号自动递增（v1.11.30 固化·防错位/防跳号）

根因警示（某引线框架标的复盘）：报告曾出现「§2.1 半导体行业概览」塞入*公司自身营收轨迹图*、「§2.3.2 细分市场份额结构」实为*公司产品结构饼图*——两类错配同期发生：① 图表编号硬编码，移动图表后未同步重编号，导致「图表 2-2 无 2-1」「4-1 与 4-2 倒置」跳号；② 图表内容与所在章节语义不符（行业章节混入公司财务/产品图）。自 v1.11.30 起，交付检查 1.32 强制阻断跳号、软警告语义错位。

强制规则：

1. 章节语义边界：行业概览类章节（§2.1 半导体行业概览 / §2.2 细分行业分析）只允许放置行业/市场层图表——市场规模、CAGR、国产化率、竞争格局/市场份额饼图、产业链图；禁止放置任何公司自身数据图（营收轨迹、产品占比、产能、客户结构、毛利率），这些一律归入第4章 业务DD（§4.1 产品与客户 / §4.2 销售与增长）。
2. §2.3.2 语义专属：「细分市场份额结构」必须放置市场份额/竞争格局图（即行业维度的份额/集中度），禁止放置公司自身产品占比图（那是 §4.1 的内容）。
3. 编号按章连续：图表须按「章内顺序连续」编号（图表 X-1、X-2…），禁止硬编码后移动不重编号；推荐用自动递增变量生成编号，杜绝跳号/倒置。
4. 交付前自审：每个图表须确认「标题语义 == 所在章节语义」且「编号 X-Y 与所在章 X 一致、Y 连续」；任一不符即移动章节或重编号，不得带病交付。

规则7：正文数学符号一律实体化（v2.9.8 同版补强 · 1.18-c 配套）

正文中表示「小于／大于」的数学符号，一律写作 < / >，禁止裸写 < / >。

后一种形态按规范无害，仍要求实体化，三条理由：

1. 可移植性：产物一旦交给严格 XML 解析器（xmllint、部分 PDF 引擎、把 html 当 xml 处理的静态站点构建器），裸 < 直接 not well-formed。
2. 一致性：同一份报告里两种写法并存已实测到（2026-11-08 某半导体集团 C-98：Ch2 裸写四处在同一句，Ch3／Ch4 同期已用 <）。读者看不出差别，审计口径却不统一。
3. 成本为零：实体化后渲染结果字节一致。同轮实测 4 处替换后，DOCX word/document.xml 仍是 < 十处、双重转义 < 零处。

不得以「后面是数字所以安全」作为放宽理由，那只是在赌下游解析器。交付前 1.18-c 的 benign_lt 计数应为 0；非 0 即回改源文件并重走渲染链（装配 → DOCX → 清单复钉哈希 → 分发副本同步）。

技能概述

本技能专门用于半导体行业非上市公司股权投资尽职调查，覆盖私募股权（PE）、成长股权（Growth Equity）、风险投资（VC）、并购（M&A）、战略投资、Pre-IPO 等全部交易类型。

半导体行业具有技术密集、资本密集、供应链全球化、出口管制敏感、产品生命周期短、客户验证周期长等特征，需要高度专业化的尽职调查框架。

本技能将通用PE尽职调查"五书框架"（业务、财务、法律、行业、技术）与半导体行业特有的"三支柱验证框架"（技术可行性、量产可落地性、供应链安全性）深度融合，形成系统化、可执行的DD工作流。

适用交易类型

默认输出

• 主输出（阶段1-10 主报告）：项目名称_DD报告_完整版.html 与 项目名称_DD报告_完整版.docx 必须同时产出（HTML + Word 双格式，权威交付物）。HTML 由 templates/dd-report-template.html 经 scripts/fill_template.py 填充生成；Word 由 scripts/generate_dd_docx.py（HTML→DOCX 结构映射转换器）从同一 HTML 同步转换，结论与 HTML 完全一致、仅做格式映射、不改任何分析结论。命名三件套对称（主报告/财务/估值均遵循 项目名称_XXX报告）。
• 辅输出：数据请求清单（Excel）、管理层访谈指南（Word/PDF）、红旗扫描摘要（PPT/HTML）
• 可选输出：IC汇报PPT（.pptx）、PDF 版本（.pdf）、财务模型（Excel）、投后价值创造建议（Word/PDF）、DD数据汇总Excel

多格式输出：详见 references/multi-format-output-spec.md

• Word 版为主报告默认必交付（双格式之一，由 scripts/generate_dd_docx.py 自动生成，无需用户单独请求）
• 输入"生成IC汇报PPT"→同时输出.pptx
• 输入"生成PDF版本"→同时输出.pdf
• 输入"生成全部格式"→同时输出所有5种格式

统一归集路径：上述所有产出文件的实际落盘位置为 已分析项目/{公司简称}/（详见「⚠️ 项目文件夹统一归集铁律」与操作契约 #8），不得直接落在工作区根目录。例：已分析项目/某显示驱动标的/某显示驱动标的_DD报告_完整版.html 与同名 .docx。

输入材料清单

技能可处理以下输入材料（均为可选，技能根据可用材料调整分析深度）：

公司提供材料

• BP / CIM（商业计划书 / 机密信息备忘录）
• 技术白皮书、产品规格书、测试报告
• 流片报告（工程样片、良率报告、可靠性测试）
• 客户验证报告、PO/合同、量产承诺函
• 专利清单、IP自由实施分析报告
• 晶圆厂产能协议（NDA + MPW/Customized MASK协议）
• 财务报表（审计报告优先，未审计报表+银行流水次之）
• 供应链合同（晶圆、封装、测试、原材料）
• 组织架构图、核心人员简历、股权激励计划
• 法律文件（章程、股东协议、重大合同、诉讼清单）

外部获取材料

• 行业协会数据（SIA、SEMI、中国半导体行业协会）
• 可比上市公司财务数据、估值倍数
• 专利数据库检索结果
• 供应链多方验证信息
• 客户/供应商背调访谈记录

⚠️ 项目文件夹统一归集铁律（v1.11.25 固化 · 不可绕过）

本规则与操作契约 #8（项目隔离 + 统一归集原则）互为约束；两者冲突时以本铁律为准。

• 唯一归集目录：本技能所有 DD 项目的产出文件夹，必须统一存放在工作区内的单一顶层目录 已分析项目/ 之下。任一项目的标准文件结构为 已分析项目/{公司简称}/（例：已分析项目/某显示驱动标的/）。
• 禁止散落根目录：严禁把项目文件夹直接建在工作区根目录，或与 已分析项目/ 之外的任何位置混放。此规则同时适用于新建项目与历史项目——凡散落在根目录或其他位置的历史项目，须整文件夹迁入 已分析项目/。
• 独立隔离仍生效：统一归集 ≠ 混放。每个项目依旧是 已分析项目/ 下的独立子文件夹，项目间文件互不干扰（详见操作契约 #8）。
• 联动子目录随父目录迁移：阶段5 财务分析输出 已分析项目/{公司简称}/财务分析/、阶段7 估值输出 已分析项目/{公司简称}/估值分析/，均随主项目文件夹一并归入 已分析项目/，不得外置于根目录。
• 兜底：若当前工作区尚不存在 已分析项目/，项目启动（阶段1）时自动创建该目录，再在其中创建各项目子文件夹；通用跨项目工具脚本集中存放于 已分析项目/_shared_tools/（如不存在则创建，项目产出不得放根目录）。

⚠️ 旧项目重跑铁律（v2.9.5 固化 · 不可绕过）

用户 2026-10-30 原话：「以后用户让你再次分析曾经分析过的项目时，要重新分析，因为资料可能已经更新了，可以做对比，但千万不要延用原来做分析的资料」。本节为该指令的技能内落点，与用户级长期记忆「§二 首条」同文。

触发条件：任一情形即视为「再次分析」——① 同一标的二次委托；② 材料换版或升级（BP＋TEASER → 立项报告、访谈纪要 → 审计报告、单年报表 → 三年三表）；③ 标的更名、迁址或同集团兄弟标的换壳；④ 跨大版本回归测试；⑤ 用户只说「再跑一遍」而未声明材料是否更新（该情形按「已更新」处理）。

强制动作（五项，缺一即视为未执行重跑）：

1. 重读材料：只读当前磁盘上的原始材料，按阶段 2 全量重解析。旧主报告、旧 FA／EV／建议书、旧 _materials/ 解析文本一律不得作为输入。
2. 重算数字：DD／FA／EV 的 _calc*.py 全部重跑，从新材料重新取数。禁止继承旧 _calc*.out.txt，也禁止「只改变化的那几个参数」——分母、可比组、口径年份都可能随材料一起变。
3. 重建目录：新建 已分析项目/{标的}-{YYYYMMDD}/，旧目录只读、原地不覆盖。两套目录并存本身就是「重跑已发生」的证据。
4. 重出结论：SFFRS 八模块、红旗清单、三支柱得分、加权估值区间与回报测算全部重新生成。旧结论不得抄入新一轮正文，只能在跨版本对比节里以「上轮口径」名义出现。
5. 查重三通道：入库前按操作契约 #7 跑行业关键词＋财务指纹＋估值指纹反查，确认新例与旧例是两条独立案例，各自登记、互不覆盖（先例：C-89 某先进封装标的第 13 例、C-95 某GaN机器人芯片公司第 15 例）。

旧报告的唯一合法用途 = 对比基准。须成节呈现，每处引用标明「上轮（C-XX）」，并写清三件事：① 变了什么（材料层级／交易结构／可比组／口径年份）；② 为什么变（下条二分归因）；③ 哪些没变（方法、权重、折现率等固定项，用于证明结论变化不是换模型换来的）。

材料层级变化时须二分归因（C-95 实证，本节为强制格式）：

禁止用「综合影响」「多重因素」笼统带过。C-95 的正解是：估值中枢两轮仅差 −1.67%（参数更新），结论却从「暂缓」翻转为「有条件推进」，翻转 100% 来自报价由 20.00 亿元重置为 7.50 亿元（交易结构＝事实推翻）。不做二分，会把它误判为「模型不稳」或「材料变好」。

唯一例外：用户显式声明「材料未变，只重跑框架／只换版本」时，可复用上一轮 _materials/ 解析文本，但须在报告首页与分析基准段双处标注「本轮材料未更新，复用 YYYY-MM-DD 解析结果」。无此声明即默认材料已更新——这是本铁律的默认方向，不得反向推定。

机械锚点（铁律 1：新纪律须配校验，本版不新增检查项）：

• 目录并存：已分析项目/ 下同标的存在 ≥2 个日期目录时，最新目录的报告日期须晚于旧目录，且旧目录的文件清单与哈希快照未变（只读证明）。
• 材料新鲜度：_materials/ 内解析产物的源文件 mtime 须晚于旧报告的分析基准日；否则触发「材料可能未换」提示，须书面确认后方可继续。
• 时效族兜底：1.55—1.59 已校验「报告日期／材料日期／数据源日期」三者一致，本铁律直接复用该族，不新开判据。

为什么写成本铁律而非建议：v2.9.4 及之前的技能文本只在「案例库参考」处提到「参照同行业案例」，从未禁止把同一标的的旧报告当作输入。C-95 证明这个缺口的代价很高——旧口径（投前 20.00 亿元）若被沿用，本轮会得出「报价溢价 167%」的完全相反结论，而真实读数是对中枢折价 30.57%。

操作契约

1. 证据驱动：所有结论必须标注证据来源和可信度等级（详见 references/evidence-and-red-flags.md）
2. 红旗分级：识别的红旗问题必须按严重程度分级（一级/二级/三级），并给出明确建议
3. 三支柱验证（v2.5.4 强化 · 命名唯一）：技术可行性、量产可落地性、供应链安全性三者缺一不可。以上三者为本技能的规范命名，全篇（执行摘要 / 第 9 章综合判断 / 附录 A 验证矩阵 / 任何汇总表与图表）必须使用同一套名称，严禁各章自创别名——历史缺陷：某特色工艺代工厂报告的执行摘要用规范名，第 9.3 节却改用「商业化可行性 / 财务健康度」，同一报告出现两套三支柱体系。财务维度的健康度评估以 SFFRS 专项检测（5.5 节）与财务风险红旗清单（5.6 节）独立呈现，不占三支柱权重，避免与其他维度重复计分
4. 中性表述：报告表述保持专业中性，避免绝对化判断，投资决定权归用户
5. 敏感信息处理：出口管制、军工关联、未公开财务数据等敏感信息在报告中标注处理建议
6. 细分行业适配：根据公司所属细分行业（设计/制造/设备/材料）自动加载对应适配器（详见 references/subsector-index.md）

发布版分支：发布包内 cases/ 为脱敏副本（标的匿名）——步骤 7 的同类案例参考、步骤 9 的入库与 validate 均照常可用，但新交付案例的实名登记只进本地库（publish_desensitize 重跑即增量脱敏）。

1. 案例库参考与入库：新项目启动时查阅案例库（cases/目录）参照同行业/同阶段案例；项目交付后须按操作契约 #9 强制脱敏入库
2. 项目隔离 + 统一归集原则（⚠️ 不可绕过）：① 每个DD项目必须在独立文件夹中开展工作；② 所有项目的文件夹必须统一归集到单一顶层目录 已分析项目/ 之下，即项目启动时即创建 已分析项目/{公司简称}/（中文名或拼音均可，如 已分析项目/某显示驱动标的/），严禁散落在工作区根目录或与其他项目混放。本报告生成的所有文件——DD报告HTML/Word、材料解析文本、提取脚本、生成脚本、图表SVG源文件、财务分析/估值分析子目录、数据请求清单、中间版本等——一律存入 已分析项目/{公司简称}/。③ 通用跨项目工具脚本集中存放于 已分析项目/_shared_tools/ 文件夹（如尚不存在则在 已分析项目/ 内创建，项目产出不得放根目录）。此规则确保项目资料可追溯、可归档、可复用，且全量集中便于统一查阅。详见「⚠️ 项目文件夹统一归集铁律（v1.11.25）」。
3. 案例库强制入库：每次完成DD报告并交付后，必须将本项目脱敏生成 cases/case-XX-{赛道}-{阶段}.md 并更新 cases/case-library-index.md，必要时增量更新 cases/ 下 4 个专项知识文件（non-standard-verification / lessons-learned / efficient-techniques / ipo-regulatory-inquiry）。脱敏须遵循 cases/README.md 脱敏规则与 references/desensitization-guide.md。此规则为强制，纳入交付前自检清单与交付检查清单 1.19，未入库不得视为项目闭环。
4. 索引结构机械校验（⚠️ v2.5.3 新增，与 #9 绑定的强制门禁）：case-library-index.md 靠人工多点维护、无单一事实源，历史上出现过四类结构性缺陷——① 编辑器回写残留行号前缀 43→ 打断表格行；② 「红旗严重度对比」表长期只维护到 41 例，而「案例总览」已有 57 例，16 例从未补行（C-14/15/17/20/21/22/23/25/26/27/29/33/34/35/45/46）；③ 表内混入空行把一张表切成两段、单元格以 … 截断；④ 重建时重复写入表头。因此每次案例入库后必须执行：

“bashpython scripts/validate_case_index.py # 退出码 0 才算入库完成`校验项：案例总览(7列) / 红旗严重度对比(6列) / 案例文件 三者的 **C 编号集合必须完全一致**（这是核心断言，任一表缺行即 FAIL）、编号连续无缺无重、无 NN→ 行号前缀污染、无表内空行断表、无 … 截断单元格、表头唯一、索引内所有 C 编号引用均已登记、红旗表计数与案例文件 共N项 声明一致（软警告）。**插入方式纪律**：补行必须用**单个脚本一次性插入全部行**（不得在编辑器里手工逐行粘贴，也不得多次追加），插入后立即跑校验器；脚本写回时必须**在表头之前（而非分隔行之前）截断原文**，否则会重复写入表头。修正既有案例文件的红旗计数时，须同时回改 case-library-index.md` 红旗表对应单元格并复跑校验器。

1. 执行摘要回写纪律（⚠️ v2.5.4 新增 · 不可绕过）：执行摘要（Ch0）是全篇唯一「结论前置」章节，其所有跨章引用的数字必须在第 3—10 章定稿之后逐项回写核对，禁止在正文定稿前冻结 Ch0。须逐项校验的五类内容：
   • ① 估值口径——独立公允区间的上下沿与中枢、报价所处位置、溢价或折价百分比，且须与阶段7 估值引擎产物的最终加权结论一致，不得只引用单一子口径（历史缺陷：某特色工艺代工厂 DD 8.2.1 原写市场法单口径「131—196 亿元 / base 161」，与估值引擎的三口径加权「113—196 亿元 / 中枢 145」不一致）；
   • ② 三支柱得分与名称（与第 9.3 节完全一致）；
   • ③ 红旗数量与级别分布（L1/L2/L3 各几项，与第 9.1 汇总表一致）；
   • ④ 交割前置条件的条数与内容（与第 9.4 节逐条对应）；
   • ⑤ 回报测算数值（各情景的 MOIC / IRR / 退出市值，与第 8.3 节、第 9.4.1 节一致）。

根因：Ch0 通常在正文之前起草，正文结论经多轮迭代后未回写，导致同一报告首屏结论与后文自相矛盾。某特色工艺代工厂实测中四类脱节同时出现，其中估值口径一处方向相反（Ch0 称「报价处区间上沿、溢价约 16%」，第 8 章称「位于区间下沿、无明显高估」）。

执行工作流

完整执行工作流详见 references/workflow.md，概述如下：

⚠️ 阶段0（v2.5.1 新增 · 写作前必读 · 不可省略）：动笔撰写任何章节前，先通读

references/delivery-contract-cheatsheet.md。delivery_check.py 的 44 项检查中（编号体系 1.1—1.44），一大批依赖

精确正则 / 字面关键词 / 精确计数（SFFRS 必须恰好 9 个、红旗 ≥8 个、正文 <h2> 必须

无属性、附录须拆为 appa–appf、条件模块须命中「退出情景表」「政策调整列」「替代窗口期」

「数据截止」「未接实时源」等字面词）。把这些契约提前写进章节骨架，可把交付返工从 4 轮压到 1 轮。

阶段0：交付契约速读（读 delivery-contract-cheatsheet.md，把硬阻断契约写进章节骨架）
    ↓
阶段1：项目启动与材料收集
    ├─ 创建独立项目文件夹 已分析项目/{公司简称}/（统一归集于 已分析项目/ 之下，所有本项目产出存入此处，禁止散落根目录）
    ↓
阶段1.5：文件智能解析（详见 file-parsing-strategy.md）
    ↓
阶段2：基础信息提取（强制）
    ↓
阶段3：技术尽职调查（三支柱验证①）
    ↓
阶段4：业务与行业尽职调查（⚠️ v2.4.7 起条件强制：凡涉及市场规模/渗透率/国产化率论述，须先按 `industry-lifecycle-and-sizing.md` 判定生命周期阶段与国产替代阶段，再按 TAM/SAM/SOM 分层测算；阶段结论决定后续分析重心与笔墨分配——判为成长期却通篇论证盈利性属逻辑错配）
    ↓
阶段5：财务尽职调查（⚠️ 默认强制联动 semiconductor-financial-analysis 财务分析引擎做六步 SOP 严谨拆解；仅当用户**自发**明确指定"仅用内置财务核查"或该技能确实无法加载时方可跳过）〔**不问**：AI 不得就此征询用户，见下方提问边界纪律〕
    ↓
阶段6：法律与合规尽职调查
    ↓
阶段7：估值与交易条款分析（⚠️ 默认强制联动 equity-valuation 估值引擎做严谨建模；仅当用户**自发**明确指定"仅用内置估值五法"或该技能确实无法加载时方可跳过）〔**不问**：AI 不得就此征询用户，见下方提问边界纪律〕
    ↓
阶段8：红旗汇总与投资建议
    ↓
阶段9：报告生成与交付
    ↓
阶段10：收口询问（⚠️ v2.5.1 强化 / v2.5.2 默认开启 · 不可省略 · v2.8.4 机械化）
    ├─ FA/EV 完成后、delivery_check 之前，编排器先写出收口交接清单（清单是 1.41/1.46 的校验输入）
    └─ **必须以 AskUserQuestion 显式询问**用户是否衔接 semiconductor-investment-report 生成投资建议书
       （详见「技能联动：与 semiconductor-investment-report」章节；未询问 = 1.41 硬阻断，未问执行方式 = 1.46 硬阻断）

✅ 阶段10 默认值已于 v2.5.2 改为 ask（2026-09-04 上海某 x86 CPU 标的实测教训的固化）：orchestrate_dd.py

的 --proposal-mode 默认为 ask——三产物齐备且 delivery_check EXIT=0 后自动输出

{公司简称}_收口交接清单.json 并打印决策提示；门禁未全绿则跳过，修复后重跑自动补发。

仍需注意：跑编排器跑通 ≠ 完成收口，脚本只负责出清单与提示，**向用户提出询问这一步必须由

AI 显式执行**。如需静默（无 handoff）才显式传 --proposal-mode none。

**【v2.7.6 必请示纪律】用户答复 approved 只回答「衔不衔接」——执行方式（本轮执行 /

新会话执行 / 暂缓）须另行请示用户，按答复经 --execution-mode 回填 execution_mode 字段

（检查项 1.46 硬阻断）。AI 不得自行裁决「当轮跑还是新会话跑」，也不得单方面把

approved 降格为「待办」（2026-10-09 某 VCSEL 光芯片标的实测暴露的形态）。

★ 提问边界纪律（v2.8.8 新增 · 必须与阶段10 配套阅读）——整条管线只问一件事：IR

唯一需要以 AskUserQuestion 征询的环节是阶段10（是否衔接 semiconductor-investment-report）。

阶段5 FA 与阶段7 EV 一律不问——它们是管线的组成部分，不是可选项。

1. 流程图标明「默认强制联动」，跳过条件只有两条：用户自发明确指定「仅用内置财务核查／仅用内置估值五法」，

或该技能确实无法加载（此时须在报告中显式标注降级）。这两条都不是「先问一句再决定」的授权。

1. 检查项 1.30 无条件硬阻断 FA/EV 产物缺失。反证：若「问了之后可以跳过」成立，用户答「不联动」

就是一个合法终态，1.30 便不该阻断——它阻断，就是设计意图的直接证明。

1. orchestrate_dd.py --proposal-mode 是阶段10 专用开关，与阶段5/7 无关。

明令禁止的行为形态：以「是否现在联动跑 FA/EV」「要不要我一起做财务分析和估值」

「需不需要我调用财务分析引擎」等任何措辞向用户征询联动与否。

跳过只能由用户自发提出；AI 主动征询，即等于把强制项降格为可选项。

失效方向辨析：1.41 防的是「把询问降级成告知」（某射频功率虚拟 IDM 标的轮：清单与提示俱在、用户从未被问到）；

本纪律防的是反方向——「把强制降级成询问」（某MCU Fabless标的轮：用户被问到本不该问的事）。

两者同属一条根因：没有显式否定句的强制项，会被礼貌性动作消解。

根因留档（教训写进日志 ≠ 写进规则）：本偏差已由 v2.8.4 在 CHANGELOG.md 复盘过一次

（原文：「① FA/EV 按设计不问——SKILL 原文『默认强制联动』『不可因用户未主动要求而跳过』，

本就在提问范围之外」），但该结论只留在 CHANGELOG、未进入本文件正文。CHANGELOG 按需查、

本文件必读，命中率差一个数量级，于是 2026-10-25 某MCU Fabless标的轮二次复发。

故本版将其从复盘段提升为正文纪律，并同步写入 1.30 与速查表——

凡是能拦住执行偏差的结论，落点必须在必读文件里。

方法论来源

本技能融合以下方法论框架：

技能联动：与 equity-valuation 估值引擎（⚠️ 强制协同）

本技能在阶段7（估值与交易条款分析）默认强制联动技能 equity-valuation 作为估值引擎（其蒸馏自 CFA Level 2 Kaplan Book 3），由其负责严格的 CFA 标准估值推演：完整的模型选型论证、公式级分步推导、财务归一化、敏感性边界、多模型交叉验证、标准化估值底稿。本技能自身的"估值五法融合"（DCF/PE/PS/PEG/同行交易法）与references/semiconductor-valuation-and-terms.md 定义的"半导体行业*用什么方法、加什么调整*"继续作为行业上下文保留，不冲突。

⛔ 三个同名估值技能，只认一个（v3.1.3 固化）

技能	定位	本管线是否使用
equity-valuation	完整估值引擎（DDM/DCF/相对估值/剩余收益 + WACC 拆解 + 敏感性）	✅ 唯一正确
equity-valuation-engine	方法论体系（DDM/FCFF/FCFE/倍数/剩余收益/非上市六大体系）	❌ 不同产物形态
equity-valuation-model-builder	生成 Excel 活公式工作簿	❌ 面向 Excel 建模

唯一入口同样是编排器 scripts/orchestrate_dd.py 的 DEFAULT_EV 常量；

手工拼路径一律违规。产物签名校验：HTML 页脚「本报告由…」行须含

equity-valuation 或「股权投资估值」（1.30 已内建）。

• 检测与触发（强制）：进入阶段7 启动估值时，**必须通过 Skill 工具尝试加载

equity-valuation。加载成功 → 强制协同，由估值引擎完成严谨推导；加载失败（技能不存在）→ 降级回退内置"估值五法融合"，并在报告中显式标注"未启用 CFA 严谨估值引擎"。不可因用户未主动要求而跳过尝试加载。**

• 分工：
  • semiconductor-equity-investment-dd → 判定财务可信度（SFFRS 8维造假检测、三支柱

验证、红旗）、给出半导体特有调整（周期位置、里程碑 DCF、行业调整因素、交易条款与安全边际），并产出主报告（HTML）。

• equity-valuation → 在清洗后的数据上套用严谨 CFA 模型（DDM/FCFF/FCFE/RI/乘数）、

公式级推导、归一化、敏感性分析，输出固定格式估值报告与底稿，作为阶段7 的严谨推导子节 + 独立底稿 / Excel 附出（不破坏 DD 报告标准模板结构）。

• 衔接点：本技能 comparable-companies-database.md 提供的归一化可比公司集，直接

喂给 equity-valuation 的相对估值步骤；本技能的周期判断与行业调整系数，并入equity-valuation 的敏感性 / 局限性章节。

• 循环防护：阶段7 调用 equity-valuation 仅用于建模推导，不要求其反向再调本技能；

数据可信度核查已由阶段3–6 与 SFFRS 完成，估值侧不再重复触发 DD。单向调用：DD →（阶段7）valuation，绝不 valuation → DD → valuation。

• 可用性：equity-valuation 为项目级技能（位于 Equity Valuation Skill 项目的

.workbuddy/skills/），在本项目内默认可协同；若用户在用户级也安装了该技能，则其他项目同样可协同。仅当完全无法加载时降级内置五法。

• 交付校验（强制）：本联动须由 delivery-checklist.md 检查项 1.21 自动核验——Ch8 须含 equity-valuation 协同子节 或 "未启用 CFA 严谨估值引擎" 降级声明，缺项阻断交付（v1.11.4 固化）。

⚠️ 阶段7 交付物铁律（v1.11.18 固化 · v1.11.21 修订：联动默认完整版 · 不可绕过）

1. 阶段7 估值产物必须由本引擎（位于 equity-valuation skill）的 scripts/build_report_assets.py 渲染为 HTML + Word(.docx) 双格式，落于项目独立文件夹 估值分析/，文件名与主报告 Ch8 交叉引用一致（默认 项目名称_估值报告.html / .docx + 项目名称_估值底稿.md + 项目名称_估值数据来源.md）。
2. 严禁以"仅手写 MD / 通用名 report.md"替代双格式产物。手写 markdown 仅为引擎源输入，须经脚本渲染成 HTML/Word 才算交付。
3. 引擎生成的 HTML/Word 为权威交付物，不得对其正文/表格/署名做人工二次修改（footer 由 equity-valuation 的 build_report_assets.py 统一注入）。源 markdown 仅可做引擎兼容的结构性准备（如删去与引擎 footer 重复的署名行），不得改动任何估值结论与参数。
4. 主报告 Ch8 须显式交叉引用：独立交付物见 估值分析/项目名称_估值报告.html 与 .docx。
5. 联动默认出「完整版」而非摘要版（v1.11.21 固化）：联动调用 equity-valuation 时，源 markdown 必须按 equity-valuation 的 Fixed Output Format 七节骨架撰写——①公司画像与估值场景分类；②最优模型选择与剔除理由（禁用静态 P/E 须显式论证）；③核心参数假设与数据清洗（含 WACC build-up 表，折现率各部件取值+来源）；④完整模型公式与逐步推导；⑤基准估值 + 强制 WACC×g 3×3 敏感性网格（bear/base/bull）；⑥模型局限；⑦实务修正建议。真实数据缺口按 equity-valuation Global Constraint #9 显式声明假设、禁编造；ifind 未配置或调用超时时改用公开行业数据并透明标注降级（超时判定：单次 >30 秒即视为不可用，重试上限 1 次；细则见 references/comparable-companies-database.md §0.1.1）。须同步产出 项目名称_估值底稿.md（填 semiconductor-financial-analysis 的 references/worksheet.md 骨架）与 项目名称_估值数据来源.md（数据溯源日志）。仅当用户明确要摘要版方可降级，且须注明偏离本铁律。

⚠️ 主报告（阶段1-10）双格式交付物铁律（v1.11.24 固化 · 不可绕过）

1. 主报告（完整版DD报告，覆盖阶段1-10 + 6 附录）必须同时产出 HTML 与 Word(.docx) 双格式，文件名对称：项目名称_DD报告_完整版.html / .docx，落于项目独立文件夹根目录，与主报告 Ch5/Ch8 引用一致。
2. HTML 由 templates/dd-report-template.html 经 scripts/fill_template.py 填充生成（强制从标准模板起步，禁止从零手写 HTML）；Word 由 scripts/generate_dd_docx.py（HTML→DOCX 结构映射转换器，覆盖封面/章节/表格/SFFRS 九宫格/红旗/提示框/footer，SVG 图表以「（图表：见 HTML 版）」占位）从同一 HTML 同步转换。
3. DOCX 仅做格式映射、不得改动任何分析结论与数据，其与 HTML 的内容一致性由"同源于一份 HTML"天然保证；DOCX 为权威交付物之一，不单独二次编辑。
4. 该双格式要求为默认强制，不依赖用户单独请求"生成Word版本"；若用户明确只要单一格式，须在交付说明中注明偏离本铁律。
5. ⚠️ 提示框样式块级承载铁律（v1.11.26 固化 · 不可绕过）：所有提示框（.note-box / .warning-box / .danger-box / .success-box / .verdict-box）必须以 <div> 或 <p> 等块级元素承载，禁止用 <span> 内联。误用 <span> 会使浏览器提前闭合父级 <p>、忽略垂直 margin，导致边框/背景/留白渲染错乱（某半导体设备公司 case-30 首版曾因此缺陷）。模板 CSS 已加 display:block 兜底渲染，且 scripts/delivery_check.py 检查项 1.28 硬性拦截此误用（缺项阻断、EXIT≠0）。生成/拼接正文时，警示框一律写作独立 <div class="danger-box">…</div>，不得塞进 <p> 内当 <span>。
6. ⚠️ 主报告命名铁律（v2.4.8 固化 · 影响交付校验）：主报告必须命名为 {项目名称}_DD报告_完整版.html / .docx，不得改用 {项目}_DD报告_v247.html 等自定义后缀。原因：delivery_check.py 检查项 1.30 从主报告文件名派生项目前缀再定位阶段5/7 联动产物，命名不匹配会触发「产物缺失」误判（v2.4.8 前无兜底，现已放宽为三级候选但仍以标准命名为唯一推荐）。派生命名对称约定：
   • 主报告：{项目}_DD报告_完整版.html / .docx
   • 阶段5：财务分析/{项目}_财务分析报告.html / .docx
   • 阶段7：估值分析/{项目}_估值报告.html / .docx（另附 {项目}_估值底稿.md、{项目}_估值数据来源.md）
7. ⚠️ HTML 交付物只读分发铁律（v2.4.8 沉淀 · 防结构破坏）：生成后的报告 HTML 禁止用在线编辑器 / 文档预览器打开并回写保存。实测此类编辑器会重写 DOM——<h2> 标签全部丢失、注入数千个 data-page-node-id 标记，导致 1.22（竞争格局）/1.8（Ch8 五标准 h2）/1.23（目录一致）集体误报、EXIT≠0。发现此类误报时，用项目内构建脚本重新生成 HTML 后复检，不得手工改结构。自动防线：scripts/delivery_check.py 检查项 1.34（v2.4.9）在最前置 fail-fast 检测此类污染（编辑器回写标记超阈值或 <h2> 数为 0 即阻断并跳过后续检查），无需人工判断——详见上文「交付物 HTML 结构完整性（检查项 1.34）」。

技能联动：与 semiconductor-financial-analysis 财务分析引擎（⚠️ 强制协同）

本技能在阶段5（财务尽职调查）默认强制联动技能 semiconductor-financial-analysis 作为财务分析引擎，由其负责严格的六步 SOP 财务推演（外部景气预判→竞争力映射→四大财务拆解→量化风险识别→景气预判→结论），恪守"仅基于原文、不估值、不谈股价"的纯财务分析纪律。本技能自身的财务核查（含 SFFRS 8 维造假检测、三支柱财务验证）继续作为可信度前置保留，不冲突。

⛔ 同名技能陷阱与唯一入口纪律（v3.1.3 固化 · 必读）

机器上同时存在两个「财务分析」技能，名字高度相似，必须区分：

技能	定位	渲染器	本管线是否使用
semiconductor-financial-analysis	半导体六步 SOP	约 38 KB	✅ 唯一正确
financial-statement-analysis	通用「八看」财报体检	约 23 KB	❌ 禁止用于 DD 阶段5

二者 scripts/generate_report.py 不同源，功能差异是实质性的：半导体版独有目录、书签、

PAGEREF 页码引用、标题层级回归护栏、SOP 标注自动剥离；通用版全部没有。用错引擎时产物

照样落盘、页脚却署名另一个技能，Word 版无目录无页码。

引擎路径的唯一权威源是编排器：scripts/orchestrate_dd.py 的 DEFAULT_FA / DEFAULT_EV

常量。凡在会话里手工拼写引擎脚本路径（而非经编排器调用），一律视为违规操作——

v3.1.2 轮即因手工拼路径误选通用八看引擎，导致阶段5 产物由错引擎渲染、而 1.30 判据满分通过。

判别产物是否由正确引擎渲染（1.30 已内建此校验）：读 HTML 页脚「本报告由…」行——

FA 须含「半导体」与「财务分析」，EV 须含 equity-valuation 或「股权投资估值」。

禁止全文搜关键词：标的名本身含「半导体」，全文搜会 100% 误通过。

• 检测与触发（强制）：进入阶段5 启动财务分析时，必须通过 Skill 工具尝试加载 semiconductor-financial-analysis。加载成功 → 强制协同，由财务分析引擎完成六步严谨拆解；加载失败（技能不存在）→ 降级回退内置财务核查逻辑，并在报告中显式标注"未启用半导体财务分析引擎"。不可因用户未主动要求而跳过尝试加载。
• 分工：
  • semiconductor-equity-investment-dd → 判定财务可信度（SFFRS 8 维造假检测、三支柱验证、红旗）、提供标的/赛道/数据室材料上下文，并产出主报告（HTML）。
  • semiconductor-financial-analysis → 在清洗后的数据上套用六步 SOP（赛道差异化会计口径、8 大类风险量化阈值、杜邦/周转修正、国产替代红利量化），输出六大章节财务分析报告与底稿，作为阶段5 的严谨推导子节 + 独立底稿附出（不破坏 DD 报告标准模板结构）。
• 衔接点：本技能提供的归一化财务数据与可比公司集，直接喂给 semiconductor-financial-analysis 的横向对标步骤；本技能 SFFRS 造假评分作为数据可信度前置，财务分析引擎不再重复做可信度核查。
• 循环防护（单向 loop guard）：阶段5 调用 semiconductor-financial-analysis 仅用于财务拆解推导，严禁其反向再调本技能（避免 DD→财务→DD 递归）；该财务分析引擎亦严禁调用 equity-valuation（估值不在其范围）。单向调用：DD →（阶段5）semiconductor-financial-analysis，绝不反向。
• 可用性：semiconductor-financial-analysis 为用户级技能（位于 ~/.workbuddy/skills/），跨项目默认可协同；仅当完全无法加载时降级内置财务核查。

⚠️ 阶段5 交付物铁律（v1.11.18 固化 · v1.11.19 修订命名规则 · v1.11.20 强制完整版 · 不可绕过）

1. 阶段5 财务分析产物必须由本引擎（位于 semiconductor-financial-analysis skill）的 scripts/generate_report.py 渲染为 HTML + Word(.docx) 双格式，落于项目独立文件夹 财务分析/，文件名统一为 项目名称_财务分析报告（如 某毫米波射频标的_财务分析报告.html / .docx；可选配套底稿 项目名称_财务分析底稿.xlsx），与主报告 Ch5 交叉引用一致。
2. 严禁以"仅手写 MD / 仅给 XLSX / 通用名 report.md"替代上述双格式产物——某混合信号标的首版曾仅交 MD+XLSX 被纠正。手写 markdown 仅为引擎的源输入（命名同样须为 项目名称_财务分析报告.md），必须经脚本渲染成 HTML/Word 才算交付。
3. 引擎生成的 HTML/Word 为权威交付物，不得对其正文/表格/署名做人工二次修改（署名与 footer 由 semiconductor-financial-analysis 的 scripts/generate_report.py 统一注入）。源 markdown 仅可做"引擎 markdown 子集兼容"的结构性准备（报告标题设为首个 #、章节用 ##/###、删去与引擎 footer 重复的署名行），不得改动任何分析性结论与数据。
4. 主报告 Ch5 须显式交叉引用：独立交付物见 财务分析/项目名称_财务分析报告.html 与 .docx（示例：财务分析/某毫米波射频标的_财务分析报告.html）。
5. 【v1.11.20 新增 · 联动默认「完整版」】 联动调用 semiconductor-financial-analysis 时，喂给引擎的源 markdown 须按 semiconductor-financial-analysis 的 references/worksheet.md 全六步 SOP 骨架撰写，默认出完整版而非摘要版，具体要求：
   • 六章齐全且严格对应 SOP 顺序（外部景气预判 → 竞争力映射 → 四大财务拆解 → 量化风险识别 → 景气预判 → 结论），不得压缩为「每步 1 表 + 1–2 段摘要」的精简写法；
   • 逐单元格标注原文出处（审定报表期次 / 材料解析章节 / 公开行业数据来源），真实数据缺口一律填「原文未提供」并降级结论强度（依 worksheet 第九章缺口补救规则），禁止编造或默认达标；
   • 套用 semiconductor-financial-analysis 的 references/track_templates.md 对应赛道专属子模板（如 IC 设计须含存货库龄/跌价、流片成本、产品矩阵毛利分层）；
   • 竞品对标须按 semiconductor-financial-analysis 的 references/knowledge.md 第七章四步筛选锁定可比组，无法满足则声明「可比组不完整」并降级；
   • 景气预判须含情景分析表（基准/上行/下行，明确假设边界并标注为推演非历史事实）；
   • 因 ifind 未配置或调用超时（单次 >30 秒无返回，重试上限 1 次）而改用公开行业数据（SIA/WSTS/行业协会等）时，须透明标注「公开行业数据（ifind 未配置·降级）」或「公开行业数据（ifind 超时·降级）」——两种标注不得混用，详见 references/comparable-companies-database.md §0.1.1。
   • ⚠️ 铁律第3条（引擎产物不得人工二次修改）不变：上述「完整版」要求针对源 markdown 撰写质量，引擎渲染出的 HTML/Word 仍为权威交付物、不得改其内容；若用户明确只要摘要版，可降级但须在交付说明中注明偏离本铁律第5条。
6. 【v2.6.11 新增 · 落盘命名优先级裁决 · 强制】 阶段5/7 联动的落盘路径以本技能口径为准——财务分析/{标的}_财务分析报告.{md,html,docx} 与 估值分析/{标的}_估值报告.{md,html,docx}（含配套底稿/数据来源），与主报告 Ch5/Ch8 交叉引用严格对齐。该裁决已同时写回 semiconductor-financial-analysis v1.3.3 与 equity-valuation v1.7.6 的 SKILL.md（「联动场景的落盘让渡」条款），自本版起三技能对同一产物的落盘路径口径唯一。
   • 历史教训（勿重演）：v1.5.x—2.4.x 时期两引擎各自按自身默认命名落盘，已实证分叉——FA 口径 {标的}财务分析报告/财务分析报告.* 6 份（某军品射频 SiP 标的、某 RISC-V 标的、某混合信号标的）、EV 口径 {标的}-{YYYYMMDD}/ 12 份（某军品射频 SiP 标的、某 RISC-V 标的）。根因不是任一方写错，而是两个技能同时定义了同一产物的落盘路径、且缺优先级裁决条款——「A 强制调用 B」的架构必须显式声明联动场景以谁的约定为准。
   • 不构成对 EV 纪律的违反：equity-valuation 明文「Never mix multiple targets in one folder」在联动场景同样成立（估值分析/ 归属单一 DD 项目目录），两口径的唯一差别是目录命名形态，不是「是否混目录」。

技能联动：与 semiconductor-investment-report 投资建议书（下游衔接执行）

定位与原则（收口联动 5 铁律，v2.4.5 固化）：

① 只执行技能、不做框架定义——本段仅规定「何时、以何种输入衔接 semiconductor-investment-report」，不定义任何五书/投资框架；

② 喂入投资建议书的资料均不脱敏——DD/FA/EV 三产物与项目原始材料均以原文形态交付；

③ 收口询问点置于「DD 主报告 + FA + EV 三份报告」生成之后——先跑完三报告与 delivery_check，再提示用户是否运行投资建议书；

④ 暂不出 PPTX——若后继 semiconductor-investment-report 升级为强制出 PPTX 再另行开启；

⑤ 冲突裁决默认「收口件对分歧重新标注」——投资建议书须全列分歧点并标注【信息冲突】，不得择一隐瞒。

本技能在「DD 主报告 + 阶段5 FA + 阶段7 EV 三份产物」齐备后，可作为 下游衔接执行 的入口，将成果交付给 semiconductor-investment-report（投资建议书）技能生成产业投资建议书。该技能遵循 零编造原则（所有内容 100% 锚定原始资料、缺失标注「资料暂缺」）与 不估值/不谈股价/不做多空判断 纪律——其「不估值」的精确含义是：不做新的估值测算，但消费本技能阶段7 EV 产物中已有的估值信息，填写其第十/十一章对应章节。

• 触发时序（强制）：进入收口阶段前，必须先后完成 ① DD 主报告（HTML+Word）→ ② 阶段5 FA 引擎（HTML+Word 双格式）→ ③ 阶段7 EV 引擎（HTML+Word 双格式 + 底稿 + 数据来源）→ ④ delivery_check（EXIT=0 才可交付）。仅在以上四步完成、三报告齐备之后，才进入收口询问（铁律③）。
• 双源输入（建议书「项目原始资料」）：
  • 分析层：DD 主报告 + FA 报告 + EV 报告（三产物，满足其零编造锚定原则）；
  • 事实层：项目原始材料文件/目录（BP/白皮书/尽调摘要/财务数据/团队履历等，不脱敏，铁律②）。
• ★ 必请示纪律（v2.8.4 强化 · 与 1.41/1.46 绑定）：semiconductor-investment-report 不在 FA/EV 的「默认强制联动」范围内——FA 与 EV 是「不问也做」，IR 是「必须问」。三产物齐备后，AI 须以 AskUserQuestion 一次性问清两件事：① 是否衔接 IR（approved / declined）；② 若衔接，执行方式（本轮执行 / 新会话执行 / 暂缓）。两项答复分别经 --set-decision … --evidence "…" 与 --execution-mode <值> 回填清单。

不可自行裁决的两个情形：ⓐ 不得因「上一轮已 approved」就不再问——整目录复制会让旧清单连同旧授权一起进入新项目，1.46-b（输入路径归属）与 1.46-c（main_report_sha256 绑定）专门拦这种跨轮继承，编排器的同轮守卫也会把 user_decision / execution_mode 重置为 pending；ⓑ 不得把「本轮要不要跑 IR」自行降格为「待办·建议新开会话」（2026-10-09 某 VCSEL 光芯片标的实测形态）。重跑项目时：主报告重跑 → main_report_sha256 变化 → 上一轮授权自动失效 → 必须重新问一次。这是设计意图，不是骚扰。

• 编排器 handoff（推荐路径）：scripts/orchestrate_dd.py 已内置 --proposal-mode ask 与 --raw-materials 参数。以 ask 模式重跑编排器，会在三报告生成后、delivery_check 前输出「收口交接清单」（{name}_收口交接清单.json + 打印），含三产物路径、原始材料路径、输出形态（DOCX+HTML，铁律④）、冲突裁决（reannotate，铁律⑤），并提示用户决策。该清单仅做交接物准备，不跨 workspace 调用投资建议书脚本——实际生成由用户另行显式触发 semiconductor-investment-report 技能执行。【v2.7.6】清单含 execution_mode 字段（本轮执行 / 新会话执行 / 暂缓）：approved 后执行方式必请示、经 --execution-mode 回填，1.46 硬阻断校验——AI 不得自行裁决执行方式。
• 循环防护（单向 loop guard）：DD →（收口）semiconductor-investment-report 为单向衔接；投资建议书技能严禁反向再调本技能或 FA/EV 引擎，避免收口链路递归。
• 独立性声明对齐：semiconductor-investment-report 其 SKILL.md 第210行已补「可被 DD 管线在用户显式授权后衔接执行」条款；本技能不自动串联，须经用户确认（ask 模式）方可衔接。
• 可用性：semiconductor-investment-report 位于独立 workspace D:/WorkSpace/投资分析报告Skill/.workbuddy/skills/（作者同为本技能作者），需用户显式激活/授权后衔接，本技能不假定其常驻可用。

引用文件列表

案例库（cases/目录）

质量规则

1. 完整性检查：所有必填字段必须有值或明确标注"无法获取"
2. 交叉验证：关键数据（财务数据、产能数据、客户验证）必须有至少两个独立来源
3. 红旗覆盖：每个模块必须输出红旗扫描结果
4. 细分行业适配：必须识别公司所属细分行业并加载对应适配器
5. 证据标注：所有事实陈述必须附带证据来源和可信度等级
6. 投资建议明确性：最终必须给出明确的投资建议（建议投资/有条件投资/不建议投资）
7. 竞品对比强制：报告必须包含3个强制竞品对比表格（五维度对比表 + 技术指标对比表 + 竞品威胁评估表），即使在IC备忘录模式下也不可省略
8. 公开信息交叉验证：每次DD必须至少执行快速验证（实体清单筛查+失信筛查+经营状态+重大诉讼），标准/深度验证由投资阶段决定
9. 文件解析质量：用户上传的文件必须经过智能解析（详见file-parsing-strategy.md），扫描版PDF关键数字需标注OCR精度，多文件间数据冲突必须标注
10. 定制化数据请求清单：报告必须自动生成5维定制（已有材料+细分赛道+投资阶段+已发现红旗+竞品差距）的数据请求清单，按P0/P1/P2分级，L1红旗必须有至少2项跟进请求
11. 访谈智能分析：所有管理层访谈必须使用智能纪要模板（四分类标注：📌承诺/⚠️风险/🔀矛盾/🫥含糊），每位受访人完成可信度5维评估，多人访谈后执行交叉验证，访谈发现必须联动注入红旗表/证据索引/数据请求清单
12. 半导体财务造假专项检测：财务DD必须执行8维度造假检测（R&D资本化/收入确认/存货/CapEx/政府补贴/关联方/Fabless成本/综合评分），生成SFFRS综合评分（0-100分），L1红旗≥2项时SFFRS≥41分，4条信号联动规则必须检查
13. 多格式输出一致性：当用户选择多种输出格式时，各格式间核心数据必须一致（红旗数量/投资建议/SFFRS评分/关键财务指标），竞品对比3表和SFFRS评分在所有格式中均不可省略（PPT至少保留精简版）

写作质量纪律（v2.4.2 固化 · 借鉴投资建议书 Agent 升级版系统指令）

来源：用户「投资建议书生成 Agent 升级版系统指令」§三（核心写作总纲）明确治"内容单薄、表述零散、只甩信息不阐释"的文风病。DD Skill 此前仅在结构/校验层发力（1.23 目录一致 / 1.25 重述 h3 / 1.32 图表对齐），文风层缺护栏；本纪律补此缺口。仅借鉴其写作工艺，不照搬其"零外推"约束——DD Skill 的强制外推模块（1.11 退出情景 / 1.12 政策催化 / 1.13 断供压测）为投决特性，必须保留。

撰写报告叙事章（Ch1-4 / Ch7 / Ch9）时，除表格、红旗清单、明确分点条目（投资亮点 / 风险点 / 数据请求清单 / 资金用途 / 投后建议）外，须恪守三条：

1. 事实+阐释双结构，禁止只甩信息：每个核心信息点不能仅孤立陈述事实，须同步解读其业务意义与投资语境（"处于什么阶段、意味着什么、对项目有何影响"）。仅基于资料内信息做逻辑推导，不新增外部数据 / 行业常识 / 第三方结论。
   • 反面：公司完成 28nm 制程流片。
   • 正面：公司核心产品已完成 28nm 制程全流程流片验证，标志产品从实验室研发迈入量产验证周期，为下游客户导入与批量交付奠定工艺基础。
2. 正文全段落连贯表达，禁止碎片化短句：所有正文论述模块须以连贯专业段落呈现（总起—分述—小结），用"具体来看 / 在此基础上 / 从产业视角看"等连接词串联；不得把正文拆成零散短句 / <li> 罗列。
3. 数据讲趋势与结构，禁止只列数字：财务 / 经营 / 技术数据须结合上下文说明趋势特征、结构意义与对标关系，不孤立抛数值（可优化表述逻辑，但不得自行计算资料未给的增长率、不做超出资料的归因）。

自动校验：scripts/delivery_check.py 检查项 1.33（软警告·不阻断）机械检测叙事章 <h2>/<h3> 小节是否"仅含 ≥2 个 <li> 而无 ≥40 字连贯段落"的碎片化罗列，命中即软警告建议补"事实+阐释"段落。该规则永不阻断交付（EXIT 不受其影响），属文风补强提示。

判据与豁免（v2.4.8 对齐 writing-quality-discipline v1.1.1，消除判据漂移）：命中前先过三道豁免，避免对合规研报体例误报——

• 表格豁免：小节内已含 <table> 即视为已做结构化表达（"引导段+表格+清单"是研报标准体例），跳过；
• 分点即段落：<li> 平均长度 ≥40 字，说明每个分点本身即完整论述段落（属优秀写法），跳过；
• 清单体豁免：标题命中豁免词（亮点/风险/清单/数据请求/红旗/投资逻辑/团队履历/建议/投后/资料/附录/要点/行动/条款/条件/备注/自检/核查/事项/速览/问题/目录/大纲/术语/声明/免责/参考等）的小节，分点是其体裁要求，跳过。

语言纪律：去机器腔（v2.8.9 新增 · 校验项 1.60 · 软警告不阻断）

为什么单列一节：2026-10-28 某GaN机器人芯片公司（C-93）交付后，用户反馈「很多表述不符合人类的表述方式，AI 味太重，看起来费脑」。当时 49 项契约全绿、数字与结论零错——语法没错、数字没错、契约没错，病在句法密度。这是铁律 22 教训的重演：新增一类产物缺陷形态，就必须同步新增一条产物级校验项，否则「全绿」只是一张纸。

三个病灶（实测，非感觉）。 四件套 9.7 万汉字逐项统计：

1. 每句都在自我解释——「这意味着／换言之／也就是说」全篇 22 次。潜台词是「怕你没看懂，我再翻译一遍」。人类写作者不这么干，他默认读者能看懂。删掉这些连接词，九成句子仍然通顺。
2. 机械编号枚举——「其一…其五」几乎出现在每一处图表判读，且严格对称、每点都是「事实＋判断」。读者被迫在编号里找重点，而编号本身不表示重要性排序。
3. 一句塞太多信息——FA 平均句长 40.3 字、最长单句 156 字（DD 210 字）；一个句子里五组数字、四处引号、四个分号。人的工作记忆一次只拿三四个组块，超过就得回读。

八条硬规则（由 scripts/style_check.py 机械校验，阈值以每千汉字或句数占比归一）

判定口径：FAIL＝超阈值 2 倍（明显机器腔，须改写后复检）；WARN＝超阈值未达 2 倍（建议改，不阻断）。1.60 只出软警告，EXIT 不受影响，理由同 1.33：这是文风问题，不是交付阻断项。

★R8 的段落口径（v2.9.3 修复，勿再按行判）：R8 数的是「读者眼中的一段」——html 按块级闭合标签（</p>／</li>／</div>／</h1-6>）与 <br> 切段，md 按空行切段且列表项各占一块；源码换行一律不算段落边界。旧实现按换行切段，而 html 一个 <p> 常跨多行源码，于是一个段落被打散成 N 行、每行只剩 1—2 个「其N」，R8 恒报 0 段——这是长期假阴性（漏报，非误报）。全库标定：319 份产物中 5 份 DD 报告由 0 转 1—4 段（某SiC衬底标的 2／某光刻胶材料标的 1／某X射线晶体定向仪标的 4／某车规 SoC 芯片公司 2／某硅光检测公司 2），逐条复核均为真阳性（「可确认的信息有四条：其一…其四」这类同段枚举）。自检命令：python scripts/style_check.py --selftest（13 条断言：R8 段落 7 条两侧都验——多行段落／div 卡片 <br>／md 硬换行该抓，3 项、分段落书写、md 列表项不该抓；句长切句 5 条；排版权同源 1 条）。v2.9.4 补齐同一根因的另一半：句长族 R1a／R1b／平均句长原先同样按换行切句，段落硬换行多则句长被切碎、指标偏低——偏差方向固定为低估，门禁只会漏报不会误报。现由 sents_from_blocks() 统一按逻辑段落切句。to_text() 仍未动（它的输出是 R3—R7 的计数底本与 /千字 归一分母），故 R3—R8 与字符数逐位不变：712 份样本冻结项漂移 0 份，而 31 份报告由「句长三项全绿」转「至少一项不绿」，DD 报告占多数（模板生成的 HTML 带缩进换行，段落跨行最多）。

三条软规则（不可机械判定，靠写的人自觉）

• S1 不立稻草人。 别先说「这不是 X，而是 Y」，直接说 Y。只有读者真的会往 X 想的时候，才值得先把 X 提出来。
• S2 动词要具体。 「形成判断」→「判断」；「存在缺口」→「缺」；「进行了测算」→「算了」。
• S3 允许口语连接。 「另外」「顺带说一句」「这点要小心」「说得直白些」——正式报告也需要呼吸感，不必每句都端着。

与上文三条写作纪律的关系（必读，否则执行时打架）：上文 1—3 条治「碎」（禁止只甩信息、禁止碎片化短句），本节治「绕」（禁止长句与过度解释）。两条合起来的正确区间是——段落连贯（每节有 ≥40 字连贯段落）＋ 单句 ≤45 字 ＋ 真清单才用列表。冲突时以本节阈值为准，因为它可机械判定。补件清单、数据请求清单这类真清单，改成分行列表反而是加分（既降 R8 又降 R1），不算碎片化。

正反例（取自 C-93 真实句子）

反：财务与信息基础是本案的短板，且短板的性质不是「数据难看」而是「数据不存在」：无审计报表、无三表、无股权结构，2025 年营收并存 8,828 万元与 11,068 万元两个互斥口径（差 1.25 倍），复合增长率宣称 68.829% 而三种算法均不复现，订单宣称 2.29 亿元而明细可复算仅 6,493 万元，单台芯片价值与出货均价背离 16.01 倍

正：本案最大的短板在信息基础，不在数据难看。没有审计报表，没有三表，没有股权结构。2025 年营收有两个口径，8,828 万元和 11,068 万元，差 1.25 倍。复合增长率材料写 68.829%，三种算法都算不出来。订单宣称 2.29 亿元，明细能对上的只有 6,493 万元。单台芯片价值和出货均价差 16.01 倍。

一条 108 字的句子拆成六句，信息一条没少，读者不用一口气扛五个数字。

校验与豁免（写之前先读，否则会把真问题当误报）

python scripts/style_check.py <报告.md 或 .html> [--list 30] [--json]

• HTML 模式不判 R7：html 的 <strong> 大量由模板生成（卡片标题、L1-0X 编号、表头），统计必误报。以 md 源为准。
• 两种模式都剔除表格整块：单元格内以「；」分隔的短标签会被切成伪长句（DD 首测即出现该假阴性）。
• 切句不按「；」：中文分号是句内停顿，按它切会把「其一…；其二…」切成短句，掩盖真正该拆的长句（同一轮第二个假阴性，已修）。
• 清单式段落判为长句属真阳性，不是误报——应改分行列表。

实测基线（某GaN机器人芯片公司 FA，2026-10-28）：改前平均 42.8 字／R1a 18.5%／R1b 43.7%／R3 0.89／R4 3.44／R7 5.34／R8 1 段，FAIL 5 项 WARN 4 项；改后 28.2／1.9%／14.4%／0.18／0.61／1.34／0 段，九项全 PASS，字符数 29,884 → 29,223（−2.2%），数字多重集除两处应修口径外零变动。改文风不必删内容，删的只是冗余句法。 适用域（先确认量的是什么，再吵指标）

本节判据面向报告产物，即 DD / FA / EV / IR 交付物里的叙事段。它不适用于技能文档与规范说明（SKILL.md、references/*、CHANGELOG.md）。理由是结构性的，不是标准松紧问题：规范必须把被检词本身列出来当示例（「这意味着／换言之／也就是说」），必须写规则反例（「不是 X，而是 Y」），必须加粗规则名与病灶标题。这三件事命中 R5 / R3 / R7，但一条都不是文风缺陷。

实测证据（2026-10-28，三份 SKILL.md 新增的「语言纪律」节各自单独扫描）：破折号 0／千字、R1a 0%、平均句长 25.0—28.1 字，全部达标；R3 恒为 1.15—1.23／千字（各 1 次，全是规则反例）、R5 恒为 3.44—3.68／千字（各 3 次，全是被检词列举）、R7 为 10.33—18.40／千字（规则名与标题加粗）。九项 FAIL 全部落在这三条上，且全部可归因到明确的规则结构。

由此得出一条通用纪律：判据上线时必须同时声明适用域。缺少适用域声明时，使用者第一次拿它去扫规范文档就会得到一片红，接着要么开始怀疑判据、要么开始改写规范里的必要示例，两种处置都是错的。这与此前「HTML 模式不判加粗」是同一类事后补丁，区别只在这次的边界划在文档类型上。

交付物 HTML 结构完整性（检查项 1.34 · v2.4.9 新增 · 硬阻断）

为什么要单列一项：交付物 HTML 可能被预览面板静默回写，此时 1.22/1.8/1.23/1.24 会集体报错，看起来像"报告写错了"，实际与内容质量无关。1.34 在最前置拦截并直接退出，避免污染文件产出误导性结论。

机理（2026-09-04 实测取证）：WorkBuddy 内置预览面板采用腾讯文档 Janus 编辑器内核（证据位于 WorkBuddy 本体 resources/app.asar 偏移 191,237,787 的 direct-dom-sync.ts，注释原文「JanusDataModel → iframe DOM 单向同步…按 data-page-node-id 打补丁」）。它把 HTML 解析为自有数据模型后序列化回写原文件，无需用户做任何保存动作；回写版本字节级恒定，说明是面板缓冲区在回写而非重新渲染。

判定（命中任一即阻断，EXIT=1 并跳过后续检查）：

• 编辑器回写标记元素数超阈值：data-page-node-id / data-node-id / data-block-id ≥100、mce-* ≥20、contenteditable ≥5；
• <h2> 小节数为 0（DD 报告章节骨架基准 49）。
• 软警告（不阻断）：<h2> 数 1~9，骨架疑似部分丢失。

两档差异化处置（按是否检出编辑器标记区分，避免误报归因）：

• 带回写标记 → 判"被回写污染"：用项目构建脚本重新生成（或从 _备份_* 恢复干净版），校验与生成期间勿用预览面板打开，确需预览先复制"分发副本"。
• 无回写标记但 h2=0 → 判"报告自身骨架缺失"（如早期项目误用 <h1> 承载章节，或文件为修复脚本残留碎片）：按 templates/dd-report-template.html 的 h2 骨架重建，与回写污染无关。

说明：本项与独立技能 writing-quality-discipline 的 check_writing.py 碎片化判据同源同参（阈值 40 字、三道豁免一致），两处判据须同步演进；但 DD 流水线不联动该技能（独立性铁律），仅共享判据标准。

⚠️ 防中断编排纪律（最高优先级 · v1.11.31 固化 · 不可绕过）

问题根因：某 BLDC 驱控芯片标的 DD 首次执行时，主报告生成后 FA/EV 引擎与 delivery_check 未一次跑完，流水线在「主报告已出、交付校验未过」中点被长对话摘要截断，需用户多次「继续未完成的任务」续跑。本纪律从流程上根除该中断面。

强制规则：

1. 后段必须一次性编排执行：主报告生成器（build_{公司}_dd.py）产出 _{公司}_DD报告_完整版.html 后，必须立即在同一执行批次内运行 scripts/orchestrate_dd.py 一次跑完后段——阶段5 FA 引擎渲染 + 阶段7 EV 引擎渲染 + delivery_check 校验。禁止在主报告生成后停下、等分多轮对话由用户「继续」才补 FA/EV/校验。
2. 编排器幂等可恢复（v2.8.4 修订跳过语义）：orchestrate_dd.py 幂等——但跳过条件不再是「产物存在」而是「产物不早于渲染源」。FA/EV 的 .html 存在且不比对应 .md 旧才跳过，并显式打印 [⚪] 已存在且不早于渲染源，本轮未重做；源更新过则自动重渲染。调用方式：

   python scripts/orchestrate_dd.py --project-dir "已分析项目/{公司简称}/" --name {公司简称}
   # 项目重跑（口径/数据变更）：必须强制重做
   python scripts/orchestrate_dd.py --project-dir "已分析项目/{公司简称}/" --name {公司简称} --force-all

项目重跑专用纪律（v2.8.4）：对既有项目重跑 DD 时（口径修正、数据更新、版本升级复跑），一律加 --force-all，不得依赖「已存在即跳过」；单侧重做用 --force-fa / --force-ev。2b. 收口清单先于 delivery_check 生成（v2.8.4 顺序修正）：编排器现在在 FA/EV 之后、delivery_check 之前写出 {公司}_收口交接清单.json。原因：1.41 / 1.46 读的就是这份清单——原「dc 全绿才发清单」形成死锁（清单旧 → 阻断 → 不全绿 → 不重发），且首轮清单不存在时 1.41 一直处于「跳过」，收口询问从未被真实校验。清单内含 main_report_sha256，用于把授权绑定到签发时的那一版主报告。

1. 被摘要截断后的恢复动作：若会话仍被摘要截断，不得重新从零生成主报告，直接重跑第 2 条的 orchestrate_dd.py 即可自动续跑 FA/EV/校验（已成功步骤跳过），直到 delivery_check 返回 EXIT=0。
2. 编排器默认路径（可 --fa-engine/--ev-engine/--delivery-check 覆盖）：FA 引擎 semiconductor-financial-analysis/scripts/generate_report.py、EV 引擎 equity-valuation/scripts/build_report_assets.py、校验 semiconductor-equity-investment-dd/scripts/delivery_check.py。引擎调用 cwd 固定为其脚本目录，保证内部相对 import/文件读取正确。
3. 退出码语义：编排器 0=FA/EV 齐备且 delivery_check 全绿（可交付）；1=存在失败步骤（修复后重跑续接）；2=前置缺失（主报告 html 或引擎脚本找不到）。
4. 写作前先读交付契约速查卡（v2.5.1 新增）：撰写任何章节前先读 references/delivery-contract-cheatsheet.md，

把硬阻断契约（SFFRS=9 / 红旗≥8 / <h2> 无属性 / 附录 appa–appf / 条件模块字面关键词）直接写进骨架。实测教训：上海某 x86 CPU 标的首轮 13 项踩空，全靠「跑校验 → 读源码 → 修补 → 重跑」迭代 4 轮才全绿；契约前置可压到 1 轮。

1. 收口询问不可省略（v2.5.1 新增 / v2.5.2 默认开启 · 易漏）：--proposal-mode 默认已是 ask，

因此首次跑编排器时就应带上 --raw-materials <项目原始材料路径>，一次跑通即同时完成FA/EV、交付校验与收口清单，无需二次补跑：

   python scripts/orchestrate_dd.py --project-dir "已分析项目/{公司简称}/" --name {公司简称} 
          --raw-materials <项目原始材料路径>

输出 {公司简称}_收口交接清单.json 后，显式询问用户是否衔接 semiconductor-investment-report生成投资建议书。脚本只出清单不代为询问——不得据「编排器跑通」推定收口已完成。v2.7.4：回填 approved 必须附答复证据——--set-decision approved --evidence "用户答复原文/落点"；1.41 对「approved 且 decision_evidence 为空」视同 pending 硬阻断（2026-10-02/03 两轮越权自答由此漏网）。v2.7.6：approved 后执行方式必请示——「衔不衔接」的答复不等于「怎么衔接」；执行方式（本轮执行 / 新会话执行 / 暂缓）须以 AskUserQuestion 请示用户（可与决策询问合并为同一次提问），按答复一并回填：--set-decision approved --evidence "…" --execution-mode 本轮执行；1.46 对「approved 且 execution_mode 为空且项目目录无建议书产物」硬阻断（2026-10-09 某 VCSEL 光芯片标的「approved 被单方面降格为待办」实测暴露）。仅在确需静默时才显式传 --proposal-mode none。

（v2.6.3 起本步骤已有机械落点）询问取得答复后必须立即回填决策：

   python scripts/orchestrate_dd.py --project-dir "已分析项目/{公司简称}/" 
          --set-decision approved --evidence "用户答复原文/落点" --execution-mode 本轮执行
   # 用户明确不需要衔接 → --set-decision declined（approved / declined 均为正常终态）

清单里的 user_decision 初始为 pending；delivery_check.py 检查项 1.41 在其为pending 时硬阻断交付。由此「压根没问」与「问了但用户拒绝」被区分开：前者永远pending、无法自愈；后者回填 declined 即闭环。

2026-09-16 实测教训：本条纪律此前已在 SKILL.md 明文标注「易漏」、编排器默认 ask、

清单与决策提示均已自动产出，却仍被漏执行——因为整条链路没有可检查的落点。

纯纸面纪律必然复发，故 v2.6.3 把询问结果物化为文件字段并由 1.41 机械拦截。

⚠️ 上下文预算纪律（最高优先级 · v2.6.17 固化 · 不可绕过）

问题根因（2026-09-24 实测取证）：单次 DD 的「最小必读集」实测 334,711 字符——delivery_check.py 占 33.9%、references/html-report-output.md 占 21.9%。回合边界经常落在管线中段（读参考 + 多次重渲染之后、主报告尚未生成之前），该轮以「无交付物」结束，用户必须发「继续未完成的任务」才能续跑。

为什么必须写进技能、不能只留在记忆里：用户级记忆 ~/.workbuddy/MEMORY.md 实测为 4,000 字符硬上限，超限即字符级腰斩并在注入末尾打 ... (user memory truncated)——该文件现 23,677 字符、83.1% 从未进入任何一次对话，其中恰含本节纪律。记忆会截断，技能不会：故本纪律以本技能为唯一权威源。

强制规则（每次 DD 执行必遵守）：

1. 一次性产出自交付物：每个报告用「一次写全脚本 + 一次运行」产出。禁止 Write → 多次 Edit → 重跑 的增量式脚本拼装——它成倍放大回合数，把交付物推到回合边界之后。
2. 预算花在生产上、不花在读上：契约不确定时只读最小片段（几行签名 / 按检查项编号定位），绝不读完整模板或完整历史脚本；要复用历史脚本就 copy 成新文件当起点再改。「少读大文件」不是观感问题，而是预算问题——每多读一段，回合边界就更靠近交付物之前。
3. 不让回合结束在中间步骤：若逼近回合上限，最后一步必须是已产出的交付物（present_files）或一条能跑完剩余流程的单命令；绝不以「中间 Edit / 状态更新」收尾。
4. 长管线优先用单条后台命令跑到底：把「解析 → 生成 → 渲染 → 校验」串成一条脚本一次启动，使其越过回合边界也能自洽完成，不依赖逐步在线。

读法约束（针对本技能两个最大体量文件）：

• 读 scripts/delivery_check.py 前先定检查项编号（1.1—1.44），再按编号定位片段；禁止整文件读入（该文件约占最小必读集的 1/3）。
• 校验输出按项取用（v2.6.18）：先 --list 看检查项索引（序号 / 状态 / 检查项编号 / 首行），再 --grep <编号或关键词> 只看命中的输出块（支持 --grep A,B 多项）。实测某毫米波射频标的 40 段输出：默认 3,240 字符 → --grep 1.39 651 字符（↓约 80%）。筛选只影响显示：汇总行恒报全局 ✅/❌/⚠️/ℹ️ 计数，未被命中的 ❌ 另列清单，退出码与默认模式一致——筛选绝不隐藏失败。
• 读 references/html-report-output.md 时分节读（offset/limit），单次不超过 ~400 行。

与上一条纪律的分工：「防中断编排纪律」管后段不被漏执行（主报告之后 FA/EV/校验一次跑完）；本条管前段不把预算耗在准备上。两者互补、不可互相替代——实测教训：上一条上线后中断仍在发生，因为其 7 条一条都不涉及上下文预算（全机 32 个技能内该主题备份数为 0）。

⚠️ 联动件完整独立报告纪律（最高优先级 · v2.7.9 固化 · 不可绕过）

定位裁决（用户 2026-10-16）：FA / EV / IR 联动件一律是「完整独立报告」，不是 DD 主报告的摘要附件——IR 联动件（投资建议书）从 DD、FA、EV 及用户提供的原始资料中抽取相关信息重组；FA/EV 联动件必须由 FA/EV 技能按其完整六步 / 七节 SOP 产出，并执行其技能内「各步到位标准 / 交付前三问」自检。

强制规则：

1. 禁止旁路薄稿：不得为满足 1.30 存在性校验而绕开 FA/EV 技能 SOP 手写摘要稿。历史实证：某DRAM IDM标的（C-88）FA 联动件 6.6K 字符、拆解节零表格零 h3 分级、M1—M8 压成单张汇总表，在旧密度档（≥3K）下「门禁全绿」漏网，而全流程独立产出样本实测 30.8K——密度差 4.8 倍。
2. 产物级兜底（1.49 v2.7.9 档）：密度基准表扩档——FA 全文 ≥25K / EV ≥18K；FA 核心节 ≥2K·常规节 ≥1.2K、EV 推导/网格节 ≥3K·常规节 ≥1K；FA 结构判据（字数可注水、结构不可）：拆解节定量表格 ≥4 张、h3 分级 ≥4 个、M1—M8 逐模块小节 8 模块齐备。权威源唯一：references/density-baseline.md——本技能不复制 FA 技能「各步到位标准」文案，只查产物形状，两侧以指针互引（铁律 12/14，SFFRS 双份漂移同源教训）。
3. 分节阈值不含「目录」占位节（渲染器自动生成正文目录，源 md 中的占位节 0—4 字符非缺陷）。
4. 存量告警按批消化：新档位上线即对存量管线联动件（某军品射频 SiP 标的/某 GPGPU 算力芯片标的/某引线框架材料标的/某电子特气标的/某 BLDC 驱控芯片标的/某前道量检测设备标的等）产生软警告——属真实欠账非误报，登记台账按批回修，不阻断交付（铁律 2：软警告标定，连续 3 项目零误报再议硬阻断）。

交付前强制验证（⚠️ 不可省略）

根本原则：从下一个项目开始，报告生成必须遵循"从模板填充，非从零创建"原则，并在交付前执行完整的delivery-checklist.md检查。

生成方式强制规范

❌ 错误方式（容易导致纰漏）：

# 从零创建HTML（容易遗漏模板元素）
html = "<html><head>...</head><body>..."
html += generate_ch1(...)
html += generate_ch2(...)

✅ 正确方式（从模板填充，确保无纰漏）：

# 1. 读取标准模板
with open('templates/dd-report-template.html', 'r', encoding='utf-8') as f:
    template = f.read()

# 2. 在模板中填充内容（模板已包含所有强制元素）
report = template
report = report.replace('{{COMPANY_NAME}}', '示例公司')
report = report.replace('{{CHAPTER1_CONTENT}}', generate_ch1(...))
report = report.replace('{{CHAPTER2_CONTENT}}', generate_ch2(...))
# ...

# 3. 执行交付前检查清单（自动）
check_result = run_delivery_checklist(report)
if not check_result['pass']:
    raise Exception(f"交付前检查未通过：{check_result['failed_items']}")

# 4. 保存
with open('output.html', 'w', encoding='utf-8') as f:
    f.write(report)

交付前检查清单（自动执行）

在生成报告后、交付前，必须自动执行references/delivery-checklist.md中的全部检查项：

检查脚本：references/delivery-checklist.md §七包含Python检查脚本（含 check_desensitization / check_skill_version_semver），生成报告后必须执行。

故障排查（v2.8.1 新增 · 出错先读这一节）

delivery_check.py 的每条 ❌ 行首都带一个契约短码 [E1xx]，退出时还会汇总一份「失败项错码索引」。遇到失败不要先读文案，先看码：

❌ [E143] 跨文档估值数字契约不一致（1.43 硬阻断）：
...
── 失败项错码索引（详见 references/troubleshooting.md）──
  [E143] 跨文档估值契约

三条排障纪律：

1. 一次只改一处，改完复跑全量。 脚本有 fail-fast 项（1.34 / 1.42）会阻断并跳过其后全部检查，后面的 ❌ 常是前一条的连带噪声；修完第一条必须重跑，再看剩下几条还在不在。
2. 退出码不可信。 Windows / Git Bash 下 $? 常为 0。判据是让脚本自己写日志再读日志，不是看退出码。
3. --skill-dir 与报告级检查互斥。 前者只跑三道打包前门禁（EPS1—EPS3），完全不跑报告级检查，两者必须分两次跑。别把「三道门禁绿」误读成「报告也绿」。也别把「三道门禁绿」误读成「可以打包」——第四道 EPS4（发布包脱敏审计）不在本命令里，须对 staging 另跑 scripts/audit_names.py（见「发布打包纪律」第 6 条）。

失败行若没有短码，说明该项尚未绑定契约编号——这本身是校验器缺陷，会在索引末尾以「另有 N 条失败未带契约编号」列出，请记录并补编号，不要用关键词猜它属于哪一项（猜错比不标更有害）。

静默降级清单（v2.8.1 起显式可见）

以下三处降级在正常路径下不会出现，但一旦出现即意味着该项校验没有真正生效，统一列在输出末尾的「本次运行的显式降级」块中：

历史版本中这三处均为静默 skipped——表现在输出上就是「这一项没出现」，用户无法区分「通过」与「跳过了」。

改校验器之后（v2.8.2 新增 · 修门禁的人必读）

改 delivery_check.py 的验收线不是「我这次要验的那项变红了」，而是零退化 + 门禁未变哑，两步都要跑：

# ① 零退化：已知样本的 FAIL 数与 EXIT 码须与改动前逐项一致
python scripts/delivery_check.py <已知全绿项目>/xxx_DD报告_完整版.html
# ② 门禁未变哑：10 类历史真事必须仍被拦住
python scripts/negative_tests.py --baseline <某已完成项目目录>

为什么第 ② 步不可省：改校验器最坏的后果不是崩溃，而是某项永久返回 pass 却无人知晓——输出看起来和通过一模一样，用户永远不会来投诉。v2.8.1 已实锤 5 处静默 except（修了 3 处），这类缺陷只能靠主动注入发现。此前曾用人工构造的残缺 HTML 验证过 E134 / E137，验完即删，下次改脚本须从头再造；negative_tests.py 就是把那次一次性劳动固化下来。

配套动作：用 --checker 指向改动前的备份脚本跑同一用例，确认它在旧版上失败——证明用例有区分力，而不是永远绿的假测试。同理，若某天 negative_tests.py 需要「放宽」某个用例才能通过，先怀疑校验器退化了。

交付前自检

在生成最终报告前，必须完成以下自检：

• [ ] 基础信息表所有必填字段已填写（或标注无法获取及原因）
• [ ] 技术三支柱（可行性/量产/供应链）均已验证
• [ ] 所有红旗问题已分级并给出处理建议
• [ ] 竞品深度对比3表完整：五维度对比表 + 技术指标对比表 + 竞品威胁评估表（⚠️ 强制，不可省略）
• [ ] 公开信息交叉验证已完成（至少快速验证：实体清单+失信+经营状态+重大诉讼）
• [ ] 文件解析数据质量已校验（L1字段级+L2交叉+L3语义三层校验通过）
• [ ] 定制化数据请求清单已生成（P0/P1/P2分级+5维定制来源标注+红旗跟进请求+竞品差距请求）⚠️ 强制，不可省略
• [ ] 访谈智能分析已完成（智能纪要四分类+可信度评估+交叉验证+访谈发现已联动注入红旗表/证据索引/数据请求清单）⚠️ 如有访谈则强制
• [ ] 半导体财务造假8维检测已完成（M1-M8全部执行+SFFRS综合评分+4条信号联动规则已检查）⚠️ 强制，不可省略
• [ ] 多格式输出核心数据一致（红旗数量/投资建议/SFFRS评分/关键财务指标在所有格式间一致）⚠️ 如生成多种格式则强制
• [ ] 退出情景表 + LP 约束检查项已落地（联动 exit-and-lp-structure.md §4.1/§4.2）⚠️ 凡材料含退出/LP/交易结构资料（募集说明书/合伙协议/LP名单/对赌回购/IPO时间表/并购意向等，见 §4.0 触发规则）则强制，二者缺一不得交付
• [ ] 政策催化估值建模已落地（联动 policy-catalyst-valuation.md §2/§3）⚠️ 凡材料含税收优惠（如所得税率15%）/国产化采购占比/大基金任一类资料（见 §0 触发规则）则强制：须含"政策调整列" + 裸估值/含政策估值双栏对照，缺项不得交付
• [ ] 断供压力测试已落地（联动 export-control-dynamics.md §3 四步法）⚠️ 凡材料含进口依赖/海外垄断/受管制品类/国产替代逻辑任一类资料（见 §0 触发规则）则强制：Ch6/Ch7 须含海外依赖清单+断供传导链+替代窗口期+红旗定级，仅定性叙述不得交付
• [ ] 数据时效标注已落地（联动 periodic-review-triggers.md §0）⚠️ 凡报告引用管制清单/大基金/税收窗口/可比估值等外生变量，或标的数据截止日与出具日跨度≥12月则强制：封面/方法论章须标注"行业基准数据截止日" + 过期变量加 ⚠️ 时效警示，缺项不得交付
• [ ] 案例库强制入库已落地（联动 cases/ ⚠️ 每次完成DD项目交付后强制）：已生成脱敏案例 cases/case-XX-*.md 并更新 cases/case-library-index.md，脱敏 0 真实名/人名残留（缺项不得视为项目闭环）
• [ ] 执行摘要回写核对已完成（v2.5.4 新增 · 强制）：Ch0 的估值口径 / 三支柱得分与名称 / 红旗数量与级别 / 交割条件条数与内容 / 回报测算数值，已与第 3—10 章逐项核对一致；估值口径已与阶段7 估值引擎的最终加权结论统一（禁止正文定稿前冻结 Ch0）
• [ ] 案例库索引结构校验已通过（v2.5.3 新增·强制）：python scripts/validate_case_index.py 返回 EXIT=0；「案例总览 / 红旗严重度对比 / 案例文件」三方 C 编号集合一致、无 NN→ 行号污染、无空行断表与 … 截断（未通过不得视为项目闭环）
• [ ] SFFRS 计分方向已显式声明（v2.5.5 新增 · 强制）：§5.5 已标注「造假风险分·分值越高风险越高」及档位划分，未使用反向（稳健度）计分（缺项由 1.35 软警告提示）
• [ ] 执行摘要与正文关键数字已一致（v2.5.6 新增 / v2.5.7 扩展 · 强制 · 硬阻断）：Ch0 的估值区间与中枢、裸估值区间、一级红旗数、SFFRS 综合分已逐项与 Ch8 加权结果 / Ch9 红旗汇总 / §5.5 综合评分比对一致；且 §5.5 内如引用红旗数量（「本项目一级红旗 N 项」）已与第 9 章红旗汇总段逐字一致（由 1.36 六项子校验机械拦截，任一不符即阻断交付）
• [ ] 模板 SFFRS 九宫格为 9 槽位（v2.5.7 新增 · 强制）：M1–M8 + 综合评分，与 references/semiconductor-financial-fraud-detection.md §9 的维度定义对齐；不得退回「应收账款/营收比」等财务比率旧槽位（旧槽位仅 4 个，既违反 1.1–1.4 的「恰好 9 个」判定，也与 M1–M8 语义脱节）
• [ ] 封面读者自证性已达标（v2.5.8 新增 · 强制 · 硬阻断）：封面含 cover-tag（报告类型）与 cover-title（标的全称），禁用非法标签 <h0>，且封面用到的每一个 class 都必须在 <style> 中有 .类名 定义——自创 class 名（如把 summary-val 写成 summary-value）不会报错，只会静默丢失全部样式（由 1.37 机械拦截）；封面结构一律照抄 templates/dd-report-template.html 的封面契约，历史产物可用 python scripts/refresh_cover.py <报告.html> 一键回修（缺项不得视为项目闭环）
• [ ] 分发副本与源文件 sha256 一致（v2.5.9 新增 · 强制 · 硬阻断）：_分发副本/ 内每份 .html/.docx/.md 均与同相对路径源文件逐字节一致，且主报告本体已在副本中；源文件改动后必须重跑同步再复跑本项——否则副本静默停在旧版本，用户拿到的分发件与已修复报告不是同一份东西（由 1.38 机械拦截，未通过不得视为项目闭环）
• [ ] 报告类型字号可读性（v2.6.4 追加 · 强制 · 硬阻断）：cover-tag 的 CSS 字号不低于 16px——封面要同时回答「这是什么报告」与「是谁的报告」，报告类型一旦被压成小字徽标，读者就无法一眼判断报告类别。阈值 16px 即「裸渲染」时浏览器的默认字号（也就是 v2.5.8 记录的缺陷态本身），故定在此处可同时拦住「回退成小字」与「退化成无定义」。由检查项 1.37 的 COVER_TAG_MIN_PX 子判据机械拦截；未显式声明 font-size 给软警告（提示显式声明以免疫上下文漂移）**
• [ ] SFFRS 综合分可复算（v2.6.1 新增 · 强制 · 硬阻断）：§5.5 已写出八维分值、均分取值与上浮系数是否触发，且综合分 = round(八维等权均分 × k)（财务维度 L1≥2 时 k=1.2；41 分为披露下限而非上浮值，低于须附拆解）可由第三方复算通过；档位标签与造假风险分区间一致；未自拟算法（缺项由 1.39 机械拦截，未通过不得视为项目闭环）
• [ ] 提示框内无标题标签（v2.6.2 新增 · 强制 · 硬阻断）：所有提示框容器（verdict-box/note-box/warning-box/danger-box/success-box/interview-card/ann/who/cred）内部未使用 <h1>–<h4>，结论框标题用 <div class="verdict-title">；未通过会导致 Word 目录整体错链，由 1.40 机械拦截，未通过不得视为项目闭环）
• [ ] 收口询问已闭环（v2.6.3 新增 · 强制 · 硬阻断）：已向用户显式提出「是否衔接 semiconductor-investment-report 生成投资建议书」，并按答复把 {项目}_收口交接清单.json 的 user_decision 回填为 approved（衔接）/ declined（用户已知情并决定不衔接）；停留 pending 即「收口询问未闭环」，由 1.41 机械拦截，未通过不得视为项目闭环（清单缺失或老清单无该字段时仅软警告）；v2.7.4：approved 回填须附 --evidence（用户答复落点），证据为空视同 pending**
• [ ] 收口后执行方式已请示（v2.7.6 新增 · 强制 · 硬阻断）：user_decision = approved 后，执行方式（本轮执行 / 新会话执行 / 暂缓）已以 AskUserQuestion 请示用户并按答复把 {项目}_收口交接清单.json 的 execution_mode 回填（经 --execution-mode）——AI 不得自行裁决「当轮跑还是新会话跑」，也不得单方面把 approved 降格为待办；approved 且 execution_mode 为空且项目目录无建议书产物即「执行方式未经请示」，由 1.46 机械拦截，未通过不得视为项目闭环（清单缺失 / 非 approved 时跳过；老清单如建议书已实际产出则兼容放行）
• [ ] Word 版导言区达标（v2.6.6 新增 · 强制 · 硬阻断）：Word 版目录已另起一页（封面与目录之间存在分页符），且封面要素（报告类型「投资尽职调查报告」+ 密级声明「CONFIDENTIAL」）已真的落进 DOCX——两类缺陷在 HTML 里都没有可观测形态（网页无「页」概念；密级声明只丢在 DOCX 渲染路径上），故此前 41 项校验全绿放行。由 1.42 check_docx_intro_layout 机械拦截；修复方式：用当前版 generate_dd_docx.py 重新渲染（渲染器已在目录前强制分页并修正类名匹配），未通过不得视为项目闭环（未生成同名 .docx 时仅软警告）**
• [ ] 财务数据已完成交叉验证
• [ ] 出口管制风险已评估
• [ ] 估值分析使用了至少两种方法
• [ ] 投资建议明确，与红旗扫描结果一致
• [ ] HTML报告可在浏览器中正常渲染
• [ ] 敏感信息已妥善处理

使用方式

用户："帮我对这家芯片公司的BP做一份投资尽职调查"
（技能将引导用户提供材料，或基于已有材料启动分析）

用户："生成IC备忘录，重点关注技术风险"
（技能将生成压缩版IC备忘录，技术风险部分加重）

用户："帮我准备一份数据请求清单"
（技能将生成针对半导体行业的定制化DD清单）

用户："这家公司的专利有没有侵权风险？"
（技能将启动专利与IP DD模块）

注意事项

• 本技能不提供法律意见，IP风险和合规风险分析建议咨询专业律师
• 财务分析基于用户提供的财务报表，不替代审计工作
• 出口管制评估基于公开信息，复杂情况建议咨询专业合规顾问
• 所有输出物均为投资决策参考，最终投资决定由用户做出

版本更新记录

当前版本：v3.1.3（2026-11-09）｜完整版本演进见 CHANGELOG.md

交付前三问（固化 · 交付前强制执行）

本节为交付流程节点，与机械门禁同级——不是建议。任何一份对外产物（DD/FA/EV/建议书）在跑完 delivery_check 后、交付前，逐问执行并留存结论。

1. 四源承接完整性——报告每个主题是否已从「原始资料 + DD + FA/EV/估值 + 数据源」四源承接？逐章核对：上游报告有承载章节的内容，必须已引用（含表格与数据），不得只引原始材料。
2. 密度对标——各节体量对照 references/density-baseline.md（或本技能到位标准）：低于下限 → 扩写或书面声明材料不足原因（写进交付物，不写进过程记录）。
3. 读者视角预演——模拟投委会三问：「这章支撑得了投资决策吗？」「哪个数字没有出处？」「哪一节读起来像摘要而非分析？」任一答不上 → 回到对应节补强。

暂缺标注纪律：用户未提供材料的部分，一律显式标注「【资料暂缺】/待补充＋缺口清单（缺什么、去哪补）」；禁止以省略替代标注，禁止在无材料处编写内容。「零暂缺」须与材料完备度交叉验证——材料单薄而零暂缺 = 漏标注，而非内容完整。

发布打包纪律（v2.7.8 · 第四门禁）

1. 发布包构建（v2.7.8 政策：案例库脱敏副本随包）：python scripts/publish_desensitize.py 从本地实名技能目录机械派生发布 staging——cases/ 全部 92 例经映射表脱敏后随包（标的名/人名/客户/投资方/代码匿名，金额与估值数字保留原值，公开可比公司数据保留）；CHANGELOG.md、references/publish-blocklist.txt、映射表（作者侧 _publish_internal/）、*.log/*.bak 排除；本地实名 cases/ 永不改写（查重三通道依赖实名），发布副本=派生量（铁律 12）
2. 泄露扫描：python scripts/publish_leak_scan.py <发布目录或zip>——按 references/publish-blocklist.txt 词表扫描，命中即阻断；零命中才可上传
3. 词表与匿名化映射同源维护（v2.8.2 加固）：新项目交付后，须把标的全名与常用简称、投资方、自然人同时补进 publish-blocklist.txt（负责"拦"）与 dd-name-map.json 的 entries（负责"换"）。三条实测教训——① 只补全名 = 扫描盲区：C-87 标的的全称在词表内，而案例正文大量使用简称（全称去掉机构后缀那两个字），leak_scan 报零命中、真名仍在包内；② 只补词表 = 脱敏缺口：C-88 某DRAM标的、C-90 某功率模块标的入库后词表已加、entries 未加，扫描会拦但替换不发生；③ 跨案例引用须用 scope: "*"：案例之间会互相引用他案实名（C-89 引用某系统级封装模块标的、C-90 引用某电子特气标的），按文件枚举 scope 必然反复漏。
4. 替换后须做畸形收口（v2.9.3 新增）：映射表多以简称收录，替换后原名的机构后缀会被孤立保留——「某简称科技」变成「某X公司科技」全称、「某全称有限公司」变成「某X标的有限公司」（v2.9.3 全包 37 处）。publish_desensitize.py 在既有「折叠 某X标的」之后加两条收口正则：…标的 + 「（股份）有限公司」、…公司／标的 + 「科技／股份」（后者要求词边界，防「某公司的科技投入」被误伤）。★两条不可合并：合并后 (?:公司|标的) 会先把「股份有限公司」里的「公司」吃掉，后缀就匹配不上（实测踩过）——化名结尾词与后缀是互斥配对。另：.py 文件不参与替换，故脚本注释里同样不得写真实标的名称。

验收判据（v2.8.5 起机械化，不再靠人工 grep）：跑 python scripts/audit_names.py <staging> --map <映射表>，EXIT=0 才可打包。它扫的是「阻断词表 ∪ 映射表」并集（六类敏感项：自然人／信用代码／标的全称／投资方／英文或拼音名／城市级中间态），并额外做结构缺口检查（词表有、映射表无 = 「负责拦、没负责换」）。comparable-companies-database.md 属公开白名单，允许保留。不能只看 publish_leak_scan.py 的 EXIT=0——它只认词表里已有的词，词表本身漏了词就永远绿灯；三种假绿的实测过程见 CHANGELOG v2.8.5。

1. 替换必须迭代到不动点（v2.8.4 新增，实测根因）：entries 是单遍替换，当规则 A 生成的新形态恰好又匹配规则 B、而 B 在「长者优先」排序中已执行过时，新形态无人处理——这不是漏登记，是机制缺陷。实测三类：源码实名先被替成一个「城市名 + 某 + 品类」的中间态，而该形态的规则已跑过 → 真名随包上架；城市级中间态同理；postpass 的「某自然人团队」折叠成「某自然人团队」后也不再收敛。修法：替换循环与 postpass 均迭代至无变化（上限 3—4 轮）。遇到「明明登记了却没替换」时先怀疑次序，不要靠继续加条目。
2. 敏感项不止人名与商标（v2.8.4 新增）：一次完整验收应覆盖六类——① 自然人姓名（含拼音与大写英文写法）；② 统一社会信用代码 18 位（标的唯一标识，比公司名更硬）；③ 标的公司中文全称与英文全称（英文常在「英文名称」字段单列）；④ 投资方/基金管理人全称（含脱敏说明段自身的真名——「X 泛化为 [某PE基金]」等于把 X 直接告诉读者）；⑤ 城市级中间态；⑥ 客户/股东实名。漏检高发点是 ②③④ 三类：它们不长得像「名字」，肉眼扫查时最容易滑过。
3. 第五门禁 EPS4：脱敏审计由脚本判定，不由纪律判定（v2.8.5 新增）：publish_desensitize.py 建完 staging 会自动调用 scripts/audit_names.py，硬命中即令自身 EXIT=1——脱敏不通过就构造不出「可打包」状态，这是把纪律物化到工具链的唯一靠得住的做法（--no-audit 仅供排障，用了必须在日志里写明「脱敏完成度未验证」）。判定三级：❌ 硬命中（词表词 / 映射表 scope:"*" 词 / 18 位统一社会信用代码，出现在成员名或内容里）、⚠️ 软提示（文件级 scope 的作用域遗留、词表↔映射表结构缺口、--generic 的人名候选）、⚪ 显式降级（缺词表或缺映射表时必须打印「该项未生效」，不得静默通过）。OOXML（docx/xlsx/pptx）走内层 XML 取文，不因「二进制读不出字」漏检；直接对 zip 跑也对齐包内形态。自证有区分力：python scripts/audit_names.py --self-test（真阳性／真阴性／作用域分级／降级显式化／文件名 -realname 残留五例）。

与第 2 条的分工：publish_leak_scan.py 是单向词表扫描（只负责拦），audit_names.py 是双向并集审计（拦 + 换 + 结构缺口）。两道都跑，不是二选一。

★protect 与 entries 不得重叠（v2.9.4 新增配置自检）：protect 在每文件替换前占位、替换后还原。若同一 pattern 同时列在 protect 与 entries，那条替换规则永远匹配不到东西——规则写了、门禁绿了、实名照旧随包发布。实测一例：某标的名两处同时存在，3 处实名随 v2.9.3 包发布，而 leak_scan 因终检词表未收录该名同样报绿，两道兜底同时失效。现 publish_desensitize.py 在 staging 之前做配置自检，两类冲突直接 EXIT=2：① 完全同名；② 碎片遮蔽——protect 收的是 entries 的子串（如 protect 收简称、entries 收「简称+后缀」），碎片被占位后大规则再也拼不出完整串。反向组合（entries 是 protect 的子串）不判失败：那是「大名字受保护、小规则只作用于他处」，属预期。教训一句话：能替换 ≠ 会替换，而终检词表是唯一不依赖替换链的兜底，重叠项必须双写。

完整变更历史与根因复盘见 [CHANGELOG.md](CHANGELOG.md) —— 该文件是唯一权威源。

本节按「必须守住的纪律 → 由谁机械守住 → 引入版本」索引化，不复述变更过程；查不到的东西一律回 CHANGELOG。

收敛史：原历史演进段 26,628 字符（约占本文件 34%）→ v2.6.11 首次下沉（18 个版本块逐一核对、0 缺失）→ v2.6.16 二次收敛为本表。

最近四版摘要（滚动保留 4 条，更早版本见 [CHANGELOG.md](CHANGELOG.md)）：

• v3.1.1（2026-11-09）：1.43(a2) 第二层根因修复：兜底词语义错误 + 跨区间回溯（不新增检查项，契约规模仍 1.1—1.63）。v2.9.9 修完量纲与词序后对 96 份 DD 主报告跑判据本体，8 份报「跨文档加权口径漂移」而两侧真值完全一致。根因一：候选词表末位是「裸估值」，而 EV 摘要标准写法「三方法加权（…）得出…中枢 17.0 亿元（裸估值等权口径…中枢 16.7 亿元）」并不含「加权结果」四字，遂落到「裸估值」抓走 16.7——裸估值是剔除政策/等权的另一口径，语义上不是加权结果，6 份因此误报。根因二：加权结果[^。]{0,40}?区间…[^。]{0,20}?中枢 是惰性嵌套，遇「加权结果 195—264 亿元与三方法交集 201—256 亿元高度重叠，加权中枢 230.0」会回溯抓走后一区间（2 份）。修复四条：① 删「裸估值」兜底、补「加权中枢」，高优先级词全不命中即跳过并明示「裸估值不参与兜底」；② 分步定位（定词位→取其后第一个区间→区间后第一个中枢），全程不回溯；③ 表格优先——先解析 EV 的 4 列 <tr>（权重须恰 100%），失败才回落文本法；④ 量纲无关比对（同量纲沿用 1.43(b) 的 ±0.5 取整界、跨量纲相对 0.5%，数字允许千分位）。标定正例 96 份：8 份误报全部归零且均改由表格行命中，某军品射频 SiP 标的 C-99 万元级仍一致，全库 MISMATCH=0；负例 2 例（人为改 EV 中枢 +74.11 万元／+1.5 亿元）均成功报出，证明 ±0.5 没放走真漂移。诚实披露：HIT 18→25、SKIP_A2 4→5，某引线框架材料标的与旧某军品射频 SiP 标的由「命中」转「跳过」——其 EV 写「三方法加权：lo = … ；中枢 = …」公式形态，原靠裸估值偶然命中，跳过是正确行为但属已知未覆盖。附带发现（不修）：96 份中 51 份 1.43 整体跳过（Ch8 表格列结构对不上即返回 0 方法行、EXIT 仍 0），即1.43 在库内 53% 的报告上从未运行，属兼容性欠账。
• v2.9.9（2026-11-09）：1.43(a2) 量纲硬编码根因修复（不新增检查项，契约规模仍 1.1—1.63）。某军品射频 SiP 标的第二轮（C-99）实测：DD 与 EV 两侧「加权结果」行完全一致（1,906.12—3,270.15 万元／中枢 2,525.89 万元），判据却报「跳过该子判据」而整体 EXIT=0。根因是 EV 侧正则把单位硬编码为「亿元」，凡万元量级标的（某军品射频 SiP 标的、C-82、C-87 一类）永远解析不出——跳过不计失败，判据形同虚设且无人知晓，属比误报更危险的假绿面。修法两条：① 单位组改 (亿元|万元)，中枢先归一到区间单位，DD 侧单位不可知故接受「同单位直比」与「1e4 换算（相对容差 0.5%）」两种映射；② 同判据另修 C-98 已记录的词序缺陷——re.search 按位置取词会让「裸估值」抢在「加权结果」之前，改按词优先级尝试并把命中词打进 detail。标定三例：某军品射频 SiP 标的（万元）由「跳过」转为「双侧一致 1906.12／3270.15／2525.89 万元」，某半导体集团 C-98 与某 TGV 先进封装标的 C-97（均亿元级）零误报、EXIT 均 0。诚实边界：(a) 方法行仍走量纲无关的数值配对路径（单位不同即失配，那属真实漂移）；库内其余万元级历史案例未逐一重跑，须另做全库回归。
• v2.9.8（2026-11-08）：新增检查项 1.63 版心容器完整性（硬阻断，契约规模 1.1—1.63）。起因：用户指出「某 TGV 先进封装标的网页版 DD 报告的页边距也有问题」，与某特色工艺代工厂报告比对后发现同模板两份产物版心不同。根因不在 CSS（两份 body／*／.container 样式逐字节相同），而在本项目装配脚本对封面 cover-meta 的整块替换正则 .*?</div>s*(?=</div>)：它靠「</div> 紧跟 </div>」定位结尾，而模板里相邻的闭合对出现在密级声明之后，正则遂在「报告用途」行的 </div> 处提前成立，把 cover-meta 自己的闭合标签留在了替换结果之外。残留的那一个 </div> 顺序关掉 .cover 与 .container，目录起全篇正文成为 body 直接子元素：浏览器实测 container 本身仍在（L150.5/W1100），其内 toc／h1／table／svg／footer 全部 L0/W1401，max-width:1100px 居中与 40px 60px 内边距双双失效。该缺陷 div 配平、标签闭合全对、1.18-c 与 1.22—1.62 全绿、DOCX 完全不受影响——50✅/0❌ 而交付物在浏览器里就是错的，与 1.26（内部元数据进标题）同属「只影响呈现、不影响校验」的盲区。1.63 的判法：用 div 栈求 .container 的 [start,end)，再比对目录／首个 h1／SFFRS 九宫格／页脚四个标志物的位置，任一越界即硬阻断；未见 container 的早期模板跳过。全库标定 101 份（2026-11-08）：命中 1 份真缺陷（某射频前端芯片公司 v2 优化版页脚逃逸）、6 份无 container 结构跳过、94 份零误报；并在某 TGV 先进封装标的报告上双向验证（修复前 4 个标志物全部越界、修复后全绿）。教训：覆盖已知结构块时，锚点须落在该块自身的闭合行（换行＋缩进＋</div>），不要用「相邻 </div>」前瞻——相邻关系的成立位置可能远在块外；同类正则一律按此复核。
• v2.9.7（2026-11-08）：执行摘要编号层级重构（改载体，不新增检查项，契约规模仍 1.1—1.62）。起因：用户指出执行摘要「3、核心投资逻辑」至「5、关键交割条件」下的要点与节标题同为「数字＋标点」，辨识度不足，且要求编号逻辑整章贯通而非只改三节。根因是载体层级错位：小节写 h3，DOCX 目录记作第 3 级、正文 emit 却映射 Heading 2（与其余各章 h2 即「N.Y」既不同级又不同形），要点则挤在裸 <p> 里，DOCX 转换连缩进都丢失——三层各说各话。改为「h1 章／h2＝N、／h4＝（n）」四层结构后与各章同构：目录 6 条由 TOC 3 归位 TOC 2、正文 Heading 2 下出现 Heading 3、1.62 的「（n）」断点组由 5 组增至 8 组。判据侧 1.48 扫描目标同步由 <h3> 迁到 <h2>（仍要求 ^d+、）；模板 Ch0 示例的 <ol> 一并改为 h4——该 <ol> 才是「1. 2. 3.」的来源，DOCX 会自动编号，与「1、」节标题完全重合，即缺陷的示范源。实测：某 TGV 先进封装标的 C-97 主报告 50✅/0❌/3⚠️（1.23／1.47／1.48／1.61／1.62 全绿）。