如果你这两天刷技术社区可能已经注意到一个有点“反差感”的视频主题写《代码整洁之道》的 Uncle BobRobert C. Martin在聊 AI 时代的软件工程基础。很多人第一反应是一个 70 多岁的软件工程老前辈讲 AI 是不是有点跟不上时代但恰恰相反Uncle Bob 是 Agile Manifesto 的签署人之一也是过去几十年里对“专业主义”“纪律”“可测试性”强调得最狠的技术布道者。他谈 AI不是站在“AI 会怎样改变世界”的宏大叙事上而是站在“程序员每天该怎么干活”的微观视角上。这个视角恰恰是当前 AI 编程讨论里最稀缺的。这篇文章我想帮你做几件事梳理 Uncle Bob 的核心观点以及他为什么在 AI 时代反复强调“软件工程基础”。把“基础”落到四个具体层面需求、设计、测试、纪律。用可运行的代码示例演示“AI 生成代码 TDD Clean Code”到底怎么配合。给出实际接入 AI 编程助手时容易踩的坑和工程建议。不管你是刚用 AI 写代码的新手还是已经在团队里推广 AI 编程的技术负责人这篇文章都值得收藏后慢慢看。核心判断我先放在这里AI 真正改变的不是“写代码”这件事而是把程序员的压力从“生成代码”转移到了“理解、验证和维护代码”上。软件工程基础不再是选修课而是 AI 时代的生存技能。1. 为什么 AI 时代还要听 Uncle Bob 讲基础先说一个很现实的问题AI 编程助手已经能生成大段可用代码为什么还要强调“基础”如果你只看 Demo会觉得 AI 已经替我们完成了 80% 的工作。但真实场景根本不是这样。AI 生成代码时它并不理解你的业务约束不理解你的团队约定不理解你的部署环境更不会为你的技术债负责。它只是基于大规模代码语料给出一个“看起来正确”的统计结果。这个结果能不能直接上线取决于使用它的人有没有工程判断力。Uncle Bob 的最新分享正好点在这个问题上。他的核心观点可以概括成一句话工具越强纪律越重要。这个判断背后的逻辑并不复杂。在 AI 出现之前写代码的速度本身就是一种约束。一个人一天能写的代码量有限哪怕故意写差造成的破坏也可控。但 AI 把“生成代码”变成了一项成本几乎为零的操作。你可以在一个下午生成过去一周才能写完的代码量——如果这些代码没有测试保护、没有清晰的边界、没有命名规范那你欠下的不是代码而是几倍于此的理解成本和排错成本。从材料看Uncle Bob 在演讲中反复回扣“软件工程”这个概念本身。他提醒大家软件开发中真正昂贵的从来不是写代码而是搞清楚要做什么。保证改代码时不会弄坏已有功能。让后来的人能读懂并接手。在需求变化时能以可控成本调整系统。这些在任何时代都是工程问题而 AI 只是把“写代码”这个环节压缩了工程问题一个都没消失。甚至因为产出速度变快工程问题的爆发速度也变快了。这才是 Uncle Bob 谈“基础”的真正原因不是老派守旧而是 AI 让“空中楼阁”式开发的危险性被放大了。2. 核心概念软件工程基础到底包括什么为了后续讨论不流于口号我们先定义清楚“软件工程基础”是什么。结合 Uncle Bob 长期以来的观点软件工程基础可以拆成四个层次层次核心问题对应能力AI 时代的挑战需求层我们到底要做什么需求澄清、验收标准、行为约束AI 会顺着模糊需求自行“脑补”行为设计层代码如何组织才能长期演进职责划分、依赖方向、架构边界AI 默认生成“一次性代码”缺乏结构意识验证层怎么证明它是对的单元测试、集成测试、契约测试AI 可以生成代码但不会帮你验证正确性纪律层团队如何保持一致的质量底线TDD、Code Review、重构、CIAI 生成速度远快于 Review 速度质量门槛容易被冲垮注意这四个层次的顺序。需求在最前面不是偶然。Uncle Bob 多次强调过一个观点软件开发的大部分失败根因不是技术实现而是需求没有形成精确的、可验证的表述。很多人以为“软件工程基础”等于“写代码的基本功”这是最大的误读。在实际开发里真正区分普通程序员和资深程序员的是前三层的综合判断力。代码写得快从来不是核心竞争力代码写对了且长期能改才是。这个框架对 AI 时代的启示非常直接如果你没有需求层的澄清能力AI 的生成能力只会让你更快地做错误的东西如果你没有验证层的测试习惯AI 的生成能力只会让你更快地积累不可维护的代码如果你没有纪律层的团队约束AI 的生成能力只会让代码风格和架构一致性加速崩溃。3. 需求层提示词工程本质上就是需求工程这一章值得所有 AI 编程使用者反复读。因为在我看来这是 Uncle Bob 观点里和“AI 编程”碰撞最激烈的地方。先说结论提示词写得好不好本质上是需求表达得好不好。很多人用 AI 编程助手时习惯这样提问帮我写一个用户登录功能这个提示词看起来简单但实际上没有任何工程信息。它至少缺了以下内容登录凭据是什么用户名密码、手机验证码、还是第三方 OAuth密码存储用什么算法连续失败需要锁定吗锁定多久登录成功后的会话保存方式是什么是否需要验证码失败提示信息怎么做才不会泄露用户是否存在接口返回结构是什么这个功能是 Web 端、移动端还是前后端分离AI 拿到“帮我写一个用户登录功能”的时候它不会反问你——它只会根据统计概率挑一个最常见的实现方式。这个实现可能正好适合你也可能完全不适合。更麻烦的是它会表现得非常自信看起来每一行都合理。在传统开发模式里需求不清楚至少还要和产品经理开个会或者自己停下来想一想。但在 AI 编程模式下反馈速度极快人们倾向于连续提问连续接受结果。这样一个小时之后你可能已经积累了几百行方向错误、但看起来“能跑”的代码。那怎么把需求层做扎实一个真正有用的模板是把用户故事写成可验证的行为规约。作为【角色】 我希望【功能】 以便【业务价值】 验收标准 - 当【条件A】时系统应该【行为X】 - 当【条件B】时系统应该【行为Y】 - 当【条件C】时系统应该【异常处理Z】这个模板看起来像写文档实际上是在对 AI 做“约束”。AI 生成的自由度越高错误越隐蔽约束越明确AI 生成的结果越可控。我们可以做一个对比。同样是“登录功能”升级后的提示词可以是实现一个用户名密码登录接口要求 1. 输入用户名、密码。 2. 用户不存在时统一返回“用户名或密码错误”。 3. 密码使用 BCrypt 算法存储和校验。 4. 连续失败 5 次后该账号锁定 30 分钟。 5. 登录成功后返回 JWT Token有效期为 2 小时。 6. 接口返回格式为 { code, message, data }。 请先列出接口实现需要的技术栈和文件结构再逐文件生成代码。你看一旦把需求讲清楚AI 的输出质量就会有明显提升。原因很简单它不需要猜你的意图了。这个章节省略地讲是想强调一个观点提示词工程不是“会聊天”而是把自己对需求的理解翻译成机器能执行的约束条件。Uncle Bob 谈软件工程基础时强调“精确的需求”今天你写提示词时要求“精确的上下文”——这是同一件事。4. 设计层AI 默认生成“能跑的代码”不生成“能演进的代码”需求层解决“做对的事”设计层解决“把事做对且能长期改”。用 AI 编程一段时间后你会发现一个规律AI 生成的代码短篇看非常漂亮长篇看逐渐混乱。原因是语言模型的训练目标是“生成看起来像人类会写的代码”而不是“生成长期可维护的代码”。它擅长的是单点任务的实现不擅长跨文件的架构一致性。这其实不奇怪。因为架构决策高度依赖上下文这个模块以后会不会拆出去这个接口是否会被外部系统调用团队是偏向简单直接还是偏向防御式编程这些信息在训练语料里不存在AI 只能在生成时做“最优猜测”。更准确地说AI 生成代码的默认风格是“扁平化”——把逻辑堆在一起函数尽量直接类尽量少。这种代码在小型脚本场景下非常理想但在中大型项目里会迅速变成维护噩梦。我们来看一个具体例子。假设需求是“计算订单折扣”AI 可能输出这样的代码# 文件路径discount.py初次生成的版本代码质量依赖提示词 def calculate_discount(user, order): total sum(item[price] * item[quantity] for item in order[items]) if user[level] vip: if total 1000: return total * 0.8 elif total 500: return total * 0.85 else: return total * 0.9 if user[level] normal: if total 1000: return total * 0.9 else: return total if user[level] staff: if total 100: return total * 0.7 else: return total * 0.75 return total这段代码能跑吗能。一个订单有商品列表、一个用户有等级根据等级和金额计算折扣逻辑简单直接。但它有几个明显的设计问题calculate_discount承担了所有逻辑后续每增加一种用户等级、每调整一次折扣规则都要修改这个函数。折扣规则散落在 if-else 里业务人员无法直观核对。测试很难写你需要构造 user 和 order 的完整字典任何字段漏了都会产生隐蔽错误。最核心的问题这段代码没有表达“业务规则”的边界。用 Clean Code 的标准来看这个函数应该被拆分。折扣规则本身应该独立出来用户可以有自己的类型计算逻辑应该显式地分层# 文件路径discount_refactored.py from abc import ABC, abstractmethod from dataclasses import dataclass from typing import List, Dict dataclass class DiscountRule: user_level: str min_total: float discount_rate: float def matches(self, user_level: str, total: float) - bool: return self.user_level user_level and total self.min_total class DiscountPolicy(ABC): abstractmethod def get_rate(self, user_level: str, total: float) - float: pass class SimpleDiscountPolicy(DiscountPolicy): def __init__(self, rules: List[DiscountRule], default_rate: float 1.0): self._rules rules self._default_rate default_rate def get_rate(self, user_level: str, total: float) - float: for rule in self._rules: if rule.matches(user_level, total): return rule.discount_rate return self._default_rate def calculate_discount(policy: DiscountPolicy, user_level: str, items: List[Dict]) - float: total sum(item[price] * item[quantity] for item in items) rate policy.get_rate(user_level, total) return round(total * rate, 2)重构后的代码更长了但它带来了两个关键能力业务规则可配置新增折扣档位时只需要新增 DiscountRule不需要修改计算逻辑。可测试性大幅提升可以只测 SimpleDiscountPolicy 的匹配逻辑不需要每次构造完整的订单数据。在 AI 编程场景下这个设计的价值更加突出。你可以把重构后的代码作为一个“模板”喂给 AI告诉它“后续的折扣功能都按照这个结构实现。”这样AI 生成的代码就会延续你既定的设计风格而不是每次都重新发明轮子。所以给读者的建议是不要直接接受 AI 的第一版输出要对结果做设计审查。重点看类的职责是否单一、依赖方向是否正确、后续扩展时会不会大改。这个审查习惯就是软件工程基础里的设计能力。5. 验证层测试是 AI 生成代码的“安全护栏”如果说需求层决定了 AI 做什么设计层决定了 AI 怎么做那么验证层决定了“AI 做的东西能不能上线”。Uncle Bob 对测试的强调是一贯的。他推广 TDD测试驱动开发几十年核心逻辑可以用一句话解释**先写测试你才知道“完成”意味着什么。**这句话放到 AI 时代反而更有力量。现在很多开发者用 AI 写代码的流程是这样的让 AI 生成代码 - 能跑 - 提交这个流程忽略了一个致命问题AI 生成的代码“能跑”并不等于“行为正确”。它可能漏掉了边界条件、没有处理异常、用的是已经过期的 API。如果没有测试“能跑”只是你看到的那几个案例能跑不代表所有输入都正确。而 TDD 的流程是这样的先写一个失败的测试 - AI 生成实现 - 测试通过 - 重构这个流程把“什么是对的”从人脑中的一个模糊想法变成了一段可执行的代码。AI 的任务变成了“让测试通过”而不是“猜你要什么”。两者的体验完全不同。我们用一个最小示例来演示。假设需求是“实现一个函数输入商品价格和折扣率返回折后价格保留两位小数”。第一步先写测试此时你应该把这个测试文件提供给 AI 作为上下文# 文件路径test_price.py import pytest from price import apply_discount def test_apply_discount_for_normal_rate(): assert apply_discount(100, 0.8) 80.0 def test_apply_discount_rounds_to_two_decimals(): assert apply_discount(99.9, 0.83) 82.92 def test_apply_discount_zero_rate(): assert apply_discount(100, 0) 0 def test_apply_discount_full_price(): assert apply_discount(100, 1) 100 def test_apply_discount_invalid_rate(): with pytest.raises(ValueError): apply_discount(100, 1.5)第二步把这个测试文件交给 AI让它实现apply_discount。AI 会看到这些测试生成一个能满足约束的实现# 文件路径price.py def apply_discount(price: float, rate: float) - float: if not 0 rate 1: raise ValueError(rate must be between 0 and 1) return round(price * rate, 2)第三步运行测试pytest test_price.py -v预期输出test_apply_discount_for_normal_rate PASSED test_apply_discount_rounds_to_two_decimals PASSED test_apply_discount_zero_rate PASSED test_apply_discount_full_price PASSED test_apply_discount_invalid_rate PASSED这个例子很简单但背后的原则很重要**AI 的实现必须通过测试才能被接受而测试是由你定义的。**这样验证标准在“写代码”之前就已经确定了而不是事后补的。实际项目中测试的粒度会比这个复杂。但核心思路不变把关键业务规则先写成测试。让 AI 负责实现用测试卡住正确性。如果 AI 生成的实现无法让测试通过大概率是需求理解有偏差需要回头改测试或补充上下文。没有测试AI 是“替你做决定”有测试AI 才是“帮你执行决策”。这个差别决定了你是项目的 owner还是 AI 的跟随者。6. 纪律层AI 时代最缺的不是编码能力是“不提交坏代码”的底线最后一层是纪律。这一层最难写也最容易被忽略因为它不涉及具体技术而是团队和个人的行为规范。Uncle Bob 的职业观里有一个很核心的词professionalism专业主义。他多次说过医生不会因为“今天状态不好”而做一台糟糕的手术程序员也不应该因为“AI 生成太快”而降低提交标准。但现实是AI 编程普及后很多团队的质量底线在悄悄下移。过去代码是逐行敲出来的写的时候至少过了一遍脑子现在代码是一次性生成的很多人连看都没看完就提交了。表面上看个人产出提升了两三倍实际上Reviewer 的压力、线上故障的风险、重构的成本都在增加。为什么会出现这种状况因为 AI 改变的不只是写代码的速度还改变了人的心理预期。当生成代码变得极其容易时你会下意识地认为“反正可以重新生成”从而降低对每一行代码的认真程度。这是一种认知偏差比技术问题更难克服。从工程角度看应对方案不是禁止使用 AI而是建立更强的质量护栏。这里有几个具体可执行的纪律第一AI 生成的代码必须通过本地测试才能提交。这不是口号而是可执行的命令。你的 CI 流程要保证任何人提交代码之前pytest或对应测试框架必须全绿。如果团队还没有自动化测试那么第一条纪律实际上是“把自动化测试搭起来”——这是 AI 编程落地的前提而不是可选优化。第二AI 生成的代码必须经过 Code Review。这里有一个常见误解以为 Code Review 是为了检查语法错误。实际上在 AI 编程时代语法错误已经不是主要风险主要风险是“看起来正确但行为和预期不一致”。Reviewer 要看的是这个实现是否偏离了需求是否引入不必要的复杂度是否破坏了既有架构第三AI 生成的代码不能直接进入主分支。建议做法是AI 生成的代码先放在特性分支配合测试和 Review确认无误后再合并。你可以在最简流程中这样操作git checkout -b feature/ai-generated-coupon # 在这里让 AI 生成代码、运行测试、人工审查 pytest -v git add . git commit -m feat: AI 生成优惠券模块已补充单元测试 git push origin feature/ai-generated-coupon # 发起 Pull Request请同事 Review第四团队必须约定“AI 使用边界”。哪些场景允许 AI 直接生成哪些场景必须人工手写比如业务核心算法、支付相关逻辑、数据迁移脚本这些高风险场景应该要求人工逐行编写AI 最多做辅助建议。这个边界不是限制 AI 的使用而是为了防止风险不可控。第四点看起来偏管理但它恰恰是软件工程基础里“纪律”的体现。一个团队如果没有共同的工程底线AI 引入后代码风格、模块边界、测试覆盖会迅速失控。这种失控比“某个人的代码写得差”严重得多因为它是系统性的质量塌方。7. AI TDD 最小实践流程前几章讲了四个层次这一章把理论落成一套可以直接执行的流程。如果你想在下一个项目里立刻用起来可以按这个顺序操作。7.1 准备环境安装 Python 3.9确保pytest可用。准备一个支持 AI 编程的 IDE 或命令行工具当前常见选择包括 Cursor、Continue 等具体以你团队实际使用为准。安装测试框架pip install pytest7.2 定义需求不要上来就让 AI 写代码先写出至少三个测试用例。这一步等价于传统开发中的需求分析。示例需求实现一个函数parse_order接收一行订单 CSV 文本返回订单对象。约束如下文本格式为order_id,user_id,amount。order_id必须是正整数。user_id必须是正整数。amount必须是两位小数。解析失败时抛出ValueError并给出明确错误信息。7.3 先写失败测试# 文件路径test_order_parser.py import pytest from order_parser import parse_order def test_parse_valid_order(): order parse_order(1001,2024,99.90) assert order[order_id] 1001 assert order[user_id] 2024 assert order[amount] 99.90 def test_parse_invalid_order_id_raises(): with pytest.raises(ValueError, matchorder_id must be positive integer): parse_order(abc,2024,99.90) def test_parse_missing_fields_raises(): with pytest.raises(ValueError, matchmust contain exactly three fields): parse_order(1001,2024) def test_parse_negative_amount_raises(): with pytest.raises(ValueError, matchamount must be non-negative): parse_order(1001,2024,-5.00)7.4 让 AI 生成实现把测试文件作为上下文提供给 AI提示词可以这样写我写好了测试文件 test_order_parser.py请根据这些测试实现 order_parser.py。 要求 1. 所有测试必须通过。 2. 不要修改测试文件。 3. 如果测试未覆盖的行为有歧义不要自行假设先列出问题。AI 可能生成这样的实现# 文件路径order_parser.py def parse_order(line: str) - dict: fields line.strip().split(,) if len(fields) ! 3: raise ValueError(line must contain exactly three fields) order_id_str, user_id_str, amount_str fields if not order_id_str.isdigit() or int(order_id_str) 0: raise ValueError(order_id must be positive integer) if not user_id_str.isdigit() or int(user_id_str) 0: raise ValueError(user_id must be positive integer) try: amount round(float(amount_str), 2) except ValueError: raise ValueError(amount must be a number) if amount 0: raise ValueError(amount must be non-negative) return { order_id: int(order_id_str), user_id: int(user_id_str), amount: amount, }7.5 运行测试验证pytest test_order_parser.py -v如果测试全绿说明 AI 的实现达到了你定义的验收标准。如果测试失败先看失败信息判断是需求描述不清晰还是 AI 理解偏差然后修正提示词或补充测试用例。7.6 人工 Review 与重构测试通过不等于设计合理。检查 AI 生成的实现看是否存在重复逻辑、命名不清晰、边界处理缺失等问题。需要重构时遵循同样的流程先改测试再让 AI 或人工调整实现最后跑测试确认。这套流程的核心价值在于AI 的产出被清晰的验收标准约束你的工程判断力不需要在“AI 生成的几百行代码”上逐行消耗。8. 常见问题与排查方法在实际使用 AI 编程的过程中下面这些问题很容易遇到这里给出排查清单。问题现象可能原因排查方式解决方案AI 生成代码运行时报错依赖版本不匹配或 API 已废弃查看报错堆栈检查实际安装的依赖版本将项目依赖版本写入 requirements.txt要求 AI 严格按版本使用 API测试通过但逻辑不符合业务预期测试用例覆盖不足人工审查测试覆盖范围检查边界条件补充边界测试把业务规则写成更精确的 Given-When-Then 验收标准AI 生成的代码风格与项目不一致提示词缺少代码风格约束检查 AI 输出与项目现有代码差异在提示词中加入“遵循项目现有代码风格”或提供示例文件作为 few-shot 上下文代码能跑但后续扩展困难AI 默认生成扁平化代码人工审查类职责、模块边界对核心模块先给出接口设计再让 AI 填充实现团队不同人用 AI 产出差异巨大缺少统一的 AI 使用规范对比不同成员的工作结果制定团队级 AI 使用指南统一提示词模板和验收流程AI 在理解需求时“自信地脑补”提示词中的约束不足检查 AI 输出中是否有你没有提到的假设在提示词中明确列出“不要做的事”和“不确定时必须提问”9. 最佳实践与工程建议把前面所有内容压缩成几条可执行建议适合贴在团队 Wiki 里作为 AI 编程规范。需求先于代码。无论 AI 多强一个没有写好验收标准的功能生成结果只能是“概率上正确”。建议团队为每个功能准备 3 到 5 条核心验收标准再开始写代码。这不只是 AI 时代的要求但 AI 时代让这个要求变得比过去更关键。测试先行。没有测试保护的 AI 生成代码等于没有安全气囊的高速驾驶。建议至少做到关键函数全部有单元测试模块边界有集成测试主流程有端到端测试。测试数量不追求多但必须覆盖核心业务分支。让 AI 重复你的架构习惯。如果你的项目有清晰的分层架构不要每次让 AI 自己发挥。把项目的目录结构、核心基类、异常处理约定整理成文档放进 AI 的上下文。这样 AI 的输出会更贴近你的架构而不是每次生成一个“野路子”实现。Code Review 的重点要转移。AI 能生成通过测试的代码但测试无法覆盖“这个模块以后会不会变成大泥球”。Review 时重点关注职责是否单一、依赖是否合理、扩展时改动面大不大、命名是否破坏领域语言。把语法检查交给工具把架构判断留给人。保留人工控制权。AI 可以提建议、写初稿、写测试、做重构但“是否接受”的决定权必须留在开发者手里。不要因为在 IDE 里看起来合理就直接回车自己不理解的代码不要提交到主分支。构建团队知识库。建议把团队的质量标准沉淀为可复用的提示词片段。例如“所有金额计算必须使用 Decimal”“所有对外接口必须记录请求日志”“所有文件操作必须显式关闭资源”。这些规定不需要每次口述直接作为 AI 的 system prompt 或项目文档上下文。10. 总结与后续学习方向Uncle Bob 谈 AI 时代软件工程基础本质上不是在否定 AI而是在提醒我们工具可以升级工程原则不会过时。这篇文章的核心内容可以概括为四句话需求层提示词工程就是需求工程先写清楚“要什么”和“怎么验证”再让 AI 动手。设计层AI 默认生成“能跑的代码”不默认生成“能长期演进的代码”需要你用设计能力兜底。验证层测试不是可选项而是 AI 生成代码唯一可信的安全护栏。纪律层团队质量底线不能被生成速度冲垮Code Review 和自动测试比以往更关键。如果你想在 Uncle Bob 的方向上继续深入建议按这个顺序学习先把 TDD 用在一个真实的小功能上感受“先写测试再写实现”和“先写实现再补测试”的差异。读一遍《代码整洁之道》重点关注命名、函数长度、注释和错误处理。学习如何积累“项目上下文提示词”把团队的编码规范、架构约定和技术选型整理成 AI 可读取的文档。在团队里尝试一个小范围的“AI 编程规范试点”用一两周的 Code Review 数据来判断质量是否稳定。软件开发三十年来一直在变但一些最基本的东西始终没变代码是给人读的测试是让人安心的架构是让变化可控的。AI 让写代码的门槛变低了反而让这些“基础”的价值变高了。真正值得担心的不是 AI 会不会取代程序员而是程序员在 AI 的协助下能不能守住软件工程的底线。