geekx-app-forgelisted

# GeekX App Forge 把“我好像想做个东西”锻造成**值得做、范围清楚、体验克制、可直接开发**的产品交付包。 核心不是更快写 Spec，而是先证明：**为什么要做、真正要解决什么、最小产品是什么、什么绝对不做。** ## 硬门槛 1. **先查再问。** 能从上下文、文件、仓库、官方文档或公开资料确认的事实，不问用户。 2. **先怀疑需求。** “能做”不等于“该做”；AI Coding 降低开发成本，不等于降低维护和产品复杂度。 3. **至少 10 轮有效澄清。** **REQUIRED SUB-SKILL:** 使用 `geekx-grilling`，一次一问。每轮必须改变目标、范围、用户、成功标准、风险或路线；禁止凑数。 4. **推荐不等于确认。** 用户没有明确选择，就不能关闭分支。 5. **先自用，再商业化。** 先验证自己的高频真实痛点，再检查是否存在可复制人群、付费理由和差异化。 6. **先删再加。** 每个功能都问：`这是用户真正要的吗？删掉会不会更好？现在不做会怎样？` 7. **确认前不写 Spec。** 需求、非目标和主要风险未关闭时，不进入设计资产。 8. **交付必须可开发。** 已经调研过的静态数据、文案、分类、图标规范、App identity 不得甩给 Coding Agent 重新研究。 ## 阶段门 ### Gate 0 — 还原真正动机 先确认： - 为什么现在产生这个想法； - 当前真实场景和频率； - 不做 App 时用户如何解决； - 用户说要 A，底层是不是其实要 B； - 这是持续问题、一次性问题，还是“因为现在容易开发所以想做”。 随后进入至少 10 轮 `geekx-grilling`。读取 `references/grilling-and-reality-check.md`。 ### Gate 1 — Reality Check 对已经形成的主张做反方审查： - 伪需求风险； - 使用频率是否足够； - 是否已有更轻的替代方案； - 技术可行性与平台限制； - 最大复杂度税； - 最可能失败的假设； - 最低成本验证； - 什么证据会让我们停止。 证据不足时只能标记“待验证”，不能装成事实。 ### Gate 2 — Evidence Chain 对会改变决策的事实做调研。优先级： 1. 官方/一手资料； 2. 原始仓库、API、平台政策； 3. 真实用户/社区反馈； 4. 竞品与商业信号； 5. 二手分析仅作补充。 读取 `references/evidence-and-commercialization.md`。输出证据、反证、未知项和结论权限。 ### Gate 3 — Product Shape 把想法压成： - 目标用户； - 核心任务； - 高频触发场景； - 一句话价值； - P0； - 明确非目标； - 成功标准； - 最小验证； - P0.5/P1 只作为延期项。 如果 P0 仍像一个平台，继续删。 ### Gate 4 — Commercialization Lens 先保证自用价值成立，再回答： - 哪类人和我有同样痛点； - 为什么他们会持续使用； - 为什么现有方案不够； - 什么能力可形成差异； - 谁可能付钱、为什么； - 商业化会不会反过来污染 P0。 商业化不是强行加账号、订阅、云服务；只是保留未来路径。 ### Gate 5 — Design Freeze 若为 Apple 平台，读取 `refere