demo-production — 演示-生产

演示生产 使用此技能将早期、模糊的项目想法转化为具体的、可运行的和可评审的演示。优化以减少用户提示同时保留与用户意图的一致性。默认行为：自主继续到第 3 阶段，交付交互式演示，然后停止以便用户评审。仅在用户确认后继续到第 4 阶段，除非用户明确要求端到端的自主完成。

核心原则 将模糊的提示视为正常输入，而不是阻塞器。慷慨地推断，但简要说明重要的假设。仅在答案会实质性地改变演示方向、技术可行性或核心工作流时才提问。保留用户可能的精神模型：识别他们想要看到的体验，而不仅仅是他们使用的字面文字。构建最小的演示以令人信服地展示核心思想。更喜欢具有模拟数据的连贯原型而不是过度构建的部分产品。在现有代码库中工作时，使用现有的项目模式、框架和依赖项。对于新的前端演示，创建实际可用的体验作为第一个屏幕，而不是营销登陆页面。当后端实现不必要时，使用模拟数据、模拟操作和本地状态。明确标记什么是功能性、模拟、模拟或留给生产版本的内容。

管道概述 遵循以下 4 阶段管道： 第 1 阶段：意图接收和重构 -> 如果核心意图不明确：询问或循环第 1 阶段 -> 如果足够明确：可选研究参考，然后第 2 阶段 第 2 阶段：规划和结构设计 -> 如果范围或结构不明确：循环第 2 阶段或返回第 1 阶段 -> 如果原型范围明确：第 3 阶段 第 3 阶段：交互式演示生产 -> 默认情况下始终停止以便用户评审 -> 如果工作流或意图错误：返回第 1 阶段 -> 如果结构或范围错误：返回第 2 阶段 -> 如果 UI 或交互需要更改：循环第 3 阶段 -> 如果批准：第 4 阶段 第 4 阶段：生产演示和边缘情况验证 -> 如果核心流程失败：循环第 4 阶段 -> 如果方向发生变化：返回第 3 阶段或第 2 阶段 -> 如果完成：最终交付

第 1 阶段：意图接收和重构 目标：将用户的原始提示转换为可操作的演示简报。 操作 评估提示的完整性。识别缺失的信息、风险和安全假设。重构可能的产品意图。决定是否需要澄清。决定是否需要外部参考研究。产生简洁的演示简报。

提示完整性 分类提示：低：用户只提供一个域、产品类别或粗略的愿望。中：用户提供一个目标和一些功能，但关键流程、用户、数据或平台选择缺失。高：用户提供受众、核心工作流程、平台、设计方向和接受期望。 评估这些维度：目标用户和上下文、核心工作、主要演示工作流程、平台和设备目标、数据源或模拟数据需求、视觉风格和语气、技术栈约束、所需集成、成功标准、非目标。

澄清决策 使用此规则：如果缺失的信息风险低，则做出合理的假设并继续。如果缺失的信息影响核心工作流程，则提出一个简洁的问题或提供默认路径。如果多个方向是合理的，但一个创建了明显更强的演示，则选择它并将其标记为假设。如果多个方向是合理的且互相排斥，则要求用户在 2 到 3 个选项中选择。不要暴露长的私人推理。仅总结决策、假设和风险。

示例总结：提示完整性：中 假设：单用户 Web 演示、模拟数据、桌面优先布局具有响应式行为 澄清所需：无

参考研究门 当它会实质性地改善演示时，执行专注的 Web 或 GitHub 研究。建议在以下情况下进行研究：用户命名或暗示一个已知的产品，例如“类似 Notion”，“Trello 风格”，“类似 Linear”，或“Cursor for X”。该想法属于成熟的产品类别，具有既定的工作流程，例如 CRM、看板、分析仪表盘、习惯跟踪器、客户支持工具、开发人员工具或内部运营工具。演示依赖于当前生态系统选择、开源库、UI 组件、API 或平台约定。用户明确要求竞争对手、开源或最佳实践参考。存在不确定性，关于是否命名项目、产品、API 或库仍然存在或是当前相关的。

跳过研究，当：演示简单，参考资料不会改变核心工作流程。搜索会增加复杂性而不会改善演示。用户明确表示不浏览或不使用外部参考。使用参考资料来提取：常见工作流程、信息架构、交互模式、术语、功能边界、开源实现想法、预期 UI。