AI已经开始替你修PR，你自己那份代码却还没推上去，两边会怎样相遇？Qwen Code 0.26.3为这个协作缝隙补上一道启动检查：用户本地仍有未推送提交、未提交改动，或者状态无法确认时，自动修复流程先停下来说明情况。它不让“看不见的工作”被默认当成不存在，也没有承诺替整个仓库建立万能安全锁。

快速看点：新稳定版于10月28日发布，相关改动27日合入；检查覆盖同一克隆中匹配PR头分支的检出目录，包括关联工作树；辅助命令输出状态，真正停止启动的是内置技能约定，两层责任不能混为一谈。

自动修复看的是PR，不是你桌面的全部工作

自动修复监视会在独立工作树中处理PR，并向同一个头分支推送提交。用户自己的检出目录里，如果还有未提交文件，或者提交尚未到达PR，监视那边并不能直接看到。两边继续推进，会增加推送竞争：自动修复先推送后，用户后推可能遭遇非快进拒绝，重新协调代码与审查状态都需要时间。

这次增量让prepare辅助命令额外报告localUncommittedChanges，同时保留未推送提交数，并增加localWorkUnknown表示无法比较。启动流程读到工作未同步或状态未知时，需要向用户说明发现了什么，再停止启动；一次性运行也包括在内，不能用“只跑一轮”跳过这条约定。

这里有一个重要区别：prepare本身不是拒绝一切的硬闸门，它可以已经准备工作树并返回报告。内置技能随后根据报告决定不启动修复。自行编写脚本、直接调用辅助命令的团队，也需要消费这些字段，不能只凭命令成功退出就当作已获准自动推送。

未跟踪文件和子模块，也要进入视野

检查不是简单询问当前目录是否干净。代码先确认本地分支的上游与PR的推送目标匹配，再枚举这个克隆中检出该分支的工作树。这样，用户把PR分支放在旁边一个关联工作树中编辑，也能纳入检查；不属于该分支的另一个检出目录则不应混进来。

读取Git状态时，最终实现显式要求包含未跟踪文件和子模块变化，避免用户配置把它们隐藏。对未跟踪的.qwen目录，还会继续区分辅助流程自己的临时状态与用户放在其他位置的内容。不能为了消除一次误报，就把整个.qwen目录排除，否则自定义技能等改动也可能被漏掉。

正式标签中的回归用例覆盖了新建文件、隐藏未跟踪文件的配置、子模块改动、关联工作树、恢复监视和远端PR已前进等情况。本文查看了对应测试代码，没有执行这些测试；上游断言说明设计要守住哪些场景，不等于本站已经完成跨平台生产验证。

不知道，就不要解释成没有改动

如果PR的新头提交不在这个克隆里，或Git无法读取某个检出，报告会把情况标为未知。启动约定要求先让用户获取分支或修复检出。旧版Git不支持工作树列表的零字符分隔格式时会尝试行格式；路径解析或读取仍不能确认的场景，也不能被悄悄写成“没有工作”。

恢复既有监视时，未推送提交数会与GitHub当前PR头比较，而不是仅拿监视上一次记录的旧头作基准。否则用户刚刚推送成功的提交，也可能被错误算作尚未推送。这种基准更新看似细小，却影响自动化提示是否可信：频繁误报会诱使人习惯性跳过真正重要的警告。

范围仍需说清：它只检查当前克隆中的相关副本，不会自动巡视另一个克隆里的同名分支；没有匹配上游的本地分支，也不属于这套副本比较。启动检查更不是永久锁，不能由此推导后续每一次编辑与推送都绝无竞争，或用户文件已被备份。

用户知情后仍可要求继续；但状态未知时，首先应补齐状态，而不是把未知解释成安全。团队接入这类工具时，应明确谁负责保存或推送本地工作、谁可以批准继续、何时重新检查。这里提出的是交付检查方法，不是已经验证的效率收益或减少事故的量化结果。

本轮只核准0.26.3中这项启动保护，区别于此前0.26稳定版的运行时未知结果与恢复逻辑。版本还包括其他界面和工具改动，未随本文一并批准。没有在本站项目安装Qwen Code、创建自动修复任务或对任何PR执行推送。

小编判断

代码智能体的可靠性，不只取决于能不能修对，还取决于开始修之前有没有看清人的工作。Qwen Code把未同步改动和未知状态带入启动决定，是更清楚的协作契约；实施团队仍要把“报告状态”和“允许执行”连接起来，才能避免一个成功返回的命令掩盖尚未解决的冲突。