模拟场景：报告说餐饮坪效偏低，但那一周有两个档口停业
以下为模拟示例。某中型体育场的运营团队在场馆项目中生成了月度商业分析。报告指出，东侧大厅通道的餐饮坪效比西侧低约30%，建议调整东侧档口的品类组合。运营经理看完后指出，统计期内东侧有两个档口因设备检修停业了五天，这部分营业额缺失，才把坪效拉低。
这类情况在场馆经营中很常见。模型只能看到接入的数据，停业、临时改价、赞助商包场这些信息如果没有进入系统，报告就会给出偏离实际的结论。人工修改的价值正在于补上这些背景。
可以改，但要先分清改的是哪一层
报告的内容可以理解为三层，每一层的修改方式和后果不同：
- 数据层：例如把停业档口的五天标记为“非营业日”，或修正一条重复导入的POS记录。数据层修改后，相关指标会重新计算，报告里受影响的图表和结论会刷新。
- 假设层：例如假设下月客流比本月高15%，或假设东侧档口改为饮品为主。这类修改不改变历史数据，而是生成新的推演结果。
- 结论文字层：例如把模型生成的建议改写成更符合团队语境的表述，或补充一段现场观察。文字修改不会触发重新计算。
回到模拟场景，正确的做法是在数据层把停业日标记出来，让坪效按实际营业天数重新计算，而不是在结论文字里直接把“偏低30%”改成“基本持平”。
人工修改标注在报告里怎么显示
所有人工改动都会在报告中留下可见的标注。数据层修改会在对应指标旁显示一个修正标记，点开可以看到修正前后的数值和修改说明；结论文字被改写后，段落左侧会出现“人工撰写”标识，并保留模型原文供对照；假设情景则以独立卡片的形式出现，不会混入基于历史数据的结论中。
这种设计的目的，是让任何读报告的人都能分辨哪些判断来自模型计算，哪些来自人工经验。场馆的商业决策往往涉及招商、租金和活动排期，读者需要知道每个结论的来源。
版本记录：每一次修改都留下了什么
在报告右上角的“版本记录”里，可以看到每个版本的生成时间、修改人、修改类型和修改说明。模型重新计算会生成一个新版本，人工修改也会生成一个新版本。任何两个版本之间可以做差异对比，差异部分会高亮显示。
如果发现某次修改有误，可以回退到之前的版本，回退本身也会作为一条记录保留。建议在修改说明里写清原因，例如“东侧A3、A5档口检修停业五天，已标记非营业日”，而不是只写“修正数据”，这样三个月后复盘时仍然能看懂。
假设情景对比：不要直接覆盖原结论
运营团队常见的另一种需求是“如果……会怎样”。例如：如果把一场周六晚间比赛改到周日下午，餐饮和停车收入会有什么变化？如果在南侧通道增加一个零售点，会不会分流现有档口的客流？
这类问题应该用假设情景来做。App允许在同一份报告下建立多个情景，每个情景独立设置参数，结果并排展示。原报告作为基准情景保持不变。这样做的好处是，管理层可以同时看到基准和几种备选方案，而不是只看到一个被改过的结果。Venue Intelligence在情景推演中会给出区间而不是单一数值，区间越宽，说明依据越少，越需要现场验证。
情景之间也可以互相比较。比如餐饮负责人建立了“东侧改饮品为主”的情景，零售负责人建立了“南侧加设零售点”的情景，两者可以合并成一个组合情景，看看同时实施时是否会互相分流。这种组合推演很难靠手工表格完成，但它依然只是推演，真正落地前需要用一到两场活动做小范围试点。
哪些内容不建议手动改
有几类内容即使可以改，也不建议直接动手。一是模型的原始计算结果，如果你认为结果不对，应该去修正输入数据或假设，而不是改输出数字。二是空间分区定义，场馆平面图和分区一旦调整，历史数据的归属会整体变化，应由项目管理员统一处理。三是跨活动的对比基线，随意替换基线会让所有同比、环比失去参照。
多人协作时的推荐修改流程
- 由熟悉现场的运营人员先在数据层补充背景信息，并写明修改说明。
- 项目管理员复核数据层修改，确认后触发重新计算。
- 各业务负责人（餐饮、零售、广告、招商）在各自板块建立假设情景，不直接改动基准结论。
- 最终由报告负责人整理结论文字，人工撰写部分会自动标注。
- 定稿后锁定版本，后续修改在新版本中进行。
更多关于场馆收入结构和活动比较的方法，可以参考体育场馆商业运营栏目。报告和版本记录会随项目一起同步到云端，换设备后同样可以查看，具体说明见换手机以后项目会不会丢。在BB体育的设计里，AI报告是讨论的起点，最终结论由熟悉场馆的人来确认。
