方法分享 | 基于 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 作为后验证步骤 （至少要过编译）
• 这套方法论给我最大的体验实际上是开发视角的转变，对于独立开发来说，把人从开发者这个劳动中抽离出来，人更多担任是产品经理和测试的角色。