AI 能写代码，为什么很多软件依然很难做？

近两年，ChatGPT、Claude、Gemini、Codex 等 AI 工具普及，软件开发行业巨变。 一个原本几天的页面，现在可能几小时生成；一个简单管理系统，AI 甚至能直接搭出完整原型。

于是很多人开始认为：

• AI 已经可以替代程序员
• 软件开发门槛正在消失
• 软件本身将越来越不值钱
• “既然 AI 都能写，为什么项目报价还这么高？”

这种认知，往往源于对软件开发工作的误解。 AI 最擅长的部分，恰恰不是软件开发最困难的部分。

AI 最擅长的是“已知答案的问题”

大模型本质是：从海量已有知识中寻找模式并组合。 例如：写登录页面、管理后台、CRUD 接口、数据库实体类、REST API。 这些问题有大量公开案例，AI 生成效果很好。 很多人第一次用 AI 编程会震撼：“原来开发这么简单。”

但问题在于：这些并不是软件开发中最难的部分。

真正困难的是“没有标准答案的问题”

现实企业软件项目，大部分工作不是写代码，而是： 理解业务、历史系统、行业规则、用户习惯、隐含需求、系统边界。 很多时候客户自己都说不清需求，需要开发人员靠经验推导。 这些能力不是 AI 擅长的——AI 可学代码，但无法直接学习企业十几年的业务演变过程。

一个典型误区：认为 AI 可随意修改 ONLYOFFICE

有人觉得：ONLYOFFICE 社区版源码开源了，有 AI 帮忙，想改什么功能都行。 实际上，它本质上接近浏览器版 Word/Excel/PPT，背后涉及： OOXML 规范、排版模型、计算引擎、协同编辑算法、评论系统、修订模式、插件体系…… 这些系统往往经过十几年演化，代码量数百万行。 即便源码全给你，不知从何开始。AI 同样如此——它可帮助定位代码、分析逻辑、生成补丁，但并不真正理解设计原因。 能改一个按钮，不等于知道这个按钮会影响多少模块。

能改一个功能，不等于能维护一个产品

AI 可完成局部修改：增加菜单、调整样式、修改接口。 但软件工程真正困难的是持续演进： 今天改功能 → 明天升级 → 后天加模块 → 大后天修兼容 → 半年后支持新格式 → 一年后重构架构。 如果最初修改没有遵循整体设计，后续维护成本指数级上升。 AI 能帮你写代码，却无法替代长期积累的架构经验。

一个真实案例：AI 去除 PDF 水印失败

有人用 Codex 去除 PDF 文本水印。AI 给出了完整方案：安装依赖、下载工具、编写代码、执行处理。 结果：水印没删，反而删了正常文字。 因为 AI 不知道 PDF 水印到底是页面内容流、图层、注释、页眉页脚、Form XObject、OCR 文字层还是渲染后的矢量图形。 人类专家第一步是分析 PDF 结构，而不是直接写代码。

AI 最大的问题不是不会写代码

今天的大模型已能写出相当不错的代码。 真正的问题是：AI 缺乏对问题本身的理解能力。 它像一个经验丰富的助手，而不是真正负责决策的架构师。 它知道很多答案，但未必知道哪个答案适用于当前场景。

为什么经验仍然重要

做十年 Office 软件 vs 做十年电商系统的人，编程能力相近，但面对 Office 项目效率差数倍。 原因不是代码能力，而是领域经验——知道哪些问题一定会出现、哪些改动会产生连锁反应、哪些方案未来无法维护。 这些隐性经验来自长期踩坑，AI 可以学习文档，却无法直接获得。

AI 会淘汰什么？

• 重复劳动：页面搭建、CRUD、接口封装、单元测试、文档整理
• 低门槛实现：企业官网、简单后台、小型工具系统
• 信息搬运：API 调用示例、基础技术方案、常见代码模板

AI 不会淘汰什么？

• 业务理解：理解企业为什么需要这个功能
• 系统架构：设计可持续演进十年的系统
• 领域知识：Office、CAD、PDF、财务、医疗、工业等
• 问题诊断：找到真正根因
• 技术决策：多方案取舍
• 工程治理：保证产品持续维护和升级

这些仍然高度依赖人的经验。

结语

AI 正成为软件开发最重要的生产力工具之一，大幅提升编码效率、降低门槛。 但这并不意味着软件开发变得没有价值。 软件行业最昂贵的部分，从来不是代码本身，而是对复杂问题的理解能力。 代码只是最终呈现形式。真正有价值的，是长期积累的业务经验、领域知识、架构能力和工程判断。 AI 可以帮助人更快地解决问题，但至少在可预见的未来，它仍然无法替代那些真正理解问题的人。