01 · About
前言
我有十年互联网质量保障经验，其中 2 年兼任项目经理对接交付，2 年主导线上问题治理，有几件事是我反复在做的：全链路项目统筹、多次从零搭起一个项目、长期跟一线用户打交道洞察用户痛点、靠数据做决策优先级。这些事看着分散，收敛下来其实是三件产品动作，从真实用户声音里洞察问题、把想法从 0 到 1 做成能跑的东西、用数据判断需要做什么不需要做什么。下面三个项目，就是我把这三件事各做了一遍。
第一个项目 QualityPilot，是我结合过去做测试的痛点、以及这么多年观察到的团队困境去做的一个产品。最大的特点是支持在需求评审和生成测试方案时调用历史业务沉淀和隐性知识来提效，提前规避风险。从需求定义到 Agent 架构、再到上线部署，由我全程独立完成。
第二个项目是产品研究，我选了一个自己常用的 App，把我觉得可以利用 AI 优化的功能，走了一遍「合成用户调研 → 竞品分析 → 模型选型分析 → PRD 输出」的完整流程。
第三个项目是数据分析，我选了 Kaggle 和阿里云天池的公开数据集，分别做了漏斗分析和 A/B 实验效果分析。
02 · Works
项目作品
QualityPilot — 需求质量协作 Agent
角色：产品定义 + 技术落地（独立完成） ｜ 形态：MVP 已部署，支持在线演示 ｜ 交付：完整 PRD、可运行系统
背景与问题
技术团队在需求阶段经常面临需求理解不一致、评审依赖个人经验、测试用例编写耗时等问题，导致问题往往到研发或测试阶段才暴露。QualityPilot 以对话式工作台为入口，将需求问答、需求评审和测试用例生成整合到同一流程中，帮助团队更早发现需求风险，并减少重复性的人工分析工作。
我的角色
- 产品侧：从真实需求协作痛点出发，完成问题定义、目标用户与场景拆解、MVP 范围设计、Agent 工作流设计、知识库/RAG 方案设计、结果质量控制与产品化验证。
- 技术侧：通过 vibe coding 独立搭建从文件解析、知识切分、向量检索、结果重排、工作流调用、结果验收到报告版本化的完整链路，并完成线上部署验证。
- 项目状态：QualityPilot 定位为「接近生产形态的 MVP」，已上线，可用于个人演示与低频真实使用。
核心能力与系统架构
用户输入自然语言提问 / 上传 PRD / 引用报告
上下文组装会话历史 / 当前文档 / 报告锚点
Planner 决策DeepSeek 判断任务关系与工具选择
RAG 增强pgvector 向量召回 / 检索结果排序优化 / 知识适用性校验
Dify 专业工作流需求评审 / 测试用例生成
结果交付Validator 验收 / 修复 / 版本化输出
三大核心功能
- 需求知识问答：基于历史 PRD、业务规则和测试经验回答需求问题；检索结果经过重排与知识适用性校验，只使用可用引用，避免跨领域知识误用
- 需求评审（6 维度）：围绕完整性、明确性、一致性、可测试性、隐含假设、用户体验输出评审问题；每条问题包含原文定位 + 风险说明 + 修改建议 + 验收口径
- 测试用例生成与迭代：基于 PRD 和可用历史知识生成结构化用例，覆盖主流程、异常、边界、权限和状态流转；支持报告追问、版本化重生成及 Markdown / CSV / XMind 导出
关键设计决策
- 从单次生成升级为连续协作：系统能理解用户是在新建任务、继续追问，还是基于上一份报告修改，避免每轮都让用户重新解释背景
- 知识库先校验再使用：历史资料不是检索到就直接引用，会先判断是否适用于当前需求，避免把不相关领域的规则带入评审结果
- 入库前可预览：管理员能先看到文档被如何切分、哪些内容被提权，再确认入库，降低脏数据影响后续 AI 判断的风险
- 生成结果要验收：评审和用例不是生成完就结束，会检查结构完整性、重点场景覆盖和用户明确要求；不满足时定向修复
- 多任务上下文隔离：不同 PRD、报告和待办状态按任务隔离，支持“刚才那份报告”“基于这个再细化”等自然表达，同时避免串项目
🤖
成果与反思
- 完成从想法到线上 MVP 的闭环：QualityPilot 已支持 PRD 上传、需求评审、测试用例生成、知识库管理、报告追问、版本化重生成和多格式导出
- 核心认知：AI 产品的价值，是把过去靠人工经验完成的复杂流程拆解出来，把依赖人工经验、反复沟通、流程繁琐的工作，抽象成 AI 可以协助完成的任务流程；识别哪些环节适合 AI 协助，哪些环节必须保留规则校验和人工确认
- 方法论沉淀：AI 产品落地不能只看单次生成效果，而要把用户表达转成可执行任务，拆解出「意图识别、参数抽取、信息完整性判断、任务路由、工具调用、结果校验、失败修复」等关键环节；只有每一层都有明确边界和评测标准，AI 才能稳定进入真实业务流程。
扇贝单词「长难句拍照分析」：体验 → 用户研究 → PRD
角色：产品全流程（独立完成） ｜ 交付：体验分析报告 + 竞品分析 + 多模型合成访谈 + 产品需求文档
📌 说明：本案例为完整的产品方法训练（以扇贝单词为研究对象），未在扇贝真实上线，重点展示「体验 → 用户研究 → 需求 → PRD」方法链路的完整性。
背景与问题
以「扇贝单词」为研究对象（2011 年上线、2 亿注册用户、考研/四六级/雅思备考场景头部 App）。从产品体验、用户研究、需求定义三个层次系统拆解，最终落到一个具体的功能需求上：备考用户在纸质真题上遇到长难句时，只能手动输入到 App 分析，打断学习流程、放弃率高——能不能拍照直接分析？
我的角色
- 独立完成「体验分析 → 用户研究 → 需求定义 → PRD 输出」全流程
- 体验分析：所有事实性内容均来自可公开验证渠道（App Store / 官网 / 专利局），并在报告中标注来源
- 多模型合成用户研究：7 大模型 × 4 画像合成访谈，验证需求方向与付费假设
体验分析 · 核心发现
- 业务逻辑：扇贝核心围绕「AI 学习 → 智能复习 → 用户激励」三大环节构建闭环，查过的生词可同步到扇贝阅读/听力，形成「单词 + 阅读 + 听力」三位一体学习生态
- 技术壁垒：自研「精简单词智能系统」获国家发明专利（ZL 2024 1 1008490.X），率先接入 DeepSeek，AI 转型动作领先行业
- 商业化结构：会员订阅（核心）+ 课程销售 + 贝壳虚拟货币，付费模式从买断转向订阅制
- 用户反馈短板：黑猫投诉/App Store 评论高频问题集中在自动续费、退款、客服响应——产品功能扎实，但付费后的服务体验是短板
第一手体验 · 选题起点
- 作者长期用扇贝阅读（读原著）+ 扇贝单词（背词），非备考人群
- 发现「长难句能力在扇贝内部割裂」：扇贝阅读顺滑，扇贝单词却要手动输入、单句解析
- 由此提出核心假设：功能形态与场景错配，目标人群主要是做纸质真题的考研用户（待验证）
多模型合成用户研究 · 需求验证
用 7 个大模型 × 4 类备考画像 = 28 段合成访谈（326 条消息），验证需求方向与付费假设，得出三条跨模型收敛的结论：
- 输入是最大敌人：用户被长难句卡住时，第一反应是手动打字 / 切 App 查词，折腾 7-15 分钟仍拿不到结构拆解——「拍照免输入」的诉求在 7 个模型独立复现
- 视觉化拆解是刚需：28/28 段对话都在方案描述前自发提出「颜色标注主谓宾、主干先行、从句归属」——需求先于方案存在，不是被引导出来的
- 付费锚点一致：可接受定价跨模型落在月付 20-50 元 / 年付 200-300 元区间
需求设计 · 核心需求
基于洞察输出完整 PRD（含功能需求 / 计费规则 / 异常流程 / AI 评测 / 上线标准）：
- 用户故事：「作为一名考研/四六级/雅思备考用户，我希望 拍照就能分析纸质真题中的长难句，以便 不打断精读流程，高效攻克难点。」
- 核心功能：「拍照 OCR + AI 分析」——OCR 识别多张图片（上限 3 张拼接），AI 自动标记长难句并按句子成分着色标注，点击查看结构拆解/翻译/词汇释义
- 关键设计决策：次数绑定「完整分析」而非技术环节——OCR 不扣次、点击「开始分析」预扣 1 次、失败自动返还；异常流程三原则「失败不扣次 / 能自动恢复的不打扰 / 每条提示带下一步」
- 成功指标：长难句分析功能使用率提升 ｜ 分析完成率 ｜ 会员转化率（每日免费 3 次 + 会员无限次模式）
- AI 上线标准：识别准确率/召回率/翻译准确率 ≥ 90%、成分标注 ≥ 85%，达标后灰度 10% 用户 2 周无回退再全量；评测数据集 ≥ 500 条人工标注样本
💡
成果与反思
- 产出 4 份可展示交付物：体验分析报告（数据标注来源）、竞品分析（用户自救工具链）、多模型合成访谈（7 模型 × 4 画像）、PRD（完整需求文档）
- 最大的认知收获：需求不是「用户说想要什么」，而是「用户未说出口的损失」——长难句分析功能一直存在，真正的痛点是输入方式，不是功能缺失
项目 3
数据分析漏斗归因A/B TestPython
数据分析报告：转化漏斗归因 + 营销策略 A/B 验证
角色：数据分析（独立决策 + AI 辅助） ｜ 工具：Python（pandas / scipy / statsmodels / matplotlib） ｜ 数据集：Retailrocket 275 万事件 + 阿里云天池 221 万用户
📌 说明：以上报告为基于公开数据集的分析练习（Retailrocket 电商日志 / 阿里云天池实验数据）。
两份报告遵循 问题定义 → 口径选择 → 数据清洗 → 归因分析 → 实验验证 → 业务建议 的完整链路。这不是我第一次用数据做决策：治理线上问题时，每个问题修不修、排多前，都是先盘影响面再定的，报告只是把同样的思路用在产品分析上。
电商购买转化漏斗分析
基于 Retailrocket 电商真实行为日志，用「商品级严格有序漏斗」口径拆解 137 天的 275 万行为事件，定位最大流失环节并设计验证实验。
核心发现：最大瓶颈是「浏览 → 加购」，流失率高达 97.71%；80.5% 流失用户只看 1 件商品，决策窗口中位仅 12 分钟
业务建议：详情页增加「相似商品推荐」+ 首屏强化关键信息，A/B 实验目标把浏览→加购转化率从 2.29% 提升至 2.54%
支付宝营销策略对照实验（A/B Test）
对 220.9 万用户进行双新策略对照实验，独立完成数据清洗、跨组污染样本识别、三步法显著性检验与稳健性分析。
核心发现：策略二点击率 3.07%，相较对照组（1.34%）提升 128%；实际差距是正常波动的 61 倍，p < 0.001，提升确定真实
业务建议：策略二优势显著，但两天内幅度波动较大，建议再观察 1 周确认稳定后全量推广
📊
数据思维沉淀
- 掌握「问题定义 → 口径选择 → 数据清洗 → 归因分析 → 实验验证 → 业务建议」的完整数据链路
- 能独立完成数据清洗与质量治理（如 A/B 实验中的跨组污染用户识别与处理）