1. Vibe Coding不是让AI写代码是在和需求反复博弈先说个大家可能都有的经历拿到Cursor第一周感觉很爽让它生成个函数、写个页面几乎都是秒出。但两周之后项目越做越乱AI生成的代码散落各处函数之间到处打架改一个地方崩三处。最后你不得不承认Vibe Coding这件事看似在写代码其实是在管理AI的行为边界。我最初对Vibe Coding的理解也有偏差以为就是把需求扔给AI然后喝着咖啡等结果。真正把几个项目完整跑下来之后才发现Vibe Coding的核心从来不是生成代码这个动作而是如何在充满随机性的AI输出中建立可控的交付链路。这个事情做好了AI是你的超级外挂做不好AI就是代码垃圾的生产机器。这个训练营标题里的几个关键词——Cursor、SDD方法论、Claude Code、多Agent协作拆开来看其实是Vibe Coding落地的四层递进关系层级工具解决的核心问题交互层Cursor让AI理解项目上下文产出符合预期的代码方法论层SDD把模糊需求变成AI能执行的结构化任务执行层Claude Code在独立环境中批量处理工程级改动协同层多Agent让多个AI角色分工协作互相校验我这里想强调的是这四个层次不是并列关系而是严格的上下游关系。你可以在任何一个环节做得很好但只要某个环节断裂整体项目质量就会崩盘。我见过有人在Cursor里把提示词写得天花乱坠但项目结构本身一团糟AI再聪明也无从下手也见过有人SDD文档写得非常规范但执行时仍然依赖单线程对话一个Agent从头写到尾最后代码风格混乱、职责边界模糊。所以这篇博文我会从自己跑通的全栈项目出发把这条链路里最关键的方法、工具使用细节、以及踩过的坑一层层剥开讲清楚。2. Cursor驾驭的核心不是提示词是上下文工程2.1 先搞明白Cursor到底在做什么很多人对Cursor的理解停留在“带AI的编辑器”这个理解不能说错但远远不够。你如果只是把它当成一个自动补全工具那它的价值只发挥了两成。Cursor真正的特殊之处在于它把所有项目文件都变成了AI的“可感知记忆”。你选中一个函数它能看相关的文件你提到某个配置项它可以自动定位到项目里对应的位置。这意味着什么意味着Cursor的输入质量取决于你给AI喂的上下文结构而不是提示词的长度。我发现一个很有意思的规律80%的Cursor使用问题出在项目上下文混乱只有20%出在提示词本身。具体来说当我用一个结构清晰、命名规范、文件分工合理的前端项目时即使提示词写得马虎一点Curor生成的结果也有七八成能用反过来如果项目文件扁平堆砌、命名一半中文一半拼音、没有合理的分层那提示词写得再精细AI输出的东西也经常“牛头不对马嘴”。2.2 规则文件是你和AI的一纸约定我第一次用Cursor的时候没有写过任何规则文件。结果最典型的问题就是光标在哪个文件AI就默认在哪个文件里加代码。你在App.tsx里让它写登录逻辑它顺手把组件、接口、类型定义全部塞进去你在路由文件里问它要不要加一个页面它直接就把页面组件也生成了硬塞进路由文件里。这个问题的根源在于AI每轮对话只能看到有限的上下文它没有能力跳出当前文件去判断这个功能应该放在哪个目录、用哪种模式、遵循什么命名方式。这时候规则文件就是你和AI之间的“合约”。我现在的做法是在每个项目的根目录维护一个.cursor/rules/global.mdc文件内容大致包括这几块项目技术栈和架构模式比如前端是 React TypeScript Vite后端是 Node.js Fastify目录结构约定组件放哪、接口放哪、类型定义放哪、工具函数放哪命名规范组件用PascalCase工具函数用camelCase样式文件用kebab-case禁止事项不允许在组件文件里写API调用不允许复制粘贴重复代码等等这里我想重点说明一下规则文件的本质是在降低AI的决策熵。AI每次生成代码时其实都在做“下一步该写什么”的判断。如果你提供的约束足够清楚它的判断空间就大幅缩小输出自然更稳定。反过来如果约束太少AI的创造力就变成了一把双刃剑。举个具体例子。我的规则文件里有一条所有后端接口错误必须返回统一格式的错误对象{ code, message, details }。前期没写这条规则的时候AI生成的错误处理五花八门有的返回字符串有的抛异常有的吞掉错误返回null。后来我加上这条规则再去让AI写接口生成的结构基本保持一致。这就是约束带来的收益。2.3 小心上下文窗口的“隐形天花板”很多人用Cursor遇到一个问题对话聊久了AI开始“遗忘”前面交代过的事情。你明明第二十轮说过“用户头像要支持裁剪”第五十轮生成的时候它却完全不记得了。这不是AI变傻了而是上下文窗口被无关内容撑满了。以主流模型为例超大上下文虽然看起来能容纳很多内容但实际使用时模型的注意力会倾向于中段和尾部早期内容很容易被“稀释”。而且上下文里的token是有限的你前面贴了大段的报错日志、复制了一堆无关代码那么关键的项目约定就被挤出了有效区域。我的经验是每个独立的开发任务最多对话控制在几轮内完成超过就开启新对话并且先把规则文件、关键文件路径、需要实现的功能说明重新喂一遍。这个方法听起来麻烦但实际测试下来输出质量比长对话稳定很多。另外还有一个小技巧在对话里尽量不要贴无关代码。比如你想让AI帮你排查一个报错只需要贴出报错堆栈、报错位置附近的代码片段、以及你尝试过什么方案而不要顺手把整个文件几千行都复制进去。你省的每一千个token都是留给关键需求的空间。2.4 Agent模式的使用边界Cursor的Agent模式是很强的功能它可以自主读取多个文件、修改多处代码、运行命令、处理报错基本就是一个“有手”的AI。但强大的能力也意味着更大的失控风险尤其是当你对它说“帮我实现一个XX功能”的时候它可能会自作主张地改掉你不希望动的文件。我用Agent模式有个明确边界只让它做局部重构和机械性改动不让它做架构级决策。比如对接一个接口我可以让Agent跑一遍修改类型定义、接口请求封装、页面调用这几层但涉及到“这个路由应该怎么设计”“这个状态该放全局还是局部”我绝不会交给Agent判断而是先在文档里自己定义好再让Agent去执行。这一点在后面讲SDD时会进一步展开本质上就是Agent负责的是执行可信的执行它不应该被授权去做带有决策风险的判断。3. SDD里的“约束前置”先写清规则再让AI动手3.1 为什么说SDD救了我SDD的全称是Specification-Driven Development翻译过来就是“规格驱动开发”核心思想非常简单在写代码之前先写清楚这次改动要做什么、不做什么、怎么验收。我一开始觉得这套理论很虚开发嘛需求拆一下不就行了。直到有一次做一个带会员体系的电商项目需求经过好几轮确认但每次让AI生成代码都走样——它不是功能不完整而是实现方式和产品预期差得远。比如需求里说“会员积分在订单完成后发放”AI理解成了“下单时预估积分但先不发放”从代码逻辑上看它也不算错但产品验收时就是要返工。后来我才意识到问题出在“需求文档”到“AI可执行的规格”之间存在巨大的鸿沟。需求文档是给人看的里面有各种默认前提和行业常识而AI执行时它只能基于你提供的明确文字做推断一旦你没写清楚它就按照自己的“常识”来补全。这个“补全”往往就是灾难的开始。3.2 单文件输入上下文最容易被忽略的硬约束这里我要分享一个非常重要的踩坑经历。我做过一个模拟项目X需要在已有的大规模代码库里新增一个功能模块。初期我用Claude Code在终端里指定要改的目录然后让它“实现新模块”。结果它每次生成的代码要么和项目里已有的工具函数重名要么引用了不存在的依赖总之就是“看起来没问题一跑就报错”。排查了很久我发现根因在于Claude Code在终端模式下虽然能看到你指定的目录但项目的其他部分它并不可见。它的上下文建立是依靠代码库扫描机制当项目规模大、文件多的时候扫描结果不一定完整覆盖到你那个模块依赖的所有公共代码。这导致它经常在一个“信息不到位的环境”里强行生成代码自然就容易“闭门造车”。解决这个问题的关键就是SDD里的一个约束单文件输入上下文。我采用的实践是将任务粒度拆小每次只让AI修改一个文件并且把该文件依赖的其他函数、类型定义、公共组件的关键签名贴在提示词里。把项目的目录结构、核心模块说明、已有公共方法清单写入一个专门的项目上下文文件在任务开始前让它先读一遍。严格要求AI不新建依赖所有引用的函数必须是在已有代码中确认存在的东西如果确实要新增公共方法必须先单独立项等公共层代码稳定后再让业务层引用。这套约束看起来让流程变重了但实际效果立竿见影。代码生成的一次通过率大幅提升不再是“AI编一个、我改十个”的状态。3.3 把SDD文档写成AI能执行的“规格清单”很多人的SDD文档之所以没用是因为他们写得太像“产品需求文档”了。满篇都是“系统应该提供流畅的用户体验”“页面应该美观大方”这种东西给AI看了等于废话。真正对AI有效的规格清单必须是离散的、可验收的、无歧义的。我习惯把每个任务拆成一张规格清单包含以下几个字段任务名称一句话说明要做什么输入数据明确的数据来源、数据结构、字段类型输出结果期望的函数签名、组件props、接口返回格式约束条件不许动哪些文件、不许改哪些接口、必须遵循哪种代码模式验收标准怎样算完成比如“调用后返回正确状态码”、“边界值测试通过”举个例子。如果我要实现一个“订单超时自动关闭”的任务规格清单不会写“系统应在超时后自动关闭订单”而会写任务名称订单超时自动关闭定时任务 输入数据orders表包含create_time、status字段status有效值为PENDING/PAID/CLOSED 输出结果新增一个定时任务函数 checkTimeoutOrders每5分钟扫描一次将超时30分钟且statusPENDING的订单更新为CLOSED 约束条件不动订单创建流程不引入新的任务调度框架复用项目已有的cron工具 验收标准构造一条超时订单数据运行任务执行后status从PENDING变为CLOSED未超时订单不受影响这样写AI没有任何自由发挥的空间每一步都是确定的。而在我看来SDD的价值不在于约束AI的“自由”而在于把模糊的人意翻译成机器可执行的确定性。AI不是不需要想象力而是它在执行层面的想象力应该被严格限制在一个牢固的框架里。3.4 FIC为什么AI必须永远说真话SDD流程里还涉及一个模型能力上的硬性要求叫Faithful In Context直译就是“对上下文的忠实”。这个概念听起来有点学术但你把它放到实践中就非常好理解AI在生成代码时必须基于你提供的真实上下文而不能胡编乱造不存在的函数、接口和文件。我用Claude Code时的体会非常深它有时会“装懂”在代码里引用一个看起来合理的函数名但这个函数根本不存在。它之所以这么做是因为模型生成时的目标是“输出的内容在统计上符合预期”而不是“输出的内容经得起代码编译检验”。如果上下文不够充分它就会用“最可能的猜测”来填补空白。FIC越强的模型和工具越能明确区分“这是我从上下文里读到的”和“这是我推测的”。这也是为什么在AI编程工具选型时不能只看生成速度还要观察它在信息不足时的表现。我测试过的几个模型里Claude在上下文忠实性上明显更好尤其是在大批量代码库上它扫描项目结构的能力更强生成代码时更少出现“装懂”的情况。另外设置合适的上下文参数也很关键这个下节细说。4. 项目做一半失控了一次完整的多Agent排查复盘4.1 从正常到失控问题是怎么积累的前面讲的理论再多都不如实实在在走一遍弯路来得深刻。我接下来要完整复盘一次项目失控和回归正常的过程这里面的细节我觉得比很多教程文档都有价值。当时我在做一个模拟的跨平台数据同步系统架构是一个Node后端一个Web前端一个通用的定时任务模块另外还接了一个外部接口做数据校验。项目的规模不算特别大但涉及的文件分散在前端、后端、任务三个目录里。由于需求一直在调整我连续几周都用“对话式”的方式让AI帮改代码今天在这个文件加个字段明天在那个文件调整一下逻辑。转折点出现在一次“大改”之后我让Claude Code一次性调整多个文件的接口参数它执行得很顺利测试也能通过。但过了两天我才发现有几个老接口的文件已经被它改得面目全非而它只是在对应的调用方做了适配根本没有动公共定义。也就是说它没有选择“让所有调用方统一走新接口”而是选择“改一部分另一部分打补丁”结果整个系统的接口风格变得支离破碎。4.2 失控的三种典型症候如果你发现自己也陷入了类似的状态通常会有以下三个典型症候症候一AI生成代码的“局部正确、整体错误”。表面上看每个文件单独跑都是对的但把它们串起来数据流却是断的。原因就是每次对话的上下文窗口有限AI无法完整掌握全局。症候二同一个功能出现多套实现风格。前端组件有的用函数式组件有的用类组件虽然很快被改掉但痕迹很明显后端接口有的返回{ data: ... }有的直接返回裸数据。这就是缺少全局约束的后果。症候三AI开始“复读机式”地修改同一处代码。你今天让它修一个bug它在A文件里改了一版过两天同类bug又出现它又在B文件里写了一段逻辑相近但风格不同的代码。这时候你就该意识到项目已经没有统一的规格约束了。4.3 我是怎么一步步把项目拉回正轨的发现失控后我没有立刻开始“补代码”而是先把AI工具全部停掉回到“人类模式”做了一次全局梳理。这次梳理花了我大概一整天但事后证明非常值。梳理的内容其实不复杂就三件事把项目中所有公共模块、公共类型定义、接口定义列一个清单标注状态稳定、待改、废弃。把最近一周所有AI改动过的文件列一个清单标注改动目的。把项目根目录的规则文件重新整理明确命名规范、目录职责、禁止事项并把这次梳理的结果回填进规则文件。这一步做好之后我才重新启动Claude Code并且把规则文件内容、项目结构清单、本次要修改的任务规格一起写在提示词里。你猜怎么着同样的需求AI这次生成的代码风格和结构完全对得上。不是AI变聪明了而是它终于“看得到”全局了。这个案例我反复拿出来讲是因为它特别能说明Vibe Coding的一个核心原则AI的输出质量不是由模型的智商单独决定的而是由你提供的上下文的完整度决定的。项目失控表面看是AI乱写代码实质是你的工程约束缺失了。5. Claude Code接管收尾让多Agent各司其职5.1 三个工具的真正分工在把这些工具都用过一轮之后我发现最容易出效果的组合方式是Cursor做早期探索和原型验证SDD做任务约束Claude Code做收尾执行。这里我想稍微展开一下它们之间的关系。Claude Code适合干重活它能在终端里真实读取项目文件、执行测试、运行命令像一个能自己动手改代码的AI主力。如果你的SDD规格写得清楚把任务交给它执行成功率很高。Cursor更适合作实时编码在编辑器里逐行修改、补全代码、做局部的代码洞察时Cursor的体验是最好的。多Agent的价值在并行验证比如你可以让一个Agent在不改动代码的情况下通读注释尝试发现注释是否符合SDD要求、是否存在不一致的地方同时让另一个Agent去检查新生成的代码结构。5.2 多Agent协作时的高效通信方法论多Agent协作最大的难点不是每个Agent不会干活而是它们之间缺少统一的“工作语言”。如果你让Agent A和Agent B分别处理同一项目的两个模块它们各自的产出结果很可能在接口对接时对不上。怎么解决我的做法是引入一个中间层专门做Agent任务分配和结果汇总。这个中间层可以是人即你自己也可以是一个消息推送脚本。具体来说我在项目根目录建了一个AGENT_TASKS.md文件里面记录当前所有Agent的待办、进行中、已完成状态以及每个Agent产出的关键文件路径。这样每个Agent在启动任务前都可以快速扫一眼这个文件了解自己在整个项目中的位置。这样做的好处还在于如果你中途需要人工介入修改某个Agent的产出你可以在AGENT_TASKS.md里标记“此模块已有人类修正其他Agent请勿覆盖”避免多个Agent互相踩踏。5.3 用Agent通信文件避免那种“左耳进右耳出”的尴尬有一次我同时开了两个Agent一个负责调整后端数据校验逻辑一个负责更新前端展示层。它们各自干得热火朝天但最后前端对接时接口文档完全对不上。后来我排查原因两个Agent的上下文是独立的它们根本不共享信息只能通过中间文件沟通。之后我就开始用“通信文件”的方式。具体做法是每次Agent完成任务后必须更新对应的接口说明文件写清楚“我改了什么、新增了什么、删除了什么”。另一个Agent在开发前必须先读接口说明文件中自己依赖的部分。如果发现不一致优先以接口说明文件为准而不是自行猜测。这样做之后多Agent协作时信息断层的概率大大降低。这里有一个关键点Agent和Agent之间沟通靠的不是自然语言对话而是共享的项目文件。你不需要让Agent之间能互相“说话”你只需要让它们能看到同一份“工作手记”。5.4 自动化命令与工作流的保存还有一个使用Claude Code时非常实用的小技巧把常用的工作流保存成可重复执行的命令。比如我有一段“检查代码是否违反SDD约束”的提示词每次开新对话都要手动写一遍后来我把这段提示词保存成一个脚本文件需要时一行命令就让它自动执行。这类“自动化命令星”其实就是你个人的最佳实践沉淀用得越多跑得越顺。6. 落盘在真实项目上的实践心得前面说的都是方法和工具如果你刚接触Vibe Coding可能会觉得“这么多环节我该从哪一步切入”。我把自己的上手路径再总结一下希望能给你一些参考。我建议的顺序是先拿一个小型项目或Demo练手跑通“需求→SDD→Cursor→Claude Code→验收”的完整闭环再放大到复杂项目。很多人的问题在于一开始就在大项目里用AI结果环境太复杂、上下文管不住最后得出“AI编程不靠谱”的结论。其实不是AI不靠谱是你还没学会给AI搭“护栏”。另外我还想补充一点Vibe Coding再“Vibe”工程底线不能丢。比如Git提交信息不要随手让AI写一堆“fix stuff”而要明确提交目的再比如测试不能省至少核心流程要有人工验收。AI能帮你把代码写出来但不能替你做“代码审查”而审查机制恰恰是项目质量的最后一道防线。我也遇到过很多开发者纠结“要不要买训练营课程”的问题。我的看法是这种课程的核心价值不一定在于教一个工具而在于帮你少走弯路。因为Bia Coding这个领域教程文档散落且更新极快自己摸索的成本非常高。如果有机会看到别人的完整案例和踩坑复盘其实是花小钱买时间。这话不是建议只是我自己的体会。如果你正准备开始一个需要使用AI辅助开发的项目我强烈建议你在项目开始的第一天就建立规则文件和SDD日常维护流程而不是等项目失控之后再来补救。因为重建稳定的代价永远是维护的许多倍。希望这篇复盘对你有一些帮助。如果你也在用这些工具做项目欢迎和我交流你的踩坑经历尤其是关于Agent协作和上下文管理方面的坑我最近正在整理一个“AI编程项目失控预警清单”到时候整理完了再来分享。
1. Vibe Coding不是让AI写代码是在和需求反复博弈先说个大家可能都有的经历拿到Cursor第一周感觉很爽让它生成个函数、写个页面几乎都是秒出。但两周之后项目越做越乱AI生成的代码散落各处函数之间到处打架改一个地方崩三处。最后你不得不承认Vibe Coding这件事看似在写代码其实是在管理AI的行为边界。我最初对Vibe Coding的理解也有偏差以为就是把需求扔给AI然后喝着咖啡等结果。真正把几个项目完整跑下来之后才发现Vibe Coding的核心从来不是生成代码这个动作而是如何在充满随机性的AI输出中建立可控的交付链路。这个事情做好了AI是你的超级外挂做不好AI就是代码垃圾的生产机器。这个训练营标题里的几个关键词——Cursor、SDD方法论、Claude Code、多Agent协作拆开来看其实是Vibe Coding落地的四层递进关系层级工具解决的核心问题交互层Cursor让AI理解项目上下文产出符合预期的代码方法论层SDD把模糊需求变成AI能执行的结构化任务执行层Claude Code在独立环境中批量处理工程级改动协同层多Agent让多个AI角色分工协作互相校验我这里想强调的是这四个层次不是并列关系而是严格的上下游关系。你可以在任何一个环节做得很好但只要某个环节断裂整体项目质量就会崩盘。我见过有人在Cursor里把提示词写得天花乱坠但项目结构本身一团糟AI再聪明也无从下手也见过有人SDD文档写得非常规范但执行时仍然依赖单线程对话一个Agent从头写到尾最后代码风格混乱、职责边界模糊。所以这篇博文我会从自己跑通的全栈项目出发把这条链路里最关键的方法、工具使用细节、以及踩过的坑一层层剥开讲清楚。2. Cursor驾驭的核心不是提示词是上下文工程2.1 先搞明白Cursor到底在做什么很多人对Cursor的理解停留在“带AI的编辑器”这个理解不能说错但远远不够。你如果只是把它当成一个自动补全工具那它的价值只发挥了两成。Cursor真正的特殊之处在于它把所有项目文件都变成了AI的“可感知记忆”。你选中一个函数它能看相关的文件你提到某个配置项它可以自动定位到项目里对应的位置。这意味着什么意味着Cursor的输入质量取决于你给AI喂的上下文结构而不是提示词的长度。我发现一个很有意思的规律80%的Cursor使用问题出在项目上下文混乱只有20%出在提示词本身。具体来说当我用一个结构清晰、命名规范、文件分工合理的前端项目时即使提示词写得马虎一点Curor生成的结果也有七八成能用反过来如果项目文件扁平堆砌、命名一半中文一半拼音、没有合理的分层那提示词写得再精细AI输出的东西也经常“牛头不对马嘴”。2.2 规则文件是你和AI的一纸约定我第一次用Cursor的时候没有写过任何规则文件。结果最典型的问题就是光标在哪个文件AI就默认在哪个文件里加代码。你在App.tsx里让它写登录逻辑它顺手把组件、接口、类型定义全部塞进去你在路由文件里问它要不要加一个页面它直接就把页面组件也生成了硬塞进路由文件里。这个问题的根源在于AI每轮对话只能看到有限的上下文它没有能力跳出当前文件去判断这个功能应该放在哪个目录、用哪种模式、遵循什么命名方式。这时候规则文件就是你和AI之间的“合约”。我现在的做法是在每个项目的根目录维护一个.cursor/rules/global.mdc文件内容大致包括这几块项目技术栈和架构模式比如前端是 React TypeScript Vite后端是 Node.js Fastify目录结构约定组件放哪、接口放哪、类型定义放哪、工具函数放哪命名规范组件用PascalCase工具函数用camelCase样式文件用kebab-case禁止事项不允许在组件文件里写API调用不允许复制粘贴重复代码等等这里我想重点说明一下规则文件的本质是在降低AI的决策熵。AI每次生成代码时其实都在做“下一步该写什么”的判断。如果你提供的约束足够清楚它的判断空间就大幅缩小输出自然更稳定。反过来如果约束太少AI的创造力就变成了一把双刃剑。举个具体例子。我的规则文件里有一条所有后端接口错误必须返回统一格式的错误对象{ code, message, details }。前期没写这条规则的时候AI生成的错误处理五花八门有的返回字符串有的抛异常有的吞掉错误返回null。后来我加上这条规则再去让AI写接口生成的结构基本保持一致。这就是约束带来的收益。2.3 小心上下文窗口的“隐形天花板”很多人用Cursor遇到一个问题对话聊久了AI开始“遗忘”前面交代过的事情。你明明第二十轮说过“用户头像要支持裁剪”第五十轮生成的时候它却完全不记得了。这不是AI变傻了而是上下文窗口被无关内容撑满了。以主流模型为例超大上下文虽然看起来能容纳很多内容但实际使用时模型的注意力会倾向于中段和尾部早期内容很容易被“稀释”。而且上下文里的token是有限的你前面贴了大段的报错日志、复制了一堆无关代码那么关键的项目约定就被挤出了有效区域。我的经验是每个独立的开发任务最多对话控制在几轮内完成超过就开启新对话并且先把规则文件、关键文件路径、需要实现的功能说明重新喂一遍。这个方法听起来麻烦但实际测试下来输出质量比长对话稳定很多。另外还有一个小技巧在对话里尽量不要贴无关代码。比如你想让AI帮你排查一个报错只需要贴出报错堆栈、报错位置附近的代码片段、以及你尝试过什么方案而不要顺手把整个文件几千行都复制进去。你省的每一千个token都是留给关键需求的空间。2.4 Agent模式的使用边界Cursor的Agent模式是很强的功能它可以自主读取多个文件、修改多处代码、运行命令、处理报错基本就是一个“有手”的AI。但强大的能力也意味着更大的失控风险尤其是当你对它说“帮我实现一个XX功能”的时候它可能会自作主张地改掉你不希望动的文件。我用Agent模式有个明确边界只让它做局部重构和机械性改动不让它做架构级决策。比如对接一个接口我可以让Agent跑一遍修改类型定义、接口请求封装、页面调用这几层但涉及到“这个路由应该怎么设计”“这个状态该放全局还是局部”我绝不会交给Agent判断而是先在文档里自己定义好再让Agent去执行。这一点在后面讲SDD时会进一步展开本质上就是Agent负责的是执行可信的执行它不应该被授权去做带有决策风险的判断。3. SDD里的“约束前置”先写清规则再让AI动手3.1 为什么说SDD救了我SDD的全称是Specification-Driven Development翻译过来就是“规格驱动开发”核心思想非常简单在写代码之前先写清楚这次改动要做什么、不做什么、怎么验收。我一开始觉得这套理论很虚开发嘛需求拆一下不就行了。直到有一次做一个带会员体系的电商项目需求经过好几轮确认但每次让AI生成代码都走样——它不是功能不完整而是实现方式和产品预期差得远。比如需求里说“会员积分在订单完成后发放”AI理解成了“下单时预估积分但先不发放”从代码逻辑上看它也不算错但产品验收时就是要返工。后来我才意识到问题出在“需求文档”到“AI可执行的规格”之间存在巨大的鸿沟。需求文档是给人看的里面有各种默认前提和行业常识而AI执行时它只能基于你提供的明确文字做推断一旦你没写清楚它就按照自己的“常识”来补全。这个“补全”往往就是灾难的开始。3.2 单文件输入上下文最容易被忽略的硬约束这里我要分享一个非常重要的踩坑经历。我做过一个模拟项目X需要在已有的大规模代码库里新增一个功能模块。初期我用Claude Code在终端里指定要改的目录然后让它“实现新模块”。结果它每次生成的代码要么和项目里已有的工具函数重名要么引用了不存在的依赖总之就是“看起来没问题一跑就报错”。排查了很久我发现根因在于Claude Code在终端模式下虽然能看到你指定的目录但项目的其他部分它并不可见。它的上下文建立是依靠代码库扫描机制当项目规模大、文件多的时候扫描结果不一定完整覆盖到你那个模块依赖的所有公共代码。这导致它经常在一个“信息不到位的环境”里强行生成代码自然就容易“闭门造车”。解决这个问题的关键就是SDD里的一个约束单文件输入上下文。我采用的实践是将任务粒度拆小每次只让AI修改一个文件并且把该文件依赖的其他函数、类型定义、公共组件的关键签名贴在提示词里。把项目的目录结构、核心模块说明、已有公共方法清单写入一个专门的项目上下文文件在任务开始前让它先读一遍。严格要求AI不新建依赖所有引用的函数必须是在已有代码中确认存在的东西如果确实要新增公共方法必须先单独立项等公共层代码稳定后再让业务层引用。这套约束看起来让流程变重了但实际效果立竿见影。代码生成的一次通过率大幅提升不再是“AI编一个、我改十个”的状态。3.3 把SDD文档写成AI能执行的“规格清单”很多人的SDD文档之所以没用是因为他们写得太像“产品需求文档”了。满篇都是“系统应该提供流畅的用户体验”“页面应该美观大方”这种东西给AI看了等于废话。真正对AI有效的规格清单必须是离散的、可验收的、无歧义的。我习惯把每个任务拆成一张规格清单包含以下几个字段任务名称一句话说明要做什么输入数据明确的数据来源、数据结构、字段类型输出结果期望的函数签名、组件props、接口返回格式约束条件不许动哪些文件、不许改哪些接口、必须遵循哪种代码模式验收标准怎样算完成比如“调用后返回正确状态码”、“边界值测试通过”举个例子。如果我要实现一个“订单超时自动关闭”的任务规格清单不会写“系统应在超时后自动关闭订单”而会写任务名称订单超时自动关闭定时任务 输入数据orders表包含create_time、status字段status有效值为PENDING/PAID/CLOSED 输出结果新增一个定时任务函数 checkTimeoutOrders每5分钟扫描一次将超时30分钟且statusPENDING的订单更新为CLOSED 约束条件不动订单创建流程不引入新的任务调度框架复用项目已有的cron工具 验收标准构造一条超时订单数据运行任务执行后status从PENDING变为CLOSED未超时订单不受影响这样写AI没有任何自由发挥的空间每一步都是确定的。而在我看来SDD的价值不在于约束AI的“自由”而在于把模糊的人意翻译成机器可执行的确定性。AI不是不需要想象力而是它在执行层面的想象力应该被严格限制在一个牢固的框架里。3.4 FIC为什么AI必须永远说真话SDD流程里还涉及一个模型能力上的硬性要求叫Faithful In Context直译就是“对上下文的忠实”。这个概念听起来有点学术但你把它放到实践中就非常好理解AI在生成代码时必须基于你提供的真实上下文而不能胡编乱造不存在的函数、接口和文件。我用Claude Code时的体会非常深它有时会“装懂”在代码里引用一个看起来合理的函数名但这个函数根本不存在。它之所以这么做是因为模型生成时的目标是“输出的内容在统计上符合预期”而不是“输出的内容经得起代码编译检验”。如果上下文不够充分它就会用“最可能的猜测”来填补空白。FIC越强的模型和工具越能明确区分“这是我从上下文里读到的”和“这是我推测的”。这也是为什么在AI编程工具选型时不能只看生成速度还要观察它在信息不足时的表现。我测试过的几个模型里Claude在上下文忠实性上明显更好尤其是在大批量代码库上它扫描项目结构的能力更强生成代码时更少出现“装懂”的情况。另外设置合适的上下文参数也很关键这个下节细说。4. 项目做一半失控了一次完整的多Agent排查复盘4.1 从正常到失控问题是怎么积累的前面讲的理论再多都不如实实在在走一遍弯路来得深刻。我接下来要完整复盘一次项目失控和回归正常的过程这里面的细节我觉得比很多教程文档都有价值。当时我在做一个模拟的跨平台数据同步系统架构是一个Node后端一个Web前端一个通用的定时任务模块另外还接了一个外部接口做数据校验。项目的规模不算特别大但涉及的文件分散在前端、后端、任务三个目录里。由于需求一直在调整我连续几周都用“对话式”的方式让AI帮改代码今天在这个文件加个字段明天在那个文件调整一下逻辑。转折点出现在一次“大改”之后我让Claude Code一次性调整多个文件的接口参数它执行得很顺利测试也能通过。但过了两天我才发现有几个老接口的文件已经被它改得面目全非而它只是在对应的调用方做了适配根本没有动公共定义。也就是说它没有选择“让所有调用方统一走新接口”而是选择“改一部分另一部分打补丁”结果整个系统的接口风格变得支离破碎。4.2 失控的三种典型症候如果你发现自己也陷入了类似的状态通常会有以下三个典型症候症候一AI生成代码的“局部正确、整体错误”。表面上看每个文件单独跑都是对的但把它们串起来数据流却是断的。原因就是每次对话的上下文窗口有限AI无法完整掌握全局。症候二同一个功能出现多套实现风格。前端组件有的用函数式组件有的用类组件虽然很快被改掉但痕迹很明显后端接口有的返回{ data: ... }有的直接返回裸数据。这就是缺少全局约束的后果。症候三AI开始“复读机式”地修改同一处代码。你今天让它修一个bug它在A文件里改了一版过两天同类bug又出现它又在B文件里写了一段逻辑相近但风格不同的代码。这时候你就该意识到项目已经没有统一的规格约束了。4.3 我是怎么一步步把项目拉回正轨的发现失控后我没有立刻开始“补代码”而是先把AI工具全部停掉回到“人类模式”做了一次全局梳理。这次梳理花了我大概一整天但事后证明非常值。梳理的内容其实不复杂就三件事把项目中所有公共模块、公共类型定义、接口定义列一个清单标注状态稳定、待改、废弃。把最近一周所有AI改动过的文件列一个清单标注改动目的。把项目根目录的规则文件重新整理明确命名规范、目录职责、禁止事项并把这次梳理的结果回填进规则文件。这一步做好之后我才重新启动Claude Code并且把规则文件内容、项目结构清单、本次要修改的任务规格一起写在提示词里。你猜怎么着同样的需求AI这次生成的代码风格和结构完全对得上。不是AI变聪明了而是它终于“看得到”全局了。这个案例我反复拿出来讲是因为它特别能说明Vibe Coding的一个核心原则AI的输出质量不是由模型的智商单独决定的而是由你提供的上下文的完整度决定的。项目失控表面看是AI乱写代码实质是你的工程约束缺失了。5. Claude Code接管收尾让多Agent各司其职5.1 三个工具的真正分工在把这些工具都用过一轮之后我发现最容易出效果的组合方式是Cursor做早期探索和原型验证SDD做任务约束Claude Code做收尾执行。这里我想稍微展开一下它们之间的关系。Claude Code适合干重活它能在终端里真实读取项目文件、执行测试、运行命令像一个能自己动手改代码的AI主力。如果你的SDD规格写得清楚把任务交给它执行成功率很高。Cursor更适合作实时编码在编辑器里逐行修改、补全代码、做局部的代码洞察时Cursor的体验是最好的。多Agent的价值在并行验证比如你可以让一个Agent在不改动代码的情况下通读注释尝试发现注释是否符合SDD要求、是否存在不一致的地方同时让另一个Agent去检查新生成的代码结构。5.2 多Agent协作时的高效通信方法论多Agent协作最大的难点不是每个Agent不会干活而是它们之间缺少统一的“工作语言”。如果你让Agent A和Agent B分别处理同一项目的两个模块它们各自的产出结果很可能在接口对接时对不上。怎么解决我的做法是引入一个中间层专门做Agent任务分配和结果汇总。这个中间层可以是人即你自己也可以是一个消息推送脚本。具体来说我在项目根目录建了一个AGENT_TASKS.md文件里面记录当前所有Agent的待办、进行中、已完成状态以及每个Agent产出的关键文件路径。这样每个Agent在启动任务前都可以快速扫一眼这个文件了解自己在整个项目中的位置。这样做的好处还在于如果你中途需要人工介入修改某个Agent的产出你可以在AGENT_TASKS.md里标记“此模块已有人类修正其他Agent请勿覆盖”避免多个Agent互相踩踏。5.3 用Agent通信文件避免那种“左耳进右耳出”的尴尬有一次我同时开了两个Agent一个负责调整后端数据校验逻辑一个负责更新前端展示层。它们各自干得热火朝天但最后前端对接时接口文档完全对不上。后来我排查原因两个Agent的上下文是独立的它们根本不共享信息只能通过中间文件沟通。之后我就开始用“通信文件”的方式。具体做法是每次Agent完成任务后必须更新对应的接口说明文件写清楚“我改了什么、新增了什么、删除了什么”。另一个Agent在开发前必须先读接口说明文件中自己依赖的部分。如果发现不一致优先以接口说明文件为准而不是自行猜测。这样做之后多Agent协作时信息断层的概率大大降低。这里有一个关键点Agent和Agent之间沟通靠的不是自然语言对话而是共享的项目文件。你不需要让Agent之间能互相“说话”你只需要让它们能看到同一份“工作手记”。5.4 自动化命令与工作流的保存还有一个使用Claude Code时非常实用的小技巧把常用的工作流保存成可重复执行的命令。比如我有一段“检查代码是否违反SDD约束”的提示词每次开新对话都要手动写一遍后来我把这段提示词保存成一个脚本文件需要时一行命令就让它自动执行。这类“自动化命令星”其实就是你个人的最佳实践沉淀用得越多跑得越顺。6. 落盘在真实项目上的实践心得前面说的都是方法和工具如果你刚接触Vibe Coding可能会觉得“这么多环节我该从哪一步切入”。我把自己的上手路径再总结一下希望能给你一些参考。我建议的顺序是先拿一个小型项目或Demo练手跑通“需求→SDD→Cursor→Claude Code→验收”的完整闭环再放大到复杂项目。很多人的问题在于一开始就在大项目里用AI结果环境太复杂、上下文管不住最后得出“AI编程不靠谱”的结论。其实不是AI不靠谱是你还没学会给AI搭“护栏”。另外我还想补充一点Vibe Coding再“Vibe”工程底线不能丢。比如Git提交信息不要随手让AI写一堆“fix stuff”而要明确提交目的再比如测试不能省至少核心流程要有人工验收。AI能帮你把代码写出来但不能替你做“代码审查”而审查机制恰恰是项目质量的最后一道防线。我也遇到过很多开发者纠结“要不要买训练营课程”的问题。我的看法是这种课程的核心价值不一定在于教一个工具而在于帮你少走弯路。因为Bia Coding这个领域教程文档散落且更新极快自己摸索的成本非常高。如果有机会看到别人的完整案例和踩坑复盘其实是花小钱买时间。这话不是建议只是我自己的体会。如果你正准备开始一个需要使用AI辅助开发的项目我强烈建议你在项目开始的第一天就建立规则文件和SDD日常维护流程而不是等项目失控之后再来补救。因为重建稳定的代价永远是维护的许多倍。希望这篇复盘对你有一些帮助。如果你也在用这些工具做项目欢迎和我交流你的踩坑经历尤其是关于Agent协作和上下文管理方面的坑我最近正在整理一个“AI编程项目失控预警清单”到时候整理完了再来分享。
