PMFlow/design.md

Neural Sync: AI 原生项目管理平台设计方案

目标用户: 10 人精英 AI 技术团队 | 核心价值: 认知对齐 & 极速响应 | 原则: 拒绝外部开源工具臃肿堆砌，全自研轻量化核心

1. 原始方案深度审计

你原有的方案依赖于集成 Plane (项目管理) 和 MaxKB (知识库)。 为什么这违背了“AI Native”的目标：

• 数据孤岛 (Siloed Data)：需求躺在 Plane 里，知识躺在 MaxKB 里，代码躺在 Git 里。AI 需要跨越这三座孤岛去“搬运”信息，这本身就制造了巨大的认知延迟和错误率，而不是消灭它。
• 静态与动态的错位: Plane 管理的是“任务 (Tasks)”（静态的），但 AI 开发管理的是“实验 (Experiments)”（动态的）。在传统软件中，代码合并即任务完成；但在 AI 开发中，只有评测分数 (Eval Score) 提升了，实验才算成功。Plane 无法原生追踪评测分数。
• 维护黑洞: 你只有 10 个人，却要维护两套复杂的开源系统。光是修这两个系统的 Bug 和适配 API 变动，就会消耗掉你 2 个人的战力。

2. 优化后的核心哲学：“活体上下文 (Living Context)”

我们不再管理“任务”，而是管理 “上下文 (Context) & 评测 (Evals)”。

• 上下文 (Context): 我们已知的信息（市场洞察、模型能力边界、技术约束）。
• 评测 (Evals): 我们如何定义成功（准确率、延迟、用户留存）。
• 假设 (Hypothesis): 所谓的“任务”，本质上只是一个基于当前上下文，试图提升评测指标的“假设”。

3. 系统架构 (Neural Sync 引擎)

3.1 技术栈 (统一且 Python 原生)

• 前端: Vue 3 + Naive UI (比 Element Plus 更轻量，更适合数据密集型应用)。
• 后端: FastAPI (Python)。 理由：你的 10 人团队都是 AI 专家，Python 是母语。不要强迫他们为了内部工具去写 Java (Spring Boot)。这让你们可以直接在后端集成模型训练/评测流水线。
• 数据库: PostgreSQL (带 pgvector 扩展)。统一存储关系型数据（用户、任务）和语义数据（RAG 向量）。
• 编排: 轻量级事件总线 (Event Bus) (例如内部 Python asyncio 队列 或 Redis Streams)。

3.2 核心模块 (全自研，无开源 PM 工具)

模块 A: “脉搏” (The Pulse - 市场与模型信号接收)

• 功能: 替代“市场监控”。
• 机制:
  • 信号源: 自动爬虫 (新闻、论文、竞品更新) + 内部模型评测日志。
  • AI Agent ("侦察兵"): 分析信号 -> 生成 洞察 (Insight)。
  • 动作: 如果 洞察 与当前的 计划 相冲突，触发 “对齐警报 (Alignment Alert)”。

模块 B: “认知核心” (The Cognitive Core - 活体说明书)

• 功能: 替代“Wiki/MaxKB”。
• 机制:
  • 原子化知识: 信息以 ContextNode (知识节点) 形式存储 (例如：“我们的 RAG 切片大小是 512”)。
  • 版本化: 每个节点都有版本历史。
  • 强关联: 任务直接挂载在节点上。如果节点发生变更 (切片大小 -> 1024)，所有关联的任务自动标记为“已过时 (Outdated)”。

模块 C: “实验室” (The Lab - 评测驱动的任务管理)

• 功能: 替代“Plane/Jira”。
• 机制:
  • 实体: Experiment (实验)。
  • 工作流: 提出假设 -> 代码实现 -> 自动化评测 -> 决策。
  • 仪表盘: 不是看板 (Kanban)，而是实验的 “排行榜 (Leaderboard)” 及其对核心指标的影响。

4. 数据库设计 (PostgreSQL) - 唯一的真理来源

-- 1. 认知的原子单位
CREATE TABLE context_nodes (
    id UUID PRIMARY KEY,
    content TEXT NOT NULL, -- 实际知识内容 (例如: "用户画像: 数据科学家")
    embedding VECTOR(1536), -- 用于语义搜索/RAG
    version INT DEFAULT 1,
    status VARCHAR(20) DEFAULT 'active', -- active, deprecated
    created_by UUID REFERENCES users(id)
);

-- 2. "实验" (即传统意义上的任务)
CREATE TABLE experiments (
    id UUID PRIMARY KEY,
    title VARCHAR(255),
    hypothesis TEXT, -- "假设：如果我们增加切片大小，召回率会提升。"
    status VARCHAR(50), -- 'draft', 'running', 'evaluating', 'success', 'failed'
    owner_id UUID REFERENCES users(id),
    linked_context_nodes UUID[], -- 依赖的知识节点
    target_metric VARCHAR(50), -- 例如: 'rag_accuracy'
    current_score FLOAT -- 来自 CI/CD 的实时分数
);

-- 3. 信号 (外部触发器)
CREATE TABLE signals (
    id UUID PRIMARY KEY,
    source VARCHAR(50), -- 'market_news', 'model_update', 'competitor_release'
    content TEXT,
    impact_score FLOAT, -- AI 评估的紧急程度 (0-1)
    processed BOOLEAN DEFAULT FALSE
);

5. 工作流：“零负担”闭环

1. 信号: “OpenAI 发布了 GPT-5”。
2. Agent (侦察兵): 创建一条 Signal 记录。标记为高影响分。
3. Agent (对齐者): 检查 ContextNodes。发现节点：“基座模型: GPT-4”。标记该节点为“潜在过时”。
4. 通知: 技术负责人收到 Ping：“信号 GPT-5 与知识节点 '基座模型' 冲突。是否创建实验？”
5. 动作: 负责人点击“是”。系统自动创建 Experiment：“评估 GPT-5 在代码生成上的表现”。
6. 执行: 开发者实现代码。提交 Commit。
7. 评测: CI 流水线运行 Benchmark。更新 experiments.current_score。
8. 闭环: 分数 > 基线。实验标记为“成功”。ContextNode 自动更新为“基座模型: GPT-5”。

6. 为什么这最适合你们

• 10 人团队: 不需要复杂的权限/角色管理。速度是唯一指标。
• 认知同步: ContextNode 的强关联机制确保了当“基座模型”变更时，每个人都知道，因为他们的任务会变红（被标记）。
• 无开源臃肿: 你只需要建立这 3 张表和少量的 Python 接口。快速、干净、完全可控。