让我想想作为第一篇 blog，该讲些什么比较好呢。
就讲讲我自己这几个月以来的 vibe coding 的当中的感悟吧，其实我自己在平时查询网上 vibe coding 教程好，还是 cc，codex 等专业的 agent 教程也好，大多数都是教导用户如何去使用这些工具，其实我自己认为大部分教程讲的内容很大一部分是相同的，毕竟一个工具的功能点就这么多，很难写出花了。看了第一篇不会，再看了第二篇看多了终是会审美疲劳的，就好像讲的东西少了什么, 讲的东西始终没有让我想见恨晚的感觉，后面我自己实际去尝试使用了，我明白了我一直想要学习的东西是什么了，是真正的开发，我自己只是一位大学生，没有相关的业界开发经历，我很想知道实际开发，我缺乏的也正是这个，于是自己尝试写了一个 app，目前也有了十几万行了吧，还没开源，但是基础的功能什么的都已经开发完毕了剩下的就是打磨 UI|UX 了，或许等这个系列写完了，就差不多可以发布了。

实话实说我自己觉得应该有点参考价值的，毕竟高强度使用了数个月的 cc 和 kiro，从目前的套餐数据来看 GLM 一个月平均用了 10 亿 token 再加上 minimax 的还有几个亿打下手，至于写文档与代码的 claude 我估计应该也用了几亿token 每个月了光是这个都感觉已经是不小的开销了。

好了正式说下我的开发经验吧。

1 模型选择方面

1 ）请不要为了性价比而放弃 SOTA 模型

在实际体验下来，SOTA 模型（opus，5.2）的操作体验绝对不是一流，二流模型可以比拟的，当然选择次一点的模型最大的原因就是钱包撑不住，但是没关系基本上各大厂商都存在一定的白嫖方法成本一个月算下来也只是比国内的 code plan 贵上一些，但还在个人开发的承受范围。如果说老板，环境什么的不支持不能实际用于工作，但是私下回家体验一下还是很值得的，最重要的是看到目前的 vibe coding 的前景，读了很多的 blog 最有印象的一句是‘未来是“UGS”的时代’，
用户就可以产出软件了，编程的门槛没变，但是产出的门槛确实是实打实的降低了,或许跟厂商的 100 分大众软件相比，未来的 60 分的私人定制或许可以成为新的方向，不要让模型的智力限制了对于未来的想象。

2 ）学着分工

同样是开发流程当中的事情，在行业以前的开发流程里面，和产品对接要需求，开发讨论技术选型，开发苦逼的写代码, Review，测试来测试，记录 BUG，开发返工，上线部署，盈利, 运维同学运维，提出新需求，重复这套流程。
现在在 agent（vibe coding 工具很多，命令行的codex，cc，插件的 cline，Roo，IDE 的 cursor 等，本文统一称为 agent，代理）的代码能力在整个 2025 年有了极大的提高，但是主要是体现在我们的开发部分，还不包括后面的 Review 和 Debug 的流程，所以说效率也没有提升的那么可怕需求的敲定，技术的选型还是需要人为的参与，模型理解的偏差还是需要的人类的插手，目前除了在纯粹的开发环节可以做到自由驾驶，在其他阶段还是手动挡，我们还是只能慢慢来。

那我也一个一个说吧，需求敲定的流程，看你对于这个项目的理解的如何，不过一般人类的想法是比较短的，没经过整理的情况下很难形成一个良好的文档让 agent 去理解你的需求，所以需求敲定的第一步是尝试讨论清楚，不用太长，主要是把自己脑袋想要的东西记录下来，不要试图指望什么一句话就让 agent 开发一个软件出来不现实，所以在开发之前把需求想清楚，自己都不明白的可以去简单的和网页端的模型聊聊，让它不断追问细节很容易先写出符合你的需要的文档的，所以我们需求讨论这里放给了网页端的 agent（主要是免费，你直接在 agent 里面问也可以，甚至效果会更好一点毕竟有了你的项目作为上下文，不过成本问题就需要你自己考虑一下了）

第二个场景即使文档的撰写了，这个简单直接放给 agent做就好了，唯一需要注意的就是这家伙有没有曲解你的意思，写完了 review 一下就好了，但是这个模型选择还是推荐 SOTA 模型去编写，因为后面相较于你的提示词，这个文档内容才是上下文的大头，更值得好好打磨一下，编写出一个合格甚至是优秀的文档绝对是不加钱提升 agent 能力里面最简单的了。当然如何 review 可以丢给其他的 agent 让它读完过后告诉你这个新增的功能预期是什么样的，哪里理解不对让他找出原文，然后你自己或者 agent 再去修改就好了。

第三个开发的场景这个就很值得说了，要注意的点太多了，专门成文去说。

第四个是 review 的方向，我目前自己真正需要注意的是需求文档（PRD）的审查，至于后面的技术设计文档，实施计划，api 接口文档这些统一 agent 代笔，agent Review 当然这里的 review 就不需要 SOTA 选择稍微低一些的模型就行了，国产的量大管饱正合适。

第五个测试，同样的 agent 的编写测试用例，这里需要注意的是尽量不要使用 mock 的数据，因为 mock 的数据也是 agent 自己写的，当测试失败他大概率会认为自己的测试用例 mock 错误了，要改测试用例，所以导致测试是 0 error 连编译都过不去，正确的做法是 code agent 不使用 mock 的数据必须使用真实的数据即使这个过程需要人为辅助，但是相信我这是值得的，第二步就是在人工辅助测试过后基本功能跑通了，专门调用几个其他的模型开一个分支去各种测试, 边界情况，特殊情况，给出报告最后拿着报告再来细看是否真实存在问题。

剩下的部署，直接 agent 自己就能完成了，人类在这里参与度不大。
当然分工最主要的用途还是在 code 和 review，考虑成本和性能的平衡，所以在 review 阶段可以多尝试使用便宜的国产模型，执行这类任务还是可以的。

2 agent 的使用方面

1 ）重视你自己提示词

这个层面说的就更多了，整个业界的工具都是在不断的进步的，各种新技术，新协议都是层出不穷的，但是我觉得本质上除了模型本身的能力进步外剩下的都是为了重复的；利用上下文，让 agent 能够指哪打哪，当然这些就是开发者的水平体现了。
所以基于上面的无论是什么 skills, subagent,都是为了缓解上下文腐烂这个问题，所以对应的开发过程当中自己的提示词就是极为重要的了，毕竟大佬们也没想出什么好方法，要想把钱真的花在刀刃上首先需要做的就是让 agent 真的理解你自己的方法，其实人机交互也是与过去开发人人交互是一样的，你可以认为 agent 就是过去的初级程序猿，你自己就是无良的老板，绝大多数的时候都是只负责张嘴的，我相信你也很讨厌那种需求自己都不说清楚，连设计方案都不提供，Bug 信息都不知道的 leader 了，agent 也是一样，如果你能在你的提示词里面强调你真的想要什么，Debug 能和过去向大佬请教那样，讲清问题，给出源代码和报错，还有尝试了什么解决方案，结尾的时候考虑礼貌一点，agent 的试错的代价会小很多，上下文就不会容易被垃圾填满了，当然更能执行好你的命令了，重要的是也能减少成本了。

2 ） 及时清空 agent的上下文

就像前面说的面对问题的时候，agent 的上下文总是会填满的，所以最好的选择不是说一个 context window 用到死，而是选择及时记录下来未完成的工作，把过去的垃圾及时清理掉，不要让没用的东西一直干扰着 agent 的思考。
并且基于此，如果你对于 agent 的自己的 compact 的指令不感兴趣，早点找到适合自己这个项目的 compact 的命令才是正路。

写到这里第一篇应该已经可以简单的结个尾了，一开始原本说着写开发软件当中遇到的问题没想到最后还是回来了，不过也算是梳理了自己的想法，给大家提供了一点经验也算是有一点意义，也给自己的 blog 开个头。