别再研究 AI 怎么写代码了, 软件工程正在开始机器化

当写代码越来越便宜，真正的软件工程开始变贵。

过去两年，大家都在统计一个数字：AI 写了多少代码？

20%、30%、50%……

但这个数字，可能正在迅速失去意义。

因为企业真正需要的，从来不是更多代码，而是更多被正确完成的工作。

当 AI 开始自己理解任务、搜索代码、修改文件、运行测试、发现失败、继续修复，并最终交付一个通过验证的结果时，变化就已经不再是“AI 会不会写代码”。

软件工程本身，开始机器化了。

这里说的“机器化”，不是过去 CI/CD 那种把几个固定步骤自动化。传统自动化解决的是“重复执行”，现在的 Agent 正在尝试解决的是“自主完成”。

自动化解决的是“重复执行”，机器化解决的是“自主完成”。

01 AI Coding 真正的变化，不是“写得更多”

我们过去其实一直把 AI Coding 理解得太窄。

Copilot 时代，AI 做的事情主要是：你写一半，它帮你补完。后来 ChatGPT、Cursor 出现：你描述一个需求，它帮你生成一段代码。

本质上，我们一直在问：AI 能不能替程序员敲键盘？

但软件开发真正困难的部分，从来不只是写代码。真正困难的是：理解需求、判断影响范围、选择方案、遵守系统约束、处理异常、完成测试、Review，并最终判断——这件事到底做对了没有？

写代码，是软件工程的一部分；把一件事正确地做完，才是软件工程。

而现在真正值得关注的变化，就是 AI 开始从前者进入后者。

OpenAI 对 Codex 面向软件工程团队的官方定位已经非常直接：它不只是生成代码，而是可以从 issue 开始，规划修改、写代码、运行测试，再准备一个可以进入人工 Review 的 PR。

也就是说，产品目标已经从 Code Generation，逐渐进入 Task Execution。

02 从 Code Completion，到 Goal → Verified Result

如果把 AI Coding 最近几年的变化拉长来看，大概可以分成三个阶段。

第一阶段：Code Completion

你输入一个函数开头，AI 帮你补完下面的代码。核心关系是：Token → Token。

这时候 AI 更像一个高级输入法。

第二阶段：Coding Agent

你告诉它：给这个接口增加分页，并补充测试。

搜索代码 → 理解项目 → 修改文件 → 执行测试 → 发现错误 → 再继续修改

这个阶段开始变成：Task → Code。

Codex、Claude Code 今天其实已经大量进入这一阶段。

第三阶段：Engineering Agent

未来你给出的可能只是：这个接口最近 7 天 P99 延迟上涨了 30%，找出原因并修复，但不能影响现有调用方。

观察 → 定位 → 制定方案 → 修改 → 测试 → Review → 修复 → 最终验证

Goal → Verified Result

这才是我认为 AI Coding 真正重要的跃迁。

OpenAI 在自己的内部实验中已经走得更远。2026 年 2 月，他们公开了一次很有意思的实践：一个真实运行的内部软件产品，应用逻辑、测试、CI、文档、可观测性和内部工具，全部由 Codex 生成，没有人工直接提交代码。

更值得关注的不是“100 万行代码”，而是他们最后总结出来的一句话：Human steer. Agents execute.

人的工作开始从直接写代码，转向设计环境、明确意图、建立反馈循环。

这已经不是简单的 AI 辅助编程，而是软件生产方式本身在发生变化。

03 真正的竞争，正在从模型变成“工程系统”

这时候会出现一个很有意思的现象。两家公司可能使用完全一样的模型，都用 GPT，都用 Claude。

但 A 公司的 Agent 可以自主完成一个 Feature，B 公司的 Agent 只能帮程序员写几个函数。

为什么？很可能不是模型差距。

A 公司给 Agent 建了一间整理好的工厂；B 公司只是把 Agent 扔进一个杂乱的仓库。

Prompt 当然仍然重要，但它会越来越像整个工程系统中的一个组件，而不是决定 AI Coding 效果的全部。

真正决定 Agent 能不能稳定工作的，是 Context、Specification、Execution、Verification 和 Governance。

我把它叫做：软件工程机器化的五块基础设施。

1. Context：这个系统是什么？

• 系统架构

• 模块职责

• API 约束

• 业务术语

• 历史设计决策

• 常见坑

• 项目规则

例如 AGENTS.md、Architecture Docs、ADR、Repository Instructions。OpenAI 在 Codex 官方文档里也强调过：配置好的开发环境、可靠的测试和清晰的文档，会直接影响 Coding Agent 的表现。

2. Specification：到底要做什么？

• 业务目标

• 预期结果

• 影响范围

• 禁止修改

• 异常场景

• 验收标准

• 验证命令

换句话说，把模糊需求，变成可执行的 Specification。

3. Execution：Agent 怎么完成？

搜索代码 → 修改文件 → 执行命令 → 运行测试 → 读取错误 → 再继续修复

过去这些动作必须一个程序员逐个完成。现在它们开始变成一个持续运行的 Loop。

4. Verification：怎么知道它做对了？

这是整套系统里，我认为最重要的一层。因为 Agent 最大的问题从来不是“它能不能生成代码”，而是“谁来判断这些代码真的正确？”

• Unit Test

• Integration Test

• Contract Test

• Lint

• Security Scan

• Performance Test

• Acceptance Test

最终目标只有一个：让“完成没完成”变成机器能够判断的问题。

Machine-verifiable Acceptance Criteria

机器可验证的验收标准

只有 Verification 足够强，Agent 才能真正形成：尝试 → 失败 → 修复 → 再验证的闭环。

5. Governance：Agent 什么不能做？

Agent 能力越强，这一层越重要。当 Agent 可以访问 Git、Shell、CI、数据库、云资源和生产环境，问题就不再只是 AI 好不好用，而是 AI 被允许做什么。

• Allowed Paths

• Allowed Commands

• Approval Gates

• Audit Logs

• Rollback

• Secret Protection

OpenAI 今年专门公开了内部运行 Codex 的安全实践，核心就是明确 Agent 的访问边界、人工审批点和审计能力。Anthropic 也提出了一个很形象的概念：Blast Radius。

AI Coding 正在从开发工具问题，进入工程治理问题。

04 不要再统计 AI 写了多少代码，开始统计 AI 完成了多少工作

今天很多公司评价 AI Coding，会说：我们 AI 生成代码占比已经达到 30%。

这个指标有价值，但长期看远远不够。

假设 AI 写了 90% 的代码，但最后工程师仍然需要重新阅读全部代码、手动运行测试、判断影响范围、修一堆 Bug、再手动提交，那么 AI 本质上仍然只是一个非常快的打字员。

真正值得关注的，我认为应该是两个指标。

第一个：任务自主闭环率

Autonomous Task Completion Rate

无需人工介入并通过最终验收的任务数 ÷ Agent 接收任务总数

比如一个月给 Agent 100 个任务，其中 65 个无需人工介入并通过最终验证，20 个需要人工接管，15 个失败。

那么任务自主闭环率 = 65%。

AI 代码占比衡量的是 AI 参与了多少；任务自主闭环率衡量的是 AI 完成了多少。

企业真正购买的，从来不是 Token，也不是代码行数，而是已经完成的工作。

第二个：自治工程跨度

Autonomous Engineering Horizon

Agent 在不需要人接管的情况下，可以持续完成多长的工程任务？

一个函数 → 一个 Bug → 一个 Issue → 一个跨文件 Feature → 一个完整 Work Item → 甚至一个 Sprint

Anthropic 今年分析了大约 40 万次 Claude Code 会话，发现一个很明显的变化：人在典型会话中更多负责决定“做什么”，Claude 更多负责决定“怎么做”。而且随着时间推进，使用方式也在从 Debugging，逐渐向更完整的端到端任务迁移。

自动驾驶有一个很好的类比。真正重要的问题从来不是 AI 会不会转方向盘，而是它能连续开多少公里不需要人接管。

Coding Agent 也一样。真正的进步不是又能多写多少代码，而是可以独立承接多长的工作链。

未来评价 Coding Agent，可以只看一个二维坐标：横轴是任务自主闭环率，纵轴是自治工程跨度。真正的进步，就是两个数字不断向右上方移动。

05 当代码越来越便宜，程序员的工作会继续向上移动

到了这里，很容易滑入一个老问题：那程序员是不是要被取代了？

我反而觉得，这不是最值得讨论的问题。

因为计算机行业过去几十年一直在发生一件事情：人的抽象层不断上移。

机器码 → C / Java → Framework / Cloud / Kubernetes → Agent

现在，人的抽象层可能又开始向上移动：

写代码 → 定义任务 → 定义约束 → 定义验证 → 设计软件生产系统

所以未来优秀工程师的价值，未必只是“我能写最复杂的代码”，而可能越来越变成：我能让一个软件生产系统持续正确地工作。

这也会重新定义 Tech Lead。

以前：Review Code → 以后：设计 Review System

以前：告诉开发怎么做 → 以后：把“应该怎么做”编码成规则

以前：发现问题亲自解决 → 以后：定义哪些问题 Agent 自己解决，哪些必须升级给人

过去程序员编程软件。未来越来越多优秀工程师，会开始编程“软件生产系统”。

06 如果你负责一个研发团队，明天就可以开始做这 5 件事

不用一上来搞十几个 Agent，也不用先搭一个宏大的 AI Coding 平台。

真正值得做的是，把现有项目一点一点变成：机器可以理解的软件工程系统。

第一步：给核心项目补一份 AGENTS.md

至少明确：项目是什么、核心模块是什么、哪些模块不能乱动、怎么运行、怎么测试、有哪些工程约束。

先把高级开发脑子里的知识，沉淀到 Repository 里。

第二步：修改你的研发任务模板

以后重要开发任务至少增加：业务目标、影响范围、禁止修改、异常场景、验收标准、验证命令。

不要只写“实现 XX 功能”，而要让 Agent 能够判断什么时候才算真正完成。

第三步：盘点哪些验收条件还只能靠人判断

比如“页面看起来正常”“性能没问题”“不会影响旧接口”，这些对于 Agent 都太模糊。

逐渐把它们变成自动化测试、性能阈值、Schema Check、Contract Test、Regression Test。

你的 Verification 越强，Agent 才越能自主。

第四步：先建立一个最小闭环

Task → Implement → Test → Repair → Verify

不要马上追求自动上线。哪怕一开始只能处理很小的 Bug，只要 Loop 能自己跑起来，后面能力就会慢慢叠加。

第五步：开始统计“自主闭环率”

不要只统计 AI 使用次数，也不要只统计 AI 代码占比。开始真正记录：多少任务 Agent 接了？多少任务无需人工介入完成？什么地方最容易被人工接管？为什么会失败？

然后每一次失败，都不要只想着“换一个 Prompt 再试试”，而应该多问一句：我们的工程系统缺了什么？

缺 Context？

缺测试？

缺工具？

缺权限？

还是缺验收标准？

这才是 Harness Engineering 真正有价值的地方。

软件工程从来没有等于写代码。只是过去，代码本身足够昂贵，以至于我们经常把两者混在一起。

当 AI 开始快速降低代码生成的边际成本，真正稀缺的东西才会慢慢浮出来：

• 如何定义正确的问题

• 如何建立可靠的边界

• 如何验证最终结果

• 如何把个人经验变成组织能力

OpenAI 在自己的 Agent-first 工程实践里总结：工程师的工作正在越来越集中在环境、反馈循环和控制系统上。

Anthropic 的真实使用数据也显示：人在越来越多负责“决定做什么”，而 Agent 开始承担更多“怎么做”。

这两件事放在一起，其实已经指向同一个方向。

AI Coding 的终局，可能从来不是：程序员终于不用写代码了。

而是：软件工程第一次开始从一套高度依赖人脑的工作方式，变成一套机器可以理解、执行、验证和持续运行的系统。

过去程序员编程软件。未来，越来越多程序员会开始编程：生产软件的系统。

当代码越来越便宜之后，真正的软件工程，开始变贵。