最近，我参加了Datawhale开源社区组织的每月组队学习，在平台带领下接触并阅读了《CodeBuddy领航：AI辅助编程应用·架构·交付》第一章内容，书中系统梳理了 AI Coding 的起源、技术基础、发展脉络以及典型平台 CodeBuddy 的实践路径。

作为一名计算机系的本科学生，结合先前对AI Coding的浅层接触，不局限于用它解决日常的小的作业问题，或许，在此我又对它又有了进一步的深刻认识。

一、编程的方式，正在悄悄发生变化

以前用 AI 写代码时，我偶尔会觉得它只是“见过类似的东西，然后抄过来”。但书中强调，大语言模型并不是简单记忆，而是在大规模学习过程中形成了对程序逻辑和结构的抽象理解。

换句话说，它能在语义层面理解我想要什么，然后推理出合适的实现方式。这也让我明白：写好提示词、把需求说清楚，变得越来越重要。对我这种计算机学生来说，这其实也是一项新的、值得刻意练习的能力。

二、大语言模型不是在“背代码”，而是在“理解语义”

书中反复强调一点：大语言模型并非简单记忆代码片段，而是在大规模语料学习中建立了对程序语义、控制结构与工程模式的抽象理解。

这一点对我的触动较大，因为在实际的使用中，我偶尔会将模型生成能力归因于“训练数据够多”。但更准确的解释是：模型在语义空间中完成了意图解析、逻辑推理与代码生成的协同过程。这意味着，当我们给出清晰、结构化的提示词时，模型有能力进行类人的推理与设计，而不仅仅是检索与拼接。

因此，高质量的人机交互（尤其是 Prompt 设计）正逐渐成为一项核心技能。

三、AI Coding 是一个“表达—生成—检查—优化”的闭环

书中把 AI Coding 的流程概括为四个步骤：

表达需求 → 生成代码 → 审查代码 → 优化迭代

这个模型让我重新理解了 AI 在开发中的角色。以前我往往是“写一句提示、拿一段代码、能用就行”，很少认真做审查和迭代。

但事实上，真正有效的 AI 编程，是在人和模型之间形成一个持续的反馈回路。我需要在审查环节判断代码是否正确、安全、合理，然后再引导模型改进。这个过程里，人的判断力不但没有被削弱，反而更重要了，我们需要对生成的代码进行调试与判断，进一步优化以达到我们的预期，这对人的想法创意与技术要求其实也是很高的。

四、AI 编程不是要取代传统编程，而是互补关系

书中有一个对比表格，把传统编程和 AI 编程放在一起比较：驱动方式、效率、门槛、适用场景等。给我的感受是：两者并不是对立关系。

• 传统编程在底层系统、性能敏感的场景中仍然不可替代。
• AI 编程在 Web 开发、原型设计、业务系统、课程作业等场景中明显更高效。

对我们学生来说，不是“学了 AI 就不用学基础了”，而是要在打好基础的前提下，学会用 AI 提升效率。两者结合，反而能学得更深、走得更快。

五、CodeBuddy 体现的是“工程级智能协作者”的定位

书中以 CodeBuddy 为例，介绍了它通过 IDE、插件、CLI 三种形态，覆盖编码、调试、重构、测试等开发全流程。让我印象比较深的是三个点：特别值得注意的是以下这些：

• 上下文感知：它不只是看当前文件，而是能理解整个项目的结构和依赖。
• 一致性保障：在多文件、多模块协作时，生成的代码风格和架构不容易乱。
• 人机协同闭环：开发者负责设计和判断，AI 负责高频、重复、容易出错的部分。

这种设计理念，让我也更加明确：未来的高效开发者，不是那些会“写更多代码”的人，而是那些善于与 AI 协同、能够有效引导并校验 AI 输出的人，这或许也正是AI出现的意义——与人合作。

六、感悟与启示

结合这次的阅读和思考，我给自己列了几个小方向：

1. 多练习写清楚需求：把提示词写得结构清晰、逻辑完整，把它当成和写代码同等重要的能力。
2. 不盲信生成结果，保持审查习惯：AI 出的代码也要认真看，理解之后再使用。
3. 尝试用 CLI 和插件把 AI 融入日常开发：不只是偶尔用一下，而是让 AI 成为开发流程的一部分。
4. 继续打好基础：AI 是工具，真正的判断力和设计能力还是来自于对计算机原理和工程方法的理解。

小结：
这一章内容让我对 AI Coding 有了更系统的认识。我明白，它不是一个短暂的热点，也不是程序员的“终结者”，而是一次实实在在的开发方式演进。对我们学生来说，现在正是理解和实践 AI 编程的好时机——不是焦虑被替代，而是主动学习如何与 AI 更好地协作。

如果你也在学习 AI 编程，欢迎一起交流 🙌如果想要一起学习，也可以一起来Datawhale平台获取更多的学习资源，和我一起组队学习。封面为AI生成嘿嘿~