Fragments: September 24

碎片：9月24日

Martin Fowler

2026年9月24日

Rob Bowley 对当前媒体关于AI可能灭绝人类的报道感到愤怒，他形容自己"在脑海中翻桌"

我担心的风险不是未来机器决定消灭人类。而是当今AI被仓促而随意地接入所有系统。

网络攻击已造成数百万美元的经济损失，即使完全不涉及AI。Bowley认为减缓AI发展的呼声让我们忽视了现有技术潜藏的问题。如今代理系统经常被部署在包含"致命三联体"的场景中，造成巨大的安全漏洞。

我们真正需要放慢的是将AI接入所有系统的进程。不是因为模型可能演变成什么，而是因为我们尚未掌握安全实现的方法。我们正在构建一个无法控制的技术，却在解决过程中就将其推向所有人。

 ❄                ❄                ❄                ❄                ❄

我读到了Nikita Prokopov的帖子：《我很抱歉，但每个人都在错误地使用语法高亮》。他主要抱怨的是使用不同颜色突出显示每个代码元素的配色方案。

如果所有元素都高亮显示，反而什么都突不出。你的眼睛会适应这种新规范：一切都明亮闪亮，反而会融合在一起。

他建议使用绝对最少的颜色，他本人只用四种：字符串、常量、注释和顶级定义。这与我的做法很接近，我也小心地使用柔和颜色显示不应突出的元素，用明亮颜色突出关键元素（主要是定义时的函数名）。

配色方案通常会降低注释的亮度以便跳过。他同意当注释过多时这种做法很好，但当注释使用得当时却很重要，需要明亮的高亮。我也喜欢他建议在浅色模式下使用背景色。我使用浅色模式，这个建议值得尝试。

随着代理编程的兴起，越来越多的人需要阅读代码。谨慎使用颜色可以显著改善阅读体验。

像许多头发逐渐变灰的人一样，我对"前部署工程师"的讨论感到厌烦，因为其中很多内容都在重复我们几十年来一直在倡导的事情。不过我发现Vinoo Ganesh最近的帖子很有趣，他深谙这一趋势，曾在Palantir工作过一段时间，可能是FDE概念的最初提出者。

如果你了解我，就不会对这个观察感到惊讶：

/think

几个月前，a16z推出了“前向部署工程师”（Forward Deployed Engineer）奖学金计划，我有幸被选为其中的成员之一，与一些我曾经共事过的人一起。这是一个非常棒的项目，我享受了其中很多次深入的交流。上周我参加了在旧金山举办的首次成员晚宴。在座的有来自Snowflake、Anthropic以及一些我之前读过报道的初创公司的“前向部署工程师”，在晚宴过程中，我们逐渐意识到，我们都在用“前向部署”（forward deployed）这个词来描述几乎毫无关联的职位。在对话的某一部分，“前向部署工程师”是负责销售的工程师，他们参与“第二次客户沟通”；在另一部分，他们则是需要编写Python代码的有业绩指标的销售代表；而在不远处，他们更像是带着笔记本电脑和工作说明书的顾问，被雇佣来完成产品本身无法实现的任务。

Ganesh接着解释了他对于“前向部署工程师”职责的看法，这些观点本身是合理的（尽管用词风格更偏向大语言模型的表达方式，这让我略感不适）。他认为“前向部署工程师”的职责是理解业务，收集“名词和动词”，这与领域驱动设计（Domain-Driven Design）倡导者在Eric出版《领域驱动设计》（蓝皮书）之前就已经在做的事情不谋而合。

尽管我对这些观点有些不屑一顾，但“前向部署工程师”这一概念确实推动着一些有价值的方向。是的，我很容易指出，这不过是敏捷宣言中“业务人员和开发人员必须在整个项目过程中每天协同工作”的原则，或者是我同事在过去一个世纪里一直倡导的“将用户和开发人员集中在一起”的愿望。几十年来，我一直主张软件开发领域最大的问题在于开发人员与最终受益于软件的人员之间的沟通，因此我们需要专注于弥合这个令人绝望的鸿沟。但尽管如此，我们并没有取得太大进展，因此我认为新一代的评论者尝试用新的框架、名称和口号再次推动这一方向是重要的。

Ganesh的视角并非来自定制软件开发者的角度，而是来自产品团队——更严格地说，是平台团队的视角。“前向部署工程师”是与用户一起工作的开发者，他们实施定制化方案——但更重要的是，他们会将这些变更反馈到核心平台，以决定是否需要为所有用户改进平台。

让客户满意是一项真实且重要的工作，这属于解决方案架构师的职责，他们也理应以此作为衡量标准。而“前向部署工程师”的职责是将现场学到的经验转化为未来每一位客户都能获得的成果。如果一次“前向部署工程师”的合作只让一个客户满意，但没有对上游系统做出任何改变，那么这次合作就完全失败了。你获得了上下文，却只在局部使用了它。

最新片段：

9月24日

上一篇：

9月16日

所有片段 /think