ai coding这么长时间也算有点想法，可惜基本还没怎么使用过skills(新新提示词)，多agent等最新最潮的内容，感觉说出的话没有什么说服力，主要还是想着每次模型更新还得同步更新这么些个东西就有点头疼然后摆了，最重要的是没有什么钱，主力还是copilot学生包(巨硬是恩人)，算是比较穷的vibe coding，个人的探索也有限
随便记录一些关于(低预算非深度)vibe coding自己的想法/小技巧，看到的vibe coding大手子轻喷，可以多多交流
-
现在的ai很强，spec明确，scope边界限制好，我很难写出比ai好的代码，写出来的死代码也比我好
-
和ai pair programming，而不是单纯的让ai干活，及时给ai做code review，多怀疑它的代码，避免一些架构/简单的失误，tdd或许是好东西？但是我没有实践过，感觉会比较烧token而我是个穷逼
-
我并不是没用/被架空的，ai帮我处理80% - 90%的工作，我还需要做好20% - 10%，有且不仅有code review，还有帮ai擦屁股的工作，帮ai总结一些外部文档的工作，思考ai的架构合不合理的工作…防止ai又在空转烧我的token…当然如果你实在不在意任何细节，不考虑任何可维护性只想coding出功能当我没说，毕竟代码大部分时候没有价值，它实现的业务功能才有价值
-
承接上条，当你不用写代码的时候你就变成了架构师，这或许让你能去思考更多的问题，比如系统架构怎么做更合理，产品方向到底对不对，计数选型背后有哪些tradeoff，这些之前我们当代码大头兵很少关注的东西，现在或许会更加有价值
-
再承接上条，如果你干了这些事情，可能会发现其实自己还是很累，要权衡架构，要和ai聊架构进行对接，要一次code review生成的小千行代码，还要指出可能存在的过度设计再次迭代再次cr，脑力消耗很可能没有减少
-
有限token的情况下，一个bug ai自己跑了两轮没解决，就需要自己介入查看了，根据它的分析自己人工为ai纠正思路，当然你也可以搞一个playwright让他自己探索替代你来动脑（可恶的有钱人）
-
上下文窗口一定要看好，我把80%作为边界，让ai进行大规模审查后，一定不要让当前会话直接去批量修复，总结成文档开几个小的/自己分步去解决，ai被塞满了也会降智（哦齁并感？
-
要想要一个项目一开始就好用ai开发，开始最好就设计成agent-first的项目，要记住文档是给ai用的，让不同的ai了解项目的历史，毕竟你又不是写代码的，接口是让ai写的，测试也是ai写的，文档也是ai写的，human的东西肯定往后稍稍，文档结构性要强，及时更新，分层架构
-
重构这个东西ai大部分时候做的还行，但是有时候就很蠢，这种活你要是不想做，最好自己先想好要怎么做，提示词写明确，让ai实施，“帮我简化这个项目的逻辑”这种许愿式的不太可取，除非你token足够多你们决斗好几轮（你先出杀）
-
vibe coding多了真的会影响自己写代码的能力，而且会让你变得浮躁，优秀产出的评价从我的架构有多好/我的代码设计有多整洁到位变成了我一天搞了多少pr/ai coding了多少行代码，当然这也是生产力提高的一个侧面(耍我啊混蛋)，每个人都在这波浮躁的浪潮中寻找最佳实践，但如果你对自己的代码有更多追求，还是要适当的放慢一点脚步，多多思考
未完待续…