怎样用好 Vibe Coding，大幅减少重复编码？

前言

所谓vibe coding氛围编程觉得其实就是借助AI的力量去帮你写代码，但是很多人觉得有了AI之后就不需要程序员了，只要有了AI，我想做什么他都能帮我写出来。但真到自己上手的时候：一是找不到强力的模型。二是不会用AI编程的工具，三是只会向AI去描述自己抽象到极致的想法，完全不考虑实际实现起来有多么的困难，也不考虑自己的描述是否能让AI理解自己所真正想要的东西，最后大概率的结果就是得到了一坨，一坨与自己想法差距巨大，AI味十足的shit。而我，作为一名科班出身的程序员，经历了古法编程的时代见证了AI的崛起，从在网页上问AI自己这段代码哪儿错了，到使用claude code进行完整的工程级的项目开发。自身对于vibe coding的经验可以说是比较丰富了，市面上主流的Agent基本都使用过。

同时我自身所处的领域也比较特殊，鸿蒙开发对于绝大多数模型来说，都是没有过多训练语料的一个领域，对于鸿蒙开发相关的基础知识在训练数据里所占的比例是远低于其他专业技术栈的，其生成的代码质量，大多依赖于我给予的信息以及仿照现有的代码。因此，我也被迫去学习了很多很多关于Agent方面的知识，以便于弥补模型能力的不足。毕竟对于其他语言，你哪怕没有上下文，模型简单读个局部一下也都能猜到你要干什么，而且生成的也都是有成熟案例的最优质的代码。相反，对于鸿蒙开发来说，上下文就是至关重要的。如果你没有严格的约束以及提供充足的API信息的话，模型会按照其他前端语言的范式去进行编写，最终就会产生大量的语法规范上的问题，以及接口乱用的问题。

模型与agent选择

模型和agent的区别我就不再过多陈述，对于26年4月下旬这个时间节点，各个模型之间的差异说实话还是挺大的，尤其是对于长上下文的大项目，逻辑复杂依赖网络繁杂的场景模型之间的表现差距还是相当之大的。

模型

我现在的主力模型是DeepSeek-V4-Pro以及Kimi K2.6，没错是两个国模，Opus4.7和GPT5.5固然强的没边，直接抛弃大脑，但是价格也是真的让你飞起来。国模只要在完善的上下文约束下也是可以完成大部分的开发工作，同时DeepSeek现在也是有着绝对的价格优势。

我们可以将其接入cc去使用，体验还是相当爽的。不过DeepSeekV4说实话是个好模型但是绝不是个好产品。在编程方面，他没有自家的Agent，也没有相关的插件；在轻度AI用户方面，它的网页功能过于单一，且没有原生多模态，无法识别图片，音频，视频等，这对于平常用AI提取文字处理表格，阅读ppt的用户来说是致命的打击。这也引入了我之所以要同时使用两个国模的原因，DeepSeek是便宜，其能力也与K2.6相差无几但它没有多模态就导致很多场景下我需要通过截图进行需求描述，bug展示的我就需要Kimi的原生多模态来去进行需求与问题的描述。一方面是充当一个翻译官，另一方面是使用两个模型彼此检查互相监督也是很重要的一个点。

最后我还是同时开了一个Cursor Pro会员以便于在迫不得已时能够稳定的使用Opus 4.7去兜底。

Agent

首先对于Agent的选择，最优解肯定是使用各家自己的agent，但CC和Codex这种agent像用上原厂模型对于中国用户来说还是比较困难的。所以使用CC switch来去牛头人CC基本上是最通用的解决方案了，绝大多数的模型厂商都是会提供A厂接口API的。Open Code这种开源Agent也是不错的选择，但我们也要明白Agent内置的工具以及其内置提示词、内置的权限管理、系统提示词等差异也是影响编程效果的重要因素。

当然还有一种特殊的情况就是你需要部署一个agent在你的服务器上，去帮你进行一些操作，这种情况下去给CC配环境变量或者是去配置CC Switch就会变成一个比较繁琐的工具，但像KimiCode这种直接一键安装并且黏贴token即可登录的agent对于国内用户还是有较大优势的。

上下文工程

context上下文是整个VibeCoding乃至是所有AI使用场景中最重要的部分了。如何写好上下文是所有程序员现在必须要学习的。这里我来分享一些我的心得。

长期记忆

上下文窗口无论大小，目前来讲，哪怕是1M的窗口，对于一个工程级项目来说都是不够用的，绝对会出现上下文溢出而触发上下文压缩的情况。上下文压缩的质量有极大随机性，模型认为需要保留的重点很有可能与你所想的重点存在偏差，这种偏差带来的影响是致命的，尤其是在单次修改尚未结束的情况下触发了压缩。所以我们需要在开始先先让AI创建一个专门存储长期记忆文档的文件夹，并创建一个引导文件，在里面标明所有子目录的含义以及模型所必须遵守的规则。

常见的通用规则有：

上下文压缩后的恢复规则：当模型触发上下文压缩后，必须第一时间回到长期记忆文件夹，重新读取引导文件和相关模块文档。严禁在压缩后凭”残存记忆”继续编写，否则极易出现接口张冠李戴、业务逻辑前后矛盾的问题。这一点在鸿蒙开发中尤为致命——模型压缩后常常把ArkTS的语法写成TypeScript，或者把@State和@Prop的用法搞混。
先读后改，禁止盲写：在修改任何文件之前，必须先完整阅读目标文件。看似浪费时间，实则避免了大量”我以为这个文件里有XXX”的惨案。尤其是在多人协作或者AI多次修改后，文件的实际状态很可能已经和你印象中的完全不同。
单次修改范围约束：一次只改一个功能点。不要因为”顺手”而去碰不相关的代码。修改范围越大，上下文压缩的概率越高，出错的概率也呈指数级上升。如果确实需要修改多个模块，每完成一个模块就立即更新对应的长期记忆文档，然后再进入下一个模块。
API与接口的合法性约束：明确告知模型——只允许使用项目中已经出现过的API和导入方式，严禁凭空创造不存在的接口。对于鸿蒙开发来说，这条规则基本是刚需。你必须在规则文件里写明”所有@ohos.*的导入必须先在本项目中搜到使用案例，否则一律视为不存在”，否则模型会用它在前端领域的经验去编造看起来很像但实际上根本不存在的鸿蒙API。
不确定性升级机制：遇到信息不足、需求模糊、或者多个方案难以抉择时，禁止模型自行脑补。要求模型列出具体的不确定点，生成结构化的确认清单，等待人工回复后再继续。脑补五分钟，修bug两小时。
修改后自检清单：每完成一次修改，自动检查——本次修改是否引入了未使用的导入？是否破坏了已有的类型约束？是否影响了其他引用该模块的文件？如果是前端项目，还要检查UI是否在多种状态下都能正常渲染。
记忆更新与版本记录：每次完成一个阶段性任务后，必须在长期记忆文件夹中更新对应模块的当前状态。记录做了什么、改了哪些文件、当前还存在的问题。这份记录不仅是给AI自己看的，也是给你看的——当你过两天回来继续开发时，能让模型快速恢复上下文，而不是重新解释一遍项目结构。
禁止过度工程化：模型天然倾向于写出”看起来很完整”的代码——加一堆永远不会用到的错误处理、抽象出没人需要的接口层、为”未来可能的扩展”预留一堆配置项。必须在规则中明确要求：只写当前需求需要的代码，不做过度设计。代码越少，出错的表面积越小。

其中我认为最应当强调的是：如果有任何不清楚的一定要及时向我提问，向我请求帮助，要求我提供相关文档、使用案例。这一点是尤其重要的，尤其是对于鸿蒙这种模型训练语料不足的场景。大多AI是不会主动提问的，Agent的系统提示词一般也不会让AI过多提问，AI会尽全力去找出一个最可能看起来最合理的答案，哪怕有编造的信息掺杂其中也会给出一个看似完美的答案。给出这条提示词后AI就会让你提供一些日志，测试截图等信息来去协助他定位问题，这是及其重要的过程，Cursor甚至会有一个问题列表每个问题下面都有模型给出的选项和其他，这就属于是Agent独有的优势，用户可以直接从可能的情景中进行选项的选择，并总结发给模型，这样模型就能更准确的定位问题，同时很大程度上避免模型捏造信息。