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 + repIDworker 只负责计算，输出写入由单线程汇总写文件3.2 代码骨架：Config 结构体 + 读取// sim/config.gopackagesimimport("encoding/json""os")typeConfigstruct{DayMinutesfloat64`json:"day_minutes"`NPatientsint`json:"n_patients"`Resourcesstruct{SignInint`json:"signin"`Labint`json:"lab"`Doctorint`json:"doctor"`Pharmacyint`json:"pharmacy"`Infusionint`json:"infusion"`Observationint`json:"observation"`Resusint`json:"resus"`}`json:"resources"`Policystruct{Schedulingstring`json:"scheduling"`// "Uniform" or "Staggered"PharmacyPrebool`json:"pharmacy_pre"`}`json:"policy"`IrAEstruct{Enablebool`json:"enable"`TotalProbfloat64`json:"total_prob"`MildSharefloat64`json:"mild_share"`ModerateSharefloat64`json:"moderate_share"`}`json:"irae"`Experimentstruct{Replicationsint`json:"replications"`BaseSeedint64`json:"base_seed"`Workersint`json:"workers"`}`json:"experiment"`Outputstruct{OutDirstring`json:"out_dir"`WritePatientFlowJSONbool`json:"write_patient_flow_json"`WriteTimeSeriesCSVboo