如何正确的开始vibe coding

先放一张封面图 叠甲：以下内容为个人观点，仅供小白参考。本人非计算机专业，如有问题欢迎在评论区指正。 今天来说说如何正确使用agent进行vibecoding，或者说进行 相对正规的长期项目开发（适用于中大型项目 ）。以 codex 为例，其它平台也适用。 先将你的codex调整到codex模式，其它平台可能不需要切换。  1.不要反复造轮子。 不管你有什么创意都先让AI在GitHub帮你深度搜索一下 ，看看有没有类似的项目可以作为参考，这样你的项目就不用从头开始大框架了，甚至都不需要vibecoding了，直接拿成熟的项目去用就行。可以参考项目 右上角的star数 以及 开发者近期有没有对项目进行维护 来确定这个项目对你的参考价值。 2.开始coding之前先和模型充分讨论 在vibe coding中最重要的一句提示词是： 如果你还有任何问题或建议可以先向我提出，解决所有分歧和阻塞后再执行任务。 无论你处于哪一阶段，我都建议你将它放在结尾，或者放进全局个性化指令中也可以。先和AI对齐颗粒度，才能保证后续的开发更顺畅，不然AI很有可能会自作主张，或者隔一段时间就停下来问你这些它当时没问清楚的问题。 在coding之前最重要的是和模型确定下面几件事： ① 你需要哪些功能 。你要先详细的向模型描述你需要的功能、使用场景、你希望能达成的效果。让模型去根据你的需要去GitHub做可行性调查，找找有没有直接可用的项目或者类似项目采用的技术路线。最终向你提供一个最佳的实现路径。 参考提示词：我需要开发一个xxxxx，它需要包含一下几个功能：一、xxxx 。二、xxxx。三、xxxx.这个程序主要xxxxxx场景中使用，我希望它能做到：xxxxx。帮我在GitHub寻找类似的项目，并做一个可行性分析报告，分析GitHub中相关项目的实现方式，向我推荐最佳的开发路线。 如果你还有任何问题或建议可以先向我提出，解决所有分歧和阻塞后再执行任务。 ② 详细的阶段性开发方案 。在确定好开发路线之后就可以做开发方案了。开发方案分 前端 和 后端 ， 前端主要是用户能看到的可视化面板即UI ，后端是代码层，整个程序的功能主要靠后端的代码来实现，但一个好的前端对大部分人来说同样重要。 基本功能确定好之后，后端的开发方案交给AI自己做就行。一定要交给你能获取的性能最好的模型来做开发方案。 如果你的开发的项目需要前端的可视化面板，那么这一段得好好看看。因为目前除了Claude以外其它模型做的UI都属于勉强能看，实际上还有很多小问题。 （1）如果你觉得UI能用就行的话，直接让模型自己设计就行。 （2）如果你想让UI更美观的话，可以在这一阶段告诉AI你对UI的要求，让它在HTML里渲染一个预览UI给你看。UI设计是一个比较复杂的工作，可以用以下几种方式来做： ①把你钟意的UI通过截图发给有视觉识别能力的模型，让它照着做。 ②让AI去苹果官网找苹果的UI设计规范，按照设计规范去做。 ③按照你的想法详细向AI描述你设想的UI界面。 按照之前的讨论结果帮我设计一份详细的开发方案，包含前端UI预览和后端的功能开发。 以上提示词仅做参考，具体的UI预览可以是渲染后的HTML文件，也可以是字符画预览。我还是更推荐直接做一个渲染好UI的HTML界面，这样比较直观，后期实现的时候也不容易走样。 3.搭好项目框架 确定好开发方案就可以开始搭你的项目框架了。主要是涉及项目开发的基础文件还有项目级个性化指令约束。 这些文件实际上是模型在项目开发过程中的持久化记忆，用来方便其它模型接手的 。因为真正开始开发之后，你不可能只用一个对话，也不可能只用一个模型，甚至不可能只用一个平台来做开发。所以必须要先把基础性文件做好，才能方便其它模型快速接手。 第一步，选定一个位置创建项目文件夹，可以让AI代劳，你需要做的是在你的codex内部把这个文件夹设置为项目文件夹，这样之后的项目开发都会在这个文件夹中开展。 第二步，让AI开始创建用来记录项目开发记录、文件路径、开发规则的相关文件。并写入初版的开发内容。大概需要创建以下几类文件： - PROJECT_INDEX.md：约 2–4 KB 的定位、当前摘要与路由；已有更简洁的等价入口可沿用。未改变项目状态不机械更新日期。 - NOWmd：需要接续进度、排期或待验收事项时定位相关章节。 - MAPmd：多版本路径、同步边界；只保存有效映射，不堆叠安装和发布流水账。 - RUNBOOKmd：运行、构建、验收或交付时读取对应步骤及前置条件。 - DECISIONSmd / RISKSmd：设计冲突、相关高风险操作触发读取。 - history/：按月份或主题归档有价值过程；先搜索，再读命中上下文。不要为写历史而复制整段聊天。 这几类文件创建好之后，还需要一个项目级agent md，放置到项目入口，主要用来教接手项目的AI怎样去在上述文件中查找相关内容，怎样去做记录方便下一个模型接手任务。特别强调一点：要在这个文件中注明：模型在阅读相关文件时必须通过搜索查找当前需要的内容，不能默认读取文件夹中的所有内容。不然会产生极高的token消耗，因为模型会默认读取整个文件的内容。 当然还可以加入一些你自己设定的开发规则，当然全局agent md也可以加入一些其它的规则。例如下图： 这里有一个现成的提示词，项目文件夹弄好之后直接发给AI就行： 请在当前项目中建立或完善基础文档，并实际创建或修改文件。目标是让后续 AI 能按需获取上下文，将信息写入正确位置，并可靠接续工作。 一、执行原则 先确认项目根目录、适用规则和已有文档。已有同等职责的文件或章节优先沿用，不重复建档，不强制改名。缺失事实标注“待核实”，不得编造项目情况。 本次仅处理基础文档及其导航，不修改业务代码、安装依赖、运行服务，不执行 Git 提交、推送、部署或删除。保留已有内容和用户修改；仅在目标不明、规则冲突或可能覆盖成果时询问。 二、读取规则 以下规则立即用于本次任务，并写入项目规则文件： 按当前问题选择资料，不因文件存在、可能有用或被索引链接就读取。 不默认读取所有项目文件，也不默认全文读取选中的文件。定位到文件后，继续定位相关章节、条目、函数或配置项。 优先使用已有有效信息；需要查找时，按“索引或限定范围搜索 → 标题、符号或关键词 → 命中片段及必要上下文”的顺序读取。 只有证据不足、存在冲突或需要核对依赖时才扩大范围；信息足够即停止。不得连续分段读取，变相遍历无关全文。 全文读取仅用于短小且全部相关的文件、完整理解适用规则，或明确需要整份审查的任务。不得因此扩展为全目录或全项目读取。 索引是条件路由，不是必读清单。历史、日志、依赖、产物和数据目录不默认读取；不读取密钥及无关私人数据。 不为节省上下文跳过适用规则，也不因片段过窄而断章取义。已加载且仍有效的内容不重复读取。 三、写入规则 将以下规则写入项目规则文件： 仅在任务允许且信息有实质变化时更新；只读任务不改记录。 每类事实只设一个权威来源，其他位置使用简短摘要和链接。 修改前读取目标部分及必要上下文，局部修改使用定点编辑；不得根据局部阅读覆盖整份文件。 当前状态直接修订，有价值的旧过程归档；不反复追加矛盾快照，不保存完整聊天和操作流水账。 区分事实、计划、建议、已确认决定与待核实事项；区分代码完成、测试通过、安装验证、用户验收和发布授权。 命令已配置不等于执行成功，历史结果不等于当前证据，文档中的操作步骤不构成执行授权。 使用清晰标题和项目内相对链接；核验日期注明对象与范围，不写入秘密或个人设备私有路径。 四、文件分工 无等价结构时，在根目录建立 AGENTS.md、PROJECT_INDEX.md、README.md；其余专题放入 docs/context/。已有结构可使用等价文件或章节承载。 AGENTS.md：保存长期规则、上述读写规则及必要验证要求。接手项目时确认适用规则；长期约定变化时更新。 PROJECT_INDEX.md：保存简短项目定位和“任务 → 文件或章节”路由。需要定位时读；入口或职责变化时更新，不复制专题正文。 README.md：保存项目用途、基本使用方式和文档入口。了解或使用项目时读；实际能力和使用方式变化时更新。 NOW.md：保存当前目标、进展、阻塞、下一步和证据入口。接续任务时读；状态实质变化时更新。 MAP.md：保存目录、版本、配置和部署位置的必要关系。定位修改或运行对象时读；映射变化时更新，不虚构环境。 RUNBOOK.md：保存有依据的操作、前置条件及验证步骤。执行对应操作前读；方法变化时更新，未执行的命令明确标注。 DECISIONS.md：保存已确认决策、理由、范围和来源。涉及相关选择时读；决策确认或替代时更新，不把建议当作决定。 RISKS.md：保存有证据的问题、风险、验证缺口及保护措施。任务涉及对应风险时读；证据或状态变化时更新。 history/README.md：索引有价值的历史记录。需要追溯时先搜索再读；发生必要归档时更新。 已有 PROJECT_NOTES.md：保留有效内容并补充专题入口，按需检索；没有独立用途时不新建。 五、检查与交付 “完整”指职责覆盖完整，不要求扫描整个项目或填满每个专题。无资料的部分简短标注状态。 完成后仅检查本次改动及直接关联的链接，确认职责清楚、读写规则齐全、无重复权威来源、未覆盖既有成果。报告新建、修改和沿用的文件、检查结果及待核实项，然后结束任务，不自动扩展为全项目审计。 3.开始vibe coding 当以上所有基础文件都创建完成后，你需要做的就是是把之前那个负责设计开发方案的对话拖到该项目下。然后新建一个对话，右键之前负责设计方案的对话，在右键菜单选择 复制 - 复制深度链接 ，把复制的链接粘贴到对话框，选择一个性价比较高的模型去执行开发任务。比如 DeepSeek 或者 GPT6 sol 就很适合执行编程任务。 万事开头难，学会了如何开始后面的开发任务就很简单了。日常coding最重要的事情就是在执行任务前和模型讨论好所有细枝末节，确保模型真的懂了你的意思。这样才能让每一项任务都得到落实。 下面是我前段时间做自己用的UIskill的过程： 第一步，我先找DeepSeek 4.1flash把最粗糙的数据收集的活干完。让它把我所有项目中关于UI的任务记录整理出来，然后按照任务历史中我对这次UI任务的后续要求来给UI设计方案打分，如果UI设计没有返工，历史记录显示我对这次任务很满意，就会给这次任务打一个正向分数，表明这次任务是可参考的正面例子。如果这次UI任务总是返工，那么就会打负分，把这次案例判定为反面案例。 第二步，我让GPT6 Astra去分析DeepSeek做好的数据库，按照我的要求先做了一个初版UI设计skill的方案出来。因为这一步比较重要，所以需要我能获取的最聪明的模型来做。当然设计方案时也免不了要反复讨论skill的一些细节。 第三步：全部的细节确认好之后就可以开始创建skill了， 初版skill主要是为了解决模型在做UI的时候经常遇到的坑，所以目前还没有去GitHub寻找素材。 第四步：在实际使用中不断打磨，每次使用UIskill之后我都会让Astra去分析这次UI设计任务出现的问题，持续打磨细节。 第五步：在经历了数十轮细节打磨之后，关于UI设计的常见错误这一块就处理的差不多了，接下来的时间我让Astra去GitHub找了很多star比较多的skill做参考，开始补充一些当前skill缺少的内容。在吸取了GitHub高star项目的精华之后符合我自己要求的UIskill就基本完成了，现在仍然在依靠真实任务积累的数据不停的迭代。skill创建是一个非常轻量化的项目，但需要大量的数据积累才能设计出好的skill。等你有了足够多的数据之后也可以尝试一下创建更适合自己使用习惯的skill。 1 个帖子 - 1 位参与者 阅读完整话题

• 情报分类：技术学习与提效
• 分类依据：内容涉及技术、AI、软件工具或工程实践
• 信息来源：服务器 / LINUX DO - 最新话题
• 发布时间：2026/10/8 11:11:48