GoodVibe
登录
AI 创意工程师

驾驭 Vibe Coding · 01.3 / 04

交付阶段：留下一条公开链接

先用 Diff 和浏览器确认这一轮做对了什么，再留下能够恢复的版本、清楚的变更说明和公开链接。线上页面重新走通以后，这次交付才有完整证据。

  • GoodVibe 编写
  • 含发布实验

本地页面能够使用以后，交付阶段要回答三件事：这一轮究竟改了什么，别人能否安全接手，公开链接是否和本地结果一致。Agent 的完成说明只能提供线索，最终判断来自文件变化、浏览器操作和生产环境。

这一节把检查、版本、PR 和发布放进同一条路径。中间发现问题就回到对应步骤修正，不需要为排错单独学习一套流程。

一份能够解释的改动、一个可恢复版本和一条经过验收的公开链接。

交付阶段的完成标志

提交前检查

把文件变化和页面结果放在一起看

Git Diff 会显示文件里新增、删除和替换的内容。第一次不需要读懂所有语法，先看改动涉及哪些文件，再把每个文件对应到任务与完成标准。一个按钮调整却带出了路由、依赖或陌生配置，范围就需要重新确认。

文件范围合理以后，在浏览器重走主要流程，并用边界数据、键盘和手机宽度检查页面。代码变化解释实现发生了什么，浏览器则显示使用者真正得到什么，两边需要互相对应。

  1. 01

    确认修改范围

    区分当前任务、之前未保存的个人修改、构建产物与本地配置。

    留下 本次交付文件清单
  2. 02

    检查删除与覆盖

    确认原有 Props、状态、键盘操作、错误处理和埋点没有被视觉改造顺手删掉。

    留下 保留与改变的行为记录
  3. 03

    重走用户路径

    检查正常、空白、失败、刷新、键盘与不同视口，记录能复现的问题。

    留下 浏览器验收结果
  4. 04

    运行项目检查

    执行项目现有的类型、测试和生产构建命令，不临时发明一套新的质量标准。

    留下 命令与通过结果

让 Agent 审查这一轮改动

delivery-review.md改动审查Prompt
请审查当前修改，暂时不要继续写代码。
按顺序说明：1. 哪些文件发生变化，每个文件对应哪个完成标准2. 是否存在超出本次任务范围的修改3. 原有行为、状态或样式有没有被删除或覆盖4. 是否出现密钥、环境文件、调试代码或生成产物5. 还缺哪些浏览器、响应式、可访问性或生产检查
最后给出“可以进入交付 / 需要先修正 / 应该撤回”中的一个结论，并附上依据。

文件范围突然变大

让 Agent 解释每个文件对应的任务目的；无关重构、依赖升级和格式化先从交付中移开。

页面只在默认状态正常

补查空数据、长内容、错误状态、键盘和手机宽度，再决定是否提交。

同一个问题反复修不好

停止继续修改，重新提供复现步骤、完整报错和最后一次正常版本，一次只验证一个原因。

新界面覆盖了旧能力

对照修改前后的事件、状态与交互路径，逐项恢复或明确记录有意放弃的内容。

保存版本

一轮任务对应一个清楚的恢复点

Branch 保存一条独立修改路径，Commit 记录其中一个有说明的节点，Push 把本地分支同步到远程。提交以前先检查 .gitignore、环境变量和工作区状态，避免把密钥、账号信息、下载数据或无关改动一起送出去。

四个常见 Git 动作

terminalBash
# 查看当前分支与修改git status
# 为当前任务创建独立分支git switch -c feat/course-directory-mobile
# 只暂存已经确认的文件，再保存版本git add components/course/CourseDirectory.tsxgit commit -m "feat(course): improve mobile directory"
# 把当前分支推送到远程git push -u origin feat/course-directory-mobile

创建版本前先做只读检查

checkpoint-review.md版本检查Prompt
请帮我准备一个安全的 Git checkpoint，先只做检查。
请说明：1. 当前分支和工作区状态2. 哪些文件属于本次任务，哪些与它无关3. 是否存在 .env、密钥、下载文件、缓存或构建产物风险4. 建议暂存的明确文件清单5. 一条能够说明修改目的的 Commit message
不要使用 git add .，不要包含无关改动。等我确认清单后再执行。

交给别人看

PR 说明要回答改了什么和怎样验收

一份可用的 PR 说明包含任务背景、改动范围、已完成检查、仍待处理的业务逻辑和预览入口。截图可以帮助快速浏览，真实 URL 与操作路径才能支持完整验收。

生成一份可以继续协作的 PR 说明

pull-request.md
## 这次解决什么<用户问题与本轮范围>
## 主要改动- <页面或组件，以及改变原因>- <状态、数据或响应式处理>
## 怎样验收1. 打开 <本地或预览 URL>2. 执行 <主要操作路径>3. 检查 <正常、空白、失败和手机状态>
## 已完成检查- [ ] 类型检查 / 测试 / 生产构建- [ ] 桌面与手机- [ ] 键盘与错误状态
## 仍待接入- <真实接口、权限或业务规则>
## 预览<公开链接、截图或录屏>

第一次发布

故意把项目做小，完整走完一次

第一次发布只需要一个有真实内容、主要状态和清楚验收方式的小页面。下面的实验会根据三个参数生成任务 Prompt；把它交给 Agent 时，仍然要先确认项目规则和改动文件。

最小发布练习

调三个参数，复制一条任务，交付一个链接

第一次发布 · 01等待验收

一个有明确完成标准的小页面

先把一个小页面做成。

01

修改一处

02

验收页面

03

发布链接

可交付预览

first-ship-prompt.md
请在当前项目里完成一个最小可发布 Demo。

[目标]
做一张标题为“先把一个小页面做成。”的发布卡片（Launch Card），并让按钮有清楚的 hover 和键盘 focus 反馈。

[当前情况]
请先读取项目规则、package.json、页面入口和现有 Design System，再决定放在哪个组件里。

[限制]
- 沿用现有颜色和字体 Token
- 信息密度：平衡
- 卡片形状：轻圆角
- 不安装新依赖，不改无关页面
- 保留手机布局和 reduced motion

[完成标准]
1. 本地页面可以打开，没有 Console 错误
2. 390px 与桌面宽度下内容不溢出
3. 按钮能用键盘聚焦
4. 通过生产构建
5. 给出公开 URL，并在生产环境复走以上检查

先给出最小方案和涉及文件，等我确认后再实现。
01本地页面可以运行
02桌面与手机都通过验收
03公开链接可以正常打开

生产环境

公开链接需要重新走一遍主要路径

本地和生产环境可能使用不同的变量、资源路径、缓存与网络条件。拿到公开 URL 后重新检查加载、主要交互、刷新、手机宽度和错误日志；访问的是生产地址，证据也要来自生产页面。

验收公开链接

production-check.md发布验收Prompt
请对生产环境做一次发布验收。
公开 URL：<production-url>主要任务：<用户应该完成什么>设备范围：桌面 / 平板 / 手机
请检查：1. 页面和主要资源是否正常加载2. Console、Network 和服务端日志是否有错误3. 关键交互、空白、失败和刷新后的状态4. 响应式、键盘操作、对比度和 Reduced Motion5. 本地与生产环境是否存在差异
把结果整理成“通过 / 失败 / 需要人工确认”，并附上可复查的证据。

学习进度

正在读取你的学习记录…