夜雨聆风今天分享下我最近一次VibeCoding（使用自然语言借助AI写代码）经验，希望对你有用~
Part1 我最近干了什么
在没有任何开发、测试介入情况下，纯用AI coding，完整走完一个业务需求的研发上线流程，目前已给业务使用。
1、先说下我的coding背景
2、我最近VibeCoding了什么
「网站评分工具」
1）输入网站URL可以获取这个网站在SEO、网站设计方面的评分，以及评分细则
2）可以直接导出评分结果PDF，发给客户或内部查阅
3）可以登录到评分管理后台，调整评分细则项的权重（满分）：
3、关于本项目的花费
本项目累计约900元，一周时间（每天约2-3h coding时间）。
Part2 我为什么干这个
主要还是想，一直想让AI按自己的想法做出一款完整的产品，解决一些问题和需求
我负责的业务，经常收到这样的需求：
因此，需要有一个有业内标准和评估准则，来对网站进行评分和建议的工具。
除了有这个实际的需求，其次和其他的业务代码相对独立，不会带来麻烦。
Part3 我具体怎么干的
1、开搞前的准备
尝试不借助任何开发介入，我按照业务理解，梳理了如下执行步骤
在经历了minimax2.7的折磨，还是选专业的coding模型吧
1）网站分析时是需要做内容截图和视觉分析的，需要调用专业的截图工具和模型
事实上，VibeCoding后，这些在我面前的难点，在AI面前也就几秒的事。
2、开搞！1）先粗暴点“一句话需求”
1）先粗暴点“一句话需求”
之前用Trae、Cursor等VibeCoding工具，让它们生成一个贪吃蛇游戏，一句话“帮我生成一个贪吃蛇游戏”，就能生成的非常好。
于是我想着这个需求也不复杂，试试直接给coxxmaker讲需求，让它帮我实现。
输入 | 输出 |
 |  |
丑的不行，流程也没跑通。
2）折中点
，“给个PRD”
2）折中点
，“给个PRD”
由于一句话需求缺少很多页面、逻辑等信息，于是我让豆包根据我的三句话需求生成了一份PRD，发现还是不达到预期，要调整的地方太多太多了。
3）按完整开发流程来
3）按完整开发流程来
① 原型设计：“Stitch画原型”
我把豆包的PRD给 Stitch，画出来的原型不符合预期，有很多我不需要的，我猜测是这个PRD太长了细节太多了。
于是我换了Gemini，让它给我一个相对详细的给Stitch的Prompt，我来补充细节。
Stitch听话了！满意度80%，先让coxxmaker开搞。先跑起来，别太纠结细节。
② 需求明确：“SDD（spec）”
在给coxxmaker之前，我了解过SDD规范，基本上就是先澄清，再规划，再拆解，再干活。speckit、openspec、superpowers这些都是开发框架/规范/技能包。
coxxmaker里有speckit、openspec，我决定使用speckit。
过程
截图
/ specify 输入需求
/clarify 会和我澄清
生成的spec.md文件
③ 需求开发：“claude+其他模型”
惊人的好！但是有一些逻辑错误，比如评分结果不该在规则后台、规则后台应该要登录、规则后台没有审核以及各种无用的介绍等
4）需求变更&调优
4）需求变更&调优
于是就开始和coxxmaker输入指令，注意一个问题一个问题地修改。
比如，上面提到的配置后台和评分页面是耦合的，我要让它拆分开
改的过程还挺顺畅，但其实对我来说就是个盲盒。比如，服务打不开了，我就按他说的配合他测试。
所以如果想改的更快，最好还是懂点基础的技术知识，最快的方法就是请个AI来做帮手，比如服务打不开的问题，其实是端口变化了，它会告诉你原因是什么。,
当然，也可以在coxxmaker里让claude通俗的讲解下错误原因，但是会增加上下文长度，消耗更多token并且影响后续结果，所以这种“请教”类内容我会找Gemini帮忙。
我决定让它回退，但是发现还是没有完全恢复，我只能又一个问题一个问题地修改。
于是，我决定给整一个版本记录，这样我就可以放心地修改了。
直接安装GIT Autocommit 插件就可以，我直接和coxxmaker说让它帮我安装，而它非常聪明选择了更好的方案。
5）三方接口/服务对接
5）三方接口/服务对接
通过mock的数据，跑通主流程，接下来要把评分规则需要用到的工具、接口实际接入。
但开始我就遇到问题，比如移动端适配效果、LCP等指标，有哪些权威的通用的工具呢？
在开始做调研前，我试着让AI直接帮我搞。再一次使用spec模式进行开发，没想到全都帮我搞定了
过程 | 截图 |
 | |
 | |
 |
6）完整的技术架构
6）完整的技术架构
为了“掌控”它，我让它生成架构图给我确认，在和业务同学确认可用后，发现它真的强！
7）测试/验收：人
7）测试/验收：人
其实可以引用一些成熟的测试框架，比如DeepEval，但是由于本项目很简单，所以直接上人会更高效。整体流程、效果都没话说，但我有个问题：
我用了几种最简单有效的方法：
1、嘱咐AI+让AI对Mock数据标识
2、观察.md，比如agent.md文件
3、断网测试，还能跑说明假
4、过程产物检查，比如执行过程是否真正截了网站页面的图
5、结果业务性检查，返回的内容是否有业务属性
6、数据源头实际调用检查，比如Lighthoue的调用和实际测试结果是否一致
7、多测几次，看评分差异
做了这些，基本可以验证是真的执行了，为了保证每次都是真的执行，我让它在执行结果把数据来源贴出来。
分享几个印象深的调优case
我发现每个网站测试下来，这俩指标都很低（20多秒），但是实际打开并没有那么慢。
于是让AI讲述测速方案，发现它按照4g以及最普通的性能进行网络测试，这明显不符合我们的需求。
把测速标准用自然语言进行了调整，AI自动盘点影响点，我接受后它自动修改好了。
移动端适配明明不OK（样式错乱），但还是高分。
于是让它对标Google的移动端适配API数据，发现它为了节省视觉模型用量，自动采用了简单方案（viewport meta标签+Lighthouse Performance性能分）
于是和它提样式要求的检测，在找Gemini验证后，决定采用“Lighthouse tap-targets +font-size ”和“Puppeteer 手机视口截图+GPT-4oVision”结合的更真实的方案。
发现有些网站反爬，这时候AI会自己制定方案，比如更改UA，一次就改好了
经常出现模型调用或返回失败的问题，每次都得人工重新识别（目前用的是中转模型会不稳定）。AI判断token问题，并且很聪明的自己加了“重试”，完美解决！
8）部署上线
8）部署上线
就是让别人也能访问。
这里我感觉是最复杂、最难点，难点在于：我不了解部署的流程，不像前面的产品开发流程我很熟悉。
去咨询开发！需要用到哪些平台、流程是什么、如何申请镜像和集群等...
按照流程不停让coxxmaker执行，自己检查、确认、补充细节、考它，最终成功上线了！
并且让它给我通俗地、打比喻地讲解整个部署流程。
,
Part4 我收获到哪些经验
之前用minnimax2.7 +Trae/Cursor，改来改去，根本无法控制...（即使调整上下文长度、temperature参数等）。如果是coding，尤其复杂项目，还是建议claude。
当然，如果简单按钮、文案修改，可以用minimax、GLM这种轻量且便宜的模型。
最好用支持多模态识别的模型，比如minimax、deepseek v4都不支持截图分析，这样让它修问题就很难....
这就是导致经常遇到的上下文过长带来幻觉或漂移的问题，且上下文过长带来不必要的token消耗。
每次开启新会话后，直观上有两个效果改进：执行更快了！输出内容丰富度更高了！
可以：分支流程直接启用新会话、主对话过长让AI压缩后开启新会话（新会话读取压缩内容）
AI生成的Prompt、原型都不可能尽善尽美，即使100分，AI也不一定能还原。
先扔给AI跑起来，再调整！（就像我们平时做事一样）
对接三方接口的时候，本想着自己先调研，或者让它先找一些 webscore 的skill。
但是直接让AI尝试，给出的结果已经非常可用了，这帮我节省了很多的调研时间。
在测试时候发现，它总有漏检的情况，于是让AI增加日志，这样就能清楚看到每次执行任务时候，哪些没做、为什么没做
参见上文“需求变更&调优”，让它安装版本记录插件！
这样改起来无压力。
通过给AI下原则、看.md文件、看实际过程产物、看依赖工具的调用情况、看结果的业务准确性、看多次结果的差异性、找一个agent等方法来判断。
Part5 这个项目有什么提升空间
Part6 我对VibeCoding的看法
AI极大降低了写代码的门槛，解决自己所拥有知识以外的事情，并且学习这些新知识的成本极低。我知道了DOM、UA、CDP、Cheerio、Puppeteer、镜像、容器、等技术名词或工具。很难想象下图是出自我手的...
它非常聪明！而且学习和复盘很快！
AI很强，会操控体现在：
Part7 关于VibeCoding小建议
未来已来！！选择一个工具，找一个场景，写出你的第一个程序吧 ！
