ARTICLE · 1205528
AI时代,软件到底是上坡路还是下坡路?
AI时代,软件到底是上坡路还是下坡路?最近几番论战非常有意思。虽然脱离审计圈很多年，不过仍在财务信息化这个圈子里混，这两年谁也逃不开AI。 虽没有仔细阅读研究始末，也粗粗浏览了几篇文章。正好最近又在开发AI相关的功能，也来凑个热闹谈谈自己的理解。 虽然这次的讨论是在说审计软件，但其实AI时代之后，所有的软件都会面临相似的问题。显然这两年的美股股价一定程度上反映了这一点。从高点回落、到低位震荡、再到近期回升。 
从各家模型厂商发现coding是真的有商业化可能的领域之后，25年下半年开始AI coding能力大幅提升，直到现在几乎已经没有人再古法手搓代码。这在软件开发领域显然已经形成了共识。 大家还在摸索的只是对于整个团队或者说软件交付的端到端供应链来说，如何才能进一步提高整体产出的效率。也因此大家在是不是还需要产品经理，前端代码应该产品写还是后端写，测试怎么办等种种环节争论不休。 然而AI Coding的能力提升，既没有如此倍数地泛化到整个软件交付行业，就更没有到其他领域了。比如财务、比如审计。 传统的工作流程上，必然有1-N个人类负责初步产出，他们知道执行层的细节，同时也负责在这个层面上跟其他人类进行沟通交流。比如一线开发要跟一线产品、测试等沟通，审计小朋友要问客户拿材料等等。 然后再由高级一些的人类进行复核。那怎么复核呢？传统上代码要进行coding review；审计/财务底稿则先看数对不对得上，放一些check公式，然后看该分析的该拿材料的有没有都做，再去看结果是不是符合自己预期。 所以传统的初步生成过程，包括了执行level的经验、生成的可验证的结果、跟其他人交叉沟通得到的结论等等。而复核则包括了更高更抽象层次的对这项工作的理解。 但起初AI生成的必然不是这样，说到底它确实是概率化的基础。虽然到了现在这个时间点，你用国外的模型，几乎已经不用再纠结幻觉与否的问题，或者说，它可能出错的概率不会比你的普通同事更高。但它的原理仍然决定了你很难核对它的结果。 这就跟传统信息化数字化的逻辑产生了极大的背离。传统意义上，总是逃不过一开始excel单次处理——多次之后做成公式、模板，每次只要少量手工操作——系统化，进行标准数据集成并把所有规则系统化，覆盖所有边界情况，人工进行复核。 这样的流程虽说耗时耗资巨大，但可以极大程度减少出错概率，并大大加快流程。以前需要十天半个月的管理报告，上系统之后可能几天内就能获取到。财务信息结果获取的时效性对上层有重大的意义。 所以，传统判断是否值得信息化的逻辑一定在于，原来的流程是否高频、是否高价值。才值得组织起多个部门的人，逐一调研，产出蓝图。一个个对接系统进行字段和逻辑的梳理，将原来只在人脑和excel表格中的逻辑组织成系统化的语言。再要交付给实施顾问或者开发进行配置与开发。 但这样的做法是有穷的。实际业务通常80%是正常情况，而20%是异常例外。但程序开发往往在主流程上花20%的时间但需要在例外上花80%的时间才能保证一切情况都得到了妥善处理。更何况业务是在不断变化的，因此后续也需要不断叠加叠加叠加。 但AI来了之后，不管你是会代码的还是不会代码的，但凡你尝试过，你一定会发现问题在于产出的内容你不能精确控制与核对。老板要是问这个数字怎么来的，答不上来啊。 那怎么让AI能固定产出内容呢？显然，模仿以前模板的逻辑，既然现在AI coding能力那么强，那就让它生成固定的脚本，这样就能保证每次的输入和输出是一致的了。 但如果生成的是固定的脚本，跟以前开发一段程序又有什么区别呢？ 可以解释说： 1）开发的门槛降低了，普通人也能vibe coding了。毕竟原来很大的工作量在于业务逻辑的理解与转换。需要业务人员、产品经理、开发、测试 四个工种理解业务逻辑，而现在如果是由业务人员自己处理，那就只要一个人了。 但这一解释的问题在于实践发现能自己掌握vibe coding，知道自己要什么，说得清楚逻辑，能开发一个个人意义上可以持续维护运行的程序的业务人员并没有想象中多。 先不说掌握最基本代码常识(理解前后端、数据库，知道为什么localhost别人不能访问)的业务人员非常稀有。传统上，做how和what的人和知道why的人一定是两层人。 于是很显然如果一个主管本来有一个管理报告是由下属交付的。如果他知道里面的这些映射分摊规则为什么要这么设计，那他很可能不知道这里的数要从哪些系统找哪些IT拿到。 而相反，如果一个执行的人对这些数据处理的逻辑很清楚，那他也很可能不能从原理上概括出为什么要这样，以至于就算一次性能实现，在后续的过程中也还是要反复修改。最终确实提升的只是单人的工具化处理效率。 这就像以前企业里会写VBA的大神，虽然得到了普罗大众的尊敬，但似乎从整个企业层面上来说并不值一提。因为企业所需的整个信息化协同流程中，逻辑处理只是一小个环节。而这样的人也没有匹配的激励机制让他能持续这么进行下去。 但客观上，这样的模式对于个人效率的提升是最显著的。因为它不仅是加速，它通过拓宽这个vibe coding的人的技能边界，把原来需要跟人沟通、登录系统、找IT等等的工作全部内化为人+AI互动的模型，指哪打哪。 2)由程序员把【生成固定脚本】这件事进一步深化。做成所谓的工具或者引擎。这也往往是目前软件厂商在做的事情。 普通人写的脚本(哪怕利用ai写)往往是枚举的。而普通人甚至看不出这种枚举来。比如你让它写一个处理excel的脚本，它往往会固定取你本地这个文件夹的路径里固定这个名字。于是你下次发现有问题，不能直接执行，就再要求他修正。 虽然AI完全可以很快地根据你要求的逻辑写出不枚举的代码，但是普通人原来并没有这样的【常识】，也因此他无法在初始就清楚地跟AI表达它的业务规则，以及是否需要这个工具能否在服务器上持续运行，是给自己一次性运行还是要发给其他人，其他人的电脑是win还是mac还是信创等等等。 而AI在不知道这些信息的情况下，也只能依据它自己的理解先来一版，然后持续纠正优化。 而程序员天然就有这些概念，只是以前生产好的代码的成本太高了，任何一个小功能都需要花时间去编写、联调、测试、修改、运维。现在只要开发这个程序的人比较理解业务逻辑，开发这一环节的效率可以倍数提升。 于是，对于跟财务有关的原本就是偏规则偏计算的领域，大可以快速地把常见的场景全部都脚本化，且尽可能多的为AI提供所需的规则和其他上下文。并且告诉AI我有这些逻辑。 于是使用者就可以通过自然语言的形式去进行需求的描述，也可以通过自然语言去维护一些业务规则或者术语列表，再由脚本产生出结果。 这一方面大大降低了逻辑的不可控性，另一方面也提升了用户体验，改变了以前需要先进行培训，学习软件的使用方式的整个流程。 而整体来说，它必然会且已经在改变整个软件行业。 需要注意的是，以上说的任何一个小点，其实在24年各家软件单点也都会搭载。比如菜单搜索不用你记了，你用你自己的语言说，它帮你列出近似的。但以前单点的能力可以认为是都是把LLM当做自然语言解析器在使用。随着点连成片，AI的模型能力愈发强大，上下文窗口越来越多，执行工具相关的协议越来越完善，这些单点的功能逐渐综合化成了AI Agent。AI功能不再是一个个单点的按钮，而可以完整获取你的需求和上下文，帮你执行。 当然这时懂行的人会问那如果通过本地AI工具调用MCP的形式是否也可以达到类似的效果呢？是的 所以在我看来，短期的未来AI时代稀缺的可能会是对AI工作流的理解和总结。 虽然本质上仍然是AI大模型能力+工具执行能力(规则、脚本等等都可以归结到tool)，但由于AI的能力进展非常迅速，大部分工作过去依赖的经验化的积累都无法跟上这样的节奏。 这个时间段，能够理解如何把过去某个端到端产出的工作流程转换成和AI适配的新的工作流程，并且能让使用者感到可信的能力，是非常稀缺的。这意味着需要理解why、how、what以及模型能力的边界、工具怎么设计、上下文怎么给、交付的步骤和内容如何呈现。企业级很重要的还有权限以及给到模型的内容是否需要脱敏。 更进一步的，企业在AI时代的生产力改变了，如何匹配对应的生产关系改变？ 这在不同的行业都会有不同的答案。 写到这里本文已经三千字啦。在AI这个大的浪潮之下，一周约等于过去两个月的节奏。任何想法和观点的时效性都极其短暂。 因此我的建议只有：多使用AI，有任何问题尝试用AI解决，如果它解决不了，问他为什么，如何才能解决。 你没有必要一定要理解Agent的原理，harness和model是什么关系。但你也别信那些说不用学，很快会过时的人。 你只要学会了开车，哪怕你对车的机械原理毫不理解，你也比那些走路的人要快成千上万倍，你可以去到过去你从未敢想的地方。
一些周末无聊的抒发。 欢迎大家留言自己在财务相关领域的一些对AI的想法、问题或是觉得可能可以用AI解决的难点，一起讨论。
这些软件公司的股价，也让人想重新思考一个问题：AI 到底是在削弱软件的价值，还是在改变软件创造价值的方式？
