AI 时代要拥抱 AI，学着去使用 AI
一个非软件方向的计算机专业学生，从只会 C 语言和 Python 基础，到借助 AI 完成网络安全毕业设计的真实经历与思考。
前言
我是计算机专业的大学生，但所学方向并不是软件开发。大学期间真正接触过的编程内容，主要是 C 语言基础和 Python 基础。放在传统的软件开发路径里，这样的基础很难让我独立完成一个结构完整、能够实际运行的项目。
但在 AI 时代，情况正在发生变化。
从 2025 年 4、5 月前后开始，我尝试使用 AI 工具写代码，做一些自己感兴趣的小工具。到后来，我甚至决定从零开始开发一个与网络安全有关的工具，并把它作为自己的毕业设计。
这段经历并不轻松。AI 没有让我按一下按钮就得到成品，反而带来了大量反复修改、测试和重新沟通。但它确实让我跨过了原本很难跨过的技术门槛，也让我更加确信：在 AI 时代，与其担心被 AI 取代，不如先学会使用 AI，把它变成自己的能力放大器。
从几个小工具开始
刚开始接触 AI 编程时，我没有明确的开发路线，也谈不上掌握工程化方法。我的想法很简单：让 AI 帮我写代码，把脑海里一些有趣的点子做出来。
这个过程很像一场持续的问答。我描述需求，AI 生成代码；我运行代码，发现问题；再把报错和实际效果反馈给 AI，让它继续修改。有时一个功能很快就能完成，有时同一个问题会来回调整很多次。
虽然这些小工具并不复杂，但它们让我第一次感受到：编程基础有限，并不意味着只能停留在看教程和写练习题的阶段。只要能把需求说清楚，愿意阅读代码、运行测试并不断修正，就有机会把一个想法变成真正可以使用的程序。
一个突然出现的毕业设计想法
2025 年 5 月底左右，在准备毕业论文和毕业设计时，我突然有了一个想法：能不能借助 AI，从零到一开发一个网络安全方向的工具，并把它作为自己的毕业设计？
这个想法对当时的我来说并不简单。我既没有完整的软件开发经验，对桌面界面、后端服务和智能体系统也没有系统学习过。但既然已经开始使用 AI 写代码，我决定尝试把目标定得更高一些。
那段时间，我陆续接触了 Trae CN、通义灵码（现在的 Qoder CN）等 AI 编程工具。暑假期间，腾讯 CodeBuddy 开始内测，我也参与了使用。后来逐渐形成了自己的工具组合：以 CodeBuddy 作为主要开发工具，Trae 辅助，通义灵码作为备用。
CodeBuddy 当时可以选择多种大模型，这给了我比较和尝试不同模型的机会。不同模型对需求的理解、代码风格和解决问题的能力并不一样。经过大约一周与 AI 的讨论和反复权衡，项目最终确定使用 Python 作为主要开发语言。
技术选型大致如下：
| 模块 | 技术 |
|---|---|
| 主要开发语言 | Python |
| 桌面界面 | PySide6 |
| 后端接口 | FastAPI |
| MCP 能力 | FastMCP |
| 开发方式 | AI 生成代码，人工审查、运行与测试 |
现在回头看，这套组合并不一定是唯一答案，但对当时的我来说，它降低了从想法到原型的门槛，也为后续加入 Agent、工作流和 MCP 留出了空间。
每天都是一场新的挑战
项目刚开始时，不管是 PySide6、FastAPI 还是 FastMCP，我都处于边做边学的状态。大部分代码由 AI 生成，我负责描述需求、检查结果、测试功能，再根据实际问题让 AI 修改。
那时的 AI 编程能力还没有现在成熟。它经常误解需求，也会修好一个问题后引入另一个问题。有些代码看起来完整，真正运行时却会出现依赖、状态管理或模块衔接方面的错误。很多时候，我需要反复调整提示词，拆分任务，把一个大需求变成多个小步骤，再让 AI 逐个完成。
那段时间，我每天大约会开发 6 到 8 个小时，经常从下午两点左右一直做到凌晨一两点。每天打开项目，都可能遇到一个新的问题：界面交互不符合预期、后端接口无法正常调用、功能模块之间难以衔接，或者 AI 连续修改几次仍然没有解决报错。
开发成果一开始并不让我满意，但看着 AI 根据自己的想法不断生成和修改代码，又确实是一种很特别的体验。那段日子可以说是痛苦与快乐同时存在。
我逐渐总结出一个最实用的方法：先让功能实现，再逐步优化。
如果一开始就要求 AI 同时做到架构合理、界面美观、代码简洁、性能优秀和功能完整，结果往往是哪一项都做不好。把任务拆开，先验证最小可用功能，再处理结构和体验，项目才真正开始向前推进。
Agent、工作流与 MCP 带来的转折
到了 2025 年 10、11 月，Agent 和工作流开始快速流行，逐渐进入市场和大众视野。我也开始了解这些新的概念，并尝试把它们融入自己的工具。
过去让大模型完成任务，更多是一次提问、一次回答。Agent 则强调目标、工具调用、环境反馈和连续决策；工作流负责把复杂任务拆成相对稳定的执行步骤；MCP 则为模型连接外部工具和数据提供了更统一的方式。
经过不断尝试，项目的大体框架终于逐渐形成：一个基于 Multi-Agent、Workflow 和 MCP 的安全测试工具。不同智能体承担不同任务，工作流组织测试过程，MCP 负责连接工具能力。核心功能基本实现后，剩下的工作就是持续补充、完善和打磨。
这也是整个开发过程中最明显的一次转折。AI 不再只是替我生成某个函数或页面，而是开始参与一个更完整的任务执行过程。
从“能够运行”到“真正智能”还有距离
到了 2026 年 3、4 月，临近提交毕业论文时，我开始接入大模型 API，对工具进行更完整的测试。
测试结果并没有想象中理想。工具中的智能体可以正常运行，也能够完成渗透测试流程和靶场任务，但“可以完成”与“效果足够智能、稳定”之间仍然有很大差距。
智能体可能选择不够合适的步骤，可能无法充分利用前面的结果，也可能在任务变复杂后偏离目标。模型本身的能力、提示词设计、上下文管理、工具描述和工作流结构，都会影响最终表现。任何一个环节设计得不够好，都可能让整体效果打折扣。
这让我认识到，AI 生成了代码并不代表项目已经完成，API 成功返回结果也不代表智能体真正可靠。AI 项目同样需要工程设计、边界控制和大量测试。越是把任务交给 AI 自主执行，越要重视日志、状态、异常处理和人工监督。
完成项目之后，还有论文
经过长期熬夜和不断修改，工具最终达到了可以展示和使用的程度，毕业论文也终于写完了。
相比写代码，写论文对我来说是另一种痛苦。项目能否运行，通常可以通过测试直接判断；论文则要把背景、设计、实现和结果完整地表达出来，还要处理格式、引用、逻辑和重复率等问题。写完之后，还有 AIGC 检测和查重。
好在最后顺利通过，一切也算告一段落。
回头看，这个项目当然还有许多不成熟的地方，但对我个人而言，它的意义并不只是一份毕业设计。它让我从只能写一些基础代码，走到了能够理解并组织桌面端、后端、Agent、工作流和 MCP 的完整项目。这个跨度如果只靠原有基础和有限时间，我很难独自完成。
我理解的“拥抱 AI”
拥抱 AI，不是把所有事情都丢给 AI，更不是复制一段代码、看到它能运行，就认为自己已经掌握了开发。
真正学着使用 AI，至少需要做到几件事：
- 学会描述问题。 需求越清楚，背景和限制越完整，AI 越可能给出可用的结果。
- 学会拆分任务。 不要期待一个提示词完成整个项目，把目标拆成能够验证的小步骤。
- 保留判断能力。 AI 会生成错误代码，也会一本正经地解释错误结论，最终决定仍然需要人来做。
- 坚持运行和测试。 不要只看代码是否“像是正确的”，而要真正运行，检查每个功能和异常情况。
- 在实践中补基础。 遇到不懂的概念就去查、去学。AI 可以降低入门门槛，但基础知识决定了能走多远。
- 先实现，再优化。 先证明方案可行，再改善架构、性能和体验，更适合个人项目的推进节奏。
AI 确实会让不会的事情变得可以尝试，但它不会自动替人承担目标、判断和责任。使用者依然需要监督过程、识别问题，并对最终结果负责。
结语
我不是软件开发方向的学生，开始时也只有 C 语言和 Python 的基础，但借助 AI，我最终完成了一个原本超出自己能力范围的毕业设计。
这个过程没有想象中轻松。它有大量失败、返工、熬夜和自我怀疑，也有功能第一次成功运行时的惊喜。正是这些反复尝试，让我真正理解了 AI 的价值：它不是一个无所不能的替代者，而是一个需要沟通、监督和共同迭代的工具。
AI 时代已经到来。与其站在远处讨论它会带来什么，不如先亲手用起来。从一个小想法、一个小工具开始，在实践中学习如何与 AI 协作，也学习如何让自己变得更有能力。
版权声明
- 作者
- Dawn
- 许可
- 本博客所有文章除特别声明外，均采用CC BY-NC-SA 4.0许可协议。转载请注明来源 Dawn's Blog！