6.5 常见误区与综合实践
面向经管学生、研究者与从业者的 AI 智能体设计教材
最后用一个典型场景，把本章的对话流程和判断串联起来。
假设你在一个文档项目中需要同时做三件事：调整目录结构和导航配置、重写某个章节的正文、更新项目说明。比较稳妥的一条本地流程用对话表达如下：
帮我从当前主线开一条新分支，名字叫 part2-git-reorder。
然后按顺序处理，每一步都先让我确认范围：
1. 只提交导航配置的两个文件（_quarto-full.yml 和 _quarto-selection.yml），
备注写"调整第二篇导航顺序"
2. 再提交章节重写部分（section-6-1.qmd 到 section-6-5.qmd），
备注写"重写第 6 章 Git 正文"
3. 第三次提交项目说明和配置（README.md 和教材大纲_最新版.md）
不要把临时文件或顺手改动一起提交。Claude Code 会逐项执行，每一步都回报选定范围、等待你确认，再形成提交。三件事各自独立，后面审阅时能分别确认。
如果发现某个文件其实不属于这次提交，可以让它撤掉：
刚才那次提交里，chapter-7 的文件不该放进去。请把这次提交恢复到提交前的状态，我来重新选定。- 让 AI 把所有改动一次性提交 —— 最容易把临时文件、顺手改动和无关修补一起送进历史。
- 不看改动就提交 —— AI 写得快，不等于每一行都该保留。
- 一条提交同时解决多个问题 —— 提交越杂，后面越难审，也越难回退。
- 把回退当成失败 —— 真正危险的不是回退，而是没有回退点。
- 还没形成本地提交，就急着讨论 PR 和 CI —— 没有本地版本点，后面的协作接口没有稳定对象可审。
大文件、敏感数据与协作场景
实际项目中还会遇到几类边界问题。这些问题不需要你掌握底层机制，只要知道怎么用对话让 Claude Code 处理。
大文件管理
数据文件、模型权重、高清图片可能达到几百 MB。直接纳入 Git 会拖慢整个仓库。解决方法是启用 Git LFS（Large File Storage，大文件存储），让大文件以轻量指针形式存在历史中，实际内容存放在独立空间。
我的 data 目录里有几个大 Excel 文件，帮我启用 Git LFS 来管理它们，避免拖慢仓库。Claude Code 会完成 LFS 配置，之后这些文件纳入跟踪但不会膨胀历史。
敏感数据进入历史
如果不小心把含密钥的配置文件提交了，简单删除当前版本是不够的——历史里仍留有痕迹。这种情况需要彻底清理历史：
我不小心把 .env 文件提交了，里面有 API 密钥。
请用专业工具彻底清除这个文件在所有历史版本中的痕迹。历史清理会改写所有提交记录，属于高风险操作。执行前务必让 Claude Code 备份当前状态，并在操作后确认历史仍能正常回溯。已推送到远端的仓库，还需要通知合作者重新拉取。
Overleaf 与 Git 结合
很多研究者用 Overleaf 写论文，Overleaf 自带版本历史但功能较简单。需要复杂分支管理（中英文版并行）、或要和代码仓库联动时，Git 更合适。两者可以结合：Git 管理本地项目，Overleaf 作为协作平台。
合作者不用 Git
这很常见。合作者习惯用微信或网盘发文件，你照样可以把收到的文件放进自己的 Git 项目中存档。至少你自己这一侧的历史是完整的。等合作者看到你能随时回到任何版本，可能会主动产生兴趣。
本章最小对话流程
学会版本控制的第一步，不是记忆一长串命令，而是把版本边界建立起来。只要能稳定走完下面这条对话链，本章目标就实现了：
看现场 → 看改动 → 选定本次范围 → 存档 → 看历史 → 必要时回退结合分支、Worktree、PR、Hooks 和评估，整套协作流程才能稳定运行。