生成式 AI 拯救的遗产与被舍弃的遗产（4/7）
前言
在第 3 回里，我们确认了当代的公民开发基础——RPA 与 no-code/low-code——隐藏着甚至超过神 Excel 的债务风险。 在这条延长线上，生成式 AI 的登场究竟会改变什么？
生成式 AI 能读取既有的软件资产，协助迁移或重新设计。 但那些没有写成代码的资产——no-code 与 RPA 的黑盒——即便对 AI 来说也难以现实地拯救。
换句话说，未来会留下的负资产，很可能集中在“没有被写成代码的东西”上。
全系列
- 洞察公民开发的未来──历史、当下、生成式 AI 以及更远的前方 0/7
- 公民开发是 EUC 的回归吗？──神 Excel 的历史教训 1/7
- 神 Excel 真的是反派吗？──从救世主到负资产 2/7
- 现代公民开发平台的光与影 3/7
- 生成式 AI 拯救的遗产与被舍弃的遗产 4/7 （本回）
- 公民开发并非万能──它是“草稿式开发” 5/7
- 视角错位如何批量制造负资产 6/7
- 遗产仍会不断诞生，也要驯服它──公民开发的未来图景 7/7
生成式 AI 的强项──“解冻”代码资产
传统上，迁移遗留代码需要庞大的人力。 用 COBOL 或 VB 等旧语言写成的数百万行程序往往没有文档，只能依赖资深工程师分析。
生成式 AI 在这里打开了缺口。
-
自动化的代码阅读 它能可视化函数之间的依赖关系，并从上下文推测变量或结构的含义。
-
语言转换的辅助 生成从 COBOL 到 Java、从 VB 到 Python 等迁移草稿，成为移植工作的起点。
-
半自动化的重构 把意大利面式的逻辑拆分成函数，生成测试代码，让后续团队能以更顺手的形态接手。
总之，只要资产仍以代码形式存在，AI 就能半自动地将其“解冻”。 在这点上，生成式 AI 有潜力成为基于代码的遗留系统更新的游戏规则改变者。
当然，“有代码就一定能救”并不成立。 如果依赖环境已经消失，或掌握业务知识的人早已离开，仍会留下 AI 无法填补的空缺。 但与只剩下黑盒的资产相比，重生的可能性高出许多。
无法拯救的对象──从未被代码化的资产
相对地，用 no-code 或 RPA 制作的资产又如何？
它们以 GUI 操作或流程图的形式存在，内部表示被封在厂商独有的数据结构里。 生成式 AI 最擅长处理文本，面对被加密或专有格式封装的黑盒，分析极其困难。
例如 RPA 的“业务流程”，表面看似积木流程图，实质上多半是加密的项目文件。 no-code 的“应用”往往只能在厂商云端运行，根本没有考虑以源代码形式导出。
在现实中，重新设计往往比救援更快。 或许未来的研究能从操作记录或画面截图推测流程，但至少在当前，要直接继承黑盒化的资产几乎不可能。
负资产的分水岭──是否留在代码里
于是我们看到了决定未来负资产的分水岭。
- 留成代码的资产，因为生成式 AI，而开启了再利用、迁移与改善的道路。
- 未被代码化的资产，对生成式 AI 来说有大片不可见的部分，只能重新设计。
也就是说，未来能否获救取决于 “它是否以代码的姿态被留下”。 生成式 AI 让这条分界线愈发清晰。
展望──AI 不是万能的救世主
生成式 AI 的确强大，但至少现在还远非万能。 它无法完全拯救已经黑盒化的公民开发资产，也无法替过去的决策洗白。
AI 迫使我们直面 “不写代码的自由”所要付出的代价。 被 no-code 的即时效果吸引的组织，将发现自己得不到 AI 的援手，只能自行承担重新设计的成本。
因此，下一回将深入探讨 如何避免制造负资产──从治理设计的视角。