现代公民开发平台的光与影 3/7

引言

在第 1 回与第 2 回里，我们确认了 EUC 与神 Excel 虽然短期拯救了一线，却给组织留下了长期的负资产。本篇把视角移到现在，检视 RPA 与无代码／低代码等现代公民开发平台的光与影。

它们既是神 Excel 的重演，同时在规模与依赖度上潜藏更大的风险。为了在下一回讨论生成式 AI 的冲击，我们必须先正确理解它们的特性。

无需写代码，只靠 GUI 操作就能很快完成简单的自动化或应用。把每日的抄录或例行处理在数天内替换掉，对第一线来说价值巨大。

以流程图或画面设计呈现成果，让没有专业知识的人也能直接理解。对管理层而言，看到“会动的图”就像看见成果本身，常常成为推动导入的决断因素。

在输入表单或轻量级工作流程等限定用途上，非工程师也能自制工具。至少到这个阶段，确实能感受到“谁都能做”，成为组织整体扩展公民开发裾野的入口。

表面看来似乎“谁都能操作”，但一旦想在实务上正式运用，最终还是需要与编程同质的思维和系统工程视角。

控制结构无法回避 按客户条件拆分处理就必须有条件分支（If/Else）。要处理数百笔数据就离不开循环（ForEach）。为了预防外部系统的延迟或错误，异常处理（Try/Catch）是必需的。GUI 只是换了呈现方式，本质仍是编程。
必须理解数据结构 展开 JSON 或数组、映射层级、统一日期与数值格式——这些都是业务整合不可或缺的作业。仅靠表格思维无法收拾，没有数据结构知识就会崩溃。
系统间联动依旧复杂 API 认证的有效期管理、跨系统的一致性、速率限制的规避等，都与传统软件工程的课题如出一辙。只不过被 GUI 掩盖了，难度甚至更高。
运营与质量的要求仍在 监控、日志收集、测试与正式环境的差异管理、发布时的回滚计划——缺乏这些运营设计，很快就会陷入混乱。无法用代码管理的部分，也更容易失去可观察性。

面对这堵墙，公民开发者很难单独构建并维持可用于生产的系统，最终还是得依赖专业技术者。原本的产能瓶颈并未因此解消。

神 Excel 至少还有救赎之处：它存在于单一文件中。表格数据可以导出成 CSV，函数与宏虽然受限于 Excel，但仍能用其他表格软件部分兼容，也能读懂代码。相反，RPA 与无代码／低代码的成果大多被封在平台专属的 UI 或设定文件里。

与仍能在文件层级收尾的神 Excel 相比，其依赖程度与负债风险高出许多。

技术人员很快就能看出“专业墙”终会出现。但管理层看到用 GUI 画出的流程或画面，就容易以为“这谁都可以”。

为什么？因为对管理层而言，系统平常是黑箱。当看到箭头串起的业务流程与输入表单时，就会觉得自己已经理解内部复杂度。然而现实是，背后仍是同样的控制逻辑与错误处理，要在实务中撑得住，仍离不开工程知识。

这种“管理层的安心感”与“技术者的警惕”之间的落差，既加速导入，也成为扩大未来负债的温床。

综上所述，RPA 与无代码／低代码正沿着神 Excel 的轨迹前进。它们以立竿见影的成果拯救一线、以可视化说服管理层，最终随着黑箱化与属人化，给组织留下沉重包袱。

但决定性的差异在于影响范围。神 Excel 只在文件层级收尾，现代公民开发却嵌入云端与整个核心业务，可能演变成束缚组织规模的负债。更糟的是，它们具备比 Excel 更强的锁定结构，由此招致“神 Excel 2.0”般的局面。

现代公民开发的力量比神 Excel 更强，同时也更加危险。下一回，我们将检视当生成式 AI 加入这股潮流时会发生什么。