A
我们看到的真问题
- 找不到
知道想完成什么，但不知道该搜什么、该信哪个项目。
- 装不上
README 默认你会命令行、Python、Node、驱动和环境变量。
- 配不好
参数、格式、模型、路径，一步填错就跑不出结果。
- 不敢信
陌生脚本、第三方安装器、许可证和隐私边界不透明。
“用户要的不是一个仓库链接，而是一个能打开、能完成任务、下次还能用的结果。”
创新创业基础 · 实践项目 · 2026
把“想做的事”
变成能用的工具
拾用 OpenFoundry 是面向没有编程与部署经验的 Windows 用户的开源工具交付平台。说一句需求，平台完成发现、选型、配置和验收。
输入
把商品图统一成 800×800
自然语言，不需要命令
交付
图片批处理 · 已准备
参数、入口、验收清单
向下查看完整实践过程
课程展示站 · 演示数据与真实产品边界已标注
3个已接入工具
图片 / 影音 / 文本
图片 / 影音 / 文本
24条公开来源
策划案附录可核对
策划案附录可核对
2种模型路径
本地 Ollama / 外部 API
本地 Ollama / 外部 API
9/12需求初筛自评
进入补充验证
进入补充验证
1个 Windows 便携包
不要求预装 Node / Python
不要求预装 Node / Python
01 / 项目概览
不是再做一个软件导航站
开源工具很强，但普通用户往往卡在发现、判断、安装、配置、验证五道门。拾用把“需求”作为入口，用 AI 选型、本机适配和验收清单补齐最后一公里。
B
我们给出的解法
- 1说出目标
用自然语言描述要完成的事，而不是先学工具名。
- 2AI 理解与选型
检索公开项目，比较许可证、维护状态和实际能力。
- 3本机适配与配置
把参数、运行环境和入口准备好，不把命令丢给用户。
- 4打开工具并验收
预览、下载、重开、停模型，分别记录是否真的通过。
当前交付
0.2.2 已跑通“找工具 → 我的工具 → 设置”的本地闭环，并把图片、影音、文本三类高频任务做成可重复使用的工具。
真实可运行
不是静态概念稿：三个工具能选文件、跑任务、预览和下载结果。
本机优先
图片与影音处理在本机完成，不上传素材；模型可本地可外部。
可验收
安装、运行、重开、停模型分别验收，避免把“找到项目”当成“交付完成”。
可扩展
配方与适配器分离，同类工具优先通过配置接入，而不是每次重写。
02 / 趋势洞察
PEST 四维探测器
把“开源工具交付”放回政策、经济、社会和技术四个维度里看：机会窗口在扩大，但真正的缺口不在工具数量，而在普通人的使用门槛。
P
政治 / Policy
数字中国与开源生态被持续鼓励
- 《“十四五”数字经济发展规划》提出加快数字技术与实体经济融合。
- 《数字中国建设整体布局规划》把数字基础设施和数据资源体系作为基础。
- 开源、人工智能与中小企业数字化是政策高频词；许可证、数据安全与网络安全是监管红线。
工具国务院政策文件词频分析 · 政策关键词云
判断：政策顺风，但“能装”不等于“合规”。平台必须展示来源、许可证与安全边界。
E
S
社会 / Society
AI 用户规模上来，数字技能鸿沟还在
- 截至 2024 年 12 月，我国网民规模 11.08 亿，生成式人工智能产品用户规模 2.49 亿（CNNIC 第 55 次报告）。
- 个体创作者、学生、小微商家和灵活就业者，越来越需要图片、影音、文本的批量处理。
- “会提需求”与“会配环境”是两种能力；后者正是普通用户被挡在门外的地方。
工具微博热点话题情感分析 · CNNIC 互联网发展报告
判断：需求在从“有没有工具”转向“能不能直接用起来”。
T
技术 / Technology
本地推理成熟，集成层仍然稀缺
- Ollama、llama.cpp 等让本地模型在普通 Windows 电脑上可运行，隐私和成本更有优势。
- GitHub 2024 Octoverse 显示生成式 AI 项目数量快速增长，开源供给持续变多。
- 但“能跑”与“普通人能装好、配好、验证结果”之间，仍缺一层交付与适配。
工具Gartner 新兴技术成熟度曲线 · GitHub Octoverse
判断：技术不是最大瓶颈，产品化交付才是。
项目组产出
政策趋势与热点词汇
从公开政策、行业报告和平台数据中提炼的高频词。它们共同指向一个方向：数字化要下沉，交付要完整。
数字中国
人工智能+
开源生态
中小企业数字化
本地推理
AI PC
数字技能
数据安全
许可证合规
降本增效
灵活就业
个体创作者
数据口径：公开资料整理，具体报告以来源链接为准；市场规模与用户测算见下一节，属于课程推演，不构成市场结论。
03 / 行业认知
用五角星模型看行业
市场规模、行业格局、产业上下游、领头羊企业、用户与痛点——五个角共同回答一个问题：拾用应该站在哪里，靠什么形成壁垒。
开源工具交付需求 → 可用结果
01市场规模谁需要，值多少钱
02行业格局替代方案与空位
03产业上下游供给从哪来
04领头羊企业谁已经跑在前面
05用户与痛点谁最痛，痛在哪
01
市场规模：先算可服务的人，不画大饼
采用“经营主体 → 有批处理需求 → Windows 非技术用户 → 愿意付费”的自下而上口径。所有比例都是团队假设，待访谈与预售校准。
| 口径 | 测算 | 金额 |
|---|---|---|
| TAM潜在市场 | 1.8 亿户经营主体 × 10% 有图片/影音/文本批处理需求 ≈ 1,800 万用户 × 199 元/年 | 约 35.8 亿元 |
| SAM可服务市场 | 1,800 万 × 20% Windows 非技术用户 ≈ 360 万用户 × 99 元/年 | 约 3.56 亿元 |
| SOM首年可获取 | 1,000 名付费用户 × 99 元/年 | 约 9.9 万元 |
关键假设
用户愿意为“省时间、少踩坑”付费；平台能把首次成功使用时间压到 30 分钟以内；适配器可以复用，边际交付成本随规模下降。
02
行业格局：空位在“交付完整度”
技术 / 适配门槛 →
交付完整度 →
工具导航 / 教程
包管理器
Pinokio
AI 编程助手
拾用
导航站解决“知道”，包管理器解决“装”，编程助手服务开发者；拾用要补的是“非技术用户从需求到可用结果”的完整交付。
03
产业上下游：站在开源供给与普通用户之间
上游
↓
中游
↓
下游
平台不生产模型和开源项目，价值在于降低理解、安装、配置与验证成本，并对交付结果负责。
04
领头羊企业：学习路径，而不是正面硬碰
- Pinokio本地 AI 应用安装器
验证了“图形化安装 + 本地运行”的需求，但更偏 AI 应用目录。
- Homebrew / Chocolatey / Scoop包管理器
解决开发者的安装效率，默认用户懂命令行和依赖。
- GitHub开源项目发现
供给最全，但不负责普通用户的最后一公里。
- Ollama本地模型运行时
把本地推理变简单，仍是组件，不是完整任务交付。
拾用的差异化不在“收录更多项目”，而在“把一次交付做完整，并能复用”。
05
用户与痛点：五类人，一个共同卡点
A个体电商卖家
上新频繁，图片尺寸、水印、编号重复劳动多。
B学生 / 研究者
要处理数据、文档、音视频，但不想学开发环境。
C内容创作者
剪辑、转码、提取音频，工具多但流程碎。
D小微团队业务人员
需要可重复的内部工具，没有专职 IT。
E技术爱好者
愿意尝试新项目，但不想每次从零配环境。
共同卡点
不知道选什么 → 装不上 → 配不好 → 不敢信 → 换电脑又要重来
结论
机会不在“再做一个导航站”，而在把开源供给变成普通用户能验收的交付。壁垒由三件事构成：适配器复用、验收证据、用户信任。
04 / 需求初筛
先排除伪需求，再谈产品
我们用课程给的 6 项标准给项目打分。结论不是“完美真需求”，而是“方向成立、证据不足、需要补充验证”。这比自嗨式满分更接近真实创业。
用户诊断模板
我解决的是 没有编程与部署经验的 Windows 用户 的 “想用开源工具但装不上、配不好、不敢信” 问题，具体的场景是这样的：个体电商卖家每次上新 20–50 张商品图，需要统一尺寸、加水印、按编号保存；学生需要把会议视频转成音频；创作者需要把长文整理成摘要。
9/12
当前自评
需优化
补充验证
补充验证
不是伪需求：用户、场景、替代方案都成立。但付费意愿、使用频率和用户主动提及痛点的证据还不够。
需求真伪评分
六项标准，每项 0–2 分
维度得分现有证据下一步
用户与场景定义用户标签具体、场景可还原2已锁定非技术 Windows 用户，列出电商上新、会议转写、视频转音频等场景用 10 次访谈把场景写成任务脚本
付费意愿测试预付率 ≥10%，退款率 ≤5%1尚未做真实预付；只有“愿意省时间”的口头判断3 个预付测试 + 价格锚点
替代方案与成本成本 ≤ 竞品且满意度高 1 分2替代方案：手动教程、包管理器、Pinokio、远程人工配置；拾用减少来回沟通记录一次任务的时间与人工分钟
道德风险无高风险且规避措施完备2展示来源/许可证；安装需人工批准；本地优先；不静默执行未知命令补第三方代码风险提示与卸载清单
频率验证高频需求（每周 ≥3 次）1电商上新可能高频，但学生/创作者场景频率差异大2 周使用日记，分场景统计
用户感知≥70% 用户未提示时主动提及痛点1尚未做无提示访谈，不能声称用户“痛到需要”5 个开放式访谈 + 关键词编码
0–5 伪需求6–9 需优化≥10 真需求
判定：6–9 分，需优化并补充验证。当前最重要的不是加功能，而是拿到真实用户的时间、频率和付费证据。
伪需求七信号
逐项自检，避免把“很多人不会装”直接当成需求。状态：不成立 / 待验证。
无细分客户 不成立
无创新杠杆 不成立
无付费意愿 待验证
无场景锚点 不成立
无社会价值 不成立
无持续频率 待验证
无感知 / 替代方案 待验证
自检
伪需求识别清单
- ✓
是否在解决一个“不存在的问题”？否。安装与配置门槛真实存在。
- ✓
用户是否真的“痛”到需要额外工具？待验证。需要无提示访谈。
- △
方案是否比现有方式效率提升 10 倍？待测。目标是把首次成功时间压到 30 分钟内。
- △
用户是否可能用更简单/免费的方式绕过？可能。在线工具、PS 动作、包管理器都是替代。
- ✓
是否与用户的核心价值观冲突？否。本地优先、来源透明。
- ✓
是否有一群用户会强烈反对？暂未发现。但第三方代码风险需说明。
- △
用户是否愿意为“偶尔发生”的需求付费？待验证。优先找高频场景。
- ✓
商业模式是否依赖用户的高道德自律？否。不依赖绕过规则。
- ✓
项目是否依赖用户突破规则？否。许可证与来源可核对。
- △
是否有足够多用户愿意承担道德/法律风险？不需要。我们不把风险转嫁给用户。
- △
需求是否依赖“一时冲动消费”？不是核心。但需要验证持续使用。
- ✓
是否与公共空间规则或政策冲突？否。数字技能与开源使用方向一致。
画布
需求假设验证画布
目标用户
没有编程/部署经验的 Windows 用户：个体商户、学生、创作者、小微团队业务人员。
具体场景
电商上新批量改图；会议视频提取音频；长文整理成摘要；第一次使用某个开源能力。
核心痛点
找不到、装不上、配不好、不敢信、换电脑重来。
现有替代
教程 + 手动安装、包管理器、Pinokio、在线工具、远程人工配置、直接放弃。
价值主张
说一句需求，得到能打开、能完成任务、能继续使用的工具。
付费假设
按次 9.9 元 / 月付 29 元 / 年付 99 元；先验证预付，不先做订阅系统。
最大风险
用户不愿付费；AI 选型错误；第三方代码安全；Windows 环境碎片化。
验证方法
10 次访谈、3 个预付测试、5 次可用性测试、2 周使用日记、30 条冻结需求。
下一步
先做 10 次访谈和 3 个预付测试；如果预付率低于 10%，回到场景选择，而不是继续加功能。
0110 次访谈
5 个目标用户 + 5 个非技术用户；不问“你会用吗”，问最近一次怎么解决。
023 个预付测试
9.9 元单次 / 29 元月付 / 99 元年付，观察真实支付而非口头意愿。
035 次可用性测试
从“说需求”到“拿到结果”，记录时间、卡点和人工介入。
042 周使用日记
统计每周使用次数、复用场景和放弃原因，验证频率。
05 / 设计思维
从共情到 MVP 的完整过程
二手资料、用户关系、痛点聚类、HMW、POV、创意收敛、4W1H、关键假设与 MVP——课程要求的每一步，都在这里留下可核对的产出。
5.1
二手资料研究：先建立基本认知
不少于 200 字，覆盖用户背景、行为、需求与痛点。
公开资料显示，我国网民规模已达 11.08 亿，生成式人工智能产品用户规模 2.49 亿；数字经济规模约 53.9 万亿元，占 GDP 比重约 42.8%。与此同时，全国登记在册中小企业超过 6000 万户、个体工商户约 1.25 亿户。供给端，GitHub 上的生成式 AI 项目持续增长，Ollama 等本地运行时让普通电脑也能跑模型；需求端，个体商户、学生、创作者和小微团队都在产生图片、影音、文本的批量处理需求。
但“有工具”不等于“用得上”。我们对项目已有的 24 条技术来源、公开报告和真实原型验收记录做了交叉阅读，发现普通用户的卡点集中在五处：不知道该搜什么；看不懂 README 和许可证；装不上依赖；参数太多不知道填什么；失败后不会恢复。现有替代方案包括图文教程、包管理器、Pinokio、在线工具和远程人工配置，它们分别解决“知道”“装”“跑”或“单次处理”，但很少对“普通用户的一次完整交付”负责。
因此，本项目的机会不是再做一个工具目录，而是把发现、选型、配置、验收串成一条可重复的路径。这个判断仍需真实访谈和付费测试校准，不能仅凭公开数据下结论。
主要来源
- CNNIC：《第 55 次中国互联网络发展状况统计报告》，2025 年 1 月。
- 中国信息通信研究院：《中国数字经济发展研究报告（2024 年）》。
- 工信部、市场监管总局：中小企业与个体工商户登记数据。
- GitHub：《Octoverse 2024》；Ollama 官方文档。
- 项目内部：策划案附录 24 条公开来源、0.2.2 原型验收报告。
注：公开数据用于建立认知，不代表本项目已完成市场规模验证；用户访谈与付费测试仍待执行。
5.2
用户关系网络图
谁影响核心用户？谁提供供给？谁决定信任？
直接相关人
间接相关人
核心用户
5.3
痛点聚类：12 张便利贴，4 个痛点群
基于共情资料写下痛点，合并重复项，按场景归类，每人 3 票选出优先级。
发现难
不知道搜什么、信哪个不知道用什么关键词搜
6 票搜到很多项目，不知道选哪个
8 票 · 优先README 全是英文和术语
5 票安装难
依赖、版本、失败恢复装到一半报错，不知道缺什么
9 票 · 最高依赖冲突 / 版本不匹配
7 票不敢运行陌生脚本
6 票配置难
参数、格式、结果不对参数太多，不知道填什么
7 票 · 优先输出格式 / 尺寸不对
5 票失败后不会恢复
6 票信任与维护难
结果、许可证、换电脑不知道结果是否可信
5 票许可证能不能商用
4 票换电脑又要重装
4 票
优先级痛点群
安装失败不会恢复（9 票）、不知道选哪个（8 票）、参数太多 / 依赖冲突（7 票）。这三个痛点共同指向一件事：用户需要的不是更多信息，而是有人对“这一次交付”负责。
5.4
HMW 与 POV：把痛点变成设计挑战
具体、可行动、不预设解决方案；再把最佳 HMW 转成用户需求陈述。
候选 HMW 问题
- H1
我们如何能让没有编程经验的 Windows 用户，在不看命令行的情况下完成安装、配置和第一次成功使用？
- H2
我们如何让 AI 推荐的工具和参数可解释、可核对，而不是一个黑盒？
- H3
我们如何把“安装失败”变成可恢复、可回退的步骤？
- H4
我们如何让用户在 10 分钟内拿到第一个可验证的结果？
- H5
我们如何让用户相信第三方开源工具的来源、许可证和运行边界？
最佳 HMW
H1：我们如何能让没有编程经验的 Windows 用户，在不看命令行的情况下完成安装、配置和第一次成功使用？
可行性 – 创新性矩阵
创新性 →
可行性 →
H1
H2
H3
H4
H5
H1 落在“高可行 × 高创新”象限：它不要求发明新技术，但要求把选型、适配、验收串成完整体验。
POV 问题陈述“没有编程经验的 Windows 用户需要在不看命令行、不查教程的情况下完成开源工具的安装和第一次成功使用，因为现有方案默认他们会配置环境，一旦失败就不知道如何恢复。”
✓ 用户具体✓ 需求可量化：30 分钟内完成首次任务✓ 原因来自共情资料
5.5
创意发散与可行收敛
每位成员至少 3 个方案；用成本–效用矩阵和六顶思考帽筛选。
发散12 个想法
人工代装、图文教程、浏览器插件、远程桌面、预装 U 盘、企业上门、社区互助、AI 聊天机器人、一键脚本、软件订阅、硬件盒子、插件市场。
→
收敛3 个方向
按成本、效用、创新性和可复用性合并为 A / B / C 三个方向，再用矩阵筛选。
开源工具导航 + 图文教程
整理项目、教程和常见坑，靠内容和搜索流量变现。
- 成本：低
- 效用：低
- 壁垒：低
不选：解决“知道”，不解决“装好”。
AI 选型 + 人工远程配置
AI 先给方案，复杂环境由人工远程协助，按次收费。
- 成本：中
- 效用：中
- 壁垒：中
备选：能验证付费，但难规模化。
本地交付平台（拾用）
AI 选型 + 适配器配置 + 本机运行 + 验收清单，交付可重复使用的工具入口。
- 成本：高
- 效用：高
- 壁垒：高
选择：成本最高，但边际效用和复用价值最高。
矩阵
成本–效用筛选
| 方案 | 成本 1 低 – 5 高 | 效用 1 低 – 5 高 | 创新 1 低 – 5 高 | 综合判断 |
|---|---|---|---|---|
| A 导航 + 教程 | 2 | 2 | 1 | 低 |
| B AI + 人工 | 3 | 3 | 3 | 中 |
| C 本地交付平台 | 4 | 5 | 5 | 高 |
C 的成本高，但把“选型、配置、运行、验收”做成可复用资产；随着适配器增加，单次交付成本下降。
六帽
六顶思考帽速记
- 白
事实：3 个工具已跑通，24 条来源可核对，真实用户数据仍不足。
- 绿
创意：AI 选型 + 适配器 + 验收清单，把一次性服务变成可复用交付。
- 黄
价值：本地优先保护隐私；工具可重开；停模型仍可用。
- 黑
风险：第三方代码安全、Windows 碎片化、模型选型错误、用户不愿付费。
- 红
直觉：用户真正想要的是“别让我折腾”，不是更多功能。
- 蓝
流程：先做窄而完整的 MVP，再用真实使用和支付决定是否扩展。
5.6
一句话说清解决方案：4W1H
如果一句话说不清，说明还没想清楚。
拾用 OpenFoundry 提供的开源工具交付服务，利用 AI 选型、本机适配和验收清单，帮助没有编程经验的 Windows 用户在不看命令行的情况下把需求变成能打开、能使用的工具。
Who
没有编程/部署经验的 Windows 用户：个体商户、学生、创作者、小微团队业务人员。
What
开源工具交付平台：从需求到可用工具，而不是一个下载链接。
Why
把发现、安装、配置、验证的门槛降下来，让开源能力真正被用起来。
Where
Windows 桌面，本地优先；需要模型时可选本地或外部。
When
需要批量处理图片/影音/文本，或第一次尝试某个开源能力时。
How
自然语言需求 → AI 选型 → 本机适配 → 验收清单 → 可重复使用的工具入口。
5.7
关键假设与 MVP
至少 3 个关键假设；MVP 不是功能堆叠，而是验证假设的最小闭环。
假设
五个必须验证的假设
- 01用户愿意用自然语言描述需求，并允许平台检测本机环境。
验证：10 人任务测试，观察是否主动授权、是否理解检测目的。状态：待验证。
- 02AI 能在常见需求上选对工具和参数，错误能被界面拦住。
验证：30 条冻结需求 + 人工复核；已有真实选型记录。状态：部分验证。
- 03适配器可以复用，新增同类工具主要是配置工作。
验证：3 个已接入工具 + 3 个新需求，记录新增适配工时。状态：部分验证。
- 04用户愿意为“省时间、少踩坑”付费。
验证：3 个预付测试，预付率 ≥10%、退款率 ≤5%。状态：未验证。
- 05第三方代码与许可证风险可控。
验证：来源、许可证、哈希、人工批准、卸载清单；不做静默执行。状态：部分验证。
MVP
0.2.2 的范围
✓ 已交付
- 找工具 / 我的工具 / 设置三个入口
- 图片批处理、影音处理、文本整理
- 本地模型准备 + 外部兼容 API
- 真实选型、参数配置、运行与下载
- Windows 便携包与停模型验收
- MCP / DSH 插件接入
○ 尚未交付
- 任意 GitHub 项目自动适配
- 云端多用户与账号系统
- 全 Windows 版本 / 全显卡兼容
- 全部云模型供应商验收
- 付费、订阅与发票
- 移动端原生应用
MVP 判断
“窄而完整”的本地闭环已经跑通。下一步不是加工具数量，而是验证真实用户、真实频率和真实付费。
原型路径
低保真流程 → 高保真页面 → 可运行 MVP → 可用性测试
测试指标
首次任务成功率、完成时间、人工介入次数、放弃原因、复用意愿
当前证据
3 个工具真实运行；1440px / 390px 页面；停模型验收；便携包冷启动
06 / 原型演示
浏览器里的可点击版本
下面是一个按真实产品流程做的交互演示：描述需求 → 查看方案 → 准备配置 → 运行结果。演示数据不会上传，也不会执行任何安装。
演示模式
真实产品是 Windows 本地应用，依赖本机文件系统、运行时与模型；本页只演示流程和界面，不代替真实安装/运行验收。
真实界面
不是效果图，是验收截图
点击放大查看。截图来自 0.2.2 原型在 1440px 桌面与 390px 手机宽度下的实际页面。
390px · 找工具
390px · 我的工具响应式
桌面与手机都能打开
课程展示站本身也做了移动端适配；真实产品当前以 Windows 桌面为主，手机页面用于查看与轻量操作。
07 / 验证与交差
哪些是真的，哪些还要补
创业项目最怕把“找到项目”说成“交付完成”。我们把已验证、部分验证和不能声称的内容分开写，答辩时也按这个口径讲。
0.2.2
当前真实原型版本
3
可实际运行的工具
8
类验收证据
9/12
需求初筛自评
| 验证项 | 实际检查 | 状态 |
|---|---|---|
| 本地模型 | 复用 Ollama，在平台独立目录下载 Qwen 2.5 1.5B，执行结构化参数检查 | 已通过 |
| 需求选型 | 真实模型选择图片配方，生成 800×600、PNG、文字水印、右下角配置 | 已通过 |
| 图片处理 | 处理真实 PNG 并重新解码验证尺寸；浏览器选择中文文件、预览与下载 | 已通过 |
| 影音处理 | 固定 FFmpeg 构建，校验压缩包与二进制 SHA-256；MP4 提取 MP3、压缩并重新解码 | 已通过 |
| 文本整理 | 真实本地模型整理中文会议记录，输出 Markdown，检查关键人名和预算保留 | 已通过 |
| 页面与响应式 | 1440px 桌面与 390px 手机布局，无脚本错误、无浏览器外部资源请求 | 已通过 |
| Windows 便携包 | PATH 中没有 Node/Python/npm 的独立目录启动，导入配方、处理图片、重开保留状态 | 已通过 |
| 停模型验收 | 停止模型服务并阻断模型通道后，无模型工具仍能完成真实输出 | 已通过 |
| 真实用户付费 | 尚未进行预付测试，不能声称付费意愿成立 | 待补 |
| 任意项目自动适配 | 未知 GitHub 项目可检索和读来源，尚不能自动接入任意仓库 | 边界 |
| 全 Windows / 全云模型 | 未覆盖所有 Windows 版本、显卡和云服务商，需分别验收 | 边界 |
课程任务对照
每一项要求放在哪
学习通仍需提交文字版；本站可打印为 PDF，作为展示与答辩材料。
趋势洞察 PEST02 洞察已完成
行业五角星模型03 行业已完成
用户诊断 + 伪需求评分04 需求已完成
需求假设验证画布04 需求已完成
二手资料 3–5 个来源05.1 设计已完成
用户关系网络图05.2 设计已完成
痛点聚类 10+ 项05.3 设计已完成
HMW + POV05.4 设计已完成
3 套方案 + 成本效用矩阵 + 六帽05.5 设计已完成
4W1H 一句话方案05.6 设计已完成
3 个关键假设 + MVP05.7 设计已完成
原型设计与测试06 原型已完成
真实用户验证数据04 / 07待补
下一步
四周验证计划
- W110 次访谈
5 个目标用户 + 5 个非技术用户；记录最近一次如何解决，不问假设性问题。
- W23 个预付测试
9.9 元单次 / 29 元月付 / 99 元年付；真实支付，不做好友价。
- W35 次可用性测试
从说需求到拿到结果，记录时间、卡点、人工介入和放弃原因。
- W42 周使用日记 + 决策
看频率、复用和推荐意愿；决定继续、收窄场景或转向。
边界
答辩时不要这样说
- ×
“任何开源项目都能一键装好。”实际：只对已接入适配器的工具负责。
- ×
“用户已经愿意付费。”实际：尚未做真实预付测试。
- ×
“所有 Windows 电脑都能用。”实际：只验证了当前电脑和独立目录。
- ×
“模型完全可靠。”实际：轻量模型仍可能理解偏差，结果需核对。
可以这样说：“我们已经跑通一个窄而完整的本地闭环，并证明了三个高频工具可以真实运行；下一步用真实用户和支付验证需求。”
项目组
四条线，一个项目组
课程项目组按能力分工，不做“挂名式协作”。姓名与学号请在提交前补入。
研究 / 用户洞察
访谈、PEST、行业数据、需求评分
产品 / 设计
流程、界面、课程材料、演示站
工程 / 适配
本地平台、适配器、验收证据
运营 / 验证
招募用户、预付测试、反馈闭环