从 Issues 到 Wishes：开源协作模式的范式转移

摘要：当 AI 编程工具的能力突破临界点，开源协作的核心正在从"代码贡献"转向"需求策展"。我们正在见证一个历史性的转变：以前开源的是行动（Action），现在开源的是想法（Idea）。

Part 1: 一个工作流引发的思考

最近，开源社区中出现了一种颠覆性的工作流变化。分享这一模式的是 yetone（关西鹏）——一位在开源社区极具影响力的开发者。

他最知名的项目是 avante.nvim，一个模拟 Cursor AI IDE 体验的 Neovim 插件，在 Hacker News 等平台引发广泛讨论。Cursor 的设计主管 Ryo Lu 曾公开邀请他加入团队，Cursor CEO 也关注了他的账号。目前，他正在构建一个名为 Alma 的新项目，并在 X 平台拥有超过 6.8 万粉丝。

正是这样一位深度参与 AI 编程工具生态的开发者，分享了他的新工作模式：

"以前用户在 GitHub 里提 issues 和 PR，我去实现或者 review。现在用户在 feedback 网站提交 feature request，经审核过后一键转发到 Claude Code 自动化实现，直接合并到主分支。"

这不是个例。当 AI 编程工具的能力突破临界点后，开源协作的核心正在从代码贡献转向需求策展。传统的 Issue → PR → Review → Merge 链条正在被打破，取而代之的是一条以"意图"为核心的自动化流水线。

Part 2: 传统开源协作的瓶颈

贡献者视角：陡峭的门槛

在传统模式下，一个外部开发者想要贡献代码，必须跨越多道门槛，导致大量创意流失：

[产生想法] ──▶ [环境搭建] ──▶ [源码理解] ──▶ [功能实现] ──▶ [PR 流程] ──▶ [代码合并]
              流失 ~40%      流失 ~30%      流失 ~20%      流失 ~10%

结果：一个想法从产生到落地，往往需要数周甚至数月。很多好想法因为贡献门槛太高而流失。

维护者视角：三重困境

• Review 成本高：每个 PR 都需要仔细审查代码质量、安全性、风格一致性
• 沟通成本高：与不同背景的贡献者反复对齐需求理解（Context Switching）
• 质量参差不齐：许多 PR 甚至需要维护者重写才能合并

Part 3: 许愿式开发（Wish-Driven Development）

新模式可以被称为许愿式开发——用户负责许愿，维护者负责策展，AI 负责实现。

核心工作流

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  用户提交    │ ──▶ │  维护者审核  │ ──▶ │  AI 实现    │ ──▶ │  合并主分支  │
│  Feedback   │     │  + 策展      │     │  (Claude)   │     │             │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘
      ↑                   ↑                   ↑
   仅描述需求         核心壁垒：            无人工
   无需代码          判断做什么           Code Review

关键环节是中间的"审核 + 策展"。这一步决定了：

• 哪些需求值得实现
• 需求的优先级排序
• 需求描述的规范化

正如原帖作者指出的：核心壁垒是"经审核过后"这一步。

让 AI 可靠实现需求的关键：Spec-Driven Development

为什么有些人的 AI 编程工具"可以完成一整个需求"，有些人的却"必须手把手"？

区别在于是否采用了 SDD（Spec-Driven Development，规格驱动开发）。

核心原则：

1. 先写规格，后写代码
2. 小步迭代，持续验证
3. 明确边界条件

Spec 示例

不要直接给 AI 模糊指令，而是提供结构化的 Spec：

## Feature: 用户反馈自动分类

### 1. 需求背景
用户提交的 feedback 类型多样，需要自动分类以便后续处理。

### 2. 验收标准 (Acceptance Criteria)
- [ ] 系统能识别 `bug report` / `feature request` / `question` 三种类型
- [ ] 分类准确率需 > 90% (基于测试集)
- [ ] 单条处理时间 < 2 秒

### 3. 边界情况 (Corner Cases)
- **空输入**：应返回标准错误提示 JSON
- **多语言混合**：以文本中占比最高的语言为准进行分析
- **无法分类**：标记为 `needs-review` 人工队列

实践建议：可以参考 GitHub Spec Kit 中的"开发九课"，尤其是前三条——需求清晰化、验收标准明确、边界条件定义。

Part 4: 两种模式的深度对比

结论：核心壁垒已从"写出高质量代码"转移到了"审核与定义（Audit & Define）"。

Part 5: 潜在风险与防御体系

风险 1: 需求漂移（Scope Creep）

问题：自然语言是模糊的，直接转发可能导致 AI 实现偏离预期。

防御方案：引入 Product Agent 层

用户 Feedback → Agent 转化为 Gherkin 用例 → 人工确认 → Coding Agent 实现

这样 AI 提交的不只是 Feature，而是自带绿色构建的可交付单元。

风险 2: 质量失控

问题：放弃人工 Code Review 听起来很疯狂。

防御方案：

• CI 强制拦截：AI 生成的代码必须通过所有自动化测试
• 健康度审计：定期人工抽查代码库结构
• 渐进式信任：从小功能开始，逐步扩大 AI 的自主范围

风险 3: 上下文丢失（Context Loss）

问题：AI 不懂项目的"历史包袱"和架构决策。

防御方案：

• 维护 CLAUDE.md 或 CONTEXT.md，作为项目的"长期记忆"
• 将关键架构决策（ADR）文档化，作为 Prompt 的一部分
• 定期更新项目规范

Part 6: 范式转移的深远影响

对个人开发者

利好：一个人维护大型项目的时代来了。当"实现"不再是瓶颈，你的产出上限取决于：

• 你能策展多少好需求
• 你的系统设计能力

对开源社区

可能的变化：

• 贡献形式多样化：提一个高质量的 Feature Request，写一份清晰的 Spec，甚至更新文档，都将成为一级贡献
• 社区重心转移：GitHub Issues 区将变得比 PR 区更热闹，社区讨论将更聚焦于"产品方向"而非"代码风格"
• 协作模式重构：GitHub PR 可能不再是唯一的协作中心

新的稀缺能力

• 需求的表达与规范化
• 架构决策与系统设计
• 策展与优先级判断

Part 7: 局限性与反思

这种模式并非银弹，它有明确的适用边界。

✅ 何时适用"许愿式开发"

• 功能相对独立、模块化程度高
• 项目有良好的自动化测试覆盖（Safety Net）
• 维护者具备极强的需求拆解能力
• 对实时性要求不高

⚠️ 何时仍需"传统模式"

• 涉及核心架构的底层变更
• 安全敏感的加密/鉴权模块
• 需要极深领域知识（Domain Knowledge）的复杂算法
• 跨模块的复杂重构

未解决的问题

• 贡献归属：AI 实现的功能，贡献者是提需求的用户还是维护者？
• 知识传承：当代码主要由 AI 生成，项目知识如何传承？
• 社区凝聚力：减少直接代码协作，会影响社区氛围吗？

结语

"以前开源的是行动，现在开源的是想法。"

不仅是AI工具的胜利，更是人类价值的回归。当 AI 承担了繁琐的"砌砖"工作，开源维护者终于可以从无穷尽的 Code Review 中解放出来，去扮演更重要的角色：架构师与产品经理。

开源的本质——聚集分散的智慧解决共同的问题——没有变。变的是，我们现在可以用更纯粹的智慧（想法），去驱动更强大的生产力（AI）。

也许用不了多久，"提交一个好的 Feature Request"会和"提交一个好的 PR"一样，成为开源贡献的标准方式。