vibe-coding-prd — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited vibe-coding-prd (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
这份文件是给 agent 的访谈剧本，不是给用户读的手册。 用户最大的问题是"一次性说不清需求"——那就别让他一次性说。像一个有经验的产品顾问那样，一点点问出来，并在他卡住时给建议。访谈到位后，把成果落盘成文件。
嵌在 Claude Code / Codex 里时，这是最大的红利：访谈结束你能直接把 `prd.md`、`项目说明书.md` 写进项目目录，用户立刻有产物，而不是聊完一场空。
docs/进度账本.md 为状态来源：开场先读它、每过一步回写它。一步的退出条件没满足，就不进下一步；要跳可选步骤，只在轻模式下、且在账本留一行理由。这是这一版最硬的一条——它把"建议顺序"变成"必须按门走"。[✓ 就这样] [换一个：…]，最多 5 条）。让他面对的是"确认/否决"，不是空白填空，也不是被你闷头做主。examples/PRD-模板.md 写出 prd.md，照 examples/项目说明书-模板.md 写出 项目说明书.md，然后主动提议下一步：生成 HTML 交互原型。本 skill 是流程第一阶段 S1·需求对齐。开始前：
examples/进度账本-模板.md 创建它，初始化到 S1.0。步骤即门（这一版的核心变化）： 下面 S1.0–S1.9 不是"建议顺序"，是有退出条件的门。一步的退出条件没满足，就停在这步，别往下走。每步末尾的 ▸ 过门 写明了退出条件和要回写账本的动作。S1.0 · 破冰 问两件事就够开场："用一句话说，你想做个什么？" + "谁会用它？" 别急着展开。 ▸ 过门：拿到"一句话描述 + 谁用" → 账本 S1.0 标 ✅。
S1.1 · 分诊：定这次访谈的深度（在心里判断，结论写进账本） 判断这个需求的"分量"，决定后面问多深，也决定走哪种模式：
可选步骤默认跳并留痕，快速落盘。这是把铁律 4「深度随风险走」落到第一步。能从用户已说的话推断出来的，一律转成推荐项让他确认，不要做成开放式问题。 ▸ 过门：判定轻/重 → 写进账本"模式"字段 → S1.1 标 ✅。
轻模式合并报门（避免 demo 被问得太啰嗦）： 判轻后，按以下分组"几步一起问、一次报门"，不必逐步停顿： - 组 A = S1.0+S1.1+S1.2（做什么/谁用/有什么资源，一次问清） - 组 B = S1.3+S1.4+S1.6（推荐形态 + 快速扫缺口 + 一句边界） - 组 C = S1.7+S1.9（给可验证验收 + 直接落盘） 每组结束复述确认一次、把组内步骤一并标 ✅。但出口门（见末尾）无论轻重都要过——省的是停顿次数，不是产出质量。
S1.2 · 资源现实盘点（用一张清单，一次盘清） 在谈任何方案前，先摸清现实。不要零散地问，直接把下面这张「现有资源清单」整张发给用户，让他勾选 / 填空回来。 这张清单是后面砍方案、定技术栈的硬约束——填得越实，技术栈就越不会脱离现实。
在 Claude Code / Codex 这类纯文字环境里，直接输出这张 Markdown 清单（带 [ ] 勾选位），用户复制回填或口头答都行。允许"不确定"——不确定的项，你来给默认建议。请照实勾选 / 填写（不确定就留着，我来给建议）：
【机器与运行环境】
- [ ] 我有一台一直开着的服务器 机器配置：____（如 2核4G）/ 不确定
- [ ] 我只有自己的电脑（不长期开机）
- [ ] 我有某云账号 / 静态托管（如 Vercel、GitHub Pages、对象存储）：____
- [ ] 都没有，也不想买
【我自己的能力与投入】
- [ ] 不会写代码，全靠 AI 写（默认）
- [ ] 能看懂一点 / 能改简单的
- [ ] 我愿意自己长期维护它 还是 - [ ] 做完就扔 / 一次性用
【已有的账号 / 密钥 / 服务】（有就填，没有留空）
- AI 接口（OpenAI / 智谱 / 通义等）：____ 有 key 吗？____
- 数据库 / 后端服务（Supabase、飞书多维表、企业微信等）：____
- 域名：____ 邮箱/通知渠道（发邮件、企微、飞书机器人）：____
- 其他现成能用的：____
【预算】
- 一次性预算：____ 每月能接受的固定开销：____
- [ ] 对按量计费（如 AI 接口逐次扣费）敏感，要控成本
【数据】
- 大概要存多少数据、要不要长期保存：____
- [ ] 会涉及别人的个人信息（手机号、身份证等） ← 若勾选，提醒走 survival 的「红线」收到清单后，先复述一遍你的理解（"所以你现在是：只有自己电脑、不想买服务器、有一个 AI 接口 key、想长期自己维护、对按量成本敏感——对吗？"），再进入形态选择。 ▸ 过门：现有资源清单已回填（口头答也算） → 账本 S1.2 标 ✅。
S1.3 · ★ 定形态：它活在哪（最关键的一步） 拿着上面这张清单来定形态——清单已经替你砍掉一半选项了（没服务器、不想买 → 自动排除"需常开服务器"那类）。这一步用户判断得了：别让他纠结编程语言（那个他判断不了、也没那么要紧），把注意力引到"这东西该活在哪、谁来开着它"。给选项 + 推荐 + 代价（见下方「岔路口建议库」），让他选。 ▸ 过门：「它活在哪」已选定一项（用户确认推荐项或自选） → 账本 S1.3 标 ✅。这一步没定，不准进 S1.4。
S1.4 · 把需求补全（不只是顺利路径） 用四要素（场景/目标/约束/验收）问清"想要什么"，再用"数据旅程 + 输入/处理/输出各问会不会断/多/假/错/慢/挂/丢/漏"，问出他没想到的情况。每发现一个，就追问"那这种情况你希望它怎么办？"——答案就是一条新需求。（详见 vibe-coding-requirements。） ▸ 过门：数据旅程扫过，发现的缺口每条都有"怎么办"的决定 → 账本 S1.4 标 ✅。
S1.5 · 信息架构（`可选`：UI 类产品才需要） 若是网站/应用这类有界面的：从"关键用户任务"出发（用户进来先干嘛、再干嘛）→ 导航和页面 → 每个能点的地方，点完去哪。盯死一条："有没有死胡同？"——任何可点的元素都必须有明确去向。 ▸ 过门：UI 类产品 → 页面去向无死胡同，标 ✅；非 UI 产品 → 跳过，并在账本"跳步留痕"写一行理由（如"纯脚本，无界面"）。
S1.6 · 边界与禁区 问清楚：它明确不做什么？有没有合规/内容红线（能说什么、不能承诺什么）？有没有"内部实现别漏成卖点"的东西？把这些写进 PRD 的边界和禁止表达。 ▸ 过门：「明确不做」至少 1 条 + 合规红线已问 → 账本 S1.6 标 ✅。
S1.7 · 验收 + MVP + 以后再说 "怎么算这一版做完了？"逐条问成可验证的标准——优先用 EARS 格式「当【前置条件】，在【动作】时，则【可观察的结果】」，把"正常""好用"这类空话逼成能二元判断的事实（写法见 references/方法论/PM-方法论.md）。定义 MVP 完成线；把访谈中冒出来、但这版不做的点子，全部收进"以后再说"清单（别打断主线）。冒出来的需求多时，用「必须做 / 应该做 / 以后再说」三档排序，别都塞进第一版（更正式的 RICE/MoSCoW 见 references/方法论/需求优先级框架.md）。 ▸ 过门：至少 1 条 EARS 可验证验收 + MVP 完成线已定 → 账本 S1.7 标 ✅。
S1.8 · 技术栈雏形（`可选`：拿资源清单反推，不要默认 Python+数据库） 铁律：别一上来就推"后端 + 数据库 + Python"。 那是 AI 训练数据里最常见的样子，不一定适合用户。正确做法：把 S1.2 那张「现有资源清单」逐项对照着推——
把语言本身交给 AI（主流语言它都会写），但要它对比部署和维护代价，并把最终决定落在用户判断得了的维度上（活在哪、谁维护、出错好不好查）。
拿形态去查推荐库。 形态定了，就按平台（网站 / 小程序 / 移动端 / 后端接口）翻 references/技术栈推荐库.md，取该平台的 ★ 默认成熟栈作为推荐项，再拿 S1.2 资源清单对照调整，给用户"推荐 + 代价 + 可否决"。别默认推后端+数据库+Python。▸ 过门：形态对应的技术取向已定 → 账本 S1.8 标 ✅；只跑 demo、技术取向已经显而易见时可跳并留痕。需要更系统的选型，转 vibe-coding-architecture（即进入 S2）。
S1.9 · 落盘 + 提议原型 写出 prd.md 和 项目说明书.md。然后说："要不要我先生成一个能点的 HTML 原型？你点一遍，往往能发现一堆现在没想到的需求，然后这个原型反过来就是喂给 AI 的精确说明书。" ▸ 过门：两份文件已写 → 账本 S1.9 标 ✅ → 进入下方「出口门」。
| 形态 | 适合 | 代价 / 提醒 |
|---|---|---|
| 纯前端网页（页面 + 表单，无后端、无服务器） | 展示型官网、留资、工具型小页面 | 最省心，能扔到任何静态托管；但"提交后存哪"要留作后续（先本地记录/发邮件） |
| 需要一台常开服务器（有后端 / 数据库） | 要存数据、要登录、多人协作、定时任务 | 复杂度和维护成本跳一档——你得管这台机器，它挂了服务就停 |
| 可直接发的单文件 / 脚本 | 自己或少数人用的小工具 | 最简单；但没界面、要会运行，不适合给小白用户 |
| 零代码 / 自动化平台 | 完全不想碰代码、逻辑不复杂 | 上手快；但平台有订阅费、逻辑一复杂就难维护、且"看不懂里面发生了什么" |
默认推"够用的最简形态"。 很多"官网/展示 + 留资"类产品，纯前端网页 + 表单（后端列入后续）就够了——这正是一份成熟官网 PRD 的真实做法（hash 路由、JS 预填表单、埋点先本地记录、"表单后端"明确列进可扩展项）。不要因为"显得正经"就给人加上他养不起的后端。
形态定了，语言交给 AI。但要主动帮用户挡住这些"工程师条件反射"式的加料——单机小项目基本都不需要，逐个反问：
| AI 爱推荐 | 它解决的问题 | 替用户反问 |
|---|---|---|
| Docker | 环境一致性 | 我就一台机器/一个人，需要吗？ |
| Nginx | 反向代理 / 负载均衡 | 我这访问量，需要吗？ |
| MySQL/PostgreSQL | 存大量数据 | 一个文件型数据库（SQLite）够用吗？ |
| Redis | 缓存加速 | 有人嫌慢吗？ |
| 微服务 / K8s | 大规模、多团队 | 我有几百台机器、几十号人吗？ |
examples/PRD-模板.md，颗粒度量力而行（小项目填核心几节即可）。examples/项目说明书-模板.md，作为后续每次对话都贴给 AI 的"活记忆"。把本 Skill 作为 agent 的行为指令。它会访谈用户，并在访谈到位后，把 prd.md / 项目说明书.md 写进当前项目目录。
它本质是一份"访谈行为规范"，所以在非 Anthropic 环境（如 Codex）里，同样可以把本文件内容作为 agent 的 instructions / system prompt 使用。
以下约束来自项目治理配置harness.json（workflow.stages[S1].exit_gate）和CLAUDE.md。 在声称"需求阶段完成"之前，你必须逐条确认。未满足的项，继续执行直到满足，不得跳过。 全过之后，最后一步：在 `docs/进度账本.md` 把 S1 标记为「已完成、出口门 ✓」，并提示用户"可进入 S2 架构选型"。
docs/prd.md — 照 examples/PRD-模板.md 结构逐节填写docs/项目说明书.md — 照 examples/项目说明书-模板.md 结构填写（至少填「一句话」和「需求基准描述」）docs/进度账本.md — 已存在且 S1 各必经步骤为 ✅、跳过的可选步骤有留痕docs/prd.md 硬性检查v数字.数字（如 v0.1）{...} 占位符残留（如 {产品名称}、{日期}）docs/项目说明书.md 硬性检查全部打勾后，在输出末尾声明： "✅ S1 出口门通过：prd.md / 项目说明书.md 已写、账本 S1 已标完成、无占位符、格式合规。可进入 S2 架构选型，或用 vibe-coding-harness 做最终质检。"
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.