# **IIT Manager Agent 多端角色与微信端开发指�?*

## **1\. 微信端选型分析：为什么必须是企业微信�?*

在临床研究的长周期中，消息触达的可靠性是第一位的�?
| 特�?| 微信订阅�?| 微信服务�?| 企业微信 (WeCom) |
| :---- | :---- | :---- | :---- |
| **消息主动�?* | 极弱（折叠在文件夹） | 中（模板消息有次数限制） | **�?*（可直接发给外部联系�?群） |
| **48小时限制** | �?| 有（用户不互动则无法发信�?| **�?*（只要是外部联系人，随时触达�?|
| **身份属�?* | 媒体/信息�?| 机构/品牌展示 | **专业/职业属�?*（实名认证医生） |
| **PI 适用�?* | 不推�?| 一般（仅用于简单日报） | **推荐**（用于决策确认与紧急通知�?|
| **患者适用�?* | 不推�?| 不推荐（无法长效随访�?| **推荐**（CRC通过企微加患者微信） |

## **2\. 规模化部署下的品牌与归属感方�?*

针对�?00 个项目�?7 家医院”的规模化场景，传统的“一院一授权”不可行。建议采�?**“中央应�?\+ 动态品牌�?* 的架构�?
### **2.1 品牌展示策略 (Branding Strategy)**

1. **企业简称优�?*：申请企业微信认证时，将简称设置为“壹证循临床研究”或“临床研究服务中心”（需配合相关商标或软件著作权证明）�? 
2. **多应用隔�?*：针对不同项目创建不同的“自建应用”�? 
   * 应用 A：名为“北医三院骨质疏松项目�? 
   * 应用 B：名为“北大肿瘤肺癌研究组�? 
3. **消息发送者自定义**：通过企业微信 API，在�?PI 推送消息时，可以将卡片的摘要（Title）动态修改为具体项目组名称�?
### **2.2 小程�?vs 企业微信：深度对�?*

| 维度 | 微信小程�?| 企业微信应用 |
| :---- | :---- | :---- |
| **品牌突出�?* | **极高**（完全独立命名、Logo�?| **�?*（受限于企业主体的后缀�?|
| **通知时效�?* | **�?*（需用户主动订阅，有次数限制�?| **极高**（消息直达聊天列表） |
| **交互深度** | **�?*（复杂的表单、可视化图表�?| **�?*（多为简单的卡片�?H5 链接�?|
| **患者依从�?* | 依赖用户主动打开习惯 | 依赖 CRC 的私域互动（更强�?|

## **3\. 推荐架构：“通知-落地”双轨模�?*

为了平衡“通知及时性”与“医院品牌感”，推荐以下混合方案�?
1. **统一通知中枢 (WeCom)**�? 
   * 使用壹证循统一的企业微信主体�? 
   * 负责所有项目的：访视提醒、质控警报、日报推送�? 
   * 用户感官：收到一条来自“临床研究助理”的消息�? 
2. **多租户品牌落�?(Mini-Program / H5)**�? 
   * PI �?CRC 点击企微消息，跳转到对应项目�?*微信小程�?*�? 
   * 小程序界面顶部显著展示：\[北京大学肿瘤医院\] 及其 Logo�? 
   * 业务逻辑：小程序通过 project\_id 自动渲染对应的品牌元素�?
## **4\. 微信端开发准备清�?(针对 100+ 项目规模)**

1. **资质准备**�? 
   * \[ \] **企业微信代开发模�?*：如果希望未来更灵活，可以申请成为“企业微信服务商”�? 
   * \[ \] **多域名备�?*：准�?1-2 个通用的学术性域名（�?research-support.com）�? 
2. **数据隔离技�?*�? 
   * \[ \] **WeCom-ID 映射�?*：在 iit\_schema 中记�?user\_id 在不同项目应用中�?OpenID�? 
   * \[ \] **消息模板引擎**：支持根据不同项目动态生成卡片文案�?
## **5\. 结论**

* **关于更名**：腾讯不允许无资质的泛指词更名。建议以“公司名+服务中心”作为主体，以“项目组”作为应用名�? 
* **关于小程�?*：小程序不适合作为“第一提醒入口”，但非常适合作为“第一展示窗口”�? 
* **最终建�?*�?*用企业微信推消息，用小程序看报表和填表�?* 这样既解决了 47 家医院的对接难点，又通过小程序给足了 PI 面子�?
**版本**：V3.1 (规模化修正版) | **最后更�?*�?025-12-30