方法分享 | 基于 GitHub issue 的 vibe coding 工作流，可大幅提高代码可维护性。
- 内容介绍
- 文章标签
- 相关推荐
概览
workflow1920×1047 431 KB
前置工具
- tmux
- codex/claude
- lazygit
- nvim
- github cli
方法优点
- 上下文共享/不怕换cli
- 领域收窄/单步可验证
- 关注变动，保持代码可控增长
方法分享
这是我在重构 fcitx5-vinput 时候摸索出来的方法，目前还不是特别成熟，欢迎各位佬交流。
背景
0.0
起初写这个语音输入法自用的时候大概只 vibecoding 了 一天，第一天的需求的实现方式就是无脑和 codex 聊天，实现/编译/本地验证。 这个时候的问题，代码里充斥着硬编码，所有功能堆在多个单文件里，项目结构纯平铺
1.0
视频发布出去之后，迎来了很多外部需求，新需求要与旧代码融合，仍旧先无脑纯聊，结构上大平铺，迎来了项目第一次的屎山。
2.0
github 收获了一部分 star 想把这项目做好，所以开始重构，重构之前思路已经相对清晰要做的功能，本地识别/llm后处理/云asr接入/流式接入，对于云asr的接入也已经确定了 基于 std 标准流的方案，做了可行性验证。
方法思路
- 以 github issue 为串联工具，串起整个工作流程，保证工作计划/步骤/进度的清晰
- 以 lazygit 为 review 工具，关注每次代码变更的增长，少量可控的揪出坏味道代码，及时纠偏
- 以 nvim 作为全局概览，主要关注 目录结构/lsp 报错等。
- 以 github action worflow 作为后验证步骤 （至少要过编译）
- 这套方法论给我最大的体验实际上是开发视角的转变，对于独立开发来说，把人从开发者这个劳动中抽离出来，人更多担任是产品经理和测试的角色。
这套思路里 github 是提效流程的主线，且 github 本身擅长做这些，issue 就是用来提问题的，action 就是用来构构建的，我们的主要工作只是把他们原本的功能接入我们的开发流程。
方法实践
- 导航到开发项目，开 tmux 左右 panel，左边放 codex/claude 右边 放 lazygit
image1366×768 190 KB
- 另开 tab 放 nvim
image1366×768 171 KB
这样我们基本的流程工具框架就搭建好了。
开发流程
- 规划在前，编码在后，在前置阶段，先提需求、定标准、定方向，这个阶段先和ai聊，聊完了，将标准先固定，以我的项目为例，核心的标准有 配置文件的 schema cli 的指令风格，参数等，这里只关注这个产物，在指定这个制定的时候一定尽可能把你自己能想到的问题都想了，不知道聊啥，就仅仅说出你自己的疑问，在 一轮一轮的 Q&A 中标准会浮现出来，标准定下来之后，可以让 ai 分析当前代码，做规划拆解为 todo 项目，发布 issue 关联刚刚的标准的issue。
- 小步迭代，进度可控，在编写代码阶段，ai 依据 todo task 的项目 逐一执行，执行完成后，人 review lazy git 的变更，满意则提交，让 ai check 上一项任务，开始像一个任务，不满意就让他接着改，对于目录级别的结构调整，lazygit 可能看着不太清晰，这个时候且下 nvim 看一眼。，所有 todo 完成关闭 所有相关 issue，开始下一个需求。
- 领域分割，清晰架构，每一轮基本上都是这样的流程，这里的原则是，每个issue只关注某一个领域的问题，如有其他的问题可以，发新的关联。
总体流程
- 挑出一个需求
1.1. 聊需求，定标准 发布标准 issue
1.2. 拆 TODO 关联标准 issue
1.3. 拿 TODO，写代码，lazygit nvim review 不满意则重复此步骤
1.4. 确认无误 commit push 触发 ci ci 失败 停留在当前TODO,重复1.3，成功且满意，勾选 issue 完成的 TODO 项，开始拿下一个 TODO
1.5. 所有 TODO 轮空，结束此轮 - 开始下一个需求
谢谢你看到这里，欢迎评论讨论
网友解答：--【壹】--： huerfano66:
，这个是什么工具啊，这终端好看多了
都是人才
--【贰】--：
todo 的 plan 也发 issue，不写入文件，todo 的 issue 关联 标准 isuue，构成解锁系统，commit 的时候可关联可不关联，但要回填 checkbox，这样下次干活，先拉 issue 启动时间短。
--【叁】--：
建议看一下autoclaude这个项目,还有Google的jules项目
--【肆】--：
好，谢谢佬
--【伍】--：
tmux、lazygit 和 nvim
--【陆】--：
大佬，是让codex cli、claude cli 生成规范时候利用 gh 自己发 issue，然后拆解时候也把 todo plan 文件发issue （关联起来）吗，然后完成时候让commit带上这些issue 的id？
--【柒】--：
感觉和claude的skill------https://github.com/obra/superpowers思路差不多
--【捌】--：
佬，这个是什么工具啊，这终端好看多了
--【玖】--：
看了一眼他的readme确实，思路上很相近。 当然，人家更大神一点儿。 我这套的好处主要是。 就是当我没有额度的时候，我可以薅免费的。 再来换另一个干活。
--【拾】--：
感谢大佬。
--【拾壹】--：
感谢大佬分享
--【拾贰】--：
我的想法是不要本地文件，因为换 cli 重读会很重，基于 issue，其实很轻巧，它第一次拉下来也多是标题之类的元信息，需要的话才读内容，相当于加载了上下文。而且比如也可以约束基于 label 的方案，一个 feature 一个 label，比本地文件灵活。open 和 close 也自带状态了，不会因为自己没来得及改记录在本地的文档，而在下次打开 cli 引入过多，错误的信息。
概览
workflow1920×1047 431 KB
前置工具
- tmux
- codex/claude
- lazygit
- nvim
- github cli
方法优点
- 上下文共享/不怕换cli
- 领域收窄/单步可验证
- 关注变动，保持代码可控增长
方法分享
这是我在重构 fcitx5-vinput 时候摸索出来的方法，目前还不是特别成熟，欢迎各位佬交流。
背景
0.0
起初写这个语音输入法自用的时候大概只 vibecoding 了 一天，第一天的需求的实现方式就是无脑和 codex 聊天，实现/编译/本地验证。 这个时候的问题，代码里充斥着硬编码，所有功能堆在多个单文件里，项目结构纯平铺
1.0
视频发布出去之后，迎来了很多外部需求，新需求要与旧代码融合，仍旧先无脑纯聊，结构上大平铺，迎来了项目第一次的屎山。
2.0
github 收获了一部分 star 想把这项目做好，所以开始重构，重构之前思路已经相对清晰要做的功能，本地识别/llm后处理/云asr接入/流式接入，对于云asr的接入也已经确定了 基于 std 标准流的方案，做了可行性验证。
方法思路
- 以 github issue 为串联工具，串起整个工作流程，保证工作计划/步骤/进度的清晰
- 以 lazygit 为 review 工具，关注每次代码变更的增长，少量可控的揪出坏味道代码，及时纠偏
- 以 nvim 作为全局概览，主要关注 目录结构/lsp 报错等。
- 以 github action worflow 作为后验证步骤 （至少要过编译）
- 这套方法论给我最大的体验实际上是开发视角的转变，对于独立开发来说，把人从开发者这个劳动中抽离出来，人更多担任是产品经理和测试的角色。
这套思路里 github 是提效流程的主线，且 github 本身擅长做这些，issue 就是用来提问题的，action 就是用来构构建的，我们的主要工作只是把他们原本的功能接入我们的开发流程。
方法实践
- 导航到开发项目，开 tmux 左右 panel，左边放 codex/claude 右边 放 lazygit
image1366×768 190 KB
- 另开 tab 放 nvim
image1366×768 171 KB
这样我们基本的流程工具框架就搭建好了。
开发流程
- 规划在前，编码在后，在前置阶段，先提需求、定标准、定方向，这个阶段先和ai聊，聊完了，将标准先固定，以我的项目为例，核心的标准有 配置文件的 schema cli 的指令风格，参数等，这里只关注这个产物，在指定这个制定的时候一定尽可能把你自己能想到的问题都想了，不知道聊啥，就仅仅说出你自己的疑问，在 一轮一轮的 Q&A 中标准会浮现出来，标准定下来之后，可以让 ai 分析当前代码，做规划拆解为 todo 项目，发布 issue 关联刚刚的标准的issue。
- 小步迭代，进度可控，在编写代码阶段，ai 依据 todo task 的项目 逐一执行，执行完成后，人 review lazy git 的变更，满意则提交，让 ai check 上一项任务，开始像一个任务，不满意就让他接着改，对于目录级别的结构调整，lazygit 可能看着不太清晰，这个时候且下 nvim 看一眼。，所有 todo 完成关闭 所有相关 issue，开始下一个需求。
- 领域分割，清晰架构，每一轮基本上都是这样的流程，这里的原则是，每个issue只关注某一个领域的问题，如有其他的问题可以，发新的关联。
总体流程
- 挑出一个需求
1.1. 聊需求，定标准 发布标准 issue
1.2. 拆 TODO 关联标准 issue
1.3. 拿 TODO，写代码，lazygit nvim review 不满意则重复此步骤
1.4. 确认无误 commit push 触发 ci ci 失败 停留在当前TODO,重复1.3，成功且满意，勾选 issue 完成的 TODO 项，开始拿下一个 TODO
1.5. 所有 TODO 轮空，结束此轮 - 开始下一个需求
谢谢你看到这里，欢迎评论讨论
网友解答：--【壹】--： huerfano66:
，这个是什么工具啊，这终端好看多了
都是人才
--【贰】--：
todo 的 plan 也发 issue，不写入文件，todo 的 issue 关联 标准 isuue，构成解锁系统，commit 的时候可关联可不关联，但要回填 checkbox，这样下次干活，先拉 issue 启动时间短。
--【叁】--：
建议看一下autoclaude这个项目,还有Google的jules项目
--【肆】--：
好，谢谢佬
--【伍】--：
tmux、lazygit 和 nvim
--【陆】--：
大佬，是让codex cli、claude cli 生成规范时候利用 gh 自己发 issue，然后拆解时候也把 todo plan 文件发issue （关联起来）吗，然后完成时候让commit带上这些issue 的id？
--【柒】--：
感觉和claude的skill------https://github.com/obra/superpowers思路差不多
--【捌】--：
佬，这个是什么工具啊，这终端好看多了
--【玖】--：
看了一眼他的readme确实，思路上很相近。 当然，人家更大神一点儿。 我这套的好处主要是。 就是当我没有额度的时候，我可以薅免费的。 再来换另一个干活。
--【拾】--：
感谢大佬。
--【拾壹】--：
感谢大佬分享
--【拾贰】--：
我的想法是不要本地文件，因为换 cli 重读会很重，基于 issue，其实很轻巧，它第一次拉下来也多是标题之类的元信息，需要的话才读内容，相当于加载了上下文。而且比如也可以约束基于 label 的方案，一个 feature 一个 label，比本地文件灵活。open 和 close 也自带状态了，不会因为自己没来得及改记录在本地的文档，而在下次打开 cli 引入过多，错误的信息。