碎片：5月14日

Martin Fowler

Martin Fowler2026年5月14日

碎片：5月14日

8.5Score

TL;DR · AI 摘要

Martin Fowler 分享了关于 AI 在软件开发中的应用、代码迁移和规范验证的见解。

核心要点

LLM 可以在 3 天内将 GNU Cobol 编译器移植到 Rust，共 70K 行代码。
通过 Interrogatory LLM 验证大型规范文档的正确性是一种新方法。
Lift and Shift 现在应作为遗留系统迁移的第一步，因为成本大幅降低。

结构提纲

按章节快速跳转。

§引言
作者参加了一个讨论 AI 对软件开发影响的闭门会议，并分享了几点观察。
·LLM 在代码移植中的应用
一个团队用 LLM 将 GNU Cobol 编译器移植到 Rust，仅用 3 天完成。
·Interrogatory LLM 验证规范
利用 LLM 向人类专家提问，验证大型规范文档的准确性。
·Lift and Shift 的新视角
由于 LLM 降低了迁移成本，Lift and Shift 应成为遗留系统迁移的第一步。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

Fragments: May 14
- LLM 在代码移植中的应用
  - GNU Cobol 到 Rust 移植
  - 70K 行代码，3 天完成
- Interrogatory LLM
  - 验证大型规范文档
  - 通过提问人类专家
- Lift and Shift 新策略
  - 迁移成本降低
  - 应作为遗留系统迁移第一步

金句 / Highlights

值得收藏与分享的关键句。

一个团队用 LLM 在 3 天内将 GNU Cobol 编译器移植到 Rust，生成 70K 行代码。
— 第 2 段
⬇︎ 下载 PNG 𝕏 分享到 X
LLM 可以通过向人类专家提问来验证大型规范文档的正确性。
— 第 3 段
⬇︎ 下载 PNG 𝕏 分享到 X
Lift and Shift 成本大幅下降，现在应作为遗留系统迁移的第一步。
— 第 4 段
⬇︎ 下载 PNG 𝕏 分享到 X

#AI#软件架构#代码迁移#规范验证

打开原文

标题：碎片集：5月14日

来源网址：https://martinfowler.com/fragments/2026-05-14.html

发布时间：2026年5月14日，星期四 21:53:01（GMT）

碎片集：5月14日

[](https://martinfowler.com/fragments/2026-05-14.html#navmenu-bottom)

重构
敏捷
架构
关于我
Thoughtworks
[](https://martinfowler.com/feed.atom "RSS订阅")
[](https://www.twitter.com/martinfowler "Twitter动态")
[](https://toot.thoughtworks.com/@mfowler "Mastodon动态")
[](https://www.linkedin.com/in/martin-fowler-com/ "LinkedIn")
[](https://bsky.app/profile/martinfowler.com "Bluesky")

碎片集：5月14日

马丁·福勒｜2026年5月14日

上周，我参加了一场为期一天的闭门研讨会，与多位从事软件开发工作的同行共同探讨“智能体编程”（agentic programming）兴起背景下软件工程职业的未来。本次活动遵循查塔姆研究所规则，因此我无法透露所听到的观点和故事的具体出处。（若您认出其中某条内容并希望获得署名，请随时告知我。）以下是我笔记中摘录的几则要点。

❄❄

一个小组用 Rust 实现了 GNU Cobol 编译器的行为克隆版。最终成果为 7 万行 Rust 代码，仅耗时 3 天完成。这再次印证了大语言模型（LLM）在将既有代码迁移到新平台方面所展现出的强大能力。在此过程中，高质量的回归测试至关重要（不过我并不清楚 GNU Cobol 自身的测试覆盖情况如何）。此外，若已有可运行的原始实现，还可基于它构建一套自动化测试套件。

❄❄

大型规格文档往往结构复杂、难以由人工全面审阅。一位与会者提出一种思路：让大语言模型扮演“访谈者”，向人类专家提问，以验证规格说明的正确性——这是一种被称为质询式大语言模型（Interrogatory LLM）的应用模式。

❄❄

虽不直接涉及人工智能，但我很欣赏一位与会者分享的经验：他为客户组织提供咨询时，第一步总是研读其变更控制委员会（Change-Control Board）制定的指导方针。这些方针正是过往失败经验所留下的“疤痕组织”。我常强调：要理解某项事物为何呈现当前形态，就必须了解它一路演进的历史。而查阅这类制度性文档，无疑是挖掘关键历史线索的绝佳途径。

❄❄

长期从事遗留系统现代化工作的同事们，一向对“迁移即替换”（Lift and Shift）策略持保留甚至轻蔑态度——即在不改变功能的前提下，将遗留系统整体迁移至新平台，以维持功能一致性（Feature Parity）。

我们认为这种做法错失了重大机遇。旧系统往往随时间推移日益臃肿：大量功能早已被用户弃用（据 2014 年 Standish Group 报告，比例高达 50%），业务流程也已发生演变。盲目复刻这些陈旧功能纯属浪费。相反，我们应鼓起勇气退后一步，深入理解用户当前的真实需求，并据此结合业务目标与关键指标进行优先级排序。

然而，这一观点形成于大语言模型尚不具备高效代码迁移能力的时代。一位深耕该领域的与会者指出，如今“迁移即替换”理应成为所有遗留系统迁移项目的首要步骤。迁移成本已大幅降低，且新平台环境更利于后续持续演进——只是切勿止步于此。

❄❄

多位与会者来自金融行业，因而深陷于一类典型困境：一方面需应对高度复杂的遗留系统，另一方面又受制于严格的监管要求；一旦软件在资金处理上出现差错，后果将极为严重。其中一个突出难题是：当同一款金融产品面向多个司法管辖区推出时，每个辖区均有各自需满足的监管规则。系统需在运行时准确判断适用哪个辖区的法规，并在工作流的恰当节点选取对应的一组规则——由此催生了大量软件复杂性。

由此引发的问题是：智能体编程的快速迭代能力，是否意味着我们可以为每个司法管辖区分别构建独立、更简化的专用系统？再借助大语言模型确保各系统间的一致性——即当产品规则发生变化时，各系统能自动同步更新，适配自身所在辖区的监管环境。

软件设计的很大一部分，就在于识别不同业务场景中哪些是共通的、哪些是差异化的。当某些事物本应保持一致时，我们自然会警惕代码重复——因为这会提高后续更新的成本，并增加不一致的风险。真正值得思考的问题是：大语言模型（LLMs）能否为我们提供全新的工具，来更有效地应对这一挑战？

❄❄

正如这类聚会中常见的那样，与会者普遍关注初级开发者的成长问题。当我们使用“精灵”（The Genie）这类 AI 工具时，我们的核心价值恰恰在于良好的判断力——那么，我们又该如何培养这种判断力呢？本次讨论中，大家共同认可的一个实践方法是结对编程（Pair Programming）。结对编程的关键优势之一，始终是技能传承：经验丰富的“具身化程序员”（agentic programmer）可以将自己在软件设计上的判断力，以及如何借助“精灵”达成目标的经验，直接传递给搭档；而初级开发者也常常能贡献一两个独到技巧——尤其在迈向具身化未来的转型过程中，这样一双新鲜的眼睛尤为珍贵。

❄❄

历史上，我们一直利用计算机系统为混乱的人类流程建立秩序。如今，AI 是否正在逆转这一趋势？

❄❄

大量软件本质上都在处理数据转换：那边的数据记录需要被这边的 API 消费，但二者的数据结构往往存在差异——这通常源于它们处于不同的限界上下文（Bounded Contexts），因此我们必须编写转换逻辑。而智能体（Agents）恰好特别擅长编写这类转换代码，尽管这类工作常常比我们期望的更加枯燥乏味。

❄❄

混沌工程（Chaos Engineering）已成为提升系统韧性的宝贵实践，其知名度很大程度上归功于 Netflix 的“混沌猴”（Chaos Monkey）——它会随机中断线上服务，以检验整个生态系统的响应与恢复能力。那么，面向 AI 的“混沌猴”会是什么样子？它是否会刻意在流水线中注入幻觉（hallucinations），以测试各类检测机制是否能及时发现并拦截？

❄❄❄❄❄

回到我的工位

关于结构化提示驱动开发（SPDD）一文，作者们在文末的问答环节（Q&A）中回应了不少读者提问。其中一个问题尤其引起我的注意：

你们是否考虑过让智能体自身来完成提示/规格审查工作？——不是由人审阅“画布”（Canvas），而是由一个智能体同时读取 REASONS 画布与代码变更（code diff），自动验证二者是否对齐？

作者的答复指出：目前确实存在可执行该任务的命令，但同时也存在明显弊端。其中一个关键原因正是：

要让人持续学习。审查过程本身，也是人类从 AI 的决策中学习的过程——学习其采用的设计模式、权衡取舍，以及那些我们此前未曾想到的备选方案。若完全绕过人工审查，虽可加快交付速度，却会阻碍长期能力的成长；而这恰恰是 SPDD 所致力于保护的核心价值。……随着决策规则库不断积累、逐步建立起足够强的信心之后，我们或许会逐步将更多审查职责移交智能体；但“人类向 AI 学习”这一环节，我们计划长期保留。

评判一款 AI 工具价值的重要维度之一，正是它能在多大程度上帮助我们人类更深入地理解我们所栖居、所构建的世界。

❄❄❄❄❄

上周，我的肘部以某种奇怪的方式受了伤。完全不知缘由——没有发生任何让我脱口而出“糟了！”的明确事件，只是逐渐开始疼痛并出现肿胀。我奉行了一辈子的“规避运动损伤策略”1这次彻底失灵了。我敷了冰袋、服用了布洛芬，肿胀有所消退，但活动范围反而进一步受限。好在我童年在英国学会了用刀叉吃饭，所以平时就习惯用左手进餐。

我注意到，活动受限的情况是在我回家后才开始加剧的——那时我又恢复了整天伏案工作的状态。虽然我并未直接动用肘部发力，但右手却持续进行大量打字和鼠标操作。我的办公桌配置其实相当符合人体工学：配备了一把优质键盘，鼠标配有腕托，椅子也带扶手。即便如此，回到家后的电脑使用，是否真的加重了我的肘部问题？对我来说，放弃电脑几乎不可想象——写作早已成为一种无法抑制的习惯。不过，也许这次受伤正是一次契机，让我认真尝试语音输入——毕竟，绝大多数人的语速远高于打字速度。

多年前我就试过语音输入。当时一位同事告诉我，语音识别技术一旦完成个性化训练，效果会非常出色。我照做了，结果发现，即便在那个尚无现代 AI 技术加持的年代，语音识别准确率也的确很高。但它并不适合我。我在 Emacs 中写作时，习惯快速敲出文字，然后几乎立刻回溯修改：写两句话、调整润色；再写一句、重审整段。这种“眼见文字—脑中思辨”的闭环极其紧密，我无法单纯靠口述完成创作。

这让我进一步反思：我直到二十几岁才开始用电脑写作。学生时代必须手写长文，大学时期则用打字机。而这些传统媒介，根本无法支撑我如今这般高频、即时的反复改写。倘若没有文本编辑器的发明，我是否还能成为一名作家？

❄❄❄❄❄

詹姆斯·普里查德（James Pritchard）认为，许多开发者在产品运行时过度依赖智能体（agents），而实际上，大语言模型更适合作为函数（LLMs are functions）来使用。

智能体的问题，不在于它“不能工作”，而在于它“工作得不可预测”。你用一条已知、可控的执行路径，换来了所谓“自主性”——而这种“自主性”，大多只意味着“我不知道它接下来会干什么”。当一个由智能体驱动的功能在线上环境崩溃时，你调试的对象不再是清晰的调用栈（stack trace），而是一份对话日志（conversation transcript）。
大多数标榜为“智能体”的应用场景，本质上其实是工作流（workflows）：即一系列步骤明确、顺序固定的流程，其中仅有一两个步骤恰好需要调用 LLM。对于这类场景，你根本不需要“自主性”，你只需要一次函数调用。

他指出，函数的组合具有可预测性，因此如果你已明确工作流程，那么在程序代码中显式组合函数，远胜于让智能体自行摸索协调方式。这种方式更快，且消耗更少的 token。当交互范围更小时，处理失败通常也更容易。

❄❄❄❄❄

普里查德还认为，人们使用“技能”（skills）的频率远超其实际需要。他认为，人们往往积累大量 Markdown 格式的技能文件夹，但大语言模型（LLM）对这些技能的调用却极不一致：要么在真正需要时遗漏它们，要么在不需要时过度填充上下文。许多本该放入技能中的内容，其实应置于 harness（运行环境/支撑框架）的其他部分——尤其是计算型组件中。技能仅应在经过审慎设计、且执行频次较低的特定工作流中使用。

对“技能”的痴迷，实则是更深层模式的症状：人们本该思考架构设计，却一味诉诸配置。
“LLM 写不出好的测试。”——那就别写一个“测试技能”。你的现有测试是否不一致？测试环境搭建是否过于复杂？解决这些问题后，LLM 自然能写出高质量的测试，无需你手把手教。把它指向一份你引以为豪的测试文件即可。代码比英文更清晰。
[…]
最佳的设置，是几乎完全无需对 LLM 进行配置：一个结构清晰、模式明确的代码库；一份简短的项目配置文件（仅覆盖非显而易见的部分）；若干自动化钩子（hooks）；以及最多一两个专为刻意启用的特定工作流而设的技能。仅此而已。

❄❄❄❄❄

关于“智能体编程”（agentic programming）兴起的一个常见论点是：我们必须开始直面工作中日益增长的不确定性（non-determinism）。当然，这多少是一种简化——因为软件开发的某些领域早已长期与不确定性共存。分布式系统便是一个典型例子；而凯尔·金斯伯里（Kyle Kingsbury，网名 Aphyr）正是引领我们深入探索分布式系统那令人极度不安水域的关键人物。

上月，他发布了一篇长文（PDF 共 32 页），阐述他对 LLM 赋能未来的看法。标题《万物之未来，大概皆为谎言》已毫不掩饰他对这一前景的冷淡态度。

毫无疑问，有些读者会因本文未更多着墨于机器学习的奇迹而感到不满——比如 LLM 在代码生成上的惊人能力，又比如 Suno 如何将随口哼唱的旋律转化为精良歌曲。但本文并非探讨开车有多快或多方便；我们都知道汽车很快。我想追问的是：城市格局将因此发生怎样的改变？

尽管全文读来并不轻松，却绝对值得一读。金斯伯里以一位对 AI 能力了然于胸的专家视角，提出了诸多关于 AI 快速扩张的深切忧虑。

他的核心主张是：面对这一切，我们最好的回应就是——停下脚步。他拒绝在写作、软件开发乃至个人生活中使用 AI；他呼吁就职于 AI 公司的人们辞职离开。然而与此同时，他也清楚这些工具确有实用价值，并希望加以利用。

对我而言，面对 AI 的未来，我既是乐观者，也是悲观者。从根本上说，我认为任何强大技术都如同一辆巨型巴士：我们不是登上它，就是被它碾过。我选择登车，是因为我相信，仅靠筑起几道屏障，根本无法避免被它的车轮压垮。或许登车之后，我能与一些人同行，稍稍影响一下司机的方向。此外，我也极不愿意对未来结果妄加推测——尤其当对象是如此强大的技术时。十八世纪末期的早期工业家们，可曾预见到自己掀起的工业革命将带来何种后果？它固然造成了诸多伤害，却也让数以百万计民众的生活水平大幅提升——至少那些“上了这辆巴士”的国家的民众如此。AI 或许也将带来我尚无法想象的巨大福祉；虽然我难以预见全貌，但当我看到它帮助一位朋友延缓帕金森病进展时，已隐约窥见一丝曙光。

这些希望确实存在；但金斯伯里的文章，却如一道强光，照亮了当下现实更为阴暗的一面，并向责任归属提出了严肃诘问：

我作为 Mastodon 实例的一名管理员，日常工作之一是响应用户举报；其中偶尔涉及儿童性虐待材料（CSAM），而我依法必须审查并提交至美国国家失踪与受虐儿童中心（NCMEC）。我绝不想看到这些图像，更希望自己从未见过。在那些阴郁的清晨，当我坐到电脑前，发现待审举报竟是由 AI 生成的性侵图像时，我有时真希望 OpenAI 等公司的工程师们也亲眼看看这些内容。或许这能促使他们反思：自己正将何种技术推向世界？而所谓“对齐”（alignment），在现实中究竟成效如何？