"你是什么真实的?我们正好 10 年前就谈过这个了!"
本页为原文的机器翻译，未经人工译者审核。历史信息可能已发生变化。
"你是什么真实的?我们正好 10 年前就谈过这个了!"
突然,在与一位老友的对话中,我们深入谈到 AI 的记忆,更确切地说,是为什么它会在对话中途"忘记"东西。这位老友描述了 context window 如何工作,而我听到的是"RAM 内存管理"。进入上下文窗口的内容对模型立即可用。没进入的,对它来说就不存在。完全就像普通软件中的工作内存。
朋友们,一切都在重复。太阳底下没有新鲜事,AI 革命中现在也是如此。
上下文窗口从各方面来说就是内存 -- 进入上下文窗口的内容对模型立即可用,没进入的,对它来说就不存在。完全就像普通软件中的工作内存。RAG 就像从硬盘加载以及随之而来的挑战。对话摘要是有损压缩。Prompt caching 是经典的缓存。Sliding window 是 ring buffer。所有这些概念存在了几十年,只是换了新名字。
而这不只发生在基础设施层面。每当新技术到来,我们就重新进行同样的对话。Angular 出现时,人们争论状态管理、关注点分离、组件架构。与多年前在其他场景下存在的争论一模一样。现在有了 AI 也是一样:保留什么、丢弃什么、索引什么、检索什么。软件工程师已经解决了好几代人的问题。
这里还有一个值得不要错过的思维工具。如果你理解上下文窗口的行为像工作内存,你就能提前预测接下来会出现哪些功能,因为你已经从经典软件世界中了解这些问题和解决方案。作为资深开发者有它的好处 🙂
更加不变、却极具迷惑性的,是软件工程的基本实践 -- 恰恰因为 AI 加速了开发,它们今天比以往任何时候都更重要。
2025 和 2026 年的数据很清楚:用 AI 生成的代码包含更多 bug,PR 的 review 时间显著上升,可读性问题出现得更频繁。DORA 报告对此展示得最好:AI 是放大器。流程强的团队会变得更强。流程弱的团队会变得更弱。
用 AI 编写可用于生产环境(production ready)的代码,与没有 AI 时是同样的挑战。
需要小而可读的 PR。需要 SOLID 原则来优化访问代码的智能体的上下文。需要考虑在面对成千上万或数百万客户时生产环境的规模(scale),感觉模型对此仍然没有足够的上下文。需要与团队一起规划和分享以获得多种视角 -- 每个人及其专业领域 -- 以确保我们覆盖所有真正无法放进智能体上下文的东西。
简而言之,构成良好软件开发基础的所有工作实践都没有改变。
所以"不写代码"的幻觉只对实际写代码的部分成立。代码维护需要并强制要求机器与人之间的同步,并希望通过高度的 Trust 层来减少这个昂贵而缓慢的接口。
技术确实在变化和更新,但 bug 依然存在。开工吧
