我如何使用 AI Coding Agent 构建小型 Demo

为什么我不把 AI Coding Agent 当成自动程序员

最开始用 AI Coding Agent 时，我试过把一个完整需求直接丢给它，让它从头到尾写完。

结果通常有两种：要么它写出一堆看起来能跑但结构混乱的代码，要么它在实现过程中自作主张改了我本来不想动的部分。

后来我意识到，AI Coding Agent 最适合放在执行环节：我先想清楚要做什么，再让它帮我快速落地。判断、决策和验收这些环节，还是得由我来做。

所以我现在的做法是：把工作拆成几个阶段，让 Agent 只在合适的位置发挥作用。

我的基本分工

我目前用三个角色来划分工作：

判断模型 - 负责理解需求、拆解问题、决定做什么和不做什么。这个角色通常是我自己，偶尔会用 Claude 或 GPT 帮我梳理思路，但最终判断由我来做。

执行 Agent - 负责写代码、改文件、跑命令。Claude Code、Codex、Antigravity 都可以承担这个角色。关键是给它明确的边界：只改这些文件，只做这件事，不要动其他东西。

验收官 - 负责检查执行结果是否符合预期。包括本地 build、页面预览、功能验证、git status 检查。这个角色必须是我自己，不能交给 Agent。

一个 Demo 的最小工作流

我最近构建的几个 AI Demo（企业需求澄清 Agent、销售助理订单协同 Agent、相亲嘴替）都遵循类似的流程。先想清楚问题边界：给谁用、输入输出是什么、哪些功能必须有。这些不需要写成完整 PRD，但在给 Agent 写指令之前要自己想清楚。技术上的选择也在这一步确定：小型 Demo 我通常用 React 或 Vue，后端放在 Cloudflare Workers 或 Pages Functions，AI 接入直接调用 API，不做复杂编排。

执行阶段交给执行 Agent，给它明确的文件范围（只改这几个文件）、功能目标（实现这一个功能）、约束（不要改 UI 样式，不要加新依赖）。每次 Agent 完成一轮执行，我会跑 npm run build 确认没有编译错误，再跑 npm run preview 在本地看效果，然后检查 git status 确认没有意外修改。如果 build 失败，先看错误信息判断是 Agent 的问题还是配置问题，再决定是让它修还是我自己修。本地验收通过后才部署到线上，部署后再检查一遍：页面能打开、功能能用、没有明显样式问题。

如果 Agent 的执行结果不满意，用 git 回滚到上一个 commit，重新给指令。如果要把项目交接给另一个 Agent（比如从 Claude Code 换到 Codex），先写一份简短的交接文档：项目结构、当前状态、下一步要做什么。

我踩过的坑

Agent 自作主张改 UI

有一次我让 Agent 实现一个 API 接口，它顺手把页面布局也改了。改完之后 build 能过，但页面样式全乱了。

后来我学乖了，每次给指令都会明确说”只改这几个文件，不要动 UI”。

一次性上下文太长

有一次我把整个项目的历史、需求、技术栈全塞进一个 prompt，结果 Agent 输出的内容前言不搭后语。

现在我会把上下文拆成多轮对话，每轮只聚焦一个具体问题。

没有先 commit 导致回滚困难

有一次 Agent 执行完之后，我发现结果不满意，想回滚，但之前没有 commit，git status 显示一堆改动，分不清哪些是 Agent 改的，哪些是我之前改的。

现在我会在 Agent 每次执行前先 commit 一个干净状态，这样回滚起来很清晰。

把 Mock 和真实 API 混淆

有一次我在本地用 Mock 数据测试通过了，部署后发现真实 API 返回的数据结构和 Mock 不一样。

现在我会尽早接入真实 API，哪怕只测一个接口，也比 Mock 靠谱。

当前我采用的原则

现在最稳定的原则还是把任务拆小。每轮只做一个目标，不让 Agent 一次实现三个功能；执行前先让它读相关文件，确认理解现状；执行后先在本地 npm run build，不要在本地还没通过的情况下直接部署。

方向判断也要留在自己手里。执行 Agent 只负责写代码，不负责决定做什么。每完成一个可验收的功能，就 commit 一次，留下干净的回滚点。这个习惯看起来麻烦，但在 Gemini Flash 改坏主页 UI、About 内容和导航逻辑之后，我对这件事的理解变得很具体：没有干净基线，后面所有修复都会变成猜谜。

后续还需要改进的地方

后面还需要把交接文档写得更稳定一些。Antigravity 额度中断后，我临时写了一份交接文档切到 Codex 接手，这件事本身就说明：只靠聊天上下文不够，新的 Agent 需要看到项目状态、已完成的修改、不能动的文件和下一步边界。

验收环节也还有很多手动部分。现在主要靠 build、preview、线上检查和 git status，对于小 Demo 够用，但还谈不上自动化。prompt 模板也是类似的问题，每次都要重新组织语言，复杂项目里分工边界仍然容易写得不够清楚。这些不会一次解决，只能在后续项目里慢慢补。

这些改进方向会随着后续项目实践逐步补充。