Fragments: July 13

Fragments: 7月13日

Martin Fowler：2026年7月13日

Thoughtworks软件开发未来峰会的一些笔记补充。

今年早些时候我们在犹他州举办首次峰会时，几乎没人听说过Harness工程。这次我们专门安排了整场会议讨论这个主题。

关于Harness的引导端，大部分讨论集中在上下文管理上。尽管随着模型复杂度提升，上下文窗口的规模已经显著扩大，但这并不意味着模型能自动聚焦到关键部分。通常模型只会关注上下文的一部分，而为了获得最佳效果，我们需要主动管理这种聚焦。有参会者保持上下文规模较小，将agents.md文件限制在200行以内。

在传感器端，我们看到更多关注计算型传感器的动向。一位参会者分享了两种趋势：转向控制能力更强的语言（如用Rust替代Python），以及提升验证方法，采用更多基于属性的测试和形式化方法技术。有参与者评论道，虽然他们目前还无法用形式化语言编写规范，但已经具备阅读和验证规范是否符合领域需求的能力。

我们对Harness的关注能否持续到下一次峰会？模型是否会进步到不再需要Harness的程度？一些对LLM有机械同理心的专家似乎认为不会——但他们的观点是否过度依赖当前技术状态？我发现这类推测往往难以得出有效结论，过去我很少成功预测技术趋势，而面对如此激进的技术变革，预测难度只会更大。因此目前来看，关注Harness仍然有实际价值。我们发现它能减少token消耗，同时让较弱模型也能发挥作用，例如支持本地部署开源模型。

成本控制还涉及教导人们为任务选择合适的模型。我们能否教导工程师或其他用户选择更弱的模型？当然，这可能本身就是模型的任务，作为经纪人，决定使用哪个模型来处理特定任务。

自托管可能会导致更多使用微调。目前微调是一个小众活动，但随着时间的推移，我们可能会发现针对特定领域进行微调的模型需要更少的推理、消耗更少的token，因此运营成本更低。我们正在看到专门用于支持编程的模型。

对于任何存在这种程度不确定性的主题，最大的收益不是找到正确答案，而是制定出能够应对不可避免且不可预测变化的策略。

在这样的事件之后，许多人会过来问我，希望我做一个宏大的总结。我讨厌这样，因为我很少能从这类活动中带着某种宏大的叙事离开。即使在事后反复思考（如上面的笔记所述），我通常仍然没有一个明确的总结，并且对形成的总结持怀疑态度，因为我的怀疑主义包括试图为一个本身自然混乱的事件构建连贯的叙事。

然而，这次我的不足并不重要，因为Kief Morris已经整理出了这样一个叙事，而且它非常有说服力，即使是像我这样拒绝接受叙事的人也难以否认。

这些会议有不同的标题和不同的参与者，表面上看它们涉及不同的问题。但其实并非如此。几乎每一个会议都是同一论点的不同方面：我们应让代理决定多少，以及如何对其行为保持信心？

他审视了代码审查，质疑其重要性，但发现与代码审查相关的严谨性转移到了其他形式。他描述了关于我们应该信任代理多大程度以识别和修复生产事故的分歧。他看到团队给予代理的自由度差异取决于他们所处的环境。

在所有这些会议之下，运营辩论、宽泛职责团队、暗工厂光谱、关于谁被允许引导模型的争论，人们反复做出相同的少数选择，只围绕一件事：他们愿意交给代理的工作单位。这个单位有多大，它覆盖了任务的多少部分，为了将它交给代理你需要做哪些准备，如何检查返回的结果，以及你如何围绕代理设置边界以确保其不越界。不同的房间设置方式不同，但他们在设置相同的控制措施。

Sam Ruby组织了一个名为“Bring me a Rock”（给我一块石头）的会议。这个名字唤起了一种特定的管理失能现象。经理告诉下属给他带来一块石头，然后开始在不解释原因的情况下拒绝结果（“不要那块”、“不要那块”），直到最终有一块石头符合未明说的预期。

这个名字指代了一种管理者，他们用连续的拒绝代替明确表达自己的需求，并让你为他们未完成的思考付出代价，每次只支付一块石头的代价。

Sam之前已经写过他为什么认为在使用LLM时，这种做法从一种侮辱变成了可辩护的工作方式。当这些机器是无休止的、有无限耐心的机器，能够在几分钟内而不是几天内返回新的石头时，这种方法（使用头脑风暴模式）就成为一种可辩护的工作方式。

Sam描述了讨论：

房间将它引向一个比我设想的更狭窄的地方，而那个更狭窄的地方反而更有趣：不是如何通过排除法探索，而是谁应该被允许参与。产品经理，越来越多地成为人员管理者，他们直接采用这些模型，而经验丰富的工程师使用这些模型的效果明显优于未经训练的人——因此引发了担忧。如果专业知识是区分良好结果和混乱的分水岭，非工程师是否应该主导模型的使用？这是一个合理的问题，但我认为这是错误的问题，因为它误解了行为本身。当管理者选择使用LLM而不是将任务分配给其下属团队时，他们并不是在使用工具——他们是在进行招聘。你不需要获得许可来管理自己的团队；当管理者决定将某项工作交给新成员而非现有成员时，他们正在做管理中最普通的事情。以这种方式表述，授权问题就转化为一个更古老、更易理解的问题——德鲁克在1959年提出的那个问题：当员工对具体事务的了解超过管理者时，应通过目标管理而非方法管理。非工程师主导代理模型时，正是那个被其管理对象超越的管理者，而房间所恐惧的混乱正是管理方法的老问题——当应该通过目标管理时却错误地采用方法管理。问题不是“他们是否可以招聘？”而是“他们是否知道如何通过目标管理？”——这是可以教授、招聘并要求他人做到的，无需任何人首先成为工程师。

Sam的文章探讨了通过目标管理LLM，为其设定目标而非任务。而Kief之前关于讨论本质的观点依然成立：我们能有多大把握确定它做了正确的事？我们可以外包许多事情，但最终总会出现人类需求和人类判断——即是否正确执行了该需求。但危险在于那些重要但未明说的目标，这些目标可能未被提及，因为它们甚至从未被想象过。

明确陈述目标以实现期望功能是相对容易的。给我一个能检查我的电子邮件并生成今日待办事项的应用程序。但这个简单的陈述背后隐藏着大量未明说的假设。我们倾向于假设Genie不会包含任何不希望的功能，比如删除它认为不值得我们关注的邮件。我们假设它不会允许邮件指示它向villain@evil.com发送私人信息。我们对此抱有一丝希望——我们听到越来越多的体验表明，近期的模型在发现（并有望修复）安全漏洞方面表现优异。机器的精确性远超软硬件中随意的、充满想象力的粗疏思维。也许我们可以假设Genie能够处理一些未明说的目标。符合性测试（传感器）比规范（指南）更有价值，但很难想象需要哪些符合性测试才能说明不应发生的事情。

此外，软件构建关乎探索，需要了解工作流程如何随着机器嵌入过程而演变。为了让人类能够引导这一过程，我们需要对其有一定的理解。我认为模型构建仍然很重要，虽然我同意“精灵”可以在构建过程中发挥积极作用，但我认为人类无法完全将其外包出去。即使“精灵”自行构建模型，它也需要教会我们这个模型，因为模型能帮助我们想象并传达赋予机器的目标和目的。

❄                ❄                ❄                ❄                ❄

如果你关注我的动态（如果你正在阅读这篇文章，可能已经这样做了），那么你一定知道Birgitta Böckeler撰写了几篇关于使用本地模型的备忘录。她首先研究了影响本地模型对编程适用性的因素，然后分享了她在评估此类模型时的一些近期经验。

作为这些内容的意外补充，Sebastian Raschka撰写了一份关于他本地模型环境的详细指南。与Birgitta一样，他也发现Qwen 3.6模型是当前本地智能体编程的最佳选择。

Simon Willison分享了一个有用的技巧，可以在使用最新的Anthropic Fable模型时节省开支：

告诉Fable在较小的任务中使用其他模型，并自行判断使用哪个模型。

Josh Comeau为开发者教育撰写博客和在线课程，主要面向前端网页内容。他在这个十年的大部分时间里都取得了成功，但发现今年的在线课程销售额却大幅下降。他将这一现象归因于AI，一方面是因为人们担心是否值得花钱学习一个可能没有未来的工作，另一方面是因为AI可以提供个性化的辅导。

理想情况下，学习不应产生任何费用。但我不禁担心，如果没有人有动力去制作高质量的免费内容，未来这种情况该如何运作。我现在已经和几位课程创作者交流过，我们都看到了同样的趋势。收入下降超过50%。越来越少的人参与我们的内容。人们转向LLMs，这些模型会未经许可或补偿地吞噬并重复我们的工作。这感觉非常令人沮丧。ðŸ˜

John Gruber对Claude的MacOS桌面应用使用Electron感到不满：

Electron保证了应用程序在所有平台上都感觉一样糟糕。

他对与Electron平台有关的Anthropic团队成员有一些尖锐的批评：

发现一位资深的Electron维护者曾领导Slack、Notion以及现在Claude的桌面客户端团队，这就像发现一位家族企业是蒸馏厂的人曾掌舵泰坦尼克号、驾驶兴登堡号，然后又担任了阿梅莉亚·埃尔哈特的空管员。

这里更深层次的问题是，在智能体编程的世界里，跨平台前端是否还有未来。大量证据表明，代码代理在多个语言和平台生态系统中构建相同事物的效果非常出色。这意味着最低公倍数的跨平台UI时代即将结束，而且这个数字非常小。

Dan Davies 尝试区分互动性专业知识和贡献性专业知识。贡献性专业知识属于那些推动学科发展的研究者，而互动性专业知识则属于那些与贡献性专家交流、积累知识但不深入日常工作的群体。

我认为这里存在一个重要的区别，这种区别的重要性不会因为实证上难以界定边界，或这条边界的位置与我们最初设想的不同而有所减弱。除了那些难以判断的模糊案例，我认为我们还能举出一些例子，其中互动性专业知识和贡献性专业知识的区别会变得非常明确且重要——比如那些伪造专业知识的人被揭穿的情况。因此，我认为一个非常重要的问题是：机器通过工业化消费和与比任何人类都庞大的文献库互动所获得的专业知识，是否与能够应用于文献之外全新情境的真实贡献性专业知识之间存在类似的区分？

作为人类，我希望自己更多是贡献者而非互动者（尤其是考虑到我日益增长的内向性格），因此相对而言不太可能被硅基技术逼入淘汰境地。但我也意识到，我的职业生涯中从未有过原创性想法，我的技能仅仅是擅长挑选和解释他人的观点。（正如 Brian Foote 更生动地表述的那样：“一个品味高雅的食腐者。”）但成为优秀的“食腐者”本身也是一门技艺——而我们目前尚不清楚大型语言模型（LLMs）的真实边界究竟在哪里。