Simon Willison 抛出一个有趣的观察：过去两年大模型能力突飞猛进，唯独上下文长度几乎没动。我们在20万到100万token这个区间已经停留很久了。
他的判断是，这更像一个硬件瓶颈。上下文需要显存，而内存带宽是核心制约因素。
但讨论中涌现出更深层的洞见。
有人指出，真正的瓶颈不是长度，而是注意力质量。一个能真正追踪依赖关系的20万token窗口，远胜于读到第50页就忘了第3页的200万token窗口。这话说到点子上了。
另一位开发者分享实战经验：试着把关键信息放在15万token的位置，然后看模型假装它不存在。这才是行业不愿公开的秘密。所谓的百万级上下文，很大程度上是营销数字。
从技术角度看，推理成本不是线性增长的。长上下文会把注意力机制变成一种类似自旋玻璃的状态，太多弱耦合的token会制造出大量浅层竞争盆地，而不是一个深井。简单说，模型会迷失在信息海洋里。
有趣的是，实践者们反而不那么渴望更长的窗口。一位开发者说得好：1万token精准的上下文，胜过10万token的大杂烩。瓶颈已经从「能不能装下」转移到「该装什么」。
还有人提出更激进的观点：与其追求更长的上下文，不如实现持续学习，让上下文窗口扩展变得没有必要。这可能才是研究者们真正努力的方向，只是持续学习太难，进展都藏在水面下。
据透露，Google内部已有1000万token的上下文能力，只是成本上还不可行。而Magic LTM-2-Mini声称达到1亿token，Llama 4 Scout推到1000万。但这些数字背后，是三个残酷的瓶颈：算力、成本、以及模型实际利用这些上下文的能力。
一个类比很贴切：人们在喷气发动机真正量产前几十年就知道它能工作。同样的动态正在上演。当前架构下，2到3倍的改进不会带来惊艳感。真正的突破需要100倍甚至1000倍的有效上下文提升，这需要有人愿意押注全新的模型架构。
目前的解决方案是子代理模式。Claude Code可以精心设计恰到好处的上下文，发送给子代理，等待回复。这本质上是用工程手段绕过了硬限制。
所以现状是：标签上写着百万token，实际可用的可能只有十分之一。行业正在从「堆长度」转向「用好长度」。这个转变本身，或许比单纯的数字增长更有价值。
一个大胆的假设：C语言之于汇编，Java之于C，Python之于Java，现在LLM智能体正在对所有编程语言做同样的事。
这里说的LLM智能体，指的是一种全新的开发模式：多个智能体并行工作，大部分时间自主运转，只在关键节点需要人类介入。判断这个假设是否成立的标准很简单：如果一个开发者借助多智能体能产出十倍于从前的成果，那它就是真的。2026年初的今天，我还不能完全确定，但已经在认真考虑这种可能性。
对于在软件行业摸爬滚打多年的人来说，质疑声不会少。先回应几个常见的：
“十倍代码量不等于十倍产出，那只是垃圾代码。”没错，衡量标准应该是实际交付的功能价值，不是代码行数。如果假设成立，真正的“代码”其实是你给LLM的指令。
“LLM是给不会写代码的人用的。”LLM确实会带来大量新程序员，但这不意味着老手用不上。事实上，很多资深开发者正在借助LLM实现产出的飞跃。
“用LLM就是偷懒不想动脑。”恰恰相反。当你用LLM做更多事情时，你需要思考和工作得更多，而不是更少。管理一支智能体舰队比自己写代码更费心力，因为你要设计的东西是原来的好几倍。
“LLM会让我们的编程技能退化。”可能吧。但我们在工作中也不会担心汇编或C语言技能生疏。大多数人只在业余时间练习这些，因为没人能证明用汇编写业务代码会更高效。
“LLM写的代码比我差太多。”几乎肯定如此。但你的汇编代码也比不上专家。只要LLM生成的代码足够高效，能跑起来，就已经可以交付了。系统会丑一些，但它能用。
“用LLM智能体太贵了。”如果它们能带来50%的生产力提升，对比你的薪资，其实一点都不贵。而且LLM只会越来越便宜。它们只在绝对值上贵，相对值上并不贵。
“我试了一下午，纯粹浪费时间。”学习曲线是存在的。想想你当初花了多少时间和编程工具、语法搏斗，才勉强上手。
以上这些反对意见在逻辑上都站不住脚，但情感上确实不容易接受。
真正触及核心的问题有两个：质量和可理解性。LLM生成的代码会不会很快变成一堆垃圾？我们是不是在沙子上建房子？LLM生成的代码量会不会大到我们永远无法理解？即使系统能跑，我们是否会因为不理解而永远失去控制？
我认为质量和可理解性应该成为任何LLM编程框架的核心目标。从经济角度看，只追求质量是不够的。可理解性可能是浪漫主义的幻想，也可能是一个值得押注的长期赌注。我选择后者。
有趣的是，LLM比以往任何高级语言都更具非确定性。但它们也能在高层次描述上帮你理清思路，这是以前任何抽象层都做不到的。
未来的开发会是什么样子？我看到四个核心要素：文档是一组描述系统规格的页面，包括目的、核心实体、接口、约束、关键流程和编码规范；实现是代码库加上所有数据，代码库应该能从文档重建，数据应该与文档描述一致；对话是多个智能体在执行任务时产生的思考流，人类可以随时查看或介入；任务是一组动态的离散工作单元，可以嵌套，有状态追踪。
两个存量，两个流量。文档和实现是系统的积累，对话和任务是构建它们的过程。人类当然可以直接修改文档和实现，但这种情况会越来越少，因为大部分工作流是智能体驱动的，人类主要在与智能体交互。
智能体可以扮演多种角色：独立完成任务的执行者、协调下一步的管理者、试图破坏新功能的测试者、脱离上下文审查代码的评审者、解决冲突的合并者。重要的是人类可以灵活配置，指令可以是一次性的，也可以是文档的一部分。
MCP协议带来了一个打破应用孤岛的机会。它可以被视为一种通用的数据请求接口，让你的智能体能够从任何现有应用中提取功能和数据，放到你自己设计的动态画布上。你可以说“从某个系统给我拿这些数据”，LLM就会去取，然后在你想要的地方做一个漂亮的即时可视化。这才是真正的孤岛终结者。
如果我们用一个好的底层基座而不是臃肿的技术栈，LLM输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。
还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。
有人分享了一套 claude.md 的配置框架，评论区炸了。不是因为内容多新颖，而是它戳中了一个被严重低估的真相：大多数人用 AI 编程，每次都在从零开始。
先说这套框架的核心逻辑。
第一条原则是「计划模式优先」。任何超过三步的任务，先停下来做规划。方向错了就立刻止损重来，别硬撑。写详细的规格说明来减少歧义。这听起来像常识，但多少人是一上来就让 AI 开干，然后在十五轮对话后才发现方向跑偏？
第二条是「子代理策略」。大方任务拆给子代理，保持主线程干净。复杂问题让子代理并行处理。一个子代理只做一件事。这本质上是在教 AI 学会分治，而不是把所有东西塞进一个上下文窗口里窒息。
第三条最关键，叫「自我改进循环」。每次纠正 AI 的错误后，让它把教训写进 lessons.md 文件。然后无情地迭代这些规则，直到错误率下降。每次开新会话，先回顾这些教训。
有人评论说得好： lessons.md 的循环才是真正能沉淀下来的东西。手动做了一周，效果立竿见影，它不再在你的代码库里犯同样的蠢错了。其他都是不错的默认设置，但这一条会复利增长。
还有几条值得一提。「验证优先于完成」，永远不要在没有证明代码能跑之前就标记任务完成。问自己：一个高级工程师会批准这个吗？「追求优雅但要平衡」，对于非平凡的改动，停下来问一句：有没有更优雅的方式？但如果改动很简单，就别过度工程化了。「自主修复 bug」，遇到报错就直接修，别等着被牵着走。
有个用户分享了自己的实践：三个月前开始维护一个 claude.md 文件，每周更新。提示词从十五轮对话缩减到两三轮。秘诀是记录失败而不只是成功。每次 AI 搞砸支付逻辑或导航流程，就把具体的修复方案加进去。现在文件里有四十七条规则，覆盖从 RevenueCat 集成到应用商店截图规范的所有细节。
他说了一句话我很认同：你其实是在训练一个专属的编程助手，让它学会像你一样思考。一旦调教好了，把项目交给任何人，他们都能得到同样质量的输出。
当然也有人泼冷水。有人指出这些 md 文件只是文本，没有基础设施来强制执行就没用。模型可能遵守，也可能不遵守，上下文一重置什么都不剩。还有人说这套框架缺了几样东西：目标清晰度、优先级排序、来自真实用户的反馈、时间约束、向他人学习的机制、产品思维。
这些批评都有道理。但我觉得重点不在于这套框架是否完美，而在于它指向了一个被忽视的方向：把你的使用模式变成活的配置文件。工具的威力，来自于习惯变成配置的那一刻。
有人开玩笑说 claude.md 是新时代的 .bashrc，每个人都有一个，但没人记得里面一半的内容是干嘛的。
但这恰恰说明它正在成为基础设施的一部分。
