夜雨聆风如果你最近关注 AI 工具，可能会注意到一件挺有意思的事。
不管是帮你做调研的、帮你写报告的、帮你操作电脑的，还是帮你搭网站的 AI 助手——去翻翻它们的"简历"，你会发现一个共同点：它们几乎都有一段"给程序员打工"的从业经历。
GitHub Copilot、Cursor、Claude Code，这些是直接帮程序员写代码的。Devin 号称"AI 软件工程师"，能自己规划任务、写代码、跑测试。国内的字节跳动做了 Trae，阿里做了通义灵码，腾讯做了 CodeBuddy——清一色，也是先给程序员用的。
然后，这些工具的能力开始"外溢"。
Manus 可以帮你写研究报告、做数据图表、搭建网站，但你拆开它的引擎看看，核心还是在写代码、跑代码、操作浏览器。智谱的 AutoGLM 能帮你操作电脑——在飞书、微信、浏览器之间跳来跳去干活，本质上，还是把你的操作"翻译"成了一套指令去执行。
为什么会这样？为什么 AI Agent 这条路，偏偏先从编程开始跑通了？
这背后有三个层层递进的原因。
第一层：编程是 AI 最完美的"练手场"
要理解这件事，得先想一个问题：AI 怎么知道自己做得对不对？
这个问题听起来简单，但其实是 AI Agent 能不能真正"干活"的核心瓶颈。
想想看，让 AI 帮你写一篇营销文案，写完了，好不好？见仁见智，同事觉得挺好，老板却觉得不够"高端大气上档次"，没有一个客观标准。AI 写完之后，它自己也不知道该不该改、往哪个方向改。
再比如，让 AI 帮你做一份市场分析。结论对不对？数据有没有看错？逻辑链条有没有漏洞？这些都得靠人来核查，AI 自己很难判断。
但写代码就完全不一样了。
代码写完，编译一下，要么通过，要么报错。跑个测试，要么通过，要么失败。错误信息还会精确地告诉你第几行出了什么问题。这种反馈是即时的、自动的、二元的。对就是对，错就是错，没有模棱两可的空间。
这意味着 AI 可以在编程领域形成一个完美的自我改进循环：写代码 → 跑一下 → 看结果 → 哪里报错改哪里 → 再跑一下 → 直到全部通过。整个过程完全不需要人介入，AI 自己就能把活儿闭环干完。
而且，编程世界还自带一整套用了几十年的"基础设施"，编译器、测试框架、代码版本管理、命令行工具……这些不是 AI 时代才发明的，是几代程序员积累下来的。AI Agent 来了直接用就行，不需要从零搭建什么新的评估体系。
打个比方：这就像学开车得先去驾校。驾校有封闭的场地、有明确的交规、犯了错也不会出人命。编程环境就是 AI 的"驾校"——规则清晰、反馈即时、犯错成本低。
所以，不是因为编程比其他工作更重要，而是因为编程这个领域的结构，恰好最适合 AI 练出"干活"的能力。
第二层：造 AI 的人，就是程序员
光有第一层原因，我们可能只会看到一堆编程领域的"技术验证项目"，不一定能形成今天这么大的市场。
真正让编程 Agent 迅速起飞的，还有一个更朴素的原因：造 AI 的人，本身就是程序员。
这是人之常情。厨师发明了一口新锅，第一个拿来试菜的肯定是自己。裁缝改良了一种新面料，第一件衣服肯定先给自己做。同样的道理，程序员研发出了强大的语言模型，第一个想到的应用场景，自然是"它能不能帮我写代码？"
这不是什么深思熟虑的战略决策，而是一种本能：我最了解自己工作中的痛点，我手头就有数据和场景可以测试，那我先拿自己的活来试试。
GitHub Copilot 的诞生就是这个逻辑。微软旗下的 GitHub 和 OpenAI 合作，用海量的开源代码训练模型，这些代码本来就躺在 GitHub 的服务器上，然后做成工具，先给自家平台上的几千万开发者用。天时、地利、人和，全齐了。
国内也是同样的路径。字节跳动的程序员们先在内部用上了 AI 编程助手 MarsCode，用着顺手、迭代改进后推出了面向外部开发者的 Trae。阿里的通义灵码也是从内部研发工具孵化出来的，先解决自家工程师的需求，再推向市场。
结果就是，程序员成了 AI Agent 最早、最密集的试用者和反馈者。到 2025 年，开发者群体中超过 85% 已经在使用某种 AI 编程工具。GitHub Copilot 一家就积累了超过 2000 万用户，财富 100 强企业中 90% 已经部署了它。
这种普及速度，在 AI 应用的其他领域很难想象。
第三层：你的电脑工作，本质上也是"编程"
前两层解释了"为什么 AI Agent 的能力先在编程领域练出来了"。但真正有意思的问题其实是下一个。
为什么这些编程 Agent 的能力，能这么快地扩散到非编程领域？
答案可能会让你有点意外：因为大量白领在电脑前做的工作，本质上就是一种"编程"。只不过我们平时不这么叫它。
仔细想想：
你在 Excel 里写 VLOOKUP 公式，设筛选条件，做数据透视表。这个过程是什么？你在用一种特定的语法，对数据下达处理指令，让机器按你的规则输出结果。这不就是编程吗？
你在公司 OA 系统里提交审批、流转单据、按固定流程录入数据。这些动作是什么？一系列"如果……那么……"的条件判断和顺序操作。这不就是在手动执行一段脚本吗？
你用 Figma 做设计，设定间距参数、定义可复用组件、配置响应式约束。这本身就是一种可视化编程。
甚至你每天最机械的那些操作，打开浏览器、登录后台、从一个系统里复制数据粘贴到另一个系统——这些东西，传统的 RPA（机器人流程自动化）十年前就开始用脚本来模拟了。所谓 RPA，就是用程序去自动执行人的鼠标点击和键盘输入，它本身就是编程。
所谓"操作电脑"，本质上就是在执行一系列可以被形式化描述的指令序列。而这，恰恰就是"编程"最广义的定义。
理解了这一点，你就能理解为什么那些编程 Agent 能这么快地"变身"成通用助手。
Manus 能帮你做市场调研、生成数据图表、搭建网站。拆开它看，执行引擎核心就三件事：写代码、跑代码、操作浏览器。它不是在"理解你的工作"，而是在把你的工作翻译成编程任务，然后用它最擅长的方式去执行。
智谱的 AutoGLM 能在电脑上自动操作，在飞书、微信、浏览器之间跳来跳去干活。它做的事情，本质上就是把你的鼠标点击和键盘操作翻译成一套指令序列去执行。
这些工具之所以能从"编程助手"进化成"通用助手"，不是因为它们突然学会了新技能，而是因为它们发现了：你在电脑前做的绝大多数工作，都能被"翻译"成编程任务。
而编程任务，恰好是它们最擅长的。
回头看，整个逻辑链条其实很清晰：
编程领域有即时反馈和成熟工具链，是 AI 练出"干活"能力的天然试验场。造 AI 的又恰好是程序员，他们本能地先拿自己的活开刀。而当编程 Agent 的能力足够强之后，它们发现了一条通往所有人的路,大量白领的电脑工作，本质上都可以被翻译成编程任务。
这就是我们今天看到的局面：AI 助手正在从程序员的专属工具，变成每个人的电脑助手。这个过程不是"从编程领域跨界到其他领域"，而是"发现其他领域的工作，本来就可以用编程的方式来完成"。
所以，下次当你看到一个新的 AI 助手工具，不管它说自己能帮你做调研、写方案、还是管理日程，可以去看看它的底层。大概率，它的基本功还是那三件事：能写代码、能跑代码、能操作电脑。
这三样，就是今天 AI Agent 行走江湖最核心的武艺。
而它们，全都是从"给程序员打工"那一个阶段练出来的。
