聪明的外行——AI编程在存量代码面前的窘境与新范式预言

going_hlf

513人浏览 · 2026-03-25 19:36:15

going_hlf · 2026-03-25 19:36:15 发布

引言

最近，我一直在观察团队中使用 AI 编程助手的模式与效果。发现了一个有趣的现象：

当我们在一个拥有 10 年历史的存量代码库中引入 AI 时，它表现得像个刚毕业的实习生——经常犯错、需要大量监督、甚至会把整个模块搞崩溃。

但当我们从零开始一个新项目时，同样的 AI 却能展现出架构师的潜质——代码结构清晰、模式运用得当、效率惊人。

这不仅仅是我的个人感受。经过深入思考，我得出了一个结论：

AI 不适合处理增量代码，但它天生就是为全新代码开发而生的。

这个结论背后有着深刻的认知逻辑。今天，我想通过这篇文章，聊聊这个观点。

第一部分：存量代码的“不可理解性”

1.1 问题本质：认知基础的不牢靠

存量代码最大的问题是什么？不仅是代码写得差，而是它承载了太多“隐式上下文”，导致新需求扩展困难。

这些隐式上下文包括：

历史遗留的业务逻辑（“为什么这里要加 1？因为 5 年前有个客户提了个特殊需求”）
多人协作产生的风格冲突（A 喜欢工厂模式，B 喜欢简单函数）
不断妥协的技术债（“本来应该重构，但上线时间不够，先这样吧”）
隐含的依赖关系（“这个函数看起来没用，但删了之后登录就挂了”）

AI 学习的是人类公开发布的代码、文档、最佳实践。它学到的是“理想世界”的编码方式。但存量代码往往是“现实世界”的产物——充满了妥协、历史包袱和非理性的决策。

AI 的认知建立在理想之上，而你的代码建立在现实之上。这两者之间存在一道鸿沟。

1.2 代码案例：AI 在存量代码中的失败

让我们看一个具体的例子。假设我们有一个遗留的订单处理模块：

# 存量代码（有 8 年历史）
class OrderProcessor:
    def __init__(self):
        self.db = LegacyDatabaseConnection()  # 已废弃的数据库驱动
        self.cache = {}  # 手动实现的简陋缓存
        
    def process_order(self, order_data):
        # 为什么要用字符串拼接？因为 2016 年那个版本不支持 JSON
        query = "SELECT * FROM orders WHERE order_id = '" + order_data['id'] + "'"
        
        # 为什么要写这个 if？因为某个大客户的数据格式特殊
        if order_data.get('client_id') == 'SPECIAL_CLIENT_001':
            order_data['amount'] = order_data['amount'] * 1.08  # 加 8% 手续费
        
        result = self.db.execute(query)
        
        # 这个缓存逻辑有 bug，但所有人都不敢动
        if result[0]['status'] in self.cache:
            return self.cache[result[0]['status']]
        
        # 300 行类似的业务逻辑...

现在，假设我们让 AI 帮忙重构这个 process_order 方法：

# AI 给出的“优化”代码
class OrderProcessor:
    def __init__(self, db: Database, cache: CacheService):
        self.db = db  # AI 认为应该用依赖注入
        self.cache = cache
        
    async def process_order(self, order_data: dict) -> dict:  # AI 加了 async
        # AI 使用了参数化查询（这是最佳实践）
        query = "SELECT * FROM orders WHERE order_id = $1"
        
        # AI 移除了特殊客户的特殊逻辑（因为它认为这应该是配置化的）
        # 但这样会导致那个大客户的订单金额计算错误！
        
        result = await self.db.execute(query, order_data['id'])
        
        # AI 改用了现代缓存抽象
        return await self.cache.get_or_set(
            result[0]['status'], 
            lambda: self._process_logic(result[0])
        )

这段 AI 生成的代码技术上更优秀，但它破坏了业务逻辑：

移除了特殊客户的 8% 手续费（业务错误）
改用了异步（与调用方不兼容）
改变了缓存行为（可能引发性能问题）

问题不在于 AI 的能力，而在于 AI 无法理解这 8% 手续费背后的历史故事。

1.3 “重写”的经济学

有人会问：那我们可以花时间让 AI 理解这些存量代码吗？

答案是：可以，但成本可能比重写还高。

让 AI 理解存量代码，你需要：

为 AI 提供完整的业务上下文（可能需要梳理数百个需求文档）
逐个解释历史遗留决策的原因
建立一套“规则库”来约束 AI 的行为
每次迭代都要更新这个知识库

这个过程本身就是一项巨大的工程。等到你终于把 AI “教会” 了，你其实已经完成了一次隐式的重构——既然如此，为什么不直接让 AI 从头重写呢？

这就是核心矛盾：AI 理解存量代码的成本，接近甚至超过了重写这些代码的成本。

第二部分：全新代码的“无主之地”

2.1 为什么 AI 适合从 0 到 1？

当代码库还是空白时，情况完全不同：

没有历史包袱：AI 的所有决策都是基于“当前最优”
认知基础一致：AI 的理想模型就是代码的现实
人机协作清晰：人类负责“做什么”（需求），AI 负责“怎么做”（实现）

在全新项目中，AI 不需要理解任何历史决策，它只需要：

理解当前的需求
运用最佳实践
在反馈中迭代

这完美契合了 AI 的工作模式。

2.2 代码案例：AI 开发全新特性

假设我们要开发一个“用户积分系统”的全新特性。以下是理想的 AI 协作流程：

第一步：AI 生成初始方案

# AI 自动生成的设计文档（固化到 skill）
"""
# 用户积分系统设计文档

## 核心实体
- User: 用户信息
- PointsAccount: 积分账户
- PointsTransaction: 积分流水

## 业务规则
- 用户注册奖励 100 积分
- 每日签到奖励 10 积分（连续签到递增）
- 每消费 1 元获得 1 积分
- 积分有效期为 365 天

## API 设计
- POST /api/points/earn - 增加积分
- POST /api/points/redeem - 兑换积分
- GET /api/points/balance - 查询余额
"""

# AI 自动生成的代码
from datetime import datetime, timedelta
from typing import Optional
from sqlalchemy import Column, Integer, DateTime, ForeignKey
from sqlalchemy.orm import relationship

class PointsAccount(Base):
    __tablename__ = 'points_accounts'
    
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer, unique=True, nullable=False)
    balance = Column(Integer, default=0)
    created_at = Column(DateTime, default=datetime.utcnow)
    updated_at = Column(DateTime, onupdate=datetime.utcnow)
    
    transactions = relationship('PointsTransaction', back_populates='account')
    
    def earn(self, amount: int, reason: str) -> 'PointsTransaction':
        """增加积分"""
        self.balance += amount
        transaction = PointsTransaction(
            account_id=self.id,
            amount=amount,
            type='earn',
            reason=reason,
            expires_at=datetime.utcnow() + timedelta(days=365)
        )
        return transaction
    
    def redeem(self, amount: int, reason: str) -> Optional['PointsTransaction']:
        """兑换积分"""
        if self.balance < amount:
            return None
        
        self.balance -= amount
        transaction = PointsTransaction(
            account_id=self.id,
            amount=-amount,
            type='redeem',
            reason=reason
        )
        return transaction

第二步：人类验证并反馈

人类开发者测试后发现：“连续签到的递增逻辑需要累加，而不是每次都重置。”

第三步：AI 自主修改

# AI 根据反馈修改代码
class PointsAccount(Base):
    # ... 原有代码 ...
    
    def check_in(self) -> 'PointsTransaction':
        """签到奖励（支持连续签到递增）"""
        # AI 自动查询最近签到记录
        last_checkin = self.transactions.filter(
            PointsTransaction.type == 'checkin',
            PointsTransaction.created_at >= datetime.utcnow() - timedelta(days=1)
        ).first()
        
        if last_checkin:
            # 连续签到，奖励递增（AI 自动实现递增逻辑）
            consecutive_days = self._get_consecutive_days()
            reward = min(10 + consecutive_days, 50)  # 上限 50
        else:
            reward = 10
        
        return self.earn(reward, '每日签到')

关键原则：人类不修改代码，只反馈需求。

这样做的好处是：

AI 保持对代码的“所有权”
需求与实现之间的映射关系始终由 AI 维护
人类只需要关注“做什么”，不需要关注“怎么做”

第三部分：从“人懂”到“机懂”的范式转变

3.1 传统开发模式 vs AI 原生开发模式

维度	传统模式	AI 原生模式
代码所有权	人拥有代码	AI 拥有代码，人拥有需求
维护方式	人直接修改代码	人反馈，AI 修改代码
文档更新	事后补充，容易过期	AI 自动维护，实时更新
Clean Code	必须严格遵守	AI 内部优化，人无需干预
重构成本	高，需要人工分析	低，AI 全局理解后自动重构

3.2 Clean Code 在 AI 时代的重新定义

Robert C. Martin 提出的 Clean Code 原则，本质上是让代码对人类友好。但在 AI 原生开发模式中，代码的主要“读者”变成了 AI 本身。

这意味着：

变量命名：AI 不需要你命名成“自解释”的，它理解上下文
函数长度：AI 可以轻松管理 200 行的函数，不会迷失
设计模式：AI 在生成时就天然运用了合适的模式

这不是说 Clean Code 不重要，而是说它的优先级变了。 在新模式下，我们更关注：

需求表达的清晰度（人类给 AI 的反馈是否明确）
设计文档的完整性（AI 能否理解全局架构）
测试覆盖的全面性（验证 AI 的行为是否正确）

3.3 未来预言

基于以上分析，我对 AI 在软件开发中的应用做出以下预言：

AI 在存量代码中的价值会有一个明确的上限。除非重写这些代码，否则 AI 不可能真正融入存量代码的日常维护中。

对于全新项目，AI 将从第一天起就扮演“主导开发者”的角色，人类退居“产品经理+测试”的监督角色。

未来的软件开发将分化为两个世界：

“遗产世界”：由人类维护，AI 只充当结对编程助手（检查语法、建议优化、识别代码异味）

“新大陆世界”：由 AI 主导开发，人类负责需求定义和验收

第四部分：实践建议

4.1 对于存量代码

如果你必须在存量代码中使用 AI，建议将 AI 的角色限制为：

结对编程伙伴：让 AI 检查代码质量，而不是修改业务逻辑
语法和类型检查：识别潜在的类型错误和空指针
冗余检测：找出重复代码和不必要的复杂度
设计模式建议：判断是否适合引入某种设计模式

示例提示词：

不要修改业务逻辑。请分析以下代码的：
1. 潜在的 bug 和边界条件问题
2. 可以提取为公共函数的重复逻辑
3. 是否适合使用策略模式简化条件分支

4.2 对于全新代码

从一开始就让 AI 主导：从项目初始化就让 AI 生成代码
人只反馈，不修改：即使发现小问题，也让 AI 去改
固化设计文档：要求 AI 把架构决策记录在 skill 或文档中
接受“不优雅”：只要功能正确，不要纠结代码风格（AI 有自己的审美）
让 AI 修 bug：即使是生产环境的 bug，也让 AI 分析并修复

结语

AI 不是万能药，也不是洪水猛兽。它有自己的认知边界和适用场景。

存量代码承载的是历史，而 AI 不擅长理解历史。全新代码面向的是未来，而 AI 恰好是创造未来的最佳工具。

接受这个现实，调整你的开发策略，AI 才能成为真正的生产力倍增器。

不要试图让 AI 理解你的屎山——那不是它的使命。它的使命，是帮你建造下一座不需要屎山的新世界。

本文仅代表个人观点，欢迎讨论和反驳。毕竟，技术的未来从来不是预言出来的，而是实践出来的。

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

开源鸿蒙跨平台直播｜RNOH 渲染流程与并行化优化

AtomGit开源社区

AtomGit 9月三方库下载量排行榜重磅发布！开源鸿蒙黑马杀出重围，仓颉生态新锐力量强势破局

AtomGit开源社区

开源鸿蒙社区月度优秀评选公示（6-8月）

AtomGit开源社区

所有评论(0)

查看更多评论

going_hlf

@inTheChangingRoad

已为社区贡献3条内容

聪明的外行——AI编程在存量代码面前的窘境与新范式预言

going_hlf

引言

第一部分：存量代码的“不可理解性”

1.1 问题本质：认知基础的不牢靠

1.2 代码案例：AI 在存量代码中的失败

1.3 “重写”的经济学

第二部分：全新代码的“无主之地”

2.1 为什么 AI 适合从 0 到 1？

2.2 代码案例：AI 开发全新特性

第三部分：从“人懂”到“机懂”的范式转变

3.1 传统开发模式 vs AI 原生开发模式

3.2 Clean Code 在 AI 时代的重新定义

3.3 未来预言

第四部分：实践建议

4.1 对于存量代码

4.2 对于全新代码

结语

所有评论(0)

温馨提示：您尚未绑定手机号

going_hlf