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，每个人都有一个，但没人记得里面一半的内容是干嘛的。
但这恰恰说明它正在成为基础设施的一部分。
SST 创始人 Dax 发了一条很有意思的推文，大意是：你可以全程 vibe coding，没人拦你。你可以骗自己说这是聪明的策略。但所有人都能感觉到，你的作品里透着敷衍，透着你有多不在乎。因为你做一件事的方式，就是你做所有事的方式。
评论区炸了。
有人反驳说，我花大量时间设计架构、规划需求，只是让 AI 来写具体代码，这怎么能叫懒？工业革命时期肯定也有人这么批评机器。
也有人说，vibe coding 本身不是问题，不知道自己到底想要什么才是问题。当一个人真正理解自己的愿景时，他的 prompt 是锋利的；当他在偷懒时，就只会说“让它能跑起来”，然后陷入无尽的来回修改。
还有一条评论很精准：放弃亲手写代码这件事本身没问题，甚至可以提高效率。但如果放弃到连为什么这么做、怎么做的都不知道，那就危险了。
我觉得这场争论的核心其实不在于用不用 AI，而在于你有没有真正锁定问题，还是只在找捷径。
工具从来不决定你是哪类人。每一个承诺压缩努力的工具都会制造一个筛选机制：有人用它去做更有意义的事，有人用它来少做事。如果你所处的环境只衡量产出数量，无法区分深思熟虑的方案和随便生成的东西，那人们自然会选择阻力最小的路径。这不是懒惰，这是对不再重视深度的系统的理性反应。
vibe coding 用来从零到一很好用，但从一到一百的过程中，那些不在乎的部分会开始在日志和用户流失里显形。你没办法靠 prompt 永远绕过一个破碎的架构。
2025 年的真正高手，不是回避 AI，而是把它当成高精度仪器，而不是思考的替代品。
Dax 自己做了最好的 AI 辅助编程工具之一，却依然对 vibe coding 保持警惕。这种清醒值得尊重。
最近看到很多人急着上手 Clawdbot，Greg Isenberg 泼了盆冷水：如果你还没深度用过 Claude Code，别急着碰它。
道理很简单。Claude Code 是基本功训练场，你在这里学会提示词怎么写、代码怎么调、MD 文件怎么用、安全边界在哪里。而 Clawdbot 本质上是个放大器，它能把你现有的能力乘以一个系数，全天候帮你干活。
问题在于，放大器不挑好坏。你的能力强，它帮你事半功倍；你的能力弱，它帮你批量生产垃圾。
有人说得更直白：Clawdbot 是最终 Boss，Claude Code 是新手教程。跳过教程直接打 Boss，只会死得更快更花哨。
一位用户分享了他的笨办法：连续两周记录提示词日志。每次 Claude 给出完美输出，记下提示词结构；每次失败，记下问题所在。60 条记录之后，规律浮现了。80% 的好结果来自同样的 5 种提示词框架。现在他的机器人就跑这几套框架，稳定输出。
没有这个积累阶段，他只会把自己的错误自动化。
这让我想到一个更普遍的问题：我们总想跳过积累直达结果。但工具从来不创造能力，只是暴露能力。你用 Claude Code 写不出好东西，换成 Clawdbot 也不会突然开窍，只是错得更快、规模更大。
自动化一个烂流程，你只会以光速得到烂结果。
当然也有不同声音。有人认为不该自我设限，Clawdbot 有很多种玩法，不一定非要会写代码。这话也对，但前提是你得清楚自己在做什么。
真正的捷径往往是慢慢来。那些看起来一夜之间的成功，背后通常是无数次重复练习的积累。乔布斯说过，你无法预先把点连成线，只能回头看时才能理解。
所以别急。先把 Claude Code 用熟，把基本功打扎实。等你真正理解了底层逻辑，再去驾驭那个 24 小时不休息的助手。否则你不是在指挥一个强大的工具，而是在管理一团高速运转的混乱。
