腾讯云粤港澳大湾区架构师峰会游记

2026 年 8 月 15 日 · 腾讯云粤港澳大湾区架构师峰会

这次峰会讨论了 AI 编程、软件架构、工程师转型、业务实践和个人知识管理。分享者来自不同年龄和职业阶段，但他们关注的是同一个问题：当 AI 承担越来越多执行工作时，工程师应该重点培养哪些能力？

我的主要结论是：AI 会降低编码和标准化执行的成本，工程师的工作重点将向需求、架构、业务、判断和复盘迁移。

AI 正在改变软件交付流程

传统软件交付包括需求分析、方案设计、编码、测试、上线和运维。AI 已经可以参与其中的大部分环节，例如：

生成和修改代码；
补充测试；
分析日志；
定位可能的故障原因；
提供性能优化建议。

需求越明确，AI 完成这些工作的效果越好。随着模型能力提升，编码和其他标准化执行工作的占比会继续下降。

但软件交付不等于生成代码。前期仍然需要理解用户目标，把模糊诉求抽象成清晰需求，并识别范围、约束和风险。系统上线后，也需要结合业务上下文判断故障原因、选择优化方案并验证结果。

AI 可以辅助这些工作，但人仍需提供组织内部的信息，并对最终决策负责。因此，软件工程的价值会逐渐集中在交付流程的两端：

交付前：理解场景、定义问题、设计方案；
交付后：验收结果、排查偏差、优化系统、复盘经验。

这要求工程师继续学习计算机基础、软件工程和系统设计。学习目标也会发生变化。过去学习这些知识，主要是为了亲自实现系统；现在还需要用它们判断 AI 生成的方案是否正确、可靠和可维护。

技术品味来自长期比较和实践

峰会上多次提到“品味”。在工程领域，品味可以理解为识别方案质量并作出合理取舍的能力。

阅读经典书籍可以建立基础框架，但阅读不是唯一来源。技术品味还来自：

阅读优秀源码和设计文档；
比较不同方案的成本和适用范围；
参与真实项目；
处理线上故障；
回顾设计在长期运行后的结果。

AI 降低了生成方案的成本，也增加了备选方案的数量。工程师需要更快地识别哪些方案适合当前系统。基础知识和实践经验因此变得更重要，而不是更不重要。

全栈工程师的能力范围正在扩大

未来的全栈工程师不只是同时掌握前端和后端。一个人可能需要完成从业务理解、产品设计、系统实现到模型接入和上线运营的完整闭环。

这种全栈能力包括：

理解产品目标和业务流程；
完成前端、后端、数据和部署工作；
选择适合任务的模型；
管理上下文、知识库和工具调用；
建立模型评测；
平衡准确率、延迟、成本和系统可靠性。

工程师需要补充人工智能知识，但不必默认从训练或微调模型开始。对多数应用开发者，更实用的学习顺序是：

理解模型的基本原理、能力和限制；
学习上下文工程、结构化输出和工具调用；
学习检索增强生成（RAG）和 Agent 工作流；
建立评测、监控和成本控制；
在通用方案无法满足稳定业务需求时，再评估模型微调。

目标不是增加一个“懂 AI”的标签，而是把概率性的模型能力转化为可测试、可观测和可维护的系统能力。

AI 的效果取决于业务场景

一位分享者用“蒸馏不掉的时间和场景”总结自己的产品经历。模型可以学习公开的代码、文章和成功案例，但这些材料通常只保留最终结果，不包含产品形成过程中的全部信息。

真实项目还包括用户反馈、组织约束、资源限制、失败记录和阶段性决策。离开这些信息，同一种技术在不同业务中可能产生完全不同的结果。

评估 AI 项目时，需要回答以下问题：

用户是否需要这项能力？
新方案是否改善了原有流程？
任务完成率是否达到要求？
成本和响应时间是否可以接受？
出错后如何发现、恢复和追责？

这要求工程师深入了解业务。需求文档只是起点，还需要理解用户为什么提出需求、当前如何工作、主要阻塞点是什么，以及哪些指标可以证明方案有效。

当通用技术方案更容易获得时，业务建模能力会成为新的差异点。工程师需要梳理端到端流程，识别关键对象、状态、规则和边界，再把这些知识转化为系统实现。

编码岗位会变化，工程职责仍然存在

有位分享者认为，传统意义上的程序员可能会消失。这里的“程序员”主要指把业务需求翻译成代码的人。

AI 正在提高这种翻译工作的效率。单纯依赖编码速度、框架熟练度和重复实现经验建立的优势会逐渐缩小。但工程师仍需在约束条件下交付可用系统。

需求是否正确、架构如何取舍、风险是否可以接受、系统能否长期运行，这些问题不会因为代码可以自动生成而消失。工程师需要从代码执行者逐渐转向：

问题定义者；
系统设计者；
业务建模者；
结果负责人。

长期积累的行业经历仍然有价值。AI 更容易接管能够清晰表达和重复执行的工作，而业务理解、风险判断和复杂环境中的交付经验仍需持续积累。

输出和复盘帮助知识内化

峰会关于知识管理的分享提供了一个实用的学习闭环：

输入 → 实践 → 输出 → 反馈 → 复盘 → 方法论

阅读和听课可以获得信息。实践可以检验知识。输出则要求自己重新组织内容，并暴露理解中的空缺。

复盘可以分为两类：

单项目复盘：项目结束后记录目标、结果、关键决策、偏差和改进措施；
周期性复盘：每隔半年或一年比较多个项目，寻找重复出现的问题和共通规律。

单项目复盘保留具体经验。周期性复盘把零散经验转化为可复用的方法。

个人知识库也不应只保存原文和链接。更值得记录的内容包括：

学习后的个人理解；
项目中的关键决策及原因；
故障的原因和处理过程；
有价值的 AI 对话及其结论；
观点随时间变化的过程；
从多个项目中总结的方法。

AI 可以协助整理这些材料，但前提是个人先留下真实、可追溯的记录。

人需要保留最终决策权

圆桌讨论提出了一个问题：哪些事情不应该交给 AI？回答包括对现实世界的观察、人生方向、最终决策、亲密关系和真实生活体验。

这些回答可以归纳为一条原则：AI 可以提供信息和建议，也可以承担执行工作，但人需要保留最终决策权，并对结果负责。

AI 节省下来的时间也不必全部投入更多工作。阅读、线下交流、运动、陪伴家人和探索暂时没有明确用途的兴趣，都在帮助个人形成经验和判断。

我的后续行动

结合讲座内容，我计划从四个方向继续学习和实践。

加强专业基础

继续学习计算机基础、软件工程、架构和系统设计。通过书籍、源码、项目和故障复盘，提高判断方案质量的能力。

补充 AI 工程知识

学习模型基础、上下文工程、RAG、工具调用、Agent 和评测方法。目标是独立完成 AI 应用从需求到上线的完整流程。

深入理解业务

主动了解业务流程、用户目标、关键指标和实际约束。设计方案时，先明确需要改善的问题和验收标准。

建立输出和复盘习惯

学习后记录自己的理解，项目结束后完成复盘，并定期比较多个项目，从经验中提炼可复用的方法。

总结

AI 会继续降低编码和标准化执行的成本。工程师需要把更多精力投入需求理解、方案设计、业务建模、系统验证和经验复盘。

模型可以快速生成已有知识的组合，但个人仍需积累场景经验、建立判断标准并承担决策责任。这些能力决定了 AI 生成的结果能否转化为可靠的业务价值。

本文根据 2026 年 8 月 15 日腾讯云粤港澳大湾区架构师峰会现场讲座及个人参会体会整理。现场录音由飞书妙记自动转写，部分专有名词可能存在识别误差。