最近越来越多人喜欢用一个词来形容 AI 带来的变化：superpowers。
这个词很容易让人误解。因为一说“超能力”，很多人脑子里浮现出来的，还是那种很抓眼球的画面：一句提示词生成一个页面、几分钟写完一个脚本、十分钟做完一份 PPT、张口就给出一套看上去很完整的方案。
这些当然很惊艳，但如果只把 superpowers 理解成“原来 AI 能一下子帮我多干很多活”，那其实还是低估了这件事。
我现在越来越倾向于把它理解成另一层意思：
AI 时代真正的超能力，不是单次产出的魔术感，而是你能不能把模型能力稳定接进自己的判断、工作流和交付系统里。
这两者表面看起来都在用 AI，本质上却完全不是一回事。
最近看到一篇很长的文章，主题是 Harness 最佳实践：在 Java Spring Boot 项目中落地 OpenSpec + Claude Code。看完之后，我觉得它最有价值的地方，不是又介绍了一个“新概念”，而是把一件很多团队已经隐约意识到、但还没系统化表达的事情讲清楚了：
AI 真正要进入生产研发流程，重点从来不是“它能不能多写点代码”，而是“它能不能在边界内、按流程、可审计地工作”。
这也是我对 Harness 这个词最直白的理解：不是让 AI 更自由，而是让 AI 在工程规则里稳定工作。
这两年，关于”AI 会不会取代程序员”的讨论几乎已经被说烂了。每隔一段时间，总会有人抛出一个更刺激的判断：程序员将被大规模替代，写代码会像流水线一样被模型接管，未来只需要少数人发号施令，大多数人都会被清理出场。
这种说法听起来很有冲击力，但我越来越觉得，它真正制造的不是洞见，而是情绪。因为它把一个复杂问题，粗暴地压缩成了一个耸动结论：AI 会写代码，所以程序员要完。
可问题是，程序员如果只是”写代码的人”，那这个职业从一开始就被理解错了。
代码从来都不是软件开发最难的部分。代码只是最后被看见的部分，是冰山露出水面的那一截。真正决定一个系统质量的，往往不是”这一段代码怎么写”，而是”为什么要写这段代码””它解决的到底是不是真问题””它和旧系统如何衔接””它的代价由谁承担””出事之后谁来收拾”。如果把程序员理解成一个高级打字员，那 AI 确实已经足够危险；但如果承认程序员的核心工作从来都包含理解、拆解、权衡、取舍和负责，那问题就完全不是一个层面了。
随着人工智能技术在代码生成、测试、部署和运维等领域的深入，开发者的工作方式正在发生深刻变化。本篇博客从实务角度出发，聚焦三大维度：协作流程、工具生态与技能要求，以及对代码质量与交付节奏的影响。
OpenClaw 是一个强大的 AI Agent 框架，可以将 AI 能力接入 WhatsApp、Telegram、Discord、Slack 等多种即时通讯平台。本文记录了从零开始安装和配置 OpenClaw 的完整流程。
openclaw gateway — 运行 WebSocket 网关服务器openclaw gateway start|stop|restart — 管理网关服务openclaw channels login — WhatsApp 二维码配对openclaw channels add — 添加机器人openclaw channels status --probe — 渠道状态检测openclaw onboard — 交互式设置向导openclaw doctor — 健康检查 + 快速修复openclaw models list|set|status — 模型管理 + 认证状态
在职场中呆久了，接触到不同的人，他们的做事风格各异，这种风格可能和性格，环境以及过往经验有关。
这些做事风格在处理事情上无论是过程还是结果都可能千差万别。我总结大概有两种类型，一种是对上管理型，一种是处理问题型。
虽然对上管理型最终也是要解决问题的，但是他是面向上级解决问题，在解决问题的时候不太会思考怎么解决问题，而在意的是解决问题的结果。这种可能问题最终是被解决了，但是可能不是最佳方式，可能是临时解决，基于这种对上解决问题的方式也注定他在处理问题时不会考虑相对长远的事情，属于领导发现问题解决问题，再发现再解决。这种方式可能比较高效，但是对组织是否有益可能不一定。问题如果都是单点式的处理，就不能形成问题-解决-总结-经验-避免下次再出现的闭环。导致的结果是，可能相同的问题重复出现。
处理问题型其实也就是面向问题解决问题，有可能领导发现的是A问题，但是分析下来其实A是由于BCD问题导致的，其实你可以只解决A，领导的问题被解决了，但是BCD还在那里。因为这种处理问题的方式你会思考问题本身，所以你会总结经验，因为很多问题有相似性。这种方式相对处理问题会低效，但是可能对组织的长远发展是有易的。前期问题比较多，但是一旦处理好之后问题会越来越少，因为每一次的问题处理都是对一类问题的处理。