免疫治疗门诊动线优化：Go离散事件仿真（DES）从“常规排队”到“ResusBay挤兑”的技术全解（下）
8. 结果怎么写“技术解读”：从指标到机制
8.1 预配（Pre=true）为什么几乎总是有效？
在仿真里你会看到：
PhW（药房等待）显著下降AvgTot、Over4h通常同步下降
机制解释：
- Pharmacy 作为上游瓶颈，会在串联系统中形成“波峰积压”
- 预配相当于降低该站点平均服务时长与方差（甚至直接近似为 0）
- 串联系统中，上游方差下降会沿链路传导，改善下游拥堵
技术写法：把它描述成“降低瓶颈站点的服务时间与方差，从而降低系统排队时延的尾部”。
8.2 错峰（Staggered）为什么更影响 P90 而不是均值？
机制解释：
- 输注椅是“长服务时长资源”，系统对方差高度敏感
- 当短/长混排时，服务时间方差上升，会造成峰值排队
- 错峰降低方差，让峰值更平滑
- 因此 P90/超时率改善更显著
8.3 ResusBay 为什么是“低均值、高风险”的典型？
这段是本文技术亮点（强烈建议写长一点）：
- Resus 利用率
ResU可能并不高（因为 Severe 概率低） - 但一旦 Resus 忙，
ResW上升 ResW上升会导致 Severe 患者在输注椅“占位等待转运”- 这会抬高
InfW，并把P90Tot与Over4h拉坏 - 结果就是：平均指标看起来没事，尾部指标雪崩
技术术语可以写：这是“稀缺资源导致的耦合拥堵（coupled congestion）”，属于系统性风险而非局部排队问题。
9. 让博客更“硬核”的三类实验
9.1 敏感性分析：Resus 床位容量 1 → 2
改动一行：
s.Resources[Resus]=&Resource{ Cap:2}观察 ResW、InfW、P90Tot、Over4h 的变化。
写作要点：
- 强调这是评估“加床位”的 ROI：收益体现在尾部风险
- 即便
ResU不高，也可能值得增加容量（风险对冲）
9.2 响应流程优化：prep 15~30 → 5~15
把 Severe 分支里的：
prep :=15+ rand*15改成更小，解释为：
- 更快的应急响应
- 更顺畅的院内转运
- 更清晰的 SOP 与物资到位
观察椅位额外占用是否下降（InfW、Over4h 是否改善）。
9.3 风险水平扫描：IrAETotalProb 3% / 6% / 10%
写成“临界点实验”：
- 系统在低风险下平稳
- 达到某个阈值后，队列开始非线性上升（尤其尾部）
这段你可以写成“相变（phase transition）”：队列系统在高负载下出现临界拥堵。
第 10 章 工程化落地：把 DES 仿真从“能跑”做成“可用工具”
前面我们已经有了一个可运行的 Go 离散事件仿真（DES）模型：包含站点队列、资源容量、预约策略、药房预配、irAE 分级、以及 ResusBay 挤兑机制。
但要让它真正支持“运营决策”，还差关键一步：工程化。
工程化的目标不是“写更多代码”，而是让模型具备四种能力：
- 配置化（Config-driven）：不用改代码就能切换参数、策略组合、容量、概率、分布
- 跑批（Batch）：一次跑完几十/几百/几千个策略组合，输出对比表
- 可复现（Reproducible）：固定 seed 得到可重复结果；Monte Carlo 才能做统计置信区间
- 可视化接口（Visualization-ready）：输出 CSV/JSON，让 Python/BI/Excel 直接画图
下面我们按“架构 → 配置 → 并发跑批 → 输出格式 → 可视化数据管道”的顺序展开。
1）项目结构：推荐从单文件升级为可维护模块
把原来的 main.go 拆成：
sim/ model.go // Patient/Station/Resource/Event 数据结构 engine.go // Run(), 事件处理, 队列资源逻辑 report.go // Summarize(), percentile(), 指标定义 config.go // Config 结构体与读取 cmd/ batchrun/ main.go // 解析参数、生成场景、并发跑批、输出文件 好处：
- 仿真引擎稳定后可以复用
- 你可以单测
Summarize()、scheduleArrivals()、onIrAE()等关键逻辑 - 跑批程序和核心引擎解耦，方便 CI/数据管道接入
2）配置化：用 JSON/YAML 描述系统，而不是写死在代码里
2.1 配置文件应该包含哪些字段？
最小可用的配置项建议覆盖：
- 运营时间与日预约量：
day_minutes、n_patients - 资源容量：
cap_signin, cap_lab, cap_doctor, cap_pharmacy, cap_infusion, cap_observation, cap_resus - 策略枚举：
scheduling（Uniform/Staggered）、pharmacy_pre（true/false） - irAE：
enable_irae,irae_total_prob,mild_share,moderate_share - 分布参数：至少允许你替换 mu/sigma 或直接选择“经验分布”（后续扩展）
2.2 示例：config.json
{ "day_minutes":480,"n_patients":120,"resources":{ "signin":2,"lab":2,"doctor":2,"pharmacy":2,"infusion":12,"observation":12,"resus":1},"policy":{ "scheduling":"Staggered","pharmacy_pre":true},"irae":{ "enable":true,"total_prob":0.06,"mild_share":0.60,"moderate_share":0.30},"experiment":{ "replications":100,"base_seed":20260213,"workers":8},"output":{ "out_dir":"./out","write_patient_flow_json":true,"write_timeseries_csv":false}}为什么用 JSON：Go 原生 encoding/json 最省心；如果你想 YAML 也行，但会引入第三方库。3）并发跑批：从“跑一次”到“跑 100×4 场景 + 置信区间”
3.1 关键原则：并发要“可控、可复现、可汇总”
常见坑 😅：
- 多 goroutine 共用一个
rand.Rand：会导致竞态 + 不可复现 - 每次
time.Now().UnixNano()作为 seed：结果不可复现、难 debug - 输出文件并发写：产生文件破坏或乱序
正确做法：
- 设定
base_seed - 为每个 replication 派生唯一 seed：
seed = base_seed + scenarioID*1_000_000 + repID - worker 只负责计算，输出写入由单线程汇总写文件
3.2 代码骨架：Config 结构体 + 读取
// sim/config.gopackage sim import("encoding/json""os")type Config struct{ DayMinutes float64`json:"day_minutes"` NPatients int`json:"n_patients"` Resources struct{ SignIn int`json:"signin"` Lab int`json:"lab"` Doctor int`json:"doctor"` Pharmacy int`json:"pharmacy"` Infusion int`json:"infusion"` Observation int`json:"observation"` Resus int`json:"resus"`}`json:"resources"` Policy struct{ Scheduling string`json:"scheduling"`// "Uniform" or "Staggered" PharmacyPre bool`json:"pharmacy_pre"`}`json:"policy"` IrAE struct{ Enable bool`json:"enable"` TotalProb float64`json:"total_prob"` MildShare float64`json:"mild_share"` ModerateShare float64`json:"moderate_share"`}`json:"irae"` Experiment struct{ Replications int`json:"replications"` BaseSeed int64`json:"base_seed"` Workers int`json:"workers"`}`json:"experiment"` Output struct{ OutDir string`json:"out_dir"` WritePatientFlowJSON bool`json:"write_patient_flow_json"` WriteTimeSeriesCSV boo
