简介面向监狱信息化与智能化监管场景这份《2025年信息化方案监狱信息化建设技术方案单个监狱模板》以单座监狱为落地模板适合系统集成商、安防方案设计人员及监狱信息化项目负责人参考。内容覆盖智能化监管控制、数字化监狱监控、视频监控、报警与周界防备、门禁巡更、接见会见、广播对讲、电化教育、集中管理平台与综合布线等子系统逐项说明设计依据、系统构成、设备选型及功能设计并给出拓扑结构、点位分布和平台联动思路。资源包仅含 1 个 doc 文档约2.82MB便于查阅、摘取与改写为项目方案已有45人学习下载。目录按背景概述、总体设计、具体设计与系统特点分层组织读者可快速搭建方案框架理解多级联网、权限管理、系统集成与应急指挥等要求也可作为投标技术文件与方案评审的参考底稿。1. 单个监狱信息化建设技术方案先算容量再画拓扑拿到「2025年信息化方案监狱信息化建设技术方案单个监狱模板.doc」这类交付物多数人的第一反应是打开绘图工具拉一张拓扑再往框里填交换机型号。我更愿意先把三个数摸清楚关押规模换算出的房间与床位数量、监区到指挥中心的弱电间数量、需要覆盖的室外周界米数。这三个数一出来摄像机点位、门禁与通道点位、会见对讲分机、光纤芯数、机柜数量基本就锁死了后面画的架构图只是给这些数字找一个合理的落点。单个监狱的技术方案与智慧XX这类顶层规划不是一回事。顶层规划可以只谈理念和分层架构单点方案要能直接拿去报价、评审、进场施工所以模板的价值不在辞藻而在参数可算、清单可核、图纸可对。一份能落地的单点方案正文里每一个数字都应该能追溯到图纸、点位表或者一条计算公式凡是根据经验配置的表述评审时都会被追问。这份内容适合售前方案工程师、集成商技术负责人以及第一次独立扛单点标的技术经理。后面按四条线展开目录骨架怎么搭、子系统拆到什么颗粒度、容量参数怎么算、模板怎么做成可复用且可自检的形态。2. 单监狱技术方案的目录骨架与子系统拆分模板要解决的核心问题是每次投标都从零写。一份可复用的骨架应该让不同项目之间只有参数在变章节结构、表格形式、术语口径保持恒定。这样评审专家看到的是熟悉的框架写方案的人只需要替换 YAML 里的数字而不是重新组织语言。2.1 六段式目录骨架让评审一眼看到交付物单个监狱的信息化方案正文控制在六章最合适。章数再少子系统写不透章数再多评审翻到第五章就疲劳了。下面这个骨架是多个单点项目里比较通用的划分页数占比可以按项目规模微调。章节核心内容落到什么颗粒度建议页数占比第一章 项目概述现状、缺口、建设目标量化指标点位/容量/可用小时数10%第二章 总体设计设计原则、逻辑架构、网络分区分区图 对接边界表20%第三章 子系统设计监控、门禁、对讲、周界、报警、广播每个子系统含原理 点位 参数40%第四章 机房与基础设施机柜、供电、桥架、防雷接地平面布置与配电回路10%第五章 工程量清单设备、线缆、辅材、安装调试可报价的行项15%第六章 实施与验收工期、里程碑、验收判据可测量的验收条目5%第三章是全篇的重心40% 的篇幅意味着子系统不能只写采用高清网络摄像机这种话。每个子系统至少给出一张点位分布表加一段参数说明参数里要能看出为什么选这个分辨率、这个码率、这个锁具类型。2.2 子系统拆分把十大系统落到可报价的颗粒度行业习惯把建设内容说成十大系统但十大系统直接搬进清单是报不出价的。我在拆分时按一个系统对应一张点位表、一组设备、一类施工工艺来切视频监控拆成前端点位、传输、存储、显示四块前端再按室内半球、室外枪机、球机、全景、监舍内防拆机型分档门禁与通道拆成门禁控制器、读卡器、电控锁、通道闸、访客登记会见对讲拆成会见窗口分机、家属端话机、录音录像主机周界报警拆成张力或脉冲电子围栏、周界摄像机联动、广播喊话紧急报警拆成监舍求助按钮、民警随身终端、报警主机广播拆成网络功放、分区音箱、消防联动接口机房与网络拆成核心交换、接入交换、光纤链路、机柜配电存储与算力拆成存储阵列、流媒体服务端、智能分析算力业务应用按对接范围列出接口清单运维按质保年限列服务条目。拆分后的每一个末级条目都必须能回答三个问题装在哪、装多少、怎么接线。回答不了的条目说明颗粒度还不够需要继续往下切一层。2.3 占位符与样式约定让 .doc 模板能被脚本渲染模板要能被程序反复使用前提是样式名统一、占位符规范。最省事的做法是先用脚本生成一份标准骨架锁定Heading 1到Heading 4、Normal、Table Grid这几套样式后续所有渲染都只认样式名不认手工加粗。from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() # 样式名必须固定docxtpl 渲染时按样式定位标题层级 h1 doc.styles[Heading 1] h1.font.size Pt(16) h1.font.name 黑体 h1.element.rPr.rFonts.set(qn(w:eastAsia), 黑体) SKELETON [ (Heading 1, 第一章 项目概述与建设目标), (Heading 2, 1.1 现状与信息化缺口), (Heading 2, 1.2 建设目标与量化指标), (Heading 1, 第二章 总体设计), (Heading 2, 2.1 设计原则与技术路线), (Heading 2, 2.2 总体逻辑架构与网络分区), (Heading 2, 2.3 与既有系统的对接边界), (Heading 1, 第三章 子系统设计), (Heading 1, 第四章 机房与基础设施), (Heading 1, 第五章 工程量清单与设备参数), (Heading 1, 第六章 实施计划与验收标准), ] for style, text in SKELETON: doc.add_paragraph(text, stylestyle) doc.save(监狱信息化方案_骨架.docx)这段脚本的关键点有三处。eastAsia字体必须显式设置否则中文字体在部分 Word 版本里会回落到宋体add_paragraph(text, stylestyle)依赖样式已存在如果模板文件是从老版本 .doc 转换而来样式名可能变成标题 1需要先统一重命名骨架里只写标题不写正文正文留给后续的 YAML 数据填充避免脚本和人工编辑互相覆盖。占位符命名建议带子系统前缀例如{{ cam_total }}、{{ door_total }}、{{ storage_tb }}不要用{{ total1 }}这种命名。前缀的好处是当模板里有几十个变量时一眼能看出这个数属于哪个系统YAML 数据源也能按同样的前缀分组。3. 参数表与容量公式把设备清单算准点位数量和容量决定了 80% 的成本也决定了方案能不能通过技术评审。这一章把数点位和算容量的方法固定下来让它变成可以反复套用的公式而不是依赖某个人的经验。3.1 点位表从建筑图纸到点位数量数点位的第一步是拿房间表不是拿效果图。房间表里每一个有独立门禁控制的房间通常意味着一个门禁点位每一条走廊、每一段楼梯口意味着一个监控点位。我一般按下面的顺序推进先按监区划片每个片区内统计监舍数量、功能用房数量、走廊长度、出入口数量再把公共区域指挥中心、会见区、医务区、食堂、操场、周界单独列一张表最后把两张表合并按区域小计避免同一位置重复计数。数点位时有三个容易漏的地方。监舍内部点位要考虑防拆和视角遮挡实际点数通常是床位数的 1/2 到 1不能按每间 1 个简单估。室外周界点位要按直线距离除以单台有效覆盖距离含云台覆盖重叠区计算拐角处必须单独加点位。通道类点位人行通道闸、车行通道要同时算门禁读卡和监控抓拍两套点位只算一套后面一定会补。统计完成后输出一张区域—点位类型—数量的矩阵表这张表是后面所有计算和清单的源头。矩阵表变了设备清单和容量核算必须跟着重算所以它应该放在 YAML 数据源的第一层而不是散在正文段落里。3.2 视频存储与带宽的核算公式存储容量和上行带宽是评审最爱追问的两个数。核算的核心是码率而码率取决于分辨率、编码格式和场景复杂度。下面这张表给出常见配置下单路视频的容量可以直接作为参数依据。分辨率/编码典型主码流单路每小时单路每天100 路留存 30 天1080P / H.2652 Mbps0.88 GB21.1 GB61.8 TB4MP / H.2653 Mbps1.32 GB31.6 GB92.6 TB4MP / H.2645 Mbps2.20 GB52.7 GB154.4 TB8MP / H.2656 Mbps2.64 GB63.3 GB185.4 TB表格里的数按 8 bit 一字节、1 GB 1024 MB 换算实际落地还要乘 RAID 开销系数通常 1.1 到 1.2再预留 10% 热备空间。留存天数按点位重要性分档出入口和通道一般 90 天普通区域 30 天不要全场面统一按 90 天算那会让存储预算翻三倍。带宽核算和存储核算共用码率区别在于并发系数。实时预览的并发路数通常远小于总路数但流媒体服务端的转发带宽要按并发预览 全部录像回传考虑。下面这段脚本把两个数一次算出来。# 单监狱视频存储与带宽核算 BITRATE { # 单位 Mbps主码流典型值 1080p_h265: 2.0, 4mp_h265: 3.0, 4mp_h264: 5.0, 8mp_h265: 6.0, } def storage_tb(channels, days, raid1.1, spare1.1): channels: {机型: 路数}days: 留存天数 mbps sum(qty * BITRATE[k] for k, qty in channels.items()) raw mbps * 3600 * 24 * days / 8 / 1024 / 1024 # Mbps 换算到 TB return round(raw * raid * spare, 1) def uplink_mbps(channels, concurrent0.3, factor1.3): concurrent: 实时预览并发比例factor: 协议与帧头开销余量 mbps sum(qty * BITRATE[k] for k, qty in channels.items()) return round(mbps * (1 concurrent) * factor) ch {1080p_h265: 300, 4mp_h265: 120, 4mp_h264: 30} print(90天存储:, storage_tb(ch, 90), TB) print(30天存储:, storage_tb(ch, 30), TB) print(上行带宽:, uplink_mbps(ch), Mbps)三个函数的参数含义需要说清楚。raid是磁盘阵列的冗余开销RAID5 取 1.1 左右RAID6 或双校验取 1.2spare是预留空间低于 10% 会在接近满盘时出现覆盖异常concurrent是同时被调看的路数占总路数的比例指挥中心大屏通常只调十几路但多个客户端同时操作时会叠加取 0.3 比较稳妥factor覆盖 RTP 头部、I 帧突发和丢包重传带来的额外开销取 1.3 是常见做法。算出来的上行带宽决定核心交换机和流媒体服务端的选型如果结果超过单台千兆口能力的 60%就应该考虑万兆上联或分布式部署。3.3 网络端口、供电与辅材的余量系数设备清单最容易低估的是接入层。PoE 端口的总数不是点位数量而是点位数量乘以余量系数。我一般要求每个接入交换机至少留 20% 空口同时单台 PoE 交换机的总功率预算不低于单口功率 × 实际路数 × 1.3其中单口功率按设备实际功耗取普通枪机 12 W、带云台球机 25 W、带加热的室外机 30 W。如果机柜在室外还要考虑加热模块的额外功耗。辅材的算法不一样它依赖线缆长度而不是点位数。六类线的工程量按平均点位线长 × 1.15 两端各预留 2 m计算平均线长不要拍脑袋要按楼层平面图量取室内一般取 45 到 60 m。光纤按每个弱电间到机房的实际路由长度加上熔接损耗余量芯数按需求芯数 × 2 且不低于 12 芯配置因为主干链路一旦烧纤剩下的备用芯就是恢复时间。桥架和管槽按路由长度乘 1.1 的施工损耗穿墙和转弯处的辅材单列。余量系数写进方案时要给出理由。评审看到留 20% 余量会问为什么答后续扩展太虚答本监狱三年内计划扩容的点位约 XX 个按现有交换机的端口占用率推算就站得住。4. 用 YAML 加 docxtpl 把单个监狱模板渲染成正式方案模板做成脚本可渲染的形态收益在第二单以后才体现。第一单你可能要多花半天配置从第二单开始改参数、换项目名、重算清单、导出文档的流程能压缩到十几分钟而且不会出现改了清单忘了改正文的低级错误。4.1 数据源拆分YAML 存参数docx 存版式原则很简单凡是数字和名称全部放进 YAML凡是标题、段落、表格样式全部留在 docx 模板。不要在两个地方同时维护同一个数字否则一定会不一致。# prison_single.yaml project: prison: 某监狱 name: 2025年信息化建设技术方案 version: V1.2 author: 技术部 summary: zones: 6 # 监区数量 camera_total: 450 door_total: 86 storage_tb: 890.1 points: - {area: 监区走廊, type: 1080P半球, qty: 180, need_poe: true} - {area: 室外周界, type: 4MP球机, qty: 60, need_poe: true} - {area: 指挥中心, type: 8MP枪机, qty: 12, need_poe: true} switches: - {model: 24口PoE, qty: 26, ports: 24, poe: true}YAML 的层级要跟正文章节对得上project对应封面与页眉summary对应第一章的建设目标points对应第三章的点位表switches对应第五章的清单。这样当评审要求补充某个子系统时你知道该改哪一段。4.2 循环渲染点位表与条件片段docxtpl 的用法是在 Word 模板里写 Jinja 语法。表格行的循环需要加tr前缀段落条件加p前缀这两个前缀写错是渲染失败最常见的原因。from docxtpl import DocxTemplate import yaml from datetime import date cfg yaml.safe_load(open(prison_single.yaml, encodingutf-8)) tpl DocxTemplate(监狱信息化方案模板.docx) ctx { project: cfg[project], summary: cfg[summary], points: cfg[points], # 表格行循环数据源 switches: cfg[switches], today: date.today().strftime(%Y年%m月%d日), } tpl.render(ctx) out f监狱信息化建设技术方案_{cfg[project][prison]}_{ctx[today]}.docx tpl.save(out) print(生成:, out)对应的模板写法是在表格第一行的单元格里写{{ p.area }}、{{ p.type }}等字段然后在行首和行尾分别插入{%tr for p in points %}与{%tr endfor %}。条件段落用于按规模切换描述例如{%p if summary.camera_total 400 %}后面接本项目建设规模较大前端点位超过 400 路建议按监区划分子网{%p endif %}收尾。渲染时若报UndefinedError先检查 YAML 里的键名和模板里的变量名是否完全一致大小写和空格都算差异。4.3 目录域、页眉页脚与版本号的自动处理docxtpl 渲染后的文档目录不会自动刷新打印出来可能是空的或者旧页码。有两个处理方式一是打开文档后手动更新域二是让 Word 在打开时提示更新。from docx.oxml.ns import qn # 在 settings.xml 中标记 updateFieldsWord 打开文档时会提示更新目录 settings tpl.get_docx().settings.element uf settings.find(qn(w:updateFields)) if uf is None: uf settings.makeelement(qn(w:updateFields), {}) settings.append(uf) uf.set(qn(w:val), true)版本号和页眉要从project分组里取不要在模板里写死。页眉建议只放项目名称与版本号编制人、日期放在封面这样跨版本对比时页眉差异一眼可见。如果同一批次要出多个监区的方案把prison字段做成参数传入循环调用渲染脚本即可不要复制多份模板文件。5. 交付前的交叉校验与模板迭代技巧方案写完后最容易出的错不是文字问题而是数据不一致点位表写 450 路清单里是 445 路交换机总端口够但 PoE 功率不够线缆长度按旧图纸算新图纸里多了两层楼。这些错误打印出来才会被发现返工成本很高。5.1 三张校验表把不一致挡在打印之前我一般固定做三轮校验每轮只看一个维度避免一次看太多反而漏项。校验项数据来源 A数据来源 B允许偏差前端点位数区域点位矩阵表设备清单前端口数0PoE 端口余量接入交换机端口合计需供电点位数≥ 20%线缆工程量点位 × 平均线长 × 1.15清单线缆米数±5%存储容量码率 × 路数 × 天数 × 系数存储阵列裸容量≥ 0机柜数量设备 U 数合计 ÷ 42U清单机柜数≥ 0偏差为 0 的项说明必须严格相等写成≥的项说明可以有余量但不能缺。存储容量这一项要特别注意方向是存储阵列的可用容量必须大于等于核算结果反过来写会导致容量不足。5.2 用一段自检脚本代替人工对数把校验逻辑写进脚本每次渲染前跑一遍比人工对表可靠。import yaml cfg yaml.safe_load(open(prison_single.yaml, encodingutf-8)) # 校验一点位数与清单前端口数一致 pt sum(p[qty] for p in cfg[points]) # 校验二PoE 端口余量 ports sum(s[ports] for s in cfg[switches] if s.get(poe)) need sum(p[qty] for p in cfg[points] if p.get(need_poe)) print(f点位数 {pt}PoE 需求 {need}可用 {ports}余量 {(ports-need)/need:.1%}) assert ports need * 1.2, PoE 端口余量不足 20%回查接入交换机选型 assert cfg[summary][camera_total] pt, 概述中的摄像机总数与点位表不一致脚本里两个assert是硬门槛失败就中断渲染不生成文档。这种宁可报错也不出稿的策略在赶标书的时候看起来麻烦实际上省掉的是打印后返工的时间。点位类型和编码格式的映射关系也建议放进同一份数据源避免出现点位表写 H.265、清单写 H.264这种跨表冲突。模板迭代上有个小技巧每完成一个单点项目把该项目 YAML 里新出现的字段反哺回模板同时在模板文件里用批注标注该字段对应的图纸或依据。下一单遇到类似规模的监狱直接复制 YAML 改数字即可模板本身不需要动只有出现新的子系统类型时才回模板里增加章节和对应的循环块。这样一来模板的版本号增长只代表能力扩充不代表每次都要重排格式。本文还有配套的精品资源点击获取 单个监狱信息化方案：先算容量再画拓扑，YAML+docxtpl模板化
简介面向监狱信息化与智能化监管场景这份《2025年信息化方案监狱信息化建设技术方案单个监狱模板》以单座监狱为落地模板适合系统集成商、安防方案设计人员及监狱信息化项目负责人参考。内容覆盖智能化监管控制、数字化监狱监控、视频监控、报警与周界防备、门禁巡更、接见会见、广播对讲、电化教育、集中管理平台与综合布线等子系统逐项说明设计依据、系统构成、设备选型及功能设计并给出拓扑结构、点位分布和平台联动思路。资源包仅含 1 个 doc 文档约2.82MB便于查阅、摘取与改写为项目方案已有45人学习下载。目录按背景概述、总体设计、具体设计与系统特点分层组织读者可快速搭建方案框架理解多级联网、权限管理、系统集成与应急指挥等要求也可作为投标技术文件与方案评审的参考底稿。1. 单个监狱信息化建设技术方案先算容量再画拓扑拿到「2025年信息化方案监狱信息化建设技术方案单个监狱模板.doc」这类交付物多数人的第一反应是打开绘图工具拉一张拓扑再往框里填交换机型号。我更愿意先把三个数摸清楚关押规模换算出的房间与床位数量、监区到指挥中心的弱电间数量、需要覆盖的室外周界米数。这三个数一出来摄像机点位、门禁与通道点位、会见对讲分机、光纤芯数、机柜数量基本就锁死了后面画的架构图只是给这些数字找一个合理的落点。单个监狱的技术方案与智慧XX这类顶层规划不是一回事。顶层规划可以只谈理念和分层架构单点方案要能直接拿去报价、评审、进场施工所以模板的价值不在辞藻而在参数可算、清单可核、图纸可对。一份能落地的单点方案正文里每一个数字都应该能追溯到图纸、点位表或者一条计算公式凡是根据经验配置的表述评审时都会被追问。这份内容适合售前方案工程师、集成商技术负责人以及第一次独立扛单点标的技术经理。后面按四条线展开目录骨架怎么搭、子系统拆到什么颗粒度、容量参数怎么算、模板怎么做成可复用且可自检的形态。2. 单监狱技术方案的目录骨架与子系统拆分模板要解决的核心问题是每次投标都从零写。一份可复用的骨架应该让不同项目之间只有参数在变章节结构、表格形式、术语口径保持恒定。这样评审专家看到的是熟悉的框架写方案的人只需要替换 YAML 里的数字而不是重新组织语言。2.1 六段式目录骨架让评审一眼看到交付物单个监狱的信息化方案正文控制在六章最合适。章数再少子系统写不透章数再多评审翻到第五章就疲劳了。下面这个骨架是多个单点项目里比较通用的划分页数占比可以按项目规模微调。章节核心内容落到什么颗粒度建议页数占比第一章 项目概述现状、缺口、建设目标量化指标点位/容量/可用小时数10%第二章 总体设计设计原则、逻辑架构、网络分区分区图 对接边界表20%第三章 子系统设计监控、门禁、对讲、周界、报警、广播每个子系统含原理 点位 参数40%第四章 机房与基础设施机柜、供电、桥架、防雷接地平面布置与配电回路10%第五章 工程量清单设备、线缆、辅材、安装调试可报价的行项15%第六章 实施与验收工期、里程碑、验收判据可测量的验收条目5%第三章是全篇的重心40% 的篇幅意味着子系统不能只写采用高清网络摄像机这种话。每个子系统至少给出一张点位分布表加一段参数说明参数里要能看出为什么选这个分辨率、这个码率、这个锁具类型。2.2 子系统拆分把十大系统落到可报价的颗粒度行业习惯把建设内容说成十大系统但十大系统直接搬进清单是报不出价的。我在拆分时按一个系统对应一张点位表、一组设备、一类施工工艺来切视频监控拆成前端点位、传输、存储、显示四块前端再按室内半球、室外枪机、球机、全景、监舍内防拆机型分档门禁与通道拆成门禁控制器、读卡器、电控锁、通道闸、访客登记会见对讲拆成会见窗口分机、家属端话机、录音录像主机周界报警拆成张力或脉冲电子围栏、周界摄像机联动、广播喊话紧急报警拆成监舍求助按钮、民警随身终端、报警主机广播拆成网络功放、分区音箱、消防联动接口机房与网络拆成核心交换、接入交换、光纤链路、机柜配电存储与算力拆成存储阵列、流媒体服务端、智能分析算力业务应用按对接范围列出接口清单运维按质保年限列服务条目。拆分后的每一个末级条目都必须能回答三个问题装在哪、装多少、怎么接线。回答不了的条目说明颗粒度还不够需要继续往下切一层。2.3 占位符与样式约定让 .doc 模板能被脚本渲染模板要能被程序反复使用前提是样式名统一、占位符规范。最省事的做法是先用脚本生成一份标准骨架锁定Heading 1到Heading 4、Normal、Table Grid这几套样式后续所有渲染都只认样式名不认手工加粗。from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() # 样式名必须固定docxtpl 渲染时按样式定位标题层级 h1 doc.styles[Heading 1] h1.font.size Pt(16) h1.font.name 黑体 h1.element.rPr.rFonts.set(qn(w:eastAsia), 黑体) SKELETON [ (Heading 1, 第一章 项目概述与建设目标), (Heading 2, 1.1 现状与信息化缺口), (Heading 2, 1.2 建设目标与量化指标), (Heading 1, 第二章 总体设计), (Heading 2, 2.1 设计原则与技术路线), (Heading 2, 2.2 总体逻辑架构与网络分区), (Heading 2, 2.3 与既有系统的对接边界), (Heading 1, 第三章 子系统设计), (Heading 1, 第四章 机房与基础设施), (Heading 1, 第五章 工程量清单与设备参数), (Heading 1, 第六章 实施计划与验收标准), ] for style, text in SKELETON: doc.add_paragraph(text, stylestyle) doc.save(监狱信息化方案_骨架.docx)这段脚本的关键点有三处。eastAsia字体必须显式设置否则中文字体在部分 Word 版本里会回落到宋体add_paragraph(text, stylestyle)依赖样式已存在如果模板文件是从老版本 .doc 转换而来样式名可能变成标题 1需要先统一重命名骨架里只写标题不写正文正文留给后续的 YAML 数据填充避免脚本和人工编辑互相覆盖。占位符命名建议带子系统前缀例如{{ cam_total }}、{{ door_total }}、{{ storage_tb }}不要用{{ total1 }}这种命名。前缀的好处是当模板里有几十个变量时一眼能看出这个数属于哪个系统YAML 数据源也能按同样的前缀分组。3. 参数表与容量公式把设备清单算准点位数量和容量决定了 80% 的成本也决定了方案能不能通过技术评审。这一章把数点位和算容量的方法固定下来让它变成可以反复套用的公式而不是依赖某个人的经验。3.1 点位表从建筑图纸到点位数量数点位的第一步是拿房间表不是拿效果图。房间表里每一个有独立门禁控制的房间通常意味着一个门禁点位每一条走廊、每一段楼梯口意味着一个监控点位。我一般按下面的顺序推进先按监区划片每个片区内统计监舍数量、功能用房数量、走廊长度、出入口数量再把公共区域指挥中心、会见区、医务区、食堂、操场、周界单独列一张表最后把两张表合并按区域小计避免同一位置重复计数。数点位时有三个容易漏的地方。监舍内部点位要考虑防拆和视角遮挡实际点数通常是床位数的 1/2 到 1不能按每间 1 个简单估。室外周界点位要按直线距离除以单台有效覆盖距离含云台覆盖重叠区计算拐角处必须单独加点位。通道类点位人行通道闸、车行通道要同时算门禁读卡和监控抓拍两套点位只算一套后面一定会补。统计完成后输出一张区域—点位类型—数量的矩阵表这张表是后面所有计算和清单的源头。矩阵表变了设备清单和容量核算必须跟着重算所以它应该放在 YAML 数据源的第一层而不是散在正文段落里。3.2 视频存储与带宽的核算公式存储容量和上行带宽是评审最爱追问的两个数。核算的核心是码率而码率取决于分辨率、编码格式和场景复杂度。下面这张表给出常见配置下单路视频的容量可以直接作为参数依据。分辨率/编码典型主码流单路每小时单路每天100 路留存 30 天1080P / H.2652 Mbps0.88 GB21.1 GB61.8 TB4MP / H.2653 Mbps1.32 GB31.6 GB92.6 TB4MP / H.2645 Mbps2.20 GB52.7 GB154.4 TB8MP / H.2656 Mbps2.64 GB63.3 GB185.4 TB表格里的数按 8 bit 一字节、1 GB 1024 MB 换算实际落地还要乘 RAID 开销系数通常 1.1 到 1.2再预留 10% 热备空间。留存天数按点位重要性分档出入口和通道一般 90 天普通区域 30 天不要全场面统一按 90 天算那会让存储预算翻三倍。带宽核算和存储核算共用码率区别在于并发系数。实时预览的并发路数通常远小于总路数但流媒体服务端的转发带宽要按并发预览 全部录像回传考虑。下面这段脚本把两个数一次算出来。# 单监狱视频存储与带宽核算 BITRATE { # 单位 Mbps主码流典型值 1080p_h265: 2.0, 4mp_h265: 3.0, 4mp_h264: 5.0, 8mp_h265: 6.0, } def storage_tb(channels, days, raid1.1, spare1.1): channels: {机型: 路数}days: 留存天数 mbps sum(qty * BITRATE[k] for k, qty in channels.items()) raw mbps * 3600 * 24 * days / 8 / 1024 / 1024 # Mbps 换算到 TB return round(raw * raid * spare, 1) def uplink_mbps(channels, concurrent0.3, factor1.3): concurrent: 实时预览并发比例factor: 协议与帧头开销余量 mbps sum(qty * BITRATE[k] for k, qty in channels.items()) return round(mbps * (1 concurrent) * factor) ch {1080p_h265: 300, 4mp_h265: 120, 4mp_h264: 30} print(90天存储:, storage_tb(ch, 90), TB) print(30天存储:, storage_tb(ch, 30), TB) print(上行带宽:, uplink_mbps(ch), Mbps)三个函数的参数含义需要说清楚。raid是磁盘阵列的冗余开销RAID5 取 1.1 左右RAID6 或双校验取 1.2spare是预留空间低于 10% 会在接近满盘时出现覆盖异常concurrent是同时被调看的路数占总路数的比例指挥中心大屏通常只调十几路但多个客户端同时操作时会叠加取 0.3 比较稳妥factor覆盖 RTP 头部、I 帧突发和丢包重传带来的额外开销取 1.3 是常见做法。算出来的上行带宽决定核心交换机和流媒体服务端的选型如果结果超过单台千兆口能力的 60%就应该考虑万兆上联或分布式部署。3.3 网络端口、供电与辅材的余量系数设备清单最容易低估的是接入层。PoE 端口的总数不是点位数量而是点位数量乘以余量系数。我一般要求每个接入交换机至少留 20% 空口同时单台 PoE 交换机的总功率预算不低于单口功率 × 实际路数 × 1.3其中单口功率按设备实际功耗取普通枪机 12 W、带云台球机 25 W、带加热的室外机 30 W。如果机柜在室外还要考虑加热模块的额外功耗。辅材的算法不一样它依赖线缆长度而不是点位数。六类线的工程量按平均点位线长 × 1.15 两端各预留 2 m计算平均线长不要拍脑袋要按楼层平面图量取室内一般取 45 到 60 m。光纤按每个弱电间到机房的实际路由长度加上熔接损耗余量芯数按需求芯数 × 2 且不低于 12 芯配置因为主干链路一旦烧纤剩下的备用芯就是恢复时间。桥架和管槽按路由长度乘 1.1 的施工损耗穿墙和转弯处的辅材单列。余量系数写进方案时要给出理由。评审看到留 20% 余量会问为什么答后续扩展太虚答本监狱三年内计划扩容的点位约 XX 个按现有交换机的端口占用率推算就站得住。4. 用 YAML 加 docxtpl 把单个监狱模板渲染成正式方案模板做成脚本可渲染的形态收益在第二单以后才体现。第一单你可能要多花半天配置从第二单开始改参数、换项目名、重算清单、导出文档的流程能压缩到十几分钟而且不会出现改了清单忘了改正文的低级错误。4.1 数据源拆分YAML 存参数docx 存版式原则很简单凡是数字和名称全部放进 YAML凡是标题、段落、表格样式全部留在 docx 模板。不要在两个地方同时维护同一个数字否则一定会不一致。# prison_single.yaml project: prison: 某监狱 name: 2025年信息化建设技术方案 version: V1.2 author: 技术部 summary: zones: 6 # 监区数量 camera_total: 450 door_total: 86 storage_tb: 890.1 points: - {area: 监区走廊, type: 1080P半球, qty: 180, need_poe: true} - {area: 室外周界, type: 4MP球机, qty: 60, need_poe: true} - {area: 指挥中心, type: 8MP枪机, qty: 12, need_poe: true} switches: - {model: 24口PoE, qty: 26, ports: 24, poe: true}YAML 的层级要跟正文章节对得上project对应封面与页眉summary对应第一章的建设目标points对应第三章的点位表switches对应第五章的清单。这样当评审要求补充某个子系统时你知道该改哪一段。4.2 循环渲染点位表与条件片段docxtpl 的用法是在 Word 模板里写 Jinja 语法。表格行的循环需要加tr前缀段落条件加p前缀这两个前缀写错是渲染失败最常见的原因。from docxtpl import DocxTemplate import yaml from datetime import date cfg yaml.safe_load(open(prison_single.yaml, encodingutf-8)) tpl DocxTemplate(监狱信息化方案模板.docx) ctx { project: cfg[project], summary: cfg[summary], points: cfg[points], # 表格行循环数据源 switches: cfg[switches], today: date.today().strftime(%Y年%m月%d日), } tpl.render(ctx) out f监狱信息化建设技术方案_{cfg[project][prison]}_{ctx[today]}.docx tpl.save(out) print(生成:, out)对应的模板写法是在表格第一行的单元格里写{{ p.area }}、{{ p.type }}等字段然后在行首和行尾分别插入{%tr for p in points %}与{%tr endfor %}。条件段落用于按规模切换描述例如{%p if summary.camera_total 400 %}后面接本项目建设规模较大前端点位超过 400 路建议按监区划分子网{%p endif %}收尾。渲染时若报UndefinedError先检查 YAML 里的键名和模板里的变量名是否完全一致大小写和空格都算差异。4.3 目录域、页眉页脚与版本号的自动处理docxtpl 渲染后的文档目录不会自动刷新打印出来可能是空的或者旧页码。有两个处理方式一是打开文档后手动更新域二是让 Word 在打开时提示更新。from docx.oxml.ns import qn # 在 settings.xml 中标记 updateFieldsWord 打开文档时会提示更新目录 settings tpl.get_docx().settings.element uf settings.find(qn(w:updateFields)) if uf is None: uf settings.makeelement(qn(w:updateFields), {}) settings.append(uf) uf.set(qn(w:val), true)版本号和页眉要从project分组里取不要在模板里写死。页眉建议只放项目名称与版本号编制人、日期放在封面这样跨版本对比时页眉差异一眼可见。如果同一批次要出多个监区的方案把prison字段做成参数传入循环调用渲染脚本即可不要复制多份模板文件。5. 交付前的交叉校验与模板迭代技巧方案写完后最容易出的错不是文字问题而是数据不一致点位表写 450 路清单里是 445 路交换机总端口够但 PoE 功率不够线缆长度按旧图纸算新图纸里多了两层楼。这些错误打印出来才会被发现返工成本很高。5.1 三张校验表把不一致挡在打印之前我一般固定做三轮校验每轮只看一个维度避免一次看太多反而漏项。校验项数据来源 A数据来源 B允许偏差前端点位数区域点位矩阵表设备清单前端口数0PoE 端口余量接入交换机端口合计需供电点位数≥ 20%线缆工程量点位 × 平均线长 × 1.15清单线缆米数±5%存储容量码率 × 路数 × 天数 × 系数存储阵列裸容量≥ 0机柜数量设备 U 数合计 ÷ 42U清单机柜数≥ 0偏差为 0 的项说明必须严格相等写成≥的项说明可以有余量但不能缺。存储容量这一项要特别注意方向是存储阵列的可用容量必须大于等于核算结果反过来写会导致容量不足。5.2 用一段自检脚本代替人工对数把校验逻辑写进脚本每次渲染前跑一遍比人工对表可靠。import yaml cfg yaml.safe_load(open(prison_single.yaml, encodingutf-8)) # 校验一点位数与清单前端口数一致 pt sum(p[qty] for p in cfg[points]) # 校验二PoE 端口余量 ports sum(s[ports] for s in cfg[switches] if s.get(poe)) need sum(p[qty] for p in cfg[points] if p.get(need_poe)) print(f点位数 {pt}PoE 需求 {need}可用 {ports}余量 {(ports-need)/need:.1%}) assert ports need * 1.2, PoE 端口余量不足 20%回查接入交换机选型 assert cfg[summary][camera_total] pt, 概述中的摄像机总数与点位表不一致脚本里两个assert是硬门槛失败就中断渲染不生成文档。这种宁可报错也不出稿的策略在赶标书的时候看起来麻烦实际上省掉的是打印后返工的时间。点位类型和编码格式的映射关系也建议放进同一份数据源避免出现点位表写 H.265、清单写 H.264这种跨表冲突。模板迭代上有个小技巧每完成一个单点项目把该项目 YAML 里新出现的字段反哺回模板同时在模板文件里用批注标注该字段对应的图纸或依据。下一单遇到类似规模的监狱直接复制 YAML 改数字即可模板本身不需要动只有出现新的子系统类型时才回模板里增加章节和对应的循环块。这样一来模板的版本号增长只代表能力扩充不代表每次都要重排格式。本文还有配套的精品资源点击获取