浏览 AI使用教程
git status 怎么看：改代码前先确认工作区变更归属
接手一个已有改动的仓库，第一件事是看清工作区。逐个确认修改归属、生成文件和未跟踪文件，才能避免格式化或回退掉别人的工作。
沿完整工作流推进
前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。
git status 里的 23 个文件，不能默认都属于这次任务
接手项目时 `git status` 有 23 个修改文件。Agent 如果先格式化或恢复，很可能覆盖用户尚未提交的工作；如果全部当成本任务，又无法交付清晰 diff。
- staged/unstaged/untracked 已区分
- 每项变更有归属或未知标签
- 没有执行破坏性恢复命令
先确认这次任务的起点、边界和交付
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 下面5行构造的git status --short；只拟修改src/search.mjs。修改归属尚需任务记录与diff确认。 |
| 不能越过的边界 | 只读确认变更归属；不 reset、checkout 或删除；无法判断的文件先不碰。 |
| 要交付的结果 | 变更归属清单与安全起点 |
从“读取规则和分支”走到“限制后续编辑”
| 当前阶段 | 实际处理 |
|---|---|
| 读取规则和分支 | 确认项目贡献规则、当前分支、远端关系和禁止修改区域。 |
| 逐文件看状态 | 区分已暂存、未暂存、未跟踪和忽略文件，查看 diff 与最近提交，不只看文件名。 |
| 标注变更归属 | 将本次需要、用户已有、生成物和未知改动分开；未知项与任务重叠时先停止确认。 |
| 建立安全起点 | 在不覆盖用户改动的前提下选择新分支、补丁、提交或备份，记录恢复方式。 |
| 限制后续编辑 | 每轮修改后重看 diff，确保没有格式化或生成命令带来大范围无关变化。 |
先读两列，再读差异
构造输出
保留开头空格
M src/pay.mjs M src/search.mjs MM README.md ?? notes.md UU src/status.mjs
只读命令
不改变暂存区
git status --short git diff -- src/search.mjs README.md git diff --cached -- src/pay.mjs README.md git diff --name-only --diff-filter=U
M空=已暂存；空M=工作树未暂存；MM=两处都有修改；??=未跟踪；UU=双方修改造成未解决冲突。未跟踪内容不在普通diff中，要另行阅读。状态不等于作者归属，文件名也不等于可以清理。
完成后的变更归属清单与安全起点
状态表示索引与工作树差异，不能判断作者。先读两种diff，再逐块区分既有修改，不重置未知内容。
为什么“任务文件本来就有用户改动”还不能交付
任务文件本来就有用户改动
- 原因
- 同一文件存在混合归属
- 怎么改
- 逐块阅读 diff，与用户改动叠加而不覆盖；无法安全区分时停下说明