完整工作流：AI 写完代码之后，事情才刚开始
这一课的目标不是让你记命令，而是建立一张地图。以后出问题时，你能判断它发生在“想法、代码、本地运行、Git、构建、部署还是域名”哪一站。
一张完整路线图
text
① 想法和用户问题
↓
② 写成可执行 Prompt
↓
③ AI 产品 / Agent 修改本地代码
↓
④ 本地开发服务器预览
↓
⑤ 人工检查 + 测试 + 生产构建
↓
⑥ Git 创建版本存档
↓
⑦ Push 到 GitHub 远程仓库
↓
⑧ Cloudflare / Railway 拉取或接收代码
↓
⑨ 安装依赖 → Build → 启动或发布
↓
⑩ DNS 把域名带到部署平台
↓
⑪ 用户访问 → 看日志和反馈 → 下一轮修改搬家类比
想法是“我要住进什么样的房子”；Prompt 是给设计师的需求说明；AI 修改代码是在装修；本地预览是验房；Git commit 是给当前状态拍照存档；GitHub 是云端保险柜；Build 是打包家具；Deploy 是把东西运到新家；DNS 是写给访客的导航地址。
第一阶段：把想法变成可检查的任务
太模糊的说法
text
把网站做得更好一点。AI 必须猜“更好”是什么意思：颜色、速度、内容还是手机布局？猜错后，代码写得再快也没用。
可以执行的说法
text
目标：让完全不会编程的人看懂 AI 工具链。
范围：扩写 MCP、CLI、模型、API Key 和工作流页面。
交互：在顶部导航和侧边栏都能进入，章节标题可以直接点击。
设备：手机和 iPad 上也能正常使用目录。
验收：生产构建通过，所有目录链接都指向存在的页面或章节。这就像点外卖时写清菜名、数量、地址和忌口。Prompt 不是越长越好，而是重要信息不能靠对方猜。
第二阶段：AI 在本地项目里工作
代码代理接到任务后，常见过程是：
- 先读取项目说明
查看目录、配置、已有页面和开发规则，不应该凭空假设技术栈。 - 确定修改范围
例如只改 AI 课程和导航，不顺手重做无关的 React 章节。 - 修改本地文件
此时改动只在你的电脑里，线上用户还看不到。 - 启动开发服务器
例如npm run dev，把本地文件临时变成浏览器可访问的网站。 - 检查真实结果
看页面、链接、Console、Network 或自动测试，不只看 AI 的文字总结。
localhost 为什么只有你能看到
http://127.0.0.1:5173 或 localhost 像你家里的样板间，只在这台电脑上临时营业。它不是公开网址，关掉开发服务器后通常就打不开。
保存文件不等于上线
这是零基础最容易混淆的一点：
text
保存文件 只更新电脑上的文件
本地预览 让你在自己电脑上看到效果
Git commit 保存一个可回退版本
git push 把版本上传到 GitHub
Deploy 才把新版本交给线上用户第三阶段：验证不是问 AI“好了吗”
AI 说“已经完成”只是工作报告，不是证据。真正证据要对应任务：
| 你担心什么 | 应该看什么证据 |
|---|---|
| 页面能不能打开 | 本地或线上实际返回成功 |
| 代码能不能打包 | npm run build 成功 |
| 按钮有没有发请求 | 浏览器 Network |
| JavaScript 是否报错 | Console 第一条红色错误 |
| 手机目录能不能用 | 在手机宽度实际打开菜单并点击 |
| 后端是否启动 | 运行日志和健康检查 |
| 数据是否写入 | 数据库记录或接口响应 |
类比：装修师傅说“水管装好了”是一句话；真正打开水龙头、检查是否漏水才是验收。
第四阶段：Git 和 GitHub 保存路线
Git 像游戏存档系统
它不只是“上传代码”，更重要的是记录每次发生了什么变化。
text
git diff
↓ 看这一轮到底改了什么
git add 指定文件
↓ 选择哪些改动进入本次存档
git commit -m "说明"
↓ 创建本地版本节点
git push
↓ 把这些版本发送到 GitHubGitHub 像云端仓库
它保存远程版本、方便协作，也经常成为部署平台获取代码的来源。但“已经 push 到 GitHub”仍不必然等于“线上已经更新”：
- 自动部署项目会在 push 后触发构建；
- 手动部署项目还需要单独执行发布；
- 构建失败时，GitHub 有新代码，线上仍可能停留在旧版本。
为什么 commit 要小而清楚
如果一次 commit 同时改登录、数据库、颜色和部署，出问题时很难知道该退回哪部分。小 commit 像每完成一个房间就拍一张照片，更容易比较和恢复。
第五阶段：部署平台做了什么
以静态 VitePress 网站为例：
- 得到源代码
平台从 GitHub 拉取，或 CLI 直接上传构建产物。 - 安装依赖
根据package.json和锁文件准备 VitePress 等工具。 - 运行 Build
Markdown 和 Vue 被转换成浏览器能使用的 HTML、CSS、JavaScript。 - 发布构建产物
Cloudflare 把静态文件放到网络节点。 - 生成一次 Deployment
每次发布都有独立记录；失败时通常不会替换上一个正常版本。
静态网站和后端服务部署的区别
- VitePress / Cloudflare Pages 更像印好的一批书，用户来时直接把现成页面交出去。
- Flask / Railway 更像持续营业的厨房，请求来了以后服务器现场执行代码并返回结果。
因此静态网站常看“构建和资源路径”，后端服务还要看“进程是否启动、端口、环境变量和运行日志”。
第六阶段：域名、DNS 和 HTTPS
部署平台可能先给你一个地址，例如 项目.pages.dev。自定义域名 code.hanyue-room.design 需要 DNS 告诉互联网它应该去哪里。
- 域名 像用户记得住的店名。
- DNS 像电话簿，把店名查成真正的网络地址。
- HTTPS / SSL 像密封运输袋，减少传输途中被偷看或修改。
- CDN 像分布在不同城市的仓库，让静态文件离用户更近。
域名打不开时，重写 React 组件通常没用；应该检查 DNS 记录、Cloudflare 自定义域名状态和证书。
当前知识库的真实过程
你正在看的站点就是一条完整证据链：
text
需求：零基础 AI 编程知识库
↓
本地目录：vibecoderstudy
↓
内容：docs/*.md
界面：.vitepress/theme
导航：.vitepress/config.ts
↓
npm run build
↓
Git commit
↓
GitHub：远程项目仓库
↓
Cloudflare Pages：vibecoderstudy
↓
自定义域名：code.hanyue-room.design当你在 127.0.0.1:5173 看到新内容、公开域名还是旧内容时，可以判断：本地修改成功了，但 Git / Build / Deploy 这几站中至少有一站还没走完。
出错时先判断是哪一站
| 现象 | 更可能在哪一站 | 先看哪里 |
|---|---|---|
| 本地页面都打不开 | 开发服务器 | 终端是否仍在运行、端口地址 |
| 页面打开但按钮没反应 | 前端代码 | Console、按钮事件 |
| 按钮有反应但请求失败 | API 路线 | Network 状态码和 Response |
| 本地正常、Build 失败 | 构建阶段 | 第一条构建错误、文件行号 |
| Build 成功、线上仍是旧版 | Push / Deploy | 远程 commit、部署记录 |
| 平台地址正常、自定义域名失败 | DNS / SSL | 域名绑定、DNS、证书状态 |
| 页面正常、后端功能 500 | 后端运行阶段 | Railway / Worker 运行日志 |
最重要的判断方法：找到最后一个确定成功的站点，再检查它后面的第一站。 不要从头随机重做全部流程。
一次完整练习
下次只改网站上的一句话，按这份清单走：
- 写清楚要把哪句话改成什么。
- 修改后在本地刷新确认。
- 运行生产构建。
- 用
git diff确认只有预期内容变化。 - 创建 commit 并 push。
- 查看部署是否成功。
- 用公开域名确认新文字已经出现。
完成这七步，你就亲手走完了一次真正的软件交付，而不只是“让 AI 写了一行代码”。
学完测试
本地 localhost 已经看到新页面，为什么公开域名还可能是旧页面？
答案：因为本地预览只证明本地文件和开发服务器正常。新版本还需要经过 Git 保存、push、生产构建和部署，公开域名才会显示它。
线上域名打不开时，为什么不应该第一时间重写页面 CSS？
答案：域名访问属于 DNS、平台绑定或证书这一层。CSS 只控制页面显示，通常不能修复域名解析和 HTTPS 问题。