vibe-coding-survival — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited vibe-coding-survival (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.
这是 vibe-coding-kit 里贯穿整个开发过程的 Skill。前面几个 Skill 是"开工前想清楚"，但 Vibe Coding 真正翻车，大多发生在"开工后"。下面这些不属于某个阶段，要在整个开发过程里持续做。对不写代码的人来说，这几件事比任何技术选型都重要。
配套：vibe-coding-requirements（需求）、vibe-coding-architecture（选型）、vibe-coding-production（上线）。
流程角色： 本 skill 是harness.json里的always_on——不占流水线某一阶段，而是全程在跑。它和账本（docs/进度账本.md）的关系有两条：① 卡住、改坏、改不动时，把问题记进账本的「阻塞项」；② 红线（动钱 / 动别人隐私）是硬提示，一旦触及，不管在哪个阶段都要停下来提醒用户找真人把关——这条优先级高于"按门推进"。
AI 在长对话里会"忘事"——聊久了它会忘记早先的决定、自相矛盾，甚至改坏之前好的部分。对策：
做着做着冒出"要不再加个……"，AI 每次都说行，于是越加越多、越来越脆，最后全盘崩掉。对策：
非技术用户最痛的事：改着改着坏了，又退不回去，之前能用的也没了。对策：
项目-2024-06-能用版）。AI 经常很自信地说"已完成"，但实际没跑通——它不是骗你，是它自己也没真运行过。对策：
有些事，一个不写代码的人靠 AI 单干风险太高，一个 bug 就可能是真金白银或法律责任。碰到下面这些，强烈建议找一个懂行的人帮你过一遍，别全压在 AI 身上：
会判断"哪些我能自己搞定、哪些该收手找人"，本身就是行家的一部分。能看懂架构（见 vibe-coding-architecture）会让这个判断更准。各个 Skill 的产出，汇总进一个文档，这就是你的"项目说明书"。它有两个作用：① 让你随时看得懂自己的项目；② 每开新对话先整段贴给 AI，直接解决"AI 忘事"。
完整可复制的模板见仓库 examples/项目说明书-模板.md。骨架：
【项目说明书】
· 一句话：这个项目是做什么的
· 需求基准描述：……
· 选定技术栈：…… / 为什么选它
· 目录结构：……
· 开发规范要点：……
· 安全清单：……
· 部署步骤：……
· 验收清单：……
· "以后再说"清单：……
· 当前进度 / 还剩什么没做：……
· 能用版备份在哪：……让 AI 帮你维护它：
"每次有重要改动，提醒我该更新项目说明书的哪一部分。"
| 原则 | 含义 |
|---|---|
| 需求没说清，等于没说 | AI 会朝着模糊的方向飞速跑偏 |
| 先说问题，再说方案 | 描述方案会锁死 AI，描述问题才有更优解 |
| AI 会忘事 | 长对话里它会丢失上下文，靠项目说明书兜底 |
| 一次只推进一件事 | 范围一散，项目就脆 |
| 先备份，再动手 | 永远留一个能用的版本可退回 |
| 没亲眼跑通，就不算做完 | 别轻信 AI 的"已完成" |
| 复杂度是负债 | 每引入一个组件，都是在向未来借债 |
| 你有权说不 | AI 推荐的任何东西都是可选的 |
| 没有代价的方案不存在 | 不讲代价的推荐不可信 |
| 维护成本是最终裁决 | 一年后修不修得动，比什么都重要 |
| 懂"为什么"才算懂 | 用 6 维度拷问、追问取舍，把每个项目变成一次升级 |
| 动钱和动别人隐私，先找人 | 这两条红线别独自硬上 |
| 场景 | 话术 |
|---|---|
| AI 忘事了 | （开新对话）"这是我的项目说明书，请基于它继续：……" |
| demo 不对 | "我做了 X，看到的是 Y，但我期望的是 Z，怎么回事？" |
| 报错了 | "这是完整报错（贴上），帮我看怎么回事，用大白话说。" |
| 验证 | "我怎么自己验证它真的好了？给我具体步骤。" |
| 改坏了 | （从"能用版"备份恢复，然后）"我们从这个能用的版本重新来，这次只改 X。" |
| 记进度 | "每次有重要改动，提醒我该更新项目说明书的哪一部分。" |
以下约束来自项目治理配置harness.json和CLAUDE.md。 在声称"完成"之前，你必须逐条确认。
docs/项目说明书.md 中「以后再说清单」已存在（可以暂时为空，但不能缺这一节）docs/项目说明书.md 中「能用版备份在哪」建议填写docs/项目说明书.md 中「当前进度 / 还剩什么没做」建议填写（与 docs/进度账本.md 的当前阶段/步骤对得上）全部通过后声明： "✅ 硬约束自检通过：以后再说清单已建立，范围已守住，能用版备份已记录。"
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.