感谢字节的同学，有幸第一时间体验了SOLO这款产品，应该也消耗了不少Token,最大的收获有两个，一是看到很多产品和技术割裂情况下绝对不可能做的一些产品尝试，文中会做一些说明；二是项目开发过程中Agent的一种新的UI组织可能性；作为一个新产品，目前的产品整体可以给65分(绝对不是低分，还有很大的完善空间)。需要说明，除了上面的内容和后面的一些建议意见，这篇帖子的绝大部分内容也是SOLO生成的，：
为什么说这是极高难度挑战？
| 挑战维度 | 难度说明 |
|---------|---------|
| 业务复杂度 | 需要统一理解产品、技术、业务团队的语言 |
| 技术栈深度 | 从前端 React 到后端 NestJS 再到 PostgreSQL 全链路 |
| 可视化交互 | D3.js 力导向图、拖拽编辑、实时预览 |
SOLO 如何帮助我们攻克难关
项目规划与拆解
挑战：项目太大，不知从何下手
SOLO 的帮助：
-
使用
TodoWrite工具创建清晰的任务清单 -
自动规划技术实现路径
-
智能建议最佳实践
✅ 修改字典管理页面使用真实 API
✅ 修改菜单管理页面使用真实 API
✅ 完善用户管理移除 mock 引用
✅ 完善租户管理移除 mock 引用
✅ 修复租户管理成员和关系数据使用真实 API
✅ 修复用户管理身份详情和登录日志使用真实 API
...
代码生成与重构
挑战：从 mock 数据切换到真实 API 需要修改大量文件
SOLO 的帮助：
-
自动识别需要修改的文件
-
智能生成 API 客户端代码
-
保持代码风格一致性
前后端联调
挑战：前后端数据结构不一致，接口调试困难
SOLO 的帮助：
-
生成共享的 TypeScript 类型定义
-
自动创建后端服务端点
-
提供智能的错误诊断
一、项目背景：为什么做本体管理系统？(最主要是难，一般人类不会干!!!)
业务痛点
❌ 重复定义：同一个"客户"概念，在CRM、订单、售后系统中定义各异
❌ 沟通成本：跨团队协作时，光"对齐字段定义"就要开3次会
❌ 数据孤岛：各系统数据无法互通，报表数据经常"打架"
❌ 维护困难：核心字段变更时，要同步修改十几个系统的代码
核心目标
✅ 建立统一的数据语言体系
✅ 实现业务概念的可视化管理
✅ 支持变更追溯和版本控制
✅ 赋能智能应用（搜索、推荐、风控）
二、系统架构设计
整体架构
┌─────────────────────────────────────────────────────────┐
│ 用户层 (React) │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 本体概览 │ │ 本体建模 │ │ 变更审批 │ ... │
│ │ Dashboard │ │ Visual │ │ Workflow │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
├─────────────────────────────────────────────────────────┤
│ 服务层 (NestJS) │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 本体服务 │ │ 实体服务 │ │ 关系服务 │ ... │
│ │Ontology │ │ Entity │ │Relation │ │
│ │ Service │ │ Service │ │ Service │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
├─────────────────────────────────────────────────────────┤
│ 数据层 (PostgreSQL) │
└─────────────────────────────────────────────────────────┘
三、核心功能展示
1. 本体概览仪表盘
┌─────────────────────────────────────────────────────────────────┐
│ 📊 本体健康度总览 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 领域 │ │ 类 │ │ 属性 │ │ 关系 │ │ 健康度 │ │
│ │ 12 │ │ 1,847 │ │ 5,293 │ │ 2,164 │ │ 82% │ │
│ │ 个 │ │ 个 │ │ 个 │ │ 个 │ │ 良好 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 🔥 近期变更 (近7天) │ │
│ │ │ │
│ │ 新增 客户域/企业客户 新增「注册资本」字段 │ │
│ │ 修改 交易域/订单 新增「优惠金额」计算属性 │ │
│ │ 废弃 产品域/商品 「二级分类」字段（待清理引用） │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2. 可视化本体建模
┌─────────────────────────────────────────────────────────────────┐
│ 🎨 本体建模 - 客户域 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ 客户域 │ │
│ └──────┬──────┘ │
│ │ │
│ ┌───────────┼───────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │企业客户│───│个人客户│ │潜在客户│ │
│ └──┬───┘ └──┬───┘ └──────┘ │
│ │ │ │
│ │ 1:N │ │
│ │◀───────▶│ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────┐ │
│ │ 联系方式 │ │
│ │ (姓名/电话/邮箱) │ │
│ └──────────────────┘ │
│ │
│ [+ 新增类] [+ 新增关系] [属性配置] [版本发布] │
└─────────────────────────────────────────────────────────────────┘
技术实现亮点：
- D3.js 力导向图：实现类关系图的可视化展示
- 拖拽交互：React DnD 实现类的拖拽布局
- 实时预览：WebSocket 实现多人协作编辑
三栏列表视图（不错的实现，调整消耗了很多token）：
图谱模式
全景视图 (不是我想要的知识图谱展示方式，不过也还凑合，花的token反而很少，做项目的话少说几个人月工作量)
3. 智能变更审批流(solo没有给出想要的设计，借助image2生成的原型图片喂给solo完成)
┌─────────────────────────────────────────────────────────────────┐
│ 📝 变更申请 #20240115-003 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 申请人：张三 (市场部) 申请时间：2024-01-15 14:30 │
│ 变更类型：⚡ 新增字段 涉及范围：客户域/企业客户 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 变更内容： │ │
│ │ │ │
│ │ 在「企业客户」类下新增字段： │ │
│ │ │ │
│ │ 字段名：注册资本 │ │
│ │ 数据类型：Decimal(18,2) │ │
│ │ 必填：否 │ │
│ │ 说明：企业注册资本金额（万元） │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 影响分析： │
│ ├─ 受影响的功能模块：CRM客户管理(3)、数据分析(1) │
│ ├─ 受影响的API接口：12个 │
│ └─ 风险等级：🟡 低风险 │
│ │
│ 审批流程： │
│ [✅ 张三提交] → [⏳ 李四审批中] → [ 王五 ] → [ 完成 ] │
│ │
└─────────────────────────────────────────────────────────────────┘
技术实现亮点：
- 影响分析引擎：自动扫描关联的表、API、报表
- 变更差异对比：类似 Git Diff 的可视化 Diff 展示
- 灰度发布：支持字段的渐进式上线
4. 暗黑模式(一般小团队绝不会花这个成本，但对于AI很容易，全局扫描替换，怕出错换个AI再review一遍)
5. 国际化(当然国际化小团队更不会干了，本以为AI应该easy，不过结果有不少残留)
6. 环境自动配置(所有人都很烦的点，SOLO解决的很出色)
自动在docker环境安装了：postgresql,redis,elasticsearch,rabbitmq,kibana,minio，贴心的帮我初始化了账号密码，甚至一次报错都没有，作为干净的本地开发环境已经很完美了。
四、技术架构亮点
1. 前后端分离 + TypeScript 类型安全
// 共享的类型定义，确保前后端数据一致
// shared/ontology.ts
export interface OntologyClass {
id: number;
name: string;
domainId: number;
properties: Property[];
// ...
}
// 前端直接复用类型，IDE 自动补全
const updateClass = async (classId: number, data: Partial<OntologyClass>) => {
const response = await api.put(`/ontology/classes/${classId}`, data);
return response.data; // TypeScript 自动推断类型
};
收益：
前后端接口零沟通成本
IDE 智能提示，减少低级错误
代码即文档，新人上手速度提升 50%
2. 统一的状态管理模式
// 使用 React Context + useReducer 管理本体状态
interface OntologyState {
domains: Domain[];
currentClass: OntologyClass | null;
pendingChanges: ChangeOrder[];
isLoading: boolean;
}
// 统一的 Action 处理所有状态变更
type OntologyAction =
| { type: 'LOAD_DOMAINS'; payload: Domain[] }
| { type: 'ADD_PROPERTY'; payload: { classId: number; property: Property } }
| { type: 'UPDATE_CLASS'; payload: OntologyClass }
| { type: 'SUBMIT_CHANGE'; payload: ChangeOrder };
3. 性能优化策略
| 优化点 | 实施方案 | 效果 |
|---|---|---|
| 首屏加载 | Code Splitting + 懒加载 | 首次加载 < 2s |
| 列表查询 | 分页 + 虚拟滚动 | 10万数据秒级渲染 |
| 图表渲染 | Canvas 替代 SVG | 渲染性能提升 10x |
| 搜索 | Elasticsearch 全文索引 | 搜索响应 < 100ms |
| 缓存 | Redis 多级缓存 | 热点数据 QPS 10万+ |
五、产品问题和建议
关于多Agent管理能力
我特别把左侧的会话重命名成我想要的多Agent方式，各司其职，最好的做法应该是在会话中配置好Skill，或提示固定，不需要每次/调用
浏览器支持
开始几天内嵌浏览器打不开原型，后面几天好了，应该是团队也发现了问题修复了，但是原型加载缺少入口，如果关闭了内嵌浏览器，我一般要告诉solo,“帮我打开原型”…
图片替换是噩梦
我让solo帮我把设计的logo
替换上去后的图标变成了这样，试过了svg/png
原型设计
操作figma/pencil这类工具还不是很方便，虽然直接生成了ts原型和mock数据，但是效率还是太低，作为ui/ue阶段的结果输出就可以了，过早生成在修改调整过程中消耗大量token
---
## 结语
总体而言，虽然在一些能力上还与CLAUDE、CODEX有一定差距，但是能看出产品团队很有想法，体现出了solo这款产品的潜力，在没有手敲一行代码、编辑一行文档的情况下把这个功能做到这个程度，已经达到很不错的水平，希望SOLO继续加油，中国的AI团队加油。