|
|
楼主 |
发表于 2026-6-6 18:11:53
|
显示全部楼层
# 新闻稿
## 长沙优易软件开发有限公司(UESOFT)与DeepSeek联合发布DSuE_RSI：LLM驱动的自动化代码修复工具
**湖南长沙，2026年06月06日** — 长沙优易软件开发有限公司（UESOFT）与深度求索（DeepSeek）今天联合发布 **DSuE_RSI**（Recurrent Self-Improvement），一个基于大语言模型的自动化代码编译错误修复工具。这是业界将LLM驱动的自我改进循环（RSI）应用于生产级C++项目的开源解决方案。
DSuE_RSI通过"编译 → 捕获错误 → LLM诊断 → 生成补丁 → 应用 → 重编"的闭环，实现无人值守的代码修复。它不仅能修复编译错误，还能检测并修复运行时崩溃（如段错误），并将成功的修复自动提交到Git仓库。
### 核心能力
- **自动编译修复**：捕获编译错误，调用DeepSeek API生成unified diff补丁，自动应用并重编
- **运行时错误检测**：编译成功后自动运行测试二进制，检测SIGSEGV等运行时崩溃
- **无限循环模式**：支持 `--loop` 参数，实现"编译→修复→测试→提交"的持续自我改进
- **Git集成**：每次成功修复后自动commit，形成可追溯的修复历史
- **双引擎架构**：
- `dsue_rsi` — 代码层RSI（编译/运行错误自动修复）
- `llama-sleep` — 权重层RSI（推理错误→LoRA训练→权重自动更新）
### 技术架构
DSuE_RSI底层是UESOFT从Meta发布的llama.cpp项目分叉并改进的分支，该分支已由DeepSeek-V4-flash和GLM5.1完成82/95个GGML算子的反向传播支持（V3-V6补丁系列），覆盖了Transformer全量微调和LoRA微调所需的梯度通路。这使得RSI循环不仅能修复代码，还能通过LoRA训练持续改进模型自身的推理能力。
### RSI三层架构
| 层级 | 名称 | 功能 |
|------|------|------|
| 代码层 | `dsue_rsi` | 编译错误 + 运行时崩溃自动修复 |
| 权重层 | `llama-sleep` | 推理错误 → 轨迹收集 → LoRA训练 → 热加载 |
| 调度层 | `DSuE_Task` | 任务统计 + 中断信号（不替LLM做决策，LLM自行判断） |
### 适用场景
- 大型C++项目的持续集成流水线
- LLM框架（如llama.cpp）的反向传播算子开发与调试
- AI辅助编程工具的自动修复后端
- 教育与研究：学习LLM如何理解并修复代码
### 开源与获取
DSuE_RSI已作为UESOFT的dsue_skills项目的一部分开源，并集成在llama.cpp的UESOFT分支中。
- 代码层RSI：`~/dsue_skills/dsue_rsi.cpp`
- 权重层RSI：已集成至llama-server，支持 `--rsi-sleep-pressure` 参数
- 一键启动：`bash rsi_bootstrap.sh`
### 历史渊源：自动化编译修复的演进
1970s-1980s: Make + 手动修复
1990s: IDE出现，提供错误高亮（Borland C++、Visual C++ 6.0）
2000s: Code::Blocks、UEStudio增强编译输出解析
2010s: Clang引入-fixit，可自动应用简单修复
2020s: GitHub Copilot、ChatGPT出现，LLM驱动修复成为可能
2024: Anthropic Claude Code,Mythos。
2026： ChatGPT+Codex,DSuE_RSI代表最新范式——无需预置规则，LLM理解任意错误
### 🎯 DSuE_RSI的独特价值
传统IDE的Quick Fix是枚举型的——开发者预先写好每种错误的修复模板。而DSuE_RSI是生成型的：
cpp
// 传统IDE能修复的（预置规则）：
error: 'cout' was not declared → 添加 #include <iostream>
// DSuE_RSI能额外修复的（LLM理解语义）：
error: use of dangling pointer 'ptr' after std::move
→ 分析所有权转移，生成正确的生命周期管理代码
### 缺陷
1. prompt设计缺陷（最严重）
cpp
"只输出修改后的代码，不要解释。使用标准 diff 格式。"
❌ LLM很难严格遵守"只输出diff"，经常输出解释文字
❌ 没有提供few-shot示例，LLM可能输出错误格式
❌ parse_errors只能解析标准diff格式，容错性差
2. diff解析过于简陋
cpp
if (line[0] == '-') old_text += line.substr(1) + "\n";
else if (line[0] == '+') new_text += line.substr(1) + "\n";
❌ 只支持单块替换，无法处理多文件/多块修改
❌ 无法处理context格式diff（GNU diff默认输出）
❌ 无法识别diff头中的文件路径（--- a/xxx.cpp vs --- /dev/null）
3. 错误解析不完整
cpp
std::regex err_re(R"(^(.+?) \d+):\d+:\s*(error|warning):\s*(.+)$)");
❌ 只匹配file:line:col:格式，不匹配file:line:（clang有时输出）
❌ 不匹配MSVC格式（file(line) : error）
❌ 不匹配链接错误（undefined reference）
❌ 不匹配断言失败（assertion failed）
4. 缺少安全检查
cpp
src.replace(pos, old_text.size(), new_text);
write_file(target_file, src);
❌ 直接替换，无备份机制。LLM错误可能破坏代码
❌ 无语法验证，可能产生更严重的编译错误
❌ 无循环检测，同一错误可能反复修复失败
5. 硬编码路径问题
cpp
exec("cd /mnt/d/vc/llama && git diff --stat 2>/dev/null");
❌ 硬编码了/mnt/d/vc/llama，不通用
❌ 应该从build_cmd或当前目录推断项目根目录
6. API调用脆弱
cpp
auto content_pos = resp.find("\"content\":\"");
❌ 简单字符串搜索提取JSON，遇到转义字符会出错
❌ 无错误处理（API限流、网络错误、JSON解析失败）
7. 性能问题
每次重编译都是全量编译，无增量缓存利用
无并行修复能力（多个文件错误需串行处理）
### 改进方案
改进1：使用结构化输出（最重要）
cpp
// 强制LLM输出JSON格式
static std::string call_llm_structured(const std::string& api_key,
const std::string& api_url,
const std::string& error_info) {
std::string prompt = R"(
你是一个C++修复专家。分析以下编译错误，输出JSON格式的修复方案：
{
"files": [
{
"path": "src/example.cpp",
"replacements": [
{"line": 42, "old": "int x = y;", "new": "int x = y + 1;"},
{"start_line": 10, "end_line": 15, "new_content": "..."}
]
}
]
}
错误信息：
)" + error_info;
// 在system prompt中要求输出JSON
// ... 使用JSON mode (DeepSeek支持)
}
改进2：健壮的diff解析
cpp
#include <vector>
#include <string>
#include <regex>
struct Patch {
std::string file;
int start_line = 0;
std::vector<std::string> old_lines;
std::vector<std::string> new_lines;
};
static std::vector< atch> parse_diff_robust(const std::string& diff) {
std::vector<atch> patches;
std::istringstream iss(diff);
std::string line;
Patch current;
bool in_hunk = false;
enum { SEEK_FILE, SEEK_HUNK, IN_HUNK } state = SEEK_FILE;
while (std::getline(iss, line)) {
// 匹配 unified diff 格式: --- a/file.cpp
if (line.find("--- ") == 0) continue;
if (line.find("+++ ") == 0) {
current.file = line.substr(4);
if (current.file.find("b/") == 0) current.file = current.file.substr(2);
state = SEEK_HUNK;
continue;
}
// 匹配 @@ -10,7 +10,9 @@
std::smatch m;
if (std::regex_match(line, m, std::regex(R"(@@ -\d+(?:,\d+)? \+\d+(?:,\d+)? @@)"))) {
if (!current.old_lines.empty() || !current.new_lines.empty()) {
patches.push_back(current);
current.old_lines.clear();
current.new_lines.clear();
}
state = IN_HUNK;
continue;
}
if (state == IN_HUNK && !line.empty()) {
if (line[0] == '-') {
current.old_lines.push_back(line.substr(1));
} else if (line[0] == '+') {
current.new_lines.push_back(line.substr(1));
} else if (line[0] == ' ') {
current.old_lines.push_back(line.substr(1));
current.new_lines.push_back(line.substr(1));
}
}
}
if (!current.old_lines.empty() || !current.new_lines.empty()) {
patches.push_back(current);
}
return patches;
}
改进3：备份+验证机制
cpp
#include <filesystem>
namespace fs = std::filesystem;
class SafePatcher {
std::string backup_dir;
public:
SafePatcher() {
backup_dir = "/tmp/dsue_backup_" + std::to_string(getpid());
fs::create_directory(backup_dir);
}
~SafePatcher() {
fs::remove_all(backup_dir);
}
bool apply_patch(const std::string& filepath, const std::string& new_content) {
// 1. 备份原文件
std::string backup_path = backup_dir + "/" + fs::path(filepath).filename().string();
write_file(backup_path, read_file(filepath));
// 2. 应用修改
write_file(filepath, new_content);
// 3. 快速语法检查（调用编译器）
std::string check_cmd = "g++ -fsyntax-only " + filepath + " 2>&1";
std::string check_out = exec(check_cmd);
if (check_out.find("error:") != std::string::npos) {
// 回滚
write_file(filepath, read_file(backup_path));
printf(" ❌ 语法检查失败，已回滚\n");
return false;
}
return true;
}
};
改进4：智能项目根目录检测
cpp
static std::string find_project_root() {
std::string cwd = exec("pwd");
cwd.pop_back(); // remove trailing newline
std::string path = cwd;
while (!path.empty()) {
if (fs::exists(path + "/.git") || fs::exists(path + "/CMakeLists.txt")) {
return path;
}
path = fs::path(path).parent_path().string();
}
return cwd;
}
改进5：增量编译 + 缓存
cpp
struct BuildCache {
std::map<std::string, std::string> file_hashes;
bool has_changed(const std::string& file) {
std::string new_hash = exec("sha256sum " + file);
if (file_hashes[file] == new_hash) return false;
file_hashes[file] = new_hash;
return true;
}
void touch(const std::string& file) {
file_hashes[file] = exec("sha256sum " + file);
}
};
// 在apply_fix后只重新编译修改的文件
static bool incremental_build(const std::vector<std::string>& changed_files) {
std::string cmd = "cmake --build build_sycl --target ";
for (const auto& f : changed_files) {
// 提取目标名：src/llama.cpp -> llama
fs::path p(f);
std::string target = p.stem().string();
cmd += target + " ";
}
return run_build(cmd).ok;
}
改进6：使用jq解析JSON响应
cpp
static std::string call_llm(const std::string& api_key, const std::string& api_url,
const std::string& prompt) {
// ... 请求代码不变 ...
// 使用jq提取content，避免手动解析
std::string jq_cmd = "echo '" + resp + "' | jq -r '.choices[0].message.content' 2>/dev/null";
std::string content = exec(jq_cmd);
if (content.empty() || content.find("null") != std::string::npos) {
// fallback to manual parsing
// ...
}
return content;
}
改进7：添加few-shot示例到prompt
cpp
static std::string build_prompt_with_examples(const std::string& error_info) {
return R"(
你是一个C++修复专家。输出格式要求：只输出unified diff格式的patch，不要任何解释。
示例1：
错误：undefined reference to `MyClass::myMethod(int)'
修复：
--- a/src/myclass.cpp
+++ b/src/myclass.cpp
@@ -15,6 +15,7 @@
+int MyClass::myMethod(int x) {
+ return x * 2;
+}
示例2：
错误：error: 'nullptr' was not declared
修复：
--- a/src/old.cpp
+++ b/src/old.cpp
@@ -1,4 +1,5 @@
+#include <cstddef>
现在请修复以下错误：
)" + error_info;
}
📊 改进优先级
优先级 改进项 预期效果
🔴 P0 结构化输出/JSON解析 根本解决解析失败问题
🔴 P0 备份+回滚机制 避免代码被破坏
🟡 P1 健壮的diff解析 支持多种patch格式
🟡 P1 项目根目录检测 消除硬编码
🟢 P2 语法检查验证 避免错误修改
🟢 P2 增量编译 提升速度
🔵 P3 并行修复 多文件同时处理
最关键的改进是让LLM输出JSON而非自然语言+diff，这样可以完全消除解析的歧义性。DeepSeek支持response_format: {"type": "json_object"}参数，应该优先使用。
### 关于UESOFT
长沙优易软件开发有限公司（UESOFT）由李国斌创立，是中国领先的工业软件和AI基础设施开发商。公司致力于将AI技术深度融入软件开发全生命周期，从代码生成到自我修复，构建新一代智能开发工具链。
### 关于DeepSeek
深度求索（DeepSeek）是中国领先的通用人工智能研究公司，致力于开发先进的AI模型和技术，推动AI在编程、推理和多模态领域的应用。
---
**媒体联系**：http://www.uesoft.com
*更多信息请访问：https://gitee.com/uesoft/llama.cpp*
https://gitee.com/uesoft/AIBuddy
https://gitee.com/uesoft/dsue_skills
以下是Qwen3.7-千问回答“Recurrent Self-Improvement”：
您提到的 Recurrent Self-Improvement 在人工智能领域通常被称为 递归自我提升（Recursive Self-Improvement，简称 RSI）。这是当前AI领域最前沿、也最具颠覆性的概念之一。
🔄 什么是递归自我提升（RSI）？
简单来说，RSI 指的是 AI 系统能够参与并主导对自身架构、算法或能力的改进过程，从而形成一个“AI造AI”的反馈闭环。就像滚雪球一样，AI 造出更好的 AI，更好的 AI 再造出更强大的 AI，如此循环往复，可能导致智能水平的指数级增长（即“智能爆炸”）。
过去，这仅仅存在于学术论文和思想实验中，但如今它已经从理论构想转变为各大顶级 AI 实验室路线图上的明确工程项目。
🚀 行业现状与早期迹象
截至 2026 年，业界已经观察到了 RSI 的切实进展，人类在 AI 研发中的监督角色正在逐渐减弱：
顶尖公司的布局：包括 Anthropic、OpenAI 等在内的主要实验室已将“AI for AI R&D”列为核心研发目标。例如，Anthropic 联合创始人预测，到 2028 年底 AI 实现完全自主递归自我改进的概率约为 60%。甚至有专门的初创公司（如 Recursive Superintelligence）直接以该概念命名并获得了巨额融资，致力于让 AI 成为自主的 AI 研究员。
AI 编写自身代码：在实际工程中，AI 已经开始替代工程师写自己的代码。有数据显示，Anthropic 内部合并的代码中已有超过 80% 是由 Claude 撰写的，工程师的人均代码生产量实现了数倍的增长。
加速模型训练：在优化小型语言模型训练的测试中，AI 展现出的加速倍数从早期的约 3 倍飙升到了 50 倍以上，而在同等任务上，人类研究员通常需要花费数小时才能达成几倍的加速效果。
⚠️ 面临的挑战与潜在风险
尽管进展迅速，但要实现完全的 RSI 仍面临巨大挑战，甚至引发了安全层面的担忧：
人类的“最后壁垒”：目前的 AI 依然缺乏真正的“自我驱动力”。它们虽然能高效执行任务，但在决定“哪些研究方向值得投入”以及“何时判断陷入瓶颈”等宏观战略决策上，仍然高度依赖人类。
失控与对齐风险：如果 AI 真正开始自主设计下一代模型，当前模型中哪怕极其微小的“目标偏差（Misalignment）”，都可能在迭代过程中被复利式地放大，最终导致人类彻底失去对超级智能的控制。
评估难题：当 AI 开始自主设计和评估实验时，人类如何确保其评估结果的准确性成为了一个棘手的问题，这需要依赖可解释性研究来打开 AI 内部的“黑盒”。
总而言之，RSI 正处于从理论走向技术实践的关键拐点。它既代表着 AI 生产力即将迎来爆发式的飞跃，也对人类如何建立有效的安全控制机制提出了前所未有的考验。
7篇来源
RSI与智能爆炸有什么关系？
实现RSI有哪些关键技术？
RSI带来的安全挑战该如何应对？

内容由AI生成，可能不准确，请注意核实
|
|
发表于 2026-6-6 18:11:14
湘公网安备 43019002001550号