企业官网建设流程全解析

凌晨三点，某山区乡镇卫生院的电话突然响起来，村医接起一听，老人突发胸痛，疑似心梗。卫生院的急救箱里有阿司匹林，可患者所在的自然村在山腰上，救护车开不进窄巷，村医自己骑车过去至少要二十多分钟。这种场景在基层医疗里太常见了——药就在手里，却送不到病人面前。

这个项目做的就是一件事：把大语言模型（LLM）变成无人机调度的大脑，让无人机带着急救药从乡镇卫生院起飞，直线飞到患者家里。试点测试下来，从电话呼入到药品送达，耗时只有传统开车送药的一半左右。这篇复盘我会把整套系统的设计思路、核心参数、提示词模板、调度代码和实际踩过的坑全部讲清楚，想搞LLM+无人机落地、做基层医疗应急方案的朋友可以直接参考。

1. 项目整体设计与思路拆解

1.1 乡村急救送药的"最后一公里"到底卡在哪

先说清楚传统模式为什么慢。常规流程是家属或村医打电话给卫生院，值班医生记录地址和症状，判断需要用哪种药，再联系司机或者让家属自己来取，最后车辆出发走山路。每一步看起来都不算慢，但串联起来之后问题就出现了。

位置信息是靠嘴问的，电话里说"村东头老槐树下第三家"，值班医生未必熟悉每个自然村，往往要反复确认。药品决策靠经验，心梗、哮喘、蛇咬伤、农药中毒对应的药完全不同，半夜值班的年轻医生不一定能快速判断。而运输环节完全依赖公路，山区很多自然村之间看着直线距离只有两三公里，实际开车要绕七八公里的盘山路。

我在项目里把整个流程拆成"决策时间"和"运输时间"两部分，发现传统模式里决策阶段就要花4到8分钟，运输阶段20分钟起步。真正的瓶颈不是车不够快，而是信息链路太长——人问人、人查人、人打电话，每一环都在消耗急救黄金时间。无人机解决的是"路"的问题，但如果没有LLM，无人机自己不会知道该飞去哪里、带什么药、怎么应对临时情况。

1.2 为什么是LLM而不是固定规则程序

你可能会想：派无人机这事，写个规则引擎不就行了？有急救电话进来，提取关键词"胸痛"，匹配到"阿司匹林"，再自动规划航线，完全可以实现。我最初也是这么想的，但落地时发现两个硬伤。

硬伤一：急救呼救的表述千变万化。代码里能写"胸痛"，但实际情况是"我爷爷喘不上气，胸口闷得厉害""孩子被蛇咬了，腿肿得老高""家里老人晕倒了，脸色煞白"。规则引擎要做语义映射就需要枚举海量表达，永远有漏掉的情况。LLM这一步明显更擅长，它能从混乱的口语里提取症状、年龄、接触史等关键信息。

硬伤二：决策不是简单的"症状→药品"映射。同样一个心梗，有高血压史和没有高血压史的用药思路不一样，癫痫患者能不能含服硝酸甘油也需要谨慎。这些知识分散在药品说明书、诊疗指南和患者基础信息里，用规则写会让系统变成一锅复杂的面条，而LLM天然适合做这种多条件综合判断。

当然，这里必须强调，LLM只做"决策大脑"，不做"飞行大脑"。它不直接控制电机、不处理传感器数据，只负责判断该派哪架飞机、带什么货、飞到哪个坐标、遇到情况要不要返航。具体的飞行控制交给飞控系统，安全逻辑用固定代码兜底，这样就能把模型的幻觉风险隔离在决策层，不会因为模型乱说话导致飞机乱飞。

1.3 整体架构：四层各司其职

整个系统拆成四层，每一层只干一件事：

入线层接收各种渠道的呼救请求，包括电话录音转文字、微信语音转文字、网页表单，统一成文本。这里的关键是"低学习成本"，不能让村医和家属学一套新的申报流程，原怎么说就怎么说。

调度大脑层是LLM，它拿到文本后做三件事：信息抽取，把症状、时间、地址、患者情况抽成结构化数据；药品匹配，结合药品库存和患者禁忌生成建议方案；任务编排，输出"该不该派无人机、带什么药、飞去哪里、要不要同步通知急救人员"的完整指令。

执行协调层负责把LLM的决策变成可执行的硬件指令：调用地图服务解析经纬度、用航线服务生成飞行路径、向飞控模块发送起飞指令、控制装载舱开合。

闭环反馈层在无人机落地后自动上报位置、投放状态、剩余电量，并把现场反馈同步给值班医生和家属。

这个架构的核心思路是"智能上移、安全下沉"。LLM负责聪明，规则代码负责可靠，两层之间通过标准JSON数据交互，谁都不越权。整套系统在一台普通工控机上就能跑起来，不需要机房级别的算力。

2. 核心细节解析与实操要点

2.1 模块职责边界：LLM绝对不能碰的几条红线

做这类系统的第一原则是划清楚人和AI的权限。下表是我们项目里的模块职责划分，建议直接照抄：

我最看重的是规则校验层和LLM层之间的"防火墙"。LLM可以建议"这次可以飞"，但它没有权限把风速阈值从8米每秒改成10米每秒；LLM可以输出药品建议，但最终药品名称必须匹配库存白名单，不在白名单里的直接用红色警告拦下来，不进入执行流程。

有人会觉得这样限制了LLM的能力，我的观点相反：在急救场景里，稳定安全比聪明重要一万倍。LLM的角色更像一个特别会读题、特别会安排的值班组长，手电钻还是手电钻，不能因为它能说会道就让徒手掰钻头。

2.2 关键参数怎么定：航距、载荷、气象阈值

硬件参数不是拍脑袋定的，推荐按下面的逻辑推导。

航距与时间估算：多旋翼无人机在乡镇场景下的巡航速度约40km/h，起飞和降落各要预留约40秒。从乡镇卫生院到周边自然村的直线距离普遍在2到6公里，一次任务的飞行时间约5到12分钟。电池续航要留出1.5倍冗余，实际续航少于任务需求1.5倍时不接收任务。

载荷与药箱：急救药以口服片剂、喷雾剂、注射剂为主，整体重量轻，3公斤载荷就够用。但注射剂和生物制剂有温控要求，我们用的保温药箱加两片医用冰排，能把2到8℃的温度环境维持40分钟以上，超过常规任务时长。药箱内部用珍珠棉开模挖槽固定不同药品，防止飞行晃动导致玻璃安瓿瓶碎裂。

气象阈值及计算方式：

• 风速：低空多旋翼的抗风能力有限，超过8m/s不飞。
• 降水：轻微毛毛雨可以飞，但考虑到药品怕潮，预报降水概率超过60%或者当前有持续性降雨就不飞。
• 能见度：起飞点与降落点能见度均低于800米不飞。
• 温度：锂电池在低温下放电性能下降，环境温度低于-5℃时需要给电池做预热处理。

这些阈值全部写进规则校验层，LLM的决策建议会先过校验，不达标直接返回不可执行并通知人工介入。

2.3 投放方式的选择：绳索缓降比抛投稳妥太多

刚开始做机载投放的时候，我们考虑过直接开舱抛投，结构简单、成本低，测试一次就出了问题。药品盒从3米高度砸到水泥地上，瓶装液体裂了两瓶。乡村院落地面情况更复杂，泥土、石板、杂草、晾衣绳，都可能影响落点。

后来换成绳索缓降方案：无人机飞到目标点上方8米处悬停，绞盘释放绳索把一个带缓冲泡沫的药箱缓缓放到地面，触地后药箱的卡扣自动断开，无人机收绳返航。这套方案多花了一点钱，但药品完好率从测试初期的不到80%直接拉到接近满分。如果你也在做类似项目，投放方式环节一定不要省这个成本。

3. 实操过程与核心环节实现

3.1 第一步：搭一套最小可行系统

硬件清单方面，不需要多昂贵的穿越机或工业机，一台载重能力足够、可靠性稳定的多旋翼加上RTK模块就可以。RTK模块很有必要，乡镇地区没有任何可靠的固定停机坪，纯靠GPS在狭窄院落降落误差波动大，RTK能让起降精度稳定在厘米级。

软件方面，飞控系统就用开源的，因为它的开发者接口更开放，我们直接在飞控上层写了一个任务脚本，接收来自调度端的航线指令并执行。地图服务用主流地图供应商的Web服务API，用来做地理编码和路线规划。语音转文字和LLM调用都走标准化接口，方便后续替换提供商。

3.2 第二步：设计让LLM稳定输出的提示词框架

直接贴我们在试点项目里用的提示词模板，可以复制后按实际场景调整。核心思路是：给足上下文，明确角色，限定输出格式，把自由度收窄到可控范围。

你是乡镇卫生院急救无人机调度系统的决策大脑。你的任务是根据呼救信息，判断是否需要派遣无人机配送急救药品。 【卫生院库存清单】 - 阿司匹林肠溶片（用于疑似心梗） - 硝酸甘油片（用于心绞痛，低血压患者禁用） - 蛇药片（用于毒蛇咬伤） - 氯雷他定片（用于严重过敏） - 肾上腺素注射液（用于过敏性休克，需人工注射并陪同） 【患者基础信息】 姓名：{姓名} 年龄：{年龄} 既往病史：{病史} 过敏史：{过敏史} 【呼救内容】 {用户原始输入} 【当前环境状态】 风速：{风速}m/s，天气：{天气}，能见度：{能见度}，当前时间：{时间} 你的任务： 1. 从呼救内容中提取关键信息：症状、发生时间、患者状态、具体地址。 2. 判断是否可以处理：如果症状指向危急情况，输出"需要无人机配送"；如果信息不足，输出"需要人工回拨确认"；如果明显不适用（如需要现场复杂操作），输出"建议人工急救并等待救护车"。 3. 如果决定配送，从库存中选择药品，并给出简要理由。 【输出格式】严格按照如下JSON输出，不要输出任何其他内容： { "alert_level": "紧急/普通/待确认", "action": "dispatch/phone/request_ambulance", "target_location": { "description": "自然村/院落描述", "coordinates": "经纬度或待解析地址" }, "medications": [ {"name": "药品名", "quantity": 数量, "reason": "选择理由"} ], "flight_advice": "航线建议或特别提醒", "broadcast_message": "同步给值班医生和家属的简短说明" }

这里有一个重要经验：强制JSON输出。如果让LLM自由发挥，下游程序解析文本就是一场灾难。用JSON约束后，调度代码就不需要再做自然语言理解，直接读出字段写库即可。为了防止模型偶尔不守规矩，我们还在前面加上"不要输出任何其他内容"的约束，但仍然会在解析层做容错。

3.3 第三步：把LLM和无人机调度串起来

调度核心代码逻辑可以简化成下面这段Python伪代码，真实项目里会加大量日志和异常处理，但主干就是这样：

def dispatch_pipeline(user_text: str): # 1. 语音已转为文本，直接交给LLM llm_result = call_llm(dispatch_prompt(user_text)) # 2. 解析结构化输出 decision = json.loads(llm_result) # 3. 规则校验层，防止模型幻觉闯祸 if decision["alert_level"] == "待确认": return notify_human("信息不足，请电话回拨确认") if decision["action"] == "request_ambulance": return notify_ambulance(decision["broadcast_message"]) if decision["action"] != "dispatch": return log_and_exit(decision) # 4. 校验药品库存 for med in decision["medications"]: if med["name"] not in stock_whitelist: raise SafetyViolation(f"药品不在白名单: {med['name']}") # 5. 校验气象和航线安全 if wind_speed() > 8 or rain_probability() > 0.6: return route_to_human("气象条件不满足无人机飞行") # 6. 解析地址并生成航线 coords = geocode(decision["target_location"]["description"]) if not coords: return notify_human("地址无法自动定位，需要人工介入") route = flight_planner.plan(origin=base_point, dest=coords) # 7. 人工确认后起飞（最终安全闸门） if human_confirm(route, decision["medications"]): flight_controller.takeoff(route, payload=pack_meds(decision["medications"])) flight_controller.auto_low_altitude_deliver() flight_controller.rtl() # return to launch # 8. 闭环上报 system_status.report("done", route.flight_time, delivered=True)

真实的项目里，"人工确认"这一步我纠结了很久要不要保留。自动化做彻底了会更酷，但急救场景容错率太低，万一模型判断错了，完全无人值守风险太大。最终方案是保留了值班医生一键确认的环节，但对确认操作做优化——医生只需要看一眼屏幕上的"药品名称、目标地址、飞行时间"三个字段，点一个按钮即可，整个确认过程不超过10秒。

3.4 试飞记录：从呼入到起飞40秒，全程9分钟送达

在某次全链路测试中，模拟呼入内容为"我父亲在XX村2组，胸口疼得厉害，冒冷汗，家里有高血压史"。

时间戳记录如下：

从呼入电话到药品落地，全程约9分半钟。而传统流程在这个村开车需要绕行约14公里山路，至少25分钟。这就是标题里"快一倍"的直接来源。

4. 为什么能快一倍：时效拆解与数据对比

4.1 传统流程的每一分钟去哪了

传统模式完整时间线：

• 家属打电话：0到1分钟，焦急表述，说不清地址。
• 值班医生记录并追问：1到3分钟，反复确认自然村名称和路线。
• 医生判断用药：3到6分钟，核对库存，找药装药。
• 联系司机/通知家属自取：6到8分钟，打电话、等人接电话。
• 司机从卫生院出发：8到11分钟，启动车辆、出大门、上对路。
• 车辆行驶：11到30分钟，盘山公路绕行，受会车、落石等因素影响。

传统模式全程大约30分钟。注意这里面"开车时间"只占不到三分之二，前期有近10分钟消耗在"人对人沟通"上。而人的沟通时间很难压缩，因为值班医生同时还要接诊其他电话，司机可能在忙别的事。

4.2 LLM+无人机模式的各环节耗时

新流程时间线：

• 呼入转文字+LLM解析：0到10秒。
• 决策和药品匹配：10到13秒。
• 规则校验：13到14秒。
• 地址自动解析：14到26秒。
• 人工一键确认：26到32秒。
• 起飞准备：32到44秒。
• 航线飞行：44秒到9分半。
• 投放：约18秒。
• 自动返航并上报：同步进行。

整体对比非常直观：新流程把决策阶段的10分钟压缩到半分钟以内，运输阶段用直线飞行替代盘山公路，又省掉了一半距离。两重优化叠加，总时间自然就快了一倍。

4.3 三个决定提速的关键因素

第一，路径是直线的。无人机不考虑山路弯曲度，5公里直线距离对40km/h的机型就是8分钟的事，而有盘山公路的汽车往往要绕到15公里以上。

第二，决策环节被并行化了。LLM解析、药品匹配、航线规划可以在十几秒内同时完成，而传统模式需要医生找药、司机找车、电话联系多个人，天然是串行的。

第三，无人机不需要"往返"。送药这件事，无人机到达、投放、掉头返航，全程不需要人员下车，没有停车、问路、找门牌的时间损耗。

当然要诚实说：快一倍不是绝对数字。如果目的地直线距离超过8公里，电量可能不够；如果天气不佳无人机根本不能起飞，系统只能退化为传统模式。这套方案的核心价值是把"可飞条件下的响应时间"大幅压缩，同时因为气象校验的存在，不会在不可飞的条件下强行冒险。它不是万能的，但在适合的场景里效率提升是实打实的。

5. 常见问题与排查技巧实录

5.1 高速问题速查表

实测中遇到过的典型问题整理成表，按优先级排列：

5.2 LLM误判的兜底策略

模型一定会犯错，这不是骂一句就能解决的，必须用机制约束。我们的兜底是三层保险。

第一层是白名单校验。LLM建议的所有药品必须存在于库存白名单，名称、剂量完全一致才放行。第二层是症状-药品规则复核。比如LLM建议了硝酸甘油，独立规则引擎会检查患者信息里有没有"低血压"关键字，有就直接拦截。第三层是回放审核。每次任务结束后，系统自动保存LLM的提示词、输出、用户原话、最终决策，形成一条完整决策链，每周抽一次做人工复盘。

这么做了以后，模型误判真正导致的风险事件基本归零。即使模型提出了不合适的建议，也会在下游被规则卡住，最多让任务多等几十秒转人工，不会出现直接飞个错误药品到现场的严重后果。

5.3 天气突变与空中特情处理

山区天气说变就变。某次夜航测试，起飞时风力3m/s，飞到中途突然下起阵雨，风速爬到6m/s。飞机在雨中飞了半分钟，图传开始出现抖动，但好在当时设计了一条安全策略：预设好"返航触发条件"，风速超阈值或降水强度超阈值时，飞控直接中断任务并自动返航到最近的应急点，不必等LLM决策。

那次的教训是：不要把应急判断交给LLM。空中每一秒都是变量，模型的推理需要时间，等它给出建议飞机可能已经没电了。应急逻辑必须写死在飞控层，LLM永远只做"出发前决策"和"事后的优化建议"，不参与飞行中的实时应急。

最后分享一点项目之外的心得

整套系统做下来，我对AI落地的理解比做之前清晰了不少。LLM真正有价值的不是单独秀智商，而是当一个"会听人话、能整合信息、愿意遵守边界"的中间层，把复杂决策压缩到秒级，让人的经验在最后一道闸门把关。

如果你也想做类似的尝试，我的建议是先别急着上大模型。先用规则引擎把系统跑通，在真实场景里收集一批呼救文本和流程卡点，然后再用LLM替换最难写的规则判断部分。把安全底座的坑提前填好，让无人机真正飞得稳、降得准、放得稳，最后加语言智能才有意义。急救场景里没有试错机会，稳，永远比炫技重要。