AI 辅助完成 GitLab 协作与日常编码的实践

方穆诚：AI 辅助完成 GitLab 协作与日常编码的实践

背景

我现在使用 AI 编程助手，已经不只是把它当成“会解释报错的搜索框”，而是把它放进完整的开发流程里：先让它理解目标、拆分任务、检查环境，再根据命令输出一步步调整方案。这种方式在需要同时处理代码、Git、远程仓库、认证和页面操作时尤其有用。

这次我想完成一个很具体的目标：在 GitLab 上 fork ustcnic/ai，创建分支，写一篇自己的分享，提交、推送并发起 Merge Request。单看每一步都不复杂，但真正做起来会遇到很多细节，比如：

• 本地目录里哪个仓库才是目标仓库
• 当前机器能不能访问 GitLab
• Git 和网页登录态是不是同一个身份
• fork 是否已经存在
• push 时该用什么认证方式
• Merge Request 应该指向哪个源仓库和目标分支

这些问题如果只靠人工排查，往往要来回切换终端、网页和文档。AI 在这里最有帮助的地方，不是“代写一段代码”，而是把整个流程梳理清楚并持续跟进。

这次是怎么用 AI 的

1. 先确认上下文，而不是直接动手

我先让 AI 检查本地工作区，确认当前目录并不是目标仓库本体，而是需要另外 clone 一份 GitLab fork。它随后继续检查：

• 本机是否能访问 git.ustc.edu.cn
• 有没有可用的 GitLab CLI
• 浏览器自动化环境是否可用
• 当前仓库结构里 shares/ 的命名约定是什么

这一步很重要，因为很多“写代码失败”其实不是代码问题，而是上下文搞错了。

2. 用 AI 处理认证和 fork 这种麻烦但重复的工作

这次最麻烦的部分其实不是写 Markdown，而是 GitLab 的认证链路。AI 帮我做了几件很实用的事：

• 自动探测上游仓库是否可达
• 通过浏览器自动化拉起 GitLab 登录页和中国科大统一身份认证
• 在登录成功后读取当前 GitLab 用户信息，确认我的命名空间是 miger
• 判断 fork 是否已经存在，而不是盲目重复创建

最后确认我的 fork 已经存在于 miger/ai，这样后面的 clone、分支和推送就都能接上了。

3. 把网页登录态桥接到本地 Git 操作

这是这次我觉得最有意思的一点。网页里已经登录，不代表命令行里的 git clone 和 git push 一定能直接工作。AI 没有停在“网页已经登录了”这个表面结论，而是继续解决：

• 命令行 Git 是否真的能访问我的 fork
• 是否必须额外申请 token
• 能不能复用现有网页登录态完成 clone 和 push

最终它通过现有会话验证了对 miger/ai 的访问能力，让整个流程不需要我额外再找一套认证方式。

4. 写内容时先看现有风格，再落文件

在创建我的分享目录之前，AI 先读取了仓库里的 README.md 和几位同学的分享文件，确认这个仓库通常采用：

• shares/名字/README.md 的结构
• 根目录 README.md 里的“成员分享”表格登记入口

这样做的好处是不会写出一个“技术上存在、但风格上不融入仓库”的内容。

平时用 AI 辅助写代码时，我最常见的方式

除了这次 GitLab 协作，我平时更常把 AI 用在下面几类任务里。

1. 生成第一版可运行代码

比如要写一个 Python 小工具做数据清洗、批量重命名或者文件转换时，我通常不会要求 AI 一次给出“最终完美版本”，而是先让它生成一个最小可运行版本。只要第一版能跑通，后面就可以基于真实输出继续改。

这种方式比一开始就追求“大而全”的脚本更稳，因为可以尽快进入“运行 - 观察 - 修正”的闭环。

2. 根据真实报错迭代

当程序报错时，我通常会把下面三类信息一起给 AI：

• 报错栈
• 输入样例
• 我预期的输出结果

这样 AI 的修改更有针对性，也能避免它只从抽象层面给建议。很多时候，一次报错分析就能顺带把边界条件、路径处理、编码问题一起补上。

3. 帮我梳理陌生工具链

如果任务里涉及我不熟悉的工具，比如 GitLab 的某个页面流程、某个框架的配置方式，AI 很适合先帮我梳理一遍“应该先看什么、再做什么、失败时怎么判断卡在哪一步”。这能显著减少我在文档里来回搜索的时间。

这次最大的收获

经过这次实践，我对 AI 辅助编程的感受更明确了：

1. AI 最有价值的地方，不只是写代码，而是能把复杂流程拆成可执行的小步骤。
2. 当任务同时涉及代码、环境、权限、远程仓库和网页登录时，AI 作为“流程协作者”比作为“代码生成器”更有价值。
3. 真正可靠的工作方式仍然是小步前进，每一步都看输出，再决定下一步怎么做。
4. 即使 AI 已经帮忙完成了大部分操作，最后的 diff、提交内容和 MR 目标仍然要自己确认。

我现在更倾向于把 AI 看成一位很擅长排查和推进任务的结对搭档。它能显著减少机械性的搜索和试错，但关键判断、结果验收和内容表达，还是需要人来把关。

给后来者的几点建议

如果你也想用 AI 来辅助完成类似任务，我觉得下面几点最实用：

1. 把目标说具体，最好明确到仓库地址、分支名、目录名和最终交付物。
2. 先让 AI 检查环境，不要一上来就改文件。
3. 每一步都基于真实输出继续推进，不要只看“理论上应该可以”。
4. 涉及认证、权限和远程仓库时，优先确认身份和访问方式是否一致。
5. 提交前自己看一遍 diff，确认改动范围和内容都符合预期。

这次从 fork 到 MR 的完整过程，让我更明显地感受到：AI 辅助写代码最强的地方，不是替你按下每一个键，而是帮你把复杂问题变成一条能走通的路径。