最近看到一篇很长的文章，主题是 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 辅助开发的浪潮中乘风破浪。

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

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

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

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

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

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

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

OpenClaw 是一个强大的 AI Agent 框架，可以将 AI 能力接入 WhatsApp、Telegram、Discord、Slack 等多种即时通讯平台。本文记录了从零开始安装和配置 OpenClaw 的完整流程。

🔍 文档内容摘要

核心 CLI 命令

• 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还在那里。因为这种处理问题的方式你会思考问题本身，所以你会总结经验，因为很多问题有相似性。这种方式相对处理问题会低效，但是可能对组织的长远发展是有易的。前期问题比较多，但是一旦处理好之后问题会越来越少，因为每一次的问题处理都是对一类问题的处理。

review代码的时候看到一个副作用，有点忘记原理了，就问了下AI，我觉得它回答的非常好，记录一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

LaunchedEffect(boValue, countDownTime) {
        if (countDownTime == CountDownState.Finished.times) {
            navigator.navigate(BOExceptionDestination()){
                popUpTo(BOWornDetectionDestination.route) {
                    inclusive = true
                }
            }

        }
        if (boValue > 0) {
            navigator.navigate(BOResultDestination(boValue.toInt())){
                popUpTo(BOWornDetectionDestination.route) {
                    inclusive = true
                }}
        }
    }

提问：不太明白这个副作用函数的运行机制，你上面说它会开启一个协程来执行内部代码，但是又会监听LaunchedEffect中的key值，这个是怎么做到的？另外，如果key值变化了，主线程中正在执行的代码会怎么样？请作为Android资深工程师用浅显易懂的方式给我讲清楚。

AI回答：
现在我们把上面的比喻套在你的代码上：

LaunchedEffect(boValue, countDownTime) { … }

1. 首次运行：

• 你的界面第一次显示时，boValue 可能是 0，countDownTime 是 30。
• LaunchedEffect 记录下 (key1=0, key2=30)，并启动一个协程来执行 {} 里的代码。
• 这个协程现在开始运行，它会检查 if 条件，发现都不满足，然后就“挂起” (suspend)，等待下一次 key 的变化。

2. 当 countDownTime 变化时：
   • 1秒后，countDownTime 变成了 29。这导致了界面重组 (Recomposition)。
   • 在重组过程中，LaunchedEffect 会再次被执行。它对比新旧 key：
     • 旧 key: (boValue=0, countDownTime=30)
     • 新 key: (boValue=0, countDownTime=29)◦它发现 countDownTime 变了！于是：
     • 立即取消上一个 countDownTime=30 时启动的协程。
     • 启动一个全新的协程，并记录下新的 key (0, 29)。这个新协程又从头开始执行 {} 里的逻辑。这个过程会每秒重复一次。
3. 如果 boValue 突然变化了：

• 假设在倒计时到 25 秒时，血氧传感器返回了数据，boValue 从 0 变成了 98。
• 界面再次重组。LaunchedEffect 对比 key：
  • 旧 key: (boValue=0, countDownTime=25)
  • 新 key: (boValue=98, countDownTime=25)
• 它发现 boValue 变了！于是：
  • 立即取消上一个 (0, 25) 的协程。
  • 启动一个全新的协程。这个新协程一进来就检查 if (boValue > 0)，条件满足，立刻执行 navigator.navigate(…) 进行页面跳转。任务完成！

关于主线程的问题

你还问到：“如果key值变化了，主线程中正在执行的代码会怎么样？”这是一个非常好的问题，涉及到协程的核心优势。

• LaunchedEffect 里的代码默认运行在主线程上，但它是可挂起 (suspendable) 的。
• 当协程执行到一个挂起点（比如 delay(1000) 或者其他需要等待的异步操作）时，它会释放主线程，但并不会销毁自己。主线程可以去干别的事，比如响应用户点击、刷新动画等，UI 不会被卡住。
• 当 key 变化时，是 Compose 框架在主线程的重组阶段发现了 key 的变化，然后它会向旧的协程发送一个取消信号。
• 正在运行的协程（无论它当前是真正在执行 CPU 指令，还是正处于挂起状态）收到取消信号后，会在下一个挂起点或检查点响应取消，并抛出 CancellationException 来终止自己。
• 这一切的取消和重启调度都是由 Compose 框架和 Kotlin 协程库在背后无缝完成的，不会阻塞主线程的正常工作。

总结

• 机制：LaunchedEffect 不是“边运行边监听”，而是在每次重组时，通过对比新旧 key 值来决定是否取消旧协程，启动新协程。
• 目的：确保副作用代码（比如网络请求、数据库操作、导航）始终与当前的 state (也就是 key) 保持同步。
• 线程：代码虽然在主线程协程中，但由于其“可挂起”的特性，不会阻塞 UI 渲染。它的生命周期管理是自动且安全的。