标签归档：开发经验

我的 AI Coding Guide

发表评论

最新更新于 2026 年 6 月 24 日

这个指南是我自己的 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 负责让可发布版本以可审计、可回滚的方式进入环境。

代码是你的，不是 Agent 的。

11. KISS(Keep it Simple Stupid)

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

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

总结

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

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

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

代码是你的，不是 Agent 的。

使用 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，就是为你准备的。

半年过去了，我和 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 带来的变革是大势，我们无能为力。就像大浪袭来，我们可以选择站在岸边等浪扑到脸上，也可以选择拿上冲浪板，主动走上浪尖，做弄潮儿。

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

从“代码补全”到“全托管 Agent”：我的 2025 AI Coding 进化论

1 条回复

本文有一个 Online 的 Sample 版本。如果你对于「我具体是怎么做的」感兴趣，可以直接看这个 Twitter Threads

2025 年，我的工作习惯彻底被 Claude Code / Cursor / Codex 改变了；这一年给我带来的改变，不亚于当年我用易语言写出第一个应用程序的时候。这句话不仅适用于我的产品经理身份，同样适用于我的工程师身份。这不仅是软件开发效率的提升，更是软件开发方式的重构。

AI Coding？到底是什么？

在社交媒体上讨论 AI 编程的时候，很多时候大家其实没有对齐在讨论的 AI 编程的范畴和适用领域，使得大部分时候，大家在鸡同鸭讲，公说公有理，婆说婆有理。所以，在我们真正讨论 AI 编程之前，我们需要先澄清一下，我们到底在讨论什么「AI Coding」？

目前来说， AI Coding 有几种不同的产品形态和用户交互形态，他们包括：

L1：古典的直接问 ChatGPT：有问题直接问 ChatGPT、Gemini、Claude 等 AI 助手，借助 AI 助手给出的信息，自行 Debug 和修改代码。
L2：使用 IDE / 插件中提供的补全功能：直接写函数名，然后 AI 会帮你补全函数的细节，你再自己微调或者不微调。这种能力其实过去也有，只是没有这么强悍。大家使用 IDE 来开发，很大程度上就是 IDE 提供了极好的补全能力。
L3：使用本地的 AI Coding 工具的 Agent 模式，全托管或半托管式的编程：你只描述需要做什么，具体做动作由 AI 来完成；这里还有几个细分的方式，包括完全托管（比如 claude code 开 --dangerously-skip-permissions ; codex 开 --dangerously-bypass-approvals-and-sandbox）和半托管（用户手动确认行为，只是由 AI 来完成具体修改的动作）。L3 操作的是你的本地环境，有破坏的风险，但也有无限的可能。
L4：使用网页端的 AI Coding 工具，直接出 Demo：你不需要在本地有任何开发环境的配置，直接在网页端使用一个应用，来完成 Coding，你只需要描述你想要的东西，剩下的完全交给 AI（虽然这往往意味着难以与复杂的本地业务流集成）。

大家在社交媒体上和别人讨论 AI Coding 的时候，需要注意，很有可能你在聊的是 L3 ，但别人在聊的是 L4 ；你们看似聊的都是一个东西，但实际上是完全不同的东西。我们这篇文章讨论的，则主要是 L3 —— 即使用本地的 AI Coding 工具的 Agent 模式，全托管或半托管式的编程。

到底谁在用 AI Coding 工具的 Agent 模式？为什么是 Agent 模式？

说完了大家眼中不同的 AI Coding 工具，我也必须再强调一下，即使大家聊的都是【AI Coding 工具的 Agent 模式】，因为身份的不同，每个人的用法也会有很大差异，大家对他的预期也完全不同。因此，不同的人对其的评价也千差地别：其中大体也可以拆分为三个大类：

传统的软件工程师：使用 AI Coding 工具完成自己工作过程中的一些辅助性工作，对于自身的能力和工作的要求有较高的要求。
有一定研发概念的产品工程师（称之为产品工程师是因为他们有一些基础的软件工程概念）：使用 AI Coding 工具拓展自己的能力圈，去做一些之前必须依赖软件工程师才能做完的事情（比如做个小 Demo，或是上线一个软件产品）。
被媒体上的文章忽悠进来的小白（他们基本上没有太多的软件工程经验和基础）：跟着网络上的信息了解到了 Coding Agent，然后尝试在不同的软件上使用（不局限于 Claude Code，Cursor 的 Agent 模式也算），经常会卡在一些软件工程的基础问题上。（我特别推荐这类人去看《计算机教育中缺失的一课》，看完以后，会让你很快理解你所遇到的问题，并能够快速处理 AI Agent 所给你的信息，进行下一步操作）。

这三类人因为工作的要求、对于软件工程的理解的不同，会导致他们使用 AI Coding 工具的 Agent 产出完全不同的体验，从而有不同的评价。

而之所以是 Agent 模式，是因为相比于补全模式需要你现有一段代码；Chat 模式往往不指引你完成所有的工作或需要你现有互联网软件的基础才能完成工作；Agent 模式自带的环境操作能力，使得你即使完全不懂 AI 和 Coding，也可以做一个像模像样的小应用出来。这打破了过去需要软件工程师才能做出一个 Demo 的限制，同时也极大的鼓励了新手小白，试着去做一些有意思的事情。

Agent 模式也是 AI Coding 最出圈的一个 Feature；

我和 AI Coding 工具的 Agent 模式的缘分

在这条推上，我提到，我其实经历过三种不同的状态，这源自于我过去一年的体验。

在过去这一年里，我从一个「以补全为主，抗拒 AI Coding Agent」的工程师，转变为了一个「好好利用 AI Coding Agent」的工程师。这其中，离不开我身边的朋友们和小伙伴们，和他们的协作，让我真的意识到了 AI Coding Agent 的价值。

这里要感谢刘超、杨鼎睿、岳增五，和你们的协作让我极大的改变了自己对于 AI Coding 的认知和看法。

作为一个写了十数年代码的工程师，我拥有一些自己平时写代码的脚手架，可以帮助我快速完成一个项目，而同时，作为工程师的自我要求，我希望我自己写的代码能够拥有不错的代码质量和性能，从而可以提供一个稳定的软件质量。所以在一开始，我对于 AI Coding Agent 的能力是持怀疑态度的，虽然依然会使用，但整体信任度没有那么高，往往只让它处理细枝末节，基本上是让 AI 去写一个完整的功能的细节，或者是让 AI Coding Agent 去进行 Code Review，而不是让他去动业务代码；直到 Claude Sonnet 3.7 的时候，我才发现 Claude Code 已经能完成不少的工作，甚至很多小的 Feature，不再需要我先行规划，再让他自己去做细节，我可以非常坦然的交给他一些功能，让他自己去完成我只做关键验收。

而从这个时刻开始，我对于 AI Coding Agent 的使用开始与日俱增，我开始使用 AI Coding 去完成越来越多的功能和效果，然后，我开始对 AI Coding 放权；开启了 --dangerously-skip-permissions ，让 Claude Code 自己去写代码，去实现效果；

也和所有的使用 AI Coding Agent 的人一样，我也经历过 AI Coding 工具将代码整的一团糟，然后放弃的时刻。不得不说，Claude 有些时候的过度设计，真的让人觉得无语。或许这是最佳实践，但最佳实践不仅仅要配合着实践用，也要配合着项目的时间节点和周期，以更好的完成项目的目标 —— 你要记得，Coding 只是完成目标的手段，而不是目的。

不过，随着对于 AI Coding Agent 的逐步使用的深入，我对于 AI Coding Agent 的使用越来越了解也越来越多的在不同的场景下去使用 AI Coding Agent ，去完成自己的工作。

如今的我对于 AI Coding Agent 模式的观点

首先，我旗帜鲜明的说所有的软件工程师都应该试着使用 AI Coding Agent，放弃、逃避、蒙头装鸵鸟都是没有意义的，熟练掌握 AI Coding Agent 已不再是加分项，而是生存技能。 AI Coding Agent 正在切实的改变着我们的行业。诚然，AI Coding Agent 不会影响我们这些「老」工程师的工作，但这个问题如同被熊追着我们一样 —— 淘汰你的从来不是熊，而是比你跑得更快的人。 AI 不会淘汰工程师，但会淘汰那些拒绝进化的“手动操作员”。优秀的工程师不会消失，我们的职责正从“手写逻辑”转变为“选择方案、设计架构、验收质量”。

其次，我依然相信大家的软件工程经验是有价值的，就像上面我提到，最佳实践本身没有问题，但每个人所面对的项目的节奏是完全不同的。软件工程师的价值从手写代码，变为了选择 AI 提供的解决方案，Review AI 提供的解决方案，可以帮助我们更好的完成自己的工作。优秀的软件工程师只是工作职责变了，但他们不会消失，甚至会获得更多的加成。

我现在怎么用这些 Coding Agent？

我目前自己同时在使用的包括 Claude Code、OpenAI Codex、和 Gemini Cli；其中前两者是我自己花钱买的，后者是 GDG 赠送的。

我强烈建议大家自己花钱购买。如果公司买了最好，如果公司没买，自己买也是划算的。 Claude Code 5X 已经满足日常使用了，如果你用量大，再升级 Claude Code 20X 即可；$100 其实就是大家聚餐吃一顿价格，并不贵，但给你带来的提升是远超这个价格的。

我对于 Coding Agent 的使用会包含两块：

本地使用
云端使用

以及，一些质量守卫。

本地使用

本地使用时，我会使用 Claude Code 的 Plan Mode 来设计一些需求，通过和 Coding Agent 的几轮交互，约束需求的范围，并让 Claude Code 去完成相关的功能；

同时，我会使用 Codex 来为我的项目补全测试 —— 过去我自己很多时候懒得写测试，现在有了 AI 来帮助我们完成测试的基础覆盖，大大提升了我的效率。或许 AI 无法保证测试的如一个专业的测试同学，但却可以让我先完成从 0 到 1 的建设，让我自己可以变的更好。

Gemini Cli 则会在一些时候，我会让其作为项目的补充，主要也是 GDG 赠送的 Plan 额度有限，所以用的不多。

之所以会同时使用三个不同的 Coding Agent，主要还是考虑到模型本身的能力是有差异的；不同的模型可以给我提供不同的视角，从而可以确保对于一个问题有更全面的思考，规避可能的思维漏洞。

云端使用

除了本地的使用，我还会在云端使用 AI Coding Agent，但并不是使用网页端的 Coding 工具，而是在 CI 工具链中集成 AI Coding Agent，使用 AI Coding Agent 对于我的每一次提交、每一次 PR 进行 Code Review ，通过这样的方式，帮助我更好的发现代码中的问题，既可以确保自己对于问题的思考没有漏洞，同时可以进一步的发现自己的经验不足，补全对于问题的思考维度。

特别是，集成多个 Coding Agent 可以明显看到不同 Coding Agent 对于问题的思考角度和深度不同，对于自我提升非常有帮助。

质量守卫

由于AI Coding Agent 本身存在的问题，往往会在大规模编辑代码的时候，存在一些编辑错误、无用代码、不符合规范的问题，因此我在深度使用 AI Coding Agent 的项目中，都会引入大量的质量守卫，来确保不符合规范的代码无法提交到云上。我们应当保持对 AI 的信任，但必须坚守「信任，但要核实 (Trust, but Verify)」的原则，确保 AI 提交的代码每一行都可信、可控。

具体包括：

引入静态检查的准入机制，扼杀低级错误：借助 git hook，在提交前进行 code format
引入质量红线，控制确保逻辑不出错，没有改错之前的代码：借助 git hook 和单元测试围栏，要求提交到代码库中的代码必须测试覆盖率满足要求（强 AI Coding Agent 介入的项目会要求测试覆盖率到 100%；并包含集成测试和端到端测试）。
引入 AI Agent 的自愈能力，闭环问题的修复：借助 git hook 和一些 linter 工具，发现代码中的问题，并让 AI Coding Agent 自己去修复他。
引入代码复杂度分析工具，让 AI 写出人和 AI 都易于维护的代码：常见的编程语言基本上都提供了圈复杂度检查工具，你可以在你的项目中引入圈复杂度检查工具，让 AI 提交之前确保所有代码的复杂度不会太高，从而既可以借助 AI 的能力快速迭代，同时又保留自己随时介入的可能性。

当你有充足的围栏检查的时候，你就可以放心让你的 AI 去完成工作，并要求他自行提交 commit，这样可以让其自动执行 git hook ，并修复 git hook 中所配置的工具检查出来的问题，从而确保提交到代码库中的代码不会有一些基础问题。

如果你还没有开始使用 AI Coding Agent ，你要怎么开始（工程师篇）

如果你是一个工程师，想要试试 AI Coding Agent ，但不知道怎么做？

我能理解你对于代码质量的要求和你的工作对于你的要求；
我也知道你担心引入 AI 导致你的项目复杂度快速提升，无法维护，最后导致项目彻底崩盘，你反而被干掉；

所以，我推荐你这么干：

在现有的 CI 工具链中加入 AI Coding Agent 进行 Review，从而让 AI 先从 Review 代码开始，给你提供更多的建议，帮助你先变成一个更好的工程师；
在习惯让 AI Coding Agent 参与到你的工作流里后，可以先让 AI 帮助你补全测试，建立起单元测试围栏，从而让你放心的使用 AI Coding Agent 参与到你的项目里；
使用 AI Coding Agent 完成你的工作（记得加入各种围栏），让你自己获得进一步的解放。

当你完成了上述三步后，你已经熟悉了 AI Coding Agent，就可以除了做一些你熟悉的工作，还可以让他带着你，去做一些你所不熟悉的事情，比如你是前端，让他带着你搞后端；或者你是后端，让他带着你搞 iOS。

总结

到了 2026 年，你依然可以 Happy Coding，不过你要学会意识到，我们除了做体力劳动的 Coding，我们更应该用好 AI Coding 工具，将体力劳动托管给 AI Coding Agent，让自己的工作越来越具有「创造性」，做一个「创造者」。

如何在 Google Analytics 4（GA4）查看 Referer URL ，获取来源地址

2条回复

作为统计站的第一，这个 Blog 也挂了 GA 4 作为统计。如果你希望知道是谁在推荐你的 Blog，一个很好的办法是查看 HTTP 的 Referer 的 URL，来判断哪些人在哪些地方推荐了你。

不过 Google Analytics 在升级到 GA4 之后，查看 Referer 变得麻烦了不少，没办法直接通过预置的看板来查看。这篇文章就是帮你找回丢失 Referer URL。

具体操作步骤

一、登录 GA 4 ，找到你的站点；点击左侧的「探索」，进入到探索页面。在探索页面点击「空白」，来创建一个新的探索看板

二、新的探索页面，选择维度这里，新增两个维度和一个指标

维度：网页引荐来源网址和网页位置

指标：新用户数

三、将网页位置和网页引荐来源网址配置到设置中的行，且顺序为网页位置在先，网页引荐来源网址在后；显示行数设置为 500；将新用户数配置到设置中的值当中；设置过滤器为网页引荐来源网址包含 //

四、配置完成后，你就可以看到类似我这样的界面了，在这个页面里，你就可以看到不同的来源给你带来了多少流量；从而进一步的去和对方沟通~

django-storages 配置使用 S3 Provider 支持 Aliyun OSS 使用

发表评论

阿里云 OSS 提供了 S3 的兼容，所以如果你在 Django 应用当中，希望使用 OSS 作为文件存储的话，可以参考下方的说明，来使用。

安装

首先，你需要执行如下命令安装 django-storages 的 S3 兼容

# uv
uv add django-storages[s3]
# pip
pip install django-storages[s3]
Code language: CSS (css)

配置

接下来，就是在你的项目文件夹中的 settings.py 中添加如下配置

AWS_S3_ACCESS_KEY_ID = env("AWS_S3_ACCESS_KEY_ID") # 你在阿里云拿到的 ACCESS_KEY
AWS_S3_SECRET_ACCESS_KEY = env("AWS_S3_SECRET_ACCESS_KEY") # 你在阿里云拿到的 Secret Key
AWS_STORAGE_BUCKET_NAME = env("AWS_STORAGE_BUCKET_NAME")# 你在阿里云拿到的 Bucket Name
AWS_LOCATION = env("AWS_LOCATION") # 你的文件上传路径，比如  uploads/，你的所有文件都会上传到这个路径下
AWS_S3_REGION_NAME = env("AWS_S3_REGION_NAME") # 你的 OSS 的可用区，比如 oss-cn-beijing
AWS_S3_CUSTOM_DOMAIN = env("AWS_S3_CUSTOM_DOMAIN") # 你自己的自定义域名，以便于后续访问的时候使用。如果不知道的话，可以填 bucket 的默认域名。
AWS_S3_ENDPOINT_URL = env("AWS_S3_ENDPOINT_URL") #  你的阿里云 Endpoint URL，比如 https://oss-cn-beijing.aliyuncs.com

AWS_S3_ADDRESSING_STYLE = "virtual" # 阿里云只支持二级域名的形式
AWS_S3_SIGNATURE_VERSION = "s3" # 阿里云只支持 v2 版的签名逻辑

# 配置默认使用 S3 Storage，即使用 OSS 的 URL
STORAGES = {
    "default": {
        "BACKEND": "storages.backends.s3.S3Storage", # 使用 S3  Storage
    },
}

Code language: PHP (php)

参考上方的配置，添加配置项后，保存，并重启服务器，即可在代码中进行测试。

测试代码

你可以执行 python manage.py shell 并执行如下代码，如果无报错，且可以在 OSS 控制台看到文件，则说明你的配置成功了。


from django.core.files.storage import default_storage
from django.core.files.base import ContentFile
content = ContentFile(b"Hello World!")
path = default_storage.save('test_file2.txt', content)
print(f"文件保存路径: {path}")
# 测试文件读取
if default_storage.exists(path):
    with default_storage.open(path, 'r') as f:
        content = f.read()
        print(f"文件内容: {content}")
# 测试文件URL生成
url = default_storage.url(path)
print(f"文件URL: {url}")
# 测试文件删除
default_storage.delete(path)
print(f"文件是否存在: {default_storage.exists(path)}")

Code language: PHP (php)

一些我自己用的还不错的 Chrome 插件

4条回复

英语/日语翻译：沉浸式翻译

我的日常要看到很多英文文章和网站，因此，可以借助沉浸式翻译，帮助我快速翻译多种语言为中文，从而降低我在阅读不同语言内容的障碍。

快速搜索：超级搜索

超级搜索支持我快速的选中词汇并进行搜索，对于一些特定的场景下，会非常有帮助。比如我在浏览网页的时候，发现了一部电影，想快速在豆瓣电影中找到并标记，就可以借助超级搜索，配置一个搜索关键词来实现。

SEO 检查器：AITDK

AI TDK 是我用来检查自己的网页是否完成了一些基本的 SEO 设置的工具。当我上线了一个新的网站后，就会打开 AITDK，然后查看哪里的信息还不完整，需要补充的。就可以继续去补充相应的内容。

JSON 查看：JSON Viewer

在开发的时候，经常会有要查看服务端返回的 JSON 的情况，借助 JSON Viewer 可以将不容易看明白的 JSON 给格式化了，方便你快速定位要看的 JSON。

广告拦截：AdGuard

广告拦截我选择了 AdGuard，有了它，我看 Youtube 再也没有广告了。。。

复制为 Markdown：Copy as Markdown

因为经常要将部分内容复制为 Markdown，方便在我的其他工具中使用，所以我安装了这个 Copy as Markdown 插件，方便自己随意复制。

页面增强：篡改猴

当我需要对一些网页做一些快速的改造，但同时又不想写成 Chrome 插件的时候，就会选择写成油猴脚本，然后放在篡改猴里来用，非常方便。

灵感记录：Memos

我自己部署了一个 Memos ，用于记录自己的灵感和想法。因此，我使用了一个 Chrome 插件，来方便我记录。

记一次发现小宇宙 iOS 版的跳转注入漏洞

1 条回复

漏洞风险：可以在其他应用借助小宇宙端内跳转任何网页。

此文章发布前，小宇宙已经修复了这个问题，所以你们可能不能复现这个问题了。

先看漏洞效果，这个漏洞的问题是你可以在小宇宙里跳转到任何网站，甚至是 PornHub。不过这个 Bug 不重要，重要的是发现 Bug 的过程。

漏洞效果

0. 背景

在一天晚上，我在和朋友聊小宇宙的 URL Scheme，想要做个功能，可以实现一键打开小宇宙的节目页面。但卡在我面前的是，我不知道小宇宙的 URL Scheme 到底是什么。于是便开始了我的 Hack 之旅，也就找到了小宇宙的这个安全漏洞。

1. 找到小宇宙的 URL Scheme

由于 Scheme 是在 App 中定义的，所以当我想到要找 Scheme 之后，第一反应的是去拿 iOS App 的 Info.plist（因为 iOS 是将 Scheme 定义在 info.plist 当中）。

过去需要通过 IPA 备份、越狱等方式来获取到这个文件，不过得益于 M 系列支持在 macOS 上运行的原因，现在 IPA 的获得变得非常的简单。先在 App Store 安装小宇宙，并在「应用程序」中找到小宇宙。

然后右键点击小宇宙，点击「显示包内容」

然后看到这样的内容，WrappedBundle 是一个假的应用程序，所以继续点击 Wrapper 往里跳转。

然后会发现里面还有一个 Podcast 应用，这个才是真正的小宇宙的 IPA 包。然后继续点击「显示包内容」

在包内容当中可以看到 info.plist 文件，使用 Xcode 或者 VSCode 打开 info.plist 文件。

在 info.plist 文件中，搜索 CFBundleURLSchemes ，找到了小宇宙的 URL Scheme（里面有很多个，但很多都是其他应用的，试一下就可以发现）：cosmos://。

2. 找到 URL Scheme 能够打开的页面

找到了 URL Scheme，只能通过 cosmos:// 打开应用首页，无法满足我的需求，于是开始继续寻找可能的 URL Scheme 。一般来说，这个时候就只能继续反编译 IPA 包或者 APK 包了。不过对于我来说，这些不是一个好的选项（成本太高）。

然后想到，小宇宙的网页似乎是提供了打开客户端的能力，所以可以从网页版找到突破口。通过简单的搜索，果然让我在网页前端找到了突破口。找到了 7 个 Scheme 。

当然，中间存在一些重复的 Scheme。所以最终梳理出来的 Scheme URL：

cosmos://page.cos/discover:打开发现页
cosmos://page.cos/shownotes/EPISODE_ID：打开节目的 Shownote 页面
cosmos://page.cos/episode/EPISODE_ID：打开节目的详情页
cosmos://page.cos/webView?url=：意义不明，看起来像是打开一个特定的 URL
cosmos://page.cos/web?url=:意义不明，看起来像是打开一个特定的 URL

3. 发现问题 URL Scheme

前面的三个很正常，但后面的两个带 URL 的引起我的注意 —— as a Hacker，你知道的，任何一个可能的输入框都可能成为我们的注入点，于是乎，我就构建了一个链接，来打开我的 Blog

cosmos://page.cos/web?url=https%3A%2F%2Fwww.ixiqin.com
Code language: JavaScript (javascript)

将这个链接使用 Safari 打开，就会自动唤起小宇宙，并打开我的播客。

至此，我发现了小宇宙这个跳转注入漏洞，并快速将其反馈给小宇宙官方同学。

复盘：如何规避这样的问题

在这个 Case 当中，小宇宙因为没有设置 URL 跳转的白名单，导致实际上出现了跳转恶意网站的风险。理论上，作为应用提供商，出于安全合规的视角，最好是控制 URL 跳转的域名和空间，避免被恶意滥用。

或者也可以参考我们现在见到的很多网站，在外部跳转时加一个风险提醒。

如果在这个 Case 当中，小宇宙在一开始就限制了可以打开有限域名，那也不会出现如今我这次的漏洞问题。

这个问题风险大么？

取决于如何定义和如何使用。如果只是跳转一些常规网站，自然是风险不大的。但如果不受限制的，比如跳转到一些诈骗网站，可能风险就是大的。

如何修改 Advanced Media Offloader 使其可以批量将历史文件上传至对象存储？

发表评论

Advanced Media Offloader 提供了 Bulk Offload 功能，可以实现将历史的文件上传到对象存储中，从而降低本地的存储压力，使得站点自身变得无状态。

但其默认的 Bulk Offload 功能每次只能加载 50 个图片，如果附件太多，则需要点击 N 次，十分麻烦。

不过，可以通过简单的修改，来实现一次上传，将多个图片进行 Offload。

在 WordPress 后台的插件管理器中，找到 Advanced Media Offloader 插件，并将includes/BulkOffloadHandler.php文件打开，找到其中的 get_unoffloaded_attachments 函数，修改函数定义中的 $batch_size = 50 为你想要的大小即可使其一次批量加载多个文件了。

修改后效果：

WordPress 使用 Caddy 完成静态化缓存

4条回复

在使用 Caddy 处理 WordPress 当中，我提到在用 Caddy 处理 WordPress，且为了性能做了很多优化。

我的博客经历了三重优化：最基础的 PHP OpCache + Redis 数据查询缓存 + 静态化缓存。

其中一个比较有效的，便是在整个站点上加入静态化缓存，绝大多数游客看到的其实是预先生成好的静态页面，从而减少了数据库加载、渲染、计算的成本。

而想要实现静态化，则需要借助于 Cache Enabler 插件和 Caddy 配置来完成。

安装插件并启用

安装 Cache Enabler 插件，并启用插件，启用后，在后台设置中，配置过期时间和对应的清除策略，并保存。这个时候，Cache Enabler 就会自动帮你去生成不同的页面了。

配置 Caddy 路由转发

首先，你应该在你的 php_fastcgi unix//run/php/php-fpm.sock 前面加入缓存的代码并重启 Caddy，具体如下

缓存配置如下

     @cache {
		not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
		not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
		not method POST
		not expression {query} != ''
    }

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}
    }
       
Code language: JavaScript (javascript)

这部分配置先定义了一个 @cache 块，用于后续判断，并在其中加入了多种条件判断，说明了不使用缓存的情况：

如果用户有以下 Cookie，就不使用缓存：
- comment_author（评论作者）
- wordpress_[a-f0-9]+ （WordPress 的会话 Cookie）
- wp-postpass（密码保护文章的 Cookie）
- wordpress_logged_in（登录状态的 Cookie）
如果当前请求命中了以下路径则不缓存
- /wp-admin/（后台管理页面）
- /xmlrpc.php（XML-RPC 接口）
- 所有 wp-*.php 文件（WordPress 系统文件）
- /feed/（RSS 订阅）
- sitemap 相关文件
POST 请求不缓存（比如评论）
带查询参数的缓存不请求。

随后，通过 route @cache 定义了命中缓存部分的查找顺序：

先找 HTTPS 版本的缓存：/wp-content/cache/cache-enabler/{host}{uri}/https-index.html
再找普通缓存：/wp-content/cache/cache-enabler/{host}{uri}/index.html
如果找不到缓存，就尝试原始路径：{path}
最后尝试 PHP 文件：{path}/index.php?{query}

查看效果

打开一个无痕窗口，访问你的网站，如果在 html 底部看到  ，则说明你已经成功启用静态化缓存了！

参考资料

如果你使用 WP Supercache 、 WP Rocket、WP Fastest cache、W3 Total Cache，则可以参考 https://caddy.community/t/example-configure-wordpress-with-a-static-cache/8215 进行相关配置。