ideas-inbox

name

ideas-inbox

description

管理开发/测试/体验产品时冒出来的新想法,防止'测试时一个想法直接变成开发计划修改'这种节奏被打断的情况。Use this skill whenever: (1) user is testing/experiencing a product they're building and mentions new ideas, (2) agent itself encounters bugs/improvements/extensions outside current task scope, (3) user says 'I just thought of...', '冒出来一个想法', '顺便也...', or any similar phrasing that suggests scope creep. Also trigger at end of dev sessions for inbox review. The skill enforces a three-class taxonomy (A-bugs/B-optimization/C-extension) and a 24-hour cooling rule for C-class ideas.

Ideas Inbox — 想法仓库纪律

测试/体验产品时冒出新想法是好事——说明产品直觉在线。但新想法直接变成开发计划的修改就是灾难。这个 skill 就是那道闸门。

核心机制

所有"测试时冒出的新想法",先进仓库,不直接进开发:

新想法 → 打 A/B/C 标签 → 进 ideas_inbox.md → 批次处理 → 进 ideas_parked.md 或下轮计划

三类想法分类法

类型	含义	例子	处理
A-堵漏	真 bug、空状态没处理、阻塞主路径	"新用户进来 Step 默认 done"	当前任务结束立刻修
B-优化	现有功能可以更好,但能用	"按钮位置太靠右"、"文案不准"	不动,攒批次
C-扩展	新功能/新场景/新模块	"应该再加个 XX 功能"	24 小时冷却后再决策

关键判断:

• 不确定 A 还是 B → 默认 B(更保守)
• 不确定 B 还是 C → 默认 C(更需要冷却)
• 想"小改一下"就直接动 → 错的,先记 B

文件位置和格式

项目根目录维护两个文件:

• ideas_inbox.md — 活跃想法,定期清理
• ideas_parked.md — 归档想法,不删但不做

条目格式(一行一条):

[X-类型] YYYY-MM-DD 简短描述 (可选:文件位置)

示例:

[A-堵漏] 2026-05-22 src/components/Step.tsx moduleStatus 默认 done
[B-优化] 2026-05-22 内容切入页按钮位置感觉太靠右
[C-扩展] 2026-05-22 用户可能希望保存灵感模板供下次复用
[B-优化] 2026-05-23 错误提示文案不够具体

不同角色的使用方式

用户测试产品时

1. 手边开 ideas_inbox.md
2. 新想法冒出来 → 3 秒内打标签写一行 → 继续测试
3. 不要中途打开 IDE/Claude Code 去改

Agent 开发过程中

详见 vibecoding-workflow skill 的「铁律二」

• 发现范围外的问题 → 写入 inbox,不打断当前任务
• 完成任务时,列出 inbox 新增让用户过目
• A 类严重 bug 例外:可以停下来问用户"是否现在处理"

Agent 帮用户测试/体验时

• 主动提醒用户:"我发现这里 X,要不要先记到 inbox?"
• 如果用户说"顺便改了吧",反过来劝:"建议先记 inbox,测完再批量处理,你看现在跑断节奏值得吗?"

批次处理流程

触发时机(任一即可):

• 每天结束
• 每个 sprint/任务结束
• inbox 累积超过 15 条
• 用户主动说"清一下 inbox"

处理步骤:

Step 1: 分类汇总

按 A/B/C 分组列出所有条目,用户视角看一眼。

Step 2: A 类处理

A 类应该已经在测试结束时立刻修了。如果还在 inbox 里,说明:

• 是误标(其实是 B/C)→ 重新标
• 是真 A 但被搁置 → 升级为最高优先级任务

Step 3: B 类筛选

所有 B 类条目过一遍,问每条:

• 这个问题影响当前主路径吗?是 → 加入下轮计划
• 用户真的会被这个细节困扰吗?是 → 加入下轮计划
• 否 → 移到 ideas_parked.md

经验法则:B 类积累 20 条,真正重要的只有 2-3 条。仓库的大小本身就是过滤器。

Step 4: C 类决策(关键)

对每个 C 类想法,问:

问题一:满 24 小时了吗?

• 否 → 跳过,下次再说
• 是 → 进入问题二

问题二:现在是 0→1 还是 1→10?

• 0→1 阶段 → 90% 的 C 类应该被拒,移到 parked
• 1→10 阶段 → 进入问题三

问题三:这个扩展能让某个已经在用的用户解决一个具体痛点吗?

• 能,且痛点具体 → 加入下轮计划
• 不能,或痛点抽象("用户可能希望...")→ 移到 parked

Step 5: 更新文件

• 进下轮计划的 → 从 inbox 移除,写入项目 backlog
• 移到 parked 的 → 从 inbox 剪切到 ideas_parked.md
• 还需要观察的 → 留在 inbox,标注观察日期

反模式

❌ "这个小改 1 分钟就好了"——心流断掉 20 分钟,不是 1 分钟 ❌ "记下来一会儿再说"——必须当场打标签,否则等于没记 ❌ "C 类先做着看看"——C 类必过 24 小时冷却 ❌ inbox 累积超过 50 条不清理——失去过滤作用 ❌ A/B/C 都不标只是文字描述——分类动作本身是过滤器,不能省

为什么这套机制有用

1. 分开情绪和决策——测试时是"沉浸+敏感"状态,决策需要"抽离+理性"状态,仓库就是物理隔离
2. 保护心流——心流断一次重新进入要 20-30 分钟
3. 暴露真实优先级——20 条 B 类里真正重要的只有 3 条,inbox 的大小就是过滤器
4. 历史档案——parked 文件保留所有放弃的想法,以后回头看能发现"当初觉得很重要但其实不需要"的规律

一句话总结

想法先进仓库,不直接进开发。打标签 + 24 小时冷却 + 0→1 阶段默认拒 C 类,三步过滤掉 80% 的伪需求。