메뉴
用户调研技能。当用户有想法但不确定用户是否真的需要、不知道找谁验证时使用。用最低成本做用户访谈和需求验证，输出可检查的调研结论。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
小象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 条问"有没有这种工具"——通过。
把你的产品想法告诉我，我帮你设计访谈提纲、判断找谁聊、整理访谈结论。
对话示例：