第1800篇：里程碑特辑——1800篇后对AI辅助软件工程的深度思考
第1800篇：里程碑特辑——1800篇后对AI辅助软件工程的深度思考
1800这个数字，打出来的时候有点愣了一下。
每天一篇，大约五年。五年里写了什么，改变了什么，哪些判断是对的，哪些是错的——今天这篇，想坦诚地聊一聊。
不是庆功，是复盘。
从「用AI写代码」到「AI辅助工程」的认知转变
最开始写这个专栏，我的框架是「AI帮你写代码更快」。Copilot补全、ChatGPT生成模板、让AI帮你调试。那时候觉得AI就是个很好的代码加速器。
现在回头看，这个框架太窄了。
这几年，AI在软件工程里的价值，远不止「写代码」这一件事。
AI真正改变的，是软件工程中「思考」的方式。
架构设计不再是一个人或少数几个人的事——可以把设计稿抛给AI，得到一个不带情绪、不怕得罪人的批评者。需求分析不再是读完文档靠记忆翻漏洞——可以系统性地穷举边界情况。技术决策不再是「有经验的人拍板」——可以建立结构化的评估框架，让决策过程可追溯。
但这个变化是有代价的。
它要求工程师具备更强的「提问能力」——不是「写一个排序函数」，而是「在以下约束条件下，为什么方案A比方案B更适合，如果我的假设X是错的，结论会怎么变」。这种提问能力，本质上是思维能力的外化。AI放大了好的思维，也同样放大了坏的思维。
这1800篇里，哪些判断是错的
我不想只说对的，错的更值得说。
错误判断一：「AI会让初级工程师快速升级」
我早期写过好几篇讲「初级工程师用AI能力提升」的文章，现在我觉得这个判断是有问题的。
AI的确能让初级工程师产出更多代码，但代码数量不等于能力提升。我见过很多「AI辅助生成」的代码，初级工程师自己看不懂，出了问题不会调试，线上故障时一脸茫然。
真正的成长需要理解底层——为什么这样设计、这段代码的取舍是什么、出了问题怎么追踪。AI加速了产出，但如果不刻意对抗「绕过思考」的诱惑，可能反而减慢了成长。
后来我改变了建议：对初级工程师，AI更适合作为「讲解老师」，而不是「代码生成器」。「帮我写这段代码」不如「解释这段代码的实现思路，让我自己来写」。
错误判断二：「大模型会快速替代大量工程师」
2023年前后，行业里有一波「工程师要失业」的恐慌，我当时也有一定程度上被这个叙事影响，写了几篇偏「危机感」的文章。
现在看，这个预测的时间尺度严重错误。
不是因为AI不强——AI现在写代码已经相当厉害了。而是因为软件工程远不只是「写代码」。理解业务、处理模糊需求、维护复杂系统、做跨团队协调、承担责任和判断——这些是AI目前做不了的，而且在相当长的时间内都还是人的核心价值。
工程师被替代的，是「机械性任务」——重复的CRUD、标准模板、简单的代码转换。这些任务本来就不是优秀工程师的核心价值所在。
真正的风险不是被AI替代，而是被「会用AI的工程师」替代。 这个判断我现在还是认同的，而且随着时间推移越来越确定。
错误判断三：「Prompt工程是未来的核心技能」
我写过一整个系列讲Prompt优化，现在回头看，这个方向过于短视。
Prompt工程是工具，不是底层能力。随着AI模型越来越强，「写好Prompt」的门槛在不断降低——你不再需要用复杂的技巧让AI理解你的意图，把问题说清楚就够了。
真正的底层能力是：把复杂问题分解的能力、识别问题本质的能力、批判性评估输出的能力。这些能力不会被模型进步所淘汰。
这几年技术方向的关键变化
讲几个我觉得对工程师影响最大的变化：
变化一：「语义理解」进入了开发工具链
以前，代码工具只能做语法层面的分析（格式化、类型检查、lint）。现在有了AI，工具可以做语义层面的分析（这段代码的意图是什么、有没有逻辑漏洞、命名是否准确体现意图）。
这让很多以前只能靠人工Code Review才能发现的问题，变得可以自动化。这一点在未来几年会持续演进。
变化二：「上下文窗口」正在成为架构设计的新变量
早期的AI工具，上下文窗口只有几千token，只能分析单个函数。现在100K+的上下文窗口，可以把整个模块甚至整个小项目塞进去分析。
这从根本上改变了AI辅助分析的能力上限。很多以前需要「把代码切片才能分析」的任务，现在可以直接给整体。
但这也带来新挑战：如何组织上下文信息，让AI的有效分析不被无关信息淹没，是一个新的工程问题。
变化三：AI Agent开始进入软件工程流程
从「问答式AI」到「自主执行多步任务的AI Agent」，这个转变正在发生。AI不仅能给建议，还能在你的指导下直接执行——读文件、写代码、运行测试、提交改动。
这是一个更大的变化。它改变的不只是效率，而是工程师的工作模式——从「我写代码，AI辅助」变成「我定义目标，AI执行，我审查」。
这个模式目前还不成熟——AI执行的可靠性还不够高，「我审查」的工作量并不比「我写代码」少多少。但方向是清晰的。
对「AI工程师」这个职业的理解
写了这么多关于AI辅助工程的文章，我对「AI工程师」这个身份有了一些更深的理解。
AI工程师不是「用AI的工程师」，而是「理解AI能力边界的工程师」。
什么意思？一个会用Copilot的工程师，不是AI工程师；但一个知道「哪些任务AI可靠、哪些任务AI会出错、出错了如何识别和纠正」的工程师，是。
这种「能力边界感」很难通过读文档获得，只能通过大量实践踩坑积累。这也是为什么「会用AI工具」和「是AI工程师」是两件完全不同的事。
具体来说，AI工程师需要的核心判断力包括：
一、知道什么时候不用AI
AI在有确定答案的场景表现好（代码生成、模板、解释），在需要组织特有上下文的场景容易犯错（了解你们团队约定的代码风格、理解5年前某个设计决策的历史背景）。
在项目里，那些「需要深度组织上下文才能做判断」的任务，过度依赖AI会产出看起来正确但实际不符合项目实情的结果。
二、知道如何验证AI的输出
AI会自信地给出错误答案——这是大模型的本质特征。工程师的核心价值之一，就是不把AI的输出当成金标准，而是作为「第一个草稿」，通过自己的判断和验证来决定采纳哪些、丢弃哪些。
批判性思维，是AI时代工程师最不可被替代的能力。
三、知道如何把复杂问题分解成AI能有效处理的子问题
「帮我做这个大项目」不如「帮我分析这个具体的技术问题，前提条件是X，约束是Y，预期输出是Z」。
把大问题分解成小问题、给每个小问题明确边界、整合多个局部答案——这个能力，本质上是工程师经典的问题拆解能力，在AI时代变得更加重要。
对「AI辅助软件工程」的几个预测
既然是里程碑文章，做几个预测，几年后复盘用。
预测一：AI代码质量的可信度阈值还需要3-5年才能真正被信任
目前AI生成的代码，在「看起来对不对」上已经很好了，但在「处理边界情况、并发场景、异常恢复」上还有明显短板。这些是需要深度系统理解才能做好的地方。
我预测在3-5年内，AI生成的核心业务代码还是需要有经验的工程师仔细Review，「无人值守地AI全自动生成并上线」在关键系统里还不会发生。
预测二：「代码理解」比「代码生成」更有价值，这个认知会在3年内成为共识
现在大家讲AI写代码，主要讲生成。但软件工程里，理解一个陌生代码库的时间，往往比写新代码多得多。
AI辅助理解遗留代码、分析依赖关系、追踪业务逻辑——这类「理解」任务的价值，我预测会在未来3年被更广泛认知。
预测三：「AI安全」会成为工程师必备的基础知识
提示注入、训练数据污染、模型越狱——随着AI系统越来越多地进入生产环境，针对AI的攻击面会变得越来越重要。
不懂这些的工程师，就像10年前不懂SQL注入的工程师——会被视为基础安全素养的缺失。
预测四：工程师的「判断力溢价」会越来越高
AI让执行层面的工作越来越自动化，但判断层面的工作还是需要人。「做什么」「为什么做」「这个方向对吗」——这类判断性工作，不会被AI取代，反而因为AI的普及变得更值钱。
有深度判断力的工程师，和只会执行的工程师，薪资差距会越来越大。
这套AI辅助工程实践体系的全局视图
回顾这个系列最近的十篇文章，想在这里做一个完整的体系梳理。
软件工程的生命周期，大概是这样的几个阶段：需求理解 → 架构设计 → 技术选型 → 开发实现 → 质量保证 → 上线运营 → 维护演进。AI在每个阶段都可以切入，但切入的方式和价值密度是不同的。
我的体会是：AI在「发现问题」上的价值，比在「生成方案」上的价值更可靠。
发现问题的AI：架构评审找漏洞、需求分析找歧义、代码审查找反模式、监控诊断找根因——这些场景里，AI是在帮你做「你可能遗漏的检查」，即使AI有误判，你也有能力识别。
生成方案的AI：生成数据库设计、生成API接口、生成重构路线图——这些场景里，AI的输出质量差异很大，需要有经验的工程师大量介入来评估和修正。
这两种使用方式都有价值，但前者的「信任门槛」更低，对团队来说更容易落地。如果你的团队刚开始AI工程化实践，建议从「检查」场景入手，而不是从「生成」场景入手。
AI辅助工程的「危险地带」
值得认真讲一个反直觉的观点：AI辅助越深，某些风险反而越高。
当AI生成了一个看起来很完整、很专业的架构设计或技术方案，工程师会产生一种「已经充分分析过了」的心理错觉。这种错觉有时候比「完全没分析」更危险，因为它让人放松了警惕。
我见过一个案例：团队用AI生成了数据库设计，文档写得非常规范，字段定义、索引建议、分区策略一应俱全。但AI完全没有考虑到这个业务的一个关键特征——某类数据需要做法律合规的物理隔离，不能存在同一个数据库里。这个问题，如果是人工设计，DBA在第一次看需求的时候就会想到。但因为AI的设计「看起来太完整了」，这个问题被遗漏了，直到上线前合规review才发现，改动成本巨大。
教训是：AI生成的技术方案，必须专门过一遍「AI不知道的事情」的checklist——组织特有的规定、行业特有的合规要求、只有老员工才知道的历史包袱。这些信息AI没有，但这些信息往往是最关键的约束。
未来五年的学习建议
如果要给想在AI时代持续成长的工程师一份学习建议，我会这样说：
第一条：先把软件工程基础打牢。
这听起来和「AI转型」没关系，但恰恰相反——AI放大了基础能力的价值。一个数据结构和算法扎实、设计模式熟悉、系统设计有经验的工程师，用AI的时候能清楚地评估AI输出的质量；一个基础薄弱的工程师，只能接受AI给什么就用什么，没有判断力。
第二条：建立真实的AI使用量。
不是看文章、看视频、做教程，而是在真实项目里用AI解决真实问题。只有在真实场景下，你才会遇到「AI给了一个看起来很好的答案，但有个细节不对」的情况，才会学会如何识别和处理这类情况。
第三条：培养「系统思维」而不是「工具思维」。
工具思维是「我学会了怎么用这个工具」，系统思维是「我理解了工具背后的原理，能在工具失效时知道为什么以及怎么绕过」。系统思维需要时间积累，但是持久的竞争力。
第四条：保持写作和表达的习惯。
AI让「写代码」变容易了，但让「说清楚你要什么」变得更重要了。工程师的书面表达能力——写需求分析、写技术方案、写故障复盘——在AI时代会越来越有价值，因为这是人机协作的核心接口。
写给正在转型的工程师
最后，想说几句给正在考虑「AI转型」的工程师。
这几年我见了很多人，有转型成功的，有转型卡壳的，有直接放弃的。成功的人有些共同点：
他们不是在「学AI」，而是在「用AI解决真实问题」。
学了很多课程、读了很多文章、做了很多demo，但没有真实的业务问题作为锚点，这些都是浮沙。能力是在解决真实问题的过程中建立的，不是在课程体系里建立的。
他们能说清楚「AI帮我做了什么、我自己做了什么」。
转型不是「我现在用AI了」，而是「我能区分AI能做和不能做的，我能填补那个gap」。如果面试时说不清楚自己在AI辅助工作中的具体价值，很难让人信服。
他们不焦虑，但也不自满。
焦虑和自满都是信号失真。前者让你跑向错误的方向，后者让你停下来。最好的状态是：清楚地知道自己在哪里，清楚地知道目标在哪里，然后每天做一件能缩短这个距离的事。
有时候，「转型」这个词本身就给人一种「需要来一次彻底改变」的压力感，仿佛现在的自己是错的，需要变成另一个人。但我观察到的大多数成功的「AI转型」，其实是悄悄发生的：某个工程师开始在日常工作里用AI做代码Review，几个月后发现自己识别代码问题的能力提升了；某个架构师开始用AI辅助做技术评审，发现团队评审质量提升了。
不需要大跃进，需要的是持续的、有意识的、反思性的使用。
1800篇，这是个数字，也是个问号。
下一个1800篇，AI会在哪里，软件工程会是什么样，我们会是什么样——说实话，我不知道。但我知道，保持好奇、持续实践、诚实复盘，这几件事不会错。
感谢每一位读者，是你们的反馈和问题让这个专栏一直有值得写的东西。
继续更新。