夜雨聆风For InnoX Students · Human-in-the-Loop
做产品不是搭积木，是种树——根要扎进真实的土壤（共情），主干要挺直（定义问题），枝叶才能自由伸展（构思与原型）。
§1 核心理念：你在这件事里
Human-in-the-Loop 说的不是「AI 做完了你来审核」——而是你在整个创作的循环里，是一个主动的、会思考的参与者。你提出直觉，AI 帮你澄清；AI 给一个方向，你质疑一个根本假设；你表达感受，AI 换个维度探索。你们彼此激发、彼此启发，产出的东西比任何一方独立工作都好。
人和 AI 不是上下游，是同一个 Loop 里的两个思考者。
去观察那些真正用好 AI 的人，你会发现他们不是在筛选 AI 的方案，而是在和 AI 对话。人说了一个模糊的直觉，AI 把它说清楚了；AI 给了一个逻辑自洽的方向，人质疑了一个 AI 不会质疑的假设。最终得到的东西，不是人想出来的，也不是 AI 想出来的——是他们一起想出来的。
🌿 人机协作的核心公式
更好的产品 = 人的元能力 × AI 的计算力
人的元能力（AI 做不到）：
批判性思维：质疑假设 共情力：感受用户的情绪 元认知：意识到「我在想什么」 提问力：好问题比好答案更重要
AI 的计算力（人追不上）：
知识广度：瞬间调取海量信息 不知疲倦：24 小时不累 快速生成：毫秒级方案迭代 格式执行：代码 / 文案 / 设计稿
两者相乘，不是相加。 没有人的元能力，AI 产出的是精致的平庸；没有 AI 的计算力，人的洞察停在模糊的直觉。
🌱 你在 Loop 里成长
批判性思维：每次质疑 AI 的方向，你在练习独立判断 共情力：每次审查文案的语气，你在训练对人心的敏感 元认知：每次自省「我真正想问的是什么」，你在看清自己的思维 提问力：好问题比好答案更重要——提问的能力在增长
🍎 产品中的人
不是「功能能不能实现」，而是**「用户需不需要」** 不是「界面好不好看」，而是**「用户感觉被理解了吗」** 每个文案、每个按钮、每个空态，都问：真实用户看到会怎么想？ AI 不懂人的感受——你的共情力是产品灵魂的来源
§2 创作六步法：像树一样循环生长
这六步不是「做完 1 做 2」的流水线。你随时可以回头——事实上，回头才是常态。AI 让回头的成本极低，所以不要怕推翻重来。
共情 → 定义 → 构思 → 原型 → 测试 → 沉淀 → ↺ 回到共情
Step 1 · 共情：找到真实的人（扎根土壤）
不要在脑子里想象用户。走出去和真实的人聊——哪怕只是 3 个人。问他们：「你现在最困扰的是什么？」而不是「你觉得这个功能有用吗？」
AI 怎么帮： 帮你设计访谈提纲、帮你整理访谈笔记、帮你从对话里提取关键洞察。但 AI 不能帮你感受——你要亲自听、亲自看、亲自感受用户的表情和犹豫。
我要做[方向]的产品。帮我设计一份用户访谈提纲，5-8 个问题，从开放式的经历聊起，不要问"你觉得这个功能好不好"这种引导性问题。Step 2 · 定义：把感受变成问题（找到主干）
访谈之后你会得到一堆碎片。让 AI 帮你归纳，但你自己判断哪个洞察最值得做。一个好的问题定义是：「[人群]在[场景]中因为[原因]而无法[目标]」。
Human-in-the-Loop 关键点： AI 会给你很多「看起来合理」的问题定义。你要用你的共情力判断——这个定义真的反映了用户的痛，还是只是逻辑上说得通？
以下是访谈笔记：[粘贴笔记]。请你：1) 找出 3-5 个关键洞察2) 每个洞察写一句问题定义3) 然后反过来追问我：你觉得哪个最重要？为什么？Step 3 · 构思：探索，不是筛选（自由分枝）
最常见的误区：把「构思」做成「让 AI 生成 20 个方案，我选 3 个」——这只是筛选，不是构思。
真正的构思是对话式的探索：你说一个感受，AI 给一个方向；你质疑那个方向，AI 重新想；AI 提出一个角度，你发现它触动了什么，然后你把自己的真实感受说出来——这才是发散。
💡 案例：发现「生命力」才是核心
在做一款帮助家里蹲用户回归社会的 App 时，AI 第一次给出的 PRD 是「帮助用户成长的微行动打卡产品」——功能完整，逻辑清晰。
但我们没有选，而是提出了疑问：「家里蹲用户会愿意使用行动打卡产品吗？」
这一句提问，让整个方向发生了转变。AI 不是在生成更好的 PRD——而是我们用直觉引发的追问，打开了真正的问题空间。
怎么触发这种共鸣探索：不要问「给我方案」，而是去描述那个感觉。
我有一种感觉，但我说不清楚——[描述你的模糊直觉]。你觉得这种感觉指向什么方向？先不要给具体方案，帮我把这种感觉说清楚。Step 4 · 原型：让想法可以被触摸（长出叶子）
用 WorkBuddy 快速搭建可交互的原型——HTML 页面或小程序。先做核心流程，不追求完美。
AI 怎么帮： 写代码、写文案、生成图片。但你来决定交互逻辑、页面流程、功能优先级。AI 不知道「先让用户看到什么」比「功能完不完整」更重要。
基于以下 PRD，帮我做最小可交互原型：[粘贴 PRD]。只要核心流程——用户第一次打开 → 看到什么 → 做什么 → 得到什么反馈。先不要做完整功能。Step 5 · 测试：让用户告诉你答案（经历风雨）
把原型给真实用户用。观察他们：在哪里犹豫了？哪里笑了？哪里直接关掉了？
Human-in-the-Product 关键点： 不要问「你觉得怎么样」——用户说不清。观察行为。AI 帮你记录和分析，但你要亲自看用户的表情和肢体语言。
Step 6 · 沉淀：让过程可复用（结出果实）
把走通的路存下来——对 WorkBuddy 说「把这个工作流保存为 skill」。下次遇到类似任务，AI 直接按你的方法做。
同时： 把调研记录、用户反馈、迭代日志都保存好。这些过程资产比最终产品更有价值——它们证明了你的思考过程。
§3 WorkBuddy 实操：和 AI 对话的正确姿势
WorkBuddy 是你的 AI 协作伙伴。用对方式，它会成为你最靠谱的搭档；用错方式，它会变成漂亮的废物生成器。
🚨 最常见的错误用法
打开 WorkBuddy 说「帮我做一个 XX 小程序」→ AI 生成一堆代码 → 你看不懂 → 改不了 → 放弃。
为什么失败： 你跳过了「共情 → 定义 → 构思」，直接让 AI 从零猜你要什么。AI 不知道你的用户是谁、他们需要什么、什么体验是好的。于是产出就是——用户不愿意用的产品。
更深的问题： 你在等 AI 给答案，而不是通过对话发现问题。好问题比好答案更重要。
1. 准备上下文：让 AI 认识你
WorkBuddy 有记忆机制。第一次使用时，告诉它你是谁、你在做什么项目、你的用户是谁。之后它会自动记住。
我是 InnoX 的学生。我正在做一个为[目标用户]解决[问题]的产品。我的价值观是[你关心什么]。请记住这些信息，后续所有工作都以此为准。2. 调研：先搜索，不急着动手
对 WorkBuddy 说「帮我调研 XX 方向」。它会自动搜索互联网、整理信息、保存调研报告。
为什么重要： 你的想法 90% 概率已经有人做过了。先搜能避免重复造轮子，也能找到别人的失败教训。
3. 需求澄清：让 AI 追问你自己
最关键的一步。不要让 AI 直接给方案——让它先追问你。
你是我的产品合伙人。请不要直接给方案，先连续追问，帮我澄清：1) 目标用户到底是谁？2) 他们最痛的点是什么？3) 现有方案为什么不够？4) 我们不做的是什么？5) 怎么判断做成了？追问到我回答清楚了再出 PRD。🧠 Human-in-the-Loop 的关键时刻
AI 会追问你。每一个追问都是帮你思考——不要敷衍回答。如果你答不上来，说明你需要回去和用户聊。
更重要的时刻： 当 AI 给出 PRD 后，先不要说「好的继续」。问自己：「这个 PRD 回答的，是我真正想问的问题吗？它里面有没有一个 AI 不会质疑但应该被质疑的假设？」 如果有，说出来——往往这才是最有价值的一步。
4. 开发：PRD 驱动，不是一句话驱动
有了清晰的 PRD 再开发。对 WorkBuddy 说「按这个 PRD 开始开发」，而不是「帮我做个 XX」。
AI 怎么帮： 拆任务、写代码、跑测试、修 bug。但你来决定功能优先级和验收标准。
5. 设计：先定方向，再出界面
让 AI 先理解你要什么感觉，再让它写界面代码。
帮我设计这个产品的界面。视觉方向：[如"光遇式的治愈空灵感" / "Notion 式极简"]。目标用户是[谁]，他们看到界面应该感到[什么情绪]。先给我 3 个视觉方向选择，不要直接写代码。6. 打磨：人的参与，让产品有温度
AI 生成的东西通常「功能正确但灵魂缺失」——按钮文案像说明书，空状态像报错，交互像填表。这一步必须你来。
🧐 检查清单：AI 生成的界面里，有哪些地方让你觉得"不对"？
按钮文案是不是命令式的（"完成" "提交"）？能不能换成邀请式的？ 空状态是不是在强调"你还没有"？能不能换成"即将有"？ 数字显示是不是在制造焦虑（"0 篇"）？能不能在数量少时隐藏数字？ 用户不想做时，有没有温和的退出方式？
§4 完整案例：用 WorkBuddy 做一个温暖治愈的微信小程序
以 Reconnect（帮助宅家年轻人重新出门的治愈小程序）为例，完整展示从 0 到 1 的创作过程。
P1 · 共情：理解宅家的年轻人
Reconnect 的目标用户是长期宅家的年轻人。在写一行代码之前，我们先做了最重要的事——和 3 个目标用户聊了天。
🎧 真实访谈发现
「我知道应该出门，但想到要社交就觉得累」 「一个人出去没什么意义」 「试过出门，但不知道去哪，在楼下站了 5 分钟又回去了」 「最怕被问'你怎么总是一个人'」 这些感受，AI 生成不了。只有亲自聊才能听到。
AI 在这一步怎么帮你： 对 WorkBuddy 说：「帮我设计一份访谈提纲，针对长期宅家的年轻人，了解他们出门的心理障碍」。然后带着提纲去真人访谈，回来把笔记贴给 AI：「帮我从这些笔记里提取关键洞察」。
P2 · 定义：从感受到问题
访谈后的关键洞察：核心障碍不是「不想出门」，而是「出门后不知道做什么」和「害怕被评判」。
问题定义
「长期宅家的年轻人在想要出门时，因为缺乏低门槛的行动指引和免于评判的心理安全感，而无法将意愿转化为行动。」
⚠️ 险些犯的根本错误：AI 给的方向，不一定是你的问题
AI 第一次给出的产品方向是「帮助用户成长的微行动系统」——PRD 完整，功能合理，逻辑自洽。
但认真看，这个方向回答的不是我们发现的问题。这个「成长」的方案预设了用户有社交的能力缺失；而真实访谈告诉我们，她的问题是对现实世界失去了期待感。
如果我们直接用 AI 的第一版 PRD，我们会做出一个用户「应该需要」但实际上不想要的产品。
🧭 如何判断 AI 给的方向对不对？
它回答的是不是我真正想问的问题？ AI 的 PRD 逻辑自洽 ≠ 它回答了正确的问题。回到你的用户访谈——用户最痛的那个点，这个 PRD 解决了吗？ 如果我不做这个方向，用户损失的是什么？ 如果答案是「损失了一个功能」——方向偏了；如果答案是「失去了一种感受」——方向对了。 这个方向里，有没有一个 AI 不会质疑但应该被质疑的假设？ 本案例中，AI 假设了「用户需要成长」——但真实用户需要的是「生命力」。
P3 · 构思：对话式探索的实战记录
这是 Reconnect 项目里最值得复盘的一段对话。重点不是「我们做对了」，而是：什么样的对话，能让人机协作产出比任何一方独立工作都更好的结果？
🤖 AI 第一版 PRD： 「帮助用户成长的微行动系统。目标：激活行动力、建立自律……DAU、行动完成率、打卡天数……」
🧑 你质疑（这句话改变了方向）： 「我的用户真的渴望建立自律吗？她会愿意用打卡 app 吗？我觉得她实际上最需要的是获得生命力。」
🤖 AI 回应后发现的核心洞察：
她的问题不是「不知道要运动、社交、学习」，而是：
现实世界 → 没有期待 → 没有惊喜 → 没有人在等我 → 没有事情值得我做 → 刷手机 → 更加空虚
所以产品不是「自律工具」，而是「让世界重新在呼唤你」。
🔍 复盘：这个转折为什么值得学习？
重点是：转折发生在人质疑 AI 假设的那一刻。AI 假设用户需要「成长」——逻辑上完全自洽。但人的共情力和对用户的直觉说：不对，她需要的不是成长，是生命力。
可迁移的理解： 人机协作中最重要的不是你的设计能力或编程能力，而是你在 AI 给出一个逻辑自洽的方案后，还能问出「它回答的是我真正想问的问题吗？」的能力。这种能力——我们叫它元认知——可以迁移到任何领域。
这次探索之后，我们确定了产品的核心设计决策：
| 微信小程序 | ||
| 每日一个任务 | ||
| 光遇式美学 | ||
| 星图系统 |
P4 · 原型：AI 搭建产品，你注入灵魂
Step 1：让 AI 搭建项目骨架
帮我创建一个微信小程序项目。使用云开发（wx.cloud）。主要页面：1) 旅程页 index（每日任务）2) 旅人日记 diary3) 星图 starmap4) 引导页 onboarding底部导航 tabBar 包含旅程、日记、星图三个 Tab。视觉风格：奶油色背景、玻璃拟态卡片、金色点缀。先生成完整目录结构和 app.json 配置，再逐页实现。📁 微信小程序的标准目录结构
app.js ← 全局逻辑（初始化云环境、全局数据）app.json ← 全局配置（页面列表、tabBar、窗口样式）app.wxss ← 全局样式pages/ ← 每个页面一个文件夹 index/ ← index.wxml / .wxss / .js / .json diary/ starmap/cloudfunctions/ ← 云函数（每个功能一个文件夹）WorkBuddy 会自动生成这套结构，你只需确认 app.json 里的 pages 列表和 tabBar 配置是否和你的设计一致。
Step 2：用 Skills 增强 AI 能力
WorkBuddy 支持安装 Skills（技能包）来扩展 AI 的能力：
| wechat-miniprogram | ||
| requirement-discovery | ||
| auto-dev | ||
| frontend-design | ||
| research-workflow |
怎么安装 Skill： 对 WorkBuddy 说：「帮我找一个可以[描述能力]的 skill」。WorkBuddy 会搜索 Skill 市场，找到后确认安装，之后直接用触发词调用。
Step 3：在微信开发者工具中预览和迭代
WorkBuddy 生成的代码保存在项目目录中（注意记下路径） 打开「微信开发者工具」→ 新建项目 → 选择项目目录 → 填入 AppID 左侧模拟器自动显示小程序效果，右侧可查看代码结构 发现问题 → 回到 WorkBuddy 描述问题（可直接贴错误信息）→ AI 修改 → 回到开发者工具按 Ctrl+S 保存 → 模拟器自动刷新 想看真机效果 → 点右上角「预览」→ 手机扫码 核心原则：做一点看一点——别等所有功能写完才看效果
💡 Debug 小技巧： 开发者工具底部 Console 标签页会显示报错信息。遇到错误直接复制错误内容，贴给 WorkBuddy：「遇到这个报错，帮我解决：[粘贴报错]」。
云开发常见坑： 如果调用
wx.cloud.callFunction失败，先检查app.js的wx.cloud.init({ env: '你的云环境ID' })是否填写正确。
P5 · 打磨：AI 做不到的事，你来
AI 做不到的事（需要你来做）：
感受用户看到某个文案时的情绪反应 判断两张图哪张更「温暖」而不是更「精致」 理解为什么「没有失败」这四个字会刺痛特定人群 创造有文化质感的细节（如中式留白 vs 西式信息密度） 决定「这个功能先做还是那个先做」背后的价值排序
实际案例：Reconnect 中「人」的修改
💛 Human-in-the-Product 审查框架
每个界面元素都过一遍这个检查清单：
1. 语气审查： 这个文案是命令还是邀请？是审视还是理解？ 2. 缺失审查： 空状态在强调「你还没有」还是「即将有」？ 3. 量化审查： 数字在制造焦虑吗？数量少时能隐藏数字吗？ 4. 自主审查： 用户有选择权吗？不想做时能温和退出吗？ 5. 共情审查： 如果你的目标用户看到这个，会怎么想？
P6 · 部署：让产品到达用户
innox-xxx），填入 app.js 的 wx.cloud.init({ env: 'xxx' }) | ||
cloudfunctions/ → 右键每个云函数目录 → 「上传并部署（云端安装依赖）」 | ||
tasks / diary） | db.collection('xxx') 保持一致 | |
fileID（格式 cloud://xxx），填入代码 | ||
🚀 开发阶段：不需要每次都提交审核
日常开发修改代码后，在开发者工具里按 Ctrl+S 保存，模拟器会自动刷新。只有当你想让别人（非开发者）测试时，才需要「上传」→「体验版」扫码——正式发布才需要提交审核。
⚠️ 最常见的部署踩坑
环境 ID 填错： wx.cloud.init里的 env 必须和控制台一致域名未配置： 小程序请求外部接口需要在后台「开发设置」里配置合法域名 云函数忘记部署： 改了云函数代码后必须重新上传部署，否则线上还是旧代码 图片用网络路径而非 cloud:// ： 小程序不支持直接引用 http 图片（需要配置域名白名单或用云存储）
§5 工具箱：WorkBuddy 内置能力 + Skills 配置
WorkBuddy 的能力可以通过 Skills 扩展。以下是学生做项目最常用的几个。
核心 Skills（直接说触发词即可）
| research-workflow | ||
| requirement-discovery | ||
| auto-dev | ||
| frontend-design | ||
| wechat-miniprogram | ||
| cloudstudio-deploy |
怎么安装新 Skill
帮我找一个可以[描述能力]的 skill。比如：「帮我找一个可以读取 Figma 设计稿的 skill」怎么保存自己的 Skill
当你走通了一个完整的工作流，把它保存下来让 AI 下次自动执行：
把刚才的工作流程保存为 skill，命名为"[skill 名称]"。这样下次遇到类似任务我可以直接触发。🌳 金句沉淀
人和 AI 不是上下游——是同一个 Loop 里的两个思考者。协作的本质是彼此激发，直到触动了真正重要的东西。
好问题比好答案更重要。AI 会让你停下来，但不会让你反省——反省只能你自己来。
缺了人的元能力，AI 产出的是精致的平庸；缺了 AI 的计算力，人的洞察停在模糊的直觉。两者相乘，不是相加。
你在这次协作中真正会带走的，不是产品本身，而是那种在 AI 给出逻辑自洽的答案后还能质疑的元能力。
每个文案、每个按钮、每个空态，都问：真实用户看到会怎么想？
AI Native 产品创作指南 · 2026 年 6 月 · Human-in-the-Loop · 像树一样生长
共情（扎根）→ 定义（主干）→ 构思（分枝）→ 原型（长叶）→ 测试（风雨）→ 沉淀（结果）↺
