云数智花园

TECH

AI Loop 本机开发环境实战：Windows + WSL + Podman 从 0 到 1

面向 AI Coding 的本机环境搭建指南。本文从选型决策、架构关系、0-1 搭建到复杂系统扩展，讲清如何让 AI 承担更多执行工作，让人类聚焦选择与决策。

topic: ai-way type: 文章 origin: 原创 score: 8 addedAt: 2026-02-27

修订记录

版本时间说明
v12026-02-27初稿，覆盖 Podman 原理、Desktop 机制与 Windows 实战配置
v22026-02-27重构为 AI Loop 主线：先讲价值与选型，再给 0-1 实操、脚本契约、A3 分工与复杂系统扩展
v32026-02-27收敛开头结论：只保留价值与路径，技术实现约束下沉到后文章节
v42026-03-02补充 Windows + WSL + Podman 重装后的实战坑位：rootful/rootless 视图、代理注入、compose provider、镜像仓库迁移与一键修复路径
v52026-03-02主题归类调整为 AI Coding 主线：topic 调整为 ai-apps，并保留 cloud 标签作为基础设施维度
v62026-03-05内容目录迁移到 ai-way，主题调整为 topic: ai-way

先看结论

如果只想先抓关键结论，记住这 5 点：

  1. AI 时代的效率瓶颈不只在“写代码”，更在“环境启动 + 回归验证”。
  2. 本机算力足够时，本机 DevOps 快环通常比远端共享环境更高效。
  3. 推荐 CLI 主导 + Desktop 辅助，把环境控制面做成脚本契约，才能支撑 AI 稳定循环。
  4. A3 阶段的目标是：AI 负责可判定执行，人类负责判断、取舍和发布决策。
  5. 本文提供一条从 0 到 1 的可落地路径，并可扩展到 Hadoop + MySQL + PostgreSQL 的复杂场景。

实现细节（如连接上下文、rootful/rootless、依赖分层）会放在后文“原理、扩展与排障”章节展开，不在开头打断主线。

阅读导航

  1. 为什么先做本机 AI Dev Loop
  2. 选型与取舍：为什么是 Windows + WSL + Podman
  3. 架构图：人、AI Agent、代码、环境、测试怎么协作
  4. A3 成功标准与职责边界
  5. 从 0 到 1：把运行面搭起来
  6. 建立脚本契约：让 AI 可稳定执行
  7. 前端点击验证：AI 什么时候做，人什么时候接管
  8. 扩展到复杂系统：Hadoop + MySQL + PostgreSQL
  9. Podman 原理速通：关键概念一次讲清
  10. 高频故障速查与落地规范

1. 为什么先做本机 AI Dev Loop

很多团队已经把代码生成速度提升了，但迭代总时长并没有同步下降。原因是开发链路里还有三类慢点：

  1. 依赖环境启动慢，且跨项目互相污染。
  2. 测试链路断裂，尤其是“后端通过但前端关键路径未验证”。
  3. 回归失败后定位慢，日志和上下文经常不一致。

本文目标不是“换个容器工具”，而是搭建一套本机可复用的 AI Loop：

  1. AI 能自动执行可判定任务（启动、测试、回归、日志归因）。
  2. 人类从重复执行中脱身，主要做目标定义与决策判断。
  3. 在进入最终测试或生产环境前，尽量把大多数问题在本机快环内消化。

2. 选型与取舍：为什么是这条路线

2.1 宿主系统：为什么是 Windows

这台开发机是 Windows（i9 + 64GB），本机算力足够承载较完整的开发与验证链路。对这种硬件条件来说，“在本机快速拉起依赖并回归”有明显收益：

  1. 减少等待共享环境与排队资源。
  2. 降低网络波动对迭代节奏的影响。
  3. 提高问题重现与定位速度。

如果你使用 macOS，整体方法同样成立，差异主要在工具安装与虚拟化实现细节。

2.2 容器引擎：为什么从 Docker 迁移到 Podman

核心原因是 Docker Desktop 的许可证与成本约束；其次是工程收益：

  1. Podman 的 daemonless 设计减少中心进程单点依赖。
  2. rootless 能力在多项目并行开发中更灵活。
  3. Docker 命令与镜像生态兼容度高，迁移门槛可控。

2.3 操作模式：为什么是 CLI 主导 + Desktop 辅助

AI 要高频稳定执行，关键在“可脚本化、可复现、可回放”。CLI 更符合这个目标。Desktop 的价值主要是给人使用：

  1. 可视化观察容器状态和日志。
  2. 连接/上下文快速确认。
  3. 故障定位时的辅助入口。

2.4 路线对比（简版）

路线优势风险/限制适配 A3
CLI 主导 + Desktop 辅助最利于 AI 自动化，链路可脚本化需要先建立脚本契约高
Desktop 主导上手直观状态容易依赖手工操作，自动化弱中
多入口混用（CLI/GUI/多 WSL 随机切）短期方便高概率 context 漂移，难排障低

3. 架构关系图：人、AI Agent、代码、环境、测试

下面这张图描述了完整闭环。它本质上就是 AI-Coding 时代的本地 DevOps 快环：

flowchart TB
    H[👤 人类: 目标定义 / 取舍 / 发布决策]
    H --> S[📋 Spec 与约束]
    S --> A[🤖 AI Agent]
    A -. 产出 .-> R[📦 代码仓库]
    A --> K[📜 脚本契约: up / test / logs / down / reset]

    K --> F[⚡ 快通道: WSL 直接执行<br/>L1 lint · L2 单元测试]
    K --> C[Core: MySQL / PG / Redis]
    K --> X[Extended: Hadoop 等]
    C --> P[App: API / Web / Worker]
    X --> P
    P --> G[🐳 全通道: 容器验证<br/>L3 集成测试 · L4 E2E]

    F --> T[✅ 验证结果汇总]
    G --> T
    T -- 自动反馈 --> A
    T -. 需人类干预或放行 .-> H
    H -. 随时审查代码/脚本/运行状态 .-> A

图里有四个重点：

  1. 人类输入从”执行命令”变成”定义目标、做判断、做放行”，并可随时审查 AI 产出。
  2. AI 通过脚本契约驱动环境与测试，而不是直接自由操作每个命令。
  3. 验证分双通道：快通道（L1+L2 在 WSL 直接跑，秒级反馈）和全通道（L3+L4 走容器，分钟级但环境可信）。
  4. 复杂依赖分层运行，快环与全量回归拆开执行。

4. A3 成功标准与职责边界

A3 的目标是：AI 可以稳定完成执行闭环，人类做最终判断。

4.1 验证分层

层级内容默认执行者是否可自动判定
L1lint/typecheck/formatAI是
L2单元测试/契约测试AI是
L3集成测试（真实 DB/依赖）AI是
L4前端关键路径脚本化点击AI是（关键路径）
L5体验、价值、风险判断人类否

4.2 人机分工

AI 负责：

  1. 启停环境、执行测试、收集日志、尝试小步修复。
  2. 生成可审计的变更说明和回归结果。

人类负责：

  1. 需求取舍、架构选择、风险评估、发布放行。
  2. 对不可判定问题做最终判断。

4.3 强制交接条件

出现以下任一情况，AI 应停止自动修复并交给人类：

  1. 同类错误连续修复失败 3 次以上。
  2. 测试结果反复波动（flaky）且无法稳定复现。
  3. 涉及数据迁移、权限策略、对外协议变更或成本风险。

5. 从 0 到 1：搭建基础运行面（Windows + WSL + Podman）

本章只做最小可用，不追求一次到位。每一步都按“目标 -> 命令 -> 预期输出 -> 失败处理”执行。

5.1 预检查（PowerShell）

目标：确认 WSL 可用、虚拟化正常、发行版状态清晰。

wsl --status
wsl -l -v

预期输出：

  1. WSL2 可用。
  2. 至少有一个开发发行版（如 Ubuntu）。

失败处理：

  1. 先安装或修复 WSL，再继续容器环境搭建。
  2. 避免在 WSL 未就绪时直接初始化 Podman machine。

5.2 初始化 Podman machine

podman machine init --cpus 8 --memory 24576 --disk-size 200
podman machine start podman-machine-default
podman machine list

预期输出：

  1. podman-machine-default 状态为 running。

失败处理：

  1. 若 machine 已存在，跳过 init，直接 start。
  2. 若启动失败，先检查 wsl -l -v 中该发行版状态。

5.3 固定默认连接（避免 context 漂移）

podman system connection list
podman system connection default podman-machine-default-root
podman system connection list

预期输出：

  1. Default 指向 podman-machine-default-root（或你团队统一约定的连接）。

5.4 首次验收

podman info
podman version
podman run --rm quay.io/podman/hello
podman ps -a

预期输出：

  1. podman info 正常返回。
  2. hello 容器可拉起并退出。
  3. podman ps -a 可看到最近运行记录。

5.5 C 盘空间保护（可选但推荐）

Windows 下 machine VHDX 默认可能在系统盘，建议尽早迁移到非系统盘。

podman machine stop podman-machine-default
wsl --export podman-machine-default E:\temp\podman-machine-default.tar
wsl --unregister podman-machine-default
wsl --import podman-machine-default D:\WSL\podman-machine-default E:\temp\podman-machine-default.tar --version 2
podman machine start podman-machine-default

6. 建立可复用脚本契约（AI 可执行的接口）

如果没有稳定脚本接口，AI 只会变成“会敲命令的人”，而不是可重复执行的工程助手。

6.1 最小脚本集合

建议至少定义以下入口：

  1. scripts/dev/up.sh：启动 core 依赖与应用。
  2. scripts/dev/test.sh：执行 L1-L4 验证。
  3. scripts/dev/logs.sh：按服务聚合日志。
  4. scripts/dev/down.sh：停止但不删数据。
  5. scripts/dev/reset.sh：清理并重建（高成本动作）。

6.2 契约规则（关键）

  1. 所有脚本必须返回明确退出码（0 成功，非 0 失败）。
  2. 输出中要有可被 AI 和 CI 解析的关键字段（例如 PASS/FAIL、失败服务名）。
  3. reset 不应作为默认动作，防止每轮循环都重建全量依赖。

6.3 与 Spec-Coding / TDD 的对应关系

  1. Spec-Coding：先定义需求、边界和验收条件，再让 AI 实现。
  2. TDD：先有可判定测试，再进入实现与修复循环。
  3. 脚本契约：把“方法论”固化为统一执行入口，避免环境操作随意发散。

7. 前端点击验证：AI 什么时候合适，什么时候需要人类

你的判断是对的。前端验证不应只靠人工点，也不能完全取消人工判断。

7.1 推荐分工

AI 适合：

  1. 关键路径脚本化点击（登录、核心表单、核心查询）。
  2. 回归冒烟执行和失败截图归档。
  3. 失败后根据日志与截图做小步修复尝试。

人类适合：

  1. 体验质量判断（交互节奏、可读性、业务语义是否正确）。
  2. 高风险场景确认（金额、权限、关键数据展示）。
  3. 发布决策与异常兜底策略。

7.2 建议把前端验证也纳入脚本契约

npm run test:e2e:smoke
npm run test:e2e:critical

AI 默认执行 smoke；critical 和最终验收由人类决定是否触发。

8. 扩展到复杂系统：Hadoop + MySQL + PostgreSQL 的分层策略

在开发过程中，确实没必要每次都重启所有依赖。建议采用双层策略：

  1. core：MySQL、PostgreSQL、Redis、应用服务，默认常驻。
  2. extended：Hadoop 等重依赖，按需启用。

8.1 Compose 分层示意

services:
  mysql:
    image: mysql:8.4
  postgres:
    image: postgres:16
  app:
    build: .
    depends_on: [mysql, postgres]

  hadoop-master:
    image: your-hadoop-master:latest
    profiles: ["extended"]

8.2 运行策略

# 快环：日常开发
podman compose up -d

# 全量：需要验证大数据链路时
podman compose --profile extended up -d

只在以下场景使用 reset：

  1. 基础镜像或依赖大版本升级。
  2. schema/初始化脚本发生破坏性变更。
  3. 环境污染已影响结果可信度。

9. Podman 原理速通：关键概念讲清楚

9.1 daemonless 的含义

Podman 不依赖长期常驻的中心 daemon。命令触发后按需执行，这让本地多项目场景更灵活，也减少了“一个 daemon 挂掉影响全部容器”的风险。

9.2 rootful 与 rootless

二者不是“好坏之分”，而是两个不同运行上下文：

  1. rootless：容器进程以普通用户运行，默认隔离更强，权限更小。
  2. rootful：容器进程以 root 上下文运行，更容易拿到端口、网络、特权能力。

在 WSL + Podman machine 里，这通常对应两条连接：

  1. podman-machine-default（user socket，rootless）。
  2. podman-machine-default-root（root socket，rootful）。

所以你在 rootful 下创建的容器，不会自动出现在 rootless 视图里。
Desktop 空列表的高频原因，不是容器没了，而是 GUI 正连在另一个上下文。

9.3 connection/socket 决定“你能看到什么”

Podman Desktop、Windows 终端、WSL 终端可能连接到不同 socket。容器“消失”多数不是丢失，而是看到了另一个上下文。

9.4 Podman Desktop 的真实定位

Desktop 是管理面，不是运行时。它很适合观察与排障，但自动化执行仍应以脚本与 CLI 为主。

10. 高频故障速查（症状 -> 检查 -> 修复）

10.1 Desktop 空列表

podman machine list
podman system connection list
podman ps -a

重点看 Default 连接是否正确，machine 是否 running。

10.2 端口映射存在但 Windows 访问不到

  1. 看容器是否 Up。
  2. 看服务进程是否已监听内部端口。
  3. 分别做主机探测和容器内探测。

一个很常见的“误判点”是：你以为自己在测 Windows 访问，其实是在测 WSL 访问；或者反过来。建议用一个最小烟雾测试把问题切开。

最小烟雾测试（建议用 rootful 默认连接）：

podman run -d --name test-nginx -p 28080:80 docker.io/library/nginx:alpine
podman ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
podman port test-nginx

然后分两侧验证：

# Windows 侧：优先用 127.0.0.1，避免部分环境下 localhost 先走 ::1（IPv6）导致“看起来连不上”
curl.exe -I http://127.0.0.1:28080/
# 或：
Test-NetConnection 127.0.0.1 -Port 28080 | Select-Object -ExpandProperty TcpTestSucceeded
# WSL 侧：如果你开启了 mirrored 网络模式，WSL 内用 127.0.0.1/localhost 访问暴露端口可能会超时
# 这不是“容器没启动”，而是访问路径变了。用 WSL 的网卡 IP 测更稳。
WSL_IP="$(ip -4 -br addr show eth9 | awk '{print $3}' | cut -d/ -f1)"
curl -I "http://${WSL_IP}:28080/"

如果你发现：

  1. Windows 侧 127.0.0.1:28080 正常，但 WSL 侧 127.0.0.1:28080 超时，而 WSL 侧 ${WSL_IP}:28080 正常：大概率是 WSL 的 networkingMode=mirrored 导致的行为差异。此时要么改脚本/验收到“按所在侧选地址”，要么把 WSL 网络模式切回 NAT。
  2. Windows 侧 localhost:28080 不稳定但 127.0.0.1:28080 正常：优先把客户端配置（浏览器/代理/脚本）从 localhost 换成 127.0.0.1 规避 IPv6 优先级差异。
  3. Windows 侧 127.0.0.1:28080 也超时，同时你看到 WSL 提示“使用镜像网络模式时，wsl2.localhostForwarding 设置无效”：说明你当前的 WSL 镜像网络模式不支持（或不启用）Windows <-> WSL 的 localhost 端口转发。此时如果你的目标是“Windows 浏览器访问容器端口”，建议直接切回 NAT。

清理烟雾容器：

podman rm -f test-nginx

10.3 compose 偶发失败

podman compose down
podman network ls
podman compose up -d

先清残留再重建，不要直接怀疑业务代码。

10.4 C 盘空间持续增长

检查 VHDX 所在路径与大小，必要时迁移至非系统盘。

10.5 重装后 podman machine start 失败（端口漂移 / user-mode networking）

症状：

  1. podman machine start 报错，提示 machine 没进入 running。
  2. 日志中出现 detected port conflict、machine did not transition into running state。
  3. podman-net-usermode 相关启动链路失败。

检查：

podman machine list
podman machine inspect podman-machine-default
podman --log-level=debug machine start

最小修复（先恢复可用）：

podman machine set --user-mode-networking=false podman-machine-default
podman machine start

再固化默认上下文：

podman machine set --rootful=true podman-machine-default
podman system connection default podman-machine-default-root
podman system connection list

10.6 Windows 有代理，但 Podman machine 拉镜像失败

典型症状：

  1. Windows 代理是 127.0.0.1:7078（例如 Clash）。
  2. Podman machine 继承该代理后，podman pull 失败：connect 127.0.0.1:7078 refused。

原因：

  1. 127.0.0.1 在 Windows、WSL、Podman machine 是不同网络命名空间。
  2. Windows 本地回环代理地址不一定在 machine 内可达。

建议策略（避免破坏全局代理）：

  1. 不改 Windows/WSL 全局代理。
  2. 只在 Podman 作用域设置可达代理（例如 172.x.x.x:7078）。
  3. 用“命令级代理”或 Podman 服务级 drop-in，不污染其他开发链路。

10.7 重装后 podman compose 提示找不到 provider

症状：

  1. podman compose ... 报 looking up compose provider failed。
  2. 提示找不到 docker-compose / podman-compose。

修复：

podman machine ssh --username root "python3 -m ensurepip --upgrade && pip3 install podman-compose"

10.8 Bitnami 官方标签缺失（manifest unknown）

症状：

  1. docker.io/bitnami/kafka:2.8.1、docker.io/bitnami/mysql:8.0 等标签拉取失败。

原因：

  1. 部分历史标签迁移或下架，bitnami/* 与 bitnamilegacy/* 存在差异。

修复建议：

  1. 在 compose 中优先改用可用镜像源（例如 docker.io/bitnamilegacy/kafka:2.8.1、docker.io/bitnamilegacy/mysql:8.0）。
  2. 不再依赖临时本地 tag 映射作为长期方案。

10.9 serjs/go-socks5-proxy:latest 启动即退出

症状：

  1. 日志报 REQUIRE_AUTH is true, but PROXY_USER and PROXY_PASSWORD are not set。

修复：

  1. 若用于内网调试，显式设置 REQUIRE_AUTH=false。
  2. 若用于共享环境，改为配置用户名密码并启用认证。

11. 给团队的最小落地规范

  1. 统一默认连接（明确 rootful 或 rootless，避免混用）。
  2. 统一脚本契约（up/test/logs/down/reset）。
  3. CI 与本机复用同一套脚本，保证行为一致。
  4. 默认跑快环（core），按需跑全量环（extended）。
  5. 明确人工放行门槛，避免“自动化通过 = 可以发布”的误判。

12. 结语

这套路线的目标不是“让 AI 取代人”，而是让 AI 取代重复执行，让人类集中在选择和决策。
当环境可脚本化、验证可判定、边界可治理后，AI 才能稳定承担越来越多工作，团队才能在快速迭代中保持质量与可控性。

参考链接

  1. Podman Desktop 官方文档：https://podman-desktop.io/docs
  2. Podman 官方文档（machine）：https://docs.podman.io/en/latest/markdown/podman-machine.1.html
  3. Podman 官方文档（system connection）：https://docs.podman.io/en/latest/markdown/podman-system-connection.1.html

评论