夜雨聆风7 月 11 日的报道里，密云防灾小程序“叫应”露出了几个很具体的页面。
可以看各镇、各村的转移情况，可以查地质灾害隐患点和受威胁险户，可以对应包保人员；雨情和山体预警有变化，状态跟着更新。值班人员准备去某个隐患点，还能从页面直接跳到导航。
做过 GIS 项目的人，看到这里应该已经能列出一张数据表：隐患点、险户、村镇、责任人、雨情、预警、转移状态。至于“副局长自购 10 亿 token”“一个月手搓 App”“分摊下来不到 30 元”，当然很抓眼球，但它们解释不了这个工具为什么能用。
谢陨石做对的第一步，是把防汛值班室里那些散落在台账、电话、微信群和人脑里的关系，装进了一张能随时更新的空间责任网。
这件事对 GIS 软件公司有点刺耳。客户不再只会提需求，他已经能拿着 AI，把第一版软件直接做出来了。
“叫应”不是发一条预警消息
“叫应”这个词很容易被理解成群发通知。
但中国气象局公开的机制里，它至少包含两头：一头把预警送到基层防汛责任人，另一头要求责任人采取措施并反馈。北京公开的防汛预案把这条链写得更直白：有预警、有叫应、有行动、有反馈。
所以，一条暴雨预警出现在手机上，只完成了第一格。
后面还要知道它覆盖哪个镇、哪个村、哪些地质灾害隐患点；每个隐患点威胁哪些住户；谁负责联系；人有没有转；转到哪里；状态是谁更新的；最后有没有反馈回来。
把这些对象连起来，系统才开始像“叫应”。
它的数据关系大概长这样：
雨情 / 预警 -> 影响区域 -> 隐患点 -> 受威胁险户 -> 包保人员 -> 转移动作 -> 反馈状态 这里每个箭头都可能出错。预警范围和行政村边界对不上，隐患点坐标偏了，险户台账没有更新，包保人员换了，转移状态被重复提交，都会让屏幕上的“已完成”失去意义。
这也是“叫应”App 比普通信息查询工具难的地方。它显示的不只是位置，还在记录某个时间点上，谁要对哪个地点、哪一户人做什么。
业务人员为什么能先把它做出来
外包团队第一次听需求，拿到的可能是一句话：“做一个防汛叫应小程序。”
然后大家开始画首页、驾驶舱、雨情图、人员台账和消息中心。页面可以很快铺开，真正会卡住会议的却是一些小词：什么算“已叫应”？电话接通就算，还是对方明确回复才算？住户离开危险区算“已转移”，还是到达安置点才算？一户多人如何计数？临时返家拿东西，状态要不要回滚？
这些词不是 UI 文案。它们是业务规则。
长期在现场工作的人，脑子里已经存着大量这种规则。他知道村名的简称，知道哪条山路下雨后容易断，知道一个隐患点对应哪些住户，知道某个责任人没回消息时该找谁。他过去很难把这些经验写成一份完整需求文档，现在可以一边描述、一边让 AI 生成页面和代码，再用实际工作去修正。
Vibe Coding 在这里降低的是“把业务经验表达成软件”的成本。
以前业务人员要先把经验讲给产品经理，产品经理写成原型，再讲给开发，开发做出版本，业务试用后发现词不对、状态不对、顺序也不对。每经过一层，现场逻辑都会损失一点。
现在第一版原型可以直接长在业务人员手里。字段不对，当晚改；筛选不好用，第二天换；缺一个导航入口，马上补。
但这不等于软件工程消失了。它只是把软件公司的入场时间往后推了。
GIS 公司接到的，不该再是一张需求清单
如果我接到一个业务人员用 AI 做出的“叫应”原型，我不会先安排设计师把页面重画一遍。
我会先把四样东西导出来。
第一样是数据字典：隐患点、险户、村镇、责任人、预警和转移记录分别有哪些字段，主键是什么，数据从哪里更新。
第二样是状态表：“未叫应”“已通知”“已回复”“转移中”“已转移”“已复核”分别由谁修改，能不能撤回，多久没反馈要升级提醒。
第三样是权限表：谁能看险户信息，谁能改转移状态，谁能导出名单，AI 工具能接触哪些字段，哪些数据只能留在内网。
第四样是接管清单：代码仓库在哪里，模型生成过哪些模块，配置和密钥放在哪里，部署依赖什么账号，日志怎么查，原作者不在时谁能恢复系统。
这四张表做完，原型才有机会从“一个人做出来的工具”变成“一个组织接得住的系统”。
这也是 GIS 软件公司可以重新定价的地方。
过去项目报价里最显眼的是页面数量、接口数量、地图功能和开发人月。Vibe Coding 会把这些标准动作继续压便宜。客户甚至会拿着一个能跑的版本来问：我都做出来了，你们还要多少钱？
软件公司如果只能回答“我们代码更规范、页面更专业”，说服力会越来越弱。
更硬的回答应该是：我们能把你的原型接进正式数据源，给每个空间对象建立版本和更新规则；把账号、权限、日志、备份、弱网和异常状态补齐；拿错坐标、错人员、重复台账和失联场景去压测；最后交一套别人能维护、能复核、能追责的运行包。
这部分不一定比写页面更性感，但它更接近项目为什么愿意付钱。
先别急着把个人原型直接复制到全区
目前公开报道展示了“叫应”的功能和使用价值，没有披露完整技术架构。数据是不是全部上云、哪些字段做了脱敏、权限如何划分、有没有审计日志、弱网下怎么运行、代码由谁长期维护，公开材料不足以回答。
所以不能因为它是个人开发，就默认它不安全；也不能因为它在防汛中发挥了作用，就默认它已经具备一套成熟政务系统的全部能力。
我更关心第一轮接管测试会怎么做。
拿一条错误雨情，看系统会不会把不相关村镇带进来；把一个隐患点坐标故意偏到隔壁山沟，看导航和影响户是否跟着错；换掉一名包保人员，检查旧账号还能不能改状态；让网络断开半小时，再看现场记录如何补传、冲突如何合并。
首屏打开快不快，当然要测。防灾工具更该先测错人、错点和错状态。
而且任何一个“叫应”系统都不能把现场动作删掉。手机显示已通知，仍可能需要电话确认；地图上标了安全转移点，仍要有人检查道路和场所；页面写着已转移，仍要有人清点、复核并防止擅自返回。
软件能缩短信息链，不能替人完成最后那段山路。
“IT 懂业务”还是“业务会 IT”，这个问题已经不够用了
业务人员会继续自己做工具。尤其是范围小、时间紧、规则强、使用者就在身边的场景，Vibe Coding 会让他们比外包团队更快做出第一版。
程序员和 GIS 公司也不会因此自动消失。真实系统仍然需要数据治理、接口、权限、安全、测试、部署、灾备、运维和责任边界。
变化出在两边的交接处。
以前是业务写需求，IT 从零开发。以后更常见的流程可能是：业务先做出能表达真实规则的原型，IT 不再从空白需求文档起步，而是接管一个已经带着字段、页面、状态和使用痕迹的活东西。
能不能看懂它，能不能验证它，能不能把个人经验固化成组织资产，可能比“谁会写第一行代码”更重要。
密云“叫应”App 给 GIS 行业的提醒也在这里：客户会写代码以后，软件公司的工作没有归零，只是不能再把“替客户写代码”当成全部价值。
如果你也遇到过业务人员自己用 AI 做 GIS / 防汛 / 巡检 / 台账工具，你接管时最卡的是哪一步？
是数据字典没有、坐标来源说不清、账号权限混在一起、状态无法回滚、代码仓库没人管，还是原作者一离开就没人敢部署？留言写工具链、数据格式和交接环节，我后面挑一个真实原型，继续拆“业务自建、IT 接管”到底该交哪几张表。
参考资料
●GIS小丸子：《规自局长VibeCoding，未来趋势是「IT懂业务」还是「业务会IT」～》
● https://mp.weixin.qq.com/s/6-FTZEqQVbnqqoYZlNq0rw长安街知事：《自购10亿token“手搓”小程序，副局长花了多少钱？》
● https://xinwen.bjd.com.cn/content/s6a550c50e4b0e45f3fd493a4.html政知见转载：《北京密云一副局长自购10亿token，自主编程密云专属防灾App》
● https://finance.sina.com.cn/wm/2026-07-12/doc-inihqkzr7617988.shtml北京市规划和自然资源委员会：密云分局领导简介
● https://ghzrzyw.beijing.gov.cn/zhengwuxinxi/jggk/fjldjj/miyun/中国气象局：《汕头：联合应急管理部门强化预警“叫应”机制》
● https://www.cma.gov.cn/2011xwzx/2011xqxxw/2011xjctz/202305/t20230511_5496603.html北京市丰台区人民政府：《北京市丰台区防汛应急预案（2026年修订）》
● https://www.bjft.gov.cn/xxfb/yjgl/202606/t20260609_215435.shtml北京市应急管理局：《北京市十六届人大三次会议第0085号建议的答复意见》
https://yjglj.beijing.gov.cn/art/2025/11/13/art_9726_690300.html
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
