IT博客汇
  • 首页
  • 精华
  • 技术
  • 设计
  • 资讯
  • 扯淡
  • 权利声明
  • 登录 注册

    Martin Fowler最新洞察:LLM 不止是“更高”的抽象,它正在改变编程的“本质”!

    bigwhite发表于 2025-06-25 23:02:07
    love 0

    本文永久链接 – https://tonybai.com/2025/06/26/non-deterministic-abstraction

    大家好,我是Tony Bai。

    在软件开发领域,Martin Fowler 的名字几乎等同于思想的灯塔。他的每一篇文章、每一次演讲,都能为我们揭示行业发展的深层脉络。最近,Fowler 大师又发布了一篇简短但引人深思的博文——《LLMs bring new nature of abstraction》,再次精准地捕捉到了一个正在发生的、可能颠覆我们认知和工作方式的巨大变革。

    Fowler 认为,大型语言模型(LLM)的出现,对软件开发的影响,堪比从汇编语言到首批高级编程语言(HLLs)的飞跃。但关键在于,LLM 带来的不仅仅是又一个“更高层次”的抽象,它正在从根本上改变编程的“本质”——迫使我们思考,用“非确定性工具”进行编程究竟意味着什么。

    在这篇文章中,我们就来简单解读一下。

    从“确定性”的阶梯到“非确定性”的岔路

    回顾编程语言的发展史,我们一直在追求更高层次的抽象,以提升生产力、降低复杂度:

    • 汇编语言 vs. 机器指令: 汇编让我们用助记符替代了 0 和 1,但仍需关注特定机器的寄存器和指令集。
    • 高级语言 (HLLs) vs. 汇编: Fortran、COBOL 等早期 HLLs 让我们能用语句、条件、循环来思考,而不用关心数据如何在寄存器间移动。Fowler 回忆道,他用 Fortran IV 编程时,虽然有诸多限制(如 IF 没有 ELSE,整数变量名必须以 I-N 开头),但这已经是巨大的进步。
    • 现代语言、框架、DSL vs. 早期 HLLs: Ruby、Go、Python 等现代语言,以及各种框架和领域特定语言(DSL),进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递,使用丰富的库和模式,而不用从头编写大量底层代码。

    Fowler 指出,尽管这些发展极大地提升了抽象层次和生产力,但它们并没有从根本上改变“编程的性质”。我们仍然是在与机器进行一种“确定性”的对话:给定相同的输入和代码,我们期望得到相同的输出。错误(Bug)也是可复现的。

    然而,LLM 的介入,打破了这一基本假设。

    Fowler 写道:“用提示词与机器对话,其差异之大,犹如 Ruby 之于 Fortran,Fortran 之于汇编”。

    更重要的是,这不仅仅是抽象层次的巨大飞跃。当 Fowler 用 Fortran 写一个函数,他可以编译一百次,结果中的 Bug 依然是那个 Bug。但 LLM 引入的是一种“非确定性”的抽象 (non-deterministic abstraction)。

    这意味着,即使我们把精心设计的 Prompt 存储在 Git 中,也不能保证每次运行都会得到完全相同的行为。正如他的同事 Birgitta Böckeler 精辟总结的那样:

    我们并非仅仅在抽象层级上“向上”移动,我们同时也在“横向”移入非确定性的领域。

    Fowler 文章中的配图非常形象地展示了这一点:传统的编程语言、编译器、字节码是一条清晰的、自上而下的抽象路径;而模型/DSL、代码生成器、低代码、框架是其上的不同抽象层次。自然语言(通过 LLM)则像一条从旁边切入的、直接通往“半结构化/接近人类思维”的道路,这条路本身就带有模糊和不确定性。

    “非确定性”编程时代的挑战与启示

    这种“非确定性”的本质,对我们 Gopher,乃至所有软件开发者,都带来了前所未有的挑战和需要重新思考的问题:

    1. 版本控制与可复现性: 当 Prompt 不能保证结果一致时,我们如何管理和版本化我们的“AI辅助代码”?如何确保开发、测试、生产环境的一致性,或者至少是可接受的差异性?仅仅版本化 Prompt 可能不够,我们还需要版本化模型、参数(如 temperature)甚至是一些关键的种子(seed)吗?
    2. 测试与调试: 如何测试一个输出不完全固定的“组件”?传统的单元测试、集成测试方法是否依然有效?我们可能需要引入新的测试策略,例如基于属性的测试、对输出结果的统计验证、或者更侧重于行为和意图的验证。当 LLM 生成的代码出现问题,调试的难度是否会指数级增加?
    3. 可靠性与契约: 在一个包含非确定性AI组件的系统中,如何定义和保证整体的可靠性?服务间的“契约”又该如何描述和强制执行?
    4. 思维模式的转变: 我们习惯了对代码的精确控制,追求逻辑的严密和行为的可预测。现在,我们可能需要学会与“模糊”和“概率”共存,从“指令下达者”转变为“意图沟通者”和“结果筛选者”。

    这对我们 Gopher 意味着什么?

    Go 语言以其明确性、强类型、简洁的并发模型以及相对可预测的行为,深受开发者喜爱。当我们尝试将 LLM 融入 Go 的生态和开发流程时,这些“非确定性”的特性会带来新的思考:

    • AI 生成 Go 代码: 当我们使用 LLM 生成 Go 代码片段、单元测试,甚至整个模块时,如何确保生成的代码符合 Go 的最佳实践、是高效且安全的?如何对生成的代码进行有效的审查和集成?
    • 用 Go 构建与 LLM 交互的工具/Agent: 如果我们用 Go 开发与 LLM 交互的后端服务或智能体(Agent),我们需要在架构设计上充分考虑 LLM 的非确定性,设计更鲁棒的错误处理、重试机制,以及对 LLM 输出结果的验证和筛选逻辑。
    • 利用 LLM 理解复杂 Go 系统: LLM 或许能帮助我们理解遗留的复杂 Go 代码库,但其解释的准确性和一致性也需要我们审慎评估。

    Fowler 在文末表达了他对这一变革的兴奋之情:“这种改变是戏剧性的,也让我颇为兴奋。我相信我会为一些失去的东西感到悲伤,但我们也将获得一些我们中很少有人能理解的东西。”

    小结:拥抱不确定,探索新大陆

    Martin Fowler 的这篇文章,为我们揭示了 LLM 时代编程范式可能发生的深刻转变。它不再仅仅是工具的进化,更是与机器协作方式的本质性变革。

    作为 Gopher,作为软件工程师,我们需要开始认真思考这种“非确定性”带来的影响,积极探索与之共存、甚至利用其特性创造价值的新方法。这无疑是一个充满挑战但也充满机遇的新大陆。

    你如何看待 Fowler 的这个观点?你认为 LLM 带来的“非确定性”会对你的日常开发工作产生哪些具体影响?欢迎在评论区分享你的看法!


    你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

    • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
    • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
    • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

    继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

    我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

    目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


    商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

    © 2025, bigwhite. 版权所有.



沪ICP备19023445号-2号
友情链接