不知道该写点啥
从春节假期回来上班，已经一个多月了，无论是生活还是工作上总觉得挺无聊的。工作上，每天做 Doris 的清道夫，干的都是脏活累活，也没啥成就感的反馈。生活上，最近游戏也不太想继续玩，书也有点看不下去，刷刷手机倒也挺快。感觉整个人都废了。
不过话说回来，最近带给我惊喜最大的应该就是 AI 的发展了。刚巧最近也读了不少 AI 相关的书籍，不如简单的聊聊 AI 吧。
（其实一直想写点 AI 相关的内容，但作为门外汉不知道写点啥，下面的内容主要来自于个人的主观使用体验，可能大部分都是废话，大家图一乐就行
Cursor 开启 Vibe Coding 的时代
第一次用 Cursor 是 2024 年 7 月，当时看很多 𝕏 友都在推，但电脑上已经有 VSCode 了，还要再装一个类似的玩意，从内心来说是比较抵触的，这东西真的有那么好用吗？抱着试一试的心态，还是安装了下。
由于是包了一层 VSCode，所以可以做到无缝迁移，配合 Claude 3.5 Sonnet 的超强理解能力，当时的第一感受是非常惊艳的。
但在聊 Cursor 之前，得先说说它的"前辈" GitHub Copilot，毕竟很多人的 AI 编程初体验都是从 Copilot 开始的。
从 Copilot 到 Cursor：不只是换了一个工具
Copilot 出现得更早，大概是 2022 年就已经可以用了。我也用过一段时间，体验上确实比纯手打强——你写一个函数签名，它猜出函数体；你写一行注释，它把后面的实现给你补全。但用久了会发现，Copilot 本质上是一个增强版的自动补全。它的工作模式是"你先动手，它来接话"，你得给它足够的上下文（前面几行代码、函数签名、注释），它才能猜到你想干嘛。
这意味着几个事情：
你必须先想清楚怎么写。 Copilot 无法帮你做设计决策。你得先把文件建好、把函数签名写出来、把数据结构定义好，然后它在这个骨架里帮你填充实现。如果你连"这个功能应该拆成几个函数"都还没想清楚，Copilot 帮不了你。
它只看得到当前文件。 早期的 Copilot 对跨文件上下文的理解非常有限。你在 A 文件里定义了一个类型，切到 B 文件写代码的时候，它不一定能把这个类型和相关的用法关联起来。你经常需要手动把相关代码复制过来当"提示"。
交互是单向的。 你写代码，它补全，你接受或者拒绝——没有对话，没有来回讨论。如果它补全的方向不对，你只能删掉重写前面几行，换一种方式"引导"它，有时候费的时间还不如自己写。
Cursor 彻底换了一种交互范式。它不是在你已有的代码上做补全，而是在对话框里和你沟通。你用自然语言描述想做什么——"帮我给这个 ProcessFunction 加一个处理延迟的 metrics 上报"、"把这段数据校验逻辑抽成一个独立的工具函数"——它理解你的意图后，直接生成或修改代码，甚至同时改动多个相关文件。
这个转变看似只是 UI 上的差异（从内联补全变成了对话框），但实际上是编程范式的升级：
- 从"你写它猜"到"你说它做"。 你不再需要先写出代码骨架来引导 AI，而是直接表达意图。这意味着即使你还没想清楚具体实现，也可以先把需求说出来，让 AI 给你一个起点。
- 从单文件到项目级上下文。 Cursor 可以索引整个项目，理解文件之间的依赖关系。你说"重构这个函数"，它知道哪些地方引用了这个函数，会一起改。
- 从单次补全到多轮对话。 生成的代码不满意？你可以说"这里改成用 Builder 模式"、"错误处理再完善一下，要覆盖超时和重试的场景"——像和一个人讨论一样迭代优化。
后来知道 Andrej Karpathy 给这种方式起了个名字叫 Vibe Coding——不再逐行推敲代码，而是描述意图，让 AI 去实现，你只管感受（vibe）结果对不对。说得有点玄乎，但确实挺贴切的。
站在 2024 年中的时间点来看，Cursor 的出现让我第一次觉得 AI 编程工具从"锦上添花"变成了"真的能改变工作方式"。所以很自然地，Copilot 被我冷落了，Cursor 成了主力。
从 2024 年 7 月到 2025 年 6 月，差不多整整一年，Cursor 一直是我的主力开发工具。用了一年之后，逐渐摸清了它的能力边界——什么场景下如鱼得水，什么场景下力不从心。
一年下来，边界在哪？
Cursor 好用的场景不难总结：规则清晰、范围局部、不需要长期维护的工作。写 Doris 运维脚本、给 Rust struct 按照现有模式补 trait 实现、临时搞一段日志分析脚本——这类活描述清楚需求后基本一次成型，省下来的时间是实实在在的。
但用了一年之后，我越来越清楚它的天花板在哪。本质上是两条边界：
第一条边界：局部 vs 全局。 Cursor 的所有能力都建立在"看当前上下文"这个前提上。单个文件内的改动，它得心应手；但一旦改动涉及多个模块、层层依赖，它就开始失控——改完上游不知道下游的接口也要同步，你得反复"喂"上下文、提醒关联改动。代码质量问题也是同一个根因：它每次给的建议都是"局部最优"，但缺乏对项目整体一致性的感知——命名风格、错误处理策略、抽象层次，它一概不管。时间一长，代码不知不觉就积累出一种"拼凑感"。
第二条边界：文本 vs 语义。 Cursor 看的是代码文本，不理解程序的运行时行为。它能帮你读报错信息、建议一个 fix，但涉及到"为什么会走到这个状态"——并发竞态、生命周期管理、跨语言调用链——这类需要理解程序真实执行逻辑的问题，光看源码文本是解决不了的。换句话说，Cursor 能回答"这段代码怎么改"，但回答不了"这段代码为什么会出问题"。
用一句话概括：Cursor 是一个极其强大的局部代码生成工具，但它不是你的结对伙伴。 它能帮你加速执行，但架构判断、质量把控、深度排查这些事情，仍然得靠你自己。
从 Cursor 到 Agent：当 AI 学会自己干活
如果说 Cursor 让我体验到了"AI 辅助编程"，那 2025 年开始出现的一波工具，则让我看到了另一种可能：AI 不再辅助你编程，而是自己编程。
Claude Code：跳出 IDE 的 Agent
2025 年中，Anthropic 发布了 Claude Code。第一次用的时候，最大的感受不是"它写代码更好了"，而是交互方式彻底变了。
Cursor 再怎么强，本质上还是一个 IDE 插件——你在编辑器里打开文件，告诉它改哪里，它帮你改。你是司机，它是导航。但 Claude Code 不一样：它直接运行在终端里，你给它一个任务描述，它自己去读代码、理解项目结构、规划改动方案、修改多个文件、跑测试验证——整个过程你只需要在旁边看着，偶尔确认一下方向。
用了一段时间后我越来越觉得，跳出 IDE 做 Agent 这个选择本身就是对的。IDE 看起来提供了丰富的上下文（打开的文件、选中的代码、侧边栏面板），但对 Agent 来说这些反而是噪音——它需要的是干净的、和任务直接相关的上下文，而不是你碰巧打开了哪些 Tab。CLI 天然做到了这一点。而且 CLI 可以在任何环境里跑——本地终端、远程服务器、Docker 容器、CI/CD 流水线——这意味着 Agent 不再被绑在你的桌面上。当编程的主要方式从"人写代码"变成"人指挥 Agent 写代码"，一个干净的命令行入口比一个功能繁多的 IDE 界面更合理。
这意味着 Cursor 的两条边界，Claude Code 都在尝试突破：
局部 vs 全局？ Claude Code 可以自己遍历项目目录结构、读取相关文件、理解模块之间的依赖关系，然后一次性改动多个文件。你不再需要一个文件一个文件地"喂"上下文——它会自己去找上下文。
文本 vs 语义？ Claude Code 可以执行命令。它能跑 cargo test 看测试结果、跑 grep 搜索引用、甚至启动服务验证行为。虽然它仍然不真正"理解"运行时，但通过 "改代码 → 执行 → 看结果 → 再改" 这个循环，它可以逼近语义层面的正确性。
当然，Claude Code 远不是完美的。它对大型项目的理解仍然有上限，长任务容易"跑偏"，有时候会自信满满地做出一堆错误改动。但它代表的方向是清晰的：AI 编程工具正在从"辅助"走向"自主"，从"你指挥它干活"走向"你描述目标它自己搞定"。
Codex：另一种思路
差不多同一时期，OpenAI 推出了 Codex。目标和 Claude Code 一样——让 AI 自主完成编程任务。但两者的做法和强项截然不同。下面是我的主观感受，不一定对：
Claude Code 赢在 Agent 能力。 它的工具链打磨得很好：读文件、改代码、跑命令、理解报错、自我修正——整个流程串起来非常流畅。配合 Opus 4.6 本身极强的编码理解力，Claude Code 在处理复杂的、需要多步推理的编程任务上，体验是目前最好的。它更像是一个能力很强、还会主动思考的结对伙伴——你给它一个模糊的目标，它能自己拆解成步骤、逐步执行、遇到问题自己调整。
Codex 赢在模型底座。 说实话，Codex 的 Agent 生态做得一般——工具调用的流畅度、任务编排的能力，和 Claude Code 比还有差距。但它背后的 GPT-5.4 模型能力太强了：理解代码的准确性、生成方案的质量、处理不熟悉的技术栈时的泛化能力——单论"给你一段代码"这件事，GPT-5.4 已经是我日常工作的首选了。它更像是一个知识面极广的顾问——你问它问题，它几乎总能给出高质量的回答，但让它自己动手从头到尾完成一个任务，就没有 Claude Code 那么顺畅。
这两者的差异其实反映了 AI 编程工具竞争的两个维度：Agent 能力（工具链、任务编排、自主执行）和模型能力（理解力、生成质量、泛化性）。理想情况当然是两者兼得，但目前还没有。所以我的用法是：需要自主完成复杂改动用 Claude Code，日常查问题、讨论方案、生成代码片段用 GPT-5.4。两条腿走路。
不管哪种工具占上风，有一点是确定的：Agent 化是 AI 编程工具的必然方向。 不是某一家公司的选择，而是整个行业正在收敛到这个范式。
用多了之后还有一个感受：Codex 的异步模式正在悄悄改变工程师的工作方式。你会发现自己越来越少直接写代码，而是花更多时间为 Agent 搭脚手架——定义架构约束、构建工具链、编写验收标准。当 Agent 做得不好的时候，你反思的不是"这段代码该怎么改"，而是"我是不是哪条规则没交代清楚"。纪律依然重要，但体现在脚手架和规则上，而不是代码本身。
MCP：协议层的野心
2025 年另一个出圈的概念是 MCP（Model Context Protocol）——定义一套标准协议，让 AI 模型可以和外部工具（数据库、API、文件系统、CI/CD 等）统一交互。社区里一时热情高涨，各种 MCP Server 实现涌现。但说实话，我对 MCP 持保留态度。
原因在于："AI 如何与外部系统交互"本质上是一个集成问题，而不是一个协议问题。每个团队的基础设施、工作流、安全策略都不一样，想用一套统一协议适配所有场景，最终要么极度复杂，要么只能覆盖最简单的情况。历史上类似的尝试（SOAP、GraphQL Federation）都没有取代定制化集成。MCP 也许会成为一个有用的基础层，但远不会是很多人期望的"AI 时代的 HTTP"。
Skills：教 AI "你的规矩"
相比 MCP 的宏大叙事，我反而更看好一个不那么起眼的趋势：Skills（或者叫 Rules / AGENTS.md）。
最常见的误解是觉得 Skills "不就是一个 markdown 文件吗"。其实不是。Skills 是一个文件夹——里面可以包含说明文档、脚本、参考代码、模板、配置，甚至数据文件。AI 在执行任务的时候会主动去发现和使用这些资源。它的本质是：不是给 AI 更多能力，而是教它如何在你的项目里做事。
用了一段时间之后，有几条心得体会：
不要说废话，只写"打破 AI 默认行为"的信息。 AI 对编程本身已经很懂了，你不需要教它怎么写循环。真正有价值的是那些它猜不到的东西：你的项目有哪些特殊约定？哪些看似合理的做法在你这里会踩坑？哪些依赖库有隐藏的边界条件？Skills 里信息量最大的部分，往往是一个踩坑点（gotchas）清单——记录 AI 反复犯错的地方，每次发现新的就补进去。
渐进式披露，而不是信息轰炸。 把所有信息塞进一个大文件里是低效的——AI 的上下文窗口是有限的。更好的做法是利用文件夹结构做分层：主文件只放概要和导航，详细的 API 签名放到 references/ 目录，代码模板放到 templates/ 目录。AI 需要的时候会自己去读，不需要的时候不浪费上下文。
不要把 AI 限制得太死。 这条最反直觉。很多人写 Skills 的第一反应是事无巨细地规定每一步该怎么做，但这反而会让 AI 变得僵硬——遇到稍微不同的情况就不知道变通。更好的方式是告诉它约束和目标，把具体实现留给它判断。就像管理一个有经验的工程师：你说清楚需求边界和质量标准，但不需要规定他用哪个变量名。
这个东西看起来朴素，但它恰好解决了 Cursor 时代最让我头疼的问题——代码一致性。还记得前面说的"拼凑感"吗？Skills 就是对症下药：与其让 AI 每次猜你的风格，不如直接告诉它。而且 Skills 的覆盖面远不止代码风格——从 API 参考、测试策略、部署流程到运维手册，团队积累的一切工程知识都可以沉淀成 Skills。
往大了说，Skills 正在成为一种新形态的工程知识管理。以前团队的经验沉淀在 wiki 里（没人看）、口口相传（容易丢失）、或者靠 code review 慢慢传递。现在这些知识直接变成了 AI 的工作指令——每次执行都会自动遵守，新人入职不需要"老人带"，AI 自己就按规矩来。
从 Cursor 到 Claude Code，再到 Skills，AI 编程工具的演进路径其实很清晰：先让 AI 能写代码（Copilot/Cursor）→ 再让 AI 能自主完成任务（Claude Code/Codex）→ 最后让 AI 能按照你的方式做事（Skills）。 每一步都在缩小"AI 的输出"和"你真正想要的东西"之间的差距。
OpenClaw 全民养龙虾的癫狂
2026 年初的社交媒体上有一段时间非常魔幻：满屏都是人在晒自己的"龙虾"——OpenClaw。有人比谁的龙虾更聪明，有人分享龙虾的"日常生活"，有人甚至给龙虾起名字、建社群、搞排行榜。那段时间刷 𝕏 有一种很强的 FOMO 感：好像全世界都在养龙虾，你不养就落伍了。
OpenClaw 的设计理念——给 Agent 本地执行权限、用 CLI 工具扩展能力——和前面聊的 Claude Code、Codex 是一脉相承的，不再赘述。它的贡献在于把这些理念包装成了极低门槛的项目，让不写代码的人也能拥有私人 Agent。没有 OpenClaw 也会有别的项目出来，但它恰好踩中了时间窗口。
真正让我不舒服的是"养龙虾"这股热潮本身。
社群的狂热程度有点邪教的味道：给龙虾设定"人格"、让龙虾在社群里发言、比谁的龙虾"更有灵性"。这已经不是在使用工具了，更像是一种身份投射——人们把 Agent 当成了虚拟宠物甚至社交替身。当讨论从"怎么让 Agent 解决实际问题"变成"怎么让我的龙虾更有个性"，方向就歪了。
Token 浪费也是一个值得说的问题。一个 Agent 长期"随便聊天"、"巡逻"文件系统、定时发"心情汇报"——每次交互都在消耗 token。个人层面是在烧订阅额度，系统层面当几万人同时在做这件事，就是对算力资源的浪费。AI 算力远未过剩的今天，把 token 花在"让龙虾讲笑话"上，多少有点荒诞。
回归冷静
啰里八唆扯了一堆，谈谈最近一些看法吧。三月是 Coding Agent 折腾比较多的一个月。尝试了 Codex，Claude Code，还有为了追求量大管饱在 Antigravity 使用 Opus4.6。再到最近的大面积封号，国内的中转站也基本凉了。OpenAI 成功融资之后，Codex 想低成本用上可能会一去不复返了。还有就是有些 Coding 工具用的比较早，但是初体验一般也就没有继续在用，比如 Copilot 和 OpenCode 这类。跟随着大环境的趋势，应该也是变得比较好用了起来的，毕竟身边有同事还在用。不过从我的观点来说，人类的贪念是无止尽的，不会仅仅满足于“够用”，更想要的是“好用”。
但真正让我慢下来的，不是工具的起起落落，而是 token。
之前 token 用不完的时候，人反而像被 AI 鞭打的机器——有想法就去做，做了也不一定有用，一堆 AI 生产的代码懒得维护，最后不了了之。token 变少之后，反而慢了下来。慢下来才有机会想清楚，什么是真正值得做的。
这是一个好时代吗？某种意义上是的。AI 极大地降低了学习和创造的门槛——以前需要花几个月啃下来的技术栈，现在借助 AI 可能几天就能上手出活。但硬币的另一面是，门槛降低带来的不只是效率，还有浮躁。 很多人用 AI 生成了一堆"看起来像那么回事"的内容——博客、教程、开源项目、技术分享——但仔细一看全是似是而非的东西。AI 在生产内容这件事上太高效了，以至于互联网上的信噪比正在急剧恶化。你花时间去读一篇文章、看一段代码，最后发现它只是 AI 的产物、完全经不起推敲——这种体验越来越频繁。当"生产内容"变得几乎零成本，"辨别内容"反而成了最稀缺的能力。
折腾了这么多 AI 工具之后，我越来越清楚一件事：AI 放大的是你已有的能力，而不是凭空给你能力。 你得先知道该做什么、做到什么程度、什么是好的什么是烂的——AI 才能帮你加速。如果你自己都没想清楚，AI 只会帮你更快地走向错误的方向。
机器跑得再快，方向盘还是得在自己手里。