SCDF：用 Power Platform 与 Copilot Studio 培养一线数字能力

先把公开记录摆清楚，再谈判断。据微软 Power Platform 官方案例库 2026 年 3 月发布的文章，新加坡民防部队（SCDF，隶属内政部 MHA）与内政部下属的科技局 HTX 合作，围绕 Power Platform 与 Copilot Studio 建设了一批内部应用和一个对话式代理。案例点名了四个用 Power Apps 搭的应用：自动派勤 App（ADA，按消防员的技能与驾照把人和车辆智能匹配）、食堂点餐与消耗 App（FICA，管理民防学院每日超过 3000 份餐食）、交互式排障 App（ITA，让一线自助诊断车辆故障、少打电话找供应商）、以及值班官排班 App（DORA，把非一线人员的团级值勤集中化、可自助换班）。在这四个之上，才有了 NEXA（Next Evolution Assistant），一个用 Copilot Studio 搭的对话代理，从政府网站和内部知识库里取信息，还带了 SharePoint、Dataverse、Power Automate 支撑的问答式游戏化学习功能。

案例披露的数字需要逐一标出边界。微软文章称，交付的解决方案「价值约 2000 万美元，而开发成本低于 5 万美元」；ADA 与 ITA 被 23 个消防站的 2100 名一线人员实际使用；DORA 服务约 700 名非一线员工；FICA 由一人在三个月内独立开发完成；NEXA 已部署给全部 6000 名 SCDF 官兵；App 交付周期从传统方式的 2 至 3 年压到 1 至 3 个月。这些数字全部来自微软与 SCDF/HTX 的自我披露，属于厂商案例叙事，未见独立审计或第三方评估。尤其那句「价值约 2000 万美元」，是「若外包会花多少」的规避成本口径，而非产生的收益，HTX 2023 年的报道把它表述为「省下约 2000 万美元的开发成本」——这是估算，不是结算。

再补一层来自 HTX 官方的记录以便交叉核对。据 HTX 2023 年的报道，最早的八个应用是在 2023 年 2 至 5 月约三个月内建成的，花费不到 5 万新元；这批 App 由 HTX 民防项目管理中心（CDPMC）的工程师主导，采用「四个内部自建、一个 SCDF 与 CDPMC 联合、三个协同外包」的组合。除了案例里那四个，HTX 记录还点出了另外几个应用名：响应者体能测试记录 App（RFFT）、楼宇消防检查预约 App（BIAB）、给一线查操作规程的一站式手册 App（BTM），以及一个产品清单方案的自动核对工具。SCDF 官网对 2023 年 5 月「成为数字一线人员」活动的记述则更直白：应用是 HTX 工程师用 Power Apps 和 Power Automate 建的，现场为高管办了「搭 App 挑战赛」和动手演示。

时间线也值得对齐,因为不同材料给的起点不一。微软案例说 SCDF 早在 2021 年就开始数字化业务与运营流程,2023 年落成四款 Power Apps 打底、2024 年试水 Copilot Studio 建出 NEXA、2025 年开始把数据接进应用与 AI;HTX 2025 年的报道则把「数字工厂」的正式建制定在 2024 年 4 月,并列出此后陆续冒出的全球协作管理系统（GEMS）、SCDF AI 助手、HT Buddy、REDCON 等新应用。案例还提到 SCDF 凭这套打法在 2023 年拿到内政部下属机构里最高的数字成熟度评级,并吸引了 300 多名本地及国际同行来取经。把三方口径叠起来看,事实层是扎实的、可交叉印证;真正有分歧、也最值得拆的是叙事层——同一批事实,微软案例讲成「人人皆是数字一线人员」的能力故事,HTX 与 SCDF 自己的记述却更像一支中心工程队高效交付的故事。这道缝隙,正是后面所有分析的入口。

如果只看 NEXA，这个案例平平无奇：一个政府机构用 Copilot Studio 接上内部文档，做了个问答机器人。真正值得分析的分水岭不在模型，而在组织想解决的那个老问题:传统 IT 项目一个需求要走两三年，对一支靠时效吃饭的一线队伍来说太慢。SCDF 与 HTX 的应对，是在 2023 年组建「数字工厂（Digital Factory）」团队，用敏捷方式把「从想法到上线」的路径压短，据 2025 年 HTX 的报道，这个团队 2024 年 4 月正式建制，配了一支不走传统采购流程、直接写软件的「敏捷小队（Agile Squad）」。

把它和「用 AI 提效」区分开的，是它试图搬动的东西。提效是把某个具体流程自动化，产物是一个更快的流程；而这里官方反复强调的口号是「人人都做数字一线人员（digital frontliner）」，产物本应是一线自己「会造工具」的能力。这是两种不同的资产：一个流程用坏了得重做，一种能力却可以复用到下一个还没被人想到的流程上。更贴切的说法是,这更像在长肌肉,而不是买一台跑步机。跑步机是交付物，买来即用，也用完即弃；肌肉是能力，得靠持续使用才长得住，一旦停练就会萎缩。SCDF 想要的显然是那台跑步机之外的东西。

这也是为什么低代码是这套打法的关键零件，而不只是省钱手段。Power Apps 的门槛低到让 FICA 可以由一人三个月建成，这在传统开发里几乎不可想象。门槛低意味着离业务最近的人有机会自己动手，能力才有可能从中心工程团队向一线渗。传统 IT 的两三年周期里,真正的成本不只是时间,还有中间那道翻译损耗:一线把痛点讲给需求分析师,分析师写成文档给供应商,供应商做出来往往已经偏离了现场真正需要的东西。低代码把这条链路压短,理论上让「提需求的人」和「造工具的人」可以是同一个人,比如民防学院食堂那个懂点餐流程的人,自己就能把 FICA 的字段调对。这才是「数字一线人员」这个词最有价值的内核:让离业务最近的人手里第一次有了直接把想法变成工具的杠杆,而非仅仅多学几个新 App 的用法。

但也正因如此,判断这套机制成没成的标准,不该是上线了几个 App。上线数是产出,产出可以完全由中心工程队贡献,和一线会不会造工具毫无关系。更该问的是这块「会造工具」的能力到底长到了谁身上:是长在了 HTX 那支中心工程队里,还是真的长到了 23 个消防站的班组里。同样一批亮眼的上线数据,背后可能是一线普遍学会了自建,也可能只是中心一支强队替所有人代劳;两者看起来一样,组织真正留下的存量却天差地别。这个区分,是后面所有讨论的轴,也是本案例最容易被产出数字盖过去的地方。

公共部门低代码落地里最容易被口号盖住的一个问题是：中心那支能力团队，究竟在「教一线钓鱼」，还是「把鱼钓好端上桌」。这两件事都叫赋能，但组织后果截然不同。前者留下的是一线自己会迭代的应用，后者留下的是一批一线不会改、也没人负责改的应用。

从公开记录看，SCDF 的重心明显偏向交付端。八个最早的应用由 HTX 民防项目管理中心的工程师主导建成，SCDF 官网自己的记述里，应用是「HTX 工程师用 Power Apps 和 Power Automate 建的」，一线在 2023 年那场活动里参与的是「搭 App 挑战赛」和动手演示,按 SCDF 页面的语境，更接近意识唤醒，而非把独立开发的技能真正交到官兵手上。HTX 2023 年报道给出的数字也印证这一点：约 200 名一线官兵被「导入使用」这些新应用，另有面向 4000 人的推广——注意，这是培训人去「用」App，而非培训人去「造」App。真正体现能力下沉的孤证，是 FICA 那句「由一人独立开发」；但案例没说这个人是消防站的一线官兵，还是数字工厂里的成员，这个关键身份在记录里是空的。

HTX 2025 年的报道进一步坐实了这个偏向:数字工厂配的是一支「敏捷小队」,直接写软件、绕开采购,这描述的是一支专业开发队,不是一群会顺手搭 App 的一线官兵。人事名单也印证:公开点到的是 HTX 的副司长、一线机动主管、牵头工程师这类角色,清一色是中心侧的技术与管理人员,没有任何「某消防站班长自建某 App」这类一线署名。换句话说,记录里能查到的「造」的主体,几乎全在中心。

所以更准确的描述是：SCDF 建了一支高效的中心交付队，并给它套上了「数字一线人员」的能力叙事外壳。这两者不矛盾，很多组织都是先由中心队打样、再逐步把工具交出去；这是合理的演进节奏,早期就该由懂工程的人先立标准、打样板。问题只在于,公开材料把「赋能一线自建」和「中心替一线代交付」这两件后果迥异的事,笼统装进了同一套说辞里。要判断它到底走到哪一步，得看一个记录里目前完全缺失的变量：这些 App 上线后由谁维护、由谁迭代。如果答案仍是 HTX 的工程师，那能力还锁在中心，一线只是使用者;如果站里已经有人能自己改 DORA 的换班规则,那能力才算开始往一线长。案例通篇没有回答这个问题,而这个问题的答案,恰恰决定了「数字一线人员」是一句已兑现的描述,还是一个尚待验证的目标。

支撑「能力下沉」叙事最有力的证据，是设计过程本身。据微软客户故事，三方在开发前用设计思维方法先摸清用户需求，目的是在用户中「养出共同拥有感（co-ownership）」；HTX 副司长 Tan Song Beng 说，低代码平台让他们「能在更短的开发周期里做出定制化方案」；SCDF 副总监 Ling Young Ern 说 ADA「显著减少了行政时间」。把一线拉进需求环节，确实是能力建设该有的做法:离痛点最近的人最知道 App 该长什么样，ADA 按技能和驾照派车这种规则，也只有懂消防运作的人提得出来。

但「共同拥有感」和「拥有权」是两回事，中间隔着一道低代码不会自动帮你跨过的坎。让一线参与设计，是把需求知识引进来;让一线拥有应用，是把维护责任交出去。前者靠几场工作坊就能做到，后者需要一线里长期有人具备读懂并修改应用逻辑的能力，而这恰恰是记录里最薄的部分。一个一线官兵能在设计会上说清 DORA 的换班规则该怎么定，不等于半年后规则要改时他能自己进 Power Apps 把它改了。低代码降低了「造」的门槛，却没有降低「守」的门槛：应用一旦接上 Dataverse、Power Automate 流、SharePoint 数据源，它的可维护性就取决于有没有人搞得懂这条链路，而不取决于当初拖拽有多容易。

NEXA 这一侧把「守」的门槛暴露得更清楚。它接了三类知识源:政府公开网站、上传的 SCDF 官方文件、以及由 Power Automate 从 SharePoint 灌进 Dataverse 的结构化数据,还要按识别到的意图去做器材识别和自动出题。这是一条相当长的数据链路,任何一环变了——某份操作规程更新了、某个 SharePoint 库改了结构,都需要有人看得懂整条链路才能修。一线官兵能在设计会上说清「新兵该背哪些条例」,不代表半年后规程一改,他能自己进 Copilot Studio 把知识源和意图配置理顺。对话式代理尤其如此:它出错不像传统表单那样报个红,而是安静地给出一个听起来合理、实则过时的答案,这种错误只有懂它内部逻辑的人才发现得了。

这正是公共部门这类项目最隐蔽的债务。把人拉进环里做需求，收益立竿见影、上线数据好看;把维护权真正交到一线，则是慢功夫，短期没有亮眼指标，还要占用一线本就紧张的执勤时间。理性的中心团队，在没有硬约束时会自然偏向前者:先把东西交付出去、把覆盖数做上去,维护那笔账往后放。案例里那句「共同拥有感」，究竟兑现成了一线的维护能力，还是停在了参与感，公开材料给不出答案，而这道坎迈没迈过去，才是这套组织设计成败的真正分野。

把交付周期从两三年压到一至三个月,是这个案例最硬的成绩,也埋下最实的隐患。速度来自绕开传统采购:数字工厂那支敏捷小队直接写软件,不走冗长流程。绕过采购省下的是前置时间,但采购流程附带的那套东西——需求文档、验收标准、供应商的长期维护合同、退役与交接规范,并不会随流程一起消失,它们只是从合同里挪到了组织自己肩上。低代码越普及、造得越快,这笔隐性账就越大。

公开记录在这里几乎全是空白。微软案例的「要点」一节给出的建议是「建立卓越中心或数字工厂团队来沉淀内部能力」,但通篇没有触及治理的硬问题:这些应用谁做安全审查?接入 Dataverse 和政府网站作为知识源的 NEXA,权限边界怎么划?一个由一线人员搭的 App,如果作者调岗或退役,谁接手?八个、再到 2024 年后陆续冒出的 GEMS、SCDF AI 助手、HT Buddy、REDCON 等应用,构成的是一个越来越大的低代码资产组合,而组合越大,「无人认领的应用」这种熵就越容易累积。这不是 SCDF 独有的问题,而是所有 citizen-developer 式落地共同的账单:造的门槛塌了,治理的门槛没塌,速度红利和维护债务是同一枚硬币的两面。

这里还有一层公共部门特有的敏感度。SCDF 处理的是应急救援与人员部署,NEXA 又直接接了政府官方文件作知识源,一旦权限边界没划清、或代理把某份内部规程答给了不该看到的人,后果就不止是效率问题。低代码平台默认让搭建者能连各种数据源,这种便利在治理缺位时会变成风险敞口:谁有权把哪个 SharePoint 库接进哪个 App、哪些数据能出现在对话代理的回答里、模型幻觉出一条不存在的操作规程时谁来兜底,这些都需要一套跑在敏捷之上的治理框架。而公开材料对这套框架只字未提,既没提数据分级,也没提代理回答的审查机制。这不代表 SCDF 没做,政府机构通常有既有的信息安全制度;只代表这个案例作为可迁移的样板,恰恰在最难的治理环节留了空白。

值得肯定的是,SCDF 把能力常态化成了建制——数字工厂 2024 年建团、进入「Digital Frontliner 3.0」把 apps、data、AI 合成「三位一体」,说明它没把这当一次性项目。建制化本身就是对可维护性的一种回应:有一支固定的队,总比项目结束就散摊要强,应用组合越大越需要一个常设主体来登记、审查和退役。但这也把问题顶到了台前:如果可维护性最终靠的是那支中心队常在,那么「能力下沉到一线」在多大程度上是真的?这支队是脚手架,搭好了就该逐步拆掉、把承重交给一线;还是承重墙,一旦撤走整栋就塌?记录还没到能回答的时候,但这是最该盯的结构性问题,它的答案将决定这条路究竟走不走得通。

把披露的数字放回它们能承重的范围内,才不会读过头。能证明的部分相当扎实:交付速度确有量级提升(2 至 3 年到 1 至 3 个月,这是可核对的相对量);覆盖面真实且不小(NEXA 触达 6000 名官兵,ADA 与 ITA 覆盖 23 站 2100 人,DORA 服务约 700 人);单点效率有具体佐证(FICA 一人三个月,一线自助排障减少了对供应商的呼叫)。这些说明「用低代码在公共机构里快速交付内部工具」是可行的,并非画饼。

不能证明的部分同样清楚。第一,「价值约 2000 万美元」是规避成本的估算,不是审计过的收益,更不是净值,它没扣除人力、许可、维护和未来重建的成本,把它读成 ROI 是误读。第二,所有数字都是覆盖与产出口径(部署给多少人、建了多少个),没有一个是留存与维护口径:没有应用的月活、没有上线一年后仍在用的比例、没有由一线自己迭代的次数。而恰恰是后一类,才能证明「能力下沉」这件事。第三,记录只覆盖顺利的一面,没有任何失败或弃用应用的数据:八个 App 全部被讲成成功,而任何真实的应用组合都会有沉默的死亡率,这个率在公开材料里是零披露。

第四,连覆盖数字本身也要读得细一点。「NEXA 部署给 6000 名官兵」是「可用人数」,不是「在用人数」;部署到位和被日常使用之间,隔着采用率这道坎,而采用率恰恰没披露。同理,「ADA 与 ITA 覆盖 2100 人」说的是有权用的人数,不是每天真在用的人数。这类口径在厂商案例里是常规操作,并非造假,但读的人得自己把「部署」和「活跃」两个概念掰开,否则很容易把一个铺开的动作误读成一个见效的结果。

所以对这个案例最诚实的读法是:它证明了「快速造」,没有证明「造得住」。前者是流量,后者是存量;厂商案例天然擅长展示流量,而公共部门真正的价值在存量,即一批能在中心团队注意力转移后依然被一线用着、改着、养着的应用。回到长肌肉那个比方:我们看到了能力被练出来的那一刻,却没看到停练之后它还在不在。缺的不是好看的数字,缺的是时间轴上第二个数据点——同一批应用在一年、两年后的存活与迭代记录。有了那个点,这个案例才能从「一次成功的快速交付」升级为「一次成功的能力建设」的证据。

同一套 Power Platform,放在两种组织设计里,会长出完全不同的东西。SCDF 走的是有中心统筹的路径:HTX 提供工程底座,数字工厂做建制化沉淀,应用集中在一个可见的组合里。这条路的风险是能力过度集中在中心、一线始终是使用者。但还有另一条更常见、也更危险的路径,值得作为反面对照:彻底放开的 citizen developer 模式,任由每个部门自己拖拽出应用,没有中心团队兜底。

这条路的失败模式在业界有个熟悉的名字:影子 IT。低代码把造应用的门槛降到人人可为,好处是需求响应极快,代价是很快冒出成百上千个无人登记、无人审查、无人负责的应用。它们绑着敏感数据、接着关键流程,作者一离职就成了没人敢碰又不敢关的黑箱。对一支处理应急救援、人员部署这类高后果业务的部队来说,这种熵是不可接受的:一个换班或派勤逻辑出错,后果不在报表上,在现场。SCDF 选择用 HTX 的工程能力和数字工厂来兜住这条底线,是合理的取舍;它宁可牺牲一点「人人皆可造」的纯度,换来可治理性。

还有第三种失败模式,比影子 IT 更隐蔽,也和 SCDF 这条路更贴近:中心交付的「金丝雀应用」。中心队做工又快又好,一线也乐得有人代劳,于是所有应用长期由中心一手包办,一线始终不必学会自己改。表面上井井有条、组合可控,但整个体系的能力和记忆全锁在那支中心队里,一线对这些工具的理解停留在「会点按钮」。这种模式平时运转良好,风险要到中心队因预算或改组而收缩时才暴露——那一刻才发现,没有一个消防站能接手养自己天天在用的那个 App。它不像影子 IT 那样制造混乱,而是制造一种脆弱的整洁:整齐,但一碰就散。

三种模式的对照点,恰恰落在同一个轴上:能力到底该长在哪。彻底放开是把能力尽数推给一线,却守不住;金丝雀式的全集中是守得住,却没真正下沉,还养出对中心的隐性依赖。SCDF 目前明显偏集中一端,这在早期是对的:先建承重墙,再谈往一线放。但对照也提醒:偏集中的代价,是「数字一线人员」可能长期停在口号,一线永远差最后一公里没拿到维护权。理想状态是有脚手架的能力下沉:中心团队立标准、做审查、兜底维护,同时持续把可迭代的应用逐步移交给一线,并留下谁改坏了谁能修回来的机制。这条中间路难走,却是把「能力建设」和「集中交付」「影子 IT」区分开来的唯一位置。

对东盟及新加坡本地的公共机构和大型企业,SCDF 案例可迁移的不是那几个 App,而是那套组织设计的骨架。值得抄的有三条,且都是组织动作而非技术选型。其一,先建承重墙再谈下沉:像数字工厂那样立一支懂工程、能立标准做审查的中心队,给一线的自建圈出安全边界,而不是一上来就全放开赌自觉。其二,把交付周期当成能力指标而非炫耀指标:1 至 3 个月的意义在于它让「造得起工具」这件事进入日常,而不在数字本身好看。其三,从第一天就为交接和维护设计:在应用上线时就明确谁能改、作者调离后谁接手,别把这笔账留到出问题才算,这恰恰是公开记录里 SCDF 也还没展示的一环,后来者可以做得更早。

真正的价值主张需要落在一个只有这个案例支撑的机制上:公共部门低代码 AI 的价值,在于把「构建能力」沉到一线并且可维护;检验它的验证点,是一线自建应用的存活率和可维护性,而不是上线数量。上线数量是最容易刷、也最容易骗自己的指标;而一个 App 在中心团队注意力移开之后,还有没有一线的人在用、在改、在养,才是那块肌肉到底长在谁身上的唯一证据。把跑步机搬进健身房很快,难的是让人年复一年自己来练。

所以不必断言 SCDF 一定会成功,更该给出一个会证明这条路走岔了的反向信号:如果哪天中心能力团队(数字工厂或 HTX 那支队)因预算、改组或人事变动而撤出或缩编,而一线自建的那批应用随即无人维护、逐渐荒废、悄悄被旧流程替回去——那就说明能力从未真正下沉到一线,之前长出来的是中心的肌肉,一线只是借用者,承重墙一撤楼就塌。触发条件很具体:盯中心团队的编制和预算是否稳定,以及应用的留存与迭代数据是否开始由一线而非中心产生。反过来,如果中心队转做平台和治理、把日常迭代交给了站里的人,而应用存活率不降反升,那才是这套「数字一线人员」叙事真正兑现的信号。这个案例现在只给了第一个数据点,值得在 12 到 24 个月后回来看第二个。