从用AI美化一张食堂菜单，到构建一个完整的发版管理系统，我走过的路，或许也是许多开发者正在经历的AI赋能之旅。

2025年，被称为“Agent元年”，AI编程的浪潮以惊人的速度重塑着开发者的工作流。作为一个在浪潮中尝试“下水”的实践者，我从最初的好奇与试探，到如今能相对熟练地利用AI工具解决实际问题，期间经历了无数次的对话、调试与重构。今天，我想通过复盘近期完成的四个“今天”系列小项目，分享这段旅程中的真实感悟、踩过的坑以及收获的宝贵经验。

01 项目实践：四个“今天”，四种成长

我的AI编程学习并非始于宏大的构想，而是从一个极其具体且微小的需求切入。

1. 今天吃什么——每周食堂菜单：AI编程的“破冰”之旅

PixPin_2026-01-25_04-19-00.png

这是我的第一个AI应用，需求简单到极致：将每周枯燥的Excel食堂菜单，变成一个美观的网页。我选择了 Trae 作为工具，看中其600次的免费提问额度，并指定 Gemini 3 Pro 作为模型，因为它在UI设计上素有口碑。

  • 收获与反思：这个项目让我完成了从“想”到“做”的跨越。我学习了如何向AI描述一个视觉需求，并初次接触了 Frontend Skills 和 GitHub Actions 的配置。它印证了一个观点：AI编程最适合从解决身边一个真实、微小的痛点开始，而非好高骛远。这也是一种典型的“Vibe Coding”初体验——通过与AI聊天，轻松地将想法变为可运行的代码。

2. 今天发什么——发版管理系统：从“玩具”到“工具”的升级

当需求从个人趣味转向工作实际，挑战陡然增加。我需要为即将到来的系统上线，将一个Excel记录流程平台化、规范化。这次我选择了 Kiro，因其在 Spec（规范）编程 方面的优势，这正符合我对流程确定性的要求。

  • 核心方法：我采取了 “边开发、边测试、边整理需求” 的滚动式开发。这与社区总结的 “小步迭代” 方法论不谋而合。每完成一个小的功能模块，就进行测试和代码审查，并用Git保存进度，防止AI在后续修改中将代码引入混乱。

  • 技术探索：为了解决环境调试难题，我尝试了通过远程桌面操作Linux系统进行在线编程。这让我能在接近生产环境的Docker容器中调试，避免了直接依赖GitHub Workflow编译导致的反复试错。这个过程让我深刻体会到，清晰的开发环境是高效AI协作的前提。

3. 今天开什么——GitHub项目采集：探索混合开发工作流

image-NQJO.png

这个项目源于我的个人兴趣：高效获取并理解海外开源项目。它更像一次技术探险。

  • 混合工具链：我利用 Google Stitch 进行产品原型设计，用 AI Studio 生成前端代码基调，最后在 Trae 中开发后端并接入自部署的大模型。这种“设计-AI生成-深度开发”的流程，让我体验到如何将不同工具的专长组合成高效的生产线。

  • 意外发现：由于Trae暂不支持Linux，我意外摸索出了 “Windows本地Trae编辑器 + SSH远程Linux开发环境” 的混合方案。这既享受了本地编辑器的流畅和白嫖的模型额度，又获得了Linux原生Docker环境的部署便利。这再次说明，灵活组合现有资源，往往能突破工具本身的限制。

4. 今天下什么——客户端下载页：追求确定性与细节还原

这是一个经典的优化需求：重写一个设备判断与下载引导页面。这次我进行了一次有趣的 “平行实验”：同时使用 Trae（Builder模式） 和 Kiro（Spec模式） 开发同一需求。

  • 对比感悟：对于这类强展示、逻辑相对固定的页面，Trae的Builder模式更加直观高效；而Kiro的Spec模式则显得有些“杀鸡用牛刀”。这让我对 “工具与场景的匹配” 有了更深理解。同时，通过上传设计素材让AI反复调整，我体会到：只要需求描述足够精确，AI在实现C端页面交互细节和美观度上，往往能凭借其海量经验，给出超越普通开发者直觉的方案。

02 核心心得：从“与AI聊天”到“对AI工程”

通过这四个项目，我的AI编程观念发生了根本性转变，从最初的“氛围编程”（Vibe Coding）爱好者，逐渐转向追求工程化和确定性的实践者。

1. 工具选择：没有“最好”，只有“最合适”与“最熟练”

我先后深度使用了Trae和Kiro，也浅尝了其他平台。这与许多开发者的经历相似。一个深刻的体会是：顶级AI编程工具的功能正在快速趋同。Plan模式、AGENTS.md、Skills等功能已成为标配。因此，与其不断追逐新工具，不如选择一个顺手的、处于第一梯队的工具，并与之深度磨合。就像赛车手需要熟悉自己的赛车一样，开发者也需要与自己的AI工具建立“人机合一”的默契。

2. 需求沟通：清晰度决定代码的可用性

这是AI编程中最核心的一课。初期，我常抱怨AI“听不懂”或“做错了”，但根本原因在于我的需求描述含糊不清。例如，不能说“做个列表页”，而要说“做一个移动端优先、支持分页和搜索、使用SWR进行数据请求的商品卡片列表页”。结构化沟通（背景+需求+约束+输出） 是确保AI理解无误的关键。我的“发版管理系统”项目能顺利推进，正是得益于在开发过程中不断将模糊需求沉淀为清晰的“规格说明书”。

3. 开发方法论：小步迭代、严格审查与上下文管理

  • 小步快跑，善用Git：将一个复杂功能拆解成多个可验证的小步骤，每完成一步就提交代码。这能有效防止AI在复杂修改中“跑偏”，一旦出现问题也能迅速回滚。

  • 代码审查（Code Review）不可或缺：绝不能因为代码是AI生成的就放松审查。AI可能会为了完成当前任务，无意中修改其他模块的通用方法，埋下隐患。每一段生成的代码，都必须经过功能逻辑和影响范围的审视。

  • 守护上下文窗口：模型的能力受限于其上下文窗口。当上下文被占满（例如加载了过多规则文件或开启无用工具），AI的表现会显著下降，开始“胡言乱语”或写出更多bug。我的经验是，始终保持上下文使用率在60%以下，必要时开启新对话，这是提升AI编程稳定性的最简单有效的方法。

4. 角色进化：从“码农”到“架构师”与“产品经理”

AI接管了大量样板代码、重复逻辑和调试排查的初筛工作。这迫使我的角色发生转变：

  • 更专注于系统设计与核心逻辑：我不再纠结于某个API的具体写法，而是更多地思考模块划分、数据流设计和用户体验。

  • 更像个产品经理：需要更精准地定义需求、拆解任务、排定优先级，并评估AI产出的结果是否真正符合业务目标。正如一位实践者所言，“效率不再是‘写了多少行代码’，而是‘用更少的代码解决更复杂的问题’”。

03 总结与展望：拥抱变化，掌握原理

回顾这段旅程，我最大的感触是：AI编程并没有让开发变“简单”，而是让开发的难点从“动手实现”前移到了“动脑思考与清晰表达”。它不是一个“偷懒神器”，而是一个“思维增强器”，逼着我们去更好地理解问题、设计架构和沟通意图。

2025年，我们告别了初期的Vibe Coding狂欢，开始进入AI编程的方法论时代。社区涌现的SDD、RPI等方法论，以及工具内建的Plan模式，都指向更工程化、更确定性的协作方式。

对于未来，我认同这样的趋势：成功的方法论，必然是能更高效利用模型上下文、用更高密度信息精准传递意图的方法。同时，随着模型Agentic能力的持续进化，开发者将更多地扮演 “智能体（Agent）设计师” 的角色。

对我而言，学习AI编程，不仅是学习使用新工具，更是学习一种在智能时代与机器协同创造的新思维模式。这条路还在延伸，但起点清晰：从一个真实的“今天吃什么”开始，保持开放心态，持续实践、复盘与磨合。这趟旅程，值得每一个开发者亲身走一遍。

PS：题外话

未来已来。作为一名从程序员转向项目经理的“老码农”，我长期穿梭于需求、文档、汇报与客户之间。工作的压力让我逐渐放下了键盘，淡忘了写代码的手感，更失去了追逐新框架的精力。在这个行业，稍慢一步，便可能被技术浪潮抛在身后。

然而，AI 的出现，仿佛为我们这些“老人家”注入了新的活力。它让我们能够跳过底层技术更迭的漫长学习曲线。而多年在产品和项目中打磨出的大局观与系统思维，反而成了这个时代难得的稀缺能力。甚至那些曾经为了效率而学的 Markdown、业余折腾的 NAS 和 Docker，如今都成了理解与驾驭 AI 编程的坚实基底。

AI 开发不再只是一种辅助工具，它更像是一次时代的馈赠。它不仅给了我们这些一度远离编码的人二次出发的机会，也在无声地鞭策着年轻一代开发者不断向上。我们不再只是孤身奋战的码农，而是与智能体并肩同行的协作者，更是驾驭技术的指挥官。