精选案例 · 工程接入与部署 / Agent 自动化
bobo：AI 辅助写代码与 Git 协作实践
作者分享了自己如何利用 AI 编程助手（OpenClaw / Hermes / Claude Code）和 GitLab CLI 完成从 Fork 仓库到创建 Merge Request 的完整协作流程，并总结了 AI 辅助写代码与调试的有效方法，包括环境检查、分步迭代、需求具体化等经验。
案例速读
文章详细记录了使用 AI 完成 GitLab 协作流程的全过程，包含环境检查、fork、分支、提交、MR 等步骤，并总结了 AI 辅助编程的有效方法（先拆任务、分步迭代、不跳过错 review），对不熟悉 GitLab 或希望提升 AI 使用效率的开发者具有实际参考价值。 建议从 「bobo：AI 辅助写代码与 Git 协作实践」、「背景」、「使用的 AI 工具」、「具体过程」 进入正文，先确认真实任务和模型辅助过程。
- 重点看 AI 先检查本地环境（git config、glab auth、token 配置）的实践、AI 轮询 GitLab 仓库 import_status 直到完成才继续的细节处理、分步骤迭代开发方法：先生成最小可运行版本，再逐步补全功能与错误处理。结合 工程接入与部署 / Agent 自动化 / AI 辅助编程 / Git 协作 和「开发者、学生、对 AI 辅助编程感兴趣的人」，它更适合作为任务检索后的精读材料。
- 正文目录和原始材料仍然是判断依据；导读只帮助你更快定位阅读重点。
- 首读入口
- 背景
- 读者
- 开发者、学生、对 AI 辅助编程感兴趣的人
- 复用
- AI 先检查本地环境（git config、glab auth、token 配置）的实践
- 结构
- 6 个目录入口
原文内容
bobo：AI 辅助写代码与 Git 协作实践
背景
我之前写代码时主要把 AI 当成“能问语法和报错的搜索引擎”，例如 Python 脚本报错、Git 命令不熟悉、环境变量不知道怎么配时，把错误信息贴进去让它解释。真正让我觉得有用的是最近几次把 AI 放进完整工作流里：先让它拆任务，再让它改代码、跑命令、看输出，最后根据结果继续修。
这次参加「词元计划」成长营，我想顺便练习一次 GitLab 的协作流程：Fork 上游仓库、创建分支、写分享、提交、推送并发起 Merge Request。以前这些步骤我都知道大概意思，但遇到 token、远程地址、分支追踪、MR 目标仓库这些细节时还是容易卡住。
使用的 AI 工具
- OpenClaw / Hermes / Claude Code 这类 AI 编程助手
- GitLab CLI
glab - Git 与 GitLab 的 HTTPS Token 认证
具体过程
我先用自然语言把目标写清楚：
帮我 fork
https://git.ustc.edu.cn/ustcnic/ai到我的命名空间，克隆 fork 后的仓库，创建my-name分支，在shares/bobo/下写一篇我用 AI 辅助写代码的经历，提交、推送并创建 Merge Request。
AI 没有直接开始改文件，而是先检查本机环境：git config 里的姓名和邮箱、glab auth status 的登录状态、GitLab 是否使用 HTTPS、token 是否存在 keyring 里。中间还发现一个细节：我的全局 Git credential helper 原来指向 GitHub 的 gh，如果直接操作科大 GitLab，普通 git clone / git push 可能不会自动用 glab 的 token。AI 帮我把 git.ustc.edu.cn 单独配置成 glab auth git-credential，这样 GitHub 和科大 GitLab 的认证互不影响。
在 fork 仓库时，AI 通过 GitLab API 创建了 bobo/ai，并且注意到刚创建时仓库还处在 import_status=scheduled。它没有立刻 clone 空仓库，而是轮询到 import_status=finished、empty_repo=false 后才继续。这个细节如果我自己操作，很可能会以为 clone 下来的空仓库是哪里配错了。
写分享内容时，我让 AI 先读项目根目录的 README.md 和已有同学的分享目录，确认仓库约定是每个人在 shares/ 下建自己的目录。它随后创建 shares/bobo/README.md，并把首页“成员分享”表格也加了一行。提交前还跑了 git diff --check，确认没有多余空白或格式问题。
以前写代码时的一个例子
除了这次 GitLab 协作，我平时也会让 AI 帮我写一些小工具。比如处理实验或课程中的表格数据时，我会先描述输入文件格式、想要的输出列和异常情况，让 AI 生成一个 Python 脚本初版；运行后如果遇到编码、空值、列名不一致的问题，就把 traceback 和几行样例数据贴回去，让它改成更稳的版本。
我觉得比较有效的做法不是让 AI 一次写完“最终代码”，而是把它当成结对编程助手：先生成可运行的最小版本，再让它补日志、补参数、补边界条件。比如一个 CSV 处理脚本，第一版只要能读文件和输出结果；第二版再加入命令行参数；第三版再处理缺失值、重复行和输出目录不存在的情况。这样每一步都能验证，不容易被一大段看似完整但没跑过的代码骗过去。
收获
这次体验让我感受到，AI 不只是能写几段函数，也能帮助完成开发协作里的流程性工作。对不熟悉 GitLab 的人来说，它最有价值的地方是把“下一步该做什么”讲清楚，并且能根据真实命令输出继续调整，而不是停留在教程层面。
我的经验是：
- 需求要具体。目标仓库、分支名、目录名、最终要不要创建 MR，都应该直接写出来。
- 让 AI 先检查环境。很多问题不是代码错了，而是账号、token、远程地址或分支状态不对。
- 每一步都看输出。AI 写代码很快，但真正可靠的是“运行、看报错、再修改”的循环。
- 不要跳过 review。AI 可以生成内容，但提交前还是要自己看 diff，确认没有改到无关文件。