企业官网建设流程全解析

最近一年，大量 AI Coding Agent 出现了。

它们可以理解代码、生成代码、修改项目，甚至尝试完成比较复杂的开发任务。这当然很有价值，但我在实际开发和自动化流程里逐渐意识到：并不是所有代码错误都需要一个“大而全”的 Agent 来解决。

有一类问题其实更像“运行时故障”，而不是“代码创造问题”。

比如：

- 文件路径缺失
- 配置文件不存在
- Python module 缺失
- 命令参数写错
- 命令启动失败
- 简单运行时异常
- 某些环境或依赖问题

这些问题的共同点是：错误已经真实发生，程序已经给出了 stderr/stdout，修复动作通常也应该很小。

所以我没有继续做另一个 AI Coding Agent，而是做了一个更窄的东西：

RepairLoop。

项目地址：
https://github.com/guohuancui123-a11y/repairloop

## RepairLoop 想解决什么问题？

传统 Coding Agent 的典型流程大概是：

```text
理解项目
↓
生成修改
↓
希望问题解决
```

RepairLoop 的流程不一样。

它从一个已经失败的命令开始：

```text
Run → Capture → Repair → Verify
```

也就是：

```text
运行失败命令
↓
捕获真实错误
↓
生成最小修复
↓
重新运行验证
```

它关心的不是“能不能生成一段看起来合理的代码”，而是一个更具体的问题：

> 这个程序能不能重新跑起来？

## 为什么不是另一个 AI Coding Agent？

很多时候，我们并不需要模型理解整个项目。

比如一个脚本报错：

```text
FileNotFoundError: [Errno 2] No such file or directory: 'demo/generated/config.txt'
```

这类错误不一定需要大模型重构项目。

更合理的动作可能是：

1. 识别缺失路径；
2. 给出创建文件或目录的修复建议；
3. 默认只预览，不修改；
4. 用户确认后应用；
5. 重新运行原命令验证。

这就是 RepairLoop 的核心思路。

它不是要替代开发者，也不是要替代 Cursor、Claude Code 或其他 Coding Agent。

它更像一个本地的、可检查的自动化维修层。

## 设计原则 1：Local-first

RepairLoop 的核心引擎是本地优先的。

这意味着：

- 不需要云服务；
- 不需要 API Key；
- 不上传源码；
- 不依赖远程模型才能运行。

对于一些内部项目、企业代码、CI 环境或者不方便上传源码的场景，这一点很重要。

不是所有自动化工具都应该默认把代码交给云端。

## 设计原则 2：Safe by default

自动修复最容易让人担心的一点是：它会不会乱改文件？

所以 RepairLoop 默认是 dry-run。

例如：

```bash
repair-loop repair -- python demo/missing_file.py
```

这条命令只会展示修复方案，不会真正修改文件。

只有显式加上：

```bash
--apply
```

才会执行修复。

例如：

```bash
repair-loop repair --apply -- python demo/missing_file.py
```

这个设计的目的很简单：

> 自动化可以参与修复，但最终修改必须是显式确认的。

## 设计原则 3：Verification first

很多“自动修复”工具的问题是：

它们告诉你“我改好了”，但并没有证明真的好了。

RepairLoop 的核心是验证。

修复之后，它会重新运行原来的命令。

如果原命令仍然失败，就不能算成功。

所以 RepairLoop 的闭环是：

```text
失败
↓
诊断
↓
最小修复
↓
重新执行
↓
验证结果
```

这也是它和普通 patch generator 的区别。

## 架构流程

可以把 RepairLoop 理解成下面这个流程：

```text
User Command
↓
Run
↓
Capture stdout/stderr/exit code
↓
Diagnose runtime failure
↓
Generate minimal repair suggestion
↓
Preview or Apply
↓
Rerun original command
↓
Verify success/failure
```

核心点是：它始终围绕“真实运行结果”工作，而不是围绕一个抽象 prompt 工作。

## 一个简单 Demo

假设有一个 Python 脚本缺少配置文件。

直接运行：

```bash
python demo/missing_file.py
```

报错：

```text
FileNotFoundError
```

先预览修复：

```bash
repair-loop repair -- python demo/missing_file.py
```

RepairLoop 会识别缺失文件，并给出修复动作。

然后显式应用：

```bash
repair-loop repair --apply -- python demo/missing_file.py
```

它会执行修复，并重新运行原命令验证结果。

项目 README 里有 10 秒 Demo GIF，可以直接看到这个闭环。

## 当前能力

RepairLoop 目前还处在早期阶段，不是一个大而全的修复系统。

当前支持的一些方向包括：

- 缺失文件或路径；
- 缺失 Python module；
- 命令启动错误；
- CLI 参数错误；
- 简单语法错误；
- 部分 SQLite / Flask 运行时场景；
- JSON report 输出，方便 CI、自动化脚本或 Agent workflow 集成。

我不想把它包装成“什么都能修”的工具。

它现在更像一个小而清晰的 repair primitive。

## 为什么这个方向值得做？

因为在很多工程场景里，真正需要的是：

- 可解释；
- 可预览；
- 可回滚；
- 可验证；
- 可集成。

而不是每次都启动一个黑盒 Agent 去大范围修改项目。

RepairLoop 的目标不是“让 AI 接管开发”，而是提供一个更确定、更窄、更容易信任的修复闭环。

对于 CI、自动化脚本、Agent runtime、本地开发工具来说，这种小型 repair loop 可能比一个通用 Agent 更容易接入。

## 后续计划

下一步我更想听真实开发者的反馈，而不是继续盲目增加功能。

我关心的问题包括：

- Python 开发中哪些 runtime failure 最值得自动修复？
- dry-run / explicit apply 这种安全模型是否足够可信？
- JSON report 对 CI/CD 或自动化流程是否有价值？
- 哪些修复动作应该永远只建议，不应该自动执行？

项目地址：
https://github.com/guohuancui123-a11y/repairloop

如果你经常维护 Python 项目，欢迎体验并反馈你希望自动修复的错误类型。

RepairLoop 现在还很早期，但它想表达的是一个很明确的工程观点：

> 不是所有代码错误都需要 AI Agent。有些失败，更适合进入一个本地、可解释、可验证的 Repair Loop。