本以为会得到一堆废话，结果AI回复：“这段代码看起来是在验证用户输入，但实际上它制造了一个竞态条件，攻击者只需间隔0.3秒发送请求就能绕过身份验证。”
这恰恰是真正的漏洞所在。
为什么“求错”反而能得到正确答案？因为当你要求AI给出错误解释时，它被迫从对抗性视角思考，而不是乐观地假设一切正常。常规提问让AI扮演助手，反向提问让它变成审计员。
这背后有一个设计领域的经典方法叫“最糟糕的点子”。只有真正理解什么是好的，才能精准地生成坏的。而且当人们被允许说任何离谱的话时，那些平时不敢提的观察才会浮出水面。
有人用这个方法做时尚品牌策划，团队提出“免费送皮革制品”这种荒唐想法。但正是这个“烂点子”打开了思路，皮革这种昂贵材料此前从未被认真讨论过，因为大家都觉得它太特殊不能乱动。最终他们在疫情最严重的时期打破了销售记录。
几个实测有效的反向提问句式：
“这段代码为什么会失败？”比“这段代码能用吗？”更有价值。
“假设我是个白痴，我漏掉了什么？”
“像这段代码得罪了你一样狠狠吐槽它。”
“扮演我最苛刻的批评者，找出所有能反驳我的地方。”
还有人分享了一个更系统的调试提示词：倒过来思考这个问题，告诉我所有让这段代码出错的可能性，这段代码本应实现某某功能，慢慢分析，给我所有能让它崩溃的场景。
当然也有人提醒：AI同样可能为了迎合你而编造批评。它太想让你满意了，这意味着它经常说你的代码很好，即使代码很烂。所以反向提问不是万能药，而是打破AI讨好倾向的一种策略。
有人在自定义指令里写：“少一些反射性倾听，我不需要啦啦队，我需要有人挑战我的想法。”还有人更直接：“别拍我马屁，你连手都没有。”
最好的代码审查是那种让你心里不舒服的审查。我们一直试图从AI那里获得有帮助的答案，但也许更该让它来摧毁我们的作品。
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输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。
还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。
