干货长文预警。很多人让 AI 写代码已经驾轻就熟但让 AI 稳定地产出能上生产的代码是另一回事。这篇文章我拿一个真实例子——RBAC 权限系统用户-角色-权限——把完整工作流拆开每一步为什么这么做、具体怎么做、有什么坑。全流程真实可复用不灌水。先回答为什么你用 AI 越用越乱先别急着看方法先对号入座——你有没有这些感觉AI 写出来的东西不敢合合了怕出问题AI 换个会话就什么都不记得上次定的方案全作废AI 偶尔会把手头代码越改越乱回退都找不到原样大项目让 AI 接手拆不动、接不住。如果你中了两条以上问题不在 AI而在你没有一套流程。先说一个贯穿全文的观点AI 很好用但它的可靠性是挣出来的不是给出来的。AI 有三件事天生做不好验证不了自己写的代码、记不住上次的决策、偶尔会回退或误删。而这篇文章里的每一步本质上都是在补这三个洞。总览我的 AI 开发流水线先记住这张图后面每一步都是它的展开一句话记住它先让 AI 有地可依环境再让它方向不偏设计然后让它每一步可验证TDD最后让代码落袋为安git CI。技术栈很常规你大概率都熟后端Node.js前端Vue3 Vite UnoCSS Naive UIUI 组件由uipro统一规范。选 RBAC 当例子是因为它足够真实——权限做错了是要出事的最考验流程靠不靠谱。第一步搭环境——让 AI 的产出能被验证为什么这是第一步AI 有个致命短板它自己证明不了代码对不对。你让它改一个接口它说改好了但你能不能放心取决于你能不能立刻验证。所以第一步不是写代码而是给 AI 搭一个实验台。怎么做三件套gitAI 敢大胆动手的前提。一切可回退、可对比、可审查coding agent执行器Claude Code、Codex 等负责理解需求、写代码、跑测试test-env用Docker 本地数据构建的开发环境。test-env 有三个硬性要求缺一个都不合格要求含义反例可重建环境坏了删掉一键重建手修了一个下午的数据库确定性每次起来都是同一套初始状态测试数据被人改过测出幻觉 bug隔离AI 在独立环境里随便折腾直连生产库一次误删全完记住这条红线千万不要直连生产库。AI 的一次误操作对生产数据来说是不可逆的——这条写进项目的规矩里比写进人的自觉里更可靠。技术规约也在这里定环境搭好的同时把技术规约定下来它是给 AI 的宪法架构前后端分离apiweb技术栈Node Vue3 Vite UnoCSS Naive UIUI 规范由uipro统一约束组件保证 AI 产出的界面风格一致、组件可复用。目录怎么摆整个示例系统的目录这一步就定死——它决定了 AI 往哪里写代码rbac/├── api/ # 后端Node.js│ ├── src/│ │ ├── routes/ # 接口层用户 / 角色 / 权限 的 HTTP 接口│ │ ├── services/ # 业务层分配角色、权限校验│ │ └── models/ # 数据模型ORM对应 migrations 的表│ ├── migrations/ # SQL 版本管理schema 变更像代码一样走 git│ │ ├── 001_create_user.sql│ │ ├── 002_create_role.sql│ │ ├── 003_create_permission.sql│ │ ├── 004_create_user_role.sql│ │ └── 005_create_role_permission.sql│ └── tests/ # TDD 测试├── web/ # 前端Vue3 Vite UnoCSS Naive UI│ └── src/│ ├── pages/ # 页面│ ├── components/ # 组件由 uipro 统一规范│ └── api/ # 调后端的 HTTP 客户端├── test-env/ # Docker 本地开发环境本地数据│ ├── docker-compose.test.yml│ └── init/ # 按序执行 migrations 灌种子数据└── docs/ # 技术规约、设计文档这一段的关键认知数据模型不只是 ORM 代码还要有migrations/——每处 schema 变更就是一个带序号的 SQL 文件走 git、可回滚、可追溯。schema 也是代码别让它脱离版本控制。api 和 web 怎么衔接很多团队在这里含糊我讲清楚web 永远不直接碰数据库只通过 HTTP 调api的 REST 接口。用户登录后api 签发 JWTweb 之后每个请求都带上 tokenapi 在路由层做权限校验没有权限返回 403。web 侧也有路由守卫、菜单按权限显示这类前端控制但它只是体验优化——真正的安全边界在 api 侧前端可以被绕过api 不能。想通这一点你才知道安全测试该写在哪一层。第二步设计先行——别让 AI 在流沙上盖楼为什么很多人让 AI 上来就写代码这是最大的坑开发完了才发现方向错了前面的投入全白费。AI 每个会话都失忆如果你连设计都靠嘴说它写着写着就偏了。怎么做我坚持先用superpowers把需求和设计确认好再动手用brainstorming把做什么、为什么、边界在哪想清楚产出设计文档架构、数据模型、接口、页面然后才进开发。RBAC 这一步要确认的东西权限点怎么划分、角色能不能叠加、无角色用户怎么办、哪些页面需要哪些权限……这些不确定就开发等于让 AI 在流沙上盖楼。记住这条经验设计阶段多花的时间会在开发阶段成倍省回来。第三步TDD 开发——给 AI 一份需求契约设计确认后进入开发推荐使用TDD做法是按功能点推进一个功能点一套红 → 绿 → 重构。为什么 TDD 对 AI 开发尤其重要因为测试是给 AI 的唯一一份需求契约它不记得开会内容但它能读懂这个函数必须通过这组测试。测试红了它知道要实现测试绿了它知道做完了。RBAC 里最典型的就是权限校验——永远先写测试// 红先写测试此刻实现还不存在describe(requirePermission, () { it(有权限的请求放行, () { withUser({ role: admin }) const handler requirePermission(user:create, () ok) expect(handler()).toBe(ok) }) it(无权限的请求返回 403, () { withUser({ role: viewer }) const handler requirePermission(user:create, () ok) expect(() handler()).toThrowError(/403/) })})测试红了 → 让 agent 实现 → 变绿 → 重构。每完成一个功能点、测试全绿才进下一个。测试不仅是给 AI 的契约也是你后面验收时的依据。第四步代码评审——从三个角度挑刺功能写完不直接验收先过code-review我从三个角度审性能有没有明显的慢操作、N1 查询、无谓的重复计算安全权限校验能不能被绕过、参数校验漏没漏、有没有注入风险功能是否真正满足需求边界场景无权限、重复分配、空角色有没有覆盖。RBAC 的评审重点是安全——权限矩阵是否完备、有没有绕过路径。这个角度错了上线就是事故。一个建议写代码的和审代码的分开。让 AI 审自己的代码等于让运动员兼裁判换一个 agent 来挑刺它没有维护自己产出的包袱能狠得下心。第五步用户验收——需求和代码的唯一对账评审通过后进入用户验收。我把功能点摆给用户看验收通过 → 这个功能点落袋有调整 → 回到开发流程迭代改完再评再验。记住验收是一个循环不是一个终点。它是需求和代码之间唯一的对账动作——评审保证代码写得对验收保证做的东西是想要的两件事不能互相替代。第六步提交 推送——防止 AI回退的最后防线一个很多人在意的细节功能点验收通过就立即提交代码。但这还不够我有个习惯审核通过的功能不仅提交还要推送远程仓库。为什么防止 AI 回退。AI 在后续迭代中可能误改或回退掉已验证的代码——如果只在本地万一丢了就是不可恢复的损失。所以先落袋为安把已验证的代码推上远程作为安全基线。后面 AI 再怎么折腾都有这个基线可以回到原点。hooks 自动推 CI/CD推送之后hooks自动触发 CI/CD 部署push → hook 触发 → 拉代码 → 起 test-env → 跑测试 → 构建 → 部署又一个前后呼应CI 跑的环境就是第一步搭的那套 test-env数据库 schema 是同一套 migrations。验证机制从本地习惯变成了强制流程——这就是生产可部署和原型的分水岭原型靠运气生产靠流水线。第七步上下文管理——给 AI 装持久记忆最后一步也最容易被忽略。AI 会话是失忆的我用wdp-ctx当项目记忆。项目启动建一份profile把会长期不变的东西固化下来至少四类技术规约架构决策、技术栈、UI 规范——AI 照它写才不会越写越偏业务 skills业务规则与方法如权限点怎么命名角色叠加取什么策略——AI 照它判才不会想当然工具 skills项目用哪些技能、各在什么场景调用TDD、评审、画图——AI 照它选才不会用错方法运行方式与已知坑怎么起环境、怎么跑测试、踩过哪些雷——AI 照它执行才不会重蹈覆辙。每个阶段收尾跑一次sum固化进度为快照新开会话用init一键载入无缝接续收工 /wdp-ctx sum# 把今天的进展和决策固化下来开工 /wdp-ctx init # 新会话载入全貌无缝接续记住让决策跨会话存活AI 才真正变成长期的生产力而不是一段用完即弃的对话。推荐阅读原文给 AI 开发找个简单的记忆方案避坑清单这 7 条我踩过坑才总结出来#规则防止什么1验收通过立即提交并推送远程防 AI 回退代码落袋为安2先用 superpowers确认需求和设计再开发防方向错误别开发完才发现做错了3本地数据 Docker开发环境绝不直连生产库防误删、防污染误操作不可逆4上下文当日用品profile 启动建、sum 阶段收尾跑、init 新会话接续防换会话就断片5按复杂度分级选工具简单直接 agent中等走 skill复杂上子代理/工作流防止杀鸡用牛刀 / 拿菜刀砍大树6写和审分开交付前给 AI 戴技术专家/业务专家角色终审防止自说自话堵住盲区7技术图用archify轻量图用Mermaid让图也可验证、可维护你现在就能开始做的 3 件事别想着一步到位从最小闭环开始搭一个最小环境半天一个 Docker test-env 一份技术规约。环境能一键重建这是后面所有步骤的地基挑一个小功能走一遍 TDD一天先写测试 → 让 agent 实现 → 变绿。感受一下每一步有据可依是什么体验项目启动就建一个 wdp-ctx profile每个阶段收尾sum一次。等你要换会话接续时你会感谢这个习惯。最后总结把流程当工作台而不是负担回顾这条完整流水线每一站单独看都不复杂真正的价值在串成一条流水线环境保证能验证设计先行保证方向不偏TDD 保证每一步有据可依评审保证有人挑刺验收保证需求和代码对齐提交推送保证代码落袋为安CI 保证强制验证上下文保证决策不丢。AI 开发不是丢一句话让它写而是用一套流程把 AI 的不可靠性兜住。当你发现 AI 的产出可以被验证、被接续、被审查时它就从玩具变成了真正能部署上生产线的生产力。这套流程用到的工具superpowers设计 TDD、code-reviewer评审、wdp-ctx上下文管理、archify架构图、uiproUI 规范。都是开源或常见的技能/插件你可以按自己的栈替换——方法比工具重要但工具能让方法落地。
干货长文预警。很多人让 AI 写代码已经驾轻就熟但让 AI 稳定地产出能上生产的代码是另一回事。这篇文章我拿一个真实例子——RBAC 权限系统用户-角色-权限——把完整工作流拆开每一步为什么这么做、具体怎么做、有什么坑。全流程真实可复用不灌水。先回答为什么你用 AI 越用越乱先别急着看方法先对号入座——你有没有这些感觉AI 写出来的东西不敢合合了怕出问题AI 换个会话就什么都不记得上次定的方案全作废AI 偶尔会把手头代码越改越乱回退都找不到原样大项目让 AI 接手拆不动、接不住。如果你中了两条以上问题不在 AI而在你没有一套流程。先说一个贯穿全文的观点AI 很好用但它的可靠性是挣出来的不是给出来的。AI 有三件事天生做不好验证不了自己写的代码、记不住上次的决策、偶尔会回退或误删。而这篇文章里的每一步本质上都是在补这三个洞。总览我的 AI 开发流水线先记住这张图后面每一步都是它的展开一句话记住它先让 AI 有地可依环境再让它方向不偏设计然后让它每一步可验证TDD最后让代码落袋为安git CI。技术栈很常规你大概率都熟后端Node.js前端Vue3 Vite UnoCSS Naive UIUI 组件由uipro统一规范。选 RBAC 当例子是因为它足够真实——权限做错了是要出事的最考验流程靠不靠谱。第一步搭环境——让 AI 的产出能被验证为什么这是第一步AI 有个致命短板它自己证明不了代码对不对。你让它改一个接口它说改好了但你能不能放心取决于你能不能立刻验证。所以第一步不是写代码而是给 AI 搭一个实验台。怎么做三件套gitAI 敢大胆动手的前提。一切可回退、可对比、可审查coding agent执行器Claude Code、Codex 等负责理解需求、写代码、跑测试test-env用Docker 本地数据构建的开发环境。test-env 有三个硬性要求缺一个都不合格要求含义反例可重建环境坏了删掉一键重建手修了一个下午的数据库确定性每次起来都是同一套初始状态测试数据被人改过测出幻觉 bug隔离AI 在独立环境里随便折腾直连生产库一次误删全完记住这条红线千万不要直连生产库。AI 的一次误操作对生产数据来说是不可逆的——这条写进项目的规矩里比写进人的自觉里更可靠。技术规约也在这里定环境搭好的同时把技术规约定下来它是给 AI 的宪法架构前后端分离apiweb技术栈Node Vue3 Vite UnoCSS Naive UIUI 规范由uipro统一约束组件保证 AI 产出的界面风格一致、组件可复用。目录怎么摆整个示例系统的目录这一步就定死——它决定了 AI 往哪里写代码rbac/├── api/ # 后端Node.js│ ├── src/│ │ ├── routes/ # 接口层用户 / 角色 / 权限 的 HTTP 接口│ │ ├── services/ # 业务层分配角色、权限校验│ │ └── models/ # 数据模型ORM对应 migrations 的表│ ├── migrations/ # SQL 版本管理schema 变更像代码一样走 git│ │ ├── 001_create_user.sql│ │ ├── 002_create_role.sql│ │ ├── 003_create_permission.sql│ │ ├── 004_create_user_role.sql│ │ └── 005_create_role_permission.sql│ └── tests/ # TDD 测试├── web/ # 前端Vue3 Vite UnoCSS Naive UI│ └── src/│ ├── pages/ # 页面│ ├── components/ # 组件由 uipro 统一规范│ └── api/ # 调后端的 HTTP 客户端├── test-env/ # Docker 本地开发环境本地数据│ ├── docker-compose.test.yml│ └── init/ # 按序执行 migrations 灌种子数据└── docs/ # 技术规约、设计文档这一段的关键认知数据模型不只是 ORM 代码还要有migrations/——每处 schema 变更就是一个带序号的 SQL 文件走 git、可回滚、可追溯。schema 也是代码别让它脱离版本控制。api 和 web 怎么衔接很多团队在这里含糊我讲清楚web 永远不直接碰数据库只通过 HTTP 调api的 REST 接口。用户登录后api 签发 JWTweb 之后每个请求都带上 tokenapi 在路由层做权限校验没有权限返回 403。web 侧也有路由守卫、菜单按权限显示这类前端控制但它只是体验优化——真正的安全边界在 api 侧前端可以被绕过api 不能。想通这一点你才知道安全测试该写在哪一层。第二步设计先行——别让 AI 在流沙上盖楼为什么很多人让 AI 上来就写代码这是最大的坑开发完了才发现方向错了前面的投入全白费。AI 每个会话都失忆如果你连设计都靠嘴说它写着写着就偏了。怎么做我坚持先用superpowers把需求和设计确认好再动手用brainstorming把做什么、为什么、边界在哪想清楚产出设计文档架构、数据模型、接口、页面然后才进开发。RBAC 这一步要确认的东西权限点怎么划分、角色能不能叠加、无角色用户怎么办、哪些页面需要哪些权限……这些不确定就开发等于让 AI 在流沙上盖楼。记住这条经验设计阶段多花的时间会在开发阶段成倍省回来。第三步TDD 开发——给 AI 一份需求契约设计确认后进入开发推荐使用TDD做法是按功能点推进一个功能点一套红 → 绿 → 重构。为什么 TDD 对 AI 开发尤其重要因为测试是给 AI 的唯一一份需求契约它不记得开会内容但它能读懂这个函数必须通过这组测试。测试红了它知道要实现测试绿了它知道做完了。RBAC 里最典型的就是权限校验——永远先写测试// 红先写测试此刻实现还不存在describe(requirePermission, () { it(有权限的请求放行, () { withUser({ role: admin }) const handler requirePermission(user:create, () ok) expect(handler()).toBe(ok) }) it(无权限的请求返回 403, () { withUser({ role: viewer }) const handler requirePermission(user:create, () ok) expect(() handler()).toThrowError(/403/) })})测试红了 → 让 agent 实现 → 变绿 → 重构。每完成一个功能点、测试全绿才进下一个。测试不仅是给 AI 的契约也是你后面验收时的依据。第四步代码评审——从三个角度挑刺功能写完不直接验收先过code-review我从三个角度审性能有没有明显的慢操作、N1 查询、无谓的重复计算安全权限校验能不能被绕过、参数校验漏没漏、有没有注入风险功能是否真正满足需求边界场景无权限、重复分配、空角色有没有覆盖。RBAC 的评审重点是安全——权限矩阵是否完备、有没有绕过路径。这个角度错了上线就是事故。一个建议写代码的和审代码的分开。让 AI 审自己的代码等于让运动员兼裁判换一个 agent 来挑刺它没有维护自己产出的包袱能狠得下心。第五步用户验收——需求和代码的唯一对账评审通过后进入用户验收。我把功能点摆给用户看验收通过 → 这个功能点落袋有调整 → 回到开发流程迭代改完再评再验。记住验收是一个循环不是一个终点。它是需求和代码之间唯一的对账动作——评审保证代码写得对验收保证做的东西是想要的两件事不能互相替代。第六步提交 推送——防止 AI回退的最后防线一个很多人在意的细节功能点验收通过就立即提交代码。但这还不够我有个习惯审核通过的功能不仅提交还要推送远程仓库。为什么防止 AI 回退。AI 在后续迭代中可能误改或回退掉已验证的代码——如果只在本地万一丢了就是不可恢复的损失。所以先落袋为安把已验证的代码推上远程作为安全基线。后面 AI 再怎么折腾都有这个基线可以回到原点。hooks 自动推 CI/CD推送之后hooks自动触发 CI/CD 部署push → hook 触发 → 拉代码 → 起 test-env → 跑测试 → 构建 → 部署又一个前后呼应CI 跑的环境就是第一步搭的那套 test-env数据库 schema 是同一套 migrations。验证机制从本地习惯变成了强制流程——这就是生产可部署和原型的分水岭原型靠运气生产靠流水线。第七步上下文管理——给 AI 装持久记忆最后一步也最容易被忽略。AI 会话是失忆的我用wdp-ctx当项目记忆。项目启动建一份profile把会长期不变的东西固化下来至少四类技术规约架构决策、技术栈、UI 规范——AI 照它写才不会越写越偏业务 skills业务规则与方法如权限点怎么命名角色叠加取什么策略——AI 照它判才不会想当然工具 skills项目用哪些技能、各在什么场景调用TDD、评审、画图——AI 照它选才不会用错方法运行方式与已知坑怎么起环境、怎么跑测试、踩过哪些雷——AI 照它执行才不会重蹈覆辙。每个阶段收尾跑一次sum固化进度为快照新开会话用init一键载入无缝接续收工 /wdp-ctx sum# 把今天的进展和决策固化下来开工 /wdp-ctx init # 新会话载入全貌无缝接续记住让决策跨会话存活AI 才真正变成长期的生产力而不是一段用完即弃的对话。推荐阅读原文给 AI 开发找个简单的记忆方案避坑清单这 7 条我踩过坑才总结出来#规则防止什么1验收通过立即提交并推送远程防 AI 回退代码落袋为安2先用 superpowers确认需求和设计再开发防方向错误别开发完才发现做错了3本地数据 Docker开发环境绝不直连生产库防误删、防污染误操作不可逆4上下文当日用品profile 启动建、sum 阶段收尾跑、init 新会话接续防换会话就断片5按复杂度分级选工具简单直接 agent中等走 skill复杂上子代理/工作流防止杀鸡用牛刀 / 拿菜刀砍大树6写和审分开交付前给 AI 戴技术专家/业务专家角色终审防止自说自话堵住盲区7技术图用archify轻量图用Mermaid让图也可验证、可维护你现在就能开始做的 3 件事别想着一步到位从最小闭环开始搭一个最小环境半天一个 Docker test-env 一份技术规约。环境能一键重建这是后面所有步骤的地基挑一个小功能走一遍 TDD一天先写测试 → 让 agent 实现 → 变绿。感受一下每一步有据可依是什么体验项目启动就建一个 wdp-ctx profile每个阶段收尾sum一次。等你要换会话接续时你会感谢这个习惯。最后总结把流程当工作台而不是负担回顾这条完整流水线每一站单独看都不复杂真正的价值在串成一条流水线环境保证能验证设计先行保证方向不偏TDD 保证每一步有据可依评审保证有人挑刺验收保证需求和代码对齐提交推送保证代码落袋为安CI 保证强制验证上下文保证决策不丢。AI 开发不是丢一句话让它写而是用一套流程把 AI 的不可靠性兜住。当你发现 AI 的产出可以被验证、被接续、被审查时它就从玩具变成了真正能部署上生产线的生产力。这套流程用到的工具superpowers设计 TDD、code-reviewer评审、wdp-ctx上下文管理、archify架构图、uiproUI 规范。都是开源或常见的技能/插件你可以按自己的栈替换——方法比工具重要但工具能让方法落地。
