文章总结： 文章分享AI编程与Agent开发实战经验。建议将AI视为同事，先讨论需求形成文档锚点，配置全局安全规则，精准提问并及时纠正跑偏。Agent开发中面对语义级失败应反馈错误供LLM重试，针对钟摆现象、方向偏离和上下文爆炸三种失败模式，提出了检测重复、设置检查点及压缩上下文等具体解法。 综合评分： 86 文章分类： 实战经验,AI安全,安全开发

从Vibe Coding到Agent开发：和AI协作的经验分享

原创

Purpleroc Purpleroc

Purpleroc的札记

2026年3月16日 20:59 广东

#

用了那么久的AI编程，我最大的感悟是：别把它当工具，要把它当同事。 一个能写代码、能排查问题、能帮你分析数据的同事。但和真实同事一样，你得学会怎么跟它沟通、怎么管理它、怎么在它跑偏的时候及时拽回来。这篇文章，聊聊我在Vibe Coding和Agent开发中积累的一些经验，希望对你有用。

一、Vibe Coding：让AI真正成为你的”编码搭子”

我的主力编码工具是Cursor，但下面这些方法应该是相通的——不管你用的是Cursor、Claude Code还是其他工具，本质上它们都是一个完善的Agent了。

1. 先聊需求，再动手

很多人拿到需求就直接让AI开写，这其实很容易跑偏，进而得到一个不太符合你需求的项目。

我的做法是：在项目开始前，先粗略描述需求，和它讨论。 让它站在产品、开发、用户、架构等不同角色的视角，帮我拆解、分析，发现我没考虑到的点、潜在的问题，以及可行的解决方案。

这里有个原则——不能只发现问题不给方案。

讨论完之后，让它把结果整理成一份开发需求文档。后续这个系统所有的开发、修改、优化，都从这份需求文档开始。这样做的好处是：每次对话都有一个”锚点”，AI不会偏离太远。

2. 把”每次都要嘱咐的话”变成规则

有些事情你每次对话都要交代一遍，比如”SQL要用参数化查询”、”代码里不能硬编码密钥”、”改完代码要更新文档”。说多了烦，不说又怕它忘。

解决方案很简单：写成内置规则。

比如我在Cursor中配置了几条用户级规则：

编码安全规则——SQL必须参数化、命令执行必须参数化、URL必须白名单校验、禁止硬编码密钥……这些安全底线，每次对话自动加载，不用重复叮嘱。

文档更新规则——开发完成后必须更新项目文档，只记录业务逻辑相关的内容，不记流水账。

需求确认规则——动手之前先确认自己理解了需求，有疑问先问，别闷头就干。

一次配置，永久生效。把你的编码规范、安全要求、协作习惯都沉淀下来，这才是效率最大化。

3. 选中代码片段，精准提问

这一条是我在改bug和调试过程中发现的。

当你发现某段逻辑有问题、某个运行日志符合预期的时候，直接选中那段代码再提问，比在对话框里描述”第几行到第几行那个函数好像有问题”要快得多、准得多。选日志的话，最好再AT对应的逻辑的文件。

AI的注意力是有限的，你帮它缩小范围，它就能给你更精准的答案。

4. 发现跑偏，立刻打断

AI有时候会沿着自己的理解越走越远，等你发现的时候，它可能已经改了十几个文件了。及时停下来，明确告诉它你的意图和它理解的差异在哪。

不要心疼已经生成的内容，方向错了，走得越远代价越大。

5. 让它自己去发现问题

这是我最近越来越多在做的事情。

比如某天告警量突然飙高，我不自己去翻日志，而是直接跟它说：

“昨天推送到群里的告警量有点大，你看下是不是每一条都是必须推送的？推送的信息中，有多少是真实值得关注的？针对这个问题，需要怎么优化现在的告警逻辑？”

然后它自己去接入数据，统计、分析、发现问题、给出方案。

把它从”执行者”升级为”分析者”，你会发现它能做的事情远超预期。

此外，让它摸一摸数据，可能能更好的给你一些解决方案。

二、Agent开发：当AI任务失败了，怎么办？

Agent开发和传统开发最大的不同在于：失败往往是语义级别的。 没有报错、没有crash，程序跑得好好的，但任务就是完不成。

这里有一个核心思路：当LLM调用工具失败时，不要直接抛出异常结束任务，而是把失败信息返回给LLM，让它思考下一次应该用什么参数、什么方法来重试。给它纠错的机会，而不是一棍子打死。

以下是我看到的和遇到过的一些Agent失败模式：

模式一：左右摇摆，陷入死循环

我把它叫做”钟摆现象”。

最典型的场景是自动纠错：比如我在做规则自动生成的时候，AI把good case覆盖好了，去处理bad case；bad case处理完，又把good case搞坏了。来来回回，对话记录里全是——

“因为A，所以改成B” “因为B，所以改回A” “因为A，所以改成B” ……

还有一种变体：AI换着关键词去查数据，但忘了上次用过什么关键词，导致不断重复无效尝试。

识别特征： 重复调用相同工具、相似参数。

解法： 记录工具调用历史，增加代码级的重复检测逻辑。当检测到循环模式时，主动中断并提示。

模式二：方向偏离，越走越歪

这应该是最常见的问题了。信息在传播过程中总是会失真，人和人交流都有理解偏差，何况是LLM理解你的自然语言描述。

通常表现为：前几步就理解错了，后面全链路跟着歪。

解法： 除了在任务描述中尽量明确需求外，还需要设置阶段性检查点——每执行几步，让LLM自行总结执行历史，对照最初目标，检查是否有偏移。发现偏了就及时纠正，别等到最后才发现全白干了。

模式三：上下文爆炸，注意力涣散

长任务的天敌。

执行步骤一多，上下文数据越积越多，LLM的注意力被稀释，无法聚焦在当前任务上，甚至直接因为上下文超长导致调用失败。

解法有两个：

第一，按需披露。 信息不要一股脑全塞进去，用到的时候再查询、再加载，减少干扰。这也是”渐进式披露”的思路。

第二，定期压缩。 阶段性地做信息摘要，只保留关键数据和结论，丢掉中间过程的细节。别让上下文变成一个只增不减的垃圾堆。

当然，一定要设置最大步骤数。 不能让Agent无止境地运行下去，现阶段token还是要花钱的。

好了，就写到这吧，希望对你有用～

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Purpleroc的札记 Purpleroc Purpleroc《从Vibe Coding到Agent开发：和AI协作的经验分享》