别再迷信“一句话写软件”:AI 稳定交付全栈项目的 5 步工作流

现在很多人以为装个智能编辑器，丢一句“给我写个系统”，AI 就能交付完美代码。但实际落地时，往往是一堆跑不通的 Bug 和走样的架构。

AI 编程的核心痛点早就不在 Prompt 怎么写，而是如何像架构师一样做好工程化编排。

近期在搭建一个智能客服派单系统（涉及前后端交互和 Redis 状态管理）时，全程使用 AI 辅助。以下是复盘出的 5 步核心工作流，把 AI 从“只会写片段代码的新手”转变为“能稳定交付的研发”。

一、环境搭建与“立规矩”

不要让 AI 上来就写业务代码。第一步是建好 Git 仓库，并在项目根目录创建一个 agent.md。

这个文件是给 AI 看的“全局规约”。除了强制要求“每次改动必须完成 Git Commit”以保留版本快照外，还要把环境配置规范写死。

例如，在 WSL/Ubuntu 环境下跑 Docker 极易遇到宿主机与容器的文件权限冲突，必须在规约里明确要求：AI 在生成 .env 时，配置 CONTAINER_USER=1001，从根源解决权限坑。

二、产品设计：划定 MVP 边界

AI 极度容易“过度设计”。如果让它写客服系统，它可能会立刻塞入多级角色权限控制（RBAC）和多级空闲超时熔断等复杂逻辑。

必须人工做减法：强制要求第一版（MVP）只跑通单队列轮询派单。

砍掉复杂的 RBAC，先用极简方式管理状态，并让 AI 整理输出一份《产品设计文档 MVP 版》。这划定了后续开发的绝对边界。

三、技术方案设计：架构把控

拿着极简的产品需求，让 AI 评估并输出技术方案，但核心技术栈必须由人拍板决定。

在这个客服系统中，可以直接框定后端使用 Java 25 和 Spring Boot 4，前端使用 React 19，数据持久化落地到 PostgreSQL 17，高频的状态流转交给 Redis。

AI 的任务是基于这些既定框架，产出包含接口定义、数据结构和组件流转的《技术方案说明书》。

四、产品实现：赋予 AI 闭环自测能力

很多开发者用 AI 编程时最痛苦的一点，就是不断在终端、IDE 和 AI 对话框之间来回复制报错信息，自己彻底沦为 AI 的“肉身测试员”和“剪贴板工具人”。

破局的技术方案是给 AI 开放真实环境的操作权限。具体操作上，在编程 Agent 中为其挂载操控电脑（Computer Use）和浏览器（Chrome）的插件。

工作流随即改变：当 AI 写完 Spring Boot 的后端逻辑，它可以自己调起终端运行单元测试；写完 React 前端后，它能自己用 Chrome 插件打开 localhost，抓取界面的渲染结果或控制台的网络报错。

遇到问题，AI 会自己读日志、分析原因并原地修复代码。这种闭环让 AI 交付的不再是半成品代码块，而是本地真实跑通的成品。

五、人工验收：不可妥协的底线

AI 的自测只能保证代码编译通过、接口能调通，但它测不出业务直觉。

比如客服突然断线这种极端状态机扭转时，前端页面的延迟感和重连逻辑是否顺滑，AI 是无法感知的。

最终把关必须由人来完成。 亲自启动全栈项目跑通主流程，发现体验异常的地方，再通过局部指令让 AI 针对性微调，直到完全符合预期。

总结

让 AI 稳定干活只需要守住三条铁律：无 Git 不开工，无闭环自测不写码，人工做最终验收。

当把环境权限和边界设计好，AI 才能真正展现出生产力价值。