name: semiconductor-equity-investment-dd
description: 半导体行业非上市公司股权投资尽职调查，面向 PE/VC/产业资本/FA/投委会/IR/券商行研/拟上市公司 CFO。覆盖私募股权、成长股权、VC/PE、并购、战略投资、Pre-IPO 等交易类型，适用于拟投项目、标的、一级市场、未上市企业的立项、投决、过会场景。可处理 BP/CIM、商业计划书、技术白皮书、流片报告、良率数据、客户验证报告、专利清单、晶圆厂产能协议、财务报表、供应链合同、访谈纪要、数据室文件等材料，生成投资尽职调查报告、IC备忘录、技术红旗扫描、数据请求清单、管理层访谈指南、财务DD草稿、技术/业务/行业/法律综合分析、估值与回报案例、投后价值创造建议等输出物。默认输出独立HTML报告，适用于内部投委会传阅。
agent_created: true

版本号规则：三段式 x.y.z；每个分段的取值须为 1–9（用户原话「从 1 开始，每逢 10 就进一位」）。

逢 10 向高位进 1 且本位重置为 1（如 2.6.9 → 2.7.1、1.9.9 → 2.1.1）；判据不是「含不含 0」——

2.6.19 不含 0 但分段 19 ≥ 10，同样违规；SkillHub 不接受两段式（如 1.9）。

注：历史版本中的 1.10.0 / 1.11.26 / 1.11.30 / 2.6.10–2.6.18 属规则启用前后的历史遗留，不追溯更名。

version: "2.7.7"
triggers:
- 半导体尽职调查
- 半导体DD
- 半导体投资
- 芯片公司尽调
- IC备忘录
- 流片报告分析
- 技术红旗扫描
- 半导体行业尽调
- 芯片投资DD
- 晶圆厂产能分析
- 半导体供应链审查
- semiconductor DD
- chip company due diligence
- semiconductor investment due diligence
- IC memo semiconductor
- 半导体并购尽调
- Pre-IPO半导体
- 半导体PE投资
- 芯片技术评估
- 半导体估值
- 半导体估值模型
- 芯片公司估值
- 可比公司法半导体
- 半导体产业链分析
- 半导体国产替代
- 晶圆涨价影响
- 芯片议价能力
- 技术路线图评估
- 芯片路线图可行性
- 半导体技术趋势
- 技术路线图风险评分
- 半导体竞品对比
- 芯片竞品分析
- 竞争对手对比
- 市场份额分析
- 竞争格局评估
- 技术指标对比
- 竞品威胁评估
- 竞争壁垒分析
- 半导体交叉验证
- 公开信息核实
- 芯片公司背调
- 实体清单筛查
- 专利有效性验证
- 半导体合规筛查
- 半导体文件解析
- PDF芯片报告提取
- 专利清单标准化
- 财务数据自动提取
- 流片报告解析
- 多文件数据融合
- 定制化数据请求清单
- 动态数据请求
- DD清单定制
- 尽调数据清单生成
- 访谈纪要自动整理
- 管理层可信度评估
- 访谈动态追问
- 访谈交叉验证
- 半导体财务造假检测
- R&D资本化造假
- 收入确认造假
- 存货造假
- CapEx造假
- 关联方交易造假
- Fabless成本操纵
- 财务造假综合评分
- DD报告Word版
- IC汇报PPT
- DD报告PDF
- 财务模型Excel
- 尽调报告多格式输出
- 立项
- 投决
- 立项材料
- 投决材料
- 过会材料
- 拟投项目
- 拟投公司
- 被投企业
- 看个标的
- 一级市场尽调
- 未上市企业尽调
- 半导体立项报告
- 半导体BP分析
- 商业计划书尽调
- 芯片公司立项
- 半导体投资备忘录
- teaser review
- CIM review
- NDA DD
- deal screening
- investment memo
- project DD
- VC DD
- PE DD
- chip IC memo
author: 依然飯特矽
contact: [email protected]
license: All Rights Reserved
copyright: "© 2026 依然飯特矽. 版权所有，保留一切权利。"
category: 金融投资
tags:
- 半导体
- 股权投资
- 尽职调查
- 一级市场
- 投资研究
- 财务分析
- 估值建模
- 芯片
- 投委会
- 并购
platforms:
- WorkBuddy

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

> 【版权与使用条款 · 请先阅读】
> - 创作者：依然飯特矽　|　反馈联系：[email protected]
> - 本 Skill 版权归创作者 依然飯特矽 所有（© 2026），保留一切权利（All Rights Reserved）。
> - 仅授权在 WorkBuddy 官方技能市场安装后"使用"：不得复制、导出、再分发源文件；不得修改、反编译或基于本 Skill 制作派生作品。
> - 使用过程中遇到任何问题、Bug 或改进建议，欢迎通过邮箱 [email protected] 反馈给创作者。
> - 欢迎投稿脱敏案例：如果你在使用中积累了有价值的 DD 案例，欢迎按脱敏规则（隐去真实公司名/人名/非公开数据，用"公司A/竞品X"泛化）整理后发送至 [email protected]，一经采纳将纳入后续版本案例库，帮助更多使用者。
> - 未经创作者书面授权，禁止将本 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> 一键回修封面与样式。

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

报告生成后，必须执行 scripts/delivery_check.py（各项目复制为 run_check.py 后运行；v2.6.11 起不再引用 delivery-checklist.md §七内嵌副本——那份内嵌副本与源码双份维护且已陈旧，已下线）。任一项未通过则不得交付。检查项 1.1—1.48（48 项编号规模；脚本实跑打印 ✅ 40 行（含 v2.7.2 新增 1.44、v2.7.3 新增 1.45、v2.7.6 新增 1.46、v2.7.7 新增 1.47/1.48；行数随报告的软警告／跳过分支浮动——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起），以及 1.24—1.48 各项。

规则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 断供压力测试 单块）。非触发型单块小节不得留孤号 X.1，改描述性 h3 或直挂 h2。
4. 根因警示：v1.11.5 及更早报告（长江存储/芯原/亿智）出现「正文被全量重写、自行发明 h2 标题、静态 TOC 未同步」的系统性错配——编号相同但含义完全不同、prescribed 小节(供应链与地缘政治/技术风险评估/SFFRS/关键成功因素等)整节消失、正文与目录对不上。自 v1.11.6 起，交付检查 1.23 强制阻断此类错配。
5. 生成器纪律：推荐做法——fill_template.py 直接填充模板现成的 h2 槽位（仅替换 <h2>…</h2> 与内容，不改标题）；若必须自定义标题，须同步改写目录 li.sec，或调用统一 scripts/gen_toc.py 由同一章节映射生成目录，杜绝双源漂移。
6. 注入 marker 锚点约定（v1.11.13 新增护栏）：模板各章节用 HTML 注释锚点 <!-- ========== 第N章 XXX ========== -->（短名，如「第1章 公司概况」「第3章 技术DD」「第7章 供应链分析」），与 TOC/标题的长名（如「第1章 公司概况与基础信息」）故意不同。generate_report.py 的注入 marker 字典 必须严格使用模板短名，误用长名会导致章节静默 fallback 到模板空占位、整章丢失（超芯星缺陷复盘）。强烈建议调用 scripts/fill_template.py::fill_report(template, sections, required) 做注入——它从模板自动提取真实锚点，并在 (a) sections 含模板不存在的锚点、或 (b) 必填章节注入后为空 时直接抛 ValueError 响亮报错，而非静默丢章。
7. h1 章标题契约与执行摘要编号形态（v2.7.7 新增）：① 目录 li.ch 条目是正文 h1 的唯一权威源——正文 <h1 id="chN"> 须与 li.ch 文本逐字一致（含「第N章」前缀），自拟章名 = 检查项 1.47 硬阻断（根因：1.23 只覆盖 h2 层，四轮执行三种形态——瑞识全无前缀/泊微·江诠半对齐/峰岹全无前缀且 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 先标定）。

规则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 连续」；任一不符即移动章节或重编号，不得带病交付。

技能概述

本技能专门用于半导体行业非上市公司股权投资尽职调查，覆盖私募股权（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/（如不存在则创建，项目产出不得放根目录）。

操作契约

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）
7. 案例库参考与入库：新项目启动时查阅案例库（cases/目录）参照同行业/同阶段案例；项目交付后须按操作契约 #9 强制脱敏入库
8. 项目隔离 + 统一归集原则（⚠️ 不可绕过）：① 每个DD项目必须在独立文件夹中开展工作；② 所有项目的文件夹必须统一归集到单一顶层目录 已分析项目/ 之下，即项目启动时即创建 已分析项目/{公司简称}/（中文名或拼音均可，如 已分析项目/通锐微/），严禁散落在工作区根目录或与其他项目混放。本报告生成的所有文件——DD报告HTML/Word、材料解析文本、提取脚本、生成脚本、图表SVG源文件、财务分析/估值分析子目录、数据请求清单、中间版本等——一律存入 已分析项目/{公司简称}/。③ 通用跨项目工具脚本集中存放于 已分析项目/_shared_tools/ 文件夹（如尚不存在则在 已分析项目/ 内创建，项目产出不得放根目录）。此规则确保项目资料可追溯、可归档、可复用，且全量集中便于统一查阅。详见「⚠️ 项目文件夹统一归集铁律（v1.11.25）」。
9. 案例库强制入库：每次完成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，未入库不得视为项目闭环。
10. 索引结构机械校验（⚠️ 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）；③ 表内混入空行把一张表切成两段、单元格以 … 截断；④ 重建时重复写入表头。因此每次案例入库后必须执行：
    bash python scripts/validate_case_index.py # 退出码 0 才算入库完成
    校验项：案例总览(7列) / 红旗严重度对比(6列) / 案例文件 三者的 C 编号集合必须完全一致（这是核心断言，任一表缺行即 FAIL）、编号连续无缺无重、无 NN→ 行号前缀污染、无表内空行断表、无 … 截断单元格、表头唯一、索引内所有 C 编号引用均已登记、红旗表计数与案例文件 共N项 声明一致（软警告）。
    插入方式纪律：补行必须用单个脚本一次性插入全部行（不得在编辑器里手工逐行粘贴，也不得多次追加），插入后立即跑校验器；脚本写回时必须在表头之前（而非分隔行之前）截断原文，否则会重复写入表头。修正既有案例文件的红旗计数时，须同时回改 case-library-index.md 红旗表对应单元格并复跑校验器。
11. 执行摘要回写纪律（⚠️ 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 严谨拆解；仅当用户明确指定"仅用内置财务核查"或该技能确实无法加载时方可跳过）
    ↓
阶段6：法律与合规尽职调查
    ↓
阶段7：估值与交易条款分析（⚠️ 默认强制联动 equity-valuation 估值引擎做严谨建模；仅当用户明确指定"仅用内置估值五法"或该技能确实无法加载时方可跳过）
    ↓
阶段8：红旗汇总与投资建议
    ↓
阶段9：报告生成与交付
    ↓
阶段10：收口询问（⚠️ v2.5.1 强化 / v2.5.2 默认开启 · 不可省略）
    ├─ 三产物齐备 + delivery_check EXIT=0 后，编排器默认自动输出收口交接清单
    └─ 显式询问用户是否衔接 semiconductor-investment-report 生成投资建议书（详见「技能联动：与 semiconductor-investment-report」章节）

> ✅ 阶段10 默认值已于 v2.5.2 改为 ask（2026-09-04 上海兆芯实测教训的固化）：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 瑞识科技实测暴露的形态）。

方法论来源

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

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

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

• 检测与触发（强制）：进入阶段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 未配置时改用公开行业数据并透明标注降级。须同步产出 项目名称_估值底稿.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 维造假检测、三支柱财务验证）继续作为可信度前置保留，不冲突。

• 检测与触发（强制）：进入阶段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 未配置而改用公开行业数据（SIA/WSTS/行业协会等）时，须透明标注「公开行业数据（ifind 未配置·降级）」。
> - ⚠️ 铁律第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 份（泊微科技、苏州异格、捷研芯）、EV 口径 {标的}-{YYYYMMDD}/ 12 份（泊微科技、苏州异格）。根因不是任一方写错，而是两个技能同时定义了同一产物的落盘路径、且缺优先级裁决条款——「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/白皮书/尽调摘要/财务数据/团队履历等，不脱敏，铁律②）。
• 编排器 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 字，说明每个分点本身即完整论述段落（属优秀写法），跳过；
- 清单体豁免：标题命中豁免词（亮点/风险/清单/数据请求/红旗/投资逻辑/团队履历/建议/投后/资料/附录/要点/行动/条款/条件/备注/自检/核查/事项/速览/问题/目录/大纲/术语/声明/免责/参考等）的小节，分点是其体裁要求，跳过。

交付物 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 固化 · 不可绕过）

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

强制规则：

1. 后段必须一次性编排执行：主报告生成器（build_{公司}_dd.py）产出 _{公司}_DD报告_完整版.html 后，必须立即在同一执行批次内运行 scripts/orchestrate_dd.py 一次跑完后段——阶段5 FA 引擎渲染 + 阶段7 EV 引擎渲染 + delivery_check 校验。禁止在主报告生成后停下、等分多轮对话由用户「继续」才补 FA/EV/校验。
2. 编排器幂等可恢复：orchestrate_dd.py 已具备幂等能力——FA/EV 的 .html 产物若存在则自动跳过，仅补跑缺失步骤。调用方式：
   bash python scripts/orchestrate_dd.py --project-dir "已分析项目/{公司简称}/" --name {公司简称}
3. 被摘要截断后的恢复动作：若会话仍被摘要截断，不得重新从零生成主报告，直接重跑第 2 条的 orchestrate_dd.py 即可自动续跑 FA/EV/校验（已成功步骤跳过），直到 delivery_check 返回 EXIT=0。
4. 编排器默认路径（可 --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/文件读取正确。
5. 退出码语义：编排器 0=FA/EV 齐备且 delivery_check 全绿（可交付）；1=存在失败步骤（修复后重跑续接）；2=前置缺失（主报告 html 或引擎脚本找不到）。
6. 写作前先读交付契约速查卡（v2.5.1 新增）：撰写任何章节前先读 references/delivery-contract-cheatsheet.md，
   把硬阻断契约（SFFRS=9 / 红旗≥8 / <h2> 无属性 / 附录 appa–appf / 条件模块字面关键词）直接写进骨架。
   实测教训：上海兆芯首轮 13 项踩空，全靠「跑校验 → 读源码 → 修补 → 重跑」迭代 4 轮才全绿；契约前置可压到 1 轮。
7. 收口询问不可省略（v2.5.1 新增 / v2.5.2 默认开启 · 易漏）：--proposal-mode 默认已是 ask，
   因此首次跑编排器时就应带上 --raw-materials <项目原始材料路径>，一次跑通即同时完成
   FA/EV、交付校验与收口清单，无需二次补跑：
   bash 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 瑞识科技「approved 被单方面降格为待办」实测暴露）。
   仅在确需静默时才显式传 --proposal-mode none。

（v2.6.3 起本步骤已有机械落点）询问取得答复后必须立即回填决策：
bash 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）。

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

> 根本原则：从下一个项目开始，报告生成必须遵循"从模板填充，非从零创建"原则，并在交付前执行完整的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中的全部检查项：

| 26 | 分发副本与源文件一致性（v2.5.9 新增 · 机械校验） | 强制（硬阻断，由检查项 1.38 自动执行）：_分发副本/ 下每个 .html/.docx/.md 须与同相对路径的源文件 sha256 逐字节一致，且主报告本体（{项目}_DD报告_完整版.html/.docx）在副本中存在。交付契约早就写明「预览只用副本、源文件保持只读」（防 1.34 的预览面板回写污染），但此前无任何机械校验——中芯宁波复核实测 6 份副本中 5 份已过期（DD html/docx、FA html/docx、EV docx 全部对不上源文件），而 36 项校验仍全绿：修复源文件后忘记重跑同步，副本静默停在修复前版本，用户拿到的分发件与已修复报告不是同一份东西，且从体积/日期完全看不出来 | 依交付校验 1.38 check_dist_copy_freshness 比对；重跑同步（源 → _分发副本，保持同相对路径）后复跑本项至 sha256 全部一致。未建立 _分发副本/ 目录时仅软警告（不影响未进入分发阶段的项目） |
| 27 | SFFRS 算法唯一性（v2.6.1 新增 · 机械校验） | 强制（硬阻断，由检查项 1.39 自动执行）：§5.5 的 SFFRS 综合分须可由八维分值机械复算——综合分 = 八维等权均分 B × k，k = 1.2 当财务维度（§5.6）L1 红旗 ≥ 2 项、否则 1.0；触发上浮时取 max(41, S)。须写出八维分值、均分取值与上浮是否触发；档位标签须与造假风险分区间一致。禁止自拟算法（旧「红旗计数 × 维度权重 × 等级权重」公式已废弃：按字面不可实现、会饱和、且未覆盖 M8）。历史案例分值口径分段见 cases/case-library-index.md 的「SFFRS 历史口径分段说明」。 |
| 28 | 提示框内禁标题标签（v2.6.2 新增 · 机械校验） | 强制（硬阻断，由检查项 1.40 自动执行）：提示框容器（verdict-box / note-box / warning-box / danger-box / success-box / interview-card / ann / who / cred）内部不得使用 <h1>–<h4>，结论框标题须用 <div class="verdict-title"> 承载。根因：scripts/generate_dd_docx.py 的 collect_toc() 按「h1/h2/h3 即目录条目」预分配书签，而 emit() 把提示框整体当普通段落渲染、不输出标题——两条遍历规则不同构，提示框内一旦出现标题标签，该条目会占住书签队列头部不放，导致其后全部标题在 Word 里错链（华太科技实测：96 条目录条目未匹配、95 条锚点顺序漂移，而 HTML 侧 39 项校验全绿）。模板 <style> 已内置 .verdict-title 定义并示范改写。 | 依交付校验 1.40 check_no_heading_in_callout 比对；把提示框内的 <h3> 改为 <div class="verdict-title"> 后重新生成 HTML 与 DOCX |
| 29 | 收口询问闭环（v2.6.3 新增 · 机械校验） | 强制（硬阻断，由检查项 1.41 自动执行）：{项目}_收口交接清单.json 的 user_decision 不得停留在 pending——须向用户显式提出「是否衔接 semiconductor-investment-report 生成投资建议书」，并按答复用 orchestrate_dd.py --set-decision approved（衔接）/ declined（用户已知情并决定不衔接）回填；二者均为正常终态。v2.7.4 升级：approved 回填必须附 --evidence（用户答复落点/原文）——1.41 对「approved 且 decision_evidence 为空」视同 pending 硬阻断（无证据的 approved 与「没问用户却自答 approved」在文件上不可区分；2026-10-02/03 英集芯、思瑞浦两轮越权自答实测暴露）。根因：本步骤早已写成显式阶段（阶段10）并被标注「易漏」，编排器亦默认 ask、门禁全绿即自动产出清单与决策提示，但脚本只出清单不代为询问，而「把问题递到用户面前」这件事此前没有任何可检查落点——清单落盘 + 提示打印在 stdout 叠加，极易被误判为「收口已完成」（2026-09-16 华太科技实测：清单与提示俱在、40 项校验全绿，用户却从未被问到）。 | 依交付校验 1.41 check_handoff_decision 比对；向用户显式询问后回填 approved/declined 即消警（清单缺失或老清单无该字段时仅软警告）；v2.7.4 起 approved 须另验 decision_evidence 非空 |
| 30 | 收口后执行方式必请示（v2.7.6 新增 · 机械校验） | 强制（硬阻断，由检查项 1.46 自动执行）：user_decision = approved 只回答「衔不衔接」，执行方式（本轮执行 / 新会话执行 / 暂缓）须以 AskUserQuestion 请示用户（可与决策询问合并为同一次提问），按答复经 orchestrate_dd.py --execution-mode 回填 execution_mode 字段。根因：1.41 只能证明「用户同意衔接」，证明不了「衔接怎么执行」——2026-10-09 瑞识科技实测：approved 被单方面降格为「待办·建议新开会话」，既不执行也不请示，交接清单形态与真实闭环完全相同、建议书却永远不出现，用户被迫回溯质询。1.46 判据：approved 且 execution_mode 为空时，项目目录亦无「投资建议书.docx」产物 → 硬阻断（老清单如建议书已实际产出则兼容放行；清单缺失 / 非 approved → 跳过，由 1.41 管辖） | 依交付校验 1.46 check_proposal_execution_mode 比对；请示用户后 --set-decision approved --evidence "…" --execution-mode <值> 回填即消警 |
| 30 | Word 版导言区契约（v2.6.6 新增 · 机械校验） | 强制（硬阻断，由检查项 1.42 自动执行）：本技能第一个直接解析 DOCX 内部结构的校验项（下述缺陷在 HTML 里没有可观测形态，只查 HTML 必然全绿）。两个子判据：① 目录须另起一页——封面末段与目录标题之间须存在分页符；② 封面要素须真的落进 DOCX——报告类型「投资尽职调查报告」与密级声明「CONFIDENTIAL」须出现在 word/document.xml 中。根因：ⓐ 分页此前依赖 HTML 的 page-break 标记，而模板只在「目录→正文」处放过、「封面→目录」处从未放过，渲染器 emit() 的注释却称「分页交给模板的 .page-break」——一份双方都没兑现的空契约，emit_cover() 的分页又只在封面 div 内部含该子元素时才触发；ⓑ emit_cover() 判密级声明写作 'confidential' in cls，而 cls 是 class 名列表、实际类名是 cover-confidential，列表成员判断恒为 False，声明被静默丢弃（2026-09-17 华太科技实测：HTML 有、Word 无，41 项校验全绿）。 | 依交付校验 1.42 check_docx_intro_layout 比对；用当前版 generate_dd_docx.py 重新渲染即同时消除两者（渲染器已在目录前强制分页并修正类名匹配）；未生成同名 .docx 时仅软警告 |
| 31 | 目录↔正文 h1 章标题逐字一致（v2.7.7 新增 · 机械校验） | 强制（硬阻断，由检查项 1.47 自动执行）：目录 li.ch 条目为唯一权威源，正文 h1（含「第N章」前缀）须与之一一对应，空白归一化后全等；自拟章名阻断。根因：1.23 只覆盖 h2 层，四轮执行三种形态门禁次次全绿（瑞识全无前缀/泊微·江诠半对齐/峰岹全无且 7 处章名自拟），2026-10-10 用户指出后回溯发现 | 依检查项 1.47 check_toc_h1_consistency 比对；正文 h1 逐字对齐目录后重新检查 |
| 32 | 执行摘要小节编号形态（v2.7.7 新增 · 机械校验） | 软警告（不阻断，由检查项 1.48 自动执行）：执行摘要（ch0）章内 h3 用「1、2、3、」编号（禁用 0.x），正文引用写「本章第 N、节」。软警告因存量报告 ≤v2.7.5 全为 0.x（铁律 2 先标定误报率） | 依检查项 1.48 check_ch0_section_numbering 提示；新报告一律「N、」形态，存量回修挂账 |

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

交付前自检

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

• [ ] 基础信息表所有必填字段已填写（或标注无法获取及原因）
• [ ] 技术三支柱（可行性/量产/供应链）均已验证
• [ ] 所有红旗问题已分级并给出处理建议
• [ ] 竞品深度对比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 已写出八维分值、均分取值与上浮系数是否触发，且综合分 = 八维等权均分 × k（财务维度 L1≥2 时 k=1.2 且取 max(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风险和合规风险分析建议咨询专业律师
• 财务分析基于用户提供的财务报表，不替代审计工作
• 出口管制评估基于公开信息，复杂情况建议咨询专业合规顾问
• 所有输出物均为投资决策参考，最终投资决定由用户做出

版本更新记录

> 当前版本：v2.7.7（2026-10-10）。完整变更历史与根因复盘见 CHANGELOG.md —— 该文件是唯一权威源。
> 本节按「必须守住的纪律 → 由谁机械守住 → 引入版本」索引化，不复述变更过程；查不到的东西一律回 CHANGELOG。
> 收敛史：原历史演进段 26,628 字符（约占本文件 34%）→ v2.6.11 首次下沉（18 个版本块逐一核对、0 缺失）→ v2.6.16 二次收敛为本表。

最近三版摘要（详情见 CHANGELOG.md）：

• v2.7.6（2026-10-09）：新增检查项 1.46「收口后执行方式必请示」+ 编排器 --execution-mode 强制（硬阻断）（起因：用户质询「收口时让我执行投资建议书为什么没执行」——瑞识科技轮收口答复 approved 后，AI 单方面把衔接降格为「待办·建议新开会话」，既不执行也不请示；用户裁决口径为「必请示」）。缺口：1.41 只能证明「用户同意衔接」，证明不了「怎么衔接」——approved 与「自行挂账」在文件上不可区分。修复：orchestrate_dd.py --set-decision approved 须同时附 --execution-mode（本轮执行 / 新会话执行 / 暂缓，缺省即拒绝 exit 3），落 execution_mode/execution_mode_at 且重跑保全；delivery_check.py 新增 1.46——approved 且 execution_mode 为空且项目目录无「投资建议书.docx」→ 硬阻断；阶段10／handoff 段／易漏段／检查项 30／交付清单勾选／纪律沉淀／交接清单模板 schema 七处契约同步。检查项总数 45 → 46。
• v2.7.4（2026-10-03）：1.41 升级「approved 须附用户答复证据」+ 编排器 --evidence 强制（硬阻断）（起因：用户质询「为什么最近收口都没询问」→ 会话 jsonl 逐条取证：10-02 英集芯／10-03 思瑞浦两轮 AI 跳过收口询问、把自拟计划文本误读为授权而直接回填 approved；用户裁决「均不追认」→ 双项目回填 declined、越权产出的投资建议书移入待处置区、分发副本 11→8）。缺口：1.41 只能拦 pending——无证据的 approved 与「自答 approved」在文件上不可区分。修复：orchestrate_dd.py --set-decision approved 无 --evidence 即拒绝（exit 3），证据落 decision_evidence/decision_evidence_at 且重跑保全；1.41 对「approved 且证据为空」视同 pending 硬阻断；阶段10／检查项 29／交付清单勾选／checklist 1.41 行四处契约同步。检查项总数仍为 45。
• v2.7.3（2026-10-01）：新增检查项 1.45「红旗清单结构完整性」（硬阻断·四子项）。缺口：红旗的分级—编号—登记—描述四项结构不变量此前全无机械兜底；且严重度类 flag-pX 是 1.39 判定 SFFRS 上浮系数 k 的输入（1.39 以「§5.6 内 flag-p0 计数 ≥2 → k=1.2」计分），类名错配可静默改写 SFFRS 结论。判据：(a) class="flag-item flag-pX">Ln- 须满足 X = n−1（p0↔L1／p1↔L2／p2↔L3）；(b) 章内卡片编号 ⊆ §9.1 汇总表登记；(c) 汇总表分级编号 01..N 连续无缺号无重号；(d) 同一编号跨清单描述的中文 2-gram 集合须有交集（撞号探测）。豁免白名单：卡片显式声明「并入／归入／合并为 Lx-nn」不计入 (b)（迪思微实测形态）。标定：129 份历史 DD HTML 语料 → 硬阻断 6 份 / 误报 0（6 份均逐条取证确认为真实缺陷：4 份共 7 处严重度类错配 + 2 份共 4 处编号撞号）。检查项总数 44 → 45。
• v2.7.2（2026-09-30）：新增检查项 1.44「第2章图表存在性与覆盖率」（硬阻断 + 软警告）+ 判据借用业界行研方法论的数据可视化纪律。缺口：v2.7.1 前第2章有图表规范、无存在性兜底——第2章堆表格不配图可直通交付（与投资建议书侧 v1.7.9 契约 I 的缺口同源）。判据：Ch2 <tr> ≥10 行而 <svg> = 0 → ❌；<tr> ≥40 行而仅 1 张图 → 软警告。阈值由 86 份历史 DD 主报告标定（Ch2 图数均值 2.55；svg=0 的 6 份均为中间产物且其 <tr> 亦为 0；4 份最新交付件全部通过）——误报 0 / 漏报 0，5 份中间产物真阳性命中。文字侧并入 references/industry-lifecycle-and-sizing.md §7.5 图表覆盖率要求（市场规模 / 分层判定 / 国产替代三分区各至少 1 图 + 图表与表格并存 + 每图必配 ≥40 字解读 + 无成图数据须显式留痕），并更新 §7.4 与附录速查卡。不联动该技能（禁用场景含单公司尽调，且自带独立渲染栈与 outputs/ 目录规范）。检查项总数 43 → 44。