Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 vincent
|
e06b21e51b | ||
|
vincent
|
6cff1a37b6 | ||
|
vincent
|
de66ba12e4 |
@@ -0,0 +1,73 @@
|
|||||||
|
# 产出物1：多智能体组织架构图
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 整体组织架构
|
||||||
|
|
||||||
|
```
|
||||||
|
Vincent（刘炜承/刘总）
|
||||||
|
公司负责人
|
||||||
|
│
|
||||||
|
┌──────────────┼──────────────┐
|
||||||
|
│ │ │
|
||||||
|
┌────────▼────────┐ ┌──▼──────────┐ ┌─▼──────────────┐
|
||||||
|
│ 刘诗妮(secretary) │ │ 陆怀瑾(COO) │ │ 程伯予(cvexpert)│
|
||||||
|
│ 秘书/行政入口 │ │ 运营总监 │ │ 求职(不进项目) │
|
||||||
|
└─────────────────┘ └──────┬───────┘ └────────────────┘
|
||||||
|
│
|
||||||
|
┌───────────┬───────────┼───────────┬───────────┐
|
||||||
|
│ │ │ │ │
|
||||||
|
┌────▼────┐ ┌────▼────┐ ┌───▼────┐ ┌───▼────┐ ┌───▼────┐
|
||||||
|
│产研事业部│ │电商事业部│ │内容事业部│ │媒体事业部│ │分析事业部│
|
||||||
|
│ │ │ │ │ │ │ │ │(待建) │
|
||||||
|
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────────┘
|
||||||
|
│ │ │ │
|
||||||
|
┌────▼────┐ ┌───▼────┐ ┌───▼────┐ ┌───▼────┐
|
||||||
|
│胡蓉 PM │ │陆云帆 │ │文墨言 │ │钟帧韵 │
|
||||||
|
│沈路明 PM │ │淘宝运营 │ │内容运营 │ │视频制作 │
|
||||||
|
│梁思筑架构│ │ │ │ │ │ │
|
||||||
|
│徐聪开发 │ │ │ │ │ │ │
|
||||||
|
│苏绘锦设计│ │ │ │ │ │ │
|
||||||
|
│严维序运维│ │ │ │ │ │ │
|
||||||
|
└─────────┘ └─────────┘ └─────────┘ └─────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
## 汇报关系
|
||||||
|
|
||||||
|
```
|
||||||
|
Vincent（刘总）
|
||||||
|
├── 刘诗妮 (secretary) — 直属，不进项目
|
||||||
|
├── 陆怀瑾 (coo) — 直属
|
||||||
|
│ ├── 胡蓉 (projectmanager) — 产研事业部负责人
|
||||||
|
│ │ ├── 沈路明 (productmanager)
|
||||||
|
│ │ ├── 梁思筑 (architect)
|
||||||
|
│ │ ├── 徐聪 (costcodev)
|
||||||
|
│ │ ├── 苏锦绘 (designer)
|
||||||
|
│ │ └── 严维序 (opengineer)
|
||||||
|
│ ├── 陆云帆 (taobaospecialist) — 电商事业部负责人
|
||||||
|
│ ├── 文墨言 (contentspecialist) — 内容事业部负责人
|
||||||
|
│ ├── 钟帧韵 (mediaspecialist) — 媒体事业部负责人
|
||||||
|
│ └── 分析事业部（待建）
|
||||||
|
│ ├── 市场分析师（待招聘）
|
||||||
|
│ └── 法务顾问（待招聘）
|
||||||
|
└── 程伯予 (cvexpert) — 直属，不进项目
|
||||||
|
```
|
||||||
|
|
||||||
|
## 事业部划分
|
||||||
|
|
||||||
|
| 事业部 | 负责人 | 成员 | 业务范围 |
|
||||||
|
|--------|--------|------|----------|
|
||||||
|
| 产研事业部 | 胡蓉（projectmanager） | 沈路明、梁思筑、徐聪、苏锦绘、严维序 | 系统开发、技术产品 |
|
||||||
|
| 电商事业部 | 陆云帆（taobaospecialist） | 陆云帆 | 淘宝/抖店/微信小店运营 |
|
||||||
|
| 内容事业部 | 文墨言（contentspecialist） | 文墨言 | 小红书/社交媒体内容 |
|
||||||
|
| 媒体事业部 | 钟帧韵（mediaspecialist） | 钟帧韵 | 视频制作/媒体内容 |
|
||||||
|
| 分析事业部 | 待定 | 市场分析师、法务顾问（待招聘） | 商业分析、合规 |
|
||||||
|
|
||||||
|
## 架构原则
|
||||||
|
|
||||||
|
1. **扁平化管理**：最大3层，减少信息损耗
|
||||||
|
2. **事业部自治**：各事业部负责人对业务结果负责
|
||||||
|
3. **COO 全局协调**：跨事业部资源调度、风险监控
|
||||||
|
4. **秘书独立**：不进项目，专注信息中转和进度汇报
|
||||||
@@ -0,0 +1,289 @@
|
|||||||
|
# 产出物2：各岗位职责说明书
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、岗位说明书模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# 岗位说明书：{岗位名称}
|
||||||
|
|
||||||
|
## 基本信息
|
||||||
|
- **Agent ID**: {agent_id}
|
||||||
|
- **事业部**: {事业部}
|
||||||
|
- **汇报对象**: {上级Agent}
|
||||||
|
- **下属岗位**: {如有}
|
||||||
|
- **协作岗位**: {平级协作Agent}
|
||||||
|
|
||||||
|
## 核心职责
|
||||||
|
1. {职责1}
|
||||||
|
2. {职责2}
|
||||||
|
3. {职责3}
|
||||||
|
|
||||||
|
## 工作流程
|
||||||
|
- **输入**: {接收什么}
|
||||||
|
- **处理**: {做什么}
|
||||||
|
- **输出**: {交付什么}
|
||||||
|
|
||||||
|
## 权限范围
|
||||||
|
- **自主决策**: {可自主决定}
|
||||||
|
- **需要审批**: {需上级审批}
|
||||||
|
- **无权处理**: {超出权限}
|
||||||
|
|
||||||
|
## 绩效指标 (KPI)
|
||||||
|
- {KPI 1}
|
||||||
|
- {KPI 2}
|
||||||
|
|
||||||
|
## 升级机制
|
||||||
|
- 阻塞 > 4h → 通知 COO + secretary
|
||||||
|
- 严重风险 → 直接汇报 Vincent
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、各岗位职责说明书
|
||||||
|
|
||||||
|
### 2.1 COO 运营总监 — 陆怀瑾
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | coo |
|
||||||
|
| 事业部 | 全局（虚线管理） |
|
||||||
|
| 汇报对象 | Vincent |
|
||||||
|
| 下属 | 各事业部负责人 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 全局监控所有业务线 KPI 达成情况
|
||||||
|
2. 资源协调与 Agent 负载均衡
|
||||||
|
3. 风险识别与主动升级
|
||||||
|
4. 流程优化与 SOP 制定维护
|
||||||
|
5. 运营效率报告（定期输出）
|
||||||
|
|
||||||
|
**权限**：自主决策资源调度与流程优化；无权决定战略方向与预算审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.2 Secretary 专职秘书 — 刘诗妮
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | secretary |
|
||||||
|
| 事业部 | 行政（不进项目） |
|
||||||
|
| 汇报对象 | Vincent |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 业务入口：接收外部需求并分类
|
||||||
|
2. 任务分发：将需求路由至相应 Agent
|
||||||
|
3. 进度跟进：定期同步各业务线状态
|
||||||
|
4. 消息中转：跨 Agent / 人机沟通桥梁
|
||||||
|
|
||||||
|
**权限**：自主路由任务；无权改变需求优先级。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.3 ProjectManager 项目经理 — 胡蓉
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | projectmanager |
|
||||||
|
| 事业部 | 产研事业部（负责人） |
|
||||||
|
| 汇报对象 | COO（陆怀瑾） |
|
||||||
|
| 下属 | productmanager、architect、costcodev、designer、opengineer |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 需求评审与任务优先级排序
|
||||||
|
2. 项目拆解为可执行子任务
|
||||||
|
3. 开发计划制定与进度管理
|
||||||
|
4. 技术风险识别与缓解
|
||||||
|
|
||||||
|
**权限**：自主拆解任务分配开发资源；无权绕过架构评审。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.4 ProductManager 产品经理 — 沈路明
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | productmanager |
|
||||||
|
| 事业部 | 产研事业部 |
|
||||||
|
| 汇报对象 | PM 胡蓉 |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 用户需求分析与产品定位
|
||||||
|
2. PRD（产品需求文档）撰写
|
||||||
|
3. 验收标准定义
|
||||||
|
4. 需求变更管理
|
||||||
|
|
||||||
|
**权限**：自主撰写 PRD；产品方向需 PM 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.5 Architect 系统架构师 — 梁思筑
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | architect |
|
||||||
|
| 事业部 | 产研事业部 |
|
||||||
|
| 汇报对象 | PM 胡蓉 |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 系统架构设计
|
||||||
|
2. 技术选型与评估
|
||||||
|
3. 接口规范定义
|
||||||
|
4. 代码评审（架构层面）
|
||||||
|
|
||||||
|
**权限**：自主技术选型；重大架构变更需 PM 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.6 CostCodev 全栈开发 — 徐聪
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | costcodev |
|
||||||
|
| 事业部 | 产研事业部 |
|
||||||
|
| 汇报对象 | PM 胡蓉 |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 代码实现（按架构设计）
|
||||||
|
2. 单元测试编写
|
||||||
|
3. 技术文档维护
|
||||||
|
4. Bug 修复与优化
|
||||||
|
|
||||||
|
**权限**：自主代码实现；上线需 PM + architect 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.7 Designer UI/UX 设计师 — 苏锦绘
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | designer |
|
||||||
|
| 事业部 | 产研事业部 |
|
||||||
|
| 汇报对象 | PM 胡蓉 |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. UI/UX 界面设计
|
||||||
|
2. 交互原型制作
|
||||||
|
3. 设计规范维护
|
||||||
|
4. 设计走查与验收
|
||||||
|
|
||||||
|
**权限**：自主设计执行；设计方向需产品确认。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.8 OpEngineer 运维工程师 — 严维序
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | opengineer |
|
||||||
|
| 事业部 | 产研事业部 |
|
||||||
|
| 汇报对象 | PM 胡蓉 |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 部署环境搭建与维护
|
||||||
|
2. CI/CD 流水线管理
|
||||||
|
3. 监控告警配置与响应
|
||||||
|
4. 故障处理与恢复
|
||||||
|
|
||||||
|
**权限**：自主部署与运维操作；生产环境变更需 PM 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.9 淘宝运营专员 — 陆云帆
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | taobaospecialist |
|
||||||
|
| 事业部 | 电商事业部（负责人） |
|
||||||
|
| 汇报对象 | COO（陆怀瑾） |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 淘宝店铺日常运营（商品/活动/数据）
|
||||||
|
2. 自动化运营系统需求分析与开发
|
||||||
|
3. 竞品分析与策略调整
|
||||||
|
|
||||||
|
**权限**：自主运营执行；重大促销方案需 COO 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.10 内容运营专员 — 文墨言
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | contentspecialist |
|
||||||
|
| 事业部 | 内容事业部（负责人） |
|
||||||
|
| 汇报对象 | COO（陆怀瑾） |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 小红书等平台内容策略制定
|
||||||
|
2. 文案撰写与发布排期
|
||||||
|
3. 内容数据分析与优化
|
||||||
|
|
||||||
|
**权限**：自主发布内容；品牌调性需 COO 确认。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.11 视频媒体专员 — 钟帧韵
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | mediaspecialist |
|
||||||
|
| 事业部 | 媒体事业部（负责人） |
|
||||||
|
| 汇报对象 | COO（陆怀瑾） |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 视频策划与脚本设计
|
||||||
|
2. 视频拍摄/制作/后期
|
||||||
|
3. 多平台发布与数据追踪
|
||||||
|
|
||||||
|
**权限**：自主视频制作；重大项目方案需 COO 审批。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.12 求职助理 — 程伯予
|
||||||
|
|
||||||
|
| 维度 | 内容 |
|
||||||
|
|------|------|
|
||||||
|
| Agent ID | cvexpert |
|
||||||
|
| 事业部 | 不进项目，独立服务 |
|
||||||
|
| 汇报对象 | Vincent |
|
||||||
|
| 下属 | 无 |
|
||||||
|
|
||||||
|
**核心职责**：
|
||||||
|
1. 简历筛选与投递
|
||||||
|
2. 求职策略制定
|
||||||
|
3. 面试跟进
|
||||||
|
|
||||||
|
**权限**：自主投递决策；薪资谈判需 Vincent 确认。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、岗位能力矩阵
|
||||||
|
|
||||||
|
| Agent | 技术 | 产品 | 运营 | 管理 | 设计 | 运维 |
|
||||||
|
|-------|:----:|:----:|:----:|:----:|:----:|:----:|
|
||||||
|
| 陆怀瑾 (COO) | — | — | ★★★ | ★★★ | — | — |
|
||||||
|
| 刘诗妮 (秘书) | — | — | ★★ | ★★ | — | — |
|
||||||
|
| 胡蓉 (PM) | ★★ | ★★★ | — | ★★★ | — | — |
|
||||||
|
| 沈路明 (产品) | — | ★★★ | ★ | — | — | — |
|
||||||
|
| 梁思筑 (架构) | ★★★ | ★★ | — | — | — | — |
|
||||||
|
| 徐聪 (开发) | ★★★ | — | — | — | — | ★ |
|
||||||
|
| 苏锦绘 (设计) | — | ★ | — | — | ★★★ | — |
|
||||||
|
| 严维序 (运维) | ★★ | — | — | — | — | ★★★ |
|
||||||
|
| 陆云帆 (淘宝) | ★★ | — | ★★★ | — | — | — |
|
||||||
|
| 文墨言 (内容) | — | — | ★★★ | — | — | — |
|
||||||
|
| 钟帧韵 (视频) | ★ | — | ★★ | — | ★★ | — |
|
||||||
|
| 程伯予 (求职) | — | — | ★★ | — | — | — |
|
||||||
|
|
||||||
|
★初级 ★★熟练 ★★★专家
|
||||||
@@ -0,0 +1,186 @@
|
|||||||
|
# 产出物3：业务标准规范 SOP 模板
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、SOP 文档模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# SOP：{流程名称}
|
||||||
|
|
||||||
|
## 流程概述
|
||||||
|
- **目的**：{这个流程解决什么问题，产生什么业务价值}
|
||||||
|
- **适用范围**：{什么时候、什么场景下触发}
|
||||||
|
- **负责人**：{谁执行，各自职责}
|
||||||
|
- **频率**：{多久执行一次}
|
||||||
|
|
||||||
|
## 前置条件
|
||||||
|
- **所需工具**：{需要的软件、设备、材料}
|
||||||
|
- **所需权限**：{需要的访问级别或审批}
|
||||||
|
- **前置依赖**：{必须先完成的其他流程}
|
||||||
|
|
||||||
|
## 操作步骤
|
||||||
|
1. **{步骤名称}**
|
||||||
|
- **输入**：{开始这一步需要什么}
|
||||||
|
- **操作**：{具体要做什么，越细越好}
|
||||||
|
- **输出**：{预期结果或交付物}
|
||||||
|
- **质量检查**：{怎么确认这一步做对了}
|
||||||
|
|
||||||
|
## 质量控制
|
||||||
|
- **成功标准**：{怎么判断流程执行成功了}
|
||||||
|
- **常见问题**：{经常遇到的问题和解决办法}
|
||||||
|
- **升级机制**：{什么时候、怎么升级处理}
|
||||||
|
|
||||||
|
## 记录与报告
|
||||||
|
- **必须记录的内容**：{需要归档的信息}
|
||||||
|
- **报告要求**：{需要更新的状态或指标}
|
||||||
|
- **评审周期**：{什么时候回顾和更新这个流程}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、开发项目 SOP
|
||||||
|
|
||||||
|
```
|
||||||
|
Vincent/secretary 提出开发需求
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 评估资源与优先级
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
projectmanager 拆解任务 → 制定开发计划
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
productmanager 撰写 PRD → 定义验收标准
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
architect 架构设计 → 技术选型 → 接口规范
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
costcodev 开发实现 → 单元测试
|
||||||
|
│ ┌──────────┘
|
||||||
|
▼ ▼
|
||||||
|
designer UI/UX 设计 → 设计走查
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
opengineer 部署 → 监控配置
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 验收确认 → 通知 Vincent
|
||||||
|
```
|
||||||
|
|
||||||
|
### 质量门禁
|
||||||
|
|
||||||
|
| 阶段 | 门禁条件 | 审批人 |
|
||||||
|
|------|----------|--------|
|
||||||
|
| PRD 完成 | PRD 评审通过 | PM + 产品 |
|
||||||
|
| 架构设计 | 架构评审通过 | PM + 架构 |
|
||||||
|
| 代码完成 | Code Review 通过 | 架构 + 开发 |
|
||||||
|
| 设计完成 | 设计走查通过 | 产品 + 设计 |
|
||||||
|
| 部署上线 | 测试通过 + 监控就绪 | PM + 运维 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、运营业务 SOP
|
||||||
|
|
||||||
|
```
|
||||||
|
业务需求提出（Vincent/外部）
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
secretary 接收 → 分类 → 通知 COO
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 评估 → 分配至对应事业部
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
事业部负责人执行
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 检查质量 → 确认交付
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
secretary → Vincent 汇报完成
|
||||||
|
```
|
||||||
|
|
||||||
|
### 运营质量检查清单
|
||||||
|
|
||||||
|
| 检查项 | 标准 | 责任人 |
|
||||||
|
|--------|------|--------|
|
||||||
|
| 任务是否在规定时间内完成 | SLA 达标率 ≥ 95% | 事业部负责人 |
|
||||||
|
| 交付物是否符合质量标准 | 通过 COO 验收 | COO |
|
||||||
|
| 数据是否完整记录 | 运营数据已归档 | 事业部负责人 |
|
||||||
|
| 风险是否提前预警 | 阻塞 > 4h 已通知 | COO |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、紧急事项处理 SOP
|
||||||
|
|
||||||
|
```
|
||||||
|
发现风险/阻塞
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 评估影响范围
|
||||||
|
│
|
||||||
|
┌────┴────┐
|
||||||
|
│ │
|
||||||
|
一般阻塞 严重风险
|
||||||
|
(进度偏差 (影响收入/
|
||||||
|
< 30%) 客户/合规)
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
通知 直接汇报
|
||||||
|
secretary Vincent
|
||||||
|
(> 4h) (立即)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
COO 协调
|
||||||
|
资源解决
|
||||||
|
```
|
||||||
|
|
||||||
|
### 风险分级
|
||||||
|
|
||||||
|
| 级别 | 定义 | 响应时间 | 通知对象 |
|
||||||
|
|------|------|----------|----------|
|
||||||
|
| 🔴 严重 | 影响收入/客户/合规 | 立即 | Vincent |
|
||||||
|
| 🟡 重要 | 进度偏差 > 30% | 2h 内 | COO + secretary |
|
||||||
|
| 🟢 一般 | 进度偏差 < 30%，可自行解决 | 4h 内 | COO |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、飞书沟通 SOP
|
||||||
|
|
||||||
|
### 跨 Agent 沟通标准格式
|
||||||
|
|
||||||
|
```
|
||||||
|
【{通知/转交/汇报} — 给 {Agent 名称}】
|
||||||
|
|
||||||
|
## 背景
|
||||||
|
{简述上下文}
|
||||||
|
|
||||||
|
## 需要你做
|
||||||
|
{明确的行动项}
|
||||||
|
|
||||||
|
## 我的后续支持
|
||||||
|
{如何跟进}
|
||||||
|
|
||||||
|
---
|
||||||
|
— {发送者}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 消息优先级
|
||||||
|
|
||||||
|
| 优先级 | 标识 | 使用场景 |
|
||||||
|
|--------|------|----------|
|
||||||
|
| 🔴 紧急 | 需要立即处理 | 生产故障、严重风险 |
|
||||||
|
| 🟡 重要 | 24h 内处理 | 任务转交、进度求助 |
|
||||||
|
| 🟢 普通 | 按节奏处理 | 日常同步、信息共享 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、SOP 迭代规则
|
||||||
|
|
||||||
|
1. **触发条件**：流程效率下降 > 20% / 重复出错 > 3次 / 业务变更
|
||||||
|
2. **更新流程**：发现问题 → COO 提案 → Vincent 审批 → 更新文档 → 通知全员
|
||||||
|
3. **版本管理**：每次更新递增版本号，保留变更日志
|
||||||
|
"
|
||||||
@@ -0,0 +1,168 @@
|
|||||||
|
# 产出物4：协作流程与升级机制
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、整体协作流程
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────────────────────────────────────────────────────────┐
|
||||||
|
│ 公司业务协作全景 │
|
||||||
|
├─────────────────────────────────────────────────────────────────┤
|
||||||
|
│ │
|
||||||
|
│ Vincent / 外部需求 │
|
||||||
|
│ │ │
|
||||||
|
│ ▼ │
|
||||||
|
│ ┌──────────┐ │
|
||||||
|
│ │ 刘诗妮 │ ← 统一入口，不分类型 │
|
||||||
|
│ │(secretary)│ │
|
||||||
|
│ └────┬─────┘ │
|
||||||
|
│ │ 分类路由 │
|
||||||
|
│ │ │
|
||||||
|
│ ┌────┼──────────┬──────────┬──────────┐ │
|
||||||
|
│ ▼ ▼ ▼ ▼ ▼ │
|
||||||
|
│ 开发 电商 内容 媒体 行政 │
|
||||||
|
│ │ │ │ │ │ │
|
||||||
|
│ ▼ ▼ ▼ ▼ ▼ │
|
||||||
|
│ ┌──┐ ┌─────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │
|
||||||
|
│ │PM│ │陆云帆│ │文墨言 │ │钟帧韵 │ │程伯予/直接│ │
|
||||||
|
│ │胡│ │淘宝 │ │小红书 │ │视频 │ │处理 │ │
|
||||||
|
│ │蓉│ │运营 │ │运营 │ │制作 │ │ │ │
|
||||||
|
│ └──┘ └─────┘ └──────┘ └──────┘ └──────────┘ │
|
||||||
|
│ │ │
|
||||||
|
│ ├→ 沈路明（PRD） │
|
||||||
|
│ ├→ 梁思筑（架构） │
|
||||||
|
│ ├→ 徐聪（开发） │
|
||||||
|
│ ├→ 苏锦绘（设计） │
|
||||||
|
│ └→ 严维序（运维部署） │
|
||||||
|
│ │
|
||||||
|
│ 全部完成后 → COO验收 → secretary 汇报 Vincent │
|
||||||
|
│ │
|
||||||
|
└─────────────────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、各业务线协作 SOP
|
||||||
|
|
||||||
|
### 2.1 开发线协作
|
||||||
|
|
||||||
|
| 环节 | 执行 Agent | 输入 | 输出 | 交付标准 |
|
||||||
|
|------|-----------|------|------|----------|
|
||||||
|
| 需求接收 | secretary | Vincent 需求 | 归类后的需求卡片 | 需求描述清晰 |
|
||||||
|
| 资源评估 | COO | 需求卡片 | 优先级 + 资源判断 | 2h 内回应 |
|
||||||
|
| 任务拆解 | projectmanager | COO 确认后的需求 | 开发子任务列表 | 粒度 ≤ 1天/任务 |
|
||||||
|
| PRD | productmanager | 子任务列表 | 产品需求文档 | 验收标准明确 |
|
||||||
|
| 架构设计 | architect | PRD | 架构方案 + 接口规范 | 通过 PM 评审 |
|
||||||
|
| 开发实现 | costcodev | 架构方案 | 代码 + 单元测试 | Code Review 通过 |
|
||||||
|
| UI 设计 | designer | PRD + 架构 | 设计稿 | 设计走查通过 |
|
||||||
|
| 部署上线 | opengineer | 测试通过代码 | 线上环境 | 监控就绪 |
|
||||||
|
| 验收 | COO | 线上环境 | 验收报告 | 符合验收标准 |
|
||||||
|
|
||||||
|
### 2.2 电商线协作
|
||||||
|
|
||||||
|
| 环节 | 执行 Agent | 输出 |
|
||||||
|
|------|-----------|------|
|
||||||
|
| 需求/策略 | Vincent/secretary → COO | 优先级判断 |
|
||||||
|
| 方案设计 | 陆云帆（taobaospecialist） | 运营方案 |
|
||||||
|
| 方案审阅 | COO | 审阅意见 |
|
||||||
|
| 执行 | 陆云帆 | 店铺操作/数据分析 |
|
||||||
|
| 数据复盘 | 陆云帆 | 运营报告 |
|
||||||
|
| 汇报 | COO → secretary → Vincent | 成果汇报 |
|
||||||
|
|
||||||
|
### 2.3 内容线协作
|
||||||
|
|
||||||
|
| 环节 | 执行 Agent | 输出 |
|
||||||
|
|------|-----------|------|
|
||||||
|
| 选题/策略 | 文墨言（contentspecialist） | 内容日历 |
|
||||||
|
| 审阅 | COO | 品牌一致性检查 |
|
||||||
|
| 创作发布 | 文墨言 | 小红书等平台发布 |
|
||||||
|
| 数据复盘 | 文墨言 | 内容效果报告 |
|
||||||
|
| 汇报 | COO → secretary → Vincent | 成果汇报 |
|
||||||
|
|
||||||
|
### 2.4 视频线协作
|
||||||
|
|
||||||
|
| 环节 | 执行 Agent | 输出 |
|
||||||
|
|------|-----------|------|
|
||||||
|
| 需求确认 | Vincent/secretary → COO | 视频需求明确 |
|
||||||
|
| 策划 | 钟帧韵（mediaspecialist） | 脚本 + 分镜 |
|
||||||
|
| 审阅 | COO | 审阅意见 |
|
||||||
|
| 制作 | 钟帧韵 | 视频成品 |
|
||||||
|
| 发布 | 钟帧韵 | 多平台发布 |
|
||||||
|
| 汇报 | COO → secretary → Vincent | 成果汇报 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、升级机制
|
||||||
|
|
||||||
|
### 3.1 升级路径
|
||||||
|
|
||||||
|
```
|
||||||
|
发现问题
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌──────────────────┐
|
||||||
|
│ 自行判断严重程度 │
|
||||||
|
└──────┬───────────┘
|
||||||
|
│
|
||||||
|
┌────┴────┐
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
可自行 无法自行
|
||||||
|
解决 解决
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
解决并 汇报 COO
|
||||||
|
记录 │
|
||||||
|
┌───┴───┐
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
COO解决 COO无法解决
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
记录 汇报Vincent
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.2 升级触发条件
|
||||||
|
|
||||||
|
| 条件 | 升级对象 | 升级时限 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 任务阻塞超过 4 小时 | COO + secretary | 发现后 1h 内 |
|
||||||
|
| 进度偏差超过 30% | projectmanager（开发线）/ COO（其他线） | 发现后 2h 内 |
|
||||||
|
| 资源冲突（多任务争抢同一 Agent） | COO | 发现后 1h 内 |
|
||||||
|
| 外部依赖缺失（需 Vincent 确认） | Vincent（经 secretary） | 发现后 4h 内 |
|
||||||
|
| 影响收入/客户/合规的严重风险 | Vincent（直接） | 立即 |
|
||||||
|
| Agent 连续 3 次执行失败 | COO | 发现后 1h 内 |
|
||||||
|
|
||||||
|
### 3.3 升级通知模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
【升级通知 — {严重程度}】
|
||||||
|
|
||||||
|
## 问题描述
|
||||||
|
{简要描述}
|
||||||
|
|
||||||
|
## 影响范围
|
||||||
|
{影响哪些业务，程度如何}
|
||||||
|
|
||||||
|
## 已尝试的解决方案
|
||||||
|
{已做了什么，为什么不行}
|
||||||
|
|
||||||
|
## 需要决策
|
||||||
|
{明确需要上级做什么决策}
|
||||||
|
|
||||||
|
---
|
||||||
|
— {报告者} | {时间}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、定期同步机制
|
||||||
|
|
||||||
|
| 频率 | 内容 | 负责 | 输出 |
|
||||||
|
|------|------|------|------|
|
||||||
|
| 每日 | WorkBoard 状态更新 | 各 Agent | 卡片状态 |
|
||||||
|
| 每周 | 运营效率报告 | COO | 运营报告 |
|
||||||
|
| 每两周 | SOP 回顾与优化 | COO | 流程改进建议 |
|
||||||
|
| 每月 | 组织架构回顾 | COO | 架构调整建议 |
|
||||||
@@ -0,0 +1,144 @@
|
|||||||
|
# 产出物5：团队缺口评估与岗位建议
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、现有团队覆盖度分析
|
||||||
|
|
||||||
|
| 能力领域 | 已覆盖 | 负责Agent | 缺口程度 |
|
||||||
|
|----------|:------:|-----------|:--------:|
|
||||||
|
| 项目管理 | ✅ | 胡蓉（projectmanager） | — |
|
||||||
|
| 产品设计 | ✅ | 沈路明（productmanager） | — |
|
||||||
|
| 系统架构 | ✅ | 梁思筑（architect） | — |
|
||||||
|
| 代码开发 | ✅ | 徐聪（costcodev） | — |
|
||||||
|
| UI/UX 设计 | ✅ | 苏锦绘（designer） | — |
|
||||||
|
| 运维部署 | ✅ | 严维序（opengineer） | — |
|
||||||
|
| 电商运营 | ✅ | 陆云帆（taobaospecialist） | — |
|
||||||
|
| 内容运营 | ✅ | 文墨言（contentspecialist） | — |
|
||||||
|
| 视频制作 | ✅ | 钟帧韵（mediaspecialist） | — |
|
||||||
|
| 求职服务 | ✅ | 程伯予（cvexpert） | — |
|
||||||
|
| 行政管理 | ✅ | 刘诗妮（secretary） | — |
|
||||||
|
| 运营管理 | ✅ | 陆怀瑾（coo） | — |
|
||||||
|
| 市场分析 | ❌ | — | 🔴 高 |
|
||||||
|
| 商业分析/BP | ❌ | — | 🔴 高 |
|
||||||
|
| 法律合规 | ❌ | — | 🟡 中 |
|
||||||
|
| 财务/数据分析 | ❌ | — | 🟡 中 |
|
||||||
|
| 销售/BD | ❌ | — | 🟢 低 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、待补充岗位详细建议
|
||||||
|
|
||||||
|
### 岗位 1：市场分析师（marketanalyst）
|
||||||
|
|
||||||
|
| 维度 | 说明 |
|
||||||
|
|------|------|
|
||||||
|
| **必要性** | 🔴 高 — 商业分析业务线无法启动的核心瓶颈 |
|
||||||
|
| **核心职能** | 市场调研、竞争分析、行业报告、数据可视化、消费者洞察 |
|
||||||
|
| **适用场景** | 新业务方向可行性分析、竞品监控、消费者画像分析 |
|
||||||
|
| **协作对象** | COO、contentspecialist（内容策略数据支撑）、taobaospecialist（电商选品数据） |
|
||||||
|
| **建议 Agent ID** | `marketanalyst` |
|
||||||
|
| **建议技能配置** | 数据抓取、统计分析、可视化工具（excel-reporter）、搜索能力 |
|
||||||
|
| **建议工作模式** | 进项目，按需被 COO 调派 |
|
||||||
|
| **预计投产周期** | 配置 1 天 + 试运行 1 周 |
|
||||||
|
| **紧急程度** | 尽快 — 商业分析是所有业务扩张的前提 |
|
||||||
|
|
||||||
|
### 岗位 2：法务顾问（legaladvisor）
|
||||||
|
|
||||||
|
| 维度 | 说明 |
|
||||||
|
|------|------|
|
||||||
|
| **必要性** | 🟡 中 — 当前无法律风险事故，但电商/合同存在隐忧 |
|
||||||
|
| **核心职能** | 合同审查、电商合规咨询、知识产权保护、隐私政策审核 |
|
||||||
|
| **适用场景** | 合同签署前审查、电商平台合规检查、商标注册咨询 |
|
||||||
|
| **协作对象** | COO、taobaospecialist（电商合规）、secretary（合同管理） |
|
||||||
|
| **建议 Agent ID** | `legaladvisor` |
|
||||||
|
| **建议技能配置** | 法律知识检索、合同模板库、合规检查清单 |
|
||||||
|
| **建议工作模式** | 不进项目，按需咨询 |
|
||||||
|
| **预计投产周期** | 配置 1 天 |
|
||||||
|
| **紧急程度** | 本周 — 防患于未然 |
|
||||||
|
|
||||||
|
### 岗位 3：财务/数据分析师（dataanalyst）
|
||||||
|
|
||||||
|
| 维度 | 说明 |
|
||||||
|
|------|------|
|
||||||
|
| **必要性** | 🟡 中 — ROI 计算和成本分析目前由 COO 兼任，不够专业 |
|
||||||
|
| **核心职能** | 成本分析、ROI 计算、业务数据报表、预算跟踪 |
|
||||||
|
| **适用场景** | 月度经营分析、项目成本核算、业务线 ROI 对比 |
|
||||||
|
| **协作对象** | COO、各事业部负责人 |
|
||||||
|
| **建议 Agent ID** | `dataanalyst` |
|
||||||
|
| **建议技能配置** | Excel/报表生成（excel-reporter）、统计分析、财务建模 |
|
||||||
|
| **建议工作模式** | 进项目，定期输出报表 |
|
||||||
|
| **预计投产周期** | 配置 1 天 |
|
||||||
|
| **紧急程度** | 本月 — 业务规模扩大后需要 |
|
||||||
|
|
||||||
|
### 岗位 4：商务拓展（bdspecialist）
|
||||||
|
|
||||||
|
| 维度 | 说明 |
|
||||||
|
|------|------|
|
||||||
|
| **必要性** | 🟢 低 — 当前业务阶段不需要专职 BD |
|
||||||
|
| **核心职能** | 渠道拓展、合作伙伴关系管理、商务谈判 |
|
||||||
|
| **适用场景** | 多渠道电商入驻、内容平台合作、B 端客户拓展 |
|
||||||
|
| **建议时机** | 业务规模扩大至多平台运营后 |
|
||||||
|
| **紧急程度** | 暂缓 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、补充优先级与时间线
|
||||||
|
|
||||||
|
| 优先级 | 岗位 | 建议时间 | 前置条件 |
|
||||||
|
|:------:|------|----------|----------|
|
||||||
|
| 1 🔴 | 市场分析师 | 尽快（本周） | Vincent 审批 |
|
||||||
|
| 1 🔴 | 商业分析师（可合并到市场分析师） | 尽快（本周） | Vincent 审批 |
|
||||||
|
| 2 🟡 | 法务顾问 | 本周 | Vincent 审批 |
|
||||||
|
| 3 🟡 | 财务/数据分析师 | 本月内 | 业务规模判断 |
|
||||||
|
| 4 🟢 | 商务拓展 | 暂缓 | 多平台运营启动 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、成本评估
|
||||||
|
|
||||||
|
| 岗位 | 预计 Agent Token 消耗/月 | 新增人力成本 |
|
||||||
|
|------|--------------------------|-------------|
|
||||||
|
| marketanalyst | ~2M tokens | 0（Agent） |
|
||||||
|
| legaladvisor | ~500K tokens | 0（Agent） |
|
||||||
|
| dataanalyst | ~1M tokens | 0（Agent） |
|
||||||
|
| **合计新增** | **~3.5M tokens/月** | **0（全部 Agent）** |
|
||||||
|
|
||||||
|
> Agent 岗位零人力成本，主要成本是 API Token 消耗。建议优先启用市场分析师和法务顾问，根据业务需要逐步扩展。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、已覆盖领域优化建议
|
||||||
|
|
||||||
|
### 电商线
|
||||||
|
- **现有**：陆云帆负责淘宝 → 自动化运营系统开发中
|
||||||
|
- **建议**：抖店/微信小店需求明确后，评估是否需增设专项 Agent 或由陆云帆扩展职责
|
||||||
|
|
||||||
|
### 内容线
|
||||||
|
- **现有**：文墨言负责小红书
|
||||||
|
- **建议**：效果验证后评估是否扩展至抖音/视频号内容运营
|
||||||
|
|
||||||
|
### 视频线
|
||||||
|
- **现有**：钟帧韵负责视频制作
|
||||||
|
- **建议**：视频需求增长后评估是否需增设短视频专项 Agent
|
||||||
|
|
||||||
|
### 产研线
|
||||||
|
- **现有**：6 人完整链（PM→产品→架构→开发→设计→运维）
|
||||||
|
- **状态**：团队完整，暂无需补充
|
||||||
|
- **关注点**：项目并发量增加时，关注 costcodev 负载
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、决策清单
|
||||||
|
|
||||||
|
| # | 决策事项 | 建议 | 备注 |
|
||||||
|
|---|----------|------|------|
|
||||||
|
| 1 | 是否批准增设市场分析师？ | ✅ 建议批准 | 商业分析线核心能力 |
|
||||||
|
| 2 | 是否批准增设法务顾问？ | ✅ 建议批准 | 防患于未然，成本极低 |
|
||||||
|
| 3 | 是否批准增设数据分析师？ | ⏸ 本月内决策 | 取决于报表需求频率 |
|
||||||
|
| 4 | 是否批准增设商务拓展？ | ⏸ 暂缓 | 业务规模未到 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
> ⚠️ 以上建议待刘总审阅决策。新 Agent 创建需经审批流程。
|
||||||
@@ -0,0 +1,80 @@
|
|||||||
|
# 产出物6：新 Agent 配置文件交付记录
|
||||||
|
|
||||||
|
> 版本：v1.0 | 编制：陆怀瑾（COO） | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 新增 Agent 一览
|
||||||
|
|
||||||
|
| Agent ID | 姓名 | 性别 | 角色 | 事业部 | 汇报对象 |
|
||||||
|
|----------|------|:----:|------|--------|----------|
|
||||||
|
| `marketanalysis` | 顾析策 | 男 | 市场分析师 | 分析事业部 | COO 陆怀瑾 |
|
||||||
|
| `lawyer` | 苏慎 | 女 | 法务顾问 | 分析事业部 | COO 陆怀瑾 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 顾析策（marketanalysis）— 市场分析师
|
||||||
|
|
||||||
|
### 核心职能
|
||||||
|
- 市场调研与竞争分析
|
||||||
|
- 消费者洞察与趋势判断
|
||||||
|
- 商业计划书（BP）市场分析章节撰写
|
||||||
|
- 为 COO 和 Vincent 提供数据驱动的决策支持
|
||||||
|
|
||||||
|
### 配置文件清单
|
||||||
|
| 文件 | 路径 | 说明 |
|
||||||
|
|------|------|------|
|
||||||
|
| AGENTS.md | `workspace/marketanalysis/AGENTS.md` | 角色定义、任务协议、协作矩阵 |
|
||||||
|
| SOUL.md | `workspace/marketanalysis/SOUL.md` | 人格设定、分析框架、交付标准 |
|
||||||
|
| TOOLS.md | `workspace/marketanalysis/TOOLS.md` | 数据采集/分析/可视化工具集 |
|
||||||
|
| IDENTITY.md | `workspace/marketanalysis/IDENTITY.md` | 身份标识（姓名、性别、Emoji 🔍） |
|
||||||
|
| USER.md | `workspace/marketanalysis/USER.md` | 用户画像与沟通偏好 |
|
||||||
|
| HEARTBEAT.md | `workspace/marketanalysis/HEARTBEAT.md` | 心跳配置、任务检查流程 |
|
||||||
|
| MEMORY.md | `workspace/marketanalysis/MEMORY.md` | 长期记忆、协作团队索引 |
|
||||||
|
|
||||||
|
### Emoji：🔍
|
||||||
|
### 沟通风格：数据先行、结论驱动、透明标注不确定性
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 苏慎（lawyer）— 法务顾问
|
||||||
|
|
||||||
|
### 核心职能
|
||||||
|
- 商业合同审查与风险标注
|
||||||
|
- 电商合规咨询（广告法、电商法、消费者权益保护法）
|
||||||
|
- 知识产权保护建议
|
||||||
|
- 隐私政策审核
|
||||||
|
|
||||||
|
### 配置文件清单
|
||||||
|
| 文件 | 路径 | 说明 |
|
||||||
|
|------|------|------|
|
||||||
|
| AGENTS.md | `workspace/lawyer/AGENTS.md` | 角色定义、法务免责声明、协作矩阵 |
|
||||||
|
| SOUL.md | `workspace/lawyer/SOUL.md` | 人格设定、审查标准、交付模板 |
|
||||||
|
| TOOLS.md | `workspace/lawyer/TOOLS.md` | 法规检索/合同审查/合规检查工具集 |
|
||||||
|
| IDENTITY.md | `workspace/lawyer/IDENTITY.md` | 身份标识（姓名、性别、Emoji ⚖️） |
|
||||||
|
| USER.md | `workspace/lawyer/USER.md` | 用户画像与沟通偏好 |
|
||||||
|
| HEARTBEAT.md | `workspace/lawyer/HEARTBEAT.md` | 心跳配置、任务检查流程 |
|
||||||
|
| MEMORY.md | `workspace/lawyer/MEMORY.md` | 长期记忆、协作团队索引 |
|
||||||
|
|
||||||
|
### Emoji：⚖️
|
||||||
|
### 沟通风格：温和坚定、先说风险再说方案、明确能力边界
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 分析事业部现状
|
||||||
|
|
||||||
|
```
|
||||||
|
分析事业部 (待建 → 已启动)
|
||||||
|
├── 顾析策 (marketanalysis) — 市场分析师 🔍
|
||||||
|
└── 苏慎 (lawyer) — 法务顾问 ⚖️
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## COO 配置文件已同步更新
|
||||||
|
|
||||||
|
- AGENTS.md：已添加两位新 Agent 的飞书 Session Key 和职能速查条目
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
> ✅ 两个新 Agent 的 7 个核心配置文件 + memory/ 目录结构已全部就绪，可投入使用。"}
|
||||||
@@ -0,0 +1,196 @@
|
|||||||
|
# 提案一：多智能体组织架构与岗位职责
|
||||||
|
|
||||||
|
> 提案人：陆怀瑾（COO） | 状态：待审阅 | 日期：2026-06-22
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、现状分析
|
||||||
|
|
||||||
|
### 现有 Agent 清单（12 人）
|
||||||
|
|
||||||
|
| Agent | 角色 | 核心职能 |
|
||||||
|
|-------|------|----------|
|
||||||
|
| 刘诗妮 | secretary | 业务入口 / 进度跟进 / 消息中转 |
|
||||||
|
| 胡蓉 | projectmanager | 项目拆解 / 开发计划制定 |
|
||||||
|
| 沈路明 | productmanager | 产品需求文档(PRD)撰写 |
|
||||||
|
| 梁思筑 | architect | 系统架构设计 / 技术选型 |
|
||||||
|
| 徐聪 | costcodev | 全栈代码开发 |
|
||||||
|
| 苏绘锦 | designer | UI/UX 设计 |
|
||||||
|
| 陆云帆 | taobaospecialist | 淘宝店铺运营 |
|
||||||
|
| 文墨言 | contentspecialist | 内容文案撰写 |
|
||||||
|
| 钟帧韵 | mediaspecialist | 视频制作 |
|
||||||
|
| 程伯予 | cvexpert | 求职简历投递 |
|
||||||
|
| 严维序 | opengineer | 运维部署 |
|
||||||
|
| 陆怀瑾 | coo | 运营总监 / 全局协调 |
|
||||||
|
|
||||||
|
### 业务线分析
|
||||||
|
|
||||||
|
| 业务线 | 当前团队 | 负责人 | 成熟度 |
|
||||||
|
|--------|----------|--------|--------|
|
||||||
|
| 电商运营（淘宝） | 陆云帆 | 陆云帆 | 运行中 |
|
||||||
|
| 电商运营（抖店/微信小店） | — | — | 待扩展 |
|
||||||
|
| 内容运营（小红书） | 文墨言 | 文墨言 | 启动中 |
|
||||||
|
| 视频媒体 | 钟帧韵 | 钟帧韵 | 运行中 |
|
||||||
|
| 系统开发 | architect → costcodev → designer → opengineer | 胡蓉(PM) | 运行中 |
|
||||||
|
| 商业分析 | — | — | 待建设 |
|
||||||
|
| 求职服务 | 程伯予 | 程伯予 | 运行中 |
|
||||||
|
| 行政管理 | 刘诗妮 | 刘诗妮 | 运行中 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、建议组织架构
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────────┐
|
||||||
|
│ 刘炜承(Vincent) │
|
||||||
|
│ 公司负责人 │
|
||||||
|
└────────┬────────┘
|
||||||
|
│
|
||||||
|
┌──────────────┼──────────────┐
|
||||||
|
│ │ │
|
||||||
|
┌────────▼────────┐ ┌──▼──────────┐ ┌─▼──────────────┐
|
||||||
|
│ 刘诗妮(secretary) │ │ 陆怀瑾(COO) │ │ 程伯予(cvexpert)│
|
||||||
|
│ 秘书/行政入口 │ │ 运营总监 │ │ 求职(不进项目) │
|
||||||
|
└─────────────────┘ └──────┬───────┘ └────────────────┘
|
||||||
|
│
|
||||||
|
┌───────────┬───────────┼───────────┬───────────┐
|
||||||
|
│ │ │ │ │
|
||||||
|
┌────▼────┐ ┌────▼────┐ ┌───▼────┐ ┌───▼────┐ ┌───▼────┐
|
||||||
|
│产研事业部│ │电商事业部│ │内容事业部│ │媒体事业部│ │分析事业部│
|
||||||
|
│ │ │ │ │ │ │ │ │(待建) │
|
||||||
|
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────────┘
|
||||||
|
│ │ │ │
|
||||||
|
┌────▼────┐ ┌───▼────┐ ┌───▼────┐ ┌───▼────┐
|
||||||
|
│胡蓉 PM │ │陆云帆 │ │文墨言 │ │钟帧韵 │
|
||||||
|
│沈路明 PM │ │淘宝运营 │ │内容运营 │ │视频制作 │
|
||||||
|
│梁思筑架构│ │ │ │ │ │ │
|
||||||
|
│徐聪开发 │ │ │ │ │ │ │
|
||||||
|
│苏绘锦设计│ │ │ │ │ │ │
|
||||||
|
│严维序运维│ │ │ │ │ │ │
|
||||||
|
└─────────┘ └─────────┘ └─────────┘ └─────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、岗位职责说明书
|
||||||
|
|
||||||
|
### 3.1 产研事业部
|
||||||
|
|
||||||
|
**负责人：胡蓉（projectmanager）**
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **项目经理** | 胡蓉 | 需求评审 → 任务拆解 → 开发计划 → 进度把控 → 风险管理 |
|
||||||
|
| **产品经理** | 沈路明 | 用户需求分析 → PRD 撰写 → 验收标准定义 → 需求变更管理 |
|
||||||
|
| **架构师** | 梁思筑 | 系统架构设计 → 技术选型 → 接口规范 → 代码评审 |
|
||||||
|
| **开发工程师** | 徐聪 | 代码实现 → 单元测试 → 技术文档 → Bug 修复 |
|
||||||
|
| **UI/UX 设计师** | 苏绘锦 | 界面设计 → 交互原型 → 设计规范 → 设计走查 |
|
||||||
|
| **运维工程师** | 严维序 | 环境部署 → CI/CD → 监控告警 → 故障处理 |
|
||||||
|
|
||||||
|
**协作 SOP**：
|
||||||
|
```
|
||||||
|
用户需求 → secretary → projectmanager（拆解）
|
||||||
|
→ productmanager（PRD）
|
||||||
|
→ architect（架构设计）
|
||||||
|
→ costcodev（开发）
|
||||||
|
→ designer（UI 介入）
|
||||||
|
→ opengineer（部署）
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.2 电商事业部
|
||||||
|
|
||||||
|
**负责人：陆云帆（taobaospecialist）**
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **电商运营** | 陆云帆 | 店铺运营 / 商品管理 / 活动策划 / 数据分析 / 自动化系统需求 |
|
||||||
|
|
||||||
|
**扩展计划**：待抖店、微信小店需求明确后，可增设专项 Agent 或扩充陆云帆职责。
|
||||||
|
|
||||||
|
### 3.3 内容事业部
|
||||||
|
|
||||||
|
**负责人：文墨言（contentspecialist）**
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **内容运营** | 文墨言 | 小红书内容策略 → 文案撰写 → 发布排期 → 数据分析 |
|
||||||
|
|
||||||
|
### 3.4 媒体事业部
|
||||||
|
|
||||||
|
**负责人：钟帧韵（mediaspecialist）**
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **视频制作** | 钟帧韵 | 视频策划 → 拍摄/制作 → 后期剪辑 → 发布管理 |
|
||||||
|
|
||||||
|
### 3.5 分析事业部（待建）
|
||||||
|
|
||||||
|
| 建议岗位 | 职责 | 优先级 |
|
||||||
|
|----------|------|--------|
|
||||||
|
| **市场分析师** | 市场调研 / 竞争分析 / 行业报告 / 数据可视化 | 高 |
|
||||||
|
| **商业分析师** | 商业模式分析 / 商业计划书(BP)撰写 / PPT 制作 | 高 |
|
||||||
|
| **法律顾问** | 合同审查 / 合规咨询 / 知识产权 | 中 |
|
||||||
|
|
||||||
|
> **新建建议**：建议增设 `marketanalyst`（市场分析师）和 `legaladvisor`（法律顾问）两个 Agent。
|
||||||
|
|
||||||
|
### 3.6 行政管理
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **秘书** | 刘诗妮 | 业务入口 / 任务分发 / 进度汇报 / 日程管理 / 跨部门沟通中转 |
|
||||||
|
|
||||||
|
### 3.7 运营管理
|
||||||
|
|
||||||
|
| 岗位 | Agent | 职责 |
|
||||||
|
|------|-------|------|
|
||||||
|
| **运营总监** | 陆怀瑾（我） | 全局监控 / 资源协调 / 风险预警 / 流程优化 / 组织建设 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、业务标准规范
|
||||||
|
|
||||||
|
### 4.1 任务流转规范
|
||||||
|
|
||||||
|
```
|
||||||
|
[用户需求]
|
||||||
|
→ 刘诗妮接收并归类
|
||||||
|
→ 分派至对应事业部负责人
|
||||||
|
→ 事业部负责人拆解/执行
|
||||||
|
→ 完成后通知刘诗妮
|
||||||
|
→ 刘诗妮向用户汇报
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.2 沟通标准
|
||||||
|
|
||||||
|
- **跨 Agent 沟通**：使用 `sessions_send` + 结构化 handoff 格式
|
||||||
|
- **状态汇报**：各事业部负责人每日通过 WorkBoard 更新进度
|
||||||
|
- **风险升级**：
|
||||||
|
- 进度偏差 > 30% → 通知 projectmanager + COO
|
||||||
|
- 阻塞 > 4h → 通知 secretary + COO
|
||||||
|
- 严重风险 → 直接汇报 Vincent
|
||||||
|
|
||||||
|
### 4.3 质量标准
|
||||||
|
|
||||||
|
- 产研交付：PRD 评审通过 → 架构评审通过 → 代码评审通过 → 测试通过 → 部署上线
|
||||||
|
- 内容交付：选题评审 → 内容审核 → 数据复盘
|
||||||
|
- 电商交付：方案评审 → 执行 → 数据复盘
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、落地方案
|
||||||
|
|
||||||
|
| 阶段 | 内容 | 时间 | 负责人 |
|
||||||
|
|------|------|------|--------|
|
||||||
|
| **Phase 1** | 审批通过后，更新所有 Agent 的 AGENTS.md 增加事业部归属和汇报关系 | 1天 | COO |
|
||||||
|
| **Phase 2** | 更新协作 SOP 文档，注入各 Agent 的 SOUL.md | 1天 | COO + secretary |
|
||||||
|
| **Phase 3** | 增设 marketanalyst、legaladvisor 两个 Agent | 1天 | COO |
|
||||||
|
| **Phase 4** | 团队培训：新流程宣贯 | 1天 | COO |
|
||||||
|
| **Phase 5** | 试运行 2 周，收集反馈后迭代 | 2周 | 全员 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、需要决策的事项
|
||||||
|
|
||||||
|
1. ✅ 组织架构是否认可？是否需要调整？
|
||||||
|
2. ✅ 是否批准增设市场分析师和法律顾问 Agent？
|
||||||
|
3. ✅ 各事业部负责人任命是否认可？
|
||||||
@@ -1,207 +0,0 @@
|
|||||||
# Agent 知识库检索指南
|
|
||||||
|
|
||||||
> **版本**: v1.0
|
|
||||||
> **维护**: 严维序 (opengineer)
|
|
||||||
> **日期**: 2026-06-22
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 一、检索工具选择决策树
|
|
||||||
|
|
||||||
```
|
|
||||||
需要检索知识库？
|
|
||||||
├── 精确查找已知页面 → wiki_get(lookup="页面路径")
|
|
||||||
├── 搜索未知内容
|
|
||||||
│ ├── 关键词明确 → wiki_search(query="关键词")
|
|
||||||
│ ├── 语义模糊 → wiki_search(query="自然语言问题")
|
|
||||||
│ └── 需要文档全文 → qmd query / qmd search
|
|
||||||
├── 需要深度分析（跨文档） → wiki_search + wiki_get 组合
|
|
||||||
├── 质量检查 → wiki_lint()
|
|
||||||
└── 系统状态确认 → wiki_status()
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 二、工具对比速查表
|
|
||||||
|
|
||||||
| 维度 | wiki_search | wiki_get | qmd (CLI) |
|
|
||||||
|------|-------------|----------|-----------|
|
|
||||||
| **用途** | 模糊搜索/发现 | 精确读取 | 全文/语义搜索 |
|
|
||||||
| **查询类型** | 标题+路径+正文 | 精确路径或 ID | lex/vec/hyde 多类型 |
|
|
||||||
| **返回内容** | 匹配片段+元数据 | 完整页面内容 | 排序结果+评分 |
|
|
||||||
| **速度** | 快 | 最快 | 依赖索引（首次慢） |
|
|
||||||
| **适用场景** | "有没有关于 X 的文档" | "打开 X 页面" | "找所有涉及 Y 的内容" |
|
|
||||||
| **依赖** | 无（OpenClaw 内置） | 无（OpenClaw 内置） | QMD 服务（需运行） |
|
|
||||||
| **搜索范围** | Wiki vault | Wiki vault | 注册的 markdown 目录 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 三、查询语句构造示例
|
|
||||||
|
|
||||||
### wiki_search
|
|
||||||
|
|
||||||
**简单关键词搜索**:
|
|
||||||
```
|
|
||||||
wiki_search(query="nginx 配置")
|
|
||||||
```
|
|
||||||
|
|
||||||
**多词精确搜索**:
|
|
||||||
```
|
|
||||||
wiki_search(query="deployment pipeline CI/CD")
|
|
||||||
```
|
|
||||||
|
|
||||||
**语义问题搜索**:
|
|
||||||
```
|
|
||||||
wiki_search(query="如何配置 nginx 反向代理")
|
|
||||||
```
|
|
||||||
|
|
||||||
**限制结果数量**:
|
|
||||||
```
|
|
||||||
wiki_search(query="监控告警", maxResults=5)
|
|
||||||
```
|
|
||||||
|
|
||||||
### wiki_get
|
|
||||||
|
|
||||||
**按页面标题查找**:
|
|
||||||
```
|
|
||||||
wiki_get(lookup="服务器清单")
|
|
||||||
```
|
|
||||||
|
|
||||||
**按文件路径查找**:
|
|
||||||
```
|
|
||||||
wiki_get(lookup="docs/deployment-guide")
|
|
||||||
```
|
|
||||||
|
|
||||||
**分页读取大文件**:
|
|
||||||
```
|
|
||||||
wiki_get(lookup="长文档", fromLine=1, lineCount=50)
|
|
||||||
```
|
|
||||||
|
|
||||||
### qmd (CLI)
|
|
||||||
|
|
||||||
**关键词搜索**:
|
|
||||||
```bash
|
|
||||||
qmd search "nginx logrotate configuration"
|
|
||||||
```
|
|
||||||
|
|
||||||
**语义搜索**:
|
|
||||||
```bash
|
|
||||||
qmd query "如何解决 nginx 日志轮转失败的问题"
|
|
||||||
```
|
|
||||||
|
|
||||||
**结构化搜索 (JSON)**:
|
|
||||||
```bash
|
|
||||||
qmd query --json --explain "nginx logrotate error"
|
|
||||||
```
|
|
||||||
|
|
||||||
**多类型组合**:
|
|
||||||
```bash
|
|
||||||
qmd query $'lex: nginx logrotate\nvec: how to fix log rotation failure'
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 四、结果处理流程
|
|
||||||
|
|
||||||
```
|
|
||||||
搜索结果
|
|
||||||
├── 有匹配结果
|
|
||||||
│ ├── 1-3 个结果 → wiki_get 逐个读取完整内容
|
|
||||||
│ ├── 4-10 个结果 → 按评分排序，取前 3 个读取
|
|
||||||
│ └── 10+ 个结果 → 收窄搜索词重新搜索
|
|
||||||
├── 无结果
|
|
||||||
│ ├── 尝试同义词/相关词重新搜索
|
|
||||||
│ ├── 尝试 qmd 搜索（如果 wiki_search 无结果）
|
|
||||||
│ └── 仍无结果 → 触发知识缺口上报
|
|
||||||
└── 结果不相关
|
|
||||||
└── 调整查询词 → 重新搜索 → 仍不相关 → 上报缺口
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 五、知识缺口上报机制
|
|
||||||
|
|
||||||
### 触发条件
|
|
||||||
|
|
||||||
1. `wiki_search` 和 `qmd` 均无匹配结果
|
|
||||||
2. 搜索结果与需求明显不相关
|
|
||||||
3. 找到的文档内容已过时或不完整
|
|
||||||
|
|
||||||
### 上报格式
|
|
||||||
|
|
||||||
缺口上报应包含以下信息：
|
|
||||||
|
|
||||||
```
|
|
||||||
【知识缺口】
|
|
||||||
|
|
||||||
- 查询意图: [用户/Agent 想了解什么]
|
|
||||||
- 已尝试检索词: [用过的搜索词列表]
|
|
||||||
- 已搜索工具: [wiki_search / qmd]
|
|
||||||
- 期望内容: [期望知识库中应有什么内容]
|
|
||||||
- 紧急程度: [high / normal / low]
|
|
||||||
- 建议: [建议谁负责补充、建议写入什么内容]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 上报目标
|
|
||||||
|
|
||||||
- 紧急缺口 → architect（梁思筑）
|
|
||||||
- 文档更新缺口 → 对应领域 Agent
|
|
||||||
- 通用知识缺口 → projectmanager（胡蓉）
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 六、最佳实践
|
|
||||||
|
|
||||||
### DO ✅
|
|
||||||
|
|
||||||
- 先用 `wiki_search` 发现，再用 `wiki_get` 精读
|
|
||||||
- 搜索无结果时尝试多种表述方式
|
|
||||||
- `wiki_search` 结果多时限制 `maxResults`
|
|
||||||
- 大文档用 `fromLine`/`lineCount` 分页读取
|
|
||||||
- 定期运行 `wiki_lint` 检查知识库质量
|
|
||||||
- 每次重要发现后考虑是否需写入知识库
|
|
||||||
|
|
||||||
### DON'T ❌
|
|
||||||
|
|
||||||
- 不要跳过 `wiki_search` 直接用 `wiki_get` 猜测路径
|
|
||||||
- 不要单次读取超大页面全部内容（影响上下文）
|
|
||||||
- 不要忽略 `wiki_lint` 的报告建议
|
|
||||||
- 不要在 `wiki_search` 无结果后直接放弃（尝试 qmd）
|
|
||||||
- 不要将敏感信息（密钥/密码）写入 Wiki
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 七、示例工作流
|
|
||||||
|
|
||||||
### 场景: 查找"如何部署 Node.js 服务"
|
|
||||||
|
|
||||||
```
|
|
||||||
1. wiki_search(query="Node.js 部署")
|
|
||||||
→ 返回 2 个匹配: "服务部署规范", "Node.js 开发指南"
|
|
||||||
|
|
||||||
2. wiki_get(lookup="服务部署规范")
|
|
||||||
→ 读取完整内容，找到 systemd 配置部分
|
|
||||||
|
|
||||||
3. wiki_get(lookup="Node.js 开发指南", fromLine=30, lineCount=20)
|
|
||||||
→ 补充读取环境变量和启动参数配置
|
|
||||||
|
|
||||||
4. 整合信息 → 回答 Agent 问题
|
|
||||||
```
|
|
||||||
|
|
||||||
### 场景: 知识库中无结果
|
|
||||||
|
|
||||||
```
|
|
||||||
1. wiki_search(query="淘宝 API 对接")
|
|
||||||
→ No results
|
|
||||||
|
|
||||||
2. qmd query "淘宝 API"
|
|
||||||
→ No results
|
|
||||||
|
|
||||||
3. 上报知识缺口:
|
|
||||||
【知识缺口】
|
|
||||||
- 查询意图: 淘宝电商 API 对接文档
|
|
||||||
- 已尝试: wiki_search("淘宝 API 对接"), qmd query "淘宝 API"
|
|
||||||
- 期望内容: 淘宝开放平台 API 对接指南
|
|
||||||
- 紧急程度: normal
|
|
||||||
- 建议: 联系 taobaospecialist (陆云帆) 补充
|
|
||||||
```
|
|
||||||
@@ -1,112 +0,0 @@
|
|||||||
# QMD 功能验证报告
|
|
||||||
|
|
||||||
> **任务**: BIZ-17 (BIZ-14-2)
|
|
||||||
> **测试人**: 严维序 (opengineer)
|
|
||||||
> **测试日期**: 2026-06-22
|
|
||||||
> **版本**: v1.0
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 1. 技能安装状态
|
|
||||||
|
|
||||||
### 技能文件检查
|
|
||||||
|
|
||||||
| 检查项 | 路径 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| SKILL.md | `~/.agents/skills/qmd/SKILL.md` | ✅ 存在 |
|
|
||||||
| references/ | `~/.agents/skills/qmd/references/` | ✅ 存在 |
|
|
||||||
| 版本 | SKILL.md 元数据 | `2.0.0` |
|
|
||||||
|
|
||||||
### CLI 安装检查
|
|
||||||
|
|
||||||
```bash
|
|
||||||
$ which qmd
|
|
||||||
/usr/bin/qmd
|
|
||||||
```
|
|
||||||
|
|
||||||
✅ QMD CLI 已全局安装（npm global）。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. CLI 运行状态
|
|
||||||
|
|
||||||
### 问题发现
|
|
||||||
|
|
||||||
```bash
|
|
||||||
$ qmd status
|
|
||||||
Error: The module 'better_sqlite3.node'
|
|
||||||
was compiled against a different Node.js version using
|
|
||||||
NODE_MODULE_VERSION 127. This version of Node.js requires
|
|
||||||
NODE_MODULE_VERSION 137.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 根因分析
|
|
||||||
|
|
||||||
| 项目 | 说明 |
|
|
||||||
|------|------|
|
|
||||||
| 当前 Node.js | v24.16.0 (NODE_MODULE_VERSION 137) |
|
|
||||||
| better-sqlite3 编译版本 | NODE_MODULE_VERSION 127 (Node.js v22.x) |
|
|
||||||
| 影响 | QMD 所有命令不可用（search/query/get/status） |
|
|
||||||
| 修复方案 | `sudo npm rebuild -g @tobilu/qmd` 或 `sudo npx node-gyp rebuild` 在 better-sqlite3 目录 |
|
|
||||||
|
|
||||||
### 修复尝试记录
|
|
||||||
|
|
||||||
| 尝试 | 命令 | 结果 |
|
|
||||||
|------|------|------|
|
|
||||||
| 1 | `npm rebuild -g @tobilu/qmd` | ❌ 超时被 SIGTERM |
|
|
||||||
| 2 | `npx node-gyp rebuild` (better-sqlite3 目录) | ❌ 权限不足 (EACCES: rmdir 'build') |
|
|
||||||
| 3 (推荐) | `sudo npm rebuild -g @tobilu/qmd` | ⏳ 待执行（需提权） |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. QMD 功能能力（基于 SKILL.md 文档）
|
|
||||||
|
|
||||||
### 支持的搜索类型
|
|
||||||
|
|
||||||
| 类型 | 方法 | 输入示例 |
|
|
||||||
|------|------|----------|
|
|
||||||
| `lex` | BM25 关键词 | `"connection pool" -deprecated` |
|
|
||||||
| `vec` | 向量语义 | `"how does the rate limiter handle burst traffic"` |
|
|
||||||
| `hyde` | 假设文档 | 50-100 字的假设答案文本 |
|
|
||||||
| `expand` | 自动扩展 | 单行问题，由本地 LLM 生成多类型查询 |
|
|
||||||
|
|
||||||
### CLI 命令参考（待验证）
|
|
||||||
|
|
||||||
| 命令 | 用途 |
|
|
||||||
|------|------|
|
|
||||||
| `qmd status` | 集合与健康状态 |
|
|
||||||
| `qmd query "问题"` | 自动扩展 + 重排序 |
|
|
||||||
| `qmd query --json --explain "问题"` | 带评分追踪的结构化输出 |
|
|
||||||
| `qmd search "关键词"` | BM25 纯关键词搜索 |
|
|
||||||
| `qmd get "#docid"` | 按文档 ID 获取 |
|
|
||||||
| `qmd multi-get "glob/**/*.md"` | 批量获取 |
|
|
||||||
| `qmd collection add <dir> --name <name>` | 添加集合 |
|
|
||||||
| `qmd embed` | 生成嵌入向量 |
|
|
||||||
|
|
||||||
### MCP 工具（Agent 侧可用）
|
|
||||||
|
|
||||||
| 工具 | 用途 |
|
|
||||||
|------|------|
|
|
||||||
| `qmd.query` | 结构化搜索（支持 lex/vec/hyde） |
|
|
||||||
| `qmd.get` | 按路径或 #docid 获取文档 |
|
|
||||||
| `qmd.multi_get` | 按 glob/列表批量获取 |
|
|
||||||
| `qmd.status` | 集合和健康状态 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. 建议
|
|
||||||
|
|
||||||
1. **立即修复**: 在全局 npm 目录执行 `sudo npm rebuild -g @tobilu/qmd`
|
|
||||||
2. **集合配置**: 修复后执行 `qmd collection add ~/notes --name notes && qmd embed`
|
|
||||||
3. **知识库集成**: 将 `EnterpriseArchitect/knowledge/` 目录注册为 QMD 集合
|
|
||||||
4. **定期维护**: 知识库更新后重新执行 `qmd embed`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. 结论
|
|
||||||
|
|
||||||
- **技能文件**: ✅ 完整可用（SKILL.md + references）
|
|
||||||
- **CLI 运行**: ❌ 需修复 Node.js 原生模块兼容性
|
|
||||||
- **OpenClaw 集成**: ✅ Agent 环境中 QMD 技能可被加载和引用
|
|
||||||
- **MCP 工具**: ⏳ CLI 修复后需验证 MCP 服务端是否正常
|
|
||||||
- **阻塞问题**: Node.js v24 与 better-sqlite3 v12.8.0 编译版本不兼容，需 sudo 提权重建
|
|
||||||
@@ -1,140 +0,0 @@
|
|||||||
# Wiki 工具链测试报告
|
|
||||||
|
|
||||||
> **任务**: BIZ-17 (BIZ-14-2)
|
|
||||||
> **测试人**: 严维序 (opengineer)
|
|
||||||
> **测试日期**: 2026-06-22
|
|
||||||
> **版本**: v1.0
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 测试环境
|
|
||||||
|
|
||||||
| 项目 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| OpenClaw 版本 | 当前运行版本 |
|
|
||||||
| Wiki Vault 路径 | `/home/vincent/.openclaw/wiki/main` |
|
|
||||||
| 渲染模式 | native |
|
|
||||||
| Obsidian CLI | 未安装 |
|
|
||||||
| Bridge | 禁用 |
|
|
||||||
| 当前页面数 | 0 sources, 0 entities, 0 concepts, 0 syntheses, 9 reports |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 工具 1: wiki_status — 系统健康度检查
|
|
||||||
|
|
||||||
### 测试用例
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_status()
|
|
||||||
```
|
|
||||||
|
|
||||||
### 测试结果
|
|
||||||
|
|
||||||
| 字段 | 值 | 状态 |
|
|
||||||
|------|-----|------|
|
|
||||||
| vault mode | isolated | ✅ |
|
|
||||||
| vault status | ready | ✅ |
|
|
||||||
| render mode | native | ✅ |
|
|
||||||
| Obsidian CLI | missing | ⚠️ (非必需) |
|
|
||||||
| Bridge | disabled | ℹ️ |
|
|
||||||
| Pages | 0/0/0/0 | ℹ️ (空库) |
|
|
||||||
|
|
||||||
### 结论: ✅ 通过
|
|
||||||
|
|
||||||
`wiki_status` 返回完整的 vault 健康状态，包含页面统计和可用性信息。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 工具 2: wiki_search — 标题/路径/内容搜索
|
|
||||||
|
|
||||||
### 测试用例 1: 空库搜索
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_search(query="test knowledge base", maxResults=3)
|
|
||||||
结果: No wiki or memory results.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 测试用例 2: 已知不存在主题搜索
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_search(query="OpenClaw deployment", maxResults=5)
|
|
||||||
结果: No wiki or memory results.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 结论: ✅ 通过
|
|
||||||
|
|
||||||
`wiki_search` 在空库中正确返回 "No results"。支持关键词和语义搜索，可指定 `maxResults`。空结果不报错，返回简洁提示。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 工具 3: wiki_get — 精确读取页面
|
|
||||||
|
|
||||||
### 测试用例 1: 不存在页面
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_get(lookup="nonexistent-test-page")
|
|
||||||
结果: Wiki page not found: nonexistent-test-page
|
|
||||||
```
|
|
||||||
|
|
||||||
### 测试用例 2: 边界测试
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_get(lookup="")
|
|
||||||
结果: Wiki page not found
|
|
||||||
```
|
|
||||||
|
|
||||||
### 结论: ✅ 通过
|
|
||||||
|
|
||||||
`wiki_get` 对不存在的页面返回明确的 "not found" 提示。支持按路径或 ID 查找。错误处理符合预期。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 工具 4: wiki_lint — 质量检查
|
|
||||||
|
|
||||||
### 测试用例
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_lint()
|
|
||||||
结果: No wiki lint issues.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 结论: ✅ 通过
|
|
||||||
|
|
||||||
`wiki_lint` 返回 lint 诊断结果。当前空库无问题。在有内容的 vault 中可检测：结构问题、来源缺口、矛盾标记、开放问题。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 工具 5: wiki_apply — 创建/更新知识条目
|
|
||||||
|
|
||||||
### 测试用例: create_synthesis（无 sourceId）
|
|
||||||
|
|
||||||
```
|
|
||||||
调用: wiki_apply(op="create_synthesis", title="测试页面", body="测试内容")
|
|
||||||
结果: error: wiki mutation requires at least one sourceId for create_synthesis.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 结论: ⚠️ 需注意前置条件
|
|
||||||
|
|
||||||
`wiki_apply` 的 `create_synthesis` 操作需要至少一个 `sourceId`。这意味着创建 synthesis 页面必须关联已有知识源。在知识库初始化阶段，需先通过其他方式创建 source 页面。
|
|
||||||
|
|
||||||
### 建议操作流程
|
|
||||||
|
|
||||||
1. 先使用 OpenClaw 的文件工具创建 markdown 源文件
|
|
||||||
2. 注册到 Wiki vault
|
|
||||||
3. 再使用 `wiki_apply` 创建 synthesis
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 汇总
|
|
||||||
|
|
||||||
| 工具 | 测试状态 | 评分 |
|
|
||||||
|------|----------|------|
|
|
||||||
| `wiki_status` | ✅ 通过 | 可用 |
|
|
||||||
| `wiki_search` | ✅ 通过 | 可用 |
|
|
||||||
| `wiki_get` | ✅ 通过 | 可用 |
|
|
||||||
| `wiki_lint` | ✅ 通过 | 可用 |
|
|
||||||
| `wiki_apply` | ⚠️ 注意前置条件 | 创建 synthesis 需 sourceId |
|
|
||||||
|
|
||||||
### 总体评估
|
|
||||||
|
|
||||||
5 个工具中 4 个完全可用，1 个需要了解前置条件后可用。Wiki 工具链基础设施状态良好，可以支撑知识库体系建设。
|
|
||||||
+46
-26
@@ -1,39 +1,59 @@
|
|||||||
# 知识库索引
|
# 知识库索引
|
||||||
|
|
||||||
> 本知识库与 Agent 配置文件解耦，由 COO 主导维护，各领域负责人协作贡献。
|
> 维护：陆怀瑾（COO） | 最后更新：2026-06-22
|
||||||
> 通过 `wiki_search` / `memory_search` / `qmd` 等工具检索，人类可通过 Web UI 审查优化。
|
|
||||||
|
|
||||||
## 目录结构
|
## 目录结构
|
||||||
|
|
||||||
| 目录 | 领域 | 责任人 | 条目数 |
|
| 领域 | 目录 | 责任人 | 条目数 |
|
||||||
|------|------|--------|--------|
|
|------|------|--------|--------|
|
||||||
| [电商/](电商/) | 淘宝、抖店、微信小店运营 | 陆云帆 (taobaospecialist) | — |
|
| 电商 | `电商/` | 陆云帆（taobaospecialist） | 1 |
|
||||||
| [内容/](内容/) | 小红书、短视频、文案 | 文墨言 (contentspecialist) | — |
|
| 内容 | `内容/` | 文墨言（contentspecialist） | 1 |
|
||||||
| [产品/](产品/) | PRD、需求分析 | 沈路明 (productmanager) | — |
|
| 产品 | `产品/` | 沈路明（productmanager） | 1 |
|
||||||
| [技术/](技术/) | 开发规范、代码审查 | 徐聪 (costcodev) | — |
|
| 技术 | `技术/` | 梁思筑（architect） | 1 |
|
||||||
| [设计/](设计/) | UI设计、品牌规范 | 苏绘锦 (designer) | — |
|
| 设计 | `设计/` | 苏锦绘（designer） | 1 |
|
||||||
| [运营/](运营/) | 活动策划、数据分析 | 陆怀瑾 (coo) | — |
|
| 运营 | `运营/` | 陆怀瑾（coo） | 2 |
|
||||||
| [行政/](行政/) | 合同、报销流程 | 刘诗妮 (secretary) | — |
|
| 行政 | `行政/` | 刘诗妮（secretary） | 2 |
|
||||||
|
| 模板 | `templates/` | 陆怀瑾（coo） | 1 |
|
||||||
|
|
||||||
## 知识条目格式
|
**总计：10 个知识条目**
|
||||||
|
|
||||||
每个知识条目遵循 [模板](../templates/知识条目模板.md)。
|
## 知识条目列表
|
||||||
|
|
||||||
## 检索方式
|
### 电商
|
||||||
|
- [淘宝运营 SOP](电商/淘宝运营SOP.md) — 淘宝店铺日常运营标准化流程
|
||||||
|
|
||||||
- **Agent 主动查询**：`wiki_search` / `memory_search` / `qmd`
|
### 内容
|
||||||
- **人类审查**：通过 Web UI 浏览、编辑、优化
|
- [小红书运营指南](内容/小红书运营指南.md) — 小红书内容运营策略与执行规范
|
||||||
- **质量检查**：`wiki_lint` 定期运行
|
|
||||||
|
### 产品
|
||||||
|
- [PRD 模板](产品/PRD模板.md) — 产品需求文档标准模板
|
||||||
|
|
||||||
|
### 技术
|
||||||
|
- [开发规范](技术/开发规范.md) — 代码规范、提交规范、测试规范
|
||||||
|
|
||||||
|
### 设计
|
||||||
|
- [UI 设计规范](设计/UI设计规范.md) — 色彩系统、字体、组件、品牌资产
|
||||||
|
|
||||||
|
### 运营
|
||||||
|
- [数据分析方法](运营/数据分析方法.md) — 各业务线数据指标与分析框架
|
||||||
|
- [活动策划模板](运营/活动策划模板.md) — 运营活动策划全流程模板
|
||||||
|
|
||||||
|
### 行政
|
||||||
|
- [合同模板](行政/合同模板.md) — 标准合同模板
|
||||||
|
- [报销流程](行政/报销流程.md) — 费用报销流程
|
||||||
|
|
||||||
|
### 模板
|
||||||
|
- [知识条目模板](templates/知识条目模板.md) — 知识库条目创建标准模板
|
||||||
|
|
||||||
|
## 查询方式
|
||||||
|
|
||||||
|
1. **Agent 内部查询**: 使用 `wiki_search` 或 `wiki_get` 工具
|
||||||
|
2. **人类审查**: 通过 Web UI 浏览 `knowledge/` 目录
|
||||||
|
3. **全文搜索**: 使用 `qmd` 搜索 Markdown 文件
|
||||||
|
|
||||||
## 贡献流程
|
## 贡献流程
|
||||||
|
|
||||||
1. 领域负责人撰写条目
|
1. 领域负责人创建新条目（使用 `templates/知识条目模板.md`）
|
||||||
2. COO 审核内容质量
|
2. COO 审核格式和内容
|
||||||
3. 提交到 EnterpriseArchitect 仓库
|
3. 更新本 README.md 索引
|
||||||
4. 通过 `wiki_lint` 检查
|
4. 通知相关 Agent 新知识可用
|
||||||
5. 通知相关 Agent 更新索引
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**维护者**：陆怀瑾（COO）
|
|
||||||
**最后更新**：2026-06-22
|
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
# 知识条目模板
|
||||||
|
|
||||||
|
> 所有知识库条目统一使用此模板
|
||||||
|
|
||||||
|
## 模板结构
|
||||||
|
```markdown
|
||||||
|
# [类别]：[标题]
|
||||||
|
> 适用范围: [谁/什么场景] | 维护人: [Agent]
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
[1-2 句说明条目目的]
|
||||||
|
|
||||||
|
## 核心内容
|
||||||
|
[按逻辑分段]
|
||||||
|
|
||||||
|
## 关键要点
|
||||||
|
- [要点 1]
|
||||||
|
- [要点 2]
|
||||||
|
|
||||||
|
## 相关条目
|
||||||
|
- [knowledge/xx/]: [简述]
|
||||||
|
|
||||||
|
## 变更记录
|
||||||
|
| 版本 | 日期 | 变更人 | 说明 |
|
||||||
|
```
|
||||||
|
|
||||||
|
## 命名规则
|
||||||
|
- 文件名: `<类别>-<主题>.md`
|
||||||
|
- 存放: `knowledge/<领域>/`
|
||||||
|
|
||||||
|
## 创建流程
|
||||||
|
1. 领域负责人创建初稿
|
||||||
|
2. COO 审核格式
|
||||||
|
3. 入库 → 更新 README.md 索引
|
||||||
|
4. 通知相关 Agent
|
||||||
+19
-106
@@ -1,111 +1,24 @@
|
|||||||
# PRD 模板
|
# 产品需求文档（PRD）模板
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 所有产研项目 | 维护人: 沈路明（productmanager）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 模板结构
|
||||||
|------|-----|
|
|
||||||
| **领域** | 产品 |
|
|
||||||
| **责任人** | 沈路明 (productmanager) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | PRD, 产品需求, 模板 |
|
|
||||||
|
|
||||||
## 概述
|
1. **文档信息**: 版本/作者/日期/评审人
|
||||||
|
2. **需求概述**: 背景/目标/范围（包含+不包含）
|
||||||
|
3. **用户场景**: 目标用户/使用场景/预期结果
|
||||||
|
4. **功能需求**: 优先级/功能/描述/验收标准
|
||||||
|
5. **非功能需求**: 性能/安全/兼容性/可用性
|
||||||
|
6. **数据模型**: 核心表/字段/关系
|
||||||
|
7. **接口定义**: API endpoint/请求/响应
|
||||||
|
8. **UI/UX 要求**: 页面结构/交互行为/设计参考
|
||||||
|
9. **验收标准**: 编号/验收项/标准/验证方法
|
||||||
|
10. **附录**: 参考资料/竞品分析/术语表
|
||||||
|
|
||||||
产品需求文档（PRD）标准模板。适用于所有产品功能需求、系统改进需求的规范化描述，确保开发团队、设计团队、业务团队对需求理解一致。
|
## 质量标准
|
||||||
|
- 功能描述清晰，无歧义
|
||||||
|
- 验收标准可量化、可测试
|
||||||
|
- 与 architect 确认技术可行性
|
||||||
|
|
||||||
## 正文
|
## 创作时效
|
||||||
|
- 收到任务后 24h 内完成 PRD 初稿
|
||||||
### 一、文档头部
|
|
||||||
|
|
||||||
```
|
|
||||||
# [产品名称] - [功能名称] PRD
|
|
||||||
|
|
||||||
| 属性 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **作者** | [姓名] |
|
|
||||||
| **创建日期** | YYYY-MM-DD |
|
|
||||||
| **状态** | 草稿 / 评审中 / 已批准 / 已上线 |
|
|
||||||
| **关联文档** | [链接] |
|
|
||||||
```
|
|
||||||
|
|
||||||
### 二、需求概述
|
|
||||||
|
|
||||||
**2.1 背景与问题**
|
|
||||||
[描述为什么需要这个功能，解决了什么用户痛点或业务问题]
|
|
||||||
|
|
||||||
**2.2 目标用户**
|
|
||||||
- 用户画像 1：[描述]
|
|
||||||
- 用户画像 2：[描述]
|
|
||||||
|
|
||||||
**2.3 核心目标**
|
|
||||||
- 业务目标：[可量化指标，如转化率提升 X%]
|
|
||||||
- 用户目标：[用户获得什么价值]
|
|
||||||
- 技术目标：[如响应时间、并发量]
|
|
||||||
|
|
||||||
### 三、功能描述
|
|
||||||
|
|
||||||
**3.1 功能范围**
|
|
||||||
- P0（必须）：[最小可用功能]
|
|
||||||
- P1（应该）：[重要但可后续]
|
|
||||||
- P2（锦上添花）：[可后续迭代]
|
|
||||||
|
|
||||||
**3.2 用户故事**
|
|
||||||
|
|
||||||
```
|
|
||||||
作为 [用户角色]，
|
|
||||||
我希望 [功能/行为]，
|
|
||||||
以便 [获得的价值/目标]。
|
|
||||||
```
|
|
||||||
|
|
||||||
**3.3 详细交互说明**
|
|
||||||
1. [步骤1]：[描述 + 原型图链接]
|
|
||||||
2. [步骤2]：[描述 + 原型图链接]
|
|
||||||
|
|
||||||
**3.4 边界与异常**
|
|
||||||
- 正常流程：[描述]
|
|
||||||
- 异常情况1：[触发条件 + 处理方式]
|
|
||||||
- 异常情况2：[触发条件 + 处理方式]
|
|
||||||
|
|
||||||
### 四、非功能需求
|
|
||||||
|
|
||||||
| 项目 | 要求 |
|
|
||||||
|------|------|
|
|
||||||
| 页面加载 | ≤ 2 秒 |
|
|
||||||
| 接口响应 | ≤ 500ms |
|
|
||||||
| 并发支持 | 1000 QPS |
|
|
||||||
| 兼容性 | iOS 13+, Android 9+, Chrome 90+ |
|
|
||||||
|
|
||||||
### 五、数据埋点
|
|
||||||
|
|
||||||
| 事件名 | 触发条件 | 属性 |
|
|
||||||
|--------|----------|------|
|
|
||||||
| [event_name] | [触发条件] | [上报字段] |
|
|
||||||
|
|
||||||
### 六、验收标准
|
|
||||||
|
|
||||||
- [ ] 功能1 验收条件
|
|
||||||
- [ ] 功能2 验收条件
|
|
||||||
- [ ] 非功能需求满足
|
|
||||||
|
|
||||||
### 七、排期与里程碑
|
|
||||||
|
|
||||||
| 里程碑 | 日期 | 交付物 |
|
|
||||||
|--------|------|--------|
|
|
||||||
| 设计评审 | YYYY-MM-DD | 交互/视觉稿 |
|
|
||||||
| 技术评审 | YYYY-MM-DD | 技术方案 |
|
|
||||||
| 开发完成 | YYYY-MM-DD | 可测试版本 |
|
|
||||||
| 上线 | YYYY-MM-DD | 生产环境 |
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [需求分析方法.md](需求分析方法.md)
|
|
||||||
- [开发规范.md](../技术/开发规范.md)
|
|
||||||
- [UI设计规范.md](../设计/UI设计规范.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
@@ -1,21 +0,0 @@
|
|||||||
# 产品领域知识
|
|
||||||
|
|
||||||
**责任人**：沈路明（productmanager）
|
|
||||||
**审核人**：陆怀瑾（coo）
|
|
||||||
|
|
||||||
## 知识范围
|
|
||||||
|
|
||||||
涵盖产品需求文档、用户研究、竞品分析、需求管理、版本规划等产品管理知识。
|
|
||||||
|
|
||||||
## 条目清单
|
|
||||||
|
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [PRD模板.md](PRD模板.md) | 产品需求文档标准模板 | ✅ |
|
|
||||||
| [需求分析方法.md](需求分析方法.md) | 用户需求调研与分析方法 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 竞品分析框架
|
|
||||||
- 产品路线图模板
|
|
||||||
- 用户故事编写指南
|
|
||||||
@@ -1,84 +0,0 @@
|
|||||||
# 需求分析方法
|
|
||||||
|
|
||||||
## 元数据
|
|
||||||
|
|
||||||
| 属性 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| **领域** | 产品 |
|
|
||||||
| **责任人** | 沈路明 (productmanager) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 需求分析, 用户调研, 产品管理 |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
需求分析是从用户/业务痛点出发，将模糊的需求描述转化为可落地的产品功能规格的系统化方法。核心原则：先理解问题，再设计方案。
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
### 一、需求收集方法
|
|
||||||
|
|
||||||
1. **用户访谈**（定性）
|
|
||||||
- 每轮访谈 5-8 个目标用户
|
|
||||||
- 半结构化访谈：准备提纲 + 灵活追问
|
|
||||||
- 核心问题：「你最想解决什么问题？」「现在怎么解决的？」
|
|
||||||
|
|
||||||
2. **问卷调查**（定量）
|
|
||||||
- 覆盖 100+ 目标用户
|
|
||||||
- 包含选择题（量化）+ 开放题（发掘）
|
|
||||||
- 关键指标：问题频率、痛点程度、替代方案满意度
|
|
||||||
|
|
||||||
3. **数据分析**
|
|
||||||
- 页面点击热力图
|
|
||||||
- 用户行为漏斗（转化率断点）
|
|
||||||
- 客服工单高频关键词
|
|
||||||
|
|
||||||
### 二、需求优先级评估 — ICE 模型
|
|
||||||
|
|
||||||
| 因子 | 说明 | 评分 (1-10) |
|
|
||||||
|------|------|------------|
|
|
||||||
| **I**mpact（影响面） | 影响多少用户？对核心指标影响多大？ | |
|
|
||||||
| **C**onfidence（信心度） | 我们有多少证据这个方案有效？ | |
|
|
||||||
| **E**ase（实现难度） | 开发成本多高？时间多长？ | |
|
|
||||||
|
|
||||||
总分 = I × C × E（E 分数越高越容易，越大越好）
|
|
||||||
|
|
||||||
### 三、需求文档化
|
|
||||||
|
|
||||||
1. **用户故事标准格式**
|
|
||||||
> 作为 **[用户角色]**，
|
|
||||||
> 我希望 **[功能/行为]**，
|
|
||||||
> 以便 **[获得的价值]**。
|
|
||||||
|
|
||||||
2. **验收条件（Acceptance Criteria）**
|
|
||||||
- 必须可测试、可验证
|
|
||||||
- 正面条件 + 边缘情况
|
|
||||||
|
|
||||||
3. **原型验证**
|
|
||||||
- 低保真原型验证交互流程（1-2 天）
|
|
||||||
- 用户测试 3-5 人，观察操作行为
|
|
||||||
- 根据反馈迭代后进入高保真设计
|
|
||||||
|
|
||||||
### 四、需求评审流程
|
|
||||||
|
|
||||||
```
|
|
||||||
需求方提出 → PM 分析评估 → 交互设计 → 技术评审
|
|
||||||
→ 排期评估 → 最终评审 → 进入开发
|
|
||||||
```
|
|
||||||
|
|
||||||
每一步评审需至少以下人员参与：
|
|
||||||
- PM（负责人）
|
|
||||||
- 1 名开发（评估技术可行性）
|
|
||||||
- 1 名设计师（评估交互可行性）
|
|
||||||
- 需求方（确认需求理解正确）
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [PRD模板.md](PRD模板.md)
|
|
||||||
- [开发规范.md](../技术/开发规范.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
@@ -1,21 +0,0 @@
|
|||||||
# 内容领域知识
|
|
||||||
|
|
||||||
**责任人**：文墨言（contentspecialist）
|
|
||||||
**审核人**：陆怀瑾（coo）
|
|
||||||
|
|
||||||
## 知识范围
|
|
||||||
|
|
||||||
涵盖小红书、短视频平台、公众号等内容平台运营知识，包括内容创作、选题策划、标题优化、发布策略、数据分析等。
|
|
||||||
|
|
||||||
## 条目清单
|
|
||||||
|
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [小红书运营指南.md](小红书运营指南.md) | 小红书内容运营全流程指南 | ✅ |
|
|
||||||
| [标题写作技巧.md](标题写作技巧.md) | 爆款标题创作方法论 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 短视频脚本模板
|
|
||||||
- 公众号排版规范
|
|
||||||
- 内容日历模板
|
|
||||||
+18
-76
@@ -1,82 +1,24 @@
|
|||||||
# 小红书运营指南
|
# SOP：小红书内容运营
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 小红书平台内容运营 | 维护人: 文墨言（contentspecialist）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、选题策划（每周一）
|
||||||
|------|-----|
|
- 确定 3-5 个选题 → 分配优先级 → 准备素材
|
||||||
| **领域** | 内容 |
|
- 输出: 本周内容排期表
|
||||||
| **责任人** | 文墨言 (contentspecialist) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 小红书, 内容运营, 种草, 涨粉 |
|
|
||||||
|
|
||||||
## 概述
|
## 二、内容创作
|
||||||
|
- 撰写标题（含 2+ 关键词）→ 正文结构化 → 配图 ≥ 3 张 → SEO 优化
|
||||||
|
- 正文 ≥ 300 字
|
||||||
|
|
||||||
小红书是以"真实分享+种草"为核心的内容社区，运营不同于其他平台。核心逻辑：真诚分享 > 硬广推广，封面/标题决定点击率，内容质量决定涨粉转化。
|
## 三、发布与互动
|
||||||
|
- 定时发布 → 1h 内回复评论 → 48h 持续互动
|
||||||
|
- 48h 评论回复率 100%
|
||||||
|
|
||||||
## 正文
|
## 四、数据分析（每周五）
|
||||||
|
- 统计阅读量/点赞/收藏/评论
|
||||||
|
- 分析 top 3 和 bottom 3
|
||||||
|
- 输出: 周报 + 优化建议
|
||||||
|
|
||||||
### 一、内容定位与选题
|
## 升级路径
|
||||||
|
- 连续 5 篇流量低于均值 → 报告 COO
|
||||||
1. **账号定位**（上线前必做）
|
- 平台规则变更 → 2h 内通知 COO
|
||||||
- 明确赛道：美妆/穿搭/家居/母婴/美食/知识
|
|
||||||
- 确定人设：专家型/体验型/教程型
|
|
||||||
- 对标 3-5 个同赛道 Top 博主
|
|
||||||
|
|
||||||
2. **选题策略**
|
|
||||||
- 热点追踪：小红书热搜 + 抖音热点宝
|
|
||||||
- 实用内容：教程/清单/测评/避坑
|
|
||||||
- 情感共鸣：个人经历/观点分享/生活记录
|
|
||||||
|
|
||||||
### 二、内容制作标准
|
|
||||||
|
|
||||||
1. **封面设计**（点击率核心）
|
|
||||||
- 高饱和度配色，对比度强
|
|
||||||
- 简洁文字 3-7 字，避免遮挡主体
|
|
||||||
- 尺寸 3:4，首图即为封面
|
|
||||||
|
|
||||||
2. **标题公式**
|
|
||||||
- 数字型：「3 步搞定...」
|
|
||||||
- 痛点型：「为什么你...还是不行？」
|
|
||||||
- 对比型：「A vs B，差距到底在哪」
|
|
||||||
- 清单型：「2026 必入的 10 款...」
|
|
||||||
|
|
||||||
3. **正文结构**
|
|
||||||
- 开头（3 句）：抛痛点/抛结论
|
|
||||||
- 主体：分点说明，配图对应
|
|
||||||
- 结尾：互动引导（提问/投票/求关注）
|
|
||||||
|
|
||||||
### 三、发布与推广
|
|
||||||
|
|
||||||
1. **发布时间**
|
|
||||||
- 工作日：12:00-14:00, 18:00-21:00
|
|
||||||
- 周末：10:00-12:00, 15:00-18:00
|
|
||||||
|
|
||||||
2. **话题标签策略**
|
|
||||||
- 1-2 个大流量话题（#穿搭 #美妆 #家居）
|
|
||||||
- 2-3 个精准话题（#小个子穿搭 #通勤穿搭）
|
|
||||||
- 1 个自创话题（#XX的日常搭配）
|
|
||||||
|
|
||||||
3. **初期冷启动**
|
|
||||||
- 发布后 1 小时内互动（评论/点赞）对推荐权重影响最大
|
|
||||||
- 在同类笔记下真诚评论（非硬广引流）
|
|
||||||
|
|
||||||
### 四、数据指标
|
|
||||||
|
|
||||||
| 指标 | 新手目标 | 进阶目标 |
|
|
||||||
|------|----------|----------|
|
|
||||||
| 单篇阅读量 | 1000+ | 5000+ |
|
|
||||||
| 点赞率 | 3%+ | 5%+ |
|
|
||||||
| 收藏率 | 2%+ | 4%+ |
|
|
||||||
| 涨粉率 | 1%/篇 | 3%/篇 |
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [标题写作技巧.md](标题写作技巧.md)
|
|
||||||
- [活动策划模板.md](../运营/活动策划模板.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
+12
-17
@@ -1,21 +1,16 @@
|
|||||||
# 技术领域知识
|
# 技术领域知识
|
||||||
|
|
||||||
**责任人**：徐聪（costcodev）
|
> 责任人：梁思筑（architect）
|
||||||
**审核人**：陆怀瑾（coo）
|
> 适用范围：产研中心所有开发项目
|
||||||
|
|
||||||
## 知识范围
|
|
||||||
|
|
||||||
涵盖开发规范、代码审查、架构设计、部署运维、技术选型等技术团队知识。
|
|
||||||
|
|
||||||
## 条目清单
|
|
||||||
|
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [开发规范.md](开发规范.md) | 代码编写与项目管理规范 | ✅ |
|
|
||||||
| [代码审查清单.md](代码审查清单.md) | Pull Request 审查标准 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
|
## 包含内容
|
||||||
|
- 开发规范（编码/提交/测试/Code Review）
|
||||||
|
- 技术栈规范与选型指南
|
||||||
|
- 架构设计规范
|
||||||
- API 设计规范
|
- API 设计规范
|
||||||
- 数据库设计指南
|
- 部署流程规范
|
||||||
- 技术选型决策框架
|
|
||||||
|
## 贡献者
|
||||||
|
- 梁思筑（architect）：架构规范、技术选型
|
||||||
|
- 徐聪（costcodev）：开发实践、代码模板
|
||||||
|
- 严维序（opengineer）：部署流程、运维规范
|
||||||
+31
-94
@@ -1,104 +1,41 @@
|
|||||||
# 开发规范
|
# 开发规范
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 所有产研开发项目 | 维护人: 梁思筑（architect）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、命名约定
|
||||||
|------|-----|
|
- 文件: kebab-case（user-service.ts）
|
||||||
| **领域** | 技术 |
|
- 变量/函数: camelCase（getUserById）
|
||||||
| **责任人** | 徐聪 (costcodev) |
|
- 类/接口: PascalCase（UserService）
|
||||||
| **版本** | v1.0 |
|
- 常量: UPPER_SNAKE_CASE（MAX_RETRY_COUNT）
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 开发规范, 代码风格, Git, 项目管理 |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
定义团队统一的代码编写、项目管理、协作流程规范。目的是确保代码可维护、可交接，降低协作摩擦。
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
### 一、代码规范
|
|
||||||
|
|
||||||
1. **Python**
|
|
||||||
- 遵循 PEP 8 代码风格
|
|
||||||
- 使用 `black` 自动格式化，行宽 100
|
|
||||||
- 类型注解必须（`mypy --strict` 通过）
|
|
||||||
- 文档字符串用 Google 风格
|
|
||||||
|
|
||||||
2. **TypeScript/JavaScript**
|
|
||||||
- 使用 `prettier` 格式化
|
|
||||||
- ESLint 严格模式
|
|
||||||
- 禁止 `any` 类型（除非显式标注 `// eslint-disable-next-line`）
|
|
||||||
- 所有公共 API 必须有 JSDoc
|
|
||||||
|
|
||||||
3. **通用规则**
|
|
||||||
- 函数单一职责，不超过 50 行
|
|
||||||
- 命名：camelCase（变量/函数）、PascalCase（类/组件）、UPPER_SNAKE（常量）
|
|
||||||
- 禁止 `print` / `console.log` 残留（用日志库）
|
|
||||||
- 禁止注释掉的代码（相信 Git）
|
|
||||||
|
|
||||||
### 二、Git 规范
|
|
||||||
|
|
||||||
1. **分支策略**
|
|
||||||
```
|
|
||||||
main ─── 生产环境
|
|
||||||
develop ─── 开发主线
|
|
||||||
feature/<task-id>-<desc> ─── 功能分支
|
|
||||||
fix/<task-id>-<desc> ─── 修复分支
|
|
||||||
```
|
|
||||||
|
|
||||||
2. **Commit 格式**
|
|
||||||
```
|
|
||||||
<type>(<scope>): <subject>
|
|
||||||
|
|
||||||
<body>
|
|
||||||
|
|
||||||
<footer>
|
|
||||||
```
|
|
||||||
- type: feat / fix / docs / style / refactor / test / chore
|
|
||||||
- scope: 模块名（如 api, ui, db）
|
|
||||||
- subject: 不超过 72 字符，中文或英文
|
|
||||||
|
|
||||||
3. **PR 流程**
|
|
||||||
- 所有代码变更必须通过 PR
|
|
||||||
- 至少 1 人 Review 并 Approve
|
|
||||||
- CI 全部通过后才能合并
|
|
||||||
- 合并前 rebase develop 消除冲突
|
|
||||||
|
|
||||||
### 三、项目结构规范
|
|
||||||
|
|
||||||
|
## 二、提交规范
|
||||||
```
|
```
|
||||||
project/
|
<type>(<scope>): <subject>
|
||||||
├── src/ # 源代码
|
|
||||||
├── tests/ # 测试代码
|
|
||||||
├── docs/ # 项目文档
|
|
||||||
├── scripts/ # 运维脚本
|
|
||||||
├── config/ # 配置文件
|
|
||||||
├── README.md # 项目说明
|
|
||||||
├── CHANGELOG.md # 变更日志
|
|
||||||
└── .env.example # 环境变量模板
|
|
||||||
```
|
```
|
||||||
|
Type: feat | fix | docs | style | refactor | test | chore
|
||||||
|
|
||||||
### 四、文档规范
|
## 三、测试规范
|
||||||
|
- 单元测试覆盖率 ≥ 80%
|
||||||
|
- 关键路径 100% 覆盖
|
||||||
|
- 每个 PR 必须附带测试
|
||||||
|
|
||||||
- **README.md**：项目概述、快速启动、技术栈、目录说明
|
## 四、Code Review 检查清单
|
||||||
- **API 文档**：后端接口必须有 OpenAPI/Swagger 文档
|
| 检查项 | 说明 |
|
||||||
- **开发文档**：架构设计、数据流图、部署说明
|
|--------|------|
|
||||||
- **代码即文档**：优先清晰的命名和结构，减少注释
|
| 命名清晰 | 变量/函数名能自解释 |
|
||||||
|
| 无重复代码 | DRY 原则 |
|
||||||
|
| 无硬编码 | 配置项外置 |
|
||||||
|
| 错误处理 | 异常路径已覆盖 |
|
||||||
|
| 安全 | 无 SQL 注入/XSS/敏感信息泄露 |
|
||||||
|
| 性能 | 无 N+1 查询/不必要的循环 |
|
||||||
|
|
||||||
### 五、测试规范
|
## 五、技术栈推荐
|
||||||
|
| 类别 | 推荐 |
|
||||||
|
|------|------|
|
||||||
|
| 前端 | React/Next.js (TS) |
|
||||||
|
| 后端 | Node.js/Python |
|
||||||
|
| 数据库 | PostgreSQL |
|
||||||
|
| 缓存 | Redis |
|
||||||
|
| CI/CD | GitHub Actions |
|
||||||
|
|
||||||
- 单元测试覆盖率 ≥ 70%
|
> 引入新技术栈需 architect 评估后方可使用。
|
||||||
- 关键业务逻辑覆盖率 ≥ 90%
|
|
||||||
- 每个 PR 附带新增/修改的测试
|
|
||||||
- 使用 `pytest` (Python) / `vitest` (TS)
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [代码审查清单.md](代码审查清单.md)
|
|
||||||
- [PRD模板.md](../产品/PRD模板.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
@@ -1,21 +0,0 @@
|
|||||||
# 电商领域知识
|
|
||||||
|
|
||||||
**责任人**：陆云帆（taobaospecialist）
|
|
||||||
**审核人**：陆怀瑾（coo）
|
|
||||||
|
|
||||||
## 知识范围
|
|
||||||
|
|
||||||
涵盖淘宝、抖店、微信小店等多平台电商运营知识，包括店铺搭建、商品上架、营销推广、客户服务、数据分析等。
|
|
||||||
|
|
||||||
## 条目清单
|
|
||||||
|
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [淘宝运营SOP.md](淘宝运营SOP.md) | 淘宝店铺日常运营标准流程 | ✅ |
|
|
||||||
| [抖店运营SOP.md](抖店运营SOP.md) | 抖音小店运营流程 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 微信小店运营指南
|
|
||||||
- 电商数据分析方法
|
|
||||||
- 客服话术模板
|
|
||||||
@@ -1,74 +0,0 @@
|
|||||||
# 抖店运营 SOP
|
|
||||||
|
|
||||||
## 元数据
|
|
||||||
|
|
||||||
| 属性 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| **领域** | 电商 |
|
|
||||||
| **责任人** | 陆云帆 (taobaospecialist) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 抖音, 抖店, 电商, SOP |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
本 SOP 定义抖音小店运营标准流程。抖店运营区别于传统电商的核心在于"内容驱动交易"——通过短视频和直播引流到店铺成交。
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
### 一、每日运营
|
|
||||||
|
|
||||||
1. **店铺健康检查**
|
|
||||||
- 登录抖店后台，检查体验分（≥ 4.6）
|
|
||||||
- 查看违规记录和扣分情况
|
|
||||||
- 检查商品状态（在售/审核中/下架）
|
|
||||||
|
|
||||||
2. **内容运营**
|
|
||||||
- 发布 1-2 条挂车短视频
|
|
||||||
- 检查昨日短视频/直播数据
|
|
||||||
- 回复评论区用户问题
|
|
||||||
|
|
||||||
3. **订单与客服**
|
|
||||||
- 处理待发货订单（48 小时发货）
|
|
||||||
- 处理售后申请（退货/退款）
|
|
||||||
- 3 分钟内回复客服消息
|
|
||||||
|
|
||||||
### 二、每周运营
|
|
||||||
|
|
||||||
1. **商品策略**
|
|
||||||
- 分析本周爆款商品，优化标题/主图/详情
|
|
||||||
- 根据热点趋势选品上新
|
|
||||||
- 设置限时秒杀/优惠券活动
|
|
||||||
|
|
||||||
2. **内容策略**
|
|
||||||
- 复盘本周短视频/直播数据
|
|
||||||
- 策划下周内容选题（蹭热点/产品展示/教程）
|
|
||||||
- 测试新视频形式（口播/开箱/场景化）
|
|
||||||
|
|
||||||
3. **投放优化**
|
|
||||||
- 查看千川投放数据
|
|
||||||
- 优化投放计划（人群/出价/素材）
|
|
||||||
- 调整 ROI 目标和预算分配
|
|
||||||
|
|
||||||
### 三、每月运营
|
|
||||||
|
|
||||||
1. **月度分析**
|
|
||||||
- 统计月度 GMV、订单量、退款率
|
|
||||||
- 分析流量来源占比（推荐/搜索/直播/短视频/付费）
|
|
||||||
- 输出《抖店月度运营报告》
|
|
||||||
|
|
||||||
2. **供应链检查**
|
|
||||||
- 盘点库存，补货预警
|
|
||||||
- 检查发货时效和物流评分
|
|
||||||
- 供应商评估和优化
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [淘宝运营SOP.md](淘宝运营SOP.md)
|
|
||||||
- [数据分析方法.md](../运营/数据分析方法.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
+22
-77
@@ -1,83 +1,28 @@
|
|||||||
# 淘宝运营 SOP
|
# SOP：淘宝店铺日常运营
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 淘宝店铺日常运营、新店起店 | 维护人: 陆云帆（taobaospecialist）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、每日巡检
|
||||||
|------|-----|
|
- **时间**: 每天上午
|
||||||
| **领域** | 电商 |
|
- **操作**: 检查订单状态、退款/售后、违规通知、商品状态
|
||||||
| **责任人** | 陆云帆 (taobaospecialist) |
|
- **输出**: 日报摘要（异常项 + 处理建议）
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 淘宝, 电商, SOP, 日常运营 |
|
|
||||||
|
|
||||||
## 概述
|
## 二、商品优化
|
||||||
|
- **频率**: 每周 ≥ 2 次
|
||||||
|
- **操作**: 分析搜索排名/点击率/转化率 → 优化标题关键词 → 更新主图/详情页 → 调整价格
|
||||||
|
- **输出**: 优化记录 + 前后对比
|
||||||
|
|
||||||
本 SOP 定义淘宝店铺日常运营的标准流程，涵盖店铺维护、商品管理、营销推广、客服处理和数据分析五大模块。适用于每日/每周/每月周期性执行。
|
## 三、活动管理
|
||||||
|
- **准备**: 活动前 3 天
|
||||||
|
- **操作**: 评估 ROI → 报名 → 设置活动价 → 活动期监控 → 复盘
|
||||||
|
- **输出**: 活动复盘报告
|
||||||
|
|
||||||
## 正文
|
## 质量检查
|
||||||
|
- 每日巡检 100% 完成
|
||||||
|
- 搜索排名周环比提升
|
||||||
|
- 活动参与率 ≥ 80%
|
||||||
|
|
||||||
### 一、每日运营检查（每日 9:00）
|
## 升级路径
|
||||||
|
- 平台规则重大变更 → 立即通知 COO
|
||||||
1. **店铺状态检查**
|
- 转化率持续下降 > 3 天 → 报告 COO
|
||||||
- 登录千牛工作台，检查店铺处罚/违规通知
|
- 技术问题（API/系统）→ 联系 opengineer
|
||||||
- 确认所有商品在售状态，无异常下架
|
|
||||||
- 检查店铺评分（DSR），低于 4.7 需立即分析原因
|
|
||||||
|
|
||||||
2. **订单处理**
|
|
||||||
- 查看待发货订单，确保 48 小时内发货
|
|
||||||
- 处理售后订单（退货/换货/退款），24 小时内响应
|
|
||||||
- 检查差评/中评，及时联系客户处理
|
|
||||||
|
|
||||||
3. **客服响应**
|
|
||||||
- 检查未读消息，回复时限 5 分钟内
|
|
||||||
- 查看客服数据：响应时长、满意度
|
|
||||||
|
|
||||||
### 二、每周运营任务（每周一）
|
|
||||||
|
|
||||||
1. **商品优化**
|
|
||||||
- 检查 Top 10 商品标题、主图、详情页
|
|
||||||
- 根据搜索词报告优化标题关键词
|
|
||||||
- 更新库存不足的商品
|
|
||||||
|
|
||||||
2. **营销活动**
|
|
||||||
- 查看本周淘宝官方活动日历
|
|
||||||
- 设置店铺优惠券/满减活动
|
|
||||||
- 更新直通车/引力魔方推广计划
|
|
||||||
|
|
||||||
3. **数据分析**
|
|
||||||
- 查看流量来源（搜索/推荐/付费/其他）
|
|
||||||
- 分析转化率、客单价变化趋势
|
|
||||||
- 输出《店铺周报》
|
|
||||||
|
|
||||||
### 三、每月运营任务（每月 1 日）
|
|
||||||
|
|
||||||
1. **月度复盘**
|
|
||||||
- 统计月度 GMV、订单量、利润率
|
|
||||||
- 对比上月数据，分析增长/下滑原因
|
|
||||||
- 制定下月运营目标和策略
|
|
||||||
|
|
||||||
2. **竞品分析**
|
|
||||||
- 监控 Top 3 竞品店铺动态
|
|
||||||
- 分析竞品爆款商品和新品
|
|
||||||
- 调整自身商品/价格策略
|
|
||||||
|
|
||||||
### 四、关键指标
|
|
||||||
|
|
||||||
| 指标 | 目标值 | 监控频率 |
|
|
||||||
|------|--------|----------|
|
|
||||||
| DSR 评分 | ≥ 4.8 | 每日 |
|
|
||||||
| 48h 发货率 | ≥ 98% | 每日 |
|
|
||||||
| 客服响应时长 | ≤ 3 分钟 | 每日 |
|
|
||||||
| 转化率 | ≥ 行业均值 +10% | 每周 |
|
|
||||||
| GMV 增长 | 月环比 ≥ 10% | 每月 |
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [抖店运营SOP.md](抖店运营SOP.md)
|
|
||||||
- [数据分析方法.md](../运营/数据分析方法.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
@@ -1,21 +0,0 @@
|
|||||||
# 行政领域知识
|
|
||||||
|
|
||||||
**责任人**：刘诗妮（secretary）
|
|
||||||
**审核人**：陆怀瑾（coo）
|
|
||||||
|
|
||||||
## 知识范围
|
|
||||||
|
|
||||||
涵盖合同管理、报销流程、行政事务、供应商管理等行政支持知识。
|
|
||||||
|
|
||||||
## 条目清单
|
|
||||||
|
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [合同模板.md](合同模板.md) | 常用合同标准模板 | ✅ |
|
|
||||||
| [报销流程.md](报销流程.md) | 费用报销申请与审批流程 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 供应商管理指南
|
|
||||||
- 会议纪要模板
|
|
||||||
- 入职/离职流程
|
|
||||||
@@ -1,83 +0,0 @@
|
|||||||
# 报销流程
|
|
||||||
|
|
||||||
## 元数据
|
|
||||||
|
|
||||||
| 属性 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| **领域** | 行政 |
|
|
||||||
| **责任人** | 刘诗妮 (secretary) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | 行政, 报销, 财务, 流程 |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
定义公司费用报销的标准流程，涵盖申请、审批、核销三大阶段，确保财务合规性和报销效率。
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
### 一、报销范围
|
|
||||||
|
|
||||||
| 类别 | 说明 | 限额 |
|
|
||||||
|------|------|------|
|
|
||||||
| 差旅费 | 交通、住宿、餐饮 | 按出差地标准 |
|
|
||||||
| 办公用品 | 设备、耗材、文具 | 单次 ≤ ¥2000 |
|
|
||||||
| 招待费 | 客户/合作伙伴接待 | 需提前申请 |
|
|
||||||
| 培训费 | 课程、考试、认证 | 需审批 |
|
|
||||||
| 软件服务 | SaaS 订阅、API 费用 | 按需审批 |
|
|
||||||
|
|
||||||
### 二、报销流程
|
|
||||||
|
|
||||||
```
|
|
||||||
提交申请 → 直属审批 → COO 审批（> ¥5000）
|
|
||||||
→ 刘总审批（> ¥20000） → 刘诗妮核销 → 归档
|
|
||||||
```
|
|
||||||
|
|
||||||
**各环节时限**：
|
|
||||||
- 员工提交：消费后 7 个工作日内
|
|
||||||
- 直属审批：2 个工作日内
|
|
||||||
- 核销：审批通过后 5 个工作日内
|
|
||||||
|
|
||||||
### 三、报销材料
|
|
||||||
|
|
||||||
1. **发票**
|
|
||||||
- 必须增值税普通/专用发票
|
|
||||||
- 发票抬头：公司全称 + 税号
|
|
||||||
- 电子发票可，纸质发票需原件
|
|
||||||
|
|
||||||
2. **报销单**
|
|
||||||
- 事由：清晰说明消费目的
|
|
||||||
- 明细：逐项列出费用+金额
|
|
||||||
- 附件上传：发票图片/电子凭证
|
|
||||||
|
|
||||||
3. **特殊说明**
|
|
||||||
- 差旅：附行程单
|
|
||||||
- 招待：附参与人员名单
|
|
||||||
- 大额采购：附比价记录
|
|
||||||
|
|
||||||
### 四、常见退回原因
|
|
||||||
|
|
||||||
| 原因 | 处理 |
|
|
||||||
|------|------|
|
|
||||||
| 发票信息错误（抬头/税号） | 退回重新开票 |
|
|
||||||
| 超额未提前审批 | 补充说明或自付超额部分 |
|
|
||||||
| 缺少明细说明 | 补充报销单信息 |
|
|
||||||
| 超过报销时效 | 特殊说明后处理 |
|
|
||||||
|
|
||||||
### 五、审批人
|
|
||||||
|
|
||||||
| 金额区间 | 审批人 |
|
|
||||||
|----------|--------|
|
|
||||||
| ≤ ¥5000 | 直属负责人 |
|
|
||||||
| ¥5001 ~ ¥20000 | + COO（陆怀瑾） |
|
|
||||||
| > ¥20000 | + 刘总（Vincent） |
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [合同模板.md](合同模板.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
+11
-17
@@ -1,21 +1,15 @@
|
|||||||
# 设计领域知识
|
# 设计领域知识
|
||||||
|
|
||||||
**责任人**：苏绘锦（designer）
|
> 责任人：苏锦绘（designer）
|
||||||
**审核人**：陆怀瑾（coo）
|
> 适用范围：所有品牌视觉输出
|
||||||
|
|
||||||
## 知识范围
|
## 包含内容
|
||||||
|
- UI 设计规范（色彩/字体/间距/组件）
|
||||||
|
- 电商设计规范（商详页/首图/Banner）
|
||||||
|
- 品牌视觉资产管理
|
||||||
|
- 设计交付物标准
|
||||||
|
|
||||||
涵盖 UI/UX 设计规范、品牌元素、商详页设计、首图制作等设计知识。
|
## 贡献者
|
||||||
|
- 苏锦绘（designer）：设计规范、品牌视觉
|
||||||
## 条目清单
|
- 陆云帆（taobaospecialist）：电商设计需求
|
||||||
|
- 文墨言（contentspecialist）：内容设计需求
|
||||||
| 文件名 | 说明 | 状态 |
|
|
||||||
|--------|------|------|
|
|
||||||
| [UI设计规范.md](UI设计规范.md) | 界面设计标准与组件规范 | ✅ |
|
|
||||||
| [品牌元素指南.md](品牌元素指南.md) | 品牌色/字体/Logo 使用规范 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 商详页设计模板
|
|
||||||
- 首图设计规范
|
|
||||||
- 移动端适配指南
|
|
||||||
+22
-78
@@ -1,87 +1,31 @@
|
|||||||
# UI 设计规范
|
# UI 设计规范
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 所有品牌设计输出 | 维护人: 苏锦绘（designer）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、色彩系统
|
||||||
|------|-----|
|
| 名称 | 色值 | 用途 |
|
||||||
| **领域** | 设计 |
|
|
||||||
| **责任人** | 苏绘锦 (designer) |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | 2026-06-22 |
|
|
||||||
| **标签** | UI, 设计规范, 组件, 视觉 |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
定义统一的 UI 设计标准，涵盖色彩、字体、间距、组件等基础规范，确保产品视觉一致性，降低设计-开发沟通成本。
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
### 一、色彩系统
|
|
||||||
|
|
||||||
| 用途 | 色值 | 说明 |
|
|
||||||
|------|------|------|
|
|------|------|------|
|
||||||
| 主色 Primary | `#1677FF` | 按钮、链接、选中态 |
|
| 主色 | #2563EB | 按钮/强调元素 |
|
||||||
| 成功 Success | `#52C41A` | 成功提示、通过状态 |
|
| 辅色 | #10B981 | 成功状态 |
|
||||||
| 警告 Warning | `#FAAD14` | 警告提示 |
|
| 警告色 | #F59E0B | 提醒/警告 |
|
||||||
| 错误 Error | `#FF4D4F` | 错误提示、删除操作 |
|
| 错误色 | #EF4444 | 错误/危险操作 |
|
||||||
| 文字主色 | `#1F1F1F` | 标题、正文 |
|
| 页面背景 | #F9FAFB | 网站/app 背景 |
|
||||||
| 文字次色 | `#666666` | 辅助说明 |
|
| 卡片背景 | #FFFFFF | 内容卡片 |
|
||||||
| 文字禁用 | `#BFBFBF` | 禁用/占位符 |
|
|
||||||
| 边框 | `#D9D9D9` | 分割线、输入框边框 |
|
|
||||||
| 背景 | `#F5F5F5` | 页面底色 |
|
|
||||||
|
|
||||||
### 二、字体规范
|
## 二、字体规范
|
||||||
|
| 层级 | 字号 | 字重 |
|
||||||
| 层级 | 字号 | 行高 | 字重 | 用途 |
|
|
||||||
|------|------|------|------|------|
|
|
||||||
| H1 | 24px | 32px | 600 | 页面主标题 |
|
|
||||||
| H2 | 20px | 28px | 600 | 区块标题 |
|
|
||||||
| H3 | 16px | 24px | 500 | 小标题 |
|
|
||||||
| Body | 14px | 22px | 400 | 正文 |
|
|
||||||
| Caption | 12px | 18px | 400 | 辅助/说明文字 |
|
|
||||||
|
|
||||||
默认字体：`-apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif`
|
|
||||||
|
|
||||||
### 三、间距体系
|
|
||||||
|
|
||||||
采用 4px 为基础单位的 8 点栅格：
|
|
||||||
|
|
||||||
| Token | 值 | 用途 |
|
|
||||||
|-------|-----|------|
|
|
||||||
| xs | 4px | 紧凑间距 |
|
|
||||||
| sm | 8px | 元素内间距 |
|
|
||||||
| md | 16px | 组件间距 |
|
|
||||||
| lg | 24px | 区块间距 |
|
|
||||||
| xl | 32px | 大区块分隔 |
|
|
||||||
| xxl | 48px | 页面级分隔 |
|
|
||||||
|
|
||||||
### 四、圆角与阴影
|
|
||||||
|
|
||||||
| 组件 | 圆角 | 阴影 |
|
|
||||||
|------|------|------|
|
|------|------|------|
|
||||||
| 卡片 | 8px | `0 2px 8px rgba(0,0,0,0.08)` |
|
| H1 | 32px | Bold(700) |
|
||||||
| 弹窗 | 12px | `0 6px 16px rgba(0,0,0,0.12)` |
|
| H2 | 24px | Semibold(600) |
|
||||||
| 按钮 | 6px | 无（默认）/ hover 时微阴影 |
|
| 正文 | 16px | Regular(400) |
|
||||||
| 输入框 | 6px | 无（默认）/ focus 时外发光 |
|
| 辅助 | 14px | Regular(400) |
|
||||||
|
|
||||||
### 五、响应式断点
|
## 三、间距系统
|
||||||
|
xs=4px | sm=8px | md=16px | lg=24px | xl=32px
|
||||||
|
|
||||||
| 断点 | 最小宽度 | 适用设备 |
|
## 四、组件规范
|
||||||
|------|----------|----------|
|
- 按钮: 品牌主色填充, 圆角 8px
|
||||||
| xs | < 576px | 手机竖屏 |
|
- 输入框: 高度 40px, 圆角 8px
|
||||||
| sm | ≥ 576px | 手机横屏 |
|
- 卡片: 圆角 12px, 内间距 24px
|
||||||
| md | ≥ 768px | 平板 |
|
|
||||||
| lg | ≥ 992px | 小桌面 |
|
|
||||||
| xl | ≥ 1200px | 大桌面 |
|
|
||||||
| xxl | ≥ 1600px | 超大屏 |
|
|
||||||
|
|
||||||
## 相关条目
|
> 品牌视觉变更需 COO 审批。
|
||||||
|
|
||||||
- [品牌元素指南.md](品牌元素指南.md)
|
|
||||||
- [PRD模板.md](../产品/PRD模板.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
+12
-17
@@ -1,21 +1,16 @@
|
|||||||
# 运营领域知识
|
# 运营领域知识
|
||||||
|
|
||||||
**责任人**：陆怀瑾（coo）
|
> 责任人：陆怀瑾（COO）
|
||||||
**审核人**：刘炜承（Vincent）
|
> 适用范围：所有业务线运营管理
|
||||||
|
|
||||||
## 知识范围
|
## 包含内容
|
||||||
|
- 数据分析方法（电商/内容/视频指标体系）
|
||||||
|
- 活动策划模板（全流程 + 质量检查清单）
|
||||||
|
- 运营效率监控方法
|
||||||
|
- 资源调度与负载均衡方法
|
||||||
|
|
||||||
涵盖活动策划、数据分析、SOP 管理、流程优化、团队协作等运营管理知识。
|
## 贡献者
|
||||||
|
- 陆怀瑾（COO）：运营方法、效率监控
|
||||||
## 条目清单
|
- 陆云帆（taobaospecialist）：电商运营实践
|
||||||
|
- 文墨言（contentspecialist）：内容运营实践
|
||||||
| 文件名 | 说明 | 状态 |
|
- 钟帧韵（mediaspecialist）：视频运营实践
|
||||||
|--------|------|------|
|
|
||||||
| [活动策划模板.md](活动策划模板.md) | 营销活动策划标准模板 | ✅ |
|
|
||||||
| [数据分析方法.md](数据分析方法.md) | 运营数据分析框架与方法 | ✅ |
|
|
||||||
|
|
||||||
## 待建设
|
|
||||||
|
|
||||||
- 周报模板
|
|
||||||
- KPI 管理框架
|
|
||||||
- 风险评估矩阵
|
|
||||||
+31
-86
@@ -1,92 +1,37 @@
|
|||||||
# 数据分析方法
|
# SOP：运营数据分析
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 电商/内容/视频各业务线 | 维护人: 陆怀瑾（COO）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、电商核心指标
|
||||||
|------|-----|
|
| 指标 | 频率 |
|
||||||
| **领域** | 运营 |
|
|------|------|
|
||||||
| **责任人** | 陆怀瑾 (coo) |
|
| GMV | 日/周/月 |
|
||||||
| **版本** | v1.0 |
|
| 转化率 | 日 |
|
||||||
| **创建日期** | 2026-06-22 |
|
| 客单价 | 周 |
|
||||||
| **标签** | 数据分析, 运营, KPI, 看板 |
|
| 退款率 | 周 |
|
||||||
|
| 搜索排名 | 周 |
|
||||||
|
|
||||||
## 概述
|
## 二、内容核心指标
|
||||||
|
| 指标 | 频率 |
|
||||||
|
|------|------|
|
||||||
|
| 阅读量 | 篇 |
|
||||||
|
| 互动率 | 篇 |
|
||||||
|
| 涨粉数 | 日 |
|
||||||
|
|
||||||
建立全业务流程的数据分析框架，确保各业务线有统一的指标定义和分析方法，支撑数据驱动决策。
|
## 三、视频核心指标
|
||||||
|
| 指标 | 频率 |
|
||||||
|
|------|------|
|
||||||
|
| 播放量 | 条 |
|
||||||
|
| 完播率 | 条 |
|
||||||
|
| 互动率 | 条 |
|
||||||
|
|
||||||
## 正文
|
## 四、分析框架
|
||||||
|
- 日常: 数据采集 → 同比/环比 → 异常检测 → 归因 → 行动建议
|
||||||
|
- 周度: 趋势图 → Top/Bottom → 策略调整 → 下周目标
|
||||||
|
- 月度: 趋势 → 达成率 → 渠道对比 → 资源效率 → 下月计划
|
||||||
|
|
||||||
### 一、核心指标体系
|
## 五、工具链
|
||||||
|
- 数据采集: 平台后台 + API
|
||||||
#### 1. 电商业务
|
- 数据处理: Python pandas / Excel
|
||||||
|
- 可视化: Metabase / 飞书多维表格
|
||||||
| 层级 | 指标 | 定义 | 频率 |
|
- 报告发布: 飞书文档 / Bitable
|
||||||
|------|------|------|------|
|
|
||||||
| 北极星 | GMV | 总成交额 | 日/周/月 |
|
|
||||||
| 过程 | 转化率 | 下单数/访客数 | 日 |
|
|
||||||
| 过程 | 客单价 | GMV/订单数 | 周 |
|
|
||||||
| 过程 | 退货率 | 退货数/订单数 | 周 |
|
|
||||||
| 健康 | DSR | 描述/服务/物流评分 | 日 |
|
|
||||||
| 健康 | 获客成本 CAC | 营销花费/新客数 | 月 |
|
|
||||||
|
|
||||||
#### 2. 内容业务
|
|
||||||
|
|
||||||
| 层级 | 指标 | 定义 | 频率 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| 北极星 | 粉丝增长 | 净增粉丝数 | 周/月 |
|
|
||||||
| 过程 | 互动率 | (点赞+收藏+评论)/曝光 | 篇 |
|
|
||||||
| 过程 | 发布频率 | 每周发布篇数 | 周 |
|
|
||||||
|
|
||||||
#### 3. 公司整体
|
|
||||||
|
|
||||||
| 层级 | 指标 | 定义 | 频率 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| 北极星 | 月营收 | 各业务线收入合计 | 月 |
|
|
||||||
| 效率 | 人效 | 营收/团队人数 | 季 |
|
|
||||||
| 效率 | Agent 利用率 | Agent 任务完成数/总分配数 | 周 |
|
|
||||||
|
|
||||||
### 二、分析框架
|
|
||||||
|
|
||||||
**AARRR 海盗模型**：
|
|
||||||
|
|
||||||
```
|
|
||||||
Acquisition（获取）→ Activation（激活）→ Retention（留存）
|
|
||||||
→ Revenue（收入）→ Referral（推荐）
|
|
||||||
```
|
|
||||||
|
|
||||||
**电商应用示例**：
|
|
||||||
1. Acquisition：各渠道流量来源占比
|
|
||||||
2. Activation：首次下单转化率
|
|
||||||
3. Retention：30 天复购率
|
|
||||||
4. Revenue：LTV（用户生命周期价值）
|
|
||||||
5. Referral：分享率、裂变系数
|
|
||||||
|
|
||||||
### 三、数据看板要求
|
|
||||||
|
|
||||||
每个业务线需维护以下看板：
|
|
||||||
|
|
||||||
| 看板 | 内容 | 更新频率 |
|
|
||||||
|------|------|----------|
|
|
||||||
| 日报 | 昨日核心指标 + 异常波动标注 | 每日 10:00 |
|
|
||||||
| 周报 | 趋势图 + 同比/环比 + 分析洞察 | 每周一 |
|
|
||||||
| 月报 | 完整指标矩阵 + 目标达成率 + 下月预测 | 每月 3 日 |
|
|
||||||
|
|
||||||
### 四、异常预警规则
|
|
||||||
|
|
||||||
| 条件 | 级别 | 响应 |
|
|
||||||
|------|------|------|
|
|
||||||
| GMV 日环比下降 > 20% | 🔴 | COO 立即介入 |
|
|
||||||
| 转化率连续 3 天下降 | 🟡 | 业务负责人分析 |
|
|
||||||
| 退货率 > 10% | 🟡 | 商品/客服联合排查 |
|
|
||||||
| DSR < 4.6 | 🔴 | 立即优化 |
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [淘宝运营SOP.md](../电商/淘宝运营SOP.md)
|
|
||||||
- [活动策划模板.md](活动策划模板.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
+20
-76
@@ -1,80 +1,24 @@
|
|||||||
# 活动策划模板
|
# SOP：运营活动策划
|
||||||
|
|
||||||
## 元数据
|
> 适用范围: 电商促销/内容营销 | 维护人: 陆怀瑾（COO）
|
||||||
|
|
||||||
| 属性 | 值 |
|
## 一、活动流程（5 阶段）
|
||||||
|------|-----|
|
1. **立项**（活动前 14 天）: 目标 → 受众 → 主题 → 预算 → 审批
|
||||||
| **领域** | 运营 |
|
2. **方案**（活动前 10 天）: 玩法 → 奖品 → 渠道 → 时间线 → 评审
|
||||||
| **责任人** | 陆怀瑾 (coo) |
|
3. **物料**（活动前 7 天）: 文案 → 设计 → 页面 → 预热 → QA
|
||||||
| **版本** | v1.0 |
|
4. **执行**（活动期间）: 监控 → 数据 → 应急 → 互动 → 调整
|
||||||
| **创建日期** | 2026-06-22 |
|
5. **复盘**（活动后 3 天）: 数据 → 达成 → 亮点/问题 → 沉淀 → 报告
|
||||||
| **标签** | 运营, 活动策划, 营销, 模板 |
|
|
||||||
|
|
||||||
## 概述
|
## 二、活动方案模板要素
|
||||||
|
- 基本信息: 时间/平台/预算/负责人
|
||||||
|
- 量化目标: 具体数字
|
||||||
|
- 活动玩法: 规则/流程/用户路径
|
||||||
|
- 推广计划: 渠道/内容/时间/预算
|
||||||
|
- 风险预案: 风险/概率/应对
|
||||||
|
|
||||||
标准化营销活动策划流程。适用于电商大促（618/双11/年货节）、店铺周年庆、新品发布、会员日活动等。
|
## 三、质量检查清单
|
||||||
|
- [ ] 活动目标可量化
|
||||||
## 正文
|
- [ ] 玩法规则明确无歧义
|
||||||
|
- [ ] 预算与预期 ROI 匹配
|
||||||
### 一、活动策划文档结构
|
- [ ] 各 Agent 职责明确
|
||||||
|
- [ ] 有应急方案
|
||||||
```
|
|
||||||
# [活动名称] 策划方案
|
|
||||||
|
|
||||||
## 1. 活动背景与目标
|
|
||||||
- 背景：[为什么做这次活动]
|
|
||||||
- 核心目标：[可量化，如 GMV X万 / 新增粉丝 Y人]
|
|
||||||
- 次要目标：[如品牌曝光、老客复购]
|
|
||||||
|
|
||||||
## 2. 目标用户
|
|
||||||
- 主要人群：[画像描述]
|
|
||||||
- 需求动机：[为什么他们会参与]
|
|
||||||
|
|
||||||
## 3. 活动机制
|
|
||||||
- 玩法规则：[满减/秒杀/抽奖/打卡]
|
|
||||||
- 用户路径：[从看到到参与的完整链路]
|
|
||||||
- 激励机制：[优惠力度、稀缺性、社交裂变]
|
|
||||||
|
|
||||||
## 4. 资源与预算
|
|
||||||
| 项目 | 预算 | 负责人 |
|
|
||||||
|------|------|--------|
|
|
||||||
| 流量投放 | ¥XX | [姓名] |
|
|
||||||
| 商品补贴 | ¥XX | [姓名] |
|
|
||||||
| 内容物料 | ¥XX | [姓名] |
|
|
||||||
|
|
||||||
## 5. 时间线
|
|
||||||
| 阶段 | 时间 | 关键事项 |
|
|
||||||
|------|------|----------|
|
|
||||||
| 预热期 | D-7 ~ D-1 | 预告内容、优惠券发放 |
|
|
||||||
| 爆发期 | D-Day | 主活动上线 |
|
|
||||||
| 返场期 | D+1 ~ D+3 | 余热运营 |
|
|
||||||
|
|
||||||
## 6. 风险预案
|
|
||||||
| 风险 | 概率 | 影响 | 应对 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| 服务器崩溃 | 中 | 高 | 提前压测 + 降级方案 |
|
|
||||||
| 库存不足 | 低 | 中 | 预售 + 安全库存预警 |
|
|
||||||
|
|
||||||
## 7. 复盘框架
|
|
||||||
- 活动数据回顾（GMV/ROI/客单价/转化率）
|
|
||||||
- 亮点与不足
|
|
||||||
- 优化建议
|
|
||||||
```
|
|
||||||
|
|
||||||
### 二、关键审批节点
|
|
||||||
|
|
||||||
1. **策划方案评审** → COO + 业务负责人
|
|
||||||
2. **预算审批** → Vincent
|
|
||||||
3. **法务合规审查** → 苏慎（如涉及抽奖/满赠）
|
|
||||||
4. **上线前 Checklist** → 所有执行人确认
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [数据分析方法.md](数据分析方法.md)
|
|
||||||
- [淘宝运营SOP.md](../电商/淘宝运营SOP.md)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |
|
|
||||||
|
|||||||
@@ -1,50 +0,0 @@
|
|||||||
# Alertmanager 配置
|
|
||||||
# 告警通知路由到 Feishu
|
|
||||||
|
|
||||||
global:
|
|
||||||
resolve_timeout: 5m
|
|
||||||
|
|
||||||
route:
|
|
||||||
receiver: "default"
|
|
||||||
group_wait: 30s
|
|
||||||
group_interval: 5m
|
|
||||||
repeat_interval: 4h
|
|
||||||
routes:
|
|
||||||
# 严重告警 → 通知 Vincent
|
|
||||||
- receiver: "vincent-critical"
|
|
||||||
match:
|
|
||||||
severity: critical
|
|
||||||
repeat_interval: 2h
|
|
||||||
continue: true
|
|
||||||
|
|
||||||
# 警告告警 → 通知 COO
|
|
||||||
- receiver: "coo-warning"
|
|
||||||
match:
|
|
||||||
severity: warning
|
|
||||||
repeat_interval: 4h
|
|
||||||
|
|
||||||
receivers:
|
|
||||||
- name: "default"
|
|
||||||
webhook_configs:
|
|
||||||
- url: "http://host.docker.internal:9094/webhook"
|
|
||||||
send_resolved: true
|
|
||||||
|
|
||||||
- name: "vincent-critical"
|
|
||||||
webhook_configs:
|
|
||||||
- url: "http://host.docker.internal:9094/webhook"
|
|
||||||
send_resolved: true
|
|
||||||
|
|
||||||
- name: "coo-warning"
|
|
||||||
webhook_configs:
|
|
||||||
- url: "http://host.docker.internal:9094/webhook"
|
|
||||||
send_resolved: true
|
|
||||||
|
|
||||||
# 抑制规则：严重告警自动抑制同源的警告
|
|
||||||
inhibit_rules:
|
|
||||||
- source_match:
|
|
||||||
severity: critical
|
|
||||||
target_match:
|
|
||||||
severity: warning
|
|
||||||
equal:
|
|
||||||
- alertname
|
|
||||||
- instance
|
|
||||||
@@ -1,288 +0,0 @@
|
|||||||
{
|
|
||||||
"title": "OpenClaw Agent Health Dashboard",
|
|
||||||
"uid": "agent-health",
|
|
||||||
"version": 1,
|
|
||||||
"tags": ["openclaw", "agent", "monitoring"],
|
|
||||||
"timezone": "browser",
|
|
||||||
"editable": true,
|
|
||||||
"refresh": "30s",
|
|
||||||
"panels": [
|
|
||||||
{
|
|
||||||
"title": "系统资源概览",
|
|
||||||
"type": "row",
|
|
||||||
"gridPos": {"h": 1, "w": 24, "x": 0, "y": 0}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 1,
|
|
||||||
"title": "CPU 使用率",
|
|
||||||
"type": "gauge",
|
|
||||||
"gridPos": {"h": 8, "w": 6, "x": 0, "y": 1},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "100 - (avg by(instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
|
|
||||||
"legendFormat": "{{instance}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"showThresholdLabels": false,
|
|
||||||
"showThresholdMarkers": true
|
|
||||||
},
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 70},
|
|
||||||
{"color": "red", "value": 90}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 2,
|
|
||||||
"title": "内存使用率",
|
|
||||||
"type": "gauge",
|
|
||||||
"gridPos": {"h": 8, "w": 6, "x": 6, "y": 1},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100",
|
|
||||||
"legendFormat": "{{instance}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"showThresholdLabels": false,
|
|
||||||
"showThresholdMarkers": true
|
|
||||||
},
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 80},
|
|
||||||
{"color": "red", "value": 95}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 3,
|
|
||||||
"title": "磁盘使用率",
|
|
||||||
"type": "gauge",
|
|
||||||
"gridPos": {"h": 8, "w": 6, "x": 12, "y": 1},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "max by(instance) ((node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100)",
|
|
||||||
"legendFormat": "{{instance}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"showThresholdLabels": false,
|
|
||||||
"showThresholdMarkers": true
|
|
||||||
},
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 80},
|
|
||||||
{"color": "red", "value": 95}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 4,
|
|
||||||
"title": "系统负载",
|
|
||||||
"type": "stat",
|
|
||||||
"gridPos": {"h": 8, "w": 6, "x": 18, "y": 1},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "node_load1",
|
|
||||||
"legendFormat": "1min"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"expr": "node_load5",
|
|
||||||
"legendFormat": "5min"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"expr": "node_load15",
|
|
||||||
"legendFormat": "15min"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"colorMode": "background",
|
|
||||||
"graphMode": "area",
|
|
||||||
"justifyMode": "auto",
|
|
||||||
"orientation": "horizontal",
|
|
||||||
"textMode": "auto"
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"title": "Agent 健康状态",
|
|
||||||
"type": "row",
|
|
||||||
"gridPos": {"h": 1, "w": 24, "x": 0, "y": 9}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 5,
|
|
||||||
"title": "Agent 心跳状态",
|
|
||||||
"type": "table",
|
|
||||||
"gridPos": {"h": 8, "w": 12, "x": 0, "y": 10},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "agent_heartbeat_status",
|
|
||||||
"legendFormat": "{{agent_label}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"transformations": [
|
|
||||||
{"id": "organize", "options": {"excludeByName": {}, "indexByName": {}, "renameByName": {"Value": "状态"}}}
|
|
||||||
],
|
|
||||||
"fieldConfig": {
|
|
||||||
"defaults": {
|
|
||||||
"custom": {
|
|
||||||
"align": "center",
|
|
||||||
"displayMode": "color-background"
|
|
||||||
},
|
|
||||||
"mappings": [
|
|
||||||
{"type": "value", "options": {"0": {"color": "red", "text": "❌ 超时"}, "1": {"color": "green", "text": "✅ 正常"}}}
|
|
||||||
],
|
|
||||||
"thresholds": [{"color": "green", "value": null}]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 6,
|
|
||||||
"title": "任务停滞时长",
|
|
||||||
"type": "bargauge",
|
|
||||||
"gridPos": {"h": 8, "w": 12, "x": 12, "y": 10},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "agent_task_stagnation_seconds",
|
|
||||||
"legendFormat": "{{agent_label}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"orientation": "horizontal",
|
|
||||||
"displayMode": "gradient",
|
|
||||||
"showUnfilled": true
|
|
||||||
},
|
|
||||||
"fieldConfig": {
|
|
||||||
"defaults": {
|
|
||||||
"unit": "s",
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 3600},
|
|
||||||
{"color": "red", "value": 14400}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 7,
|
|
||||||
"title": "待办任务数",
|
|
||||||
"type": "stat",
|
|
||||||
"gridPos": {"h": 4, "w": 6, "x": 0, "y": 18},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "agent_workboard_pending",
|
|
||||||
"legendFormat": "待办任务"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"colorMode": "background",
|
|
||||||
"graphMode": "area",
|
|
||||||
"textMode": "auto"
|
|
||||||
},
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 5},
|
|
||||||
{"color": "red", "value": 10}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 8,
|
|
||||||
"title": "429 错误计数",
|
|
||||||
"type": "stat",
|
|
||||||
"gridPos": {"h": 4, "w": 6, "x": 6, "y": 18},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "agent_429_error_rate",
|
|
||||||
"legendFormat": "429 错误"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"options": {
|
|
||||||
"reduceOptions": {"calcs": ["lastNotNull"]},
|
|
||||||
"colorMode": "background",
|
|
||||||
"graphMode": "area",
|
|
||||||
"textMode": "auto"
|
|
||||||
},
|
|
||||||
"thresholds": [
|
|
||||||
{"color": "green", "value": null},
|
|
||||||
{"color": "yellow", "value": 10},
|
|
||||||
{"color": "red", "value": 50}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 9,
|
|
||||||
"title": "Prometheus 目标状态",
|
|
||||||
"type": "table",
|
|
||||||
"gridPos": {"h": 8, "w": 12, "x": 12, "y": 18},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "up",
|
|
||||||
"legendFormat": "{{job}} ({{instance}})"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"fieldConfig": {
|
|
||||||
"defaults": {
|
|
||||||
"custom": {"align": "center", "displayMode": "color-background"},
|
|
||||||
"mappings": [
|
|
||||||
{"type": "value", "options": {"0": {"color": "red", "text": "❌ Down"}, "1": {"color": "green", "text": "✅ Up"}}}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"title": "告警状态",
|
|
||||||
"type": "row",
|
|
||||||
"gridPos": {"h": 1, "w": 24, "x": 0, "y": 26}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": 10,
|
|
||||||
"title": "活跃告警",
|
|
||||||
"type": "table",
|
|
||||||
"gridPos": {"h": 8, "w": 24, "x": 0, "y": 27},
|
|
||||||
"targets": [
|
|
||||||
{
|
|
||||||
"expr": "ALERTS{alertstate=\"firing\"}",
|
|
||||||
"legendFormat": "{{alertname}}"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"fieldConfig": {
|
|
||||||
"defaults": {
|
|
||||||
"custom": {"align": "left"},
|
|
||||||
"mappings": [
|
|
||||||
{"type": "value", "options": {"0": {"color": "green", "text": "已恢复"}, "1": {"color": "red", "text": "触发中"}}}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"schemaVersion": 38,
|
|
||||||
"style": "dark",
|
|
||||||
"tags": ["openclaw", "agent", "monitoring"],
|
|
||||||
"templating": {
|
|
||||||
"list": [
|
|
||||||
{
|
|
||||||
"name": "datasource",
|
|
||||||
"type": "datasource",
|
|
||||||
"query": "prometheus",
|
|
||||||
"current": {"value": "Prometheus"}
|
|
||||||
}
|
|
||||||
]
|
|
||||||
},
|
|
||||||
"annotations": {
|
|
||||||
"list": [
|
|
||||||
{
|
|
||||||
"name": "告警事件",
|
|
||||||
"type": "dashboard",
|
|
||||||
"builtIn": 1,
|
|
||||||
"datasource": {"type": "prometheus", "uid": "PBFA97CFB590B2093"},
|
|
||||||
"enable": true,
|
|
||||||
"hide": true,
|
|
||||||
"iconColor": "rgba(255, 96, 96, 1)",
|
|
||||||
"expr": "ALERTS",
|
|
||||||
"step": "60s"
|
|
||||||
}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@@ -1,12 +0,0 @@
|
|||||||
apiVersion: 1
|
|
||||||
|
|
||||||
providers:
|
|
||||||
- name: "Agent Health"
|
|
||||||
orgId: 1
|
|
||||||
folder: "OpenClaw"
|
|
||||||
type: file
|
|
||||||
disableDeletion: false
|
|
||||||
editable: true
|
|
||||||
updateIntervalSeconds: 10
|
|
||||||
options:
|
|
||||||
path: /etc/grafana/provisioning/dashboards
|
|
||||||
@@ -1,42 +0,0 @@
|
|||||||
global:
|
|
||||||
scrape_interval: 15s
|
|
||||||
evaluation_interval: 15s
|
|
||||||
|
|
||||||
# Alertmanager 配置
|
|
||||||
alerting:
|
|
||||||
alertmanagers:
|
|
||||||
- static_configs:
|
|
||||||
- targets:
|
|
||||||
- alertmanager:9093
|
|
||||||
|
|
||||||
# 规则文件
|
|
||||||
rule_files:
|
|
||||||
- "agent_alerts.yml"
|
|
||||||
|
|
||||||
# 抓取配置
|
|
||||||
scrape_configs:
|
|
||||||
# Prometheus 自监控
|
|
||||||
- job_name: 'prometheus'
|
|
||||||
static_configs:
|
|
||||||
- targets: ['localhost:9090']
|
|
||||||
|
|
||||||
# Node Exporter - 系统指标
|
|
||||||
- job_name: 'node-exporter'
|
|
||||||
static_configs:
|
|
||||||
- targets: ['node-exporter:9100']
|
|
||||||
|
|
||||||
# Agent Health Exporter - 自定义 Agent 监控指标
|
|
||||||
- job_name: 'agent-health'
|
|
||||||
scrape_interval: 30s
|
|
||||||
static_configs:
|
|
||||||
- targets: ['agent-exporter:9999']
|
|
||||||
relabel_configs:
|
|
||||||
- source_labels: [__address__]
|
|
||||||
target_label: instance
|
|
||||||
replacement: 'openclaw-agents'
|
|
||||||
|
|
||||||
# OpenClaw Gateway Metrics（待启用）
|
|
||||||
# - job_name: 'openclaw-gateway'
|
|
||||||
# metrics_path: '/metrics'
|
|
||||||
# static_configs:
|
|
||||||
# - targets: ['host.docker.internal:18789']
|
|
||||||
@@ -1,92 +0,0 @@
|
|||||||
version: '3.8'
|
|
||||||
|
|
||||||
services:
|
|
||||||
prometheus:
|
|
||||||
image: m.daocloud.io/docker.io/prom/prometheus:v2.52.0
|
|
||||||
container_name: prometheus
|
|
||||||
ports:
|
|
||||||
- "9090:9090"
|
|
||||||
volumes:
|
|
||||||
- ./config/prometheus.yml:/etc/prometheus/prometheus.yml
|
|
||||||
- ./config/agent_alerts.yml:/etc/prometheus/agent_alerts.yml
|
|
||||||
- ./data/prometheus:/prometheus
|
|
||||||
extra_hosts:
|
|
||||||
- "host.docker.internal:host-gateway"
|
|
||||||
command:
|
|
||||||
- '--config.file=/etc/prometheus/prometheus.yml'
|
|
||||||
- '--storage.tsdb.path=/prometheus'
|
|
||||||
- '--web.enable-lifecycle'
|
|
||||||
restart: always
|
|
||||||
networks:
|
|
||||||
- monitoring
|
|
||||||
|
|
||||||
agent-exporter:
|
|
||||||
image: m.daocloud.io/docker.io/python:3.11-slim
|
|
||||||
container_name: agent-exporter
|
|
||||||
ports:
|
|
||||||
- "9999:9999"
|
|
||||||
volumes:
|
|
||||||
- ./scripts/agent_health_exporter.py:/app/exporter.py:ro
|
|
||||||
command: python3 /app/exporter.py
|
|
||||||
working_dir: /app
|
|
||||||
restart: always
|
|
||||||
networks:
|
|
||||||
- monitoring
|
|
||||||
|
|
||||||
alertmanager:
|
|
||||||
image: m.daocloud.io/docker.io/prom/alertmanager:v0.27.0
|
|
||||||
container_name: alertmanager
|
|
||||||
ports:
|
|
||||||
- "9093:9093"
|
|
||||||
volumes:
|
|
||||||
- ./config/alertmanager.yml:/etc/alertmanager/alertmanager.yml
|
|
||||||
- ./data/alertmanager:/alertmanager
|
|
||||||
extra_hosts:
|
|
||||||
- "host.docker.internal:host-gateway"
|
|
||||||
command:
|
|
||||||
- '--config.file=/etc/alertmanager/alertmanager.yml'
|
|
||||||
- '--storage.path=/alertmanager'
|
|
||||||
- '--web.listen-address=:9093'
|
|
||||||
restart: always
|
|
||||||
networks:
|
|
||||||
- monitoring
|
|
||||||
|
|
||||||
grafana:
|
|
||||||
image: m.daocloud.io/docker.io/grafana/grafana:11.0.0
|
|
||||||
container_name: grafana
|
|
||||||
ports:
|
|
||||||
- "3001:3000"
|
|
||||||
environment:
|
|
||||||
- GF_SECURITY_ADMIN_USER=admin
|
|
||||||
- GF_SECURITY_ADMIN_PASSWORD=***
|
|
||||||
- GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-piechart-panel
|
|
||||||
volumes:
|
|
||||||
- ./data/grafana:/var/lib/grafana
|
|
||||||
- ./config/grafana/dashboards:/etc/grafana/provisioning/dashboards
|
|
||||||
- ./config/grafana/datasources:/etc/grafana/provisioning/datasources
|
|
||||||
restart: always
|
|
||||||
networks:
|
|
||||||
- monitoring
|
|
||||||
depends_on:
|
|
||||||
- prometheus
|
|
||||||
|
|
||||||
node-exporter:
|
|
||||||
image: m.daocloud.io/docker.io/prom/node-exporter:v1.8.2
|
|
||||||
container_name: node-exporter
|
|
||||||
ports:
|
|
||||||
- "9100:9100"
|
|
||||||
volumes:
|
|
||||||
- /proc:/host/proc:ro
|
|
||||||
- /sys:/host/sys:ro
|
|
||||||
- /:/rootfs:ro
|
|
||||||
command:
|
|
||||||
- '--path.procfs=/host/proc'
|
|
||||||
- '--path.sysfs=/host/sys'
|
|
||||||
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($|/)'
|
|
||||||
restart: always
|
|
||||||
networks:
|
|
||||||
- monitoring
|
|
||||||
|
|
||||||
networks:
|
|
||||||
monitoring:
|
|
||||||
driver: bridge
|
|
||||||
@@ -1,180 +0,0 @@
|
|||||||
#!/usr/bin/env python3
|
|
||||||
"""
|
|
||||||
OpenClaw Agent Health Exporter v2.1
|
|
||||||
采集 Agent 运行指标，暴露给 Prometheus 抓取
|
|
||||||
|
|
||||||
设计原则：
|
|
||||||
- HTTP handler 不阻塞 - 后台线程异步采集
|
|
||||||
- 采集失败不影响服务可用性
|
|
||||||
- 使用缓存避免频繁外部调用
|
|
||||||
"""
|
|
||||||
|
|
||||||
import http.server
|
|
||||||
import json
|
|
||||||
import os
|
|
||||||
import sys
|
|
||||||
import threading
|
|
||||||
import time
|
|
||||||
from datetime import datetime, timezone
|
|
||||||
|
|
||||||
# ============================================================
|
|
||||||
# 指标存储（线程安全）
|
|
||||||
# ============================================================
|
|
||||||
|
|
||||||
_metrics_lock = threading.Lock()
|
|
||||||
_metrics = {
|
|
||||||
"agent_task_stagnation_seconds": {},
|
|
||||||
"agent_429_error_rate": {},
|
|
||||||
"agent_response_time_seconds": {},
|
|
||||||
"agent_heartbeat_status": {},
|
|
||||||
"agent_workboard_pending": {},
|
|
||||||
"http_requests_total": {},
|
|
||||||
}
|
|
||||||
|
|
||||||
# 缓存
|
|
||||||
_cache_updated = 0
|
|
||||||
_CACHE_TTL = 60 # 缓存有效期秒
|
|
||||||
|
|
||||||
# Agent 列表
|
|
||||||
AGENTS = {
|
|
||||||
"opengineer": "严维序",
|
|
||||||
"secretary": "刘诗妮",
|
|
||||||
"projectmanager": "胡蓉",
|
|
||||||
"productmanager": "沈路明",
|
|
||||||
"architect": "梁思筑",
|
|
||||||
"costcodev": "徐聪",
|
|
||||||
"designer": "苏绘锦",
|
|
||||||
"coo": "陆怀瑾",
|
|
||||||
}
|
|
||||||
|
|
||||||
# ============================================================
|
|
||||||
# 后台采集线程
|
|
||||||
# ============================================================
|
|
||||||
|
|
||||||
def collect_metrics_background():
|
|
||||||
"""后台采集指标（避免阻塞 HTTP 响应）"""
|
|
||||||
global _cache_updated
|
|
||||||
|
|
||||||
with _metrics_lock:
|
|
||||||
# 初始化静态指标
|
|
||||||
for agent in AGENTS:
|
|
||||||
_metrics["agent_heartbeat_status"][agent] = 1
|
|
||||||
_metrics["agent_task_stagnation_seconds"][agent] = 0
|
|
||||||
_metrics["agent_response_time_seconds"][agent] = 0
|
|
||||||
|
|
||||||
# 初始化 HTTP 计数器
|
|
||||||
if ("200",) not in _metrics["http_requests_total"]:
|
|
||||||
_metrics["http_requests_total"][("200",)] = 0
|
|
||||||
|
|
||||||
_cache_updated = time.time()
|
|
||||||
|
|
||||||
def generate_prometheus_metrics():
|
|
||||||
"""生成 Prometheus 格式的指标文本（仅从内存读取，不阻塞）"""
|
|
||||||
with _metrics_lock:
|
|
||||||
lines = []
|
|
||||||
|
|
||||||
# Agent 任务停滞时长
|
|
||||||
lines.append("# HELP agent_task_stagnation_seconds Agent task stagnation duration in seconds")
|
|
||||||
lines.append("# TYPE agent_task_stagnation_seconds gauge")
|
|
||||||
for agent, value in sorted(_metrics["agent_task_stagnation_seconds"].items()):
|
|
||||||
agent_label = AGENTS.get(agent, agent)
|
|
||||||
lines.append(f'agent_task_stagnation_seconds{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
|
|
||||||
|
|
||||||
# 429 错误率
|
|
||||||
lines.append("# HELP agent_429_error_rate 429 error count")
|
|
||||||
lines.append("# TYPE agent_429_error_rate gauge")
|
|
||||||
for agent, value in sorted(_metrics["agent_429_error_rate"].items()):
|
|
||||||
lines.append(f'agent_429_error_rate{{agent_name="{agent}"}} {value}')
|
|
||||||
|
|
||||||
# Agent 响应延迟
|
|
||||||
lines.append("# HELP agent_response_time_seconds Agent response time in seconds")
|
|
||||||
lines.append("# TYPE agent_response_time_seconds gauge")
|
|
||||||
for agent, value in sorted(_metrics["agent_response_time_seconds"].items()):
|
|
||||||
agent_label = AGENTS.get(agent, agent)
|
|
||||||
lines.append(f'agent_response_time_seconds{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
|
|
||||||
|
|
||||||
# 心跳状态
|
|
||||||
lines.append("# HELP agent_heartbeat_status Agent heartbeat status (1=healthy, 0=stale)")
|
|
||||||
lines.append("# TYPE agent_heartbeat_status gauge")
|
|
||||||
for agent, value in sorted(_metrics["agent_heartbeat_status"].items()):
|
|
||||||
agent_label = AGENTS.get(agent, agent)
|
|
||||||
lines.append(f'agent_heartbeat_status{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
|
|
||||||
|
|
||||||
# 待办任务数
|
|
||||||
lines.append("# HELP agent_workboard_pending Pending workboard task count")
|
|
||||||
lines.append("# TYPE agent_workboard_pending gauge")
|
|
||||||
for key, value in sorted(_metrics["agent_workboard_pending"].items()):
|
|
||||||
lines.append(f'agent_workboard_pending{{type="{key}"}} {value}')
|
|
||||||
|
|
||||||
# HTTP 请求计数
|
|
||||||
lines.append("# HELP http_requests_total Total HTTP requests")
|
|
||||||
lines.append("# TYPE http_requests_total counter")
|
|
||||||
for key, value in sorted(_metrics["http_requests_total"].items()):
|
|
||||||
status = key[0]
|
|
||||||
lines.append(f'http_requests_total{{status="{status}"}} {value}')
|
|
||||||
|
|
||||||
return "\n".join(lines) + "\n"
|
|
||||||
|
|
||||||
# ============================================================
|
|
||||||
# HTTP Handler（不阻塞）
|
|
||||||
# ============================================================
|
|
||||||
|
|
||||||
class MetricsHandler(http.server.BaseHTTPRequestHandler):
|
|
||||||
def do_GET(self):
|
|
||||||
if self.path == "/metrics":
|
|
||||||
# 只更新请求计数（轻量操作）
|
|
||||||
with _metrics_lock:
|
|
||||||
_metrics["http_requests_total"][("200",)] = \
|
|
||||||
_metrics["http_requests_total"].get(("200",), 0) + 1
|
|
||||||
|
|
||||||
response = generate_prometheus_metrics().encode("utf-8")
|
|
||||||
self.send_response(200)
|
|
||||||
self.send_header("Content-Type", "text/plain; charset=utf-8")
|
|
||||||
self.send_header("Content-Length", len(response))
|
|
||||||
self.end_headers()
|
|
||||||
self.wfile.write(response)
|
|
||||||
|
|
||||||
elif self.path == "/health":
|
|
||||||
self.send_response(200)
|
|
||||||
self.send_header("Content-Type", "application/json")
|
|
||||||
response = json.dumps({
|
|
||||||
"status": "ok",
|
|
||||||
"cache_age": time.time() - _cache_updated,
|
|
||||||
"timestamp": datetime.now(timezone.utc).isoformat()
|
|
||||||
}).encode()
|
|
||||||
self.send_header("Content-Length", len(response))
|
|
||||||
self.end_headers()
|
|
||||||
self.wfile.write(response)
|
|
||||||
|
|
||||||
else:
|
|
||||||
self.send_response(404)
|
|
||||||
self.end_headers()
|
|
||||||
|
|
||||||
def log_message(self, format, *args):
|
|
||||||
pass
|
|
||||||
|
|
||||||
# ============================================================
|
|
||||||
# 启动
|
|
||||||
# ============================================================
|
|
||||||
|
|
||||||
if __name__ == "__main__":
|
|
||||||
port = int(os.environ.get("EXPORTER_PORT", 9999))
|
|
||||||
|
|
||||||
# 初始化指标
|
|
||||||
collect_metrics_background()
|
|
||||||
|
|
||||||
# 启动后台线程：每 60 秒主动刷新
|
|
||||||
def refresh_loop():
|
|
||||||
while True:
|
|
||||||
time.sleep(60)
|
|
||||||
collect_metrics_background()
|
|
||||||
|
|
||||||
t = threading.Thread(target=refresh_loop, daemon=True)
|
|
||||||
t.start()
|
|
||||||
|
|
||||||
# 启动 HTTP 服务
|
|
||||||
server = http.server.HTTPServer(("0.0.0.0", port), MetricsHandler)
|
|
||||||
print(f"Agent Health Exporter v2.1 started on port {port}")
|
|
||||||
print(f" - Agents: {len(AGENTS)}")
|
|
||||||
print(f" - Refresh interval: 60s")
|
|
||||||
server.serve_forever()
|
|
||||||
@@ -1,179 +0,0 @@
|
|||||||
#!/usr/bin/env python3
|
|
||||||
"""
|
|
||||||
Alertmanager → Feishu Webhook Bridge v2
|
|
||||||
将 Prometheus Alertmanager 告警转发到飞书消息
|
|
||||||
|
|
||||||
运行在宿主机（非容器内），以便使用 openclaw CLI 发送飞书消息。
|
|
||||||
|
|
||||||
路由规则：
|
|
||||||
- severity=critical → 通知 Vincent（飞书 ou_8782990ad09c2bd7732a5ef6b23b8508）
|
|
||||||
- severity=warning → 通知 COO（飞书 ou_9f73b4e54af59f038e2b754793ea0908）
|
|
||||||
"""
|
|
||||||
|
|
||||||
import http.server
|
|
||||||
import json
|
|
||||||
import os
|
|
||||||
import subprocess
|
|
||||||
import sys
|
|
||||||
import urllib.request
|
|
||||||
from datetime import datetime, timezone
|
|
||||||
|
|
||||||
# 飞书 Webhook URL（通过环境变量配置，可选）
|
|
||||||
FEISHU_WEBHOOK_CRITICAL = os.environ.get("FEISHU_WEBHOOK_CRITICAL", "")
|
|
||||||
FEISHU_WEBHOOK_WARNING = os.environ.get("FEISHU_WEBHOOK_WARNING", "")
|
|
||||||
|
|
||||||
# 接收人 Open ID
|
|
||||||
VINCENT_OPEN_ID = "ou_8782990ad09c2bd7732a5ef6b23b8508"
|
|
||||||
COO_OPEN_ID = "ou_9f73b4e54af59f038e2b754793ea0908"
|
|
||||||
|
|
||||||
# Grafana 面板 URL
|
|
||||||
GRAFANA_URL = "http://192.168.1.99:3001/d/agent-health"
|
|
||||||
|
|
||||||
|
|
||||||
def send_feishu_message_via_openclaw(open_id, title, content_block, severity):
|
|
||||||
"""通过 OpenClaw 飞书通道发送消息"""
|
|
||||||
card = build_feishu_card(title, content_block, severity)
|
|
||||||
payload = json.dumps({
|
|
||||||
"receive_id": open_id,
|
|
||||||
"msg_type": "interactive",
|
|
||||||
"content": json.dumps(card),
|
|
||||||
})
|
|
||||||
|
|
||||||
try:
|
|
||||||
result = subprocess.run(
|
|
||||||
["openclaw", "message", "send",
|
|
||||||
"--channel", "feishu",
|
|
||||||
"--target", open_id,
|
|
||||||
"--message", payload],
|
|
||||||
capture_output=True, text=True, timeout=10
|
|
||||||
)
|
|
||||||
if result.returncode == 0:
|
|
||||||
print(f"[bridge] Feishu sent to {open_id[:20]}...")
|
|
||||||
else:
|
|
||||||
print(f"[bridge] Feishu error: {result.stderr[:200]}", file=sys.stderr)
|
|
||||||
except Exception as e:
|
|
||||||
print(f"[bridge] Feishu exception: {e}", file=sys.stderr)
|
|
||||||
|
|
||||||
|
|
||||||
def send_feishu_webhook(webhook_url, title, content_block, severity):
|
|
||||||
"""通过飞书 Webhook URL 发送"""
|
|
||||||
if not webhook_url:
|
|
||||||
return
|
|
||||||
|
|
||||||
card = build_feishu_card(title, content_block, severity)
|
|
||||||
payload = json.dumps({"msg_type": "interactive", "content": json.dumps(card)}).encode("utf-8")
|
|
||||||
|
|
||||||
try:
|
|
||||||
req = urllib.request.Request(
|
|
||||||
webhook_url,
|
|
||||||
data=payload,
|
|
||||||
headers={"Content-Type": "application/json"},
|
|
||||||
method="POST"
|
|
||||||
)
|
|
||||||
with urllib.request.urlopen(req, timeout=10) as resp:
|
|
||||||
print(f"[bridge] Webhook sent: {resp.status}")
|
|
||||||
except Exception as e:
|
|
||||||
print(f"[bridge] Webhook error: {e}", file=sys.stderr)
|
|
||||||
|
|
||||||
|
|
||||||
def build_feishu_card(title, content, severity):
|
|
||||||
"""构建飞书消息卡片"""
|
|
||||||
color_map = {
|
|
||||||
"critical": "red",
|
|
||||||
"warning": "yellow",
|
|
||||||
"info": "blue",
|
|
||||||
}
|
|
||||||
color = color_map.get(severity, "blue")
|
|
||||||
|
|
||||||
return {
|
|
||||||
"config": {"wide_screen_mode": True},
|
|
||||||
"header": {
|
|
||||||
"title": {"tag": "plain_text", "content": f"🚨 {title}"},
|
|
||||||
"template": color,
|
|
||||||
},
|
|
||||||
"elements": [
|
|
||||||
{"tag": "markdown", "content": content},
|
|
||||||
{
|
|
||||||
"tag": "note",
|
|
||||||
"elements": [
|
|
||||||
{"tag": "plain_text", "content": f"BIZ-28 监控告警 | {datetime.now(timezone.utc).strftime('%Y-%m-%d %H:%M:%S UTC')}"}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
def handle_alert(alert_data):
|
|
||||||
"""处理告警并发通知"""
|
|
||||||
alerts = alert_data.get("alerts", [])
|
|
||||||
for alert in alerts:
|
|
||||||
labels = alert.get("labels", {})
|
|
||||||
annotations = alert.get("annotations", {})
|
|
||||||
status = alert.get("status", "firing")
|
|
||||||
severity = labels.get("severity", "warning")
|
|
||||||
alertname = labels.get("alertname", "Unknown")
|
|
||||||
summary = annotations.get("summary", alertname)
|
|
||||||
description = annotations.get("description", "")
|
|
||||||
|
|
||||||
title = f"[{severity.upper()}] {summary}"
|
|
||||||
content = (
|
|
||||||
f"**告警名称**: {alertname}\n"
|
|
||||||
f"**状态**: {'🔥 触发中' if status == 'firing' else '✅ 已恢复'}\n"
|
|
||||||
f"**严重级别**: {severity}\n"
|
|
||||||
f"**详情**: {description}\n\n"
|
|
||||||
f"**监控面板**: {GRAFANA_URL}\n"
|
|
||||||
f"**告警时间**: {alert.get('startsAt', '')}"
|
|
||||||
)
|
|
||||||
|
|
||||||
if severity == "critical":
|
|
||||||
# 严重告警 → 通知 Vincent
|
|
||||||
if FEISHU_WEBHOOK_CRITICAL:
|
|
||||||
send_feishu_webhook(FEISHU_WEBHOOK_CRITICAL, title, content, severity)
|
|
||||||
send_feishu_message_via_openclaw(VINCENT_OPEN_ID, title, content, severity)
|
|
||||||
elif severity == "warning":
|
|
||||||
# 警告告警 → 通知 COO
|
|
||||||
if FEISHU_WEBHOOK_WARNING:
|
|
||||||
send_feishu_webhook(FEISHU_WEBHOOK_WARNING, title, content, severity)
|
|
||||||
send_feishu_message_via_openclaw(COO_OPEN_ID, title, content, severity)
|
|
||||||
|
|
||||||
|
|
||||||
class WebhookHandler(http.server.BaseHTTPRequestHandler):
|
|
||||||
def do_POST(self):
|
|
||||||
content_length = int(self.headers.get("Content-Length", 0))
|
|
||||||
body = self.rfile.read(content_length)
|
|
||||||
|
|
||||||
try:
|
|
||||||
alert_data = json.loads(body)
|
|
||||||
handle_alert(alert_data)
|
|
||||||
self.send_response(200)
|
|
||||||
self.send_header("Content-Type", "application/json")
|
|
||||||
response = json.dumps({"status": "ok"}).encode()
|
|
||||||
self.send_header("Content-Length", len(response))
|
|
||||||
self.end_headers()
|
|
||||||
self.wfile.write(response)
|
|
||||||
except Exception as e:
|
|
||||||
print(f"[bridge] Handler error: {e}", file=sys.stderr)
|
|
||||||
self.send_response(500)
|
|
||||||
self.end_headers()
|
|
||||||
|
|
||||||
def do_GET(self):
|
|
||||||
if self.path == "/health":
|
|
||||||
self.send_response(200)
|
|
||||||
self.send_header("Content-Type", "application/json")
|
|
||||||
response = json.dumps({"status": "ok"}).encode()
|
|
||||||
self.send_header("Content-Length", len(response))
|
|
||||||
self.end_headers()
|
|
||||||
self.wfile.write(response)
|
|
||||||
else:
|
|
||||||
self.send_response(404)
|
|
||||||
self.end_headers()
|
|
||||||
|
|
||||||
def log_message(self, format, *args):
|
|
||||||
pass
|
|
||||||
|
|
||||||
|
|
||||||
if __name__ == "__main__":
|
|
||||||
port = int(os.environ.get("WEBHOOK_PORT", 9094))
|
|
||||||
server = http.server.HTTPServer(("0.0.0.0", port), WebhookHandler)
|
|
||||||
print(f"[bridge] Alert Webhook Bridge started on port {port}")
|
|
||||||
server.serve_forever()
|
|
||||||
@@ -1,210 +0,0 @@
|
|||||||
# BIZ-25 定时心跳检查 cron 任务部署方案
|
|
||||||
|
|
||||||
> **版本：** v1.0
|
|
||||||
> **编制：** 严维序（opengineer）
|
|
||||||
> **日期：** 2026-06-24
|
|
||||||
> **状态：** 已部署
|
|
||||||
> **父方案：** [BIZ-13 运行稳定性保障方案](./BIZ-13_运行稳定性保障方案.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 一、概述
|
|
||||||
|
|
||||||
本方案是 BIZ-13 Phase1 的执行层方案，负责将 HEARTBEAT.md 模板+共享脚本部署为可运行的定时心跳检查机制。
|
|
||||||
|
|
||||||
### 部署架构
|
|
||||||
|
|
||||||
```
|
|
||||||
┌─────────────────────────────────────────────────────┐
|
|
||||||
│ OpenClaw Gateway Cron │
|
|
||||||
│ ┌────────────┐ ┌────────────┐ ┌──────────────┐ │
|
|
||||||
│ │ Agent A │ │ Agent B │ │ Agent C │ │
|
|
||||||
│ │ 心跳(10/15m)│ │ 心跳(15m) │ │ 心跳(15m) │ │
|
|
||||||
│ └─────┬──────┘ └─────┬──────┘ └──────┬───────┘ │
|
|
||||||
│ │ │ │ │
|
|
||||||
│ ▼ ▼ ▼ │
|
|
||||||
│ ┌──────────────────────────────────────────┐ │
|
|
||||||
│ │ shared/scripts/heartbeat_helper.py │ │
|
|
||||||
│ │ + multica_proxy.py │ │
|
|
||||||
│ │ + rate_limiter.py │ │
|
|
||||||
│ └──────────────────────────────────────────┘ │
|
|
||||||
│ │ │ │ │
|
|
||||||
│ ▼ ▼ ▼ │
|
|
||||||
│ ┌──────────────────────────────────────────┐ │
|
|
||||||
│ │ 三源任务检查: WorkBoard + Multica + 文档 │ │
|
|
||||||
│ └──────────────────────────────────────────┘ │
|
|
||||||
└─────────────────────────────────────────────────────┘
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 二、Agent 心跳频率分类
|
|
||||||
|
|
||||||
根据 BIZ-13 方案定义：
|
|
||||||
|
|
||||||
| 分类 | 频率 | Agent | 数量 |
|
|
||||||
|------|------|-------|------|
|
|
||||||
| **高频** | **10 分钟** | 陆怀瑾 (coo), 刘诗妮 (secretary) | 2 |
|
|
||||||
| **常规** | **15 分钟** | 严维序 (opengineer), 沈路明 (productmanager), 胡蓉 (projectmanager), 梁思筑 (architect), 苏锦绘 (designer), 徐聪 (costcodev), 文墨言 (contentspecialist), 程伯予 (cvexpert), 许言 (prompt-engineer), 钟帧韵 (mediaspecialist), 陆云帆 (taobaospecialist), 顾析策 (marketanalysis), 苏慎 (lawyer) | 13 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 三、部署清单
|
|
||||||
|
|
||||||
### 3.1 ✅ 已完成 — HEARTBEAT.md 模板
|
|
||||||
|
|
||||||
所有 15 个 Agent 的工作区均已部署 HEARTBEAT.md：
|
|
||||||
|
|
||||||
| 工作区 | 频率 | 核心内容 |
|
|
||||||
|--------|------|----------|
|
|
||||||
| `coo/` | 10 min | BIZ-38 模板 + 全局积压巡检 |
|
|
||||||
| `secretary/` | 10 min | BIZ-38 模板 |
|
|
||||||
| `opengineer/` | 10 min | BIZ-38 模板 + 三源检查 |
|
|
||||||
| `projectmanager/` | 10 min | BIZ-38 模板 |
|
|
||||||
| `costcodev/` | 10 min | BIZ-38 模板 |
|
|
||||||
| 其余 10 个 Agent | 15 min | 标准模板 + 三源检查 |
|
|
||||||
|
|
||||||
### 3.2 ✅ 已完成 — 共享心跳脚本
|
|
||||||
|
|
||||||
路径：`shared/scripts/`
|
|
||||||
|
|
||||||
| 文件 | 用途 | 状态 |
|
|
||||||
|------|------|------|
|
|
||||||
| `rate_limiter.py` | 缓存管理 + 请求调度 + 协调轮询 | ✅ 已部署 |
|
|
||||||
| `multica_proxy.py` | Multica CLI 代理 + 缓存封装 | ✅ 已部署 |
|
|
||||||
| `heartbeat_helper.py` | 三源任务检查 + 超时检测 + 心跳入口 | ✅ 已部署 |
|
|
||||||
|
|
||||||
### 3.3 ⬜ 本次部署 — OpenClaw Cron 任务
|
|
||||||
|
|
||||||
使用 OpenClaw Gateway cron 系统创建定时任务，通过 `agentTurn` 隔离会话实现各 Agent 的周期性心跳触发。
|
|
||||||
|
|
||||||
#### Cron Job 规格
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
每个 Agent:
|
|
||||||
schedule:
|
|
||||||
kind: cron
|
|
||||||
expr: "*/10 * * * *" # 高频 Agent
|
|
||||||
# expr: "*/15 * * * *" # 常规 Agent
|
|
||||||
tz: "Asia/Shanghai"
|
|
||||||
sessionTarget: "isolated"
|
|
||||||
payload:
|
|
||||||
kind: "agentTurn"
|
|
||||||
message: "运行心跳检查。执行你的 HEARTBEAT.md 中的三源任务检查。"
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 四、部署执行记录
|
|
||||||
|
|
||||||
### 执行时间：2026-06-24 00:14 CST
|
|
||||||
|
|
||||||
#### 创建的 Cron Job 清单
|
|
||||||
|
|
||||||
| Agent | 频率 | Cron Session | 状态 |
|
|
||||||
|-------|------|-------------|------|
|
|
||||||
| coo (陆怀瑾) | 10 min | isolated agentTurn | ✅ |
|
|
||||||
| secretary (刘诗妮) | 10 min | isolated agentTurn | ✅ |
|
|
||||||
| opengineer (严维序) | 10 min | isolated agentTurn | ✅ |
|
|
||||||
| projectmanager (胡蓉) | 10 min | isolated agentTurn | ✅ |
|
|
||||||
| costcodev (徐聪) | 10 min | isolated agentTurn | ✅ |
|
|
||||||
| productmanager (沈路明) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| architect (梁思筑) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| designer (苏锦绘) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| contentspecialist (文墨言) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| cvexpert (程伯予) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| prompt-engineer (许言) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| mediaspecialist (钟帧韵) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| taobaospecialist (陆云帆) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| marketanalysis (顾析策) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
| lawyer (苏慎) | 15 min | isolated agentTurn | ✅ |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 五、心跳检查内容
|
|
||||||
|
|
||||||
每次心跳触发后，Agent 在隔离会话中执行以下检查：
|
|
||||||
|
|
||||||
### 5.1 三源任务检查
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[心跳触发] --> B[检查 WorkBoard 待办卡片]
|
|
||||||
A --> C[检查 Multica 待办 Issues]
|
|
||||||
A --> D[检查本地待办文档]
|
|
||||||
B --> E{有待办?}
|
|
||||||
C --> E
|
|
||||||
D --> E
|
|
||||||
E -->|有| F[自动执行任务]
|
|
||||||
E -->|无| G[结束心跳]
|
|
||||||
F --> H[任务完成?]
|
|
||||||
H -->|是| I[更新状态]
|
|
||||||
H -->|否| J[通知 COO]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.2 超时检测
|
|
||||||
|
|
||||||
- 进行中任务超过 20 分钟无进展 → 标记"疑似超时"
|
|
||||||
- 确认超时 → 自动恢复流程
|
|
||||||
|
|
||||||
### 5.3 依赖检查
|
|
||||||
|
|
||||||
- 认领任务前检查 `depends_on`
|
|
||||||
- 依赖未满足 → 保持 todo，不认领
|
|
||||||
|
|
||||||
### 5.4 轮次控制
|
|
||||||
|
|
||||||
- 单任务最大 50 轮
|
|
||||||
- 接近 80%（40 轮）→ 预警
|
|
||||||
- 达到上限 → 暂停，通知 COO
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 六、风险与规避
|
|
||||||
|
|
||||||
| 风险 | 影响 | 应对 |
|
|
||||||
|------|------|------|
|
|
||||||
| 心跳任务自身卡死 | 监控失效 | rate_limiter.py 缓存 + 超时保护 |
|
|
||||||
| 新增 Agent 未配心跳 | 遗漏 | 本方案作为部署 SOP 参考 |
|
|
||||||
| 会话隔离导致上下文丢失 | 心跳重复 | 心跳仅做检查，不承担复杂任务 |
|
|
||||||
| Agent 不在线 | 心跳无响应 | 系统事件 fallback，COO 巡检兜底 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 七、验证方法
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# 检查 cron job 列表
|
|
||||||
openclaw cron list
|
|
||||||
|
|
||||||
# 手动触发一次心跳 for a specific agent
|
|
||||||
openclaw cron run <job-id>
|
|
||||||
|
|
||||||
# 检查心跳脚本健康状态
|
|
||||||
python3 shared/scripts/heartbeat_helper.py <agent_id> --health
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 八、修复记录
|
|
||||||
|
|
||||||
### v1.1 — 2026-06-24
|
|
||||||
|
|
||||||
| 问题 | 修复 |
|
|
||||||
|------|------|
|
|
||||||
| cron delivery 报 Feishu 投递错误 | delivery 从 `announce` 改为 `none`（原方案未指定 delivery，不影响功能） |
|
|
||||||
| Multica workspace_id 未传递 | `multica_proxy.py` 新增 `_inject_workspace_id()`，自动在所有 multica CLI 调用注入 `--workspace-id` |
|
|
||||||
| AGENT_CONFIGS 仅 5 个 Agent | `heartbeat_helper.py` 扩展至全部 15 个 Agent |
|
|
||||||
| COO HEARTBEAT 显示未部署 | 更新 BIZ-38 集成清单表 |
|
|
||||||
|
|
||||||
## 九、后续优化方向
|
|
||||||
|
|
||||||
- [ ] 监控面板集成（BIZ-28 Phase3）
|
|
||||||
- [ ] 心跳结果聚合展示
|
|
||||||
- [ ] Agent 健康状态告警
|
|
||||||
- [ ] 自动 Agent 发现（新增 Agent 自动配置心跳）
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> **运维记录**：严维序 2026-06-24
|
|
||||||
> 所有 15 个 Agent 的 HEARTBEAT.md 已部署，共享脚本已就位，cron 定时器已配置。
|
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
# Agent 岗位说明书索引
|
||||||
|
|
||||||
|
> 编制：陆怀瑾（COO） | 2026-06-22
|
||||||
|
|
||||||
|
## 已完成的岗位说明书
|
||||||
|
|
||||||
|
| Agent | 角色 | 所属部门 | 上级 |
|
||||||
|
|-------|------|----------|------|
|
||||||
|
| 刘诗妮 (secretary) | 专职秘书 | 管理层 | Vincent |
|
||||||
|
| 陆怀瑾 (coo) | COO 运营总监 | 管理层 | Vincent |
|
||||||
|
| 程伯予 (cvexpert) | 求职助理 | 管理层 | Vincent |
|
||||||
|
| 胡蓉 (projectmanager) | 项目经理 | 产研中心 | COO |
|
||||||
|
| 沈路明 (productmanager) | 产品经理 | 产研中心 | projectmanager |
|
||||||
|
| 梁思筑 (architect) | 系统架构师 | 产研中心 | projectmanager |
|
||||||
|
| 徐聪 (costcodev) | 全栈开发工程师 | 产研中心 | projectmanager |
|
||||||
|
| 苏锦绘 (designer) | UI/UX 设计师 | 运营中心 | COO |
|
||||||
|
| 严维序 (opengineer) | 运维工程师 | 产研中心 | projectmanager |
|
||||||
|
| 陆云帆 (taobaospecialist) | 淘宝运营专员 | 运营中心 | COO |
|
||||||
|
| 文墨言 (contentspecialist) | 内容运营专员 | 运营中心 | COO |
|
||||||
|
| 钟帧韵 (mediaspecialist) | 视频媒体专员 | 运营中心 | COO |
|
||||||
|
|
||||||
|
## 岗位说明书结构
|
||||||
|
|
||||||
|
每份岗位说明书包含：
|
||||||
|
1. 基本信息（ID/汇报对象/协作岗位）
|
||||||
|
2. 核心职责（5 条）
|
||||||
|
3. 工作流程（输入→处理→输出）
|
||||||
|
4. 权限范围（自主/审批/无权）
|
||||||
|
5. 绩效指标（3-4 项关键 KPI）
|
||||||
|
6. 升级机制（阻塞/风险上报路径）
|
||||||
|
|
||||||
|
各岗位详细说明书参照 BIZ-11 方案 4.1 节模板。
|
||||||
@@ -0,0 +1,82 @@
|
|||||||
|
# 协作流程与升级机制
|
||||||
|
|
||||||
|
> 编制：陆怀瑾（COO） | 2026-06-22 | v1.0
|
||||||
|
|
||||||
|
## 一、开发项目标准流程
|
||||||
|
|
||||||
|
```
|
||||||
|
Vincent/secretary 提出需求
|
||||||
|
↓
|
||||||
|
COO 评估资源可行性
|
||||||
|
↓
|
||||||
|
projectmanager 拆解任务（WBS）
|
||||||
|
↓
|
||||||
|
productmanager 撰写 PRD
|
||||||
|
↓
|
||||||
|
architect 设计架构方案
|
||||||
|
↓
|
||||||
|
costcodev 代码开发
|
||||||
|
↓
|
||||||
|
designer UI 设计（并行）
|
||||||
|
↓
|
||||||
|
opengineer 部署上线
|
||||||
|
↓
|
||||||
|
COO 验收确认 → Vincent
|
||||||
|
```
|
||||||
|
|
||||||
|
## 二、运营业务标准流程
|
||||||
|
|
||||||
|
```
|
||||||
|
业务需求（电商/内容/视频）
|
||||||
|
↓
|
||||||
|
COO 分配任务至运营专员
|
||||||
|
↓
|
||||||
|
运营专员执行
|
||||||
|
↓
|
||||||
|
COO 质量检查
|
||||||
|
↓
|
||||||
|
Vincent 确认 / 发布
|
||||||
|
```
|
||||||
|
|
||||||
|
## 三、升级标准
|
||||||
|
|
||||||
|
| 级别 | 触发条件 | 通知对象 | 响应时间 |
|
||||||
|
|------|----------|----------|----------|
|
||||||
|
| L1 一般 | 进度偏差 > 30% | projectmanager | 4h |
|
||||||
|
| L2 关注 | 阻塞 > 4h | secretary | 即刻 |
|
||||||
|
| L3 紧急 | 影响收入/客户 | COO | 即刻 |
|
||||||
|
| L4 严重 | 系统故障/安全事故 | Vincent（直接汇报） | 即刻 |
|
||||||
|
|
||||||
|
## 四、协作规则
|
||||||
|
|
||||||
|
### 任务认领
|
||||||
|
- 所有任务从 WorkBoard 认领，不接收口头任务
|
||||||
|
- 依赖任务完成后，后续任务自动解锁
|
||||||
|
- 认领后 2h 内必须有实质性进展
|
||||||
|
|
||||||
|
### 信息互通
|
||||||
|
- COO 和 secretary 保持密切信息互通
|
||||||
|
- 任何业务启动/进展/阻塞，COO 必须知晓
|
||||||
|
- 重大变更需在 WorkBoard 更新 + 通知相关方
|
||||||
|
|
||||||
|
### 交付标准
|
||||||
|
- 所有交付物必须有明确的验收标准
|
||||||
|
- 交付时附带自检清单
|
||||||
|
- 验收不通过 → 退回修正 → 重新验收
|
||||||
|
|
||||||
|
### 跨 Agent 沟通格式
|
||||||
|
```
|
||||||
|
【任务转交 - 给[Agent名称]】
|
||||||
|
## 任务背景 / 你需要交付 / 我的后续支持
|
||||||
|
```
|
||||||
|
|
||||||
|
## 五、风险应对速查
|
||||||
|
|
||||||
|
| 风险类型 | 识别信号 | 应对措施 |
|
||||||
|
|----------|----------|----------|
|
||||||
|
| 任务停滞 | Agent 24h 无响应 | 心跳检测 + 自动重试 |
|
||||||
|
| 429 限流 | API 调用频繁失败 | 令牌桶限流 + 模型降级 |
|
||||||
|
| 资源不足 | 多任务排队 > 5 | 重新分配 + 扩招建议 |
|
||||||
|
| 质量问题 | 交付物不符合标准 | 返工 + 流程优化 |
|
||||||
|
| 外部依赖 | 平台 API 变更 | 快速适配 + 预案 |
|
||||||
|
| 安全事件 | 数据泄露/权限异常 | 直接汇报 Vincent |
|
||||||
@@ -0,0 +1,46 @@
|
|||||||
|
# 岗位能力矩阵
|
||||||
|
|
||||||
|
> 编制：陆怀瑾（COO） | 2026-06-22 | v1.0
|
||||||
|
|
||||||
|
## 能力符号说明
|
||||||
|
|
||||||
|
| 符号 | 含义 |
|
||||||
|
|------|------|
|
||||||
|
| ★★★ | 核心能力（自主执行） |
|
||||||
|
| ★★☆ | 辅助能力（需要协作） |
|
||||||
|
| ★☆☆ | 基础认知（知道边界） |
|
||||||
|
| — | 不适用 |
|
||||||
|
|
||||||
|
## 能力矩阵
|
||||||
|
|
||||||
|
| Agent | 项目管理 | 开发执行 | 电商运营 | 内容运营 | 视频制作 | UI设计 | 运维部署 | 商业分析 | 市场研究 |
|
||||||
|
|-------|----------|----------|----------|----------|----------|--------|----------|----------|----------|
|
||||||
|
| 刘诗妮 | ★★★ | — | — | — | — | — | — | — | — |
|
||||||
|
| 陆怀瑾 | ★★★ | — | ★★☆ | ★★☆ | ★★☆ | — | ★☆☆ | ★★☆ | ★★☆ |
|
||||||
|
| 程伯予 | — | — | — | — | — | — | — | ★★★ | ★☆☆ |
|
||||||
|
| 胡蓉 | ★★★ | ★☆☆ | — | — | — | — | — | — | — |
|
||||||
|
| 沈路明 | ★★☆ | ★☆☆ | — | — | — | ★☆☆ | — | ★★☆ | ★★☆ |
|
||||||
|
| 梁思筑 | ★☆☆ | ★★★ | — | — | — | — | ★★☆ | — | — |
|
||||||
|
| 徐聪 | — | ★★★ | — | — | — | — | ★☆☆ | — | — |
|
||||||
|
| 苏锦绘 | — | — | ★★☆ | — | ★☆☆ | ★★★ | — | — | — |
|
||||||
|
| 严维序 | — | ★☆☆ | — | — | — | — | ★★★ | — | — |
|
||||||
|
| 陆云帆 | — | ★★☆ | ★★★ | ★☆☆ | — | ★☆☆ | ★☆☆ | — | — |
|
||||||
|
| 文墨言 | — | — | ★★☆ | ★★★ | — | — | — | — | ★☆☆ |
|
||||||
|
| 钟帧韵 | — | — | ★☆☆ | ★★☆ | ★★★ | ★☆☆ | — | — | — |
|
||||||
|
|
||||||
|
## 能力缺口分析
|
||||||
|
|
||||||
|
| 能力领域 | 当前覆盖 | 缺口 | 影响业务 | 建议 |
|
||||||
|
|----------|----------|------|----------|------|
|
||||||
|
| 市场分析 | COO(基础) | 高 | 商业分析业务线 | 优先招聘市场分析师 |
|
||||||
|
| 法务合规 | 无 | 中 | 电商合规/合同风险 | 招聘法务顾问或外部顾问 |
|
||||||
|
| 深度数据分析 | COO(基础) | 中 | 成本优化/ROI | 招聘数据分析师 |
|
||||||
|
| 跨境业务 | 无 | 低 | 海外扩张 | 暂缓，现有业务优先 |
|
||||||
|
|
||||||
|
## Agent 当前负载（2026-06-22）
|
||||||
|
|
||||||
|
| Agent | 活跃任务数 | 负载评级 |
|
||||||
|
|-------|-----------|----------|
|
||||||
|
| 陆怀瑾 (coo) | 7 | 🔴 重载 |
|
||||||
|
| 严维序 (opengineer) | 1 | 🟢 轻载 |
|
||||||
|
| 其他 Agent | 0 | 🟢 空闲 |
|
||||||
@@ -0,0 +1,60 @@
|
|||||||
|
# 多智能体组织架构图
|
||||||
|
|
||||||
|
> 编制：陆怀瑾（COO） | 2026-06-22 | v1.1
|
||||||
|
|
||||||
|
## 架构总览
|
||||||
|
|
||||||
|
```
|
||||||
|
Vincent（刘总）
|
||||||
|
│
|
||||||
|
┌──────────────┼──────────────┐
|
||||||
|
│ │ │
|
||||||
|
刘诗妮 (秘书) 陆怀瑾 (COO) 程伯予 (求职)
|
||||||
|
│
|
||||||
|
┌───────────────────┼───────────────────┐
|
||||||
|
│ │ │
|
||||||
|
运营中心 产研中心 商业分析中心(待建)
|
||||||
|
┌───┴───┐ ┌──────┴──────┐ ┌────┴────┐
|
||||||
|
│ │ │ │ │ │
|
||||||
|
陆云帆 文墨言 胡蓉 (PM) 钟帧韵 市场分析师 法务顾问
|
||||||
|
(淘宝) (内容) │ (视频) (待招聘) (待招聘)
|
||||||
|
│
|
||||||
|
┌─────┼─────┐
|
||||||
|
│ │ │
|
||||||
|
沈路明 梁思筑 苏锦绘
|
||||||
|
(产品) (架构) (设计)
|
||||||
|
│
|
||||||
|
徐聪 (开发)
|
||||||
|
│
|
||||||
|
严维序 (运维)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 团队统计
|
||||||
|
|
||||||
|
| 层级 | 角色 | 人数 |
|
||||||
|
|------|------|------|
|
||||||
|
| 管理层 | Vincent | 1 |
|
||||||
|
| 专职支持 | secretary, cvexpert | 2 |
|
||||||
|
| 运营管理 | COO | 1 |
|
||||||
|
| 运营执行 | taobaospecialist, contentspecialist, mediaspecialist, designer | 4 |
|
||||||
|
| 产研管理 | projectmanager | 1 |
|
||||||
|
| 产研执行 | productmanager, architect, costcodev, opengineer | 4 |
|
||||||
|
| 待建 | 市场分析师, 法务顾问, 数据分析师 | 3 |
|
||||||
|
| **合计** | | **16**（现有 13 + 待建 3） |
|
||||||
|
|
||||||
|
## 汇报关系
|
||||||
|
|
||||||
|
| Agent | 直接上级 | 虚线汇报 |
|
||||||
|
|-------|----------|----------|
|
||||||
|
| 刘诗妮 (secretary) | Vincent | COO（信息同步） |
|
||||||
|
| 陆怀瑾 (coo) | Vincent | — |
|
||||||
|
| 程伯予 (cvexpert) | Vincent | — |
|
||||||
|
| 胡蓉 (projectmanager) | COO | secretary（信息同步） |
|
||||||
|
| 沈路明 (productmanager) | projectmanager | — |
|
||||||
|
| 梁思筑 (architect) | projectmanager | — |
|
||||||
|
| 徐聪 (costcodev) | projectmanager | — |
|
||||||
|
| 严维序 (opengineer) | projectmanager | — |
|
||||||
|
| 苏锦绘 (designer) | COO | — |
|
||||||
|
| 陆云帆 (taobaospecialist) | COO | — |
|
||||||
|
| 文墨言 (contentspecialist) | COO | — |
|
||||||
|
| 钟帧韵 (mediaspecialist) | COO | — |
|
||||||
@@ -1,62 +0,0 @@
|
|||||||
#!/bin/bash
|
|
||||||
# wiki-lint-check.sh — Wiki 知识库质量检查脚本
|
|
||||||
#
|
|
||||||
# 用途: 定期运行 wiki_lint 检查知识库质量，生成报告
|
|
||||||
# 用法: ./scripts/wiki-lint-check.sh [--report-dir <dir>]
|
|
||||||
#
|
|
||||||
# 建议通过 cron 定期执行，例如每日凌晨:
|
|
||||||
# 0 2 * * * cd /path/to/EnterpriseArchitect && ./scripts/wiki-lint-check.sh
|
|
||||||
|
|
||||||
set -euo pipefail
|
|
||||||
|
|
||||||
REPORT_DIR="${REPORT_DIR:-/tmp/wiki-lint-reports}"
|
|
||||||
TIMESTAMP=$(date '+%Y-%m-%d_%H%M%S')
|
|
||||||
REPORT_FILE="${REPORT_DIR}/wiki-lint-${TIMESTAMP}.md"
|
|
||||||
|
|
||||||
mkdir -p "$REPORT_DIR"
|
|
||||||
|
|
||||||
echo "=== Wiki Lint Check ==="
|
|
||||||
echo "时间: $(date '+%Y-%m-%d %H:%M:%S %Z')"
|
|
||||||
echo "报告路径: $REPORT_FILE"
|
|
||||||
echo ""
|
|
||||||
|
|
||||||
# 运行 wiki_lint（通过 OpenClaw CLI）
|
|
||||||
# 注意: 此脚本需在 OpenClaw 环境中执行
|
|
||||||
LINT_RESULT=$(openclaw skill wiki-lint 2>&1) || true
|
|
||||||
|
|
||||||
# 生成报告
|
|
||||||
cat > "$REPORT_FILE" << EOF
|
|
||||||
# Wiki Lint 检查报告
|
|
||||||
|
|
||||||
**检查时间**: $(date '+%Y-%m-%d %H:%M:%S %Z')
|
|
||||||
**执行主机**: $(hostname)
|
|
||||||
**执行用户**: $(whoami)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 检查结果
|
|
||||||
|
|
||||||
\`\`\`
|
|
||||||
${LINT_RESULT:-No output from wiki_lint}
|
|
||||||
\`\`\`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 状态
|
|
||||||
|
|
||||||
EOF
|
|
||||||
|
|
||||||
if echo "$LINT_RESULT" | grep -qi "error\|fail\|issue"; then
|
|
||||||
echo "**状态**: ⚠️ 发现问题，需处理" >> "$REPORT_FILE"
|
|
||||||
echo ""
|
|
||||||
echo "⚠️ Wiki Lint 发现问题，请检查: $REPORT_FILE"
|
|
||||||
else
|
|
||||||
echo "**状态**: ✅ 无问题" >> "$REPORT_FILE"
|
|
||||||
echo ""
|
|
||||||
echo "✅ Wiki Lint 检查通过"
|
|
||||||
fi
|
|
||||||
|
|
||||||
echo "报告已生成: $REPORT_FILE"
|
|
||||||
|
|
||||||
# 清理 30 天以前的旧报告
|
|
||||||
find "$REPORT_DIR" -name "wiki-lint-*.md" -mtime +30 -delete 2>/dev/null || true
|
|
||||||
@@ -1,279 +0,0 @@
|
|||||||
# 多智能体文档存储、命名与索引规范 v1.0
|
|
||||||
|
|
||||||
> 版本：v1.0（实施版）
|
|
||||||
> 编制：陆怀瑾（COO）
|
|
||||||
> 日期：2026-06-22
|
|
||||||
> 状态：已批准，执行中
|
|
||||||
> 适用范围：所有 Agent 的 workspace 目录
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 一、统一目录结构
|
|
||||||
|
|
||||||
每个 Agent 的 workspace 必须采用以下标准目录结构：
|
|
||||||
|
|
||||||
```
|
|
||||||
workspace/
|
|
||||||
├── AGENTS.md # Agent 协作协议
|
|
||||||
├── MEMORY.md # 长期记忆 → 含文档索引表（核心）
|
|
||||||
├── SOUL.md # 角色定义 → 引用外部内容，不填塞
|
|
||||||
├── IDENTITY.md # 身份信息
|
|
||||||
├── USER.md # 用户画像
|
|
||||||
├── TOOLS.md # 工具清单 → 仅保留索引，详情外挂
|
|
||||||
├── HEARTBEAT.md # 心跳配置
|
|
||||||
│
|
|
||||||
├── memory/ # 记忆归档目录（按日期）
|
|
||||||
│ └── YYYY-MM-DD.md
|
|
||||||
│
|
|
||||||
├── docs/ # 项目文档目录（按项目分）
|
|
||||||
│ └── {project}/
|
|
||||||
│ ├── README.md
|
|
||||||
│ └── ...
|
|
||||||
│
|
|
||||||
├── plans/ # 方案文档目录
|
|
||||||
│ └── YYYY-MM-DD_{topic}.md
|
|
||||||
│
|
|
||||||
├── specs/ # 规范/标准文档目录
|
|
||||||
│ └── BIZ-XX_{name}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── reports/ # 运营报告目录
|
|
||||||
│ └── YYYY-Q{N}_{type}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── knowledge/ # 知识库目录（按领域分）
|
|
||||||
│ └── {domain}/
|
|
||||||
│ └── {topic}.md
|
|
||||||
│
|
|
||||||
├── tasks/ # 任务文件目录（可选）
|
|
||||||
│ └── ...
|
|
||||||
│
|
|
||||||
└── assets/ # 资源文件目录
|
|
||||||
├── images/
|
|
||||||
├── files/
|
|
||||||
└── templates/
|
|
||||||
```
|
|
||||||
|
|
||||||
### 目录用途速查
|
|
||||||
|
|
||||||
| 目录 | 用途 | Token 影响 |
|
|
||||||
|------|------|-----------|
|
|
||||||
| 根目录 .md | Agent 核心配置 | **直接影响 Token**，必须精简 |
|
|
||||||
| memory/ | 按日归档记忆 | 通过 memory_search 检索，不占用上下文 |
|
|
||||||
| docs/ | 项目文档 | 按需加载 |
|
|
||||||
| plans/ | 方案文档 | 仅 COO 维护 |
|
|
||||||
| specs/ | 规范标准 | 按需加载 |
|
|
||||||
| reports/ | 运营报告 | 仅 COO 维护 |
|
|
||||||
| knowledge/ | 知识库 | 知识库检索，不占用上下文 |
|
|
||||||
| assets/ | 二进制资源 | 不占用上下文 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 二、文件命名规则
|
|
||||||
|
|
||||||
### 2.1 强制命名格式
|
|
||||||
|
|
||||||
```
|
|
||||||
{日期/编号}_{中文主题}_{版本}.md
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2.2 各目录命名约定
|
|
||||||
|
|
||||||
| 目录 | 命名模式 | 示例 |
|
|
||||||
|------|----------|------|
|
|
||||||
| memory/ | `YYYY-MM-DD.md` | `2026-06-22.md` |
|
|
||||||
| plans/ | `YYYY-MM-DD_{主题}.md` | `2026-06-22_多智能体协作体系总体方案.md` |
|
|
||||||
| specs/ | `BIZ-{编号}_{主题}_v{M}.{N}.md` | `BIZ-12_文档存储规范_v1.0.md` |
|
|
||||||
| reports/ | `YYYY-Q{N}_{类型}_v{M}.{N}.md` | `2026-Q2_运营效率报告_v1.0.md` |
|
|
||||||
| knowledge/ | `{主题}_v{M}.{N}.md` | `淘宝运营_SOP_v1.0.md` |
|
|
||||||
| docs/{project}/ | `{功能}_{版本}.md` | `requirements_v1.0.md` |
|
|
||||||
| memory/ day file | `YYYY-MM-DD.md` | `2026-06-22.md` |
|
|
||||||
|
|
||||||
### 2.3 禁止事项
|
|
||||||
|
|
||||||
- ❌ 使用特殊字符：`/ \ : * ? " < > |` 空格
|
|
||||||
- ❌ 超过 80 字符的文件名
|
|
||||||
- ❌ 不含日期/编号的裸文件名
|
|
||||||
- ❌ 中文和英文混排无分隔符
|
|
||||||
- ✅ 统一使用下划线 `_` 作为分隔符
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 三、索引机制（核心）
|
|
||||||
|
|
||||||
### 3.1 索引分离原则（刘总反馈已纳入）
|
|
||||||
|
|
||||||
> **配置文件只保留索引指针，详细内容外挂存储。**
|
|
||||||
|
|
||||||
此原则适用场景：
|
|
||||||
- **TOOLS.md**：只列工具名称 + 引用路径，不列完整参数
|
|
||||||
- **待办列表**：只记录 ID + 主题 + 状态，详情在独立文件中
|
|
||||||
- **Agent 协作表**：只列 Agent 名 + 职能 + Session Key，详情在各自文件
|
|
||||||
- **知识索引**：MEMORY.md 只保留索引表，知识条目在 knowledge/ 中
|
|
||||||
|
|
||||||
### 3.2 MEMORY.md 索引表模板
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# MEMORY.md - {Agent Name} 长期记忆
|
|
||||||
|
|
||||||
## 📑 文档索引
|
|
||||||
|
|
||||||
### 方案文档
|
|
||||||
| 日期 | 主题 | 路径 | 状态 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| 2026-06-22 | 多智能体协作体系 | plans/2026-06-22_多智能体协作体系总体方案.md | 已批准 |
|
|
||||||
|
|
||||||
### 规范标准
|
|
||||||
| 编号 | 主题 | 路径 | 版本 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| BIZ-12 | 文档存储规范 | specs/BIZ-12_文档存储规范_v1.0.md | v1.0 |
|
|
||||||
|
|
||||||
### 项目文档
|
|
||||||
| 项目 | 文档 | 路径 | 状态 |
|
|
||||||
|------|------|------|------|
|
|
||||||
|
|
||||||
### 运营报告
|
|
||||||
| 周期 | 类型 | 路径 | 状态 |
|
|
||||||
|------|------|------|------|
|
|
||||||
|
|
||||||
### 知识库条目
|
|
||||||
| 领域 | 主题 | 路径 | 更新时间 |
|
|
||||||
|------|------|------|----------|
|
|
||||||
|
|
||||||
---
|
|
||||||
（以下是实际记忆内容...）
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3.3 各目录 README.md 模板
|
|
||||||
|
|
||||||
每个目录应有一个 `README.md`：
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {目录名称}
|
|
||||||
|
|
||||||
> 最后更新：{YYYY-MM-DD}
|
|
||||||
> 维护者：{Agent Name}
|
|
||||||
|
|
||||||
## 目录说明
|
|
||||||
{简短描述本目录的用途和使用规范}
|
|
||||||
|
|
||||||
## 文件列表
|
|
||||||
| 文件名 | 描述 | 最后更新 |
|
|
||||||
|--------|------|----------|
|
|
||||||
| ... | ... | ... |
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 四、检索体系
|
|
||||||
|
|
||||||
### 4.1 分层检索路径
|
|
||||||
|
|
||||||
```
|
|
||||||
第一层：memory_search（语义检索，跨 memory/*.md + MEMORY.md）
|
|
||||||
↓ 未命中
|
|
||||||
第二层：wiki_search / wiki_get（编译型知识库检索）
|
|
||||||
↓ 未命中
|
|
||||||
第三层：qmd（QMD 全文检索，已安装 —— 刘总反馈已纳入）
|
|
||||||
↓ 未命中
|
|
||||||
第四层：web_fetch / web_search（外部知识）
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4.2 检索优先级
|
|
||||||
|
|
||||||
1. **memory_search**（corpus=all）：首选，零 token 消耗
|
|
||||||
2. **qmd**：本地全文检索，补充 memory_search 未覆盖的长文档
|
|
||||||
3. **wiki_search/wiki_get**：编译型结构化知识库
|
|
||||||
4. **web_search/web_fetch**：外部补充，仅在以上均未命中时使用
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 五、Token 预算控制
|
|
||||||
|
|
||||||
### 5.1 配置文件大小限制
|
|
||||||
|
|
||||||
| 文件 | 最大行数 | 说明 |
|
|
||||||
|------|----------|------|
|
|
||||||
| AGENTS.md | 200 行 | Agent 协议 + 协作表（精简） |
|
|
||||||
| MEMORY.md | 150 行 | 长期记忆 + 索引表 |
|
|
||||||
| SOUL.md | 80 行 | 角色定义 |
|
|
||||||
| IDENTITY.md | 30 行 | 身份信息 |
|
|
||||||
| USER.md | 30 行 | 用户画像 |
|
|
||||||
| TOOLS.md | 100 行 | 工具索引（不填塞完整参数） |
|
|
||||||
| HEARTBEAT.md | 60 行 | 心跳配置 |
|
|
||||||
|
|
||||||
### 5.2 引用代替填塞
|
|
||||||
|
|
||||||
**反例（填塞模式）**：
|
|
||||||
```markdown
|
|
||||||
# TOOLS.md - 全部填入
|
|
||||||
- memory_search: 参数 query, maxResults, minScore, corpus=[memory|wiki|all|sessions]...
|
|
||||||
（占用大量 token）
|
|
||||||
```
|
|
||||||
|
|
||||||
**正例（引用模式）**：
|
|
||||||
```markdown
|
|
||||||
# TOOLS.md - 索引模式
|
|
||||||
## 已安装 Skills
|
|
||||||
- plantuml-skill → 详见 skills/plantuml-skill/SKILL.md
|
|
||||||
- qmd → 详见 skills/qmd/SKILL.md
|
|
||||||
- ...
|
|
||||||
## 核心工具（已内置于运行时，无需列出参数）
|
|
||||||
- memory_search / wiki_search / web_fetch
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 六、文档生命周期管理
|
|
||||||
|
|
||||||
### 6.1 状态流转
|
|
||||||
|
|
||||||
```
|
|
||||||
创建 → 草稿(draft) → 审阅中(in_review) → 已批准(approved) → 归档(archived)
|
|
||||||
↓
|
|
||||||
废弃(deprecated)
|
|
||||||
```
|
|
||||||
|
|
||||||
### 6.2 操作规范
|
|
||||||
|
|
||||||
| 操作 | 规则 |
|
|
||||||
|------|------|
|
|
||||||
| 创建 | 在正确目录，按命名规则创建 |
|
|
||||||
| 更新 | 小改动直接覆盖；大改动新建版本 |
|
|
||||||
| 审阅 | 状态标记 `in_review`，通知审阅人 |
|
|
||||||
| 归档 | 移动到 `archive/` 子目录 |
|
|
||||||
| 删除 | 不直接删除，先归档 30 天后清理 |
|
|
||||||
|
|
||||||
### 6.3 版本标记
|
|
||||||
|
|
||||||
- v1.0：首版
|
|
||||||
- v1.1-v1.9：小修
|
|
||||||
- v2.0+：大修 / 重构
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 七、Agent 端执行规范
|
|
||||||
|
|
||||||
### 7.1 每次任务后
|
|
||||||
1. 更新 `memory/YYYY-MM-DD.md`（日记）
|
|
||||||
2. 如产出文档，更新 MEMORY.md 索引表
|
|
||||||
3. 检查文件名是否符合规范
|
|
||||||
|
|
||||||
### 7.2 每周
|
|
||||||
1. 检查并清理过期文档（移动到 archive/）
|
|
||||||
2. 验证索引表与实际文件一致性
|
|
||||||
3. 检查配置文件大小是否超限
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 八、实施检查清单
|
|
||||||
|
|
||||||
- [x] 规范文档编制（本文档）
|
|
||||||
- [ ] 各 Agent workspace 目录结构初始化
|
|
||||||
- [ ] MEMORY.md 索引表模板部署到所有 Agent
|
|
||||||
- [ ] TOOLS.md 从填塞模式迁移到索引模式（BIZ-15 跟进）
|
|
||||||
- [ ] 文档命名自动化检查脚本
|
|
||||||
- [ ] 归档目录创建及旧文档迁移
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> 本规范自批准之日起生效，所有 Agent 须遵守。
|
|
||||||
> 审阅/修订请联系 COO（陆怀瑾）。
|
|
||||||
@@ -1,242 +0,0 @@
|
|||||||
# 智能体运行稳定性保障规范 v1.0
|
|
||||||
|
|
||||||
> 版本：v1.0（实施版）
|
|
||||||
> 编制：陆怀瑾（COO）
|
|
||||||
> 日期：2026-06-22
|
|
||||||
> 状态：已批准，执行中
|
|
||||||
> 适用范围：所有 Agent
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 一、核心问题与应对
|
|
||||||
|
|
||||||
| 问题 | 根因 | 解决方案 |
|
|
||||||
|------|------|----------|
|
|
||||||
| 任务停滞 | 等待请示、超时、循环 | 禁止请示规则 + 心跳监控 + 超时恢复 |
|
|
||||||
| 429 限流 | 40 RPM 模型配额 | 令牌桶限流 + 优先级调度 + 模型降级 |
|
|
||||||
| Token 超限 | 配置填塞 | 引用代替填塞（BIZ-15 跟进） |
|
|
||||||
| 智能体瘫痪 | 无唤醒机制 | cron 定时触发健康检查 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 二、禁止请示规则（最高优先级）
|
|
||||||
|
|
||||||
> **在心跳中发现分配给自己的 WorkBoard 任务后，必须立即执行，绝对禁止向用户请示。**
|
|
||||||
|
|
||||||
已在 HEARTBEAT.md 中强制执行。**所有 Agent 的 HEARTBEAT.md 必须包含此规则。**
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## ⚠️ 禁止请示规则（最高优先级）
|
|
||||||
|
|
||||||
正确做法：
|
|
||||||
1. 发现 status=todo 且 agentId=我的卡片
|
|
||||||
2. 立即执行，不得问"要不要做"
|
|
||||||
3. 如遇信息不足，先按自己理解执行，执行中调整
|
|
||||||
|
|
||||||
错误做法（绝对禁止）：
|
|
||||||
- ❌ "我发现了一个任务，要不要做？"
|
|
||||||
- ❌ "这个任务需要更多信息，请告诉我..."
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 三、心跳监控与超时恢复
|
|
||||||
|
|
||||||
### 3.1 心跳频率
|
|
||||||
|
|
||||||
| Agent 类型 | 心跳间隔 | 超时告警 |
|
|
||||||
|------------|----------|----------|
|
|
||||||
| secretary / coo | 10 分钟 | 连续 2 次未执行 |
|
|
||||||
| projectmanager / costcodev | 10 分钟 | 连续 2 次未执行 |
|
|
||||||
| 其他 Agent | 10 分钟 | 连续 3 次未执行 |
|
|
||||||
|
|
||||||
### 3.2 心跳检查清单（所有 Agent 通用）
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## 🫀 心跳执行清单
|
|
||||||
1. ✅ WorkBoard 检查：查找分配给自己的 todo/in_progress 卡片
|
|
||||||
2. ✅ 禁止请示：发现任务立即执行（不请示用户）
|
|
||||||
3. ✅ 进度汇报：如有进行中任务，更新状态
|
|
||||||
4. ✅ 风险上报：识别阻塞、超时问题，通知 COO
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3.3 超时恢复流程
|
|
||||||
|
|
||||||
```
|
|
||||||
Agent 超过 30 分钟无响应
|
|
||||||
↓
|
|
||||||
COO 心跳检测到超时
|
|
||||||
↓
|
|
||||||
记录日志 + 评估任务状态
|
|
||||||
↓
|
|
||||||
┌──────────┴──────────┐
|
|
||||||
│ │
|
|
||||||
任务可恢复 任务不可恢复
|
|
||||||
│ │
|
|
||||||
重新触发任务 通知 Vincent
|
|
||||||
(workboard dispatch) (via session_send)
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 四、429 限流治理
|
|
||||||
|
|
||||||
### 4.1 当前配额与监控
|
|
||||||
|
|
||||||
| 模型 | RPM 限制 | 建议预留 |
|
|
||||||
|------|----------|----------|
|
|
||||||
| 主模型 | 40 | 保留 10 RPM 给紧急任务 |
|
|
||||||
| 备用模型 | 40 | 满 35 RPM 时切换 |
|
|
||||||
|
|
||||||
### 4.2 令牌桶限流策略
|
|
||||||
|
|
||||||
```
|
|
||||||
每个 Agent 独立的令牌桶:
|
|
||||||
- 容量：按 Agent 优先级分配
|
|
||||||
- COO/secretary: 8 RPM
|
|
||||||
- 开发 Agent: 6 RPM
|
|
||||||
- 业务 Agent: 4 RPM
|
|
||||||
- 预留池: 10 RPM (紧急任务)
|
|
||||||
|
|
||||||
令牌桶耗尽 → 自动降级到备用模型或排队
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4.3 优先级调度
|
|
||||||
|
|
||||||
| 优先级 | 适用场景 | 处理方式 |
|
|
||||||
|--------|----------|----------|
|
|
||||||
| P1 紧急 | Vincent 直接指令 | 立即可用预留池 |
|
|
||||||
| P2 高 | 阻塞性任务、风险告警 | 优先分配令牌 |
|
|
||||||
| P3 正常 | 日常任务 | 正常排队 |
|
|
||||||
| P4 低 | 后台优化、报告生成 | 低峰期执行 |
|
|
||||||
|
|
||||||
### 4.4 模型降级链
|
|
||||||
|
|
||||||
```
|
|
||||||
主模型 (qwen3.5-397b) RPM 不足
|
|
||||||
↓
|
|
||||||
备用模型 (deepseek-v4-pro)
|
|
||||||
↓
|
|
||||||
等待 + 指数退避重试 (1s → 2s → 4s → 8s)
|
|
||||||
↓
|
|
||||||
3 次重试后仍失败 → 记录日志，通知 COO
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4.5 请求合并优化
|
|
||||||
|
|
||||||
| 优化项 | 当前做法 | 优化后 |
|
|
||||||
|--------|----------|--------|
|
|
||||||
| WorkBoard 轮询 | 每个 Agent 独立轮询 | COO 统一轮询，广播结果 |
|
|
||||||
| 重复检索 | 多个 Agent 重复查同一文档 | 缓存关键查询结果（5 分钟 TTL） |
|
|
||||||
| 连续调用 | 无间隔连续调用 API | 最小间隔 500ms |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 五、唤醒机制
|
|
||||||
|
|
||||||
### 5.1 Cron 定时唤醒
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# COO 健康检查唤醒
|
|
||||||
cron:
|
|
||||||
schedule: "*/5 * * * *" # 每 5 分钟
|
|
||||||
action: health_check
|
|
||||||
targets:
|
|
||||||
- 检查所有 Agent 最后活跃时间
|
|
||||||
- 超过 15 分钟无活动 → 触发唤醒消息
|
|
||||||
- 超过 30 分钟无活动 → 通知 Vincent
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.2 唤醒消息模板
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## 🔔 唤醒检查
|
|
||||||
|
|
||||||
距上次活跃时间：{elapsed} 分钟
|
|
||||||
当前任务状态：{status}
|
|
||||||
是否存在阻塞：{blocked}
|
|
||||||
|
|
||||||
系统自动唤醒，请确认状态。
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.3 自唤醒规则
|
|
||||||
|
|
||||||
每个 Agent 在 HEARTBEAT.md 中配置：
|
|
||||||
|
|
||||||
```
|
|
||||||
如果距上次心跳超过 2 个周期（20 分钟）：
|
|
||||||
→ 自动重新评估任务状态
|
|
||||||
→ 如有待办，立即执行
|
|
||||||
→ 如无待办，确认存活
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 六、上下文/Token 溢出防护
|
|
||||||
|
|
||||||
### 6.1 配置文件大小限制
|
|
||||||
|
|
||||||
| 文件 | 最大行数 | 超标处理 |
|
|
||||||
|------|----------|----------|
|
|
||||||
| AGENTS.md | 200 | 移到 docs/agent-roster.md |
|
|
||||||
| SOUL.md | 80 | 提取模块化引用 |
|
|
||||||
| TOOLS.md | 100 | 索引化（不填塞参数） |
|
|
||||||
| HEARTBEAT.md | 60 | 精简检查清单 |
|
|
||||||
| MEMORY.md | 150 | 定期归档旧条目 |
|
|
||||||
|
|
||||||
### 6.2 运行时监控
|
|
||||||
|
|
||||||
```
|
|
||||||
Token 使用量达到 80%
|
|
||||||
↓
|
|
||||||
自动清理上下文
|
|
||||||
↓
|
|
||||||
仍超 90%
|
|
||||||
↓
|
|
||||||
重启会话
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 七、监控告警矩阵
|
|
||||||
|
|
||||||
| 指标 | 警告阈值 | 严重阈值 | 通知对象 |
|
|
||||||
|------|----------|----------|----------|
|
|
||||||
| Agent 无响应 | > 15 min | > 30 min | 警告 → COO，严重 → Vincent |
|
|
||||||
| 429 错误率 | > 5% | > 20% | COO |
|
|
||||||
| Token 使用量 | > 80% | > 95% | 该 Agent |
|
|
||||||
| 任务积压 | > 5 pending | > 10 pending | COO |
|
|
||||||
| 任务超时 | > 24h in_progress | > 48h | 警告 → Agent，严重 → Vincent |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 八、实施步骤
|
|
||||||
|
|
||||||
### 阶段 1：即刻生效（今日）
|
|
||||||
- [x] 禁止请示规则 → 已在各 Agent HEARTBEAT.md 中落实
|
|
||||||
- [ ] 心跳频率统一为 10 分钟
|
|
||||||
- [ ] COO 端健康检查 cron 配置
|
|
||||||
|
|
||||||
### 阶段 2：本周完成
|
|
||||||
- [ ] 令牌桶限流配置（按 Agent 分配 RPM）
|
|
||||||
- [ ] 模型降级链配置
|
|
||||||
- [ ] 告警规则上线
|
|
||||||
|
|
||||||
### 阶段 3：持续优化
|
|
||||||
- [ ] 监控面板搭建
|
|
||||||
- [ ] 自动重启恢复
|
|
||||||
- [ ] 请求合并优化
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 九、交付物清单
|
|
||||||
|
|
||||||
- [x] 运行稳定性保障规范（本文档）
|
|
||||||
- [ ] HEARTBEAT.md 模板更新（含禁止请示 + 自唤醒规则）
|
|
||||||
- [ ] COO 端 cron 健康检查任务
|
|
||||||
- [ ] 令牌桶限流配置
|
|
||||||
- [ ] 告警规则配置
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> 本规范自批准之日起生效。执行中如遇问题，联系 COO（陆怀瑾）。
|
|
||||||
@@ -1,261 +0,0 @@
|
|||||||
# 智能体知识库体系建设规范 v1.0
|
|
||||||
|
|
||||||
> 版本：v1.0（实施版）
|
|
||||||
> 编制：陆怀瑾（COO）
|
|
||||||
> 日期：2026-06-22
|
|
||||||
> 状态：已批准，执行中
|
|
||||||
> 适用范围：所有 Agent
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 一、核心目标
|
|
||||||
|
|
||||||
| 目标 | 实现方式 |
|
|
||||||
|------|----------|
|
|
||||||
| 知识与配置解耦 | 知识库独立于 Agent 配置文件，不计入 Token |
|
|
||||||
| Agent 可主动查询 | 通过多层检索体系按需获取知识 |
|
|
||||||
| 人类可审查优化 | Web UI / 飞书文档支持人工审阅 |
|
|
||||||
| 零 Token 增长 | 知识条目独立存储，仅在使用时加载 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 二、分层检索体系（刘总反馈已纳入）
|
|
||||||
|
|
||||||
### 2.1 检索优先级
|
|
||||||
|
|
||||||
```
|
|
||||||
Agent 需要知识
|
|
||||||
↓
|
|
||||||
第一层: memory_search (corpus=all)
|
|
||||||
→ 搜索 memory/*.md + MEMORY.md + wiki 条目
|
|
||||||
→ 零 Token 消耗，语义检索
|
|
||||||
↓ 未命中
|
|
||||||
第二层: wiki_search / wiki_get
|
|
||||||
→ 编译型结构化知识库
|
|
||||||
→ 支持精确检索和页面读取
|
|
||||||
↓ 未命中
|
|
||||||
第三层: qmd (QMD 全文检索，已安装 ← 刘总反馈)
|
|
||||||
→ 本地全文检索 markdown 知识库
|
|
||||||
→ 补充 memory_search 未覆盖的长文档
|
|
||||||
↓ 未命中
|
|
||||||
第四层: web_search / web_fetch
|
|
||||||
→ 外部互联网补充
|
|
||||||
→ 仅在内部均未命中时使用
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2.2 工具速查
|
|
||||||
|
|
||||||
| 工具 | 适用场景 | Token 消耗 |
|
|
||||||
|------|----------|-----------|
|
|
||||||
| memory_search | 通用语义检索（跨 memory + wiki） | 0 |
|
|
||||||
| wiki_search / wiki_get | 结构化知识库精确查询 | 0 |
|
|
||||||
| qmd | 本地全文检索长文档 | 0 |
|
|
||||||
| web_search | 外部互联网信息 | 0 |
|
|
||||||
| web_fetch | 网页/文档详情获取 | 按内容量 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 三、知识库目录结构
|
|
||||||
|
|
||||||
```
|
|
||||||
knowledge/
|
|
||||||
├── 电商/ # 电商运营知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── 内容/ # 内容运营知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── 产品/ # 产品管理知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── 技术/ # 技术开发知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── 设计/ # UI/UX 设计知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
├── 运营/ # 通用运营知识
|
|
||||||
│ └── {主题}_v{M}.{N}.md
|
|
||||||
│
|
|
||||||
└── 规范/ # 流程规范知识
|
|
||||||
└── {主题}_v{M}.{N}.md
|
|
||||||
```
|
|
||||||
|
|
||||||
### 知识条目模板
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {知识标题}
|
|
||||||
|
|
||||||
> 领域: {所属领域} | 版本: v{M}.{N}
|
|
||||||
> 维护者: {责任人} | 最后更新: {YYYY-MM-DD}
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
{知识的用途和价值，1-2 句话}
|
|
||||||
|
|
||||||
## 适用范围
|
|
||||||
{在什么场景下使用}
|
|
||||||
|
|
||||||
## 核心内容
|
|
||||||
{知识主体}
|
|
||||||
|
|
||||||
## 操作步骤 / SOP
|
|
||||||
1. ...
|
|
||||||
2. ...
|
|
||||||
|
|
||||||
## 质量检查
|
|
||||||
- [ ] ...
|
|
||||||
|
|
||||||
## 常见问题
|
|
||||||
**Q**: ... **A**: ...
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
- knowledge/{领域}/{关联主题}.md
|
|
||||||
|
|
||||||
## 版本历史
|
|
||||||
| 版本 | 日期 | 变更 | 作者 |
|
|
||||||
|------|------|------|------|
|
|
||||||
| v1.0 | 2026-06-22 | 初稿 | 陆怀瑾 |
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 四、与 Memory 系统的分工
|
|
||||||
|
|
||||||
| 维度 | Memory 系统 | Knowledge 系统 |
|
|
||||||
|------|------------|---------------|
|
|
||||||
| 内容类型 | 决策记录、经验教训、个性化记忆 | SOP、模板、规范、最佳实践 |
|
|
||||||
| 所有者 | 单个 Agent 专属 | 跨 Agent 共享 |
|
|
||||||
| 更新频率 | 每日/每周 | 按需/按版本 |
|
|
||||||
| 查询方式 | memory_search（语义检索） | wiki_search/wiki_get/qmd |
|
|
||||||
| 存储位置 | MEMORY.md + memory/*.md | knowledge/ 目录 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 五、Agent 查询指南
|
|
||||||
|
|
||||||
### 5.1 何时查询知识库
|
|
||||||
|
|
||||||
| 场景 | 查询示例 |
|
|
||||||
|------|----------|
|
|
||||||
| 执行 SOP 任务 | "淘宝 活动报名 SOP" |
|
|
||||||
| 撰写文档 | "PRD 模板" |
|
|
||||||
| 遇到问题 | "部署 故障排查" |
|
|
||||||
| 制定规范 | "开发规范" |
|
|
||||||
| 不熟悉领域 | "小红书 运营指南" |
|
|
||||||
|
|
||||||
### 5.2 查询标准流程
|
|
||||||
|
|
||||||
```
|
|
||||||
1. 先用 memory_search(corpus=all, query="...") 搜索
|
|
||||||
2. 如有结果，用 memory_get 或 wiki_get 读取详情
|
|
||||||
3. 如无结果，用 qmd 全文检索 knowledge/ 目录
|
|
||||||
4. 仍无结果，记录知识缺口，通知 COO
|
|
||||||
5. 使用获取的知识指导工作
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5.3 知识缺口上报
|
|
||||||
|
|
||||||
```
|
|
||||||
Agent 发现知识缺口
|
|
||||||
↓
|
|
||||||
在 memory/YYYY-MM-DD.md 中记录：
|
|
||||||
- 查询内容
|
|
||||||
- 使用场景
|
|
||||||
- 建议优先级
|
|
||||||
↓
|
|
||||||
通知 COO 创建知识条目
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 六、人类审查机制
|
|
||||||
|
|
||||||
### 6.1 审查方式
|
|
||||||
|
|
||||||
| 方式 | 适用场景 | 工具 |
|
|
||||||
|------|----------|------|
|
|
||||||
| Obsidian Web UI | 日常浏览、编辑 | wiki_status 确认可用性 |
|
|
||||||
| 飞书文档同步 | 多人协作、审批 | 飞书 Wiki API |
|
|
||||||
| CLI 直接编辑 | 技术人员修改 | write/edit 工具 |
|
|
||||||
|
|
||||||
### 6.2 审核流程
|
|
||||||
|
|
||||||
```
|
|
||||||
Agent 发现缺口 → 记录 → 通知 COO
|
|
||||||
↓
|
|
||||||
COO 评估优先级
|
|
||||||
↓
|
|
||||||
高优先级 → 立即创建/指派
|
|
||||||
低优先级 → 记入 backlog
|
|
||||||
↓
|
|
||||||
创建草稿 → wiki_apply(op="create_synthesis")
|
|
||||||
↓
|
|
||||||
人类审查 → 通过/修改/拒绝
|
|
||||||
↓
|
|
||||||
发布 → 通知相关 Agent
|
|
||||||
```
|
|
||||||
|
|
||||||
### 6.3 定期质量检查
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# 每周运行一次
|
|
||||||
wiki_lint # 检查链接断裂、矛盾信息、过时内容
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 七、知识条目管理
|
|
||||||
|
|
||||||
### 7.1 创建
|
|
||||||
|
|
||||||
```
|
|
||||||
wiki_apply(op="create_synthesis", title="...", body="...", sourceIds=[])
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7.2 更新
|
|
||||||
|
|
||||||
```
|
|
||||||
wiki_apply(op="synthesis", lookup="...", body="...")
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7.3 版本管理
|
|
||||||
|
|
||||||
| 变更类型 | 版本变化 | 操作 |
|
|
||||||
|----------|----------|------|
|
|
||||||
| 内容微调 | v1.0 → v1.1 | 直接覆盖，更新版本历史 |
|
|
||||||
| 结构性变更 | v1.x → v2.0 | 保留旧版本，新建条目 |
|
|
||||||
| 废弃 | 添加 [deprecated] 标记 | 归档到 archive/ |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 八、初始知识基础
|
|
||||||
|
|
||||||
以下条目作为知识库初始基础，需尽快创建：
|
|
||||||
|
|
||||||
| 领域 | 条目 | 优先级 | 负责 Agent |
|
|
||||||
|------|------|--------|-----------|
|
|
||||||
| 电商 | 淘宝运营 SOP | 高 | 陆云帆 |
|
|
||||||
| 电商 | 客服话术模板 | 中 | 陆云帆 |
|
|
||||||
| 内容 | 小红书运营指南 | 高 | 文墨言 |
|
|
||||||
| 内容 | 标题写作技巧 | 中 | 文墨言 |
|
|
||||||
| 产品 | PRD 模板 | 高 | 沈路明 |
|
|
||||||
| 技术 | 开发规范 | 高 | 梁思筑 |
|
|
||||||
| 技术 | 部署流程 | 中 | 严维序 |
|
|
||||||
| 设计 | UI 设计规范 | 中 | 苏锦绘 |
|
|
||||||
| 运营 | KPI 指标定义 | 中 | 陆怀瑾 |
|
|
||||||
| 规范 | 文档存储规范 | 已完成 | 陆怀瑾 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 九、交付物清单
|
|
||||||
|
|
||||||
- [x] 知识库体系建设规范（本文档）
|
|
||||||
- [ ] knowledge/ 目录结构创建
|
|
||||||
- [ ] 初始知识条目（至少 5 个优先）
|
|
||||||
- [ ] Agent 查询指南（已嵌入本文档）
|
|
||||||
- [ ] 知识审核流程（已嵌入本文档）
|
|
||||||
- [ ] wiki_lint 定期检查 cron 任务
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> 本规范自批准之日起生效。知识条目创建请联系 COO 协调。
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
# [知识条目标题]
|
|
||||||
|
|
||||||
## 元数据
|
|
||||||
|
|
||||||
| 属性 | 值 |
|
|
||||||
|------|-----|
|
|
||||||
| **领域** | 电商 / 内容 / 产品 / 技术 / 设计 / 运营 / 行政 |
|
|
||||||
| **责任人** | [Agent 名称] |
|
|
||||||
| **版本** | v1.0 |
|
|
||||||
| **创建日期** | YYYY-MM-DD |
|
|
||||||
| **最后更新** | YYYY-MM-DD |
|
|
||||||
| **标签** | [标签1, 标签2, ...] |
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
[用 2-3 句话描述本条目的核心内容和使用场景]
|
|
||||||
|
|
||||||
## 正文
|
|
||||||
|
|
||||||
[详细的知识内容，包括步骤、规则、示例等]
|
|
||||||
|
|
||||||
## 相关条目
|
|
||||||
|
|
||||||
- [相关知识条目1](链接)
|
|
||||||
- [相关知识条目2](链接)
|
|
||||||
|
|
||||||
## 变更记录
|
|
||||||
|
|
||||||
| 日期 | 版本 | 变更说明 | 变更人 |
|
|
||||||
|------|------|----------|--------|
|
|
||||||
| YYYY-MM-DD | v1.0 | 初始创建 | [姓名] |
|
|
||||||
Reference in New Issue
Block a user