精选案例 · Agent / 实践案例
bobo：AI 辅助写代码与 Git 协作实践
这个案例围绕「bobo：AI 辅助写代码与 Git 协作实践」记录了一条真实 AI 实践线索，正文重点集中在「背景」「使用的 AI 工具」，适合先按任务意图阅读再判断复用。
案例速读
README 标题「bobo：AI 辅助写代码与 Git 协作实践」下已经出现运行/配置路径、脚本或接口线索、结果证据，正文重点集中在「背景」「使用的 AI 工具」，比纯概念介绍更适合进入精选阅读流。 这篇案例的阅读价值在于，它把真实任务、模型辅助过程和可迁移做法放在同一个上下文里，读者可以从 「bobo：AI 辅助写代码与 Git 协作实践」、「背景」、「使用的 AI 工具」、「具体过程」 进入正文。
- 建议重点看 可参考其中的运行与配置路径、包含可迁移的命令、脚本或接口线索、已有结果或观测证据可用于判断复用价值。结合 Agent / 实践案例 和「任务驱动用户、AI 实践者」这一受众定位，它更适合作为任务检索后的精读材料，而不是只看一句短摘要后快速跳过。
- 正文目录和原始材料仍然是判断依据；导读只帮助你更快定位阅读重点。
- 看点
- bobo：AI 辅助写代码与 Git 协作实践
- 读者
- 任务驱动用户、AI 实践者
- 复用
- 可参考其中的运行与配置路径
- 结构
- 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，确认没有改到无关文件。