从繁琐到丝滑：我如何与大模型结对，打造属于自己的效率神器

AI 开发 技巧

image.png

作为开发者，我们每天都在与代码搏斗，构建复杂的系统。但有时，拖垮我们效率的并非那些宏大的技术难题，而是一些微小、重复，却又不得不做的“脏活累活”。

今天，我想分享一个故事：关于我如何识别出工作流中的一个“效率小偷”，并与大模型（LLM）结对，将一个简单的想法，一步步打造成一个真正提升幸福感的自动化脚本。

一、故事的开端：那个每天都在“偷”我时间的动作

我的工作场景是 iOS 与 Flutter 的混合开发。这意味着，调试流程比纯 Flutter 项目要多一个步骤。

我的“效率小偷”就是这个流程：

  1. 在 Xcode 中编译、运行项目到真机上。

  2. Xcode 控制台会输出一行关键信息：The Dart VM service is listening on http://127.0.0.1:xxxx/yyyyyy=/。

  3. 这个 URL 的端口和路径是动态变化的。

  4. 我必须手动选中、复制（Cmd+C）这个 URL。

  5. 然后打开 VS Code，找到项目的 .vscode/launch.json 文件。(iOS 开发用不习惯Android Studio,Android Studio是能自动编译的)

  6. 在配置中找到 observatoryUri 字段，粘贴（Cmd+V）新的 URL，保存。

  7. 最后，才能在 VS Code 中启动调试器（Attacher）。

这个流程，每天多的时候要重复几十次。每一次，在 vscode 中都需找到 launch 文件,找到observatoryUri行,然后’精准’粘贴, 整个过程不难不分杂,但是烦人😂

于是，一个想法诞生了：“我能让这一切自动化吗？”

二、与 AI 对话：把想法变成可执行的计划

我没有直接开始写代码，而是打开了我的 AI 助手，把它当作一个资深的结对程序员，开始了一场“头脑风暴”。

我的第一步，不是问“怎么写代码”，而是“定义问题”：

我： “我想生成一个脚本，辅助我进行 Flutter 真机编译。背景是…（详细描述了我的痛点），需求是自动复制这个动态 URL 并更新到 launch.json 的指定位置。”

我特意加了一句：“你先理解背景和需求，有任何疑问可以向我询问。” 这很重要，我把它当成一个需要上下文的同事，而不是一个只会执行命令的机器。

(Claude Code 原对话框关闭了,从系统日志里找到的对话历史的 json 文件) AI 的反馈非常专业，它没有立刻给代码，而是开始提问，帮助我理清思路：

AI： “我理解了。让我确认几个细节：1. 你希望脚本如何获取 Xcode 的输出？2. launch.json 的文件结构是怎样的？3. 你希望脚本如何触发？”

这场对话非常有价值。我们迅速确定了几个关键点：

  • 数据源： Xcode 的编译日志。

  • 目标文件： /path/to/your/project/.vscode/launch.json。

  • 核心逻辑： 提取 URL -> 解析 JSON -> 替换字段 -> 保存 JSON。

至此，一个模糊的想法，已经变成了一个清晰、可执行的技术方案。

三、现实的碰撞：当“完美方案”遇到权限的墙

我们最初的构想是“完全自动化”——让脚本像一个不知疲倦的哨兵，实时监控 Xcode 的日志文件，一旦发现新的 URL，就立刻更新。

这个方案听起来最优雅。于是，我们（我和 AI）开始尝试。AI 动用了它的 Bash 工具，开始在我的 Mac 上寻找 Xcode 的日志文件。

Generated bash

# AI 尝试的命令
ls -la ~/Library/Developer/Xcode/DerivedData
find ~/Library/Developer/Xcode/... -name "*.log"
log show --predicate 'subsystem contains "flutter"'

Use code with caution.Bash

然而，现实很快给了我们一记重拳。macOS 的沙盒机制和隐私权限，让直接、稳定地读取 Xcode 的实时日志变得异常困难。我们遇到了各种问题：“文件找不到”、“权限不足”、“日志格式不统一”。

这是整个过程中最关键的转折点。

我们意识到，追求技术上的“完美”，可能会陷入一个为了解决 10% 的问题而花费 90% 精力的陷阱。我们的核心目标是“提效”，而不是“造一个技术上最牛的日志分析器”。

四、聪明的妥协：从“零操作”到“一键完成”

既然“完全自动”的路走不通，我们立刻调整了策略。

我问自己：在这个流程里，最简单、最不可能出错的用户动作是什么？

答案是：复制（Cmd+C）。

当我看到 Xcode 输出那行日志时，我的肌肉记忆就是选中并复制它。这个动作本身很快，烦人的是后续的“粘贴-保存”。

于是，一个新的、更务实的方案诞生了：

  1. 我，作为用户，只需要做一件事：看到日志后，按 Cmd+C 复制。

  2. 脚本，作为我的助手，在后台持续监听剪贴板的变化。

  3. 一旦发现剪贴板里出现了符合 Flutter VM URL 格式的内容，就立即执行后续的更新操作。

这个方案，我们称之为“智能剪贴板监听”，它把一个复杂的 7 步操作，简化成了一个 Cmd+C 的“一键操作”。自动化程度虽然从 100% 降到了 95%，但方案的稳定性和可行性却从 30% 飙升到了 100%。

这正是我所说的，想法的价值远大于工具本身。关键的不是写出一个多牛的脚本，而是找到那个能完美平衡效率、稳定性和实现成本的“甜点区”。

五、最终的成果：一个提升幸福感的效率神器

在 AI 的帮助下，我们很快用 Python 写出了这个“智能剪贴板监听器”脚本。它使用 pyperclip 库来监控剪贴板，用正则表达式来匹配 URL，用 json 库来读写 launch.json。

为了让它用起来更方便，AI 还帮我写了一个 start.sh 启动脚本，并提供了设置为开机自启动的方法。

现在，我的工作流变成了这样：

  1. 开机时，脚本自动在后台运行。

  2. 我在 Xcode 中编译项目。

  3. 看到日志后，选中，Cmd+C。

  4. 然后…就没有然后了。 在我切换回 VS Code 的一瞬间，launch.json 已经被悄无声息地更新了。我可以直接启动调试，心流完全不被打断。

这种“魔法般”的体验，就是我们追求的终极效率。

结语：你的“效率小偷”是什么？

这个小工具为我每天节省了至少 10-20 分钟的碎片时间，更重要的是，它消除了我开发流程中的一个巨大摩擦点，让我的心情都变好了。

回顾整个过程，我想分享的核心不是那段 Python 代码，而是这个思考路径：

  1. 敏锐地发现并定义问题：识别出那些“小而烦”的重复性任务。

  2. 与 AI 开放地对话：把它当作伙伴，共同探索可能性，而不是把它当成代码生成器。

  3. 拥抱现实，做出聪明的妥协：当完美方案不可行时，迅速调整，找到那个 80% 收益的务实方案。

  4. 聚焦最终体验：我们的目标是让工作更“丝滑”，而不是技术本身。

这个故事证明，大模型真正的力量，不仅仅是写代码，更是作为我们思想的催化剂和延伸，帮助我们更快、更好地将一个提升效率的想法变成现实。

所以，不妨现在就停下来想一想：在你的工作流里，那个隐藏的“效率小偷”是什么？

也许，你离解决它，只差一场与 AI 的对话。