这两年，很多团队都已经把 AI 带进了软件开发流程里。但如果仔细看，大多数所谓的“落地”，其实还停留在很浅的一层：写代码时开着 Copilot，遇到问题时问一下大模型，写文档时让它先起个草稿。它当然有帮助，但这种帮助更像是把 AI 当成一个更聪明的搜索框，而不是把它真正纳入工程系统。

我越来越觉得，AI 工程化真正要解决的问题，不是“开发者会不会用 AI”，而是“传统软件开发流程能不能被系统性改造，让 AI 在每个关键环节都稳定提高效率”。

这两者的差别很大。前者偏个人技巧，谁会提 prompt，谁更熟悉某个工具，谁就能多拿一点收益；后者偏组织能力，它关注的是流程是否可复制、结果是否可追踪、风险是否可控制、效率提升是否能从个人扩展到团队。

最近看到一条帖子，主题很抓人：一个 Plus 账号不够用，一个 Pro 账号又经常闲着，于是用 CLIProxyAPI 把多个账号组成本地代理池给 Codex 用。

如果只看表面，这像是在讲一个“3 分钟就能搭起来”的小技巧；但我觉得它真正值得聊的，不是教程本身，而是它背后的工程思路：当模型入口越来越多、账号形态越来越杂时，真正有价值的事情，不是再开一个入口，而是把这些入口组织成一个稳定可控的能力层。

很多人会把“代理池”理解成简单轮询，甚至直接联想到“中转站”。但对个人开发者或者小团队来说，更实际的意义其实是：把分散、零碎、时好时坏的模型访问能力，重新收束成一个本地可控的统一出口。

看完这篇对比 OpenClaw 和 Hermes 的文章，我的结论很简单：如果你还在问“谁替代谁”，大概率是把它们放错了维度。

它们确实都属于通用 Agent，也都在做 Skills、Memory、聊天入口、工具调用这些事。但真正的区别，不在功能清单，而在系统的厚度长在哪一层：OpenClaw 更偏入口、控制面和真实世界接入；Hermes 更偏执行循环、经验沉淀和跨任务复用。

为什么它们看起来很像

表面上看，OpenClaw 和 Hermes 都能接聊天渠道、都能跑工具、都能保存记忆、都能通过技能扩展能力，所以很容易被当成“同类竞品”。

但这种比较方式有个问题：它只看到了“都能做什么”，没看到“主要在解决什么”。

对 Agent 系统来说，这两个问题不是一回事。一个系统可以把入口、消息路由、设备接入和权限治理做得很好，但不一定擅长把经验沉淀成可复用能力；另一个系统可以在长任务、技能复用和会话检索上做得很强，但不一定在多渠道接入和控制面上最顺手。

最近越来越多人喜欢用一个词来形容 AI 带来的变化：superpowers。

这个词很容易让人误解。因为一说“超能力”，很多人脑子里浮现出来的，还是那种很抓眼球的画面：一句提示词生成一个页面、几分钟写完一个脚本、十分钟做完一份 PPT、张口就给出一套看上去很完整的方案。

这些当然很惊艳，但如果只把 superpowers 理解成“原来 AI 能一下子帮我多干很多活”，那其实还是低估了这件事。

我现在越来越倾向于把它理解成另一层意思：

AI 时代真正的超能力，不是单次产出的魔术感，而是你能不能把模型能力稳定接进自己的判断、工作流和交付系统里。

这两者表面看起来都在用 AI，本质上却完全不是一回事。

最近看到一篇很长的文章，主题是 Harness 最佳实践：在 Java Spring Boot 项目中落地 OpenSpec + Claude Code。看完之后，我觉得它最有价值的地方，不是又介绍了一个“新概念”，而是把一件很多团队已经隐约意识到、但还没系统化表达的事情讲清楚了：

AI 真正要进入生产研发流程，重点从来不是“它能不能多写点代码”，而是“它能不能在边界内、按流程、可审计地工作”。

这也是我对 Harness 这个词最直白的理解：不是让 AI 更自由，而是让 AI 在工程规则里稳定工作。

如何使用 Skill：从理解概念到亲手做一个自己的 Skill

这两年，越来越多的 AI 工具开始支持“Skill”机制。很多人第一次看到这个词，会下意识把它理解成“插件”或者“扩展功能”。这么理解不算错，但还不够准确。

Vibe Coding：驾驭 AI 提升开发效率的艺术

在软件开发日新月异的 2026 年，Vibe Coding（意即“氛围编码”或“感觉编码”）正成为一股不可忽视的力量。它不仅仅是简单的代码补全，而是通过自然语言描述，让 AI 驱动开发流程，从而显著提升开发效率和创新能力。本文将深入探讨 Vibe Coding 的核心技巧与最佳实践，助您在 AI 辅助开发的浪潮中乘风破浪。

拥抱心流：Vibe Coding 的实战技巧

在快节奏的软件开发世界里，”Vibe Coding”，或者说拥抱心流（Flow State）进行编码，不仅仅是一种工作方式，更是一种提升效率、创造力和满足感的艺术。它指的是一种高度专注、全身心投入的编码状态，在这个状态下，时间仿佛静止，问题迎刃而解，代码如行云流水般自然生成。那么，如何才能更好地进入并维持这种”Vibe”呢？

这两年，关于”AI 会不会取代程序员”的讨论几乎已经被说烂了。每隔一段时间，总会有人抛出一个更刺激的判断：程序员将被大规模替代，写代码会像流水线一样被模型接管，未来只需要少数人发号施令，大多数人都会被清理出场。

这种说法听起来很有冲击力，但我越来越觉得，它真正制造的不是洞见，而是情绪。因为它把一个复杂问题，粗暴地压缩成了一个耸动结论：AI 会写代码，所以程序员要完。

可问题是，程序员如果只是”写代码的人”，那这个职业从一开始就被理解错了。

代码从来都不是软件开发最难的部分。代码只是最后被看见的部分，是冰山露出水面的那一截。真正决定一个系统质量的，往往不是”这一段代码怎么写”，而是”为什么要写这段代码””它解决的到底是不是真问题””它和旧系统如何衔接””它的代价由谁承担””出事之后谁来收拾”。如果把程序员理解成一个高级打字员，那 AI 确实已经足够危险；但如果承认程序员的核心工作从来都包含理解、拆解、权衡、取舍和负责，那问题就完全不是一个层面了。

随着人工智能技术在代码生成、测试、部署和运维等领域的深入，开发者的工作方式正在发生深刻变化。本篇博客从实务角度出发，聚焦三大维度：协作流程、工具生态与技能要求，以及对代码质量与交付节奏的影响。