三年间，LLM 改变了什么

当我开始认真尝试把 LLM 用到软件开发中时，我最关心的问题其实很简单：

这个工具真的能在实际开发中帮到我吗？

2023 年时，我的答案大概介于“有时候非常惊艳”和“还是挺费劲”之间。模型已经能够给出很有说服力的解释、生成代码，并且在第一眼看上去给出相当专业的技术回答。但与此同时，它们也制造了大量 Noise：会虚构 API、错误假设 Framework 的能力，也会把最新发展和已经过时的知识混在一起。尤其是在变化很快的技术领域，你必须对这个领域足够熟悉，才能判断一个答案究竟是真的合理，还是只是听起来合理。

对于规模小、边界清晰的任务，这已经很有用了。解释一个函数、重构一个方法，或者生成一个不复杂的示例，往往能做得出乎意料地好。但如果任务变成：分析一个陌生而长期演化的应用、找到真正相关的位置、理解既有架构、跨多个 Layer 完成改动、执行测试并自行处理错误，那就是完全不同的级别。

到了 2026 年，我使用这些工具的方式已经明显不同了。不是因为它们突然变得不会犯错，而是因为我现在能够合理交给它们的任务类型发生了变化。

对我来说，这段变化大致是这样的：

这不是一条人工智能的普遍进化曲线，而只是我自己的使用方式发生变化的轨迹。这个系列正是从这些经历中产生的。

两种几乎完全不同的现实

我的 LLM 使用经验来自两个差异非常大的场景。在工作中，我面对的是大型软件系统，其中一些系统处于高度敏感的数据环境中。在这种场景里，“Agent 技术上能做什么？”远远不够。至少同样重要的问题还有：系统允许看到哪些信息、可以访问哪些工具、哪些决策可以自己做、之后如何追踪和 Review 变更，以及最终由谁对结果负责。

因此，一个 Agent 即使技术上能够分析整个应用，也不代表它就应该被允许分析整个应用。信息边界、数据保护、Governance、Security 和可追溯性，与模型本身一样，都是专业 Agentic Work 的组成部分。

而在私人项目中，我拥有更大的实验自由度。过去几年里，我在接近 40 个不同规模和复杂度的项目中使用过 LLM 和 Coding Agent，其中包括小型实验、Frontend、Backend、Infrastructure，以及 AI 本身就是产品功能一部分的应用。

这些项目让我可以更激进地实验：给 Agent 完整 Repository 的访问权限、修改 Agent Files 和 Skills、使用 Memories、不断调整 Specs、切换模型，或者观察 Context 变大或变小时结果会如何变化。这当然不是一组科学样本，但实践量已经足够大，让我能够明显看出它与最早那些实验之间的差异。

一开始，最令人惊讶的是语言

早期面向大众开放的 LLM 有一个很有意思的特点：在很多技术场景里，它们看起来“很懂”的速度，往往比它们真正理解问题的程度要快。语言很有说服力，方案听起来很合理，代码也像是某个开发者真的可能写出来的东西。

问题的一部分恰恰就在这里。如果你熟悉对应的 Framework 或 API，很快就能发现某个函数其实不存在、参数写错了，或者方案依赖的是已经过时的知识。但如果你并不熟悉这些内容，得到的依然是一段非常自信的回答。

这并没有让这些系统对我失去价值。恰恰相反，从一开始，它们就是处理小型、边界清晰问题的好 Sparring Partner。它们可以生成不同方案、减少 Boilerplate、解释代码，也能帮助你进入一个陌生技术领域。但真正把这些建议整合进系统的工作，仍然主要由开发者完成。

当时典型的流程更像这样：

AI 是一个嵌在人类主导开发流程里的工具。真正困难的技术工作通常并不是写出某一个函数，而是判断一个改动应该放在哪里、会影响系统哪些部分，以及可能产生哪些副作用。在这些问题上，早期系统对我来说明显更受限。

对我来说，最重要的进步不是代码写得更好了

某个阶段之后，我对 LLM 的看法开始变化。当然，代码生成本身也在进步。但真正让我更在意的是另一件事：

LLM 对我的价值变大，首先是因为它们越来越擅长读取已有代码。

关注点不再只是一个函数。多个文件可以被一起分析，依赖关系可以被识别，陌生 Feature 可以被探索，Bug 可以跨多个 Layer 追踪，既有 Pattern 会变得可见，不同解决路径也可以放在现有架构中进行比较。

这也改变了我面对陌生技术时的工作方式。以前，遇到一个新的 Library 或未知 Subsystem，通常意味着先读文档、找入口、搜索代码，再从示例中慢慢构建 Mental Model。今天，LLM 可以显著加速这个最初的定位过程。

它并没有替我思考，而是在缩小 Search Space。Agent 可以找到入口点、整理相关文件、追踪依赖、为一个 Bug 提出假设，或者准备一个 Proof of Concept。结果并不等于完整的系统理解，但我建立自己系统理解的路径可以缩短很多。

对我来说，这比下一次生成的方法是不是再优雅一点重要得多。

从 Assistant 到 Agent

Tool Use 又一次改变了工作方式。一个传统 Chat 首先只知道我主动提供给它的内容。而 Coding Agent 可以在权限允许的范围内主动搜索 Repository、读取和修改文件、执行测试、看到 Compiler 或 Linter 错误，并根据这些结果继续行动。

于是流程变成了这样：

听起来这只是渐进式变化，但在实际工作中，差异非常大。

在我自己的项目中，如今已经可以给 Coding Agent 描述一个边界清晰的 Feature，然后得到跨多个技术 Layer 的连贯实现。根据系统不同，这可能从 Data Model 或 Backend 开始，经过 API 和 State，一直到 UI。

这并不适用于所有任务，也不适用于所有模型。它需要足够的 Context，不会自动产生好的方案，更不意味着 Review 可以省略。但仅仅是这种 Workflow 已经真正具备了实践价值，就足以让今天的工作方式与我最早使用 LLM 的时候产生根本区别。

研究也开始更细致地区分传统 Assistive System 与更具 Agentic 特征的工具。例如，一项关于 Copilot 与 Coding Agent 的 CHI 对照研究指出，更高自动化程度的 Agent 可以接手一些传统辅助系统不会走那么远的任务，从而减少人类投入。同时，新的要求也随之出现：使用者仍然需要理解 Agent 在做什么，并能够判断它的行为。 [1]

这与我的实践经验非常接近：更高的 Autonomy 并不会自动让人的工作消失，而是改变人的工作内容。

Agent 不需要完美，也可以非常有价值

关于 AI 与软件开发的讨论里，经常会使用一个我认为很奇怪的衡量标准：AI 能不能完全自主地替代一个有经验的开发者？如果今天的答案是否定的，就很容易进一步推导出“这项技术被高估了”。

对我的日常工作来说，另一个问题更重要：

借助这些工具，我能够可靠地对多少高质量工作负责？

Coding Agent 并不需要完美，才能产生巨大价值。如果它能加速我探索一个陌生区域，能在一小时而不是一个下午内准备一个 Proof of Concept，或者能在大量文件中一致地完成重复性改动，这就已经有价值。它如果能跨多个 Layer 追踪 Bug、整理出几个合理原因，或者在 Spec 足够清楚的情况下完成大部分实现，然后由我检查架构和结果，同样有价值。

关键并不是让人的工作消失，而是我把时间花在哪些工作上的比例发生了变化。

从个人感受来说，我很确定：在很多任务上，现代 LLM 和 Coding Agent 让我快了很多。但这并不能直接推出一个普遍的生产力结论。目前的研究呈现出明显更加复杂的图景。

2026 年的三项随机现场实验共覆盖 4,867 名开发者，综合结果显示，使用 AI Coding Assistance 的开发者完成任务数量增加了大约 26%。其中经验较少的开发者效果更明显。但需要注意的是，这些研究主要考察的是 Coding Assistant，而不是今天完整范围的 Agentic Workflow。 [2]

与此相对，一项广受讨论的实验研究了 16 名经验丰富的 Open Source 开发者。他们在自己已经熟悉多年的项目中完成了 246 个真实任务。在那个实验环境下，允许使用当时的 AI 工具反而让完成任务的时间增加了 19%。尤其有意思的是，即使实验结束之后，开发者仍然认为自己使用 AI 后更快。 [3]

2026 年一项汇总 23 项研究的 Meta-analysis 又得出了中等程度的正向生产力效果，但不同场景之间的差异很大。受控实验中的效果通常比 Open Source 与企业环境中的效果更加明显。 [4]

对我来说，这并不是一个需要立刻解释掉的矛盾。它也许恰恰是更值得关注的结论：AI Assistance 可以提升生产力，但这个效果有多大，甚至方向如何，都高度依赖 Context、任务、工具和开发者本身。

这当然没有“AI 让开发者快 50%”那么吸引眼球，但作为一条 Engineering 结论，它有用得多。

快速生成的代码还不是好的解决方案

另一个习惯并没有因为 LLM 而改变：我不会因为代码“能跑”就直接接受它。以前如此，有 Coding Agent 之后更是如此。

Agent 可以让测试变绿，却仍然选错 System Boundary。它可以正确实现 Requirement，却同时做出一个会妨碍后续需求的 Architecture Decision。它可以干净地复制一个现有 Workaround，制造局部一致性，却进一步加剧整体不一致；也可以给出技术上正确、但被放在系统错误位置的解决方案。

关于 AI-generated code 质量的研究也给出了足够理由，说明 Verification 不应该只是一个可选的最后步骤。一篇关于 AI 代码 Security 的 Systematic Review 总结了生成方案中的已知弱点，并强调适当 Review 与 Verification 流程的重要性。 [5]

这并不意味着 AI 生成的代码不安全，而人写的代码就安全。那显然过于简单。代码的质量不会因为作者是人还是模型而自动成立。它必须通过同样的领域、架构、功能和 Security 质量边界。

也正是在这里，我在私人项目里反复遇到一个非常值得研究的现象。有些项目中的规则其实非常明确：Architecture Rules、Agent Files、Skills、Memories、示例，以及关于 Component、Application Logic、State 或 Infrastructure 应该承担什么职责的清晰边界。即便如此，某些 Pattern 还是会重新出现。

例如，在经过几轮修改后，Component 又开始承担领域流程的 Orchestration；原本清晰的 Reactive Flow 中出现了 Imperative 中间步骤；某个 Layer Boundary 被局部放松，只因为当前实现看起来更简单。这并不会立刻发生，也不是所有 Agent 都会如此，但它出现得足够频繁，已经成为我实践中一个重复出现的观察。

个人观察： 明确的架构规则能够明显减少有问题的决策，但它们并不能自动阻止 Coding Agent 在较长的工作过程中重新滑向熟悉、局部看来合理的 Pattern。

为什么会这样，是这个系列后面会继续讨论的问题之一。直接得出“LLM 根本不懂架构”的结论太简单了。真正有意思的问题是：模型、Context、已有代码、本地示例、Spec 和 Tooling 如何共同影响下一步什么样的解决方案看起来最合理。

AI 是一个催化剂

今天很多围绕 Coding Agent 的问题，其实是非常古老的软件工程问题。人会复制已有代码，会参考本地示例，会对模糊 Requirement 做不同解释，会继承 Workaround，也会继续建立在那些原始背景早已消失的历史决策之上。

Coding Agent 并没有发明这些机制，但它可以极大地加快它们发生的速度。

假设一个系统里存在一个不太理想的 Workaround。它能运行，离当前任务又很近，看起来也像一个已经存在的 Pattern。之后另一个 Change 参考了它，于是这个 Workaround 第二次出现。这样它在 Repository 中变得更显眼，下一次遇到类似任务时，也就更容易被理解为一种有意的本地约定。

这很像一种 Broken Window Effect。我并不是说这一机制已经被证明是 Coding Agent 的普遍规律。对我来说，它目前首先是一种由重复观察产生的 Hypothesis：如果已有代码是新决策的重要 Context，那么频繁出现的本地 Pattern 可能会进一步提高自己再次被复制的概率。

有意思的是，这种动态并不一定是负面的。好的 Pattern 也可以以同样方式变得更显眼，被复制，并提高整个系统的一致性。

因此，比起把 AI 看成一种全新的软件问题来源，我更喜欢把它理解为一种催化剂或放大器。

AI 并没有重新发明软件工程中很多熟悉的问题，但它可以极大地提高这些问题传播的速度和范围。

同样的逻辑也适用于好的 Engineering Practice。Architecture 并不会因此变得不重要，它产生效果的速度反而可能更快。

人目前仍然可以非常有效地纠偏

读到这里，很容易产生一种印象：Coding Agent 迟早都会在架构上越走越偏，因此必须始终带着高度怀疑盯着它工作。但这并不符合我的经验。

关键在于，速度对双方都成立。Agent 可以在很短时间内完成很多实现，而有经验的开发者往往也能很快发现方案正在朝一个不理想的方向发展。这时并不需要把一切推倒重来。可以让 Spec 更精确、把 Boundary 写得更明确、指定一个 Pattern 作为参考，或者删除一个错误的 Abstraction，然后让 Agent 继续工作。

Agent 快速工作
↓
结果整体可用
↓
较早发现问题方向
↓
修正 Context 或 Constraint
↓
Agent 继续实现

对我来说，这正是目前最有效的 Agentic Work 方式之一。不是“全部做完了再告诉我”，而更像是：“在一个清晰限定的空间里尽量独立工作，我重点检查那些可能跨出这个空间的决策。”

因此，截至 2026 年，我依然认为具备深度系统理解的经验开发者是专业 Agentic Work 的关键组成部分。这不是在预测五年或十年后的模型能力，而只是描述我今天实际工作的状态。

我交给 Agent 的 Implementation Work 越多，当前就越需要有人能够判断最终方案是否真的适合这个系统。

也正因为如此，Repository-wide Change 与完整 Software Autonomy 不能被当成同一件事。新的 Benchmark 越来越尝试评估完整流程，而不仅仅是单个 Code Change，包括 Environment Setup、Implementation 和 Verification。2026 年的 SWE-Cycle Preprint 例如报告，当这些原本可以分开的任务必须作为一个没有 Human Scaffolding 的完整 End-to-End 流程执行时，Agent 的表现会明显下降。 [6]

今天的 Agent 可以完成令人印象深刻的连贯改动。但这并不意味着它能够完全自主接管任意软件项目。这两种说法之间还有很大的空间——而我认为真正有意思的实践恰恰发生在这里。

真正的问题已经变了

2023 年，我会问自己：

AI 到底能不能真正写出有用的代码？

今天，这个问题对我已经没有太大吸引力了。当然，它可以写代码——不一定每次都正确，不一定每次都好，也不能脱离足够的 Context。但“AI 能否生成有用代码”对我来说已经不是一个开放问题。

现在更有意思的问题是：

我们怎样使用这种速度，才能真正得到好的软件？

这会打开一个更大的问题空间。我们需要理解为什么结果不总是可复现、Context 到底意味着什么、Memory 与 Skills 能做什么以及不能做什么，也需要理解 SWE-bench 这样的 Benchmark 实际测量了什么。我们还要讨论：为什么 Agent 即使有规则仍可能 Drift？当 Implementation 越来越便宜时，Requirement 要精确到什么程度？Architecture 如何限制可行的 Solution Space？当生成软件的速度超过人类舒适 Review 的速度时，Verification 应该如何进行？

除此之外还有经济与组织问题：什么时候真的需要大的 Frontier Model？什么时候更小或者本地模型已经够用？如果把 Review、Infrastructure 和错误决策一起算进去，Agentic Work 到底要花多少钱？当越来越多 Implementation Work 都可以被委托出去时，我们自己的角色又会发生什么变化？

这个系列会讨论其中一些问题。不是因为 AI 突然取代了软件工程里所有旧问题，而是因为它让很多旧问题在新的条件下变得更加明显。

2023 年写的文章，今天已经会带有历史感

如果我在 2023 年写下这篇文章，那么今天其中很大一部分已经只能算是一张历史快照。这很值得注意，但它并不意味着我们现在就应该以同样不严谨的方式走向另一个极端。

我们不知道下一次能力跃迁会有多大，也不知道继续扩大模型规模什么时候会出现明显的边际递减，更不知道今天的哪些限制会被更好的模型解决，而哪些问题最终会被证明是现有方法本身的结构性特征。

所以我认为下面两句话必须同时成立：

不应该把 2026 年的限制理解成永恒的限制。

同样：

也不应该因为过去三年发展异常迅速，就把这种速度无限外推到未来。

两者都只是猜测。

对于 Software Engineering 来说，今天的状态已经足够重要。技术已经足够强大，以至于我们必须学习如何专业地使用它。

为什么要写这个系列

所以，我不想把这个系列写成 AI 广告，也不想写成一份“为什么 AI 都被高估了”的论证集。模型排行榜同样不是我最感兴趣的东西，因为系列还没写完，它很可能就已经过时了。

我真正感兴趣的是 Engineering Question：今天什么真的可行？哪些场景的效果比预期好？风险在哪里出现？哪些所谓的新问题其实只是旧问题被加速？哪些 Workflow 有帮助，哪些规则没有想象中有效？什么可以测量，什么仍然只是经验？最重要的是，当下一代模型再次明显强于今天时，哪些原则仍然值得保留？

过去几年里，我对 LLM 的理解已经发生过多次变化：从令人印象深刻的 Text Generator，到实用的 Coding Assistant，再到用于分析和探索的工具，最终发展到今天的 Agent——在条件合适时，我已经可以把一个具体实现中的相当一部分工作交给它。

这既不是“只会制造 Noise”，也不是一个能够在没有人类引导的情况下可靠接管复杂系统的自主软件开发者。对我来说，这两种描述都已经过于轻松了。

两者之间的现实要有意思得多，而且它已经足够实用，以至于 Software Engineering 必须认真回应。

因此，这个系列首先是一份阶段性的总结：

观察、理解、尝试、验证——然后尽可能从中提炼出可靠的 Engineering Principle。

不过，在我们讨论为什么 Agent 有时候会做出令人惊讶的好决定，有时候又会做出令人惊讶的奇怪决定之前，还需要先退一步。

LLM 内部到底发生了什么？Training 和 Inference 是什么？Token 是什么？Context 是什么？当我们说一个结果是 probabilistic 时，到底意味着什么？

下一篇文章将从这里开始。

参考资料

[1] Valerie Chen, Ameet Talwalkar, Robert Brennan, Graham Neubig: Code with Me or for Me? How Increasing AI Automation Transforms Developer Workflows. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, 2026. DOI: 10.1145/3772318.3790850.

[2] Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz: The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science, 2026. DOI: 10.1287/mnsc.2025.00535.

[3] Joel Becker, Nate Rush, Elizabeth Barnes, David Rein: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Preprint, 2025. arXiv: 2507.09089. DOI: 10.48550/arXiv.2507.09089.

[4] Sebastian Maier, Moritz Gunzenhäuser, J. Schweisthal, Manuel Schneider, S. Feuerriegel: A meta-analysis of the effect of generative AI on productivity and learning in programming. Preprint, 2026. arXiv: 2605.04779.

[5] Claudia Negri-Ribalta, Rémi Géraud-Stewart, Anastasia Sergeeva, Gabriele Lenzini: A systematic literature review on the impact of AI models on the security of code generation. Frontiers in Big Data 7, 2024. DOI: 10.3389/fdata.2024.1386720.

[6] Hao Guan, Lingyue Fu, Shao Zhang, Yaoming Zhu, Kangning Zhang, Lin Qiu, Xunliang Cai, Xuezhi Cao, Weiwen Liu, Weinan Zhang, Yong Yu: SWE-Cycle: Benchmarking Code Agents across the Complete Issue Resolution Cycle. Preprint, 2026. arXiv:2605.13139.