等保测评全流程实战:从定级备案到整改复测的关键要点
做等保测评这行久了会发现一个特别有意思的现象大部分企业用户第一次接触“网络安全等级保护测评”脑子的第一反应往往是“又来一个花钱走流程的事”。尤其在被通知要配合测评的时候IT部门从上到下都是一脸“又要加班整理材料”的表情。但真正扎进去做过两次完整测评之后多数人会对这个工作改观——等保测评本质上是给系统做一次全面“体检”只不过这个体检报告是国家认可的而且指标维度覆盖得比大多数企业内部自查要广得多、细得多。这篇内容主要面向三类读者一是刚接手公司等保工作的运维或安全负责人二是准备给客户做等保整改项目的实施人员三是想要了解等级保护测评到底怎么一回事的合规新人。我会把一次完整测评从定级备案到拿到报告的每个环节拆开讲清楚包括测评机构进场后具体做什么、需要企业配合什么、哪些地方容易翻车、高风险项怎么判定。这些内容都是基于实际测评项目里的常见情况涉及具体测评方法的地方我会尽量说明哪些是通用标准要求哪些是实操中普遍采用的做法。1. 测评启动前定级、备案与测评范围的边界划分1.1 定级不是填个表那么简单很多人以为等保定级就是填一张“定级报告”交上去就完事实际上定级是整个等保工作的地基。定级定错了后面所有测评、整改、备案全是白忙活。等保2.0标准下定级要素调整为“受侵害的客体”和“对客体的侵害程度”信息系统根据业务信息和系统服务被破坏后对国家、社会、公民法人权益的影响范围与程度划分为五个级别一到五级的安全保护能力逐级递增。实际工作中大部分企业系统定在第二级或第三级。二级系统以“指导保护”为主三级系统以“强制保护”为主测评要求也天差地别。我见过不少企业为了省事把明明该定三级的人力资源系统、财务系统硬定成二级结果测评机构进场后按二级要求测完监管侧审核备案材料时直接退回来要求重新定级不仅耽误时间整改成本反而更高。反过来也有企业把内部OA定成三级等于给自己上了一个远超实际需求的紧箍咒每一条三级要求都是钱和时间。定级最核心的依据是业务重要性不是系统规模。一个只有几十台服务器的内部业务系统如果它承载的是核心生产数据、涉及大量公民个人信息级别一定低不了。这需要安全负责人、系统管理员和公司管理层坐在一起把业务影响分析做扎实。1.2 备案材料的常见坑定级报告出来之后二级和三级系统需要到属地公安机关办理备案。备案材料一般包括定级报告、备案表、系统拓扑图、系统说明等。这里有个容易踩的坑拓扑图和实际网络环境对不上。很多企业画拓扑图的时候只画了个大概核心交换机、防火墙、服务器区、办公区画个框就完了测评机构进场后按图索骥发现DMZ区实际部署方式和图纸完全是两回事。倒不是企业故意隐瞒很多时候是网络改了好几次拓扑图却没跟着更新。所以备案之前一定要安排网络管理员把现有网络拓扑核对一遍尤其是边界设备、安全设备的串联位置这些会直接影响到后续测评的“安全通信网络”和“安全区域边界”两个测评项的判定。备案通过后公安机关会发备案证明这个证明是后续测评启动的前提。整个周期正常在2周到1个月左右如果材料有问题被退回时间会更长。企业如果对定级拿不准可以在备案前咨询属地公安网安部门或找有经验的测评机构做预沟通比闷头填表靠谱得多。1.3 测评范围怎么划单系统测评还是整体测评测评范围也是启动前必须理清的问题。等保测评是按“单个定级对象”开展的一个单位可能有多个系统分别定级分别测评。但在实际执行中一个系统往往不是一个独立的物理网络它可能和别的系统共用机房、共用交换机、共用运维通道这就引出两个概念单元测评和整体测评。单元测评针对每个具体测评对象如某台服务器、某个安全设备逐项检查整体测评则关注系统整体的安全保护能力是否满足级别要求。简单说测评机构不仅看单台设备配置得对不对还会看整个系统的安全防护链条是否完整、设备之间的策略是否协调。如果安全设备、服务器、应用系统分属不同团队管理测评前最好统一拉一个清单明确每个设备的管理员和责任人否则进场后现场问答环节会出现“这个问题该找谁”的尴尬局面。2. 测评机构进场后从准备到出报告的完整时间线2.1 测评准备阶段方案先行测评机构签订合同后第一步不是背着工具包冲进机房而是先做测评准备。测评准备阶段通常包含收集被测系统的相关资料定级报告、备案证明、网络拓扑、机房情况、主要设备清单、确定测评对象和测评范围、编制测评方案。测评方案是后续所有工作的蓝图里面会明确测哪些设备、用哪些测评方法访谈、文档审查、配置核查、工具测试、抽样的比例和原则、测评时间安排。一个负责任的测评机构会在进场前把测评方案发给企业确认企业这个时候要认真看特别是“测评对象”这一节。按照等保2.0的要求测评对象的选择有明确的抽样规则比如各类服务器按照类别和重要性抽样但抽样比例不是拍脑袋定的有最低数量要求。如果企业觉得某些核心系统现场测评时间不够或者某些老旧设备不希望被工具扫描应该在方案确认阶段提出来协商不要等进场后再扯皮。这一阶段企业要做的事相对轻松主要就是配合提供资料。但资料提供的完整度直接决定后续进度我建议企业固定一个接口人统一对外提交材料避免测评机构今天问A要一个文件、明天问B要一个文件两边都乱。2.2 现场测评高强度沟通与核查现场测评是整个等保测评里最紧张、也最能暴露问题的阶段。时间通常持续1到2周视系统规模和级别而定。三级系统的现场测评一般会安排多名测评师分头行动有的负责管理类要求访谈有的负责技术类要求核查有的负责工具扫描。现场测评的核心方法可以概括为四类访谈和管理员面对面沟通安全管理制度落实、日常运维操作流程、人员安全意识培训等情况。文档审查核对安全管理制度、操作规程、应急预案、运维记录、培训记录等文档是否齐全、是否落地执行。配置核查登录服务器、网络设备、安全设备检查账号权限、口令策略、补丁情况、日志配置、访问控制策略等具体配置项。工具测试使用漏洞扫描工具对主机和web应用进行扫描在授权范围内进行渗透测试。现场测评节奏很快测评师每天要完成大量核查项企业这边最好安排各个系统的管理员随时待命别让测评师在一个设备上等半小时找不到对应负责人。我参与过的一个项目企业管理员特别配合提前把所有设备的账号权限备好、把管理员密码本整理清楚三天时间就完成了原本计划五天的现场工作效率翻倍。2.3 报告编制阶段等待结果与确认问题现场测评结束后测评机构会进入分析与报告编制阶段。这一阶段企业往往会觉得“测评完了就没事了”其实不然。测评师会把现场收集到的信息进行汇总分析逐项判定每个测评项的符合情况然后进行风险分析找出高风险问题形成初步测评结论。按等保2.0的测评结论判定原则测评结论分为“符合”“基本符合”“不符合”三个等级。大多数第一次参加测评的企业拿到的都是“基本符合”因为完全符合的很少见。测评报告编制周期一般在1到2周期间测评机构可能会就某些问题和企业做最后的确认——比如某个设备的配置项现场记录得模棱两可需要补充佐证材料或者渗透测试中发现某个漏洞需要确认是否属实。这里要特别提醒测评报告征求意见稿出来后一定要仔细看“问题描述”和“整改建议”两个部分。这两个部分写得好不好直接决定了后面整改工作的可操作性。如果报告里只写着“存在中危漏洞若干”这种模糊表述务必要求测评机构列出具体的漏洞名称、涉及的IP地址、风险等级不然整改时无从下手。3. 技术测评与管理测评测评师视角下的核查重点3.1 安全物理环境机房巡检不只是看门锁等保2.0把技术要求划分为五个层面安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心。安全物理环境是最基础的一块也是很多企业最容易忽略的一块——因为机房物理安全往往归行政或基础设施团队管和安全团队不在一个部门沟通不畅导致问题频出。物理环境的测评项包括机房位置选择、物理访问控制、防盗窃防破坏、防雷击、防火、防水防潮、防静电、温湿度控制、电力供应、电磁防护。测评师到现场会实际看机房门禁、监控录像、UPS配置、空调运行情况、灭火装置等。这里有个特别多企业踩坑的点机房监控录像存储时长。等保2.0三级要求监控录像保存时间不少于6个月很多机房监控存储只有1到3个月测评时直接扣分。还有机房的防水措施有些机房空调排水管老化漏水或者机房上方就是水管测评师现场评估后会给高风险。物理安全看似不起眼整改起来却最费钱——防水改造、消防改造都不是小工程所以新建机房或租用机房时就要把等保要求考虑进去。3.2 安全通信网络与区域边界流量路径与访问控制策略安全通信网络重点看通信传输的完整性和保密性、网络架构的合理性。测评师会关注网络带宽是否满足业务需求、通信线路是否有冗余、关键网络设备是否部署了入侵检测/防御能力、传输的数据是否进行了加密特别是三级系统要求采用密码技术保证通信过程中数据的保密性。安全区域边界重点看边界防护和访问控制。这里的核心检查对象是防火墙、WAF、IDS/IPS等安全设备。测评师会重点检查防火墙策略是否遵循最小化原则是否存在任何来源到任何端口的全通策略访问控制规则是否细化到端口级别是否有多余的、长期不用的策略未清理边界设备是否部署了入侵防范措施是否有恶意代码防范能力安全设备自身的日志是否开启日志留存时间是否满足要求三级系统日志留存不少于6个月这块最常见的翻车点就是防火墙“策略越堆越多从来不清理”。很多企业的防火墙规则几百上千条其中大量是历史遗留的临时策略测评师配置核查的时候一眼就能看出来。建议在大规模测评前安全团队提前做一次策略梳理把无效策略、过期策略清一遍不是应付测评是运维本来就应该这么干。3.3 安全计算环境主机安全核查的每个细节安全计算环境是测评项最多的部分涉及身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、可信验证、数据完整性保密性等要求覆盖服务器、终端、数据库、中间件、应用系统等所有计算设备。以一台Linux服务器为例测评师配置核查时会看是否开启口令复杂度策略和登录失败锁定功能、是否配置了账户锁定阈值、远程管理是否禁止root直接登录、是否开启了审计日志如syslog、日志是否包含时间戳和源地址、是否存在不必要的服务和端口、是否安装主机入侵检测软件如HIDS、是否安装防恶意代码软件、补丁更新是否及时。Windows服务器和Linux大同小异但更关注是否关闭默认共享、是否设置屏幕保护锁定、密码策略是否通过组策略统一管理、防病毒软件病毒库是否更新到最新。这里要特别提醒一句等保测评的配置核查是可以提前自查的。企业可以在测评进场前用等保自查表把所有服务器的关键配置项过一遍把不合规的提前改掉。这个工作量大但比起测评整改阶段再大动干戈提前自查的成本低得多。3.4 安全管理中心集中管控与审计平台的价值安全管理中心是等保2.0新增的重头戏也是很多企业整改投入最大的部分。三级系统要求建立安全管理中心对安全设备、网络设备、服务器、数据库、应用系统等的运行状态进行集中监测对安全日志进行集中收集、集中分析、集中审计。说得直白点就是要有堡垒机和日志审计平台或者SIEM。没有这两个东西三级系统的安全管理中心要求基本不可能满足。日志审计平台要能收集各类设备和系统的日志并保留6个月以上堡垒机要能对运维操作进行审计做到操作可追溯。很多企业测评前会问能不能用开源的方案替代商业产品如果只是从“能不能过测评”的角度讲只要功能满足要求、日志留存合规技术上是可以的。但运维团队要考虑清楚开源的日志平台和堡垒机部署、维护、二次开发成本谁来扛出了问题有没有人能接这些实际运营问题往往比测评本身更棘手。我个人见过不少企业为了省钱上了开源方案结果半年后因为没人维护直接弃用等保复查又被打回原形。3.5 管理要求测评制度、人员、运维一个都不能少管理要求包括安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理五个方面。这部分测评以访谈和文档审查为主现场感不像技术测评那么强但涉及面极广。测评师一般会重点检查的核心机制包括是否有正式发布的安全管理制度体系包括总体方针、各类安全管理制度、操作规程是否明确了安全主管、安全管理各个方面的负责人和职责人员入职、离岗、安全意识教育和培训是否有记录第三方人员接入是否有审批流程、是否签订保密协议系统建设过程中是否有项目定级、方案评审、测试验收等记录运维管理是否覆盖资产管理、恶意代码防范管理、变更管理、备份与恢复管理、安全事件处置、应急预案管理等管理类测评有一个特点是“重证据”。制度写了但没执行或者执行了但没记录测评师都会判定为不符合。所以平时养成做记录的习惯特别重要——设备巡检有巡检记录、人员进出有审批记录、备份操作有备份日志这些记录既是运维管理的基本功也是等保测评最直接的证据。很多企业不是制度不健全而是“什么都做了但什么都没留下”这种在测评里很吃亏。4. 高风险判定与整改复测决定测评结论的关键战场4.1 高风险判定一个漏洞就可能翻车等保测评中单个测评项不符合不一定导致整体结论降级但存在高风险问题的时候结论基本可以确定不是“符合”了。等保2.0发布配套的高风险判定指引各地测评机构普遍参照执行符合其中任意一条高风险情形的单项结果直接判定为不符合且测评结论不能为“符合”。常见的高风险情形包括列举几个典型场景关键核心设备存在可直接利用的高危漏洞且能被外部利用操作系统或数据库存在默认口令、空口令、弱口令且可远程登录服务器区域与互联网边界无任何访问控制措施相当于裸奔web应用存在SQL注入、文件上传等可直接导致getshell的高危漏洞机房无任何物理访问控制措施外部人员可随意进出数据备份措施缺失关键业务数据无备份或备份不可用高风险判定是测评里最“要命”的一环因为一旦出现高风险问题不仅测评结论不理想公安机关还可能下发整改通知要求限期整改。所以整改阶段首先要把高风险问题清零这是底线中的底线。4.2 整改优先级先解决高风险再谈完善性测评结果出来后企业通常有3到6个月的整改期具体以测评机构或监管要求为准。整改资源永远有限优先级排序建议遵循“高风险优先、等级保护要求优先、投入产出比优先”的原则。第一优先级是扼杀高风险项比如修漏洞、改弱口令、补边界防护第二优先级是解决关键技术层面明显不满足等级保护要求的问题比如日志留存不达标、缺少访问控制策略第三优先级才是管理制度的补充完善和优化提升。很多企业把精力耗在整理制度文档上却放着互联网边界高危漏洞不管这属于典型的抓小放大。整改过程要有闭环意识。不只是把问题改了还要留下整改记录漏洞扫描报告、补丁安装截图、策略调整前后对比、新制度的发布记录。这些记录既是下次测评的“证据”也是安全运营的资产沉淀。4.3 复测策略怎么复测最省时间整改完成后测评机构会安排复测。复测分为两种常见方式全要素复测和针对性问题复测。等保2.0实施后多地监管要求更严格即使整改完成可能仍要求针对所有不符合项重新核查而不仅是看整改后的状态。也就是说不能只在邮件里说“我们改好了”要让测评师看到实打实的证据和当前状态。复测最省时间的策略是整改完成后先自己做一遍验证把我们上面提到的自查表再跑一遍确认所有高风险项和关键不符合项都整改到位了再通知测评机构安排复测。不要抱着“让测评师来帮我验证”的心态复测发现还有问题时间成本和费用成本都会增加。整改完成后测评机构出具最终测评报告。结论是“符合”或“基本符合”的正常运行并持续保持即可结论是“不符合”的则需要重新整改、重新测评。按照网络安全法及配套法规的要求等保三级系统每年测评一次二级系统一般每两年测评一次这是持续性的合规义务不是一次性的项目。5. 企业内部配合等保测评别人踩过的坑照着避5.1 材料清单和工作分工提前整理别临时抱佛脚测评进场前的材料准备是企业配合工作里最基础也最关键的一环。根据我的经验以下材料建议提前整理到位做成一个文件夹按类别归档基础类材料定级报告、备案证明系统总体描述、网络拓扑图、设备清单各类软硬件产品的购置合同和授权证明管理类材料信息安全管理制度汇编包含总体方针、管理制度、操作规程等岗位职责说明书、人员名单安全培训计划、培训记录应急响应预案、应急演练记录运维类材料日常运维巡检记录漏洞扫描报告、整改记录备份策略文档、备份执行记录机房出入登记记录、设备变更记录技术类材料各类设备的主要配置说明、账号权限清单安全设备部署情况说明防火墙策略、安全审计策略等应用系统清单、数据库清单这些材料提前准备好不仅是为了配合测评也是企业自身的资产管理、运维管理基本盘。很多企业测评前临时凑材料东找西找浪费一两天时间有的材料根本找不到、只能补造。与其这样不如在平时就建立文件夹归档机制每次维护操作顺手存一份记录。5.2 高层访谈与现场问答陪测人员的常见失误现场测评时测评师的访谈对象不仅是IT运维人员也包括安全主管、信息化负责人甚至有些涉及安全组织机构建设的访谈要和高层管理人员沟通。企业管理层如果对等保工作不够了解访谈时容易给出前后矛盾的回答。我遇到过一个比较典型的情况测评师在访谈安全管理机构时问道“公司是否成立了网络安全工作领导小组”被访的管理层支支吾吾半天说不清楚后来才知道文件有但领导根本没参与过相关工作。最后这个测评项的符合性被打了折扣。实际上等保工作要求里明确要建立安全管理机构、落实安全责任这些不是测评师临时提问而是企业本来就应该做的合规机制。针对访谈环节建议企业内部可以做一个简短的“迎评小培训”让参与访谈的每个人知道这个项目定的是几级、现行等保2.0的基本要求是什么、本岗位在安全体系里的职责是什么。不需要背标准条文但至少要能把话说清楚别在测评师面前出现“我负责运维安全的事别问我”这种让双方都尴尬的回答。5.3 测评机构的选择与合作别只看报价企业自己不做测评测评必须由具备资质的第三方测评机构开展。测评机构的选择有几个关键指标是否具备网络安全等级测评与检测评估机构服务认证证书、测评师的持证情况、过往类似行业的测评经验、本地化服务能力。特别想强调一句等保测评不要一味图便宜。测评市场价格参差不齐过低的价格往往意味着人员缩水、现场时间压缩、报告质量粗糙。一份质量差的测评报告不仅没办法指导后续整改公安机关检查时也可能提出质疑等于花钱买个麻烦。在和测评机构合作的过程中企业要有“共建”心态。测评不只是乙方检查甲方更是一次双方共同梳理安全建设现状的机会。测评师在行业里见过大量同类系统他们的整改建议往往很有参考价值多聊几句收获远超一份报告本身。5.4 测评结束不是终点持续合规和常态化自查写到这想额外分享一个观察。等保测评结束时很多企业像考完试一样长舒一口气然后该怎样还怎样直到第二年测评前一个月才开始突击整改。这个循环其实非常消耗团队精力而且对安全能力的提升帮助有限。更好的做法是把等保要求拆到日常运维里去。比如把等保三级的基础要求转成内部的安全基线新上线的服务器默认按基线配置把漏洞扫描从“测评前扫一次”变成“每季度扫一次”把日志留存从“为了过检开一下”变成“常态化的安全审计数据”。这样做下来第二年测评前只需要做小范围核查和补充工作量至少减少一半系统安全水平也真的在提升。等保测评不是终点而是安全工作的一个周期检核点。这一点想通了做等保的体验会完全不一样。

相关新闻

CSS架构实战指南:从命名规范到布局体系构建可复用样式

CSS架构实战指南:从命名规范到布局体系构建可复用样式

最近我在重构一个维护了三年的后台管理系统,改一个按钮样式要先全局搜五个文件,新加一个组件还得小心翼翼给class命名,生怕跟哪个全局样式撞车。这个局面的本质不是某个人写代码不认真,而是CSS架构缺位带来的必然结果。写CSS看起来…

2026/10/1 2:23:55 阅读更多 →
软件测试课后题答案别乱用!三步复盘法助你面试通关

软件测试课后题答案别乱用!三步复盘法助你面试通关

先说个真实的场景。我经常在技术社群里看到有人问“黑马程序员《软件测试》第二版的课后题答案有没有”,底下往往是一堆求资源、留邮箱的回复。但说句得罪人的话,多数人拿到答案之后,干的第一件事就是把选择题答案背下来,然后去考…

2026/10/1 2:23:55 阅读更多 →
Visual Studio深度集成R语言与BYOM模型调试工作流

Visual Studio深度集成R语言与BYOM模型调试工作流

1. 项目本质:这不是“又一个AI插件”,而是开发者工作流的底层重构 R语言开发者在Visual Studio里用上AI,这件事听起来像把咖啡机塞进拖拉机驾驶舱——两个本不该交集的系统被强行拼接。但标题里那个“自有模型”(BYOM, Bring You…

2026/10/1 2:23:55 阅读更多 →

最新新闻

电梯监控电动车检测实战:数据、调参与部署避坑指南

电梯监控电动车检测实战:数据、调参与部署避坑指南

简介:面向电梯监控视角下的电动车与自行车识别场景,这份工程资源提供了基于YOLO预训练模型微调的完整解决方案,包含检测与跟踪两种技术路线。检测方式会对每一帧中检测到的目标实例返回标注图像;跟踪方式则在检测基础上进行去重&a…

2026/10/1 3:04:20 阅读更多 →
.NET Core接入微信支付V3服务商模式:从下单到分账退款全攻略

.NET Core接入微信支付V3服务商模式:从下单到分账退款全攻略

简介:这是一份面向.NET Core开发者的微信支付V3服务商模式集成源码,覆盖普通支付、服务商模式支付、回调写回、退款以及分账给个人和子商户等核心链路,适用于电商、SaaS平台及需要二级商户资金分配的项目团队。资源包共696个文件,…

2026/10/1 3:04:20 阅读更多 →
微网多电源容量配置:两阶段鲁棒优化与CCG求解实践

微网多电源容量配置:两阶段鲁棒优化与CCG求解实践

简介:面向微电网与电力系统优化研究者的MATLAB源代码包,聚焦基于两阶段鲁棒优化算法的微网多电源容量配置问题,适合具备一定优化理论基础的学者、工程师用于算法复现与改进。压缩包共426个文件,约91.42MB,主要包含&…

2026/10/1 3:04:20 阅读更多 →
基于Docker和Redis的Scrapy分布式爬虫架构实践

基于Docker和Redis的Scrapy分布式爬虫架构实践

简介:这是一份基于Docker的分布式爬虫服务完整资料包,面向Python与Go技术栈的爬虫开发者,以及计算机相关专业在校学生、教师和企业工程师。资源直接针对多节点爬虫部署、容器化调度与高效抓取场景,既适合毕业设计、课程设计、项目…

2026/10/1 3:04:19 阅读更多 →
微信支付V3工具类封装实践:签名、验签与回调避坑指南

微信支付V3工具类封装实践:签名、验签与回调避坑指南

简介:面向Java开发者的微信支付V3版工具类,针对企业项目中的支付、退款、交易状态查询以及企业打款到个人零钱等高频交易需求,提供了一站式方法封装。压缩包共七个文件,其中五个源码文件承载具体业务逻辑,另有工程描述…

2026/10/1 3:04:19 阅读更多 →
16.RK3588 AI 边缘计算盒子怎么设计?从硬件到交付的要点拆解

16.RK3588 AI 边缘计算盒子怎么设计?从硬件到交付的要点拆解

RK3588 AI 边缘计算盒子怎么设计?从硬件到交付的要点拆解摘要:AI 盒子看起来是"核心板加个壳",真正量产时算力分配、散热、多路视频接入和远程运维每一环都可能翻车。本文按硬件构成、设计要点、交付形态三条线拆解,并附…

2026/10/1 3:03:19 阅读更多 →

日新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 0:00:30 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 0:00:30 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 1:01:17 阅读更多 →

周新闻

如何划分训练/验证集:Spirula Studio五种eval_mode策略详解

如何划分训练/验证集:Spirula Studio五种eval_mode策略详解

如何划分训练/验证集:Spirula Studio五种eval_mode策略详解 【免费下载链接】spirula-studio Cross-vendor 3D Gaussian Splatting trainer - video to splat to mesh, Vulkan or CUDA. 项目地址: https://gitcode.com/GitHub_Trending/sp/spirula-studio Sp…

2026/9/30 13:14:22 阅读更多 →
SEO怎么推广速查手册新手避坑实战指南

SEO怎么推广速查手册新手避坑实战指南

SEO怎么推广速查手册新手避坑实战指南 模板网站太丑不够用?别急着加滤镜,那是治标不治本。很多老板盯着后台流量掉得眼红,却还在纠结首页Banner的圆角是不是3像素。这就像穿着西装去挖土,姿势不对,努力白费。我整理这份 速查手册…

2026/9/30 18:13:06 阅读更多 →
FireRed-OpenStoryline少样本仿写深度解析:AI Agent如何复刻你的独特文案风格与节奏

FireRed-OpenStoryline少样本仿写深度解析:AI Agent如何复刻你的独特文案风格与节奏

FireRed-OpenStoryline少样本仿写深度解析:AI Agent如何复刻你的独特文案风格与节奏 【免费下载链接】FireRed-OpenStoryline FireRed-OpenStoryline is an AI video editing agent that transforms manual editing into intention-driven directing through natural language …

2026/9/30 13:14:49 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 0:00:30 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 0:00:30 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/1 1:01:17 阅读更多 →