Pine/opc-backup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Pine
2026-08-19 20:54:01 +08:00
commit 2b0d7a8e98
140 changed files with 41971 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/Creative-Cards-DESIGN.md
+145
View File
@@ -0,0 +1,145 @@
---
version: "alpha"
name: "Creative Cards"
description: "Creative Cards Feature Section is designed for highlighting product capabilities and value points. Key features include reusable structure, responsive behavior, and production-ready presentation. It is suitable for component libraries and responsive product interfaces."
colors:
primary: "#FF7657"
secondary: "#DFFF65"
tertiary: "#F97316"
neutral: "#FFFFFF"
background: "#FFFFFF"
surface: "#FF7657"
text-primary: "#171714"
text-secondary: "#77766F"
border: "#171714"
accent: "#FF7657"
typography:
display-lg:
fontFamily: "Inter"
fontSize: "68px"
fontWeight: 500
lineHeight: "68px"
letterSpacing: "-0.05em"
body-md:
fontFamily: "Inter"
fontSize: "14px"
fontWeight: 400
lineHeight: "22.75px"
spacing:
base: "12px"
sm: "1px"
md: "3.4px"
lg: "12px"
xl: "14.96px"
gap: "12px"
card-padding: "16px"
section-padding: "32px"
components:
card:
backgroundColor: "#1E1E1A"
rounded: "20px"
padding: "16px"
---
## Overview
- **Composition cues:**
- Layout: Grid
- Content Width: Full Bleed
- Framing: Open
- Grid: Strong
## Colors
The color system uses dark mode with #FF7657 as the main accent and #FFFFFF as the neutral foundation.
- **Primary (#FF7657):** Main accent and emphasis color.
- **Secondary (#DFFF65):** Supporting accent for secondary emphasis.
- **Tertiary (#F97316):** Reserved accent for supporting contrast moments.
- **Neutral (#FFFFFF):** Neutral foundation for backgrounds, surfaces, and supporting chrome.
- **Usage:** Background: #FFFFFF; Surface: #FF7657; Text Primary: #171714; Text Secondary: #77766F; Border: #171714; Accent: #FF7657
- **Gradients:** bg-gradient-to-br from-white/80 to-black/5 via-white/20, bg-gradient-to-br from-white/10 to-black/40 via-black/0, bg-gradient-to-br from-white to-black/5 via-white
## Typography
Typography relies on Inter across display, body, and utility text.
- **Display (`display-lg`):** Inter, 68px, weight 500, line-height 68px, letter-spacing -0.05em.
- **Body (`body-md`):** Inter, 14px, weight 400, line-height 22.75px.
## Layout
Layout follows a grid composition with reusable spacing tokens. Preserve the grid, full bleed structural frame before changing ornament or component styling. Use 12px as the base rhythm and let larger gaps step up from that cadence instead of introducing unrelated spacing values.
Treat the page as a grid / full bleed composition, and keep that framing stable when adding or remixing sections.
- **Layout type:** Grid
- **Content width:** Full Bleed
- **Base unit:** 12px
- **Scale:** 1px, 3.4px, 12px, 14.96px, 16px, 24px, 32px, 45px
- **Section padding:** 32px, 50px, 55px, 96px
- **Card padding:** 16px, 32px
- **Gaps:** 12px, 16px, 32px, 56px
## Elevation & Depth
Depth is communicated through elevated, border contrast, and reusable shadow or blur treatments. Keep those recipes consistent across hero panels, cards, and controls so the page reads as one material system.
Surfaces should read as elevated first, with borders, shadows, and blur only reinforcing that material choice.
- **Surface style:** Elevated
- **Borders:** 1px #171714; 1px #FFFFFF
- **Shadows:** rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.1) 0px 20px 25px -5px, rgba(0, 0, 0, 0.1) 0px 8px 10px -6px; rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.04) 0px 8px 30px 0px; rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.05) 0px 1px 2px 0px
### Techniques
- **Gradient border shell:** Use a thin gradient border shell around the main card. Wrap the surface in an outer shell with 1px padding and a 32px radius. Drive the shell with linear-gradient(to right bottom, rgba(255, 255, 255, 0.8), rgba(255, 255, 255, 0.2), rgba(0, 0, 0, 0.05)) so the edge reads like premium depth instead of a flat stroke. Keep the actual stroke understated so the gradient shell remains the hero edge treatment. Inset the real content surface inside the wrapper with a slightly smaller radius so the gradient only appears as a hairline frame.
## Shapes
Shapes rely on a tight radius system anchored by 4px and scaled across cards, buttons, and supporting surfaces. Icon geometry should stay compatible with that soft-to-controlled silhouette.
Use the radius family intentionally: larger surfaces can open up, but controls and badges should stay within the same rounded DNA instead of inventing sharper or pill-only exceptions.
- **Corner radii:** 4px, 20px, 31px, 32px, 9999px
- **Icon treatment:** Linear
- **Icon sets:** Solar
## Components
Reuse the existing card surface recipe for content blocks.
### Cards and Surfaces
- **Card surface:** background #1E1E1A, border 1px solid rgba(255, 255, 255, 0.2), radius 20px, padding 16px, shadow rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.25) 0px 25px 50px -12px.
### Iconography
- **Treatment:** Linear.
- **Sets:** Solar.
## Do's and Don'ts
Use these constraints to keep future generations aligned with the current system instead of drifting into adjacent styles.
### Do
- Do use the primary palette as the main accent for emphasis and action states.
- Do keep spacing aligned to the detected 12px rhythm.
- Do reuse the Elevated surface treatment consistently across cards and controls.
- Do keep corner radii within the detected 4px, 20px, 31px, 32px, 9999px family.
### Don't
- Don't introduce extra accent colors outside the core palette roles unless the page needs a new semantic state.
- Don't mix unrelated shadow or blur recipes that break the current depth system.
- Don't exceed the detected moderate motion intensity without a deliberate reason.
## Motion
Motion feels controlled and interface-led across text, layout, and section transitions. Timing clusters around 700ms and 600ms. Easing favors ease and 0.2. Scroll choreography uses GSAP ScrollTrigger for section reveals and pacing.
**Motion Level:** moderate
**Durations:** 700ms, 600ms, 300ms, 500ms, 1000ms
**Easings:** ease, 0.2, 1), cubic-bezier(0.2, 0.8, 0
**Scroll Patterns:** gsap-scrolltrigger
docs/云南省OPC超级个体综合服务平台（云超服）系统设计方案.md
+2411
View File
File diff suppressed because it is too large Load Diff
docs/云超服平台全量方案设计.md
+600
View File
@@ -0,0 +1,600 @@
# 云超服·平台全量方案设计（身份体系 · 端口管理 · 业务全流程）
> 依据《云南省OPC超级个体综合服务平台（云超服）系统设计方案》扩充为可落地的全量方案。
> 本文档定义完整身份体系、六端口全部管理功能、业务对象状态机、数据模型、接口设计与横切能力，作为编码蓝本。
---
## 目录
1. 总体设计
2. 身份与账号体系
3. 权限模型（RBAC + 数据范围 + 权限矩阵全表）
4. 平台运营端管理
5. 政务端管理（三级联动）
6. 企业端管理（发标全流程）
7. 服务商端管理（服务入驻 OPC）
8. 载体端管理（管理载体内 OPC）
9. OPC 端管理（全生命周期）
10. 投资人端管理（投融资 · 线上路演 · 培训）
11. 业务对象状态机
12. 数据模型（库表设计）
13. 接口设计概览
14. 横切能力（通知/审计/信用/结算/合同/争议）
15. 实施路线
---
## 1. 总体设计
### 1.1 目标
构建云南省级「OPC 超级个体综合服务平台」，以六大端口服务 OPC 超级个体，实现政务三级联动、生态服务闭环、数据智能驱动。
### 1.2 设计原则
- **一个核心**：OPC 超级个体为服务核心。
- **两大驱动**：AI 智能体驱动 + 数据智能驱动。
- **三大体系**：政务服务体系、生态服务体系、成长赋能体系。
- **七大端口**：运营/政务/企业/服务商/载体/OPC/投资人，数据互通、权限隔离。
- **三级联动**：省→市→区县，上级看下级，下级看本级及以下。
- **身份即权限**：账号绑定多端口身份，登录选择、头像切换。
### 1.3 核心概念
- **账号（Account）**：登录主体（手机号/用户名/微信等），一个账号可绑定多个端口身份。
- **身份（Identity）**：账号在某端口的业务身份 = (port, role, sub_role, org, region)。
- **组织（Organization）**：企业/服务商/载体的机构实体，身份可归属组织。
- **数据范围（Scope）**：政务端按 region 层级推导可见数据。
---
## 2. 身份与账号体系
### 2.1 账号生命周期
```
注册 → 实名认证 → 绑定端口身份 → 登录(身份选择) → 运行(头像切换) → 注销/冻结
```
- 注册方式：手机号 / 微信 / 支付宝 / 电子社保卡。
- 一个账号可同时绑定：运营 + 政务 + 企业 + 服务商 + 载体 + OPC 中多个身份（如 `pine` 全端口）。
- 身份可被授权/回收（运营端/政务机构管理员操作）。
### 2.2 身份类型总表
| port | role | sub_role | 职责要点 |
|---|---|---|---|
| operator | operator | op_super_admin / op_admin / op_customer_service / op_finance / op_analyst / op_techops | 平台全量管理 |
| government | government | gov_province / gov_city / gov_district / gov_org_admin / gov_op_account | 三级政务 |
| enterprise | enterprise | admin / operator | 企业需求方 |
| provider | provider | admin / operator | 专业服务商 |
| carrier | carrier | admin / operator | 创业载体 |
| opc_member | opc_member | certified / independent | 超级个体 |
| investor | investor | org_director / org_manager / personal | 机构/个人投资人 |
---
## 3. 权限模型
### 3.1 权限码分类
- `menu:*` 功能菜单（决定侧边栏可见性）。
- `action:*` 操作权限（决定按钮/接口可用性）。
- **数据范围**（`scope_region_ids`）：政务端由 region 推导「本级 + 后代」。
### 3.2 权限矩阵全表（`role|sub_role` → permissions）
```
operator|op_super_admin
menu:operator_dashboard, menu:admin_user_mgmt, menu:admin_role_mgmt, menu:audit,
menu:task_mgmt, menu:provider_mgmt, menu:content_mgmt, menu:policy_mgmt, menu:settle_mgmt, menu:system_config,
action:user.*, action:role.*, action:task.audit, action:provider.audit, action:policy.publish,
action:settle.release, action:config.*, action:audit.view, action:data.export
operator|op_admin
menu:task_mgmt, menu:provider_mgmt, menu:content_mgmt, menu:policy_mgmt,
action:task.audit, action:provider.audit, action:content.manage, action:policy.publish
operator|op_customer_service
menu:ticket_mgmt, action:ticket.handle, action:dispute.handle
operator|op_finance
menu:settle_mgmt, action:settle.release, action:fund.deposit, action:commission.adjust
operator|op_analyst
menu:dashboard, menu:report, action:data.export, action:report.generate
operator|op_techops
menu:system_config, menu:audit, action:config.*, action:audit.view
government|gov_province
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy, menu:gov_subsidy,
action:data.view.all, action:carrier.audit, action:policy.publish, action:subsidy.approve
government|gov_city
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy, menu:gov_subsidy,
action:data.view.city, action:carrier.audit, action:policy.publish, action:subsidy.approve
government|gov_district
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy,
action:data.view.district, action:carrier.audit, action:opc.audit, action:policy.publish, action:subsidy.approve
government|gov_org_admin
menu:gov_admin, action:account.manage, action:data.view.org
government|gov_op_account
menu:government_dashboard, menu:gov_data, action:data.view.scope
enterprise|admin
menu:enterprise_dashboard, menu:ent_task, menu:ent_talent, menu:ent_project,
action:task.publish, action:task.bid.evaluate, action:fund.deposit, action:task.accept, action:org.manage
enterprise|operator
menu:enterprise_dashboard, menu:ent_task, menu:ent_talent, action:task.view, action:talent.search
provider|admin
menu:provider_dashboard, menu:pro_service, menu:pro_order, menu:pro_client,
action:service.manage, action:order.deliver, action:client.manage, action:settle.withdraw
provider|operator
menu:provider_dashboard, menu:pro_order, action:order.deliver, action:service.view
carrier|admin
menu:carrier_dashboard, menu:car_opc, menu:car_space, menu:car_service,
action:opc.bind, action:opc.audit, action:space.manage, action:service.refer
carrier|operator
menu:carrier_dashboard, menu:car_opc, action:opc.view, action:space.view
opc_member|certified
menu:opc_dashboard, menu:opc_task, menu:opc_service, menu:opc_finance, menu:opc_policy,
action:task.bid, action:task.deliver, action:service.buy, action:policy.apply, action:finance.view
opc_member|independent
menu:opc_dashboard, menu:opc_task, menu:opc_service,
action:task.bid, action:service.buy
investor|org_director
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow, menu:investor_training,
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.publish, action:roadshow.host, action:invest.decide
investor|org_manager
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow,
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.attend
investor|personal
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow, menu:investor_training,
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.attend, action:roadshow.register
```
### 3.3 数据范围推导
- 省级：`province` → 全省 region 后代。
- 市级：`city` → 本市 + 所辖区县。
- 区县级：`district` → 本区县。
- 组织范围：企业/服务商/载体按 `org_id` 归属。
- 越权访问一律 403；写操作落审计。
---
## 4. 平台运营端管理（总控中心）
### 4.1 用户与账号管理
- 列表/搜索/分页/导出（手机号、角色、状态、注册时间）。
- 绑定身份（为账号添加/移除端口身份）、分配角色/子角色、设组织与区域。
- 启用/禁用/冻结账号、重置密码、吊销令牌。
- 操作审计。
### 4.2 角色与权限管理
- 角色 CRUD、角色-权限矩阵配置、子角色维护。
- 权限码字典维护、按角色预览权限。
### 4.3 任务审核
- 待审队列 → 通过/驳回（附原因）→ 违规任务下架 → 任务规则字典维护。
### 4.4 服务商准入与评级
- 入驻申请审核（资质/能力/背景）→ 签订协议 → 开通后台。
- 等级评定（认证/优质/金牌/官方）、升降级规则、黑名单。
### 4.5 内容与政策
- 资讯/公告/活动管理；政策发布（平台级）。
### 4.6 数据大屏与报表
- 全平台指标（用户/任务/成交额/服务商/载体/政策覆盖率）。
- 多维分析（OPC/任务/政策）、排行、定期报表。
### 4.7 结算与资金
- 资金托管台账、佣金比例配置、结算流水、提现审核、对账。
### 4.8 系统配置
- 全局参数、字典、审批流配置、平台费率、通知模板。
### 4.9 工单与审计
- 客服工单流转、争议仲裁；全量审计日志（按人/按对象检索、导出）。
---
## 5. 政务端管理（三级联动）
### 5.1 数据看板（按范围）
- 核心指标：OPC 总数/新增/活跃、载体数、任务数、成交额、政策覆盖率。
- 分布/趋势/排行（区县/载体/行业）。
### 5.2 载体管理
- 范围内载体列表/详情；入驻审核；等级评定；空间与入驻率数据。
### 5.3 OPC 管理
- 范围内 OPC 列表/详情；入驻审核；认证状态；信用/活跃度。
### 5.4 政策发布（多级审核）
```
起草 → 内部审核 → 上级/本级发布 → 定向推送(匹配OPC) → AI+人工解读 → 效果追踪(触达/申报/兑现)
```
### 5.5 补贴管理
- 补贴政策配置 → OPC 申报 → 初审(区县) → 复审(市) → 终审(省) → 发放 → 追踪。
### 5.6 收入/交易数据
- 范围内任务成交额、服务商订单额、载体营收，按时间/区域聚合。
### 5.7 审计
- 本级及下级操作日志；数据导出。
---
## 6. 企业端管理（发标全流程）
### 6.1 企业档案
- 企业介绍、资质、LOGO、联系方式；管理员维护，操作者查看。
### 6.2 人才搜索
- 按技能/行业/信用/地域/档期搜索 OPC；查看档案、历史交付、评价；收藏/邀请。
### 6.3 任务发布（发标）— 状态机
```
draft → pending(审核) → published
→ 接单: grab(抢单) / bid(竞标) / designated(指定) / dispatch(派单)
→ in_progress → delivered → review(验收)
├ 通过 → completed(结算+评价)
├ 驳回 → in_progress(限期修改)
└ 争议 → 平台仲裁
→ cancelled(违约/超时)
```
### 6.4 发标校验规则
- 分类必填、预算 `0 < min ≤ max`、托管金 ≥ 预算下限、deadline > now、合规审核。
- 竞标：≥1 标书才可评标；未中标释放保证金。
- 违约：超时/恶意 → 扣信用、扣保证金。
### 6.5 项目管理
- 任务看板（状态/进度/交付物）、阶段沟通、验收（通过/驳回/修改）、评价、结算查看。
### 6.6 合同与保障
- 电子合同签署、资金托管、履约险、争议处理、知识产权约定。
---
## 7. 服务商端管理（为入驻 OPC 提供服务）
### 7.1 服务商品管理
- 商品类型：标准化/定制/订阅/按次/免费。
- 商品 CRUD、定价、上下架、案例、评价聚合。
### 7.2 订单与交付
- 订单状态机：`pending(待支付) → paid(已支付/托管) → delivering(服务中) → delivered(已交付) → confirmed(已确认) → settled(已结算) / refunding(退款)`。
- 服务对象管理：为入驻 OPC 建立服务关系、跟进记录。
### 7.3 客户运营
- 服务过的 OPC 列表、续费提醒、回访记录、评价管理。
### 7.4 结算与评级
- 订单收入、提现、平台佣金；服务评分与等级升降。
### 7.5 服务品类
- 财税 / 工商 / 法务 / 知识产权 / 云服务 / 算力 / 培训。
---
## 8. 载体端管理（管理载体内 OPC）
### 8.1 入驻 OPC 管理
- 入驻申请审核、绑定关系管理、解绑；工位分配。
- OPC 状态：`申请中 → 已入驻 → 已迁出`。
### 8.2 空间/工位管理
- 工位总数/在用/空闲、入驻率、收费标准。
### 8.3 服务对接
- 引荐服务商给园区内 OPC（三方绑定：载体-服务商-OPC）；服务进度跟踪。
### 8.4 园区数据
- 入驻率、订单、营收、政策申报统计；对外展示载体简介。
---
## 9. OPC 端全量功能设计（超级个体全生命周期工作台）
OPC 端是平台**服务核心**，以「档案-任务-财税-工商-政务-智能体」为主线，提供创业经营一站式工作台。
### 9.1 基础资料编辑
**功能**：维护个人与经营资料，支撑信用、认证、任务匹配。
- **基本资料**：姓名/头像/联系方式/简介/自我介绍。
- **经营资料**：经营类型（个人创业者/个体工商户/自由职业者/小微经营者/灵活就业）、行业领域、所在区域、技能标签（多选+自定义）、服务能力、作品/案例、可接单档期。
- **联系方式**：手机号（登录绑定）、微信/邮箱（可选）。
- **资料可见性**：对企业/载体展示的公开字段可单独开关；私密字段（身份证等）仅本人/认证可用。
- **校验**：昵称/简介长度、技能标签数上限、区域必填；修改记录留痕。
**字段**：`opc_profiles(id, user_id, real_name, avatar, intro, biz_type, industry, region_id, skills[], cases[], schedule, cert_status, credit_score, ...)`
### 9.2 认证体系
- **实名认证**：身份证 OCR + 人脸活体 → `unverified → verifying → verified`。
- **工商认证（可选）**：营业执照 OCR + 市场监管局核验 → `无 → 待核验 → 已认证`。
- **技能/资质认证**：上传资质证书、平台技能测试 → 技能标签获得官方背书。
- 认证影响：认证 OPC（`certified`）可绑载体、投标权重更高、可申报补贴；未认证为 `independent`。
### 9.3 载体绑定
- 自主选择载体申请入驻 / 载体邀请绑定 / 平台推荐。
- 状态：`未绑定 → 申请中 → 已入驻(认证OPC可绑) → 已迁出`。
- 绑定后：工位信息、载体服务、载体数据归属、园区政策申报。
### 9.4 接单（抢单 / 指定 / 派单）
**接单模式与规则**：
| 模式 | 流程 | 规则 |
|---|---|---|
| 抢单 grab | OPC 在广场抢单 | 先到先得；同一 OPC 并发抢单加锁防重复；抢到即进入执行 |
| 指定 designated | 企业指定 OPC | OPC 确认接受 / 拒绝；限时确认 |
| 派单 dispatch | 平台智能派单 | 平台按匹配度派给 OPC；可接受/拒绝 |
| 竞标 bid | 见 9.5 | 投标→企业选标→中标进入执行 |
- 抢单校验：任务状态=published、OPC 未被拉黑、任务未满额、无进行中冲突（可选）。
- 接单后：任务状态 → `in_progress`，生成项目空间与里程碑。
### 9.5 投标（竞标）
**投标流程**：
```
查看竞标任务 → 提交标书(方案/报价/周期/承诺) → 待评标
→ 中标 won → 签署/进入执行
→ 未中标 lost → 释放(若缴纳投标保证金则退回)
→ 撤回 withdrawn
```
- **标书字段**：报价、交付周期、方案说明、附件、可交付样例。
- **校验**：报价 ∈ 企业预算范围、周期 ≤ 任务截止、资质/信用达标、未重复投标同一任务。
- **投标状态**：`draft → submitted → won / lost / withdrawn`。
- 中标后锁定任务；未中标自动释放保证金。
### 9.6 任务进度管理
**项目空间**（任务 `in_progress` 后建立）：
- **里程碑**：按任务分期设置里程碑（计划/实际、状态）。
- **进度更新**：OPC 更新进度百分比、填写说明、标记阶段完成。
- **交付物**：上传交付文件/说明 → `delivered`。
- **阶段沟通**：与企业消息往来、@企业、附件。
- **验收**：企业通过 → 进入结算；驳回 → 限期修改（最多 N 次）；争议 → 平台仲裁。
- **时间线**：全流程节点留痕（时间/动作/操作者）。
### 9.7 财税管理
**功能模块**：
- **一键记账**：发票/交易流水自动归集 → 生成凭证；手动补充收支。
- **财务报表**：利润表、资产负债表、现金流量表（月/季/年）。
- **税务申报**：申报周期提醒、申报表预填、在线申报、申报记录。
- **发票管理**：开票申请、进项/销项发票归集、抬头管理。
- **收支明细**：`finance_records(category=income|expense, amount, date, note, source)`；月/年聚合、图表。
- **税务日历**：报税/缴费节点提醒。
### 9.8 工商与政务管理
- **工商服务**（对接服务商/政务）：公司注册、变更登记、年报公示、注销登记、资质办理。
- **办事流程**：发起事项 → 材料上传 → 服务商/政务办理 → 进度追踪 → 结果反馈。
- **政策服务**：政策库浏览、**智能匹配**（按行业/区域/认证）、一键申报、申报进度追踪、补贴到账。
- **政务事项**：区县级政务端可查看本区县 OPC 的办事/申报记录；补贴三级审批结果反馈。
- **办事状态**：`draft → submitted → processing → done / rejected`。
### 9.9 服务购买
- 服务市场浏览/搜索/下单 → 支付（资金托管）→ 服务商交付 → 确认 → 评价。
### 9.10 信用与金融
- **信用画像**：履约（按时交付/验收通过率）、评价（服务商/企业互评）、违规记录；信用等级与积分。
- **信用应用**：推荐权重、保证金比例、权限（认证/补贴）、违约惩戒。
- **金融**：融资产品浏览/智能匹配、支付结算、保险、信用贷。
### 9.11 消息与智能体
- **消息中心**：任务/政策/订单/补贴/系统通知（站内信+推送）。
- **智能体助手**：个性化记忆、工具调用；创业助手（政策/补贴）、经营管家（财税/订单）、任务经纪人（接单/投标建议）、学习教练（技能提升）。
### 9.12 OPC 端状态机（对象级）
| 对象 | 状态流 |
|---|---|
| 实名认证 | unverified / verifying / verified |
| 工商认证 | none / verifying / certified |
| 载体绑定 | unbound / applying / joined / exited |
| 投标 | draft / submitted / won / lost / withdrawn |
| 任务(承接) | published / in_progress / delivered / review / completed / cancelled / disputed |
| 交付物 | uploading / submitted / reviewing / accepted / rejected |
| 财税申报 | draft / submitted / filed / failed |
| 办事(工商/政务) | draft / submitted / processing / done / rejected |
| 服务订单(购买) | pending / paid / delivering / delivered / confirmed / settled |
**OPC 端接口**：`/opc/profile`(读)、`PUT /opc/profile`(编辑)、`POST /opc/verify`(认证)、`POST /opc/carrier/apply`(绑载体)、`GET /opc/tasks`(广场)、`POST /opc/tasks/{id}/grab`(抢单)、`POST /opc/tasks/{id}/bid`(投标)、`GET /opc/my-tasks`、`POST /opc/tasks/{id}/progress`(进度)、`POST /opc/tasks/{id}/deliver`(交付)、`GET /opc/finance`、`POST /opc/finance/record`、`GET /opc/tax`、`POST /opc/affairs`(工商/办事)、`GET /opc/policy`、`POST /opc/policy/{id}/apply`(申报)、`GET /opc/services`、`POST /opc/services/{id}/order`、`GET /opc/messages`、`GET /opc/agent`。
---
## 10. 投资人端全量功能设计（投融资 · 线上路演 · 培训）
投资人端连接**资本与创业项目**，支持机构/个人投资人设定投资方向、查看项目、投融资对接、发布与参与线上路演、以及投融资培训。
### 10.1 投资人身份与认证
| sub_role | 名称 | 说明 |
|---|---|---|
| `org_director` | 机构投资总监 | 投资决策、活动发布/主持 |
| `org_manager` | 机构投资经理 | 项目筛选、约谈、尽调、参会 |
| `personal` | 个人投资人 | 天使投资、跟投、参会 |
- 机构认证：营业执照/基金资质、投资领域、管理规模。
- 个人认证：实名、投资经历、可投资金区间。
### 10.2 投资方向设置（preference）
- **领域偏好**：云计算/人工智能/生物医药/文旅/农业科技/智能制造/新能源/消费等（多选）。
- **阶段偏好**：种子 / 天使 / A轮 / B轮 / 成长期。
- **金额区间**：单笔投资 min–max。
- **地域偏好**：省/市/区县（默认云南省内）。
- **关注信号**：收到匹配项目/路演推送。
### 10.3 项目查看（投融资对接）
- **项目库**：展示融资项目（来源：OPC/企业/载体上架项目），含：项目名、团队、行业、阶段、融资额、估值、BP（商业计划书）、亮点、融资进度。
- **筛选/搜索**：按行业/阶段/融资金额/地域/认证。
- **项目详情**：BP 阅读、团队、财务/经营数据（授权后）、融资状态。
- **收藏/关注**、**约谈**（发起意向 → 对方确认 → 私聊/会议）。
### 10.4 投资意向与流程
```
感兴趣 interested → 已约谈 contacted → 尽调/会面 meeting → 意向书 term_sheet → 已投资 invested / 已婉拒 declined
```
- 意向记录：约谈时间、沟通纪要、BP 版本。
- 尽调：资料清单、进度、风险评估。
- 投资决策：额度、估值、条款（机构总监决策）。
### 10.5 投融资活动（线上/线下）全流程
**发布主体与范围**
| 发布主体 | 允许的活动范围 | 审核要求 |
|---|---|---|
| 投资机构 | 全网 / 指定载体/区域 | 一律需**运营方审核**（第三方商业活动） |
| 政务（省/市/区县） | 自身权限范围（region 内） | **免审直发**（自己权限内） |
| 政务 | 超出自身范围（全省/全网） | 需**运营方审核** |
| 平台运营方 | 全平台 | 免审（运营方内部走多级审批可选） |
| 载体/企业 | 自身关联范围 | 需运营方审核 |
**活动类型**
- **线上** `online`：直播推流 / 在线会议室 / 连麦 / 回放。
- **线下** `offline`：场地、地址、到会签到。
- **混合** `hybrid`：线上直播 + 线下会场。
**发布与审核状态机**
```
draft 草稿
→（免审主体）→ published 已发布
→（需审主体）→ submitted 待审 → reviewing 审核中
├→ published 已发布
├→ rejected 已驳回（附原因 → 退回 draft 修改后重提）
└→ cancelled 已取消
published → registering 报名中 → ongoing 进行中 → ended 已结束 → archived 已归档
（任意阶段可 cancelled 下架）
```
**范围校验与免审规则**
- 规则：`活动范围 ⊆ 发布者数据范围` 则**免审**，否则**需审核**。
- 政务发布：范围 = 自身 region（省级=全省、市级=本市、区县=本区县）→ 免审；跨级/全网 → 提交审核（市级跨区→省级可审或运营方；全网→运营方）。
- 运营方发布：全平台范围 = 运营方权限 → 免审（内部多级审批可选）。
- 投资机构/载体/企业：活动范围不论如何均需运营方审核。
- 校验实现：`need_review = not (publisher_is_government and scope ⊆ publisher.scope_region_ids) and not publisher_is_operator`。
**活动信息与校验**
- 字段：主题、简介、活动类型（online/offline/hybrid）、开始/结束时间、报名截止、名额、地点/直播间、主持人/嘉宾、BP 要求、可见范围、发布主体。
- 校验：`start < end`、非过去时间、`报名截止 < 开始`、名额为正、内容合规（违禁/敏感）、范围合法。
**报名与可见性**
- 可见范围：全网 / 指定区域 OPC / 指定载体 / 指定投资人。
- 报名角色：项目方（路演，需上传 BP）、投资人（参会）；状态 `applying → approved → attended → absent`。
- 校验：名额、截止时间、可见范围、身份。
**审核与审计**
- 审核记录（审核人/时间/意见/版本）、多级审批可选、操作审计；驳回原因回填、支持修改重提。
**线上路演执行**
- 在线会议室/直播（推流、连麦）、项目依次路演、计时器、一键约谈、提问互动、数据统计、回放归档。
**活动运营**
- 参会名单、项目榜单、路演评分、回放管理、活动数据（观看/约谈/意向转化）。
### 10.6 投融资培训系统
- **课程库**：投融资基础、BP 撰写、估值与条款、尽调实务、路演技巧、股权结构、法律合规（视频/直播/资料）。
- **培训对象**：投资人（进阶）、项目方/OPC（融资准备）、载体（孵化辅导）。
- **课程分类 / 报名 / 学习进度 / 证书**。
- **导师辅导**：资深投资人/创业导师约课、1v1 辅导。
### 10.7 投资组合与数据
- **我的投资**：已投项目跟踪（阶段、估值、退出）、投资金额汇总。
- **数据看板**：关注项目数、意向转化率、活动参与、投资概况。
### 10.8 状态机（投资人端对象）
| 对象 | 状态流 |
|---|---|
| 项目融资 | raising / roadshowing / negotiating / closed / withdrawn |
| 投资意向 | interested / contacted / meeting / term_sheet / invested / declined |
| 路演活动 | draft / submitted / reviewing / published / registering / ongoing / ended / archived（可 rejected / cancelled） |
| 活动报名 | applying / approved / attended / absent |
| 培训课程 | draft / published / ended |
| 培训报名 | applying / enrolled / completed / certificate |
### 10.9 数据模型（投资人端）
- `investors`（投资人档案/机构或个人）、`investment_preferences`（投资方向偏好）。
- `projects`（融资项目）、`financing_rounds`（融资轮次）、`project_bps`（BP 版本）。
- `investment_intents`（投资意向/约谈/尽调）。
- `roadshows`（路演活动）、`roadshow_registrations`（报名）、`roadshow_sessions`（项目路演场次）、`roadshow_replays`（回放）。
- `trainings`（培训课程）、`training_enrollments`（报名/进度/证书）。
### 10.10 接口（投资人端）
`/investor/profile`(读)、`PUT /investor/profile`、`PUT /investor/preferences`、`GET /investor/projects`、`GET /investor/projects/{id}`、`POST /investor/projects/{id}/intent`(约谈)、`GET /investor/intents`、`POST /investor/roadshows`(发布)、`GET /investor/roadshows`、`POST /investor/roadshows/{id}/register`(报名)、`GET /investor/roadshows/{id}/live`(线上路演)、`POST /investor/roadshows/{id}/live/join`、`GET /investor/trainings`、`POST /investor/trainings/{id}/enroll`、`GET /investor/portfolio`。
---
## 11. 业务对象状态机汇总
| 对象 | 状态流 |
|---|---|
| 账号 | active / disabled / frozen / deleted |
| 身份 | active / disabled |
| 入驻(OPC/载体/服务商) | applying / reviewing / approved / rejected / active / exited |
| 任务 | draft / pending / published / in_progress / delivered / review / completed / cancelled / disputed |
| 竞标 | submitted / shortlisted / won / lost / released |
| 订单(服务) | pending / paid / delivering / delivered / confirmed / settled / refunding / cancelled |
| 服务商品 | draft / on_sale / off_sale |
| 政策 | draft / reviewing / published / offline |
| 补贴申报 | applying / district_review / city_review / province_review / approved / paid / rejected |
| 托管金 | deposited / frozen / released / refunded |
| 投标(竞标) | draft / submitted / won / lost / withdrawn |
| 交付物 | uploading / submitted / reviewing / accepted / rejected |
| 实名认证 | unverified / verifying / verified |
| 工商认证 | none / verifying / certified |
| 载体绑定 | unbound / applying / joined / exited |
| 财税申报 | draft / submitted / filed / failed |
| 工商/政务办事 | draft / submitted / processing / done / rejected |
| 争议 | opened / mediating / resolved / closed |
| 工单 | opened / processing / resolved / closed |
| 项目融资 | raising / roadshowing / negotiating / closed / withdrawn |
| 投资意向 | interested / contacted / meeting / term_sheet / invested / declined |
| 路演活动 | draft / submitted / reviewing / published / registering / ongoing / ended / archived（可 rejected / cancelled） |
| 活动报名 | applying / approved / attended / absent |
| 培训课程 / 报名 | draft / published / ended · applying / enrolled / completed / certificate |
---
## 12. 数据模型（库表设计）
核心表（承接现有 `user_identities` / `users` / `organizations` / `regions`）：
- `accounts`（账号）、`user_identities`（身份）、`sessions`（会话）。
- `organizations`（企业/服务商/载体）、`regions`（省市区树）、`opc_profiles`（信用/认证）。
- `tasks`（任务，含 `mode/status/budget/deadline/托管` 字段）、`bids`（竞标：报价/方案/周期/状态）、`deliveries`（交付物：文件/说明/状态/验收）、`escrows`（托管金台账）、`milestones`（任务里程碑）。
- `service_products`（服务商品）、`service_orders`（服务订单）、`service_relations`（载体-服务商-OPC 三方绑定）。
- `content_items`（政策/资讯）、`policies`（政策详情）、`subsidy_applications`（补贴申报）。
- `opc_profiles`（基础资料/技能/认证/信用）、`opc_carrier`（载体绑定关系）、`opc_affairs`（工商/政务办事）、`tax_records`（财税申报）、`finance_records`（收支流水）。
- `investors`（投资人档案/机构或个人）、`investment_preferences`（投资方向）、`projects`（融资项目）、`financing_rounds`、`project_bps`（BP）、`investment_intents`（意向/约谈/尽调）。
- `roadshows`（路演活动）、`roadshow_registrations`（报名）、`roadshow_sessions`（项目路演场次）、`roadshow_replays`（回放）。
- `trainings`（培训课程）、`training_enrollments`（报名/进度/证书）。
- `finance_records`（财务流水）、`settlements`（结算）、`messages`（消息）、`audit_logs`（审计）、`disputes`（争议）、`tickets`（工单）。
- `system_configs`（配置）、`role_permissions` / `permissions`（权限）。
---
## 13. 接口设计概览（REST）
- 认证：`POST /auth/login`、`POST /auth/select-identity`、`GET /auth/me`。
- 运营：`/admin/users`、`/admin/roles`、`/admin/tasks`、`/admin/providers`、`/admin/content`、`/admin/policies`、`/admin/settlements`、`/admin/config`、`/admin/stats/*`。
- 政务：`/government/regions`、`/government/carriers`、`/government/opc`、`/government/policies`、`/government/subsidies`、`/government/data`。
- 企业：`/enterprise/talents`、`/enterprise/tasks`(发标/审核)、`/enterprise/tasks/{id}/accept`、`/enterprise/bids/{id}/evaluate`、`/enterprise/escrow`。
- 服务商：`/provider/products`、`/provider/orders`、`/provider/clients`、`/provider/settlements`。
- 载体：`/carrier/opc`、`/carrier/space`、`/carrier/services`、`/carrier/referrals`。
- OPC：`/opc/tasks`、`/opc/my-tasks`、`/opc/bids`、`/opc/deliveries`、`/opc/services`、`/opc/policy`、`/opc/finance`、`/opc/profile`。
- 投资人：`/investor/profile`、`/investor/preferences`、`/investor/projects`、`/investor/projects/{id}/intent`、`/investor/roadshows`(发布)、`/investor/roadshows/{id}/register`、`/investor/roadshows/{id}/live`、`/investor/trainings`、`/investor/portfolio`。
统一响应：`{ code, message, data }`；分页：`{ items, total, page, size }`；错误：`{ detail }`；鉴权：Bearer JWT（携带 `identity_id`）。
---
## 14. 横切能力
- **通知中心**：站内信/短信/推送；按类型（任务/政策/订单/补贴/消息）。
- **审计日志**：全量记录操作（who/what/when/ip/对象）。
- **信用体系**：信用画像（履约/评价/违规），等级应用（推荐/保证金/权限）。
- **结算**：托管金流转、佣金、提现、对账。
- **合同**：电子合同模板、签署、存证。
- **争议**：仲裁流转、记录、结果反馈信用。
- **安全保障**：RBAC 越权拦截、敏感内容审核、数据导出权限、等保合规。
---
## 15. 实施路线
- **P0 基础**：身份/权限/数据范围、账号多身份、登录选择/切换（已完成核心）。
- **P1 发标闭环**：企业发标状态机 + 抢单/竞标 + 托管 + 验收结算。
- **P2 政务三级**：数据范围过滤、载体/OPC/政策/补贴/收入全流程。
- **P3 生态闭环**：服务商服务商品/订单/交付、载体-服务商引荐、OPC 服务购买。
- **P4 深化**：智能体、信用、结算、大屏、报表、审计、通知全量。
---
## 待确认（如需本方案直接进入编码，可先按默认推进）
1. **发标/托管全流程**（竞标+资金托管+验收）是否 P1 完整实现 → 默认：是。
2. **政务数据范围**按 region 全量过滤 → 默认：是。
3. **载体-服务商-OPC 三方绑定**建实体表 → 默认：是。
4. **结算/信用/审计**是否本期实现 → 默认：审核/信用/审计本期做，结算做托管+佣金台账。
docs/任务类别.json
+28191
View File
File diff suppressed because it is too large Load Diff
docs/架构初步设计.md
+216
View File
@@ -0,0 +1,216 @@
---
Phase 0: 判断
✅ 从零开始的新项目 — 目前只有设计文档，0 行代码 → 执行完整流程
---
Phase 1: 需求澄清（6个必答问题）
根据设计文档，我已推断出答案，请确认：
┌─────┬────────────┬────────────────────────────────────────────────────────────────────────────────┐
│ # │ 问题 │ 答案（已推断） │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 01 │ 产品形态 │ 多端 Web + 移动端：PC 后台（Vue3/React）、移动端 APP、微信/支付宝小程序、H5 │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 02 │ 运行环境 │ 云端部署：阿里云/华为云云南节点，Kubernetes 集群，三级政务联动 │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 03 │ 项目规模 │ 完整产品：但按 4 期路线图分阶段实施（一期 MVP，四期完整产品） │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 04 │ 数据方案 │ 综合数据库：MySQL（主从）+ Redis + MongoDB + Elasticsearch + Milvus 向量数据库 │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 05 │ 前后端分工 │ 前后端分离 + 微服务：Vue3/React 前端，Go 后端 12 个微服务，API 网关统一入口 │
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ 06 │ 扩展预期 │ 必须可扩展：省级平台→市级→区县级三级联动，需水平扩展、多租户、开放平台 │
└─────┴────────────┴────────────────────────────────────────────────────────────────────────────────┘
这些是否符合你的预期？有没有需要调整的地方？
---
Phase 2: 架构选型（3种方案对比）
我基于文档内容和你目前的实际资源情况，提出 3 种架构方案 做对比：
方案对比表
┌──────────┬───────────────────────────────────────────────┬─────────────────────────────────────────┬──────────────────────────────┐
│ 维度 │ 方案 A：Go 微服务（原设计） │ 方案 B：Go 单体先行 + 微服务拆分 │ 方案 C：Node.js 全栈 MVP │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 架构模式 │ 云原生微服务 (12个服务) │ 模块化单体 → 渐进式微服务 │ 三层架构 / BFF │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 后端技术 │ Go 1.22 + go-zero + gRPC + K8s │ Go 1.22 + Gin + go-zero（渐进引入） │ Node.js + Express/NestJS │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 前端技术 │ Vue3 + TypeScript + Element Plus + UniApp │ Vue3 + TypeScript + Vite + Element Plus │ Vue3 + TypeScript + Vite │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 数据库 │ MySQL + Redis + MongoDB + ES + Milvus + Kafka │ MySQL + Redis（按需逐步引入） │ MySQL/SQLite + Redis │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 部署 │ K8s + Helm + ArgoCD + Istio │ Docker Compose / 轻量 K8s │ Docker / 简单部署 │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 开发速度 │ ⭐⭐（前期搭建慢） │ ⭐⭐⭐⭐（快速启动） │ ⭐⭐⭐⭐⭐（最快） │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 可维护性 │ ⭐⭐⭐⭐⭐（长期最优） │ ⭐⭐⭐⭐（平衡） │ ⭐⭐⭐（中期需要重构） │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 扩展性 │ ⭐⭐⭐⭐⭐（最高） │ ⭐⭐⭐⭐（可逐步拆分） │ ⭐⭐（单体天花板低） │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 学习成本 │ ⭐⭐（Go + K8s + 多中间件） │ ⭐⭐⭐⭐（逐步学习） │ ⭐⭐⭐⭐⭐（前端开发者友好） │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 资源消耗 │ 高（12个微服务 + K8s集群） │ 中（先单体后拆分） │ 低（单进程） │
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
│ 适用场景 │ 大型团队、完整产品、长期维护 │ 个人开发者 / 小团队 MVP → 扩展 │ 快速原型验证 │
└──────────┴───────────────────────────────────────────────┴─────────────────────────────────────────┴──────────────────────────────┘
我的推荐：方案 B — Go 单体先行 + 渐进式微服务拆分 ⭐
理由：
1. 你目前是一个人开发（根据目录结构判断），Phase 0 直接上 12 个微服务 + K8s 集群，仅基础设施搭建就要数周
2. Vibe Coding 的核心原则是："先完成，再完美" — 方案 A 过于厚重，方案 C 后期需要大重构
3. 方案 B 的路徑：
- Phase 1（MVP）：Go 模块化单体 + Gin + MySQL + Redis → 快速跑通核心流程
- Phase 2（扩展）：按热点服务拆分为独立微服务（先拆 agent-service 和 task-service）
- Phase 3（成熟）：引入 gRPC + Kafka + K8s，逐步演进到方案 A 架构
4. 技术栈不变：始终是 Go + Vue3，没有技术债务，只有架构演进
---
Phase 3: 任务拆解
云超服 项目总目标
├── 第0阶段：基础设施搭建
│ ├── 0.1 初始化 Go monorepo 项目结构
│ ├── 0.2 前端项目初始化（Vue3 + Vite + TypeScript）
│ ├── 0.3 Docker Compose 开发环境（MySQL + Redis）
│ └── 0.4 基础工具库（错误码、日志、配置、中间件）
│
├── 第1阶段：核心业务 MVP（0-2个月）
│ ├── 1.1 用户中心（注册/登录/认证/JWT/RBAC）← 优先
│ ├── 1.2 OPC 入驻与档案管理
│ ├── 1.3 任务系统（发布、广场、接单、交付）
│ ├── 1.4 基础智能体（对话 + 简单工具调用）
│ ├── 1.5 前端门户布局（OPC端 + 管理端基础框架）
│ └── 1.6 基础数据看板
│
├── 第2阶段：核心服务深化（2-4个月）
│ ├── 2.1 财税服务（记账、报表）
│ ├── 2.2 工商服务（注册、变更）
│ ├── 2.3 政策服务（政策库 + 智能匹配）
│ ├── 2.4 服务商生态（入驻、服务商品）
│ ├── 2.5 智能体增强（RAG + 工具链）
│ └── 2.6 消息通知中心
│
├── 第3阶段：生态体系建设（4-8个月）
│ ├── 3.1 金融服务（支付、结算）
│ ├── 3.2 培训与成长系统
│ ├── 3.3 信用评价体系
│ ├── 3.4 三级政务管理平台
│ ├── 3.5 移动端（APP / 小程序）
│ └── 3.6 微服务拆分（按需拆分为独立服务）
│
└── 第4阶段：深化运营（8-12个月）
├── 4.1 开放平台 + API 市场
├── 4.2 知识产权 / 法律服务
├── 4.3 数据统计分析平台（大屏）
├── 4.4 K8s 部署 + 灰度发布
├── 4.5 Istio 服务网格（可选）
└── 4.6 等保三级认证
---
Phase 4: 架构 Prompt（已收敛）
现在我来生成一份可直接用于编码的 架构 Prompt：
<details>
<summary>📋 点击展开完整架构 Prompt</summary>
## 1. 项目背景
构建云南省 OPC 超级个体综合服务平台（云超服），面向云南个体创业者、自由职业者、小微经营者的省级一站式数字化服务平台。目前为零代码状态，需从零开始搭建。
## 2. 目标用户
个体创业者、小微企业主、自由职业者、孵化器/创业载体、甲方企业、服务商、省市县三级政府、平台运营方。
## 3. 核心需求（MVP 阶段）
1. 用户注册/登录/认证与 RBAC 权限体系（六种角色）
2. OPC 超级个体入驻与档案管理
3. 任务系统（发布任务、任务广场、智能匹配、接单交付、评价保障）
4. AI 智能体助手（对话交互 + 业务工具调用）
5. 初创载体管理与服务
## 4. 架构设定
- 产品形态：PC Web（Vue3）+ 移动端 H5/APP/小程序（UniApp）
- 架构模式：Go 模块化单体 → 渐进式微服务
- 运行环境：Docker Compose（开发）→ 阿里云 ECS（生产）
- 部署方案：第一阶段 Docker Compose，后续演进到 K8s
## 5. 技术约束
- 后端：Go 1.22+ + Gin Web框架 + GORM
- 数据库：MySQL 8.0（主）+ Redis 7（缓存）
- 前端：Vue 3 + TypeScript + Vite + Element Plus
- 移动端：UniApp（后续阶段）
- API 风格：RESTful JSON + 逐步引入 gRPC
- 认证：JWT + Casbin RBAC
- AI：LLM API（通义千问/DeepSeek）+ 基础 RAG
- 工具库：Zap（日志）、Viper（配置）、Prometheus（监控）
## 6. 非功能需求
- 高性能：API 平均响应 < 200ms
- 可扩展：模块化设计，随时可拆分为独立微服务
- 安全性：HTTPS、JWT 鉴权、RBAC 权限、数据加密
- 可维护性：清晰目录结构、统一错误码、规范日志
- 可用性：核心功能 99.9%，支持水平扩展
## 7. 实施计划
共 4 个阶段：
- 第0阶段：基础设施搭建（项目初始化、Docker 环境、基础库）
- 第1阶段：核心 MVP（用户中心、入驻、任务、智能体、前端框架）
- 第2阶段：服务深化（财税、工商、政策、服务商生态、消息通知）
- 第3阶段：生态体系（金融、培训、信用、政务平台、移动端、微服务拆分）
## 8. 输出要求
- 可运行的代码（不是伪代码）
- 每一步附带简要说明（为什么这样设计）
- 关键接口提供 curl 示例
- 数据库提供迁移脚本
- 提供 Docker Compose 配置，一键启动
## 9. 验收标准
- 功能正常：核心 API 通过 Postman/curl 测试
- 界面正常：前端页面可交互、路由正常
- 数据持久化：MySQL 数据可持久存储和查询
- 代码清晰：目录结构规范、命名一致、充分注释
- 可运行：`docker compose up` 一键启动
## 10. 限制条件（非常重要）
- 不过度设计：不提前引入 K8s、gRPC、Kafka 等（第一阶段）
- 不用不了解的技术栈：只使用 Go + Vue3 主流生态
- 不引入不必要依赖：每个依赖必须有明确理由
- 不一次生成全部代码：按模块拆分，每次只做一个功能
- 不跳过测试：每个模块完成后至少运行一次确认
- 不破坏架构：每次新增代码必须符合模块化单体架构
</details>
---
Phase 5: 行动计划
接下来，如果你确认上述架构方案，我们可以 从第 0 阶段开始 一步步实现：
第0阶段第一步 → 初始化项目结构：
cloud-opc/
├── server/ # Go 后端（单体模块化）
│ ├── cmd/ # 入口
│ ├── internal/ # 内部逻辑
│ │ ├── user/ # 用户模块
│ │ ├── task/ # 任务模块
│ │ └── ...
│ ├── pkg/ # 公共包
│ ├── migrations/ # 数据库迁移
│ └── config/ # 配置文件
├── web/ # Vue3 前端
│ └── src/
├── deploy/ # Docker Compose 配置
└── docs/ # 文档
---
请你确认：
1. 上述 6个需求问题 的答案是否准确？
2. 方案 B（Go 模块化单体 → 渐进式微服务） 是否接受？
3. 是否要 现在就开始第 0 阶段 的编码实现？
docs/身份体系与端口权限设计方案.md
+194
View File
@@ -0,0 +1,194 @@
# 云超服·身份体系与端口权限设计方案
> 依据《云南省OPC超级个体综合服务平台（云超服）系统设计方案》编写。
> 本方案定义**丰富的身份体系**、**六大端口的管理能力**、**权限与数据范围模型**，作为后续编码与功能完善的设计蓝本。
---
## 一、总体设计原则
1. **账号 ↔ 端口多身份**：一个账号可绑定多个端口身份；身份即权限来源，不再由账号编码决定角色。
2. **RBAC + 数据范围**：权限按「角色-权限」矩阵下发；政务端叠加「省/市/区县」三级数据范围。
3. **一账号多身份，登录选择，头像可切换**：登录返回全部身份；多身份弹选择器；运行中经头像菜单直接切换。
4. **端口数据互通、权限隔离**：运营端最高权限；政务端按层级看数据；业务端口管自身业务。
5. **演示数据一律由服务端提供**：前端不落地任何演示数据。
---
## 二、六大端口身份体系
每个端口定义 `port`（端口）+ `role`（端口角色码）+ `sub_role`（端口内细分角色）+ `org/region`（归属与数据范围）。
### 2.1 平台运营端 `operator`（总控中心，最高权限）
| sub_role | 名称 | 核心权限 |
|---|---|---|
| `op_super_admin` | 超级管理员 | 全平台一切管理、用户/角色/权限、审计 |
| `op_admin` | 运营管理员 | 用户管理、任务/服务商/内容审核、运营 |
| `op_customer_service` | 客服管理员 | 工单、争议调解、用户咨询 |
| `op_finance` | 财务管理员 | 结算、资金托管、佣金对账 |
| `op_analyst` | 数据分析师 | 全平台数据看板、报表、导出 |
| `op_techops` | 技术运维 | 系统配置、字典、运维 |
管理功能：用户管理、角色权限、任务管理（审核/上下架）、服务商准入与评级、内容管理、政策发布、数据大屏、系统配置、审计日志、资金/结算。
### 2.2 政务端 `government`（三级联动 + 组织角色）
**数据范围**：上级看下级，下级只看本级及以下（省→市→区县）。
| sub_role | 名称 | 数据范围 | 核心功能 |
|---|---|---|---|
| `gov_province` | 省级政务 | 全省 | 全省数据总览、省级政策、市/载体/服务商管理、补贴、分析报告 |
| `gov_city` | 市级政务 | 本市 | 本市数据看板、区县管理、市级政策、载体监管、补贴 |
| `gov_district` | 区县级政务 | 本区县 | 区县数据、载体/OPC 入驻审核、区县政策、补贴初审 |
| `gov_org_admin` | 组织机构管理员 | 按机构 | 本机构内账号与数据管理 |
| `gov_op_account` | 操作账号 | 按分配 | 仅操作、无管理 |
共性功能：**数据看板（按范围）**、**载体管理**（查看范围内载体及其中 OPC）、**OPC 管理**（范围内入驻审核/信息）、**政策发布**（起草→审核→发布→推送→效果追踪）、**补贴管理**、**收入/交易数据**（范围内订单金额、任务成交额）、**审计**。
### 2.3 企业端 `enterprise`（需求方：挑人才、发任务）
| sub_role | 名称 | 说明 |
|---|---|---|
| `enterprise` | 企业账号 | 基础身份 |
| `admin` | 企业管理员 | 企业档案、发布任务、资金托管、结算 |
| `operator` | 企业操作者 | 查看、人才挑选、项目协作 |
管理功能：**企业介绍/档案**、**人才搜索**（按技能/信用/地域）、**任务发布（发标）**、**我的任务/项目管理**（接单、进度、验收、评价）、**资金托管**、**合同与保障**。详见第五章「任务发标标准」。
### 2.4 服务商端 `provider`（为入驻 OPC 提供各类专业服务）
| sub_role | 名称 | 说明 |
|---|---|---|
| `provider` | 服务商账号 | 基础身份 |
| `admin` | 服务商管理员 | 服务商品、订单、结算、团队 |
| `operator` | 服务商操作者 | 服务交付、客户沟通 |
服务商等级：`certified` 认证 → `premium` 优质 → `gold` 金牌 → `official` 官方。
管理功能：**服务商品管理**（标准化/定制/订阅/按次/免费）、**订单交付**、**为入驻 OPC 提供服务**（财税/工商/法务/知识产权/云服务等）、**客户运营**、**评级与结算**、**评价**。
### 2.5 载体/园区端 `carrier`（管理载体内的 OPC）
| sub_role | 名称 | 说明 |
|---|---|---|
| `carrier` | 园区账号 | 基础身份 |
| `admin` | 园区管理员 | 入驻 OPC 管理、工位/空间、服务对接 |
| `operator` | 园区操作者 | 日常运营、数据查看 |
管理功能：**入驻 OPC 管理**（审核/绑定/工位分配）、**空间/工位管理**、**园区数据**（入驻率、订单）、**服务对接**（引荐服务商给园区内 OPC）、**载体政策申报**。
### 2.6 OPC 端 `opc_member`（平台核心服务对象）
| sub_role | 名称 | 说明 |
|---|---|---|
| `certified` | 认证 OPC | 已完成实名/工商/技能认证 |
| `independent` | 独立 OPC | 未绑定载体的自由个体 |
核心功能：**认证**（实名/工商/技能）、**绑定载体**（所属园区）、**任务**（广场/接单/竞标/交付）、**服务市场**（购买服务商商品）、**政策匹配**、**财税/工商**、**金融/信用**、**智能体助手**。
---
## 三、权限模型
### 3.1 权限码体系
- `menu:*`：菜单/功能入口权限（如 `menu:gov_data`、`menu:admin_user_mgmt`）。
- `action:*`：操作权限（如 `action:task.audit`、`action:policy.publish`、`action:fund.release`）。
- **数据范围**（`scope_region_ids`）：政务端由 region 推导「本级+后代」，企业/载体/服务商按 org 归属。
### 3.2 角色-权限矩阵（示例）
`role|sub_role` 两级合并取权限：
```
enterprise|admin -> menu:enterprise_dashboard, action:task.publish, action:fund.deposit, action:org.manage
enterprise|operator -> menu:enterprise_dashboard, action:task.view
government|gov_district -> menu:government_dashboard, menu:gov_data, action:carrier.audit, action:opc.audit, action:policy.publish
provider|admin -> menu:provider_dashboard, action:service.manage, action:order.deliver
carrier|admin -> menu:carrier_dashboard, action:opc.bind, action:space.manage
opc_member|certified-> menu:opc_dashboard, action:task.bid, action:task.deliver, action:service.buy
```
### 3.3 政务数据范围（三级）
- 省级 → 全省 region（省+市+区县后代）。
- 市级 → 本市 + 所辖区县。
- 区县级 → 本区县。
- 越权访问一律 403；写操作写审计。
---
## 四、各端管理功能矩阵
| 功能 | 运营 | 政务(按范围) | 企业 | 服务商 | 载体 | OPC |
|---|---|---|---|---|---|---|
| 用户/账号管理 | ✅ | 本机构 | — | — | — | 本人 |
| 任务发布(发标) | 审核 | 监管 | ✅ | — | — | — |
| 任务接单/交付 | — | 监管 | 验收 | — | — | ✅ |
| 服务商品/交付 | 评级 | 监管 | — | ✅ | 引荐 | 购买 |
| 载体/入驻OPC | 监管 | ✅ | — | — | ✅管理 | 绑定 |
| 政策发布 | ✅ | ✅ | 查看 | 查看 | 查看 | 匹配 |
| 财税/结算 | ✅ | 收入数据 | 托管 | ✅ | — | 查看 |
| 数据看板 | ✅全平台 | ✅按范围 | — | 自身 | 自身 | 自身 |
| 系统配置/审计 | ✅ | 本级 | — | — | — | — |
---
## 五、企业端任务发标标准（详细逻辑与操作）
### 5.1 发标状态机
```
draft 草稿 → pending 待审核 → published 已发布
→(接单模式)
grab 抢单: OPC 抢单直接锁定
bid 竞标: 多 OPC 提交方案 → 企业选标 → 中标锁定
designated 指定: 企业指定 OPC
dispatch 派单: 平台派单
→ in_progress 进行中 → delivered 已交付 → review 验收
├─ 通过 → completed 已完成(资金结算/双方评价)
├─ 驳回 → in_progress(要求修改)
└─ 争议 → 平台介入仲裁
→ cancelled 取消(任一方违约/超时)
```
### 5.2 发标操作流（企业端页面）
1. **选分类**：一级/二级分类（设计创意/技术开发/文案写作/营销推广/咨询服务/…）。
2. **填详情**：标题、描述、需求文档、附件。
3. **设参数**：预算范围、交付周期、难度、所需技能标签。
4. **选交付方式**：线上/线下/混合。
5. **设接单模式**：抢单/竞标/指定/派单。
6. **资金托管**：任务预算托管到平台（校验托管金 ≥ 预算下限）。
7. **提交审核**：平台审核合规性 → 通过后进入任务广场并推送匹配 OPC。
### 5.3 发标规则与校验
- **预算校验**：`budget_min ≤ budget_max`，且为正；托管金 ≥ 预算下限。
- **期限校验**：deadline 晚于当前时间。
- **合规校验**：禁止违禁/敏感内容；平台审核队列。
- **竞标模式**：至少 1 份有效标书才可评标；评标后未中标自动释放保证金。
- **违约处理**：超时未交付/恶意抢单 → 信用扣分、保证金扣除。
### 5.4 验收与结算
- OPC 提交交付物 → 企业验收（通过/驳回/要求修改，最多 N 次）。
- 通过 → 托管金划付 OPC（按比例扣除平台佣金）→ 双方评价 → 信用更新。
- 争议 → 平台仲裁记录。
---
## 六、服务商服务入驻 OPC 流程
1. OPC 在服务市场浏览/搜索服务商品。
2. 查看详情、评价、案例；可咨询。
3. 下单 → 支付（资金托管）。
4. 服务商接单开始服务（绑定该 OPC 为「服务对象」）。
5. 交付/确认 → 评价 → 服务商等级与信用更新。
6. 载体端可「引荐」服务商给园区内 OPC，形成三方服务关系。
---
## 七、与现有代码的落点
| 设计项 | 现状 | 下一步 |
|---|---|---|
| 账号↔多身份 | ✅ `user_identities`，登录选择/头像切换已实现 | 补充更多角色 seed（各端口 admin/operator） |
| 六端口菜单/页面 | ✅ 全部页面有真实数据 | 深化各端 CRUD/审核流 |
| 权限矩阵 | ✅ role_permissions 已 seed | 扩充 `action:*` 权限码并按页面接入 |
| 政务数据范围 | ✅ scope_region_ids 按 region | 数据看板/载体/OPC/收入按范围过滤 |
| 企业发标 | 🟡 有基础 tasks 表 + 发布接口 | 落地 5.1 状态机 + 竞标/托管/验收 |
| 服务商服务 OPC | 🟡 有 provider/order 数据 | 落地「服务对象绑定 + 交付结算」 |
| 载体管理 OPC | 🟡 有 carrier/opc 数据 | 落地入驻审核/工位/绑定 |
---
## 八、待确认事项
1. **发标状态机**粒度：是否本期实现完整竞标+资金托管，还是先做「发布→广场→接单(抢单)→验收」最小闭环？
2. **政务收入数据**：范围过滤口径（按载体/任务/服务商归属 region）？
3. **载体-服务商引荐**：是否需要「三方绑定」实体表？