陈天的 2025 年度复盘之夜互动访谈
陈天
00:00 / 00:00
1.0x
- 3.0x
- 2.5x
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.75x
- 0.5x
2025 年是智能体普及的关键年，AI 编程工具如 Claude Code 进步显著。作为开发者应该尽快将自己的角色转变为“方案指挥者”，利用 AI 高效学习与探索，强化自己解决问题的能力。
主持人：
欢迎陈天老师来到我们的双十二直播间，这也是我们一年一度的“程序员年度复盘之夜”。接下来，我们将和老师一起聊聊 2025 年的技术里程碑、2026 年的技术趋势，以及老师在 AI 编程方向上的实践与思考。
首先，咱们回顾 2025 年，您认为有哪些值得铭记的 AI 技术里程碑事件？对于 2026 年，您又看好哪些技术趋势呢？
陈天老师：
从技术发展来看，2025 年可以说是 Agent（智能体）大规模介入应用 的一年，尤其是在 Coding Agent（编程智能体） 领域。自从 Claude Sonnet 4.5 发布以来，AI 编程与之前相比已经产生了巨大的变化。而近期 OpenAI 4.5 的推出，则进一步夯实了 AI 自主编程 的基石。
大概半年到一年前，我们对 AI 编程的印象还可能是：它经常出错、会产生幻觉，写出的代码可能需要花费很大功夫才能编译通过，至少对于像 Rust 这样的编译型语言，我过去常有这种感觉。但从 Sonnet 4.5 之后，我就很少再担心它一口气写出几千行代码，却无法一次性编译通过的问题。这一点上 AI 确实取得了长足的进步。
展望未来，我认为编程会越来越从“人类亲自执行具体任务”，转变为“在 Agent 的协助下完成大量工作”。2025 年可能是一个思维范式转变之年：我们要分清什么是“工作”，什么是“任务”。写代码本身只是你工作中的一项“任务”，而“工作”本身则更侧重于如何发现问题、分析问题、设计解决方案，以及最终推动落地。因此，执行只是工作的一部分，而执行层面的很多事，我们会越来越多地交给 AI Agent 去完成。
另一个重大的进展是 Gemini 3.0 的发布，以及由此带来的整个谷歌 AI 生态系统的变迁。我认为这也是一个重要的里程碑。AI 模型的思考能力等各方面都得到了显著提升。Nano Banana Pro 估计在过去的一个月里已经在各大社交媒体刷屏了，现在大家可以把任何知识转换成你想要的漫画形式，或任何新颖的形式输出，这在以前是很难做到的。
在开源领域，年初的 DeepSeek 无疑是开源大模型的一个跨时代发展。它打破了许多关于闭源算法的神话。随着它一步步迭代，以及在这个过程中开源出来的代码和各种论文，尤其是关于 MoE（混合专家模型） 的诸多探索，共同构成了如今开源与闭源大模型百花齐放的局面。所以，现在许多大模型的发展，某种程度上我们都要感谢 DeepSeek 在年初乃至今年发表的多篇重磅论文。
主持人：
那您刚才提到了 Gemini CLI 和 Claude Code，您觉得这两个工具对比起来哪一个更有优势呢？
陈天老师：
在我看来，Gemini CLI 与 Claude Code 相比，从对软件工程师的实际帮助角度来说，前者还远未达到一个真正可用的状态。我深度尝试过 Gemini、Codex 等工具，发现在多轮工具调用和生成内容的细节把控上，它们与 Claude Code 仍有不小差距。
大家可以做一个实验：拿一个较大的代码库，分别让 Gemini、Codex 和 Claude Code 帮你生成整个架构设计文档，包括子系统关系的详细说明，并要求用 Mermaid 图表来绘制架构图。你会发现，Gemini 和 Codex 生成的内容相对简短，虽然能捕捉一些核心要素，但不足以让你了解代码库全貌。而 Claude Code 生成的内容则非常详实，并且在 90% 的情况下，它生成的 Mermaid 图表都是正确的，Gemini 和 Codex 生成的图则可能无法直接预览。所以在工具实用性上，它们还有很长的路要走，不过这个追赶过程应该会很快。
Claude Code 是一个划时代的产品。它把我们从以往需要逐行阅读代码的 IDE 环境中解放出来。之前使用 Cursor 时，它会事无巨细地展示所有代码差异（Diff），而 Claude Code 则把这些细节都隐藏起来，让你更聚焦于思考要解决的问题、制定计划、明确需求和设计。至于具体的代码生成，则由 Claude Code 来替你掌控。
另一个我非常赞同的设计是它秉持 Unix 哲学：可组合性（Composability） 是其第一要素。它的整个生态思路不是内置繁杂功能（如代码索引或各种工具），而是依赖外部环境提供的工具来扩展自身能力。其理念是：只要模型能力和工具调用能力不断提升，并且系统外围有足够多的工具，就能很好地执行任务。这其实也是人类做事的基础逻辑。
我认为未来的 Agent 越接近人类行为模式，成功的可能性就越大。比如我们做软件开发，会使用各种 CLI 工具来验证代码是否正确。开发后端 API 时，我们会用 curl 测试不同输入下的响应。我们会将多个工具组合成完整的工作流。如果一个 Agent 能做类似的事情，它的行为就非常接近人类，产出的成果也会更可靠。 Claude Code 正是在努力让自己更像人，它不断进化“大脑”和使用工具的能力。大约两个月前，它发布了“Skills”功能——我们在不断积累各种技能，这一点也特别接近人类的行为方式。所以在工具层面，目前我认为 Claude Code 还是非常领先的。
另外值得一提的 Coding Agent 是 AWS 的 KRO，我最近才接触这个工具，是受 Re:Invent 2025 会议的启发。KRO 做得比较好的一点是，它将规范驱动开发（Spec-Driven Development） 的思路完整地嵌入到了 IDE 开发流程中。在 Claude Code 中，如果我个人想采用规范驱动的方式，可能需要自我约束行为；而 KRO 则直接帮大家做好了这种约束。它的 IDE 深度集成了这种开发模式的精髓，整个开发状态、组件更新等都体现了这一点。所以它是一个非常值得探索和研究的新开发工具。
主持人：
对于偏向业务驱动和规则复杂的开发场景，如果要构建这样的 Agent 的工作流，整体的设计可以从哪些地方入手呢？
陈天老师：
对于偏向业务驱动、规则复杂的开发场景，要构建相应的 Agent 工作流，可以从以下几个方向入手：
首先，在技术选型上需要明确原则：并不是所有场景都适合使用 Agent。如果规则虽然复杂，但能够被清晰定义，并且可以直接用编程语言实现，那么应该优先使用传统编程方式完成，不要只因为处于 AI 时代就盲目使用 Agent。
Agent 更适合处理那些边界模糊、难以用详细规则描述，或者即便能描述但很难直接用代码实现的场景。从具体设计角度，可以借鉴以下思路：
Agent 的实现依赖于为它提供足够丰富的外部工具。举个例子，我们处理过一个监控重要比赛整体状态的场景，原本我们需要依赖多个 Dashboard 和告警系统，一旦告警触发，再人工介入处理；此外还需要专人实时盯着各种 Dashboard，这是一种典型的人力行为。
那么如何用 Agent 来替代这类工作呢？
工具封装：将相关的 Dashboard 访问及其底层数据接口封装成 CLI 工具。
Skill 构建：利用 Claude Code 的 Skills 机制将这些 CLI 封装成可调用的技能。
Agent 调度：构建一个 Agent，在特定场景下（比如需要同时关注前端、机器学习、后端数据等不同方向的实时状态）调用这些 Skills。
洞察生成：Agent 不仅反馈数据或告警，更能进行汇总与洞察。因为仅仅知道“发生了什么”并不够，关键是从数据中提取有业务价值的洞察力。
报告自动化：例如可以再设计一个 Agent，将所有子系统的信息聚合并生成报告，满足像“每 10 分钟向老板汇报一次系统状态与用户流量概况”这类需求。
总的来说，这类原本依赖人力的、流程固定的任务，可以通过为 Agent 提供相应的工具与数据接入能力，并配合精心设计的 system prompt，来构建自动化的、智能的工作流。这不仅提升了效率，也让监控与汇报更加结构化和具有洞察力。
主持人：
老师在《AI 编程实战营》里说要以宏观的思维去跟 AI 去交互。那我理解是站在一个架构师的角度去看。但是如果说目前个人还达不到优秀的架构师的水平，那怎么样去利用 AI 的快速去成长？同时如果个人现在积累还不够，有时候 AI 给出的方案自己也难以评估，这时候应该怎么处理呢？
陈天老师：
这是一个非常好的问题，它触及了很多开发者正在面临的现实困境。这个问题可以拆解为两个部分：
如何在自身架构能力尚不成熟时，利用 AI 快速成长？
当难以评估 AI 给出的多个方案时，应如何处理？
首先，在个人定位上，我们需要从代码的实现者转变为方案的定义者和工作的指挥者。这对工程师自身的架构与设计能力提出了更高要求。如果感觉这方面能力尚有不足，传统的路径依然是分析他人系统、研读代码库、积累行业新知。这听起来像是老生常谈，但在 AI 时代，我们拥有了全新的利器，能将学习效率提升十倍甚至百倍。
举个例子，假设你在 AWS Re:Invent 2025 大会上看到了一个名为 KRO（Kubernetes Resource Orchestrator）的新概念。要想快速成为这方面的专家，现在有两种高效途径：第一是将大会相关的视频内容导入 Notebook LM，让它帮你生成幻灯片摘要、思维导图，并可以随时向它提问互动；第二是直接使用新版 Gemini 的深度研究（Deep Research）功能，让它帮你深入探索：什么是 KRO？工程师如何应用它？它与 Helm Chart 等现有工具有何区别与联系？它是否代表未来的技术方向？等等这些，AI 都能为你整合信息，生成一份深度全面的解答文档。
同样的，如果你想深入研究架构原则，例如 SOLID 原则在大型软件中的应用，或聚焦于“开闭原则”、“控制反转”等具体点，都可以通过这种方式进行高效学习和探索。AI 能基于最新的业界实践给出回答，并且你可以要求它用中文输出，这大大降低了学习门槛。这就好比瞬间拥有了好几位学识渊博且知识保持前沿的导师，你甚至可以要求 AI 仅基于最近三个月的最新知识来回答问题，确保信息的时效性。
因此，在这个时代，个人独有的某些经验性知识（Know-how）的价值相对而言可能不再像过去那样突出，因为“大模型 + 互联网”足以充当极为权威的导师。当你的架构和设计能力还在成长时，应主动利用 AI 去探索感兴趣的技术话题和代码库。现在，理解一个复杂的开源项目也变得非常容易，例如使用 Claude Code，你可以让它分析任何你感兴趣的代码库，生成系统架构图、数据流图、子系统关系图乃至数据库设计图，从而高效吸收顶尖项目的经验。
接下来是第二个问题：当编码智能体（如 Claude Code）为你提供了三个实现方案，而你难以抉择时，该怎么办？你其实同样可以与 AI 继续深入地对话。
首先，请 AI 详细阐述每个方案背后的权衡。软件架构没有绝对的最佳，只有相对的更合适。了解每个方案的优缺点、设计逻辑和适用场景至关重要。如果这仍不足以帮助你决策，可以进一步向 AI 说明你的特定约束条件和高层偏好。例如，在一个 Rust 项目中，你可以提出要求：“任何时候当需要用到读写锁或互斥锁时，请优先考虑使用 Actor 模式。”即便你对“Actor 模式”不完全理解，这本身就是一个绝佳的学习契机，可以就此让 AI 为你深入研究。如果添加约束后仍难分高下，可以将所有选项提交给 Gemini 进行深度研究，让它为每个方案生成详细的可行性分析报告，评估其是否符合业界最佳实践。通过对比这些报告，你就能做出更明智的决策。
最关键的一点是心态转变：当 AI 的输出触及你的知识盲区时，不应感到担忧，而应感到兴奋。因为这标志着一个明确的学习机会出现了。主动将这些盲区提取出来，交给 AI 去深入研究，你的知识体系和决策能力就能在解决实际问题的过程中实现飞速成长。
主持人：
在 AI 时代下，工程师应该优先学习哪些不太容易被 AI 替代的技能呢？
陈天老师：
我认为关键在于认清 AI 与人类能力的本质差异。AI 擅长完成具体“任务”，而人类的核心价值在于“解决问题”。因此，任何与解决问题相关的高级能力，都是我们应重点夯实的基石。
要解决问题，首先得能发现问题。这就引出了我最常强调的一点：好奇心和想象力。你是否对自己的工作、对这个世界、对所有未知领域抱有强烈的好奇？以大模型本身为例，它已发展三年，如果你还未对其底层逻辑产生好奇并主动探索，那么这正是你首先需要迈出的一步。如果连对手如何“战胜”你都不了解，又何谈防御与超越？因此，好奇心和想象力是一切能力的基石。
其次，是沟通能力。这里的沟通是广义的，不仅限于言语交流或会议讨论，也包括你撰写的文档、输出的任何内容。锤炼清晰、有条理、有逻辑的沟通能力至关重要。你可以通过博客、播客、视频、直播等多种形式分享知识与经验，这个过程不仅能提升沟通能力，更能确保你能否精准地向团队或 AI Agent 阐释意图，从而高效完成任务。
第三，是学习与适应能力。我们面对的是一个不断变化的世界，新问题会持续涌现。这又回到了之前讨论过的话题：如何高效学习？例如，当我提到《学习的革命》这本书时，你的第一反应或许是利用 Gemini 进行深度研究，探索其如何与 AI 时代结合，并获取新的学习方法论。学习应从被动接收转变为主动探索，从单点发散，构建个性化的知识网络。AI 工具能帮助我们快速捕捉知识图谱并聚焦于特定领域，实现高效的学习迭代。如果你不知如何探索，可以借助 AI 运用第一性原理或苏格拉底式提问法，深度领悟问题本质。重要的是主动利用现有工具促进学习，从而持续提升适应变化的能力。
具备了这些基础能力后，无论是在编程还是其他生活领域，你都能构建起自己的核心竞争力。这一切都围绕着“解决问题”展开。而 AI 在发现问题和创造性解决问题层面，在很长一段时间内仍将处于辅助地位。例如，AI 不会在看到整个公司系统状态后，主动提出“应将基础设施从传统的 Production/Staging/Dev 环境隔离，转变为基于流量的隔离模式”这类战略性建议。它难以进行一步步的深度思考来提出此类根本性解决方案。
但你可以让 AI 去探索：业界有哪些解决方案？最佳实践是什么？甚至进行市场调研。最终，你才是那个拍板决策、选定方案、确定解决问题方向的人。AI 可以接管大量执行层面的任务，但构建整体解决问题的能力，始终是我们需要掌握的核心。
主持人：
在使用 AI 编程时，具体应该在哪个阶段开始一行一行地审查代码？
陈天老师：
我们可以做一个类比：假设你是一个开发团队的经理，当你把一个任务（包括详细的需求和架构设计）交给团队成员去完成一个功能时，你会在什么时间点介入进行代码审查？
其实，所有与 AI 协作的问题，我们都可以转换成与人交互的场景来思考，这也是我非常坚持的原则：让 AI 的行为尽可能接近人类。我相信大家对这个问题就会有了清晰的答案：你不会在成员只完成一个半成品时就急着去审查代码。你一定是希望他能够完整地实现功能，并通过单元测试、集成测试、端到端测试或手动测试等方式，保证其正确性。作为负责人，他需要确保自己实现的东西是可靠的，之后提交的代码才值得你去审查。
将这个逻辑应用到 AI Agent 上，我认为理想的方案应该是：AI Agent 能够执行所有人类开发者会执行的步骤，最终为你提供一个经过充分测试的成品。这时，它产出的代码才值得你进行审查。
当然，这可能会让我们失去对中间过程的把控，从而产生恐惧。对于人类开发者，这种恐惧感较弱，因为一个功能的实现可能需要半个月甚至一个月，期间他会不断与你沟通思路、确认方向。而 AI 可能在几个小时内就完成大量代码，这自然会让人担心它是否“跑偏”。
因此，关键在于前期准备。我们必须从一开始就明确地表达需求和高层设计思路，清晰地界定它该做什么、不该做什么。就像我前面提到的在 Rust 项目中的限制条件一样，你可以将这些约束写成规则（Rules），或记录在 agent.md、claude.md 等文件中。在审查 AI 生成的方案时，要通过交互确保其符合你的所有需求。所以现在，前期在需求、设计和实现方案上的“精耕细作”时间会比以往更多。我们需要杜绝过去那种文档还没写好就匆忙开始编码的做法。
此外，还有一件非常重要的事：你需要指导 AI 如何进行手动测试。设计文档可以要求它完成单元测试、集成测试等，但手动测试同样是不可或缺的一环。就像人类开发者一样，即使通过了所有自动化测试，在特定环节仍需要手动测试来最终确保正确性。例如，开发一个 API 服务器，即使每个底层函数和 API 都有对应的测试，最终你可能还是需要测试一个完整的业务流程，确保数据被正确写入且整个流程无误。
我们可以让 AI 根据需求文档来生成相应的测试计划。例如，生成一系列有序、有意义的 API 调用，形成一个完整的业务流程。AI 在完成所有编码后，需要执行代码格式化、链接、静态分析、编译，以及运行所有单元测试、集成测试、端到端测试和手动测试。只有所有这些步骤都通过了，生成的代码才值得被提交为一个待审查的 PR。此时，我们可以认为 AI 生成的代码质量已经尽可能接近人类工程师的水平。这个时候的代码才值得被审查。
有人可能会问，如果生成了几千行代码，该如何审查？审查可以分两步走：
工具审查：可以利用 Codex 等工具进行初步审查。在我看来，Codex 审查代码的能力非常不错，经常能发现 Claude Code 或 Gemini 都未察觉的隐含问题。
人工审查：人工审查应更关注高层设计，例如高层接口是否正确、整体架构是否符合意图、各子系统间及对外的接口是否规范等。
至于是否需要逐行审查，我认为与其投入大量精力去做逐行审查，不如将测试体系构建得足够牢固，确保测试覆盖率有充分的保证。这可能比逐行审查更有意义。某种程度上，未来的 AI 编码可能会处于一种“持续重构”的状态。今天你审查过的代码，明天可能就被重构了。这在以前的人类开发中难以实现，但在 AI 时代完全可能发生。
另外，还有一种很重要的编码思路适用于探索性场景：很多时候我们对需求并不完全了解，是在探索中解决问题。这时，初期可以不必过于严苛，可以允许需求分析是半成品的状态。因为在没有看到实际产品之前，你可能并不清楚产品最终的样子或发展方向。你可以在保证基本正确性的前提下，放手让 AI 去完成初步实现，然后你与这个“产品”进行交互、探索，从中学习新知识、获取反馈。收集了所有这些思考、反馈和新知识后，再重新审视需求，甚至可以将整个代码推倒重来。
这意味着你随时可以从零开始。这在此前是无法想象的，因为探索性工作短则几周，长则数月，不可能轻易废弃。但 AI 可能在一两天内就能完成一个深度开发。当你获得了各种认知后，就可以丢弃之前的版本，实践“构建两次”的理念，这只有在 AI 时代才可能高效实现。
我最近做的很多项目都具有极强的探索性。比如前面提到的流量隔离问题：如何通过给流量打上特定标签，使其在服务链中能够走不同的路径再返回。这涉及到 Kubernetes Operator、控制平面服务、数据平面服务、Istio 或 Sidecar 的路由处理等，是一个非常复杂的问题。很多知识我是现学现用。这种情况下，让 AI 写的第一版代码或许能工作，但可能在未来难以扩展或存在其他问题。当你完成探索后，完全可以废弃这版代码，从头再来。这时，废弃掉几万行由 AI 生成的代码，你也不会觉得可惜。然后在第二版开发中，你可以非常严苛地要求 AI 完全按照你探索后形成的思路和学到的最佳实践来实现。
主持人：
使用 AI 工具时总会担心数据泄露的问题，有什么办法可以避免这个问题呢？
陈天老师：
有两条路径可以兼顾使用效率与数据安全。
第一种是推进大模型的本地化部署。当前不少开源模型的能力已经很强，不少能达到顶级商业模型八九成左右的效果。如果你具备本地部署的条件，完全可以考虑构建一套混合推理架构：在涉及敏感数据的场景下使用本地模型，确保核心代码与业务数据不流出内网；在非核心或通用任务场景下，再按需调用云端大模型。例如，阿里云的千问 Coder 就是一个能力相当不错的代码生成模型，非常适合在本地环境部署使用。
第二种是针对必须使用云端大模型的情况。这时，关键在于选择那些能提供严格数据保护协议的服务商。通常你需要和对方签署 NDA 协议，明确约定数据仅用于实时推理，并以暂存方式处理，任务一结束立即销毁，绝不会用于模型训练或其他用途。这套合规流程能极大降低代码和业务数据泄露的风险。
当然，也会有朋友会坚持认为，代码本身就是软件公司最核心的资产，即便有协议约束，把代码发到云端心里还是不踏实。但我想提出一个不同的视角：在 AI 时代，代码本身的重要性正在下降。一家公司真正的核心壁垒，越来越偏向其独特的业务逻辑、对市场的快速响应能力以及构建的综合护城河。很多公司积累多年的代码库，借助 AI 可能在一两周内就被复现出来。所以，代码的保密性可能没有我们传统认知中那么关键。
相比之下，数据的安全边界反而更加重要。我仍然建议采用刚才提到的混合架构：关键数据坚决由本地模型处理，非关键且需借助强大 AI 能力的任务，再考虑上云。
主持人：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 2025年是智能体普及的关键年，AI编程工具如Claude Code取得显著进步，开发者应转变角色为“方案指挥者”，利用AI高效学习与探索，强化解决问题的能力。 2. AI编程取得长足进步，编程将越来越从“人类亲自执行具体任务”转变为“在Agent的协助下完成大量工作”，思维范式发生转变。 3. 工程师在AI时代应该优先学习好奇心和想象力、沟通能力、学习与适应能力等与解决问题相关的高级能力，因为AI擅长完成具体“任务”，而人类的核心价值在于“解决问题”。 4. 在使用AI编程时，审查代码应该在成员完成一个完整的功能并通过单元测试、集成测试、端到端测试后进行，让AI的行为尽可能接近人类。 5. AI Agent 能够执行所有人类开发者会执行的步骤，最终为你提供一个经过充分测试的成品，需要通过交互确保其符合所有需求。 6. 在AI时代，代码的保密性可能没有传统认知中那么关键，相比之下，数据的安全边界更加重要，建议采用混合架构处理关键数据。 7. 推进大模型的本地化部署和选择能提供严格数据保护协议的服务商是兼顾使用效率与数据安全的两种路径。 8. AI时代下，公司的核心壁垒更偏向其独特的业务逻辑、对市场的快速响应能力以及构建的综合护城河，代码的保密性可能下降。 9. AI编码可能会处于一种“持续重构”的状态，需要构建牢固的测试体系，确保测试覆盖率有充分的保证。
2025-12-23给文章提建议
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《极客时间 VIP · 干货直播稿精选》
《极客时间 VIP · 干货直播稿精选》
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论