AI编程实战：安全工程师如何用AI高效构建安全巡检工具

1. 从震惊到实践：一个安全工程师的AI编程初体验

说实话，最近认真让AI把代码写出来之后，我是真的有点震惊的。这种震惊，不是那种看到新技术的猎奇感，而是一种切身的、关于自身工作方式与价值定位的冲击。作为一名干了十多年的安全工程师，我的日常就是和各种漏洞、攻击链、安全策略打交道，写代码更多是为了实现某个检测逻辑、分析脚本或者工具原型。以前用AI，比如ChatGPT，主要就是当个高级一点的搜索引擎，查查某个API怎么用，或者写个简单的Python脚本处理日志。我从来没想过，或者说没敢想，AI能独立完成一个功能相对完整、甚至需要前后端配合的项目。

这个转变的契机，是公司开始大力推行AI编程工具。我自己主要上手试了腾讯的WorkBuddy和Kimi的付费版（里面那个Kimi Code功能挺有意思），公司层面在推阿里的通义灵码，不过我还没来得及深度体验。我决定不再只是“试试看”，而是真正把它用到一个具体的、我需要的任务上。我选择的第一个“实验品”是一个Chrome浏览器插件，功能极其简单明确：屏蔽百度搜索结果页右侧那烦人的“百度热搜”栏目。

我的操作过程简单到有点“粗暴”：我打开百度，随便搜个词，按F12打开开发者工具，找到那个热搜区域对应的HTML元素，把那一大段<div>代码复制出来。然后，我打开WorkBuddy，选择了它的“前端工程师专家”技能，给的提示词大概是：“帮我写一个Chrome扩展，屏蔽百度搜索页面右侧的百度热搜区域。这是该区域的HTML代码片段：[粘贴代码]。插件要能正常安装和运行。”整个过程，我没有描述任何技术细节，比如要用content_scripts、要写manifest.json，我只是说了“我要什么”和“目标是什么样子”。

几分钟后，它给了我一个完整的项目文件夹。里面有标准的manifest.json配置文件，有注入页面用的JavaScript文件，甚至还有简单的图标。我按照Chrome扩展的加载方式，选择“加载已解压的扩展程序”，指向那个文件夹。刷新百度搜索页——右侧那片花花绿绿的热搜区域，消失了。干净利落。我不信邪，又把它拖进360极速浏览器里试了试，同样生效。那一刻的感觉很复杂：一方面是工具带来的高效愉悦，另一方面是一种隐隐的“失控感”。我意识到，AI写代码这件事，门槛正在从“技术实现能力”急剧滑向“问题定义与描述能力”。对于一个安全工程师，或者任何需要借助代码解决问题的岗位来说，这意味着什么？我们过去花大量时间学习的语法、框架、调试技巧，其壁垒正在被快速消解。

2. 思路转变：从写代码到“导演”AI生成解决方案

这次初体验让我彻底调整了思路。我不再视AI为一个问答机或代码补全工具，而是开始把它当作一个可以执行复杂指令的“全能型初级开发员”。我的角色，从一个事必躬亲的“码农”，转变为一个需要精准提出需求、设计架构、并验收成果的“技术导演”或“解决方案架构师”。基于这个新定位，我立刻梳理了手头几个一直想做但苦于时间或编码深度不足的安全增强项目，决定全部用AI编程的方式来尝试推进。这些项目都不是玩具，而是切中实际安全运营痛点的需求。

第一个项目：网站安全健康度巡检工具。核心需求是自动检测公司官网等重要Web资产是否被植入了恶意代码（挂马）、是否存在指向风险域名（如博彩、色情、钓鱼网站）的异常链接、以及是否存在DNS劫持的迹象（比如关键JS/CSS资源被指向了非官方域名）。这需要实现一个定时爬取、页面内容分析、外部链接提取与威胁情报比对、以及DNS解析验证的系统。

第二个项目：代码泄露监控系统。程序员把公司代码上传到Github、Gitee、个人博客甚至技术论坛，是常见的内部威胁和数据泄露场景。手动监控几乎不可能。这个项目需要能自动、持续地扫描这些公开平台，使用与公司项目相关的关键词、代码片段特征甚至部分密钥哈希进行匹配，发现潜在泄露并告警。

第三个项目：轻量级交互式蜜罐。传统的蜜罐部署和维护比较复杂。我想做一个极简的、但具备基本感知能力的蜜罐。只要有任何外部IP对它的IP发起连接（无论是TCP ping、SSH握手、HTTP请求还是其他常见协议），它都能记录下对方的IP、端口、协议类型、交互的原始流量（或关键日志），并在一个简单的Web控制台上实时可视化展示。对于高频攻击或来自特定威胁情报库的IP，能触发告警。

第四个项目：内网资产搜索引擎。很多企业的内网资产是一笔糊涂账，有多少IP、每个IP上开了哪些端口、跑着什么服务，安全团队往往不清楚。这个项目需要对指定IP段进行周期性的端口扫描与服务识别，将结果结构化存储，并提供一个可以按IP、端口、服务、主机名等条件快速检索的Web界面，实现内网资产的“一览无余”。

这四个项目，每一个都涉及前端（用于展示结果、配置任务）和后端（用于调度任务、执行检测逻辑、存储数据）。在过去，要启动其中任何一个，我可能都需要先花一两周做技术选型、搭建基础框架，再慢慢填充业务代码。但现在，我的第一反应是：如何把每个项目拆解成AI能理解的、清晰的、可执行的“指令集”？我的价值，似乎首先就体现在这个“拆解与定义”的过程之中。

3. 实战拆解：以“网站安全巡检工具”为例的AI协同开发全流程

光说不练假把式。我决定以第一个“网站安全健康度巡检工具”作为样板，详细记录我用AI编程实现它的全过程。这个过程充满了摸索、调整和迭代，远比第一个简单的浏览器插件复杂，但也更能体现人机协作的深度。

3.1 需求拆解与方案设计：给AI画好蓝图

我不能直接对AI说“做一个网站安全检测工具”。这太模糊了。我必须先自己把方案想清楚，拆分成AI能独立处理的模块。我的设计思路如下：

1. 核心调度与任务管理（后端）：需要一个主程序，可以管理要检测的URL列表，定义检测频率（如每天一次），并调度执行具体的检测任务。这涉及到定时任务框架、任务队列的概念。
2. 页面抓取模块（后端）：负责抓取目标网页的完整HTML内容。需要考虑设置合理的User-Agent、超时时间，处理可能的反爬机制（虽然对公司官网一般不用），以及处理重定向。
3. 内容分析引擎（后端）：这是核心。
   • 挂马检测：简单版可以通过在HTML中搜索典型的恶意脚本特征（如eval(String.fromCharCode(...))、非常规的<script>源域名）来实现。更可靠的方案可以提取所有<script>标签的src或内联代码，与公开的恶意代码签名库进行比对（这部分初期可简化）。
   • 风险链接提取：提取页面中所有<a>标签的href属性，以及<script>、<link>、<img>等标签的src属性。过滤出外部域名链接。
   • DNS劫持检测：针对页面中关键的第三方资源链接（如jQuery库、Google Analytics、字体库等），在检测时同时用DNS解析工具解析其域名，将解析到的IP与已知的官方IP或历史记录进行比对，不一致则告警。
4. 威胁情报比对（后端）：将提取出的所有外部域名，与本地或云端维护的风险域名库（可集成开源威胁情报Feed）进行比对，标记出高风险域名。
5. 数据存储与前端展示（前后端交互）：需要数据库（如SQLite或MySQL）来存储每次的检测结果。需要一个Web前端，以表格形式展示历史检测记录，用颜色高亮风险项（如红色代表发现恶意脚本，黄色代表存在风险链接），并提供详情查看功能。

有了这个蓝图，我才可以开始和AI“对话”。

3.2 分步实施：与AI的“结对编程”

我选择从后端核心开始，使用Python，因为它有丰富的安全与爬虫库。我打开了Kimi Code。

第一步：搭建项目骨架与任务调度。我的提示词：“我需要创建一个Python项目，实现定时网站安全检测。请帮我创建项目基础结构，并实现一个使用APScheduler库的定时任务调度器。它每天上午9点执行一次检测任务。检测任务暂时用一个打印语句代替。请给出完整的目录结构和代码。”

AI生成了标准的项目结构（src/,config/,requirements.txt等），并写出了配置APScheduler的代码。我注意到它默认使用了BackgroundScheduler，并提示在Web应用中使用时要注意线程安全。这是一个很好的细节补充。

第二步：实现网页抓取模块。提示词：“请为上述项目添加一个网页抓取模块page_fetcher.py。使用requests和BeautifulSoup库。函数需要接收URL参数，返回抓取到的HTML文本。请添加超时处理、重试逻辑和模拟常见浏览器的User-Agent。”

AI给出了代码，并主动建议使用retrying库来实现重试，以及用一个列表随机选择User-Agent。我采纳了建议，并让它把retrying加到requirements.txt里。

第三步：实现核心的内容分析引擎。这是最复杂的一步。我没有一次性要求，而是分次进行。 首先，我让它写“风险链接提取”函数：“请创建content_analyzer.py，提供一个函数extract_external_links(html_content, base_url)。它能使用BeautifulSoup解析HTML，提取所有a,script,link,img标签的href或src属性。判断是否为外部链接（与base_url的域名不同），并返回一个外部域名列表。” AI准确地实现了，并处理了相对路径和绝对路径的转换。

接着，我让它补充“简单挂马检测”：“在content_analyzer.py中增加函数detect_malicious_scripts(html_content)。检测思路：1. 查找所有<script>标签。2. 对内联脚本，检查是否包含eval(、document.write写入非常规内容、或String.fromCharCode解码长字符串等可疑模式。3. 对外部脚本，检查src域名是否在已知的可信CDN列表之外（提供一个初始的空列表，后续可配置）。返回可疑的脚本内容或URL列表。” AI实现了这个函数，并使用了正则表达式来匹配可疑模式，同时提醒我这种基于规则的方法误报率可能较高，建议后期结合动态沙箱分析。

然后，是“DNS劫持检测”：“请创建dns_checker.py。提供一个函数check_dns_hijacking(url, known_ips)。使用dnspython库解析URL中的域名，将解析到的所有A记录IP与参数known_ips（一个IP列表）比对。如果有任何一个IP不在已知列表中，则返回False和解析到的IP列表，否则返回True。请将dnspython加入依赖。” AI照做了，并给出了使用示例。

第四步：数据存储与前端。我决定用轻量级的Flask框架和SQLite数据库。 提示词：“现在创建数据模型和Web界面。使用Flask和SQLAlchemy（ORM）。创建一个models.py，定义DetectionRecord表，字段包括：id, url, check_time, malicious_scripts_found（布尔）, risk_domains（JSON文本存储列表）, hijacking_found（布尔）, details（文本）。再创建app.py，提供两个路由：1./展示所有检测记录，按时间倒序。2./check/<url>手动触发对某个URL的检测。检测逻辑调用我们之前写的那些模块。” AI生成了完整的Flask应用结构、数据库初始化脚本、以及使用Jinja2模板的简单HTML列表页。它甚至自动处理了表单提交和重定向。

在整个过程中，我并非简单地复制粘贴代码。我需要：

1. 理解与审查：仔细阅读AI生成的每一段代码，理解其逻辑。比如，在DNS检测部分，我发现AI默认使用了系统的DNS服务器，我提示它修改为使用8.8.8.8（Google DNS）和114.114.114.114（国内DNS）进行双重解析比对，增加可靠性。
2. 调试与集成：把各个模块组合起来运行时，出现了导入路径错误和数据库锁问题。我不得不自己调试，或者将错误信息反馈给AI：“运行app.py时出现ImportError: cannot import name 'extract_external_links' from 'content_analyzer'，请检查模块结构和导入语句。” AI会修正它。
3. 补充业务逻辑：AI生成了骨架，但关键的“风险域名库比对”逻辑是空的。我需要自己找一个开源威胁情报源，比如abuse.ch的SSL黑名单，或者简单点，自己维护一个文本文件列表。我让AI写一个函数来读取这个列表文件并与提取的域名进行比对。
4. 优化与提示：前端列表页很简陋。我要求AI：“请在前端页面中，用红色背景高亮malicious_scripts_found为True的记录，用黄色背景高亮hijacking_found为True的记录。并在risk_domains列中，将匹配到的风险域名用红色加粗显示。” 经过大约两天的间断性工作，一个具备基础功能的网站安全巡检工具就运行起来了。虽然它离生产级还有距离（比如没有登录认证、扫描性能待优化、威胁情报库薄弱），但它完全验证了想法，并且核心功能都是可用的。这个过程中，我写代码的时间可能只占20%，其余80%的时间都在思考架构、设计提示词、审查和调试AI的输出、以及填充AI无法自行决定的业务逻辑。

4. 价值重思：在AI编程时代，安全工程师的核心竞争力是什么？

通过亲手用AI完成这几个项目，我之前的震惊逐渐沉淀为一些更具体的思考。那个“我的价值在哪里”的问题，答案的轮廓也开始清晰。AI编程并没有让我失业，但它彻底重塑了我的工作流和价值创造点。

4.1 初级与高级工程师的边界模糊，但“系统思维”的价值凸显

我那位直接把服务器账号密码交给WorkBuddy去搭ELK的同事，案例虽然极端，但指向一个事实：很多基于明确文档的、流程化的部署和配置工作，AI确实可以替代初级甚至中级工程师。写一个CRUD接口、实现一个已知算法的代码、配置一个标准中间件，这些任务的编码部分，AI的效率极高。 然而，这恰恰把“系统思维”和“架构设计”能力推到了更核心的位置。在我的巡检工具项目中，AI不知道应该设计哪几个检测维度，不知道DNS劫持检测该和风险链接检测并行还是串行，不知道检测结果应该如何设计数据模型以便于后续溯源分析。它也不知道在什么规模下该用SQLite，什么规模下该考虑MySQL分表，什么时候该引入消息队列来解耦抓取和分析任务。提出正确的问题，并将一个模糊的业务需求（“确保网站安全”）转化为一系列清晰、可执行、可验证的技术子问题，这个能力目前完全掌握在人的手中。高级工程师的价值，就在于他能设计出更优雅、更健壮、更可扩展的解决方案蓝图，而AI是卓越的蓝图执行者。

4.2 从代码实现者到安全逻辑的定义者与审查者

对于安全工程师而言，这种转变更为深刻。我们的核心价值从来就不在于写了多少行代码，而在于对威胁模型、攻击手法、防御体系的理解。

• 定义安全逻辑：AI可以写出扫描端口的代码，但它不知道为什么要扫描这些端口（哪些端口对应高危服务？）。AI可以写出匹配字符串的代码，但它不知道什么样的字符串模式可能代表Webshell（需要丰富的攻防经验）。AI可以生成告警规则，但它不知道如何设置合理的阈值以避免告警风暴（需要运营经验）。我的工作，变成了将这些隐性的安全知识，转化为AI能够理解的、精确的检测规则、算法描述和逻辑判断条件。
• 审查AI的“安全”：这是另一个至关重要的新角色。AI生成的代码本身安全吗？它使用的requests库是否默认关闭了SSL验证？（存在中间人攻击风险）。它构建的SQL查询是否会有注入漏洞？（即使使用ORM，复杂的查询也可能不安全）。它生成的蜜罐代码，会不会本身存在漏洞，反而成为攻击者入侵的跳板？我们必须以安全专家的眼光，去严格审查AI产出的每一段代码、每一个配置，这本身就是一项高价值的安全工作。你需要懂代码，才能审代码；你需要懂攻击，才能发现AI代码里潜在的脆弱点。

4.3 经验与判断：处理模糊性与应对未知威胁

AI擅长处理有明确模式、存在大量训练数据的问题。但安全攻防是高度动态和充满模糊地带的。

• 误报与漏报的权衡：我的巡检工具初版，基于规则检测“挂马”，误报率肯定很高。一个正常的广告脚本也可能使用eval。AI无法自行决定这个阈值该怎么调。是需要我结合历史告警、业务容忍度，通过大量测试样本去调整规则，还是应该引入机器学习模型？这个决策需要经验。
• 应对“零日”与未知手法：当一种全新的攻击手法或恶意代码混淆技术出现时，没有现成的训练数据。AI无法生成有效的检测代码。这时，需要安全研究员快速分析样本，归纳出特征，然后再指导AI去实现基于新特征的检测模块。从“未知”到“已知”的归纳和抽象能力，是人类研究员的专属领域。
• 业务上下文的理解：AI不知道公司哪个业务系统最重要，不知道“双十一”期间对官网的检测频率应该从每天提升到每小时，也不知道某个看似异常的链接可能是市场部合法的推广活动。将安全策略与业务节奏、风险承受度结合起来，做出恰当的判断和调整，这离不开人对业务的深度理解。

5. 给同行者的实操建议与避坑指南

基于我这段时间的“AI编程”实战，我总结了一些心得，或许对同样想尝试的安全同行或开发者有帮助。

5.1 如何设计有效的提示词（Prompt）

这是与AI协作的第一课，也是最重要的技能。

• 角色设定：在提示词开头明确AI的角色。“你是一个经验丰富的Python后端开发工程师，擅长编写安全可靠的网络爬虫和分析程序。”
• 任务分解：不要给一个巨无霸需求。像我一样，把大项目拆解成顺序执行或并行执行的小任务。一次对话聚焦一个模块。
• 提供上下文与约束：明确技术栈（“使用Python 3.10, Flask 2.3.x, SQLAlchemy 2.0”）、代码风格（“遵循PEP 8，使用类型注解”）、以及关键约束（“函数必须线程安全”、“避免使用已弃用的库”）。
• 输入输出示例：对于复杂逻辑，直接给出你希望的函数签名和调用示例。例如：“请编写函数def analyze_page(html: str, url: str) -> Dict[str, Any]:，它返回一个字典，包含external_links,suspicious_scripts,title等键。”
• 迭代与反馈：AI第一次生成的不一定完美。把错误信息、不满意的输出结果直接反馈给它，要求它修正。例如：“这个函数没有处理网络超时异常，请增加try-except块，并在超时后记录日志并返回None。”

5.2 必须亲力亲为的关键环节

有些事，AI目前还无法代劳，你必须牢牢抓在手里。

• 环境搭建与依赖管理：AI会给你requirements.txt，但不同库版本间的兼容性问题，需要你自己在真实环境中pip install并测试。虚拟环境（venv或conda）的使用必不可少。
• 代码审查与安全审计：这是红线。必须逐行审查AI生成的代码，特别是涉及网络通信、文件操作、命令执行、数据库查询和用户输入处理的部分。检查是否有硬编码的敏感信息（密钥、密码），权限设置是否过宽。
• 测试与集成调试：AI可能会生成一些单元测试，但整体的集成测试、边界条件测试、性能测试必须由你完成。编写测试用例本身，也是验证你对需求理解是否准确的过程。
• 架构决策与选型：用SQLite还是PostgreSQL？用Flask还是Django FastAPI？用APScheduler还是Celery？这些选型背后的考量（数据量、并发量、团队熟悉度、长期维护成本），需要你基于项目实际情况做出判断，并在提示词中明确告诉AI。

5.3 我踩过的“坑”与应对策略

1. “幻觉”与过时知识：AI可能会生成一个不存在的库函数，或者推荐使用已过时、有安全漏洞的库版本。对策：对AI提到的关键库和函数，快速去官方文档或PyPI页面核实。使用pip list和版本检查。
2. 代码“正确”但低效：AI生成的代码可能能运行，但算法复杂度高，或有内存泄漏风险。例如，在循环中重复解析相同的HTML。对策：对核心逻辑保持性能敏感，进行简单的复杂度分析，或使用小规模数据测试其性能。
3. 缺乏错误处理：AI生成的代码往往乐观路径（happy path）很完整，但对网络异常、文件不存在、数据格式错误等边缘情况处理不足。对策：在提示词中明确要求“添加完善的错误处理与日志记录”，并在审查时重点关注try-except块和错误返回。
4. 项目结构混乱：如果多次就不同模块提问，AI可能会给出不一致的导入路径或项目结构。对策：最好在一个对话线程中完成一个完整子系统的开发，或者，更推荐的方式是，由你自己维护一个核心的项目骨架，只让AI填充具体模块的文件内容。

5.4 工具链的整合：让AI融入你的工作流

单纯在网页聊天框里问，效率还是太低。我目前探索出两种更高效的模式：

• IDE插件深度集成：像通义灵码、GitHub Copilot这类插件，直接在VSCode或PyCharm里使用。它的好处是拥有完整的项目上下文，能进行更精准的代码补全、函数生成和注释编写。我写一个函数名，它就能帮我补全整个逻辑框架，非常流畅。
• “聊天+本地”结合：对于复杂的新功能模块设计，我依然会在Kimi或WorkBuddy里用自然语言描述清楚，让它生成初步代码。然后，我将代码复制到本地IDE，利用Copilot进行后续的修改、重构和调试。Copilot能基于现有代码上下文，给出更贴切的建议。

6. 未来已来：拥抱变化，聚焦高价值区

回过头看最初那个让我震惊的浏览器插件，它只是一个引子。真正的震撼在于，通过这一系列项目实践，我清晰地看到，AI编程不是未来，而是已经发生的现在。它不会取代工程师，但它会重新定义工程师的工作。

对于安全工程师，以及广大技术从业者，我的体会是：不要再把“熟练编写某种语言代码”作为核心竞争力的护城河。这条河正在被AI快速填平。我们应该将精力投向那些AI目前难以企及的领域：

1. 深度理解业务与风险：成为最懂公司业务逻辑和安全痛点的人。你能提出真正关键的安全需求。
2. 架构与系统设计能力：能够设计出弹性、可扩展、安全的技术方案，并清晰地将其拆解为AI可执行的任务。
3. 安全研究能力：保持对新型攻击手法、漏洞利用技术的研究，保持“黑客思维”。你是定义新检测规则、新防御模型的人。
4. 批判性思维与审查能力：对AI的输出保持审慎的乐观，具备强大的代码审查、安全审计和逻辑验证能力。
5. 沟通与协作：能够与非技术部门沟通风险，能够管理由“人类架构师”和“AI执行者”组成的混合团队。

AI是一个强大的杠杆，它放大了“思考”的价值，而弱化了“机械执行”的价值。作为安全工程师，我现在的感觉不再是焦虑，而是有些兴奋。我可以从繁琐的编码实现中解放出来，更专注于安全策略、攻防对抗、风险治理这些更本质、也更有挑战性的工作。用AI写完蜜罐的代码后，我可以花更多时间去思考：蜜罐捕获到的攻击payload有什么新特征？这些IP背后是哪个黑产团伙？他们的攻击路径是怎样的？如何调整整个网络的防御策略来应对？

这个过程，就像是从一名埋头挖战壕的士兵，开始学习如何指挥炮兵、分析敌情、制定作战计划。战壕依然要挖，但有了工程机械（AI）的帮助，我可以去规划更坚固、更高效的整个防御体系了。价值，正在这里发生转移和升华。