有数了·洞见|跳出源码陷阱,信创下半场,如何实现“真·自主可控”?

源码交付的三重拷问：

自主可控为何成 “表面文章”？

后果一：财政资金的 “慢性失血”

部分供应商深谙 “低价中标 + 高价维保” 的套路，以低于成本的价格拿下项目，再通过后续服务获利。后续维保与升级费用往往数倍于初始建设成本，由于缺乏替代方案，政府只能被动接受，造成财政资金的长期低效消耗。

后果二：系统迭代的 “致命停滞”

当供应商因经营不善、团队解散或战略调整放弃对系统的支持时，甲方将面临 “无人维护” 的绝境。部分地区曾出现系统因供应商退出而漏洞无法修复、新政策无法适配的情况，最终只能投入巨资推倒重建，期间的服务中断给群众带来极大不便。

后果三：市场环境的 “恶性扭曲”

技术壁垒导致的供应商锁定，让新竞争者难以进入市场，形成 “一商独大” 的垄断格局。这不仅让政府失去议价权，更打击了优质企业的参与积极性，最终导致信创市场陷入 “劣币驱逐良币” 的恶性循环，阻碍了整个行业的技术创新与良性发展。

重新定义 “真・自主可控”：

新加坡 GovTech 的实践启示

维度一：过程透明

让开发全程 “看得见、可追溯”

传统模式下，供应商在私有环境开发，甲方只能在验收时 “看结果”，过程完全黑箱。GovTech 的破局之道，是搭建统一的开发协作平台 SHIP-HATS（基于 GitLab 的 CI/CD 流水线），并强制要求所有核心业务系统开发必须接入该平台。

这意味着供应商不能再 “关起门干活”，而是必须在甲方搭建的 “公共车间” 里开展工作：每一行代码的提交人、提交时间、修改内容，每一个功能模块的测试记录、问题反馈，政府项目管理人员都能实时查看；项目进度不再依赖 PPT 汇报，而是以代码提交频率、测试通过率、文档完善度等客观数据为依据；甚至可以通过平台追溯某个功能的开发全过程，实现“问题可查、责任可追”。

这种模式下，甲方拿到的不再是验收时的 “一次性成果”，而是软件生产的全生命周期数据，从根源上杜绝了 “交付代码与运行代码不一致” 的问题。

维度二：架构掌舵

把核心逻辑 “抓得住、不放手”

过去，甲方因缺乏技术人才，只能将系统的架构设计、逻辑定义完全交给供应商，导致 “需求修改要看供应商脸色”，供应商一句 “架构不支持”，就能让合理的业务调整搁浅。

为解决这一问题，GovTech 组建了专门的政府数字服务团队（GDS），并重点培养 “紫色人才”，这类人才既懂政府业务流程，又具备技术架构思维，是连接业务与技术的核心桥梁。

“紫色人才” 并不需要亲自编写海量业务代码，其核心职责是 “掌舵”：主导系统核心架构的设计，确保架构具备扩展性、兼容性；制定统一的开发规范与代码标准，避免出现逻辑混乱、难以维护的 “天书代码”；行使代码合并（Merge Request）的最终审批权，所有供应商提交的代码必须经过他们审核，确认符合架构要求、逻辑无误后才能合并入主干版本。

这一机制让政府牢牢掌握了系统的 “核心骨架”，供应商仅负责 “填充血肉”（具体业务模块开发）。即便更换供应商，新团队面对的也是架构清晰、标准统一、文档完备的代码，接盘成本大幅降低，从根本上破解了 “换供应商难” 的困境。

维度三：持续演进

让系统具备 “能适应、可生长” 的能力

传统外包项目多采用 “瀑布式” 交付，上线即固化，难以应对快速变化的需求。GovTech 则通过标准化组件复用与自动化测试，让系统具备了持续迭代的能力。

他们搭建了智慧国技术堆栈（SGTS），将身份认证、电子签章、统一支付、数据加密等通用功能沉淀为标准化组件，任何政府业务系统开发都可以直接复用这些组件，无需重复开发；同时建立了完善的自动化测试体系，新代码提交后，系统会自动进行单元测试、集成测试、安全测试，确保新增功能不影响原有系统稳定。

这种模式下，系统不再是 “一次性交付的工程”，而是 “持续生长的产品”。在 COVID-19 疫情期间，新加坡政府依托这套机制，仅用 2 周时间就上线了口罩申领系统，1 个月内完成了疫苗预约平台的迭代优化，快速响应了民生紧急需求。这背后，正是持续演进能力带来的 “反脆弱性”，系统能快速适配新需求、新环境，而非面对变化时束手无策。

内源机制：

激活数字政府的新质生产力

转型一：从 “低水平重复” 到 “复用式创新”，破解财政资金浪费困局

长期以来，信创领域的 “重复造轮子” 现象极为普遍：不同地区因政策差异或供应商不同，对同类业务系统重复开发，造成了巨大的财政资金浪费。

内源机制的破局之道，是建立 “国家级 / 省级代码共建库”，参考新加坡 SGTS 模式，将政府业务中通用性强的功能模块，如身份认证、电子证照调用、统一缴费接口、表单引擎等，沉淀为标准化、可复用的组件资产。这些组件经脱敏处理和标准化封装后，放入共建库供各级政府共享使用：

1、甲地开发出优质组件后，经专家评审纳入共建库，其开发投入转化为 “公共资产”；

2、乙地建设同类系统时，可直接从共建库中 “Fork（复用）” 该组件，仅需针对本地特殊政策进行少量定制化开发；

3、组件的后续优化升级由使用方共同参与，形成 “一次开发、多地受益、联合迭代” 的良性循环。

这种模式让财政资金的使用效率实现质的飞跃：从过去分散投入于功能雷同的重复开发，转向支持 “基于共有成果的差异化创新”，每一笔财政资金都在为全国或全省的公共技术底座添砖加瓦，实现了 “1+1>2” 的集约效应。

转型二：从 “被动数据烟囱” 到 “主动接口透明”，释放数据要素价值

“数据不通” 是数字政府建设的老难题，除了部门利益导致的行政壁垒，技术壁垒同样难以逾越。不同供应商开发的系统，数据结构、接口标准千差万别，且往往被视为 “商业机密”，即便有行政命令要求数据共享，也会因对接成本过高、技术谈判漫长而不了了之。

内源机制从技术根源上破解了这一困境：代码透明是接口标准化的 “天然催化剂”。在内源模式下，应用系统的代码对政府内部开放，其数据字典、接口定义（API Definition）自然无法隐藏，政府可以制定统一的接口标准，要求所有接入系统必须遵循。

配合统一的 API 网关（如新加坡的 APEX 平台），数据共享将变得像 “搭积木” 一样简单：部门之间无需再进行复杂的线下协调和供应商谈判，只需通过网关调用标准化接口，就能实现数据的安全、快速流转。这让数据跨部门流动不再依赖 “人为配合”，而是成为系统的 “出厂设置”，真正打破了 “数据烟囱”，释放了数据作为核心生产要素的巨大潜能。

转型三：从 “被动应急” 到 “韧性治理”，筑牢网络安全防线

信创软件的开发离不开开源组件的支撑，但传统黑盒交付模式下，甲方对系统内部引用的开源组件一无所知：用了哪些版本、是否存在高危漏洞、是否有恶意代码植入，都只能依赖供应商的 “口头承诺”。曾有高危漏洞爆发时，多个系统因无法快速排查是否使用相关组件，只能被动停机排查，造成了严重的业务中断；部分系统即便知道使用了该组件，也因缺乏代码掌控力，无法自主修复漏洞，只能等待供应商提供补丁。

内源机制通过构建 “供应链治理防线”，将安全防御从 “亡羊补牢” 推向 “未雨绸缪”。其核心做法是将 SBOM（软件物料清单）管理与自动化流水线深度融合：每当供应商提交代码时，系统会自动扫描代码中引用的所有第三方组件（包括开源组件、商业组件），生成详细的 SBOM 清单，明确组件名称、版本号、来源渠道；同时与安全漏洞数据库实时联动，一旦发现组件存在高危漏洞，立即触发预警，并提供修复建议。

这种模式下，甲方能够全面掌握软件的 “物料构成”，确保跑在国产硬件上的每一行代码都是 “清洁、可知、可控” 的；更重要的是，当安全危机爆发时，能够快速定位受影响的系统和组件，自主组织修复，不再依赖供应商的响应速度，为数字政府构建起强大的反脆弱性和自愈能力。

中国特色内源之路：

“点 – 线 – 面” 落地策略

切入点：选择非涉密、轻量级的小项目（如便民服务小程序、内部办公轻应用、查询工具等）作为试点，这类项目复杂度低、影响范围小、调整灵活，适合作为内源机制的 “试验田”。

核心逻辑：不急于推翻存量系统，避免引发过大阻力，而是通过新项目试点，建立新的开发模式和管理习惯，形成可复制、可推广的经验。

落地抓手：重构招标文件（RFP），将 “内源要求” 明确写入合同条款，实现 “资产归位”：

1、明确开发阵地：乙方必须在业主方指定的代码托管平台（如政务云 DevOps 平台、国产化代码管理工具）上进行全周期开发，严禁在私有环境开发后一次性拷贝代码交付。这本质是让代码 “在政府的地盘上诞生、生长”，从源头确保可控性。

2、重塑进度评估：项目进度不再以阶段汇报、PPT 演示为依据，而是结合代码提交频率、测试用例通过率、文档完善程度等平台客观数据综合判定。让进度 “用代码说话”，避免 “表面推进、实则滞后”。

3、明确资产归属：代码、开发文档、测试用例、API 接口定义、构建脚本、环境配置说明等所有数字资产，所有权均归业主方所有。验收核心是完成平台权限移交、资产盘点归档，而非接收硬盘或光盘”，让验收从 “收物” 变为 “收权”。

预期目标：解决 “看不见、管不住” 的问题，让代码从供应商的 “私有财产” 真正转变为政府及企业的 “受控资产”，验证内源模式在国内场景的可行性，积累项目管理、平台使用、流程衔接的实战经验。

核心痛点：内源机制落地的关键的是甲方具备 “技术把关能力”，如果缺乏懂业务、懂技术的核心人才，即便有了统一平台，也无法实现对架构的掌控和代码的审核，最终仍会陷入 “形式化内源”。

核心逻辑：不搞 “一刀切”，根据各单位的实际情况，灵活配置 “技术把关人”，补齐能力短板，构建 “管运分离” 的治理结构，政府负责 “管标准、管架构、管质量”，供应商负责 “做开发、做测试、做交付”，避免供应商既当 “运动员” 又当 “裁判员”。

落地抓手：推行 “分类施策” 的人才供给模式，适配不同单位的需求：

1、场景A（技术强局）：对于信息化基础好、已有一定研发能力的单位，鼓励自建核心架构团队。团队成员可从内部选拔业务骨干进行技术培训，或通过公开招聘引入专业技术人才，直接承担系统架构设计、开发规范制定、代码审核、质量管控等核心职责，掌握绝对话语权。

2、场景B（编制紧缺）：对于大部分缺乏专职技术人员、编制紧张的单位，不强求自建团队，而是通过 “采购技术治理服务” 的方式，引入中立的 “第三方技术管家”。这类第三方机构需具备信创领域经验、熟悉政府业务，且与系统开发供应商无利益关联，其核心职责是代表政府行使架构评审权、代码抽检权、标准监督权，确保开发过程符合内源要求，成果达到质量标准。

3、场景C（资源有限）：对于基层区县等资源有限的单位，可由省级或市级主管部门统一组建 “技术把关专班”，为辖区内的基层单位提供共享服务。比如由省大数据局组建专业团队，负责全省范围内小型政务应用的架构审核、代码抽检，既降低基层单位的成本，又能保证标准统一。

预期目标：让每个内源项目都有明确的 “技术把关人”，确保能够真正主导系统架构、掌控核心逻辑，从 “被动接收” 转向 “主动管控”，破解 “技术依赖” 的核心困境。

核心逻辑：内源机制的规模化推广，需要统一的技术底座作为支撑，就像工业化生产需要标准厂房和设备一样，软件的集约化生产也需要统一的开发流水线、协作平台和工具链。无需像新加坡那样从零自建复杂平台，而是充分利用现有信创资源，通过 “自建 + 采购” 结合的方式，快速补齐底座能力。

落地抓手：推行 “灵活供给” 的底座建设模式，各地可根据自身信息化基础选择适合的路径：

1、路径A（基础较好）：对于已有成熟政务信创云的地区（如北京、上海、广东等信息化发达省市），可直接基于本地政务信创云的 PaaS 层能力，搭建统一的 DevOps 流水线。整合国产化代码管理工具、自动化测试工具、安全扫描工具、部署工具等，形成 “一站式” 开发协作平台，将所有内源项目的开发过程纳入平台管控。

2、路径B（基础薄弱）：对于信息化基础薄弱、缺乏自建能力的地区，可采购中立第三方的 “信创适配版 DevOps 平台运营服务”，由第三方负责平台的搭建、工具链整合、安全配置、日常维护，政府只需提出需求、使用平台、进行监管，无需投入大量人力物力进行技术维护。

3、路径C（协同共建）：对于省域范围内的多个地区，可采取 “省级统筹、各地共用”的模式，由省级主管部门牵头建设统一的内源开发平台，各地市通过政务专网接入使用。既降低单个地区的建设成本，又能保证全省范围内的开发标准统一、组件复用、数据互通，为后续的代码共建库、数据共享平台建设奠定基础。

关键要求：无论选择哪种路径，技术底座都必须满足两个核心条件：一是信创适配，平台本身需基于国产操作系统、国产数据库、国产中间件构建，适配主流国产芯片，符合信创产业发展要求；二是安全合规，具备国密级加密能力，确保代码、数据等核心资产的安全，满足政府信息系统的安全等级保护要求。

预期目标：将分散在各个供应商手中的 “手工作坊”，逐步收敛为政府统一管控的 “数字化透明车间”，实现软件开发的 “标准化、集约化、可控化”，为内源机制的全面推广提供坚实的技术支撑，推动信创产业从 “硬件替代” 向 “能力升级” 的深度转型。

结语：

从 “资产拥有” 到 “能力掌控” 的进阶

作者介绍