『收集』收集一些 vibe codeing 的使用技巧和经验

来早了，正打算 Vibe Coding 搞个 iOS app，蹲一下大佬们分享经验

感觉主要是两种情况，

一种是想要什么没想到或者没想好怎么做， 直接告诉他我要哪样，有哪些资源，让它出三个方案实现 算是 **新功能设计
**
更多的是 纯懒 想好了要怎么做，明确告诉它怎么实现，让它快速实现 应该属于 力工

两种都有 debug， 第一种不知道什么 bug，描述现象。 第二种是知道什么 bug，让修复。

最想提醒新手的我感觉就是： 连环 Call 就行。 告诉 AI 要做什么，AI 给出的方案里边不懂的就一直问是什么意思。

Vibe Coding 实战要点（精简概要）

1. 示例优先，而不是抽象描述

核心原则：示例 > 描述
与其告诉 AI「我要什么」，不如直接给一个你认可的代码样子。

• 不给示例：
  • 风格不一致
  • 业务边界模糊
  • 需要大量纠偏对话
• 给最小示例：
  • AI 会主动对齐你的结构、命名、职责划分
  • 输出更像你项目里“原生存在”的代码

👉 结论：最小可对齐示例，是 Vibe Coding 的放大器。

2. 控制输出长度 = 控制思考质量

通过 max tokens 或明确提示结构来约束输出。

推荐做法

• 明确 token 上限
• 指定输出顺序（思路 → 核心代码）
• 明确“不需要解释基础概念”

收益

• 强制模型取舍
• 减少废话
• 输出更偏「工程师对工程师」

3. Claude Code / laper.ai 的核心方法论（高度浓缩）

3.1 文档是系统的一部分

• 根目录主文档：
  任何功能 / 架构 / 写法更新，必须同步更新子文档

3.2 每个文件夹都有极简说明

• 3 行以内说明目录职责
• 列出每个文件的：名字 / 地位 / 功能
• 明确声明：目录变化必须更新此文档

3.3 每个文件都有三行元注释

文件开头固定三点：

• input：依赖什么
• output：提供什么
• pos：在系统中的位置

并声明：
文件更新 ⇒ 同步更新文件注释 + 目录文档

4. 本质：分形结构（Fractal Structure）

• 局部映射整体
• 整体约束局部
• 文档、代码、认知彼此自指

这让 Vibe Coding 从：

「AI 帮我写代码」

进化为：

「AI 在理解系统结构后与我协作」

局部影响整体，整体塑造局部。

这个我最近也体验了一下
作为一个不会编程的人，确实让我有一种力大转飞的感觉。
比如，作为 beancount 用户，之前都是用脚本把 csv 文件转写成 beancount 记账的文本。
借着这个脚本的逻辑，我写了一个网页交互应用

以前的工作流是 SSH 回服务器，上传 csv 文件，输入命令

现在的工作流是，打开网页，上传文件，复制粘贴

我也尝试了其他的想法， 产出有好有坏，逐渐也摸出了人机对话的要点。就是要明确、明确、明确
指出问题要明确
你的期望要明确

这个 ai 让我必须给出简单直接的命令，这也是让我深刻总结和反思，我要的是什么，目的是什么

最后，我现在能体会那种上头一下子搞出好几千刀美元账单的人了

问一些调查之类的，最好添加一句，请同时附上官方的文档出处以及社区链接，这个非常有用，也有很大帮助，基本能过滤掉 ai 胡说

前几天遇到了一个标准 ai 胡说，aws 上的同一个内部 vpc 的 lambda 可以相互调用吗？ ai 给的都是可以，实际就是不可以，上面的人不信，我回复除非掏钱，加终端节点或者加 nat 网关，其他就是不行 ，ai 在顺着你想的答案走

请给出你的处理方法参考的网页资料，这样子 ai 就不敢随便糊弄你了（🐕

平时开发 Java，会先让 ai 参考某一个具体的模块的代码风格，命名，分层之类的，然后提供 ddl，最多的就是用来生成代码框架（最基础的 crud）以及一些重复性较高的代码，具体的业务逻辑，还得靠自己写，因为我实在是不想跟 ai 讲业务

平时开发 Java，会先让 ai 参考某一个具体的模块的代码风格，命名，分层之类的，然后提供 ddl，最多的就是用来生成代码框架（最基础的 crud）以及一些重复性较高的代码，具体的业务逻辑，还得靠自己写，因为我实在是不想跟 ai 讲业务

我基本上都是先 plan，给我计划，然后一点点调整，告诉那些需要注意的，哪些需要补充的，然后在执行。

这样多次之后，ai 准确率会直线上升，很多东西不需要你提醒，它都知道。

1. 我感觉先有一个角色设定，比如是你是 Java 工程师，提示词里面可以就写“你是一个资深 Java 工程师”，这种基本都有模板。这些车轱辘话可以持久化到 claude.md 文档里或者修改到 cursor 的 rule 里之类的。
2. 还有就是要确保上下文的干净，聊多了之后要记得新开一个会话（或者 clear 掉）|
3. 善用 checkpoint 之类的，改错了就大胆回退，修改提示词重新生成代码。同时，要配合 git,能运行了要及时 git commit。这样基本就不怕改坏了。