diff --git a/docs/仓库协作者AI分析PR与合并标准流程.md b/docs/仓库协作者AI分析PR与合并标准流程.md
index 9bc4b48..078d164 100644
--- a/docs/仓库协作者AI分析PR与合并标准流程.md
+++ b/docs/仓库协作者AI分析PR与合并标准流程.md
@@ -27,6 +27,7 @@
 11. 任何 GitHub 评论、回复、感谢留言发出后，AI 都必须立即再读一遍线上实际内容，确认正文不是乱码、不是 `?`、不是编码异常；如果发现异常，必须立刻修正后再继续后续流程。
 12. 如果流程执行过程中，PR 的实时目标分支被别人改掉，或者不再是 `dev`，AI 必须停止当前合并流程，重新拉取信息后再决定下一步。
 13. 进入“阶段 2：分析与审查”时，AI 必须先给当前 PR 添加 `审查中` 标签，并在开始正式审查前确认该标签已经在线上生效。
+14. 审查结束后，AI 必须根据实际结论把 PR 标签从 `审查中` 切换为 `完成` 或 `等待修改`，并同时把受理人设置为自己；在确认线上状态已更新前，不允许声称审查已完成。
 
 ## 输入要求
 
@@ -54,7 +55,7 @@ AI 必须先执行下面这些动作，不能跳步：
 2. 拉取 PR 元数据：
 
 ```powershell
-gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json number,title,body,author,baseRefName,headRefName,headRepository,headRepositoryOwner,changedFiles,additions,deletions,commits,files,labels,isDraft,mergeStateStatus,mergeable,state,url
+gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json number,title,body,author,baseRefName,headRefName,headRepository,headRepositoryOwner,changedFiles,additions,deletions,commits,files,labels,assignees,isDraft,mergeStateStatus,mergeable,state,url
 ```
 
 3. 先根据实时 `baseRefName` 处理目标分支：
@@ -168,6 +169,38 @@ gh pr edit <PR_NUMBER> --add-label "审查中" --repo <OWNER/REPO>
 2. 不强制给 PR 留问题评论。
 3. 是否继续合并，取决于用户命令。
 
+## 审查完成后的状态回写规则
+
+无论本次是“只分析”还是“分析后继续合并”，只要审查结论已经形成，AI 都必须立刻回写 PR 状态：
+
+1. 如果本次审查结论是“可以继续处理 / 没有明确阻塞问题”，把标签改为 `完成`。
+2. 如果本次审查结论是“存在问题，需要作者或维护者继续修改”，把标签改为 `等待修改`。
+3. 两种情况都必须同时把受理人设置为自己。
+4. 标签必须互斥，不能同时保留 `审查中`、`完成`、`等待修改` 中的多个状态标签。
+
+### 回写命令示例
+
+审查通过 / 可继续处理时：
+
+```powershell
+gh pr edit <PR_NUMBER> --remove-label "审查中" --remove-label "等待修改" --add-label "完成" --add-assignee "@me" --repo <OWNER/REPO>
+```
+
+需要修改后再继续时：
+
+```powershell
+gh pr edit <PR_NUMBER> --remove-label "审查中" --remove-label "完成" --add-label "等待修改" --add-assignee "@me" --repo <OWNER/REPO>
+```
+
+补充要求：
+
+1. 回写完成后，必须立刻重新读取一次实时 PR 元数据，确认：
+   - `labels` 中已经是正确的最终状态标签
+   - `审查中` 已经被移除
+   - 当前受理人列表中已经包含自己
+2. 如果仓库里没有 `完成` / `等待修改` 标签、当前账号无权限改标签或设受理人，或者命令执行失败，必须立刻告知用户，不能假装状态已经回写成功。
+3. 如果后续又因为继续修复、重新审查等原因需要重新打开审查流程，必须先按实际情况重新设置标签，不能让状态长期停留在错误值。
+
 ## 带问题继续合并的规则
 
 如果 PR 有问题，但用户明确要求：
@@ -326,13 +359,15 @@ AI 在对当前用户做最终反馈时，至少要说明：
 4. 是否发现重复的 `dev` PR
 5. 是否发现问题
 6. 是否已经给 PR 添加 `审查中` 标签
-7. 是否已经发了 PR 评论 / 行级代码评论
-8. 是否已经要求 PR 修改后再继续
-9. 是否已经修改 PR 分支并推回远端
-10. 是否已经完成 PR 合并
-11. 是否已经关闭 PR
-12. 如果改了代码但没跑测试，要明确提醒用户测试
+7. 审查完成后最终把 PR 标签改成了 `完成` 还是 `等待修改`
+8. 是否已经把受理人设置为自己
+9. 是否已经发了 PR 评论 / 行级代码评论
+10. 是否已经要求 PR 修改后再继续
+11. 是否已经修改 PR 分支并推回远端
+12. 是否已经完成 PR 合并
+13. 是否已经关闭 PR
+14. 如果改了代码但没跑测试，要明确提醒用户测试
 
 ## 给 AI 的一句话执行要求
 
-拿到本文件后，AI 必须按“先真实读取 PR 元数据，先校正目标分支，再拉取最新 diff，在正式审查开始时先给 PR 打上 `审查中` 标签并确认已生效；如果审核不通过，就在对应代码附件上评论并明确要求更改；如果用户要求继续处理冲突和问题，就先修好并推回 PR 分支，再按规则合并 PR，最后感谢作者、关闭 PR”的顺序执行，不能跳步，不能猜，不能偷懒。
+拿到本文件后，AI 必须按“先真实读取 PR 元数据，先校正目标分支，再拉取最新 diff，在正式审查开始时先给 PR 打上 `审查中` 标签并确认已生效；审查结束后根据实际情况把标签改成 `完成` 或 `等待修改` 并把受理人设为自己；如果审核不通过，就在对应代码附件上评论并明确要求更改；如果用户要求继续处理冲突和问题，就先修好并推回 PR 分支，再按规则合并 PR，最后感谢作者、关闭 PR”的顺序执行，不能跳步，不能猜，不能偷懒。