发表于 | 分类于
字数统计: 1.1k | 阅读时长 ≈ 3

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

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

什么是 Vibe Coding？

Vibe Coding 的精髓在于将开发者的核心精力从编写具体代码的过程，转移到对产品目标、架构设计和逻辑规划上。您不再需要逐行敲打 const express = require('express')，而是可以直接告诉 AI：“给我搭建一个包含用户认证和 PostgreSQL 数据库的 Express API。” AI 工具随后会生成实现这一功能的代码。研究表明，在 Vibe Coding 模式下，开发者约 70% 的时间投入在清晰地思考和规划要构建的内容，而 30% 的时间则用于审查、测试和优化 AI 生成的代码。

Vibe Coding 的核心技巧与最佳实践

  1. 明确目标，清晰构思：

    • “感觉”的起点：在开始 Vibe Coding 之前，最重要的一步是定义明确且具体的结果。您需要清晰构思您想构建什么，AI 才能准确“捕捉”到您的“vibe”。
    • 结构化输入：如果可能，使用结构化的方式描述您的需求。例如，明确指出所需的功能模块、技术栈偏好、数据模型、API 接口要求等。

  2. 分而治之：迭代式开发：

    • 小步快跑：不要试图一次性生成整个复杂的应用程序。将大型项目分解为小的、可管理的模块或功能，分批次地、迭代式地与 AI 协同完成。
    • 快速反馈：每次迭代后，及时审查 AI 生成的代码，进行必要的修改和测试。这种快速反馈循环是优化 AI 输出的关键。

  3. 提供高质量的上下文：

    • “给我一个 Express API” vs. “给我一个使用 Express.js 4.18.0 版本，并集成 Passport.js 进行 JWT 认证的 RESTful API，用于管理用户和文章数据，数据库使用 PostgreSQL，并提供相应的数据库迁移脚本。” 后者提供了更多上下文，AI 生成的代码自然更贴近需求。
    • 使用示例：在描述复杂逻辑时，提供具体的输入示例和期望的输出示例，这能极大地帮助 AI 理解您的意图。
    • 版本与依赖：如果对特定库或框架的版本有要求，请务必在提示中说明。

  4. AI 是您的搭档，不是替代品：

    • 人类的判断力：AI 生成的代码并非总是完美无缺。审查、测试和调试依然是开发者的核心职责。AI 擅长模式匹配和代码生成，但它缺乏人类的领域知识、安全意识和对业务细节的深刻理解。
    • 持续学习与优化：AI 模型在不断进化。保持对新工具和新模型的关注，并学习如何更有效地与它们交互，是持续提升 Vibe Coding 效率的关键。

  5. 拥抱新工具与平台：

    • 专用工具：市场上有许多专门为 Vibe Coding 设计的平台，如 RapidNative（专注于原生移动应用）、Replit 等，它们提供了优化的开发环境和 AI 集成。
    • 通用 AI 助手：即使是通用的 AI 聊天机器人，通过精心设计的提示，也能在 Vibe Coding 中发挥巨大作用。

结语

Vibe Coding 代表了软件开发的未来趋势。它不是要取代开发者，而是要赋能开发者，让我们能更专注于创造性的工作，将精力从繁琐的编码细节中解放出来。通过掌握上述技巧，您可以更有效地利用 AI 工具，以前所未有的速度和质量构建出色的应用程序。

标签：AI, 技术
分类：技术

文章内容如上。请问我是否立即将此内容写入 /Users/ervinzhang/.openclaw/workspace/personal/my-blog/source/_posts/vibe-coding-tips-2026.md，并发布？

发表于 | 分类于
字数统计: 2.7k | 阅读时长 ≈ 9

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

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

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

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

AI 最擅长的事情，是把模式化的东西快速吐出来。样板代码、接口封装、测试用例、SQL 语句、重构建议、文档初稿，这些它都越来越能干，而且干得越来越快。对很多人来说，这种速度足够震撼，于是他们自然会得出一个结论：既然 AI 已经能生成这么多东西，那程序员的价值是不是正在消失？

我反而觉得，恰恰是因为 AI 能生成这么多东西，程序员真正的价值才第一次被逼着暴露出来。

过去，很多人可以把”我写得快”误认为”我很重要”；把”我能堆出功能”误认为”我有不可替代性”；把”我熟练掌握某个框架”误认为”我拥有长期竞争力”。但 AI 一进来，这些建立在局部效率上的优越感，很快就开始松动。因为模型会补全，会仿写，会迁移，会总结，很多过去靠时间积累起来的机械优势，现在正在被迅速稀释。

这不是程序员价值的消失，这是程序员价值的去泡沫。

说得更直接一点，AI 不是在摧毁程序员，而是在摧毁那些原本就不够坚固的职业幻觉。它让人不得不面对一个很不舒服的事实：有些人所谓的”技术能力”，本质上只是对熟悉模式的重复劳动；有些人所谓的”经验”，本质上只是对旧答案的路径依赖；有些人所谓的”不可替代”，本质上只是组织还没来得及优化掉他。

所以我一直不太认同”AI 会不会替代程序员”这种问法。更值得追问的是：AI 会优先替代程序员身上的哪一部分能力，或者说，哪一部分原本就不配被当成核心能力。

在我看来，最先被压缩的，一定是那些模板化、低判断、低责任的工作内容。只会 CRUD、不会抽象问题的人，只会拼装方案、不会理解约束的人，只会复制答案、不会验证答案的人，都会越来越被动。过去这些能力还能勉强构成一种岗位价值，因为企业需要有人把脏活累活做完；但当 AI 可以以更低成本、更高速度完成同类输出时，组织一定会反过来问：既然这些东西模型也能做，你留下来的理由是什么？

这个问题很残酷，但也很真实。

很多人谈 AI 对程序员的影响时，喜欢把焦点放在”编码效率提升”上。我觉得这只是表层。更深的变化是：AI 正在强迫程序员从”产出导向”转向”判断导向”。过去大家默认一个程序员的贡献是他写了多少代码，解决了多少 ticket，完成了多少需求；以后真正重要的，可能是他是否能判断哪些需求值得做，哪些方案只是看上去能跑，哪些技术债不能再拖，哪些局部优化会在未来变成系统性代价。

这类能力，才是程序员真正稀缺的部分。

因为生成可以规模化，判断不行。生成可以被训练，责任不行。生成可以外包给模型，后果不行。

这一点非常关键。AI 可以给建议，可以给方案，可以给一段看起来很像那么回事的实现，但它并不真正承担结果。线上事故不会因为”这是模型写的”就减轻损失，架构错误不会因为”AI 当时建议这样做”就自动免责，安全漏洞也不会因为”提示词没写清楚”就不造成后果。最终站在系统前面，面对用户、业务、团队和损失的人，仍然是人。

也就是说，AI 可以参与软件生产，但它并没有真正进入责任链条。只要责任还在人，程序员这个角色就不会消失，只会重新分层。

而这种重新分层，恰恰是很多人还没有真正意识到的地方。

未来程序员之间的差距，可能不再主要体现为”谁更会写代码”，而是”谁更能定义问题”。一个人能不能把模糊的需求翻译成清晰的结构，能不能识别伪问题，能不能在业务压力、技术约束和长期维护之间做出合理取舍，能不能在 AI 给出十个看似都对的答案时筛掉九个错误方向，这些事情会比”手写能力”本身重要得多。

换句话说，AI 正在缩小”会不会写”的差距，却在放大”会不会想”的差距。当前一些公开讨论也普遍把 AI 对程序员的影响，归结为效率提升与角色变化，而不是简单的职业消失。

这件事对新人尤其残酷。因为 AI 对新手确实很友好，它能解释代码，补全模板，给出路径，降低门槛，让很多原本要靠漫长试错才能摸到的东西变得触手可及。但问题也正出在这里：门槛降低不等于能力自动增长。一个人如果越来越习惯于直接索取答案，而不是亲自经历拆问题、查文档、做验证、承受错误、修正认知的过程，那他获得的往往不是能力，而是一种被效率包装过的幻觉。

这种幻觉最危险的地方在于，它会让人以为自己已经理解了。可一旦离开提示词、离开现成上下文、离开模型给你的默认路径，很多所谓的”掌握”会立刻露出空心的部分。表面上看，AI 帮助新手跑得更快；实际上，它也可能让一些人更早失去独立思考的耐心。

所以我越来越觉得，AI 时代里最稀缺的，不是会不会用 AI，而是有没有能力不被 AI 毁掉思考习惯。

会用工具当然重要，但这只是起点，不是终点。真正拉开差距的，是你把 AI 当成杠杆，还是把它当成拐杖。杠杆会放大你的能力，拐杖会掩盖你的虚弱。一个判断力强的人，用 AI 会更快、更稳、更敢于探索；一个判断力弱的人，用 AI 只会更快地产生错误，而且常常错得更有自信。公开资料也反复强调，AI 在编程场景里仍需要人工监督、批判性思考和最终校验。

这也是为什么我不认为未来最优秀的程序员，会是那些最抗拒 AI 的人。恰恰相反，真正有竞争力的人，往往会非常积极地使用 AI。但他们使用 AI 的方式，不是把自己交出去，而是把 AI 纳入自己的判断体系里。他们会拿 AI 来做草稿、做探索、做加速、做对照、做重构建议，但不会把”模型说了什么”直接等同于”正确答案”。他们知道什么时候该信，什么时候该怀疑，什么时候该让 AI 参与，什么时候必须亲自下场。

说到底，程序员的价值重心正在发生转移：从代码生产，转向问题定义；从局部实现，转向系统理解；从执行命令，转向承担结果。

这件事听上去像一种压力，但我反而觉得，它也是一次行业清醒。程序员这个职业过去有太多不必要的神话：神化智力门槛，神化技术栈，神化”手写一切”的纯粹感，神化某种对代码的工匠式崇拜。AI 的出现，本质上是在戳破这些神话。它逼着我们承认，代码不是目的，系统才是；实现不是价值，解决问题才是；写得多不是本事，想得清楚才是。

所以如果今天再问我，AI 和程序员到底是什么关系，我的答案会比”取代”或者”协作”更锋利一些：AI 不是来消灭程序员的，它是来清算低质量程序员工作方式的。

它清算的是那种没有抽象能力却自以为资深的熟练工，清算的是那种没有判断能力却沉迷产出的忙碌感，清算的是那种没有责任意识却把模型结果当挡箭牌的轻浮态度。它不会自动带来更好的软件，但它会更快地区分出，谁在真正思考，谁只是在重复。

从这个意义上说，被改变的不是程序员这个职业本身，而是这个职业过去赖以维持体面的一部分旧逻辑。以后真正值钱的，不会是”我比 AI 更会写代码”，而是”我比 AI 更知道什么问题值得解决，什么方案值得相信，什么后果值得承担”。

而这，可能才是程序员在 AI 时代里最难被替代的部分。

发表于 | 分类于
字数统计: 875 | 阅读时长 ≈ 3

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

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

1. 优化你的物理与数字环境

  • 舒适的物理空间： 确保你的工作区域整洁、光线充足，并且符合人体工程学。一个舒适的座椅、合适高度的桌面、以及减少杂乱的摆设，都能显著降低身体的干扰，让你更专注于思考。
  • 数字世界的宁静： 关闭不必要的通知（包括邮件、社交媒体、聊天工具），整理桌面，建立清晰的文件和项目结构。使用全屏模式的 IDE 或编辑器，可以最大程度地减少视觉干扰。

2. 深入心流：专注与时间管理

  • 番茄工作法 (Pomodoro Technique)： 将工作时间划分为短小的、高度专注的”番茄钟”（通常为 25 分钟），中间穿插短暂休息（5 分钟）。这种方式有助于建立节奏感，防止疲劳，并让你更容易开始任务。
  • 深度工作区块： 安排没有打扰的长时间（如 1-2 小时）进行深度编码。在此期间，只专注于眼前的任务，拒绝一切外部干扰。
  • “音乐疗法”： 许多程序员发现，特定的音乐（如纯音乐、环境音、Lo-fi Hip Hop）能帮助他们进入心流。尝试不同的音乐类型，找到最能让你沉浸其中的背景音。

3. 智慧的工具选择

  • 你的 IDE/编辑器： 充分利用 IDE 的各项功能，如强大的代码补全、智能提示、重构工具、版本控制集成和代码片段（Snippets）。同时，探索 IDE 的”专注模式”或”极简模式”，它们能帮助你屏蔽不关心的 UI 元素。
  • 任务分解与规划： 在开始编码前，花几分钟时间明确当天或本次编码会话的目标，并将其分解为可管理的小任务。清晰的任务列表是启动心流的基石。

4. 建立支持性习惯

  • 规律的休息： 不要长时间连续编码。站起来走动、眺望远方、做些简单的伸展运动，都能帮助你的大脑重新充电，避免过度疲劳。
  • 代码前的仪式： 设定一个简单的”启动仪式”，例如喝杯水、深呼吸几次、回顾一下今天的任务。这有助于大脑从日常思维模式切换到编码模式。
  • 反思与调整： 在编码会话结束后，花一点时间反思：哪些部分进展顺利？哪些地方卡住了？是否可以优化环境或流程？

“Vibe Coding”不是一种一蹴而就的状态，而是一种需要刻意练习和不断优化的习惯。通过结合舒适的环境、高效的时间管理、智能的工具运用以及支持性的身体和心理习惯，你就能更好地解锁这种沉浸式的编程体验，让编码过程既高效又充满乐趣。

发表于
字数统计: 930 | 阅读时长 ≈ 3

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

1. 协作流程的再设计

AI 的介入并不是要取代人类开发者，而是成为高效协作的伙伴。主要表现在：

  • 需求到实现的闭环加速：AI 辅助的需求理解、用例生成和快速原型可以缩短从需求到实现的周期。开发者通过与 AI 的对话式协作，快速迭代设计。
  • 代码审查与风格一致性：代码生成工具在保持风格一致、遵循项目约定方面有显著帮助，但仍需人来判断领域语义和边界条件。
  • 流程自动化：从 CI/CD 配置、测试用例生成到部署脚本的自动化程度显著提升，减少重复性劳动，让团队把精力投入到架构设计和性能优化上。

2. 工具生态与工作方式

  • 代码生成与补全：基于上下文的代码补全、模板化代码片段与生成器将成为日常工作的一部分。这要求开发者具备评估生成结果可靠性与安全性的能力。
  • 测试与质量保证：自动化测试用例的覆盖面可以通过 AI 快速扩展，但测试的关键在于设计具有可复现性的用例、断言与边界条件。
  • 监控与了修复：将 AI 引入日志分析、异常诊断与自愈策略，使运维效率提升，系统稳定性提升，同时也带来对数据隐私和安全的关注。

3. 技能演进与职业路径

  • 新的技能组合：AI 相关的能力不再是“可选项”，而是核心技能的一部分，包括对话式设计、任务分解、数据驱动的决策，以及对生成代码的安全评估。
  • 学习路径的转变：从掌握单一语言转向熟悉多语言/多框架的组合、以及对工具链的端到端理解（从需求、实现、测试到部署）。
  • 人机协同的软技能：沟通、需求澄清、对话式交互与对 AI 产出进行有效的监控和纠错，成为团队成员的关键能力。

4. 风险与伦理考量

  • 依赖性与可解释性：过度依赖自动化可能削弱对系统设计的深刻理解，应确保 AI 产出可追溯、可解释。
  • 安全性与合规：生成代码的安全性、依赖版本的时效性、以及对开源组件的合规审查需要被纳入标准流程。
  • 数据隐私：在生成与测试过程中使用的训练数据、日志数据需符合隐私保护要求。

5. 实践要点

  • 设定清晰的边界：明确哪些任务由 AI 执行、哪些任务需要人类设计和确认。
  • 渐进式落地：从小范围项目开始，逐步扩展到全栈开发和架构设计，避免一次性引入过多工具。
  • 质量优先的自动化：确保自动化链路中的每一步都可验证、可回溯。

小结：AI 不是替代，而是放大开发者的能力。通过在协作流程、工具生态和技能体系上的有序整合，我们能够显著提升交付速度、质量和创新能力，同时对潜在风险保持警觉。

发表于 | 分类于
字数统计: 716 | 阅读时长 ≈ 2

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

环境准备

安装 OpenClaw 之前，需要确保本地已有以下环境：

  • Node.js >= 18.x（推荐使用 LTS 版本）
  • npm >= 9.x
  • 稳定的网络连接（需要访问 npm 源以及 AI 模型 API）

可以通过以下命令检查版本：

1
2
node -v
npm -v

安装 OpenClaw

使用 npm 全局安装最新版本：

1
npm install -g openclaw@latest

安装完成后，验证是否安装成功：

1
openclaw --version

初始化配置

运行交互式引导向导，完成初始设置：

1
openclaw onboard

向导会引导你完成以下配置：

  • 选择 AI 模型（OpenAI、Claude、Gemini 等）
  • 配置 API Key
  • 选择接入的通讯渠道
  • 初始化工作区目录

如果希望以后台守护进程方式运行，可以加上参数：

1
openclaw onboarding --install-daemon

配置 AI 模型

查看当前支持的模型列表：

1
openclaw models list

设置默认模型：

1
openclaw models set <model-name>

配置模型的 API 认证信息：

1
openclaw models auth

启动网关服务

OpenClaw 通过 WebSocket 网关来对接各平台渠道，启动网关：

1
openclaw gateway start

其他常用网关命令：

1
2
3
openclaw gateway stop      # 停止网关
openclaw gateway restart   # 重启网关
openclaw gateway           # 查看网关状态

接入通讯渠道

以 WhatsApp 为例，添加渠道：

1
openclaw channels add --whatsapp

执行后会弹出二维码，用手机 WhatsApp 扫码配对即可。其他平台同理：

1
2
3
openclaw channels add --telegram
openclaw channels add --discord
openclaw channels add --slack

添加后可以检查渠道状态：

1
openclaw channels status --probe

工作区文件说明

OpenClaw 的工作区默认位于 ~/.OPENCLAW/WORKSPACE，包含以下核心配置文件：

文件 作用
AGENTS.md 定义 Agent 的指令与行为
SOUL.md 设定 AI 的人格与语气风格
USER.md 记录用户偏好
IDENTITY.md 设置 Agent 的名称与身份
MEMORY.md 长期记忆存储
BOOT.md 启动时执行的初始化内容

健康检查

如果遇到问题，可以运行诊断命令，OpenClaw 会自动检测常见错误并提供修复建议：

1
2
3
4
openclaw doctor

# 深度诊断
openclaw doctor --deep

常见问题排查

  • 没有收到私信回复 → 执行 PAIRING LIST 并确认 APPROVE
  • 群组中 Bot 没有响应 → 检查 MENTIONPATTERNS CONFIG
  • 网关意外关闭 → 执行 openclaw doctor --deep
  • 记忆功能异常 → 执行 openclaw memory index 重建索引

总结

OpenClaw 的安装流程整体比较顺滑，核心就是三步：全局安装 → 执行 onboard 初始化 → 启动网关接入渠道。配置完成后，AI Agent 就可以在你日常使用的即时通讯平台上运行，极大地扩展了 AI 的使用场景。

更多命令可以参考：OpenClaw 命令速查表

内容由 AI 生成，仅供参考

发表于 | 分类于
字数统计: 388 | 阅读时长 ≈ 1

🔍 文档内容摘要

核心 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 — 模型管理 + 认证状态

快速安装

  • npm install -g openclaw@latest
  • openclaw onboarding --install-daemon
  • 全局标志：--dev、--profile、--json

渠道管理

  • WhatsApp: channels add --whatsapp
  • Telegram: channels add --telegram
  • Discord: channels add --discord
  • Slack: channels add --slack

工作区结构

  • AGENTS.md — 指令
  • SOUL.md — 人格/语调
  • USER.md — 偏好
  • IDENTITY.md — 名称
  • MEMORY.md — 长期记忆
  • BOOT.md — 启动
  • ROOT: ~/.OPENCLAW/WORKSPACE

斜杠命令/COMMANDS

  • /status — 运行状态
  • /model <m> — 切换模型
  • /compact — 压缩上下文
  • /new — 开启新会话
  • /stop — 中止
  • /think — 推理模式

基本路径映射

  • CONFIG: ~/.openclaw/openclaw.json
  • CREDENTIALS: ~/.openclaw/credentials/
  • LOGS: /tmp/openclaw/*.log

语音与 TTS

  • OpenAI / ElevenLabs: Premium
  • Edge TTS: Free (No API Key)
  • messages.tts.auto: "always"

记忆与模型

  • 向量搜索：memory search
  • 模型切换：models
  • 认证设置：models auth

故障排除

  • 没有私信回复 → PAIRING LIST → APPROVE
  • 群组中静默 → MENTIONPATTERNS CONFIG
  • 网关关闭 → DOCTOR --DEEP
  • 记忆错误 → MEMORY INDEX

自动化与研究

  • 浏览器操控：browser start
  • 定时任务：cron list
  • 心跳检查：30m

🌐 最终状态

💡 补充说明

原文网站： http://moltfounders.com/openclaw-mega-cheatsheet

内容由 AI 生成仅供参考

发表于 | 分类于
字数统计: 495 | 阅读时长 ≈ 1

在职场中呆久了，接触到不同的人，他们的做事风格各异，这种风格可能和性格，环境以及过往经验有关。

这些做事风格在处理事情上无论是过程还是结果都可能千差万别。我总结大概有两种类型，一种是对上管理型，一种是处理问题型。

虽然对上管理型最终也是要解决问题的，但是他是面向上级解决问题，在解决问题的时候不太会思考怎么解决问题，而在意的是解决问题的结果。这种可能问题最终是被解决了，但是可能不是最佳方式，可能是临时解决，基于这种对上解决问题的方式也注定他在处理问题时不会考虑相对长远的事情，属于领导发现问题解决问题，再发现再解决。这种方式可能比较高效，但是对组织是否有益可能不一定。问题如果都是单点式的处理，就不能形成问题-解决-总结-经验-避免下次再出现的闭环。导致的结果是，可能相同的问题重复出现。

处理问题型其实也就是面向问题解决问题，有可能领导发现的是A问题，但是分析下来其实A是由于BCD问题导致的，其实你可以只解决A，领导的问题被解决了，但是BCD还在那里。因为这种处理问题的方式你会思考问题本身，所以你会总结经验，因为很多问题有相似性。这种方式相对处理问题会低效，但是可能对组织的长远发展是有易的。前期问题比较多，但是一旦处理好之后问题会越来越少，因为每一次的问题处理都是对一类问题的处理。

发表于 | 分类于
字数统计: 952 | 阅读时长 ≈ 3

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 的变化。
  1. 当 countDownTime 变化时：
    • 1秒后，countDownTime 变成了 29。这导致了界面重组 (Recomposition)。
    • 在重组过程中，LaunchedEffect 会再次被执行。它对比新旧 key：
      • 旧 key: (boValue=0, countDownTime=30)
      • 新 key: (boValue=0, countDownTime=29)◦它发现 countDownTime 变了！于是：
      • 立即取消上一个 countDownTime=30 时启动的协程。
      • 启动一个全新的协程，并记录下新的 key (0, 29)。这个新协程又从头开始执行 {} 里的逻辑。这个过程会每秒重复一次。
  2. 如果 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 渲染。它的生命周期管理是自动且安全的。