别再满足“AI 写几行代码”了：把 IDE、终端、浏览器交给 AI 调度，跑通软件开发全流程

很多人卡在一个阶段：

• AI 能写函数、能改 bug、能补注释 ✅
• 一到“做成一个能上线的东西”，就开始掉链子 ❌

原因很直白：真正的软件开发不是写代码，是一堆环节的串联。

这篇给你一个可落地的玩法：

把 IDE、终端、浏览器都当成 AI 可以调用的工具。你负责“想清楚 + 审查”。AI 负责“执行 + 交付”。

你会得到一套能复用的开发流水线：从需求到 PR，从测试到部署，从文档到回滚预案。

你要的不是“会写代码的 AI”，而是“会交付的 AI”

“AI 做个小功能”很像在餐厅点了个小菜。

“AI 做全流程交付”是让它把菜单、采购、烹饪、上菜、洗碗都打包处理。

全流程交付里，最容易翻车的点通常不是语法，而是：

• 需求没定清，做着做着变成另一件事
• 没拆任务，AI 一口气写一坨，改不动
• 不写测试，跑起来像抽盲盒
• 不了解现网环境，部署直接炸
• 没文档，后面自己都维护不下去

所以这套方法的核心是：让 AI 在工具链里工作，而不是在聊天框里自嗨。

工具准备：把 AI 的“手脚”接上

你需要三类能力：

• 改代码：IDE / 编辑器
• 跑命令：终端
• 验收效果：浏览器（最好可自动化）

方案 A：省事组合（推荐）

• Cursor（或 VSCode + Continue）
  • 好处：Agent 模式能读项目、改文件、运行命令
• Claude Code / Codex CLI / Gemini CLI（选一个）
  • 好处：直接在仓库里做事，适合重活
• Playwright
  • 好处：浏览器自动化验收，能截图、能跑 e2e

你用哪个模型都行。关键不在“模型智商”，在“工作流有没有护栏”。

方案 B：团队工程化组合

• GitHub Actions / GitLab CI
• Docker / Compose
• 测试：pytest / vitest / jest
• 代码质量：eslint / ruff / prettier

这套更像“公司版本”。好处是稳定，坏处是搭起来比写功能还烦。

目录结构建议：让 AI 不迷路

AI 最怕的不是难，是找不到入口。

给项目加一个 docs/ 或 spec/，放 3 个文件就够了：

• docs/requirements.md：需求（人写）
• docs/architecture.md：结构（人审）
• docs/dev-playbook.md：工作方式（给 AI 的规矩）

docs/dev-playbook.md 可以直接抄这段

# 开发规矩（给 AI）

- 不允许直接改动超过 300 行而不解释原因。
- 每个改动必须附：影响范围、回滚方式、验证步骤。
- 新增功能必须带测试（单测或 e2e 二选一）。
- 修改前先搜索仓库已有实现，避免重复造轮子。
- 有不确定的需求点，必须提问，不允许自作主张。

你会发现：AI 一旦有规矩，产出质量立刻变正常人。

全流程怎么跑：把“开发”切成 6 个可交付物

别让 AI 一次性写完整项目。

你给它“交付物”，它就知道怎么做。

交付物 1：需求确认（可测试的那种）

你想要的是“能验收”的需求，不是“听起来不错”的愿景。

写需求时就按这个格式：

• 目标用户：谁用
• 核心流程：点哪儿、看到啥
• 约束：必须/不能
• 验收标准：怎么证明做完了

给 AI 的指令模板：

你现在是产品+测试。
根据下面想法，输出：
1) 用户故事（最多 5 条）
2) 验收标准（Given/When/Then）
3) 明确列出你需要我确认的问题（不少于 3 个）

想法：{你的想法}

交付物 2：技术方案（能落地的结构图）

别让 AI 写“宏大叙事”。你要它给：

• 模块拆分
• 数据结构
• API 列表
• 风险点（尤其是边界条件）

指令模板：

你是架构师。
根据 requirements.md，给出一个可实现的方案：
- 目录结构
- 关键数据模型
- API/函数签名草案
- 错误处理策略
- 你认为最容易翻车的 5 个点
输出必须短句、可执行。

交付物 3：任务拆分（给 AI 干活用的工单）

拆得好，AI 就像外包团队；拆得烂，AI 就像喝醉的天才。

一张好工单要包含：

• 改哪些文件
• 新增哪些文件
• 具体命令怎么跑
• 验证步骤

指令模板：

把这个方案拆成 8~15 个任务。
每个任务用同样格式：
- 目标
- 涉及文件
- 实现要点
- 验证命令
- 可能的坑
按依赖顺序排列。

交付物 4：实现 + 自测（IDE + 终端）

这里是关键：让 AI 在终端里跑。

你希望它做这些事：

• 安装依赖
• 运行测试
• 跑 lint
• 启动服务
• 修复报错

你盯着它别乱来：

• 任何删除操作都要二次确认
• 涉及配置和部署的改动，必须解释影响

常用指令模板（很管用）：

按任务 {任务编号} 实现。
要求：
- 只做这一件事，别顺手“优化一堆”
- 每次修改后都运行：{命令}
- 报错就贴完整日志并说明原因
- 结束时给我：改了哪些文件 + 如何验证

交付物 5：浏览器验收（Playwright / 手动点点点）

“我本地能跑”不算完成。

你要的是：

• 新功能能被点出来
• 关键路径不会 500
• 边界输入不会崩

给 AI 的验收方式建议：

• 有 UI：上 Playwright，跑 e2e
• 纯 API：加一个 curl 验收脚本

一个简单的 e2e 示例（Playwright）：

import { test, expect } from '@playwright/test';

test('create todo', async ({ page }) => {
  await page.goto('http://localhost:3000');
  await page.getByPlaceholder('Add a todo').fill('buy milk');
  await page.getByRole('button', { name: 'Add' }).click();
  await expect(page.getByText('buy milk')).toBeVisible();
});

交付物 6：上线准备（别把“发布”当复制粘贴）

上线要的不是勇气，是清单。

最实用的上线包：

• CHANGELOG.md：改了啥
• DEPLOY.md：怎么部署
• 回滚方式：怎么回到上一版
• 监控点：哪些指标变了要报警

你可以让 AI 写，但你得审。

指令模板：

为这次改动生成上线包：
- changelog（面向用户）
- deploy 步骤（面向工程）
- 回滚步骤
- 风险提示
要求：每一条都要能照着做。

实战模板：用 AI 从 0 做一个“小而完整”的项目

拿一个很常见的需求当例子：团队共享待办（Todo）。

目标很明确：

• 登录可先不做（用一个固定用户）
• 支持新增/完成/删除
• 前端列表展示
• e2e 测试覆盖新增流程
• Docker 一键启动

你按这个节奏喂给 AI：

1）把需求贴进 docs/requirements.md

最少写这些：

• 页面：列表页
• 行为：新增 todo、勾选完成、删除
• 验收：新增后列表可见，刷新不丢（用 sqlite 或 json 文件都行）

2）让 AI 产出方案 + 任务单

你只需要盯两件事：

• 技术栈别乱选（别今天 Next.js 明天又换 Remix）
• 数据存储别飘（demo 用 sqlite/lowdb 就够）

3）让 AI 按任务实现，并强制它每步都跑命令

典型命令链：

pnpm i
pnpm lint
pnpm test
pnpm dev

或 Python：

uv sync
ruff check .
pytest -q
uv run python app.py

4）用 Playwright 做“新增 todo”的验收

你会明显感觉：

• 没 e2e 时：改一次 UI 就心慌
• 有 e2e 时：AI 改完你敢合并

5）出 PR 文案 + 上线包

PR 描述让 AI 写很舒服，但要加约束：

• “改动点”用列表
• “验证方式”必须可复制
• “风险”必须写出来

你负责什么？AI 负责什么？分清楚就不累

你负责（别甩锅给 AI）

• 需求边界：做什么、不做什么
• 取舍：性能 vs 成本、现在 vs 未来
• 代码审查：安全、可维护性、风格统一
• 上线决策：什么时候发、怎么回滚

AI 负责（放心让它卷）

• 拉项目骨架、补样板代码
• 写测试、补文档
• 迁移文件、批量重构
• 跑命令、贴日志、定位报错
• 生成 PR 描述、变更摘要

一句话：你当导演，它当剧组。 🎬

避坑清单：这些坑踩一次就够了

• AI 一次改太多文件：后果是你根本审不完。设行数上限，分批 PR。
• 没有“验证命令”：AI 会用“我觉得没问题”糊弄你。每个任务都要写验证步骤。
• 让 AI 自己决定技术栈：它很爱炫技。你要的是能交付，不是技术展示。
• 不让 AI 读现有代码就开写：必然重复造轮子。强制它先搜索仓库。
• 把密钥贴给 AI：别干这种事。用 .env.example，真密钥走密管。
• 只测 happy path：边界输入、空值、并发、重复提交，迟早炸。

一套“可复制”的总指令（你可以直接贴给 Agent）

把下面内容当成你项目的默认系统提示：

你在一个真实项目里工作。
目标是交付可上线的功能，不是写示例代码。

工作方式：
- 任何需求不明确的点，必须提问。
- 每次改动控制在可审查范围内（建议 < 300 行）。
- 每个任务都要提供：改动文件列表 + 验证步骤 + 风险 + 回滚方式。
- 写代码必须能运行，必须能通过测试或提供新增测试。
- 需要运行命令时，给出命令和预期输出；失败就贴完整错误日志并分析。

当前任务：{粘贴你的任务单中的一条}

结尾：你会越来越像“用 AI 带团队”

当 IDE、终端、浏览器都能被 AI 调度，你会发现最爽的一点：

• 你不用盯着写样板代码
• 你把精力花在“要不要做、怎么做更稳”
• 你每天能早下班一小时，还不心虚 😄

你要是愿意，把你的项目类型（前端/后端/数据/插件）和技术栈发我，我可以按你的场景给一份“任务拆分 + 验收清单 + 提示词包”。