# 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) - 唯一的真理来源

```sql
-- 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 接口。快速、干净、完全可控。