1. 从“未标识就下线”说起AIGC内容合规到底在管什么9月16号这条消息在圈子里传得很快核心就一句话AI生成的内容如果没有按规定打上标识平台可以直接做下线处理。很多人第一反应是“又来新规了”但如果你真正在业务一线做AIGC应用会发现这件事的逻辑其实非常清晰——它不是突然冒出来的而是过去两年AIGC从“新鲜玩意”变成“基础设施”之后必然要补上的一环。我先把这件事翻译成人话你用一个AI工具生成了一段文案、一张图、一段视频或者一个数字人播报如果这段内容对外发布时没有明确告诉受众“这是AI生成的”那么一旦被识别出来平台有权把它拿掉。注意这里的关键词是“标识”不是“禁止”。也就是说监管并不是不让你用AI生产内容而是要求你在内容流转的每一个环节把“AI参与”这件事说清楚。这个变化影响的面比很多人想象的要大。它不只管那些专门做AI绘画、AI写作的工具平台还管所有“用了AI能力但没吭声”的产品。比如你做一个电商详情页生成工具底层调了大模型生成出来的文案直接铺到商品页上这算不算需要标识再比如你用AI给短视频配了个音声音是合成的画面是实拍的这算不算还有企业内部的AI知识库问答输出内容只在内部流转要不要标识这些问题在9月16号之后从“可以讨论”变成了“必须回答”。我自己的判断是这次进入执法期意味着两件事同时发生。第一平台侧的审核能力已经跟上来了。以前识别AI内容主要靠水印或者元数据现在很多平台已经能用模型去判断一段文本的“AI概率”准确率虽然做不到百分之百但足够支撑批量筛查。第二合规责任开始向“发布者”和“工具提供方”双向传导。你用了AI你得标你提供AI工具让别人生成内容你也得在输出环节留好标识能力。两边都跑不掉。所以这篇文章我想聊的不是“政策解读”而是从一个实际做AIGC应用的人的角度把这件事拆成可操作的部分标识到底怎么做、C2PA这类技术方案怎么落地、安全评估要评什么、以及在实际工程里最容易踩的坑在哪里。如果你正在做AIGC相关的产品、内容运营或者技术架构这些内容应该能直接拿去对照检查。2. 标识不是加个水印那么简单三层标识体系拆解2.1 显式标识与隐式标识的分工逻辑很多人一听到“标识”第一反应是在图片角落加个“AI生成”的水印或者在文章末尾写一句“本文由AI辅助完成”。这属于显式标识也是最容易被用户感知的一层。但如果你只做这一层在实际合规检查里大概率是不够的。显式标识的作用是“让普通受众知道”它解决的是知情权问题。比如一张AI生成的新闻配图右下角有一个清晰的“AI生成”标签读者一眼就能看到。一段AI合成的语音在播放前有一句“以下内容由AI合成”的提示音。这些都属于显式标识特点是可见、可听、可感知。隐式标识的作用是“让机器能识别”它解决的是溯源和审核问题。比如在文件的元数据里写入生成工具的名称、生成时间、模型版本或者在像素层面嵌入不可见的数字水印。普通用户看不到但平台侧的审核系统可以读出来。这一层才是真正让“未标识就下线”具备可执行性的技术基础。还有第三层我把它叫做关联标识也就是把内容和一个可验证的凭证绑定起来。C2PA就是这一层的典型代表。它不只是说“这是AI生成的”而是说“这段内容由谁在什么时候用什么工具生成之后经过了哪些编辑”。这一层解决的是深度伪造和恶意篡改的问题。三层标识的关系可以这样理解显式标识是给用户看的隐式标识是给平台看的关联标识是给监管和司法看的。只做第一层平台一扫描发现元数据里什么都没有照样判定为未标识。只做第二层用户感知不到投诉照样来。所以实际落地时三层要配合使用。2.2 文本、图片、音视频的标识差异不同模态的内容标识的实现方式差别很大不能一套方案打天下。文本内容的标识最麻烦。你没法在文字里嵌入不可见水印因为文字本身就是离散的字符。常见的做法是在元数据里记录生成信息比如在API返回时附带一个ai_generated: true的字段或者在数据库里单独存一张生成记录表。但问题是文本一旦被复制粘贴到另一个平台元数据就丢了。所以文本的隐式标识更多依赖平台侧的AI检测模型而不是内容本身携带的信息。这也是为什么“降AIGC率”这类需求会存在——有人试图让AI生成的文本看起来像人写的从而绕过检测。但从合规角度说这种做法本身就是在规避标识义务风险很高。图片的标识方案最成熟。显式水印可以直接叠加在画面上隐式水印可以用LSB最低有效位或者频域水印技术嵌入。C2PA对图片的支持也最完善可以在JPEG、PNG、WebP等格式里写入签名信息。实际工程里我建议图片至少做两层一层可见的角落标签一层不可见的元数据签名。如果图片要对外发布再额外生成一个C2PA凭证。音视频的标识介于两者之间。音频可以嵌入不可听的频段水印视频可以逐帧嵌入或者用整体元数据。但音视频的挑战在于转码和剪辑。一段带水印的视频经过平台二次压缩、裁剪、拼接之后水印很可能被破坏。所以音视频的标识策略要更偏向“发布时声明”而不是“内容内嵌”。比如在视频开头加一个持续两秒的“AI生成”提示画面同时在描述字段里写明生成工具。2.3 标识的粒度整段标还是逐段标这个问题在实际产品设计里经常被忽略。一篇长文如果只有开头一段是AI写的后面都是人工写的你怎么标一张图如果背景是AI生成的主体是实拍的你怎么标我的经验是按最小可独立传播单元来标。什么意思如果一段内容可能被单独截取出来传播那它就应该有自己的标识。比如一篇公众号文章如果AI只参与了标题生成那标题旁边就应该有提示如果整篇都是AI生成的那文章开头或结尾要有整体声明。再比如一张海报如果AI只生成了背景图那背景图作为一个独立图层应该有元数据标识但最终合成后的海报是否要加显式标签取决于AI参与的程度。实际操作中我建议采用“分级标识”策略AI参与程度显式标识要求隐式标识要求完全AI生成必须清晰可见必须包含生成工具、时间、模型信息AI辅助生成人工修改超过30%建议标注必须包含生成工具和修改记录AI仅参与润色/校对可不标注建议记录但非强制AI仅用于内部草稿不对外发布可不标内部留存记录即可这个分级不是官方标准是我在实际项目中总结的参考框架。核心逻辑是AI参与越多、内容越可能被独立传播标识要求就越严格。3. C2PA落地实操从原理到工程实现3.1 C2PA到底解决了什么问题C2PA的全称是Coalition for Content Provenance and Authenticity翻译过来就是“内容来源和真实性联盟”。它本质上是一套技术标准用来给数字内容附上一张“身份证”。这张身份证里记录了内容的来源、生成方式、编辑历史而且这些信息是防篡改的。为什么需要它因为传统的元数据太容易被修改了。你用任何一款图片编辑软件都能轻松改掉EXIF信息。但C2PA用的是密码学签名一旦内容被改动签名就会失效验证方立刻就能知道“这个内容被动过”。对于AIGC合规来说C2PA的价值在于它不只是告诉你“这是AI生成的”而是告诉你“这段内容从生成到发布中间经历了什么”。如果一段AI生成的视频被恶意剪辑后用来造谣C2PA凭证可以证明原始版本是什么样、被谁改过。这在执法期里非常关键因为平台和监管需要的不只是“标识”而是“可验证的标识”。3.2 在生成环节嵌入C2PA凭证如果你在做AIGC工具最理想的嵌入点是在内容生成的那一刻。以图片生成为例流程大致是这样的# 伪代码示意实际实现依赖具体C2PA库 from c2pa import Builder, Signer # 1. 初始化签名器使用私钥对凭证签名 signer Signer(private_keyyour_key.pem, cert_chaincert.pem) # 2. 创建builder声明生成信息 builder Builder() builder.add_assertion(c2pa.actions, { actions: [{ action: c2pa.created, softwareAgent: YourAIGCApp/1.0, when: 2024-09-16T10:00:00Z }] }) builder.add_assertion(ai_generation_info, { model: your-model-name, prompt_hash: sha256:..., generation_id: uuid }) # 3. 将凭证嵌入生成的图片 with open(generated.png, rb) as f: image_data f.read() signed_image builder.sign(image_data, signer) with open(output_with_c2pa.png, wb) as f: f.write(signed_image)这段代码的核心逻辑是在图片生成的最后一步把生成信息打包成一个断言assertion用私钥签名后嵌入图片。验证方拿到图片后可以用公钥验证签名读取里面的生成信息。实际工程里要注意几个点。第一私钥管理必须严格一旦泄露别人可以伪造你的凭证。第二签名操作会增加生成延迟图片越大延迟越明显需要做异步处理或者批量签名。第三不是所有图片格式都支持C2PA嵌入JPEG和PNG支持较好WebP和AVIF还在完善中。3.3 发布环节的验证与透传内容生成时嵌入了C2PA不代表发布时就能自动合规。中间还有一道关键工序验证与透传。很多平台在上传图片时会做压缩和转码这个过程很容易把C2PA凭证弄丢。所以如果你是一个内容发布平台需要在接收内容时先读取C2PA凭证验证有效性然后在转码后的版本里重新嵌入。如果原内容没有C2PA凭证平台应该根据自身策略决定是否拒绝发布或者强制添加平台侧的标识。我见过一个典型的坑某团队在生成端做了C2PA但发布端用的是第三方CDNCDN自动做了图片压缩把元数据全删了。结果用户看到的是带C2PA的图平台审核系统读到的却是无标识的图直接触发下线。后来他们的解决方案是在CDN回源时保留原始文件只在最终渲染时做压缩同时把C2PA信息单独存一份在数据库里审核时从数据库读取。这个案例说明C2PA的落地不是单点技术问题而是贯穿生成、存储、传输、发布全链路的一致性问题。任何一个环节断了前面的工作就白做。3.4 没有C2PA时的替代方案C2PA的生态还在完善中不是所有场景都能用。如果你的技术栈暂时不支持C2PA可以考虑以下替代方案平台侧生成记录在数据库里为每一条AI生成内容建立记录包含生成时间、工具、模型、操作人。发布时通过内容ID关联查询。自定义元数据字段在文件元数据里写入约定好的字段比如X-AI-Generated: true、X-AI-Tool: xxx。虽然防篡改能力弱但实现成本低。区块链存证把内容哈希和生成信息写到链上验证时比对哈希。适合对防篡改要求高的场景但性能和成本是瓶颈。数字水印在图片或音频中嵌入不可见水印作为C2PA的补充。水印的鲁棒性取决于算法对抗压缩和裁剪的能力有限。我的建议是如果面向的是国内平台生态优先做平台侧生成记录加自定义元数据因为国内平台审核系统目前主要读的是这些。如果面向国际平台或者对溯源要求高的场景再上C2PA。4. 安全评估与合规检查实际要准备什么4.1 安全评估的触发条件不是所有AIGC应用都需要做安全评估。根据我的经验触发条件通常包括面向公众提供生成式AI服务、生成内容可能影响公众认知、涉及特定行业如新闻、教育、医疗。如果你只是内部用AI做代码辅助或者文档摘要一般不触发。但“未标识就下线”这条执法逻辑触发条件更宽。只要你的内容对外发布并且被平台判定为AI生成且无标识就可能被下线。这跟是否做过安全评估是两件事。安全评估是事前准入标识合规是事中事后监管。4.2 安全评估材料里的AIGC检出率问题最近有个热词叫“软著AIGC率高”说的是申请软件著作权时提交的文档鉴别材料被检测出AI生成比例过高导致需要补正。这其实和内容标识是同一个逻辑的另一面监管和技术系统都在加强对AI生成内容的识别。如果你在准备安全评估或者软著材料我的建议是文档类材料尽量人工撰写或深度改写不要直接复制AI输出。如果确实用了AI辅助保留修改记录和人工审核痕迹。避免使用“降AIGC工具”去刻意规避检测一旦被认定为故意规避性质更严重。材料中的技术描述要具体包含实际参数、架构图、测试数据这些是AI很难凭空生成的。4.3 合规检查清单下面这张表是我在实际项目中用来做自查的你可以直接拿去对照检查项具体要求常见问题显式标识发布内容有可见的AI生成提示提示位置不醒目、字号过小隐式标识元数据或数据库有生成记录转码后丢失、字段不完整生成记录记录工具、模型、时间、操作人记录缺失、无法关联到具体内容用户告知产品界面说明AI使用情况藏在用户协议里、用户无感知投诉渠道提供标识问题的反馈入口入口隐蔽、处理不及时安全评估按要求完成评估并留存材料材料AI率高、技术描述空泛第三方工具确认工具提供方有标识能力工具无标识、责任划分不清这张表看起来简单但每一条在实际落地时都有细节。比如“用户告知”这一条很多产品把AI使用说明放在用户协议第8章第3节用户根本看不到。合规的做法是在用户首次使用AI功能时用弹窗或明显提示告知并且让用户确认。5. 实操中最容易踩的五个坑5.1 坑一以为加了水印就万事大吉我见过一个团队在AI生成的图片右下角加了一个半透明的“AI生成”水印然后就认为合规了。结果平台审核时读取元数据发现没有任何生成信息照样判定为未标识。水印是显式标识元数据是隐式标识两者不能互相替代。正确的做法是显式水印和隐式元数据同时做并且在发布环节验证两者都存在。如果只能做一层优先做隐式元数据因为平台审核系统主要读这个。5.2 坑二转码和压缩把标识弄丢了这是最高频的问题。图片上传时被压缩、视频转码时被重新编码、文档导出时被转换格式这些操作都可能清除元数据。解决方案是在每个可能丢失标识的环节后重新注入标识。具体来说图片上传后服务端读取原始元数据压缩后重新写入。视频转码后在输出文件的元数据里重新嵌入生成信息。文档导出时选择保留元数据的格式和选项。如果技术栈允许最好在数据库里单独存一份生成记录以内容ID为索引。这样即使文件本身的元数据丢了审核时也能从数据库查到。5.3 坑三第三方工具没有标识能力很多团队用的是第三方AIGC工具比如调某个API生成图片或者用某个SaaS平台做视频合成。这些工具的输出往往不带标识或者标识格式不符合你的平台要求。这时候责任在谁从执法逻辑看发布者承担主要责任。也就是说你用了不带标识的工具发布时没补标识被下线的是你。所以选型时一定要确认工具是否支持标识输出。如果不支持你需要在工具输出后自己加一层标识处理。这个成本要在项目初期就算进去不要等到上线了才发现。5.4 坑四标识信息写得太笼统“本内容由AI生成”这句话信息量太低。合规的标识应该包含生成工具名称、生成时间、模型版本如果可披露、是否有真人参与编辑。这些信息越具体审核时越容易通过用户信任度也越高。我建议的标识文案模板是“本内容由[工具名]于[日期]生成[有/无]人工编辑参与。”如果是图片可以在角落放一个可点击的标签点击后展开详细信息。5.5 坑五忽略了内部流转内容的标识很多团队只关注对外发布的内容忽略了内部流转的AI生成内容。比如AI生成的会议纪要、AI写的内部报告、AI做的数据分析。这些内容如果只在内部流转确实不需要显式标识但建议保留生成记录。原因有两个一是内部审计需要二是如果这些内容后来被对外引用追溯起来有依据。我的做法是在内部系统里给AI生成的内容打一个内部标签不对外展示但在导出或分享时如果检测到标签自动提示用户“此内容包含AI生成部分对外发布前请确认标识”。6. 从工程视角看AIGC合规的长期建设6.1 把标识能力做成基础设施如果你的产品线里有多个AIGC功能不要每个功能单独做标识而是把标识能力抽成一个公共服务。这个服务对外提供两个接口一个是“生成时嵌入标识”一个是“发布前验证标识”。所有AIGC功能都调这个服务保证标识格式统一、逻辑一致。这个服务需要包含几个核心模块签名管理私钥、证书、元数据写入支持不同文件格式、数据库记录生成日志、验证接口读取和校验标识。初期投入大概两到三周但后续每个新功能接入只需要一两天。6.2 监控与告警标识合规不是做完就完了需要持续监控。我建议监控几个指标标识嵌入成功率、发布时标识验证通过率、用户投诉中涉及标识问题的比例、平台下线通知的数量。这些指标异常时要有告警及时排查。特别是平台下线通知这是最直接的合规信号。一旦收到要立刻定位是哪个环节的标识丢了是生成时没嵌、传输时丢了、还是发布时没验证。定位后修复并且把案例加入内部检查清单。6.3 与平台审核系统的对接不同平台的审核系统对标识的读取方式不一样。有的读元数据有的读C2PA有的用自己的AI检测模型。如果你的内容要发布到多个平台最好在发布前针对每个平台做一次标识适配。比如面向平台A确保元数据字段符合它的规范面向平台B额外生成一个C2PA凭证。这个适配工作听起来繁琐但可以做成配置化。维护一个平台标识要求表发布时根据目标平台自动选择标识策略。这样新增平台时只需要加一条配置不需要改代码。7. 一些实际问题的快问快答问AI只参与了标题生成正文是人工写的需要标识吗答从合规角度建议在标题附近做轻微提示比如“标题由AI辅助生成”。如果平台审核严格不标可能被判定为未标识。从用户体验角度过度标识也会影响阅读所以提示可以做得轻量一些。问用户用我们的工具生成内容发布时没标识责任在谁答发布者承担主要责任但工具提供方如果明知输出内容会被对外发布却没有提供标识能力也可能被追责。所以工具侧最好默认开启标识并且在使用条款里明确告知用户标识义务。问C2PA凭证被删了怎么办答C2PA凭证被删说明内容被篡改过这本身就是一种风险信号。如果是在你自己的发布流程中被删的检查转码和压缩环节。如果是被第三方删的考虑在数据库留存备份记录。问安全评估要准备哪些材料答通常包括产品说明、技术架构、数据来源、生成内容样例、标识方案、用户告知方式、投诉处理机制。重点是技术描述要具体避免空泛。材料中的文档部分尽量人工撰写降低AIGC检出率。问内部用的AI生成内容需要标识吗答不对外发布的话显式标识不是必须的但建议保留生成记录。如果内部内容可能被导出或对外分享最好在导出时自动添加标识提示。8. 我个人的几条实操建议第一不要等到被下线了才做标识。现在就把生成、存储、发布三个环节的标识能力检查一遍缺哪个补哪个。检查成本很低被下线的成本很高。第二标识方案要简单可执行。我见过太多团队设计了复杂的标识体系结果落地时没人执行。最简单的方案是生成时写数据库发布时读数据库加元数据审核时查数据库。三步搞定不依赖复杂技术。第三把标识当成产品功能而不是合规负担。用户其实很在意内容是不是AI生成的清晰的标识反而能增加信任。我在一些产品里看到加了AI标识之后用户对内容的投诉率反而下降了因为预期更明确。第四关注平台侧的规则变化。不同平台对标识的具体要求不一样有的严有的松。定期检查你的内容在主要平台上的状态收到下线通知立刻处理不要拖。第五保留所有生成和标识记录。执法期里记录就是证据。你能证明自己在生成时嵌入了标识、在发布时验证了标识即使某个环节出了问题也能说明你尽了合规义务。这个领域变化很快今天的要求可能明天就调整。但底层逻辑是不变的AI参与内容生产这件事必须让受众知道必须让系统可验证。把这两件事做好大部分合规问题都能解决。
企业数字化 ERP 产品动态
相关推荐
高性能计算通信库MPI的优化与应用实践 1. 高性能计算通信库的核心价值在超算中心和分布式计算领域,通信性能往往是制约整体效率的关键瓶颈。我曾参与过一个气象预测项目,当计算节点扩展到1024个时,通信耗时竟然占到总计算时间的43%。这个痛点直接催生了各类高性能通信库的诞生&… · 2026/11/2 13:02:59
MySQL增删改查避坑指南:索引失效、事务锁与慢查询排查 做后端开发这些年,我见过太多人把增删改查当成"入门门槛"——背完SELECT、INSERT、UPDATE、DELETE四个关键字,跑通一个带表单的 Demo,就觉得自己会数据库了。真正上了生产环境才发现,同样是这四类语句,有人写… · 2026/11/2 13:02:59
2026年智能化测试平台:核心技术与选型指南 1. 2026年智能化测试平台行业背景与趋势2026年的软件测试领域正在经历一场前所未有的智能化变革。根据Gartner最新报告显示,到2026年全球75%的企业将采用AI驱动的测试工具,测试自动化率预计将达到90%以上。这种变革主要源于三个关键因素:首先… · 2026/11/2 13:02:59
AI驱动测试:智能用例生成与缺陷检测实践 1. AI测试的行业现状与核心挑战软件测试领域正经历从传统手工测试到AI驱动的智能测试的范式转变。根据2023年行业调查报告显示,采用AI技术的测试团队平均缺陷检出率提升47%,测试周期缩短35%。但实现这一转变需要突破三大核心挑战:测试用例生成… · 2026/11/2 20:10:35
汇编循环程序设计核心:SI/DI控制、ZF标志与REP/LOOP指令原理 简介:本资源是面向高校《微机原理与接口技术》课程学习者的经典实验教学材料,聚焦循环程序设计核心能力训练,适用于汇编语言初学者及需强化重复控制指令、串操作指令与重复前缀应用的实践者。内容涵盖验证题(双数据区比对… · 2026/11/2 20:10:35
Xinference容器化部署CUDA版本兼容全解析:从镜像构建到运行时排查 容器化部署推理服务这件事,真正让人头疼的往往不是镜像拉不起来,而是拉起来之后 GPU 认不到、认到了又跑不动、跑起来了精度还飘。Xinference 作为一个把多种推理后端统一封装起来的服务框架,在容器里跑的时候,CUDA 版本这条链路特… · 2026/11/2 20:10:35
微电网低碳调度:改进粒子群算法与碳捕集技术应用 1. 项目背景与核心挑战微电网作为分布式能源系统的重要形态,其经济调度问题一直是能源领域的研究热点。传统调度模型往往只考虑经济性指标,而忽视碳排放约束。随着"双碳"目标的提出,如何在保证供电可靠性的前提下实现低碳运行成为亟… · 2026/11/2 20:10:35
OpenClaw 与 Claw 家族:三十多个 AI Agent 衍生项目全景盘点 1. 从一条命令行说起:OpenClaw 到底是什么第一次在终端里敲下openclaw --version的时候,我其实没抱太大期待。那会儿我已经被各种"AI Agent 框架"轮番轰炸过一轮,从早期的 AutoGPT 到后来的各种编排工具,大多数给我的感… · 2026/11/2 20:10:35
Vue3 组件设计实践:从 props 契约到渲染性能优化 写 Vue3 组件这件事,很多人以为自己已经会了——毕竟从 Options API 迁过来,模板照写,<script setup>一贴,页面能跑起来就算完事。真正让我改变看法的是一次线上事故:一个看似无害的列表组件,因为 pr… · 2026/11/2 20:09:35
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 4:42:45
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 5:17:18
雷达信号调制技术解析:从LFM到伪线性调频原理与应用 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 1:01:15
基于MAX14431与TM4C123的工业SPI隔离电路设计全攻略 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 1:01:15
PLFM_RADAR:相位线性调频雷达信号处理框架 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 1:01:15
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 4:42:45
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 5:17:18