PC与WAP个人端/公司后台全景功能关系

PC与WAP个人端/公司后台全景功能关系分析

1. 分析范围与目标

本文覆盖以下端口与模块，并重点分析其前后台关系、权限链路、可展示版块及数据依赖：

PC个人端：Home + Members
PC公司后台：Merchant
WAP个人端：Wap + User
WAP公司后台：Distributors + Worker
专项页面：worker/index/index.html（员工端首页可展示能力与关联关系）

目标是明确：

各端口“谁负责展示，谁负责维护数据”
菜单/版块在前台与后台的对应关系
登录鉴权与角色权限链路
公司、员工、项目等关键实体之间的关系

2. 系统模块边界（代码目录视角）

核心模块按分组组织在 Banyan/Lib/Action：

Backstage：平台总后台（管理员）
Merchant：PC公司后台
Distributors：WAP公司后台（公司管理侧）
Worker：WAP员工后台（员工操作侧）
Wap：WAP前台（移动个人端/访客端）
User：WAP个人中心
Home：PC前台门户
Members：PC个人中心

模板按模块映射到 themes/default/<Module>/（Backstage除外，使用其独立后台模板目录）。

3. 四类端口总览（业务视角）

3.1 PC个人端（Home + Members）

定位：门户展示与个人服务入口。

特点：偏“内容消费”和“流量承接”。

主要版块：

首页聚合（资讯、招采、公司、招聘等）
公司详情、员工展示、新闻列表
个人中心（账户、消息、发布、收藏等）

与后台关系：

展示数据主要来自公司后台维护（Merchant）
个人账户行为由 Members 处理

3.2 PC公司后台（Merchant）

定位：公司侧主运营后台。

特点：权限体系最完整，承担数据生产与治理。

主要版块：

公司基础信息
员工管理、部门管理、角色授权（组织权限）
法律项目管理
招采管理、资讯管理、企业信息采集
资金、营销、评价等运营模块

与前台关系：

Home/Wap 看到的公司资料、员工、资讯、招采内容，主要由此维护

3.3 WAP个人端（Wap + User）

定位：移动端访客浏览 + 个人中心。

特点：页面轻量，注重快捷跳转。

主要版块：

WAP首页及底部导航（首页/发布/菜单/服务/我的）
公司详情、资讯、招采等移动展示页
User 个人中心（资产、消息、入口聚合）

与后台关系：

User/member 中可跳转到公司后台与员工后台
前台展示内容来自公司后台维护结果

3.4 WAP公司后台（Distributors + Worker）

定位：

Distributors：公司管理员在移动端的管理后台
Worker：员工在移动端的业务执行后台

主要版块（Distributors）：

公司设置、项目管理、招采、员工管理、企业信息采集等

主要版块（Worker）：

项目管理、资讯、招聘、点评、相册、通知、名片等（按员工权限位显示）

4. 登录与权限链路

4.1 统一用户登录态

基础登录态通过 BYCMS_TOKEN（Cookie）承载
setUid/getUid/clearUid 负责写入/读取

4.2 公司后台准入（Merchant/Distributors）

必须有有效登录 uid
必须能解析到当前公司 shop_id（店主或协作授权）
Merchant 端存在组织权限链：

- org_user_role -> org_role_permission -> org_permission

- 店主通常具备全权限放行

4.3 员工后台准入（Worker）

必须登录
必须在 shop_worker 中存在可见有效员工身份（如 closed=0、status=1，且公司有效）
多员工身份通过会话切换当前 worker_active_worker_id

4.4 菜单级与接口级双重控制

首页菜单显隐：前端按员工权限位（is_project 等）控制
控制器动作权限：后端继续校验（避免仅靠前端显隐导致越权）

5. 关键数据模型与关系

核心实体关系（简化）：

users：用户主账号
shop：公司主体（店主绑定 shop.user_id）
shop_worker：用户在某公司下的员工档案
project：项目主体
project_worker：项目与员工关联表（员工是否“参与项目”的判断来源）

关系主线：

用户登录（users）
进入公司上下文（shop）
员工身份确认（shop_worker）
项目参与关系（project_worker）

结论：员工端项目列表依赖 project_worker，而非仅依赖 project。

6. 前台展示与后台维护的映射关系

可按“展示层 <- 生产层”理解：

Home/Wap 公司详情、资讯、员工、招采展示

<- Merchant/Distributors/Worker 维护

User/Members 个人中心入口与身份切换

<- 登录态 + 员工/公司授权关系

Worker 员工业务执行页（项目、日志、租户等）

<- 项目分配关系 + 员工权限位

7. `worker/index/index.html` 专项分析

7.1 页面定位

文件：themes/default/Worker/index/index.html
作用：员工端首页（移动端工作台）
控制器：Worker/IndexAction::index()

7.2 页面展示块（对外可见能力）

首页主要显示：

员工身份卡片（姓名、公司、职务、联系方式）
功能入口宫格（项目管理、资讯、招聘、点评、相册、通知、公司管理、分公司管理、招采、企业采集、员工管理、我的名片）
微信场景功能（扫码等）
底部导航（首页/管理/帮助/通知/我的）

7.3 数据来源

Worker/CommonAction 统一注入：worker、SHOP、消息计数、微信变量等
Worker/IndexAction 注入首页统计项（各业务计数）
权限位来自 shop_worker 字段（is_xxx）

7.4 权限与安全

前端按 worker.is_xxx 控制菜单显隐
后端 Action 二次校验（关键模块直接拒绝无权访问）
项目明细页必须校验当前员工是否在 project_worker 内

7.5 跨模块跳转关系

到员工项目后台：worker/project/index
到公司移动后台模块：distributors/*（公司管理类）
到个人中心：user/member/index

结论：worker/index/index.html 是“员工工作台路由中枢”，把员工身份、公司管理入口、个人中心入口聚合到一页。

8. 端到端关系图（文字版）

用户从 Home/Wap 浏览内容
内容由 Merchant/Distributors/Worker 在后台维护
用户在 User/Members 完成个人操作与身份切换
公司用户进入 Merchant/Distributors 管理公司
员工进入 Worker 执行业务
若涉及项目，最终以 project_worker 判定员工是否参与

9. 关键一致性结论

展示与维护分离明显：前台以展示为主，后台以生产为主。
公司后台与员工后台并存：同一业务在 PC/WAP 存在双入口。
权限模型分层：账号登录、公司上下文、员工身份、角色权限、项目参与关系共同决定可见与可操作范围。
Worker 项目访问是否可见，不取决于“是否创建项目”，而取决于 project_worker 是否建立关联。

10. 优化建议（架构治理）

建立统一“端口-模块-权限-数据表”字典，降低跨模块维护成本。
对跨端同名功能（如项目管理）统一口径文档，避免“页面有入口但权限不足”的体验割裂。
将 shop_worker 权限位与 RBAC 逐步收敛为统一授权模型。
为关键链路增加自动化巡检：

- 创建项目后是否自动写入 project_worker

- 员工身份切换后是否正确刷新可见菜单与项目列表

11. 角色可见菜单矩阵（建议基线）

说明：以下为“默认常见权限模型”矩阵，实际以公司配置、员工权限位与 RBAC 配置为准。

角色	主要访问端	可见核心菜单/页面	典型限制
游客（未登录）	`Home` / `Wap`	公司展示、资讯、部分公开列表	不可进入 `User`、`Merchant`、`Distributors`、`Worker`
个人会员（已登录）	`Members` / `User`	我的账户、消息、收藏、发布、入口聚合	不自动拥有公司管理权限
公司店主/公司管理员	`Merchant`（PC）/ `Distributors`（WAP）	公司信息、员工管理、项目管理、招采、资讯、组织权限	受公司上下文和权限点约束
公司员工（普通）	`Worker`	员工首页、被授权功能入口、参与项目操作	仅可访问本人被授权模块与参与项目
项目员工（已关联）	`Worker/project/*`	项目详情、项目日志、租户相关业务	必须存在 `project_worker` 关联
平台管理员	`Backstage`	全站配置、审核、平台级管理	不参与普通员工端流程

11.1 员工端权限位与菜单映射（`shop_worker.is_xxx`）

权限位	对应常见菜单	说明
`is_project`	项目管理	仅显示入口；后端仍校验项目参与关系
`is_news`	资讯管理	无权限时控制器可直接拒绝
`is_job`	招聘管理	对应招聘发布/管理能力
`is_coupon`	活动/核销相关	结合业务模块使用
`is_photo`	相册管理	图片资料维护
`is_dianping`	点评管理	评价相关处理
`is_shop`	公司管理	公司信息类入口
`is_branch`	分公司管理	分支机构管理入口
`is_tender`	招采管理	招标采购业务入口
`is_companycollect`	企业信息采集	采集模块入口
`is_worker`	员工管理	员工资料/名片等相关入口

12. 关键流程关系（从请求到数据）

12.1 员工进入项目列表流程

员工登录并通过 Worker/CommonAction 身份校验
读取当前员工 worker_id（会话可切换）
在 project_worker 查询该 worker_id 关联的项目
再按 project.closed=0 获取项目详情并展示

结论：只创建 project 不够，必须有 project_worker 关系，员工端才能看到项目。

12.2 公司后台创建项目到员工可见流程

公司后台创建项目写入 project
系统尝试将创建者绑定到 project_worker（需匹配有效 shop_worker）
员工端按 project_worker 读取项目列表
若第 2 步失败，会出现“项目已创建但员工端未参与”

12.3 前台展示内容生产流程

公司在 Merchant/Distributors/Worker 维护内容
前台 Home/Wap 聚合并展示
用户通过 Members/User 完成个人交互和身份切换
多端共享同一业务数据，但入口和权限策略不同

13. 常见问题排查清单（可直接执行）

13.1 员工端“未参与任何项目”

检查 shop_worker 是否有效（status=1、closed=0）
检查当前会话是否切到了正确 worker_id
检查 project_worker 是否有该 worker_id 与目标 project_id 的记录
检查 project.closed 是否为 0

13.2 菜单看得到但点进去报无权限

前端显隐通过不代表后端校验通过
核查员工权限位（is_xxx）和后端动作权限是否一致
核查公司上下文 shop_id 是否切对（尤其多公司账号）

13.3 PC正常、WAP不正常（或反之）

核查访问的是哪个模块（Merchant vs Distributors vs Worker）
核查对应模块 CommonAction 的登录与上下文逻辑
核查同一功能在双端是否走了不同控制器与权限分支

14. SQL排查模板附录（实施/运维可直接复用）

使用说明：

将 SQL 中的占位符替换为真实值：

- :UID 用户 user_id

- :SHOP_ID 公司 shop_id

- :WORKER_ID 员工 worker_id

- :PROJECT_ID 项目 project_id

在 MySQL 控制台仅粘贴 SQL 语句本体，不要带 mysql> 前缀。
若表前缀不是 by_，请按实际前缀替换。

14.1 账号与公司上下文核对

-- 1) 用户基本信息
SELECT user_id, nickname, mobile, closed
FROM by_users
WHERE user_id = :UID;

-- 2) 用户可访问公司（店主）
SELECT shop_id, user_id, shop_name, audit, closed
FROM by_shop
WHERE user_id = :UID
ORDER BY shop_id DESC;

-- 3) 用户在组织授权中的公司（协作权限）
SELECT id, user_id, shop_id, role_id, create_time
FROM by_org_user_role
WHERE user_id = :UID
ORDER BY id DESC;

判读重点：

无法进入公司后台时，先看是否有店主公司或组织授权公司。
公司 closed、audit 状态异常会导致上下文解析失败或前台不可见。

14.2 员工身份（shop_worker）核对

-- 1) 某用户在所有公司的员工档案
SELECT worker_id, user_id, shop_id, name, mobile, status, closed
FROM by_shop_worker
WHERE user_id = :UID
ORDER BY worker_id DESC;

-- 2) 某员工档案详情
SELECT worker_id, user_id, shop_id, name, mobile, status, closed
FROM by_shop_worker
WHERE worker_id = :WORKER_ID;

-- 3) 某公司全部有效员工
SELECT worker_id, user_id, shop_id, name, status, closed
FROM by_shop_worker
WHERE shop_id = :SHOP_ID AND status = 1 AND closed = 0
ORDER BY worker_id DESC;

判读重点：

员工端能否进入首先取决于 shop_worker 是否有效（status=1、closed=0）。
同一 UID 可能存在多条 shop_worker，需要结合当前会话确认正在使用哪条身份。

14.3 项目可见性（project + project_worker）核对

-- 1) 最近创建项目（确认真实 project_id）
SELECT project_id, shop_id, project_name, project_status, closed, create_time
FROM by_project
ORDER BY project_id DESC
LIMIT 20;

-- 2) 指定项目详情
SELECT project_id, shop_id, project_name, project_status, closed, create_time
FROM by_project
WHERE project_id = :PROJECT_ID;

-- 3) 指定项目下的项目员工关系
SELECT id, project_id, worker_id, role, create_time
FROM by_project_worker
WHERE project_id = :PROJECT_ID
ORDER BY id DESC;

-- 4) 指定员工参与的全部项目
SELECT id, project_id, worker_id, role, create_time
FROM by_project_worker
WHERE worker_id = :WORKER_ID
ORDER BY id DESC;

判读重点：

“项目已创建但员工端显示未参与”，通常是第 3 条为空。
WORKER_ID 与 PROJECT_ID 不同维度，排查时不要混用。

14.4 项目人数统计核对（去重口径）

-- 1) 原始关系条数
SELECT COUNT(*) AS raw_count
FROM by_project_worker
WHERE project_id = :PROJECT_ID;

-- 2) 去重后员工数（建议展示口径）
SELECT COUNT(DISTINCT worker_id) AS distinct_worker_count
FROM by_project_worker
WHERE project_id = :PROJECT_ID;

-- 3) 查看是否存在重复 worker_id 关联
SELECT worker_id, COUNT(*) AS cnt
FROM by_project_worker
WHERE project_id = :PROJECT_ID
GROUP BY worker_id
HAVING COUNT(*) > 1;

判读重点：

raw_count 大于 distinct_worker_count 说明存在重复关联。
页面展示建议使用去重口径，避免“员工显示偏大”。

14.5 组织权限（RBAC）核对

-- 1) 用户在公司下拥有哪些角色
SELECT id, shop_id, user_id, role_id, worker_id
FROM by_org_user_role
WHERE user_id = :UID AND shop_id = :SHOP_ID
ORDER BY id DESC;

-- 2) 角色包含哪些权限点
SELECT rp.role_id, rp.permission_id, p.permission_code, p.permission_name
FROM by_org_role_permission rp
JOIN by_org_permission p ON p.permission_id = rp.permission_id
WHERE rp.role_id IN (
    SELECT role_id
    FROM by_org_user_role
    WHERE user_id = :UID AND shop_id = :SHOP_ID
)
ORDER BY rp.role_id, p.permission_code;

判读重点：

菜单不显示或接口拒绝时，先核对是否存在对应 permission_code。
店主账号通常有默认放行策略，但协作账号严格依赖 RBAC。

14.6 一键诊断模板（项目不可见问题）

-- A. 看项目是否存在且未关闭
SELECT project_id, shop_id, project_name, closed
FROM by_project
WHERE project_id = :PROJECT_ID;

-- B. 看该员工是否为有效员工身份
SELECT worker_id, user_id, shop_id, status, closed
FROM by_shop_worker
WHERE worker_id = :WORKER_ID;

-- C. 看该员工是否已绑定到该项目
SELECT id, project_id, worker_id, role
FROM by_project_worker
WHERE project_id = :PROJECT_ID AND worker_id = :WORKER_ID;

结果解释：

A 无记录或 closed=1：项目本身不可见。
B 无记录或状态无效：员工身份不可用。
C 无记录：需要补 project_worker 关联，员工端才会出现项目。

15. 标准处理SOP（问题受理到闭环）

本章用于实施、运维、研发协同排障，适用于以下高频问题：

员工端提示“未参与任何项目”
菜单显示异常（能看见但点不开，或应该显示却不显示）
PC 与 WAP 同一功能行为不一致

15.1 受理与信息采集（T+0）

收到问题后先收集最小必要信息：

用户标识：UID、WORKER_ID（如有）
公司标识：SHOP_ID（当前操作公司）
项目标识：PROJECT_ID（若涉及项目）
端口与路径：

- PC/WAP

- 模块路径（如 worker/project/index）

复现时间点与操作步骤（谁在何时点了什么）

输出物：一条可复现的问题单（含 5W1H）。

15.2 快速定位分流（T+0 ~ T+0.5h）

按问题类型分流：

登录/跳转问题 -> 优先看 CommonAction 准入逻辑
菜单显隐问题 -> 优先看 shop_worker.is_xxx
页面报“无权限” -> 优先看后端动作权限校验（RBAC/模块校验）
项目不可见问题 -> 优先看 project_worker 关系

输出物：归类标签（登录态 / 身份态 / 权限态 / 数据关系态）。

15.3 SQL核查（T+0.5h）

按第14章模板执行，并保存结果快照（建议复制到工单）：

账号与公司上下文
员工身份有效性
项目与项目员工关系
角色权限点

判定准则：

上下文不一致：shop_id 错位问题
身份无效：shop_worker 状态问题
关系缺失：project_worker 缺行
权限缺失：RBAC 未授权或权限码不匹配

15.4 修复策略（T+1h）

优先级：先恢复业务可用，再做根因治理。

可用性修复（短期）：

补齐缺失的 project_worker 关系
修正错误会话上下文（切换正确公司/员工身份）
临时补授权（角色-权限绑定）

根因修复（中长期）：

修补创建链路中的自动绑定逻辑
统一前端显隐和后端鉴权口径
建立上线前巡检（创建项目后自动校验关系写入）

15.5 回归验证（T+1h ~ T+2h）

至少覆盖以下回归点：

同账号在 PC 与 WAP 行为一致性
员工切换身份后菜单刷新正确
创建项目后员工端可见项目
详情页、列表页人数统计口径一致（去重）

回归通过标准：

用户侧复现路径全部恢复
同链路无新增报错
SQL 核查结果与页面表现一致

15.6 闭环与沉淀（T+2h）

结单前输出：

根因分类（配置/数据/代码）
修复动作（SQL/代码/配置）
风险评估（是否影响其他公司/员工）
预防措施（巡检项、告警项、发布检查项）

16. 上线前后检查清单（发布保障）

16.1 上线前检查（Pre-Deploy）

[ ] 关键链路冒烟：登录 -> 公司后台 -> 员工后台 -> 项目列表
[ ] 创建项目后自动写 project_worker 校验通过
[ ] 员工权限位控制与后端鉴权规则一致
[ ] 角色权限点变更已同步到对应账号
[ ] 统计口径（员工数）采用去重口径
[ ] SQL 脚本准备好回滚方案与执行记录模板

16.2 上线后检查（Post-Deploy）

[ ] 选 1 个店主账号 + 1 个协作账号做全链路验证
[ ] 选 1 个普通员工 + 1 个项目员工验证菜单和项目可见性
[ ] 核查新建项目的 project_worker 自动写入情况
[ ] 抽查 PC 与 WAP 相同功能的结果一致性
[ ] 抽查最近 10 条问题高发链路日志/数据是否异常

16.3 回滚触发条件（建议）

满足任一条件建议立即回滚或热修：

核心登录链路中断（大量用户无法进入对应后台）
大面积员工项目不可见（关系写入失效）
权限误放行或误拒绝导致业务中断
发布后错误率持续升高且无法在短时间内止血

17. 术语与字段字典（面向实施/业务）

17.1 常用术语

术语	说明	常见误区
用户（User）	系统登录账号，主键一般为 `user_id`	不是员工档案本身
公司（Shop）	企业主体，主键 `shop_id`	一个用户可关联多公司（店主或协作）
公司员工（Shop Worker）	用户在某公司下的员工档案，主键 `worker_id`	`worker_id` 不等于 `user_id`
项目（Project）	业务项目，主键 `project_id`	创建项目不等于自动成为项目员工（依赖关联写入）
项目员工关系（Project Worker）	员工参与项目的关系表	员工端项目可见性以此为准
RBAC	角色权限模型（用户/员工 -> 角色 -> 权限点）	菜单可见不代表接口必然可访问

17.2 关键 ID 字段对照

字段	含义	来源表	用途
`user_id`	登录账号ID	`users`	认证、账号识别、公司/员工归属
`shop_id`	公司ID	`shop`	公司上下文、数据隔离
`worker_id`	员工档案ID	`shop_worker`	员工权限与员工端身份
`project_id`	项目ID	`project`	项目标识与项目数据索引
`role_id`	角色ID	`org_role`	RBAC授权
`permission_id`	权限点ID	`org_permission`	接口/菜单能力定义

17.3 状态字段常见含义

字段	常见取值	语义（常见约定）
`closed`	`0/1`	`0` 正常，`1` 关闭/删除（逻辑删除）
`status`	`0/1` 或业务枚举	`1` 常表示有效/通过，`0` 常表示禁用/待审
`project_status`	枚举值	项目业务状态（进行中/暂停/结束等）

说明：不同表 status 语义可能略有差异，最终以该模块代码判断为准。

17.4 员工端菜单权限位（`shop_worker.is_xxx`）速查

字段	大致含义	影响
`is_project`	项目管理权限位	决定项目菜单显隐，后端仍需项目关系校验
`is_news`	资讯权限位	决定资讯入口与操作
`is_job`	招聘权限位	决定招聘入口与操作
`is_coupon`	活动/核销权限位	决定活动相关入口
`is_photo`	相册权限位	决定相册入口
`is_dianping`	点评权限位	决定点评入口
`is_shop`	公司管理权限位	决定公司管理入口
`is_branch`	分公司管理权限位	决定分公司入口
`is_tender`	招采权限位	决定招采入口
`is_companycollect`	企业采集权限位	决定采集入口
`is_worker`	员工管理权限位	决定员工管理入口

17.5 三组最容易混淆的概念

user_id vs worker_id

- 一个是账号，一个是员工档案，不能混用。

worker_id vs project_id

- 一个是人，一个是项目；SQL 排查时最容易写错条件。

菜单显示 vs 接口可访问

- 前端显示仅是第一层；后端权限和关系校验是最终准入。

18. 快速问答（FAQ）

18.1 为什么“我创建了项目，员工端还是看不到”？

因为员工端按 project_worker 判断是否参与项目。仅有 project 记录不够，需存在 project_id + worker_id 关联。

18.2 为什么显示员工数是 2，但我只添加了 1 个？

可能原因：

同一项目下 project_worker 存在重复 worker_id 关联
列表用了非去重统计口径
历史冗余字段未覆盖更新

建议使用 COUNT(DISTINCT worker_id) 作为展示口径。

18.3 为什么菜单能看到，点击却提示无权限？

因为前端菜单显隐和后端动作鉴权是两层机制。前端可见不代表后端已授权。

18.4 为什么 PC 能操作，WAP 不行？

常见是走了不同模块（Merchant vs Distributors/Worker）且鉴权规则不同，需分别核查对应 CommonAction 与权限分支。

18.5 一个账号可以同时是店主和员工吗？

可以。账号可同时拥有公司主体身份（店主/协作）和员工档案身份，具体可见能力取决于当前上下文与权限配置。

19. 管理层一页纸摘要（非技术版）

19.1 结论先行

当前系统已形成“多端协同、后台生产、前台展示”的完整闭环：

PC 与 WAP 双前台承担展示与触达
公司后台与员工后台承担内容生产与业务执行
权限体系决定“谁能看、谁能做、在哪个端口做”

核心管理结论：

系统能力完整，但跨端入口较多，需统一业务口径与操作规范。
问题高发点集中在“身份上下文”和“项目员工关系”两条链路。
通过标准 SOP + 发布清单 + SQL 模板，可显著降低线上故障处置时间。

19.2 业务价值

提升组织协同效率

- 公司管理层、运营人员、员工在同一数据体系协作。

降低管理风险

- 角色权限可控，可追溯“谁有权限、谁做了操作”。

保障多端一致体验

- PC/WAP 同源数据，降低信息不一致和重复维护成本。

支持持续扩展

- 现有结构可继续承载项目管理、招采、资讯、员工管理等业务增长。

19.3 当前主要风险点

身份错位风险

- 多公司/多员工身份下，若上下文切错，容易出现“有账号但无权限”。

关系缺失风险

- 项目创建后若未写入项目员工关系，会出现“项目存在但员工不可见”。

口径不一致风险

- 前端菜单显隐、后端权限校验、统计口径若不一致，容易引发认知冲突。

跨端行为差异风险

- 相同业务在 PC 与 WAP 路径不同，排障成本偏高。

19.4 建议管理动作（30天内）

发布“统一权限口径”制度

- 明确菜单显示、接口鉴权、角色授权三层规则。

建立“问题闭环机制”

- 强制执行第15章 SOP，问题单必须包含 SQL 核查证据。

固化“上线前后清单”

- 将第16章纳入版本发布准入标准。

指定“跨端一致性负责人”

- 对 PC/WAP 同功能差异进行定期巡检并收敛。

19.5 关键考核指标（KPI建议）

项目不可见类问题月环比下降率
权限误拒绝/误放行问题数量
故障平均定位时长（MTTD）与恢复时长（MTTR）
发布后 72 小时内高优先级故障数
PC/WAP 同功能一致性通过率

19.6 一句话管理建议

将“身份上下文 + 权限规则 + 项目关系写入”作为三条红线治理，系统稳定性和团队执行效率会明显提升。

20. 会议汇报版精简提纲（10条）

系统已形成“前台展示 + 后台生产 + 权限控制”的完整闭环。
四类端口职责清晰：PC个人、PC公司后台、WAP个人、WAP公司后台。
公司后台（Merchant/Distributors）是内容和业务数据的主要生产端。
员工后台（Worker）是执行端，核心受员工身份与项目关系控制。
员工端项目可见性的唯一业务基线是 project_worker 关系。
高频问题不在单点功能，而在“身份上下文错位 + 权限口径不一致”。
菜单可见不代表有操作权限，后端鉴权才是最终准入。
已沉淀可执行 SOP、SQL 模板和发布清单，可直接落地。
建议 30 天内推进三件事：统一权限口径、强制问题闭环、固化发布准入。
管理目标是把故障从“经验排查”升级为“标准化治理”，持续降低 MTTR。

20.1 30秒结语（可直接口述）

我们现在不缺功能，缺的是跨端一致的治理标准。只要抓住“身份上下文、权限规则、项目关系写入”三条主线，系统稳定性、可维护性和组织执行效率都会同步提升。

帮助中心