ARTICLE · 1075306
使用AI编程完成某大型工业软件投标评估版本,我更想谈谈代码之外的事
使用AI编程完成某大型工业软件投标评估版本,我更想谈谈代码之外的事今年，AI编程辅助我们完成了一套油气田地面工程数字化平台的投标评估版本。 这几年AI编程发展很快，软件开发的速度也确实发生了很大变化。这次项目做下来，我对这种变化有了更具体的感受：AI已经可以承担大量编码、测试和文档工作，但一个工业软件项目要真正往前推进，前面还有很多工作需要人先想清楚。 我1995年开始用C++写程序，到现在已经三十多年。中间长期做油藏数值模拟、数字油田和孪生数字油藏，也在互联网大厂工作过，还做过一段时间金融量化。经历的技术栈变了很多，软件开发的方法也一直在变。 这几年AI进入开发流程以后，变化确实很明显。写代码快了，做原型快了，测试和文档也快了。过去需要几周才能做出来的东西，现在可能几天就能看到一个能运行的版本。 但这次项目做下来，我最大的感受还是，代码提速只是其中一部分。前面有几件事情如果没有想清楚，后面写得再快，返工也会很快。 先把客户每天怎么干活弄清楚 拿到技术需求以后，最容易的做法，是按照招标文件拆模块，再按照模块拆功能。 很多软件项目过去就是这么做的。现在有AI以后，这种做法更有诱惑力，因为每一个功能看起来都能很快做出来。 问题出在实际工作流程上。 油气田地面工程涉及站场、管网、设备、计量、处理和生产运行，很多数据和计算前后关联。一个节点的工况发生变化，后面的分析和判断往往也要跟着变。 技术文件通常会写需要哪些功能，却很难把工程师一天到晚怎么用这些功能完整描述出来。 比如，一个生产节点的工况变化以后，管网计算要不要重新跑？设备运行参数变化以后，系统只更新数据，还是要提醒工程师检查上下游影响？现场数据开始偏离设计工况时，只把两条曲线画在一起够不够，还是需要继续判断偏差从哪里开始，前面发生了什么变化？ 这些问题不一定写在招标文件里，软件一旦投入使用，很快就会碰到。 所以前期我们花了不少时间，把功能列表重新放回工程师的工作流程里看。 谁产生数据，谁接着用；一个结果变了以后，会影响哪些后续工作；哪些可以自动流转，哪些环节必须由工程师确认。 我过去做油藏数模时，也一直碰到类似问题。 数模软件看起来是方程、网格、求解器和各种模型，用户实际工作时关心的却是一整条链条：地质模型怎么进来，井数据怎么处理，历史拟合怎么迭代，方案变了以后哪些结果需要重新计算。 后来做孪生数字油藏，这种感觉更强。模型、数据和业务流程没有连起来，页面再多也只是页面。 做工业软件久了以后，我会习惯先问一句：这个数据后面谁还要用？这个结果如果变了，会影响什么？ 这类问题对产品的影响，往往比某个按钮放在哪里大得多。 系统早期看着顺，不代表以后不会乱 第二个让我花很多精力的地方，是架构。 AI提高开发速度以后，功能很容易迅速堆起来。项目刚开始时，这会让人很有成就感：页面一个个出来，接口一个个通，系统看上去每天都在往前走。 问题通常不会马上出现。 真正开始接数据、扩模块、多人协同以后，前期的数据关系和服务边界如果没处理好，麻烦会慢慢冒出来。 我在互联网公司工作时，对这个问题感受很深。用户数、数据量一上去，早期一些不起眼的设计问题很快就会放大。后来做金融量化，又多了一层体会：数据时间是否对齐、版本是否一致、过程能不能复现，这些事情只要有一点含糊，最后的结果就可能完全失去意义。 工业软件也一样。 我们在开发前花时间讨论了很多底层问题：项目基础数据怎么组织，设施和设备数据怎么挂接，动态生产数据怎么保存，不同计算模块怎样共用一套基础数据，数据修改以后哪些结果要重新计算，版本怎么追踪，以后数据量上来以后系统怎么扩展。 这些内容做产品演示时不太显眼，却会直接影响系统以后好不好维护。 这一阶段我也会大量用AI。 通常先有一个初步方案，再让AI帮我反复挑问题。模块之间是不是绑得太紧，哪个服务以后可能成为瓶颈，异常状态下会不会出现数据不一致，一处修改会不会悄悄影响其他模块。 这种讨论很有价值。 以前做架构评审，往往需要几个人反复开会。现在很多初步推演可以先做一轮，把明显的问题提前暴露出来，再把真正需要团队讨论的部分留下来。 最后怎么选，还是要结合客户的使用方式和项目边界来判断。 技术方案脱离业务，很容易看起来很漂亮，用起来却很别扭。 软件能跑，离工程上能用还有一段距离 我长期做油藏数值模拟，所以对“算出来了”这件事一直比较谨慎。 数值模拟里，一个模型收敛了，只能说明求解过程结束了。离散、物性、边界条件、井控制任何一个地方有问题，都可能得到一套看起来很正常的结果。 做金融量化时也一样。回测曲线画得很好看，并不能说明策略就靠谱。数据泄漏、样本选择、交易成本处理不对，结果照样可以非常漂亮。 所以做工业软件时，我一直比较重视测试数据和验收条件。 拿一个地面管网计算功能来说，程序能够读入数据并给出结果，只说明程序跑通了。输入单位是否统一，边界条件是否合理，缺参数时怎么处理，现场数据里有异常值时怎么办，计算结果有没有已知算例可以核对，这些都要提前想。 如果没有这些条件，AI很容易迅速交付一个看起来已经完成的功能。 页面有了，按钮能点，结果也出来了。 真正的数据一进来，问题才开始出现。 所以这次项目里，我们尽量把测试往前放。开发之前先准备典型算例，先知道正常结果大概落在哪个范围，再考虑缺失数据、错误单位、异常值和极端工况怎么处理。 前期多花一点时间，后面反而省事。 任务交给工程师还是交给AI subagent都一样，先把验收条件讲清楚，开发过程就不会一直猜。 我现在很重视这一点。 AI编程能力越强，测试和验收标准越重要。代码写得快不快，已经不是最难解决的问题。难的是手里有没有一把尺子，知道结果什么时候可以接受，什么时候应该推倒重来。 任务定义清楚以后，AI的优势才真正体现出来 等业务流程、数据关系、系统架构和验收方法基本明确以后，我们才开始大量把任务交给AI subagent。 这个阶段，任务会拆得比较细。 输入数据从哪里来，采用什么计算逻辑，调用哪个服务，结果保存在哪里，异常情况如何处理，最后用什么数据验证。 任务到了这个粒度，AI的效率非常高。 前端、接口、数据处理、计算模块、测试代码和技术文档可以并行推进。我们把更多时间放在业务逻辑、工程结果和模块之间的衔接上。 这个变化对我冲击还是挺大的。 1995年刚开始写C++时，一个功能从想法到程序，很多事情都得从底层做起。后来有了成熟框架、开源库、云平台，开发效率已经提高了很多轮。AI出现以后，又把这段距离缩短了一大截。 现在，一个工程师脑子里的想法，可以很快变成一个能跑的原型，马上拿真实数据试。 对油气行业来说，这件事很有价值。 这个行业里有很多经验丰富的工程师，手上也有大量多年积累的方法。以前这些东西常常停留在Excel、脚本、计算表，或者个人的工作习惯里。想做成软件，需要产品、架构和开发团队一起配合，成本不低。 现在门槛低了很多。 最近我也看到国内外越来越多油气行业的同行开始自己做软件。有些方法他们可能已经用了十几年，只是过去没有合适的开发条件。 这当然是件好事。 同时也会带来另一个结果：界面会越来越像，标准功能会越来越容易实现，演示效果也会越来越接近。 真正拉开差距的地方，多半还是在项目里。 数据不完整怎么处理，不同来源的数据互相对不上怎么办，生产工况变化以后模型还能不能用，一个专业修改了结果以后其他专业能不能继续接着用，软件运行几年以后数据和计算结果还能不能追溯。 这些问题以前就存在。 只不过过去大量精力花在把软件先做出来，现在AI把前面的开发成本降下来以后，我们终于可以把更多时间放到这些老问题上。 这次N个月完成投标评估版本，对我来说最大的变化，就是工作重心开始移动。 我现在会把更多精力放在另外几件事上：客户实际怎么工作，数据之间是什么关系，系统以后怎么长大，计算结果用什么方法验证。 这些事情想清楚以后，AI写代码的速度才真正有意义。 写了三十多年软件，我现在对AI编程的看法其实很简单: 代码会越来越容易写，懂业务、懂系统、知道怎么算对，这些能力暂时还便宜不下来。