⚙️ 工程项目
🏃 Sprint Board
🎯 CEO 关注线
🏗 组织架构
🗺 产品全景
👤 我的看板
📣 User Voice
🗺 Roadmap
✓ saved
💾 保存版本
⤓ 导出
↺ 重置
激活
登录、Claim、订阅和 Trial 现在共同定义 D0 的转化面。
首页不再把“商业化”当成孤立主题。真实问题是转化漏斗能不能连续跑通，否则任何更上层策略都无法稳定放大。
主动信号
主动推荐已经接近发货，但可信交付必需的上下游还没完全收口。
今天不能只看 MACD demo 有没有跑起来，而要看信号、通知总线、解释和成交归因能不能一起成为一个可持续运营的主动推荐闭环。
边界
Constrained Autonomy 已经拆成可读的监控板，但中心边界仍未产品化。
接下来要盯的不是再堆更多散 issue，而是“真实状态”和“执行边界”这两条链是否真的关掉对应缺口。
运行时
shared VM 仍有系统性失真，不只是个别故障。
如果 config sync 和 observability 同时失真，任何自动化或自治都失去可信基础，所以这类 infra 票必须直接占据首页视线。
🏃 Sprint 24 (PRODUCT) (4/6 → 4/27)
🏃 Sprint 24 (ENG) (4/13 → 4/27)
🟢 ENG issues 🟣 PRODUCT issues
🌳 Scope 树
👤 按人员
全部
📝 待分诊
📋 规划中
⬚ 待开始
🔨 进行中
👀 评审中
✅ 已完成
✕ 已取消
⚠️
Sprint 风险
8 项 · 2026-04-23 快照 · 点击展开/收起
▾
激活到付费闭环还没稳定 → CEO 面：激活 + 商业化
行动: Gary 先把账户和 Claim-to-Launch 收稳 · Zouye 把 commercial MVP / Trial / 埋点口径收成同一条漏斗
主动推荐已能发货，但还不可信 → CEO 面：主动信号
行动: Jim 收口 P1 上线面 · Sylvia 交付信号定义与解释标准 · JackJun 把统一通知总线从 PRD 推到执行 contract
Constrained Autonomy 现在已经看得清，但中心边界还没做成产品能力 → CEO 面：Constrained Autonomy
行动: 继续把两张监控板当建构式监控使用，并把最缺的中心能力映射回真实产品面，而不是只停留在 spec
SlowMist 前风险还没有真正出清 → CEO 面：安全边界
行动: Jiagui 先关掉审计前最硬的资金与灾备项 · Sylvia 把推荐前安全校验拉回主产品路径
Shared VM config sync / observability 出现系统性盲区 → ENG 当前 Cycle：runtime health
行动: Wenzhang 先以 shared VM 为单位收口 config sync 与 observability blindspot，再谈更高层自动化
交易面扩张速度快于控制面 → Sprint Board：trading scope
行动: 先按上线次序收口 HIP-3 / 商品交易，再决定 Polymarket 和 Perps 的下一个扩张面，避免三条交易线一起摊大
评测 / 追溯证明面还在形成中 → CEO 面：证明面
行动: Fei 先保证 eval lane 边界和 live queueing 不互相打架 · Rui Li 把 TraceId 接回默认排障路径
关键 owner 仍然集中在少数人 → 人员风险：Safety / Trading / Runtime
行动: 给安全、交易和运行时各补一个明确的 reviewer / spec owner，把单点从“唯一会做的人”降到“主要交付的人”
Chris Zhu
CEO · Direction & Final Call
Linear ↗
Engineering 12
AI Engineering
JackJun AI Engineering Lead — 引擎架构 / LLM Routing / D0 核心 LEAD Linear ↗ Fei AI Eval & Research Lead — Eval 体系 / Frontier / Security + Engineering 落地 Linear ↗ Interface Engineering
Jin Xu d0-cli / Skills / New Interface Owner / 前端 Linear ↗ Ethan Full-stack Asset & Platform — 多链资产 / D0 Dashboard / Deposit·Withdraw·Transfer / iOS Linear ↗ Trading Engineering Peter leads ↗
← Peter (Product) cross-leads Trading 方向
Infrastructure
Regison Crypto Backend & Middleware — 后端核心 / MCP / DeFi Linear ↗ Wenzhang DevOps — K8s / ArgoCD / 监控 / Admin / Eval Infra / sub2api / 多副本 Linear ↗ Jiagui Safety & Container — 浏览器安全 / 容器隔离 / Extension Linear ↗
Product & Design 4
Peter Trading Team Lead → Trading Eng Linear ↗ Ye Zou Product Architecture & Interaction Design Linear ↗ Research & Data 2
Liang Han AI-first Trading Research — 量化策略 / 风控模型 / Discovery Linear ↗ Tao Yuan Data Engineering — 回测 / 数据管线 Linear ↗ GTM / Growth 4
Hongwei Feng GTM / Social Frontier Tracking Linear ↗ Operations & Strategy 3
Yutong Li Legal / Finance / HR (HK) Linear ↗
02
D0 产品全景 — 功能地图
产品线 × Owner × 关键指标 · 与 Sprint Board 功能模块 Tree 对齐
03
⚙️ Engineering — Initiative / Project / Issue
🏗 工程项目
📦 Repo 架构
💡 使用方法: 选你的名字 → 看到你的 issue → 点状态标签切换进度 → 编辑会自动保存
选择你的名字 → 查看和管理你的 Issues
All (全部)
JackJun
Fei
Jin Xu
Gary
Ethan
Alex
Rui Li
Regison
Wenzhang
Jiagui
Peter
Ye Zou
Sylvia
Yi Tan
Liang Han
Tao Yuan
Jim
Kevin
Justin
📝 待开始 🔨 开发中 👀 Review 中 🧪 测试中 ✅ 已完成
06
📣 User Voice — 反馈输入 × 质量验证
反馈输入
GTM / Growth 持续把高频痛点整理成具体产品问题。
这里看的是用户反复提出什么，而不是团队内部想做什么。
质量验证
Jim 负责把用户痛点收成数据正确性、查询正确性和上线前可发布性。
这里看的是：这些反馈有没有真正变成可验证、可发货的产品面。
本期收口主题
解释性、交易风控、权威数据源、主动推荐上线面。
CEO 进入这个 tab，不是看流水账，而是看这些反馈有没有被真正收口。
当前缺口
反馈输入和 QA 验证已经能看见，但 release gate 还没有完全变成统一控制面。
所以现在最重要的是把高频反馈和上线前验证连成一条闭环，而不是分别看两张表。
📥 高频反馈主题
AI 输出看不懂为什么 输入 → PRODUCT-2455 上游来源
GTM / 用户反馈归档反复出现“信号/形态不透明，用户无法验证 AI 是否真的有依据”。
用户容易过度交易和盈利回吐 输入 → PRODUCT-2454 上游来源
高频用户反馈不是“想多赚”，而是“没有及时的约束和提醒，容易反复犯错”。
AI 分析没有真正落到图表和回放层 输入 → PRODUCT-2421 上游来源
用户不只要结论，还要能在图表与回测可视层里看到 AI 分析到底落到了哪里。
🧪 当前验证与上线收口
07
🎯 CEO 关注线 — 5 条主线
CEO 重点跟踪的 5 条主线 · 聚合相关 Issue 状态 · v10.1
09
🎯 Strategic Matrix — Proactive × High-Stake
D0 能力矩阵 · 主动性 × 风险等级 · 贴 Issue 链接可查看战略对齐度 · v10.1
🔍 Issue 战略对齐检查 — 贴 Linear 链接或 Issue ID
检查对齐
X-axis: Proactive Level (L0→L4) · Y-axis: High-Stake Level (L0→L4) · Each cell = capability cluster
← v1「看得清」→
← v2「想得明」→
← v3「做得住」→
← v4「越来越好」→
P↓ S→
S0 Research
S1 Guarded
S2 Managed
S3 Continuous
S4 Self-Healing
P0 Reactive
P1 Monitor
3M TARGET
P1×S2
组合级监控面板 planned
风险暴露预警 planned
PnL 归因分析 planned
P2 Draft
P2×S0
Agent Strategy Hub — 研究报告草案推送 planned
→ connected to PRODUCT-2185
6M TARGET
P2×S2
再平衡建议推送 planned
风控违规草案 planned
P3 Constrained
6M TARGET
P3×S2
边界内再平衡 planned
自动止损执行 planned
GRPS 全约束 planned
12M TARGET
P3×S3
24/7 自主值班 planned
极端行情自动降仓 planned
P4 Adaptive
12M TARGET
P4×S3
千人千面决策引擎 planned
行为学习 + 自主策略调整 planned
📅 Version ↔ Matrix Mapping
v1 P0×S0~S1 「看得清」Reactive + Guarded — 核心流程跑通，能用敢用愿意付费
v2 P1×S1~S2 「想得明」Monitor + Managed — 个性化基础 + 知识体系 + 评测
v3 P2~P3×S2 「做得住」Draft→Constrained — 自动执行 + 风控闭环 + 审批
v4 P3~P4×S3 「越来越好」Continuous — 质量闭环 + 增长 + 自我进化
10
🔑 Issue 拆解原则
Milestone → Epic → Scope → Issue 的拆解方法 · 每个 Issue 必须能回答矩阵坐标的推进
Level 1
Milestone
矩阵上的目标格子
例: P1×S1 (30d)
Level 2
Epic
按四层架构拆分
例: Trust → GRPS 集成
Level 3
Scope
功能模块 / 技术范围
例: GRPS → D0 Bot 集成
Level 4
Issue
工程师可接的粒度
例: GRPS 软约束方法论
Milestone → Epic ·
Epic → Scope ·
Scope → Issue
🔑
Issue 验收标准
每个 Issue 必须能回答：「这把我们从矩阵的 P?×S? 推到 P?×S?」 回答不了 → 说明拆解还不够清晰，或者这个 issue 不在战略路径上。
08
🗓 版本制规划 (v3)
版本不绑日历 · Epic 验收即上线 · 全 P0 通过 = 版本达成
v1「看得清」— 核心流程跑通
用户能否第一次体验到 proactive 的价值——"D0 在替我盯着，它的判断有道理"？
版本制 · P0 全部验收通过 = v1 达成 · 9 P0 + 7 P1 Epics