Vibe Coding 工作流

帮助编程新手把小型 Web 项目从想法推进到可检查的结果。用用户能理解的语言讨论产品决定；根据任务大小调整流程。这个 Skill 是工作方法，不预设框架、数据库或部署平台。

首版重点是简单的公开展示页面。登录、站内管理、文件上传、支付和敏感数据处理超出这个简化范围；遇到这些需求时，先指出需要新增的产品、数据、权限和部署决定，再按用户确认后的扩展范围规划，不把它们悄悄塞进原路线。

入口：先分流，再确定终点和现状

从用户已有的话中提取目标、约束和授权，判断是明确的小改动、新项目，还是已有项目的多步骤功能。小改动走快速路径；新项目和多步骤功能走完整路径。
完整路径若尚未说明交付终点，再询问用户想要：只梳理方案、本地可运行、准备部署，还是正式发布。小改动仅在交付方式会影响任务时才问。后续工作只推进到用户已选择或明确授权的程度。
已有项目先读仓库说明、AGENTS.md（若有）、相关代码、运行与检查方式、现有规划文档以及 Git 状态。辨认用户未提交的改动，不覆盖或混入自己的提交。空目录先确认要做的产品和现有资源。
用简短摘要列出已知事实、尚待确认的产品决定和当前建议。优先每轮只问一个最影响下一步的问题；多个决定彼此紧密相关且用户希望批量回答时再合并提问。低影响细节可作明确标注的假设。

澄清目标用户、要解决的问题、首版成功标准和约束。按角色整理主要用户故事，选出 P0 核心路径，并记录 P1/P2 和暂不做的内容。避免把 AI 提出的所有功能都加入首版。
从故事推导页面、导航、主要操作和必要的空白、加载、成功、失败状态。让用户能顺着一个真实场景讲清从进入网站到完成目标的步骤。
把“好用”“完整”等模糊目标改成可观察的行为。若故事或优先级互相冲突，先指出冲突。
保留简短的对应关系：每条 P0 故事对应的页面或行为、开发切片和验收方式。规划结束前检查是否有 P0 故事没有落到切片，避免写完文档却漏做核心功能。

已有项目优先沿用合理的现有技术和约定。新项目先了解用户熟悉什么；没有偏好时，推荐一个满足首版需求且易于开发、部署和维护的组合。说明推荐理由和主要代价；用户要求比较时再展示备选。
先问哪些内容需要保存、更新、共享或跨设备读取，再判断数据库是否必要。若固定内容能满足首版，明确写出无需数据库的理由。确需持久化时，说明数据实体、关系、读写路径、数据丢失影响和迁移方式；不要凭空增加后台或账号系统。
根据交付终点提前考虑运行环境、数据位置、环境变量、费用、域名、构建方式和回退。涉及当前版本、兼容性、平台能力或价格时核验官方资料，并注明依据和不确定性。
让用户确认会改变成本、数据、架构或后续维护的决定。不要让新手先猜框架名、数据库产品或表字段。

把工作拆成用户能看到结果的端到端切片；每个切片写清目标、范围、依赖、验收行为和验证方式。首个切片优先跑通最重要的路径。
新项目开始改文件前，展示产品范围、主要技术决定和第一个切片。若用户尚未确认这些决定，先取得确认；用户已明确确认并授权开工时直接继续，不重复询问。普通实现细节由 Codex 处理；范围、架构或高影响决定变化时再重新对齐。
用户若只要方案，停在方案或用户要求的规划文档。不要把规划请求自动升级为编码或发布。

检查相关代码和工作区状态，用一句话说明预期行为与验收方式，完成限定范围的改动并验证。用户只要求步骤或方案时，也说明实际改动后将怎样验收，并区分计划中的检查与已经执行的检查。只有当需求实际牵涉多模块、数据结构、架构或发布方式时，才转入完整路径。无需为小改动新建产品文档或测试框架。

开始前重读当前切片、相关源码及项目约定，确认工作区没有会被覆盖的用户改动。本地 Git 用于可回退的检查点；若尚无仓库，在开始实现前建立本地仓库。不要提交用户无关的改动，远端仓库按需设置。
开发新功能时，从主分支或项目现有的集成分支创建功能分支，在该分支实现和提交。先处理工作区未提交的用户改动，避免把它们带进功能分支或合并结果。明确的小修复可按项目习惯决定是否开分支。
实现当前切片，不顺手扩大范围。若遇到未决定的产品行为、影响数据的变更或明显偏离原方案的依赖，先说明影响并更新计划。
根据风险运行现有测试、构建、启动检查或页面操作验收。关键路径可增加有价值的自动化测试；简单改动可用明确的手动步骤。验证失败时诊断、修复并重查；没有执行的检查不得报告为通过。
将实际结果逐项对照当前切片和相关 P0 故事的验收条件；未满足的条件标为待完成。检查改动范围，更新必要的项目文档与本地 Git 检查点。
功能分支的相关验收和检查通过后，确认目标主分支状态，才将功能合并回去。若有冲突或主分支在开发期间变化，解决后对合并结果重新运行相关检查；失败则保持待合并状态并报告原因，不把未验证的结果标为完成。完成这个切片后再进入下一切片。

将确认后的关键决定留在项目 docs/。新项目通常用 docs/PROJECT.md 记录产品事实、首版范围和重要选择，用 docs/ROADMAP.md 记录切片与进度；技术和数据方案复杂时再单独维护架构文档。单项功能确实需要独立验收规格时才增加规格文件。
保持一个事实只有一个主要记录位置。已有项目优先更新其现有文档结构，避免建立内容重复的新文件。以后续做时，先读项目记录，再与当前代码核对；文档与代码不一致时指出差异。
用户改变需求时，说明受影响的故事、页面、数据、技术或里程碑；更新相应记录和未完成切片，不把旧决定静默覆盖。

按用户最初选择的交付终点收尾。若需要部署，先准备构建、环境变量示例、数据迁移、正式环境检查及回退步骤；创建真实资源、产生费用或正式发布前，说明具体操作并取得相应确认。不要将真实密钥写入代码、文档或提交记录。

交付时用简短清单说明：完成了什么、如何运行、实际做了哪些验证及结果、仍有哪些限制和下一步。无法运行或验证的部分须明确标注。