最近一个叫GeoSpy的AI工具在社交媒体上引发热议。它号称能通过你发布的照片精准定位你的所在地。
这其实不是什么新技术。反向图片搜索、EXIF元数据提取、地理位置数据库早就存在多年。真正改变的是这些能力被包装成了傻瓜式界面，任何人都能上手。有评论者指出，那些GeoGuessr游戏高手比如Rainbolt，凭肉眼就能做到类似的事情。
但问题恰恰在这里。以前你要找到一个人的位置，需要真正的人类技能。现在这种能力被“民主化”了，门槛降到了地面。
真正的隐私风险不是工具本身，而是你照片里泄露的信息量远超你的想象。街道标识、建筑风格、植被特征、窗户倒影，交叉比对几张照片就能快速三角定位。更不用说很多人根本不知道自己的照片里还藏着GPS坐标。
有人分享了一个真实案例：乌拉圭一位检察官和妻子去哥伦比亚卡塔赫纳度假，毒贩通过他妻子发的Instagram照片追踪到他们，随后将他暗杀。
还有人提到那条古老的忠告：别在度假时发度假照，因为那等于告诉全世界你家现在没人。入室盗窃从未消失，瘾君子们也会刷社交媒体。
防护措施其实不复杂。不要实时发布位置信息，避免暴露日常动线规律，上传前手动清除元数据。更重要的是做好威胁建模，想清楚你真正需要防范的是谁。
目前GeoSpy已经限制了访问权限，只对企业和执法机构开放。这是好事也是讽刺。工具可以用来找回被绑架的儿童，也可以用来追踪前任。在这个问题上，善与恶之间只隔着一个用户协议。
有人评论说：想象一下军方和情报机构手里的工具是什么级别。
这大概是整个讨论中最清醒的一句话。
我们每天都在使用大语言模型，但它们内部究竟长什么样？一位开发者决定不再把模型当成黑盒来对待。
Reddit用户sultan_papagani开发了一个小工具，可以上传任意的gguf格式模型文件，用类似3D的方式可视化它的内部结构：层、神经元、连接关系，一目了然。开发者自嘲这只是个粗糙的原型，但社区反响热烈。
这个工具的核心价值在于：它让抽象的模型参数变成了可以旋转、缩放、漫游的空间结构。你可以用键盘在神经网络的层级间穿梭，看到每个权重的实际数值如何影响节点的颜色。有人评论说这像赛博朋克游戏里的黑客小游戏，某种程度上确实如此，只不过你破解的是人工智能的大脑。
技术实现上，它只读取gguf文件的头部信息，在浏览器端用纯HTML和JavaScript完成渲染，完全离线运行。这意味着你不需要把模型上传到任何服务器，隐私安全。
讨论中涌现出不少相关资源。有人提到Brendan Bycroft两年前做的LLM可视化项目堪称经典，但无法加载自定义模型。还有Neuronpedia这个开源项目，专注于模型可解释性研究，可以追踪特定概念在神经网络中的激活路径。另一位开发者曾经做过动态可视化，能显示模型推理时的激活模式，可惜账号已删除。
有用户提出了一个诱人的想法：能不能让可视化实时播放推理过程？想象坐在VR里，看着神经网络在处理每个token时逐层点亮，这对理解模型行为会有多大帮助。
AI发展飞速，但帮助人们理解AI的可视化工具严重滞后。理解你使用的工具，和盲目信任它，是两种完全不同的关系。
看到一个很有意思的讨论。一位软件开发者抱怨：两个客户原本要找他做项目，一个是AI工具的记忆系统整合，另一个是房地产资产管理系统。结果两个客户突然说，他们用Claude Code自己就能搞定。开发者看了他们做出来的东西，评价是“勉强算个原型”。
他很郁闷：怎么让这些“不懂软件的商业人士”明白，软件从0做到80%很容易，但从80%到100%才是真正的噩梦？
评论区的反应很有意思，分成了泾渭分明的两派。
第一派是“等着他们来求你”。大部分有经验的开发者都持这个观点：让他们先去撞墙吧。那20%的差距包含了安全漏洞、边界情况处理、负载均衡、错误监控、数据迁移等等一堆“不在需求文档里”的东西。原型在3个测试用户时跑得很欢，300个用户时就会崩溃。有人甚至当场黑了一个客户准备上线的“vibed coded”应用，演示了安全问题，看着他们脸色一变。建议很实际：保持优雅，递上名片，告诉他们遇到问题随时联系。几个月后接到求助电话时，报价因“通货膨胀”涨20%。如果要收拾AI留下的烂摊子，那就涨200%。而且别答应修补，直接要求从头重写，反正现在写代码已经不费事了。
第二派则提出了一个更尖锐的问题：也许80%对他们来说就够了，而你才是那个被颠覆的人。
如果两个完全不同的客户不约而同地想到了同一件事，这不是巧合，这是市场反馈。你在卖工程上的完美，但他们只需要一个现在就能用的商业解决方案。如果他们那个“勉强算原型”的工具省了一大笔钱还解决了眼前的问题，那他们就赢了。
这个观点戳到了一个很现实的地方：过去软件开发者的护城河是“只有我能写代码”。但当代码本身变得廉价，真正的价值应该是领域知识、持续支持、数据策略，以及AI工具无法从提示词里搞清楚的那些复杂整合。
有几条建议特别中肯。一位评论者说：别再把自己定位成“写代码的人”，开始把自己定位成“交付可靠性的人”。给客户展示他们的原型和生产系统之间的差异：缺失的访问限制、SQL注入漏洞、没有监控。把风险具象化、可视化。另一位评论者建议转向FUD策略，也就是恐惧、不确定性和怀疑。问客户三个问题：软件出问题谁来修？修一次要花多少钱？最后谁来为这个决定负责？
最让我觉得深刻的是这段话：被AI原型坑过一次的商业人士，会成为你最好的长期客户。而那些从来没被坑过的，本来也不会为质量付费。
事实是这样的：原型的成本已经趋近于零。但一个能持续迭代、能不断增加功能的产品，和一个能跑起来的原型，完全是两回事。当代码变得廉价，你能提供的稀缺资源是什么？这可能是每个靠写代码为生的人都要认真思考的问题了。
当AGI广告遇上服务器宕机：一场价值七千万美元的尴尬
超级碗期间，一则“AGI即将到来”的广告引爆了科技圈的讨论。广告背后是Crypto.com的CEO Kris Marszalek，他刚刚豪掷七千万美元买下了ai.com这个域名，创下公开披露域名交易的历史新高。
然而，接下来发生的事情堪称行为艺术。
当数百万观众涌向这个价值连城的网站时，他们看到的是一个504网关超时错误页面。有人调侃说：“他们的自主AI代理确实让网站加载速度变快了，方法是把整个网站删掉了。”另一位评论者更是联想到了《机械公敌》的剧情。
七千万买个域名，三千万投个超级碗广告，结果连基础的服务器扩容都没做好。这大概是2026年开年以来最昂贵的一次技术翻车。
更耐人寻味的是网站的内容本身。在短暂能够访问的时候，用户发现这个号称要“加速AGI到来”的平台，充斥着区块链项目标配的空洞词汇：“去中心化自主进化AI代理网络”、“动态自我演进的多代理架构”。一位用户吐槽：说好的去中心化平台，结果注册要用谷歌账号。
最令人警觉的是，网站要求用户输入信用卡信息来“证明你是人类”。这个设计让不少人直接关掉了页面。有用户机智地使用了虚拟信用卡完成注册，但也坦言“最大的骗局广告投在超级碗上也不是不可能”。
这件事折射出当下AI领域的一个普遍现象：营销预算远超技术投入。能花一亿美元做品牌曝光，却搞不定一个高并发网站，这种错位本身就很说明问题。
有人问AGI什么时候来。也许该先问问：连pie chart都画不好的模型，距离AGI还有多远？一位每天使用AI工作的用户分享了他的经历：让模型画个12段的饼图，标签重叠到无法阅读，反复提示五次，模型承认错误、道歉，然后继续重叠。
技术圈总喜欢说“这是用户的技能问题”。但当模型自己都承认做错了却无法改正时，这显然不是用户的问题。
AGI是否即将到来，我不知道。但我知道的是，任何宣称要改变世界的项目，如果连最基本的用户体验都无法保障，那它改变的可能只是你的钱包。
超级碗期间，一则“AGI即将到来”的广告引爆了科技圈的讨论。广告背后是Crypto.com的CEO Kris Marszalek，他刚刚豪掷七千万美元买下了ai.com这个域名，创下公开披露域名交易的历史新高。
然而，接下来发生的事情堪称行为艺术。
当数百万观众涌向这个价值连城的网站时，他们看到的是一个504网关超时错误页面。有人调侃说：“他们的自主AI代理确实让网站加载速度变快了，方法是把整个网站删掉了。”另一位评论者更是联想到了《机械公敌》的剧情。
七千万买个域名，三千万投个超级碗广告，结果连基础的服务器扩容都没做好。这大概是2026年开年以来最昂贵的一次技术翻车。
更耐人寻味的是网站的内容本身。在短暂能够访问的时候，用户发现这个号称要“加速AGI到来”的平台，充斥着区块链项目标配的空洞词汇：“去中心化自主进化AI代理网络”、“动态自我演进的多代理架构”。一位用户吐槽：说好的去中心化平台，结果注册要用谷歌账号。
最令人警觉的是，网站要求用户输入信用卡信息来“证明你是人类”。这个设计让不少人直接关掉了页面。有用户机智地使用了虚拟信用卡完成注册，但也坦言“最大的骗局广告投在超级碗上也不是不可能”。
这件事折射出当下AI领域的一个普遍现象：营销预算远超技术投入。能花一亿美元做品牌曝光，却搞不定一个高并发网站，这种错位本身就很说明问题。
有人问AGI什么时候来。也许该先问问：连pie chart都画不好的模型，距离AGI还有多远？一位每天使用AI工作的用户分享了他的经历：让模型画个12段的饼图，标签重叠到无法阅读，反复提示五次，模型承认错误、道歉，然后继续重叠。
技术圈总喜欢说“这是用户的技能问题”。但当模型自己都承认做错了却无法改正时，这显然不是用户的问题。
AGI是否即将到来，我不知道。但我知道的是，任何宣称要改变世界的项目，如果连最基本的用户体验都无法保障，那它改变的可能只是你的钱包。
有人问我职业发展最重要的建议是什么。我的答案只有一个：建立一条从「这破玩意儿怎么不工作」到「我是怎么搞定这蠢东西的」的内容管道。
这个世界上的技术问题，大多数都很蠢。每个人都会卡在同样愚蠢的地方。如果你被困住了，一定有人正在经历同样的痛苦。把解决过程写下来。
有人问：为什么要写？是为了做好人吗？
不完全是。写作对你的灵魂有好处。
这话听起来有点玄，但背后的逻辑很实在。当你把凌晨两点改配置文件的经历写成文章，你做的不只是记录，而是在强迫自己把模糊的直觉变成清晰的认知。很多时候我们「修好了」一个问题，其实并不真正理解它。写作会逼你想明白。
有个开发者分享说，他最受欢迎的文章标题永远是某个报错信息，加上简短的解决方案。这就是需求。没有人搜索「优雅的技术架构」，大家搜索的是那串让人崩溃的错误代码。
另一位说，他的技术信誉就是这么建立起来的。每修一个bug就发一条推文，帮助遇到同样问题的人。调试到内容的管道，本质上是免费的分发渠道。
有人担心：现在写博客不就是给AI提供训练数据吗？
这个担忧可以理解，但换个角度想：你的文章被AI学习，说明它有价值。而且AI能学会的是知识，学不会的是你解决问题的思维路径和持续输出的习惯。这些才是真正的护城河。
还有人说得更直接：这条管道是很多人没有放弃的唯一原因。把挫败感转化成内容，本身就是一种情绪出口。
最有意思的观察来自一条评论：真正的管道是，写博客本身变成了职业，而调试永远不会停止。
这就是闭环。你的痛苦变成别人的解药，别人的关注变成你的机会，新的机会带来新的问题，新的问题产生新的内容。
所以下次当你对着屏幕骂街的时候，记得打开一个文档。你的抓狂时刻，是最好的写作素材。
这是一个让人意想不到的时刻：AI模型写代码的速度已经比我快上一千倍，但用浏览器上网却比我慢十倍。
它能从零开始写出一个编译器，却在网页面前显得手足无措，仿佛第一次接触互联网。
这种能力上的巨大反差，揭示了一个被忽视的真相。
代码是逻辑的纯文本表达，规则清晰，边界明确。网页则是为人类眼睛设计的视觉迷宫，充满了按钮、表单、弹窗和广告。AI目前处理网页的方式是不断截图、分析、再截图、再行动，这种“看一步走一步”的笨拙方式，效率自然高不到哪里去。
更深层的瓶颈在于：网页庞大且碎片化，跨页面没有共享记忆状态。模型每次都要从头理解整个页面结构，就像一个失忆的人在陌生城市里反复认路。
有人开始尝试解决这个问题。比如构建互联网的共享状态地图，让AI拥有跨页面的连贯记忆。也有人认为，让AI通过API直接获取数据，比逼它模仿人类点击鼠标要靠谱得多。
毕竟浏览器从来不是为AI设计的。
最核心的洞见来自一位开发者的观察：代码生成的速度已经解决了，但代码生成与可靠执行之间的协调层，才是真正的瓶颈。我们还没解决协作问题。
这种能力的错位创造了一个诡异的“生产力倒挂”现象。开发者现在花在调试浏览器奇奇怪怪的问题和研究API文档上的时间，反而比写核心逻辑还多。AI能重构整个代码库，却点不对一个按钮。
还有开发者提到，AI写的代码会制造出一种“外星Bug”，那些沉默失败的错误，比显而易见的功能性Bug更难捉摸。
值得思考的是，这种局面可能只是过渡期的短暂现象。
当AI需要像人类一样去“看”界面、点按钮、填表单，这本身就是一种错配。未来的方向大概率是AI通过专门的协议与系统直接对话，数据以AI能理解的格式呈现，而非困在人类界面的像素迷宫里。
那个不需要打开浏览器窗口、一切自动化操作都在后台悄然发生的时代，可能比我们想象的更近。
浏览器，正在成为新时代的瓶颈。
“如果你曾使用 Rust 构建过任何 Web 应用（或任何需要通过网络与其他服务通信的应用），那么你很可能已经接触过 async/await 语法。你也可能不得不安装一个异步运行时（极大概率是 tokio）。
大多数情况下，像 tokio 这样的库都能很好地“隐身”于幕后：你只需在 main 函数上加上一个 [tokio::main]，并用 tokio::net::TcpListener 替代 std::net::TcpListener，你的服务器便神奇地能够使用仅少数几个线程处理成千上万的并发 TCP 连接。
但这背后究竟发生了什么？tokio 文档中的“深入异步”部分很好地解释了 Rust 标准库提供的各种异步 trait 和辅助结构体，以及 tokio 是如何实现它们的。阅读后，你会对执行器（executor）、任务（task）、唤醒器（waker）和未来对象（future）等概念有所了解。但在其示例中，你仍然只是启动一个线程休眠若干秒，然后使用另一个 crate 中的神奇 ArcWaker trait 来调度你的任务。
这些年来，我多次阅读过这些文档，也一直是异步 Rust 的满意用户。我读过大量文章，使用过许多库，编写过大量异步代码。但为了真正理解像 tokio 这类运行时背后的设计决策与权衡（例如，Send + 'static 的 future 确实令人烦恼——一个纯粹单线程的运行时会是什么样子？），我决定自己动手为 Rust 构建一个异步运行时，且不依赖任何外部库（好吧，严格来说有两个：我使用 rustix 来绑定所需的 POSIX API，当然还有标准 Rust 库）。它体积小、粗糙，可能在某些关键方面存在微妙的错误，除了教学用途外几乎毫无实用价值，但它让我对 Rust 的异步运行时有了深刻的理解。
在接下来的文章中，我将逐步讲解这个运行时的功能以及各个组件如何协同工作，并在最后分享我对整个实践过程的一些思考。”
“我一直对大量深入探究软硬件底层细节的开源项目非常着迷，比如《乐高岛》反编译项目，尤其是Xbox 360的“Bad Update”漏洞，以及随之而来的进一步努力，为Xbox 360（某种程度上的）软破解打开了大门（向我的兄弟InvoxiPlayGames致敬！）。这些项目背后所展现出的热情与驱动力，始终令我钦佩不已，我也一直渴望能以某种方式参与其中。但问题在于，尽管多年来我一直在使用C#、Golang以及JavaScript/TypeScript等语言编写各种代码，却缺乏对底层计算原理的扎实理解，也不太会使用C和C++这类低级语言。因此，我决定通过我认为最佳的方式来学习：亲手实践一个需要这些技能的小型项目。
基于这一思路，我决定选择制作一个模拟器作为项目的最终成果。这不仅是一个能持续激励我的目标，还能让我在过程中学习底层计算知识，同时开始掌握C++的使用。在我看来，这简直是一举两得！我最终选定原始Game Boy作为模拟对象，不仅因为它的技术文档极其完善（相较于许多其他游戏机而言），更因为它在硬件模拟难度上远比其他主机要简单得多。”
谷歌研究院最近公布了一项名为Sequential Attention的技术，目标直指AI领域的核心难题：如何在不牺牲准确性的前提下，让模型变得更精简、更高效。
这项技术要解决的问题本质上是"子集选择"，听起来抽象，但它几乎贯穿了深度学习优化的方方面面。特征选择是选子集，权重剪枝是选子集，嵌入维度调优也是选子集。问题在于，这类问题属于NP难问题，意味着当数据规模变大时，想要找到完美解几乎不可能。
传统的贪婪选择方法虽然有效，但代价极高，每一步都需要重新训练或评估模型。Sequential Attention的聪明之处在于，它把选择过程直接嵌入到模型训练中，用注意力权重作为重要性的代理指标。每一步选出注意力得分最高的候选项，然后重新计算剩余项的权重。这种方式天然能识别冗余，因为已选特征的存在会改变其他特征的边际贡献。
与传统的"一次性"注意力机制相比，Sequential Attention采用序列化决策。这个设计看似简单，实则抓住了问题的要害：特征之间存在复杂的非线性交互，单独看某个特征可能毫无价值，但与其他特征组合后却至关重要。反过来也成立，孤立看很重要的特征，放到整体中可能完全冗余。序列化选择让算法能够适应之前的决策，这是高质量排序的关键。
在实际应用中，这项技术已经展现出不俗的表现。在神经网络基准测试中达到了最先进水平，在结构化剪枝任务中，升级版的SequentialAttention++在ImageNet分类等任务上实现了显著的模型压缩，同时保持了准确性。
值得注意的是，当Sequential Attention应用于简单线性回归时，它在数学上等价于经典的正交匹配追踪算法。这个等价性很重要，因为后者有可证明的可靠性保证，这为Sequential Attention提供了理论根基。
谷歌列出了几个未来方向：大语言模型剪枝、推荐系统中的特征工程优化、以及药物发现和基因组学领域的应用。特别是LLM剪枝，通过这个框架可以实现结构化稀疏，剪掉冗余的注意力头、嵌入维度甚至整个transformer块。
社区对此反应不一。有人指出相关论文早在2022年就发表了，质疑这是否算"新"技术。但核心论文提出的是数学概念，最新进展在于将其成功应用于现代AI硬件和大模型场景。也有人担心这种方法对LLM是否实用，因为序列化注意力计算可能带来速度问题。
一个清醒的认识是：谷歌所说的"不牺牲准确性"指的是测试表现相当，并非像Flash Attention那样计算结果完全一致。这中间是否存在未知的权衡，还需要更多验证。
模型效率优化正在成为AI发展的关键战场。当模型规模持续膨胀，如何用更少的资源达到同样的效果，决定了AI技术能否真正普及。Sequential Attention提供了一个有理论支撑、有实践验证的思路，至于它能走多远，还要看后续在开源社区和实际部署中的表现。
本以为会得到一堆废话，结果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输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。
还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。
