打开App看到的第一个问题：这次记录的是什么

米兰体育App在新建记录时不会直接给出一张空白表格，而是先让使用者做一个选择：这次要建立的是"赛事项目"（Event Project），还是"用品项目"（Equipment Project）。很多第一次使用的人会觉得这一步有点多余，直接跳过或者随便选一个，等到填了十几个字段以后才发现界面里缺了自己需要的选项。这背后其实不是产品设计上的偏好，而是两类记录在数据结构上完全不同，一旦选错，后面很多字段都没法正常使用。

这个选择之所以放在最前面而不是后置到某个设置页里，是因为米兰体育App的底层数据模型从建档那一刻起就已经按照项目类型分叉了。换句话说，App并不是先建一条通用记录，再根据后续填写的内容动态判断这是赛事还是用品，而是一开始就要求明确归类，再据此调用不同的字段模板、不同的计算逻辑、甚至不同的报告输出格式。这种设计对使用者来说前期多了一步选择，但换来的是后续填写过程中不会出现"这个字段到底填不填"的困惑。

赛事项目：围绕一个有起止时间的事件展开

Event Project对应的是一场具体的体育赛事，比如一场同城联赛、一次多日锦标赛。它的核心特征是有明确的项目时间范围（Project Timeline），赛事什么时候开始布展、什么时候正式比赛、什么时候撤场，都要先划定清楚，因为后续所有的活动数据（观众交通、参赛人员住宿、场馆能耗）都要落在这个时间范围之内才会被计入核算。围绕这条时间轴，App会依次展开票务信息、交通问卷、住宿登记、场馆能源接入这几个模块，最终匹配排放因子（Emission Factor），生成一份碳足迹报告。这份报告不是一次性生成就固定不变的，具体的更新逻辑在碳排为什么会随着交通数据补充而变化里有详细说明。

用品项目：围绕一件具体的物品展开

Equipment Project对应的是一件具体的体育用品，比如一双跑鞋、一辆自行车、一支球拍。它和Event Project最大的不同是没有固定的结束时间，一件用品从购入、使用、维修、翻新到二手转让，可能横跨好几年，App记录的是这件物品在整个生命周期里发生的一系列事件，而不是某个时间段内的活动总量。每一次维修都会形成一条维修记录（Repair History），每一次状态评估、翻新、转手都会被追加进这件物品的档案里，逐渐积累成一份完整的产品护照（Product Passport）。这套记录方式的具体结构，可以参考米兰体育App怎么记录一辆自行车的维修和二手流通历史这篇文章。

两种项目在底层字段上的差别

从数据结构上看，Event Project的主键是"事件加时间范围"，一份报告对应一个封闭的核算周期，周期结束、数据补齐之后报告基本定型；Equipment Project的主键是"物品本身"，档案是开放式持续累积的，没有"核算完成"这个状态。这也是为什么Event Project里有观众规模、门票分布、交通方式占比这些聚合性字段，而Equipment Project里没有这些字段，取而代之的是购入日期、品牌型号、历次状态评分、维修与翻新记录这些跟着物品走的字段。如果把两者的表单结构简单叠加成一张表，反而会让两类使用者都找不到自己需要的字段。

这种差别还体现在数据更新的触发方式上。Event Project的数据更新大多是"批量到来"的，比如一批交通问卷集中回收、一份住宿名单整体提交，系统需要针对一批新数据重新计算受影响的分项；Equipment Project的数据更新大多是"单点触发"的，比如某一天完成了一次维修，就单独追加一条记录，不需要等待其他数据凑齐再统一处理。这种差异也解释了为什么两类项目的报告生成逻辑完全不同：Event Project有一个明确的"生成报告"动作，把截至当前的数据汇总成一份阶段性结果；Equipment Project没有这个动作，档案本身随时可以查看，不存在"生成"和"未生成"的区分。

选错类型会发生什么

假设一位用户想记录自己维修跑鞋的过程，却在新建时选了Event Project，接下来会发现表单要求填写举办地点、预计到场人数、票种分布，这些字段和一双鞋完全无关，勉强填完也无法生成有意义的报告。反过来，如果想核算一场比赛的碳排放却选成了Equipment Project，App只会提示填写"物品信息"，没有交通问卷和场馆能耗接入的入口，赛事相关的数据完全没有地方填。这类选错类型的情况，往往到填写中途才会暴露出来，此时已经录入的数据大多无法直接迁移到另一种项目类型下，因为两边的字段定义本身不兼容。

举一个模拟场景帮助理解：假设某位赛事组织者把"本届马拉松的赛事纪念T恤"当成核算对象建了一个Event Project，本意是想追踪这批T恤后续有没有被闲置浪费，结果填到一半发现，Event Project要求的是观众规模、举办地点这类聚合信息，根本没有地方描述单件T恤的材质、库存和后续流向。这类记录其实更接近Equipment Project的逻辑，只是记录的对象是一批同类物资而不是单件，正确做法是为这批T恤单独建立用品项目，而不是硬塞进赛事项目的时间轴里。

两种项目类型分别适合的真实场景

从米兰体育App实际使用情况看，Event Project更适合有明确起止节点、需要统计多方参与者活动数据的场景，比如一场校园运动会、一次城市马拉松、一场多日举行的邀请赛；Equipment Project则更适合追踪单件或者小批量物品从购入到报废之间的完整流转，比如一双跑鞋、一辆通勤自行车、一支训练用球拍，甚至一套健身器材里的某一个部件。判断的关键不在于"贵不贵"或者"重不重要"，而在于这次记录到底是围绕一段时间发生的活动，还是围绕一件持续存在的物品。

类型选定后能不能中途更改

目前米兰体育App不支持把一个已经建立的项目从Event Project直接转换成Equipment Project，或者反过来，原因和上面讲的字段结构差异是一致的：转换意味着要把一部分数据丢弃、把另一部分数据重新映射，风险比直接删除重建更高。如果发现选错了，建议的做法是尽早删除重建，而不是继续在错误的类型下勉强填写。已经录入的少量基础信息（比如项目名称、备注）需要手动誊抄到新项目里，这部分不会自动迁移。

值得一提的是，"尽早"重建的成本远低于"填了很久之后"再重建。如果只是在新建项目后填了标题和备注就发现类型选错，重建几乎没有额外成本；但如果已经在Equipment Project里录入了大量维修记录，才意识到其实应该建一个覆盖多件用品、多位参与者的Event Project来追踪一次装备更换活动，这种情况下已经积累的历史记录很难拆分重组到新项目里，往往只能保留原来的Equipment Project继续用，另外新建一个Event Project来记录活动本身，两者通过备注互相关联，而不是强行合并成一个项目。

如何在建立项目前快速判断类型

为了减少选错的情况，建议在新建项目之前先问自己几个问题：

  • 这次要记录的对象，有没有一个明确的开始和结束时间：如果有，倾向于Event Project。
  • 这次要记录的对象，是不是一个具体的、可以摸得到的实物：如果是，倾向于Equipment Project。
  • 是否需要统计多个人的交通和住宿数据：如果需要，只有Event Project支持这类聚合。
  • 是否关心这件物品未来会不会被维修、翻新或者转手：如果关心，只有Equipment Project会持续追踪这些事件。
  • 如果记录对象既包含赛事又包含具体用品（比如赛事赠送的纪念品后续要追踪流转），建议拆成两个独立项目分别记录，而不是勉强合并到一个项目里。

多人协作场景下的项目类型

无论是Event Project还是Equipment Project，只要涉及多人协作（比如赛事组委会多个成员共同维护一份项目，或者用品经过多次转手由不同账号接手），都需要用到权限（Permission）设置来控制谁可以编辑、谁只能查看。项目的核心数据通过账号同步（Account Sync）在不同设备之间保持一致，但权限本身是和项目绑定的，不会因为选错项目类型而自动继承，这也是尽早确认项目类型的另一个现实原因，避免后续还要重新给协作者分配权限。

为什么不做成App自动识别项目类型

有用户会问，既然填写内容能够反映记录对象的性质，为什么App不能自己根据前几个字段自动判断该用哪套模板，而是要用户一开始就手动选择。这里的顾虑主要有两个：一是自动识别在边界情况下容易出错，比如"某场赛事赠送的限量球衣"既涉及赛事又涉及具体物品，机器很难准确判断用户真正想追踪的是哪一类信息；二是即便识别对了，中途切换模板对用户来说也是一次隐藏的数据结构变化，反而不如一开始就让用户明确表态来得直观和可控。这也是为什么建立项目前的这道选择题，看似简单，实际上承担着决定整个项目后续数据结构的作用。