Vibe Coding Requirements

需求对齐：把想法说成 AI 能落地的需求

这是 vibe-coding-kit 的入口 Skill。它服务的人多半不写代码，靠 AI 把想法变成能跑的东西。最容易踩的坑不是技术，而是需求没说清，AI 朝着错误方向飞速实现。把需求说对，后面省一半返工。

套件里还有三个 Skill，在不同时刻用：

• 需要选技术栈 / 看不懂 AI 给的方案 → vibe-coding-architecture
• demo 验证过了、要做成正式系统 → vibe-coding-production
• 开发中 AI 越改越乱 / 改坏退不回去 / AI 忘事 → vibe-coding-survival（开发全程都建议配合它）

先确认：用户现在在哪一站？

判断方法：直接问。"你现在是想先跑个 demo 看看效果，还是打算做一个要长期运行、可能给别人用的正式系统？"

开问之前：先分诊，能推断的别问 ★

账本（流程状态）： 本 skill 是流程第一阶段 S1·需求对齐的"自助路径"（访谈式入口是 vibe-coding-prd，两者满足同一个 S1）。开始前读一下 docs/进度账本.md（不存在就照 examples/进度账本-模板.md 建一个，初始化到 S1）；这里的"分诊"结论就是账本里 S1.1 的轻/重判定，产出"需求基准描述"对应 S1 的核心退出条件。轻量 demo 不必逐步报门，但别跳过分诊和四要素。

新手最容易把对齐做成"审问"——一口气抛十几个问题，用户答到一半就烦了。好的需求对齐，问得少而准。 在准备每一个问题前，先过这条原则：

能自己（或从用户已经说的话）推断出来的，就别问；只把真需要用户拍板的留成问题。

具体两步：

1. 先分诊，定深度。 用一句话判断这个需求的"分量"，深度随风险走：
   • 轻（自己用、一次性、跑个 demo）→ 只问最关键的一两件事，快速进入"补全"。
   • 重（要给别人用、要长期运行、一旦出错有代价）→ 四要素逐项问，再做"数据旅程"深扫。
2. 能推断的，转成"推荐项"让用户一眼确认，而不是开放式问题。 比如用户说"帮我整理电脑里的图片"，你不必问"你用什么设备、要不要联网"——直接推断"本机运行、不联网、单文件脚本"，作为推荐默认值摆出来，用户点头或否决即可（见下方「推荐选项」写法）。

这一步把"深度自适应"落到实处：简单需求轻问快走，复杂需求才展开深问。

推荐选项写法：别让用户面对空白，也别替他做主

非技术用户最怕两件事：一是被一堆开放式问题问懵（"你想用什么技术？"——他哪知道），二是 AI 自作主张、闷头跑偏。正确的中间地带是：先把你的理解和默认假设讲出来，每条都做成"一眼能确认"的推荐项，用户点头或换一个即可。

固定结构（卡住时直接照搬）：

我先把需求理解一下，下面这些是我替你定的默认值（不对就直接说，我改）：

1. 谁在用：自己一个人用            [✓ 就这样]  [换一个：给同事/给客户…]
2. 它活在哪：本机双击运行的小脚本    [✓ 就这样]  [换一个：网页/常开服务器…]
3. 数据存哪：结果直接写回原文件夹    [✓ 就这样]  [换一个：要长期保存/要数据库…]
4. 成本：不调用任何要花钱的服务      [✓ 就这样]  [换一个：可以接受 AI 接口按量计费]

（最多 5 条，每条一句话。你不回，我就按这些往下走。）

• 每条假设 = 一道带推荐值的选择题，而不是空白填空。
• 默认值一律取最简可行那个（最省钱、最少依赖、最好维护）。
• 用户沉默 = 默认通过，但关键的、一旦定错代价大的（涉及钱、别人的数据、是否长期运行）必须等他明确点头。

这正是本套件"你有权说不""渐进式复杂度"两条信条的默认动作：不审问、不擅自做主，用推荐项把决定权轻轻交还给用户。

阶段零：先别急着写代码

写代码不是默认选项，是其中一个选项。开工前花两分钟做这个 gut-check，可能直接省掉整个项目：

1. 有没有现成的工具/产品已经能做这件事？ 先搜一圈。能买、能用现成 SaaS、能用模板配置出来的，就别从零造——自己造的每一行代码，将来都得自己（靠 AI）维护。
2. 这件事是一次性的，还是要反复做很多次？ 一次性任务（比如整理一批数据），也许直接让 AI 帮你把事做掉就行，不必做成一个长期软件。
3. 你要"自己用"还是"给很多人用"？ 自己用，标准可以很低；给别人用，复杂度、安全责任、维护成本都翻好几倍——确认你真需要，再开始。

如果这三个问题让你发现"其实不用写代码"，那是最大的省事。

阶段一：需求澄清（四要素框架）★ 核心

目标： 把模糊想法，转化成 AI 能精准理解、不会跑偏的需求描述。

1.1 先分清"想要什么"和"想解决什么"

非技术用户最常见的失误，是直接描述"我想要的功能"，而不是"我要解决的问题"。这会让 AI 锁死在你想象的某个实现上，错过更简单的做法。

先说问题，再说你设想的方案（如果有），并告诉 AI："这是我的设想，有更简单的做法可以推翻它。"

1.2 用四要素框架描述需求

逐条想清楚，再合并成一段话：

• 场景： 谁在用？什么环境、什么时候用？（一个人还是多人？手机还是电脑？）
• 目标： 最终要达成什么效果？解决前面说的什么问题？
• 约束： 逐条问自己——
  • 预算、我自己的技术能力、时间。
  • 要不要长期运行？大概多少人用、多大数据量？
  • 数据要不要长期保存？关机重开后，之前的数据还在吗？（这是 demo 和正式系统最大的区别之一，一定要早想清楚——很多人到上线才发现"数据怎么没了"。）
  • 会不会用到要花钱的服务？（调用 AI 接口、短信、云服务等多按量收费，先问 AI"这大概要花多少钱"。）
• 验收标准： 怎么算"做完了"？给出具体、能验证的标准。最稳的写法是 EARS 格式：「当【前置条件】，在【动作】时，则【可观察的结果】」——逼你把含糊词（"快"、"好用"、"正常"）换成能二元判断的事实。
  • ❌ 空话："系统运行正常" / "页面加载快"
  • ✅ 可验证："当我指定一个图片文件夹并运行，则文件夹里的图片按'年-月'分好了子文件夹，且原图都还在"
  • 更系统的写法（含数字阈值、安全类验收）见 references/方法论/PM-方法论.md 的「EARS 验收格式」。

把四要素合并成 100–200 字的需求基准描述。后续每次跟 AI 对话，都把它贴在前面，确保 AI 不偏航。

约束这一项最容易被新手省略，却最关键：需求里有约束，方案才能被约束。 你不告诉 AI 你只有一台小服务器、不会写代码、要控成本，它就默认按"大厂标准"给你一套又重又复杂、你根本养不起的方案。

1.3 哪些要写清楚，哪些留给 AI

业务上的事你说了算，技术上的事交给 AI。

1.4 demo 跑出来不对，怎么办（关键技能）

别去改代码，改你的描述。 描述"差距"，而不是指挥 AI 怎么改：

• ✅ 好："我点了提交按钮，但页面没反应，我期望它弹出一个'保存成功'的提示。"（现象 + 期望）
• ❌ 差："你把那个函数改一下。"（你不知道改哪、AI 也猜不准）

报错了，把完整的错误信息原样复制给 AI，加一句"这是报错，帮我看怎么回事"。看不懂没关系，AI 看得懂。

1.5 范例对照

反面例子（太模糊，AI 无从下手）：

"我想搭建一个开源项目。"

demo 级正面例子（轻量，验证想法用）：

场景：我一个人用，在自己电脑上跑。目标：我有一个文件夹全是杂乱图片，想按拍摄日期自动归类到子文件夹，省去手工整理。约束：我不会写代码，用 AI 写，希望双击就能运行，不想装一堆复杂环境，原图绝不能丢。验收标准：我指定一个文件夹，运行后里面的图片按"年-月"分好了文件夹，原图都在。

生产级正面例子（要长期运行、对外提供服务）：

场景：在本地 2核8G Linux 服务器部署，客户通过 HTTP 请求触发。目标：做一个卡密自动发货中间层，客户触发后系统验证身份、从库存分配卡密、转发核心平台完成服务、返回结果。约束：个人维护，不会写代码（用 AI 写），服务器只有一台，需长期稳定运行。验收标准：客户发起请求 → 返回卡密 → 核心平台确认服务完成；支持 token 鉴权、库存管理、操作日志。

（注意：这个例子"动到了钱和库存"，正式上线前应找真人工程师把关——详见 vibe-coding-survival 的「红线」。）

输出物： 一段 100–200 字的需求基准描述。把它存进你的「项目说明书」（模板见仓库 examples/项目说明书-模板.md）。