该skill从本人数十次开发经历中浓缩而来，适用于Codex / Claude Code / OpenCode 写代码（特别是刚开始尝试vibe coding的开发者），但觉得 AI“不太靠谱”的人。
我使用这个skill的真实经历
我想做一个“进阶版日记”App：记录日期、活动、人物、心理活动，一键导出。
如果按以前的习惯，我会直接让 AI 开始做计划。但这次 AI 先做了一件事：搜索 GitHub。
它找到了几个高度相似的成熟项目（Daily Nomie、Moodiary、StoryPad），并逐项核验：功能匹配、维护活跃度、许可证、数据边界。第一轮结论是“扩展现有项目”。
然后我补充了一个关键约束：必须是原生 Android、本地存储、系统指纹解锁。
约束变了，结论就变了：PWA 方案被否决，改为“只借鉴数据模型、原生自建”。这个决策救了整个项目——如果一开始就照着 PWA 框架写，后面要么推翻重来，要么将就着用不满足需求的方案。
最终这个 App 零返工地完成，通过了模拟器上的全部设备测试。
这不是 AI 变聪明了，而是它在关键节点上被“点拨”了一下。
问题：AI 很能干，但会在关键节点翻车
现在的模型足够强，强到会“顺手”重复造轮子：
- 动手前不搜开源生态，白白写一个已有项目（白干一场）
- 不问清需求就开工，做一半发现方向错了（返工）
- 十个模块同时铺开，最后主流程根本跑不通（空中楼阁）
- 说“测试全过”，其实只是编译通过（假完成）
- 把密钥写进代码、把 .env 提交到 GitHub（发布事故）
它缺的不是能力，而是关键节点上的引导。
Enough：一个只做“把关”的 Skill
市面上已有大而全的方法论（Superpowers、OpenSpec 等）。Enough 的思路相反：它不做执行工具，只做 5 道门禁。
- 没有复用决策，不开始自建 —— 动手前必须先给出“直接使用 / 使用并扩展 / 只借鉴 / 自建”的结论和证据等级（E1/E2/E3）
- 没有设计批准，不写代码 —— 一次只问一个真正影响方向的问题，其余用推荐默认值
- 最小纵向闭环未通过，不扩大并行 —— 先打通“启动 → 操作 → 持久化 → 展示”再全面铺开
- 没有逐项验收对账和证据，不声明完成 —— 每一项验收标准都要有结论，不允许“总体构建成功”掩盖单项缺口
- 没有安全和发布检查，不对外发布 —— 密钥、临时文件、调试配置逐一清点
整个 Skill 只有 4 个文件、300 余行，零依赖，工具无关（Codex / Claude Code / OpenCode 通用）。装不上任何框架也能用——缺能力时自动降级。
安装
gh skill install zhizhixia/enough enough --agent codex --scope user
# 或
npx skills add zhizhixia/enough --yes
然后像平常一样说“按我的开发流程推进 XXX”即可。
它帮你避开什么（对照表）
| 痛点 | Enough 的做法 |
|---|---|
| 白干一场 | 动手前强制开源评估，高度匹配就直接用 |
| 方向错了才发现 | 设计批准门禁，一次一问 |
| 什么都做、什么都不通 | 先打最小纵向闭环，再受控并行 |
| 假测试、假完成 | 要求真实运行证据 + 逐项验收对账 |
| 发布事故 | 发布前安全检查 |
| 同一个 bug 修不好 | 连续两次失败转根因分析 |
真实案例
仓库里有一个完整的脱敏案例：Mind Journal 端到端，记录了从开源评估 → 约束变化重评 → 设计批准 → 纵向闭环 → 设备验收的全过程，包括如实保留的未验证项。
最后
Enough 的理念是：模型的能力已经足够，网上的轮子已经足够，缺的只是关键节点上恰到好处的引导。
如果这个想法对你有用，欢迎 star、试用、提 Issue：github.com/zhizhixia/e…
