单DRI并行任务与内测门控

Perplexity 的项目执行流：

1. 每个项目一个 DRI（directly responsible individual）驱动。
2. 第一步永远是拆并行任务：把项目尽最大可能拆成自包含（self-contained）的并行任务（他们在 Linear 里做，由 head of product 带着 PM 或代行 PM 职责的人拆）。每个任务的标准：拿到就能执行、无阻塞。拆分时难免要做有争议的预设——先拆先干，争议事后再抹平。
3. 一次快速 kickoff 对齐，之后全部异步：迭代无约束、无评审流程。
4. 反馈拉动而非流程推动：谁觉得自己的设计/实现/成品可以要反馈了，扔进 Slack，团队给诚实、建设性的反馈；迭代按需自然发生。
5. 发布闸门 = 内部 dogfooding：产品在内部获得真实使用热度（internal traction）之前不发布——这是无审批流体系里唯一的质量闸门。
6. 职能也并行：设计、前端、后端（现在加上业务）同时开工，不等设计稿先行；"不要等别人来解锁你"。
7. 想法双向流动：高层目标和方向自上而下，大量新想法自下而上（专门的 Slack брainstorm 频道 → Linear 收集 → 小打磨常常直接进代码）；工程和设计对想法和细节有所有权——AI 产品的约束在写成代码/做出 mock 之前根本不可知（Discover 功能演化成播客就是没人预测到的）。

配套工具习惯：Linear auto-archiving——一个任务很久没人提起，说明它其实不重要；Notion 沉淀 design docs/RFC/postmortem，把思维链写在纸上，让异步对齐替代开会。