夜雨聆风今天上午，我们把一个很小的需求交给 AI 编程助手：补两组单测，修一处 lint，再把接口返回字段同步到前端页面。
需求本身不难。真正卡住的是第一步。
它按 README 执行 npm test，提示 Node 版本不对；换到 Python 服务跑 pytest，又缺系统依赖；页面改完想跑 E2E，Playwright 浏览器依赖不完整；接口测试依赖 Postgres 和 Redis，但这两个服务一直是同事手工在本机开着。
看起来是 AI 没把任务做完，实际是项目环境先把它拦住了。
这件事很容易被低估。以前新人接项目，环境跑不起来还能问旁边同事一句：“这个库是不是要先装？”“Redis 端口是不是改过？”“第一次启动是不是要先 migrate？”但 AI 编程助手能看到的只有仓库、配置、命令和日志。
如果环境没有写给机器看，它就只能在错误里打转。
第一次误判：以为是模型不行
刚开始大家的反应很自然：是不是提示词写得不够清楚？是不是应该把任务拆得更细？是不是 AI 对业务上下文理解不够？
后来把日志摊开看，问题并不在业务代码。
npm test | ||
pytest | ||
这张表里没有一个问题属于“模型不会写代码”。它们都是开发环境没有工程化。
AI 编程助手进入团队后，真正改变的是执行方式：它不只是给建议，而是会读代码、改文件、跑命令、根据测试结果继续修。只要它开始运行命令，团队里原本靠经验维持的环境细节就会变成硬门槛。
环境要从“人能理解”变成“机器能复现”
过去 README 写给人看，很多步骤可以含糊一点。
比如“安装依赖后启动项目”，人会知道先切 Node 版本；比如“启动数据库”，人会想起本机已经有一个 Postgres；比如“跑 E2E”，人会知道浏览器依赖之前装过。
但对 AI 来说，这些都不是信息。它只会按显式步骤执行。
所以团队要让 AI 编程助手稳定接任务，第一步不是研究更复杂的提示词模板，而是把最小开发环境固定下来：
.env.example | ||
package.json | ||
一句话：把“只有老同事知道”的步骤，写成机器能执行的配置。
先准备一个最小可用环境
这不是要把开发环境做得很重。真正需要的是“最小可复现”。
例如一个 Node 项目，可以先从这样的 devcontainer.json 开始：
{
"name": "ai-ready-dev",
"image": "docker.1ms.run/node:22-alpine",
"forwardPorts": [3000],
"postCreateCommand": "npm ci"
}如果项目依赖数据库、缓存、对象存储，就不要只写在 README 里。直接用 Compose 把依赖服务声明出来：
services:
app:
image: docker.1ms.run/node:22-alpine
postgres:
image: docker.1ms.run/postgres:16
redis:
image: docker.1ms.run/redis:7这段配置不是生产部署，也不是完整模板。它的意义是让开发者、AI 编程助手和 CI 至少站在同一套环境描述上。
给 AI 派任务前，先跑环境预检
我们后来把“让 AI 改代码”前置成两步：
第一步，先确认环境能起来。
第二步，再让它改业务逻辑。
环境预检可以很简单：
docker compose -f compose.dev.yaml pull
docker compose -f compose.dev.yaml up -d
npm run lint
npm test如果这几步不过，就不要急着让 AI 继续改代码。先把错误归类：是镜像没拉下来，依赖没装上，服务没 healthy，还是测试本身失败。
在镜像供应链这一层，我会先把常用基础镜像固定 tag 后预拉一遍：
docker pull docker.1ms.run/node:22-alpine
docker pull docker.1ms.run/python:3.12-slim
docker pull docker.1ms.run/postgres:16
docker pull docker.1ms.run/redis:7毫秒镜像（1ms.run）适合放在这里：它解决的是开发容器、依赖服务和测试运行时镜像能不能稳定拉下来。它不是 AI 编程工具，也不替代测试、代码审查和权限边界。
这个边界要讲清楚。否则文章很容易写偏，好像用了某个镜像入口，AI 就能自动交付。事实不是这样。镜像预检只是在任务开始前排掉基础设施噪音，让后续失败更容易定位到真正的代码问题。
一张给团队的检查表
如果团队准备让 AI 编程助手开始接小任务，可以先检查这 10 项：
.env.example | |
latest | |
这张表比“提示词怎么写”更基础。
因为 AI 编程助手不是一个坐在你旁边的新同事。它没有你们团队的口头经验，也不知道哪台机器上曾经装过什么。你不给它可复现环境，它就会在第一步反复撞墙。
结论
AI 编程助手进入团队后，最先要标准化的不是提示词，而是开发环境。
让它能用同一套容器跑起项目、拉起依赖服务、执行测试和 lint，后面才谈得上让它改接口、补测试、修页面、提 PR。
环境越靠口口相传，AI 越像“不好用”；环境越能被配置、命令和日志表达，AI 越有机会真正参与工程交付。
这就是今天这篇文章想说的核心：AI 要先跑起来，才能谈写得好不好。
