财务模型命名规范与版本管理指南

财务模型命名规范与版本管理指南本文档提供：一套可直接套用的文件命名模板（含5个要素的填写规则与好坏对照）、工作表命名与排序的完整清单、版本号递增的语义规则与状态标签定义、填好内容的修订日志（10条记录）、归档目录结构与发布检查清单、审计清单（20项）；本文档不提供：可自动重命名的脚本、特定机构的内部命名政策原文、版本控制软件的操作手册。（内部编号：方法框架类文档）2026-10-31序号交付物名称所在板块读者卡点用途1文件命名模板与5要素填写规则一文件名写完自己都认不出是第几版逐要素填写，好坏对照直接可判2工作表命名与排序清单二打开模型看到“Sheet1”“CopyofModel(2)”按信息流排序，用短前缀让审阅者扫一眼就懂3版本号语义规则与状态标签定义三不知道什么时候该升v2.0、什么时候v2.1就够按变更性质定大版本或小版本4修订日志（填好的10条记录）四日志写成“改了公式”“调了假设”，三个月后看不懂记录具体到格子和旧值→新值5归档目录结构与发布检查清单五旧版本散在邮件和本地，找不到董事会看到的那个文件目录模板加发布前逐项检查6审计清单（20项，含勾选栏）六命名和版本管得对不对，没有验收标准逐行勾选，失败项有补救动作7三套场景操作序列七一个人建模型和十个人协作，规范怎么分级完整版、精简版、极简版8来源层级表与能力边界声明附录判断这份指南的覆盖边界边界逐项声明一、文件命名模板与5要素文件名是审阅者接触模型的第一层信息，也是版本事故最高发的位置。“Final_FINAL_v3_USETHISONE”这类命名的问题在于，文件名本身不携带可解析的信息：它不告诉读者数据截止到哪天、这是第几版、处于什么状态、能不能对外发送。结构化命名的作用是把这些信息编码进文件名，让任何人在打开文件之前就能判断“这是不是我要的那一版”。表1文件命名5要素模板要素填写规则示例中的值常见错误①日期8位数字YYYYMMDD，取数据截止日或定稿日20260831写成“8月”“Aug25”，按字母排序时乱序②项目或标的代码内部案件代码，不写客户全称PRJ204写“某集团”，重名或泄露客户信息③模型类型3表、DCF、LBO、预算等固定缩写DCF写“财务模型”，无法区分模型种类④版本号v大版本.小版本，语义见第三板块v2.1写“最新”“终版”“打死不改版”⑤状态标签方括号内填Draft/Review/Final之一[Review]不写状态，审阅者不知道能不能引用按上表拼出的完整文件名是：20260831_PRJ204_DCF_v2.1_[Review].xlsx。这个文件名在文件夹里按日期自动排序，扫一眼能看出：数据截止2026年8月31日，项目代码PRJ204，DCF模型，第2.1版，处于审阅状态。不同来源的命名范式在要素上略有差异——有的把日期放在最前、有的把版本放在最前，有的用下划线、有的用短横线——但五类信息（日期、标识、类型、版本、状态）是共通的，缺任何一类，文件名就退化成只能靠记忆解读的标签。表2命名好坏对照坏名字为什么坏改成什么财务模型_最新版.xlsx没有日期，没有版本号，“最新”三个月后就是最旧20260831_PRJ204_DCF_v2.1_[Final].xlsxModel_v4_final_final.xlsx两套版本语义打架，“final”出现两次说明第一次不是final20260831_PRJ204_DCF_v3.0_[Final].xlsx2025年8月某集团终稿.xlsx日期不可排序，含客户名，状态用中文口语20250831_PRJ204_DCF_v1.0_[Final].xlsx预算模型（张三修改）.xlsx修改人不进文件名，进修订日志；人名混入文件名会分裂版本线20260831_PRJ318_Budget_v1.2_[Draft].xlsx日期的写法值得单独说明。用YYYY-MM-DD或YYYYMMDD的原因不是格式偏好，而是排序：按字母排序时，“20260831”永远排在“2025”之后，而“Aug25”和“Sep25”的字母顺序与时间顺序无关。月份名称的写法在跨年文件夹里会导致2026年1月排在2025年12月之前，这类错序在项目密集期会直接导致误用旧版本。二、工作表命名与排序清单工作表命名的问题是“打开之后找不到东西”。一个二十张表的模型，如果表名是Sheet1、Sheet2、Final、Final(2)、NewFinal，审阅者需要逐张点开才能知道哪张是假设、哪张是债务。命名规范的目标是让表名本身成为导航：短前缀标角色，后半段标内容，排序跟信息流一致。表3工作表命名与排序清单顺序推荐表名（含前缀）前缀含义内容命名要点100_Cover无模型名、版本、日期、用途、口径说明版本号只在这一张表定义，其他表引用它201_ChangeLog无修订日志，一行一变更放在前部，审阅者先看改了什么3IN_AssumptionsIN_输入全部假设，按收入、成本、融资、税分类输入表只放输入，不放计算4TS_TimelineTS_时间时间轴，驱动所有表的列标题三张报表的日期引用同一来源5OP_RevenueOP_运营收入驱动短前缀让滚动标签栏时可识别6OP_CostOP_运营成本与费用驱动与收入表结构对称7OP_CapexOP_运营资本开支与折旧累计折旧设上限8OP_WCOP_运营营运资本符号约定与现金流量表一致9FS_ISFS_报表利润表三张报表用FS_前缀统一10FS_BSFS_报表资产负债表表底有平衡检查行11FS_CFFS_报表现金流量表期初现金引用上期期末12DE_DebtDE_债务债务schedule清扫用MIN封顶13VA_DCFVA_估值估值输出引用FS和DE，不反向引用14SE_SensitivitySE_敏感性敏感性表数据表输入指向IN_表15CH_ChecksCH_检查全部校验行集中一页每条校验有判定标准排序的依据是信息流：先看到封面和改了什么，再看到输入和时间轴，然后是运营驱动、三张报表、债务、估值、敏感性，最后是校验。这个顺序与审阅者实际的工作路径一致——复核一个模型时，先看假设有没有改、再顺着运营到报表到估值走一遍，最后看校验页。前缀的选择不需要复杂。IN、OP、FS、DE、VA、CH这六个前缀覆盖了绝大多数模型的结构角色，短到不会让跨表引用变得冗长，又足以在标签栏宽度有限时区分表的类型。前缀在建模开始前与所有参与者约定，事后补加前缀意味着所有跨表引用都要改一遍，成本远高于一开始就定下来。表4工作表命名反例反例问题修复Sheet1、Sheet2无信息，审阅者必须逐张点开按表3改名最终版、最终版(2)两张表都叫最终版，引用时不知道指向哪张合并为一张，旧表删除Assumptions_Final_v3_USE角色前缀缺失，版本信息写进了表名改为IN_Assumptions，版本只在Cover定义计算不知道计算什么按内容拆为OP_Revenue、OP_Cost等三、版本号语义规则与状态标签版本号的作用不是“看起来专业”，而是让读者从编号本身判断变更的性质：v2.0到v2.1是小改，v2.x到v3.0是大改。没有这套语义，v4和v5之间是改了假设还是重构了模型结构，只能靠打开文件对比。表5版本号递增规则变更性质版本动作示例判定标准初始搭建完成，可内部使用v0.1→v1.0首版三表平衡、校验页通过仅刷新假设值，结构不变小版本+0.1v1.0→v1.1公式和表结构一行未动增加一列年份、增加一张辅助表小版本+0.1v1.1→v1.2原有计算逻辑不变重构债务瀑布、改变报表勾稽方式大版本+1.0，小版本归零v1.2→v2.0原有公式被替换或删除对外发布（董事会、lender、投资人）大版本+1.0v2.3→v3.0文件已离开团队控制范围小版本用于“假设刷新”，大版本用于“机制变更”，这条界线是版本管理的核心判断。把重构债务瀑布标成v1.3，读者会以为只是调了个数，打开后发现所有公式都变了，信任成本陡增；把一次假设刷新标成v2.0，版本号膨胀得很快，三个月后到了v7.0，没人记得v5和v6差在哪里。状态标签与版本号配合使用，标明文件当前能不能被引用。表6状态标签定义标签含义谁可以改能否对外发送[Draft]编制中，数字未定稿编制者否[Review]已提交审阅，编制者暂停修改审阅者批注，编制者按批注改仅审阅方[Final]已批准，作为执行或引用基准无人修改；要改则另起新版本是[Archive]已被新版本替代，只读留存无人修改仅供追溯状态从Draft到Final的单向流动是版本纪律的关键。[Final]的文件被再次编辑，等于把“已批准”的标签贴在了未批准的内容上；正确做法是从Final另存一个新文件，状态退回[Draft]，版本号小版本+0.1，改完再走审阅。[Archive]不是“旧文件”的同义词，它是“曾经被正式引用过、因此必须留存”的文件——董事会看到的那一版、lender收到的那个文件、投资决策依据的那份模型，无论后来改了多少版，原始版本必须可追溯。表7版本号与状态反例做法问题正确做法v1.0_[Final]被直接编辑Final标签失效，追溯时不知道哪个是批准版另存为v1.1_[Draft]，改完重新定稿重构模型后版本只+0.1读者按假设刷新的预期打开，发现公式全变大版本+1.0每次保存都+0.1一天产生十几个版本，版本号失去区分度只在有实质变更或对外发布时升版删除旧版本“省空间”追溯时找不到当时引用的数字移入/archive，不删除四、修订日志：填好的10条记录文件名和版本号回答“哪一版”，修订日志回答“这一版改了什么”。日志放在模型内部01_ChangeLog表，一行一变更，记录的核心是具体到格子和旧值→新值，不写“优化公式”“更新假设”这类无法复核的描述。日志不需要记录每一个公式的修补，它的目标是记录核心假设和结构的变化，让审阅者在打开模型之前就知道这一版与上一版的实质差异在哪里。表8修订日志（填好的10条记录，示例）序号日期版本状态修改位置旧值新值修改原因修改人角色审阅状态12026-08-02v0.1Draft首版搭建——项目启动，三表框架完成建模分析师未审22026-08-09v0.2DraftIN_Assumptions收入增长率5.0%4.5%管理层下调指引建模分析师未审32026-08-16v0.3DraftDE_Debt清扫比例100%75%融资协议草案条款建模分析师未审42026-08-23v1.0Review全模型——首版提交审阅，三表平衡建模分析师提交52026-08-25v1.1DraftOP_Capex第3年资本开支228250审阅意见：遗漏一项设备更新建模分析师待复审62026-08-26v1.1DraftFS_IS所得税行按利润×25%加累计亏损结转审阅意见：亏损年不应计税建模分析师待复审72026-08-28v1.2Review上述两项——复审提交建模分析师提交82026-08-30v2.0DraftDE_Debt重构清扫瀑布单档清扫两档优先顺序+MIN封顶审阅要求：按融资协议重构建模分析师待复审92026-08-31v2.0Final全模型——批准，提交lender建模负责人批准102026-08-31v2.1DraftIN_Assumptions债务成本4.80%5.10%lender反馈后敏感性情景建模分析师未审这10条记录的写法有几个要点。第2、3、5、10条的“修改位置”写到具体的工作表和行，不写“假设表”；“旧值”和“新值”并列，审阅者不用打开两个文件对比；第6条的修改原因写的是审阅意见的实质内容，不写“按审阅意见修改”——三个月后回看“审阅意见”是什么，已经没人记得。第8条的版本从v1.2跳到v2.0，因为债务瀑布被重构，属于机制变更，不是假设刷新。表9修订日志反例日志写法问题改成什么“更新了假设”不知道哪个假设、从多少改到多少IN_Assumptions收入增长率5.0%→4.5%“修复公式”不知道修了哪个公式、原来错在哪FS_IS所得税行按利润×25%→加累计亏损结转“按老板意见修改”意见内容不可追溯写明意见的实质：遗漏设备更新，资本开支228→250只记日期不记版本无法把日志条目对应到具体文件每条带版本号，版本号与文件名的版本一致日志与文件名的关系是：文件名告诉你“这是v2.0”，日志告诉你“v2.0与v1.2之间改了债务瀑布、把v1.1的所得税修复合并进来、清扫比例从100%降到75%”。两者缺一，版本信息就不完整：只有文件名，知道哪一版但不知道差在哪；只有日志，知道改了什么但不知道对应哪个文件。五、归档目录结构与发布检查清单归档解决的是“事后追溯”问题：六个月后估值被质疑、契约违约被争议、审计要求提供当时决策依据的模型，需要回答“某年某月某日，模型到底说了什么”。没有归档，这个问题的答案只能靠记忆；有归档，答案是一个确定版本的文件。表10归档目录结构层级命名存放内容规则根目录PRJ204_DCF/项目全部文件一个项目一个根目录工作区working/当前编制中的文件只放最新Draft和Review发布归档versions/每一个对外发布或用于决策的版本文件名为完整命名模板，只读旧版归档archive/被替代的旧版本从working移入，不删除外部接收received/对方发来的版本保留原始文件名，不覆盖versions/和archive/的区别是：versions/存的是“曾经被正式引用过”的版本，每一个都能对应到一次董事会、一次lender提交或一次投资决策；archive/存的是被替代但不需要单独追溯的中间版本。两者都不删除，区别只在检索优先级。发布前的检查清单把命名、版本、日志、归档四个动作串成一个闸门。表11发布检查清单（每次对外发送或提交决策前执行）序号检查项通过标准勾选1文件名符合5要素模板日期、代码、类型、版本、状态齐全☐2文件名中的版本与Cover页版本一致两处相同☐3Cover页有数据截止日、用途、口径说明三项齐全☐4ChangeLog有本次发布对应的记录版本号匹配，修改位置到表到行☐5状态标签为[Review]或[Final]不是[Draft]☐6模型校验页全部通过平衡、现金、债务闭合无失败项☐7文件已存入versions/归档路径正确☐8发送后不再编辑该文件要改则另存新版本☐六、审计清单表12命名与版本管理审计清单序号检查项判定标准失败后果补救动作勾选1文件名含8位日期可解析为YYYYMMDD按字母排序时错序重命名☐2文件名含项目代码代码可映射到项目重名或泄露客户信息补代码☐3文件名含模型类型缩写3表/DCF/LBO/预算等无法区分模型种类补类型☐4文件名含v大.小版本号格式为vX.Y版本不可比按语义重编☐5文件名含状态标签方括号内为Draft/Review/Final不知道能否引用补标签☐6无“Final_Final”“最新版”类命名全文检索无此类词版本歧义按模板重命名☐7工作表使用角色前缀IN/OP/FS/DE/VA/CH标签栏无法快速识别补前缀并更新引用☐8无Sheet1、Sheet2残留全部工作表有实质名称审阅需逐张点开重命名☐9工作表排序符合信息流Cover→Log→IN→OP→FS→VA→CH导航成本高调整标签顺序☐10版本号只在一处定义Cover页单一单元格，其他表引用版本不一致集中定义☐11小版本用于假设刷新结构未变时只+0.1版本膨胀纠正版本号☐12大版本用于机制变更重构时+1.0读者预期错位纠正版本号☐13状态标签单向流动Draft→Review→Final，未回退Final被误改另存新版本☐14ChangeLog一行一变更修改位置到表到行，有旧值和新值日志不可复核按表8格式补写☐15ChangeLog与文件名版本一致最新条目版本=文件名版本日志与文件脱节对齐☐16每个对外版本已归档versions/中有对应文件无法追溯补归档☐17旧版本未删除archive/保留被替代版本追溯断链恢复或从备份取回☐18发布前检查清单已执行表11八项全部勾选带缺陷外发重跑清单☐19外部接收版本保留原始命名received/中未被覆盖来源不可追溯恢复原名☐20归档版本状态为Final或Review不是Draft归档了未定稿核对状态☐第10项和第14项是验收的核心。版本号只在一处定义，改一处全模型跟着变，不会出现文件名v2.1、Cover页v2.0的情况；修订日志写到格子和旧值→新值，三个月后复核者不用打开历史文件就能知道改了什么。七、三套场景操作序列表13三套场景操作序列版本适用人群覆盖范围操作序列完整版投行、PE、FP&A团队，模型会对外发布表12全部20项建模前约定5要素命名和前缀→首版存versions/→每次变更写ChangeLog→升版按语义→发布前跑表11八项→发布后存versions/、旧版移archive/→交付前跑表12全部20项精简版企业财务经理、小团队（2—3人）第1—6、10—14、16项文件名用5要素模板→工作表补前缀→版本号按语义→ChangeLog记假设和结构变更→每次外发存versions/→交付前跑精简项极简版个人自用模型、学生、转行者第1、4、5、13、14项文件名写日期+v版本+状态→只在Cover定义版本号→Final不直接改、另存新版→日志记“哪张表哪行、旧值→新值”→五个动作养成习惯三套序列的差别在覆盖范围，不在原则。极简版的五个动作覆盖了版本事故中最常见的两类：文件名无法判断哪一版最新、Final被直接编辑后追溯断链。一个人建模型时，写ChangeLog到格子和旧值的习惯，比任何工具都更能防止“三个月