4、项目创建与管理：新建项目、项目结构解析、项目属性设置、保存与备份策略
在Prophet精算软件的实际应用中，项目（Project）是承载所有建模工作、数据输入、假设设置与结果输出的核心容器。无论是构建一个简单的定期寿险模型，还是搭建一套覆盖多币种、多子公司的集团级负债评估体系，项目创建与管理的规范性直接决定了后续建模效率、版本追溯能力以及团队协作的顺畅程度。本章将围绕新建项目的完整流程、项目内部结构的逻辑层次、关键属性配置以及保存与备份的最佳实践展开深入讲解，帮助您从源头建立一套严谨、可维护的项目管理习惯。
4.1 新建项目：从模板到自定义的完整流程
4.1.1 核心原理：项目文件与工作区的概念
Prophet中的项目（.proj文件）本质上是一个XML格式的索引文件，它并不直接存储模型代码或数据，而是记录了对各类子文件的引用关系、全局属性配置以及运行参数。这种设计使得项目文件本身非常轻量（通常只有几十KB），而真正的模型逻辑（.mdl）、数据表（.csv/.xlsx）和假设文件（.asmp）则以独立文件形式存在于项目目录中。理解这一原理至关重要——它意味着项目文件的完整性依赖于整个目录结构的完整性，任何单独复制.proj文件而不携带关联子文件的做法都会导致项目无法打开。
4.1.2 操作流程：新建项目的标准步骤
- 启动向导：在Prophet Professional主界面中，点击“File”菜单下的“New Project”，或使用快捷键Ctrl+N。此时系统会弹出项目创建向导。
- 选择模板：向导提供三类模板——空白项目（完全从零开始）、标准寿险模板（预置了常见的现金流模块和假设结构）、集团合并模板（适用于多法人实体汇总）。对于初学者，建议从标准寿险模板开始，以便快速理解项目结构。
- 定义项目元数据：输入项目名称（建议使用“产品线_评估时点_版本号”的命名规范，如“WholeLife_20241231_V1.0”）、存储路径（注意路径中不要包含中文字符或空格，以避免潜在的编码问题）、以及可选的项目描述。
- 设置初始属性：在向导的第二步中，需要指定基础货币（Base Currency）、评估时点（Valuation Date）和默认的会计准则（如IFRS17或C-ROSS）。这些属性在项目创建后仍可修改，但提前设置可以减少后续调整的工作量。
- 完成创建：点击“Finish”后，Prophet会自动生成项目目录结构，并在工作区中打开项目浏览器（Project Explorer）。
4.1.3 案例拆解：某寿险公司新项目创建实战
假设某中型寿险公司需要为2025年开门红产品“鑫享年年年金保险”建立精算评估模型。精算师张工在创建项目时，面临以下约束：评估需满足IFRS17和C-ROSS双准则要求，且需要支持多币种（人民币为主，部分投资资产涉及美元）。
张工的操作路径如下：
- 模板选择：选择“标准寿险模板”，因为该模板已包含IFRS17的通用假设结构，可以减少约30%的初始搭建工作量。
- 命名与路径：项目命名为“Annunity_Xinxiang_20241231_V1.0”，存储于“D:\ProphetProjects\2024\Q4\”目录下。路径中避免使用中文，防止后续在服务器上运行时出现兼容性问题。
- 属性预置：基础货币设为CNY，同时勾选“Enable Multi-Currency”并添加USD作为辅助币种；评估时点设为2024年12月31日；会计准则选择“IFRS17 & C-ROSS Dual”。
- 结果验证：创建完成后，张工检查了项目浏览器中的目录结构，确认Model文件夹下已自动生成了“Cashflow.mdl”和“Liability.mdl”两个基础模型文件，Assumptions文件夹下生成了“Economic_Assumptions.asmp”和“NonEconomic_Assumptions.asmp”。
这一案例表明，合理的模板选择和属性预置能够显著提升项目初期的搭建效率，同时为后续的双准则并行计算打下基础。
4.1.4 常见误区与总结
新建项目看似简单，但其中蕴含的命名规范、路径规划、模板选择等决策，都会对后续数月的建模工作产生深远影响。建议团队内部制定统一的项目命名和目录规范，并将其写入操作手册。
4.2 项目结构解析：理解Prophet的逻辑分层
4.2.1 核心原理：四层逻辑架构
一个标准的Prophet项目在逻辑上分为四个层次：模型层（Model）、数据层（Data）、假设层（Assumptions）和输出层（Results）。这种分层设计的核心思想是关注点分离——模型代码只负责计算逻辑，数据文件提供输入参数，假设文件管理精算假设，输出文件存储计算结果。这种架构使得精算团队可以并行工作：模型开发人员专注于.mdl文件的编写，数据团队维护输入数据表，而假设管理人员独立更新.asmp文件，互不干扰。
4.2.2 项目结构树详解
| 文件夹/文件类型 | 扩展名 | 功能说明 | 典型内容 |
|---|---|---|---|
| Model | .mdl | 存放模型代码，包含产品定义、现金流计算、准备金评估等逻辑 | Product_Definition.mdl, Reserve_Calculation.mdl |
| Data | .csv, .xlsx, .dat | 输入数据文件，包括保单明细、费率表、投资组合数据等 | Policy_Data.csv, Premium_Rates.xlsx |
| Assumptions | .asmp | 精算假设文件，包含死亡率、退保率、费用率、投资收益率等 | Mortality.asmp, Lapse.asmp, Expense.asmp |
| Results | .res, .csv, .xml | 计算结果输出，支持多种格式便于后续分析 | Liability_Output.res, Cashflow_Summary.csv |
| Scenarios | .scn | 情景定义文件，用于压力测试和敏感性分析 | Base_Scenario.scn, Stress_Interest.scn |
| Reports | .html, .pdf | 自动生成的报告文件，可定制模板 | Valuation_Report.html |
4.2.3 操作流程：如何高效浏览和管理项目结构
在Prophet的Project Explorer中，用户可以通过以下方式高效管理项目结构：
- 分组视图：点击“Group by Type”按钮，系统会按文件类型自动分组；点击“Group by Folder”则按物理目录分组。建议日常使用“Group by Type”视图，便于快速定位特定类型的文件。
- 文件依赖检查：右键点击任意.mdl文件，选择“Show Dependencies”，Prophet会以图形化方式展示该模型文件引用了哪些数据表和假设文件。这一功能在排查“模型运行时报错找不到变量”时极为有用。
- 批量导入：在Data文件夹上右键选择“Import Data”，可以批量导入多个CSV文件。Prophet会自动识别列名并映射到模型中的变量。
4.2.4 案例拆解：结构混乱导致的计算失败
某再保险公司在接手一个由外部咨询公司交付的项目时，发现项目结构异常混乱：所有模型文件都堆放在根目录下，数据文件散落在多个子文件夹中，且存在大量重复命名的假设文件。当团队尝试运行准备金计算时，Prophet报错“Ambiguous variable reference: Lapse_Rate”。
排查过程如下：
- 使用“Show Dependencies”功能检查模型文件，发现其同时引用了根目录下的“Lapse_Rate”和Assumptions文件夹下的“Lapse_Rate”，两个变量定义不同。
- 进一步检查发现，根目录下的文件是咨询公司早期版本的遗留物，而Assumptions文件夹下的是更新后的版本。
- 解决方案：删除根目录下的冗余文件，并在项目属性中设置“Strict Variable Resolution”为“On”，强制Prophet在变量引用冲突时给出警告而非静默选择。
这一案例说明，维护清晰的项目结构不仅是美观问题，更是保证计算正确性的基础。建议团队在项目启动时即制定文件命名规范（如“产品_模块_版本号.mdl”），并定期清理无用文件。
4.2.5 常见误区与总结
4.3 项目属性设置：全局参数的精细控制
4.3.1 核心原理：属性继承与覆盖机制
Prophet的项目属性（Project Properties）是全局配置的中心，其设置遵循三级继承机制：项目级属性（Project Level）→ 模型级属性（Model Level）→ 运行级属性（Run Level）。项目级属性定义了所有模型和运行共用的基础参数（如货币、时点）；模型级属性可以覆盖项目级设置，用于特定模型的特殊需求；运行级属性则在每次执行计算时临时指定，优先级最高。理解这一机制，可以避免在多个模型中重复配置相同参数，也能够在特殊场景下灵活调整。
4.3.2 关键属性配置项详解
| 属性类别 | 属性名称 | 可选值/示例 | 影响说明 |
|---|---|---|---|
| 基础属性 | Base Currency | CNY, USD, EUR | 决定所有现金流折算的基础货币 |
| Valuation Date | 2024-12-31 | 影响所有时间相关的计算，如贴现、准备金评估 | |
| Reporting Standard | IFRS17, C-ROSS, GAAP | 决定默认的报表格式和科目映射 | |
| 计算引擎 | Max Iterations | 1000（默认） | 控制迭代计算的收敛上限，过大可能影响性能 |
| Convergence Tolerance | 1e-6 | 迭代收敛精度，值越小精度越高但耗时越长 | |
| 输出控制 | Result Granularity | Policy / Product / Portfolio | 决定结果输出的聚合层级，Policy级输出文件极大 |
| Log Level | Debug / Info / Warning / Error | 控制日志文件的详细程度，Debug用于排障 |
4.3.3 操作流程：修改项目属性的标准路径
- 在Project Explorer中，右键点击项目根节点（即.proj文件），选择“Properties”。
- 在“General”选项卡中，修改项目名称、描述、基础货币和评估时点。
- 在“Calculation”选项卡中，设置迭代参数、线程数（建议不超过物理核心数的75%）、内存使用上限。
- 在“Output”选项卡中，配置结果输出格式（默认建议选择“Compressed Binary”以节省磁盘空间）、结果保留策略（如“Keep last 10 runs”）。
- 点击“Apply”后，Prophet会提示“Project properties changed. Do you want to propagate changes to all models?”——如果选择“Yes”，则所有模型将继承新的项目属性；选择“No”则仅项目级属性更新，各模型保留原有设置。
4.3.4 实战场景：多币种项目的属性配置
某跨国保险集团需要在一个项目中同时评估中国内地、香港和新加坡三个子公司的负债。项目属性配置如下：
- 基础货币：CNY（集团合并报表货币）
- 辅助币种：HKD, SGD（勾选“Enable Multi-Currency”，并设置汇率来源为“Central Bank Rates”自动更新）
- 评估时点：2024年12月31日
- 模型级覆盖：香港子公司的模型将基础货币覆盖为HKD，输出时再折算为CNY
这种配置方式使得集团层面可以直接汇总三地负债，同时保留了各子公司的本地货币视角。需要注意的是，汇率波动会直接影响合并结果，因此建议在情景分析中单独设置汇率压力情景。
4.3.5 常见误区与总结
4.4 保存与备份策略：保障项目安全的最后防线
4.4.1 核心原理：项目文件的持久化机制
Prophet的保存机制分为手动保存和自动保存两种。手动保存（Ctrl+S）会将当前所有打开的模型、假设和数据文件的引用关系写入.proj文件，但不会自动保存各子文件的内容——子文件需要单独保存。自动保存则按照设定的时间间隔（默认5分钟）将整个工作区状态写入临时文件，在异常退出时可以通过“Recover Unsaved Project”恢复。理解这一机制，可以避免“明明保存了项目，但重新打开后模型代码丢失”的困惑。
4.4.2 备份策略设计：三层备份体系
| 备份层级 | 频率 | 存储位置 | 保留策略 | 适用场景 |
|---|---|---|---|---|
| 本地自动备份 | 每次保存时 | 项目目录下的Backup文件夹 | 保留最近5个版本 | 防止误操作导致的文件覆盖 |
| 服务器每日备份 | 每日凌晨2:00 | 公司NAS或备份服务器 | 保留30天 | 应对本地磁盘故障或勒索病毒 |
| 版本控制归档 | 每次重大变更 | Git仓库（配合.gitignore） | 永久保留Tag版本 | 审计追溯、多版本并行开发 |
4.4.3 操作流程：配置自动备份与恢复
- 配置自动保存：进入“Tools” → “Options” → “General”，设置“Auto-save interval”为5分钟，并勾选“Save project before running calculations”。
- 启用本地备份：在项目属性中，勾选“Create backup copy before save”，并设置备份文件命名规则为“项目名_日期_时间.bak”。
- 设置服务器备份：使用Windows任务计划程序，编写脚本将整个项目目录（排除临时文件）复制到NAS的指定路径。脚本中应包含日志记录，便于监控备份是否成功。
- Git集成：在项目根目录初始化Git仓库，创建.gitignore文件排除以下内容：*.tmp, *.log, Backup/, Results/（结果文件通常较大且可重新生成）。每次完成重大模型修改后，执行
git commit -m "描述性信息"并打上Tag。
4.4.4 案例拆解：一次备份缺失导致的事故复盘
某咨询公司的精算团队在为客户交付IFRS17模型时，由于项目周期紧张，团队成员连续加班，忽略了每日备份。在交付前夜，一位分析师在修改模型时误删除了一个关键的假设文件，并覆盖保存了项目文件。由于本地自动备份仅保留最近5个版本，而该文件在6次保存前已被修改，无法恢复。
事故影响：项目交付延迟2天，客户产生不满；团队不得不花费大量时间重新推导被删除的假设参数。
事后复盘改进措施：
- 将本地自动备份保留版本数从5提升到20。
- 在服务器备份脚本中增加“文件完整性校验”（计算MD5哈希值），确保备份文件未损坏。
- 引入Git版本控制，要求所有模型文件在修改前必须执行
git commit，以便随时回滚。 - 建立“备份检查清单”，每日下班前由项目负责人确认当日备份已成功完成。
这一案例深刻说明，备份策略不是“锦上添花”，而是项目管理的刚性需求。在精算工作中，模型和数据的价值往往远超硬件成本，任何一次不可恢复的丢失都可能造成重大损失。
4.4.5 常见误区与总结
保存与备份策略的核心目标是“可恢复性”。一个有效的备份体系应当满足三个条件：定期执行（自动化）、可验证（定期演练）、异地存储（物理隔离）。只有将备份视为项目基础设施的一部分，而非可有可无的附加操作，才能真正保障精算工作的连续性。