现场信号：先看什么
某夜，一个临时观测小组在城郊楼顶架好设备，第一次用星空app做星图识别。约束很清楚：光污染偏重、云量断续、可用时间只有两小时，且现场没有备用电源。小组的目标不是拍出作品，而是确认这套流程在真实条件下能不能跑通。
星空app打开后，第一屏给的是当前天区与可见星的粗略分布。我们没有急着对准目标，而是先记录三类信号：
- 定位信号：设备给出的方位与时间是否稳定，是否出现跳变；
- 识别信号：星图识别返回的匹配数量与置信提示是否连续；
- 环境信号：云层遮挡、地面灯光、手持抖动对画面的影响。
这三类信号决定了后面所有判断。若第一步就跳过记录，后面很难区分是设备问题、环境问题，还是操作问题。
一线备忘：先记录，再调整。没有基线，任何“好像变好了”都不可信。
故障模式：常见翻车点
当晚出现的异常并不戏剧化，但很典型。把它们归成几类，方便下次对照：
- 识别失败：画面里星点太少，星图识别无法给出稳定结果；
- 误匹配：把亮星或灯光误认为目标，返回看似合理但方向不对的结果；
- 漂移：设备固定不牢，短时间内画面缓慢偏移，识别结果随之漂移；
- 时间错位：设备时间与本地时间不一致，导致星图识别的天区推算偏移；
- 电量与发热：长时间运行后设备响应变慢，操作反馈延迟。
这些故障模式并非星空app独有，但在观测场景里会被放大。关键是把“现象”和“原因”分开记录，不要一看到失败就归因于软件。
排查顺序：从现象到根因
我们采用的顺序是：先环境，再设备，再设置，最后才怀疑识别算法本身。理由很简单，前几项可以现场验证，最后一项往往需要更多数据。
- 确认天空条件：云是否遮住目标天区，灯光是否直射镜头；
- 确认设备稳定：支架是否锁紧，线缆是否牵动设备；
- 确认时间与位置：设备时间、时区、粗略方位是否一致；
- 确认输入画面：曝光、对焦、视野是否落在可识别范围；
- 最后再对比不同设置下的星图识别结果，观察是否收敛。
这个顺序的好处是每一步都有可观察的输出。若某一步无法确认，就把它标为“未验证”，而不是直接跳过。
回退与恢复：边界内的动作
现场时间有限，回退策略必须提前定好边界。我们给自己设了三条线：
- 若连续多次识别失败，先退回手动对星，不再反复自动尝试；
- 若设备发热明显，暂停运行，待温度回落再继续；
- 若时间或位置无法校准，记录当前状态，收工后复盘，不在现场强行推断。
回退不是失败，而是把不可控因素隔离出来。星空app的星图识别在条件合适时能给出参考，但它不能替代对现场约束的判断。边界之外的动作，宁可留到下次。
带走清单：下次现场怎么做
复盘之后，我们整理了一份可带走的检查清单，用于下一次观测场景：
- 出发前：确认设备时间、时区、电量与备用电源；
- 到场后：先记录环境基线，再打开星空app；
- 运行中：按环境→设备→设置→识别的顺序排查；
- 异常时：记录现象与时间点，不急于下结论；
- 收工后：把未验证项和已验证项分开归档，供下次对照。
这份备忘不保证每次都能顺利识别，但能让问题变得可追踪。对一线使用来说，可追踪比一次性成功更有价值。 星图识别