这两年AI编程助手几乎成了嵌入式工程师的标配GitHub Copilot、Claude Code、Cline这些工具写寄存器驱动、补DTS节点、改Makefile确实比从前自己翻手册快得多。但每次有人问我公司固件里躺着AES密钥和产线校准表你敢不敢直接把代码复制给AI我的回答一直很明确敢但不能裸着喂。“裸着喂”就是把包含密钥、寄存器地址、芯片型号、客户名、产品代号的完整工程原封不动复制粘贴到云端大模型。嵌入式代码和互联网后端代码不一样它贴着硬件、绑着密钥、藏着产线秘密。一旦泄出去代价往往不是改个密码就能解决的。所以这两年我在团队里推了一套叫“4道闸”的落地办法。这篇文章就把它完整讲一遍先想清楚嵌入式代码为什么敏感再拆解策略闸、入口闸、出口闸、回流闸分别怎么搭最后用一次STM32采集节点的实际项目复盘整个流程。内容偏工程实践适合正在用AI写嵌入式代码的开发者也适合想在公司内部推AI工具但被安全问题卡住的技术负责人。1. 先想清楚嵌入式代码为什么天生比后端代码更怕泄露1.1 固件可以被dump逆向成本远比想象中低很多后端同学不理解为什么嵌入式团队对“代码出域”这件事这么紧张。核心原因很简单嵌入式代码运行在物理设备上设备一旦到用户手里固件就在攻击者手上了。调试接口可以被锁Flash读保护也有被绕过的手段而且很多设备用的都是通用MCU芯片厂商的参考手册、勘误表、应用笔记全是公开的。攻击者拿到一个bin文件用Ghidra或者IDA打开定位字符串梳理外设基地址基本能还原出整个产品的信息流。如果你的代码再被某个云端AI平台记录下来攻击者连拆机都省了直接拿同样的问题去问大模型“帮我看看这段代码有没有漏洞”“这个加密逻辑怎么绕过”等于你把产品设计图主动递到了对方手里。后端代码藏在服务器内网里前端代码本来就公开这两类代码泄露通常只伤到业务逻辑。嵌入式固件不一样它贴身携带硬件配置、校准参数、安全启动流程泄露之后影响的是整条产品线的信任根基。这也是为什么我始终强调讨论“敏感代码能不能喂给AI”之前得先意识到这不是“某一行代码”的问题而是整个嵌入式产品安全模型的问题。1.2 哪些内容属于“绝对不能裸喂”的一级敏感项我给团队做培训时会把敏感项分成六类。下面是完整清单你可以直接拿去做红线参考敏感类别常见内容泄露后果密钥与证书AES密钥、TLS私钥、固件签名私钥、IoT设备证书设备可被仿冒、固件可被篡改、云端信任体系崩溃硬件板级信息寄存器地址映射、定制外设配置、芯片型号与版本辅助逆向大幅降低产品复制门槛产线与校准数据射频校准表、传感器温度补偿曲线、批次参数产线工艺被偷走维修体系被摸清核心算法与私有协议FOC控制参数、SOC估算模型、自定义通信协议产品核心卖点直接暴露客户与项目信息NDA范围、客户名称、产品代号、认证与报价信息商业信誉受损可能面临合同风险未公开安全设计Secure Boot整体流程、防抄板方案、固件加密方案安全机制被针对性绕过每一类里面最容易出问题的其实是“寄存器地址映射”和“校准数据”。很多工程师觉得寄存器地址反编译就能出来不算核心秘密但问题在于当这些数据和密钥、协议特征、产线参数组合在一起攻击者还原整个系统的成本会指数级下降。单独看每一块都不致命拼在一起就是完整的产品设计图。1.3 分级管控不是禁AI而是按敏感度决定“喂法”面对这么长的敏感清单最省事的做法是一刀切“公司禁止使用AI编程工具。” 但这种方案在实践中根本推行不下去工程师总有办法绕开而且绕开之后更危险——用个人账号、私人电脑去问完全失去管控。我建议的做法是分级管控。把项目代码分成三档S0级完全公开或通用代码例如标准外设驱动模板、Linux设备驱动框架、RTOS API用法、LeetCode式算法题。这类代码用公共AI没有任何问题。S1级普通业务代码不含密钥和核心算法但包含模块名、厂商SDK、内部目录结构、硬件相关配置。这类代码必须经过脱敏处理并且只能进入受管控的AI环境。S2级最敏感代码密钥证书、核心算法、私有协议、客户信息、产线数据。默认禁止出域即使经过脱敏也只在私有化模型环境下使用并且要留审计日志。“敏感代码不能喂给AI”这个说法有点绝对更准确的说法是敏感代码不能裸喂也不能喂给不受管控的AI。四道闸的整套设计本质上就是把“敢不敢用AI”这个问题变成“怎么安全地用AI、怎么有边界地用AI”。2. 第一道闸策略闸把“能不能喂AI”的规矩定死在流程里2.1 红线清单先行6类代码默认禁止出域四道闸里最先要做的是策略闸因为其他三道闸全部依赖一套清晰的规则。没有规则后面所有技术手段都会变成“形式主义”。红线清单怎么定我建议由技术负责人牵头拉上安全、法务花半天时间对照现有产品梳理一遍。不要只让工程师自己判断工程师对“什么是核心资产”的判断往往停留在技术层面容易忽略合同、认证、产线工艺这些间接风险。清单定好后直接写进团队Wiki并且在新人入职当天就讲清楚。清单至少要包含上面六类内容同时补充一条总原则凡是不确定是否敏感的内容一律默认按S2级处理。这条原则特别重要因为大多数泄露都不是恶意的而是“我觉得这段不太敏感”造成的。2.2 用仓库钩子和密钥扫描工具让规矩自动执行策略不能只靠人记必须落到自动化工具里。我在这块做两件事。第一在Git仓库里加入Gitleaks之类的密钥扫描工具刷出所有包含私钥、API Key、Token、密码的历史提交记录然后立刻清理和轮换。这里有个坑要提醒大家清理历史提交不是把文件删了就行必须重写Git历史因为旧commit里还留着敏感内容。除非你已经准备好接受“泄露后重发密钥”的代价。第二给团队配一个针对敏感模式的grep脚本提交前自动扫描。下面是一个粗糙但能跑的版本grep -rEn \ --include*.c --include*.h \ (BEGIN [A-Z ]*PRIVATE KEY|api[_-]?key|secret|password|token) \ src/ | grep -v REDACTED || echo 未发现敏感模式这个脚本只是兜底不能完全替代人工判断。真正的价值在于当提交动作触发告警时工程师会被迫停下来确认这个确认动作本身就是教育过程。提示自动化扫描工具只能扫出“已知模式”扫不出“含义敏感但格式普通的代码”比如一段看起来人畜无害的查表数据实际是产线校准参数。所以策略闸还必须配套人工评审机制。2.3 小团队轻量落地一张表、一个脚本、一个审批人如果你的团队只有几个人或者公司还没上DLP这类数据防泄漏平台别急着搞重型流程先用最轻的三件套跑起来一张表项目代码分级表标注每个模块属于S0/S1/S2哪一档。一个脚本上面那个敏感模式扫描脚本放进Git Hook或CI里。一个审批人S2级代码如果确有脱敏后使用的需求必须由指定技术负责人审批并登记。这套轻量流程我实测下来最大的好处不是“防住了所有泄露”而是让团队对“代码出域是有边界”这件事形成了肌肉记忆。等团队习惯之后再上DLP、API网关这些重型工具阻力会小很多。3. 第二道闸入口闸管住AI工具和算力的接入方式3.1 公共SaaS和私有化部署分开什么代码上云什么代码进内网策略闸定完规则第二道闸要解决“入口”问题。入口指的是AI工具和算力的接入方式这里最大的选择是用公共SaaS服务还是在内网私有化部署模型公共AI助手的特点是模型大、效果好、上手快但代码请求会离开公司网络还可能在服务商侧留存和用于训练。私有化部署的特点是代码不出域、调用可审计但模型效果通常弱于顶级云端模型部署和维护也要花人力。两者不是替代关系而是分工关系维度公共SaaS模型私有化部署模型适合代码S0级公开/通用代码S1、S2级脱敏后的业务代码代码出域是否模型能力强中取决于资源和选型审计能力依赖供应商完全可控部署成本低按账号付费中高需要GPU和运维我推荐的组合是混合模式S0级问题放心用团队统一采购的公共AI账号S1/S2级问题一律走内网私有模型。如果公司暂时没有私有化条件那么S2级宁愿不用AI也不要裸着发到公共平台。3.2 在IDE里接内网模型VSCode Ollama Continue/Cline实操私有化部署没有想象中复杂。以最常见的组合为例在带GPU的内网服务器上装Ollama拉一个开源代码模型然后把VSCode里的AI插件指向这个内网服务。第一步服务器上安装并启动模型ollama pull qwen2.5-coder:7b ollama serve如果团队规模大想统一走OpenAI兼容接口可以用vLLM部署vllm serve Qwen/Qwen2.5-Coder-7B-Instruct --host 0.0.0.0 --port 8000第二步在VSCode里装好Continue或Cline插件把模型Endpoint指向内网地址。以Continue为例配置文件的思路是这样的{ models: [ { title: Local Qwen Coder, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://192.168.1.100:11434 } ] }第三实测一个MCU工程比如问问“这个UART环形缓冲区的并发问题怎么修”确认补全和问答都能走通再推广。这里要提醒一句私有模型的代码能力参差不齐7B级别模型做局部代码补全和简单问答够用但复杂架构设计和长上下文理解会明显吃力。合理预期是“私有模型当优秀的实习生用不当架构师用”。3.3 网络隔离与登录审计堵住“外挂”入口入口闸最容易漏的地方不是IDE配置而是工程师的“外挂通道”。比如代码问题在VSCode里问内网模型没得到满意答案转头复制到个人微信小号里问公共AI或者直接用公司电脑的浏览器打开网页版大模型把同样内容再问一遍。一个S2级问题被问两遍管控就全部失效。我的做法是两条腿走路第一网络层做隔离。核心代码开发环境的网段默认访问不了公共大模型网站只能访问内网模型服务从源头上断掉“外挂”的可能。物理断网不是口号对最敏感的几个模块我甚至建议开发机直接不接外网数据拷贝走审批U盘。第二审计层做记录。所有AI工具的调用统一走网关或日志系统记录谁在什么时间、向哪个模型、提交了什么内容。这不仅是合规追溯的需要更是出问题后复盘的关键线索。没有日志安全事故发生后你连“从哪里泄露的”都说不清楚。4. 第三道闸出口闸喂给AI之前的脱敏处理四板斧4.1 删除密钥、路径、人员信息一个不留出口闸是四道闸里最有技术含量的部分因为脱敏做得好不好直接决定AI回答质量和泄露风险。我总结成四板斧删、换、裁、抽象。第一板斧是删除。不管代码要喂给公共AI还是内网私有模型密钥、证书、Token、员工姓名、内部路径、公司域名全部删干净。具体操作可以用脚本自动扫一遍但一定会有漏网所以删完之后要人工看一眼。grep -rEn \ --include*.c --include*.h \ (BEGIN [A-Z ]*PRIVATE KEY|BEGIN CERTIFICATE|/home/|/workspace/) \ src/ | grep -v REDACTED不要图省事只替换密钥文件里的内容连头文件里声明的静态密钥、固件里编译进去的证书数组都要检查。嵌入式系统一个常见问题就是密钥常以全局数组形式写在C文件里这个习惯本身就很危险更别提把它喂给AI了。4.2 替换寄存器地址、芯片型号、业务命名全部打散第二板斧是替换。这不是什么高深技术就是把这些“一眼能定位到产品”的内容全部改成占位符但要做到位比较难。举个例子从某款MCU的RF驱动里抽出来的代码原始长这样// driver/rf_433.c // Author: Zhang San // Path: /home/zhangsan/work/fw/src/drivers/rf_433.c #define RF_BASE 0x40021000 #define RF_CFG_REG (RF_BASE 0x04) #define RF_DATA_REG (RF_BASE 0x08) void rf_433_send_packet(const uint8_t *data, uint8_t len) { uint32_t temp 0; memcpy(rf_433_tx_buffer, data, len); for (uint8_t i 0; i len; i) { temp (temp 8) | rf_433_tx_buffer[i]; } WRITE_REG(RF_DATA_REG, temp); }脱敏后应该变成这样// 通用发送逻辑寄存器地址与设备型号已替换 #define RF_BASE 0x40000000 #define RF_CFG_REG (RF_BASE 0x04) #define RF_DATA_REG (RF_BASE 0x08) void rf_send_packet(const uint8_t *data, uint8_t len) { uint32_t temp 0; memcpy(tx_buffer, data, len); for (uint8_t i 0; i len; i) { temp (temp 8) | tx_buffer[i]; } WRITE_REG(RF_DATA_REG, temp); }注意不只是地址要换函数名、变量名、注释里的“rf_433”“tx_buffer”这类能联想到具体芯片和协议栈的命名也要换成通用词。为什么因为大模型本身就是一个知识库它看到rf_433结合代码风格很可能自动联想出你用的是哪家芯片、哪个频段、哪种调制方式然后把不相干的信息带进上下文反而干扰回答。4.3 裁剪只给最小问题片段不给整份工程第三板斧是裁剪。很多人喂AI有个误区总觉得给的信息越多回答越准确于是一股脑把整个driver目录或者整份main.c贴进去。实际上大模型对长上下文的注意力是有限的无关代码越多关键问题越容易被淹没回答质量反而下降。裁剪的原则是只留三类内容——函数签名、核心数据结构的字段定义、以及你当前要问的问题描述。比如你想问“这段环形缓冲区代码有没有并发问题”就把插入函数、取出函数、加锁逻辑这几段贴出来别把整个HAL层代码都放进去。这样AI能看到完整的数据流动路径又不会陷进一堆无关细节。这个习惯还有一个额外好处裁剪本身就是在脱敏。你贴出去的内容越少真正需要替换和抽象的敏感信息就越少流程负担也越小。4.4 抽象把核心逻辑翻译成“通用问题”第四板斧是抽象也是最容易被忽略的一步。抽象不是撒谎而是把代码的“业务身份”剥离掉只保留“技术结构”。举例来说“基于扩展卡尔曼滤波的电池SOC估算”可以描述成“嵌入式设备里基于EKF的状态估计器输入为电流电压采样值输出为状态估计值如何处理噪声和协方差矩阵更新”“公司私有协议的解析器”可以描述成“变长帧协议解析器帧头为固定魔数需要处理粘包和半包”。AI需要回答的其实是后面这些通用工程问题根本不需要知道你的业务代号和算法精度参数。配合抽象可以给AI加一段提示词模板说明代码已经脱敏让模型专注在通用嵌入式C规范上以下是一段脱敏后的嵌入式C代码已去掉芯片型号、寄存器物理地址、业务字段名。 请从通用嵌入式C规范和健壮性角度做代码审查 是否存在缓冲区溢出、并发问题、位操作错误、缺少volatile限定、 中断上下文调用阻塞函数等问题请给出具体改进建议。 [代码片段]4.5 出口检查清单提交给AI前的最后确认脱敏做完我建议提交前过一遍检查清单宁可慢一分钟也不要漏一个敏感项。检查项检查方式通过标准密钥、证书、Token脚本扫描 人工确认全部删除或替换为REDACTED内部路径和文件名文本搜索/home/ /workspace/等不存在芯片型号与寄存器地址搜索16进制地址和型号字符串已替换为占位符客户名、产品代号对照项目术语表搜索不存在公司域名和作者名搜索公司域名和姓名拼音不存在核心算法参数对照S2级清单人工确认已抽象为通用描述这个清单刚开始会觉得繁琐习惯之后十分钟内就能过完。我更推荐双人复核制代码的作者做脱敏另一位不直接参与该模块的同事过一遍清单。第一个人容易“看不见自己的键盘印”第二个人往往一眼就能发现漏网。5. 第四道闸回流闸AI生成代码进仓库前的四道审查5.1 AI代码三类风险功能幻觉、安全弱项、合规隐患前面三道闸管的是“喂出去的代码”回流闸管的是“AI送回来的代码”。很多团队前面防得死死的结果AI生成的代码直接合入主干最后在真机上炸了这种案例我见得太多了。AI生成的嵌入式代码风险主要集中在三类。第一类是功能风险也就是AI幻觉。嵌入式领域常见的幻觉包括漏掉外设时钟使能直接操作某个外设寄存器导致总线挂死中断回调里调用阻塞延时把整个系统卡死忘了给共享变量加volatile编译器优化后行为完全不可预测Flash写入前没做擦除操作跑起来就hardfault。这些错误在编译阶段经常不报错但到真机上就会变成非常难查的偶发问题。第二类是安全风险。AI很容易顺着习惯生成memcpy、strcpy、sprintf这类危险函数在资源受限的MCU上一旦边界没算好就是缓冲区溢出。或者生成一个“看起来正常”的随机数实际上用的是固定种子安全机制直接被绕过。第三类是合规风险。大模型的训练数据里包含大量开源代码它生成的内容可能在结构甚至逐行上和某个GPL项目高度相似。把一个GPL片段混进闭源固件开源合规就是一笔糊涂账。这件事在工程上必须处理不能有侥幸心理。5.2 静态检查与CI流水线把基础问题挡在合并前面对这些风险第一步不是靠人眼review而是靠工具。我建议把下面几类检查全部放进CI流水线合入前自动运行编译告警用-Wall -Wextra -Werror把告警直接升级为错误这一步能拦住一批类型不匹配和未使用变量的问题。静态分析Cppcheck配合--enablewarning,style,performance,portability能抓到很多隐藏问题。代码风格clang-format做格式化检查保持仓库风格统一。危险函数扫描全局搜索memcpy|strcpy|sprintf等逐个人工确认边界。一份简化的GitLab CI配置思路stages: - static - build cppcheck: stage: static script: - cppcheck --enablewarning,style,performance,portability --error-exitcode1 src/ - clang-format --dry-run --Werror src/ build: stage: build script: - make -j$(nproc) CROSS_COMPILEarm-none-eabi-需要特别提醒的是嵌入式构建一定不要只在x86主机上编过就算完。交叉编译能用但有些问题只有应对目标架构时才会暴露比如对齐、大小端、位域布局。最好在CI里直接跑QEMU仿真或者在真机上加一道冒烟测试。5.3 License与来源核查警惕GPL污染和专有代码相似工具检查之外还得处理合规问题。AI给出的代码如果涉及第三方依赖、或者疑似大规模复制了某个开源项目需要走下面这套流程第一对新引入的第三方组件做软件成分分析SCA工具可以用Fossology、ScanCode这类开源方案有预算的公司也可以上商业平台。扫描完会生成一份License清单逐项确认当前项目的License策略是否允许。第二对AI生成的大段代码做相似度检查可以把代码片段贴到搜索引擎或者代码搜索平台里比对如果发现和某个开源项目完全一致要谨慎处理。第三如果涉及复杂的License情况直接提交法务确认不要自己拍板。我理解工程师都讨厌合规流程但License问题一旦变成诉讼代价远大于当初那半小时审查。5.4 给AI辅助代码打标识让review走加强流程最后我强烈建议在协作流程里加一个“AI辅助代码标识”。具体做法很轻在PR描述模板里增加一个必填字段——“本PR是否包含AI生成或AI辅助代码是/否”。如果答案是“是”这个PR要走加强review至少两个reviewer其中一个必须熟悉这部分硬件合并前必须在真机或仿真环境跑一遍冒烟测试。为什么这么较真因为AI代码的错误模式和人不一样人犯的错通常还在逻辑框架内AI犯的错经常是“看起来完全合理实际上违背硬件时序”。单人review很容易被AI的自信输出带偏。这个标识还有一个隐藏价值积累一段时间后你可以统计“AI辅助代码的缺陷率”和“AI辅助代码的修改轮次”用数据决定之后是加大AI使用范围还是收缩到特定任务比如只让AI做驱动模板生成、不做核心协议解析。6. 完整实操复盘一个STM32采集节点项目是怎么过四道闸的6.1 项目背景与定级S1级脱敏后可用内网AI前面讲了这么多我拿最近一个实际项目完整走一遍流程你可以对照着看。项目是一个基于STM32的传感器采集节点I2C接口挂温湿度传感器定时唤醒采集数据通过某种低功耗无线方式上报。整个工程不含密钥和核心算法但包含模块命名、厂商SDK、内部目录信息所以定级为S1级脱敏后可以在内网模型中使用。项目启动时我在团队同步了三条规矩所有代码问题只能走VSCode里接入内网模型的插件任何上云请求都要先过脱敏脚本AI生成代码合入前必须过Cppcheck和同事review。这三条就是策略闸在项目里的落地。6.2 现场演示I2C驱动和低功耗逻辑的问与答开发过程中我让一位工程师把I2C初始化和低功耗唤醒这两个模块交给AI处理。操作过程是这样的工程师先把I2C外设初始化结构体里的寄存器基地址全部替换成占位符把厂商SDK的路径、芯片型号全部删掉只保留“I2C主模式初始化”“速率400KHz”这两个关键描述然后向内网模型提问“基于这个脱敏后的I2C初始化代码如何正确配置外部上拉和时序” AI给出的初始版本整体框架是合理的包括结构体填充顺序、速率分频计算思路这在以往要翻两三个小时的参考手册现在十几分钟就有雏形。低功耗唤醒部分工程师只贴了唤醒回调函数和主循环的睡眠等待逻辑抽象成“外部事件唤醒MCU需要快速恢复外设并进入低功耗”“唤醒后外设初始化应该避免哪些阻塞操作”。AI给出的修改建议里有一半可以直接用另一半需要在后续审查里剔除。6.3 回流审查中抓到的问题时钟没使能、延时全阻塞这个项目在回流闸阶段抓到了两个典型问题我觉得比代码本身更有教学价值。第一个问题出在I2C初始化代码。Cppcheck没有报错但review的同事发现AI生成的代码里漏掉了外设时钟使能。它直接操作了I2C外设寄存器却没有先打开GPIO和I2C外设对应的时钟。这个问题在编译阶段不会有任何提示拿到真机上大概率外设无响应而初级工程师通常第一反应是查I2C时序配置而不是时钟。幸好review拦住了。第二个问题出在低功耗唤醒逻辑。AI建议在唤醒中断里加一段“等待外设稳定”的循环延时这个建议本身没错但实现的时候用的是忙等方式也就是阻塞整个CPU。为了处理I2C从机状态而把唤醒延迟拉高白白牺牲低功耗指标。我们把这段改成定时器超时判断加状态机功耗立刻降了0.8mA。整体算下来这个原本预计三天完成的驱动模块实际用了一天半就合入了其中有AI的功劳也有流程的约束在起作用。四道闸不是让项目变慢而是让AI产出可以被信任。7. 常见问题与避坑实录7.1 团队觉得流程太重推不动怎么办这是最常遇到的问题尤其在小团队。我的经验是不要一步到位上重型平台先从“一张分级表 一个脱敏脚本 一个审批人”开始。流程不是目的是让大家形成“代码出域前过一下脑子”的习惯。等你发现脚本扫描已经成为肌肉记忆再逐步加CI检查、加强review阻力会小很多。7.2 本地私有模型的代码能力明显弱于云端大模型私有化部署的模型确实普遍弱于顶级云端SaaS这是需要正面接受的事实。我的应对是混合策略S0级代码和通用算法问题放心用公共AIS1/S2级代码才走内网模型。另外可以对私有模型做一次“知识预热”把常用芯片的SDK文档、单片机参考手册整理成本地知识库用RAG方式给模型做检索增强实测下来对“某某外设如何配置”这类问题的准确率提升非常明显。7.3 脱敏太狠AI反而答非所问脱敏不是把代码改得面目全非那样AI根本看不懂上下文。正确做法是用“语义化占位符”代替真实值比如把真实的寄存器基地址0x40021000换成REG_BASE把传感器型号换成TEMP_SENSOR_I2C_ADDR。保留结构、替换身份AI看到的仍然是一段逻辑完整的代码而不是一堆乱码。7.4 AI偷偷用危险API漏网了怎么办在CI里加一道危险函数扫描把所有memcpy/strcpy/sprintf/gets全部列出来人工过一遍。同时编译开启-fno-builtin这类选项减少编译器自作主张。最终防线还是review重点看数组长度、指针边界和终止符。嵌入式这种环境一次越界就可能破坏栈比服务器端更难恢复。7.5 输出代码疑似和开源专有片段撞车如果AI输出的代码段和某个开源项目逐行相似不要直接提交。先手动重写改变变量命名、调整控制流、重写注释让代码结构符合自己团队风格。如果这段代码来自GPL项目且规模不小最好通过SCA工具确认来源并提交法务判断。AI辅助编程时代“我没注意来源”不算免罪理由。7.6 截图、日志、IPC消息同样会泄露敏感信息很多AI助手支持图片输入这就多了一个泄露通道工程师可能把IDE截图直接发给AI截图里包含芯片型号窗口、调试日志、文件路径、甚至Git分支名。日志里往往写着真实寄存器地址和协议帧内容。我现在的规矩是截图必须打码日志必须脱敏能不发图就不发图能用文字描述绝不用截图。多加一道手少泄一片密。常见问题核心原因推荐对策流程推不动太重、没有真实案例刺激轻量起步用真实泄露案例建立意识本地模型答不准模型小、领域知识不足混合策略S0上云S1/S2走内网配合RAG脱敏后回答变差占位符不语义化、缺少结构信息使用语义化占位符保留函数与数据流结构危险API漏网静态检查覆盖不足CI扫描加人工review重点盯边界与开源代码相似训练数据包含开源片段重写、确认来源、法务介入截图和日志泄露非代码通道没管控截图打码日志脱敏能不发图不发图最后再分享一个小技巧如果你想在团队里推行这套流程先别急着全员铺开挑一个非核心的历史模块做一次“脱敏演练”。把它的寄存器地址、密钥、路径全部按四道闸处理一遍过程录屏讲给大家听。你会发现有人实操一遍比宣讲十页PPT有用得多。等“脱敏处理”变成团队的条件反射AI在嵌入式开发里就是效率神器而不是泄密隐患。