ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync: add healthcare compliance notes

Browse Source
This commit is contained in:
weishen
2026-04-25 08:20:22 +08:00
parent 7d0e10b299
commit df840cc5b8
21 changed files with 831 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

264
Project/fonrey/TECH_STACK/TECH_STACK.md
View File

@@ -1,155 +1,153 @@
# Fonrey 技术栈总纲（TECH_STACK）
> **For AI assistants**: Read this entire file before writing any code. All decisions here are final. Do not suggest alternatives unless asked.
## 1. 项目概览 (Project Overview)
**Fonrey (房睿) 房产经纪管理系统** 是一款面向房地产经纪公司的 B2B SaaS 平台 。系统核心目标是解决房源、客源信息散乱、跟进缺失及重复录入等痛点，支持 89,000+ 数据量级下的高效匹配 。
- **房源管理**：支持住宅/别墅/商铺/商住/写字楼/其他 6 种房源类型（P0 住宅，P1 别墅，商业类低优先级）；核心功能含录入、跟进、图片管理、价格解读、市场报盘、附件、业主联系人；目标 89,000+ 条数据量级
- **客源管理**：管理购房/租房意向客户（私客为核心，公客/成交客后续版本）；功能含录入私客、智能配房、跟进记录、活跃度分层、转公客/转成交/转无效、联系人管理、操作日志
- **楼盘管理**：楼盘为房源基础数据底座；功能含楼盘列表、楼盘详情（楼盘信息/楼栋管理/结构管理/照片/价格走势/周边配套）、区域管理（城区/商圈/关联关系）、学校管理；聚焦二手房
- **系统设置**：平台"控制中心"；本期聚焦首页设置与房源设置（字段标签、必填规则、自定义字段、标签管理）；其余设置（客源/交易/财务/人事OA/合同/通用/移动端/安装登录）在各自模块 PRD 中说明
- 所有模块均为 Web 端，移动端适配为 v2 规划
- **目标用户**：一线经纪人（高频）、店长/经理（每日）、运营/行政人员（每日）、系统管理员（不定期）
- **核心用途**：房源/客源的全生命周期管理、楼盘基础数据维护及多租户业务规则定制 。 。
- **设计哲学**：优先保障数据一致性与极速的录入/筛选体验，UI 简洁高效 。
## 2. 核心技术栈 (Core Stack)
- **Frontend**: HTMX + Alpine.js + Tailwind CSS (无重前端框架，追求极致响应) 。
- **Backend**: Django 4.x (ASGI 模式，支持异步能力) 。
- **Multi-tenant**: `django-tenants` (Postgres Schema 隔离，确保租户数据物理安全) 。
- **Database**: PostgreSQL + PgBouncer (连接池优化) 。
- **Cache**: Redis 。
- **Tasks**: Celery + Celery Beat (用于异步导出、智能配房任务) 。
- **Storage**: Cloudflare R2 (或 AWS S3 compatible) 。
- **CDN**: Cloudflare 。
- **Server**: Gunicorn + Uvicorn workers + Nginx 。
- **Monitoring**: Sentry + Grafana 。
- **Deployment**: Docker Compose。
## 3. 关键约定 (Key Conventions)
- **UI 交互模式**：
- 采用 **HTMX** 进行局部 DOM 刷新（如分页、筛选、搜索联想）。
- 采用 **Alpine.js** 处理前端状态（如弹窗开关、复选框多选、字数统计）。
- **多租户隔离**：所有数据库查询必须基于当前租户 Schema，严禁跨租户访问数据。
- **文件命名**：Django App 采用小写下划线 `snake_case`，前端模版组件采用 `kebab-case`。
- **异步处理**：所有耗时任务（如 8.9 万条房源的 Excel 导出、图片转码、复杂的智能配房计算）必须通过 Celery 异步执行 。
- **错误处理**：后端 API 需返回标准 JSON 错误格式；前端 HTMX 请求失败需触发全局 Toast 提示。
## 4. 目录结构 (Django App Structure)
Plaintext
```
fonrey/
├── apps/
│ ├── tenants/ # django-tenants 配置
│ ├── org/ # 组织人事（org_units, staff）
│ ├── region/ # 区域管理（districts, business_areas, metro）
│ ├── complex/ # 楼盘管理（complexes, buildings, schools）
│ ├── property/ # 房源核心（properties + 所有子表）
│ │ ├── models/
│ │ │ ├── property.py # Property 主表
│ │ │ ├── contact.py # PropertyContact
│ │ │ ├── follow_log.py # FollowLog
│ │ │ ├── key.py # PropertyKey
│ │ │ ├── commission.py # Commission
│ │ │ ├── survey.py # FieldSurvey
│ │ │ ├── photo.py # PropertyPhoto
│ │ │ ├── attachment.py # PropertyAttachment
│ │ │ ├── marketing.py # PropertyMarketing
│ │ │ └── completeness.py # PropertyCompleteness
│ │ ├── services/
│ │ │ ├── completeness.py # 完成度计算服务
│ │ │ ├── duplicate.py # 重复房源检测
│ │ │ └── search.py # 搜索/筛选服务
│ │ └── tasks.py # Celery 异步任务
│ ├── client/ # 客源管理
│ ├── settings/ # 系统设置（lookup, tags）
│ └── permissions/ # 权限管理
├── shared/ # 公共 Schema App（django-tenants shared_apps）
└── core/
├── models/base.py # 抽象基类
├── encryption.py # 手机号加密
└── cache.py # Redis 缓存工具
```
## 5. 组件实现标准 (Component Standards)
根据[[组件清单]]
## 6. Do NOT Use
- **❌ Do NOT** 使用 React/Vue/Angular 等重前端框架。
- **❌ Do NOT** 在 Server Action 中处理耗时超过 500ms 的任务（请用 Celery）。
- **❌ Do NOT** 使用传统的页面全刷方案。
- **❌ Do NOT** 编写复杂的原生 JavaScript，优先使用 HTMX/Alpine 指令。
## 7. 外部服务 (External Services)
- **监控**：Sentry (已配置用于错误追踪) 。
- **对象存储**：Cloudflare R2 (用于房源/客源图片与附件；同时用于客户端安装包存储与分发) 。
- **地图服务**：待规划 (本期不涉及底层地图建设) 。
**版本**: 2.0 ｜ **最后更新**: 2026-04-25
**定位**: 本文档是 Fonrey 项目技术栈的**总索引**。所有跨模块的技术决策、版本约束、目录规范、禁止项在此定稿；**单一模块的具体技术方案**（数据模型、服务层、HTMX 交互、Celery 任务等）见各自子文档（见 §9 索引）。
---
## 8. 客户端发布技术栈 (Desktop Client Stack)
## 1. 项目概览
> 本节对应 PRD：`Project/fonrey/PRD/发布管理/客户端发布管理模块PRD.md`
> 所有决策均已在 PRD 中完成选型论证，此处为最终结论，直接执行。
**Fonrey（房睿）房产经纪管理系统** —— 面向房地产经纪公司的 B2B SaaS 平台，解决房源/客源信息散乱、跟进缺失、重复录入等痛点，支撑单租户 89,000+ 房源数据量级下的高效匹配。
### 8.1 客户端框架
- **核心模块**：房源管理、客源管理、楼盘管理、组织人事、权限管理、登录管理、系统设置、客户端发布
- **目标用户**：一线经纪人（高频）、店长/经理（每日）、运营/行政（每日）、系统管理员（不定期）
- **形态**：Web 端为主 + Electron 桌面客户端（壳应用）；移动端为 v2 规划
- **设计哲学**：数据一致性 > 录入/筛选速度 > UI 简洁高效。优先保障多租户数据物理隔离与极速响应。
- **框架**：[Electron](https://www.electronjs.org/)（当前稳定版）
- **内核**：Electron 捆绑的 Chromium（版本随 Electron 版本固定，不依赖系统浏览器）
- **主进程语言**：Node.js（JavaScript / TypeScript）
- **渲染层**：直接加载 Fonrey Web 应用 URL，100% 复用现有 HTMX + Alpine.js + Tailwind CSS 技术栈，**渲染层不新增任何框架**
---
### 8.2 自动更新
## 2. 核心技术栈
- **更新库**：`electron-updater`（`electron-builder` 生态，成熟方案）
- **更新包存储**：Cloudflare R2（复用现有存储账号，新增 `releases` bucket）
- **更新包分发**：Cloudflare CDN 加速（复用现有 CDN 配置）
- **更新检测端点**：Django 后端新增 `/api/client/updates/latest/`（GET，公开接口，无需登录）
- **检测时机**：客户端启动时 + 每 4 小时轮询一次
- **更新模式**：后台静默下载，下载完成后提示用户重启；服务端可将版本标记为"强制更新"，客户端不可跳过
| 层级 | 技术选型 | 说明 |
|---|---|---|
| **Frontend** | HTMX + Alpine.js + Tailwind CSS | 无重前端框架；HTMX 局刷、Alpine 管状态、Tailwind 样式 |
| **Backend** | Django 4.x（ASGI 模式） | 支持异步能力 |
| **Multi-tenant** | `django-tenants` | PostgreSQL Schema 隔离，租户数据物理安全 |
| **Database** | PostgreSQL 16 + PgBouncer | 连接池优化，支撑高并发 |
| **Cache** | Redis | 缓存、限流、Token、权限快照 |
| **Tasks** | Celery + Celery Beat | 异步导出、智能配房、邮件、图片转码 |
| **Storage** | Cloudflare R2（S3 兼容） | 房源图片、附件、客户端安装包 |
| **CDN** | Cloudflare | 静态资源 + 客户端更新包加速 |
| **Server** | Gunicorn + Uvicorn workers + Nginx | ASGI 服务部署 |
| **Monitoring** | Sentry + Grafana | 错误追踪 + 指标监控 |
| **Deployment** | Docker Compose | 容器化部署 |
| **Desktop Client** | Electron + electron-updater | 壳应用，渲染层复用 Web 技术栈，详见 §7 |
### 8.3 安装包构建与签名
---
- **构建工具**：`electron-builder`（输出 NSIS 安装包 `.exe` + 便携版 `.zip`）
- **目标平台**：Windows x64（优先），ARM64 按需支持
- **代码签名**：EV 代码签名证书（DigiCert 或 Sectigo），由 CI/CD 在构建时自动签名，消除 Windows SmartScreen 警告
- **CI/CD**：待确认平台（GitHub Actions / Jenkins），构建流水线负责：编译 → 签名 → 上传 R2 → 调用发布 API
## 3. 关键约定
### 8.4 Django 后端新增模块
- **多租户隔离**：所有数据库查询必须基于当前租户 Schema；严禁跨租户访问。`shared_apps` 仅放平台基础数据（Tenant、ClientRelease、PermissionDef 等）。
- **UI 交互**：HTMX 处理局部 DOM 刷新（分页、筛选、联想）；Alpine.js 处理前端状态（弹窗、多选、字数统计）；禁止编写复杂原生 JS。
- **异步处理**：所有耗时 > 500ms 的任务必须经 Celery 异步执行（Excel 导出、图片处理、智能配房、邮件发送）。
- **错误处理**：后端 API 返回标准 JSON 错误格式；HTMX 请求失败触发全局 Toast 提示。
- **文件命名**：Django App 用 `snake_case`；前端模板组件用 `kebab-case`。
- **敏感数据**：手机号等 PII 通过 `core/encryption.py` 加密存储。
- **配置**：环境变量统一通过 `.env` 注入，禁止硬编码。
在现有 `fonrey/apps/` 目录下新增：
---
## 4. 目录结构
```
apps/
└── release/ # 客户端发布管理
├── models.py # ClientRelease（版本号、类型、状态、下载URL、SHA256、更新日志）
├── views.py # 公开更新检测 API + 管理后台 CRUD 视图
├── urls.py
└── admin.py
fonrey/
├── apps/
│ ├── tenants/ # django-tenants 配置（shared_apps）
│ ├── accounts/ # 登录认证（详见 登录管理技术方案.md）
│ ├── permissions/ # 权限管理（详见 权限管理系统技术方案.md）
│ ├── org/ # 组织人事（org_units, staff）
│ ├── region/ # 区域管理（districts, business_areas, metro）
│ ├── complex/ # 楼盘管理（complexes, buildings, schools）
│ ├── property/ # 房源核心（含 models/services/tasks 三层）
│ ├── client/ # 客源管理
│ ├── settings/ # 系统设置（lookup, tags）
│ └── release/ # 客户端发布管理（shared_apps）
├── shared/ # 公共 Schema App
└── core/
├── models/base.py # 抽象基类
├── encryption.py # PII 加密
└── cache.py # Redis 工具
```
**`ClientRelease` 模型关键字段**：
**Django App 内部分层规范**（以 `property` 为典型，其他模块参照执行）：
| 字段 | 类型 | 说明 |
|------|------|------|
| `version` | CharField | SemVer 格式，如 `1.2.3`，唯一索引 |
| `platform` | CharField | 平台标识，如 `win32` |
| `arch` | CharField | CPU 架构，如 `x64` |
| `release_type` | CharField | `normal` / `force`（强制更新） |
| `status` | CharField | `draft` / `published` / `archived` |
| `download_url` | URLField | EXE 安装包 Cloudflare R2 URL |
| `portable_url` | URLField | ZIP 便携版 URL（可选） |
| `checksum_sha256` | CharField | 安装包 SHA256 校验值 |
| `min_required_version` | CharField | 低于此版本的客户端强制升级（可选） |
| `release_notes` | TextField | Markdown 格式更新日志 |
| `published_at` | DateTimeField | 发布时间 |
```
apps/property/
├── models/ # 一表一文件，避免单文件膨胀
├── services/ # 业务逻辑（完成度计算、重复检测、搜索等）
├── tasks.py # Celery 异步任务
├── views.py # HTMX/JSON 视图
└── urls.py
```
**`ClientRelease` 属于 `shared_apps`（公共 Schema）**，不属于租户隔离范围，所有租户共享同一套客户端版本。
---
### 8.5 客户端关键约定
## 5. 禁止项（Do NOT）
- ❌ React / Vue / Angular 等重前端框架
- ❌ 在请求线程中处理耗时 > 500ms 的任务（必须用 Celery）
- ❌ 传统页面全刷方案
- ❌ 复杂原生 JavaScript（优先 HTMX/Alpine 指令）
- ❌ Electron 渲染进程开启 `nodeIntegration: true`
- ❌ 客户端内嵌业务逻辑或本地数据库（壳应用原则）
- ❌ 跨租户 SQL 查询（必须经 `django-tenants` 中间件切换 Schema）
- ❌ 在代码中硬编码密钥、Tenant ID、URL
---
## 6. 外部服务
| 服务 | 用途 | 配置位置 |
|---|---|---|
| **Sentry** | 错误追踪 | 已配置 |
| **Cloudflare R2** | 房源/客源图片、附件、客户端安装包 | bucket: `media`、`releases` |
| **Cloudflare CDN** | 静态资源 + 客户端更新包加速 | 复用现有账号 |
| **邮件服务** | 找回密码、通知 | 待选型（详见 登录管理技术方案） |
| **代码签名** | EV 证书（DigiCert / Sectigo） | CI/CD 阶段使用 |
| **地图服务** | v2 规划，本期不涉及 | — |
---
## 7. 客户端发布技术栈（Desktop Client）
> **完整方案**见 PRD：`PRD/发布管理/客户端发布管理模块PRD.md`。本节仅列最终结论。
- **框架**：Electron（稳定版） + Chromium 内核（随版本固定，不依赖系统浏览器）
- **渲染层**：直接加载 Fonrey Web URL，**100% 复用 HTMX + Alpine + Tailwind**，渲染层零新增框架
- **自动更新**：`electron-updater`；更新包存 R2 / 经 CDN 分发；后端检测端点 `GET /api/client/updates/latest/`（公开）；启动时 + 每 4h 轮询；后台静默下载，下载完成提示重启；服务端可标记强制更新
- **构建**：`electron-builder` 输出 NSIS `.exe` + 便携版 `.zip`；目标 Windows x64（优先），ARM64 按需
- **代码签名**：EV 证书，CI/CD 自动签名，消除 SmartScreen 警告
- **完整性校验**：下载后必须校验 SHA256 与服务端返回一致才能安装
- **后端模型**：`apps/release/ClientRelease`（`shared_apps`，所有租户共享版本表）
---
## 8. 模块技术方案索引
每个模块的具体技术决策（模型字段、服务层、缓存策略、HTMX/Celery 集成等）见对应子文档：
| 模块 | 技术方案文档 | PRD | 数据模型 |
|---|---|---|---|
| 登录认证 | [`登录管理技术方案.md`](./登录管理技术方案.md) | `PRD/登录管理/` | `DATA_MODEL/DATA_MODEL_LOGIN.md` |
| 权限管理 | [`权限管理系统技术方案.md`](./权限管理系统技术方案.md) | `PRD/权限管理/` | `DATA_MODEL/DATA_MODEL_PERMISSION.md` |
| 房源管理 | _待补充_ | `PRD/房源管理/` | `DATA_MODEL/DATA_MODEL_PROPERTY.md` |
| 客源管理 | _待补充_ | `PRD/客源管理/` | `DATA_MODEL/DATA_MODEL_CLIENT.md` |
| 楼盘管理 | _待补充_ | `PRD/房源管理/`（含楼盘） | `DATA_MODEL/DATA_MODEL_COMPLEX.md` |
| 组织人事 | _待补充_ | `PRD/组织人事管理/` | `DATA_MODEL/DATA_MODEL_ORG.md` |
| 系统设置 | _待补充_ | `PRD/系统配置/`、`PRD/系统管理/` | `DATA_MODEL/DATA_MODEL_PUBLIC.md` |
| 客户端发布 | 见本文档 §7 | `PRD/发布管理/客户端发布管理模块PRD.md` | — |
**总览数据模型**：[`DATA_MODEL/DATA_MODEL.md`](../DATA_MODEL/DATA_MODEL.md)
**MVP 范围与产品总览**：[`PRD/PRD_MVP.md`](../PRD/PRD_MVP.md)
---
## 9. 文档维护原则
- 本文档仅记录**跨模块共识**与**模块索引**，不展开模块细节
- 模块技术方案在子文档中维护，并通过 §8 表格回链
- 任何技术栈变更（替换组件、升级主版本、新增外部服务）须同步更新本文档 §2、§5、§6
- 新增模块时，先在 §4 目录结构补位，再在 §8 索引登记子文档
- **❌ Do NOT** 在 Electron 渲染进程中使用 `nodeIntegration: true`，保持 Web 沙箱安全
- **❌ Do NOT** 在客户端内嵌任何业务逻辑或本地数据库，所有业务数据由服务端提供
- **❌ Do NOT** 在客户端内新开多个 `BrowserWindow` 加载内部页面，所有导航在单窗口 SPA 内完成（外部链接除外，需在系统浏览器打开）
- 客户端版本号必须与服务端 `ClientRelease.version` 严格一致，通过 `package.json` 的 `version` 字段统一管理
- 更新包下载完成后，必须校验 SHA256 与服务端返回值一致后才能执行安装，防止下载损坏或中间人攻击

40
wiki/concepts/Appearance-Anxiety.md Normal file
View File

@@ -0,0 +1,40 @@
---
title: "Appearance Anxiety（容貌焦虑）"
type: concept
tags: [healthcare, compliance, medical-aesthetics, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"容貌焦虑"（容貌焦虑情绪/appearance anxiety）是医美广告中通过暗示不进行医美将导致负面后果，从而诱导消费者接受医美服务的营销手法。2021年起，国家市场监督管理总局（SAMR）在《医疗美容广告执法指南》中明确将制造"容貌焦虑"列为医美广告红线。
## Legal Prohibition
> "医美广告不得制造'容貌焦虑'——2021年起市场监管总局执法力度显著加强。" — SAMR《医疗美容广告执法指南》
## Prohibited Expressions
医美广告中禁止使用以下暗示负面后果的表述：
- "丑陋""不美丽""影响社交"
- "影响就业""影响感情"
- 任何暗示不进行医美将导致负面影响的表述
## Compliant Alternatives
| 违规表述 | 合规替代 |
|----------|----------|
| "现在不做，以后会后悔" | 介绍医美项目原理和技术特点 |
| "你的脸型需要改变" | 展示医师资质和机构合规证书 |
| "变美是女性的权利" | 介绍适合人群和技术安全性 |
| "再不整就晚了" | 提供科学医美知识教育 |
## Enforcement Context
2021年《医疗美容广告执法指南》发布后，市场监管部门对医美广告实施专项整治，重点打击：
- 制造容貌焦虑的广告内容
- 使用患者前后对比照片
- 虚假夸大医美效果
- 违规医美直播带货
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：容貌焦虑是医美合规的核心红线
- [[SAMR]]：《医疗美容广告执法指南》的发布机构
- [[Xiaohongshu]]：小红书大规模清理医美日记类内容的重要背景
- [[Compliance-Risk-Matrix]]：制造容貌焦虑属 High Risk 级别，面临罚款+账号封禁

39
wiki/concepts/Architectural-Empathy.md Normal file
View File

@@ -0,0 +1,39 @@
---
title: "Architectural Empathy"
type: concept
tags: [ux-design, cultural-intelligence, design-philosophy]
sources: [specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。
## Core Principles
### 1. Structural > Cosmetic
- ❌ 在首页添加一张多元人群图
- ✅ 重新设计表单字段以接受全球命名结构
### 2. Precondition, Not Afterthought
- ❌ 产品上线后再考虑国际化
- ✅ 国际化是架构设计的前提条件（Global-First Architecture）
### 3. "Who is left out?" as First Question
每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？"
### 4. Absolute Cultural Humility
永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。
## Relationship to Other Concepts
- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象
- [[Global-First-Architecture]]：Architectural Empathy 的实施方法
- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础
## Contrast: Performative vs. Structural Empathy
| 维度 | 表演性同理心 | 结构性同理心 |
|------|------------|------------|
| 位置 | 表面层 | 架构层 |
| 效果 | 短期感知改善 | 长期用户摩擦消除 |
| 检测方式 | 多元图片存在 | APAC 用户转化率提升 |
| 维护 | 每次更新需重新添加 | 架构内建，持续有效 |

45
wiki/concepts/Blue-Hat-Logo.md Normal file
View File

@@ -0,0 +1,45 @@
---
title: "Blue Hat Logo（蓝帽子标识）"
type: concept
tags: [healthcare, compliance, supplement, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"蓝帽子"（保健食品专用标志，保健食品专有标志的俗称）是经国家市场监督管理总局（SAMR）批准注册的保健食品专属标识。合法保健食品必须取得并展示蓝帽子标志，否则不得以保健食品名义进行销售或推广。
## Legal Requirements
- 保健食品须经 SAMR 注册审批或完成备案
- 须在产品包装及营销材料中展示蓝帽子标志和批准文号
- 无蓝帽子标志的产品不得以"保健食品"名义推广
## Marketing Restrictions
### 允许范围
- 24项经批准保健功能声称（如：增强免疫力、辅助降血脂、辅助降血糖、改善睡眠等）
- 必须使用标准化功能声称语言（如"辅助降血脂"而非"降血脂"）
- 必须标注："保健食品不是药物，不能替代药物治疗疾病"
### 禁止事项
- 声称治疗功能（"治愈疾病""代替药物"）
- 使用医疗术语（"治愈""治疗""保证康复"）
- 超出批准保健功能范围宣传
- 功效与药品比较或暗示替代关系
- 夸大宣传或虚假功效声称
## Compliance Risk
> "保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因。" — SAMR 合规统计
违规后果：罚款 + 产品下架 + 媒体曝光
## Key Distinction
| 类别 | 标识要求 | 功能声称 | 法律定性 |
|------|----------|----------|----------|
| 保健食品 | 须展示蓝帽子 | 24项批准功能范围内 | 食品，非药品 |
| 药品 | 须展示批准文号 | 治疗适应症 | 药品 |
| 普通食品 | 无特殊标识 | 不得声称保健功能 | 食品 |
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：蓝帽子管理是医疗营销合规的组成部分
- [[SAMR]]：蓝帽子注册审批由 SAMR 负责
- [[Compliance-Risk-Matrix]]：无蓝帽子宣传保健功能属 High Risk 级别

46
wiki/concepts/Compliance-Risk-Matrix.md Normal file
View File

@@ -0,0 +1,46 @@
---
title: "Compliance Risk Matrix（合规风险分级矩阵）"
type: concept
tags: [healthcare, compliance, risk-management, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
医疗营销合规风险分级矩阵是将医疗营销违规行为按风险严重程度分级（Critical / High / Medium / Low），并为每个等级配套相应处置措施的管理工具，帮助企业集中资源优先处理高风险违规。
## Risk Levels
### Critical（严重）
| 违规类型 | 潜在后果 | 建议行动 |
|----------|----------|----------|
| 处方药面向大众媒体广告 | 罚款 + 撤销广告批准文号 + 刑事责任 | 立即停止，启动危机应对 |
| 无审查证明发布医疗广告 | 责令停止 + 罚款20-100万元 | 立即下架，启动审查程序 |
| 非法处理患者敏感个人信息 | 最高罚款5000万元或上年度营收5% | 立即补救，激活数据安全应急预案 |
### High（高度）
| 违规类型 | 潜在后果 | 建议行动 |
|----------|----------|----------|
| 保健食品声称治病功能 | 罚款 + 产品下架 + 媒体曝光 | 48小时内修订全部推广材料 |
| 医美广告使用前后对比照片 | 罚款 + 平台账号封禁 + 行业通报 | 24小时内下架相关内容 |
### Medium（中等）
| 违规类型 | 潜在后果 | 建议行动 |
|----------|----------|----------|
| 使用绝对化表述 | 罚款 + 警告 | 72小时内完成自查整改 |
| 健康科普内容夹带产品推广 | 平台处罚 + 内容下架 | 修订内容，标注推广性质 |
### Low（轻微）
| 违规类型 | 潜在后果 | 建议行动 |
|----------|----------|----------|
| 缺失咨询/声明语句 | 警告 + 责令整改 | 添加必要声明语句 |
| 文献引用格式不规范 | 内部合规扣分 | 修正引用格式 |
## Core Usage Principle
> "合规团队须根据风险分级决定审查层级——Critical 内容须合规+法务+高管三方会审。" — 三级审查与风险分级联动
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：风险矩阵是合规管理的核心工具
- [[Three-Tier-Review-Mechanism]]：风险分级决定审查层级
- [[Medical-Advertisement-Review]]：Critical 违规多与广告审查制度相关
- [[Patient-Privacy-PIPL]]：PIPL 违规属 Critical Risk

42
wiki/concepts/Global-First-Architecture.md Normal file
View File

@@ -0,0 +1,42 @@
---
title: "Global-First Architecture"
type: concept
tags: [internationalization, i18n, architecture, ux-design]
sources: [specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
将国际化（Internationalization, i18n）和本地化（Localization, l10n）作为产品架构的先天前提条件，而非上线后的补救措施。这一设计哲学主张：从系统设计的第一天起，就假设产品将在多元文化环境中运行。
## Key Dimensions
### 1. Data Architecture
- **命名**：不接受固定结构的姓名字段 → 使用 `fullName` 或 `preferredName`
- **日期/时间**：存储为 Unix timestamp 或 ISO 8601 → 按用户 locale 渲染
- **货币**：存储为最低单位整数（如 cents）→ 按用户 locale 渲染货币符号
- **地址**：不使用固定字段组合 → 使用结构化 key-value 对
### 2. UI Architecture
- **RTL 支持**：CSS `direction: rtl` 作为默认模板变量
- **文本扩展**：按钮/标签预留 300% 宽度余量（德语等语言比英语长 30%+）
- **图标语义**：颜色不作为唯一语义载体（配合图标或文字）
- **日历系统**：支持 Gregorian / Hijri / Hebrew / Chinese / Buddhist 等多历法
### 3. Content Architecture
- **翻译层**：字符串 ID 而非硬编码文本
- **文化适配**：图像/颜色/图标按 locale 分组替换
- **A/B 测试**：文化分组作为实验维度
## Why "Global-First" vs "Localization Afterthought"?
| 维度 | 亡羊补牢式本地化 | Global-First |
|------|---------------|------------|
| 成本 | 高（后期重构 UI 和数据模型） | 低（架构内建） |
| 用户体验 | 补丁感强，一致性差 | 原生感强 |
| 可维护性 | 每次更新需同步修改所有 locale | 单次架构变更自动覆盖所有市场 |
| 技术债务 | 快速积累 | 从根本上避免 |
## Relationship to Other Concepts
- [[Invisible-Exclusion]]：Global-First Architecture 要解决的首要问题
- [[Architectural Empathy]]：Global-First Architecture 的设计哲学基础
- [[Cultural-Intelligence]]：Global-First Architecture 所需的知识基础

37
wiki/concepts/Healthcare-Marketing-Compliance.md Normal file
View File

@@ -0,0 +1,37 @@
---
title: "Healthcare Marketing Compliance（医疗营销合规）"
type: concept
tags: [healthcare, compliance, china, legal]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
医疗营销合规是指医疗健康企业（涵盖药品、医疗器械、医美、保健食品、互联网医疗等子行业）在品牌推广、内容营销、学术推广过程中，遵守中国相关法律法规和平台规则的管理体系。
## Core Framework
以《广告法》《医疗广告管理办法》《互联网广告管理办法》为核心，结合 NMPA、SAMR 及各平台规则构成完整合规框架。
## Sub-Domains
- [[Medical-Advertisement-Review]]：医疗广告审查制度
- [[Three-Tier-Review-Mechanism]]：企业内部三级审查机制
- [[Blue-Hat-Logo]]：保健食品"蓝帽子"标识管理
- [[Appearance-Anxiety]]：医美广告"容貌焦虑"红线
- [[Patient-Privacy-PIPL]]：患者隐私 PIPL 合规
- [[Academic-Detailing]]：学术推广合规
- [[Compliance-Risk-Matrix]]：合规风险分级矩阵
## Core Principles
1. **合规不是"堵营销"，而是"保护品牌"**——一次违规处罚的代价远高于合规投入
2. **"事前审查"优于"事后补救"**——所有对外发布的医疗营销内容必须经过合规团队审核
3. **建立合规文化**——定期全员合规培训，建立违规案例库
## Compliance Culture
- 合规团队须与营销团队协作，而非对立
- 建立"合规案例库"收集行业执法案例作为内部警示教育材料
- 与监管机构保持良好沟通——主动了解政策趋势，不等处罚才学新规
## Related Concepts
- [[The-Agency]]：医疗营销合规 Agent 所属框架
- [[Government-Digital-Presales-Consultant]]：政府合规 Agent（等保/商密）
- [[legal-compliance-checker]]：通用法律合规 Agent

46
wiki/concepts/Invisible-Exclusion.md Normal file
View File

@@ -0,0 +1,46 @@
---
title: "Invisible Exclusion"
type: concept
tags: [cultural-intelligence, ux-design, internationalization, accessibility]
sources: [specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
软件产品中无意识地排斥特定用户群体的设计模式——在开发者的默认假设下运作，但用户（尤其是非西方文化背景者）会感受到摩擦、困惑或被排斥。之所以"隐性"，是因为设计者往往意识不到这些假设。
## Key Patterns
### 命名结构假设
- **问题**：强制 First Name / Last Name 拆分字段
- **影响**：许多文化不使用严格的名字-姓氏二分法（西班牙语的双姓、越南的 HO + TEN、日本的氏 + 名等）
- **修复**：改为单一"Full Name"或"Preferred Name"字段
### 性别选项
- **问题**：仅提供二元性别选择器
- **影响**：跨性别者、非二元性别用户无法正确注册
- **修复**：提供开放文本字段或"Prefer to self-describe"选项
### 颜色语义
- **问题**：红色=错误/警告（西方惯例）
- **影响**：中国金融应用中红色表示"上涨"，用户会感到困惑
- **修复**：颜色+文字标签组合，不依赖单一颜色传达语义
### 日期/时间格式
- **问题**：MM/DD/YYYY 作为默认格式
- **影响**：DD/MM/YYYY 地区（欧洲、亚洲大部分）用户混淆
- **修复**：本地化格式检测或 ISO 8601 (YYYY-MM-DD)
### RTL 阅读方向
- **问题**：假设所有文字从左到右阅读
- **影响**：阿拉伯语、希伯来语用户无法正常使用界面
- **修复**：CSS `direction: rtl` + 镜像布局架构支持
## Why "Invisible"?
开发者本身属于其目标用户群体，因此这些假设对他们来说是"透明"的。[[Architectural Empathy]] 要求在设计阶段就主动质疑这些假设。
## Related Concepts
- [[Architectural Empathy]]（结构性同理心）
- [[Global-First-Architecture]]（全局优先架构）
- [[Cultural-Intelligence]]（文化智能）
- [[InclusiveVisuals]]（包容性视觉）

38
wiki/concepts/Medical-Advertisement-Review.md Normal file
View File

@@ -0,0 +1,38 @@
---
title: "Medical Advertisement Review（医疗广告审查制度）"
type: concept
tags: [healthcare, compliance, advertising, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
医疗广告审查制度是中国对医疗广告实施的前置审批管理——医疗广告必须经省级卫生行政部门审查并取得《医疗广告审查证明》后方可发布。该制度是医疗广告合规的基石，违反将面临行政处罚乃至刑事追责。
## Core Requirements
- **审查主体**：省级卫生行政部门
- **审查对象**：医疗广告（涵盖医疗机构、医疗服务、医疗产品等）
- **证书名称**：《医疗广告审查证明》
- **有效期**：通常为1年
- **内容限制**：广告内容不得超出审查批准范围；内容修改须重新申请审查
## Key Legal Basis
- 《广告法》第46条：医疗、药品、医疗器械广告等依法须经审查的广告，广告主应当在发布前委托广告审查机关对广告内容进行审查
- 《医疗广告管理办法》：医疗广告内容标准、审查程序、发布规则、违规处罚
## Three Content Categories
| 类别 | 审查要求 | 发布渠道 |
|------|----------|----------|
| 医疗广告 | 必须取得《医疗广告审查证明》 | 经审查批准渠道 |
| 药品广告 | 必须取得药品广告批准文号 | 非处方药可经大众媒体；处方药仅限专业期刊 |
| 医疗器械广告 | 必须取得医疗器械广告批准文号 | 依类别分级管理 |
## Prohibited Expressions（通用红线）
- 绝对化表述："最佳疗效""完全治愈""100%有效"
- 保证承诺："无效退款""保证治愈""一次见效"
- 诱导性语言："免费治疗""限时优惠""不治疗会恶化"
- 患者推荐/见证：患者疗效推荐/证言
- 功效比较：与其他药品或医疗机构的效果比较
## Relationship to Healthcare Marketing Compliance
医疗广告审查是 [[Healthcare-Marketing-Compliance]] 的核心前置环节。企业必须先取得相应审查证书，方可开展后续的合规营销活动。

42
wiki/concepts/Patient-Privacy-PIPL.md Normal file
View File

@@ -0,0 +1,42 @@
---
title: "Patient Privacy PIPL（患者隐私合规）"
type: concept
tags: [healthcare, compliance, privacy, data, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
患者隐私 PIPL 合规是指医疗健康企业在收集、存储、使用、传输患者个人健康信息时，遵守《个人信息保护法》（PIPL）、《数据安全法》、《网络安全法》等数据安全法规的合规义务。
## Core Legal Framework
- **《个人信息保护法》(PIPL)**：将个人医疗健康信息认定为"敏感个人信息"，须获得单独授权方可处理
- **《数据安全法》**：对医疗健康数据进行分类分级管理
- **《网络安全法》**：医疗机构信息系统的等级保护要求
- **《人类遗传资源管理条例》**：基因检测/遗传信息的收集、存储和跨境传输限制
## Sensitive Personal Information Classification
根据《个人信息保护法》第28条，医疗健康信息属于敏感个人信息，处理须满足：
- 须告知个人处理敏感个人信息的必要性及对个人权益的影响
- **须取得个人的单独同意**（不得与一般授权合并）
- 须进行个人信息保护影响评估（PIPL Impact Assessment）
## Key Compliance Requirements
### 营销场景
- 不得在未获授权情况下使用患者就诊信息、诊断结果、检验报告用于营销
- 患者案例推广须取得书面知情同意并充分脱敏
### 数据安全
- 患者数据管理须加密存储
- 分级访问控制
- 定期安全审计
- 涉及跨境数据传输须通过数据出境安全评估
### 违规处罚
> "患者健康数据属于《个人信息保护法》认定的'敏感个人信息'——违规最高罚款5000万元或上年度营收5%。" — PIPL 第66条
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：患者隐私合规是医疗营销合规的重要组成部分
- [[Compliance-Risk-Matrix]]：违规处理患者敏感信息属 Critical Risk
- [[Evidence-Based-Merge-Proposal]]（跨概念关联）：医疗数据的脱敏处理与身份识别技术相关

49
wiki/concepts/Three-Tier-Review-Mechanism.md Normal file
View File

@@ -0,0 +1,49 @@
---
title: "Three-Tier Review Mechanism（三级审查机制）"
type: concept
tags: [healthcare, compliance, process, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
企业内部三级审查机制是医疗营销合规的核心流程保障——所有对外发布的医疗营销内容须经过三层审核方可发布，通过逐级过滤最大化降低违规风险。
## Three Tiers
### 第一级：法务初审（Legal Initial Review）
- **执行者**：法务专员
- **审查重点**：法律合规性——是否触及绝对化表述、保证承诺、患者推荐等明确法律红线
- **输出**：书面审查意见（修改/通过/驳回）
### 第二级：合规复审（Compliance Secondary Review）
- **执行者**：合规经理
- **审查重点**：行业专项合规——对照 NMPA/SAMR 规定、平台规则，检查内容是否超出批准范围
- **输出**：书面审查意见（附具体修改建议）
### 第三级：终审发布（Final Approval & Release）
- **执行者**：总法律顾问或合规总监
- **审查重点**：综合评估——重大营销活动、涉及新领域或高风险内容
- **输出**：最终批准/驳回
## Application Scope
- 线上广告（搜索广告/信息流广告/程序化广告）
- 线下物料（宣传册/海报/易拉宝）
- 社交媒体内容（KOL 合作脚本/直播话术/短视频文案）
- 学术推广材料（会议赞助材料/卫星会幻灯片/医疗代表话术）
## Risk Tiering
| 风险等级 | 审查要求 |
|----------|----------|
| Low | 合规专员审核 |
| Medium | 合规经理复审 |
| High | 总法律顾问终审 |
| Critical | 合规+法务+高管三方会审 |
## Core Principle
> "所有对外发布的医疗营销内容必须经过合规团队审核。" — 三级审查机制核心原则
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：三级审查是医疗营销合规的核心流程
- [[Compliance-Risk-Matrix]]：风险分级决定审查层级
- [[Medical-Advertisement-Review]]：三级审查以取得广告审查证书为前提

28
wiki/entities/DXY.md Normal file
View File

@@ -0,0 +1,28 @@
---
title: "DXY（丁香园）"
type: entity
tags: [platform, healthcare, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Overview
丁香园（Dingxiang Yuan / DXY），中国最大的医师专业社区平台，同时运营丁香医生（面向大众的健康科普平台）和丁香通（医药企业营销平台）。在医疗营销合规中承担医师认证体系建设和健康科普内容专业审核职能。
## Key Roles
- **互联网医疗平台合规**：医师入驻资质审核（须提交医师资格证+执业证）、患者评价管理、图文/视频问诊标准
- **健康科普内容专业审核**：健康教育内容须基于循证医学，引用文献须注明来源
- **商业合作与编辑独立性分离**：商业合作内容须标注，编辑内容须保持独立性
- **保健食品合规内容平台**：在健康内容中不得嵌入产品推广
## Role in Healthcare Marketing Compliance
- 健康教育内容与广告边界——不得在科普文章中嵌入产品推广
- 医师个人品牌合规——医师须以真实身份出现，展示医师资格证和执业证
- 商业合作内容须标注"广告"或"推广"标签
## Aliases
- 丁香园
- Dingxiang Yuan
- Dingxiang Doctor
- 丁香医生
- 丁香通

39
wiki/entities/Douyin.md Normal file
View File

@@ -0,0 +1,39 @@
---
title: "Douyin（抖音）"
type: entity
tags: [platform, healthcare, china, social-media]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Overview
抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
## Healthcare Industry Access Requirements
- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
- 认证后方可发布医疗健康相关内容和广告
## Content Review Rules
- 禁止展示外科手术过程
- 禁止使用患者推荐/见证疗效内容
- 禁止展示处方药信息
- 健康科普内容须经平台人工审核
## Physician Account Certification
- 须提交医师资格证
- 认证后获得"认证医师"标识
- 认证医师可在合规范围内发布健康科普内容
## Livestream Restrictions
- 医疗账号直播期间禁止推荐具体药品或治疗方案
- 禁止进行在线诊断
- 违反规定可能导致账号封禁或流量限制
## Advertising Placement
- 医疗广告须经过行业资质审核
- 创意内容须经平台人工审核
## Aliases
- 抖音
- Douyin
- TikTok China

28
wiki/entities/NMPA.md Normal file
View File

@@ -0,0 +1,28 @@
---
title: "NMPA（国家药品监督管理局）"
type: entity
tags: [regulator, healthcare, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Overview
国家药品监督管理局（National Medical Products Administration），中国药品/医疗器械/化妆品监管核心机构，归口市场监督管理总局。负责药品注册审批、医疗器械注册审批、广告批准文号管理、药品上市后不良反应监测。
## Key Responsibilities
- 药品注册分类及对应营销限制
- 药品广告批准文号审批（有效期1年）
- 医疗器械广告批准文号审批
- 药品上市后不良反应监测与信息公开
- 仿制药生物等效性认证推广规则
## Role in Healthcare Marketing Compliance
- 处方药大众媒体广告禁令执法依据来源
- 药品营销材料适应症必须与 NMPA 批准说明书一致——超范围推广属于违规
- 仿制药营销可推广通过生物等效性研究，但不得声称"与原研药完全等效"
- 在线售药管理依据：《药品网络销售监督管理办法》
## Aliases
- 国家药品监督管理局
- National Medical Products Administration
- Guojia Yaopin Jiandu Guanli Ju

26
wiki/entities/SAMR.md Normal file
View File

@@ -0,0 +1,26 @@
---
title: "SAMR（国家市场监督管理总局）"
type: entity
tags: [regulator, healthcare, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Overview
国家市场监督管理总局（State Administration for Market Regulation），中国市场的综合监管机构，下设药品监督管理局（NMPA）。在医疗营销合规领域，SAMR 主导广告监管与执法，2021年发布的《医疗美容广告执法指南》标志着医美合规整治进入新阶段。
## Key Responsibilities
- 广告监管综合执法
- 医疗美容广告合规整治（2021年起）
- 保健食品"蓝帽子"注册标志管理
- 互联网广告管理办法执法
## Role in Healthcare Marketing Compliance
- 2021年发布《医疗美容广告执法指南》，明确医美广告监管重点
- 医疗广告须经省级卫生行政部门审查，但 SAMR 负责广告内容执法
- 保健食品无"蓝帽子"标志不得以保健品名义销售或推广
- 互联网广告（抖音/小红书/微信等平台）内容合规由 SAMR 监管
## Aliases
- 国家市场监督管理总局
- State Administration for Market Regulation

40
wiki/entities/The-Agency.md Normal file
View File

@@ -0,0 +1,40 @@
---
title: "The Agency"
type: entity
tags: [multi-agent, open-source, ai-agents]
sources: [contributing, contributing_zh-cn, specialized-workflow-architect, agentic-identity-trust, specialized-document-generator, government-digital-presales-consultant, healthcare-marketing-compliance, specialized-civil-engineer, specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
The Agency 是一个开源的多智能体（Multi-Agent）系统，提供了 147 个专业 Agent，涵盖 12 个业务部门：Engineering、Design、Finance、Game Dev、Marketing、Paid Media、Product、Project Management、Testing、Support、Spatial Computing、Specialized。
## Structure
### Departments
| 部门 | 职能 | 代表 Agent |
|------|------|-----------|
| Specialized | 垂直领域专家 | [[Cultural Intelligence Strategist]]、Civil Engineer、Document Generator |
| Engineering | 软件开发 | Backend Architect、Reality Checker、API Tester |
| Design | 视觉与体验设计 | [[ArchitectUX]]、Brand Guardian、UX Researcher |
| Project Management | 项目组合管理 | Studio Producer、Senior PM、Jira Workflow Steward |
| Spatial Computing | XR/AR/VR | XR Interface Architect、visionOS Engineer |
| Paid Media | 广告投放 | PPC Strategist、Programmatic Buyer |
| Marketing | 内容与增长 | Content Creator、Growth Hacker |
| Product | 产品策略 | Product Manager、Trend Researcher |
| Testing | 质量保障 | Accessibility Auditor、Performance Benchmarker |
| Support | 客户支持 | Support Responder、Analytics Reporter |
### Core Principles
- **鲜明性格**：每个 Agent 都有明确的个性，而非泛化的人设
- **明确交付物**：真实代码、模板、量化指标
- **可验证工作流**：经过实践检验的操作流程
- **学习与记忆**：持续更新领域知识
## Key Files
- `Agent/agency-agents/`：所有 Agent 定义文件
- `SPEC.md`：Agent 设计规范
## Related
- [[Multi-Agent-System-Reliability]]：The Agency 的可靠性架构模式
- [[Multi-Agent-Team]]：多 Agent 团队配置最佳实践

39
wiki/entities/Xiaohongshu.md Normal file
View File

@@ -0,0 +1,39 @@
---
title: "Xiaohongshu（小红书）"
type: entity
tags: [platform, healthcare, china, social-media]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Overview
小红书（Xiaohongshu / Little Red Book），中国领先的生活方式分享社区，以 UGC（用户生成内容）为核心，医美内容曾是平台热门品类。2021年起平台大规模清理违规医美内容，医疗健康内容现已纳入白名单管理。
## Healthcare Content Controls
- **2021年起大规模医美内容清理**：平台对医疗美容内容实施严格管控
- **白名单管理制度**：医疗健康内容须经平台认证方可发布
- **禁止内容**：医美前后对比照片/视频（"医美日记"）、处方药推荐、未经验证的民间偏方
## Healthcare Certified Accounts
- 医疗机构须完成专业资质认证方可发布医疗内容
- 医师须提交医疗机构执业许可证等资质文件
## Brand Collaboration Compliance（蒲公英平台）
- 医疗健康相关商业合作须通过官方平台进行
- 内容须标注"广告"或"推广"标签
- 违规商业合作可能导致品牌方和博主账号双重处罚
## Community Guidelines
- 反对伪科学内容
- 反对引发健康焦虑的内容
- 用户分享的医美经历（即使"自愿分享"）平台和诊所均可被追究连带责任
## Key Risk
> "医美日记类内容无论是否由用户'自愿'分享，平台和诊所均可被追究连带责任。" — 2021年医美合规整治后明确
## Aliases
- 小红书
- Xiaohongshu
- Little Red Book
- 蒲公英平台（Pugongying）
- Dandelion（蒲公英英文）

18
wiki/index.md
View File

@@ -4,6 +4,7 @@
- [Overview](overview.md) — living synthesis
## Sources
- [2026-04-25] [Healthcare Marketing Compliance Specialist](sources/healthcare-marketing-compliance.md)
- [2026-04-24] [Workflow Architect Agent Personality](sources/specialized-workflow-architect.md)
- [2026-04-24] [Government Digital Presales Consultant](sources/government-digital-presales-consultant.md)
- [2026-04-24] [Agentic Identity & Trust Architect](sources/agentic-identity-trust.md)
@@ -410,8 +411,7 @@
- [2026-04-20] [corporate-training-designer](sources/corporate-training-designer.md) — (expected: wiki/sources/corporate-training-designer.md — source missing)
- [2026-04-20] [automation-governance-architect](sources/automation-governance-architect.md) — (expected: wiki/sources/automation-governance-architect.md — source missing)
- [2026-04-20] [specialized-model-qa](sources/specialized-model-qa.md) — (expected: wiki/sources/specialized-model-qa.md — source missing)
- [2026-04-20] [specialized-cultural-intelligence-strategist](sources/specialized-cultural-intelligence-strategist.md) — (expected: wiki/sources/specialized-cultural-intelligence-strategist.md — source missing)
- [2026-04-20] [healthcare-marketing-compliance](sources/healthcare-marketing-compliance.md) — (expected: wiki/sources/healthcare-marketing-compliance.md — source missing)
- [2026-04-20] [Cultural Intelligence Strategist](sources/specialized-cultural-intelligence-strategist.md) — The Agency Specialized 部门文化包容性专家 Agent，检测软件开发中的"隐性排斥"（命名规范、颜色语义、性别选项等），通过四阶段工作流（盲点审计→自主研究→结构修正→解释原理）实现架构级文化智能。
- [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
- [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
@@ -620,8 +620,10 @@
- [Docker-Network](entities/Docker-Network.md)
- [Docker卷](entities/Docker卷.md)
- [DORA-Metrics](entities/DORA-Metrics.md)
- [Douyin](entities/Douyin.md)
- [DracoVibeCoding](entities/DracoVibeCoding.md)
- [DXC-VSM](entities/DXC-VSM.md)
- [DXY](entities/DXY.md)
- [EESJGong](entities/EESJGong.md)
- [Eurocode](entities/Eurocode.md)
- [fireworks-tech-graph](entities/fireworks-tech-graph.md)
@@ -695,6 +697,7 @@
- [NetApp](entities/NetApp.md)
- [Netdata](entities/Netdata.md)
- [NicholasCarlini](entities/NicholasCarlini.md)
- [NMPA](entities/NMPA.md)
- [node-exporter](entities/node-exporter.md)
- [Node.js](entities/Node.js.md)
- [nodewarden](entities/nodewarden.md)
@@ -734,6 +737,7 @@
- [Rufus](entities/Rufus.md)
- [RustDesk](entities/RustDesk.md)
- [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md)
- [SAMR](entities/SAMR.md)
- [SankarGopov](entities/SankarGopov.md)
- [shenwei](entities/shenwei.md)
- [Simon-Hoiberg](entities/Simon-Hoiberg.md)
@@ -771,6 +775,7 @@
- [Vinay](entities/Vinay.md)
- [VMware](entities/VMware.md)
- [WildCard](entities/WildCard.md)
- [Xiaohongshu](entities/Xiaohongshu.md)
- [XR-Cockpit-Interaction-Specialist](entities/XR-Cockpit-Interaction-Specialist.md)
- [XR-Immersive-Developer](entities/XR-Immersive-Developer.md)
- [XR-Interface-Architect](entities/XR-Interface-Architect.md)
@@ -785,11 +790,13 @@
- [矿神源](entities/矿神源.md)
- [网件RAX50](entities/网件RAX50.md)
- [苏东坡](entities/苏东坡.md)
- [The Agency](entities/The-Agency.md)
## Concepts
- [14种UML图](concepts/14种UML图.md)
- [7种视觉风格系统](concepts/7种视觉风格系统.md)
- [ABTesting](concepts/ABTesting.md)
- [Architectural-Empathy](concepts/Architectural-Empathy.md)
- [Account-Health-Score](concepts/Account-Health-Score.md)
- [Account-Tiering-Model](concepts/Account-Tiering-Model.md)
- [AccountArchitecture](concepts/AccountArchitecture.md)
@@ -830,6 +837,7 @@
- [Amazon-EKS](concepts/Amazon-EKS.md)
- [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md)
- [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md)
- [Appearance-Anxiety](concepts/Appearance-Anxiety.md)
- [APT-仓库配置](concepts/APT-仓库配置.md)
- [arXiv-API](concepts/arXiv-API.md)
- [Asset-Management](concepts/Asset-Management.md)
@@ -849,6 +857,7 @@
- [BI平台](concepts/BI平台.md)
- [Blocking](concepts/Blocking.md)
- [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md)
- [Blue-Hat-Logo](concepts/Blue-Hat-Logo.md)
- [BOOTSTRAP.md](concepts/BOOTSTRAP.md.md)
- [Brain-Dump](concepts/Brain-Dump.md)
- [Branch-Strategy](concepts/Branch-Strategy.md)
@@ -902,6 +911,7 @@
- [Compaction](concepts/Compaction.md)
- [Competition-Analysis](concepts/Competition-Analysis.md)
- [Compliance-Automation](concepts/Compliance-Automation.md)
- [Compliance-Risk-Matrix](concepts/Compliance-Risk-Matrix.md)
- [Confidence-Score](concepts/Confidence-Score.md)
- [Configuration-Management](concepts/Configuration-Management.md)
- [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md)
@@ -1020,6 +1030,7 @@
- [Handoff-Contract](concepts/Handoff-Contract.md)
- [HCX](concepts/HCX.md)
- [Headless-服务器](concepts/Headless-服务器.md)
- [Healthcare-Marketing-Compliance](concepts/Healthcare-Marketing-Compliance.md)
- [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md)
- [Hidden-Failure-Paths](concepts/Hidden-Failure-Paths.md)
- [Hierarchy-Agent-Pattern](concepts/Hierarchy-Agent-Pattern.md)
@@ -1086,6 +1097,7 @@
- [Management-Pack](concepts/Management-Pack.md)
- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md)
- [MEDDPICC](concepts/MEDDPICC.md)
- [Medical-Advertisement-Review](concepts/Medical-Advertisement-Review.md)
- [MeetingNotes](concepts/MeetingNotes.md)
- [Memory-Backend](concepts/Memory-Backend.md)
- [MEMORY.md](concepts/MEMORY.md.md)
@@ -1131,6 +1143,7 @@
- [Partition-Updates](concepts/Partition-Updates.md)
- [Passive-Learning](concepts/Passive-Learning.md)
- [passkey](concepts/passkey.md)
- [Patient-Privacy-PIPL](concepts/Patient-Privacy-PIPL.md)
- [Pay-as-you-go](concepts/Pay-as-you-go.md)
- [Peer-Verification](concepts/Peer-Verification.md)
- [Penetration-Testing](concepts/Penetration-Testing.md)
@@ -1278,6 +1291,7 @@
- [Test-Mode](concepts/Test-Mode.md)
- [Text-and-Search](concepts/Text-and-Search.md)
- [Threat-Modeling](concepts/Threat-Modeling.md)
- [Three-Tier-Review-Mechanism](concepts/Three-Tier-Review-Mechanism.md)
- [ThreeActProposalNarrative](concepts/ThreeActProposalNarrative.md)
- [TieredCampaignArchitecture](concepts/TieredCampaignArchitecture.md)
- [Time-to-Market](concepts/Time-to-Market.md)

9
wiki/log.md
View File

@@ -3029,3 +3029,12 @@
- Concepts created: [[Dengbao-2.0]], [[Miping]], [[Xinchuang]]
- Source page: wiki/sources/government-digital-presales-consultant.md
- Notes: 无已知冲突。Key Entities（Digital China Master Plan、Kunpeng、Phytium、UnionTech UOS、DM Database等）在源文档中属于背景知识，未创建独立Entity页面，通过Source页面Key Entities部分建立wikilinks。Entities页面已添加Dengbao 2.0、Miping、Xinchuang三条概念索引。
## [2026-04-25] ingest | Healthcare Marketing Compliance Specialist
- Source file: Agent/agency-agents/specialized/healthcare-marketing-compliance.md
- Status: ✅ 成功摄入
- Summary: Healthcare Marketing Compliance Specialist——The Agency Specialized 部门的医疗营销合规专家，覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规。核心方法：广告法/医疗广告管理办法/互联网广告管理办法核心法规体系 + 企业内部三级审查机制（法务初审→合规复审→终审发布）+ 合规风险分级矩阵（Critical/High/Medium/Low）+ 违规应急响应（2小时下架→24小时报告→72小时审计）。关键原则：合规不是"堵营销"，而是"保护品牌"。
- Concepts created: [[Healthcare-Marketing-Compliance]]（总框架）、[[Medical-Advertisement-Review]]（医疗广告审查制度）、[[Three-Tier-Review-Mechanism]]（三级审查机制）、[[Blue-Hat-Logo]]（蓝帽子标识）、[[Appearance-Anxiety]]（容貌焦虑红线）、[[Patient-Privacy-PIPL]]（患者隐私合规）、[[Compliance-Risk-Matrix]]（合规风险分级矩阵）
- Entities created: [[NMPA]]（国家药品监督管理局）、[[SAMR]]（国家市场监督管理总局）、[[DXY]]（丁香园）、[[Douyin]]（抖音）、[[Xiaohongshu]]（小红书）
- Source page: wiki/sources/healthcare-marketing-compliance.md
- Notes: index.md 中原有"source missing"条目，本次摄入后已更新为完整条目并修正标题。overview.md Specialized 部门新增 Healthcare Marketing Compliance Specialist 条目。Conflict Areas 新增第11条（与通用法律合规 Agent 的职责边界冲突）。Entities 页面中 Haodf/WeDoctor/JD-Health/WeChat 在源文档中出现频次<2，暂未创建独立页面，通过 Source 页面 Key Entities 部分建立 wikilinks。

7
wiki/overview.md
View File

@@ -687,7 +687,12 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
**[[government-digital-presales-consultant]]**（Government Digital Presales Consultant）：The Agency Specialized 部门的政府数字化售前专家——面向中国ToG（政府）市场，专注于数字政府、智慧城市、一网统管、城市大脑等主流方向的全生命周期售前支持。核心能力：政策解读（数字中国/国家数据局政策信号提取：区分"鼓励探索"与"全面实施"的政策成熟度判断）、合规架构（等保2.0三级/商用密码评估/信创适配）、招投标全流程（需求调研→方案设计→POC验证→标书撰写→述标答辩→中标交接）。五步工作流配合技术方案模板、等保合规矩阵、投标检查清单、机会评估模板等交付物。关键原则：**技术方案必须以业务场景驱动**（"市民服务处理速度提升80%"而非"微服务架构"）；**等保/密评/信创是强制项而非加分项**；方案至少经过三轮迭代打磨。成功指标：中标率>40%、零废标、售前到交付偏差<10%。与 [[sales-engineer]]（通用售前）互补——后者覆盖企业级B2B市场，前者专精中国政府ToG市场特有的政策合规与采购流程；与 [[Digital-Government]]（数字政府）和 [[Smart-City]]（智慧城市）构成完整的政府信息化知识体系。属 The Agency Specialized 部门的垂直行业方向。
**[[healthcare-marketing-compliance]]**（Healthcare Marketing Compliance Specialist）：The Agency Specialized 部门的医疗营销合规专家——覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规，深度熟悉《广告法》《医疗广告管理办法》《互联网广告管理办法》等核心法规体系。核心能力：医疗广告审查（《医疗广告审查证明》申请与合规）、处方药/OTC药广告分规管理、医疗器械三类分级合规（I类备案/II类注册/III类严格审批）、医美"容貌焦虑"红线防控、保健品"蓝帽子"标识管理、互联网诊疗合规（初诊必须线下面诊）、患者隐私 PIPL 合规（敏感个人信息须单独授权）、学术推广合规（医疗代表备案、会议赞助标准、医师讲课费规范）。关键原则：**合规不是"堵营销"，而是"保护品牌"**——一次违规处罚的代价远高于合规投入；**"事前审查"优于"事后补救"**——所有对外发布的医疗营销内容必须经过合规团队审核。成功指标：年度零监管处罚、平台违规 < 3次/年、100% 内容发布前合规审查覆盖率。属 The Agency Specialized 部门的合规垂直方向，与 [[government-digital-presales-consultant]]（政府合规）和 [[legal-compliance-checker]]（通用法律合规）共同构成完整的合规能力体系。
|**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。
**[[cultural-intelligence-strategist]]**（Cultural Intelligence Strategist）：文化包容性专家 Agent——The Agency Specialized 部门的文化智能策略师，专门检测和消除软件开发中的"隐性排斥"（Invisible Exclusion）。核心方法：**四阶段工作流**（盲点审计→自主研究→结构修正→解释原理）。典型案例：刚性 First Name / Last Name 字段在 APAC 市场失效（改为 Full Name 或 Preferred Name）；中国金融应用中红色表示"上涨"而非"错误"（需辅以文字/图标说明）；RTL 阅读方向、多日历系统、不同文化隐私期望等全局包容性设计。核心原则：**国际化是架构前提条件，而非亡羊补牢**；**拒绝表演性多元化**——仅在首页放多元人群图但产品流程本身仍具排斥性不可接受。核心价值：将文化智能（CQ）从"后期本地化补丁"提升为"架构级前提条件"。与 [[InclusiveVisualsSpecialist]]（包容性视觉）互补——前者覆盖整个产品工作流（含表单、交互、颜色语义），后者专注于 AI 生成图像的表征偏见消除；与 [[design-brand-guardian]] 在特定市场语境下存在张力——品牌一致性要求与为不同市场调整视觉语义的必要性需要平衡。
## Conflict Areas
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
@@ -710,6 +715,8 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
10. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。
11. **Healthcare Marketing Compliance vs 通用法律合规**：医疗营销合规 Agent 主张医疗领域具有高度专业化特征（《广告法》/药械注册/平台规则），通用法律合规工具无法覆盖；[[legal-compliance-checker]] 主张合规 Agent 应具备跨行业通用框架，无需细分至医疗领域。**协调方向**：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异（详见 [[healthcare-marketing-compliance]] Contradictions 部分）。
11. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。
12. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。

44
wiki/sources/specialized-cultural-intelligence-strategist.md Normal file
View File

@@ -0,0 +1,44 @@
---
title: "Cultural Intelligence Strategist"
type: source
tags: []
date: 2026-04-20
---
## Source File
- [[Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md]]
## Summary（用中文描述）
- 核心主题：Cultural Intelligence Strategist（文化情报策略师）—— 一个专门负责在软件开发流程中检测和消除"隐性排斥"的 AI Agent。
- 问题域：软件产品中的文化盲点（Western 默认假设、性别选项、命名规范、颜色语义等）导致非西方用户群体的摩擦和排斥。
- 方法/机制：通过"盲点审计 → 自主研究 → 结构修正 → 解释原理"四阶段工作流，在架构层面实现文化包容性设计。
- 结论/价值：将文化智能（Culture Intelligence, CQ）从"后期本地化补丁"提升为"架构级前提条件"，避免产品因隐性排斥而失去全球市场份额。
## Key Claims（用中文描述）
- 刚性 Western 命名结构（强制 First Name / Last Name）会严重阻碍 APAC 等非西方市场用户的注册体验，应改为单一"Full Name"或"Preferred Name"字段。
- 在中国金融场景中，红色表示"上涨/正向"，而非西方语境中的"错误/警告"，财务类应用不应仅依赖红色传达错误状态。
- 表演性多元化（仅在首页加一张多元人群图，但产品流程本身仍具排斥性）不可接受；必须从架构层面消除排斥。
- 国际化（Internationalization）必须作为架构前提条件，而非上线后的亡羊补牢。
## Key Quotes
> "This form design assumes a Western naming structure and will fail for users in our APAC markets." — 文化包容性修正的核心原则表述
> "You are an Architectural Empathy Engine. Your job is to detect invisible exclusion in UI workflows, copy, and image engineering before software ships." — 角色定义
> "Red in Chinese financial contexts indicates positive growth." — 颜色语义冲突的具体案例
## Key Concepts
- [[Invisible Exclusion]]：在 UI 工作流、文案和图像工程中，用户因文化、神经多样性、视觉障碍或非西方时间日历假设而被无意识地排斥。
- [[Cultural Intelligence（CQ）]]：检测和应对文化差异的能力，在软件产品设计中体现为对全球用户多样化需求的敏感度。
- [[Global-First Architecture]]：将国际化作为架构前提条件，而非后期补救措施的设计哲学。
- [[Contextual Semiotics]]：超越语言翻译，审查 UX 颜色选择、图标和隐喻的文化语义。
- [[Architectural Empathy]]：通过结构性解决方案而非表演性行为来实现包容性的设计理念。
- [[Negative-Prompt Library]]：在图像生成中主动禁止有害刻板印象的工具库。
## Key Entities
- [[The Agency]]：该 Agent 所属的 Agent 系统生态。
## Connections
- [[Design Inclusive Visuals Specialist]] ← extends ← [[Cultural Intelligence Strategist]]：两者均涉及多元包容，但前者专注于视觉内容，后者覆盖整个产品工作流。
- [[Design UX Researcher]] ← related_to ← [[Cultural Intelligence Strategist]]：均关注用户研究的包容性维度。
## Contradictions
- 与 [[Design Brand Guardian]]：Brand Guardian 强调品牌一致性，而 Cultural Intelligence Strategist 要求为不同市场调整视觉语义（如中国财务应用的颜色规则）。在特定市场语境下，两者需要在品牌规范层面达成平衡。