Bend2 / AI Agent 问题梳理
AI Agent 相关问题
- 速度太慢 — 不用 agent 的日子反而产出更高，agent 的 thinking paradigm 本身令人反感。
- Reward hacking — agent 写出的代码只对测试负责，测试没覆盖的部分靠碰运气。agent 找到的是"恰好能过测试"的方案，而不是正确的方案（关联 正确方案被绕过、代码质量崩溃）。
- 正确方案被绕过 — 很多模块最简单的方案就是正确答案，但 agent 仍然选择了更复杂、只对测试有效的写法（关联 Reward hacking、测试外行为不可预测）。
- 合并前不读 AI 代码 = 自毁 — 对维护性有害，属于根本性错误（关联 Reward hacking、正确方案被绕过 的后果）。
- 最佳用途边界 — agent 适合调试、调研、脚本/工具，不适合触碰长期维护的核心代码。
Bend2 项目具体问题
- C/Metal 编译器代码质量崩溃 — 作者原话"clusterfuck"，测试全过但 bug 极多（关联 Reward hacking、正确方案被绕过，AI 生成代码的直接后果）。
- 测试外行为不可预测 — 未覆盖的路径等同于 coin toss（关联 Reward hacking 的表现）。
- GPU 性能是核心竞争力 — 对手 Lean 非常强，必须有显著差异化才能发布。
- 发布前不能有 bug — 项目性质决定了有 bug 会很难看（关联 测试外行为不可预测 与此矛盾）。
- 时间紧迫 — clock is ticking，10h/天 SupGen，剩余给 Bend2。
元层面的讽刺
- Bend 自己的 proof system 本该解决这个问题 — 证明系统就是用来保证代码正确性的，但 proof system 是用 TypeScript 写的而不是 Bend，所以无法自证（关联 测试外行为不可预测，proof system 本可防止测试外的不确定性）。
- 没有自举（self-hosting） — 作者后悔没用 Bend 写 Bend，现在想做但时间不允许（关联 proof system、时间紧迫）。
MiniMax 稀疏注意力问题
标准 attention 的根本瓶颈
- O(n²) 复杂度 — 每个 token 要看所有其他 token，规模一大速度就不可用（关联 计算成本爆炸）。
- 长上下文计算成本爆炸 — 1M token 的深度处理需要 absurd amounts of GPU power（关联 O(n²) 复杂度 的直接后果）。
- 准确性和速度的矛盾 — 全量注意力保证质量但牺牲速度，必须在两者之间找平衡（关联 稀疏注意力 的动机）。
稀疏注意力的赌注
- 用"不看所有内容"换速度 — 先粗扫找相关部分，再只精读那些内容，像查索引（关联 准确性和速度的矛盾 的解法）。
- 相关性检索的覆盖风险 — 赌的是粗扫能找到真正重要的部分，遗漏的可能性存在（关联 稀疏注意力 的代价）。
- 10x/15x 加速来自跳过不相关 token — 不是优化计算本身，而是减少计算量。
Obsidian / Cortex #179 问题梳理
插件生态的稳定性问题
- 更新后界面崩溃 — 用户下载最新版本后按钮全部消失，原因通常是某个主题期望了某个特定行为。"You can 100% shoot yourself in the foot with that."（关联 无法穷举测试边缘情况）
- 无法穷举测试边缘情况 — 任何人都可以不经许可制作插件和主题，团队不可能覆盖所有组合（关联 更新后界面崩溃 的根因）。
- 对策是延长 beta 周期 — 每次更新在 catalyst 阶段停留数周到一个月，但依然不能完全避免。
商业模式的结构性困境
- 商业许可完全靠自觉 — 公司内两人以上使用需付费 $50/年，但无法强制执行。已知有千人以上公司不付费使用，"left probably millions of dollars on the table"（关联 取消强制商业许可）。
- 无法衡量活跃用户数 — app 内无 analytics，只能通过 GitHub 下载量和应用商店数字粗略估算（关联 取消强制商业许可）。
- 企业账单混乱 — 某母公司旗下 100+ 子公司各自购买商业许可，负责人离职后整个整合项目崩塌。
- 最终选择取消强制商业许可 — 反映现实而非理想，但也意味着放弃了可量化的收入（关联 商业许可完全靠自觉、无法衡量活跃用户数 的结果）。
AI 双向拉扯
- 用户因不想用 AI 而迁移到 Obsidian — 其他工具界面被 AI 功能污染，Obsidian 因"没有内置 AI"反而成为避风港（关联 用户因想用 AI 而迁入 的反面）。
- 用户因想用 AI 而迁移到 Obsidian — markdown 文件天然适合 LLM 处理，人们用 Obsidian 查看和交互 AI 生成的内容（关联 用户因不想用 AI 而迁入 的反面）。
- 两个方向同时发生且互相矛盾 — 产品定位因此受益，但也带来了身份认同的困惑。
团队协作与无会议模型的代价
- 偶尔遗忘事情 — Steph 承认"once in a while that I just totally forget something is happening"（关联 复杂项目仍需临时会议）。
- 复杂项目仍需临时会议 — 近期因一个多领域交叉项目不得不开了一次会，说明无会议模型有上限（关联 偶尔遗忘事情 的补充）。
- 异步沟通的心跳广播 — 团队成员在 Discord 发布状态更新"不是为了让人回复，只是 verbalize what is currently going on"，本质上是 rubber ducking 的制度化。
协作功能的缺失
- Obsidian 至今是单人工具 — "very siloed as an app"，连与伴侣共享购物清单这种基本需求都无法满足（关联 社区长期要求协作能力）。
- 社区长期要求协作能力 — 这是 roadmap 上的重要方向，但从本地文件到协作的跨越在架构上是根本性的（关联 Obsidian 至今是单人工具 的回应）。
翻译与多语言
- AI 翻译准确率约 90% — 剩余 10% 需要社区人工修正，但至少解决了从 15 种语言到 40+ 种语言的覆盖问题（关联 AI 前的翻译状态 的改善）。
- 右到左语言和复杂文字系统 — 阿拉伯语、希伯来语需要界面镜像，高棉语每个字符占 15 倍字节。
- AI 前的翻译状态 — 社区手工翻译的 12-15 种语言中，很多页面已过时（如商业许可变更后仍显示旧规则）（关联 AI 翻译准确率约 90% 的对照）。
任务管理的反直觉简化
- 每周新建一个 to-do list，不看上周的 — 迫使自己重新评估优先级，自然筛选出真正重要的事（关联 反复 rollover 的任务最终消失）。
- 反复 rollover 的任务最终消失 — "like emails, sometimes you just got to archive all"（关联 每周新建一个 to-do list 的结果）。
- 笔记问题 — "I have so many notebooks everywhere"，纸质笔记本的物理堆积是数字迁移的常见动因。
不代理理解（Don't Delegate Understanding）
- 核心恐惧 — 如果在每个环节都外包理解，就会"covered in parasites that are making it seem like it's easy"，被提取时间和金钱（关联 AI 编程的克制 的动机）。
- AI 编程的克制 — Obsidian 团队几乎不在编程中使用 AI，因为想要"really really firm understanding of our code base"（关联 核心恐惧 的实践）。
- 积极面：caloric energy is precious — 把需要消耗卡路里的认知工作转化为电能完成，但前提是理解你委托的是什么。
Plain text 的赌注
- File over app 的核心逻辑 — app 终将消亡（操作系统变化、用户行为变化、输入设备变化），但纯文本自 1960 年代存在至今（关联 LLM 意外受益 的意外收获）。
- 对云端数据租用模式的批判 — 过去 15-20 年人们把数据上传到别人服务器，以非加密方式租用自己的数据，"pendulum is swinging away from that"。
- LLM 意外受益 — plain text 对 LLM 最友好，但这是 karma 而非设计预判（关联 File over app 的意外收获）。
小团队的有意限制
- 7 人全职 — 3 工程师 + Erica + Steph + 客服 + 社区负责人。
- 不追求规模 — "I don't mind that constraint"，接受 Obsidian 不会成为微软。
- 从 45 人创业公司的教训 — Steph 在 Lumi 有 8-10 个会议/天的 "calendar hellscape" 经历，整个 Obsidian 的组织设计是对那段经历的有意识反叛（关联 TiddlyWiki + CSS hacks 的前身）。
- TiddlyWiki + CSS hacks 的前身 — Obsidian 之前 Steph 用 TiddlyWiki 加大量 hack 来实现类似功能，说明需求先于产品存在（关联 从 45 人创业公司的教训 的前史）。