Menu
用户调研技能。当用户有想法但不确定用户是否真的需要、不知道找谁验证时使用。用最低成本做用户访谈和需求验证，输出可检查的调研结论。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
小象AI产品Builder技能包主入口。双模式：任务前路由（你的想法该用哪个 skill）+ 任务后导航（刚做完一个 skill，下一步该干什么）。帮助用户用好 AI Agent 把想法做成上线的产品，覆盖想清楚/做出来/跑起来三阶段。触发方式：/xxskill、"帮我做产品"、"我不知道从哪开始"、"下一步怎么走"。
判断产品里要不要内置 AI 能力。当用户的产品想法已经过需求澄清，在决定要不要给产品加 AI 功能时使用。通过 4 个问题的决策链，15 分钟内给出"加 AI 功能 / 用规则功能 / 混合 / 不加"的结论，附判断标准与 AI 执行约束。
性能优化技能。当产品在低端机卡顿、接口等待白屏、历史列表滚动掉帧、或需要优化帧循环计算、运动交互时使用。覆盖典型性能场景（含 AI 调用的流式渲染、长等待、长列表、冷启动、节流防抖）和零体验降级原则，按P0/P1/P2分级优化，输出可直接应用的参考实现。
最小后端技能。当产品需要调用 AI API（或第三方 API）但不想搞复杂后端时使用。只讲最小三件套：API 代理（隐藏 key）、key 管理、简单缓存降本。不碰微服务、不碰数据库设计。
数据中心与AI评估方法论技能。当产品的 AI 能力需要提升输出质量、用户只靠改prompt碰运气、或缺乏系统化的评估方法时使用。基于Andrew Ng的Data-Centric AI思想，建立评估集、做离线/在线评估、绑定prompt与数据版本，用数据迭代而非盲目调prompt。输出数据迭代日志。AI 按本规范维护评估集与日志，用户按判断标准判断质量好坏。
安全与合规技能。当产品收集用户数据、涉及 AI 输出内容、准备提交微信小程序审核时使用。覆盖通用合规（隐私、备案、类目资质）和 AI 专属合规（内容审核、AI 输出安全），输出上线前合规检查清单。
| name | xx-research |
| description | 用户调研技能。当用户有想法但不确定用户是否真的需要、不知道找谁验证时使用。用最低成本做用户访谈和需求验证，输出可检查的调研结论。 |
在写代码之前，先用 5-10 个真实用户验证"有人真的需要这个"。
帮你在 1-3 天内完成最低成本的用户访谈和需求验证，输出一份可检查的调研结论。
调研不是"问问朋友觉得怎么样"，而是用结构化提问挖出用户的真实行为和痛点，避免做出"只有你觉得好"的产品。
呼应 xx-clarify：那个技能把模糊想法澄清成结构化问题，这个技能去验证这个问题是不是真需求。
AI 执行约束： 调研结论必须有"用户原话"作为证据，不能只有 AI 总结。原话是判断结论真伪的依据。
| 不调研的常见死法 | 调研能避免什么 |
|---|---|
| 做了没人用的功能 | 发现痛点是假的 |
| 自己脑补需求 | 听到用户真实原话 |
| 砍错功能 | 知道哪个痛点最痛 |
| 定错价格 | 知道用户现在愿意为替代方案付多少 |
数量：5-10 人就够。 Mom Test 的经验：5 个深度访谈 > 50 份问卷。
目标用户画像要素：
禁止找这些人：
| 不该找 | 原因 |
|---|---|
| 身边熟人 | 会说好话照顾你面子 |
| 同行 / 同事 | 脑补需求，不是真实用户 |
| 给你点赞最多的人 | 粉丝不是用户 |
该找的人：
铁律：禁止问"你会用吗""你觉得这个功能好不好"——会得到假答案。
人会本能地给肯定回答以示礼貌，问"你会用吗"等于白问。
| 坏问题（得到假答案） | 好问题（得到真实行为） |
|---|---|
| 你会觉得这个功能有用吗？ | 你上次遇到这个问题是怎么解决的？ |
| 你会用这个产品吗？ | 你现在用什么工具做这件事？ |
| 你愿意付多少钱？ | 你现在为这件事花过钱吗？花了多少？ |
| 这个功能好不好？ | 这个工具哪里最让你不爽？ |
| 如果有 XX 你会用吗？ | 你最近一次为这件事头疼是什么时候？ |
判断标准： 好问题问的是过去发生的行为，坏问题问的是对未来的想象。
AI 执行约束： 访谈中如用户开始评价"你的方案好不好"，立刻拉回行为问题："你刚才说你现在用 XX，那次具体是怎么用的？"
原则：记原话和行为，不记你的解读。
| 该记 | 不该记 |
|---|---|
| 用户原话（带语气词） | "用户似乎觉得..."（你的脑补） |
| 具体行为和场景 | 抽象总结 |
| 用户犹豫 / 皱眉的瞬间 | "用户很满意"（你判断的） |
| 数字（花了多少时间 / 钱） | 模糊形容词 |
记录方式：
把 5-10 份访谈原话整理成结构化假设：
用户群体：[具体到职业 + 场景]
痛点：[用户原话 + 出现频次]
现有方案：[用户现在用什么]
不满：[原话里反复出现的抱怨]
我的方案凭什么更好：[对应痛点 1:1 映射]
判断标准：
访谈只能证明"有人有这个痛点"，还要验证"他们真的会用你的方案"。
| 验证方式 | 成本 | 适合验证什么 | 通过标准 |
|---|---|---|---|
| 微信群发问 | 1 小时 | 痛点是否普遍 | ≥10 人附和 |
| 小红书 / 知乎发帖 | 半天 | 痛点共鸣度 | 评论里出现"求解决方案" |
| 落地页 + 留资 | 1-2 天 | 付费意愿 | 留资率 ≥5% |
| 手工 MVP（微信群服务） | 3-7 天 | 核心流程是否跑通 | ≥3 人愿意持续用 |
| 截图 Demo | 半天 | 方案是否对路 | 用户问"什么时候上线" |
优先级： 先做成本最低的，通过再做下一个。前一个不通过就别往下走。
调研结论必须能回答以下问题，缺一项都不算完成：
AI 执行约束： 调研结论未通过以上 8 项中的任意一项，必须明确标注"该项证据不足"，不能补全脑补。
目标用户： 平面设计师 / UI 设计师，每周做配色方案 3 次以上
访谈原话摘录：
提炼假设：
最低成本验证： 小红书发帖"设计师们你们取色后怎么命名的？"，48 小时收到 23 条评论，其中 15 条抱怨命名麻烦，4 条问"有没有这种工具"——通过。
把你的产品想法告诉我，我帮你设计访谈提纲、判断找谁聊、整理访谈结论。
对话示例：