去年年底我把一个原本需要“一个前端 一个后端 一个运维”的中型项目压成了一个人 三组 AI Agent 一套现代工具链从需求到上线全程自研自维。做这件事的过程中最深的体会是单人研发的瓶颈从来不是写代码的速度而是上下文切换的成本、知识遗忘的损耗以及没有人帮你做 Code Review 的孤独感。AI 全栈的意义不在于“打字更快”而在于把过去需要三个人分工才能维持的工程纪律压缩进一套可编排的 Agent 工作流里让一个人也能守住架构边界。这篇文章不是概念层面的讨论是实操记录。我会把整套方案的技术选型、多 Agent 编排逻辑、从零到上线的完整过程以及踩过的十几个坑原原本本拆开来讲。适合正在尝试用 AI 做独立开发、或者想给团队引入 AI 辅助研发流程的人参考不管你是前端出身想补后端还是后端出身想碰前端这套模式都能让你少走不少弯路。1. 单人研发困境与 AI 全栈思路的重构1.1 传统全栈在单人场景下为什么走不通先聊聊一个反常识的事实很多人以为“全栈工程师”就是什么都会写其实真正的全栈难点不在语言和框架而在工程纪律。我在纯手工状态下做过一个 SaaS 项目前端要管状态、路由、权限、响应式后端要管 Schema、鉴权、缓存、限流部署上还要操心 CI、日志、回滚。一个人连续开发两个月后最明显的感受是写新功能的速度尚可但凡是修改旧代码就要花大量时间回忆当初为什么这么写。代码注释和文档写得再好也赶不上记忆衰退的速度。更麻烦的是专业切换的损耗。从 React 组件思维切到 SQL 优化思维再从 Docker 配置切回业务逻辑每次切换大约要消耗 15 到 30 分钟进入状态。一天下来真正高效的时间可能只有三四个小时其他时间都花在了“回想”和“切换”上。这就是传统全栈模式在单人场景下最致命的问题不是能力不够是带宽不够。于是我开始思考一个问题能不能把一些环节外包给 AI让它不只是“帮我补全代码”而是承担一部分原来属于团队成员的工作比如梳理需求、审查代码、维护测试策略、构建部署流水线。1.2 “1 人 AI 全栈”不是口号是工作流重构后来我接触到多 Agent 的思路才意识到问题的解法不是找一个更强的 AI 对话窗口而是把研发流程拆成可并行、可验收、可追溯的若干环节每个环节交给一个专职 Agent由我充当架构师和最终决策者。这个思路其实借鉴了传统团队的分工模型有人负责理解需求、有人负责写实体和迁移、有人负责 UI、有人负责测试和部署。区别在于这些“人”是我在配置文件里定义的 AI Agent它们的上下文是隔离的输入输出是结构化的质量门禁是可自动执行的。这样一来单人研发的核心矛盾就变了我不再需要精通每一个技术细节只需要掌握“如何拆解需求、如何验收 Agent 产出、如何把模块拼接起来”。这个转变非常关键。以前我花大量时间在写代码上现在我把更多精力放在设计接口契约和定义验收标准上。接口定得越清楚Agent 的产出就越稳定验收标准写得越具体返工成本就越低。从实际效果看这套模式让我在一周内完成了过去需要三周才能做完的一个 MVP而且代码结构比我自己手写时更整洁因为每个 Agent 都只关注自己职责范围内的内容不太会出现“顺手写一堆无关逻辑”的情况。2. 技术选型背后的工程决策React19、Elysia 与 DevOps 工具链2.1 为什么前端选择了 React 19先交代一下选型背景。我原来的项目是 Vue 技术栈后端用 Node.js 的 Express部署直接扔在云服务器上手动操作。这次重构我选择了 React 19原因主要有三个都不是因为“它新、它酷”而是实打实地减少了单人开发的维护成本。第一个原因是 React 19 的 Server Components 和 Server Actions。这两个特性真正落地后很多原来必须写在客户端的逻辑可以直接放到服务器端执行。比如表单提交以前要写 API 接口、写前端请求、写 loading 状态、写错误处理现在用 Server Action 直接在组件里调用服务器函数框架帮你处理序列化和传输。这意味着我少写大量胶水代码而且 AI Agent 在生成这类代码时也更不容易出逻辑错误因为样板代码变少了。第二个原因是编译器优化。React 19 集成了 React Compiler很多原本需要手写的 useMemo、useCallback 优化会被自动处理。这一点对 AI 辅助开发特别友好AI 生成的代码如果少写了性能优化相关的 hooks编译器在构建时会自动做记忆化处理不至于一上线就出现性能问题。人工审查的压力小了很多。第三个原因是生态的确定性。React 19 虽然新但整个数据 fetch、缓存、状态管理的方案已经收敛到 use()、useEffect、Server Components 这几条主路径上不像早期 React 那样存在大量互相打架的第三方方案。对 Agent 来说“最佳实践”越统一生成的代码越可靠。我用下来最直观的感受是让 Agent 写一个 React 19 的数据请求方案它给出的代码风格基本一致不像以前写 React 16 时代组件时有 N 种写法十个输出十个样。2.2 为什么后端选择了 Elysia Bun后端选型我走了点弯路。一开始用的是 Hono因为它文档全、社区大但用了一阵子发现AI Agent 在生成 Hono 代码时经常给出不同风格的路由写法一会儿用工厂模式一会儿用类装饰器给我审查增加了不少负担。后来切换到 Elysia情况明显改善。Elysia 是跑在 Bun 上的 TypeScript 后端框架它的核心卖点是端到端类型安全。通过类似 zod 的 Schema 定义Elysia 能从路由输入到输出自动推导类型前端调用时也能享受到类型提示。这个特性在单人 AI 的场景下价值巨大以前前端和后端是两个人通过接口文档对齐现在接口类型是自动生成的Agent 写的前端调用代码如果参数不对TypeScript 编译器直接报错根本走不到运行时才发现问题。省掉了大量“联调”环节而联调恰恰是单人开发最不想面对的环节。另外一个重要的点是性能。Bun 的运行时确实快启动速度从 Node.js 的几百毫秒降到几十毫秒。对于本地开发来说改完代码立刻重启服务的体验非常爽。对 CI 来说构建时间也明显缩短。我现在的流水线从提交代码到部署完成大约 6 分钟之前用 Node Express 的时候是 12 分钟左右翻倍差距还是能感知到的。2.3 DevOps 工具链的收敛不过度设计我做 DevOps 有一个原则单人场景下任何需要花超过半小时去理解的工具直接淘汰。这不是说那些工具不好而是它们的维护成本会摊薄你写业务的时间。这次我最终选择了 GitHub Actions Docker Fly.io 的组合整套 CI/CD 逻辑不超过 200 行 YAML。GitHub Actions 负责自动化测试、镜像构建和部署触发。Docker 负责一致性封装本地跑什么线上就是什么。Fly.io 负责便宜且简单的托管一个容器直接跑起来自带全球节点、自动 HTTPS、日志聚合和监控面板。我没有引入 Kubernetes也没有自建监控系统因为这些在单用户量阶段就是给自己上刑。如果未来流量增长需要扩展Fly.io 本身支持水平扩容Docker 镜像的结构也能平滑迁移到更复杂的基础设施不会被困死在一家云厂商。技术栈整体收敛下来核心就一句话用最少的工具覆盖研发到上线全链路每个工具都必须能被 AI Agent 快速理解和生成配置。像 Dockerfile、GitHub Actions workflow、Elysia 路由、React Server Components 这些AI 都训练过大量样例生成的代码质量比较可信。而像 K8s、Terraform 这种配置领域AI 生成的内容虽然也能跑但一旦调参知识密度不够排错成本全落在人身上不符合单人研发的经济性。3. 多 Agent 协作架构怎么把团队分工搬进代码库3.1 Agent 的角色定义与上下文隔离多 Agent 体系最关键的设计不是 Agent 数量而是角色边界。我把整个研发流程拆成了六个角色每个角色拥有独立的上下文文件和输出规范互不干扰类似于传统团队里不同岗位的职责分离。第一个是架构 Agent负责理解需求和产出技术方案第二个是数据 Agent负责数据库 Schema、迁移脚本和查询优化第三个是接口 Agent负责 Elysia 路由和类型定义第四个是界面 Agent负责 React 组件和页面实现第五个是测试 Agent负责单元测试和集成测试第六个是运维 Agent负责 Dockerfile、CI 配置和部署脚本。每个 Agent 都有自己的知识库文件路径类似docs/agents/里面写清楚了它的职责范围、输入要求、输出格式和禁止事项。这样设计有几个好处。一是上下文不会爆炸每个 Agent 只加载自己需要的那部分文档和源码不会把整个项目塞进上下文窗口。二是产出可验收每个 Agent 的输出都是独立的模块我可以单独审查单独要求重写不用牵一发动全身。三是并行可控比如数据 Agent 在写迁移脚本的时候界面 Agent 已经可以基于 TypeScript 类型定义开始画 UI 了两者不需要等待彼此。下面是一个简化的 Agent 编排配置文件示例我用的是 JSON 格式描述 Agent 之间的关系{ agents: [ { name: schema-agent, role: database schema and migration, input: docs/requirements/current-feature.md, output: src/db/schema/*.ts, gate: pnpm db:check, context_files: [docs/agents/schema-agent.md, src/db/schema/index.ts] }, { name: api-agent, role: elysia routes and contracts, input: src/db/schema/index.ts, output: src/api/routes/*.ts, gate: pnpm typecheck, context_files: [docs/agents/api-agent.md, src/api/routes/_template.ts] }, { name: ui-agent, role: react components and pages, input: src/api/routes/*.ts, output: src/app/**/*.tsx, gate: pnpm typecheck pnpm lint, context_files: [docs/agents/ui-agent.md, src/app/layout.tsx] }, { name: test-agent, role: unit and integration tests, input: src/api/routes/*.ts, src/app/**/*.tsx, output: tests/**/*.test.ts, gate: pnpm test, context_files: [docs/agents/test-agent.md] }, { name: ops-agent, role: dockerfile, ci, deployment, input: package.json, fly.toml, output: .github/workflows/ci.yml, Dockerfile, gate: pnpm build, context_files: [docs/agents/ops-agent.md] } ] }这个配置文件本身也被我放进了项目根目录。每次启动新的功能开发我只需更新需求文档然后按顺序调度对应 Agent让上一步的输出成为下一步的输入。这样做的好处是工程进度是可跟踪的不会出现“聊了一个小时代码没落几行”的情况。3.2 协作流程任务下发、执行、验收、回滚流程分四条阶段走理解、设计、执行、验收。理解阶段我亲自和架构 Agent 讨论需求产出技术方案这个环节不能省因为 AI 有时候会误解业务意图。设计阶段架构 Agent 输出接口契约、数据模型和页面清单以 Markdown 文档存到docs/design/目录。这个文档是给人和机器共同看的里面每一项都有唯一编号例如API-001: POST /api/notes 创建便签后面 Agent 在实现代码时会在注释里引用这些编号方便我反查。执行阶段就是按顺序调用数据 Agent、接口 Agent、界面 Agent。我给每个 Agent 设定的规则是只改自己职责范围内的文件其他文件只读。这样可以避免出现“界面 Agent 顺手改了数据库 Schema”这种混乱局面。验收阶段是整套机制的灵魂。每个 Agent 的产出必须通过对应的质量门禁才算是完成。质量门禁包括类型检查、单测、构建、Lint 和自定义脚本例如检查是否在代码中硬编码了密钥。如果质量门禁失败该 Agent 的任务自动标记为“待返工”重新进入执行队列。这套机制让我在不需要实时盯着的情况下也能保证每个模块的质量底线。3.3 上下文管理与小步提交策略多 Agent 协作中一个容易被忽视的问题是上下文管理。我见过不少人用 AI 写代码聊着聊着就让它改了几十个文件最后代码乱成一团根本没法 review。为了避免这种问题我给每个 Agent 设定了小步提交的硬性约束每次任务改动不得超过 5 个文件且必须附带可运行的测试或构建成功证明。这个约束在工程上很有价值。因为 Agent 一旦改动范围变大它的上下文就装不下完整信息很容易在某处产生隐蔽的破坏。而小步提交能让每次改动都被 Git 记录成清晰的一次提交回滚时可以精确到单次任务。我现在的提交历史看起来非常规整一条 commit 对应一个需求编号例如feat(API-001): create note endpoint这在后来自查或者写周报时都方便极了。4. 一次完整实操从需求拆解到生产部署的全流程记录4.1 需求描述与架构 Agent 的方案输出说这么多不如直接走一个例子。我最近在手写项目里加了一个“标签聚合统计”的功能需求是用户在笔记详情页可以看到标签分布点击标签可以筛选出该标签下的全部笔记。这个功能看起来简单但涉及聚合查询、列表筛选、路由跳转和 UI 状态保持足够完整地展示多 Agent 流水线的工作方式。我把需求写成一段话丢给架构 Agent要求它输出技术方案。它的回复经过我整理后形成了下面这个方案数据模型新增note_tags表字段为id,note_id,tag_name,created_at建立复合索引(tag_name, note_id)提升筛选性能。接口设计新增GET /api/tags返回标签及数量新增GET /api/notes?tagxxx实现按标签筛选。页面改动详情页右侧增加标签聚合列表列表页读取?tag参数作为初始状态。测试策略覆盖聚合统计的正确性、空标签处理、分页边界。架构 Agent 给出方案后我并不是直接照单全收。我注意到它建议的复合索引顺序是正确的但它没有考虑已有notes表的大批量数据迁移成本。于是我追加了一条约束迁移脚本必须先执行数据回填再创建外键约束防止线上数据出现悬挂引用。这个补充动作很重要说明架构 Agent 虽然能给出通用方案但业务现场的约束条件还是要靠人来补充。4.2 数据 Agent 与接口 Agent 的具体产出方案确定后先唤醒数据 Agent。它负责的方式是读取需求文档和现有 Schema生成 Drizzle 迁移文件。以下是它生成的核心 Schema 代码import { pgTable, serial, integer, varchar, timestamp } from drizzle-orm/pg-core; export const noteTags pgTable(note_tags, { id: serial(id).primaryKey(), noteId: integer(note_id).notNull().references(() notes.id, { onDelete: cascade }), tagName: varchar(tag_name, { length: 64 }).notNull(), createdAt: timestamp(created_at).notNull().defaultNow(), });这个 Schema 定义中onDelete: cascade是数据 Agent 主动加上的因为当笔记被删除时对应的标签关联记录如果不一起删除就会成为孤儿数据。这种细节以前需要我自己想清楚现在数据 Agent 能注意到说明它的知识库中确实包含了常见数据库约束的最佳实践。我只需要在验收时确认这个行为是否符合业务预期。接口 Agent 随后读取这个 Schema生成了 Elysia 路由。以下是一个关键的路由片段import { Elysia, t } from elysia; import { db } from ../db; import { noteTags, notes } from ../db/schema; import { desc, eq, sql, and } from drizzle-orm; export const tagRoutes new Elysia() .get(/tags, async () { const result await db .select({ tagName: noteTags.tagName, count: sqlnumbercount(*), }) .from(noteTags) .groupBy(noteTags.tagName) .orderBy(desc(sqlcount(*))); return result; }) .get(/notes, async ({ query }) { const { tag } query; if (!tag) { return await db.select().from(notes).orderBy(desc(notes.createdAt)); } return await db .select() .from(notes) .innerJoin(noteTags, eq(noteTags.noteId, notes.id)) .where(eq(noteTags.tagName, tag)) .orderBy(desc(notes.createdAt)); }, { query: t.Object({ tag: t.Optional(t.String()), }), });这段代码用了 Elysia 的验证器语法通过t.Object声明了查询参数的结构如果前端传入非字符串的tag请求会自动返回 422 错误不需要我在代码里手动判断。这种基于 Schema 的边界约束极大减少了非法输入对业务逻辑的干扰也是 AI 生成代码时不容易出错的点。4.3 界面 Agent 与 React 19 的结合实现界面 Agent 拿到接口类型定义后开始实现 React 页面。它选择了 Server Component 架构列表页的初始数据在服务器端渲染时通过use()直接读取接口返回值前端只需要负责标签点击后的客户端状态更新。下面是关键组件代码import { use, useOptimistic, useState } from react; import { useRouter, useSearchParams } from next/navigation; import type { Note } from /api/types; export function TagFilter({ tags, notes }: { tags: Tag[]; notes: Note[] }) { const router useRouter(); const searchParams useSearchParams(); const activeTag searchParams.get(tag) ?? ; const [optimisticNotes, setOptimisticNotes] useOptimistic(notes); function handleTagClick(tagName: string) { const nextTag tagName activeTag ? : tagName; const params new URLSearchParams(searchParams.toString()); if (nextTag) { params.set(tag, nextTag); } else { params.delete(tag); } router.push(/notes?${params.toString()}); } return ( aside ul {tags.map((tag) ( li key{tag.tagName} button >deploy: runs-on: ubuntu-latest needs: [test, build] steps: - name: Deploy to Fly.io uses: superfly/flyctl-actions1.5 with: args: deploy --config fly.toml - name: Health check run: | curl -f --retry 5 --retry-delay 5 \ https://your-app.fly.dev/health || exit 1这里有个细节值得强调我在 workflow 里加了一个健康检查步骤部署完成后如果/health接口没有返回 200任务会被标记为失败并触发回滚。这个步骤对于单人开发者来说是保险丝防止出现“部署成功了但服务是坏的”这种最棘手的情况。以前我全靠手动 curl 检查现在交给 CI 自动完成省心不止一点。整个流程从需求下发到部署完成总耗时大约一天其中大部分时间花在等待 Agent 生成代码和人审上。如果按纯手写的速度这个功能我至少需要三天。而且这次因为每个环节都有质量门禁代码质量比我自己手写时更可预期。5. 单人 AI 研发模式下的常见问题与避坑经验5.1 上下文溢出与“AI 开始胡编”的应对办法使用多 Agent 流程最常遇到的问题是单个 Agent 上下文一长就开始输出低质量代码甚至出现幻觉比如引用了不存在的依赖包、生成了与项目风格完全不符的代码。我踩过最严重的一次是接口 Agent 在迭代中突然引入了一个没有安装的 npm 包elysiajs/cors导致构建失败我排查了半小时才反应过来是它自己预判了依赖。应对这个问题的办法有两层。第一层是严格限制 Agent 的单次任务范围让上下文始终保持精炼。具体做法是在任务描述里明确禁止引入新依赖除非在需求文档中显式声明。第二层是给 Agent 配备“事实核查”提示词要求它在输出代码前列出修改的文件清单和新增依赖清单如果没有新增就直接声明“无新依赖”。看起来不起眼但能有效降低 AI 幻觉。5.2 接口契约漂移前端类型和安全后端的失守第二个高频问题是接口契约漂移。AI 在独立写前端和后端时常常出现“后端返回的字段名前端完全对不上”的情况。引入 Elysia 的端到端类型推导后这类问题明显减少但并没有完全消失。因为 Agent 有可能同时改了两边的类型定义导致类型检查虽然通过但实际业务语义发生了变化。我的做法是在 CI 中增加一个“契约检查”脚本专门比对src/api/routes/*.ts中定义的类型和src/app/**/*.tsx中实际使用的 props 类型如果发现不一致就失败。这个脚本的灵感来源于 OpenAPI 的契约测试理念但实现成本很低不需要额外工具就是用 TypeScript 自身的类型断言加一些正则扫描。实践效果非常明显基本阻断了接口漂移隐患。5.3 测试失效与“假绿”现象另一个常见坑是测试假绿。AI 生成的测试代码有时看起来覆盖率很高但实际都在测 mock 数据没有真正验证核心逻辑。比如它可能给聚合统计接口写了个测试断言却只是“返回结果长度为 0”完全没有覆盖统计数量是否正确。我在验收环节加了一条硬性规则每个接口测试必须至少包含三条断言分别覆盖正常输入、边界输入和错误输入。例如对/api/notes?tagxxx的测试正常输入断言返回了正确的过滤结果边界输入断言不存在的标签返回空数组错误输入断言非法参数返回 422。这条规则在 Agent 任务文档中明确写出测试 Agent 才真正开始花心思构造有用的用例。5.4 失败场景速查表下面这张表是我在实际操作中总结的常见失败场景与对应的排查手段基本上覆盖了我遇到过的大部分问题症状可能原因快速排查方式Agent 生成代码引用了不存在的包上下文过长导致幻觉检查最近三次对话是否有依赖变更增加事实核查语句构建通过但接口返回 500数据库查询联表字段名不匹配启用数据库日志查看实际 SQL 语句部署成功但健康检查失败容器启动参数缺环境变量Fly.io 后台查看启动日志核对fly.toml的 env 段测试通过但覆盖率异常低测试 Agent 只测了 happy path检查测试目录验证是否覆盖错误分支前端页面状态丢失React 组件未正确读取 URL 参数检查useSearchParams的位置是否脱离了 Suspense 边界CI 中权限报错缺少 Repository secrets 或 Token 权限不足检查 GitHub Actions secrets确认 flyctl token 未过期这个表格看起来简单但对于单人开发者来说价值很大。因为当你一个人面对一堆日志和报错时最快的处理方式是先判断“这是不是常见问题”而不是从头开始读日志。表格就是我的“排错反射弧”能节省大量无头苍蝇式排查时间。5.5 多 Agent 模式下的架构腐化控制最后聊一个策略层面的问题多 Agent 模式下代码库很容易随着迭代次数增加而逐渐腐化。原因是每个 Agent 只关心自己的任务边界没有人像传统架构师那样盯着整体结构。如果放任不管三个月后你的代码库会变得比手工写的还难维护到处是重复逻辑和妥协方案。我在项目根目录维护了一份名为ARCHITECTURE.md的边界文档里面写清楚了大致的模块划分和禁止跨层调用的规则。同时每次 Agent 任务结束后我都会抽空执行一次“巡逻检查”重点看是否有函数越权访问了不属于它那层的模块。这个检查不需要很频繁一周一次足够但必须坚持。只要边界规则没有被系统性破坏AI 生成的代码就始终处于可控状态。6. 关于这套模式的更多思考与后续扩展6.1 人的角色定义边界、做决策、当最终验收者使用了几个月多 Agent 工作流后我最大的认知变化是AI 全栈不是说“人啥也不干全靠 AI 写代码”而是把人的精力从打字中释放出来集中到更高级的决策上。我现在每天花最多时间的地方是写需求文档、审查 Agent 的技术方案、以及确认最终实现的业务正确性。这些工作在传统开发模式中属于“架构师”和“技术主管”的范畴而现在一个人的团队里也能有这两个角色。有一个小技巧值得分享不要把 Agent 当作工具要把它当作需要“管理”的团队成员。这意味着你要给它清晰的指令、明确的验收标准、以及对错误产出的反馈。AI 和人类协作者一样需要从错误中学习。当我发现某个 Agent 反复犯同类错误时我会把正确的做法补进它的知识库文件例如docs/agents/schema-agent.md里新增一条“所有表必须设置外键级联规则”。这个动作的效果是持续累积的时间越长Agent 的产出质量越稳定。6.2 知识库作为团队记忆这里要多说一点知识库的作用。传统团队里经验分散在每个人的脑子里人员流动会导致知识断层。单人开发虽然没有人员流动但人会遗忘会懈怠。我把 Agent 的知识库当作项目组的“共同记忆库”每次踩坑解决后我都会花几分钟把教训写进对应的 Agent 文档。久而久之这套文档就成了我项目管理最值钱的资产比注释和 README 更有价值。知识库的维护也有方法不能想到什么写什么。我通常只记录两大类内容一类是“必须遵守的工程规则”比如数据库必须设置级联删除、接口响应必须包含统一的错误结构另一类是“常见的失败模式和解决方案”用“现象-原因-修法”三段式描述。这样的知识库不仅 Agent 能用我自己遇到类似问题也能迅速查到答案相当于给自己做了一个私人维修手册。6.3 向更多技术领域的延伸这套模式并不局限于 React、Elysia、DevOps 这个具体组合。只要工程边界划分清晰知识库沉淀到位任何技术栈都可以套用多 Agent 编排思路。比如移动端可以采用 React Native Hono EAS Build 的组合桌面端可以用 Tauri Rust 后端甚至嵌入式开发也可以拆成“驱动 Agent 业务 Agent 构建 Agent”。比较关键的是要理解多 Agent 的本质是把研发流程分治让每一个环节的上下文足够小让每一个产出可以被自动验证。技术栈只是载体载体可以换方法论才是核心。当我下次需要启动一个类型不同、技术栈全新的项目时我会复用这套流程框架只需要更新 Agent 的知识库文件就能让新项目的 AI 协作体系在一天之内跑起来。这也是我目前最想继续深挖的方向让项目从立项到上线全程有 AI 参与、全程可追溯、全程可回滚真正把单人研发的效率边界再往前推一大截。