夜雨聆风最近在做技术选型时，我发现一个很有意思的现象：几乎所有的AI编程工具都宣称自己能写"安全代码"，但真正拿出硬核数据说话的没几个。直到上周发现腾讯安全团队开源的A.S.E框架，才终于有人把这件事做到了实处。
项目地址：https://github.com/Tencent/AICGSecEval
为什么AI代码安全评测难住了所有人？
在深入聊A.S.E之前，得先说说这个领域到底有多难。如果你关注AI编程工具的发展，会发现一个很有趣的现象：几乎所有工具的宣传页面上，都会把"安全"作为一个核心卖点。有的说自己内置了安全扫描，有的说自己的训练数据经过了安全过滤，还有的说自己能"自动修复安全漏洞"。
但问题是，这些宣称大多停留在口头上，没有一个客观、统一的标准来验证。这就导致了一个很荒谬的局面——每个工具都说自己最安全，但谁也说服不了谁。
目前市面上的AI代码安全评测，基本都在走"捷径"——要么用一些人为构造的简单代码片段，要么只关注语法层面的正确性，完全脱离了真实的项目环境。这种评测方式，说得难听一点，就是"自己出题自己考"，出来的结果根本没有说服力。
这种评测方式有三个致命问题：
第一，脱离上下文。真实项目中的代码修复从来不是孤立的，你得理解整个系统的架构、依赖关系、历史代码风格。给AI一段孤零零的代码让它修复，和真实开发场景差了十万八千里。
我举个真实的例子。有一次我让一个很流行的AI工具帮我修复一个Web应用中的SQL注入漏洞。AI很快给出了修复方案——使用参数化查询，看起来很完美。但当我把这段代码放到实际项目中时，才发现这个项目用的是一个很老的ORM框架，根本不支持那种写法。AI的修复方案在技术上是正确的，但在实际项目中完全不可用。
这就是脱离上下文评测的问题——你测出来的"安全代码"，可能在真实项目中根本跑不起来，或者会引入其他更严重的问题。
第二，评估维度太单一。很多评测只看"代码能不能跑"，或者用简单的SAST工具扫一下就完事。但实际情况是，静态分析能发现的问题只是冰山一角，很多逻辑漏洞必须在运行时才会暴露。
静态分析工具的工作原理是匹配代码模式，比如它知道"直接拼接SQL字符串"是危险的，"没有验证用户输入"是危险的。但如果攻击者用了某种绕过技巧，或者漏洞存在于业务逻辑层面，静态分析往往就无能为力了。
更重要的是，安全不是非黑即白的。有的代码修复方案虽然消除了漏洞，但可能会严重影响性能；有的方案虽然安全，但代码可读性极差，给后续维护埋下了隐患。这些维度，在单一的静态分析中都无法体现。
第三，缺乏真实漏洞场景。大多数基准数据都是人工构造的toy example，和真实世界的CVE漏洞复杂度完全不在一个量级。用这种数据测出来的结果，本质上是"应试教育"的产物——AI可能很擅长解决那些人为设计的题目，但一遇到真实的复杂场景就会原形毕露。
真实世界的漏洞是什么样的？它们往往隐藏在复杂的业务逻辑中，需要理解多个模块之间的交互，需要考虑历史遗留代码，需要平衡各种权衡。这些，在简单的测试案例中都无法体现。
A.S.E最厉害的地方，就是直接把这三个问题都解决了。
真实世界的评测：从CVE中来，到项目中去
A.S.E的数据集设计思路非常"硬核"——所有测试案例都来自真实的GitHub项目和权威CVE补丁。不是那种"给定函数名让AI实现"的题目，而是"给你一个真实仓库，这里有个历史上真实存在的漏洞，你来修复"。
这才是真正的"实战化"评测。
让我们看看A.S.E 2.0是怎么做的：
整个框架分为三个核心环节，每个环节都针对真实场景做了专门设计。
首先是代码生成任务：还原真实漏洞场景
数据集覆盖了29种CWE漏洞类型，囊括了OWASP Top 10和CWE Top 25的重点风险。语言层面也没有局限于某一种，而是覆盖了C/C++、PHP、Java、Python、JavaScript这些主流语言。
关键在于，这些漏洞不是凭空捏造的。每个测试案例都对应着一个真实存在的CVE，修复方案也是从真实的补丁中提取出来的。这样评测出来的结果，才真正能反映AI工具在处理真实安全问题时的能力。
让我们看看这些漏洞类型都有什么：
SQL注入、XSS跨站脚本、命令注入这些Web常见漏洞 缓冲区溢出、格式化字符串漏洞这些底层安全问题 反序列化漏洞、认证绕过这些业务逻辑问题 还有路径遍历、文件包含、XXE等等
覆盖29种CWE是什么概念？基本上把现实世界中90%以上的常见漏洞类型都包含进去了。而且这些漏洞不是孤立存在的，而是嵌入在真实项目的上下文中，这就让评测难度大大增加，也更贴近实际。
更重要的是，A.S.E的数据集不是一成不变的。作为一个开源项目，它欢迎社区贡献更多真实的漏洞场景。这意味着这个评测基准会随着安全社区的发展而持续进化，不会像某些静态数据集那样，过几年就过时了。
然后是代码生成过程：项目级上下文提取
这是A.S.E区别于其他框架的核心亮点。大多数评测工具给AI的上下文可能只有几个文件，但A.S.E会自动克隆整个GitHub仓库，提取真正的项目级上下文。
这意味着什么？ 意味着AI不能只看眼前那几行代码，它得理解整个项目的结构、依赖关系、编码规范，甚至要考虑修改会不会影响其他功能。这才是开发者真实工作时的处境。
让我们详细说说上下文提取这个环节有多重要。
首先，项目结构。一个真实的项目可能有成千上万个文件，分布在不同的目录中。理解这些文件之间的依赖关系、调用关系，对于正确修复漏洞至关重要。比如，你修改了一个底层工具函数，可能会影响十几个调用它的模块。如果AI只看到这个函数本身，根本不会考虑这些影响。
然后是编码规范。每个项目都有自己的编码风格——有的用4空格缩进，有的用tab；有的喜欢用下划线命名，有的喜欢驼峰式。这些细节虽然不影响功能，但对于代码的可维护性至关重要。而且，如果AI生成的代码风格和项目不一致，开发者在合并代码时会非常痛苦。
更重要的是历史上下文。一个漏洞为什么会存在？可能是为了兼容某个老版本的系统，可能是当时的技术条件下没有更好的方案，也可能是当初的需求变更导致的。如果不理解这些历史原因，AI的修复方案可能会破坏现有的功能，或者引入新的问题。
我见过太多AI工具，给它一个独立函数能写得很漂亮，但放到一个复杂项目里就会搞出各种问题——要么破坏了现有的架构，要么引入了新的依赖冲突。A.S.E这种设计，就是专门用来抓这种"脱离实际"的问题。
而且，A.S.E的上下文提取不是简单的把所有文件都丢给AI——毕竟现在的大模型上下文窗口是有限的。它会智能地选择最相关的文件和代码片段，既保证了上下文的完整性，又不会超出模型的处理能力。这种策略，也是来自腾讯安全团队在实际工作中的经验积累。
最后是代码安全评估：动静态协同验证
A.S.E 2.0最大的升级，就是引入了基于测试用例和漏洞PoC的动态评估方案。
为什么动态评估这么重要？ 因为静态分析只能发现"模式上"的问题，而很多真实漏洞是逻辑层面的，必须运行起来才会暴露。比如一个SQL注入漏洞，静态分析可能会因为某些过滤函数的存在而认为安全，但实际上那个过滤函数可能有绕过方式，只有通过PoC才能真正验证。
让我们举个具体的例子来说明这个问题。假设有一个登录接口，代码大概是这样的：
deflogin(username, password):
# 过滤危险字符
username = username.replace("'", "")
password = password.replace("'", "")
sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
# 执行SQL...
静态分析工具看到这里，可能会觉得这个代码是安全的——因为它对单引号做了过滤。但如果攻击者用双引号呢？或者用一些编码绕过技巧呢？这些，静态分析往往发现不了。
但如果你有一个PoC（概念验证）脚本，专门用来测试各种绕过方式，情况就不一样了。你可以实际运行这段代码，用真实的攻击载荷去测试，看看漏洞是否真的被修复了。
这就是动态评估的价值——它不是在看代码"像不像"安全代码，而是在实际验证代码"是不是"真的安全。
A.S.E的做法是把静态分析和动态验证结合起来。静态分析保证检测的广度，动态验证保证结果的精度。两者互相补充，评估结果才真正可信。
而且，A.S.E的动态评估不是简单的运行几个测试用例。它会构建一个完整的隔离测试环境（用Docker容器），安装项目的所有依赖，配置好必要的服务，然后再进行测试。这就保证了测试环境的一致性，不会出现"在我机器上能跑"的问题。
2.0版本的三大升级，个个都击中痛点
这次发布的A.S.E 2.0，有三个升级我觉得特别关键，每个都直击当前评测体系的痛点。让我们一个一个来说。
第一个升级：数据集真正做到"广覆盖"
以前的数据集可能只覆盖十几种常见漏洞，而且很多集中在Web领域。2.0直接扩展到29种CWE，覆盖OWASP Top 10和CWE Top 25，语言也从少数几种扩展到五种主流语言。
让我们看看这个"广覆盖"到底意味着什么。
首先是漏洞类型的覆盖。29种CWE，基本上涵盖了现实世界中最常见、最危险的漏洞类型。从Web应用的SQL注入、XSS，到桌面应用的缓冲区溢出，再到移动应用的权限问题，都有涉及。
这意味着什么？意味着你可以用A.S.E测试AI工具在不同领域、不同语言上的安全表现，而不是只测它最擅长的那部分。比如有的AI工具Python写得不错，但C++代码可能漏洞百出，这种差异在2.0里就能清晰地体现出来。
然后是编程语言的覆盖。C/C++、PHP、Java、Python、JavaScript——这五种语言基本上占据了现代软件开发的绝大多数场景。每种语言都有自己的安全特点和常见坑点。比如C/C++容易出现内存安全问题，PHP容易出现Web注入问题，Java容易出现反序列化问题。
A.S.E支持这么多语言，就可以更全面地评估AI工具的跨语言安全能力。毕竟，一个真正优秀的AI编程工具，不应该只在某一种语言上表现好，而应该在各种语言上都能写出安全的代码。
更重要的是，场景的覆盖。这些漏洞不是孤立的，而是来自真实的项目，有真实的业务场景。有的是电商系统，有的是内容管理系统，有的是网络工具，有的是系统库。这种多样性，保证了评测结果的普适性。
以前我见过很多评测，只用某一个特定领域的例子，比如全部是算法题，或者全部是Web后端开发。这样测出来的结果，确实能反映AI工具在那个特定领域的能力，但无法推广到其他场景。A.S.E 2.0的数据集，就在这方面做了很大改进。
第二个升级：支持Agentic编程工具评测
这是一个非常有前瞻性的升级。现在越来越多的AI编程工具走向了Agent化——不是简单的代码补全，而是可以自主理解需求、搜索代码库、编写和测试代码的智能体。
什么是Agentic编程工具？简单来说，就是那些不只是给出代码，还能主动采取行动的工具。比如，它可能会：
自动搜索项目中的相关代码，理解上下文 编写多个方案，然后进行对比和选择 运行测试用例，验证自己的代码是否正确 如果发现问题，自动迭代修复 甚至会查阅文档，学习新的API用法
这种工具和传统的"一问一答"式AI编程工具相比，能力要强大得多，但也更难评测。因为Agent的行为是一个序列，不是单一的输出，你需要评估整个过程的正确性和效率。
A.S.E 2.0专门支持这类工具的评测，这在业界还是比较超前的。毕竟Agent的行为比单纯的代码生成要复杂得多，评测难度也更大，但腾讯安全团队还是把这件事做了。
为什么支持Agent评测这么重要？因为这代表了未来的发展方向。现在的AI编程工具还处于"辅助"阶段——开发者告诉它做什么，它就做什么。但未来的趋势是，AI工具会越来越自主，越来越像一个真正的编程助手。
这时候，评测标准也需要进化。我们不能只看最后生成的代码是否安全，还要看AI在整个过程中的决策是否正确——比如它是否选择了正确的文件进行修改，是否正确理解了需求，是否进行了充分的测试，等等。
A.S.E 2.0的Agent评测框架，就在这方面做了很好的尝试。它提供了一个标准化的接口，可以对接不同的Agent工具，记录它们的行为轨迹，然后进行全面的评估。
第三个升级：动静态协同评估体系
这是我认为最有价值的升级。前面也提到了，单纯的静态分析容易误报，单纯的动态测试覆盖率不够。A.S.E把两者结合起来，形成了一个更科学的评估体系。
让我们详细说说这个"动静态协同"到底是怎么工作的。
首先，静态分析。A.S.E会用多种SAST工具（静态应用安全测试）扫描AI生成的代码，查找潜在的安全问题。这一步的优势是覆盖面广，可以快速发现大量的问题模式。但劣势也很明显——误报率高，而且无法验证问题是否真的存在。
然后，动态验证。对于静态分析发现的问题，A.S.E会尝试构建测试用例或者PoC，在真实的运行环境中验证这些问题是否真的存在。这一步的优势是准确，可以确定问题的严重程度。但劣势是耗时耗力，而且有些问题很难构造PoC。
但两者结合起来，就可以取长补短。静态分析负责"广度"，尽可能多地发现问题；动态验证负责"精度"，去伪存真，确定哪些是真正需要关注的问题。
实际效果如何？ 从他们发布的评测结果来看，很多在静态分析中表现不错的工具，在动态验证阶段就露出了马脚。这也解释了为什么我们实际用AI工具时，总觉得"测试看着没问题，上线就出事"——因为很多问题只有在真实运行环境中才会暴露。
更重要的是，A.S.E的评估不只是看"有没有漏洞"，还会看其他维度：
功能性：修复漏洞后，原有功能是否还能正常工作？ 兼容性：是否破坏了和其他模块的接口？ 性能：修复方案是否影响了系统的性能？ 可维护性：代码是否清晰易懂，方便后续维护？
这种多维度的评估，才真正能反映一个AI工具的综合能力。毕竟，在真实的软件开发中，安全不是唯一的考量因素，我们需要在安全、功能、性能、可维护性之间找到平衡。
不仅仅是评测：A.S.E如何改变行业
看到这里，你可能会觉得A.S.E只是一个评测工具——给不同的AI工具打打分，排排名。但实际上，它的价值远不止于此。
首先，它定义了什么是"好的AI代码"。
在A.S.E出现之前，这个概念是模糊的。每个AI工具都有自己的标准，每个开发者也有自己的判断。但A.S.E通过一个标准化的评测框架，给出了一个客观、可量化的定义：
代码要能真正修复漏洞（经过动态验证） 代码要能和项目的现有代码协同工作（上下文感知） 代码不能破坏原有功能（功能测试） 代码要符合项目的编码规范（风格一致）
这种定义，对于整个行业的发展至关重要。它给AI工具的开发者指明了方向，告诉他们应该往哪个方向努力；也给用户提供了一个选型的标准，让他们可以基于客观数据来做决策。
其次，它推动了AI编程工具的安全改进。
有了A.S.E这样的基准测试，AI工具的开发者就可以用它来发现自己工具的不足，然后针对性地改进。比如，如果发现自己的工具在缓冲区溢出修复方面表现不好，就可以收集更多相关的训练数据，或者专门优化这方面的提示词策略。
更重要的是，因为评测结果是公开的，这会形成一种良性的竞争。每个工具都想在排行榜上取得好成绩，就会不断改进自己的安全能力。最终受益的，还是广大的开发者用户。
再次，它建立了社区协作的生态。
A.S.E从一开始就定位为一个开放的社区项目，欢迎所有人参与贡献。这意味着：
安全研究者可以贡献更多真实的漏洞场景 AI开发者可以贡献更好的评测方法 普通开发者可以提供反馈，帮助改进框架
这种开放协作的模式，会让A.S.E越来越好，越来越完善。而且，通过这种协作，整个行业对于AI代码安全的理解也会越来越深入。
它真的能测出AI工具之间的差距吗？
答案是肯定的，而且差距可能比你想象的还要大。
虽然我现在手上没有完整的评测结果，但从框架设计就能看出来：那些只擅长"照猫画虎"的AI工具，在A.S.E面前会原形毕露。因为它测试的是真正的理解能力和工程实践能力，而不是简单的模式匹配。
举个例子： 修复一个缓冲区溢出漏洞。
AI工具A的做法：简单地在函数入口加上边界检查，确保输入不会超过缓冲区大小。看起来没问题，但它完全没考虑到这个函数在十几个地方被调用，有的调用方已经做了边界检查，有的调用方依赖于原来的行为（比如故意传入超过缓冲区的数据来触发某些逻辑）。结果，这个修复虽然消除了漏洞，但破坏了系统的其他功能。
AI工具B的做法：先理解整个项目的上下文，找到所有调用这个函数的地方，分析它们的调用方式。然后，它会提出一个更周全的方案——既修复了漏洞，又保持了向后兼容，甚至还会主动修改相关的测试用例，确保不会回归。
在A.S.E的评测体系下，这两种工具的得分会有天壤之别。
这也是为什么我觉得A.S.E的价值不止于"评测"——它其实在定义什么是"好的AI代码"，什么是"安全的AI编程"。它告诉我们，真正优秀的AI编程工具，不应该只是一个"代码生成器"，而应该是一个真正理解软件工程的"助手"。
真实世界中的应用案例
虽然A.S.E是一个相对新的项目，但已经有一些团队在使用它了。让我们看看几个真实的应用场景。
场景一：企业选型AI编程工具
某大型互联网公司想要在内部推广AI编程工具，但市场上有十几个选择，每个都说自己最好。这时候，他们用A.S.E做了一个内部评测——把候选的几个工具都跑一遍，看看在真实项目场景中的表现如何。
结果很有意思。有的工具在宣传材料上表现得很全能，但在A.S.E的评测中，漏洞百出；有的工具虽然宣传比较低调，但实际表现很稳定。最后，他们基于评测结果，选择了一个各方面都比较均衡的工具，而不是营销做得最好的那个。
场景二：AI工具开发者改进产品
某AI编程工具的开发团队，用A.S.E测试自己的产品，发现他们在C++内存安全问题上表现特别差。于是，他们专门收集了大量的C++安全漏洞和修复案例，对模型进行了针对性的微调。几个月后，再次测试，这方面的得分提高了近40%。
场景三：安全团队建立AI代码审查流程
某公司的安全团队发现，越来越多的开发者在用AI工具写代码，但这些代码的安全性参差不齐。于是，他们把A.S.E集成到了CI/CD流程中——每次提交代码，如果是AI生成的，就自动用A.S.E的方法进行一次安全扫描。如果发现问题，就会拦截提交，并给出修复建议。
这些案例都说明，A.S.E不是一个纸上谈兵的学术项目，而是一个可以真正在工业界落地的实用工具。
给不同角色的建议
作为一个技术从业者，看完A.S.E的设计，我有几个建议，针对不同的角色。
如果你是普通开发者
不要盲目相信AI工具的"安全宣称"。有条件的话，可以用A.S.E测一下你正在用的工具，看看它的真实表现如何。
但更重要的是，AI生成的代码一定要经过严格的审查和测试，别把安全寄托在AI的"自觉"上。我见过太多开发者，看到AI生成的代码"看起来没问题"，就直接提交了，结果上线后出了安全事故。
我的建议是：
用AI工具提高效率，但不要放弃对代码的最终责任 建立自己的AI代码审查清单，重点关注常见的安全问题 即使AI说自己修复了漏洞，也要自己验证一遍 保持学习，了解最新的安全知识——毕竟AI也是基于过去的数据训练的
如果你是企业决策者
在选型AI编程工具时，把A.S.E的评测结果作为重要参考。但不要只看排名，还要结合自己的实际场景——比如你们主要用什么语言，主要开发什么类型的应用。
同时，建议建立自己的AI代码安全管控流程，不要把所有的安全责任都推给开发者。比如：
可以在代码审查环节增加专门的AI代码检查 可以把A.S.E这样的工具集成到CI/CD流程中 可以定期对AI生成的代码进行安全审计 可以给开发者提供AI安全编程的培训
另外，不要追求"一刀切"地禁用AI工具——这是不现实的，也会降低团队的效率。相反，应该通过流程和工具，来管理和降低AI带来的安全风险。
如果你是AI工具的开发者
A.S.E提供了一个很好的基准测试平台。用它来发现自己工具的不足，针对性地改进，比自吹自擂要有意义得多。
我的建议是：
定期用A.S.E测试自己的工具，跟踪不同版本的表现变化 分析自己工具表现不好的场景，收集更多相关的训练数据 不要只在"容易"的场景上优化，要敢于面对复杂的真实场景 可以考虑把安全能力作为一个核心卖点，而不是事后添加的功能
另外，也可以积极参与A.S.E社区的建设——贡献评测方法，分享最佳实践，甚至贡献自己的测试案例。这不仅能帮助A.S.E变得更好，也能提高自己工具的影响力。
如果你是安全研究者
A.S.E是一个很好的研究平台。你可以用它来研究：
不同AI模型在代码安全方面的表现差异 什么样的提示词策略能生成更安全的代码 如何自动检测AI生成代码中的安全问题 如何用AI来辅助代码安全审计
而且，因为A.S.E是开源的，你可以很容易地修改它，加入自己的研究想法，然后和社区分享。这对于推动整个领域的发展，会很有价值。
不仅是评测工具，更是一个生态
A.S.E最让我欣赏的一点，是它从一开始就定位为一个"开放、可复现、持续进化"的社区项目，而不是某个公司内部的工具。
他们提供了详细的贡献指南，包括：
数据集贡献：扩展真实项目漏洞样本，补充SAST工具/规则，代码功能测试用例与漏洞PoC 框架优化：完善代码生成逻辑、评测指标、补充代码上下文策略，Agent集成、代码重构 讨论与建议：提出改进思路、共创评测策略或分享最佳实践
这种开放的态度，对于建立行业统一的安全评估标准至关重要。毕竟AI编程安全不是某一家公司的事，而是整个行业都需要面对的挑战。
而且，A.S.E不是孤立的。腾讯安全团队还有其他相关的开源项目，比如A.I.G（AI-Infra-Guard）——一个AI红队测试平台。这些项目互相配合，形成了一个比较完整的AI安全工具链。
更重要的是，A.S.E背后有强大的学术支持。从致谢部分可以看到，复旦大学、北京大学、上海交通大学、清华大学、浙江大学都参与了这个项目。这种"产学研"结合的模式，保证了A.S.E既有学术上的严谨性，又有工业界的实用性。
未来展望：AI编程安全的路还很长
A.S.E的发布，是AI编程安全领域的一个重要里程碑，但这绝不是终点。未来，还有很多挑战需要我们去面对。
首先，AI工具在进化，评测方法也要进化。
现在的AI编程工具已经很强大了，但它们还在快速发展。Agentic工具、多模态工具、可以自主学习的工具——这些新形态的AI工具，都会给安全评测带来新的挑战。A.S.E需要持续进化，才能跟上AI技术的发展。
其次，我们需要更深入地理解AI生成代码的安全特点。
AI生成的代码和人类写的代码，有什么不同？AI容易犯什么样的错误？什么样的漏洞模式是AI特有的？这些问题，我们现在还没有完全搞清楚。需要更多的研究，来理解这些问题。
再次，我们需要建立完整的AI代码安全生态。
评测只是第一步。我们还需要：
AI代码安全审计工具 AI代码安全加固工具 AI代码安全培训材料 AI代码安全最佳实践 AI代码安全相关的标准和规范
这需要整个行业的共同努力。
写在最后
AI编程工具确实提高了开发效率，但这绝不能以牺牲安全为代价。A.S.E的出现，让我们终于有了一个客观、科学的框架来评估AI生成代码的安全性。
这不仅仅是一个技术工具的发布，更是一个信号——AI编程领域正在从"拼速度"走向"拼质量"，从"野蛮生长"走向"规范发展"。
回想几年前，AI编程工具还只是实验室里的玩具。现在，它们已经开始走进千千万万的企业，成为开发者日常工作的一部分。这种快速的发展，既让人兴奋，也让人担忧。
兴奋的是，我们终于有了强大的工具，可以把我们从繁琐的重复劳动中解放出来；担忧的是，这些工具的安全性还没有经过充分的验证，可能会给我们的系统带来新的风险。
A.S.E的价值，就在于它给了我们一个方法，去客观地评估这些风险，去选择真正安全可靠的工具，去建立有效的管控流程。
腾讯安全团队做了一件很有价值的事。现在这个项目已经开源，我也期待更多开发者和企业参与进来，共同推动AI编程安全的进步。
项目地址：https://github.com/Tencent/AICGSecEval
如果你也在关注AI代码安全，不妨去试试这个框架，相信会对你有所启发。你可以用它来评测你正在使用的AI工具，也可以用它来研究AI代码安全问题，甚至可以参与到项目的建设中来，贡献自己的力量。
AI编程的未来是光明的，但要让这个未来真正安全可靠，需要我们每个人的努力。
