会议时间：2025/08/20
参与人员：说话人A（主导）、朱晨（后端）、小关（前端）；老板提供原型，金芳与嘉林做细节补充
一、核心议题
1. 组织（Organization/客户）模块定位
- 命名为「组织」，本质是 CRM 的客户关系管理（Account）。
- 数据主要是客户，少量为合作工厂、供应商等其他类型；统一归入组织实体。
- 类似传统 CRM 的客户管理模块。
2. 组织字段结构
- 基础字段：组织名称、关系类型（客户/供应商/其他）、国家、网址（可多个）。
- 交易：显示主要经营系列 + 累计金额；货币区分美金、人民币、其他。
- 注意：从开发角度，「系列+金额」不应放在同一单元格，应在展示层合并两个独立字段。
- 联系人：对方公司的人员。
- 服务团队：本公司参与服务的人员。
- 多主体：例如 Zara Home 关联 ITX 等多个法人主体，要支持多个注册名称及与主组织的关系/主营业务。
3. 概述与摘要（AI 生成内容）
- 概述部分：由 AI 跑 company research 生成。
- 摘要：对客户的总结性信息，AI 生成，包含内容 + 标签。
- 自定义章节：如「采购倾向」，以文字为主，可附带简单图表。
- 每个章节视为一个对象，对象结构会变化；AI 是首次生成的主要来源，几乎不依赖人工。
4. 产品策略
- 跑类似产品推荐的流程，按客户关联推荐产品。
- 可分两块：
- 客户实际经营的所有品类（如 Zara Home 还经营家纺、餐厨、婴童等不在本司库内的品类）。
- 命中本司产品库的品类 → 显示推荐产品。
- 下方展示分类下产品的价格曲线等信息，便于看 AI 标签结果。
5. 添加客户的两种方式
- 单个创建：搜索 + 编辑（参考商品模块的表格编辑）；搜索时若已存在则匹配，否则按用户输入新增。
- API 检索提示：用户输入时调用外部 API（先用 Mock）建议关联公司。
- 批量导入：暂不做。
- 邮件导入（最初一次性导入）：从企业邮箱所有邮件备份中识别客户域名、参与的联系人和服务团队成员。
6. 创建流程（销售视角）
- 销售只填客户名称或网址。
- 系统跑 AI 客户分析流程，自动补全其他字段。
二、技术决策与方案细节
1. 表格结构方案三选一
| 方案 | 描述 | 优劣 |
|---|
| 固定字段 | 数据库每列对应字段 | 简单，但不支持自定义列 |
| 单列 + 自定义数据 | 表中保留固定列，附加 custom_data JSON 字段 | 折中，部分动态 |
| 元数据表 | 整张表的结构和数据均存元数据，每次取出动态拼装 | 灵活但实现复杂 |
| 动态建表 | 命名如 quip_客户_随机数，按需动态修改表结构 | 性能好但维护极复杂 |
- 倾向：先不做完整 airtable 风格动态表；待 UI 与对象定义完成后再决定底层。
- 国外类似产品（Airtable、Notion DB、Monday、Pocas 等）均走动态 table 路线，但实现复杂度极高。
2. AI Agent 架构大改
- 弃用旧 LangGraph 部分，改为基于 AI SDK V5 自建。
- 原因 1：模型自身的 agency（工具调用）能力增强，无需依赖 ReactAgent 模板。
- 原因 2：LangGraph 框架繁琐，AI 协助开发时不易写出兼容代码；前端要修改推荐 state、调用相似产品、建议等场景实现复杂。
- 架构：
- 助手（Assistant） + 多个对话框，全部内嵌 Web 项目。
- 直接和大模型交互的 message 称
model message；前端/API 层称 UI message（不是渲染卡片）。
- 整套 agent 自定义放入 Web 项目，逐步弃用 chatint 项目。
3. AI 自定义内容生成约束
- AI 生成的章节要支持引用其他字段。
- 存储格式必须是 AI 能稳定输出的结构。
三、UI/交互细节
- 表格：双击编辑、点击添加新行（最简化交互）。
- 编辑字段时区分单值字段与结构化字段（结构化字段需有专门编辑器，不能按普通字段编辑）。
- 客户搜索：已存在则关联，未存在则新建（参照材质字段交互）。
- 联系人添加同样支持新建。
- 详情页：注册名称（多主体）、概述、摘要、产品策略、潜在商机、交易笔记、自定义内容章节。
- 表格视图后续可生成多种视图（先不做）。
四、后续行动与分工
| 角色 | 任务 |
|---|
| 小关（前端） | 先实现组织模块 UI（表格 + 详情两个页面） |
| 朱晨（后端） | 整理所有字段为对象 / 表定义；先定义结构，不实现接口 |
| 后续 | UI + 对象定义完成后再讨论实现方式（固定字段 vs 动态表） |
| 推荐重构 | 组织 UI 完成后单独抽时间讨论推荐模块重构 |
- 优化类需求攒一批改一次；金芳群里反馈也按批次处理后回复群里。
- chat 部分继续用 LangGraph，待组织模块 UI 完成后再讨论推荐部分重构。
五、其他要点
- 「潜在商机」对应原客户分析中的产品切入点、资质认证、展会信息等。
- 「交易」字段记录已成交的笔记。
- 老板要求的隐藏列、新增列、筛选 + 视图等典型 table 功能后续才做。
- 产品需求层面老板矛盾：一方面想要灵活动态，另一方面提的需求又高度定制（如商品库存包装），与通用 table 形式冲突。
- 国内已有专门做此类动态表方案的项目（自部署给企业）。
- 朋友所在企业有类似低代码方案，技术实现复杂度高。