Merge branch 'main' of ssh://192.168.3.17:2222/ishenwei/nexus
This commit is contained in:
527
Project/fonrey/PRD/房源管理模块PRD.md
Normal file
527
Project/fonrey/PRD/房源管理模块PRD.md
Normal file
@@ -0,0 +1,527 @@
|
||||
# PRD: 房源管理模块
|
||||
**状态**: Draft
|
||||
**作者**: 产品经理
|
||||
**最后更新**: 2026-04-22
|
||||
**版本**: 1.0
|
||||
**所属系统**: Fonrey 房产经纪管理系统
|
||||
**关联模块**: 客源管理、组织人事管理、权限管理
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
### 背景
|
||||
|
||||
房产经纪公司的核心业务是匹配买卖双方/租赁双方,而房源是整个业务链路的起点。经纪人日常需要录入、管理、维护大量房源信息,并跟进每套房源的状态变化、与业主沟通、组织带看等。
|
||||
|
||||
传统纸质或 Excel 管理方式存在以下核心痛点:
|
||||
|
||||
- **信息散乱**:房源信息分散在不同经纪人的手机/表格中,无法共享、无法协作
|
||||
- **跟进缺失**:无系统化的跟进记录,房源状态变化靠口头传达,容易遗漏
|
||||
- **重复录入**:同一业主名下多套房源缺乏关联,造成信息重复和沟通冲突
|
||||
- **查找低效**:房源数量大(案例中 89,000+ 条),缺乏多维度筛选能力
|
||||
- **图片管理混乱**:房源照片分类不明确,无法快速识别封面图、各空间图
|
||||
|
||||
### 目标用户
|
||||
|
||||
| 角色 | 描述 | 使用频率 |
|
||||
|------|------|----------|
|
||||
| 一线经纪人 | 负责录入、维护、跟进自己名下的房源 | 每日高频 |
|
||||
| 店长/经理 | 查看全店/全区房源概况,分配任务,监控跟进完成度 | 每日 |
|
||||
| 行政人员 | 审核房源信息,维护数据质量 | 每日 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 目标与成功指标
|
||||
|
||||
| 目标 | 指标 | 当前基准 | 目标值 | 衡量周期 |
|
||||
|------|------|----------|--------|----------|
|
||||
| 提升房源录入效率 | 平均录入一条房源耗时 | 约 15 分钟(估算) | < 5 分钟 | 上线后 60 天 |
|
||||
| 提升跟进完成率 | 近 30 天有跟进的房源比例 | 待统计 | ≥ 80% | 上线后 90 天 |
|
||||
| 提升数据质量 | 房源维护完成度(系统评分)平均值 | 待统计 | ≥ 70% | 上线后 90 天 |
|
||||
| 减少重复房源 | 重复/疑似问题号码房源数量 | 待统计 | 减少 50% | 上线后 60 天 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 非目标(本期不做)
|
||||
|
||||
- 不包含商业地产(商铺、办公室、厂房)房源管理,本期仅覆盖住宅类
|
||||
- 不包含地图找房的底层地图服务建设(地图组件集成另行规划)
|
||||
- 不包含房源对外门户网站展示(营销推广为独立模块)
|
||||
- 不包含 AI 估价引擎的自研(可集成第三方价格解读服务)
|
||||
- 不包含移动端 App(本期为 Web 端,移动端适配为 v2 规划)
|
||||
|
||||
---
|
||||
|
||||
## 4. 用户故事与验收标准
|
||||
|
||||
### Story 1:经纪人录入新房源
|
||||
|
||||
**As** 一线经纪人,**I want** 快速录入一套新房源的完整信息,**So that** 房源能进入公盘流通、并由系统自动提醒后续跟进。
|
||||
|
||||
**验收标准**:
|
||||
- [ ] 支持选择房源类型(住宅/商业),本期实现住宅类型
|
||||
- [ ] 新增住宅表单分为:房源核心信息 / 业主联系人 / 基础信息 / 交易信息 / 相关方,共 5 个区块
|
||||
- [ ] 必填项未填写时,点击保存弹出红色错误提示,并定位到第一个未填项
|
||||
- [ ] 户型字段支持分别输入:室数、厅数、卫数、厨数、是否有阳台
|
||||
- [ ] 楼层填写:所在楼层 + 总楼层,均为数字输入
|
||||
- [ ] 保存成功后跳转到该房源详情页,并显示"保存成功"提示
|
||||
|
||||
### Story 2:经纪人筛选查找目标房源
|
||||
|
||||
**As** 一线经纪人,**I want** 在数万条房源中快速定位到符合客户需求的房源,**So that** 提升匹配推荐效率。
|
||||
|
||||
**验收标准**:
|
||||
- [ ] 支持关键词搜索(小区名称、地址、业主姓名、电话、钥匙编号等)
|
||||
- [ ] 支持多维度组合筛选:范围(最新挂牌/降价/与我相关/我部门相关)、区域(区/地铁)、价格区间、面积区间、户型、楼层、标签、状态/属性、装修/朝向、学校、等级、用途等
|
||||
- [ ] 列表支持排序(售价、单价、面积、挂牌日期、最后跟进日期)
|
||||
- [ ] 支持切换列表展示与海报展示模式
|
||||
- [ ] 已存搜索条件可保存,下次快速调用
|
||||
- [ ] 列表底部显示当前筛选总条数,支持分页(每页 20 条,可跳页)
|
||||
- [ ] 支持导出当前筛选结果
|
||||
|
||||
### Story 3:经纪人记录房源跟进
|
||||
|
||||
**As** 一线经纪人,**I want** 随时记录与业主的沟通内容和带看情况,**So that** 保留完整的房源跟进轨迹,团队协作时不会重复打扰业主。
|
||||
|
||||
**验收标准**:
|
||||
- [ ] 在房源详情页可直接唤起"写跟进"浮层,无需离开当前页面
|
||||
- [ ] 跟进目的为必填下拉选项(如:业主跟进、电话、带看、回访等)
|
||||
- [ ] 跟进内容为必填文本框,最少 6 字,最多 500 字
|
||||
- [ ] 支持附件上传(最多 10 张图片,每张最大 20MB,格式:bmp/jpg/png/svg/gif)
|
||||
- [ ] 跟进记录展示:跟进类型标签 + 内容 + 操作人(姓名+所属门店)+ 时间
|
||||
- [ ] 跟进日志支持按类型筛选(全部/写入跟进/敏感信息跟进/敏感信息查看/修改跟进/其他跟进)
|
||||
- [ ] 跟进日志支持关键词搜索 + 操作员筛选 + 日期范围筛选
|
||||
- [ ] 跟进目的支持按维度统计展示(如:电话 45 次、业主跟进 20 次、回访 1 次)
|
||||
|
||||
### Story 4:经纪人查看同业主其他房源
|
||||
|
||||
**As** 一线经纪人,**I want** 在查看某套房源时一键查看该业主名下的其他房源,**So that** 了解业主资产全貌,避免重复打扰、统一谈判。
|
||||
|
||||
**验收标准**:
|
||||
- [ ] 在房源详情的业主/联系人区块,显示"业主还有其他房源,建议您一起跟进,避免重复打扰"提示
|
||||
- [ ] 点击可唤起"同业主房源"弹窗,显示字段:房源名称、状态、城区商圈、房型、面积、售价、租价
|
||||
- [ ] 支持选择业主(当业主有多个关联人时)再查询
|
||||
- [ ] 弹窗内可点击房源名称直接跳转到对应房源详情
|
||||
|
||||
### Story 5:经纪人管理房源图片
|
||||
|
||||
**As** 一线经纪人,**I want** 为房源上传分类管理的照片并设置封面,**So that** 提升房源展示质量,吸引更多买家/租客关注。
|
||||
|
||||
**验收标准**:
|
||||
- [ ] 支持图片分类标签:封面、玄关、客厅、餐厅、卧室、卫生间、厨房、阳台、书房、室内其他、室外、全景等
|
||||
- [ ] 支持批量上传、批量修改分类、批量删除、批量下载
|
||||
- [ ] 支持拖拽排序调整图片顺序
|
||||
- [ ] 封面图有显著标识,只能设置一张
|
||||
- [ ] 图片显示尺寸规格信息(如 1440×1080)
|
||||
|
||||
---
|
||||
|
||||
## 5. 功能详细说明
|
||||
|
||||
### 5.1 房源列表
|
||||
|
||||
#### 5.1.1 列表视图
|
||||
|
||||
房源列表为系统核心入口,支持以下视图和操作:
|
||||
|
||||
**顶部标签页(房源交易类型切换)**:
|
||||
- 出售
|
||||
- 出租
|
||||
- 未挂牌
|
||||
- 成交房源
|
||||
- 全部房源
|
||||
|
||||
**核心列表字段**(可自定义显示列):
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 房源名称 | 小区名称 + 户室号,显示交易类型标签(买卖/租赁)颜色区分 |
|
||||
| 楼栋 | 楼栋号 |
|
||||
| 单元 | 单元号 |
|
||||
| 房号 | 房号 |
|
||||
| 区域板块 | 区 + 商圈/板块 |
|
||||
| 状态 | 出售/出租/他售/他租/暂缓等 |
|
||||
| 售价(万) | 总价,支持升降序排序,价格变动显示箭头 |
|
||||
| 单价(元/m²) | 每平米均价 |
|
||||
| 租价(元/月) | 月租金 |
|
||||
| 面积(m²) | 建筑面积 |
|
||||
| 户型 | X室X厅 |
|
||||
| 楼层 | 所在层/总层数 |
|
||||
| 朝向 | 朝向描述 |
|
||||
| 挂牌日期 | 房源上架日期 |
|
||||
| 房源最后跟进日 | 最近一次跟进记录时间 |
|
||||
|
||||
**列表顶部操作栏**:
|
||||
- 批量操作:批量收藏、取消收藏、设置保护房、修改相关方、删除
|
||||
- 导出:导出当前筛选结果(Excel)
|
||||
- 自定义列表:自定义显示字段和顺序
|
||||
- 智能排序:系统推荐排序
|
||||
|
||||
**右上角快捷功能**:
|
||||
- 新增房源按钮(主要 CTA)
|
||||
- 重复房源检测
|
||||
- 疑似问题号码房源查询
|
||||
|
||||
#### 5.1.2 搜索与筛选系统
|
||||
|
||||
**关键词搜索**:
|
||||
- 搜索范围:房源编号、小区/学校名称、地址、业主主姓名、电话、钥匙编号等
|
||||
- 支持楼栋、单元、房号独立精确输入
|
||||
|
||||
**多维度筛选分组**:
|
||||
|
||||
| 筛选组 | 筛选项 |
|
||||
|--------|--------|
|
||||
| 范围 | 最新挂牌、最降价、与我相关、我部门相关、收藏房源、超时未跟进房源 |
|
||||
| 区域 | 地区(多选)、地铁 |
|
||||
| 价格 | 售价区间 / 单价,支持自定义最小值~最大值 |
|
||||
| 面积 | 面积区间(预设段 + 自定义) |
|
||||
| 户型 | 1室/2室/3室/4室/5室及以上 + 卫生间数量 |
|
||||
| 楼层 | 低层/中层/高层/顶楼/底楼 + 自定义层数范围 |
|
||||
| 标签 | 速销、独家、有钥匙、电梯、唯一、有照片、贷款、视频、AI视频、有VR、3D |
|
||||
| 筛选 | 相关方、维护人、房屋现状、状态/属性、装修/朝向、学校、等级、用途、房本年限、唯一住房、税费/贷款、建成年代、产权性质、挂牌类型、来源、看房时间、审核、保护房 |
|
||||
| 维护 | 发布、实勘、核验、跟进/带看、钥匙/委托、维护完成度 |
|
||||
|
||||
**筛选条件可保存**,支持命名保存,下次一键调用。
|
||||
|
||||
#### 5.1.3 地图找房
|
||||
|
||||
提供地图视图入口,在地图上以点位展示房源分布,支持地图拖拽缩放查找房源(地图功能为独立组件,接入规范另行定义)。
|
||||
|
||||
---
|
||||
|
||||
### 5.2 房源详情
|
||||
|
||||
房源详情页采用多 Tab 布局,包含以下标签页:
|
||||
|
||||
| Tab | 内容 |
|
||||
|-----|------|
|
||||
| 核心信息 | 房源基本属性、价格、图片轮播、基础信息、交易信息 |
|
||||
| 跟进日志 | 所有跟进记录的时间线,支持筛选和搜索 |
|
||||
| 业务信息 | 带看记录、实勘记录等业务操作 |
|
||||
| 房源信息 | 详细的物业/楼盘信息 |
|
||||
| 营销信息 | 营销相关设置 |
|
||||
| 相关员工 | 首录方、号码方、出售方、实买方等相关方员工信息 |
|
||||
| 相册信息 | 房源图片管理 |
|
||||
| 附件信息 | 其他文件附件 |
|
||||
|
||||
**详情页顶部操作区**:
|
||||
- 房源标题(交易类型标签 + 小区名称 + 户室号)
|
||||
- 快速操作:改状态、编辑房源、分享、写跟进
|
||||
- 更多操作下拉菜单
|
||||
|
||||
**核心信息 Tab 内容**:
|
||||
|
||||
```
|
||||
[图片轮播区]
|
||||
总价:XXX 万 单价:XXXXX 元/m² [昨天最新下降 XX 万,降幅 X.X%]
|
||||
了解同小区市行情 → 价格解读
|
||||
|
||||
户型:X室X厅X卫X阳台
|
||||
面积:XX.X m² 等级:X(XX) 属性:公盘/私盘
|
||||
房屋现状:XX 看房时间:随时可看
|
||||
用途:住宅 录入时间:XXXX-XX-XX
|
||||
地址:XX区-XX镇
|
||||
房源备注:-
|
||||
```
|
||||
|
||||
**右侧信息面板**(详情页右侧固定栏):
|
||||
- 业主/联系人区块:联系人姓名(打码)、电话(打码)、身份标注、操作按钮(查看号码、新增联系人、更多)
|
||||
- 跟进提醒 TIPS:提示是否有同业主其他房源
|
||||
- 房源维护完成度:百分比进度条 + 各维度完成情况(重点信息、附件、实勘、VR、钥匙、委托、验证等)
|
||||
- 房源动态(近 30 天):带看次数、复看次数、空看人次、面访次数、收藏房源人数、巧客力分享次数
|
||||
|
||||
---
|
||||
|
||||
### 5.3 新增/编辑房源
|
||||
|
||||
#### 5.3.1 新增住宅表单结构
|
||||
|
||||
新增住宅采用单页长表单,按信息类别分为以下区块:
|
||||
|
||||
**① 房源核心信息**
|
||||
|
||||
| 字段 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 状态 | 单选 | 是 | 出售 / 出租 / 租售 / 暂缓 |
|
||||
| 房源属性 | 单选 | 是 | 公盘 / 私盘 |
|
||||
| 用途 | 单选 | 否 | 普通住宅 / 花园洋房 |
|
||||
| 小区名称 | 文本输入 | 是 | 支持联想搜索 |
|
||||
| 户室号 | 文本输入 | 否 | 栋/幢/弄/湖同 + 单元/号 + 门牌/室号 |
|
||||
| 所在楼层 | 数字输入 | 是 | 所在层数 |
|
||||
| 总楼层 | 数字输入 | 是 | 楼栋总层数 |
|
||||
| 户型 | 数字输入 | 是 | 室数 + 厅数 + 卫数 + 厨数 + 阳台(是否) |
|
||||
| 建筑面积 | 数字输入 | 是 | 单位:m² |
|
||||
| 售价 | 数字输入 | 条件必填 | 出售状态必填,单位:万 |
|
||||
| 租价 | 数字输入 | 条件必填 | 出租状态必填,单位:元/月 |
|
||||
|
||||
**② 业主/联系人**
|
||||
|
||||
- 支持添加多个联系人("添加联系人"按钮)
|
||||
- 每个联系人包含:姓名、性别(先生/女士)、身份(业主/联系人/委托人等)、电话1、电话2
|
||||
- 电话格式:手机号或座机号(座机需写区号)
|
||||
|
||||
**③ 基础信息**
|
||||
|
||||
| 字段 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 朝向 | 单选 | 是 | 东/南/西/北/东南/东北/东西/南北/西北/西南 |
|
||||
| 装修 | 单选 | 是 | 毛坯/清水/简装/中装/精装/豪装 |
|
||||
| 电梯 | 单选 | 否 | 有/无/重置 |
|
||||
| 建成年代 | 下拉选择 | 否 | 年份选择,提示:建成年代为空可能影响营销发房 |
|
||||
| 学校 | 下拉多选 | 否 | 支持添加多个学区,"添加学校"按钮 |
|
||||
| 看房时间 | 单选 | 否 | 随时可看/提前预约/不方便看/重置 |
|
||||
| 房屋现状 | 下拉选择 | 否 | 空置/自住/出租中等 |
|
||||
| 等级 | 单选 | 否 | A(急迫)/ B(较强)/ C(一般) |
|
||||
| 来源 | 下拉选择 | 否 | 房源来源渠道 |
|
||||
| 售房原因 | 文本区域 | 否 | 最多 200 字 |
|
||||
| 房源备注 | 文本区域 | 否 | 最多 500 字 |
|
||||
|
||||
**④ 交易信息**
|
||||
|
||||
| 字段 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 产权年限 | 单选 | 否 | 40年/50年/70年/永久产权/其他 |
|
||||
| 产权性质 | 单选 | 否 | 商品房/房改房/集资房/经济活用房 |
|
||||
| 房本年限 | 下拉 + 下拉 | 是 | 具体年限 + 满五/不满五等 |
|
||||
| 唯一住房 | 单选 | 否 | 唯一/不唯一 |
|
||||
| 购房付款方式 | 单选 | 否 | 一次付清/按揭付款/分批次付款/垫资解按 |
|
||||
| 包税费 | 单选 | 否 | 各付/到手/包税 |
|
||||
| 抵押 | 单选 | 否 | 有/无 |
|
||||
| 贷款 | 单选 | 否 | 有/无 |
|
||||
| 查封 | 单选 | 否 | 有/无 |
|
||||
| 限制 | 单选 | 否 | 有/无 |
|
||||
| 原购价 | 数字输入 | 否 | 单位:万 |
|
||||
|
||||
**⑤ 相关方**
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 首录方 | 自动填入当前登录用户(只读) |
|
||||
| 号码方 | 默认为当前用户,可修改 |
|
||||
| 出售方 | 默认为当前用户,可修改 |
|
||||
|
||||
#### 5.3.2 编辑房源
|
||||
|
||||
- 编辑页面结构与新增一致,数据预填充
|
||||
- 顶部显示"修改房源类型"入口(可在住宅/商业等类型间切换)
|
||||
- 套内面积为非必填字段,仅在编辑时展示
|
||||
- 保存/取消按钮固定在页面底部
|
||||
|
||||
---
|
||||
|
||||
### 5.4 跟进管理
|
||||
|
||||
#### 5.4.1 写跟进
|
||||
|
||||
跟进功能以浮层(Drawer/Modal)方式呈现,不离开当前页面:
|
||||
|
||||
| 字段 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 跟进目的 | 下拉选择 | 是 | 电话/业主跟进/带看/回访/其他等 |
|
||||
| 跟进内容 | 文本区域 | 是 | 最少 6 字,最多 500 字 |
|
||||
| 附件 | 文件上传 | 否 | 最多 10 张,单张最大 20MB,格式:bmp/jpg/png/svg/gif |
|
||||
|
||||
支持"跟进模版"功能(快速套用常用跟进话术模板)。
|
||||
|
||||
#### 5.4.2 跟进日志展示
|
||||
|
||||
跟进日志以时间线方式展示,每条记录包含:
|
||||
|
||||
- **跟进类型标签**:不同颜色区分(如绿色=业主跟进、蓝色=电话、橙色=其他)
|
||||
- **跟进内容正文**
|
||||
- **操作信息**:`[角色] 姓名 门店名称-组别 时间`
|
||||
- **操作菜单**(...):查看详情/编辑/删除(权限控制)
|
||||
|
||||
**跟进过滤 Tab**:
|
||||
- 全部
|
||||
- 写入跟进
|
||||
- 敏感信息跟进
|
||||
- 敏感信息查看
|
||||
- 修改跟进
|
||||
- 其他跟进
|
||||
|
||||
---
|
||||
|
||||
### 5.5 图片管理
|
||||
|
||||
#### 5.5.1 图片分类体系
|
||||
|
||||
| 分类 | 说明 |
|
||||
|------|------|
|
||||
| 封面 | 房源主封面,限 1 张 |
|
||||
| 玄关 | 入户区域 |
|
||||
| 客厅 | 客厅空间 |
|
||||
| 餐厅 | 餐厅空间 |
|
||||
| 卧室 | 各卧室 |
|
||||
| 卫生间 | 卫浴空间 |
|
||||
| 厨房 | 厨房空间 |
|
||||
| 阳台 | 阳台/露台 |
|
||||
| 书房 | 书房/办公空间 |
|
||||
| 室内其他 | 其他室内区域 |
|
||||
| 室外 | 外观/小区环境 |
|
||||
| 全景 | 360° 全景图 |
|
||||
|
||||
#### 5.5.2 图片操作
|
||||
|
||||
- **上传**:点击上传区域或拖拽上传,支持批量
|
||||
- **排序**:拖拽调整同类图片顺序("点击后可拖拽图片调整排序"提示)
|
||||
- **分类设置**:上传时选择分类,或批量修改已有图片分类
|
||||
- **批量操作**:全选、批量修改分类、批量删除、批量下载
|
||||
- **封面设置**:在图片缩略图上标注"封面"标签
|
||||
|
||||
---
|
||||
|
||||
### 5.6 同业主房源
|
||||
|
||||
当系统识别到当前房源的业主名下还有其他房源时,触发以下交互:
|
||||
|
||||
1. 在房源详情右侧"业主/联系人"区块显示提示条:
|
||||
> "业主还有其他房源,建议您一起跟进,避免重复打扰"
|
||||
|
||||
2. 点击"查看房源"触发弹窗,字段如下:
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 房源名称 | 可点击跳转到对应房源 |
|
||||
| 状态 | 当前交易状态 |
|
||||
| 城区商圈 | 所在区域 |
|
||||
| 房型 | 户型描述 |
|
||||
| 面积(m²) | 建筑面积 |
|
||||
| 售价(万) | 出售价格 |
|
||||
| 租价(元/月) | 出租价格 |
|
||||
|
||||
3. 当业主有多个关联联系人时,弹窗顶部提供业主下拉选择器。
|
||||
|
||||
4. 弹窗提示注意事项:"房源详情提示条存在缓存,以本页面数据为准"
|
||||
|
||||
---
|
||||
|
||||
### 5.7 房源状态流转
|
||||
|
||||
```
|
||||
┌─────────┐
|
||||
│ 新增 │
|
||||
└────┬────┘
|
||||
│
|
||||
┌──────────▼──────────┐
|
||||
│ 出售/出租 │
|
||||
└──────────┬──────────┘
|
||||
│
|
||||
┌────────────────┼────────────────┐
|
||||
▼ ▼ ▼
|
||||
┌───────┐ ┌───────┐ ┌───────┐
|
||||
│ 暂缓 │ │ 他售 │ │ 成交 │
|
||||
└───┬───┘ │ 他租 │ └───────┘
|
||||
│ └───────┘
|
||||
└────────────────▶ 出售/出租(恢复)
|
||||
```
|
||||
|
||||
**状态说明**:
|
||||
|
||||
| 状态 | 说明 |
|
||||
|------|------|
|
||||
| 出售 | 当前正在出售中,公盘流通 |
|
||||
| 出租 | 当前正在出租中,公盘流通 |
|
||||
| 暂缓 | 业主暂时不出售/出租,保留记录 |
|
||||
| 他售 | 已委托其他中介或自行处置(非本平台成交) |
|
||||
| 他租 | 同上,出租版本 |
|
||||
| 成交 | 通过本平台成功成交 |
|
||||
| 未挂牌 | 录入但尚未公开挂牌 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 技术考量
|
||||
|
||||
### 6.1 依赖关系
|
||||
|
||||
| 依赖项 | 用途 | 时间线风险 |
|
||||
|--------|------|------------|
|
||||
| 组织人事模块 | 相关方(首录方/号码方/出售方)员工数据 | 低(并行开发) |
|
||||
| 权限模块 | 控制私盘/公盘可见性、敏感信息访问权限 | 中(需明确权限矩阵) |
|
||||
| 地图服务 | 地图找房功能 | 低(可延后) |
|
||||
| 文件存储服务 | 房源图片和附件存储(OSS/S3) | 中(需确定存储方案) |
|
||||
| 小区数据库 | 小区名称联想搜索的基础数据 | 高(需预导入或接入外部数据源) |
|
||||
|
||||
### 6.2 已知风险
|
||||
|
||||
| 风险 | 可能性 | 影响 | 缓解措施 |
|
||||
|------|--------|------|----------|
|
||||
| 小区基础数据缺失 | 高 | 高 | 提前采购或导入小区数据,支持手动输入兜底 |
|
||||
| 大数据量列表性能(89000+ 条) | 中 | 高 | 后端分页 + 索引优化,禁止前端全量加载 |
|
||||
| 图片存储成本 | 中 | 中 | 限制单张大小,压缩处理,CDN 分发 |
|
||||
| 号码隐私合规 | 高 | 高 | 手机号默认打码,设置查看权限,记录查看日志 |
|
||||
|
||||
### 6.3 待解决问题(开发前必须明确)
|
||||
|
||||
- [ ] **小区数据来源**:是自建小区库还是接入第三方(安居客、链家数据接口)?— Owner: 技术负责人 — Deadline: 开发启动前 1 周
|
||||
- [ ] **私盘可见范围**:私盘仅录入人可见,还是录入人所在门店可见?— Owner: 业务负责人
|
||||
- [ ] **房源号码查看权限**:什么角色可以查看未打码号码?是否需要记录每次查看日志?— Owner: 产品 + 合规
|
||||
- [ ] **重复房源判断逻辑**:以业主电话为主键还是(小区+楼栋+单元+房号)为主键?— Owner: 产品
|
||||
- [ ] **跟进目的选项**:需要业务方提供完整的跟进目的枚举值 — Owner: 业务运营
|
||||
|
||||
---
|
||||
|
||||
## 7. 上线计划
|
||||
|
||||
| 阶段 | 时间 | 用户范围 | 通过条件 |
|
||||
|------|------|----------|----------|
|
||||
| 内部 Alpha | TBD | 开发+产品+1个试点门店(5人) | 核心流程无 P0 Bug,房源增删改查完整 |
|
||||
| 封闭 Beta | TBD | 3个试点门店(50人) | 错误率 < 1%,跟进记录功能稳定,用户反馈 CSAT ≥ 4/5 |
|
||||
| 全量上线 | TBD | 全部门店 | 性能指标达标,帮助文档完备,客服培训完成 |
|
||||
|
||||
**回滚标准**:若上线后 24 小时内出现房源数据丢失、错误率 > 5% 或业主电话泄露等 P0 问题,立即回滚并启动事故响应流程。
|
||||
|
||||
---
|
||||
|
||||
## 8. 附录
|
||||
|
||||
### 8.1 字段枚举值速查
|
||||
|
||||
**房源状态**:出售、出租、租售、暂缓、他售、他租、成交、未挂牌
|
||||
|
||||
**朝向**:东、南、西、北、东南、东北、东西、南北、西北、西南
|
||||
|
||||
**装修**:毛坯、清水、简装、中装、精装、豪装
|
||||
|
||||
**等级**:A(急迫)、B(较强)、C(一般)
|
||||
|
||||
**产权年限**:40年、50年、70年、永久产权、其他
|
||||
|
||||
**产权性质**:商品房、房改房、集资房、经济活用房
|
||||
|
||||
**付款方式**:一次付清、按揭付款、分批次付款、垫资解按
|
||||
|
||||
**包税方式**:各付、到手、包税
|
||||
|
||||
**看房时间**:随时可看、提前预约、不方便看
|
||||
|
||||
**电梯**:有、无
|
||||
|
||||
**唯一住房**:唯一、不唯一
|
||||
|
||||
### 8.2 房源维护完成度评分维度(参考)
|
||||
|
||||
| 维度 | 满分权重 |
|
||||
|------|----------|
|
||||
| 重点信息(户型/面积/价格/朝向等核心字段完整度) | 8% |
|
||||
| 附件(上传合同等文件) | 8% |
|
||||
| 实勘(经纪人实地勘察记录) | 16% |
|
||||
| VR(全景视频/图片) | 8% |
|
||||
| 钥匙(是否托管钥匙) | 10% |
|
||||
| 委托(是否签署委托协议) | 10% |
|
||||
| 验证(房源信息核实) | 7% |
|
||||
| 跟进(近期跟进活跃度) | 8% |
|
||||
| 带看 | 8% |
|
||||
| 其他 | 17% |
|
||||
|
||||
### 8.3 相关截图参考
|
||||
|
||||
- 房源列表(出售视图):`Project/fonrey/sreenshots/房源/房源列表.png`
|
||||
- 全部房源视图:`Project/fonrey/sreenshots/房源/全部房源.png`
|
||||
- 新增住宅表单:`Project/fonrey/sreenshots/房源/增房/新增住宅.png`
|
||||
- 编辑房源:`Project/fonrey/sreenshots/房源/增房/编辑房源.png`
|
||||
- 上传图片:`Project/fonrey/sreenshots/房源/增房/上传图片.png`
|
||||
- 写跟进:`Project/fonrey/sreenshots/房源/增房/写跟进.png`
|
||||
- 查看同业主房源:`Project/fonrey/sreenshots/房源/增房/查看同业主房源.png`
|
||||
56
wiki/concepts/AI-Auto-Response.md
Normal file
56
wiki/concepts/AI-Auto-Response.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "AI Auto-Response"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# AI Auto-Response
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent 基于客户消息内容和知识库自动生成并发送回复,无需人工介入的处理模式,是多渠道客服降低人工成本的核心机制。
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
Customer Message
|
||||
↓
|
||||
[Language Detection] → Detect language
|
||||
↓
|
||||
[Intent Classification] → FAQ / Appointment / Complaint / Review
|
||||
↓
|
||||
[Business Knowledge Base] → Retrieve relevant info
|
||||
↓
|
||||
[Response Generation] → Contextual, language-matched reply
|
||||
↓
|
||||
[Send to Channel] (or [Test Mode] → log only)
|
||||
```
|
||||
|
||||
## Effectiveness Metrics
|
||||
|
||||
| Metric | Description |
|
||||
|--------|-------------|
|
||||
| **Auto-response Rate** | 自动处理的消息占比(目标: >80%) |
|
||||
| **Response Time** | 从收到消息到发送回复的平均时长 |
|
||||
| **Escalation Rate** | 转人工的消息占比 |
|
||||
| **Customer Satisfaction** | 自动化回复的客户满意度评分 |
|
||||
|
||||
餐厅案例:自动处理率 80%,平均响应时间 <2 分钟(对比人工 4+ 小时)。
|
||||
|
||||
## Quality Safeguards
|
||||
|
||||
- **Never invent**:禁止生成知识库中没有的信息
|
||||
- **Handoff guard**:不确定时主动转人工而非猜测
|
||||
- **Brand consistency**:回复语气与品牌形象一致
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Intent-Classification]]:意图分类决定触发哪种回复策略
|
||||
- [[Business-Knowledge-Base]]:知识库是自动回复的信息来源
|
||||
- [[Human-Handoff]]:AI 边界之外的场景转交人工
|
||||
- [[Language-Detection]]:回复语言跟随客户语言
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
46
wiki/concepts/Active-Accountability.md
Normal file
46
wiki/concepts/Active-Accountability.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Active Accountability"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent **主动发消息询问用户**是否完成了某项任务/习惯,而非等待用户主动打开 App 记录——将行为追踪从被动记录转变为主动对话。
|
||||
|
||||
## Contrast with Passive Tracking
|
||||
|
||||
| 维度 | 被动追踪(Passive Tracking) | 主动问责(Active Accountability) |
|
||||
|------|---------------------------|-------------------------------|
|
||||
| 触发方式 | 用户主动打开 App | AI Agent 按定时计划主动发送消息 |
|
||||
| 用户参与成本 | 需要主动记录 | 只需回复确认/否认 |
|
||||
| 通知行为 | Push 通知容易被忽略 | 主动询问,回复率更高 |
|
||||
| 典型产品 | Streaks、Habitica、Loop Habit | OpenClaw Habit Tracker |
|
||||
| 放弃率 | 高(一周后通常停止) | 低(持续参与度高) |
|
||||
|
||||
## Why It Works
|
||||
|
||||
行为改变研究(Klein, 2011; Gollwitzer, 1999)表明:
|
||||
- **承诺一致性**:当用户通过回复消息明确表态("是的,我完成了"),心理承诺效应使他们更可能在未来坚持
|
||||
- **即时反馈**:AI 即时确认和鼓励比事后查看 App 数据更有激励效果
|
||||
- **社会存在感**:主动发消息的 AI 提供了"有人在监督"的真实感觉
|
||||
|
||||
## Implementation
|
||||
|
||||
依赖 [[OpenClaw]] 的 [[Scheduled Reminder]] 能力,配合 [[Adaptive Tone]] 调节消息语气:
|
||||
|
||||
1. Cron Job 按设定时间发送签到消息
|
||||
2. 用户回复完成/未完成
|
||||
3. AI 解析回复并更新 [[Streak Tracking]]
|
||||
4. 根据当前连续状态调整语气([[Adaptive Tone]])
|
||||
5. 每周日汇总 [[Weekly Pattern Analysis]]
|
||||
|
||||
## Related Concepts
|
||||
- [[Adaptive Tone]] — Active Accountability 的关键差异化因素
|
||||
- [[Streak Tracking]] — Active Accountability 的核心激励机制
|
||||
- [[Scheduled Reminder]] — Active Accountability 的技术实现
|
||||
- [[Morning Briefing]] — Active Accountability 的同模式应用
|
||||
|
||||
## Source
|
||||
- [[habit-tracker-accountability-coach]]
|
||||
43
wiki/concepts/Adaptive-Tone.md
Normal file
43
wiki/concepts/Adaptive-Tone.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Adaptive Tone"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent 根据用户表现动态调整语气和沟通策略的机制。连续成功时给予鼓励(encouraging),连续失败时保持温和坚持(gently persistent),而非使用统一的模板化消息。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
| 用户状态 | AI 语气策略 |
|
||||
|---------|-----------|
|
||||
| 连续完成(高连续天数) | 简短肯定 + 引用连续记录,例:"Day 12 of morning workouts. Solid." |
|
||||
| 偶发错失(1-2天) | 温和提醒 + 初心提醒,例:"Just acknowledge it and remind me why I started." |
|
||||
| 连续错失(≥3天) | 更长激励消息 + 询问是否调整目标 |
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- **静态提醒容易被忽视**:Push 通知、每日模板消息最终会被大脑过滤为"噪音"
|
||||
- **个性化消息具有真实激励效果**:"Day 15, don't break it now" 这类引用具体连续记录的消息会触发心理承诺一致性效应
|
||||
- **避免羞辱感**:连续错失时不要 guilt-trip(内疚轰炸),保持支持性语气才能让用户持续参与
|
||||
|
||||
## Implementation Example(OpenClaw)
|
||||
|
||||
```
|
||||
When I confirm a habit, respond with a short encouraging message and
|
||||
mention my current streak. Example: "Day 12 of morning workouts. Solid."
|
||||
|
||||
When I miss a habit, don't guilt-trip me. Just acknowledge it and remind
|
||||
me why I started. If I miss 3 days in a row, send a longer motivational
|
||||
message and ask if I want to adjust the goal.
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[Agent Personality]] — Adaptive Tone 是 Agent Personality 在习惯追踪场景的具体应用
|
||||
- [[Streak Tracking]] — Adaptive Tone 消息中的数据来源
|
||||
- [[Active Accountability]] — 需要 Adaptive Tone 才能真正实现主动问责
|
||||
|
||||
## Source
|
||||
- [[habit-tracker-accountability-coach]]
|
||||
45
wiki/concepts/Business-Knowledge-Base.md
Normal file
45
wiki/concepts/Business-Knowledge-Base.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Business Knowledge Base"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Business Knowledge Base
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent 的结构化业务知识库,包含服务详情、定价政策、营业时间、常见问题解答和人工升级触发条件等信息,是 AI 自动回复准确性的核心依赖。
|
||||
|
||||
## Contents
|
||||
|
||||
| Category | Examples |
|
||||
|----------|---------|
|
||||
| **Services & Pricing** | 服务列表、价格区间、套餐选项 |
|
||||
| **Business Hours** | 营业时间、节假日安排、紧急联系方式 |
|
||||
| **Location** | 地址、交通指引、停车信息 |
|
||||
| **FAQ Responses** | 预定义的高频问答对 |
|
||||
| **Escalation Triggers** | 需要人工处理的场景定义(投诉、退款、特殊情况) |
|
||||
|
||||
## Knowledge Injection
|
||||
|
||||
在 [[OpenClaw]] 中通过以下方式构建知识库:
|
||||
1. **Structured data**:JSON/YAML 格式的结构化业务数据
|
||||
2. **AGENTS.md 配置**:路由规则和回复模板中嵌入知识
|
||||
3. **Document ingestion**:产品手册、政策文档导入
|
||||
|
||||
## Quality Considerations
|
||||
|
||||
- **准确性**:知识库内容必须与实际业务一致,否则 AI 会生成错误回复
|
||||
- **覆盖度**:覆盖越全面,AI 自动处理率越高
|
||||
- **更新机制**:业务变更时同步更新知识库,避免信息滞后
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[AI-Auto-Response]]:知识库是自动回复的信息来源
|
||||
- [[Intent-Classification]]:知识库结构影响意图分类的准确性
|
||||
- [[Human-Handoff]]:升级触发条件定义在知识库中
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
42
wiki/concepts/Check-in-Fatigue.md
Normal file
42
wiki/concepts/Check-in-Fatigue.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Check-in Fatigue"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
当追踪的习惯数量过多时,用户因签到负担过重而开始忽略或跳过签到消息,最终导致整个习惯追踪系统失效的行为现象。
|
||||
|
||||
## Symptom
|
||||
|
||||
- 用户停止回复每日的签到消息
|
||||
- 连续天数开始归零,但用户不再关心
|
||||
- AI Agent 的消息变成"已读不回"
|
||||
- 用户最终完全停止使用系统
|
||||
|
||||
## Root Cause
|
||||
|
||||
**信号淹没**(Signal-to-Noise Ratio Degradation):当每日签到数量超过认知负荷阈值(建议 3-5 个),大脑将所有签到消息归类为低优先级噪音,选择性忽略。
|
||||
|
||||
| 追踪习惯数量 | 认知负荷 | 预期行为 |
|
||||
|------------|---------|---------|
|
||||
| 1-3 个 | 极低 | 高参与率 |
|
||||
| 3-5 个 | 可接受 | 良好参与率 |
|
||||
| 6-10 个 | 较高 | 逐渐疲劳 |
|
||||
| 10+ 个 | 过高 | 系统性忽略 |
|
||||
|
||||
## Mitigation Strategy
|
||||
|
||||
1. **初始限制**:系统建立时严格限制习惯数量为 3-5 个
|
||||
2. **渐进添加**:新习惯须等现有习惯稳定(连续 ≥14 天)后才添加
|
||||
3. **季度回顾**:定期评估每个习惯的参与率,淘汰参与率持续低于 50% 的习惯
|
||||
4. **优先级排序**:不在同一时间发送多个签到请求,分散到全天不同时段
|
||||
|
||||
## Related Concepts
|
||||
- [[Active Accountability]] — Check-in Fatigue 是 Active Accountability 系统的失效模式
|
||||
- [[Streak Tracking]] — 当用户开始忽视签到,Streak 连续天数自然归零
|
||||
|
||||
## Source
|
||||
- [[habit-tracker-accountability-coach]]
|
||||
40
wiki/concepts/Conversational-Interface.md
Normal file
40
wiki/concepts/Conversational-Interface.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Conversational Interface"
|
||||
type: concept
|
||||
tags: [interface, UX, conversation, AI]
|
||||
sources: [second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
对话即界面(Conversational Interface)是一种以自然语言对话为核心交互模式的设计理念:用户通过发送消息来操作系统,无需学习特定命令、点击特定按钮或导航特定菜单。对话本身就是使用界面,打破了"发送消息 → 另一设备构建内容"的空间壁垒。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Conversational Interface
|
||||
- 对话即界面
|
||||
- Chat as UI
|
||||
- 自然语言交互
|
||||
|
||||
## Key Insight
|
||||
|
||||
> "You can text your bot from your phone and it builds things on your computer. The interface is the conversation."
|
||||
|
||||
## Characteristics
|
||||
|
||||
1. **跨设备**:用户从手机发消息 → AI 在电脑端执行/构建
|
||||
2. **无需 App**:手机短信/Telegram/Discord → 直接触发 AI 操作
|
||||
3. **零学习曲线**:不需要学习任何新工具或新界面
|
||||
4. **上下文感知**:AI 基于对话历史理解用户意图
|
||||
|
||||
## In System
|
||||
|
||||
- [[Second Brain]] 的核心交互范式
|
||||
- [[multi-channel-assistant]] 同一模式的多渠道扩展
|
||||
- [[phone-based-personal-assistant]] 语音版对话接口
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[Zero-Friction Capture]] — 对话界面是实现零摩擦捕获的关键手段
|
||||
- [[Topic-Based Routing]] — 对话场景下的上下文隔离机制
|
||||
42
wiki/concepts/Cumulative-Memory.md
Normal file
42
wiki/concepts/Cumulative-Memory.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Cumulative Memory"
|
||||
type: concept
|
||||
tags: [memory, agent, persistence, accumulation]
|
||||
sources: [second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
累积记忆(Cumulative Memory)是一种 AI Agent 记忆系统特性:Agent 永久保留用户告知的所有内容,随时间推移积累越来越丰富的个人上下文,使 Agent 变得越来越个性化、越来越有价值。与传统会话式 AI 的"每次会话从零开始"形成鲜明对比。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Cumulative Memory
|
||||
- 累积记忆
|
||||
- Persistent Memory
|
||||
- 永久记忆
|
||||
- Long-term Memory
|
||||
- 长期记忆
|
||||
|
||||
## Mechanism
|
||||
|
||||
- 用户通过对话/短信告知 AI 的任何信息(想法、链接、书目、餐厅推荐)都会被永久存储
|
||||
- 每次新对话都基于历史上下文展开
|
||||
- 随时间推移,Agent 对用户的了解从"陌生人"进化到"贴身助理"
|
||||
|
||||
## Key Insight
|
||||
|
||||
> "OpenClaw's memory system is cumulative — it remembers *everything* you've ever told it, making it more powerful over time."
|
||||
|
||||
系统价值不是线性增长,而是**复利增长**:记忆越多 → 理解越深 → 建议越精准 → 用户越依赖 → 记忆越多。
|
||||
|
||||
## In System
|
||||
|
||||
- [[Second Brain]] 的核心价值主张
|
||||
- [[OpenClaw]] Workspace/MEMORY.md 文件承载累积记忆
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[Zero-Friction Capture]] — 零摩擦捕获是积累大量记忆的前提(摩擦越低,记录越多)
|
||||
- [[Agent Memory]] — 技术层面的 Agent 记忆实现
|
||||
45
wiki/concepts/Heartbeat-Monitoring.md
Normal file
45
wiki/concepts/Heartbeat-Monitoring.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Heartbeat Monitoring"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Heartbeat Monitoring
|
||||
|
||||
## Definition
|
||||
|
||||
定时任务定期检查客服队列状态,在消息出现积压或响应超时前主动告警的机制,确保 AI + 人工混合体系保持高可用性。
|
||||
|
||||
## Purpose
|
||||
|
||||
即使 AI 自动处理率很高,仍需监控:
|
||||
- **被 AI 错误分类的消息**(应升级但未升级)
|
||||
- **新渠道接入失败**
|
||||
- **知识库缺失导致大量相同 FAQ**
|
||||
- **人工队列积压**
|
||||
|
||||
## Implementation
|
||||
|
||||
Heartbeat 检查通常每 15-30 分钟运行一次:
|
||||
|
||||
```
|
||||
Every N minutes:
|
||||
1. Check unanswered messages older than X minutes
|
||||
2. If count > threshold → Alert (email / Slack / Telegram)
|
||||
3. Log daily response metrics:
|
||||
- Total messages received
|
||||
- Auto-response rate
|
||||
- Escalation rate
|
||||
- Average response time
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Morning Briefing]]:Heartbeat 监控数据可作为每日晨报的一部分
|
||||
- [[Self-Healing-Systems]]:异常检测后可触发自动修复(如重新分类消息)
|
||||
- [[Alerting]]:监控告警机制
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
38
wiki/concepts/Human-Handoff.md
Normal file
38
wiki/concepts/Human-Handoff.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Human Handoff"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Human Handoff
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent 将无法自动处理或需要人工判断的客户消息转移给人工客服的机制,确保复杂问题得到专业处理,同时保留 AI 的高效处理能力用于高频简单问题。
|
||||
|
||||
## Triggers
|
||||
|
||||
AI 应触发人工handoff的条件通常包括:
|
||||
- **复杂投诉**:情绪激动、涉及退款、法律条款
|
||||
- **未知领域**:问题超出知识库覆盖范围
|
||||
- **特定关键词**:明确标记的升级词(如 "speak to manager")
|
||||
- **AI 不确定**:置信度低于阈值时的模糊消息
|
||||
- **人工请求**:客户明确要求转人工
|
||||
|
||||
## Design Principles
|
||||
|
||||
1. **即时确认**:handoff 时 AI 先确认收到消息,告知客户人工将跟进,避免"静默感"
|
||||
2. **上下文传递**:转交时携带完整的对话历史,避免客户重复描述问题
|
||||
3. **优先级标记**:投诉类消息标记高优先级,加快处理
|
||||
4. **无缝衔接**:人工接手后系统应有完整上下文,无需客户重述
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Intent-Classification]]:投诉意图(Complaint)通常是 Handoff 的主要触发器
|
||||
- [[Unified-Inbox]]:人工处理也在统一收件箱内进行
|
||||
- [[AI-Auto-Response]]:AI 与人工互补,AI 覆盖高频简单问题
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
42
wiki/concepts/Intent-Classification.md
Normal file
42
wiki/concepts/Intent-Classification.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Intent Classification"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Intent Classification
|
||||
|
||||
## Definition
|
||||
|
||||
AI 自动识别客户消息的意图(Purpose / Goal),将非结构化自然语言映射为预定义的分类标签,从而触发对应的处理策略和回复逻辑。
|
||||
|
||||
## Common Intent Categories
|
||||
|
||||
| Intent | Trigger Keywords | Handling Strategy |
|
||||
|--------|-----------------|-------------------|
|
||||
| **FAQ** | "how much", "do you offer", "what is" | 从知识库检索答案并回复 |
|
||||
| **Appointment** | "book", "schedule", "available", "reservation" | 检查可用性并确认预约 |
|
||||
| **Complaint** | "frustrated", "refund", "terrible", "problem" | 标记人工审核 + 确认收到 |
|
||||
| **Review** | "google review", "rating", "stars" | 感谢反馈 + 回应问题 |
|
||||
| **Order Status** | "where is my order", "tracking", "delivery" | 查询系统返回状态 |
|
||||
|
||||
## Implementation
|
||||
|
||||
Intent Classification 通常通过 LLM 的 Function Calling 或 Prompt Engineering 实现:
|
||||
|
||||
```
|
||||
User Message → LLM Intent Classification → Match Intent to Handler → Generate Response
|
||||
```
|
||||
|
||||
在 [[OpenClaw]] 中通过 AGENTS.md 配置 `Classify intent` 步骤实现。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Unified-Inbox]]:意图分类应用于统一收件箱中的每条消息
|
||||
- [[Business-Knowledge-Base]]:FAQ 意图依赖知识库检索
|
||||
- [[Human-Handoff]]:投诉意图触发人工升级
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
51
wiki/concepts/Language-Detection.md
Normal file
51
wiki/concepts/Language-Detection.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Language Detection"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Language Detection
|
||||
|
||||
## Definition
|
||||
|
||||
AI 自动检测客户消息使用的语言,并在回复时匹配该语言的能力,是多语言客服场景的基础技术。
|
||||
|
||||
## Why It Matters
|
||||
|
||||
小型本地服务企业(餐厅、诊所、发廊)的客户群体通常包含:
|
||||
- 本地语言用户(ES/EN)
|
||||
- 外语用户(旅游客户、跨境客户)
|
||||
- 混合语言消息
|
||||
|
||||
自动语言检测确保 AI 用客户的语言回复,提升客户体验和响应准确率。
|
||||
|
||||
## Implementation
|
||||
|
||||
Language Detection 通常在 Intent Classification 之前执行:
|
||||
|
||||
```
|
||||
Customer Message → [Language Detection] → Identify: EN/ES/UA
|
||||
↓
|
||||
[Intent Classification] → ...
|
||||
↓
|
||||
[Generate Response in Detected Language]
|
||||
```
|
||||
|
||||
## Response Style Guidelines
|
||||
|
||||
| Detected Language | Response Style |
|
||||
|-------------------|----------------|
|
||||
| EN (English) | Friendly, professional, concise |
|
||||
| ES (Español) | Amigable, profesional, conciso |
|
||||
| UA (Українська) | Привітний, професійний, стислий |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Intent-Classification]]:语言检测在意图分类之前执行
|
||||
- [[AI-Auto-Response]]:回复语言跟随检测结果
|
||||
- [[Multi-Channel-Integration]]:多渠道场景下语言检测尤为重要
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
57
wiki/concepts/Streak-Tracking.md
Normal file
57
wiki/concepts/Streak-Tracking.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Streak Tracking"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
记录用户连续完成某项任务/习惯的天数,并在每次互动中引用该数据以激励用户持续参与的行为改变机制。
|
||||
|
||||
## Mechanism
|
||||
|
||||
```
|
||||
用户完成习惯 → 连续天数 +1 → AI 引用并鼓励
|
||||
用户错失习惯 → 连续天数 = 0 → 重置
|
||||
```
|
||||
|
||||
## Data Storage
|
||||
|
||||
OpenClaw 中存储在本地 JSON 文件:
|
||||
```text
|
||||
~/habits/log.json
|
||||
```
|
||||
|
||||
数据结构示例:
|
||||
```json
|
||||
{
|
||||
"morning_workout": {
|
||||
"current_streak": 12,
|
||||
"last_check_in": "2026-04-17",
|
||||
"longest_streak": 21,
|
||||
"total_days": 34
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Psychological Basis
|
||||
|
||||
- **损失厌恶**(Kahneman & Tversky):用户害怕失去已积累的连续天数,产生"不要断了它"的内在动机
|
||||
- **即时可见性**:连续天数是最直观、最即时的成就指标,比抽象的完成率更可感知
|
||||
- **社会比较**:连续打卡记录可与他人(或过去的自己)比较,形成竞争激励
|
||||
|
||||
## Integration with [[Adaptive Tone]]
|
||||
|
||||
Streak 数据驱动 AI 语气策略:
|
||||
- 高连续天数(≥7天):简短有力,例 "Day 12. Solid."
|
||||
- 中连续天数(3-6天):温和鼓励
|
||||
- 低连续天数或重置:支持性语气,不打击积极性
|
||||
|
||||
## Related Concepts
|
||||
- [[Adaptive Tone]] — Streak 数据驱动语气策略
|
||||
- [[Active Accountability]] — Streak Tracking 的应用场景
|
||||
- [[Check-in Fatigue]] — Streak Tracking 失效的副作用
|
||||
|
||||
## Source
|
||||
- [[habit-tracker-accountability-coach]]
|
||||
37
wiki/concepts/Test-Mode.md
Normal file
37
wiki/concepts/Test-Mode.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Test Mode"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Test Mode
|
||||
|
||||
## Definition
|
||||
|
||||
在不影响真实客户和现有系统的情况下,允许代理商或开发者演示、测试 AI Agent 行为的沙盒运行模式。Test Mode 下 Agent 执行完整逻辑,但所有输出仅记录到日志,不发送至真实渠道。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
```
|
||||
Real User Message → AI Agent → [Test Mode?]
|
||||
├── YES: Log response + prefix "[TEST]", DO NOT send to channel
|
||||
└── NO: Send response to real channel
|
||||
```
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **代理商演示**:向潜在客户展示 AI 客服的工作效果,无需预先配置真实渠道
|
||||
- **配置验证**:验证 AGENTS.md 路由逻辑、知识库覆盖、意图分类准确性
|
||||
- **A/B 测试**:对比不同 Prompt 配置的实际回复效果
|
||||
- **回归测试**:升级 Agent 版本前验证新版本不破坏现有行为
|
||||
|
||||
## Key Features
|
||||
|
||||
- 所有响应日志记录可查,便于审计和优化
|
||||
- `[TEST]` 前缀标识测试输出,防止与真实回复混淆
|
||||
- 完整执行所有业务逻辑(Intent Classification / Knowledge Lookup / Handoff 判断),确保行为一致性
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
52
wiki/concepts/Text-and-Search.md
Normal file
52
wiki/concepts/Text-and-Search.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Text-and-Search"
|
||||
type: concept
|
||||
tags: [information-organization, search, retrieval, PKM]
|
||||
sources: [second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
文本与搜索(Text-and-Search)是一种极简信息组织哲学:无需文件夹层级、无需标签系统、无需复杂分类——仅靠自由文本和全文搜索就能实现有效的信息管理和检索。核心论点:所有复杂组织系统的最终目的都可以通过"写下来 + 搜得到"来实现。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Text-and-Search
|
||||
- 文本与搜索
|
||||
- 无结构搜索
|
||||
- Plain Text + Search
|
||||
- 搜索即组织
|
||||
|
||||
## Core Argument
|
||||
|
||||
传统 PKM 工具(Notion、Obsidian、Roam)的困境:
|
||||
- 文件夹层级 → 需要预先规划分类
|
||||
- 标签系统 → 需要持续维护标签一致性
|
||||
- 双链 → 需要主动建立连接
|
||||
|
||||
Text-and-Search 的解法:
|
||||
- **写入**:任何格式,随意内容,无需思考结构
|
||||
- **检索**:需要时通过搜索找到,无需提前组织
|
||||
|
||||
## Mechanism
|
||||
|
||||
- **捕获**:自由文本,无需格式化
|
||||
- **存储**:AI Agent 记忆系统或全文索引
|
||||
- **检索**:全局搜索(Cmd+K)或语义搜索
|
||||
|
||||
## In System
|
||||
|
||||
- [[Second Brain]] 的核心组织原则
|
||||
- 与 Obsidian Dataview(结构化查询)形成对比
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[Zero-Friction Capture]] — Text-and-Search 允许真正的零摩擦捕获(无需组织)
|
||||
- [[Cumulative Memory]] — 累积记忆使搜索变得更有价值(海量历史数据中搜索)
|
||||
|
||||
## Contrast
|
||||
|
||||
- **[[dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1]]**:强调 Obsidian + Dataview 的结构化查询能力,属于"组织优先"
|
||||
- **[[Second Brain]]**:强调 Text-and-Search 的极简主义,属于"搜索优先"
|
||||
- 两者并非绝对对立:Text-and-Search 适合快速捕获,结构化适合深度关联分析
|
||||
40
wiki/concepts/Unified-Inbox.md
Normal file
40
wiki/concepts/Unified-Inbox.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Unified Inbox"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
---
|
||||
|
||||
# Unified Inbox
|
||||
|
||||
## Definition
|
||||
|
||||
将多个通信渠道的客户消息整合至单一平台进行统一管理和回复的架构模式。
|
||||
|
||||
## Core Properties
|
||||
|
||||
- **多渠道汇聚**:WhatsApp / Instagram DMs / Email / Google Reviews 等不同渠道的消息统一进入同一个收件箱
|
||||
- **去重与合并**:同一客户跨渠道的消息能够关联识别
|
||||
- **统一状态管理**:所有消息共享同一个处理状态(待处理 / 处理中 / 已解决 / 已升级)
|
||||
- **AI 增强层**:在收件箱之上叠加 AI 自动分类、回复建议和意图识别
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
[WhatsApp] ─┐
|
||||
[Instagram] ─┼──→ [Unified Inbox] ──→ [AI Auto-Response]
|
||||
[Gmail] ─┤ │
|
||||
[Reviews] ─┘ ├──→ [Human Handoff] ──→ [Agent Queue]
|
||||
│
|
||||
└──→ [Knowledge Base Lookup]
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Intent-Classification]]:在统一收件箱内对每条消息进行意图识别
|
||||
- [[Human-Handoff]]:AI 无法处理时转交人工
|
||||
- [[Multi-Channel-Integration]]:统一收件箱的底层多渠道接入能力
|
||||
|
||||
## Sources
|
||||
|
||||
- [[multi-channel-customer-service]]
|
||||
57
wiki/concepts/Weekly-Pattern-Analysis.md
Normal file
57
wiki/concepts/Weekly-Pattern-Analysis.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Weekly Pattern Analysis"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AI Agent 每周汇总用户的习惯完成数据,自动发现隐藏在时间序列中的行为规律,并将发现转化为可操作的下周建议。
|
||||
|
||||
## Data Inputs
|
||||
|
||||
一周的每日习惯完成记录:
|
||||
```json
|
||||
{
|
||||
"morning_workout": ["✓", "✓", "✗", "✓", "✓", "✗", "✓"],
|
||||
"read_30min": ["✓", "✓", "✓", "✓", "✗", "✗", "✗"]
|
||||
}
|
||||
```
|
||||
|
||||
## Analysis Outputs
|
||||
|
||||
每周日 10 AM 自动生成结构化报告:
|
||||
|
||||
```text
|
||||
每周总结报告:
|
||||
- 晨练:本周 5/7 天完成,最长连续 5 天
|
||||
- 阅读:本周 3/7 天完成,最差日:周五、周六
|
||||
- 整体完成率:67%
|
||||
- 最佳日:周三
|
||||
- 最差日:周五
|
||||
|
||||
发现的行为模式:
|
||||
- "你总是在有早会的日子跳过晨练"
|
||||
- "周五和周六晚上你从不阅读"
|
||||
- "喝水习惯在周末断崖式下降"
|
||||
|
||||
下周建议:
|
||||
- 考虑将周五晚上设为阅读替代时间(如播客)
|
||||
- 早会日提前 30 分钟闹钟
|
||||
```
|
||||
|
||||
## Why It Works
|
||||
|
||||
- **自我认知升级**:用户通过数据看到自己未曾注意的行为模式
|
||||
- **归因而非自责**:模式发现将"失败"转化为"可优化的行为",减少内疚感
|
||||
- **主动预防**:下周针对性的微小调整("早会日提前闹钟")比泛泛的"多努力"更可执行
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Active Accountability]] — Weekly Pattern Analysis 是 Active Accountability 的周期性总结机制
|
||||
- [[Streak Tracking]] — Streak 数据是 Pattern Analysis 的主要输入
|
||||
- [[Food Sensitivity Tracking]] — 同一模式在健康追踪场景的应用
|
||||
|
||||
## Source
|
||||
- [[habit-tracker-accountability-coach]]
|
||||
42
wiki/concepts/Zero-Friction-Capture.md
Normal file
42
wiki/concepts/Zero-Friction-Capture.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Zero-Friction Capture"
|
||||
type: concept
|
||||
tags: [capture, productivity, memory, UX]
|
||||
sources: [second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
零摩擦捕获(Zero-Friction Capture)是一种信息获取设计原则:捕获信息的操作必须像发短信一样简单,任何额外的步骤(打开 App、选择文件夹、添加标签)都会形成阻力,导致用户放弃持续使用。核心公式:**捕获摩擦力 < 遗忘摩擦力** 时,用户才会持续使用。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Zero-Friction Capture
|
||||
- 零摩擦捕获
|
||||
- Frictionless Capture
|
||||
- 低摩擦信息获取
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **即时性**:无需打开专用 App,直接在已有界面(短信/IM)捕获
|
||||
2. **无组织**:不需要选择文件夹、标签或分类
|
||||
3. **自然语言**:自由文本,无需格式化
|
||||
4. **无审查**:不需要判断"这条信息值不值得记录"
|
||||
|
||||
## Mechanism
|
||||
|
||||
- **Telegram/Discord/iMessage** → 零摩擦接收入口
|
||||
- **AI Agent** → 自动分类和存储(后端处理,用户无感知)
|
||||
- **对比传统 App**:Notion 需要选择 Workspace/Page/Block,Apple Notes 需要点击保存
|
||||
|
||||
## In System
|
||||
|
||||
- [[Second Brain]] 的核心设计原则
|
||||
- [[Inbox De-clutter]] 同一原则的 Email 场景实现
|
||||
- [[custom-morning-brief]] 通过 Telegram 实现零摩擦信息供给
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[Cumulative Memory]] — 零摩擦捕获使信息量增加,从而增强累积记忆价值
|
||||
- [[Conversational Interface]] — 对话界面是实现零摩擦捕获的关键手段
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Alex Finn"
|
||||
type: entity
|
||||
tags: [content-creator, openclaw-community]
|
||||
sources: [market-research-product-factory, content-factory, custom-morning-brief]
|
||||
sources: [market-research-product-factory, content-factory, custom-morning-brief, second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "OpenClaw"
|
||||
type: entity
|
||||
tags: [OpenClaw, Agent, Workspace, Multi-Agent]
|
||||
sources: [multi-agent-team, 万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest, self-healing-home-server, custom-morning-brief]
|
||||
sources: [multi-agent-team, 万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest, self-healing-home-server, custom-morning-brief, second-brain]
|
||||
last_updated: 2026-03-21
|
||||
---
|
||||
|
||||
|
||||
28
wiki/entities/Tiago-Forte.md
Normal file
28
wiki/entities/Tiago-Forte.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Tiago Forte"
|
||||
type: entity
|
||||
tags: [knowledge-management, productivity, author]
|
||||
sources: [second-brain]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Tiago Forte 是《Building a Second Brain》(构建第二大脑)一书的作者,提出了基于 CODE 方法(Capture/Organize/Distill/Express)的个人知识管理体系。他的方法论是数字知识管理领域的经典框架,影响了大量笔记应用和 PKM(Personal Knowledge Management)工具的设计理念。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Tiago Forte
|
||||
- Tiago Forte (BASB)
|
||||
- Building a Second Brain (BASB)
|
||||
|
||||
## Role in System
|
||||
|
||||
- [[second-brain]] 的方法论来源,提供了个人第二大脑的理论基础
|
||||
- 其 CODE 方法(Capture/Organize/Distill/Express)启发了 OpenClaw 等 AI Agent 记忆系统的设计
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — 实践层面的 AI Agent 实现,与 BASB 方法论互补
|
||||
- [[second-brain]] — 直接引用的方法论来源
|
||||
- [[Alex Finn]] — 作为 OpenClaw 内容创作者,同样受 BASB 方法论影响
|
||||
@@ -4,6 +4,10 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-22] [Multi-Channel AI Customer Service Platform](sources/multi-channel-customer-service.md)
|
||||
- [2026-04-22] [Second Brain](sources/second-brain.md)
|
||||
- [2026-04-22] [LaTeX Paper Writing](sources/latex-paper-writing.md)
|
||||
- [2026-04-22] [Habit Tracker & Accountability Coach](sources/habit-tracker-accountability-coach.md)
|
||||
- [2026-04-22] [Todoist Task Manager](sources/todoist-task-manager.md)
|
||||
- [2026-04-22] [Dynamic Dashboard with Sub-agent Spawning](sources/dynamic-dashboard.md)
|
||||
- [2026-04-22] [Pre-Build Idea Validator](sources/pre-build-idea-validator.md)
|
||||
@@ -410,10 +414,6 @@
|
||||
- [2026-04-17] [overnight-mini-app-builder](sources/overnight-mini-app-builder.md) — (expected: wiki/sources/overnight-mini-app-builder.md — source missing)
|
||||
- [2026-04-17] [local-crm-framework](sources/local-crm-framework.md) — (expected: wiki/sources/local-crm-framework.md — source missing)
|
||||
- [2026-04-17] [n8n-workflow-orchestration](sources/n8n-workflow-orchestration.md) — (expected: wiki/sources/n8n-workflow-orchestration.md — source missing)
|
||||
- [2026-04-17] [multi-channel-customer-service](sources/multi-channel-customer-service.md) — (expected: wiki/sources/multi-channel-customer-service.md — source missing)
|
||||
- [2026-04-17] [second-brain](sources/second-brain.md) — (expected: wiki/sources/second-brain.md — source missing)
|
||||
- [2026-04-17] [latex-paper-writing](sources/latex-paper-writing.md) — (expected: wiki/sources/latex-paper-writing.md — source missing)
|
||||
- [2026-04-17] [Habit Tracker & Accountability Coach](sources/habit-tracker-accountability-coach.md) — AI Agent 作为主动问责伙伴,通过 Telegram/SMS 每日定时签到,替代被动习惯追踪 App
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
@@ -635,6 +635,7 @@
|
||||
- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md)
|
||||
- [Telnyx](entities/Telnyx.md)
|
||||
- [Terraform](entities/Terraform.md)
|
||||
- [Tiago-Forte](entities/Tiago-Forte.md)
|
||||
- [Todoist](entities/Todoist.md)
|
||||
- [Trae](entities/Trae.md)
|
||||
- [TranscriptAPI](entities/TranscriptAPI.md)
|
||||
@@ -655,6 +656,8 @@
|
||||
|
||||
## Concepts
|
||||
- [ActionItemTracking](concepts/ActionItemTracking.md)
|
||||
- [Active-Accountability](concepts/Active-Accountability.md)
|
||||
- [Adaptive-Tone](concepts/Adaptive-Tone.md)
|
||||
- [Agent-Build-Gate](concepts/Agent-Build-Gate.md)
|
||||
- [Agent-Driven-Market-Research](concepts/Agent-Driven-Market-Research.md)
|
||||
- [Agent-Memory](concepts/Agent-Memory.md)
|
||||
@@ -663,6 +666,7 @@
|
||||
- [Agent-Specialization](concepts/Agent-Specialization.md)
|
||||
- [AGENTS.md](concepts/AGENTS.md.md)
|
||||
- [AgilePractices](concepts/AgilePractices.md)
|
||||
- [AI-Auto-Response](concepts/AI-Auto-Response.md)
|
||||
- [AI-ChatOps](concepts/AI-ChatOps.md)
|
||||
- [AI-Driven-Task-Extraction](concepts/AI-Driven-Task-Extraction.md)
|
||||
- [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md)
|
||||
@@ -684,6 +688,7 @@
|
||||
- [Build-Mode](concepts/Build-Mode.md)
|
||||
- [BuildInPublic](concepts/BuildInPublic.md)
|
||||
- [Business-Impact-Analysis](concepts/Business-Impact-Analysis.md)
|
||||
- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md)
|
||||
- [caffeinate](concepts/caffeinate.md)
|
||||
- [Canary-Release](concepts/Canary-Release.md)
|
||||
- [Centralized-Logging](concepts/Centralized-Logging.md)
|
||||
@@ -692,6 +697,7 @@
|
||||
- [Change-Failure-Rate](concepts/Change-Failure-Rate.md)
|
||||
- [Change-Management](concepts/Change-Management.md)
|
||||
- [Channel-Based-Monitoring](concepts/Channel-Based-Monitoring.md)
|
||||
- [Check-in-Fatigue](concepts/Check-in-Fatigue.md)
|
||||
- [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md)
|
||||
- [CICDPipeline](concepts/CICDPipeline.md)
|
||||
- [Claude-Code-Templates](concepts/Claude-Code-Templates.md)
|
||||
@@ -715,10 +721,12 @@
|
||||
- [Content Automation](concepts/Content Automation.md)
|
||||
- [Continuous-Deployment](concepts/Continuous-Deployment.md)
|
||||
- [Continuous-Integration](concepts/Continuous-Integration.md)
|
||||
- [Conversational-Interface](concepts/Conversational-Interface.md)
|
||||
- [Cost-Optimization](concepts/Cost-Optimization.md)
|
||||
- [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md)
|
||||
- [Cron定时任务](concepts/Cron定时任务.md)
|
||||
- [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md)
|
||||
- [Cumulative-Memory](concepts/Cumulative-Memory.md)
|
||||
- [Daily-Digest](concepts/Daily-Digest.md)
|
||||
- [DAST](concepts/DAST.md)
|
||||
- [Data-Governance](concepts/Data-Governance.md)
|
||||
@@ -763,8 +771,10 @@
|
||||
- [GPG-密钥验证](concepts/GPG-密钥验证.md)
|
||||
- [Green-Computing](concepts/Green-Computing.md)
|
||||
- [Headless-服务器](concepts/Headless-服务器.md)
|
||||
- [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md)
|
||||
- [high-availability](concepts/high-availability.md)
|
||||
- [HTTPS自动化证书](concepts/HTTPS自动化证书.md)
|
||||
- [Human-Handoff](concepts/Human-Handoff.md)
|
||||
- [Hybrid-Cloud](concepts/Hybrid-Cloud.md)
|
||||
- [Hyperautomation](concepts/Hyperautomation.md)
|
||||
- [IAST](concepts/IAST.md)
|
||||
@@ -773,6 +783,7 @@
|
||||
- [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md)
|
||||
- [Incident-Management](concepts/Incident-Management.md)
|
||||
- [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md)
|
||||
- [Intent-Classification](concepts/Intent-Classification.md)
|
||||
- [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md)
|
||||
- [Inversion](concepts/Inversion.md)
|
||||
- [IP纯净度](concepts/IP纯净度.md)
|
||||
@@ -782,6 +793,7 @@
|
||||
- [JFFS双清](concepts/JFFS双清.md)
|
||||
- [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md)
|
||||
- [Kill-Switch](concepts/Kill-Switch.md)
|
||||
- [Language-Detection](concepts/Language-Detection.md)
|
||||
- [Last-30-Days-Method](concepts/Last-30-Days-Method.md)
|
||||
- [launchd](concepts/launchd.md)
|
||||
- [Lead-Time](concepts/Lead-Time.md)
|
||||
@@ -868,6 +880,7 @@
|
||||
- [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md)
|
||||
- [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md)
|
||||
- [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
|
||||
- [Streak-Tracking](concepts/Streak-Tracking.md)
|
||||
- [symbolic-link](concepts/symbolic-link.md)
|
||||
- [system-monitoring](concepts/system-monitoring.md)
|
||||
- [systemd](concepts/systemd.md)
|
||||
@@ -876,6 +889,8 @@
|
||||
- [TCP隧道](concepts/TCP隧道.md)
|
||||
- [Telegram-Trigger](concepts/Telegram-Trigger.md)
|
||||
- [Telephony-Integration](concepts/Telephony-Integration.md)
|
||||
- [Test-Mode](concepts/Test-Mode.md)
|
||||
- [Text-and-Search](concepts/Text-and-Search.md)
|
||||
- [Threat-Modeling](concepts/Threat-Modeling.md)
|
||||
- [Time-to-Market](concepts/Time-to-Market.md)
|
||||
- [Todoist-API](concepts/Todoist-API.md)
|
||||
@@ -889,6 +904,7 @@
|
||||
- [tui](concepts/tui.md)
|
||||
- [UEFI-Only](concepts/UEFI-Only.md)
|
||||
- [UEFI启动](concepts/UEFI启动.md)
|
||||
- [Unified-Inbox](concepts/Unified-Inbox.md)
|
||||
- [USER.md](concepts/USER.md.md)
|
||||
- [Vendor-Lock-In](concepts/Vendor-Lock-In.md)
|
||||
- [Vibe-Coding](concepts/Vibe-Coding.md)
|
||||
@@ -898,9 +914,11 @@
|
||||
- [Wayland](concepts/Wayland.md)
|
||||
- [Webhook](concepts/Webhook.md)
|
||||
- [WEBHOOK_URL](concepts/WEBHOOK_URL.md)
|
||||
- [Weekly-Pattern-Analysis](concepts/Weekly-Pattern-Analysis.md)
|
||||
- [What-If-Simulation](concepts/What-If-Simulation.md)
|
||||
- [Workspace](concepts/Workspace.md)
|
||||
- [X11](concepts/X11.md)
|
||||
- [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md)
|
||||
- [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md)
|
||||
- [一人公司](concepts/一人公司.md)
|
||||
- [个人品牌](concepts/个人品牌.md)
|
||||
|
||||
67
wiki/log.md
67
wiki/log.md
@@ -1,3 +1,20 @@
|
||||
## [2026-04-17] ingest | Habit Tracker & Accountability Coach
|
||||
- Source file: Agent/usecases/habit-tracker-accountability-coach.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 作为主动问责伙伴,通过 Telegram/SMS 每日定时签到,替代被动习惯追踪 App。核心机制:主动问责 + 连续打卡追踪 + 自适应语气 + 每周模式分析。关键洞察:主动询问比被动记录更能驱动行为改变;保持 3-5 个习惯可避免签到疲劳;[[Adaptive Tone]] 自适应语气是关键差异化因素。
|
||||
- Concepts created: [[Adaptive-Tone]], [[Active-Accountability]], [[Streak-Tracking]], [[Check-in-Fatigue]], [[Weekly-Pattern-Analysis]]
|
||||
- Entities created: (无新增,[[Telegram Bot API]]/[[Twilio]]/[[Google Sheets API]] 各仅出现 1 次,不满足≥2次创建条件;[[OpenClaw]] 已存在)
|
||||
- Source page: wiki/sources/habit-tracker-accountability-coach.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(替换 placeholder)
|
||||
- 更新 overview.md,添加 Habit Tracker & Accountability Coach 段落,补充 [[Adaptive Tone]], [[Active Accountability]], [[Streak Tracking]], [[Check-in Fatigue]], [[Weekly Pattern Analysis]] 至 Key Concepts
|
||||
- 创建 5 个 Concept 页面:Adaptive-Tone.md、Active-Accountability.md、Streak-Tracking.md、Check-in-Fatigue.md、Weekly-Pattern-Analysis.md
|
||||
- 已有相关 Concept:[[Scheduled-Reminder]](定时签到技术基础)、[[Agent-Personality]](Adaptive Tone 的上层设计)、[[Morning Briefing]](同一 Cron + AI 推送模式)、[[Food-Sensitivity-Tracking]](同一框架的不同垂直场景)
|
||||
- 已有相关 Entity:[[OpenClaw]](底层运行平台)
|
||||
- 与 [[Health & Symptom Tracker]] 属同一框架(OpenClaw + Telegram + Cron Job + 每周分析),但垂直于个人习惯养成
|
||||
- Contradiction:与[[Todoist Task Manager]] 同属 OpenClaw 生产力工具集,但 Todoist 侧重任务管理,Habit Tracker 侧重个人行为改变——不冲突,属于互补关系
|
||||
- 与传统习惯 App(Streaks/Habitica)的对比:传统 App 强调被动记录和视觉激励;本方案强调主动询问和个性化文字激励
|
||||
|
||||
## [2026-04-22] ingest | Todoist Task Manager
|
||||
- Source file: Agent/usecases/todoist-task-manager.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -160,7 +177,25 @@
|
||||
- 冲突记录:与 habit-tracker-accountability-coach 的习惯追踪 vs 健康数据追踪侧重对比
|
||||
|
||||
|
||||
- Source file: Agent/usecases/self-healing-home-server.md
|
||||
## [2026-04-22] ingest | Second Brain
|
||||
- Source file: Agent/usecases/second-brain.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 作为个人第二大脑的记忆捕获与检索系统——通过短信/Telegram/Discord 零摩擦捕获任何内容,OpenClaw 永久记忆存储,Next.js 可搜索仪表盘提供全局检索。核心洞见:捕获像发短信一样简单,检索像搜索一样简单。灵感来源:Alex Finn YouTube 视频 + Tiago Forte《Building a Second Brain》。
|
||||
- Concepts created: [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]]
|
||||
- Entities created: [[Tiago Forte]]
|
||||
- Entities updated: [[OpenClaw]](追加 second-brain 到 sources), [[Alex Finn]](追加 second-brain 到 sources)
|
||||
- Source page: wiki/sources/second-brain.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(替换 placeholder)
|
||||
- 更新 overview.md,添加 Second Brain 段落,补充 4 个新概念至 Key Concepts
|
||||
- 创建 4 个 Concept 页面:Zero-Friction-Capture.md、Cumulative-Memory.md、Conversational-Interface.md、Text-and-Search.md
|
||||
- 创建 1 个 Entity 页面:Tiago-Forte.md
|
||||
- 与 [[dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1]] 存在冲突记录:Obsidian + Dataview(结构化查询)vs Second Brain(极简搜索)——互补而非互斥
|
||||
- 与 [[custom-morning-brief]] 和 [[self-healing-home-server]] 属相似模式(零摩擦信息捕获 + AI 主动管理),已记录为 Connections
|
||||
- 与 [[habit-tracker-accountability-coach]] 的互补关系:Second Brain 管理想法/链接/书目,Habit Tracker 管理习惯行为——场景不同但方法论相似
|
||||
- 冲突检测:无与其他已摄入来源的实质性内容冲突
|
||||
|
||||
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理——OpenClaw + SSH + Cron Job 系统实现自动健康监控、故障自愈(重启 Pod/扩缩容/修复配置)、邮件分拣、每日 8AM 晨报(天气/日历/系统状态/看板)、知识库录入和安全审计。核心洞察:Cron Job 是真正的产品;知识提取具有复利效应;AI 会硬编码 secrets,TruffleHog pre-push hooks 是必须配置的防线;Local-first Git 是防止 API Key 暴露的架构基础。
|
||||
- Concepts created: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]]
|
||||
@@ -454,7 +489,23 @@
|
||||
- 两种 Docker 开发模式各有适用场景:Attach 容器适合调试,宿主机文件模式适合编排
|
||||
- 无冲突
|
||||
|
||||
## [2026-04-22] ingest | Cursor 2.0初学者使用指南
|
||||
## [2026-04-25] ingest | Multi-Channel AI Customer Service Platform
|
||||
- Source file: Agent/usecases/multi-channel-customer-service.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI 驱动的企业级多渠道客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail、Google Reviews,AI Intent Classification 自动处理 FAQ/预约/投诉/评价,餐厅案例响应时间从 4h 降至 2min 以内,80% 咨询自动处理。支持多语言(EN/ES/UA)和 Test Mode 演示。
|
||||
- Concepts created: [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]]
|
||||
- Entities created: (无新实体;WhatsApp Business API/Instagram Graph API/Gmail/Google Business Profile API/OpenClaw 均已存在或不符合≥2次创建条件)
|
||||
- Source page: wiki/sources/multi-channel-customer-service.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(替换 placeholder)
|
||||
- 更新 overview.md,添加 multi-channel-customer-service 描述段落,添加 8 个新概念至 Key Concepts
|
||||
- 创建 8 个 Concept 页面:Unified-Inbox.md、Intent-Classification.md、Human-Handoff.md、Test-Mode.md、Business-Knowledge-Base.md、Language-Detection.md、AI-Auto-Response.md、Heartbeat-Monitoring.md
|
||||
- 冲突检测:无内容冲突
|
||||
- 与 [[multi-channel-assistant]] 互补:前者面向企业客服场景,后者面向个人助理多渠道入口
|
||||
- 与 [[phone-based-personal-assistant]] 均涉及多渠道消息路由,已在 Connections 中记录
|
||||
- Heartbeat Monitoring 与 [[self-healing-home-server]] 的 Morning Briefing 属同一机制的不同应用场景
|
||||
|
||||
## [2025-12-30] ingest | Cursor 2.0初学者使用指南
|
||||
- Source file: Vibe Coding/Cursor 2.0初学者使用指南.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Cursor 2.0 AI代码编辑器系统入门教程,涵盖安装配置、AI代理操作、代码审查与版本控制,通过Tetris游戏和网页开发案例帮助初学者快速上手
|
||||
@@ -859,4 +910,16 @@
|
||||
- 冲突已记录:Earnings Tracker vs Daily YouTube Digest(架构高度相似,可视为同一 Digest 模式的不同实例)
|
||||
- 与 Daily YouTube Digest 的时间粒度差异已在 Contradictions 节记录(财报事件触发 vs 频道更新检测)
|
||||
|
||||
## [2026-04-22] ingest | LaTeX Paper Writing
|
||||
- Source file: Agent/usecases/latex-paper-writing.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 基于 AI Agent 的 LaTeX 论文写作助手,通过云端 TeX 环境实现无需本地安装的即时编译。Prismer Docker 容器提供云端 LaTeX 编译服务 + latex-compiler skill(4 个工具)+ AI 对话生成 LaTeX 代码 + 内联 PDF 预览。支持 pdflatex/xelatex/lualatex 三种编译器、BibTeX/BibLaTeX 文献管理、四种启动模板(article/IEEE/beamer/Chinese article)。
|
||||
- Concepts created: [[latex-compiler]], [[Prismer]], [[BibTeX]]
|
||||
- Entities created: (无新增,[[Prismer]] 未达到 ≥2次出现条件,暂不创建独立 Entity 页面)
|
||||
- Source page: wiki/sources/latex-paper-writing.md
|
||||
- Notes:
|
||||
- index.md 中条目已存在(placeholder),无需更新
|
||||
- overview.md 无需更新(本内容属于垂直场景,无跨主题综合价值)
|
||||
- 已有相关 Concept:[[Docker]](容器化部署底座)、[[OpenClaw]](如在 OpenClaw 环境中使用)
|
||||
- 无已知内容冲突
|
||||
|
||||
|
||||
@@ -11,9 +11,13 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
|
||||
|
||||
**[[phone-based-personal-assistant]]**:通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话,支持日历查询、Jira 任务更新、网络搜索等技能,无需智能手机 App 或浏览器,覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补:文字入口覆盖图文交互,语音入口覆盖无屏场景。
|
||||
|
||||
**[[multi-channel-customer-service]]**:基于 [[OpenClaw]] 的企业级多渠道 AI 客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一 AI 驱动的收件箱,AI 自动识别消息意图(FAQ/Appointment/Complaint/Review)并匹配对应处理策略,语言自动检测匹配客户语言(ES/EN/UA),支持 Test Mode 演示而不影响真实客户。餐厅实测响应时间从 4+ 小时降至 2 分钟以内,80% 咨询自动处理。与 [[multi-channel-assistant]] 互补——后者面向个人助理多渠道入口,前者面向企业客服场景。
|
||||
|
||||
**Inbox De-clutter**:基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件,生成精华摘要并附原文链接,根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。
|
||||
|
||||
Key concepts: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]]
|
||||
**[[Second Brain]]**:基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容(\"Remind me to read a book...\"),OpenClaw 永久记忆存储所有对话,Next.js 可搜索仪表盘提供全局检索,Cmd+K 跨所有记忆/文档/任务全局搜索。核心洞见:**捕获像发短信一样简单,检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大,用户从手机发消息就能在电脑端构建内容。灵感来源:Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。
|
||||
|
||||
Key concepts: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]], [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]], [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]]
|
||||
|
||||
### Multi-Agent Monitoring & Automation
|
||||
**Dynamic Dashboard**:基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源,定时聚合结果推送 Discord,支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发,立即获得实时洞察。与 [[self-healing-home-server]] 的系统监控场景关联,[[earnings-tracker]] 的市场数据监控场景扩展,[[content-factory]] 共享子代理并行执行模式。
|
||||
|
||||
44
wiki/sources/latex-paper-writing.md
Normal file
44
wiki/sources/latex-paper-writing.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "LaTeX Paper Writing"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/latex-paper-writing.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:基于 AI Agent 的 LaTeX 论文写作助手,通过云端 TeX 环境实现无需本地安装的即时编译
|
||||
- 问题域:本地 LaTeX 环境配置繁琐(TeX Live 体积巨大)、编译错误调试繁琐、在编辑器和 PDF 阅读器之间切换打断写作流
|
||||
- 方法/机制:Prismer Docker 容器提供云端 LaTeX 编译服务 + latex-compiler skill(4 个工具) + AI 对话生成 LaTeX 代码 + 内联 PDF 预览
|
||||
- 结论/价值:通过云端即时编译消除本地安装,实现对话式论文写作,AI 负责生成 LaTeX 源码并自动修复编译错误
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- AI Agent 可以作为 LaTeX 写作助手,用户描述内容需求,Agent 生成对应的 LaTeX 源码
|
||||
- 通过 Docker 容器在云端运行完整 TeX Live(端口 8080),无需在本地安装任何 TeX 发行版
|
||||
- 支持三种编译器自动选择:pdflatex(默认)、xelatex(支持中文/CJK)、lualatex(Unicode 支持)
|
||||
- 内联 PDF 预览无需切换到其他应用程序
|
||||
- 提供四种启动模板:article、IEEE、beamer(演示文稿)、Chinese article(中文论文)
|
||||
- 支持 BibTeX/BibLaTeX 参考文献管理,直接粘贴 .bib 内容即可
|
||||
- 交叉引用需运行 2 次编译 pass
|
||||
|
||||
## Key Quotes
|
||||
> "Setting up a local LaTeX environment is painful — installing TeX Live takes gigabytes, debugging compilation errors is tedious, and switching between your editor and PDF viewer breaks flow." — 痛点描述
|
||||
> "Use xelatex if I need Chinese/CJK support, otherwise default to pdflatex. Always run 2 passes for cross-references." — 编译器使用规范
|
||||
|
||||
## Key Concepts
|
||||
- [[latex-compiler]]:Prismer 内置 skill,提供 4 个工具:`latex_compile`、`latex_preview`、`latex_templates`、`latex_get_template`
|
||||
- [[Prismer]]:开源 AI Agent workspace 项目,通过 Docker 提供完整 TeX Live 云端环境,LaTeX server 监听端口 8080
|
||||
- [[Docker]]:容器化部署底座,Prismer 通过 `docker compose -f docker/docker-compose.dev.yml up` 启动
|
||||
- [[BibTeX]]:LaTeX 参考文献格式工具,支持 .bib 文献库管理,BibLaTeX 是其现代替代方案
|
||||
|
||||
## Key Entities
|
||||
- [[Prismer]]:GitHub 开源项目(Prismer-AI/Prismer),提供云端 TeX Live 和 latex-compiler skill,Agent 无需额外安装
|
||||
|
||||
## Connections
|
||||
- [[latex-paper-writing]] ← depends_on ← [[Prismer]]
|
||||
- [[Prismer]] ← runs_on ← [[Docker]]
|
||||
|
||||
## Contradictions
|
||||
- (无已知冲突)
|
||||
51
wiki/sources/multi-channel-customer-service.md
Normal file
51
wiki/sources/multi-channel-customer-service.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Multi-Channel AI Customer Service Platform"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/multi-channel-customer-service.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI 驱动的多渠道客服统一收件箱,专为小型企业设计,整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一平台。
|
||||
- 问题域:小型企业在多个渠道管理客户消息时面临响应延迟、人工成本高、7×24覆盖困难等问题。
|
||||
- 方法/机制:AI 自动回复处理常见问题(FAQ/预约/咨询),复杂问题转人工,Intent Classification 识别消息类型,语言自动检测并匹配客户语言回复,支持 Test Mode 演示而不影响真实客户。
|
||||
- 结论/价值:餐厅实测将响应时间从 4 小时缩短至 2 分钟以内,80% 的咨询自动处理。
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 小型企业需在 WhatsApp、Instagram DMs、邮件、Google Reviews 多个渠道应对客户,7×24 即时响应成本高昂。
|
||||
- AI 统一收件箱将所有渠道整合至一处,AI 自动回复处理 FAQ、预约请求和常见咨询。
|
||||
- Intent Classification 将消息分类为 FAQ → 从知识库回复、Appointment → 确认预约、Complaint → 标记人工审核、Review → 感谢并回应。
|
||||
- Test Mode 使代理商可在不影响真实客户的情况下演示系统。
|
||||
- 餐厅案例:响应时间从 4+ 小时降至 2 分钟以内,80% 咨询自动处理。
|
||||
|
||||
## Key Quotes
|
||||
> "Small businesses juggle WhatsApp, Instagram DMs, emails, and Google Reviews across multiple apps. Customers expect instant responses 24/7, but hiring staff for round-the-clock coverage is expensive." — 问题背景
|
||||
> "One restaurant reduced response time from 4+ hours to under 2 minutes, handling 80% of inquiries automatically." — 实际效果数据
|
||||
|
||||
## Key Concepts
|
||||
- [[Unified-Inbox]]:将多个客服渠道(WhatsApp/Instagram/Email/Review)整合至单一 AI 驱动的收件箱
|
||||
- [[Intent-Classification]]:AI 自动识别客户消息意图(FAQ/Appointment/Complaint/Review)并匹配对应处理策略
|
||||
- [[Human-Handoff]]:复杂问题或投诉自动转交人工客服,AI 仅处理可自动回复的高频问题
|
||||
- [[Test-Mode]]:代理商演示模式,日志记录但实际不发送至真实渠道,不影响现有客户
|
||||
- [[Business-Knowledge-Base]]:AI 客服的知识库,包含服务/定价/营业时间/FAQ/升级触发条件
|
||||
- [[Language-Detection]]:自动检测客户语言(ES/EN/UA)并以对应语言回复
|
||||
- [[AI-Auto-Response]]:基于知识库的自动回复引擎,处理常见问题无需人工介入
|
||||
- [[Heartbeat-Monitoring]]:定时心跳检查,监控未回复消息积压并告警
|
||||
|
||||
## Key Entities
|
||||
- [[WhatsApp-Business-API]]:WhatsApp Business 官方 API,通过 360dialog 或官方渠道接入
|
||||
- [[Instagram-Graph-API]]:Meta Business Suite 的 Instagram 消息 API
|
||||
- [[Gmail]]:通过 gog CLI OAuth 接入 Gmail 收件箱
|
||||
- [[Google-Business-Profile-API]]:Google 商家评价 API,用于管理和回复 Google Reviews
|
||||
- [[OpenClaw]]:AI Agent 框架,支撑消息路由和 AGENTS.md 配置逻辑
|
||||
|
||||
## Connections
|
||||
- [[multi-channel-assistant]] ← extends ← [[multi-channel-customer-service]]:前者侧重个人助理多渠道入口,后者侧重企业客服场景
|
||||
- [[phone-based-personal-assistant]] ← shares_channel_concept ← [[multi-channel-customer-service]]:两者均处理多渠道消息路由,但前者针对个人助理,后者针对企业客服
|
||||
- [[Self-Healing-Home-Server]] ← shares_heartbeat ← [[multi-channel-customer-service]]:两者均使用 Heartbeat 定时检查机制
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本来源与现有 Wiki 来源在场景和目标受众上均可互补。
|
||||
48
wiki/sources/second-brain.md
Normal file
48
wiki/sources/second-brain.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Second Brain"
|
||||
type: source
|
||||
tags: [personal-knowledge-management, openclaw, memory, productivity]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/second-brain.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 作为个人第二大脑的记忆捕获与检索系统
|
||||
- 问题域:传统笔记应用(Notion/Apple Notes)组织成本过高导致用户放弃使用的问题
|
||||
- 方法/机制:零摩擦捕获(短信/Telegram/Discord 随意文本) + 永久记忆存储 + Next.js 可搜索仪表盘
|
||||
- 结论/价值:捕获像发短信一样简单,检索像搜索一样简单——零文件夹、零标签、零复杂组织
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- AI Agent 的累积记忆系统使系统随时间变得越来越强大(用户告诉它的所有内容都会被永久记住)
|
||||
- 从手机发消息给 Bot,AI 就能在电脑端构建内容——对话本身就是界面
|
||||
- 每个笔记应用最终都会变成负担,因为组织的摩擦力大于遗忘的摩擦力
|
||||
|
||||
## Key Quotes
|
||||
> "Capture should be as easy as texting, and retrieval should be as easy as searching." — 核心设计原则
|
||||
|
||||
> "Zero-friction capture — you don't need to open an app, pick a folder, or add tags. Just text." — 零摩擦捕获机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Zero-Friction Capture]]:捕获操作必须零摩擦,像发短信一样简单才能持续使用
|
||||
- [[Cumulative Memory]]:Agent 的记忆系统累积用户告知的所有内容,随时间推移变得更有价值
|
||||
- [[Conversational Interface]]:对话本身就是用户界面,用户从手机发消息,AI 在电脑端构建内容
|
||||
- [[Text-and-Search]]:无需文件夹、标签、复杂组织,仅靠文本和搜索
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:底层运行平台,提供记忆存储系统和 Next.js 构建能力
|
||||
- [[Alex Finn]]:YouTube 内容创作者,通过视频分享 OpenClaw 高阶用法,是本文档的启发来源
|
||||
- [[Tiago Forte]]:《Building a Second Brain》作者,方法论层面的重要参考
|
||||
|
||||
## Connections
|
||||
- [[custom-morning-brief]] ← similar_pattern ← [[Second Brain]]
|
||||
- [[self-healing-home-server]] ← similar_pattern ← [[Second Brain]]
|
||||
- [[Alex Finn]] ← inspired_by ← [[Second Brain]]
|
||||
- [[OpenClaw]] ← powers ← [[Second Brain]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1]] 冲突:
|
||||
- 冲突点:Obsidian + Dataview 需要用户主动维护标签和结构;Second Brain 强调零摩擦
|
||||
- 当前观点:零摩擦是持续使用的关键,结构化组织会形成阻力
|
||||
- 对方观点:Dataview 提供了结构化查询能力,是 Obsidian 的优势
|
||||
Reference in New Issue
Block a user