软件工程和AI编程的一点瞎想

大约10年前，笔者是一个愣头青Linux驱动工程师，开始接触CI/CD的一些工具和知识，也有前辈引导我去看系统工程、V模型的一些理论。

随着实践和思考，我觉得软件工程在实践中，无论从过程还是结果看，都能够达成很高的确定性。

主要的两点：

• 从软件工程的过程看，通过对大量高并发执行的回归测试集的持续建设和频繁执行，我们能将工程的行进一直约束在预设轨道上。
• 从软件工程的结果看，借助模块化思想和设计模式的积累，我们也能从设计方法论（面向过程、面向对象、面向服务）和C/C++这些语言的特性上大致推断出其能支撑的工程体量上限，然后这个限度以内保持良好的解耦状态。

工程师团队依靠特定设计语言界面所能 理解、想象、编辑 出的工程体量上限，是存在的。从纸带穿孔，到汇编语言，到高级语言，到面向对象，再到面向服务的分布式系统，每一次拉升的其实是人类在实践设计活动时所面对的那个 设计界面，自然也就拉升了目标工程的 体量上限。当然，这种界面的拉升，也是以安全的隐藏一些下层界面的细节为前提。

AI带来了自然语言设计界面

这两年下来，随着AI辅助编程工具的进化和广泛使用，随着Prompt Engineering、Context Engineering、Harness Engineering概念的一次次进化（几乎是每年定义一个新时代），软件工程的确定性，不论从过程还是结果看，都没那么清晰了。

• 过程上来看，工程的设计过程细节，已经不完全在我们手里了。Harness Engineering目前的思路，也是使用多层约束来规避风险而已。对人而言，工程过程变成了 “让AI构建和试错 - 加约束” 这样的循环，这跟原来的CI/CD工程循环完全是两码事。当然，工程师描述给AI的工程轮廓里，也包含着CI/CD的思路；这就像前人当初设计编译器时，自然也融入了自己当年多年以来手搓汇编的丰富经验。
• 从这种方法论能支撑的上限来看，现在我们面对的最高设计界面语言，变成了人类自然语言。理论上看，只要能做好这层界面（自然语言）向下层语言（计算机高级语言）的衔接，未来的工程体量上限是未定的。

能够确定的一点似乎是：

• 基于人类自然语言和高级语言的混合设计模式，是一个明显的趋势。但对于不同的工程师个体而言，这两种设计语言在过程中的使用比例，差异也是显著的。这么显著的差异存在，我们又如何像以往一样来定义一种工程模式？如何定义最佳实践？

大家甚至争论，AI辅助工程的增长点究竟主要来自大模型的进化？还是Agent外部结构的升级？当然这一点不难回答——它俩就像过去的硬件和操作系统，好马更要配好鞍，才能跑得快又不脱轨，不然怎么叫Harness Engineering呢。

AI智能体的目标就在于找到上述两者的平衡：

在AI大模型的 发散性创造性 和工程的 收敛性确定性 之间寻求平衡。

无论是从工具、设计界面、方法论等角度来看，这一轮工程实践方法的进化，都还远没有到终点，未来是很模糊的。2030年能尘埃落定吗？

设计语言界面的拉升带来确定性的降低

从工具使用角度看，这可能是确定性的又一次降级，当然也是我们所面对的设计界面的又一次拉升：

• 从数学到物理，大家接受了误差的概念
• 从科学到工程，接受了用系统工程和控制论来塑造确定结果
• 从软件工程的CI/CD方法到AI辅助编程的定义目标而适当放开过程——这个适当究竟是怎么个程度？

等方法论在行业里的讨论声音冷却了，等工具也归于那最终的两三家了，等我们对于工程确定性的定义再一次收敛了，估计我都失业了。一个30多岁的老登其实不该操心这些个东西。

给自己的角色界定

至少目前，我给自己角色的定义，对AI工具的使用，还是比较保守的。

且不论提示词写的好坏，从AI行动后置的角度，我给自己设定了这几个角色：

• 监督者——评判输出
• 教练员——引导方向
• 最后贷款人——行动介入

在使用AI工具的同时，也隐含着会问自己：

• 外延or天花板
  。对于特定领域的设计或工程，我是否知道它的上限在哪里？
• 结果判别
  。如果用AI来做，我至少应能从功能验证的角度，判别其作品的水准好坏。
• 功能建议
  。我能从功能角度给与AI多少建议？
• 设计和架构建议
  。从源码设计、软件架构角度，我又给与AI多少有效建议？
• 兜底
  。我能在多大程度上给AI输出的工程兜底？就像带新手工程师那样。

一问

大家觉得，未来几年里，在基于自然语言界面设计而产生的创造和发散性，和软件工程所追求的收敛和确定性之间，能够系统普遍的找到那个平衡点吗？