资料核对日期：2026年10月7日。本文根据官方资料整理，操作建议须先在项目副本中验证。
碰撞检测跑完，截图也发到了群里，到了下一次协调会，同一个位置却还在讨论。问题未必出在检测软件，而可能出在交接方式：接收人不知道该改哪一版模型，也不知道这条意见已经确定，还是仍在等待专业判断。
一份有用的碰撞报告，应当让别人能够找到问题、理解影响、知道下一步由谁完成。下面的做法适合用于建立项目问题单，不依赖某一个平台，也不以碰撞点数量作为工作成绩。
一、先写清这次到底检查了什么
报告开头应注明参与检查的专业模型与版本、区域、检测类型、容差和排除项。两次结果数量不同，可能是模型更新，也可能是检测范围改变；缺少这些记录，不能仅凭数字下降判断整改有效。
同一处构造可能产生多个碰撞结果。可以按位置和共同原因整理为一个协调事项，但要保留原始结果的对应关系。归组是为了方便决策，不应掩盖尚未处理的分项，更不能通过随意增大容差让列表变短。
二、一条问题单至少说明六件事
建议包括稳定的问题编号、楼层与轴网位置、相关构件标识、问题描述、处理责任人、期望完成时间。同时附上能看清关系的视点，并注明来源模型版本。标题最好写成“某区域风管与梁冲突，需确认调整方案”，避免只写“碰撞123”。
如果涉及多个专业，要区分发起人、主办人和协办人。主办人负责把问题推进到下一步，并不意味着有权单独决定结构、消防或其他专业设计变化。涉及设计调整时，应依项目既定审批流程确认后再实施。
三、看过、接受和解决不是一回事
Autodesk对Navisworks碰撞状态作了不同定义：Reviewed表示已审阅，Approved表示已认可，Resolved通常表示此前存在的碰撞在本次检测中没有再出现。手动改为Resolved后，如果再次检测发现同一碰撞，状态会回到New。查看官方状态说明
项目层面还应再问一步：碰撞消失，是因为构件位置已修正，还是因为模型未加载、检测集变了或构件被删掉？因此，建议把“提交整改”与“复核关闭”分开。关闭问题时保留更新后的模型版本、复检结果和必要的确认意见。
四、截图之外，可以评估BCF
buildingSMART的BCF用于跨工具交换与模型相关的问题信息，可以关联视点、构件与沟通内容。它帮助团队讨论和追踪已发现的问题，本身不能代替几何碰撞检测，也不能代替专业设计审核。查看BCF官方介绍
准备采用BCF时，可以先选一条真实协调事项，让两个实际使用的软件进行交换，检查视点、构件关联、评论和状态是否保留。不要只确认文件能导入，就默认所有可选信息都会完整传递。测试结论也要注明软件和版本。
五、从一张简单清单开始
暂时没有统一平台，可以用项目现有的表格管理问题，但应指定唯一维护位置，避免每个人手里都有一份不同状态的副本。每次会议优先讨论待决策、临近期限和已提交待复核的事项，而不是逐张重看全部截图。
真正值得追踪的是问题是否按期进入下一步，重要决策是否留下依据，以及整改后能否复查。碰撞检测输出的是线索，责任清晰、证据完整的问题单，才更容易把这些线索变成可执行的工作。
