企业官网建设流程全解析

一句话摘要：以真实项目为主线，用 Claude Code / Codex / Trae / Qoder 等 AI Coding Agent，配合 Superpowers、Anthropic Skills、mattpocock skills，把「需求对齐 → 计划书 → UI 原型 → 前后端开发 → 真实数据联调 → TDD」完整跑了一遍。

关键词：AI Agent、Agent Skills、Claude Code、AI 编程、Spec-Driven Development、RBAC、FastAPI、React 19、TDD、Google Stitch

适合人群：想从传统开发转向 AI 应用开发的后端 / 全栈工程师；想系统了解 Agent Skills 工作流的人。

阅读时间：约 15 分钟

0. 先说结论：这 5 天到底学到了什么

这不是一门「教你调用大模型 API」的课，而是一套用 AI Agent 交付企业级项目的工作流：

1. AI 编程的重心已经从「写代码」转移到「定义问题 + 拆解计划 + 验收结果」。代码由 AI 生成，人负责需求对齐、计划审核、联调验收。

2. Skills 是这套工作流的复用单元。一个 Skill 不只是提示词，而是Prompt + Script + Template + References + SKILL.md的组合，可以全局安装、跨项目复用。

3. 一条可复制的交付流水线：PRD 对齐 → 模块计划书 → UI 原型 → 数据库设计 → 前后端编码 → 真实数据联调 → 测试报告 → Git 提交。

4. 两个真实功能贯穿全程：RBAC 权限管理（认证 + 授权、菜单过滤、操作级控制）和智能助手（选择系统配置的模型与提示词模板进行对话）。

5. 前沿应用已经产品化：AI IDE、终端 Agent、AI 生成 UI、应用内嵌大模型，这些不再是 Demo，而是能直接进项目的工具链。

1. 六份文档 = 一条完整学习主线

原始材料是 6 份 Word 文档，其中「项目的第四天」和「项目第四天」内容互补，实际对应 6 个学习单元。整理后主线如下：

2. Day 1：先换脑子，再换工具

2.1 从 Java 企业级开发到 AI Agent

讲师自己的路径很有代表性：Java 开发 → Java 讲师 → 在线教育创业 → 2023 年 ChatGPT 出现后转向 AI。核心判断是：

• 传统企业级开发（Spring Boot + Spring Cloud + MyBatis）依然重要，负责业务与高并发；

• Python 负责AI 智能体；

• 两者不是替代关系，而是「Java 稳业务 + Python 做 Agent」的组合；

• 相关生态：Spring AI、Spring Alibaba AI、AgentScope。

这对后端同学是个很实际的信号：不用推翻原有技术栈，而是把 AI 能力嵌进去。

2.2 课程方法论：项目驱动 + AI 补齐需求

课程不是从语法讲起，而是：

1. 先给一个可运行的 Demo 项目；

2. 学员基于 Demo 做需求对齐与增强；

3. 再用 AI 补齐需求，落地两个功能：RBAC和智能助手；

4. 最终产物是源码 + 文档。

这里有个很重要的观念：AI 不是用来「凭空造项目」的，而是用来在既有架构上做增强。这更接近真实工作。

2.3 技术栈与项目结构

• 前端：React（或 Vue），项目目录app/

• 后端：Python + FastAPI + SQLAlchemy，项目目录src/

• 权限的两个层次讲得很清楚：

  • 认证 Authentication：登录，确认你是谁；

  • 授权 Authorization：访问控制，确认你能不能执行某个动作。

很多项目只做了登录，没做授权。RBAC 模块的价值就在于补上后半段。

2.4 AI Coding Agent 工具矩阵

文档里记录了一批工具，按定位可以分成三类：

同时提到两个现实问题：大模型 Token 收费较贵、账号存在封禁风险。这决定了学习阶段要善用免费额度，把复杂任务拆小。

2.5 用 AI 解决「项目跑不起来」

第一天最实用的一个练习：拿到项目后双击start.bat失败，因为 Python 需要虚拟环境.venv。于是直接让 AI 排障，提示词大意是：

请帮我启动项目的前后端。要求： 1. 基于 start.bat 这个脚本来启动项目； 2. 启动前后端后进行前后端联调； 3. 联调成功后生成项目启动注意事项文档，Markdown 格式，存到指定文件夹； 4. 全部结束后提交本地 Git，提交消息为： "feat: 这是修复后的第一次提交，由于项目环境进行了移植，因此需要更新一些配置"

这个练习包含了一个完整闭环：排障 → 联调 → 文档 → 提交。这也是后面所有任务的模板。

2.6 学习方法：碎片时间的复利

文档里记录的习惯值得单独拎出来：

• 早上 30~40 分钟读英语、刷推，关注行业大佬；

• 读别人的 Blog，也自己写 Blog；

• 通勤听播客；

• 减少游戏和纯娱乐，把时间投向 AI 相关学习。

本质上是：输入（英文信息源）+ 输出（写作）+ 持续（碎片时间）。

3. Day 2：Skills 才是这套工作流的核心

3.1 Skill 到底是什么

文档给了一个很准确的定义：

Skill = Prompt + Script + Template + References + SKILL.md

它不是一个提示词文件，而是一个可复用的能力包：

• SKILL.md：技能说明与触发条件；

• Prompt：给模型的角色与流程指令；

• Script：可执行的 Python / TS 脚本；

• Template：产出物模板；

• References：参考资料、规范、示例。

这套结构让 AI 的输出更稳定，也让团队经验可以沉淀。

3.2 三个值得收藏的技能仓库

安装方式很直接：

git clone https://github.com/obra/superpowers.git

然后对 AI 说：

"D:\...\superpowers\skills" 请帮我全局安装这个 skill

默认安装位置是C:\Users\<用户名>\.claude\skills。

3.3 需求对齐：先把 PRD 打磨到能开发

原始需求文档是PROJECT_SPEC.md，但项目里没有实现 RBAC 的授权部分。于是用/brainstorming+ 原文档做增强，产出PROJECT_SPEC_v2.md。

目标很明确：

给用户分配角色后，用户就拥有对应权限；登录后左侧菜单要按权限过滤，部分操作也要受控。

关键要求：

1. 只写 PRD，不写代码；

2. Markdown 输出到指定目录，命名为PROJECT_SPEC_v2.md；

3. 生成后提交 Git：feat: 需求进行了2次修改，加入了RBAC授权功能。

最重要的一句经验：文档生成后不要立刻写 plan，而要 review，与 AI 多来几轮头脑风暴。需求阶段的返工成本最低。

3.4 计划书：一个模块一份

用/writing-plans+PROJECT_SPEC_v2.md，让 AI 为每个模块写独立计划书，命名为【模块名称】-plan.md，同样只写文档、不写代码、单独提交。

使用 /writing-plans 这个 skill 并结合 PROJECT_SPEC_v2.md 帮我编写模块的计划书。要求： 1. 每个模块编写独立计划书，命名为【模块名称】-plan.md； 2. 只写计划书，不写代码； 3. Markdown 输出到指定文件夹； 4. 提交 Git："feat: 给每个模块编写了详细的计划书"

到这里，需求 → 计划的链路就完成了，后面才是编码。

4. Day 3：黑盒与白盒，两条实现路径

4.1 黑盒：直接执行计划

/executing-plans + 模块-plan.md + PROJECT_SPEC_v2.md

要求非常硬：

1. 模块开发完必须经过单元测试；

2. 后端使用真实 SQLite 数据，不要 mock；

3. 前端必须真实联调，不要 mock；

4. 联调通过后提交：feat: 【RBAC授权】模块开发完成，进行最终提交。

这条路适合「需求清楚、UI 要求不高」的模块，速度快。

4.2 白盒：先原型，再实现

白盒路径更适合对交互和视觉有要求的模块：

1. /frontend-design生成 UI 原型（静态页面 + 图片 + 原型设计报告）；

2. 用Google Stitch、Open Design、Pencil精修；

3. /frontend-dev+ 原型 + 计划书生成前端代码；

4. /fullstack-dev做数据库设计与后端开发。

原型要求：

• 产物 = 静态页面（HTML + CSS + JavaScript）+ 图片 + Markdown 设计报告；

• 页面必须能独立打开预览；

• 完成后单独提交 Git。

4.3 前端技术栈

文档明确给出了现代前端组合：

React 19 + TypeScript 5.9 + Vite 7 + React Router 7 + Tailwind CSS 4 + Shadcn UI（Radix UI） + Lucide 图标 + React Context（AuthContext）+ useState

项目命名为frontend，放在根目录。开发完先做 mock 测试保证能跑，再进入真实联调。

4.4 数据库与后端

• 开发期数据库：SQLite；

• 生产环境：MySQL 或 PostgreSQL（文档特别提醒了这一点）；

• 产出init.sql（建库建表）和init_data.sql（初始化数据）；

• 生成数据库设计文档，存放docs/design；

• 最终生成.db文件放到sql文件夹。

后端要求：

• 项目名backend，与frontend同级；

• 技术栈：Python + FastAPI + SQLAlchemy，遵循分层思想；

• 每个模块独立单元测试，连接真实数据库，不用 mock；

• 每个模块输出 Markdown 测试报告，存放docs/tests；

• 联调通过后生成启动脚本，方便演示。

4.5 开发环境

• VSCode + Claude Code；

• cc-switch用于切换 Claude Code 配置；

• 网络工具 FIClash + 机场服务（文档记录了「一分机场」「小小机场」等，注意合规使用）。

5. Day 4：给系统加一个「智能助手」

第四个学习单元开始引入新模块：智能助手。

这次用的不是 Superpowers，而是社区很火的mattpocock skills中的/grill-with-docs：

使用 /grill-with-docs 并结合 v2 进行需求对齐。 当前想在项目基础上实现一个全新功能： 实现一个智能助手，可以跟大模型（从本项目中加载）进行简单问答。

grill的意思是「盘问」。这个 Skill 会用文档不断追问你：边界是什么？异常怎么处理？权限怎么控？——通过高强度问答把模糊需求逼清楚。

值得注意的是：新功能不是新项目。它必须与原有技术栈、分层、权限体系完美适配，这是企业开发里最常见的场景。

6. Day 5：TDD + 智能助手 PRD

6.1 复习：两个核心 Skill

文档里有一句大实话：开发人员审核 AI 生成的计划书比较耗时。但这一步不能省，因为计划错了，后面生成得越快、错得越远。

6.2 TDD：先测试，再实现

/test-driven-development + *-plan.md

流程是：生成测试用例 → 再编写业务代码 → 跑通测试。再配合/executing-plans执行计划。

这一天的任务要求依旧是：

1. 前后端代码写完后联调；

2. 后端继续用 SQLite，不用 mock；

3. 严格前后端分离，技术栈与前面保持一致；

4. 完成后提交：feat: RBAC模块中的授权已经实现。

6.3 智能助手 PRD v3

新模块需求写得很具体：

• 用户输入提示词，选择系统里已配置好的大模型，即可对话；

• 用户也可以选择提示词模板，再选择模型，进行对话；

• 前后端技术栈必须兼容现有系统。

产出PROJECT_SPEC_v3.md，提交：feat: 新增【智能助手】模块需求PRD。然后用/writing-plans生成智能助手-plan.md。

这里体现了一个重要的产品思路：模型和提示词是系统配置项，不是写死在代码里的。企业可以把「模型 + 提示词模板」做成可运营的能力。

7. Day 6：把智能助手真正落地

最后一天是完整的工程化落地。

7.1 前端

• /frontend-design+智能助手-plan.md+PROJECT_SPEC生成原型；

• 用 Google Stitch / Open Design / Pencil 精修；

• /frontend-dev生成frontend项目；

• 技术栈：React 19 + TS + Vite + React Router 7；

• 必须做 mock 测试并输出 Markdown 测试报告；

• 提交：feat: 【RBAC授权】模块前端项目已经实现。

7.2 数据库

• 继续 SQLite，生产阶段再切 MySQL；

• 产出script.sql（建库建表）和init.sql（初始化数据）；

• 数据库说明文档放docs/design/db；

• 生成agent.db文件；

• 提交：feat: 【RBAC授权】模块数据库设计已经实现。

7.3 后端

• backend与frontend同级；

• Python 3.13 + FastAPI（异步）+ SQLAlchemy 2.0 异步 ORM；

• 必须做真实数据库连接测试 + 各 API 单元测试；

• 输出后端 API 测试报告（docs/tests）；

• 测试全通过后生成API Doc，供前端联调；

• 提交：feat: 【RBAC授权】模块后端项目已经实现。

7.4 联调与收尾

• 去除前端 mock，访问真实后端；

• 编写联调文档；

• 生成前后端启动脚本，一键演示；

• 最后一步才是 MySQL 切换与生产化考虑。

8. 前沿 AI 应用的 8 个观察

8.1 从「对话式编码」到「Agentic Engineering」

AI 编程已经不只是补全代码，而是：读项目、改多文件、跑测试、提交 Git。工具形态也从 IDE 插件扩展到 CLI Agent（Claude Code、Codex、OpenCode）。

8.2 Skills 是「可复用的组织记忆」

SKILL.md + scripts + templates + references这套结构，把个人经验变成可安装、可分发、可版本管理的资产。社区仓库（superpowers、anthropics/skills、mattpocock）正在形成生态。

8.3 Spec-Driven Development 成为主流范式

先写 PRD，再写 plan，再执行。文档不是形式，而是 AI 的上下文和验收标准。人类的价值集中在需求澄清与计划审核。

8.4 白盒 / 黑盒双路径

• 黑盒：executing-plans直接实现，追求效率；

• 白盒：先 UI 原型再编码，追求可控与还原度。

真实项目里两者会混用，取决于模块风险和视觉要求。

8.5 AI 生成 UI 已经可用

frontend-design生成 HTML 原型，再用Google Stitch / Open Design / Pencil精修，最后交给frontend-dev生成 React 代码。「设计 → 代码」的链路被打通。

8.6 应用内嵌 AI 成为标配

智能助手支持选择模型、选择提示词模板，本质是把 LLM 能力产品化、配置化。这会是未来企业软件的常见模块。

8.7 真实数据测试比 mock 更有价值

文档反复强调「不要 mock，连真实 SQLite」。因为 AI 生成代码最容易在字段、类型、接口契约上出错，只有真实数据能暴露问题。

8.8 成本、账号与合规是现实约束

Token 贵、账号可能被封、网络访问受限。实践策略是：免费额度练手、任务拆小、重要产物本地留档、遵守服务条款与当地法规。

9. 好用的应用清单（按场景）

9.1 AI 编程工具

9.2 Skills 与工作流

9.3 UI 与设计

9.4 技术栈

9.5 推荐组合

• 零成本入门：Trae / Qoder / CodeBuddy + superpowers + SQLite

• 专业开发：VSCode + Claude Code + cc-switch + anthropics/skills

• UI 还原：frontend-design → Google Stitch → Pencil → frontend-dev

• 全栈落地：writing-plans → executing-plans / TDD → fullstack-dev → 真实数据联调

10. 可直接复用的 6 个提示词模板

模板 1：启动并修复项目

请帮我启动项目的前后端。要求： 1. 基于 start.bat 启动项目； 2. 启动后进行前后端联调； 3. 联调成功后生成项目启动注意事项文档，Markdown 格式，存到 docs/ 下； 4. 全部结束后提交本地 Git，消息为："feat: 修复项目环境并完成首次提交"

模板 2：需求对齐（只写 PRD）

使用 /brainstorming 并结合 PROJECT_SPEC.md 进行需求对齐（增强）。 实质是实现【系统管理】中的 RBAC 授权：给用户分配角色后，该用户拥有对应权限； 登录后按权限过滤左侧菜单，并控制操作按钮。要求： 1. 只写 PRD，不写代码； 2. Markdown 输出到 docs/，命名为 PROJECT_SPEC_v2.md； 3. 生成后提交 Git："feat: 需求进行了2次修改，加入了RBAC授权功能"

模板 3：拆模块写计划书

使用 /writing-plans 并结合 PROJECT_SPEC_v2.md 编写模块计划书。要求： 1. 每个模块独立一份，命名为【模块名称】-plan.md； 2. 只写计划，不写代码； 3. Markdown 输出到 docs/plans/； 4. 提交 Git："feat: 给每个模块编写了详细的计划书"

模板 4：TDD 执行

使用 /test-driven-development 并结合【模块】-plan.md 进行开发。要求： 1. 先生成测试用例，再写业务代码； 2. 后端使用真实 SQLite，不使用 mock； 3. 前端完成真实联调，不使用 mock； 4. 输出 Markdown 测试报告到 docs/tests/； 5. 提交 Git："feat: 【模块】开发完成，进行最终提交"

模板 5：生成 UI 原型

使用 /frontend-design 并结合【模块】-plan.md 与 PROJECT_SPEC_v2.md 做 UI 原型。要求： 1. 产物包括静态页面（HTML + CSS + JavaScript）、原型图片、Markdown 设计报告； 2. 全部存放到 prototypes/【模块】/； 3. 完成后提交 Git："feat: 【模块】UI原型开发完成"

模板 6：全栈实现

使用 /fullstack-dev 并结合【模块】-plan.md、PROJECT_SPEC_v2.md 完成后端与数据库。要求： 1. 数据库使用 SQLite，产出 script.sql 与 init.sql； 2. 后端使用 Python + FastAPI + SQLAlchemy，遵循现有分层； 3. 每个模块连接真实数据库做单元测试，输出测试报告； 4. 生成 API Doc 供前端联调； 5. 提交 Git："feat: 【模块】后端开发完成"

11. 踩坑与建议

1. 计划书审核是最花时间的环节。建议按模块拆分、控制单份计划粒度，先 review 再执行。

2. 不要把 mock 当终点。mock 只用于前端独立开发，联调前必须切真实后端。

3. 环境问题交给 AI，但文档要留下。.venv、启动脚本、端口冲突，修完就写进启动文档。

4. SQLite 只适合开发。真实项目上线前切 MySQL / PostgreSQL，注意异步驱动与字段类型差异。

5. Token 成本要管理。优先用有免费额度的工具练手，把大任务拆成小任务，避免一次性塞入整个仓库。

6. 账号与合规风险。遵守工具服务条款和当地法律法规，重要代码与文档本地留档。

7. 隐私与密钥。不要把密钥、手机号、邮箱等敏感信息贴给模型或提交到仓库。

8. Git 小步提交。每个阶段产物（PRD、plan、原型、数据库、前后端、联调）都单独提交，出问题好回滚。

9. Skills 安装位置要统一。默认~/.claude/skills，全局安装后跨项目复用。

10. AI 生成不等于不用懂。看不懂的代码不要合并，至少让 AI 解释关键路径并补测试。

12. 我的 5 条收获

1. 会提问比会写代码更值钱。需求问不清楚，AI 只会更快地生成错误答案。

2. 流程比工具重要。PRD → plan → 原型 → 编码 → 测试 → 联调，这条链路换任何模型都成立。

3. Skills 让经验可复制。把团队规范写进SKILL.md，比口口相传可靠得多。

4. AI 最适合做「增强」而不是「重写」。在既有架构上补齐 RBAC、加一个智能助手，是最高效的落地方式。

5. 全栈能力重新变得重要。当 AI 能同时写前端、后端、SQL 和文档，能判断「哪里不对」的人才是瓶颈。

13. 检索信息（方便以后找我这篇）

主标题：从 Java 到 AI Agent：5 天用 Agent Skills 交付一个带 RBAC 与智能助手的全栈项目

备选标题：

• 5 天实战 AI 编程：Superpowers Skills + Claude Code 全栈开发复盘

• Agent Skills 驱动全栈：需求对齐、原型、TDD、联调一次走通

• 我用 AI 写完了一个带权限管理和智能助手的系统：五天全记录

• 从 PRD 到联调：AI Agent 全栈项目实战笔记

标签：#AIAgent#AgentSkills#ClaudeCode#AI编程#SpecDrivenDevelopment#RBAC#FastAPI#React19#TDD#全栈开发#GoogleStitch#Superpowers

搜索关键词： AI Agent、Agent Skills、SKILL.md、Superpowers、Anthropic Skills、mattpocock、grill-with-docs、brainstorming、writing-plans、executing-plans、test-driven-development、frontend-design、fullstack-dev、Claude Code、Codex、Trae、Qoder、CodeBuddy、OpenCode、Google Stitch、Open Design、Pencil、cc-switch、RBAC、认证与授权、菜单权限、智能助手、提示词模板、FastAPI、SQLAlchemy、React 19、Vite、Tailwind、Shadcn、SQLite、MySQL、前后端联调、真实数据测试

文件命名建议：从Java到AI-Agent-5天Agent-Skills全栈实战复盘.md

最后一句：这 5 天最大的变化，不是学会了几个工具，而是接受了「人来定义问题和验收，AI 来执行」的新分工。