接上篇所言，继续我的Datawhale组队学习之旅，在这一阶段我完成了《CodeBuddy领航》第二章和第三章的学习：如果说第一章是“理念认知”的刷新，那么这两章就是真正动手落地的开始——从安装配置到上手第一个AI Coding项目，整个过程既有平台教程的清晰指引，也有我自己的不懈尝试和探索。

一、第二章：从零到一，把CodeBuddy跑起来

书中第二章的内容干货满满，比较务实，主要围绕CodeBuddy的安装、环境配置、界面认知和基础操作流程展开。作为一个计算机系的学生，加上平台一步一步带着做的清晰教程，与CodeBuddy本身安装便捷，运行软件成功本身并不算难，但这一章的价值在于：它帮我建立了一个清晰的“使用框架”。

具体收获可以如下这样说：

1. 三种形态，各有所用：

书中介绍了CodeBuddy的三种承载方式：IDE独立版、插件版和CLI工具。其实刚知道还有插件版和CLI版时停惊喜的，因为它可以适配不同习惯于需求群体。

但我还是选择了IDE独立版，因为作为初学者，一个集成的图形界面更能帮我理清“AI辅助编程”的完整流程；插件版适合已经在VS Code等工具有深度使用习惯的开发者；CLI则更偏向服务器运维或自动化场景。理解这三者的区别，对我未来在不同场景下选择合适的工具形态也很有帮助。

2. 界面分区，认知对齐

第二章对CodeBuddy IDE的界面做了清晰的分区说明：导航区、代码编辑区、AI辅助区、终端/输出区。这些看似基础的内容，其实是后续所有操作的“认知底座”：我在跟着教程熟悉界面时，特别注意了AI辅助区的位置和交互方式——因为那将是后续与模型对话、生成代码的核心入口。

3. 基础工作闭环：“描述—生成—验证—修正”

第二章提出了一个很实用的AI Coding工作闭环：用自然语言描述需求 → AI生成代码 → 开发者在IDE中验证 → 根据结果修正或继续对话。

这个概括简洁的闭环贯穿了后续所有实践，也让我意识到：AI编程不是“一次性生成完美代码”，而是一个持续对话、逐步逼近目标的过程。

二、第三章：Hello AI World，第一个项目上手指南

第三章是本书的第一次完整实战，教程选取了To Do List作为示例项目，带着读者走完“从需求到可运行应用”的全流程。

但我没有选择跟着教程照抄——既然要学，不如直接做自己想做的项目。于是我决定：在跟着教程理解方法论的同时，同步开发我自己想做的项目——Linku 灵库。

项目简介：Linku 灵库，个人知识库问答助手

解决什么问题？我们每个人都在收藏文章、保存截图、记笔记，但几乎从不回顾。信息越积越多，知识却越来越散。Linku灵库想做的，就是把这些“沉睡的碎片”重新唤醒。

数据来源：用户自己产生的数据——Markdown笔记、PDF文档、网页剪藏、截图等。不存在获取困难，核心问题是“怎么用起来”。

核心AI能力：

• 语义检索：用自然语言提问，比如“我之前看过一个关于Python装饰器的文章”，AI帮你找出来；
• 自动标签/分类：帮你整理散落的笔记，自动归类；
• 智能摘要：长文章自动生成要点，快速回顾。

技术栈：RAG架构 + 本地向量库 + Ollama模型（完全本地运行，数据不出境）

三、从To Do List到Linku：方法论迁移与实战收获

虽然教程用的是To Do List，但第三章的核心方法论完全可以迁移到我的Linku项目上，对我的实战有很大的现实参考意义。

1. 自然语言驱动的开发流程

第三章强调了一个关键认知：

提示词不是简单的“提问”，而是一份“简化版的需求规格说明书”。

一个好的提示词应该包含：背景信息、界面结构、行为逻辑、技术约束、代码组织方式、代码风格要求。我把这个框架用在了Linku的初始开发中。比如在搭建上传模块时，我写的提示词大致是这样的：

 “我需要一个个人知识库问答助手的前端页面，包含文件上传区域（支持Markdown、PDF、图片）、文档列表展示区、以及一个对话式的问答输入框。技术栈使用HTML/CSS/JavaScript，不依赖后端框架，文件上传先做前端预览，实际解析后续再对接。”

相比以前“帮我写一个上传功能”这种模糊提问，结构化后的提示词生成的代码明显更贴近实际需求，修改成本也低了很多。

Linku在CodeBuddy上的开发界面

2. “描述—生成—验证—修正”闭环的真实体感

在实际开发中，这个闭环反复发生。比如在实现文档列表展示时，AI生成的初始版本只展示了文件名，没有展示上传时间。我验证后发现不符合预期，于是在对话中补充：“请在每条文档旁边显示上传时间，格式为YYYY-MM-DD HH:MM”。AI根据这个补充信息快速调整了代码。

这个过程让我体会到：人机协同的核心不是AI有多强，而是你能不能清晰地表达“哪里不对”和“想要什么”。

3. 结构化提示词的价值被验证

第三章给出了一个标准提示词模板，包含背景、界面、行为逻辑、技术约束等要素。我在Linku开发中尝试沿用这个结构，效果确实更好。比如在技术约束中明确“使用本地Ollama模型，不做云端API调用”，AI就会避免生成需要外部API Key的代码，从一开始就贴合我的本地优先设计。

4. AI辅助的边界：需要人工校验和持续优化

第三章也明确指出，AI生成的代码不是“开箱即用”的。我在Linku开发中就遇到了这个问题：AI生成的文件上传预览逻辑在部分格式上存在兼容性问题，需要我手动调整。

这也让我意识到：AI是高效助手，但最终的质量把控和工程判断，还是要落在开发者自己身上。

四、Linku灵库的当前进展与后续计划

已完成：

•  项目基本功能框架搭建完成（前端界面、文件上传预览、文档列表展示）
• 基础对话交互逻辑可用
• 明确了RAG + 本地向量库 + Ollama的技术路线

待持续优化：

• 后端解析逻辑（Markdown、PDF、图片OCR）需要完善
• 向量检索的准确度和性能需要调优
• 自动标签/分类和智能摘要功能需要进一步实现
• 整体交互体验需要打磨，UI界面需要优化

这个项目目前还处于“能跑但不够好”的阶段，后续会持续迭代。

但对我而言，最重要的收获不是项目本身，而是验证了一套可以复用的AI辅助开发方法论。

五、这一阶段的核心认知总结

用一段话概括这一阶段的收获：

通过第二章和第三章的学习，我完成了从“知道AI Coding是什么”到“亲手用AI Coding做一个真实项目”的跨越：CodeBuddy的安装、界面认知和基础工作闭环帮我建立了规范的操作框架；而ToDo List案例中提炼的结构化提示词方法、“描述—生成—验证—修正”的迭代模式，被我成功迁移到了自己的Linku灵库项目上。

在此我深刻体会到：AI编程不是“一键生成完美代码”的黑箱，而是一种需要开发者主动引导、持续校验、不断优化的人机协作方式。工具本身很重要，但更关键的是你如何组织需求、如何与AI对话、如何把生成结果纳入工程判断。

Linku灵库还在路上，但这条路怎么走，我已经有了更清晰的地图。

写在最后

这一阶段的学习让我对AI Coding有了更落地的理解：如果说第一章是“看清方向”，那么第二章和第三章就是“迈出脚步”。

从跟着教程做ToDo List，到做出自己的Linku灵库，中间隔的不是技术难度，而是“敢不敢把方法论迁移到自己想做的事情上”。

接下来会继续迭代Linku，也会继续跟着Datawhale的节奏学习后续章节。如果你也在做类似的个人知识库项目，或者对AI辅助编程感兴趣，欢迎和我一起交流～🤝

封面依旧由AI同志生成~~