一人工程 · solus opus

← 全部作品

one-man-projectsimedwtransformerplanningcontinuatormusic-ai

simedw 的下一步：bar/measure token + planning + parallel picking

simedw 在 HN 评论里说下一步三件事：1) bar/measure token 让模型懂小节，2) longer-term planning 类似 CoT，3) parallel continuation picking 并行生成多个续写挑最好。一人工程的研究路径——清晰、可执行、不画饼。

simedw 在 HN show 评论区自己列了下一步三件事：

  1. bar/measure token — 给模型加小节标记
  2. longer-term planning — 类似 Chain-of-Thought 的 planning step
  3. parallel continuation picking — 并行生成多个续写，挑最好的

三件事都很具体。每一个都有明确的技术路径。一人工程的研究方向，不是空想。

第一件事：bar/measure token

现在的模型表征：

  • note events (pitch, duration, velocity)
  • time shift events
  • compound note events（simedw 的 5× speedup 表征）

simedw 想加：

  • bar/measure token — 每个小节开头加一个特殊 token

为什么？

  • 现在模型不知道「这里是小节边界」——靠 time shift 推算
  • 加 bar token 后，模型直接知道节奏结构
  • 训练时 bar token 提供节奏 anchor
  • 生成时模型可以「以小节为单位」规划

类似 NLP 里加 <|sep|> token 让模型分句。

具体技术：

  • 每个 bar 第一个 note event 前加 <|bar|> token
  • vocab 加 1 个 token
  • 训练数据预处理加 bar marker
  • 模型架构不变（仍然是 transformer）

效果预期：

  • 节奏感更强
  • 跨小节 motif 更连贯
  • 小节内的 pattern 更稳定

一人工程的工作量：1-2 周。

第二件事：longer-term planning

现在的模型：

  • 输入：用户按的几个音（512 notes context）
  • 输出：下一个 note event
  • 没有「先想再弹」的步骤

simedw 想加：

  • 第一步：模型先生成「planning」——这个 continuation 的大致方向（key, tempo, mood, motif）
  • 第二步：模型根据 planning 生成具体 note events

类似 CoT（Chain-of-Thought）：

  • 「让我想想……这个 continuation 应该是 Cm 小调，缓慢的，类似巴洛克风格」
  • 「好，现在我开始按……C4, D#4, G4……」

具体技术：

  • 加一个 <|plan|> token，模型先生成 planning text
  • planning 嵌入到 attention context
  • 生成 note events 时 attend 到 planning

效果预期：

  • 长程 coherence 更好
  • 风格控制更精确
  • 用户可以中途改 planning（影响后续 generation）

一人工程的工作量：2-3 周。

第三件事：parallel continuation picking

现在的生成：

  • 模型采样 → 1 个 continuation
  • 用户听 → 接受 / 重生

simedw 想做的：

  • 模型并行采样 16 个 continuation
  • simedw 用 Gemini pairwise 评分
  • 选分数最高的那个返回给用户

类似 LLM 推理的 best-of-N sampling：

  • N=16 个候选
  • reward model（Gemini）评分
  • argmax(reward) 返回

但关键创新：

  • Gemini 不是「通用 LLM judge」，而是 simedw fine-tune 过的 music preference judge
  • 评分标准是 simedw 自己的「好听」标准
  • 16 个候选让用户选 → 收集 preference → 喂 DPO

具体技术：

  • inference 时 batch_size=16 并行采样
  • 每个采样 temperature=1.0（diversity）
  • Gemini 给每个候选打分
  • 选 top-1 返回

效果预期：

  • 用户每次得到的都是 16 个候选里最好的
  • 用户偏好数据更多 → DPO 更好
  • 整体质量上升

一人工程的工作量：1 周（pipeline + Gemini API）。

三件事的优先级

simedw 没说优先级。但从 HN 评论的语气看：

  • bar token：最先做（最容易、最直接）
  • parallel picking：中间做（pipeline 工作）
  • planning：最后做（最复杂）

理由：

  • bar token 是「表征改变」—— simedw 已经从 compound note events 验证了表征的力量
  • parallel picking 是「inference 优化」——不需要重新训练
  • planning 是「架构改变」——最复杂

simedw 的路径是从「表征」→「inference」→「架构」，一步一步加复杂度。

「表征 → inference → 架构」的一人工程研究路径

simedw 的研究路径：

  1. 表征改变（已完成）：compound note events → 5× speedup
  2. bar token（下一步）：继续表征改变
  3. parallel picking（下一步）：inference pipeline 优化
  4. planning（再下一步）：架构改变

每一步都比上一步复杂一点。但每一步都是可独立 ship 的：

  • 表征改变 → 训练时间减少 5×
  • bar token → 节奏感更好
  • parallel picking → 用户体验更好（每次得到的更好）
  • planning → 长程 coherence 更好

每一步都有自己的用户价值，不需要等所有事情做完才发布。

一人工程的「研究 vs 产品」边界

simedw 是 V7 contractor 业余做 piano app。研究和产品分得很清：

  • 研究：表征、规划、架构（这部分不直接 ship）
  • 产品：iPhone app、App Store、用户体验（这部分 ship）

研究改进的成果通过训练 / DPO / 部署 pipeline 进入产品。

研究 vs 产品的关系：

  • 研究是引擎（慢、深度）
  • 产品是车（快、用户价值）

simedw 的节奏：

  • 几周研究 → 一次大改进 → 一次 release
  • 不做天天 release（业余项目，没法 daily ship）

三件事的依赖关系

bar token ──→ 表征改变 ──→ 重新训练 ──→ DPO 用新表征
                  │
                  ↓
parallel picking ──→ inference pipeline ──→ 用户体验改进
                  │
                  ↓
planning ──→ 架构改变 ──→ 重新训练 ──→ DPO 用新架构

bar token 是 parallel picking 的前提（更好的表征 → 更好的候选）。

planning 是最后做的，因为它依赖前两个的成果。

「simedw 下一步」对一人工程的意义

simedw 的下一步路径展示了一人工程的研究纪律：

  • 不画饼：三件事都很具体，可执行
  • 不跳跃：从表征到 inference 到架构，一步步
  • 不堆人：每件事都是 1-3 周 1 人工作量
  • 不背离用户价值：每件事都对应一个用户可见的改进
  • 不重写：每件事都是「加」不是「改」，保留之前的工作

这是 OpenAI / Anthropic 不可能有的研究纪律——他们有几十个研究员，可以并行做很多事，但没有人 simedw 这种「一步步加复杂度，每步 ship」的克制。

「规划」的悖论

planning 这一步有一个悖论：

  • 目标：让模型有「先想再弹」的 planning 能力
  • 现实：模型是在训练数据上学 planning，不是真的 planning
  • 问题：用户怎么改 planning？改 plan token 吗？

simedw 可能的解法：

  • plan token 不是 hardcoded，是模型自己生成的
  • 用户可以「重 roll」plan token（保留 note generation）
  • 或者：用户可以「注入 plan token」（指定 key + mood）

这是 simedw 风格的「用户可控 + 模型灵活」平衡。

「parallel picking」的 inference cost

parallel picking 的成本：

  • 16 × 模型 inference 时间
  • 16 × Gemini API 调用 cost
  • 用户延迟 = max(16 个 inference) + Gemini 评分

simedw 的优化：

  • batch inference（4090 一次跑 16 个，比 16 次跑快）
  • Gemini Flash（便宜 + 快）
  • streaming output（用户先看到 partial result）

cost 估算：

  • batch inference 16 个 = 一次 4090 forward × 16 samples ≈ 1 秒
  • Gemini Flash 评分 16 个 ≈ 0.5 秒
  • 总延迟 ~ 2 秒（用户感觉「instant」）

cost 美元：

  • 4090 推理成本 = 忽略（已经买好）
  • Gemini Flash 16 次 ≈ $0.001
  • 总 cost $0.001 per generation

可接受。

「bar token」的最小实现

bar token 的最小可行实现：

  1. 修改数据预处理：
    • 读 MIDI 文件
    • 找到每个 bar 的开始（基于 time signature）
    • 在第一个 note event 前插入 <|bar|> token
  2. 修改 vocab：加 1 个 token
  3. 修改 positional encoding：bar token 也算 position
  4. 重新训练（用新表征）
  5. DPO（用新表征）

工作量：1-2 周。

效果：节奏感更好。

风险：bar token 位置不对 → 训练崩 → debug。

「simedw 下一步」的对照表

bar token parallel picking planning
类型 表征改变 inference pipeline 架构改变
训练？ 重新训练 不训练 重新训练
工作量 1-2 周 1 周 2-3 周
用户价值 节奏感更好 每次体验更好 长程 coherence
风险 中（数据预处理） 低（pipeline） 中（架构）
依赖 无 表征 表征 + pipeline

一人工程的研究节奏

simedw 的研究节奏：

  • 一个月 1-2 个改进
  • 每个改进独立 ship
  • 用户每天都有新版本

大公司的研究节奏：

  • 半年一个大版本
  • 一次 release 包含几十个改进
  • 用户半年等一次

一人工程胜在迭代速度 + 独立 ship。大公司胜在广度 + 资源。

「simedw 下一步」对社区的启发

simedw 的下一步清单公开：

  • HN show 评论区公开
  • simedw Twitter 公开
  • simedw 博客 / 视频公开

社区可以看到 simedw 的研究路径。这对独立开发者社区的启发：

  • 不要画饼：列具体的事，不说「我做 AGI for music」
  • 不要堆 feature：3 件事，每件对应一个用户价值
  • 不要重写：保留之前的工作，加复杂度
  • 公开研究：让社区学习 + 监督 + 反馈

「simedw 下一步」的总结

三件事都很具体：

  1. bar token → 表征改变，节奏感更好
  2. parallel picking → inference pipeline，用户体验更好
  3. planning → 架构改变，长程 coherence 更好

每件事 1-3 周工作量，每件事独立 ship。

一人工程的研究纪律：

  • 不画饼
  • 不跳跃
  • 不堆人
  • 不背离用户价值
  • 不重写

simedw 2026 的钢琴 app 会有这些改进。1-3 个月里陆续上线。

solus opus.