引言：当炒作遇上现实
"如果你听信那些关于AI和AI编程的炒作，明年此时，我们中一半人可能都不在了。"这是一个令人不安的预言，但来自Augment Code的Chris Kelly认为，那些做出这种预测的聪明人可能错了——不是因为AI编程不重要，而是因为他们很可能很久没碰过实际生产系统了。
作为一名在软件工程领域工作了20年的资深从业者，Kelly对AI编程的未来有着与众不同的看法。他的观点既不盲目乐观，也不过度悲观，而是基于对生产级系统深刻理解的冷静判断。
一、被误解的"代码生成"
代码不是工作本身
许多人将"生成代码"等同于"软件工程"，这是一个根本性的误解。正如Kelly所说："代码本身并非工作，正如蓝图并非建筑师的工作本身，而只是其产物。"
当AI能够生成30%的代码时，这听起来令人印象深刻。但问题在于：AI生成的代码终究还是代码。在Meta这样的大公司，工程师可能花六个月时间在广告平台上做一个按钮。这不是因为写按钮的代码需要六个月，而是因为在一个拥有数百万行代码的系统中，每一个决策都需要考虑无数的架构、基础设施和兼容性问题。
决策空间的复杂性
真正的软件工程工作是什么？是每天做出成千上万个关于软件功能和形态的决策：
使用什么技术栈？
引入哪些包？
如何设计架构？
单体还是微服务？
如何处理分布式系统的一致性？
这些决策在庞大的代码库中，可变空间其实很小——大部分决策已经被现有架构限定了。但恰恰是这些细微的决策空间，需要深厚的专业知识和经验。
"最好的代码是没有代码"
Stack Overflow的创始人Jeff Atwood曾说过："最好的代码就是没有代码。"这句话道出了软件工程的真谛：每行代码都是维护负担。
因此，当我们花那么多时间讨论AI能生成多少代码时，实际上走偏了方向。生成的代码越多，维护负担就越重。真正的问题应该是：AI能帮助我们做出更好的决策，写出更少但更好的代码吗？
二、生产环境的残酷现实
复杂系统的涌现行为
Kelly强调了一个关键概念：涌现行为（emergent behavior）。这是指复杂系统中无法通过单行代码或单个组件预测的行为。
即使写出优秀的代码，在复杂系统中仍会出错。当系统崩溃时，当凌晨两点传呼机响起时，"感觉编程"（vibe programming）是解决不了问题的。你需要：
深入理解系统架构
快速定位问题根源
评估修复方案的影响范围
在压力下做出正确决策
这些能力，是AI目前无法替代的。
生产级代码的标准
什么是生产级代码？Kelly给出了明确的定义：
四个九的可靠性（99.99%的正常运行时间）
数千用户的实际使用
GB级数据的处理能力
运行互联网的关键软件
这不是写几个Demo或个人项目能比拟的。生产级系统需要考虑：
性能优化
安全性
可扩展性
容错机制
监控和日志
部署策略
回滚方案
每一个环节都需要专业判断，而不仅仅是"生成代码"。
软件工程的本质：安全地修改软件
Kelly用20年的经验总结出软件工程的核心："软件工程对我而言就是安全地修改软件。"
这意味着：
如何在不破坏现有功能的前提下添加新功能
如何修改代码而不引入新的bug
如何确保数据安全
如何让用户获得他们想要的功能
为此，行业发展出了一整套工具和方法：
版本控制：追踪每一次改动
测试系统：验证改动是否引发问题
类型系统：在编译时捕获错误
部署策略：灰度发布、蓝绿部署等
代码审查：多人检查确保质量
这些都是AI需要学习和适应的，而不是简单地生成代码就能解决的。
三、历史的启示：这不是第一次
DevOps革命的前车之鉴
Kelly回忆起15年前DevOps兴起时的情景。当时，许多人也预言系统管理员的职业生涯将走到尽头。结果呢？
那些负责机架服务器和启动内核的系统管理员确实不再做这些工作了，但他们：
加了薪
转而从事更有价值的事情
对现在的工作更满意
他们没有失业，而是升级了。他们从繁琐的手工操作中解放出来，转而关注更高层次的架构设计、自动化策略和系统优化。
拖拉机没有消灭农业
Kelly用了一个绝妙的类比：拖拉机。
拖拉机取代了农工和马匹，但它消灭农业了吗？没有。它改变了农业的运作方式，提高了效率，但我们仍然需要农民，仍然需要耕作。
同样，AI会改变软件工程的工作方式，但不会消灭这个职业。我们仍然需要：
理解需求
设计架构
做出决策
审查代码
维护系统
解决问题
只是我们会在更高的抽象层次上工作。
四、"Vibe编程"的局限性
什么是Vibe编程？
Kelly提出了一个有趣的概念："vibe编程"（氛围编程）。这是指：
让AI编写所有代码
不检查代码细节
只看它是否满足需求
如果能运行就继续用
这种方式对于快速原型、个人项目或学习可能有效，但对于生产级系统来说，这是灾难性的。
为什么感觉不够用？
生产级代码涉及太多细节：
性能特征：这个包在高并发下表现如何？
安全问题：这段代码有没有SQL注入风险？
兼容性：这个改动会不会影响其他模块？
可维护性：六个月后其他人能看懂这段代码吗？
这些问题，单纯靠"感觉"是无法回答的。你需要深入理解代码，需要专业知识，需要经验积累。
代码中的细微之处
Kelly强调："代码中的细微之处"往往决定了系统的成败。
一个小小的内存泄漏，在开发环境可能几天都不会显现，但在生产环境可能导致系统每小时崩溃一次。一个不当的数据库查询，在测试数据下可能毫秒级响应，但在真实数据下可能需要几分钟。
这些细节，需要有经验的工程师去识别、去优化、去修复。
五、软件工程师为何抗拒AI？
一个反常的现象
Kelly注意到一个有趣的现象：软件工程师通常是新技术的早期采用者，但对AI编程工具却异常保守。
回顾历史：
版本控制系统（Git）：开发者迅速拥抱
云计算：开发者积极迁移
容器技术（Docker）：开发者热情采用
但面对AI编程工具，许多专业工程师却说："我绝不碰AI。"
为什么会这样？
Kelly承认他不完全理解原因，但有一些猜想：
质量担忧：AI生成的代码质量不稳定
控制感丧失：不清楚代码是如何生成的
责任问题：出了问题谁来负责？
专业自豪感：写代码是技艺，不愿被"替代"
实际体验不佳：早期工具确实不够好
但Kelly认为，这种抗拒正在改变，因为AI编程工具正在快速进化。
AI编程的演进轨迹
几年前：零散的砖块，勉强能用但实际作用不大
一年前（Sonnet 3.5发布）：质量大幅提升，真正的爆发点
四周前：智能体（Agent）成为主流，几乎所有AI编程工具都在谈论智能体
这种快速演进意味着，过去的经验可能已经过时。现在是重新评估AI编程工具的时候了。
六、如何构建AI友好的软件系统
如果我们接受AI将成为软件开发的一部分，那么问题就变成：如何构建易于AI编写的软件？
Kelly给出了几个关键建议：
1. 制定明确的标准和规范
AI需要清晰的指引：
技术栈选择：用React还是Vue？用PostgreSQL还是MongoDB？
包管理：遇到某个需求应该用哪个库？
代码库方向：整体架构是什么样的？
把这些决策明确记录下来，让AI知道该选哪个方向。否则，AI可能会在每次生成代码时做出不同的选择，导致代码库混乱。
2. 环境要可复现
开发者能否快速搭建开发环境？如果你的环境高度定制且独特，AI也会遇到同样的困难。
确保：
快速本地搭建：新人（或AI）能在30分钟内运行起来
避免过度定制：尽量使用标准工具和配置
文档完善：每一步都有清晰的说明
3. 测试要简便
能否本地快速运行测试？如果测试需要复杂的设置或很长的运行时间，AI就无法有效验证它生成的代码。
理想情况：
单元测试秒级运行
集成测试分钟级运行
清晰的测试覆盖率指标
4. 明确边界和任务
Kelly强调："你永远不会让AI明白'用绞杀者模式提取这个模块'这到底意味着什么。"
因此，你必须：
明确界定目标：具体要实现什么功能
清晰的任务描述：像给团队成员分配任务一样
避免模糊指令：不要说"让这个按钮有点不同"
AI的表现取决于任务是否明确。模糊的任务会得到模糊的结果。
5. 给AI同样的工具
Kelly提出了一个重要观点：AI需要和人类工程师一样的工具。
因为AI在做同样的工作——写代码。而我们从来不会一次就写对代码：
代码会有语法错误
需要Linter检查
需要测试验证
需要调试修复
为什么我们期望AI能一次写出完美的代码？这是不现实的。
给AI提供：
Linter和格式化工具
测试框架
调试工具
反馈循环
让它像人类工程师一样迭代改进。
七、代码审查：被遗忘的关键技能
行业可能已经忘记了这项技能
Kelly认为，整个行业可能已经忘记了代码审查这项关键技能。
现在的技术面试侧重什么？
算法题
数据结构
系统设计（有时）
但很少有公司在面试中测试：你能否读懂别人的代码并指出其优劣？
为什么代码审查将变得更重要？
随着AI生成越来越多的代码，审查代码的能力将变得至关重要：
AI生成的代码需要审查：确保质量和安全性
理解代码的能力：不仅是自己写的，也包括AI写的
识别问题的能力：性能问题、安全漏洞、设计缺陷
Kelly预测："随着智能体编写代码越来越多，审查其优劣将变得愈发重要。"
现有工具的不足
当前的代码审查工具有很大的改进空间：
按字典序排列文件：这不是人类思考的方式
缺乏上下文：难以理解改动的整体影响
缺乏智能辅助：不能自动识别潜在问题
Kelly认为，这个领域即将迎来"爆炸式增长"，代码审查工具和方法将大幅改进。
面试应该测试什么？
Kelly建议，未来的技术面试应该：
侧重代码审查能力
测试理解他人代码的能力
评估识别问题的能力
而不仅仅是解决算法题
因为在AI时代，读懂和评估代码比从零开始写代码更重要。
八、实用技巧：如何与AI协作
Kelly给出了一些实用的建议，帮助软件工程师更好地与AI协作：
1. 理解AI的本质：它只是在生成文本
Kelly分享了一个有趣的经历：有一次他对AI大喊（因为AI不听使唤时你就会这么做），AI回应说："抱歉，我刚扫了下那文件，我没看内容。"
这让Kelly困惑：软件怎么"扫描"文件？它只是"浏览"？
答案是：AI并没有真正执行这些动作。它只是在生成看起来合理的文本。因为它在训练时读过成千上万封邮件，里面常说"抱歉，我没仔细读你的文件，只是粗略看了下"，所以它学会了在适当的时候说这句话。
关键启示：对AI声称在做的事保持几分怀疑。它实际上并未执行，只是在生成文本。
2. 接受代码差异：不同不等于更差
AI生成的代码和你写的不同？没关系。
坐你旁边的人写代码的方式也和你不太一样。这很正常。
关键问题：代码是更好了，还是仅仅不同？
如果只是风格不同但功能正确、性能合理，那就接受它。不要浪费时间强迫AI按你的方式写代码。
解决方案：
使用Linter统一代码风格
建立规则系统
编写风格指南
让工具而不是人来争论代码格式
3. 建立规范文件
Kelly建议每个项目都从一个规范文件开始：
技术栈：我们用什么技术
编码规范：我们遵循什么标准
架构原则：我们的设计理念
把这个文件作为上下文的一部分发送给AI，确保它生成的代码符合你的标准。
4. 建立迭代循环
Kelly推荐的工作流程：
第一步：制定计划
用Markdown文件列出计划
明确要实现什么功能
定义成功标准
第二步：生成代码
让AI基于计划生成代码
提供充分的上下文
第三步：审查和调整
检查生成的代码
运行测试
识别问题
第四步：优化
修改计划或代码
再次生成
不断迭代
关键：不断重复这个循环，你会越来越快地掌握如何提示AI，以高效获得所需代码。
5. 放下执念
Kelly的最后建议可能是最重要的：放下那些执念。
不要坚持：
代码必须符合我的写法
必须用我喜欢的库
必须按我的思路实现
只要：
代码能用
性能合理
易于维护
符合团队标准
就足够了。
"如果你放弃了'代码必须符合我的写法'这一点，只关注写好用的代码，你的效率会高得多。"
九、展望未来：软件工程师的新角色
工作不会消失，但会转变
Kelly的核心信息是乐观的：软件工程师的工作不会消失。
但工作内容会转变：
从写代码到做决策：更多时间花在架构和设计上
从实现到审查：更多时间花在评估和优化上
从细节到全局：在更高的抽象层次上工作
这不是第一次，也不会是最后一次。每一次技术革命都带来这样的转变。
我们仍然需要的能力
在AI时代，软件工程师仍然需要：
深入理解系统：知道代码在生产环境中如何运行
做出正确决策：在无数选项中选择最合适的
审查代码质量：识别问题和潜在风险
解决复杂问题：当系统崩溃时快速定位和修复
理解业务需求：把需求转化为技术方案
持续学习：跟上技术的快速发展
这些能力，AI目前还无法替代。
拥抱变化
Kelly的建议是：拥抱AI，但保持专业判断力。
AI是工具，不是替代品。就像：
计算器没有取代数学家
拼写检查没有取代作家
自动驾驶辅助没有取代司机（至少目前）
AI编程工具也不会取代软件工程师。它会让我们更高效，让我们能专注于更有价值的工作。
结语：明年我们仍会在这里
Kelly在演讲结束时说："明年希望还能在这里见到你，希望明年我们都能在这里。工作不会消失。"
这是一个充满信心的预言。不是盲目乐观，而是基于对软件工程本质的深刻理解。
代码只是产物，决策才是工作。
生成代码很容易，构建可靠系统很难。
AI可以帮助我们，但不能替代我们。
作为软件工程师，我们需要做的是：
理解AI的能力和局限
学会与AI协作
提升代码审查能力
关注更高层次的问题
持续学习和适应
未来属于那些能够有效利用AI工具，同时保持专业判断力的工程师。
编码愉快！我们明年见。
关键要点总结：
AI生成代码≠软件工程，决策和架构才是核心价值
生产级系统的复杂性需要深厚的专业知识
历史总会重演，技术革命带来升级而非消失
"Vibe编程"有局限，生产环境需要专业判断
代码审查将成为关键技能，比写代码更重要
构建AI友好的系统需要良好的工程实践
与AI协作的关键是明确任务、接受差异、持续迭代
软件工程师的未来是在更高抽象层次上工作
AI时代的软件工程师，不是被取代，而是被赋能。关键在于我们如何适应和利用这个变化。
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！
我是 dtsola【IT解决方案架构师 | AI创业者】 ；专注AI创业、商业、技术、心理学、哲学内容分享。
提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问
博客：https://www.dtsola.com
公众号&VX：dtsola
需提供服务，加微信 dtsola，备注：IT咨询，并说明来意。
#AI编程 #VibeCoding #AI产品 #ClaudeCode #独立开发者 #AI创业 #一人公司 #程序员 #软件工程师 #软件工程
