ARTICLE · 1299064

软件开发正在变得越来越像做Research

发布时间：2026-11-03 02:06:43 最近访问：2026-11-03 02:06:46

随着软件研发自动化程度不断提高，人类正在成为整个研发流程中带宽最低、速度最慢的环节。人类不可能长期逐行理解、审查和批准 AI 生成的每一处代码，因此必然逐步从高频执行环节中被优化出去。

这并非简单的工具升级，而是从传统机器学习、深度学习到以 LLM 为基础的通用智能体不断演进的必然趋势。这与 Rich Sutton 在《The Bitter Lesson》中提出的观点高度一致：长期来看，能够利用计算规模化扩展的一般方法，往往胜过依赖人类预先注入知识的专门方法。

在这一趋势下，代码正在变得越来越不可读。不是 AI 写得不好，而是代码规模和迭代速度已经超出人类完整理解和 Review 的能力。代码逐渐有点像神经网络的参数：决定系统行为，却不再适合通过逐一检查来理解和证明系统的正确性。

当代码无法再被人类完整理解时，软件工程就必须从依赖阅读代码，转向依赖 Specification、Evaluation 和 Evidence。

这也是为什么我认为，AI 正在推动软件工程从 Code-centric Engineering 走向 Research-driven Engineering。

一、根因：AI 改变了软件研发的不确定性结构

传统软件工程的基本假设是：人类理解问题、设计方案并编写代码，测试负责验证实现。

AI Coding 改变了这个过程。代码生成成本大幅下降，但生成结果并不天然正确。

即使需求明确、技术方案成熟，AI 仍然可能生成存在逻辑缺陷、并发问题、安全漏洞或架构隐患的代码。

这里需要区分三种不确定性：

不确定性	核心问题	典型场景
Problem Uncertainty	我们到底要解决什么问题？	需求探索、根因分析
Solution Uncertainty	应该采用什么方案？	架构设计、技术选型
Implementation Uncertainty	生成的实现是否正确？	AI Coding、代码修改、系统集成

传统软件研发主要依赖工程师的专业能力来控制这三种不确定性。

AI 时代，前两种不确定性并没有消失，但第三种不确定性变得更加突出：即使问题和方案都已经明确，AI 生成的代码仍然需要独立验证。

因此：

Routine Development 并不意味着不需要 Research，也不意味着不需要 Eval。它只是探索未知的成本较低，但实现仍然需要验证。

软件研发的核心活动正在从单纯的代码生产，转向问题定义、方案探索、实现生成和结果验证。

二、有趣的对照：Research、Machine Learning 与 Software Engineering

科学研究的核心是发现未知、形成可信知识；机器学习的核心是从数据中学习规律，并验证模型的泛化能力；软件工程的核心是构建满足目标的软件系统。

三者的目标不同，但在 AI 时代，工作方法正在出现越来越多的交集。

1. Research 与 Software Engineering

Research	Software Engineering
Research Question	Requirement / Specification
Literature Review	技术调研、代码与历史方案分析
Hypothesis	技术方案、设计假设
Experiment	原型实现、系统实验
Observation	Runtime Metrics、Trace
Verification	测试、验收、质量评估
Research Findings	技术决策、实现结论、ADR
Reproducibility	实验可复现、构建可复现

值得思考的是：软件架构设计是否也应该像科学研究一样，先提出假设，再通过实验验证，而不是仅仅依靠架构师的经验和判断？

2. Machine Learning 与 AI Software Engineering

这一组对照可能更加有趣。机器学习长期面对的问题，恰恰是如何在无法完全理解模型内部机制的情况下，判断其表现是否可靠。

Machine Learning	AI Software Engineering	值得思考的问题
Training Set	开发反馈集	Agent 反复使用哪些案例修改代码？
Validation Set	方案验证集	如何比较不同实现和架构？
Test Set	独立测试集	如何避免 Agent 只适应已知测试？
Overfitting	测试过拟合	代码是否只是学会通过测试？
Generalization	行为泛化	未见过的场景是否仍然正确？
Cross Validation	跨场景验证	是否只适用于某个客户或环境？
Testbed	Sandbox / 测试环境	如何建立可重复的实验条件？
Benchmark	Engineering Benchmark	如何客观比较研发方法？
Ablation Study	架构消融实验	某个 Agent 或组件是否真的有价值？
Reproducibility	实验可复现性	能否复现某次 Agent 的执行与结果？
Distribution Shift	生产环境分布变化	测试环境与真实业务是否存在偏差？

这里有几个特别值得关注的启发：

第一，测试集需要分层。

不能让 Agent 反复利用同一套测试案例修改代码，再用同一套测试证明实现正确。应该区分开发反馈集、方案验证集和独立测试集。

第二，必须警惕 Overfitting。

测试全部通过，不代表系统真正满足需求。Agent 可能只是针对已知测试做了优化。真正重要的是未见场景下的泛化能力。

第三，架构设计也需要 Ablation Study。

多 Agent、Planning、Memory、Skill、Reviewer 等组件是否真的提升了系统能力？应该通过对照实验，而不是凭借架构图的复杂程度判断。

第四，软件测试环境应该像科学实验室一样建设。

固定环境、数据、依赖、实验条件和测量指标，才能让不同方案之间具有可比较性。

3. 从测试通过到科学证据

传统测试主要回答：代码是否满足已知测试条件？

Research 和 Machine Learning 则进一步追问：

结论是否有充分证据？

实验是否能够复现？

是否排除了其他解释？

是否存在过拟合？

是否具有泛化能力？

未来软件研发也应该逐渐建立这样的评价标准。

测试通过只是证据的一部分，而不是正确性的最终证明。对于关键系统，还需要结合不变量检查、故障注入、形式化验证和生产环境观测。

三、Research 不取代 Engineering，而是赋能 Engineering

这里需要区分两个不同层次的问题：

Research 解决的是如何发现未知、探索解决方案、形成新知识。

Engineering Workflow 解决的是如何将目标转化为可管理、可执行、可验证、可交付的软件变更。

两者并不是替代关系。

1. Issue → Code → PR → Merge 依然是正确的工程控制流程

传统软件研发的基本流程：

Issue → Code → PR → Merge

依然是非常好的研发组织和质量控制机制。

阶段	核心职责	AI 时代的变化
Issue	定义问题、范围、验收标准	AI 辅助需求澄清、拆解和规范化
Code	实现需求	Agent 自主编码、调试、测试
PR	提交变更、审查和验证	自动 Review、Eval、质量门禁
Merge	正式集成、形成版本	自动化检查通过后审批和合并

这个流程的价值不仅是管理代码变更，还包括：

工作单元化：将复杂目标分解成可执行任务。

过程可追踪：每个变更都有明确的来源和责任。

质量可控制：PR 是重要的审查和验证边界。

结果可审计：决策、代码和验证结果都有记录。

协作可扩展：多个 Agent、工程师和团队可以围绕统一工作单元协作。

因此，未来不是抛弃这套流程，而是让 AI 能够自主执行这套流程。

2. Research 是按需嵌入的探索能力

Research 并不是替代 Issue 流程，也不是所有开发任务都必须经过一套完整的科研流程。

它应该根据任务的不确定性动态触发。

例如：

任务类型	工作方式
已知问题、已知方案	直接进入工程执行
已知问题、未知方案	通过 Research 探索方案，再进入工程执行
未知问题、问题边界不清晰	先研究、定义问题，再形成 Issue
执行中发现未知问题	暂停原有执行，进入研究和实验，再继续研发

以数据库性能优化为例：

如果问题和优化方案都已经明确，Agent 可以直接按照既有 Skill 完成代码修改、测试和 PR。

如果不知道性能瓶颈在哪里，则需要：

Hypothesis → Experiment → Evidence → Decision。

例如提出索引设计、查询优化或缓存策略等候选假设，通过 Profiling、Benchmark 和对照实验寻找证据，最终选择方案，再回到 Issue → Code → PR → Merge 的工程流程。

Research 是解决未知问题的方法论，Issue 流程是组织和控制软件变更的方法论。两者是互补关系。

四、Engineering Knowledge Base：自动化研发真正的基础设施

我认为这里可能是整个问题最值得重视的部分。

Issue → Code → PR → Merge 不应该只是一套流程规范，而应该在长期实践中沉淀出一套完整的 Engineering Knowledge Base。

因为 Agent 要真正具备自主研发能力，不能每次都从零开始。

它需要知道：

项目的架构是什么？

历史上为什么做出这些技术决策？

需求应该如何分析和拆解？

编码和测试应该遵循什么规范？

如何判断实现是否正确？

过去遇到过哪些类似问题？

哪些方案经过验证，哪些方案已经被证伪？

这些知识不能只依赖每次对话中的上下文，而应该成为可以被持续检索、执行、验证和更新的工程资产。

可以分为几个类别：

知识类型	具体内容	对 Agent 的价值
Engineering Playbook	需求分析、TR1、TR2、开发、测试规范	知道如何工作
Architecture Knowledge	架构设计、接口规范、ADR	知道系统应该如何构建
Coding Standards	编码规范、设计模式、工程约束	知道如何实现
Testing Knowledge	测试策略、测试案例、质量标准	知道如何验证
Historical Knowledge	历史 Issue、PR、Bug、解决方案	利用已有经验
Evaluation Assets	Benchmark、Eval、回归测试集	判断结果是否合格
Operational Knowledge	部署、监控、故障恢复	确保交付后的可靠性