很多第一次接触 AI 编程的人会有一个误解项目资安是大公司安全团队的事自己不懂代码根本碰不了安全防护。实际上对普通项目来说数据泄露最常见的几个原因恰恰是最基础的问题比如密钥写进代码、权限拉满、日志缺失。这些问题不需要你成为安全专家也不需要你手写一套完整代码。借助 AI 编程工具把需求描述清楚让 AI 帮你生成扫描脚本、配置模板、日志代码和检查清单你只需要会复制、运行、看结果。这篇文章要拆的就是一套不懂代码也能照着做的五步项目资安流程。文章不会绕远讲安全理论而是直接按落地顺序来先搞清楚普通项目的数据泄露盲区再做资产盘点然后用 AI 写敏感信息扫描脚本接着配置权限和环境变量最后加上日志和每周检查。每一步都会给出提示词和判断标准方便你复现。1. 先搞清楚不懂代码的人做项目资安到底在做什么项目资安这个概念听起来很大但落到具体项目上核心就三件事敏感信息不裸奔、权限不失控、操作有记录。只要把这三件事做到普通项目的数据泄露风险就能降下一大半。难的不是技术而是很多人根本不知道自己的项目里有哪些敏感信息也不知道该从哪里开始检查。同一个项目如果让专业安全工程师来处理可能会从威胁建模、漏洞扫描、代码审计开始。但不懂代码的人如果也走这条路很容易卡在第一步。更现实的做法是把资安拆成可以执行的清单和脚本不追求一步到位先解决最容易出事的几个点。1.1 项目资安不等于会写安全代码很多教程一上来就讲缓冲区溢出、SQL 注入、权限提升这些内容对写代码的人都有门槛更不用说非技术背景。但对普通项目来说真正容易导致数据泄露的往往不是复杂的攻击手法而是配置层面的问题。比如 API 密钥直接写在源码里数据库口令放在项目根目录团队成员都有管理员权限离职员工的账号没有及时收回。这些问题不需要你理解安全算法只需要你愿意花时间检查文件、目录、权限和日志。AI 编程在这里的作用就是帮你自动生成检查工具把重复劳动替代掉。判断你的项目安全水位是否及格可以先看几个结果扫描脚本能不能查出敏感文件仓库是不是私有配置文件里有没有真实密钥日志能不能定位到某个操作的执行人和时间。如果这些都还没做项目就处在“裸奔”状态。1.2 数据泄露最常见的三个盲区第一个盲区是密钥放错位置。很多人为了方便把数据库地址、账号、密码、第三方服务的 API Key 直接写在一个 config 文件里然后又把这个文件提交到 Git 仓库。如果仓库是公开的等于把钥匙挂在门外。第二个盲区是权限拉满。项目初期几个人协作为了省事大家共用管理员账号或者把所有成员都设为所有者。一旦其中有人的账号被盗或者有人离职后账号没删攻击者就能直接接触全部数据。最小权限原则听起来专业实现起来并不难就是每个账号只给够用的权限不需要管理权限的账号一律不给。第三个盲区是没有日志和审计。很多项目根本没有记录“谁在什么时候做了什么操作”。等到数据泄露发生才发现无据可查连影响范围都评估不出来。日志不是给人看热闹的它是事后定位问题和界定责任的关键依据。这三个盲区恰好对应后面的四个步骤。你不用记住所有安全术语只要按步骤把盲区补上就行。2. 第一步用 AI 盘点项目资产和敏感信息做安全防护之前先要知道自己手里有什么。很多项目负责人对自己项目的依赖关系很清楚但问起哪些文件包含用户个人信息、哪些文件里有密钥、备份放在哪里就说不清了。资产盘点就是把这些问题用清单固定下来不需要你会代码只需要你会填表。这一步看起来不刺激但非常重要。后面扫描敏感文件、配置权限、加日志都是建立在盘点结果之上的。如果你连数据库连接串放在哪个文件都不知道扫描脚本跑出来的结果也很难判断是真是假。2.1 先列资产清单你不需要会代码找一个安静的时间打开项目目录把里面的东西按类型分几类源码、配置文件、文档、测试文件、备份文件、第三方服务信息。然后回答几个问题这个文件是给谁看的放在哪里里面有没有用户数据有没有密码或 Token如果泄露了会有什么影响不懂代码也没关系你不需要读懂源码逻辑。你只需要知道哪些文件存在里面大概是什么类型的信息。整理出来后可以直接用 AI 生成一个资产登记表模板再把内容填进去。如果你在用 VS Code、IntelliJ IDEA 这类编辑器也可以直接在 AI 编程插件里提问“请帮我生成一个项目安全资产盘点清单模板我需要登记敏感文件和访问权限。” 工具本身不是重点重点是你会不会把需求说清楚。2.2 一个可以直接用的 AI 编程提示词我一般会先用下面这段提示词让 AI 生成模板我是一名不懂代码的项目负责人。请生成一份项目安全资产盘点清单模板包含资产名称、类型、存放位置、负责人、是否包含用户个人信息、是否包含密钥/密码/Token、备份位置、访问权限。再生成一份敏感信息分级标准分公开、内部、敏感、机密四级每级给一个典型例子。AI 输出的结果通常是一份 Markdown 表格。你可以直接把它复制到项目根目录的 SECURITY.md 文件里或者放在自己的笔记软件中。注意不要填写真实密钥值只需要登记“哪一个文件存放了密钥、是否需要移除、负责人是谁”。资产盘点完成后至少要能回答三件事项目里有哪些敏感文件这些文件分别放在哪里哪些人应该能访问它们。如果盘点时发现某个密钥文件就在项目根目录而且没有进入忽略清单这就是第一个需要优先处理的高风险项。3. 第二步让 AI 生成敏感信息扫描脚本先解决密钥裸奔资产盘点靠人工看总会有遗漏。尤其是项目文件一多光靠肉眼找密钥非常不现实。更好的做法是让 AI 生成一个敏感信息扫描脚本自动遍历项目目录把包含 api_key、secret、token、password 等关键字段的文件和行号输出出来。这个脚本不需要写得多复杂核心功能就三个指定扫描目录跳过不必要的依赖目录输出命中结果。AI 编程工具最擅长这种“把需求翻译成代码”的事情你只需要把需求描述清楚。3.1 为什么“密钥写进代码”这么危险密钥写进代码不只是“不好看”的问题。如果代码仓库是私有的密钥暴露范围还小一点一旦仓库被设置成公开或者账号被盗攻击者拿到密钥就可能直接访问你的数据库、云服务、第三方接口。更要命的是很多人在发现密钥被提交后只是把本地文件删掉重新提交一次。但实际上Git 仓库的历史记录里仍然留着旧版本。只要别人拿到仓库历史依然能翻出当时的密钥。所以正确的处理顺序是先扫描再移除然后轮换密钥而不是简单删文件。3.2 一个可以运行的最小示例下面这个 Python 脚本是通用示例你可以直接让 AI 按你的需求重新生成不必完全照抄。import os import re SCAN_DIR . patterns [ r(?i)api[_-]?key\s*[:]\s*[\][^\][\], r(?i)secret\s*[:]\s*[\][^\][\], r(?i)token\s*[:]\s*[\][^\][\], r(?i)password\s*[:]\s*[\][^\][\] ] skip_dirs {.git, node_modules, venv, .venv, __pycache__} for root, dirs, files in os.walk(SCAN_DIR): dirs[:] [d for d in dirs if d not in skip_dirs] for name in files: path os.path.join(root, name) try: with open(path, r, encodingutf-8, errorsignore) as f: for line_no, line in enumerate(f, 1): for pattern in patterns: if re.search(pattern, line): print(f{path}:{line_no}: {line.strip()[:120]}) except Exception as e: print(fskip {path}: {e})你可以把 SCAN_DIR 改成想扫描的目录比如项目根目录或某个子目录。skip_dirs 里是常见的依赖和版本控制目录跳过它们可以避免大量无关输出。脚本执行后的输出格式是“文件路径:行号:命中的内容”。让 AI 生成时我会用这段提示词我是一名新手。请帮我写一个 Python 脚本扫描指定目录下所有文件查找包含 api_key、secret、token、password 的行跳过 .git、node_modules、venv、.venv、pycache目录。输出文件路径、行号和命中的内容不要包含任何网络请求逻辑。运行方式也很简单。把脚本保存为 scan_sensitive.py在终端执行python scan_sensitive.py如果没有安装 Python可以让 AI 生成 PowerShell 版本的脚本思路一样运行环境不同而已。运行结果怎么判断如果脚本输出了一些文件路径每条都要人工看一遍。命中的内容如果是your_api_key、xxxx、example这类示例值通常不是泄露如果是看起来像真实密钥、账号、密码的内容就要立刻处理。如果脚本完全没有输出除了说明暂时没扫到常见模式并不能证明绝对安全。我会建议先故意创建一个测试文件里面写一行api_key fake_test_123456再跑一次确认脚本本身是有效的。注意使用 AI 编程工具时不要把真实密钥或完整数据库内容粘贴到对话里。你要的是生成检查代码不是让 AI 帮你保存敏感信息。4. 第三步用 AI 配置权限和环境变量把访问控制补上扫描出敏感文件之后下一步不是删文件那么简单而是要把访问控制补上。这一步的核心思路是代码和数据分开配置和源码分开权限按最小够用原则分配。不懂代码的人最容易忽略的一点是权限不仅仅指仓库成员权限还包括服务器账号权限、数据库账号权限、文件读写权限。这些内容都可以通过配置完成不一定需要写业务代码。4.1 最小权限原则先回答三个问题配置权限之前先问自己三个问题谁需要访问这个项目他需要读、写还是管理员权限离职或调岗的人账号是否已经收回如果项目在 Git 平台上就去成员管理页面看一遍把不是当前协作者名单里的人清理掉。如果项目部署在服务器上不要直接用 root 账号跑应用给应用单独建一个普通账号只授予项目目录和日志目录的读写权限。数据库账号同理能只读就不要给写权限能限制 IP 就不要对所有来源开放。这些操作听起来偏运维但 AI 编程工具完全可以帮你生成检查清单和操作步骤。你可以直接问“请给我一份服务器权限检查清单包含普通用户创建、项目目录权限设置、数据库账号最小权限配置的步骤。” 让 AI 把每一步拆细你照着执行。4.2 把密钥从代码里移到 .env 和配置模板很多人觉得环境变量麻烦因为要多建一个文件还要在代码里读取。但这个麻烦非常值得因为它的作用就是把密钥从源码里剥离出来。常见做法是项目里放两个文件.env 保存真实配置但它不应该提交到仓库.env.example 只保留变量名和空值或示例值提交到仓库方便别人参考。你可以在 AI 编程工具里提出这样的需求请帮我生成一个示例功能是项目使用 .env 文件读取数据库连接和 API 密钥提供 .env.example 模板给出一段 Python 代码用 os.environ.get 读取这些配置避免在代码中硬编码密钥。一个简单的 .env.example 长这样DB_HOSTlocalhost DB_PORT3306 DB_USERyour_user DB_PASSWORDyour_password API_KEYyour_api_key对应读取配置的代码可以是import os from dotenv import load_dotenv load_dotenv() db_host os.getenv(DB_HOST, localhost) db_password os.getenv(DB_PASSWORD, ) api_key os.getenv(API_KEY, )这一段代码不需要你完全理解知道它是从 .env 文件里读配置就够了。关键是本地 .env 文件要加入 .gitignore避免被提交。如果你不懂 .gitignore直接问 AI“请帮我生成一个适合这个项目的 .gitignore确保 .env 文件不会被提交。”5. 第四步让 AI 生成日志和异常检查给项目留证据数据泄露发生之后最尴尬的场景不是“我们被攻击了”而是“我们不知道对方做了什么”。很多项目平时完全不记日志或者日志只记录业务成功和失败不记录权限变更、数据导出、配置修改这类敏感行为。等到需要追溯时根本没有证据。日志这件事不需要一开始做得很重。普通项目先记录四个关键动作登录、权限变更、敏感数据导出、配置修改。再加一个异常错误记录基本就能覆盖多数排查场景。5.1 日志作用没有日志泄露后无法评估影响假设有一天你发现数据库里的用户数据被导出了。如果系统没有任何日志你可能连以下问题都答不上来对方是什么时候进来的是通过哪个账号进来的导出的是哪些表导出了多少量有没有后续的权限变更只要日志覆盖了登录、权限变更、数据导出、配置修改这些问题大多可以回答。这也是为什么安全审计特别看重日志。对不懂代码的人来说不需要理解日志框架的底层原理只需要让 AI 帮你生成一个写入文件的简单模块并确认它能正常记录就行。5.2 最简日志示例和提示词下面是一个使用 Python logging 的极简示例import logging logging.basicConfig( filenameapp.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) logging.info(user login: user_id1001) logging.warning(update config without admin permission)这里的关键参数是 filename日志会写到 app.log 文件format 定义了每条日志的时间、级别和内容。实际项目中不会直接调用这么简单的配置但思路一致。你可以让 AI 生成一个更完整的模块请帮我写一个 Python 日志模块使用 logging输出到 logs/app.log记录登录、权限变更、数据导出、配置修改、异常错误每条日志包含时间、级别、事件类型、操作人和结果。不要把密码和 token 写进日志。生成之后记得检查两个点logs 目录是否存在应用是否有权限往里面写文件日志里是否出现了明文密钥。如果日志文件放在项目根目录或网页根目录还要确认它不能被外部直接访问否则日志本身也会成为泄露渠道。6. 第五步把安全动作变成每周可执行的固定检查如果你只做一次资产盘点和扫描项目安全只能维持很短时间。因为代码会变人员会变配置会变。新入职的同事可能无意中把一个 .env 文件提交到仓库外包人员可能需要临时服务器权限配置文件也可能在新版本里被改坏。所以最后一步是把安全工作变成周期性的固定检查而不是一次性的补救。6.1 不要做完一次就结束设计固定检查清单建议用表格来管理检查项下面这个表可以按需调整检查项频率判断标准敏感信息扫描每周扫描脚本无真实密钥输出仓库成员和权限每月无离职/陌生账号权限最小化密钥轮换每月或泄露时旧密钥已停用新密钥未写进代码日志检查每周关键行为有记录无异常登录备份恢复每月备份文件能够正常恢复这个表不用做得很重但要有负责人。如果你是一个人维护项目负责人就是你自己。填完之后每周末花十五分钟跑一次扫描、看一遍日志就能避免绝大多数配置类泄露。6.2 用 AI 生成一个每日检查脚本而不是靠记性人工记忆不可靠更稳妥的方式是写一个简单的检查脚本每天或每周自动输出机器状态。下面是一个可以在自己服务器或本机执行的 bash 示例#!/usr/bin/env bash echo disk df -h echo open ports ss -tuln 2/dev/null || netstat -tuln echo recent ssh login last -n 20 2/dev/null | head -n 20 echo log size du -sh logs/ 2/dev/null保存为 check_security.sh 后在终端执行bash check_security.sh。它的作用是帮你快速了解磁盘空间、开放的端口、最近的登录记录和日志目录大小。看到异常端口时再进一步排查对应的进程和用途。同样你可以让 AI 按你的系统生成 PowerShell 版或 Python 版。但注意一点这类检查脚本要在自己的项目机器上运行不要拿它去扫描别人的服务器。安全检查和未授权探测是完全两回事。7. 最后留几条排查链路和边界认识最后这部分是给实际操作中遇到的问题留几条排查顺序。很多人一遇到脚本报错就慌其实大多数问题都能从输入、环境、路径、权限这几层找原因。7.1 常见现象和排查顺序很多初学者会卡在这些地方。下面按现象给出排查顺序现象可能原因优先排查顺序扫描脚本启动失败没有安装 Python、文件编码错误、路径有空格先看控制台第一行报错再确认python --version再检查脚本保存路径扫描结果为空扫描目录不对、跳过目录太多、正则不匹配先造一个测试文件验证脚本再确认 SCAN_DIRGit 已经提交过敏感文件仓库历史里有残留不要只删本地文件先轮换密钥再从当前仓库移除敏感文件日志不写入logs 目录不存在、没有写权限检查目录是否存在查看应用的运行账号是否有写权限配置文件被外部访问项目公开、服务器目录配置不当先设置仓库私有再移走敏感文件最后扫描历史记录还有一个必须重点强调的场景如果真实密钥已经提交到公开仓库不要抱着侥幸心理只删文件。攻击者可能早就抓取过仓库历史。正确的做法是立即到相关平台重置密钥或生成新密钥然后让旧密钥失效再清理仓库中的敏感文件。这个动作越快越好。7.2 AI 编程能做和不能做的事它能做的是帮你生成扫描脚本、日志模块、权限检查清单、配置模板帮你解释报错帮你把一个复杂命令翻译成一二三四步。它很适合替代重复性检查和前期排查。但它不能代替你判断业务上下文。AI 不知道你的某个文件是不是真的包含敏感数据也不知道某个日志操作是否正常。它生成的代码可能有误报也可能漏报。更重要的是不要把整个企业内部项目的源码、真实数据库地址、客户数据、完整密钥直接发给外部 AI要先确认你所在环境的合规要求。涉及真实敏感信息时宁可把变量名和类型说清楚让 AI 生成通用代码再自己填入脱敏后的示例值。如果你现在只来得及做一件事我建议先跑一遍敏感信息扫描。很多数据泄露案例不是攻击者技术多高明而是密钥一直躺在仓库里没人管。等你能把扫描、权限、日志、每周检查串起来项目才算真正有了基本的安全底线。AI 编程不会让你一夜之间变成安全专家但它能帮你把高频、重复、容易遗漏的检查工作提前做完。剩下来的判断和复盘仍然要靠你。