标签归档：随笔

我的 AI Coding Guide

发表评论

最新更新于 2026 年 6 月 26 日

这个指南是我自己的 AI Coding 的经验总结，我认为在实际使用 AI Coding 的过程中，应该注意和遵循的规则。

这篇文章是我实践后高度总结出来的结论，如果你想看更细致的内容，可以看从“代码补全”到“全托管 Agent”：我的 2025 AI Coding 进化论和半年过去了，我和 AI Coding 的关系有什么变化？

精力管理

当你开始使用 AI Agent 来辅助编程后，你很快会发现，最大的瓶颈是你自己的管理范畴和你的精力管理。

1. Attention Is All You Need

AI 时代，信息的生产变得无比简单，这导致我们看到的信息、要处理的信息进一步爆炸。因此，如何更好地利用 AI Agent，降低我们的决策成本、提升我们的信息信噪比，让我们可以少做决策，做正确的决策。

2. Use the Strongest Model Where It Matters

使用你能接触到的最贵的模型来进行开发；能用 Claude Opus ，就不要用 GPT 5.5 XHigh；能用 GPT 5.5 XHigh，就不要使用 GLM 5.2 。

更贵的模型意味着对于你来说，可以更少的干预和决策，降低你对于 Agent 的管理成本。除非，某个任务对你来说，真的就是一句话任务，或者让他执行一个极其简单的任务。

对于格式化、批量替换、简单脚本、低风险机械任务，可以使用更便宜、更快的模型。

3. Prompt is Spec

你写给 Agent 的 Prompt，本质上就是临时规格说明。模糊的 Prompt 会生产模糊的实现。一个好的任务应该包含：背景、目标、非目标、修改范围、验收标准、验证命令和风险边界。

不要害怕给 Agent 长的 Prompt，相反，你应该尽可能榨干自己的脑子当中的想法，把和你的需求相关的事情全部写下来，即使只是很简单的个人倾向性的描述，也可以有助于帮你更快的完成自己的目标。

4. Plan Before Your Build

所有的工作，除了简单的日常动作（就是那种你觉得丢给随便哪个模型都能干的事情），只要是正常的工程工作（Feat / Bug / CI)，都要使用 Plan Mode 先聊一轮。目标是在过程中澄清你的需求，避免似是而非的需求进入到研发队列，浪费你的时间和精力。

把主要精力放在 Review Plan、Review Diff、Review Test Result 和风险项上，而不是逐行 Review Agent 写的每一行代码。你的精力终将不足以支撑传统意义上的全量 Code Review。

对低风险、可逆、影响面小的细节，可以降低审查强度；对数据、权限、计费、迁移、鉴权、删除、生产发布等高风险改动，必须重点审查。

5. Keep YOLO, But in a Reversible Sandbox

作为 AI Agent 的管理者（Manager），你要做的是抓大放小，何为大？架构设计、方案设计；何为小？具体的细节操作的命令。保持使用 YOLO 模式（Codex 的 dangerously skip permissions 模式），可以帮助你减少微操。

但是，不是无脑 YOLO。你需要确保即使是 Agent 在 YOLO 模式下发挥所造成的最灾难的状态，你是可接受的。

可逆沙盒至少意味着：代码已经进入版本控制；Agent 工作在独立 branch 或 worktree；没有生产密钥；没有生产数据库写权限；危险操作有备份或 dry run；部署、数据迁移、删除类操作需要人工确认。

工程管理

和 Vibe Coder 不同，作为工程师，我需要交付的是有价值的产品。所以，还是要让工作尽可能的 Under Control，避免 Coding Agent 帮你办离职。

6. Always Use Version Control and Remote Backup

无论你的项目大还是小，都要上一个版本控制工具。可以是 Git ，可以是 SVN，也可以是 hg，但一定要有。你需要让 Agent 始终工作在版本控制工具的范畴内，即使出现了问题，你也能快速回滚。

此外，一定要放在云上，这样即使是最极端的灾难情况 —— AI Agent 删除了你的所有代码，你也可以从云端找回一个历史的版本。

此外，用好 worktree 之类的功能。

7. Small Batches

让 Agent 以功能、特性为维度小步快跑，而不是一次性憋个大的。这对于要确认的你不友好；对于 Agent 也不友好。模型的注意力也会涣散，也会出现遗漏重点的问题。

小的步骤配合着版本管理工具，可以帮助你更快的迭代，同时，更稳。

8. Protect Production

除非你知道你在让 Agent 做什么，不然不要试图让 Agent 直接操作你的生产环境；如果实在不知道怎么操作，最好的办法是让 Agent 给你一个操作手册，你跟着操作手册去执行，并要求 Agent 解释每个行为的意义和价值。

我猜你不会想删库跑路的吧？

快速反馈

9. Fail Fast & Feedback Fast

尽可能早的报错，不管是代码，还是逻辑；尽早报错可以帮助 AI Agent 更快的发现问题，从而更快的解决问题。而不是到线上才暴露问题。

从这个视角来看，Typed Lang is better than non-typed lang。Golang、Rust、TypeScript 这类有强静态反馈的技术栈，更适合 AI Agent 协作；纯 JavaScript 这种反馈更晚、更依赖运行时和人工约束的方案，会显著增加 Agent 协作成本。

除此之外，为你的 Coding Agent 构建尽可能多的反馈回路，让他除了写代码之外，还可以通过反馈回路来获得反馈，优化自己的代码和实现。这些反馈回路包括：

Type Check
Lint
Format
Testing
Cyclomatic Complexity

让你的 Agent 在完成工作后，执行这些工具，尽快获得反馈，并自我修复，避免 Bad code smell 进入你的代码仓库。

git hook 就是一个不错的选择：pre-commit 搞定 type check、lint、format；pre-push 搞定 testing 和 Cyclomatic Complexity。

10. Work With CI/CD

尽可能构建你自己的项目的 CI/CD流程，除了本地的 hook 和检查，你还需要更加强制的校验，确保符合要求的代码才能进入你的代码仓库主分支。

确保你的 CI/CD 流程包含测试、e2e、复杂度、覆盖率分析、安全扫描，让你的代码尽可能的安全。

CI 负责阻止不合格代码进入主分支；CD 负责让可发布版本以可审计、可回滚的方式进入环境。

高并发工作

11. Async Work

由于模型的推理和 Agent 的工作需要时间，所以不要和 Agent 同步工作，而是尽可能的和 Agent 异步工作。通过 Plan 功能，前置让 Agent Review 和设计工作，并在确认后，让确认完的 Agent 工作；

这样你可以有效的让你的 Agent 和模型的工作最大化的利用；这里最重要的是让 Agent 可以在过程中一次性把要确认的快速确认完，然后自己可以兢兢业业干半个小时，甚至更久。你只在他需要你的那一刻投注注意力，剩下的时间，安排好你的注意力。

我最近比较喜欢用的是一个大的屏幕上同时开四个 Codex 干活；如果你是 Windows ，可以使用 wmux, mac 下则可以考虑 cmux 。这些都不错。

对了，一个副作用是，你可能会发现，跑了多个 Agent 之后，你会需要一台更强悍的电脑（所以我买了 2026年的 MBP M5 MAX）

12. Parallel Work

和人类不同，Agent 每一个线程都是完全独立的；只要你的 message 是独立清晰的；Agent 是可以并行工作的。而唯一能限制你并行度的，就是你自己对于工作的拆分和理解。

一个比较合理的方案是使用 git worktree 并行开发；同时尽可能避免让多个 Agent 处理同一个模块的事情，减少最后在合并回主分支时冲突的发生。

但是，需要注意，尽量不要跨项目并发工作，你自己的上下文会不足以支撑切换。

13. Sleep Work

对于人类来说，睡眠是一个很好的休息的时间，但对于 Agent 来说，不是的。 Agent 不需要休息，但很显然，休息状态时，你不太可能去跟进 Agent 的决策，确保他的产出是符合你的预期的，所以，你需要一些能够深夜自动工作的任务，从而帮助你利用好你的睡眠时间。

我一般会在深夜让 Agent 做这些事情：

写测试 & 补全测试：这些事情白天也能干，但白天可能在高频迭代，晚上让 Agent 补测试是个不错的选择。
代码重构：如果你的项目测试基建是足够好的，那么你的睡眠时间非常适合让 Agent 做自主重构，消解技术债务，帮助你的项目获得整体的高质量。

代码是你的，不是 Agent 的。

14. KISS(Keep it Simple Stupid)

AI Agent 在写代码时，会很容易出现复杂，你无法理解的写法，导致代码对你而言，彻底无法维护。这个是一定要避免的，你需要学着控制你的项目的复杂度，让 Agent 写完后跑 Cyclomatic Complexity 检查，超标必须重构，避免项目过于复杂，导致你无法维护。

即使你的代码是 Agent 写的，更加简单易于理解的逻辑，也会让你获得更好的结果。毕竟，你可能绝大多数的时候都能借助 AI Agent 搞定工作，但最终还是要确保自己有救济途径；可以接管 Agent 的工作。

总结

使用 AI Agent 编程，本质上是一次角色转变：你不再是那个逐行写代码的人，而是那个定义目标、划定边界、审查结果的 Manager。

Agent 的能力上限，取决于你给它的上下文质量；你的精力上限，取决于你把注意力放在哪里。

把决策权留给自己，把执行权交给 Agent，把验证权交给工具链。这三件事做对了，你的生产力才真正被放大——而不是被 Agent 带着跑。

代码是你的，不是 Agent 的。

2026 欧洲之旅：在意大利打车

发表评论

在意大利无法像在其他国家那样使用Uber X等网约车服务，需要下载专门的本地应用。appTaxi在佛罗伦萨覆盖率较高，而ItTaxi适用于罗马等地，范围更广。

计费从司机接单驶向乘客时便开始，上车前可能已有费用产生。司机通过专用设备接单，信息有限，需再次确认目的地。可以使用信用卡支付，前往车站则应提前预约车辆。

看到标题，你可能会好奇，诶？为什么是【在意大利打车】？在意大利打车和其他地方有什么不同么？

是的，不同的。在意大利，你并不能像我们在国内这样方便的使用 App 打车！在法国，你可以直接使用 Uber 打车，但在意大利，不行，你没办法打 Uber X（我们一般意义上的网约车）

1782227442 image — https://x.com/i/grok/share/aa3d083c7f8248e58c2e8a47dc837a71

So，如何打车？

想要在意大利打车，你需要下载当地的 App，比如我下载了 appTaxi 和 ItTaxi 这两个 App 来专门打车；

其中 appTaxi主要是在佛罗伦萨比较强，如果你是在佛罗伦萨，那么可能 appTaxi 能够更快的打到车；

而 iTTaxi 我们则是在罗马使用的，他的覆盖范围也会更广一点。

使用注意

单纯 App 倒也没啥，我们可以说一些重要的注意事项

计费逻辑不同：不管是 appTaxi 还是 itTaxi ，实际上对接的都是当地的专业的 Taxi；他们的计费逻辑是从他们接到你的订单，开始朝你这里开的时候，就会开始计费。所以有些时候你上车的时候，会看到已经有一些费用就是这个原因。
当地 Taxi 通过专用设备接单：和国内大家普遍使用手机接单不同，当地的 Taxi 往往都是有专用的设备来接单的，就是下图这个设备。你可以看到，里面的信息相当有限，因此，大概率你上车后，要和司机再 Double Check 一下你得目的地。
可以使用信用卡支付：国外确实信用卡是刚需，你打车也可以使用信用卡来支付，非常方便，不用带太多的现金了。
如果要去车站，记得提前预约：因为逻辑和司机的量不同，导致你并不一定能很快打到车，如果你要去车站之类的明确有时间限制的地方，那就记得提前预约车辆，并预估大致的时间出发

1782228259 img20260225171346514772828945590241 — 接单设备

总结

就记得意大利和其他地方不一样~得下载专门的 App 就行~

使用 Docker 部署 Github Actions Self Hosted Runner

发表评论

近些年来，我的个人项目基本上也是托管在 Github 上的。主要的原因一方面是 Github 身边的 Git Repository 使用起来体感还不错，另一方面，也是很重要的便是 Github 的 Actions。

作为一套开箱即用的 CICD 系统，Github Actions 给所有的 Public repo 提供了免费的运行时长，而对于 Private Repo，则没有那么多；我虽然购买了 Github Pro，每个月有 3000 分钟的额度可以使用，但随着你的项目越来越多，在进行的 CICD 检查越来越多，导致 3000 分钟的额度捉襟见肘，经常月中就没有了。

所以，我就瞄上了 Github Actions 的 self-hosted runners。其实如果你有足够的主机，配置起来挺简单的。打开 Github 仓库页面，找到设置 - Actions - Runner 页面，就可以新增 self-hosted Runner，在新的引导页面，选择你要使用的操作系统，然后跟随下面的指引安装即可，简单易行。

不过，这个方案也有个问题，一台主机只能安装一个 Runner，而一个 Runner 只能工作于一个仓库，对于项目比较多的人来说，还是不方便，所以就有了我研究使用 Docker 化部署的方案，在研究了前人的工作之后，我对这个方案进行了一定的优化，最终形成了你所看到的这个版本。

TL;DR

如果你不想看下面的细节描述，那比较简单粗暴，直接执行下面这个命令，就可以在你的 Docker 服务上启动一个容器作为 Github Actions 的 Self-hosted Runner。

docker run -d \
  --name actions-runner \
  --restart unless-stopped \
  -e RUNNER_URL=https://github.com/<owner>/<repo> \
  -e RUNNER_REGISTRATION_TOKEN=<token-from-config-sh-command> \
  -v /var/run/docker.sock:/var/run/docker.sock \
  bestony/actions-runner:latest
Code language: Bash (bash)

其中，第四行的 Runner URL 是指你自己的 Github 的仓库地址，直接配置上就行；

而第五行的 Token 则是你在 Runner 指引页面看到的 Config 的 Token

当你执行完成后，2-3 分钟，就可以在 Github Actions 设置页面的 Runner 看到刚刚启动的 Runner 了。

接下来，就是在你所有要使用 self-hosted runner 的 job 上，修改他对应的 run-on 配置即可

# Use this YAML in your workflow file for each job
runs-on: self-hosted
Code language: YAML (yaml)

支持哪些平台

我在代码层面支持了 Linux 和 Windows ，并预打包了对应的 Docker 镜像。Linux 使用的是 Ubuntu 24.04；Windows 使用的是 Windows 2022；此外，支持了 Linux的 x64,arm x64 和 arm v7, 如果你是本地 NAS 使用，应该也可以跑。不过我自己还没测试 ARM 的环境，如果你遇到问题，也可以直接提 issue 来反馈。

打包好的 Docker 镜像放在 https://hub.docker.com/r/bestony/actions-runner ，你可以在 DockerHub 页面上看到。

原理是什么？

这个实现的原理本质上就是借助 VM 的 Container 机制，将 Github Actions 的 Runner 二进制文件放在 Docker 镜像中，并通过托管 Docker Socket，来实现让容器内的 Runner 文件可以管理 Docker 容器，从而在后续执行 Job 的时候，创建对应的容器。

代码在 https://github.com/bestony/actions-runner （欢迎来 Star）

配置缓存

Github Actions 提供了缓存能力，从而可以让不同的 job 和不同的 run 可以使用相同的缓存，减少一部分缓存的时间和成本。 Self Runner 如果想要使用缓存，并让后续的 Runner 都可以使用缓存，你可以这样配置。关于缓存服务的自部署的更多信息，你可以参考 GHA Cache Server 的文档

创建一个网络

首先，你需要创建一个 Runner 专属的网络，从而让所有的 Runner 共享一个 Cache Server，方便后续使用。比如我们这里创建一个名为 Runner 的网络

docker network create runner

启动一个 Runner

当你已经有了提前创建好的 Repo 后，就可以根据需要来创建 Runner 了。你可以直接复制我下面的这段配置，存储成为 DockerCompose.yml ，修改环境变量配置，并使用 docker compose up -d 命令来启动，从而创建一个 Runner ，并启动相应的缓存服务器，来实现启动一个带缓存的 Runner。

services:
  runner:
    image: bestony/actions-runner:latest
    restart: unless-stopped
    env_file:
      - path: .env
        required: false
    networks:
      - runner
    environment:
      RUNNER_URL: ${RUNNER_URL:-}
      RUNNER_REGISTRATION_TOKEN: ${RUNNER_REGISTRATION_TOKEN:-}
      REPO: ${REPO:-}
      TOKEN: ${TOKEN:-}
      ACTIONS_RESULTS_URL: ${ACTIONS_RESULTS_URL:-http://cache:3000/}
      RUNNER_NAME: ${RUNNER_NAME:-}
      RUNNER_LABELS: ${RUNNER_LABELS:-}
      RUNNER_WORKDIR: ${RUNNER_WORKDIR:-_work}
      RUNNER_EPHEMERAL: ${RUNNER_EPHEMERAL:-false}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      mode: replicated
      replicas: ${RUNNER_REPLICAS:-4}
      resources:
        reservations:
          cpus: "${RUNNER_RESERVED_CPUS:-0.5}"
          memory: ${RUNNER_RESERVED_MEMORY:-1024M}
        limits:
          cpus: "${RUNNER_LIMIT_CPUS:-2.0}"
          memory: ${RUNNER_LIMIT_MEMORY:-4096M}

  cache:
    container_name: cache
    image: ghcr.io/falcondev-oss/github-actions-cache-server:latest
    restart: unless-stopped
    networks:
      - runner
    ports:
      - "3000:3000"
    environment:
      API_BASE_URL: http://cache:3000
    volumes:
      - cache:/app/.data

volumes:
  cache:

networks:
  runner:
    external: true
Code language: YAML (yaml)

上面这段配置主要有几个核心配置需要关注：

deploy 段：这部分主要是你会跑多少个 Runner，如果你的项目需要更多的 Runner 来执行 Job ，这里就可以调整的大一些；包括每个 runner 预约多少资源，能实际使用多少资源，都可以配置。
networks 段：这部分核心是要使用之前创建好的 Runner 的网络，从而让后续的所有的 Runner 都统一使用一个网络。

启动一个新的 Runner

当你完成上述的配置，但发现你需要一个新的 Self-hosted Runner 的时候，就可以复制下面不包含 Cache Server 相关的配置，直接使用了。非常的方便


services:
  runner:
    image: bestony/actions-runner:latest
    restart: unless-stopped
    env_file:
      - path: .env
        required: false
    networks:
      - runner
    environment:
      RUNNER_URL: ${RUNNER_URL:-}
      RUNNER_REGISTRATION_TOKEN: ${RUNNER_REGISTRATION_TOKEN:-}
      REPO: ${REPO:-}
      TOKEN: ${TOKEN:-}
      ACTIONS_RESULTS_URL: ${ACTIONS_RESULTS_URL:-http://cache:3000/}
      RUNNER_NAME: ${RUNNER_NAME:-}
      RUNNER_LABELS: ${RUNNER_LABELS:-}
      RUNNER_WORKDIR: ${RUNNER_WORKDIR:-_work}
      RUNNER_EPHEMERAL: ${RUNNER_EPHEMERAL:-false}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      mode: replicated
      replicas: ${RUNNER_REPLICAS:-4}
      resources:
        reservations:
          cpus: "${RUNNER_RESERVED_CPUS:-0.5}"
          memory: ${RUNNER_RESERVED_MEMORY:-1024M}
        limits:
          cpus: "${RUNNER_LIMIT_CPUS:-2.0}"
          memory: ${RUNNER_LIMIT_MEMORY:-4096M}

networks:
  runner:
    external: true
Code language: YAML (yaml)

总结

如果你和我一样，喜欢用 Github，但又没有足够多的 Github Actions 运行时长可用，或者你需要依赖一些你自己的内网环境，那么这个 self-hosted runner，就是为你准备的。

UniGetUI —— 可能是 Windows 下最好用的应用商店

发表评论

UniGetUI 是一款为 Windows 提供图形界面的包管理器聚合工具。它整合了 Winget、Scoop、Chocolatey 等多个包管理器，能够集中管理软件的安装、更新和卸载。

该工具支持创建软件捆绑包，便于批量部署或恢复个人工作环境。它通过统一的界面简化了多包管理器环境下的软件管理流程。

和 macOS 一样，Windows 也提供了一个应用商店，但和 macOS 不同的是，很多 Windows 下的软件是不会选择通过应用商店来进行分发的，所以在过去很长一段时间里，我们需要使用各种各样的包管理器来管理我们的软件，比如 Scoop、Chocolatey ，或者是直接上软件的官网，下载安装。

因为这样的需求，我们看到在中国的市场上出现了各种各样的软件管家 —— 比如 360 软件管家、火绒软件管家、腾讯应用宝。但这些软件背后的商业公司的利益或者是本身只管理通过其自己安装的软件，导致使用的时候也不是很完美。

终于，让我发现了一个接近完美的应用商店 —— UniGetUI。

UniGet UI 是什么？

严格来说，UniGetUI 并不是一个应用商店，它其实是一个为 Windows 10 & Windows 11 的常用包管理器提供了 GUI 的软件工具。而得益于他支持的包管理器足够多，所以你几乎可以将它当作「应用商店」及软件管理软件来使用。

作为一个包管理器的 GUI 实现，他提供了 Windows 近年来正火的 WinGET、老牌包管理器 Scoop 和 Chocolaty，同时也针对 Windows 下的 Powershell 5 和 Powershell 7 提供了相关的包管理器；针对编程用户常用的 NPM、PIP、Cargo 和 VCPKG 也有涉猎；虽然能力不完全对其，但最基本的安装管理和卸载等能力都是有的。

图片来源：https://github.com/Devolutions/UniGetUI/#package-managers

这些包管理器的上游来源组合在一起，基本上可以覆盖你的所有日常软件使用了你电脑上的 90% 以上的软件应该都可以找到了。

如何使用 UniGetUI？

安装 UniGetUI

UniGet UI 安装的方式有多种，你可以选择直接在 Microsoft Store 中安装。但如果你的 Microsoft Store 和我的一样，时常抽风，也可以考虑使用 Winget 、Scoop 、Chocolatey 来安装。甚至是直接下载安装包，作为你的安装入口（就和我装 macOS 一定先装 Homebrew 一样）。

https://github.com/Devolutions/UniGetUI/#installation

安装软件

当你安装完成后，接下来就比较简单了，直接打开软件，进入发现软件包，搜索你要使用的软件即可；

搜索完软件后，你可以点击，并在弹出的窗口中，查看对应软件的描述信息，了解这个软件是否是你需要的，并进行安装。

不过，你可能会发现，诶，为什么我搜索到的软件不如你的多？这是因为 UniGet UI 毕竟是一个包管理器的 UI，他所能安装的软件的选项取决于你的电脑上有哪些包管理器。默认情况下，你的系统里会自带 WinGet ，所以你搜到的都是 WinGet 当中的软件包。如果你需要更多的软件，则需要你安装更多的包管理器，并开启相关支持。

更新软件

当你安装了一些软件后，接下来的每日日常就是更新软件和管理软件，在 UniGetUI 当中，这件事也变得非常简单，只需要点击左侧的菜单，软件会自动查询对应的软件版本和你已经安装的软件，并可以根据自己的需求，选择你需要的软件，对他们进行更新或者卸载。然后他们的进展会展示在底部的队列中，一个接着一个处理（当然，你也可以修改配置，来提升并发度）。

封装软件捆绑包

除了上面的安装、更新、卸载软件之外，我觉得 UniGetUI 有一个不错的功能就是制作软件捆绑包 ——　顾名思义，这是一个帮助你将一批软件形成一个 Bundle 的能力。有了这个能力，就可以非常方便的创建出你自己的软件组合。

这样对于有自己习惯的人来说，可以维护一个简单的软件 Bundle，并不断更新这个 Bundle，这个 Bundle 将会在你下次 Setup 你的电脑的时候，作为一个非常方便的快速的包，来完成初始化。

当然，也可以是你根据需要，创建不同的 Bundle 组合，去给到他人来进行安装。

除了和 UniGetUI 强绑定的软件 Bundle，UniGetUI 还支持导出一个 Powershell 脚本。

安装脚本还是完全和 UniGetUI 无关的，意味着你可以只交付这个 Powershell 脚本，来交付你的软件包组合，可以减少你交付时的门槛（用户不用再装 UniGetUI 了，不是么）。

总结

总体来说，我觉得 UniGetUI 是一个不错的包管理器，它提供的统一的更新UI，可以帮助你确保软件都是最新的；同时，聚合了多个包管理器后，可以让你得软件最大程度的集中在一起管理，而减少视野之外的软件。同时，其自带的软件捆绑包则给这个软件提供了更多的可能性，除了用于自己的管理，还可以是用于团队管理、业务交付、软件开发环境构建等等一系列需要批量配置一批软件的场景。

干的不错！

半年过去了，我和 AI Coding 的关系有什么变化？

发表评论

作者回顾了半年来使用AI编程的发展，指出使用量显著增长。一个关键变化是发现并依赖VibeKanban进行多任务处理，其独特功能对高效并行工作至关重要。

作者认为AI正在改变软件工程行业，挤压初级程序员的溢价但提升了优秀工程师的价值。他建议从业者应注重培养判断力、品味和开放心态，主动适应技术变革浪潮。

在去年年底，我起心动念，开始写上一篇 AI Coding 文章，最终发表在从“代码补全”到“全托管 Agent”：我的 2025 AI Coding 进化论

而半年后的现在，我重新开始写这篇文章的更新，聊聊半年过去，我和 AI Coding 之间的关系的变化。

半年后的文章，我觉得不太需要重新写完整的架构，反倒是用问答的方式来撰写，其实是更好的选择。那么， Let‘s Go！

我还在使用 AI Coding 么？

是的，还在使用，而且用量与日俱增。我的 AI Coding 使用量和时间的关系大抵如此。

其中,这里面有一个曲线变陡和曲线向下，刚好对应了两件事：

第一件事是我发现了 VibeKanban 这个好用的工具，并开始大量使用它；
第二件事是 VibeKanban Sunset 之后，我没有找到平替软件来使用；

这里 VibeKanban 帮我解决了帮我做 Agent 横向拓展的能力；Sunset 实在可惜。在 VibeKanban 上，我可以一次性并行5-10个任务；

为什么是 Vibekanban，而不是 Slock(Raft)、Multica？

对于我来说，核心功能有几个：

对于 Worktree 的操作：多 Agent 在一个仓库下并行时，worktree 是必要的，不然没办法解决代码冲突的问题。
Plan Mode 的支持：目前我在用 Raft、Multica 的时候，他们都没有 Plan Mode 的支持，而我敢于快速 Scale 的前提，就是 Plan Mode。在没有 Plan Mode 的产品当中，我并不能快速且放心的批量 Scale
多分支合并下的 Agent 冲突处理：当你开足够多的分支时，冲突是不可避免的，除非你人肉规划不同的任务，让他们尽可能的不要修改相同的文件，但显然，在意图清晰的情况下；让 Agent 来去合并分支是一个更好的选择。

没有这三个Feature 的产品，对于我来说和使用 Terminal 没有本质的区别。

为什么一定是 Plan mode？聊天怎么就不行了？

我觉得这个算是我对自己的一个身份定位 —— 工程师；

作为工程师，你不是和 Vibe Coder 一样，只要让 AI 无脑干活就行；你需要保障软件的整体质量；那么这个过程中，你需要有足够的时间和精力，让你操作 AI 产出符合你预期的产品和工具；这是你的工资对应事情。

食君之禄，忠君之事。

Plan 就是我控制 AI 的手段。通过 Plan ，确认 AI 在大方向上没有问题，细节上我可以后续再调整。但大方向不能错！

为什么一定是工程师，而不是 Vibe Coder？

从上一个问题延展一下，我觉得其实很多时候，大家没太想清楚自己的定位、企业的定位。

如果你的产品做给自己使用的，且没有预期给其他人使用。那么你可以随意 Vibe。不需要工程师，不需要 Care 所谓的工程师实践。

但如果你的产品是做给别人使用的，你要考虑，对方到底要的是什么？对方是否愿意为一个 Vibe 产品付费？

我不是说不能 Vibe，不能 AI Coding；而是，你的东西应该是有一些你自己的心血在里面（一句话Prompt 不叫心血），你为他所投入的时间、心血，使得它有了价值。

“正是你为你的玫瑰付出的时间，使得你的玫瑰是如此的重要。”
《小王子》安托万·德·圣埃克苏佩里

“人类已经忘记这条真理，”狐狸说，“但你千万不要忘记。你要永远为你驯化的东西负责。你要为你的玫瑰负责……”
《小王子》安托万·德·圣埃克苏佩里

这些心血可能是你和模型对话了数百轮，才把一个产品从一句话可以打造出来的产品，变成一个正经可用的产品；也可能是你对于某一处细节、某一处流程的深度优化（即使是通过 AI 实现的）。

不要 Just Vibe。你不应该把你的狗尾巴花当成玫瑰拿出去，并预期别人把它当成玫瑰；你的玫瑰别人可能看成狗尾巴花，也可能看成玫瑰。但别人很难把你的狗尾巴花当成玫瑰。努力的用你的心血浇筑，让你的狗尾巴花变成玫瑰，然后交给他人。

当然，还有一种可能性是 —— 别人没有判断力，他压根分不清狗尾巴草和玫瑰，那么这个时候，你可以大胆的选择 —— 先给他狗尾巴草，但请不要止步于此，因为你和他不是一锤子买卖，你需要持续迭代，你可以先 Fake it as 玫瑰花，但请持续 Make it until it real a 玫瑰花，让你的狗尾巴花变成玫瑰花不止是为了他人，也是为了你自己。

我在用什么模型？

如今的我，基本上主要是 GPT 5.5 XHigh；使用模型的最高智能来完成工作，而非使用一个更便宜的模型。得益于 GPT 5.5 本身比 Claude Sonnet 更便宜的定价，我可以爽用模型。

当然，Claude 也在用，不过 Claude 更多是我日常和他对齐一些技术架构，讨论一些技术设计。大的模型消耗还是 GPT5.5。

我如何看待 AI 对于软件工程师的职业影响？

很明显，程序员的溢价中的泡沫在被挤压，对于程序员来说，可能没那么舒服了。在过去的数年里，因为程序员的缺口极大，导致很多人涌入这个行业，并不是每个人都真正适合这个行业。因为稀缺，每个人都拥有了更高的溢价。

但今天，AI模型满足了很多初级需求，对于很多初级用户的用法来说， AI 已经满足了他们的需求了，对于程序员的需求量也在下降；

另一方面，AI 也给予了软件工程师更高的溢价：因为今天虽然人人都能 Vibe 了，但你相反，更难找到好的工程师。因为人人都是程序员，让其中的工程师显得更贵。而一个好的工程师，可以帮助你的产品更加稳健的走下去。对于软件工程师来说，可以有更高的溢价 —— 可以一个人带着 AI干过去十个人的事情，同时拿过去 2-3 个人的钱。

我对新人有什么建议？

大家常聊，AI 时代，什么样特质的人是更紧缺的？答案也比较明确 —— 有 Taste、有判断力、有想法的人更重要。

前两者其实是相同的 —— 你需要先看尽好与坏的差异，然后才能在遇到不好的产品的时候，快速分辨出来；你只有看过足够多的好东西，你自然就知道你不想要的东西。所以，在 AI 的时代，应该尽可能多的去做一些尝试；然后通过尝试，体验更多的好东西。

而后者，则要求你有足够多的输入，不要固步自封，也不要怨天尤人。AI 带来的变革是大势，我们无能为力。就像大浪袭来，我们可以选择站在岸边等浪扑到脸上，也可以选择拿上冲浪板，主动走上浪尖，做弄潮儿。

如果你有更多的问题想问我的，欢迎你在文档下方评论区留言，我会后续在评论区里持续回复大家的问题。

加更：体验 Waymo 无人驾驶汽车

发表评论

作者在旧金山硅谷期间体验了Waymo的自动驾驶服务。行程从预约、上车到抵达的整个过程都由车辆自主完成。

体验感觉新奇，自动驾驶技术运作流畅。不过，Waymo的费用明显高于同类出行服务。

上次去美国的时候，我就想体验自动驾驶；但因为上次在旧金山玩的时候，光顾着看景点了，没顾得上去体验 Waymo，这次刚好有事来硅谷，刚好要在旧金山办事，有空体验 Waymo，就趁着这个机会体验了一把 Waymo 的自动驾驶。

为什么要体验 Waymo？

在我印象中， Waymo 是最早做自动驾驶的公司，作为一个科技爱好者，自然希望能够有机会来体验 Waymo。特别是当下国内的各种辅助驾驶大行其道；美国这边，Tesla 的 Robotaxi 也即将上线。在国内体验完全意义上的自动驾驶可能还需要时间，这次既然刚好临时来了硅谷，就体验一把。

Waymo 车长什么样子？

Waymo 的车和普通的汽车长相差异巨大，你能看到各种奇怪的传感器；这些传感器能让你一眼就看出来 —— 哦，这个就是 Waymo。

如何约 Waymo

Waymo是有服务范围的，你需要在服务范围内使用 Waymo；你可以直接访问 Waymo 的官网，确认她的服务范围。如果你是到旧金山湾区，那就没问题了，Just 体验 it。

如果你所在地区是支持 Waymo 的话，接下来只需要打开你的 App Store 下载一个 Waymo 的 App，使用你的 Google Account 登录上去；就可以约车了；单纯约车的界面，Waymo 和 Uber 没有什么特别大的区别，选择上车点和下车点；

上车！

约车以后，Waymo 会给你调度附近的 Waymo 车来接你；你可以根据 App 上的提示，提前到上车点等候；在你的 App 中，会展示你要乘坐的车牌号，如果你刚好碰到了多个不同的 Waymo 汽车，就可以参考应用截图中的车牌号来上车（比如下图中我的车牌号就是 83659A4）。

除此之外，Waymo 还支持上车点导航，你点击上图中上车点，Waymo 会给你展示一个指向的标记，帮助你更好的找到上车点。

需要注意的是，如果你上车的时候，刚好有别人要下车，一定要等对方下车完了，结算完了。你再上车！不然会出现你上车了，但其实前一个人的订单还没结束。我就遭遇了这个尴尬的事情。

等车到了上车点后， App 中就会展示如下图的提示，点击开锁，让车辆弹出开门把手后，你就可以打开把手，上车了。

出发

上车以后，系好安全带，点击后排座椅前方的控制面板的按钮就出发了。接下来你就可以坐在车上，体验无人驾驶了。

除了体验自动驾驶之外，你还可以切换到【我的车辆】中，根据你的需要，切换车辆的各项配置属性，比如温度、风扇、后排空间等各种属性；还可以设置要播放的音乐，绑定你自己的 Youtube 或者 Spotify 之类的。

下车

当你到达目的地后，车停稳后，就可以下车了；在下车后，下完、拿完东西后，在 App 里点击【锁车门】，你的这趟行程就走完了；接下来你所乘坐的这辆 Waymo 车，就会自己去处理下一个任务了。

Waymo 体验后感

Waymo 的体验整体比较新奇，毕竟是自动驾驶。而且作为最早坐自动驾驶的公司，整体体验还不错。不过 —— Waymo 好贵。。。。

同样的路程，去程用的 Waymo，29刀；回程打的 Uber，只需要 10 刀。。。。Waymo 只适合体验尝鲜了。。。更多的时候还是继续用 Uber 吧~。

工程师如何把多个 Coding Agent 真正带起来：一套比“开更多聊天窗口”更像工程流程的方法

发表评论

随着 Agent 的时代的到来和 AI Coding 工具的兴起，被 AI 冲击的最狠的软件工程领域也迎来一轮一轮变化；我也在这个过程中一轮轮迭代，使用不同的 Agent 的工具，来帮助我自己提升自己的工作效率。而随着我的 Coding Agent 的使用越来越多，我的问题不再是「有没有 Agent」、「有没有用好 Agent」，而是 —— 「在保证工程质量的基础上，如何把多个 Agent 同时安排出去，把结果收回来」。

现在的问题是「如何 Scale UP 你的 Agent 」

虽然目前 AI Coding 的覆盖率依然有待提升，但是，对于不少逛少数派的工程师来说，大家大多已经会用 Claude Code、Codex、OpenCode 一类工具。大家所面临的问题不再是将 AI 引入自己的工作流，而是

你已经在使用 AI 了，但你手头有 100 个任务都需要推进，每个都是 P0 任务。
你其实也知道每个任务怎么做，但终究只有一个你；
你的精力足以支撑你一个个盯这些任务，你可能会考虑多屏幕开始干活，但终究还是只能同时看 3-4 个，就很难再更大规模的扩容。

真正卡住你的不是代码能力，而是并发调度能力

为什么 Codex / Claude 的 Terminal UI 不够？

Terminal UI 从体验上来看，还是一个 Chat Bot ，你给他安排工作，让他把事情做完，这个还是单个线程的工作流；如果你有多个任务、多条分支、多种不同风格的 Agent，不可避免的要用上 Terminal 自带的多 Tab、多窗口，抑或是使用 tmux 来帮助你复用窗口，开发者本人会成为任务调度的瓶颈。

而在这个过程中， Terminal UI 的限制也有贡献，让我们集中在小范围的核心信息中把工作完成。

而这个过程中，我认为最接近当下我眼中最优解的便是 —— Vibe Kanban。

Vibe Kanban 在解决什么问题

如果你认真用过一段时间 coding agent，就会发现单 agent chat 界面有几个很明显的问题。

它天然更适合顺序执行。你可以让它完成一个明确任务，但一旦任务开始变多，吞吐量很快就会被人类自己卡住。
上下文很容易混。你本来只是想修一个 bug，结果顺手又让它改了另一个功能，再过一会儿，你已经忘了这段对话到底是为了解决哪个问题。
计划和执行是黏在一起的。很多时候不是 agent 不会写，而是你还没把任务定义清楚，它就已经开始跑了。
review 成本越来越高。你开了更多 agent，并不自动等于你获得了更高的工程效率，很多时候只是获得了更多需要你亲自收拾的 diff。

围绕着上面的这些问题，Vibe Kanban 做了一些优化，它不是新的 coding agent，而是一个把 planning、workspace、review、preview、PR 流程连起来的管理层。

这让软件工程任务从 Agent Chat 窗口中的单线程流转变成了我们更熟悉的 Kanban 机制，有了状态、有了任务，每个任务还有单独的 workspace ，我们可以使用我们熟悉的工作流，来优化完整的 Agent 落地行为。

先拆 issue
再明确计划
再开 workspace
再让不同 agent 去执行
再 review diff
再决定是否收敛、合并

我自己的 Vibe Kanban 的工作流

目前我是一个 VibeKanban 的重度依赖者；我会把我平时看到的一些任务直接添加到 Vibe Kanban 上。

在完成任务细节的补充后，直接创建一个新的任务工作区，选择 Agent，并让 Agent 强制开启 Plan Mode，通过 Plan Mode 消除任务中的歧义。

最终汇总形成完整的设计方案后，批量让其执行起来；

因为 Agent 执行是需要周期的，所以我可以同步开启 N 个 Issue ，让 Agent 并行处理，并在 Agent 需要我介入的时候，参与到任务当中。

通过这样的方式，我快速且稳定的交付了大量的高质量的需求。

我所看中的 Vibe Kanban 的几个设计细节

1. Kanban 机制

当你 Scale 的 Agent 足够多的时候，你会发现，真正限制你的不是 Agent 的数量（这个很好突破，是钱的问题），真正限制的是你的认知带宽、你的管幅。一个你更熟悉的方式，会帮助你减少 Landing 和理解的成本。

Kanban 简单的 TODO、Doing、DONE 机制，让任务本身一目了然，我们可以轻松的把任务的当前状态、Next Action讲清楚、想清楚，也可以收敛每个任务的上下文。

2. 强制开启 Plan Mode

大部分人类在给 AI / Peer 安排任务的时候，其实是很差的，我们并没有说清楚需要做什么。这是因为我们脑海中有远超我们所表达的上下文。但如果我们没有安排出清楚的上下文时，不管是 AI 还是我们的 Peer ，其实都很难做好这些事。如果想要更好的让 AI / Peer 把事情做好，就需要把上下文交代的清楚。

既然人类不习惯，那不妨让 AI 来主动追问，通过 Plan Mode 来强制让 AI 主动发现任务细节中的歧义，并主动对话来消除歧义。

3. Agent 并发接入 & 自动的 Workspace 接入；

想要最大化你的时间和精力，一个比较好的办法是让你的下属 AI 能够并发进行处理任务，并充分的利用你的精力去做重要的决策。那么就需要同时启动多个 Agent，他们并行做计划、并行推进，从而打满你，让你可以始终处在决策、确认、检查、休息的环节，而不是无所事事。

Vibe Kanban 和 Git Worktree 做了非常好的集成，当你开始一个工作区的时候，他会自动为你创建一个新的 Worktree，并可以在你的任务完成后， Merge 进入你的 Main 分支当中，非常的方便。不仅如此，当你的变更和上游发生了冲突的时候，它还提供了 AI 解决冲突的能力，从而将复杂的分支管理给简化了。

4. 一丝丝幽默感

Vibe Kanban 是支持完成任务通知你的，而通知的方式也颇为幽默。他们提供了很多种音频来提醒你，比如 —— 牛的哞哞叫。是的，我的提醒音频就是牛叫，提醒我，我的 AI 牛马把活干完了，需要我去看了。

很好玩。

Vibe Kanban 适合谁？

从我自己的时候来看， Vibe Kanban 非常适合所有的「软件工程师」，他们的问题是虽然知道每一个任务应该怎么做，但没有足够的上下文带宽来并行，Vibe Kanban 提供了串行转并行的能力，帮助你更加快速的将自己 Scale 起来。

Vibe Kanban 真的像 —— 你将自己复制了 100 份，去分别执行不同的任务。你觉得自己分身乏术？这个就是那个分身之术。

但同样的，Vibe Kanban 也不是银弹，它不适合：

不适合还不会拆任务的人
不适合把 AI 当自动许愿机的人
不适合只想偶尔用一下 agent 的轻量用户
不适合还没有 review 能力的人

遗憾的是， Vibe Kanban 终将 Sunset

虽然 Vibe Kanban 我说的很好，但不得不说，就如标题一般 —— Vibe Kanban 终将 Sunset。这也是促使我来写这篇文章的重要原因，即将转向的 Vibe Kanban 值得你尽早体验。

VibeKanban 的方向是明确的，它代表了一种易于理解、易于拆解方案的 Agent Scale 实现。作为一种工作方式和实现，他无疑是成功的，但作为一个商业化产品来说，他可能又是失败的。 Vibe Kanban 的母公司 Bloop AI 已经宣布 Shutdown ，Vibe Kanban 项目也将专项 Open Source & community maintained。

在今天，如果你还困惑于如何 Scale Up 自己，最大化发挥出 Agent 的潜力，我觉得 Vibe Kanban 是一个你的必经之路。未来或许会有更好的解决方案，但 Vibe Kanban 的 Sunset 也浇灌出了新的可能性。