用途：这是一个与 AI 软件智能体协作、把自然语言想法做成可用产品的框架，重点不在写代码，而在于人作为高保真“翻译者”把需求讲清楚，用“最小可爱产品”（MLP）而非最小可行产品的思路，做出用户真正在意的软件。
主要能力与流程：
- 初始提示界定 MLP：先给宽泛概念，再用具体参考点锚定 AI 的设计与逻辑，例如“Airbnb 克隆”。同时明确核心动作，即用户必须完成的那一个主要交互，例如“用户应能直接购买某房源”。
- 高保真细化：UI 生成后，小改动不要只靠文字提示。若工具支持，直接可视化编辑文字和颜色，可即时改底层代码，省去整页重生成。加功能时描述 UI 组件与预期结果，例如“加一个按钮，点击弹出支付模态框”。
- 用“聊天模式”解卡：AI 引入 bug 或逻辑死循环时，从“命令模式”切到“聊天模式”。多询问而非命令，例如“这个函数具体怎么工作”“为什么这里得不到我想要的结果”。报错要具体：不要说“不能用”，而要说“我点 Y 时预期发生 X，实际却发生 Z，是不是缺了某个需求”。
- 过渡到功能：从“界面原型”走向“可用产品”，可让智能体接入后端即服务（如 Supabase）做数据持久化，明确要求处理用户会话的登录流程，并按具体说明接入 Stripe 等第三方支付。
内部“Lenny 模式”自查：定稿任何 AI 生成的功能前自问：这真的在解决某个具体用户的问题吗？我为什么现在要做这个功能？有多少人真有这个痛点？
示例：做复古手表细分市场时，输入“创建复古手表市场，在商品页加一个‘出价’按钮”，AI 可能生成“立即预订”按钮，此时改为“把‘立即预订’改成‘出价’，点击后弹出模态框，用户可输入金额和留言”。排障时不要说“登录不能用”，而要说“我接了 Supabase，点登录表单的‘提交’后控制台报 404、页面不跳转，能检查一下 auth 回调 URL 吗”，AI 会定位到重定向 URL 设置不匹配并给出修复。
适用场景：从自然语言生成初始原型、细化 UI、排障、接入后端与支付、以及判断功能取舍。
常见坑与限制：指令含糊——AI 不理解“为什么”，除非你说清“做什么”，对 UI 元素和数据状态要极度具体；遇到 bug 就放弃提示——应改用聊天模式让 AI 解释自己的代码，常能促使其重新理清逻辑；过度设计路线图——不要做六个月规划，找出当下最大瓶颈今天解决；被动交互——把智能体当成需要精确需求的初级工程师，而非魔法盒，你的价值在于品味与验证输出是否正确。资料未提供该技能的具体安装命令、价格或平台支持信息。