Uncle Bob 的直播主题是《AI 时代软件工程基础》。看到这个标题时我脑子里立刻弹出一个具体问题AI 生成代码的速度越来越快软件工程的基础是被加强了还是被掏空了这个问题比任何 AI 工具评测都值得先想清楚。我自己从去年开始把 AI 编码工具接入日常开发最明显的感受不是写得快了而是“验收”这件事变得比“写”更重要了。代码生成几秒钟就能完成但判断这段代码是否正确、是否适合当前系统、会不会成为明天的维护负担仍然完全是人的活。过去我们讨论软件工程还有比较清晰的定义需求、设计、编码、测试、部署、运维。现在 AI 把“编码”压缩到了一个很短的区间很多人开始怀疑自己还需要不需要会写代码。Uncle Bob 的观点和我的实际体感是一致的编码从来不是软件工程的全貌甚至不是最核心的部分。AI 时代的软件工程基础没有消失而是被推到了更显眼的位置。工具越强人的判断力越稀缺。1. AI 生成代码的速度越快越依赖你识别“坏味道”的基本功有一个容易被忽略的细节AI 生成代码的本质是概率预测不是需求建模。它擅长根据上下文生成“看起来合理”的代码但不会主动验证这段代码是否真的满足业务目标也不会天然保证模块边界清晰、命名统一、异常路径完整。结果就是生成速度越快未经审查的坏味道可能越多。1.1 代码生成做的是“可能性”工程要求的是“确定性”如果给一个明确的函数接口和边界条件AI 工具通常能给出不错的实现。这像什么像一个读过很多源码的同事你描述清楚问题后他很快给你一版代码。但这位同事不会替你确认这版代码和现有系统是不是同一个设计语言不会替你检查两个并发任务会不会踩到同一个资源更不会替你签下“上线后出了问题我负责”的承诺。我自己的常见场景是让 AI 生成一个解析配置文件的中间层。单看函数输入输出都对异常也捕获了。但放到项目里一跑发现它把项目原有的日志规范绕过了错误信息直接 print 到标准输出。代码能跑但风格和系统割裂。这种问题靠 lint 不一定能发现靠测试也未必能覆盖只能靠人读代码时对“这个项目应该用什么方式处理错误”有基本判断。这就是工程基础的作用。它会让你在面对 AI 生成的代码时本能地追问命名是否表意、函数是否过长、依赖方向是否合理、边界输入是否被处理。这些追问不是洁癖而是长期维护成本的前置识别。1.2 为什么工程基础比以往更值钱以前手工写代码你的生产效率受限于打字速度和组织思路的速度写一百行烂代码也需要时间所以即使基础一般带来的瞬时破坏也有限。现在 AI 可以在几秒钟内生成一千行代码如果你不会识别坏味道就等于把一个有潜在结构问题的模块快速铺满整个项目。基础能力在这里变成了“放大器”。你懂 SOLID 原则你会让 AI 先给出接口再补实现你懂依赖注入你会让 AI 生成的模块可以替换你懂重构手法你会知道生成代码之后要做哪几步收紧。反过来如果这些概念只是听过没用过AI 生成速度只会把你推向更大的混乱。所以 Uncle Bob 在不同场合反复强调的那些东西——整洁代码、测试纪律、简单设计——在今天不是过时了而是变成了生存技能。代码生成负责把“从 0 到 1”的火花点燃你的基础负责决定这堆火是烧成火炬还是烧成野火。2. Uncle Bob 说的“软件工程基础”到底指哪些基础聊这个话题之前得先界定一下“软件工程基础”指什么。它不是一个具体的技术栈也不是某种语言特性而是一套能够持续交付高质量软件的纪律和思维习惯。2.1 不只是码代码是对变化的控制能力软件行业最稳定的东西是变化。需求会变依赖会变业务规模会变团队成员会变。软件工程解决的问题从来不是“把当前功能写出来”而是“在变化发生时系统还能不能稳定演进”。如果你的架构全是一团互相纠缠的代码任何新需求都是灾难如果你的测试覆盖了关键路径重构时就敢下手如果你的构建过程是可重复的部署就不会靠玄学。AI 工具出现后不少人误以为“写代码”已经变得廉价所以架构设计也会变廉价。事实恰好相反。AI 能帮你快速生成新模块但新模块和旧系统之间如何衔接、如何避免重复、如何保持边界这些恰恰是架构设计要解决的。生成速度越快系统之间的组合越多混乱的扩散速度也就越快。2.2 从敏捷宣言到 AI 时代底线没有变Uncle Bob 是敏捷开发运动的早期推动者之一。敏捷的核心不是“写一堆用户故事”而是小步迭代、快速反馈、拥抱变化、持续交付可工作的软件。AI 编码工具在“可工作的软件”这一点上确实能帮上忙它可以快速产出原型、生成测试骨架、补完重复代码。但“快速反馈”这件事仍然依赖你有一个能跑的测试环境和清晰的验收标准。如果团队没有测试、没有 CI、没有代码评审AI 生成只会让反馈变得更慢。因为没有人能在合并之前快速验证结果问题会累积到集成阶段才爆发。到那时候你看到的是一大堆不知道谁生成的代码排查成本直线上升。所以我的判断是敏捷的底线没有变变化的是“快速”可以由工具提供而“可工作”和“质量”仍然必须由人来确保。基础不是一项单独的知识而是一套组合拳需求拆解、测试设计、代码组织、重构能力、部署意识。AI 能把其中部分动作做得更快但整条链路的负责者还是你。3. 把 AI 当帮手之前先把三件工程基础补牢很多人问我AI 编程到底应该从哪开始练我给的建议通常不是学提示词技巧而是先把三件最朴素的事补牢输入、输出、维护。3.1 输入质量明确需求和验收标准比打磨提示词更关键提示词写得再花哨如果需求本身是模糊的AI 生成的代码大概率偏向“看起来合理”而不是“真正正确”。常见反面例子是“帮我写一个订单导出功能。”这个提示词里缺少日期范围、字段口径、导出格式、失败重试、权限要求、数据量级。AI 会基于自己的训练知识默认一套答案而这套答案十有八九不能直接落地。更好的做法是先把需求拆成一句句可验收的描述例如输入起始日期、结束日期、导出渠道。输出CSV 文件包含订单号、用户 ID、金额、状态。边界数据量超过 10 万条时分批写入。失败导出失败时记录 error 日志并返回可读提示。然后再把这份描述交给 AI。你会发现提示词写得长不是为了显得专业而是为了把上下文补齐。能把需求拆到这种颗粒度本质上靠的还是需求分析能力。这个能力在 AI 时代不会贬值反而会成为你和工具之间协作质量的分水岭。3.2 输出质量用测试和安全网来收编 AI 代码AI 生成的代码不能直接信。这里说的“信”不是觉得它一定有恶意而是它生成的是“概率上的正确”。你无法从一段代码看起来顺畅就判断它逻辑成立必须有可运行验证。我给自己定的规矩是任何 AI 生成的非一次性代码第一件事不是跑了看看而是先补测试。哪怕只是几条边界用例也要把输入輸出关系钉死。比如生成一个日期格式化函数我会先写测试覆盖空值、跨年、时区、非法字符串。AI 生成的函数可能能通过大部分用例但边界场景往往需要人工一点点补。这一步的真正价值不在于“测出 bug”而在于把 AI 输出的不可控性隔离在一个安全网里。之后无论重构还是扩展你都有信心按删除键。如果连测试都没有AI 生成的代码就只是一个“运行过几次”的黑盒过两周你自己也不敢动。3.3 可维护性如果代码明天要改你还能看懂吗AI 工具很擅长写“一次性解法”但不擅长为你长期演进着想。它不会主动避免重复代码不会在复杂函数旁边写一段说明意图的注释不会把你刚刚约定的目录结构当回事。所以生成之后常常需要人工收紧。我会在合并前做三件小事第一统一命名和格式让代码风格和项目现有风格一致第二拆掉明显过长的函数把太长的代码块拆成有名字的步骤第三删除 AI 生成的注释里那些“废话”只保留解释“为什么”的注释。这三件事都不需要多高深的技术但它们决定了这段代码能不能活过半年。如果你发现 AI 生成的代码需要你大改才能看不要气馁。这个过程本身就是在训练一种可维护性直觉。工具负责起草你负责让代码达到可读、可改、可替换的标准。4. 从“AI 生成的代码”到“能长期维护的系统”四步落地法把 AI 工具接入真正的项目我推荐一个比较保守的四步流程。它不刺激但能帮你避开大部分坑。4.1 第一步用一条最小路径跑通流程不要一开始就让 AI 帮你重构整个模块也不要一上来就并行生成几十个文件。先选一个边界清晰、场景简单的小任务比如“写一个根据订单状态生成中文展示文本的函数”。用它跑通“写提示词 → 生成 → 测试 → 提交”的完整链路。这一步的核心目的不是完成任务而是建立你对工具的信心和审查习惯。你会看到一个正常回应的流程长什么样也会感受到哪里容易出错。等小任务稳定了再逐步扩大范围。4.2 第二步把测试和日志当成安全网在把 AI 输出合入主干之前必须确保关键路径有测试保护。很多 AI 生成的代码有“看起来成功但实际没走到目标分支”的情况。测试能帮你快速确认代码真的做了你让它做的事。日志同样重要。如果你在开发环境里让 AI 生成一个有外部调用的模块至少要在入口和出口记录关键参数。这样以后排查问题时你能分清是输入不对、服务异常、还是 AI 生成的代码逻辑有问题。没有日志你就只能靠猜。4.3 第三步把 AI 输出当成一位“不太可靠的新同事”提交的 PR想象一位新同事提交了一份代码说“我写完了”。你会直接合并吗不会。你会看 diff会检查是否覆盖了异常路径会跑测试会在关键函数处提问。AI 生成的代码也该走这个流程。我给自己定了一个检查表是否满足原始需求边界条件是否处理有没有隐藏的副作用是否引入不必要的外部依赖和现有代码风格是否一致性能上会不会有隐患每次核对这些问题其实都是在调用你的工程基础。所以请不要跳过 PR 审查。AI 生成的代码合并前一定要有人类的确认。4.4 第四步再考虑批量化和 AI Agent前几步稳定之后再考虑让 AI 工具批量处理任务或者接 AI Agent 自动跑一些流程。批量化的前提是你已经验证过单任务的质量并且能接受失败率。AI Agent 可以自动执行“生成 → 测试 → 修改”的循环但你要提前约定好任务范围、可使用的资源限制、失败多少次后停止、是否需要人工审批关键操作。工程经验里最危险的事情是流程自动化之后没人盯输出。我始终建议给 Agent 留一个“人工闸门”生成代码可以自动做但合并到主干这一步必须有人看。这不是不信任工具而是对生产环境的负责。5. AI 编程出问题时先别急着怪工具一套排查顺序AI 编程出现问题时很容易陷入两个极端一是觉得都是自己的错反复改提示词二是觉得都是工具的错换一个工具重来。这两种反应都不太有效。更可靠的方式是沿着一条链路逐层排查。5.1 先看现象别急着改代码问题现象决定了排查方向。是编译报错逻辑结果不对测试失败运行超时还是生成结果不稳定每次都不一样不同现象对应不同层次。编译报错优先看语法、依赖、类型。逻辑结果不对先检查输入输出和边界条件。测试失败先看失败用例是断言问题还是实现问题。运行超时先看数据量和循环逻辑。结果不稳定先看提示词是否上下文不够、模型随机性、是否有依赖外部状态。建议把现象记录下来再动手改。很多时候写清楚现象的那一刻问题原因已经浮出来了。5.2 再看输入和上下文很多 AI 生成代码的问题根源在“给的输入不够清楚”或者在多文件修改场景下AI 没有看到关键上下文。比如它只知道某个函数签名不知道调用方的预期就容易生成一个“看起来对但接口不匹配”的实现。排查时先检查提示词里是否明确了输入输出格式是否提供了项目的目录结构或关键代码片段是否说明了你不需要什么比如不要改动某个方法工具是否有可能没有读取最新文件导致基于旧代码生成还有一类常见问题上下文太长之后AI 可能忽略某些早期指令。遇到这种问题把提示词精简成“最近一次修改目标 当前文件限制”往往比不断追加描述更有效。5.3 再看测试和日志如果输入没问题就要看测试和日志能不能帮助你定位。先判断当前问题有没有被测试覆盖。如果 AI 生成的代码没有测试而你也没有及时补那出了问题只能靠肉眼读代码效率很低。这个阶段我会先补一条最小复现用例。你不需要一开始就写完整测试只要能把错误场景固定住让问题可以稳定复现。然后再跑一遍看失败信息是在哪个断言、哪一行。这样可以把“我感觉有问题”变成“这里有明确的前置条件不满足”。日志的作用是观察运行时的真实状态。如果代码里没有关键路径日志可以临时加几行看输入、输出、中间变量分别是什么。人脑猜变量状态永远是低效的日志能把猜测变成证据。5.4 最后才是工具限制当输入、上下文、测试、日志都检查过问题仍然存在才需要考虑工具本身的边界。例如模型版本不支持某些语法、上下文窗口不够导致遗漏、特定语言支持不佳、某些工具对大型项目理解有限。在这个阶段比较务实的做法是“绕过”而不是“硬杠”。比如让 AI 只生成某个函数体而不是让它理解整个项目或者手动给出必要类型定义或者换一个更专业的补全工具。工具限制通常是已知的网上讨论也不少但不要什么都甩锅给工具。先把前两层排查做完很多“工具问题”其实都是输入问题。6. 适用边界AI 辅助编程适合谁不适合谁任何一个工具都不是万能的。AI 辅助编程在合适的人手里是加速器在不合适的场景里可能是混乱放大器。6.1 适合的人能控制输入、验证输出、愿意重构的工程师如果你已经具备基础的需求拆解能力知道怎么把模糊想法变成可实现的任务而且愿意为 AI 输出补测试、做重构那么 AI 工具能极大提升你的开发效率。你相当于多了一个反应很快的结对伙伴可以在几分钟内看到多种实现方案然后基于自己的工程判断选一条路。对于学习者来说AI 工具也很适合用来快速理解“一段代码大概是怎么组织的”。但前提是你不能只抄答案。你可以让 AI 生成代码然后自己把每行解释一遍再用学到的语法和模式重新实现一次。这个过程里AI 是老师你是学生而不是反过来的关系。6.2 不适合的场景模糊需求、无测试、高风险业务、团队无纪律需求本身模糊不清时AI 帮不了你反而会给出一个看似精致的错误方案。如果项目没有测试基础设施AI 生成的代码就像在没有护栏的高空作业。如果业务是支付、医疗、安全等方面的核心链路人工审查和完整测试更是不能省。还有一个常见现象团队本身没有代码评审和规范约定大家各自用 AI 生成代码然后直接合并。这种模式下代码风格会迅速走向分裂重复逻辑变多依赖关系混乱。AI 不会自动维护一致性一致性需要团队通过约定、评审和工具链来保证。如果团队没有这个纪律使用 AI 之前得先把纪律补起来。6.3 长期投入建议把 AI 工具作为“结对伙伴”而不是“代写员”工具会不断更新今天有效的提示词技巧三个月后可能因为模型升级而失效。所以我建议把注意力放在那些不变的东西上你如何描述问题、如何验证代码、如何拆分任务、如何审查结果。长期来看比较有效的做法是建立自己的“AI 协作沉淀库”。把好用的提示词模板沉淀下来把每次踩坑后的检查表放进团队文档把常用的代码片段整理成可以复用的单元。这样做之后AI 工具对你的价值会越来越稳定而不是每次换来换去一切重来。7. 回到 Uncle Bob 的那句话基础不是限制而是自由这场直播真正给我的冲击不是某个新工具、新提示词技巧而是那个被反复带回的旧命题软件工程的基础到底值不值得花时间在 AI 生成代码已经快到“疯狂”的今天这个命题比任何时候都更值得正面回答。基础从来不是为了给人设限。知道自己要什么知道怎么验证结果知道如何处理变化这些能力不会让你 “不会用 AI”只会让你在 AI 给出的无数种方向里仍然能做出有根据的选择。反过来没有基础的人面对 AI 生成代码就像站在分岔路口没有地图每条路都看起来很平坦每条路都有可能通向坑底。我会继续把时间花在整洁代码、测试设计、需求拆解和架构判断这些“老东西”上。不是因为它们时髦而是因为它们决定了 AI 生成的东西是资产还是负债。Uncle Bob 说的“基础”说到底就是一个人对代码负责的底气。AI 可以替你把代码写出来但“负责”这件事扔不掉。