--- title: 从 issue 到 PR 的 AI coding 工作流 date: '2025-12-30 12:37:59' draft: false summary: 真正顺手的 AI coding 流程，不是聊天窗口里临时改几行代码，而是让工具直接接住 issue、交付 PR、再吃掉 review 和 CI 反馈。 slug: holon-issue-to-pr-workflow syndication: - platform: Weibo url: https://weibo.com/1648815335/5249533040657167 - platform: X / Twitter url: https://x.com/jolestar/status/2005860894585282596 tags: - ai - coding - github topics: - ai - software-engineering type: post --- 前一段时间我摸索出了一套 AI coding 的工作流，但在真正用的时候发现，并没有一个工具能非常完整地贴合这套流程，于是干脆自己顺手做了一个。 我的核心诉求其实很简单： 我已经把需求和方案写成了 issue，我希望一个工具能直接拿到这个 issue，把事情做完，然后给我一个 PR 让我 review。 如果我在 review 里提了 comment，希望它能再跑一遍，把问题修掉，并且逐条告诉我它是怎么修的。 于是就有了 `holon`。 ## 我想要的交付形态 用法也很直接： ```bash holon solve github_issue_pr_url ``` 如果是一个 issue，它就直接解决并提交 PR；如果是一个 PR，它就去修 review comments 或 CI 错误，然后再提交。 `holon` 也可以配置成 GitHub workflow。只要在 issue 或 PR 下面评论 `holonbot`，就会触发它去提交 PR，或者修已有的 PR。 ## 它是怎么被做出来的 整个 `holon` 工具本身，就是用这套流程写出来的。 我先写 issue，然后 `holonbot` 开发，开发完让 Copilot review，review 的结果出来以后，再让 `holonbot` 修复，我只负责最后合并代码。 大概一周多的时间，合并了 200 多个 PR，close 了 150 多个 issue。 只有在 `holon` 把自己改坏的时候，才需要我亲自下场修。 大多数 PR 我其实不会细看代码，主要看的是 Copilot 和 `holonbot` 在哪些地方产生了分歧，看看它们在争论什么点、为什么会争论这些点。 有时候我会补一两个 review comment，但也不是每次都会被接受，偶尔还会被 `holonbot` 直接驳回。 ## 哪些问题不适合当场修 后来发现有一类 review comment，比如需要补测试，或者需要比较大的重构，其实不适合当下直接修，于是干脆让 `holon` 在这种情况下自动创建一个 issue，把问题记录下来，等未来再处理。 这个处理方式我觉得更接近真实工程流：不是所有 comment 都应该同步修完，有些更适合进入下一轮 backlog。 整体体验还是比较丝滑。 ## 原微博中的媒体 ![](./weibo-5249533040657167-1.jpg) ![](./weibo-5249533040657167-2.jpg) ![](./weibo-5249533040657167-3.jpg)