企业官网建设流程全解析

1. 现状与争议——AI写代码成了生产力，也成了定时炸弹

过去两年，AI编程工具已经从“玩具”变成了“生产力”。我身边越来越多团队把大量业务代码交给AI来写，从C++的底层逻辑到Python的量化策略，从STM32的FOC驱动到前端的爱心代码特效，AI都能在几秒内吐出一段能跑的代码。但问题也随之而来：AI生成的代码质量参差不齐，安全问题频发，而一旦线上出了事故，责任归属就成了一个烫手山芋。

就在上周，我一个做量化交易的朋友跟我抱怨，他用AI生成了一段Python交易策略代码，跑了一个月都挺稳，结果某天行情波动大，代码里的一个边界条件触发异常，导致策略在关键时刻没有执行止损，账户回撤了十几个点。他气的不是亏钱，而是“这段代码是AI写的，我怎么知道它会在这时候出问题”？更现实的是，他去找AI工具官方，对方说得很清楚：代码生成仅供辅助，使用者自行承担风险。于是这口锅稳稳地落在了他头上。

这个案例很有代表性——AI编程安全不是一个“未来的隐患”，而是“已经发生的事故”。GitHub上大量开源项目已经开始出现AI生成的低质量代码，有些甚至包含明显的安全漏洞。Stack Overflow上的代码片段被AI抓取后重新组合，里面的老漏洞、过时API、不严谨的边界处理，都被原封不动地搬了进来。更离谱的是，一些AI助手会“一本正经地胡说八道”，生成看似合理但实际有逻辑缺陷的算法，尤其是快速排序、Transformer结构这类对顺序和边界敏感的代码，AI经常在细节上翻车。

所以，今天我想认真聊聊AI生成代码的安全问题：AI写的代码到底哪些地方最容易出事？出了问题到底该谁负责？我们能做哪些事来把风险压到最低？这篇文章不是劝退你使用AI编程工具，恰恰相反，我每天自己都在用，但正因为用得多、踩过坑，才更要搞清楚边界在哪里。无论你是用AI辅助写C语言还是Python，是写业务逻辑还是算法模型，这篇内容都值得你花十分钟读完。

2. 风险拆解——AI生成代码最容易翻车的四类场景

2.1 逻辑正确性陷阱：看起来能跑，实际上边界致命

AI生成代码最大的问题不是“跑不起来”，而是“跑起来很美，边界一碰就碎”。我自己实测过很多次，让AI写一个快速排序，它给出的代码在数组长度大于等于2时表现正常，但当数组长度为1或者0时，部分实现会直接越界访问。这样的bug在常规测试中根本发现不了，因为正常入参都是有效数据，只有生产环境出现异常输入时才会爆炸。

边界条件这个坑，在很多领域都有体现。比如STM32的FOC无刷电机控制代码，AI会给出闭环控制的框架，但如果你让它处理“电机堵转”或者“电流采样超限”这种异常工况，它大概率会给出一个简单的报错返回，而不是完整的保护逻辑。而电机控制这种实时系统，一个小数点精度问题就能导致电流过冲烧掉MOS管。

我自己处理过一个真实案例：让AI生成一段C语言的文件读写操作代码，它给出了一个看似完整的实现——打开文件、读取内容、关闭文件都在，但在错误处理分支里，文件打开失败后程序继续执行后续逻辑，导致空指针解引用。这种“失败后继续往下走”的模式，在AI生成代码里出现的频率极高，因为它们训练数据中调试过的代码远远少于“一次成功”的代码。

所以这里给第一条经验：AI生成的代码，第一件事不是看“主路径能不能跑通”，而是看“异常路径处理得对不对”。正规的开发流程里，代码审查的第一关注点就是错误处理，但AI生成代码恰恰最容易在错误处理上偷懒。建议你把AI生成的代码里所有return -1、return None、throw这类异常分支全部标记出来，逐个确认它们的调用侧是否真的处理了这些异常。

2.2 过时API与隐性漏洞：训练数据的时间差是硬伤

AI模型训练的数据是有截止日期的，这意味着它很可能给你推荐一个已经存在CVE漏洞的旧版本API，或者使用一个已经被废弃的库函数。举几个很常见的例子：

• Python里过时的pickle反序列化，在AI生成的“快速加载模型”代码中出现频率极高，但pickle加载不可信数据等于直接执行任意代码，这个坑十年前就被反复强调了，AI却还在犯。
• C/C++里的strcpy、sprintf这类不安全的字符串函数，AI经常不经提示就直接给出，而现代C++已经推荐使用strncpy_s、snprintf这类安全版本。
• JavaScript前端代码中，eval的使用、innerHTML的拼接，AI会为了“简洁”直接采用，完全不考虑XSS注入的风险。

这些问题的根源在于，AI的训练数据包含了大量“能跑”但“不安全”的示例代码，尤其Stack Overflow上的老答案占了相当大的比例。这些示例代码解决的问题是“怎么让程序跑出结果”，而不是“怎么让程序安全地处理不可信输入”。所以AI学的其实是“不安全的正确答案”。

我的建议是：凡是AI生成的代码涉及网络请求、用户输入、文件解析这类外部数据交互，你必须强制自己对eval、pickle、exec、os.system、subprocess这些高危函数做一次全局搜索，把出现的每一个都人工审查一遍。这是一个非常笨但非常有效的办法，我实测下来能拦截90%以上的严重安全问题。

2.3 依赖与供应链风险：AI推荐的pip install可能是个陷阱

这是一个容易被忽视但后果非常严重的风险点。当你问AI“Python量化交易策略代码怎么实现”，它除了给你一段策略代码，往往还会贴心地附上一句“需要安装pandas、numpy、ta-lib等库”。问题在于，AI有时会推荐一些知名度不高但名字跟正规库很像的第三方包，比如把Pillow写成PIL倒还好，但如果你要求“量化交易中的K线绘图”，有些AI会推荐一个冷门的包，而这个包可能是恶意发布者上传的“仿冒包”。

供应链投毒已经是目前开源生态最严重的安全威胁之一，而AI编程工具无形中成了投毒者的“帮凶”——它们会毫不犹豫地把恶意包推荐给开发者，因为训练数据里根本分不清哪些包是官方的、哪些是劫持的。

实操层面，我应该强调一个习惯：AI推荐的每个依赖，都要去PyPI或npm官网确认“这个包名是否真实存在”，并注意查看下载量和发布时间。如果一个核心工具库的下载量只有几百，那基本可以判定要么是私人项目，要么别有用心。另外，对于AI推荐的“为了一个小功能引入一个大库”的方案，我通常直接拒绝——能用标准库解决的，不引入新依赖，这不仅减小攻击面，也让维护更简单。

2.4 安全配置缺失：AI不会主动帮你加固系统

AI生成代码的另一个特征是“功能性优先、安全性后置”。比如让AI写一个Nginx的配置，它通常会给你一个最简配置——监听80端口、server_name填个域名、location /指向某个目录，然后就没了。不会主动帮你加ssl_protocols、add_header X-Frame-Options、client_max_body_size这些安全头，更不用说配置gzip压缩和超时参数了。

更典型的是，我让AI生成过一个Web后端的登录接口示例代码，它给出了一个完整的JWT认证流程：签发Token、校验Token、过期处理都有，但Token的密钥直接写死在代码里——SECRET_KEY = "your-secret-key"。这种写法在真实生产环境等于零防护。你要是拿去上线，攻击者拿到源码就能伪造任意用户的Token。

这类问题的本质是：AI没有“安全意识”，它只会照着“最常见”的写法来完成功能。需要你在它产出的基础上补上安全加固。我对团队的要求是：AI生成的任何对外服务配置，都必须经过“安全配置补充清单”的检查——密钥管理有没有用环境变量或配置中心？有没有开启TLS并配置加密套件？有没有加访问限流？有没有把敏感错误信息返回给客户端？每一项都确认过，才允许合并到主干。

3. 责任归属——出了事，到底谁来背锅？

3.1 法律与合同层面：AI工具不背锅，你也不一定背得动

从法律角度看，目前全球主流AI编程工具的服务条款几乎一致：AI生成的内容仅供参考，不构成任何形式的担保，使用者需自行承担运用结果的全部责任。换句话说，你在IDE里按了Tab键的那一刻，就默认同意了“AI只是工具，你是使用工具的人”这个前提。

这跟“自动驾驶出车祸谁负责”的逻辑类似——自动驾驶的L2/L3级别，系统决策但你负责接管，出事了你不能怪辅助驾驶。AI编程目前也处于“辅助驾驶”阶段，关键是这个辅助不会像人类助手那样给你提醒“这段代码可能有边界问题”，它只会默默地给出代码，你用了就用了，它不会纠正你。

不过责任也不总是完全在开发者身上。如果企业强制要求员工“必须用AI提升编码效率”，但又不提供额外的代码审查和安全测试流程，出了问题让员工个人背锅，这就属于管理层面的责任错配。我见过有公司因为AI生成的代码出事故，把开发者开了，但明眼人都知道，管理层的流程设计就有问题——没有AI代码的安全评审机制，才是根因。

真正的责任分层应该是这样的：AI工具厂商对“生成内容的质量”负瑕疵担保责任，但现实中很难认定；企业管理者对“没有建立AI代码安全流程”负责，但员工没法拿这个去追责；实际编码者对“没有审查和验证就上线的代码”承担直接责任，这是当前唯一明确落地的责任主体。

3.2 工程层面：谁合并的代码，谁负责

对于开发团队来说，比法律更痛苦的是技术债的归属。代码是AI写的，但你合并到了主线，你就要对这次合并负责。哪怕你把上下文跟AI工具和对话记录都截图保存了，在事故复盘的时候，这些材料也只能帮助定位问题，不能减轻你的责任。

我们在实际团队管理中用了一个原则：所有AI生成的代码，必须填写“来源标记”——在PR描述里写明“这段代码由Copilot/ChatGPT生成，已人工审查xx模块，未审查xx模块”。这个标记看起来冗余，但它逼着开发者对自己“是否审查过”这件事做出诚实交代，也方便后续reviewer重点关注。

另一个更实际的问题是：AI生成代码的风格和你手写的风格往往不一致，这会导致后续维护时出错——你看着一段AI写的代码，很难判断它的意图，改起来容易引入新bug。所以我不建议AI生成后直接合入主干，至少你先自己读一遍，重新命名变量、补充注释、调整书写风格，让这段代码先“成为你的代码”，再去谈合并。这样至少在心理上，你愿意为它负责。

3.3 没有背锅侠的时代：把安全责任前置才是解药

这个问题绕了一圈，最后的结论听起来很残酷但很真实：AI写代码出了问题，没有真正的“外部背锅侠”。AI工具厂商躲在服务条款后面，企业流程有自己的惯性，最终落到极端情况就是开发者个人承受后果。与其讨论“谁背锅”，不如把精力放在“怎么让锅不要掉下来”。

把安全责任前置，核心就一件事：AI生成的代码必须经过一套固定的人工审查流程，谁审查谁签字。不是“大致看一眼没问题”，而是按照一份“AI代码审查清单”逐项核对。这个方法我们实践了半年多，AI代码引入的严重事故降低了至少一大半。

4. 实操防御——我给AI代码加的七道审查关

4.1 第一关：面向攻击面的全局搜索

拿到AI生成的代码后，第一件事是用IDE的全局搜索功能过一遍高危函数。不同的语言关注点不一样，下面这个表格是我整理的高危模式清单，你直接照着搜就行：

这一关的核心思路是：不追求“看懂所有代码”，而是先锁定“可能导致严重后果的代码模式”。就像医生不看全身CT，先看几个关键脏器的片子一样。每命中一个关键词，就标记出来人工审查一处。

4.2 第二关：边界条件与异常路径专项检查

这是AI代码翻车率最高的区域。我在看到AI代码时，会强制问自己四个问题：

• 这个函数的输入如果是None/NULL/0/空字符串，会发生什么？
• 如果外部系统的响应超时或返回异常格式，代码能不能优雅降级？
• 循环边界是<=还是<？数组索引会不会越界？
• 异常分支里有没有记录日志？有没有把堆栈信息暴露给用户？

如果这四个问题中任何一个答案不明确，就说明AI的代码你在审查时必须当场改写补全。我见过太多production事故都是因为“正常路径完全正确，异常路径直接炸掉”。一条简单规则：AI生成的代码，入口函数必须加上参数校验，assert或if判断都行，务必把“非法输入”挡在门外，不要让它们流进核心逻辑。

4.3 第三关：最小权限与数据安全审查

AI生成的代码往往假定自己“拥有全部权限”，比如数据库连接使用的账号拥有DBA权限，或者读取配置时不做权限控制。我在审查时会刻意检查：这段代码访问的数据，是不是只用了自己需要的最小集合？数据库连接是否只用了SELECT权限？内部API调用是否带了多余的管理员Token？

最小权限原则在处理AI代码时特别重要，因为AI不区分“能跑”和“应该跑”。一次在审查AI生成的定时任务代码时，我发现它用了root权限去创建目录，而实际上普通用户权限完全够用。这看起来是个小问题，但万一这个任务脚本被注入恶意逻辑，root权限就意味着整个服务器沦陷。

数据安全方面还有个容易踩的坑：AI代码的日志输出。它经常会打印“登录成功”“订单创建完成”这类业务日志，有时还会顺手把用户名或手机号打进去，这在某些行业合规场景下直接违规。审查时留意print、console.log、logger.info里出现的变量，凡是涉及个人敏感信息的，要么脱敏，要么去掉。

4.4 第四关：依赖清单的人工核验

接着前面提到的供应链风险，AI给的依赖清单不能直接pip install -r requirements.txt。我会把AI生成的依赖列表复制到PyPI官网逐一核对，重点看三件事：

• 包名和官方包是否完全一致，注意大小写和下划线，比如requests和Requests在PyPI上是不同的包名。
• 包的最近发布时间和版本迭代频率，长期不更新的包要慎重。
• 包的下载量和已知漏洞，主流包一般都能在公开漏洞库中查到CVE信息。

这个过程听起来繁琐，但熟练之后每次十分钟左右就够。考虑到供应链投毒一旦中招就是灾难级事故，这个时间花得非常值。

4.5 第五关：动态运行验证

代码审查只能发现“看得见的问题”，动态运行能暴露“想不到的问题”。我在本地跑AI生成的代码时，一定会做三件事：

第一，构造异常输入做fuzz测试——把随机字符串、超长字符串、负数、极小数等等喂给关键函数，看程序会不会崩。第二，在测试环境部署一次，模拟高并发或慢网络场景，观察有没有死锁或资源泄漏。第三，打开所有编译警告选项，比如GCC的-Wall -Wextra -Werror或者Python的-W error，AI生成的代码往往能触发一堆警告，把这些警告全部清零后再考虑上线。

说实话，动态验证是AI代码防御体系里最能“说实话”的一环。一个代码审查没发现的内存泄漏，可能在高并发下运行十分钟就暴露无遗。既然AI不能帮你做压力测试，那就自己来。

4.6 第六关：构建与发布环境的完整性校验

代码本身没问题不等于发布链路没问题。AI生成代码还有一种冷门的风险：它可能引导你从非官方渠道获取构建工具或依赖包。比如有些AI会在环境配置的说明里推荐“从网盘下载编译好的OpenCV库”，这种未经校验的二进制文件有被植入后门的可能性。

我的建议是：所有依赖都必须锁定版本号，并用哈希值进行校验。构建环境尽量使用官方源的镜像，不要随便使用“某某博客提供的加速地址”。这些操作虽然和安全测试看起来无关，但供应链安全的核心恰恰是“只信官方来源”。

4.7 第七关：代码签名与合规留痕

如果你的代码要对外发布，尤其涉及Windows下的应用程序，那么“代码签名证书”就不是可选项而是必需品。签名的作用是确保发布的代码确实是“你所写的代码”，没有被第三方篡改过。如果AI生成的代码里包含可执行文件或DLL，你更应该做签名——否则用户下载后可能会被杀毒软件拦截，或者被中间人替换成恶意版本。

现实中我见过团队上线AI生成的工具型软件时，因为没有做签名，用户机器上的安全软件直接报警，导致用户大量流失。这个坑花一笔签名证书的费用就能避免，但很多人不知道重点。选证书时注意选支持SHA-2和SHA-256的现代签名证书，老式只支持SHA-1的证书在2024年之后已经不被主流操作系统信任了。

5. 工具辅助——能把风险扫描自动化的东西

5.1 代码静态扫描工具怎么选

人工审查AI生成代码的同时，千万别忽略自动化扫描工具的价值。静态代码分析工具能很快帮我们定位可疑模式，给人工审查提供线索。我现在常用的组合是：

• Semgrep：开源、正则加语法树双引擎，对Python和Go的扫描效果很好，自定义规则方便，我常用于检查“高危函数黑名单”。
• Bandit：Python专用安全扫描器，专门找常见安全编码问题，比如硬编码密码、不安全的反序列化，虽然不是AI专用，但拿来扫AI生成的Python代码很对症。
• ESLint安全插件：前端代码扫描必装，eslint-plugin-security会标记出eval、innerHTML这些危险用法。
• SonarQube：团队级别的扫描平台，能持续追踪历史代码的安全状态，配合CI/CD流程自动处理，适合把“AI代码安全检查”沉淀为团队规范。

用这些工具的时候，我的经验是：不要寄希望于“零误报”，扫描器永远只能提供“怀疑清单”，最终判定还是得靠人工。但有了它们，你的审查效率至少提升一倍，人工只需要盯着高概率风险区域就够了。

5.2 依赖漏洞检查的必要插件

除了代码本身的静态扫描，依赖层面的漏洞检查同样重要。国内市场也有相关的安全服务，但最容易上手的还是几个国际化的开源方案：

• pip-audit：扫描Python依赖中已知漏洞，直接输出CVE编号，配合pip使用非常方便。
• npm audit：Node.js项目的依赖安全检查，前端项目基本必开。
• OWASP Dependency-Check：跨语言方案的依赖漏洞扫描器，适合统一管理多语言项目。
• Trivy：不仅能扫容器镜像，也能扫文件系统中的依赖，轻量快捷，我在CI流水线里用得最多。

这类工具接入不难，难的是养成“每次合并AI代码前跑一遍”的习惯。我们把依赖检查写进了CI流水线的强制阶段——依赖扫描不过，PR不允许合并。

5.3 大模型体检：用另一个AI来审AI

既然AI写代码，为什么不用AI来审查AI？现在很多工具支持“代码体检”模式，你也可以直接丢给另一个大模型做安全审查。我的做法是：把代码和“为什么这段代码是这样写的”的说明一起提交给审查模型，让它找出安全问题、边界漏洞、逻辑陷阱。这种“AI审AI”的方法不能完全代替人工审查，但能快速揪出一些低级错误和遗漏的安全配置。

尤其适合拿来补充审查的是代码逻辑层面——第一遍让AI生成，第二遍让AI挑错，第三遍让第三个模型对比两份分析结果找差异。三个模型互相打架的地方，往往就是问题所在。这个方法听上去玄学，但实践下来命中率比单一模型高不少，核心原理就是不同模型的训练数据不同，对同一段代码的盲区也不同，交叉验证能有效降低“同一个盲区被AI生成又漏掉”的概率。

6. 排查实录——AI生成代码出事故之后怎么办

6.1 一次线上事故的处理思路

分享一个我处理过的真实事故，完整走一遍排查流程，给你一个可以参考的操作模板。背景：一个内部数据报表系统，使用AI生成的一段Python代码定期从外部API拉取数据，某天突然开始大量报错，数据全面延迟。

第一步，定位范围。我先看报错日志，发现是API返回的数据结构多了一个嵌套层级，AI生成的解析代码“想当然”地用data['items'][0]['name']取值，结果items现在变成data['data']['items']，直接抛KeyError。这个问题其实在代码里存在了好几个月，但外部API一直没变过结构，所以从没触发。

第二步，临时止血。先写一个兼容函数，对新旧两种数据结构做适配，保证接口不挂。同时给这个函数加上日志，记录每次取到的数据格式，方便确认外部API的行为变化趋势。这里要注意的是，不要一上来就改AI代码的核心逻辑，先让系统“恢复运行”才是第一位，后续再梳理改进。

第三步，根因分析。外部API为什么变结构？查了API提供方的公告，发现他们升级了版本，但没有发兼容通知。这个锅严格说在对接方，但我们的代码没有做“数据结构校验”，所以外部一变动，内部就直接崩了。这里的关键教训不是“AI生成的代码有问题”，而是“AI代码缺少防御性编程，我们没有要求它加一个schema校验”。

第四步，排查同类风险。把这个事件展开到整个系统，凡是AI生成的“解析外部数据”的代码全部列出来，逐个检查是否对“数据源结构变化”有容错。结果又找出来三个类似的隐患，都是AI图省事直接硬编码字段路径导致的。这之后我们组里新增了一条规则：AI生成的代码涉及外部数据对接，必须加一个“数据格式校验层”，允许解析失败时明确报错，不允许静默异常。

第五步，复盘并形成机制。写事故报告时，我们没有把责任推给AI工具，而是写“外部API变更属正常演进，系统缺少适配层，根因是代码设计时未将外部数据视为不可信输入；修复方案包括增加schema校验、兼容函数和监控告警”。这个归因方式更准确，也更能推动系统改进，而不是陷入“骂AI还是骂员工的争论”。

6.2 常见问题的快速处理表

这个表格是我日常面对AI代码出问题的处理速查，不一定覆盖所有场景，但大部分问题都能从这里找到方向。基本原则就一条：先恢复服务，再谈追责；先定位根因，再谈优化。如果你能坚持这个顺序，AI代码出任何事你都不会慌。

6.3 排查中的常见误区

排查AI生成代码的问题时，很多人会踩两个典型误区。

误区一：一上来就重写。看到AI代码有问题，第一反应是“这段代码不行，我推翻重写”。这其实是浪费，AI代码的框架和主逻辑往往是合理的，问题只集中在边界处理或安全配置。正确做法是：先定位到具体失败点，修复失败点，再检查同一类问题是否在其他地方重复出现。

误区二：把“能运行”等同于“没问题”。AI生成的代码能跑通happy path，不代表它在极端场景下能扛住。排查时要主动构造异常输入测试，不能只依赖线上真实流量触发问题。我建议在测试环境写几组“故意气死代码”的测试用例，比如超长字符串、负数、空值、并发访问，把这些用例跑一遍，出了问题正好在可控范围内解决。

踩过这些坑之后，我形成了一个习惯：凡是AI生成代码交付，至少预留半天时间做“对抗性测试”，拿各种刁钻方式折腾这段代码。花掉这半天，比以后花几天修线上的事故要划算得多。

7. 长期演进——把AI编程安全做成团队能力

7.1 建立团队AI代码安全规范

如果你是一个技术负责人，我强烈建议把AI编程安全纳入团队的“开发规范”文档，而不是留在个人经验层面。一个简明的规范，核心包含四条：

第一，所有AI生成代码必须经过人工审查后合入，关键模块（认证、支付、数据访问）必须双人复核。第二，AI代码合入时PR描述中必须标注“AI生成+人工审查范围”，接受团队监督。第三，引入第三方依赖必须走依赖审批流程，避免个人直接安装AI推荐的冷门包。第四，定期对存量代码做AI生成部分的安全专项扫描，不能只管增量不管存量。

这套规范看起来增加了流程成本，但实际上省去了大量“火灾救援”时间。我们组刚开始推行时，开发速度确实短暂下降了一两个星期，因为大家不熟悉审查流程，但过了适应期后，效率反而比“盲目用AI”时更高，因为线上问题变少了，团队不需要反复处理紧急修复。

7.2 AI代码的安全审查文化

比规范更重要的，是让团队形成“质疑AI代码”的文化。AI写出来的代码不是标准答案，它只是“一个很快的实习生”给出的“一份初稿”。你不能要求实习生交上来的东西直接上线，你至少要自己或者找个高级工程师review一轮。

我经常对团队成员说一句话：“用AI写代码，不是在偷懒，而是在逼自己更快地读懂代码。”你读得懂AI生成的每一行，你才知道它的边界在哪里；你读过它的边界，它才不会在关键时刻反咬你一口。这个心态转变过来之后，团队的整体代码水平和安全意识都上了一个台阶。

从个人经验来说，凡是抱着“AI帮我省了事，我就不用看了”的心态的同事，几乎都出过线上事故；凡是把AI当“助手”而不是“外包”的同事，效率和安全都保持得不错。这个规律目前在我的团队里还没有例外。

7.3 关注AI编程工具的更新与补丁

AI编程工具本身也在迭代。很多工具开始推“安全代码生成模式”“漏洞自动修复”“上下文安全提示”这些功能。我的态度是：可以跟进、尝试，但不要盲目信任。每次工具更新，我都会刻意拿几个经典漏洞样例去测试新版本是否真的修复了，而不是看到发布说明就默认安全。

比如之前有一个热门话题“ZCode偷代码”事件，讲的是某些AI编程插件会把用户代码回传到云端做训练数据，这属于“AI编程工具的隐私合规风险”。我当时特意排查了自己团队使用的插件权限设置，确保敏感项目没有开着“远程代码分析”功能。这个经验现在同样适用：AI工具本身也会成为泄密通道，使用前务必确认数据是否离本机。

AI编程安全的未来，大概率经历一个“初期混乱、中期治理、后期规范”的过程。现阶段我们能做的，就是在混乱中建立起自己的防线。这篇文章写的就是我正在用的防线，你可以直接抄作业，也可以根据团队情况调整，但核心思路记住一句话：AI不是牛马，你才是。