98 lines
6.0 KiB
Markdown
98 lines
6.0 KiB
Markdown
# 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 接口。快速、干净、完全可控。
|