前言

  1. 技术背景：在现代网络攻防体系中，信息收集是决定成败的第一步，也是贯穿始终的核心环节。我们常说“未知攻，焉知防”，而“自动化发现和打包高价值数据”正是信息收集中最高效的战术之一。它处于整个攻击链（Kill Chain）的最前端——**侦察（Reconnaissance）**阶段，旨在通过非侵入性或低交互的方式，从海量公开信息中精准定位、提取并结构化存储目标的关键数据，为后续的漏洞发现、权限提升乃至横向移动提供精确制导。

  2. 学习价值：掌握本教程中的技术，您将能够解决以下核心问题：

    • 效率瓶颈：从手动、零散地搜集信息，转变为自动化、系统化地进行数据侦察，将原本数天甚至数周的工作压缩到分钟级别。
    • 信息过载：学会如何从庞杂的互联网数据中过滤噪音，精准识别出如API密钥、内部系统地址、员工凭证、敏感文件等具有直接利用价值的高价值情报。
    • 成果固化：将发现的数据自动化地进行分类、去重和打包，形成标准化的情报报告，便于团队协作和后续工具链的调用。

  3. 使用场景：这项技术的实际应用场景非常广泛，是专业安全从业者的必备技能：

    • 授权渗透测试：在获得客户授权后，快速摸清其资产暴露面，寻找被遗忘的子域名、泄露的开发凭证或未受保护的后台接口。
    • 红蓝对抗演练：作为攻击方（红队），模拟真实黑客攻击路径，通过自动化侦察快速找到突破口。
    • 企业安全自查：作为防御方（蓝队），定期扫描自身的公开信息，主动发现并移除泄露在外的敏感数据，防患于未然。
    • 漏洞赏金计划（Bug Bounty）：高效地在大量目标中寻找泄露的API密钥、配置文件等低悬挂果实，是提升赏金猎人竞争力的关键。

一、信息泄露的本质与自动化发现是什么

精确定义

信息泄露（Information Leakage），特指系统或应用在非预期的情況下，将敏感数据显示给非授权角色的现象。而自动化发现与打包高价值数据，则是利用脚本或工具，模拟人工审查行为，通过大规模扫描公开信息源（如GitHub、GitLab、网盘、代码仓库、搜索引擎缓存等），基于预设的规则（如正则表达式），自动识别、提取并整理这些泄露的敏感信息的过程。

一个通俗类比

想象一下，你是一名寻宝猎人，目标是寻找城市里遗落的“金币”（高价值数据）。

  • 传统方式：你只能徒步在城市的每一条街道（网站/服务器）上，用肉眼仔细寻找。这种方式效率低下，且容易错过藏在角落里的金币。
  • 自动化方式：你现在拥有了一支由无数微型无人机组成的“侦察蜂群”（自动化脚本）。你给它们设定了“金币”的特征（正则表达式），然后将它们释放到整个城市。它们会自动飞遍所有角落（扫描代码仓库），一旦发现符合特征的物体，就会立刻拍照（提取代码片段）、记录GPS位置（URL），并自动将所有发现汇总成一张标注清晰的藏宝图（结构化报告）交给你。

这个“侦察蜂群”就是我们的自动化发现技术。它将繁琐的体力劳动，变成了高效、精准的智能化侦察。

实际用途
  • 发现硬编码凭证：开发者图方便，将数据库密码、API密钥、云服务访问凭证（AK/SK）直接写在代码里并上传到公开的GitHub仓库。
  • 定位内部系统：在前端JavaScript文件或泄露的配置文件中，找到内部管理后台、测试环境、API网关的URL地址。
  • 获取敏感业务数据：从被错误公开的.sql、.csv、.bak文件中，直接下载到用户数据、订单信息等。
  • 识别技术栈与漏洞：通过分析泄露的package.json、pom.xml等依赖文件，快速了解目标技术栈，为后续利用已知漏洞（N-day）提供线索。
技术本质说明

自动化信息发现的技术本质是**“大规模模式匹配”。无论是代码、文档还是日志，其本质都是字符串。高价值的敏感信息（如密钥、密码、身份证号）通常具有非常明显的“结构特征”**。例如，AWS的Access Key通常以AKIA开头，后面跟着16个大写字母或数字。

我们利用这些结构特征，编写成正则表达式（Regular Expression），然后通过自动化工具在海量的数据源中进行高速检索。一旦字符串匹配成功，就意味着我们很可能发现了一条潜在的敏感信息。整个过程可以用下面的Mermaid图清晰地展示其工作流程。

自动化信息发现原理图

处理与产出阶段

执行阶段

准备阶段

GitHub/GitLab

网盘/文库

搜索引擎

匹配规则

是

有效

否

定义侦察目标

配置关键词与规则

选择信息源

API/爬虫大规模扫描

发现潜在敏感信息

提取上下文代码/文本

验证信息有效性

分类、去重并结构化存储

生成情报报告

丢弃

这张图清晰地展示了从设定目标、选择扫描源，到自动化执行扫描、匹配规则，再到最后验证和产出报告的完整闭环。

二、环境准备

为了复现本教程的实战部分，我们将使用一款强大且广受好评的开源信息泄露扫描工具：Gitleaks。它专门用于检测Git仓库中的硬编码密钥、密码等敏感信息。

  • 工具名称：Gitleaks
  • 工具版本：v8.18.2 或更高版本
  • 项目地址：https://github.com/gitleaks/gitleaks
下载方式

Gitleaks提供了多种安装方式，这里介绍最常用的几种。

  1. macOS (使用Homebrew):

    brew install gitleaks

  2. Go 安装 (适用于已配置Go环境的用户):

    go install github.com/gitleaks/gitleaks@latest

  3. 直接下载二进制文件 (推荐，通用性最强):
    访问Gitleaks的 Releases页面，根据你的操作系统（Windows, Linux, macOS）和CPU架构（amd64, arm64）下载对应的压缩包，解压后即可使用。

核心配置命令

Gitleaks的核心在于其规则配置文件。虽然它内置了大量高质量的默认规则，但在实战中我们常常需要自定义规则来发现特定目标的信息。

  1. 生成默认配置文件：
    首先，我们可以生成一份默认的配置文件作为参考和修改的基础。

    # 该命令会在当前目录下生成一个名为 gitleaks.toml 的文件
gitleaks generate-config --config="gitleaks.toml"

  2. 自定义规则示例：
    打开gitleaks.toml文件，你可以看到许多[[rules]]块。我们来添加一条自定义规则，用于匹配一个虚构的公司内部Token，格式为corp-token-[32位小写字母或数字]。

    # 在 gitleaks.toml 文件末尾添加以下内容
[[rules]]
description = "Corp Internal Token"
id = "corp-internal-token"
regex = '''corp-token-[a-z0-9]{32}'''
secretGroup = 1
tags = ["corp", "internal", "token"]
    • description: 规则描述，方便理解。
    • id: 规则的唯一标识。
    • regex: 核心，用于匹配的正则表达式。
    • tags: 标签，用于分类和过滤。
可运行环境命令或 Docker

为了方便快速部署和隔离环境，使用Docker是最佳选择。

  1. 拉取Gitleaks的Docker镜像:

    docker pull zricethezav/gitleaks:latest

  2. 使用Docker运行Gitleaks扫描本地仓库:
    假设你的项目代码位于/path/to/your/project，你可以这样扫描：

    # 将本地项目目录挂载到容器的/tmp/目录，并对该目录进行扫描
docker run --rm -v /path/to/your/project:/tmp/ zricethezav/gitleaks:latest detect --source="/tmp/" -v

  3. 使用Docker扫描远程GitHub仓库:

    # --no-git 选项告诉gitleaks不要尝试克隆，直接扫描URL指向的在线仓库
docker run --rm zricethezav/gitleaks:latest detect --repo-url=https://github.com/gitleaks/gitleaks -v

通过以上准备，你已经拥有了一个功能完备、配置灵活的自动化信息发现环境。

三、核心实战

本节将通过一个完整的、可复现的示例，带你从零开始体验自动化发现和打包高价值数据的全过程。我们将模拟一个场景：对一个公开的GitHub项目进行安全审计，寻找其中可能泄露的敏感信息。

攻击演示目标：我们将使用一个专门为此类教学目的创建的“靶场”项目：https://github.com/gitleakstutorial/my-vulnerable-app。这个项目故意包含了一些硬编码的密钥。

❗ 警告：以下所有操作仅限在授权测试环境或教学靶场中进行。未经授权的扫描属于违法行为。

步骤一：克隆目标仓库

目的：获取需要审计的全部代码历史记录。Gitleaks不仅会扫描当前的代码，还会深入挖掘每一次提交（commit）的历史，这是其强大之处。

# 克隆教学用的靶场项目到本地
git clone https://github.com/gitleakstutorial/my-vulnerable-app
# 进入项目目录
cd my-vulnerable-app

输出结果：
终端会显示克隆进度，并在当前目录下创建一个名为my-vulnerable-app的文件夹。

步骤二：执行本地扫描

目的：使用Gitleaks对本地仓库进行全面扫描，发现潜在的泄露。

请求/命令：

# 在 my-vulnerable-app 目录下执行
# --source="." 表示扫描当前目录
# --report-path="leaks-report.json" 将结果保存为JSON格式的报告
# --verbose 或 -v 提供更详细的输出
gitleaks detect --source="." --report-path="leaks-report.json" --verbose

响应/输出结果：
Gitleaks会开始扫描，并实时在终端输出发现的泄露点。最终，你会看到类似下面的输出，表明发现了多个问题，并已生成报告。

{
  "Description": "AWS Access Key",
  "StartLine": 12,
  "EndLine": 12,
  "StartColumn": 21,
  "EndColumn": 41,
  "Match": "AKIAIOSFODNN7EXAMPLE",
  "Secret": "AKIAIOSFODNN7EXAMPLE",
  "File": "config.py",
  "Commit": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
  "Author": "Test User",
  "Email": "test@example.com",
  "Date": "2026-03-23T10:00:00Z",
  "RuleID": "aws-access-key",
  "Tags": ["key", "aws"]
},
{
  "Description": "Generic API Key",
  "StartLine": 15,
  "EndLine": 15,
  "StartColumn": 18,
  "EndColumn": 50,
  "Match": "api_key = 'abcdef1234567890abcdef1234567890'",
  "Secret": "abcdef1234567890abcdef1234567890",
  "File": "main.py",
  "Commit": "f6e5d4c3b2a1f6e5d4c3b2a1f6e5d4c3b2a1f6e5",
  "Author": "Test User",
  "Email": "test@example.com",
  "Date": "2026-03-23T11:00:00Z",
  "RuleID": "generic-api-key",
  "Tags": ["key", "api"]
}
... (其他发现)

同时，目录下会生成一个leaks-report.json文件，里面包含了所有泄露的详细信息，这就是我们“打包”好的高价值数据。

步骤三：分析报告并验证

目的：对自动化工具发现的结果进行人工确认，排除误报，并评估泄露信息的实际危害。

打开leaks-report.json文件，我们可以清晰地看到：

  • 在config.py文件中，发现了一个符合AWS Access Key特征的字符串。
  • 在main.py文件中，发现了一个通用API密钥。
  • 报告还包含了泄露所在的文件、行号、提交哈希、作者等关键信息，极大地方便了溯源和修复。

接下来，你可以尝试使用这些“泄露”的密钥去访问对应的服务（在真实测试中），以验证其有效性。

自动化脚本示例

在大型渗透测试项目中，我们往往需要扫描成百上千个目标。手动执行上述命令效率低下。下面是一个简单的自动化Shell脚本，可以读取一个包含多个GitHub仓库地址的列表文件，并依次进行扫描和报告。

脚本 (scan_repos.sh):

#!/bin/bash

# 脚本功能：批量扫描GitHub仓库中的敏感信息泄露
#
# ❗ 警告：本脚本仅可用于经授权的渗透测试或安全审计。
# 未经授权的扫描是违法行为，使用者需自行承担所有法律责任。

# --- 参数定义 ---
# 仓库列表文件，每行一个GitHub仓库URL
REPO_LIST_FILE="${1:-repos.txt}"
# 报告输出目录
OUTPUT_DIR="${2:-reports}"

# --- 错误处理与检查 ---
# 检查gitleaks是否已安装
if ! command -v gitleaks &> /dev/null; then
    echo "[ERROR] gitleaks 未安装或不在PATH中。请先安装gitleaks。"
    exit 1
fi

# 检查仓库列表文件是否存在
if [ ! -f "$REPO_LIST_FILE" ]; then
    echo "[ERROR] 仓库列表文件 '$REPO_LIST_FILE' 不存在。"
    echo "用法: $0 [仓库列表文件] [报告输出目录]"
    exit 1
fi

# 创建报告输出目录
mkdir -p "$OUTPUT_DIR"

echo "[INFO] 开始批量扫描，仓库列表: $REPO_LIST_FILE"
echo "[INFO] 报告将保存在: $OUTPUT_DIR"

# --- 核心循环 ---
while IFS= read -r repo_url || [[ -n "$repo_url" ]]; do
    if [[ -z "$repo_url" || "$repo_url" =~ ^# ]]; then
        # 跳过空行和注释行
        continue
    fi

    echo "--------------------------------------------------"
    echo "[INFO] 正在扫描: $repo_url"

    # 从URL中提取仓库名，用于命名报告文件
    # 例如：https://github.com/owner/repo.git -> owner_repo
    repo_name=$(echo "$repo_url" | sed -E 's/https?:\/\/[^\/]+\/([^\/]+\/[^\/]+)(\.git)?/\1/' | tr '/' '_')
    report_file="$OUTPUT_DIR/${repo_name}.json"

    # 执行gitleaks扫描
    # --repo-url: 直接扫描远程仓库，无需克隆
    # --exit-code 0: 即使发现泄露，也正常退出，以便脚本继续执行
    gitleaks detect --repo-url="$repo_url" --report-path="$report_file" --exit-code 0 --verbose

    # 检查报告是否生成以及是否包含内容
    if [ -s "$report_file" ]; then
        echo "[SUCCESS] 发现潜在泄露！报告已生成: $report_file"
    else
        echo "[INFO] 未发现泄露，已生成空报告: $report_file"
    fi

done < "$REPO_LIST_FILE"

echo "--------------------------------------------------"
echo "[INFO] 所有仓库扫描完成。"

使用方法：

  1. 创建一个名为repos.txt的文件，内容如下： 
    # 这是需要扫描的仓库列表
https://github.com/gitleakstutorial/my-vulnerable-app
https://github.com/some-other/public-project
  2. 赋予脚本执行权限：chmod +x scan_repos.sh
  3. 运行脚本：./scan_repos.sh repos.txt reports

脚本会自动为每个仓库创建一个JSON报告，并存放在reports目录下，实现了“自动化发现与打包”的完整流程。

四、进阶技巧

常见错误

  1. 误报（False Positives）：最常见的问题。例如，一个随机生成的示例ID ex-ak-1234567890abcdef 可能会被误判为某个平台的密钥。

    • 解决方法：通过在规则中加入entropy（信息熵）阈值或更精确的上下文关键词（如keywords = ["aws_access_key_id"]）来减少误报。对于无法避免的误报，可以在代码中添加gitleaks:allow注释来忽略特定行的告警。

  2. 扫描不完整：只扫描了当前分支，忽略了历史提交和其它分支。

    • 解决方法：确保使用gitleaks detect命令时没有附带--no-git（除非是扫描远程URL）或限制扫描深度的参数（如--depth）。默认情况下，Gitleaks会扫描整个仓库历史。

  3. 性能问题：扫描一个包含数百万次提交的巨型仓库（如Linux内核）可能会非常缓慢且消耗大量内存。

    • 解决方法：使用--log-opts参数来指定扫描范围，例如只扫描最近一个月的提交：--log-opts="--since='1 month ago'"。
性能 / 成功率优化
  • 优化正则表达式：避免使用过于宽泛的匹配，如.*。尽可能使你的正则表达式具体化，这不仅能提高准确率，也能提升扫描速度。
  • 使用Git的--filter=blob:none克隆：对于只需要扫描代码而不需要完整历史的项目，可以使用浅克隆或无blob克隆来大幅减少下载的数据量，然后再进行扫描。
  • 结合其他信息源：Gitleaks专注于Git，但真正的自动化侦察应该是一个组合拳。结合使用子域名扫描工具（如subfinder）、端口扫描工具（如nmap）、以及针对JavaScript文件的分析工具（如LinkFinder），可以构建一个更全面的自动化侦察系统。
实战经验总结
  • 关注“非主流”代码托管平台：除了GitHub，不要忘记检查目标的GitLab、Bitbucket、甚至自建的Gitea/Gogs实例。很多时候，安全防护较弱的自建平台是泄露的重灾区。
  • 配置文件是金矿：相比于源代码，*.conf, *.yml, *.properties, .env, web.config这类配置文件包含硬编码凭证的概率更高。可以编写专门的规则集优先扫描这些文件。
  • 历史记录中的“宝藏”：开发者可能在某次提交中加入了密钥，然后在后续提交中删除了它。代码的当前版本看起来是干净的，但密钥永远地留在了Git历史中。这正是Goleaks这类工具的核心价值所在。
对抗 / 绕过思路

作为攻击方，你需要了解目标可能会如何防御，从而绕过这些防御。

  • Base64或其他编码：开发者可能会将密钥进行Base64编码，以“混淆”扫描器。
    • 绕过：在你的自定义规则中，可以先匹配Base64的特征（例如，一长串由字母、数字、+、/、=组成的字符串），然后编写一个后处理脚本，对匹配到的结果进行解码验证。更高级的扫描器支持在规则中定义解码步骤。
  • 密钥分段存储：将一个完整的密钥拆分成多个部分，在使用时再拼接起来。
    • api_key_part1 = "abcde"
    • api_key_part2 = "12345"
    • api_key = api_key_part1 + api_key_part2
    • 绕过：这种方式对基于单行正则表达式的扫描器是有效的防御。绕过它需要更高级的静态代码分析（SAST）工具，能够理解代码的上下文和变量的传递关系。对于简单的场景，可以尝试匹配变量名，如api_key_part。
  • 使用密钥管理服务（KMS）：这是最安全的做法，代码中只存储一个指向KMS的引用。
    • 绕过思路：攻击思路从“寻找代码中的密钥”转变为“寻找能够访问KMS的凭证或配置漏洞”。侦察的重点变成了寻找云环境的配置错误（如IAM策略过于宽松）、服务账户的泄露凭证等。

五、注意事项与防御

本节从防御者的视角出发，讲解如何避免信息泄露，以及在泄露发生后如何检测和响应。

错误写法 vs 正确写法

  • 错误写法（硬编码）:

    # config.py
DB_PASSWORD = "my-super-secret-password-123"

  • 正确写法（使用环境变量）:

    # config.py
import os

# 从环境变量中读取密码，如果不存在则返回None
DB_PASSWORD = os.getenv("DATABASE_PASSWORD")

if not DB_PASSWORD:
    raise ValueError("环境变量 DATABASE_PASSWORD 未设置！")

    在部署时，通过系统环境变量或.env文件（并确保.env文件已被加入.gitignore）来提供密码。

风险提示
  • 切勿将.env文件提交到Git仓库：这是最常见也是最低级的错误。务必在项目初始化时就将.env加入到.gitignore文件中。
  • 警惕CI/CD日志：构建和部署过程中的日志也可能打印出敏感信息。确保在CI/CD流程中关闭调试输出，或对敏感变量进行屏蔽。
  • Fork的仓库同样危险：即使你的主仓库是私有的，但如果团队成员fork了项目到自己的公开账户，那么所有历史记录都会被公开。
开发侧安全代码范式
  1. 使用密钥管理系统（KMS）：对于生产环境，应始终使用专业的密钥管理服务，如AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault。应用程序在启动时通过安全的认证机制（如IAM角色）从KMS动态获取密钥。
  2. 实现配置与代码分离：严格遵守十二因子应用（The Twelve-Factor App）原则中的第三条：在环境中存储配置。
  3. 集成Pre-commit钩子：在开发人员本地的Git环境中集成gitleaks作为pre-commit钩子。这样在执行git commit时会自动进行一次快速扫描，从源头上阻止包含密钥的提交。 
    # .pre-commit-config.yaml
repos:
-   repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
    -   id: gitleaks
运维侧加固方案
  1. 在CI/CD流水线中集成扫描：将gitleaks扫描作为代码合并（Merge Request / Pull Request）前的强制检查步骤。一旦发现泄露，流水线应立即失败并阻止合并。
  2. 定期巡检所有代码仓库：对组织内所有的代码仓库（包括历史遗留项目）进行定期的、全面的自动化扫描，并生成安全报表。
  3. 密钥轮换（Key Rotation）：建立制度化的密钥轮换策略。即使密钥发生泄露，也能在短时间内使其失效，从而将风险窗口降至最低。
日志检测线索

如果你怀疑自己的组织已经发生了密钥泄露，可以从以下日志中寻找线索：

  • 云服务访问日志（如AWS CloudTrail）：
    • 线索：发现来自异常地理位置、异常IP地址（非公司出口IP或服务器IP）的API调用。
    • 线索：一个平时很少被使用的Access Key突然产生了大量活动。
    • 线索：出现大量“权限被拒绝（Access Denied）”的日志，这可能是攻击者在使用一个低权限密钥进行横向探测。
  • 应用访问日志：
    • 线索：在非工作时间，或通过不常见的客户端（User-Agent）访问敏感API接口。
  • GitHub等平台的审计日志：
    • 线索：检查是否有非预期的用户被添加为协作者，或者仓库被设置为公开。

总结

  1. 核心知识：自动化信息发现的本质是利用正则表达式等模式匹配技术，在GitHub等海量信息源中大规模、高速地寻找具有特定结构特征的敏感信息（如API密钥、密码）。
  2. 使用场景：此技术是授权渗透测试、红蓝对抗、企业自查和漏洞赏金等活动中进行高效侦察的核心手段。
  3. 防御要点：防御的核心思想是“配置与代码分离”。绝对不要将任何形式的凭证硬编码在代码中。应使用环境变量，并最终采用专业的密钥管理服务（KMS）来管理密钥生命周期。
  4. 知识体系连接：自动化信息发现是整个攻击链的起点，它直接服务于后续的**初始访问（Initial Access）和凭证访问（Credential Access）**阶段。同时，它也是DevSecOps体系中“左移”安全思想的重要实践，通过在CI/CD流程中集成扫描，将安全卡点前置到开发阶段。
  5. 进阶方向：
    • 语义化分析：超越正则表达式，利用AST（抽象语法树）或机器学习模型理解代码上下文，以更精准地识别泄露（例如，区分真实的密钥和文档中的示例密钥）。
    • 多源情报融合：构建一个能融合代码泄露、子域名信息、端口服务、人员信息等多维度情报的自动化侦察平台。
    • 闭环与自动化响应：不仅要发现，还要能自动化地响应。例如，一旦发现AWS密钥泄露，能自动调用AWS API将其禁用，并立即通知相关负责人。

自检清单

  • 是否说明技术价值？ (是，在前言中明确了其在攻防体系中的位置和解决的问题)
  • 是否给出学习目标？ (是，在前言中列出了学会后能解决的效率、信息过载等问题)
  • 是否有 Mermaid 核心机制图？ (是，在“是什么”部分提供了清晰的流程图)
  • 是否有可运行代码？ (是，提供了完整的Gitleaks命令和可运行的自动化Shell脚本)
  • 是否有防御示例？ (是，在“注意事项与防御”部分给出了错误与正确的代码范式)
  • 是否连接知识体系？ (是，在总结部分将其与攻击链、DevSecOps等体系关联)
  • 是否避免模糊术语？ (是，对关键术语如“信息泄露”、“硬编码”等都进行了解释或提供了上下文)
# 自动化 # 运维 # 网络安全
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

32.一次 AI Native 项目收口：把 PaperPilot 从面试 Demo 推向企业级科研 Agent 产品

今天继续推进了我的个人项目。这个项目最初是为了支撑 AI 应用工程 / RAG / Agent 方向的求职面试，但随着最近在真实业务项目中的实习经历，我越来越明显地感觉到：未来的软件工程师不再只是“手写代码的人”，而是要能够基于 Cursor、Claude Code、Codex、Gemini CLI 等 AI Coding 工具，完成需求理解、架构设计、代码生成、审查、测试和持续演进的人。

avatar AtomGit开源社区

# FIVEOS AI智能编程测试说明

本文介绍了FIVEOSAI智能编程测试环境的构建与应用。该测试环境旨在研究AI辅助编程工具如何受训练数据中潜在问题的影响，通过"数理网格法"建立了一套包含结构定义、功能分解等环节的规则体系。测试分为目标设定、结构分解、规则约束下的生成、同步比对和结构化排查五个阶段，AI在受约束的框架内执行代码装配与校验任务。测试结果表明，AI编程仍存在逻辑漂移问题，要实现高水平编程还需AI能力

avatar AtomGit开源社区

【EI复现】梯级水光互补系统最大化可消纳电量期望短期优化调度模型（Matlab代码实现）

文献来源：摘要：充分发挥流域梯级水电的调节作用，实现梯级水光系统的互补联合发电是促进清洁能源消纳的重要途径。文中考虑光伏出力不确定性，以整体可消纳电量期望最大为目标，提出了梯级水光互补系统的短期优化调度模型。该模型以机组为最小调度单位，精细化建模了电站约束、机组约束以及电网约束，通过梯级负荷在电站和时段间的合理调配，挖掘梯级水电的电网供电支撑和光伏互补协调双重作用，提升互补系统整体消纳水平。

avatar AtomGit开源社区