投行级 DCF 建模

解决什么问题

把一份 DCF 模型交给分析师或模型评审时，最常见的失败不是折现率算错，而是模型本身不可审计：DCF 表里充斥着 Python 算好之后写死的数值，敏感性分析用线性近似或占位文本填充，硬编码输入没有任何来源注释。一旦假设要改，整个模型就得重算。这个技能针对的就是这类问题——它把投行常用的建模规范固化成一套可执行的构建流程，产出物是全公式驱动的 Excel 文件，而不是一份截图报告。

核心能力

公式优先是硬约束。 所有预测、利润率、折现因子、现值和敏感性单元格都必须是活的 Excel 公式，只允许三类硬编码：历史原始输入、假设驱动项、当前市场数据。技能明确警告：如果你发现自己在 Python 里算完再把结果写进去，就应该停下来。

构建流程按十步推进：数据获取与校验（净债务、摊薄股数、历史利润率）、3–5 年历史分析、三情景收入预测（Bear/Base/Bull）、OpEx 以收入为基准建模、无杠杆自由现金流（EBIT → NOPAT → +D&A → -CapEx → -ΔNWC）、WACC（CAPM + 税后债务成本）、期中折现（0.5, 1.5, 2.5…）、终值（永续增长与退出倍数双轨）、企业价值到股权价值的桥接，最后是三张敏感性表。

验证与重算依赖两个脚本。 scripts/recalc.py 通过无头 LibreOffice 强制重算公式，scripts/validate_dcf.py 做 DCF 专项校验（终值增长率合理性、TV 占 EV 比重是否落在 50–70%）。技能要求在开始前先跑依赖检查，这两步不能跳过。

人机协作的检查点机制。 技能禁止一次性端到端构建完再给结论，而是在数据获取后、收入预测后、FCF 构建后、WACC 后、终值与股权桥接后、敏感性表后分别停下来与用户确认。另外每个硬编码单元格都要求即时写入 Source: [System/Document], [Date], [Reference], [URL] 格式的注释。

注意点

环境依赖 LibreOffice，没有它 recalc.py 无法验证敏感性表。写入公式时 Office JS 与 Python/openpyxl 的写法不同，合并单元格在 Office JS 下只能先写左上角再合并。敏感性表必须是奇数维度（5×5 或 7×7），中心单元格等于基准情形隐含股价。情景切换用 INDEX 加合并列，而不是散落各处的 IF 语句。这些约束听起来繁琐，但它们决定了模型能否被别人接手修改。

适用边界

技能本身不提供数据。它默认使用用户给定的信息和可用的 MCP 数据源，历史输入的质量和来源需要使用者自己把关。它产出的是建模框架与校验逻辑，不构成投资建议——终值假设（永续增长率、退出倍数）对结果影响极大，TV 占 EV 超过 75% 时说明估值过度依赖终值假设，这属于需要人工判断的部分。