软件工厂自我改进：AI Engineer如何搭建持续优化的开发流水线

这次我们讨论一个来自 AI 工程趋势的概念：软件工厂如何自我改进。很多人看到“软件工厂”四个字，第一反应是自动化生成代码、批量出项目。实际上它背后更值得关注的是 AI Engineer 的角色变化：不是让 AI 帮你写一次代码，而是让 AI 帮你搭建一套能持续修复问题、沉淀经验、更新工作流的系统。

一句话概括本文的主题：AI Engineer 不只是在造软件，而是在造一个能造软件的“工厂”；这个工厂最重要的指标，不是第一次输出多惊艳，而是能不能在真实反馈中不断自我改进。

这篇文章会讲清楚软件工厂到底指什么、AI Engineer 在其中做什么、自我改进闭环怎么搭，并给出一套可以直接参考的最小实现方案，包括环境准备、流水线配置、功能验证、接口调用、批量任务和常见排错。适合正在做 AI 编码工具、内部研发效能平台，或者想把自己的项目接入 AI 工程师工作流的读者。

1. 核心能力速览

这里的核心判断是：软件工厂不是一个具体安装包，而是一条把 AI 编码代理、CI、代码审查、知识库串起来的工作流。 它能不能跑起来，取决于你给它的反馈通道是否完整。

2. 什么叫软件工厂，它和普通 AI 编程工具有什么区别

普通 AI 编程工具的使用方式通常是：开发者写提示词，AI 返回代码片段，开发者复制粘贴后自己 review。这个流程里，AI 是被动助手，开发者是唯一决策节点。

软件工厂的思路是反转一部分控制权：把“写代码”变成一条标准流水线，AI 代理负责从接收任务、分析代码、生成补丁、提交 PR、跑测试到最后修复问题，开发者主要做结果审核和验收。可以把它理解成在 DevOps 体系里加入一层 AI Engineer 自动化岗位，执行以下工作：

• 分析 issue 或需求描述，定位到相关模块。
• 调用 LLM 生成修改方案，并生成对应补丁。
• 自动构建、跑单测、跑静态检查。
• 根据测试结果自省，尝试修正补丁。
• 生成 PR 描述、梳理影响范围、标记风险点。
• 从已合入的 PR 中提炼规律，更新后续提示词模板或工作流配置。

软件工厂的自我改进，是指系统本身会通过反馈迭代优化。第一次跑通可能只是自动修复了一个 lint 错误，第二次可能就能自动处理比较复杂的空指针问题，第三次可能学会按照团队代码风格生成补丁。关键是每一次任务的结果都要被收集、评估、转化为下一步执行策略。

传统 CI/CD 与 AI 软件工厂的差异在于：传统 CI/CD 用于验证人类的修改，AI 软件工厂会自动生成修改并提供验证结果。两者不是替代关系，而是互补关系：CI/CD 是软件工厂的执行层，AI 工程师是软件工厂的生产层。

3. 适用场景与使用边界

3.1 适合谁

• 项目里有大量低难度 issue，例如 lint 报错、单测失败、依赖升级、简单 bug 修复。
• 团队希望沉淀一套标准化的“问题到修复”流程。
• 需要一个能在晚上自动跑批量的 AI 编码代理，并生成第二天的待审 PR。
• 需要做技术债务清理、跨仓库统一重构的团队。
• 做 AI 工程平台、想给客户提供“自动交付”能力的技术团队。

3.2 不适合什么场景

先给结论：不要一上来就让 AI 代理处理高复杂度、强业务上下文、涉及架构决策的任务。 这类任务失败率很高，而且出了问题时责任很难界定。

典型的不适合场景包括：

• 需要深入理解产品战略、用户心智和商业规则的需求。
• 涉及大量内部私有协议、历史遗留接口隐性约束的改造。
• 需要和多方业务负责人反复确认的跨团队功能。
• 生成代码后没有人工审核条件的团队。
• 安全要求极高、任何代码变更都需要严格合规审计的场景。

3.3 使用边界与合规提醒

软件工厂把代码生成、修复、提交的部分自动化，但代码合规审查权限不能完全交给 AI。接入 AI Engineer 流水线时必须明确以下边界：

• 输入代码仓库中的敏感数据、认证信息、内部 API 密钥不能未授权传给第三方大模型。
• 涉及人脸、声音、肖像、版权素材的开源项目，不能脱离授权链自动生成或替换内容。
• AI 生成的代码只是候选修改，合入主干前需要人工 review 并保留过程记录。
• 如果使用外部 LLM API，需要确认数据处理协议、日志留存方式和可用区域。
• 若涉及公开发布或商业项目，发布前必须对 AI 生成的文档和代码做事实核查与效果复核。

4. 环境准备与前置条件

搭建一个最小可运行的 AI 软件工厂，不需要大型硬件集群，但需要把以下环境准备清楚。

4.1 软件层

4.2 模型选择

本地部署 LLM 时，模型参数量直接影响显存占用。

• 使用 7B 级别模型，常见部署在消费级显卡上可以跑，但推理能力有限。
• 使用 32B~70B 级别模型，需要更大显存或多卡，适合生成更复杂补丁。
• 如果只是验证流水线可行性，直接接云端 API 更省事，先跑通闭环再考虑本地推理。

更稳妥的判断是：先以 API 方式跑通最小流程，再评估本地模型的成本与效果。 显存占用没有统一数字，必须按实际模型和并发参数测试。

4.3 目录规划

软件工厂的代码建议单独建仓库，不要把代理脚本散落在业务项目里。推荐结构：

text复制ai-factory/
├── config/
│   ├── self_improve.yaml        # 自我改进流程配置
│   └── prompts/                 # 各类任务提示词模板
├── scripts/
│   ├── ai_agent.py              # 代理主逻辑
│   ├── report.py                # 生成改进报告
│   └── eval_loop.py             # 评估循环
├── workflows/
│   └── issue_to_pr.yml          # CI 流水线模板
├── logs/
│   └── run_YYYYMMDD.log         # 每次运行日志
└── outputs/
    └── patches/                 # 生成的补丁文件

4.4 通用检查清单

在开始安装部署前，先确认：

• Git 仓库权限已配置，代理账号能创建分支和 PR。
• CI 系统能接收 Webhook，且 secrets 中已配置 LLM API Key。
• Docker 或 Python 环境可用。
• 端口规划完成，避免与已有服务冲突。
• 对要接入的仓库已做数据脱敏检查。
• 员工授权和审计要求已确认。

5. 最小实现：从 issue 到 PR 的自动化流水线

下面给出一套通用搭建流程。这里的命令和配置是模板，实际运行时需要替换成自己的仓库地址、模型 API 地址、分支名称和触发条件。

5.1 启动 LLM 推理服务

如果使用本地推理服务，常见方式是启动一个 OpenAI 兼容接口：

bash复制# 示例：以 OpenAI 兼容方式启动本地推理服务
# 实际命令以部署工具为准，这里只是常见参数示意
python -m vllm.entrypoints.openai.api_server \
  --model /models/code-model \
  --served-model-name code-model \
  --host 127.0.0.1 \
  --port 8000

如果直接使用云端 API，则不需要这一步，只需要在后续脚本中把 base_url 指向对应服务地址。

5.2 定义自我改进流程配置文件

用 YAML 配置文件描述流程，这样后续改进时可以不改代码、只改配置：

yaml复制# config/self_improve.yaml
project:
  repo: your-org/your-project
  default_branch: main

llm:
  base_url: "http://127.0.0.1:8000/v1"
  api_key_env: "LLM_API_KEY"
  model: "code-model"
  temperature: 0.2

flow:
  # 从 issue 或测试失败事件触发
  source: "issue"
  max_iterations: 3
  create_pr: true
  run_tests: true

review:
  require_human_merge: true

feedback:
  collect_logs: true
  metrics_path: "./metrics/run_results.json"

这个配置文件的核心作用：把自我改进策略参数化。 你可以随时调整 max_iterations、temperature、模型地址，不需要改动代理主代码。

5.3 编写代理主脚本

用 Python 写一个轻量代理，核心逻辑包含四步：

1. 读取任务上下文。
2. 调用 LLM 生成补丁。
3. 在本地或 CI 环境运行测试。
4. 根据测试结果决定重试或提交 PR。

python复制import os
import json
import openai
from pathlib import Path

# OpenAI SDK 调用示例，实际接口需要按所选服务调整
client = openai.OpenAI(
    base_url=os.getenv("LLM_BASE_URL", "http://127.0.0.1:8000/v1"),
    api_key=os.getenv("LLM_API_KEY", "local-key"),
)

PROMPT_TEMPLATE = """
你正在修复一个软件缺陷。请阅读以下 issue，分析可能影响文件，生成符合仓库现有代码风格的补丁。

Issue 标题：{title}
Issue 内容：{body}

要求：
1. 先定位相关代码文件；
2. 再给出修改内容；
3. 最后说明本次修改的风险点；
4. 不要臆造不存在的接口。
"""

def generate_patch(issue_title: str, issue_body: str) -> str:
    response = client.chat.completions.create(
        model="code-model",
        messages=[
            {"role": "system", "content": "你是一名 AI 工程代理，负责生成高质量补丁。"},
            {"role": "user", "content": PROMPT_TEMPLATE.format(title=issue_title, body=issue_body)},
        ],
        temperature=0.2,
    )
    return response.choices[0].message.content.strip()


def save_patch(patch_text: str, output_dir: Path):
    output_dir.mkdir(parents=True, exist_ok=True)
    patch_file = output_dir / "candidate.patch"
    patch_file.write_text(patch_text, encoding="utf-8")
    return patch_file

这是一个最小骨架，直接跑通闭环足够。生产环境建议把代码定位、补丁应用、测试执行、PR 创建拆成独立模块。

5.4 配置 CI 流水线触发

在 Jenkins、GitHub Actions 或 GitLab CI 里注册一条流水线，当新 issue 打开时触发代理。以 GitHub Actions 的 YAML 为例：

yaml复制name: AI Software Factory Improve

on:
  issues:
    types: [opened]
  workflow_dispatch:

jobs:
  improve:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          pip install openai pyyaml

      - name: Run AI improvement agent
        env:
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
          LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }}
        run: |
          python scripts/ai_agent.py \
            --issue-number "${{ github.event.issue.number }}" \
            --config config/self_improve.yaml

      - name: Create Pull Request if patch generated
        run: |
          bash scripts/create_pr.sh

启动后，系统会按“issue 打开 → 代理分析 → 生成补丁 → 提交 PR”的方式自动运行。你在浏览器里可以看到代理生成的候选 PR。

6. 让软件工厂具备自我改进能力

自动修 issue 只是第一步，自我改进的关键在于把本次执行结果转化成下一次执行能力。完整改进循环包含五个阶段。

6.1 反馈收集

代理每次运行结束后，都要生成结构化结果文件，比如：

json复制{
  "run_id": "20240101_001",
  "issue": "#1234",
  "patch_generated": true,
  "tests_passed": false,
  "failed_steps": ["test_fix_example.py"],
  "errors": ["Index out of range"],
  "llm_requests": 3,
  "duration_seconds": 540
}

为什么要有这个文件？因为未量化的失败无法驱动改进。只有知道哪个环节失败、失败多少次、卡在哪个测试上，下一步优化才有依据。

6.2 结果评估

每周或每批次任务结束后，对结果做四个维度评估：

这一阶段产出的是改进信号，不是最终结论。比如“空洞指针修复类任务通过率只有 20%”，就需要在下一轮调整提示词，着力收集更多调用上下文。

6.3 工作流模板演进

把成功案例沉淀为工作流模板。例如处理依赖升级类 issue，第一次可能只是随便生成补丁；经过几轮后，可以把“读取 package.json → 比较版本 → 参考 changelog → 生成补丁”固化为模板。

这一步就是把成功的经验从一次性结果，变成可复用的流程能力。

6.4 提示词和知识库更新

让软件工厂自我改进，还需要给它一个“记忆”。建议维护三个目录：

text复制config/prompts/
├── fix_bug.md              # 缺陷修复基础提示词
├── fix_bug_null_pointer.md # 空指针专项提示词
├── dependency_upgrade.md   # 依赖升级专项提示词
└── refactor.md             # 小范围重构提示词

当某个类型的问题反复出现时，将解决方法写进专项提示词。生成的补丁质量比通用提示词明显更高，这是比较直观的改进效果。

6.5 人工反馈闭环

即使 AI 代理自动提交 PR，开发者 review 时也要留下结构化反馈。这些反馈需要回写系统，例如在 PR 中标记：

• 此次补丁是否可合并。
• 若不可合并，主要问题是什么。
• 代理对问题的理解是否准确。
• 是否缺少必要的测试用例。

不起眼的 review 反馈，其实是自我改进最重要的燃料。没有人工反馈的代理，会长期停留在“低质量重复修复”的阶段。

7. 功能测试与效果验证

搭建完流水线后，不要直接把整个生产仓库交出去。先按下面的流程做功能验证。

7.1 测试一：单测失败自动修复

• 测试目的：验证代理能否解决一个确定性问题。
• 输入：在示例仓库中放一个单测失败的 issue，描述清楚失败现象。
• 操作：打开 issue，等待流水线触发。
• 预期结果：代理生成补丁，本地或 CI 运行单测后至少提出一个候选 PR。
• 判断标准：PR 中包含修复代码，并且测试从失败状态转为通过状态。
• 失败排查：检查代理日志中 LLM 返回是否为空，CI 是否有权限推送分支。

7.2 测试二：小范围重构任务

• 测试目的：验证代理能否理解代码结构。
• 输入：要求代理把某模块中重复的函数调用抽成一个公共方法。
• 操作：手动调用代理脚本，传入任务描述。
• 预期结果：生成补丁包含新增函数和调用点修改。
• 判断标准：编译通过，测试通过，调用点数量与人工核对一致。
• 失败排查：有可能代理没有准确定位调用点，需要在提示词中补充文件路径和函数名。

7.3 测试三：连续十次同类型任务

• 测试目的：验证自我改进是否真的带来效果提升。
• 输入：从历史 issue 中挑 10 个同类型任务。
• 操作：第一轮使用通用提示词跑一遍，记录通过率；第二轮把通过案例拆解成提示词模板后跑同一批任务。
• 预期结果：第二轮通过率应高于第一轮，或至少生成补丁的稳定性更强。
• 判断标准：通过率提升、单任务尝试轮次下降、人工修改次数下降。
• 暂停条件：连续同类型任务通过率不足 30% 时，停止扩大范围，先补充人工标注样本。

7.4 功能验证注意点

• 第一次跑流程时，尽量在独立测试仓库里做，避免 AI 代理误改生产代码。
• 每次测试都要留下日志和补丁输出目录，方便后续对比。
• 不要只看补丁生成数量，重点看最终合入的 PR 数量。
• 评估模型效果时，用同一个测试集对比，不要每次都换任务类型。

8. 接口 API 与批量任务

软件工厂从零到一跑通后，下一步要解决效率和容量问题。主要有两条路径：接口 API 化和批量任务队列化。

8.1 代理任务接口

把 AI 代理封装成一个内部服务，供外部系统调用，例如：

bash复制curl -X POST "http://127.0.0.1:8080/tasks" \
  -H "Content-Type: application/json" \
  -d '{
    "repo": "your-org/your-project",
    "issue_number": 1234,
    "task_type": "fix_bug",
    "constraints": "只修改 src/ 目录，不得改动配置文件"
  }'

实际项目中接口路径和参数需要按自己实现调整，但大致结构类似：外部系统只需要提交任务，服务负责分配代理、执行代码、返回结果。

8.2 批量任务队列

面对一次几十个 issue 的批量任务，不要让所有任务同时跑，避免把 CI 打爆或超时。常见的做法是维护一个任务队列：

text复制tasks/
├── queued/
│   └── issue_1234.yaml
├── running/
│   └── issue_1235.yaml
└── done/
    └── issue_1236.json

简单的文件队列即可起步。生产者扫描未处理的 issue，状态改为 queued；消费者每次取一个任务，执行完后把结果写到 done 目录。批量到了后期可以升级为 Redis 队列。

8.3 Python 批量调用示例

python复制import json
import time
from pathlib import Path

def dispatch_batch(issue_list, task_script):
    queued_dir = Path("tasks/queued")
    for issue in issue_list:
        task_file = queued_dir / f"issue_{issue['number']}.yaml"
        task_file.write_text(
            json.dumps(issue, ensure_ascii=False),
            encoding="utf-8",
        )

def consume_once(consumer_id="worker-1"):
    running_dir = Path("tasks/running")
    queued_dir = Path("tasks/queued")
    for task_file in sorted(queued_dir.glob("*.yaml")):
        target = running_dir / task_file.name
        task_file.rename(target)
        # 实际执行代理脚本，并捕获输出到日志
        print(f"[{consumer_id}] start task {task_file.stem}")
        time.sleep(1)
        # 执行完成后把结果写好，并清理 running 目录
        (Path("tasks/done") / f"{task_file.stem}.json").write_text(
            json.dumps({"status": "done"}),
            encoding="utf-8",
        )

if __name__ == "__main__":
    issues = [
        {"number": 1, "title": "fix npe in auth module"},
        {"number": 2, "title": "upgrade lodash to 4.17.21"},
    ]
    dispatch_batch(issues, "scripts/ai_agent.py")
    consume_once()

批量任务的三个建议：

• 每条任务都要有唯一 run_id，方便追踪日志。
• 任务失败要允许重试，但要限制最大重试次数。
• 任务执行要记录模型名、参数、耗时、成本，避免月底对账时无数据可查。

9. 资源占用与性能观察

软件工厂的资源占用不是一个固定值，主要取决于三方面：LLM 服务、CI 执行资源、任务并发量。

9.1 LLM 服务性能

本地部署 LLM 时，需要观察以下指标：

显存占用会随 input tokens 和 output tokens 变化。任务上下文越长，占用越高。批量生成大量 issue 修复时，需要评估是否增加并发，还是用队列降低瞬时压力。

9.2 任务级资源观察

每次代理任务建议记录：

• LLM 请求总次数。
• 总输入、输出 token 数。
• 代理脚本运行时长。
• CI 构建时长。
• patch 生成失败次数。
• 人工介入修改字符数或操作时长。

成本优化直接看 token 数即可。很多项目发现，简单问题用 7B 模型，复杂问题用大模型，整体成本明显低于全部请求都选大模型。

9.3 性能瓶颈判断

• 如果 LLM 服务响应慢，检查上下文是否过长，考虑裁剪无关文件内容。
• 如果 CI 排队严重，降低并发，或拆分更小的测试任务。
• 如果 PR 大量冲突，说明代理修改范围和主干变化不匹配，下一轮应在提示词中要求先同步最新分支。
• 如果日志中出现进程残留，检查代理脚本是否有异常退出，建议在流水线里加 timeout。

10. 常见问题与排查方法

排查时最有效的思路是：先确认每一条链路是不是独立可用，再组合起来。 比如问题出在 LLM 调用，就先单独测一条 prompt；问题出在合并冲突，就先单独试一次手动 PR。不要在整条链路上盲目重复尝试。

11. 最佳实践与工程建议

11.1 从小任务开始

首次落地不要选复杂业务模块，选“lint 错误修复”“单测失败修复”“依赖版本升级”这类边界清楚的任务。这类任务结果明确，模型成功率相对高，适合验证闭环。

11.2 保留最小可运行配置

软件工厂需要经常调整，建议保留一套稳定配置版本。每轮调参前记录 baseline 指标，不要同时改模型、提示词、并发数三个变量，否则无法定位效果变化来自哪一项。

11.3 分层管理目录

代码、模型、输入素材、输出结果要分开目录：

text复制factory/
├── code/             # 工厂自身代码
├── models/           # 本地模型文件或模型配置
├── inputs/           # 待处理的 issue 导出数据
└── outputs/          # 生成补丁、评审报告、运行指标

分目录的好处是：备份简单、清理方便、排查问题时有明确边界。

11.4 日志和重试机制

软件工厂跑起来后，日志是最重要的资产。每条任务至少要记录：

• 开始和结束时间。
• 使用的模型与提示词版本。
• LLM 请求次数与 token 数。
• 测试执行命令和结果。
• 最终 PR 号或失败原因。

批量任务必须加失败重试。推荐策略：重试最多 2 次，第一次原样重试，第二次减少上下文或调整提示词；连续失败的进入人工 review 队列。

11.5 安全与权限边界

• 代理账号建议使用最小权限。
• AI 生成的 PR 不能直接合入生产分支，至少要求一位开发者 review。
• 对外部 LLM API 的行输入输出数据做匿名化处理。
• 在 CI 中加 secret scanning，防止代理把凭证信息带进补丁。
• 涉及人脸、声音、版权材料的项目，必须在授权链明确时才交给 AI 代理处理。

11.6 发布前做效果复核

哪怕自动化通过率很高，发布前仍要人工复核。AI 生成的补丁可能会修复当前测试，却引入设计层面的不一致。建议将“效果复核”作为独立步骤写入流水线，而不是完全依赖自动测试。

12. 总结与下一步

软件工厂最值得尝试的点，不是让 AI 自动生成一套完整系统，而是让它先从确定性问题开始，通过“任务执行 → 结果评估 → 提示词模板更新 → 再执行”的循环提升效果。这个思路对现有团队并不难落地，只需要一条 CI 流水线、一个 LLM 接口、一个 issue 触发源，再加一个人工 review 关卡。

如果第一次测试，建议做三件事：

• 选 10 个同类型的历史 issue 作为测试集。
• 跑一遍 baseline，记录通过率。
• 把少数成功案例写成专项提示词，再跑第二轮，观察通过率变化。

最容易踩的坑是跳过 feedback 环节，只追求“能生成补丁”。补丁能不能合入、为什么被拒、下一轮如何避免，才是软件工厂自我改进的核心动力。

再往后可以扩展的方向包括：把 AI 代理接入更多仓库，统一管理跨仓库任务；把不同模型的路由策略做起来，简单任务用小模型、复杂任务用大模型；把 review 意见自动分类，生成维护团队的代码风格约束；再把整个流水线接到项目管理系统，让 issue 状态、PR 状态、发布状态自动同步。

软件工厂自我改进的本质，是把每一次人工 review 的判断逐渐结构化、把成功经验沉淀为模板、把重复劳动交给自动化流程。这个闭环先跑通，后面再逐步扩大边界，会比单纯堆一层“自动写代码”的工具稳妥得多。