别再被“什么时候做”追杀：vibe 项目公开路线图与投票墙实战

为什么要把路线图公开

每个做过产品的 vibe coder 都经历过同一个噩梦：私信、评论区、社群里反复出现同一句话——"什么时候支持 X 功能？"你第一次回答得很认真，第十次开始复制粘贴，第一百次直接已读不回。更糟的是，用户会自己脑补答案："作者上个月说在做了""隔壁竞品都有了"，然后在你毫无准备的时候爆发一波差评。

公开路线图解决的不是"规划"问题，而是"信息不对称"问题。它把三类高频客服成本一次性降下来：

• 重复提问。"做不做 X"有了唯一可查的答案，用户先查路线图再提问，提问量通常能降一半以上。
• 预期管理。用户看到自己的请求躺在"考量中"而不是石沉大海，耐心会显著变长。沉默是最贵的，它逼用户用差评来确认你还活着。
• 决策背书。当你拒绝一个呼声很高的需求时，"我们评估过，路线图里写了为什么不做"比任何临场解释都有力。

但公开路线图有个前提：只在产品出现 PMF 信号之后再开。日活还没过百、核心流程还在大改的阶段，你的路线图每周都会被自己推翻。过早公开等于给自己挖坑——用户会把"计划中"当成"承诺"，而你根本还没想清楚。判断标准很实在：当你已经连续三次被问到"接下来做什么"，而不是"这东西到底干嘛的"，就是开路线图的时机。

另外要先划清边界：路线图讲的是"未来要做什么"，changelog 讲的是"过去做了什么"。前者是预期管理，后者是交付证明。两者联动，但绝不能混成一锅粥——路线图里塞满已上线功能，会让它失去"看未来"的价值。

路线图状态机：请求的一生

公开路线图最常见的失败模式，是状态含糊。一个条目写着"考虑中"躺了八个月，用户问就是"还在考虑"，最后谁都不信了。解法是把状态做成严格的状态机，每个状态有明确定义、流转条件和用户可见文案：

• 考量中（Under consideration）——请求已收到，正在收集投票和讨论。用户可见文案示例："我们看到了，正在看有多少人需要它。投票和留言会直接影响优先级。"流转规则：票数/讨论热度达标则晋升为"计划中"；明显不符合产品方向则进入"已拒绝"。
• 计划中（Planned）——已采纳，排进开发队列，但还没开工。用户可见文案："已确认要做，排期中。注意：计划中不等于承诺上线日期。"流转规则：开工转"开发中"；热度长期不足或战略变化可降级回"考量中"，或转"已拒绝"。
• 开发中（In progress）——正在做。用户可见文案："正在开发，欢迎到讨论区提细节建议，大的方向已经冻结。"流转规则：发布转"已上线"；遇到做不动的情况（技术卡点、战略转向）转"已拒绝"，且必须写清楚原因。
• 已上线（Shipped）——终态。条目自动归档，并反向链接到对应的 changelog 条目，形成"请求→上线"的完整证据链。
• 已拒绝（Declined）——终态，但不是垃圾桶。每个被拒绝的请求都要留一条公开的拒绝理由，这是整个机制里信任含量最高的部分，后面单独讲。

允许的回流只有两条虚线：开发中→计划中（返工、重新排期），计划中→考量中（热度不够，降级）。已上线和已拒绝是终态，不允许复活——想重做就开一个新请求，引用旧的。这条铁律防止路线图变成可以随意涂改的草稿纸。

状态机一共五个状态，宁可少不可多。我见过有人做十几个状态（"评审中""设计中""联调中"…），结果维护成本爆炸，三个月后没人更新。五个是上限，对应用户真正关心的五个问题：你们看到了吗？会做吗？开始做了吗？上线了吗？为什么不做？

投票墙实现：票不是越多越好

投票墙是路线图的输入端。它的技术实现不难，难的是规则设计——规则错了，票数会变成噪音。

数据模型：request 与 vote 分开

请求和投票必须是两张表，不要图省事把票数只存成请求上的一个数字。请求表存内容和状态，投票表存"谁给哪个请求投了票"。这样你才能回答关键问题：这 200 票里有多少是付费用户？有多少是注册三天的新号？票数的时间分布是集中爆发还是细水长流？这些问题的答案，决定了票数的可信度。

一人一票 vs 权重投票

默认一人一票，简单、可解释、不容易被质疑公平性。但纯一人一票有个死穴：投票的人不等于付钱的人。免费用户人多声大，付费用户沉默但贡献收入。折中方案是权重投票：普通用户 1 票，付费用户 3 票（或 5 票），权重规则必须公开写在投票墙旁边。权重一旦藏着掖着被发现，就是一次信任事故。

还有一种更激进的：月票制。每个用户每月 N 张票，投出去就没了，下个月刷新。这招专治"顺手投票"——当票是稀缺资源，用户才会认真想"这个功能值不值得我花一张票"。Canny 这类老牌工具默认就是这个思路的变体。

冷启动：前 50 个请求最难

投票墙刚上线时最尴尬：空空如也，没人愿意当第一个提交的人。解法是"预置种子"：把你过去三个月在私信、评论区、社群里收到过的真实需求整理成 20~30 个请求，自己先发上去，署名写"来自用户反馈整理"。用户看到"原来大家提的都在这儿"，参与门槛瞬间降低。千万别伪造投票数，种子请求票数从零开始，让真实投票慢慢长出来——被发现刷种子票，整个投票墙的可信度直接归零。

防刷：三道线就够了

投票墙的刷票动机比你想象的强：竞品、想白嫖企业版功能的人、单纯想搞事的人。三道防线，按成本从低到高：

• 账号门槛。投票必须登录，且账号注册超过 7 天（或完成邮箱验证）。新号投票权重降为 0.1 或直接不计入公开票数。这条拦掉九成机器号。
• 速率限制。同一账号每小时最多投 10 票，同一 IP 每天最多注册 3 个投票账号。注意是"限制"不是"封禁"，误伤真实用户的代价远大于放过几个刷票的。
• 行为验证码。只在触发异常模式时弹出（比如 1 分钟投了 20 票），正常用户一辈子见不到它。把验证码做成常态，是赶走真实用户的最快方式。

另外记住一条：永远不要公开"谁投了票"的完整名单，只公开票数和（可选的）脱敏后的投票人画像（"38% 来自付费用户"）。完整名单是社工和骚扰的温床。

请求去重与合并：投票墙的日常

投票墙上线第一周你就会发现：同一个功能被五个人用五种说法各提了一遍，票数分散在五个请求上，每个都只有十几票，看起来都不重要。去重和合并是投票墙运营里最日常、也最决定数据质量的工作。

相似请求合并策略

合并不是删除。被合并的请求保留原页面，只是状态变为"已合并"，并醒目地指向主请求；它的票数要折算进主请求（权重票按原权重折算，一人一票直接累加）。合并操作必须留痕：谁在什么时候把 A 并入了 B，理由是什么。这条记录公开可见——被合并的提交人最在意的是"我的声音有没有被吞掉"，留痕就是答案。

合并的判断标准是"解决同一个问题"，而不是"字面相似"。"支持导出 PDF"和"支持导出 Excel"不要合并，它们是不同的工作量、不同的用户群；但"深色模式"和"夜间主题"必须合并。拿不准的时候宁可不并，错误合并比重复请求更伤信任，因为前者让用户觉得你在和稀泥。

"已在路线图"的自动关联

用户提交新请求时，前端应该实时做一次相似度检索，把最像的 3 个已有请求（或路线图条目）推到他面前，问一句："你说的是不是这个？是的话直接投票，不用新开。"这一步能拦截掉至少三分之一的重复提交。实现上不用搞向量检索那么重：标题分词 + 关键词重合度排序，对几千条数据完全够用，数据量上万再考虑上 embedding。

版主合并操作流

一人团队没有版主团队，合并操作就是你自己每周花 20 分钟做的事。固定流程：每周扫一遍新增请求→标出疑似重复→逐个确认合并或保留→给被合并的提交人发一条站内信（模板后文给）。不要攒到月底一次处理，重复请求放越久，票数分散得越厉害，合并时的"票数搬家"越容易引发争议。

路线图页面信息架构：时间轴还是看板

两种主流呈现，各有各的坑。

时间轴适合用户量大、发布节奏稳定的产品，一眼能看到"这个季度有什么"。但它的毒性在于：时间轴上的每个日期都会被用户当成承诺。Q3 的条目拖到 Q4，你收到的不是"理解"，而是"你们失信了"。用时间轴必须配免责声明，而且颗粒度不要细到月份——"2026 下半年"比"2026 年 9 月"安全得多。

看板（按状态分列：考量中 / 计划中 / 开发中 / 已上线）适合绝大多数 vibe 项目。它不承诺时间，只承诺状态，预期管理的难度低一个数量级。GitHub Projects、Trello、Notion 都能直接搭，零开发成本。我的建议：默认用看板，除非你有专人维护排期。

"近期 / 中期 / 远期"三段式

如果看板列太多，可以按时间 horizon 折叠成三段：近期（1 个月内）、中期（1 个季度内）、远期（探索方向）。注意远期那一栏的文案要格外小心，写"探索方向，不承诺做"，而不是"未来计划"。远期栏是给你画饼用的，但饼必须标明是饼。

每个卡片的必填字段

路线图卡片不是标题列表，每个条目至少要有这三个字段，否则它就是一张漂亮的废纸：

• 问题陈述（一句话）。不写"做导出功能"，写"用户每月手动整理账单要花 2 小时，导出功能要把这件事压到 5 分钟"。写清楚"为谁解决什么问题"，能过滤掉一半拍脑袋的需求。
• 目标用户。"所有用户"等于没写。写"重度报表用户（约占付费用户的 20%）"，让看的人自己判断"我是不是目标用户"。
• 成功标准。"上线就算成功"不叫标准。"上线后 30 天内 15% 的付费用户用过一次"才叫标准。成功标准是写给未来的自己看的，防止上线后没人用还自我感动。

可选但推荐：关联的原始请求链接（让投票的人能追踪到底）、负责人（一人团队就写你自己的名字，写名字比写"团队"更让人信任）。

举个完整卡片的例子。标题："CSV 批量导入（近期）"；问题陈述："从竞品迁移过来的用户，手动一条条录入 500 条数据要花整整两天，很多人迁到一半就放弃了"；目标用户："正在从竞品迁移的试用用户，约占新增注册的 15%"；成功标准："上线 60 天内，30% 的新注册用户使用过导入功能，迁移完成率提升 10 个百分点"。这样的卡片，用户看一眼就知道"这事跟我有没有关系"，你过三个月回看也知道"当初为什么要做它"。

沟通节奏：更新频率比内容重要

路线图最大的敌人不是做错规划，是停止更新。一个三个月没动过的路线图，比没有路线图更伤信任——它明明白白地告诉用户：作者连装都懒得装了。

更新频率：双周或月度二选一。双周适合开发节奏快的产品，月度适合副业项目。选哪个不重要，重要的是固定且公开："每月 1 号更新路线图"写在页面顶部，然后雷打不动。频率一旦固定，用户会自己形成"到日子再来看"的心智，不会在你耳边天天催。

每次更新做三件事：新晋升的条目（从考量中到计划中）、状态变化的条目（开发中到已上线）、被拒绝的条目及理由。不需要长篇大论，列表 + 一句话说明就够了。更新日志本身可以很短，短而准时，胜过长而随机。

与 changelog 的联动

条目从"开发中"转到"已上线"的那一刻，自动在路线图卡片上挂出 changelog 链接，同时在 changelog 条目里反向引用"来自 #128 号请求的投票"。这个双向链接是整套机制的信任放大器：用户能亲眼看到"230 个人投票的功能真的上线了"，下一次投票的参与意愿会完全不同。实现上就是 roadmap_items 表里存一个 changelog_entry_id，发布时自动回填。

延期和砍需求的沟通话术

延期一定会发生，话术决定它是"信任损耗"还是"信任投资"。模板就三句：发生了什么（"X 功能的开发中发现 Y 依赖比预期复杂"）、新的预期是什么（"从本月推迟到下季度初"）、用户现在能做什么（"等不及的可以先用 Z 方案顶一下，教程在这里"）。永远不要只说"延期了"，不说原因和新的时间。没有原因的延期会被脑补成"作者跑路了"，没有新时间的延期会被脑补成"永远不会有了"。

砍需求（计划中→已拒绝）更敏感，话术放到下一节单独讲。

优雅拒绝：不伤社区感情的三种说法

拒绝是公开路线图里技术含量最高的一环。数据显示，一个写清楚理由的"已拒绝"，对社区信任的伤害远小于一个石沉大海的"考量中"。三种拒绝话术，对应三种真实情况：

第一种：方向不符。"这个需求我们认真评估过，但它和产品的核心定位冲突：我们是给个人用户做的轻量工具，这个功能会把产品带向企业级复杂度。我们决定不做，未来也不会重新考虑。"关键点：明确说"未来也不会重新考虑"，给死心的人一个痛快，比"以后再说"的钝刀子仁慈。

第二种：代价太大。"实现这个功能需要重写同步引擎，大约是 3 个月的全职工作量。以我们目前的团队规模，接了这个就意味着 Q3 的其他三个功能全都要砍。我们选择先保那三个。"关键点：把机会成本摆出来。用户不怕你说"做不起"，怕的是你不说理由。把账算明白，大部分人会理解——他们自己也是做取舍的人。

第三种：已有替代方案。"这个场景其实已经有解法了：A 设置 + B 工作流组合起来能达到 80% 的效果，教程在这里。我们暂时不单独做这个功能，如果这套组合方案用的人多，我们再重新评估。"关键点：拒绝的同时给出口子。用户要的是"问题被解决"，不一定是"按我说的方案解决"。

三种说法一个共同点：拒绝的是"这个方案"，肯定的是"这个需求背后的问题"。永远不要写"这个需求没价值"——你否定的应该是优先级和方案，而不是用户的判断力。

另外准备一个"暂不做"的技术债式记录：有些请求现在不做，但你知道它迟早会回来（比如"等用户量到 10 万再考虑 SSO"）。给它建一个特殊的"已拒绝-条件性"记录，写清楚触发条件："当企业版用户超过 50 家时重新评估"。这不是画饼，这是把决策逻辑公开，条件到了不做，你才会被追责。

数据表设计：三张核心表

前面所有的规则，最后都要落到表结构上。三张表，不多不少：

• feature_requests——功能请求。status 用枚举对应状态机的五个状态；merged_into_id 是自引用外键，被合并的请求指向主请求；vote_count 是冗余字段，用事务维护，避免每次 COUNT(*) 全表扫描。
• votes——投票。UNIQUE(request_id, user_id) 是防重复投票的最后一道硬防线，应用层的检查都可能被并发绕过，唯一约束不会；weight 字段支撑付费用户加权。
• roadmap_items——路线图条目。从 feature_requests 晋升而来，source_request_id 保留血缘关系；problem_statement / target_users / success_criteria 是卡片必填三字段；horizon 存 near/mid/far 三段。

Prisma schema 参考（按自己项目的命名习惯调整）：

model FeatureRequest {
  id           String   @id @default(uuid())
  title        String
  description  String   @db.Text
  status       RequestStatus @default(CONSIDERATION)
  authorId     String
  mergedIntoId String?
  mergedInto   FeatureRequest? @relation("Merge", fields: [mergedIntoId], references: [id])
  mergedFrom   FeatureRequest[] @relation("Merge")
  voteCount    Int      @default(0)
  votes        Vote[]
  roadmapItems RoadmapItem[]
  createdAt    DateTime @default(now())
}

model Vote {
  id        String   @id @default(uuid())
  requestId String
  request   FeatureRequest @relation(fields: [requestId], references: [id], onDelete: Cascade)
  userId    String
  weight    Int      @default(1)
  createdAt DateTime @default(now())

  @@unique([requestId, userId])
}

model RoadmapItem {
  id               String   @id @default(uuid())
  title            String
  problemStatement String   @db.Text
  targetUsers      String
  successCriteria  String
  status           RoadmapStatus
  horizon          Horizon  // NEAR | MID | FAR
  sourceRequestId  String?
  sourceRequest    FeatureRequest? @relation(fields: [sourceRequestId], references: [id])
  changelogEntryId String?
  updatedAt        DateTime @updatedAt
}

enum RequestStatus { CONSIDERATION PLANNED IN_PROGRESS SHIPPED DECLINED }
enum RoadmapStatus { PLANNED IN_PROGRESS SHIPPED }
enum Horizon { NEAR MID FAR }

投票写入必须用事务：插入 Vote 行、voteCount +weight、检查唯一约束冲突，三步原子完成。伪代码只有一句话：先插 vote 表，靠 @@unique 挡重票，成功后再加 voteCount。顺序反了（先加数再插表），并发下必出脏数据。

常见坑：路线图不是许愿池

坑一：路线图变成"承诺清单"。这是最大的坑，有法律和预期双重风险。用户拿着你路线图上的"计划中"截图去要求退款、去社交媒体挂你，不是没发生过。对策三件套：页面顶部放"路线图是当前计划，不是承诺，可能随时调整"的声明；状态文案里"计划中"永远不配具体日期；重大条目用 horizon（三段式）代替时间点。声明不能只有一句，要出现在用户每次看路线图都能看到的位置。

坑二：竞争对手抄作业。公开路线图等于把产品方向免费送给竞品。取舍在于：路线图的价值（信任、投票、客服降本）通常远大于被抄的风险——因为路线图上写的是"做什么"，真正的壁垒是"做得怎么样"和"做得多快"。真有杀手锏级别的功能，别放公开路线图，放内部版。公开版和内部版分开维护，是成熟团队的标配，一人团队至少要在心里分两版。

坑三：投票被少数 loud 用户绑架。投票墙天然偏向"声量大"的用户：他们拉票、刷屏、在社群里造势。对策：票数只作为输入之一，不是决策本身。在路线图页面明确写出决策公式，比如"投票热度 40% + 付费用户占比 30% + 战略契合度 30%"。公式可以粗糙，但必须公开——公开的公式让落选者输得明白，不公开的"综合评估"让所有人觉得有黑幕。另外定期（比如每季度）复盘一次"高票但没做的请求"，公开解释原因，这是给投票机制续命的关键动作。

坑四：为了路线图好看而塞功能。路线图条目一多，页面就显得"产品很活跃"，于是有人开始把"换个按钮颜色"也写成路线图条目。路线图是战略沟通工具，不是工作日志。判断标准：这个条目值得用户专门点开看吗？不值得就别放。保持路线图在 10~20 个条目以内，超过 30 个就没人看了。

从今天开始的三步

别想着一次搭完投票墙 + 路线图 + 自动联动，一人团队的正确姿势是三步走：

1. 这周：用 Notion / GitHub Projects 搭一个五状态看板，把你现在心里"打算做的 10 件事"按考量中/计划中/开发中摆上去，配上问题陈述、目标用户、成功标准。公开链接，完事。
2. 下个月：加上最简投票——GitHub Discussions 的 👍 reaction 就够了，或者给每个条目加一个"想要"按钮。先跑起来，收集真实投票数据，再决定要不要做权重、防刷这些。
3. 有 100 个真实投票之后：再按本文的数据模型做独立的投票墙，把去重合并、自动关联、防刷、changelog 联动一个个加上。

公开路线图的本质，是把"我在认真做产品"这件事变成可验证的事实。用户不需要你每个需求都满足，他们需要的是：我的声音被听见了，决策有理由，承诺有回音。做到这三点，路线图就是你最便宜的增长工具。