[ { "title": "认识星桥：找到你的业务入口", "summary": "了解门户与各业务系统的分工，快速找到常用服务。", "category": "快速入门", "url": "/docs/workspace-guide.html", "text": "一个入口，连接日常业务星桥门户汇集客户服务、内部协作和研发工具。开始工作前，先明确这次要完成的任务，再进入对应系统；门户本身不保存业务单据，也不代替业务系统完成审批。按任务选择服务第一次访问前的准备确认正在访问 skyspan.tech 对应的业务子域，优先使用 HTTPS 地址。向业务负责人确认应使用的系统、组织与账号；不同应用的账号可能独立管理。保存常用入口，并用一项已知业务记录核对数据范围是否正确。找不到需要的功能先用门户搜索应用名称，再在帮助中心按业务主题查找。如果菜单缺失或数据范围不符合预期，记录账号所属组织、操作时间和目标功能，交由本组织管理员核对。不要借用他人账号完成操作。" }, { "title": "账号与权限：首次访问检查清单", "summary": "确认组织、角色和业务范围，减少首次使用时的访问问题。", "category": "快速入门", "url": "/docs/account-access.html", "text": "确认账号归属企业账号应与个人身份、组织及工作职责对应。开始使用前，向管理员确认账号在哪些应用有效、能查看哪些业务范围，以及哪些操作需要审批。不能仅凭成功登录判断已获得全部业务权限。首次登录的检查顺序从统一门户进入目标应用，核对域名与页面名称。使用管理员分配的账号登录；如系统要求修改初始密码，按页面指引完成。核对组织名称、个人资料和可见菜单是否符合工作职责。选择一条获准访问的记录，确认能完成预期的查看或处理操作。菜单缺失与权限不足菜单不可见、记录不可见和操作被拒绝可能属于不同的权限范围。反馈时写明“期望执行的操作”和“实际提示”，由管理员依据职责调整权限。申请范围应以完成当前任务为限。岗位变更与账号退出调岗、离职或临时协作结束时，应由组织管理员复核权限与账号状态。共享电脑使用完毕后主动退出应用；忘记密码时使用组织认可的找回流程，不要向无关人员转发验证信息。" }, { "title": "如何描述一个问题，让协作更高效", "summary": "整理可复现的信息，帮助业务与技术团队快速定位问题。", "category": "快速入门", "url": "/docs/support-request.html", "text": "先写清业务影响描述受影响的任务、涉及范围以及是否有可用替代流程。例如“某条运输任务在签收后仍显示在途，影响今日结算核对”，比单独写“系统有问题”更容易确定处理优先级。准备一份完整的问题记录记录应用名称、页面入口和发生时间，时间带上时区。说明原本希望完成什么，以及实际看到了什么。写下最短复现步骤，并保留完整的提示文字。提供必要的业务编号、组织范围和脱敏截图；如有请求编号，一并记录。区分偶发现象和稳定问题检查是否只有某一条记录受影响、其他获准访问的账号是否也能复现，以及刷新后现象是否持续。涉及提交、派单或签收等操作时，先核对是否已经成功，避免反复点击造成重复业务。跟进与关闭处理过程中持续记录新增线索，不要反复创建内容相同的问题。收到处理结果后，用原始步骤重新验证，并核对业务数据是否恢复一致。关闭前保留结论、验证时间和仍需跟进的事项。" }, { "title": "运输任务准备：从订单到可执行计划", "summary": "汇总运输需求与约束，为调度安排建立可靠依据。", "category": "运输调度", "url": "/docs/transport-task.html", "text": "先明确运输范围一项运输计划应明确货物、起止地点、时间窗口和服务要求。将同一业务的订单编号、客户约定与现场联系人关联起来，避免仅凭口头说明安排运输。整理调度前的必填信息建立任务前的核对确认订单仍有效，且没有被其他运输任务重复承接。核对地址与联系人，必要时与现场确认通行和卸货条件。确认温控、分段运输或交接要求已随单记录。将待确认事项列出负责人，在关键条件明确后再安排资源。保留计划与实际的区别计划时间用于协调，实际时间用于还原执行。任务推进时应分别保留两类信息；不能通过覆盖计划值来掩盖偏差。发现前置条件变化，应先确认影响范围，再调整后续安排。" }, { "title": "车辆与司机安排：派单前的五项核对", "summary": "核对运力、时间与交接条件，减少执行阶段的返工。", "category": "运输调度", "url": "/docs/vehicle-assignment.html", "text": "匹配任务与运力派单不是简单分配一个车牌或联系人。应核对车辆的合法装载能力、货物适配性、可用时段和司机的工作安排；冷链等特殊任务还需遵循对应的运营规范。五项核对清单容量：核对重量、体积与装卸方式，不以单一指标代替完整约束。时间：检查提货、交付窗口及上一任务的预计结束时间。车辆：确认车型、设备状态与任务要求匹配。人员：确认司机可联系，了解路线、站点与交接要求。交接：明确派单确认方式、异常联系人与变更沟通渠道。处理资源冲突同一车辆或司机出现重叠安排时，先核对任务时间是否准确，再由调度负责人确定调整方案。不要仅修改系统中的预计时间来消除表面冲突；所有受影响任务都应同步检查。派单后的确认通知送达不等于执行人员已接受任务。按团队约定完成确认，并记录必要的时间与责任人。实际发车前再次核对车辆、司机与任务关系，防止临时换车后追踪数据仍挂在原车辆上。" }, { "title": "运输途中变更：改线、换车与延期怎么处理", "summary": "先评估影响，再同步任务、设备与上下游的变化。", "category": "运输调度", "url": "/docs/dispatch-changes.html", "text": "界定变更类型临时绕行、交付地址变化、车辆更换和预约延期会影响不同的数据与责任边界。记录提出变更的时间、原因、提出人和业务依据，先确认是否需要客户或内部负责人批准。按顺序执行变更核对当前任务状态、车辆位置与已完成的运输节点。评估变更对到达时间、货物条件和后续任务的影响。完成必要的审批或确认后，更新任务安排并通知相关人员。涉及换车、换设备时，记录生效时间并重新核对关联关系。验证新的安排已经传达，持续跟进第一个受影响节点。哪些记录需要保留保留变更前后计划、实际执行节点、确认依据与通知记录。换车时应清楚记录货物交接和设备交接，避免把不同车辆的数据连续性误认为同一辆车的完整轨迹。延期后的协同向下一站提供经过核实的预计到达时间与更新节奏。无法可靠估算时，说明当前影响因素和下一次反馈时间，不给出未经确认的承诺。任务结束后复盘根因与可改进的前置检查。" }, { "title": "读懂订单与运输节点", "summary": "区分业务状态与定位数据，判断一票货当前进展。", "category": "订单追踪", "url": "/docs/shipment-status.html", "text": "状态回答“业务走到哪里” 订单与运输任务可能拥有不同的状态粒度。订单表示客户需求，运输任务表示一次执行安排；一个订单也可能分段运输。阅读状态前，应先确定当前查看的对象与对应的业务编号。常见节点如何理解状态与定位不一致时车辆到达目的地区域不等于货物已签收，设备停止更新也不等于车辆停止行驶。应结合最近上报时间、现场反馈与业务凭证判断，不通过单一地图点直接变更业务结论。核对一票货的顺序确认订单与运输任务之间的关联是否正确。查看最新业务节点及其实际发生时间。对照设备最近采集时间和平台接收时间。需要人工确认时，记录确认人、依据和时间，再按业务流程更新。" }, { "title": "轨迹不连续或定位延迟的排查方法", "summary": "从时间、关联关系和设备状态逐步缩小问题范围。", "category": "订单追踪", "url": "/docs/tracking-gaps.html", "text": "先确认数据的新鲜度地图展示的是设备最近一次有效上报，不保证等同于车辆当前位置。先查看定位采集时间与平台接收时间，明确是采集间隔较长、传输延迟，还是页面尚未更新。四步排查核对运输任务关联的车牌、设备编号与生效时间，排除错误关联。查看最近有效上报时间，确认是否只是跨越了正常的采集间隔。联系现场按设备说明检查供电、信号及安装环境。结合其他业务记录确认车辆状态，并把缺失时段记录到问题单。区分轨迹缺失和位置异常轨迹缺失表示某段时间没有有效位置；位置异常可能来自定位环境、坐标转换或数据关联错误。排查时保留原始时间和异常点，不用手工拼接的路线替代实际采集记录。恢复后仍要复核网络恢复后可能出现历史数据补传，应按采集时间理解路线先后，而非只按接收顺序排列。若数据始终无法补齐，说明缺失范围及原因，让使用轨迹做判断的业务人员知情。" }, { "title": "签收与交付凭证核对", "summary": "让状态、时间、数量和凭证共同说明交付结果。", "category": "订单追踪", "url": "/docs/delivery-proof.html", "text": "签收前确认对象首先核对当前订单、运输任务与实际收货方，尤其注意同一客户的不同站点和同一天的多次配送。车辆到站、货物卸完和客户签收是不同事件，不能互相代替。交付核对清单核对交付站点、收货方和对应业务编号。确认实际交付件数及货物外观；差异按约定记录。保留签收时间、签收人及所需交付凭证。对拒收、部分签收或破损等情况，记录原因与后续负责人。凭证归档原则照片或单据应能与业务记录对应，并清楚展示需要证明的交付信息。只保留必要的个人信息，不把凭证发布到无关渠道。更正签收信息时应保留原始依据与更正原因。发现不一致怎么办系统数量与现场签收数量不一致时，先确认计量单位、分批交付和是否存在重复记录。不要为了完成状态流转而直接填入计划数量；按业务流程确认实际结果后再处理结算或后续任务。" }, { "title": "温控任务准备：明确区间、设备与责任人", "summary": "把货物要求落实到温控监测与异常沟通流程。", "category": "冷链温控", "url": "/docs/temperature-setup.html", "text": "温度要求来自业务规范允许温度区间、持续时长及处置方式应以货物要求、客户约定和适用规范为准。不同货物不可直接套用同一组阈值；平台展示的测量值也不能独立替代专业的质量判定。开始任务前核对记录本次货物要求的温度区间、允许偏差及确认依据。检查设备编号、校准要求和安装位置是否符合实际用途。核对设备与车辆、箱体或任务的关联关系。明确告警接收人、现场处置人及联系不上时的升级路径。出发前检查一段有效温度数据，确认时间和单位可正确理解。采样与上报不是同一件事设备采样间隔决定本地测量频率，上报间隔决定数据何时到达平台。短时网络中断可能导致接收延迟。评估异常时应明确记录所依据的是采集时间还是接收时间。交接时的注意事项更换车辆、箱体或探头后重新检查关联和安装位置。不要沿用上一任务的条件而不复核。把配置变更时间、确认人和交接记录保存到任务资料中，供后续追溯。" }, { "title": "收到温度告警后的处理流程", "summary": "核实告警、联系现场、记录行动，并跟进恢复结果。", "category": "冷链温控", "url": "/docs/temperature-alerts.html", "text": "先确认告警对应哪次任务核对告警的设备编号、任务、位置、采集时间与阈值。已结束任务或过期关联也可能造成理解偏差。告警反映需要核查的事件，不直接等同于货物已经失效。处置流程确认数据是否连续、设备是否仍在上报，并核对异常起止时间。通知现场负责人，按货物操作规范检查实际环境和设备情况。由有权限的业务或质量负责人决定后续处置，不自行改变货物判定标准。记录采取的措施、执行时间、负责人及现场证据。持续观察恢复情况，并确认是否仍有需跟进的货物或交付影响。重复告警如何整理同一事件连续触发时，可在同一处置记录中补充后续数据，但应保留每次事件的原始时间与内容。不要通过随意放宽阈值消除提示，否则会影响后续监测与追溯。什么时候可以关闭关闭前应明确异常原因、采取的措施、数据恢复情况和业务处理结论。如果数据恢复但货物状态仍待确认，应保留待办事项与负责人，不能把技术恢复当作业务风险已经解除。" }, { "title": "温度曲线复核与运输记录归档", "summary": "结合采集时间与业务事件，解释一段完整的温控记录。", "category": "冷链温控", "url": "/docs/temperature-review.html", "text": "选择完整的复核范围以任务实际开始和结束时间确定查看范围，并适当包含前后交接时段。先核对设备、货物和运输任务的关联，再查看曲线，避免把相邻任务的数据混在一起。阅读曲线的顺序确认温度单位、时区和横轴采用的时间含义。查看数据是否连续，标记缺失、延迟及补传时段。对照装卸、开门、换车等已记录的业务事件。将超出要求的时段与告警处置记录逐一对应。缺失数据如何表达没有测量值的时段不应被描述为温度正常。报告中应说明缺失区间、已知原因和使用了哪些补充证据；若进行了分析性插值，应与原始采集数据明确区分。归档前的检查确认记录包含业务编号、设备编号、时间范围、温控要求、异常说明和责任人。将原始数据与处置凭证一并保存，并按组织的留存制度管理访问权限和保留期限。质量结论由相应负责人确认。" }, { "title": "设备登记与业务关联", "summary": "建立可追溯的设备档案，避免编号与使用对象错配。", "category": "设备管理", "url": "/docs/device-registration.html", "text": "一台设备，一份清晰档案登记前核对设备标签与实际型号，记录设备唯一编号、用途和保管责任人。编号应来自设备或采购资料，不要用现场临时昵称替代唯一标识；昵称可以作为便于识别的补充信息。登记前准备建立关联后验证确认设备未被重复登记，且没有冲突的有效关联。按照实际使用对象建立设备关系并记录生效时间。查看一次有效上报，对照设备编号、时间与测量类型。让业务使用人确认任务中看到的是正确设备的数据。换绑与停用换绑时保留原关联的结束时间与新关联的开始时间。设备停用、返修或移交时同步更新使用状态与责任人，避免新任务继续使用不再有效的设备档案。" }, { "title": "设备离线：从供电到数据链路逐项检查", "summary": "用可复核的检查记录定位离线原因。", "category": "设备管理", "url": "/docs/device-offline.html", "text": "明确“离线”的判断依据平台通常根据最近接收数据的时间判断设备是否活跃，具体间隔由设备与业务配置决定。先记录最后一次有效上报时间，再确认设备是否正在执行任务；离线提示本身不能说明具体原因。现场检查顺序核对正在检查的设备编号与任务关联。按设备说明检查供电、电量和可观察到的状态指示。确认当前所在区域的通信环境与安装条件是否变化。记录检查时间和结果，并与平台最近接收时间对照。持续无法恢复时，将设备型号、编号和现象交给设备维护人员。避免无依据的重复操作不要连续重启或恢复出厂设置来尝试消除离线状态。此类操作可能影响现场配置和待上传数据；确需执行时应先确认维护指引、业务影响与记录保全要求。恢复后核对什么检查新的数据是否来自正确设备，时间是否准确，历史缺失段是否补齐。确认运输任务中的设备关系没有变化，并在问题记录中补充恢复时间、原因及后续预防措施。" }, { "title": "设备日常巡检与维护记录", "summary": "把设备状态、业务影响与维护责任连接起来。", "category": "设备管理", "url": "/docs/device-inspection.html", "text": "建立适合业务的巡检节奏巡检频率应结合使用环境、设备说明和组织运营要求确定。高频使用与长期闲置设备的关注点不同，但都需要明确责任人和异常反馈渠道。每次巡检建议记录设备编号、巡检时间、地点和执行人。外观、固定方式、供电及可观察到的状态。最近有效上报时间与当前任务关联。发现的问题、可能受影响的任务和临时措施。需要维修、校准或更换的事项及跟进负责人。维护前先安排业务衔接在正在执行的运输任务中维护设备，需先确认数据连续性与替代安排。更换设备时应记录交接时间并验证新设备上报，保留前后设备的对应关系。让记录形成闭环维护完成后验证原问题是否消失，补充维修结论、验证方式与下一次复核安排。对于反复出现的异常，应汇总相似条件与历史记录，交由维护负责人分析，不只记录“已恢复”。" }, { "title": "接口对接前的准备清单", "summary": "先对齐业务范围、字段和责任人，再进入技术联调。", "category": "开放接口", "url": "/docs/integration-checklist.html", "text": "明确对接的业务目标从需要流转的数据与触发时机开始：谁产生订单、谁负责运输状态、哪些数据需要回传。把业务流程和系统边界画清楚，比直接开始编写请求更能减少返工。准备对接资料确定双方业务和技术负责人，以及问题跟进渠道。确认使用环境、实际服务地址和可用的接口文档版本。按获准流程申请对接身份与权限，明确有效期和保管责任。约定字段映射、唯一编号、时间格式、状态含义和缺失值处理。准备脱敏测试样例、验收标准与出现异常时的恢复方案。将字段约定写成表对每个关键字段记录名称、含义、来源、是否必填、允许值和示例。特别核对重量与体积单位、地址层级、订单拆分规则及跨系统编号映射。不要只根据字段名称推断业务含义。进入联调前的确认实际鉴权、签名、分页、限流和回调机制以双方确认的接口文档为准。本指南提供对接准备方法，不约定具体接口路径或请求格式。测试数据应与真实业务隔离，并明确如何清理或标识。" }, { "title": "重复推送与重试：避免一条业务被处理多次", "summary": "区分请求是否送达、处理是否成功和结果是否被确认。", "category": "开放接口", "url": "/docs/integration-retries.html", "text": "超时不代表没有成功请求超时可能发生在服务已经完成处理之后。如果直接创建新的业务请求重发，可能产生重复记录。重试前应依据实际接口约定查询处理结果，或使用双方认可的幂等机制。约定业务唯一性确定以哪个稳定标识代表同一业务事件，并约定该标识的有效范围。订单创建、状态更新和更正可能是不同事件，不能简单复用一个无法区分业务动作的值。设计可跟踪的重试流程记录业务唯一标识、请求时间、请求编号和响应结果。区分可重试的临时失败与需要修正数据的永久失败。按接口文档约定设置重试间隔、次数上限和限流处理。达到上限后转入人工跟进，保留原始请求与后续处理关系。联调时覆盖这些情况验证正常请求、相同事件重复到达、处理完成后响应丢失、旧状态晚于新状态到达，以及更正请求。确认不会重复创建订单、回退已确认状态或丢失失败记录。具体行为需由接口契约和实际测试共同确认。" }, { "title": "联调排查：组织时间、编号与错误信息", "summary": "建立双方都能定位的线索，提高接口问题的排查效率。", "category": "开放接口", "url": "/docs/integration-debug.html", "text": "从一条明确的业务开始选定一条获准使用的测试记录，明确预期输入与输出。避免同时修改多组参数后只报告“偶尔不成功”；每次测试都应能关联到一个可追溯的业务事件。保留最小必要信息逐层定位问题确认访问的是双方约定的环境和服务地址。检查连接是否建立，是否收到完整响应。按文档核对鉴权与参数要求；不要把凭据复制到问题单。对照业务规则检查重复事件、状态顺序和对象是否存在。由双方用同一个请求编号核对处理结果，并记录结论。修复后如何验收重新验证原失败场景，再检查一条正常流程和相关边界场景。确认不会产生重复业务或丢失记录。留存修复内容、验证时间与剩余限制，将确认后的字段或规则更新到共享对接文档。" } ]