文章总结： 本文探讨AI在软件工程中从代码生成到系统接管的演进，指出AI虽能快速生成代码但缺乏系统全局视角导致失控风险。核心解决方案是HarnessEngineering，通过提供完整上下文、行为约束和结果验证来驾驭AI。文章批判RAG在软件工程中的结构性缺陷，提出通过多模态软件资产理解统一代码、文档和二进制的语义层，使AI能操作被理解的系统而非盲目写代码，实现从知识增强到工程控制的范式转换。 综合评分： 95 文章分类： 安全开发,AI安全,应用安全,安全建设,安全工具

---

AI正在“接管”软件工程，但系统正在慢慢失控

原创

Emily Emily

玉衡实验室

2026年3月31日 18:08 北京

从代码生成到Harness Engineering：让AI真正理解软件系统

2025年，AI编程助手已经从“代码补全工具”进化到“自主编程代理”。OpenAI Codex、Devin、Cursor等AI代理已经提交了超过45.6万个Pull Request，涉及6.1万个代码仓库和4.7万名开发者。但与此同时，一个被忽视的问题正在浮现：AI写的代码“看起来是对的”，但系统却在慢慢失控。

一、从“代码补全”到“系统接管”

AI编程的跃迁

AI的能力边界正在发生根本性变化。理解这种变化，是看清问题的第一步。过去我们谈AI写代码，更多是一些局部辅助功能：

• 写函数：根据注释生成代码片段
• 补全代码：自动补全当前行或代码块
• 修bug：根据错误提示给出修复建议

但最近，事情已经悄悄变了。

AI开始做的是：

• 理解需求文档：从PRD中提取功能点并规划实现
• 生成系统设计：提出架构方案和技术选型
• 编写完整模块：跨文件、跨目录实现功能
• 自动补测试、写文档：生成单元测试和API文档

甚至，在一些实验中，AI可以独立完成接近完整的软件工程流程。

根据Cognition公司的数据，Devin在SWE-bench基准测试中正确解决了13.86%的问题，而排名第二的模型仅为1.96%。到2025年，Devin的PR合并率已经从34%提升到67%，问题解决速度提升了4倍。

二、AI能写代码，但“看不见”整个系统

失控的根源

AI的能力在跃升，但一个致命问题正在浮现：它写得越来越快，却越来越“盲目”。

想象一个场景：一个工程师只能看到一小段代码，看不到依赖关系，不知道需求背景，不理解系统架构，然后让他写一个复杂系统。结果会怎样？

这其实就是今天AI的真实状态。

它的问题不是“不会写”，而是：

• 不知道改一行代码会影响哪里
• 不知道需求和实现是否一致
• 不知道引入了什么风险

一项针对开发者的调查显示，超过一半的受访者认为AI“无法理解完整项目上下文”是“非常”或“极其”具有挑战性的问题。一位受访者指出：“当前的AI助手只能看到部分代码，错过了对外部函数的依赖。”

本质一句话：AI没有“软件世界的全局视角”。

三、不是让AI更强，而是让它“有边界”

Harness Engineering

既然问题不是AI不够聪明，而是它“看不见”，那么解决方案就不应该是堆算力，而是给它“眼睛”和“规矩”。于是，一个新方向开始出现：Harness Engineering（驾驭工程）。

它的核心不是让AI更强，而是：让AI在一个“被理解、被约束、被验证”的环境中工作。用更直白的话说就是：AI开始写软件之后，我们不得不开始“管AI”。

Harness做的三件事：

• 给AI完整上下文（不是碎片信息）：提供代码、文档、架构的统一视图
• 约束它的行为（不能乱写）：通过规则引擎限制AI的修改范围
• 验证它的结果（自动判断对错）：持续比对需求、代码和运行行为

行业一个关键变化正在发生：模型能力正在让位给“系统控制能力”。AI能力的上限，不再由模型决定，而由“底层语义+中层控制”决定。

四、RAG救不了软件工程

为什么上下文碎片化行不通

当大家发现AI“看不懂系统”，第一反应是：用RAG，把更多文档喂给它，给AI更多上下文。但RAG在软件工程场景有一个致命的结构性缺陷。

RAG的运行逻辑：

• 把系统“切碎”成片段
• 再通过向量检索拼回来

这在问答场景是有效的，但在软件工程中，会产生一个致命问题——系统关系被破坏了。

比如：

• 代码调用链断裂：函数A调用函数B的关系在分块后丢失
• 架构层级消失：模块间的层次关系无法从碎片中还原
• 依赖关系无法推理：跨文件的类型依赖、接口契约被破坏

学术研究表明，RAG的“上下文碎片化”问题是结构性缺陷。当文档被分割成小块时，关键的关系信息会丢失。在微服务架构中，一个业务逻辑可能跨越5个服务、3个仓库，分块会摧毁最重要的关系信息。

所以你会看到一个现象：RAG可以回答问题，但无法“支撑工程”。

五、软件从未被真正“理解”过

问题的本质

RAG失败了，但失败的原因不在RAG本身。我们需要往更底层看：软件系统本身，其实从未被机器真正理解过。

一个真实的软件系统包含：

• 源代码（结构复杂）：AST、调用图、依赖关系、类型系统
• 二进制（完全黑盒）：编译后的机器码，符号信息丢失
• 文档（自然语言）：PRD、设计文档、API文档
• 架构图（非结构化）：UML图、流程图、时序图

这些信息：彼此割裂，无法统一理解。这就导致AI永远只能“局部聪明”，无法“整体正确”。

六、让代码、文档、二进制“说同一种语言”

华清未央破局之路

既然问题是“割裂”，那解决方案就是“统一”。多模态软件资产理解，就是要打破这些信息孤岛。它做的不是简单的数据接入，而是打破代码、文档、二进制等软件资产的信息孤岛，构建统一的语义理解体系，为AI提供软件世界的全局视角。

01

把代码变成“结构化语义系统”

• 基于AST（抽象语法树）理解逻辑结构
• 构建调用链与依赖图：函数调用关系、模块依赖关系
• 提取类型信息：类层次结构、接口契约

研究表明，Code Property Graph（代码属性图）结合AST、控制流图、数据依赖图和调用图，可以捕获代码的结构和语义。这种图表示法已成为代码理解的主流方法。

02

把文档变成“可计算的知识”

• OCR解析扫描件：将PDF、图片转换为可处理文本
• 抽取业务规则与约束：从需求文档提取关键逻辑
• 建立文档到代码的映射：追溯需求到实现

03 让二进制“开口说话”

• 无源码理解程序行为：通过反编译、符号执行还原逻辑
• 还原执行逻辑：函数调用序列、数据流向

华清未央自研机器语言大模型，可理解二进制，实现软件原子化。

04 最关键的一步

将代码、文档、二进制等多模态软件资产信息统一到一个语义空间，这一步的意义在于让软件第一次从“文件集合”变成“可推理系统”。

华清未央多模态软件资产治理通过将企业复杂软件资产转成可被理解、可被调用、可被复用的结构化数据层，成为软件向可推理的智能体系统转型的重要入口。

七、当AI开始“操作”系统而非“写”代码

从“写代码”到“操作被理解的系统”

有了统一的语义基础，一旦把“多模态软件资产”接入Harness体系，AI的工作方式会发生质变——它不再是在“写”代码，而是在“操作”一个被理解的系统。

具体表现为：

需求、代码、运行行为自动对齐

• PRD写什么
• 代码实现什么
• 二进制实际做什么
• 可以持续自动比对

问题在“生成阶段”被发现

• 不符合需求→自动拦截
• 逻辑偏差→实时预警

软件变成“可追溯系统”

• 每个组件来源清晰
• 每次变更影响可计算

这其实正是Harness最核心的一层能力：让AI的行为可以被约束、被验证、被追踪。

八、从“知识增强”到“工程控制”

范式转换

理解了RAG和多模态软件资产的本质区别，我们就能看清这场变革的真正含义：这不是量的提升，而是质的转换。

如果用一句更清晰的话区分：RAG做的是给AI更多信息，多模态软件资产+Harness做的是定义AI如何工作。换句话说：RAG是“知识增强”，而这里是“工程控制系统”。

九、Agent+Harness+语义层

新架构浮现

当范式发生转换，整个技术栈的架构也随之重塑。如果从AI Infra角度来看，一个新的三层结构正在出现：

上层：Agent（执行者）

• 写代码
• 调用工具

中层：Harness（控制系统）

• 约束
• 调度
• 评估

底层：多模态软件资产（语义基础）

• 代码/文档/二进制统一理解

关键变化在于：AI能力的上限，不再由模型决定，而由“底层语义+中层控制”决定。

十、补上缺失的一环

从辅助工具到生产力

新架构已经清晰，但行业现状是大多数人还停留在上层。补上底层和中层，是AI从“玩具”变成“工具”的关键一跃。

当前行业有一个非常明显的“断层”：大多数系统停留在RAG、Agent工具调用，但真正缺的是让AI理解软件系统的能力。而一旦这层能力补上，AI就会从“辅助工具”变成真正参与软件工程的生产力。

一些已经在发生的信号：

• Nubank使用Devin完成ETL迁移，效率提升12倍，成本节省20倍
• 某大型银行迁移ETL框架文件，从30-40小时缩短到3-4小时
• EightSleep使用Devin后，数据功能交付量提升3倍

但与此同时，风险也在显现：Replit事件中，AI助手 reportedly 删除了生产数据库，创建了4000个虚假用户，并生成虚假测试结果来掩盖其行为。

十一、结语

AI软件工程方向

AI正在重塑软件工程，但真正的挑战不是让AI写得更快，而是让AI写得“对”。

Harness Engineering+多模态软件资产理解，可能是解决这个问题的关键路径。它不是让AI更聪明，而是给AI一个“可被理解、可被约束、可被验证”的环境。在这个新架构下，AI不再是一个“黑盒代码生成器”，而是一个在明确约束下工作的“软件工程师”。

这或许才是AI软件工程的真正起点。

参考资料

【1】：Cognition Labs. Devin’s 2025 Performance Review. 2025.

【2】：arXiv. The Rise of AI Teammates in Software Engineering (SE) 3.0. 2025.

【3】：arXiv. AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents. 2025.

【4】：Nobl9. A Guide to the Risks of AI Generated Code. 2026.

【5】：arXiv. Scalable Defect Detection via Traversal on Code Graph. 2024.

【6】：arXiv. Semantic Code Graph – an information model to facilitate software comprehension. 2024.

【7】：arXiv. Rethinking Autonomy: Preventing Failures in AI-Driven Software Engineering. 2025.

【8】：arXiv. Artificial Intelligence for Software Architecture: Literature Review and the Road Ahead. 2025.

撰稿：Emily

编辑：空格

审核：Learner0x5a/John/Joy

关于我们

玉衡实验室是华清未央旗下开展前瞻科技研发的实验室，我们秉持“独到、精准、深刻”的内容理念，致力于为决策者、创新者和思想者提供具有穿透力的观点与洞见，在众声喧哗中辨别真正价值。

玉衡实验室

关注我们，一同探索AI乐趣~

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：玉衡实验室 Emily Emily《AI正在“接管”软件工程，但系统正在慢慢失控》