我的Agent实践记录

注：在写这篇Blog时，当时还未使用过Claude Code、Codex等工具，主要还是集中在一些免费的渠道上。然后Blog里的内容在后面看来已经过时，Codex后来居上，Claude Code接入Deepseek也是性价比方案，Copilot我觉得已经快要出局了，模型和额度都越来越少，限制也越来越多。但这篇Blog还是作为我AI使用方式转变的一种记录吧，记录一些自己不太成熟的idea（2026.5.31补充）

很长一段时间里，我知道Prompt一直是用好AI的关键，但好像对Prompt工程并没有给予很高的重视，之前总是处于比较初级的用法，比如把需求描述清楚，给定角色等等，网上各种关于提示词的教程也错综复杂，所以一直没有去看，包括也有刷到过Prompt工程师等等，还有思维链等操作，当时觉得于自己而言作用并不大，自己可能也不需要那么复杂的prompt。甚至在我看来，这些对于普通用户似乎都过于遥远，尤其是如果只是在网页端与AI对话。

但最近在做一个体量稍大的个人网站项目时，这大半年重度使用各家AI的经历，让我的想法有了较大的改观。

各种AI工具的比较（截至2026.04.01）

在实际的项目推进中，我对国外一些免费的工具都进行了尝试，发现它们各有千秋，但也存在缺陷：

• Copilot：代码补全很丝滑，但在IDE的Chat里，上下文经常莫名其妙丢失，很容易出现前言不搭后语的情况。我觉得对上下文的管理不太行
• Gemini 3.1 Pro (AI Studio)：很适合用来捋清楚项目思路，能够给出较好的方向性知道。我通常用它来搭框架，写个初步的 Markdown 规划。但网页端的形态和额度限制，让它很难Hold住稍大的本地项目。
• Antigravity (调用Claude)：最初接触的时候，觉得它的 Plan 模式很不错，能把简单的 Prompt 扩写成完整的 Implementation Plan.md。其实降低了大家用AI完成项目的门槛，哪怕不是资深开发，也能够根据这些计划开发一个简单MVP。从项目实施的完整性来说，它优于 Gemini。但国内访问连接极不稳定，项目一大、需求一多就容易“歇菜”。

兜兜转转，最后的落地执行往往又回到了 VSCode 里的 Copilot Agent。之前主要是利用copilot去做补全，或者类似百科全书查询一样，多使用Ask功能，现在多用Agent的功能了，直接让它去编辑、生成代码，以及Debug。有时候需要加功能还是会去Gemini问一问，让它提供指导

但随着 Agent 的深度使用，我也发现一些弊端：

1. 版本管理：虽然主流工具都有回退功能，但极其不可靠。很多时候很难完整的回退到你需要的版本，当然这个问题可以使用git来轻松解决，对于程序员是再熟悉不过了。但对于一些不是cs专业的可能会比较陌生，就会踩坑。不过我觉得后续agent应该都会加入git管理的方式，github也早已推出了自己的CLI工具。
2. 长时记忆缺失与管理方式：对话一多，Agent 就容易丢失上下文记忆。虽然说最好不要在一个对话里完成过多任务，但有时候已经对话了这么多轮，如果再转移到新的对话上去，我觉得现在agent好像都没提供特别好的解决方案，似乎又只能重新开始（也可能是我还没找到）。并且由于记忆问题，就导致AI很喜欢打补丁，你提出了这个问题它只是针对这个小问题进行修改，换个场景下可能又出现了bug。就是它在修改代码时，往往不顾及上下文的连贯性，更不会做架构级的更新。
3. 简单问题复杂化与Review难题：Agent有时候在技术路线不明晰，没有足够约束的情况下，会将一些简单问题处理的很复杂，就容易添加很多行代码，会逐渐成长为屎山代码，重构越来越麻烦，也很难review。对于一些编程经验较少的人，这个问题尤为严重，很难去判别哪些代码是不必要的。而且我个人使用过程中，我会感觉好像agent一生成代码就很大一长串，代码量一多再加上一些封装，就会使得它很难去review，而且代码不是自己写的，debug也比较麻烦。当然不否认AI在大部分情况下写的代码要比很多人要规范，但也会有疏漏的时候，这个疏漏就恰恰会带来很多的非必要成本。我觉得在以后，AI写代码复杂化这点肯定是能够解决的，但关于review这点我会很困惑，虽然说AI也能够去debug和review，但要怎么控制安全边界呢

一些感悟与尝试

最近Claude源码泄露，我就发现其实里面有很多关于Prompt的东西，为Agent提供了行为指导，这些都是提前注入式的，包括前阵子爆火的小龙虾，里面也有很多的Prompt，又阅读了一些推文，结合最近自己所遇到的问题，加上又正在做个人网站的项目，就做了一些尝试。开始构建相关的工作流

首先，我让 AI 扫描整个项目的核心代码，强制它输出一份《全局架构文档》。以前我觉得每次让 AI 读全量代码太费 Token，现在我就倾向于让AI先读架构文档，在架构文档足够清晰的情况下，能解决不少问题，AI在更改时也会考虑架构内容。

我甚至给 AI 写了一套类似模板的约束规则：

• 每次更新代码前：必须先阅读并更新架构文档，在架构文档不清楚的情况下，再去阅读项目里相关代码并且更新加偶文档。
• 禁止无脑打补丁：遇到问题多从架构层面思考重构，而不是针对某一功能打补丁。补丁打多了牵一发而动全身，不如一开始就在架构层解决。
• 操作规范：加新功能时，必须按照我给定的模板填写范围、约束、验收标准，并记录日志。

然后关于架构审查、定义新功能、Review等等都可以有对应的子Prompt，然后这些子Prompt可以形成一个完整的工作流，把这套流程注入到对话最开始。这样AI在更新代码过程中，不光会更新架构，还会记录更新，写日志，结构验证等等，这样AI每次动作都有迹可循，能够更好的进行Vibe code，虽然读取文档感觉多了，但token消耗会少不少，AI能更有针对性的找代码进行操作，代码更新也更有效率，bug会少很多，并且减少重复工作等。我在个人网站的实践中，也很明显的体会到了这一点，加入架构文档后真的基本上没出过Bug，最多只是修复无效。通过这种方式我觉得其实相当于把一些和agent对话过程以及更改记录下来，形成本地的记忆，然后就可以比较方便的切换新对话，甚至agent，让它具有可迁移性。把项目相关的内容交由项目，而不是某个AI本身，AI只是工具。

架构：AI 时代的核心竞争力

在实践的过程中我觉得只要需求输入得当，规范文档设置好，AI 在具体代码的理解和实现上已经遥遥领先了。但是，AI 目前依然设计不好系统架构。经常有的时候看起来挺合理的，尤其是对于非专业人士，但实际执行过程中会遇到很多问题，或许随着agent能力的提升，这个问题也会得到改善吧

之前也不会去否认架构的重要性，但经常架构是会有专门的人去考虑，不是每个人都要做的。但现在agent能让我们每个人都有独立推进项目的能力，但是我们却不一定有着相应的架构思维或能力。

架构代表着高内聚、松耦合的系统性思考，它需要经验、判断力和全局视野。一个架构混乱的项目，AI 只会越帮越忙，加速其屎山化；而一个架构清晰、模块化的项目，AI 能够如虎添翼。我觉得架构会决定一个idea能否真正落地，以及落地过程中的难易程度。

我觉得工科专业要积极拥抱AI，未来核心工程师的价值，正在从纯手工实现功能变到设计出能让 AI 高效工作的系统，让AI辅助有效完成工作。系统设计、模块化封装、可扩展性……这些内容在 AI 时代不但没有贬值，反而变得比以前更有价值了。我们也应当去培养这方面的能力，让AI辅助你完成一个idea落地，只有在真正执行过程中，才能去有一些不一样的经历，这是看多少篇教程、推文都带不来的东西。

让想法先行

目前这种想法我觉得应该是很多大厂已经采用了，我只是最近才突然悟到，但我觉得这个悟的过程很重要，因此写下此篇Blog记录自己的一些心得体会。

目前这套 Prompt 玩法还比较初级。未来如果涉足机器人开发或嵌入式系统，针对不同的工具链，肯定还需要制定专门的 Prompt 规范。如果是一个从 0 到 1 的全新 Idea，系统级提示词又该怎么写？这都是需要持续验证的。

最近我也在考虑搭建本地的大模型知识库（Wiki），把这些经验内化。下一步，我打算带着这套 Vibe Coding 的经验，去尝试一些机械、机器人相关的软硬件结合项目。

此外，还有一些让我比较困惑的点，AI时代我们要如何去学习？该学习到什么程度？又该怎么从使用AI过程中学习？

最后我觉得这个时代，有更多的机会去实现自己的想法了，完成大于完美，不要让想法只停留在脑海。毕竟，写代码的门槛被 AI 大大降低，现在真正稀缺的，是那些疯狂而又严谨的 Idea。