人机融合式软件开发系列 · 6 / 6 · 维护 + 治理（末篇）
维护 + 治理：APR + 新债型 + 责任框架
维护消耗 50–70% 工程资源，是人机融合收益最大 + 风险也最大的环节。 收益：AIR 仓库级自主修复达 87.1%（SWE-bench（SWE = Software Engineering，软件工程；bench = benchmark，基准测试）Verified）、LLM（Large Language Model，大语言模型）分层知识注入修复率 79%、AI（Artificial Intelligence，人工智能）辅助 PR（Pull Request，GitHub 上的代码合并请求）合并时间 −61%。 风险：3 种新型技术债（GIST / LLM-SATD / PromptDebt）+ 质量稀释悖论 + 信任缺口。 本页讲清 3 条主线 + 3 种新债型 + 治理 4 原则。
概览
50-70%
工程资源在维护
87.1%
AIR 修复率
5.6%
LLM-SATD 占比
56.3%
CodeRabbit 评论被拒
第一篇 · 3 条主线：APR / 仓库级 / 知识注入
第 6 讲 · 3 主线 + 1 关键洞察
3 条维护主线 + 跨语言实证
先对齐标题里的缩写：APR = Automated Program Repair（自动程序修复）——用程序/模型自动定位并修复代码缺陷。Campos 等（2025/2026, arXiv:2506.03283）对 13 个开/闭源模型在 Java(Defects4J)/ JS(BugsJS)/ Python(BugsInPy)/ PHP(BugsPHP) 做泛化性实证——发现 3 条关键路径：
3 条主线
| # | 路径 | 代表 | 关键数字 |
|---|---|---|---|
| 1 | 自动程序修复 APR | 传统 LLM-as-fixer（Campos 2025） | committee of experts 在"唯一修复 bug 数"上增益；不同 LLM 对不同语言各有最优 |
| 2 | 仓库级自主修复 | AIR (Autonomous Issue Resolver, 2025) | SWE-bench Verified 87.1% / Lite 73.5% / 100 真实 OSS 修 70；DTG（数据优先变换图）是主要驱动（去掉降至 56.2%） |
| 3 | 分层知识注入 APR | Ehsani et al. ASE 2025 | Bug/Repo/Project 三层渐进注入；Llama 3.3 79%（+23%）；复杂/结构孤立 bug 仍难 |
关键洞察（报告 §6.1）：不同 LLM 对不同语言各有最优——难做"单模型跨平台"。在不完美故障定位（imperfect FL）现实假设下（不要假设能精确定位 bug 行号），准确率较"完美 FL"显著下降。工程化时：组合模型 + 接受 imperfect FL 是默认假设。
第 6 讲 · 1 主题 + 4 数据点
图 1 · 看似矛盾的 2 个数据：Cihan 实测 PR 关闭时长 +41%（5h52m → 8h20m），Collantes 实测合并时间 −61%（~9h vs ~23h）——区别在于"关闭"含被拒/撤销，"合并"是最终通过。数据：本页"AI 辅助代码审查"卡片两处实证
AI 辅助代码审查：压缩"等待"而非"判断"
工业实证（Cihan et al., Qodo PR Agent in Beko）：10 项目 4,335 个 PR / 1,568 个自动评论。结果不是"AI 帮了"或"AI 害了"那么简单。
4 个数据点
| 指标 | 数值 | 解读 |
|---|---|---|
| 自动评论被解决率 | 73.8% | AI 评论大多被采纳 |
| PR 关闭时长 | 5h52m → 8h20m（+41%） | 诡异——AI 评论反而拖慢了 PR 关闭 |
| CodeRabbit 大规模实证（Lin et al. 2026） | 31,073 对评论 / 10,191 PR / 239 仓 | 36.4% 接受 / 7.3% 引发讨论 / 56.3% 拒 |
| 拒收主因（轻量 ML 可预测 76% F1） | 误报 / 冗余 / 越界 / 与意图不符 | AI 评论"质量不够"是被拒的根因 |
GPT 辅助 PR 提速实证（Collantes et al., 25k PR）
- 中位合并：~9h vs 标准 ~23h（−61%）
- 首评：~1h vs 3h
- 等待修改：~3h vs 24h
- 关键：AI 压缩的是"等待"而非"判断"
看似矛盾的 2 个数据：Cihan 说 PR 关闭变慢 41%，Collantes 说合并变快 61%。区别在"关闭"（包括被拒、撤销、搁置）vs"合并"（最终通过）。AI 评论能加速"合并路径"但同时制造更多噪声让其他 PR 走"非合并路径"——这正是 56.3% 拒收率 的成本。
第二篇 · 3 种新债型 + 质量稀释悖论
第 6 讲 · 3 新债型 + 1 悖论 + 1 总评
图 2 · 3 种新债型的代表占比（%）：GIST 81/6,540 ≈ 1.2%（由本页"81 含 SATD / 6,540 条注释"换算）、LLM-SATD 5.6%（5,086/90,845）、PromptDebt 54.49% 源自 OpenAI 集成——三项研究口径不同，仅作量级对比。数据：本页 Part 2 三处债型列表
3 种新债型 + 质量稀释悖论
债型 1 · GIST（GenAI-Induced SATD，TechDebt 2026）
- 分析 6,540 条 LLM 引用注释 / 81 含 SATD（Self-Admitted Tech Debt）
- 设计债 33/81 / 需求债 17 / 测试债 17
- AI 使债务从设计向"需求 + 测试"后移（因为 AI 在测试和需求上更"敢写"）
- 开发者将 AI 代码视为触发者(42%) / 来源(27%) / 缓解者(23%)
债型 2 · LLM-SATD（Owolabi 2026）
- 2,854 仓库 90,845 条 SATD 中识别 LLM-SATD 5.6%（5,086 条）
- 偿还率更高（62.3% vs 46.3%）——但"测试与行为验证债"偿还中位需 76.6 天 / 179 行修改，尤堪忧
- 新子类：Agent Integration Debt / Prompt Debt
债型 3 · PromptDebt（Aljohani & Do, EASE 2025）
- 93,142 Python 文件，54.49% SATD 源自 OpenAI 集成 / 12.35% 来自 LangChain
- 提示设计是主因：指令式 38.60% / 少样本 18.13%
- 含义：prompt 是新代码，prompt 的债也是债——"写了就忘 / 复用冲突 / 调参失稳"
质量稀释悖论（SonarSource 2025/2026）
- 即使单单位代码质量提升，体量也压垮人工审查
- GitClear 2020-2024：≥5 行重复块频率 +8 倍，2024 首次复制行数超重构行数
- Google 2025 DORA：AI 采用 +90% 伴随bug 率 +9% / 审查时间 +91% / PR 规模 +154%
- 67% 开发者报告花更多时间调试 AI 代码
新债的总评：传统技术债是"写代码时偷懒"，新债是"理解不足时采纳"（GIST 论文原话："在缺乏完全理解下采纳 AI 代码"催生新债型）。AI 让写代码更容易、理解代码更难——债的源头从写作过程前移到理解过程。
第三篇 · 跨阶段治理：信任、责任、4 原则
第 6 讲 · 1 信任缺口 + 3 责任规则 + 4 治理原则
治理：信任缺口 + 责任规则 + 4 原则
信任缺口（Le Goues 2026, CMU）
- 核心论断："不能把人移出软件工程"——最大挑战始终是人性的（定义目标、理解意图、判定系统是否真在做人要做的事）
- 传统信任来源"人写 → 人审 → 人测 → 人讨论"的集体社会过程；AI 生成代码可能更不透明
- 隐性信任侵蚀：AI 打断"已知来源—理解逻辑—承担责任"的信任链，易致盲目接受（blind acceptance）
3 条责任规则
| 规则 | 含义 |
|---|---|
| Linux 内核 Signed-off-by | AI 可辅助开发，不能添加 Signed-off-by 标签——只有人能审、签、担责；AI 参与须以 Created-by / Assisted-by 标注模型版本与工具 |
| AI 提议、人处置 | 团队将 AI 视为"实习生/热心中级开发者"，合并前人类必须审并担责；提交打"AI-assisted"标签（模型名/版本）形成审计链 |
| 最小代理 least agency | Agent 不应能做其技术所能做的一切，只授完成任务之必需权限；防止 prompt injection 与供应链投毒 |
4 条治理原则（综合）
- 审批受控模型：禁用"影子 IT"公有 AI 泄露私有逻辑
- 版本化制品 + 人类审查标记：追踪 AI 辅助提交比与审查指标
- AI 生成代码"默认可疑，直至证明"：过静态分析/测试/依赖检查/密钥管理/架构评审
- 遵循 EU AI Act、ISO/IEC 42001 等合规框架
治理的核心立场：以"信任但验证 + 最小代理 + 标签化审计"将 AI 嵌入既有信任过程，而非绕过它（Linux Signed-off-by、SonarSource、ISO/IEC 42001）。AI 不会取代你，但会用 AI 的开发者可能取代不用的人——角色从代码作者转向架构师 / 策展人 / AI 团队领导者。