ARTICLE · 1039988
AI 时代的大型软件工程:我们真正需要解决的三个问题
AI 时代的大型软件工程:我们真正需要解决的三个问题最近我一直在思考一个问题： 当 Codex、Claude Code 这样的编程 Agent 已经具备越来越强的编码能力之后，大型软件项目的工程方法到底会发生什么变化？ 一开始，我们很容易把注意力放在模型本身： 它能不能写出更好的代码？ 能不能理解一个几十万行甚至几百万行代码的项目？ 能不能一次完成更复杂的任务？ 但随着实践越来越多，我发现真正的问题正在发生变化。 当“生成代码”越来越便宜之后，真正稀缺的能力开始变成：如何组织大量 Agent 持续、并行、可靠地工作。 这已经不只是写代码的问题，而重新回到了软件工程。
不管参与开发的是 10 个人，还是一个人带着 10 个 Agent，本质上我们都希望提高三个东西。 让更多任务能够同时执行。 过去一个工程师可能同时只能推进一两个主要任务。 现在理论上，我可以同时启动多个 Agent： Agent A 开发用户系统 Agent B 开发支付模块 Agent C 重构数据库 Agent D 编写测试 Agent E 进行代码审查 代码生成速度已经不再是最大的瓶颈。 真正的问题变成： 这些 Agent 能不能真正并行，而不是互相制造冲突？
第二个目标，是让 Agent 工作得更久。 现在很多 AI 编程的工作方式仍然是： 人给一个任务 → Agent 做一点 → 停下来 → 人检查 → 再给指令。 这种模式虽然提高了编码效率，但人的注意力仍然是整个系统的调度中心。 真正有价值的 Agent 应该形成一个完整的闭环： 目标 → 规划 → 实现 → 测试 → 发现问题 → 修复 → 验证 → 继续执行 也就是说： 我们希望 Agent 从“执行一条命令”，逐渐变成“持续完成一个目标”。 Agent 能连续可靠运行的时间越长，人类能够管理的 Agent 数量就越多。
第三个目标不是简单地“不要人”。 而是： 让人从低价值、高频率的执行工作中退出。 人的工作逐渐从： 写代码、跑测试、修复问题、检查文件、手动合并…… 转向： 定义目标 架构设计 划分边界 定义接口约定 确定优先级 制定验收标准 判断风险 最终决策 最终，一个人的产出不再主要取决于： “这个人一天能写多少代码。” 而取决于： “这个人能够组织多少可靠的 Agent，为同一个目标持续工作。”
这时候一个很自然的想法出现了： 既然 Agent 很便宜，那我开 10 个、50 个、100 个 Agent 不就可以了吗？ 问题恰恰出现在这里。 并行不是 Agent 数量的问题，而是工程结构的问题。 如果 10 个 Agent 同时修改相同的文件，不了解彼此的接口，不知道模块边界，也没有统一的验收标准，那么增加 Agent 数量反而可能降低效率。 所以 AI 时代并没有消灭传统软件工程。 恰恰相反： Agent 数量越多，对软件工程的要求越高。 这也是为什么大型项目依然离不开： Git、架构设计、模块边界、接口约定、数据结构、测试、代码合并、持续集成和自动部署。 它们过去解决的是“多人协作”。 未来还要解决： 多 Agent 协作。
这是我最近越来越重视的一条原则。 人和 AI 都无法携带过去本身，只能携带过去留下的结构。 人的记忆有限。 而 Agent 的执行上下文更加明显——一个任务结束以后，它在执行过程中形成的大量理解，并不会天然成为项目的一部分。 假设一个 Agent 花了三个小时解决一个问题。 它可能经历了： 尝试方案 A → 失败 尝试方案 B → 出现性能问题 阅读源码 → 发现一个隐藏约束 测试方案 C → 成功 最终提交代码 代码保存下来了。 但是： 为什么 A 不行？为什么 B 被放弃？发现了什么隐藏约束？为什么最后选择 C？ 这些东西很可能全部消失。 三个月以后，下一个 Agent 很可能重新尝试方案 A。 然后重新踩一次相同的坑。 所以一个长期项目不能只保存结果。 还必须保存： 形成这个结果所需要的知识。
传统项目主要留下两类东西： 代码 + 文档。 它们非常重要，但并不足够。 比如代码里有： timeout = 30s 代码告诉我们： 超时时间是 30 秒。 文档可能告诉我们： 系统请求超时时间设置为 30 秒。 但真正重要的项目知识可能是： 最开始设置为 5 秒。 生产环境发现某些任务会超过 5 秒。 后来改成 60 秒。 压测又发现连接占用时间过长。 最终根据实际数据确定为 30 秒。 并且流式接口不使用这个超时规则。 于是： 30 秒是结果。 而前面的过程才解释了： 为什么是 30 秒。 所以 AI 时代的项目至少应该保存两类信息。 第一类：结果结构 包括： 源代码 接口定义 数据结构 系统架构 测试 使用文档 这些东西告诉后来者： 这个系统现在是什么样子。 第二类：过程结构 包括： 决策 ：为什么这样做 重要发现 ：过程中发现了什么 约定 ：团队和 Agent 之间形成了哪些规则 踩坑记录 ：哪些地方容易出问题 放弃的方案 ：哪些方法试过但最终没有采用，以及为什么 当前进度 ：现在做到哪里 已经完成的任务 ：哪些事情不需要重复做 下一步任务 ：接下来应该做什么 这些东西告诉后来者： 这个系统为什么会变成现在这个样子。 这两类结构共同构成了一个大型项目真正的长期记忆。
因此，我现在对 AI 记忆的理解也发生了变化。 记忆的目标不是： 让 AI 永远记住所有事情。 这是不现实的，也没有必要。 真正需要的是： 让未来的 Agent 能够根据过去留下的结构，重新构建当前任务所需要的上下文。 所以真正的循环应该是： 执行 → 产生经验 → 留下结构 → 重建上下文 → 下一次执行 Agent 每执行一次任务，都会产生新的经验。 其中真正重要的部分被留下来。 这些信息逐渐成为项目结构的一部分。 未来另外一个 Agent 开始工作的时候，再从这些结构中恢复自己需要的上下文。 这样项目本身就开始拥有一种： 跨任务、跨 Agent、跨人员、跨时间的连续性。
Codex、Claude Code 等工具实际上已经帮我们完成了大量底层 Harness。 例如： 读取代码、搜索代码、修改文件、执行命令、运行测试、Git 操作、调用工具、上下文管理、子 Agent…… 这些通用能力已经越来越成熟。 所以我们真正需要建设的，不一定是另外一个编程 Agent。 而是： 属于我们自己项目的 Harness。 它应该定义： 项目目标 整体架构 模块边界 接口约定 数据结构 业务知识 开发规则 验收标准 测试与验证方法 性能指标 工作流程 项目记忆 底层的编程 Agent 负责执行。 上层的项目 Harness 负责告诉它： 在哪里工作、能做什么、不能做什么、什么叫完成，以及怎么证明自己做对了。
所以现在如果让我重新启动一个大型项目，我不会第一时间让 Agent 开始疯狂写代码。 我会先建立几个基础设施。 第一：建立项目 Harness 首先定义整个项目的工作方式。 Agent 如何接任务？ 如何读取上下文？ 重要发现记录在哪里？ 决策记录在哪里？ 任务完成以后留下什么？ 如何验证？ 失败以后如何继续？ 这相当于先建立一套： “Agent 在这个项目里应该如何工作”的规则。
第二：建立 Git 源码管理体系 Git 依然是整个大型开发体系的基础。 分支、独立工作区、提交、PR、合并、回滚…… 以前 Git 管理的是多人协作。 未来它同时管理的是： 人 + Agent + Agent + Agent。 没有可靠的源码管理，就很难实现真正的大规模并行开发。
第三：完成架构设计、边界划分和接口约定 如果想真正实现并行开发，就必须能够划分任务。 而任务能不能划分，本质上取决于边界是否清楚。 模块 A 和模块 B 谁负责什么？ 依赖方向是什么？ 接口是什么？ 数据结构是什么？ 哪些东西允许修改？ 哪些东西不能碰？ 所以： 没有清晰的边界，就没有真正的并行。
第四：建立验证体系 这是我认为 AI 编程时代极其重要的一层。 如果一个 Agent 每完成一步都必须问人： “我这样做对不对？” 它就永远无法真正自主运行。 所以必须尽可能把“对不对”变成机器可以判断的问题。 例如： 单元测试 集成测试 端到端测试 类型检查 代码规范检查 性能测试 服务质量指标 验收标准 它们共同解决一个问题： Agent 如何知道自己做对了？ 验证体系越完善，Agent 能够自主运行的时间就越长。
第五：建立集成、测试和部署流水线 Agent 可以并行产生大量代码。 但最后这些代码必须汇合。 因此： 代码提交 → PR → 自动验证 → 合并 → 集成测试 → 构建 → 部署 仍然是大型项目非常重要的主干。 AI 改变的是这个流程中大量工作的执行者。 而不是让这个流程消失。
第六：建立项目记忆 最后，就是前面所说的“留下结构”。 持续记录： 决策、重要发现、约定、踩坑记录、放弃的方案、当前进度、已经完成的任务、下一步任务。 让项目能够跨越： 任务、Agent、人员和时间。
这可能是一个看起来有些矛盾的结论。 很多人认为： Agent 越聪明，我们越不需要软件工程。 我的实践感受恰恰相反。 当一个 Agent 写 500 行代码的时候，很多问题可以靠人检查。 当 20 个 Agent 一天产生几万行修改的时候，人已经不可能逐行理解所有变化。 于是我们更加依赖： 边界、接口约定、测试、验证、性能指标、持续集成和系统架构。 因为我们必须把人的判断逐渐转化为： 机器可以理解、执行和验证的结构。 所以： AI 降低的是生成的成本，但没有消灭理解复杂系统和控制复杂度的成本。 甚至当生成速度提高几个数量级以后，后者会变得更加重要。
回到最开始的三个目标： 第一，提高并行度 让更多任务可以同时执行。 第二，提高自主性 让每一个 Agent 可以独立运行更长时间。 第三，提高人的杠杆率 让一个真正理解系统的人，可以管理越来越大的机器执行能力。 但这里还有一个非常重要的前提： 可靠性。 因为 100 个 Agent 同时工作 10 个小时，如果产生的结果无法验证，并没有意义。 所以最终可以形成一个非常简单的关系： 并行度 × 自主性 × 可靠性 → 人的杠杆率 真正困难的问题已经不再只是： “如何让 Agent 写更多代码？” 而变成： 如何让越来越多的 Agent，在越来越少的人类干预下，长时间、并行、可靠地完成一个复杂目标？ 当问题这样定义以后，我们会发现： Git、架构设计、边界划分、接口约定、验证体系、持续集成、项目记忆、Harness…… 这些看起来属于不同领域的东西，其实都在解决同一个问题。 而这可能才是 AI 时代大型软件工程真正值得研究的方向。