Afield1. 选择仓库
在集成页连接 GitHub，选择网站对应的仓库，并核对任务中的分支与项目。登录 GitHub 不等于拥有所有仓库的权限。
2. 给出具体修改
例如：“在所选网站仓库中，用下方审阅过的文案修改产品页，保留布局，更新标题和描述，列出变更文件和已做检查。”
3. 看差异和预览
查看实际改动，检查页面直接访问、窄屏布局与链接。移动 URL 时一并处理跳转、canonical 和 sitemap。
4. 按仓库流程发布
代码变更或 PR 不等于已经部署。完成正常审核与发布后打开线上页面。失败时检查仓库访问权与分支权限，再重试原任务。
给审核者一个有边界的修改
“优化网站”没有说明目标和完成条件。写清页面、替换内容和需要保留的行为。修改图片时包括素材与图注；修改路由时包括旧地址到新地址的映射。
| 检查项 | 应回答的问题 |
|---|---|
| 差异 | 是否只改了预期文件与段落？ |
| 预览 | 直接打开地址是否显示目标结果？ |
| 构建 | 相关项目检查是否完成？ |
| 发布 | 通过哪个流程才会对外生效？ |
Pull request用于审查拟议修改，存在 PR 本身不能证明网站已部署。
在哪一层失败，就处理哪一层
看不到仓库时，检查 GitHub 连接是否被授予该仓库访问权，不要反复改写作提示。分支不能更新时，检查权限和仓库审核流程；构建失败时，保留拟议内容并处理具体构建错误。
发布后独立打开公开地址，对照改动段落和图片。旧页面发生迁移时，用地址迁移示例（英文）检查重定向与新 canonical。这样完成的是已观察到的页面，而不只是一份代码差异。
沿着文件改动，走到公开页面
文章修订需要指明路由和具体段落，要求修改真正渲染该页面的源文件，而不是新增一个构建过程根本不读取的重复 HTML。按照预期文字审核改动，把无关应用修改留在本次任务之外。
打开仓库正常流程生成的预览，确认正文、链接和图片路径。如果源码改了而预览没变，先调查渲染器与构建输入，不要继续增加另一份文章副本。
仓库完成发布步骤后，再检查公开路由。合并改动仍可能没有到达预期部署。将改动记录和观察到的公开结果保存在一起。发布失败时从已准备的改动继续，不要通过重写正文去补偿部署问题。