2026年我给自己定了一个看起来不太清醒的小目标一年之内独立开发并上线100个应用。不是那种三分钟热度堆出来的静态页Demo而是以“能做出来、有人能用、不打算丢人”为底线从选题、设计、开发、部署到复盘全部自己一个人走完。100个这个数字意味着什么平均每3.65天就要交付一个应用算下来全年没有一周是能松懈的。很多人听到这个计划的第一反应是“疯了”第二反应是“这不就是刷数量嘛”。但我真正想做的是用一场高密度的量产实验把“做应用”这件事从玄学变成流水线把自己从“一个想得多做得少的人”改造成“一个能在压力下持续交付的人”。这篇文章就是我的项目宣言和完整作战计划。如果你也是那种脑子里堆了几十个灵感、却总在“架构设计”阶段就烂尾的开发者或者你想知道一个人一年到底能不能做出100个带真实功能的应用这篇内容应该能给你一套可以抄作业的排期、选题、技术栈和量产方法论。1. 凭什么敢接100个应用这种天方夜谭1.1 这个目标的第一个真相应用其实没那么“重”先别被100这个数字吓住。我拆过几百个真实上线的应用发现绝大多数所谓“应用”底层结构就是三样东西的排列组合一个壳前端界面、一类数据存储与输入输出、一个场景解决某个具体问题。剩下的差异只是“壳长什么样”“数据怎么组织”“场景切得有多细”。举个例子一个记账应用和一个时间追踪应用听起来八竿子打不着但底层都是“列表页表单页统计页增删改查”差的只是字段名称和统计逻辑。一个快递取件码整理助手和一个发票管理小工具也都是“扫码或拍照录入→结构化存储→按规则检索输出”这套流程。一旦你看穿了这层底就会明白一年100个应用的真实工作量不是“从零开发100套不同系统”而是“用同一套肌肉记忆去覆盖100个不同场景”。这种认知是我敢接下这个挑战的地基。没有这个前提100个应用就真的只是疯话有了这个前提它才变成一个强度很大但可以执行的工程问题。1.2 我逼自己上量的三个理由第一破掉完美主义。我过去做了很多应用最终真正上线的不到一半。卡住我的从来不是技术难点而是“总觉得还差点意思”——差个更好的图标、差个更顺滑的交互动效、差一个还没想清楚的配置项。这种心态非常致命因为“差点意思”是个无底洞。100个目标本身就是一剂猛药如果每个应用都要花一个月打磨才算“完美”一年最多做12个要做满100个就必须接受“先做出来再靠用户反馈变好”的节奏。我给自己定的规矩是一个应用从选题到发布最多四个工作日到点必须上线。第二建立私有素材库。做100个应用最大的副产品不是那100个应用本身而是过程中沉淀下来的模板、组件、文档、部署脚本和避坑笔记。前20个应用可能还在为每个新项目重新造轮子到第30个之后你会发现自己打开电脑十分钟就能把骨架搭起来因为一切都有现成的。这种积累才是长期值钱的东西。第三获得高频试错的机会。花八个月憋一个“爆款”去赌市场不如用100个小而完整的应用去碰需求。十个应用放出去可能只有两个有真实用户但这两个的真实反馈比关起门来猜一年的强得多。我做这个计划的核心假设就是在数量足够大的情况下市场的反应会告诉我方向而不是我坐在电脑前猜方向。1.3 谁适合参考谁不适合硬抄这套方案适合的人是已经具备独立开发简单应用能力、但卡在“发布”和“完成”环节的开发者。你不需要精通高并发、分布式这类重型技术只需要能把一个表单、一个列表、一个第三方接口跑通。不适合硬抄的人有两类。一类是时间上根本不具备条件的人比如你每天只能挤出半小时或者正处在备考、带娃、创业的关键期这种时候硬上100个只会两头都做不好。另一类是纯粹抱着“赚快钱”心态的人如果目标是一年100个然后指望其中某个一夜爆火大概率会失望。我做这个挑战的预期收益是能力、习惯、素材库和判断力这些是可以确定的市场反馈则是额外的彩票不能当成唯一目的。2. 先把“一年100个”变成一串能落地的数字2.1 时间账怎么算才不骗自己很多人听到“3.65天一个应用”就被吓退了但真正的算法不是拿“3.65天”去乘而是拆成小时。我按每天有效投入3小时来规划周末可以加到5到6小时这样一周大约有25到30小时。一年大约1300小时扣掉生病、出差、过节、纯摆烂等我按1000小时可用总工时来算那么每个应用的平均预算就是10小时。10个小时是什么概念我做过很多次实际校准一个“输入信息→结构化存储→按列表/统计展示→导出分享”类型的工具类应用顺畅状态下大约6到8小时能做完如果涉及第三方登录、支付、云同步这类额外能力要加到12到14小时。所以100个应用里我计划让大约70%走轻量模式6到8小时20%走标准模式10到12小时剩下10%允许做到15小时左右。整体平均控制在10小时以内总盘子就不会崩。我还给自己预留了两个“机动池”一是每周多出半天处理突发问题二是每个季度最后一周不排新任务专门用来补债、还技术债、修一个前期没做好的应用。没有这两个机动池任何一个意外都会让全年计划断链。2.2 排期不是匀速而是冲刺加缓冲如果把100个应用均匀分配到52个星期每个星期做2个听上去就很窒息。我的做法是把节奏改成“三周冲刺、一周休整”的循环。冲刺周里一个星期完成2个应用休整周里不开发新应用只做四件事整理上个冲刺期的模板和组件、补写技术笔记、修复用户反馈的问题、复盘哪些选题决策做错了。这种节奏的好处有两个。一是心理负担更小你永远只是“本周做完两个”而不是“今年做完一百个”二是休整周其实是质量提升周很多经验和教训如果不在当周沉淀下来等到第三十个应用时会全部忘光。月份维度我也做了划分前三个月先做20个小而纯的工具类应用目标是跑通流水线、攒模板第二季度做15个移动端优先的H5形态应用强行走一遍不同尺寸适配和触摸交互第三季度做十几个围绕数据展示和内容聚合的场景最后一个季度以收尾和复盘为主允许重制之前最受欢迎的3到5个应用。这样在全年维度上我既是做100个也是在分阶段训练不同的能力。2.3 给每个应用预先编号和分类我建了一个叫“百应用目录”的表格里面预先占好了100个编号。每个编号对应一个应用名和一句话描述。刚开始只填了前30个后面70个边做边补。这种“先占坑”的做法非常关键它帮我把压力分散了——今天不需要知道第83个做什么只需要知道第1个做什么。每个应用还会打上三个标签功能类型工具、内容、互动、数据、垂直场景通勤、记账、健康、学习、工作流等、技术形态Web静态页、带后端服务、数据展示等。这些标签统计起来之后我就能直观看到自己的选题是否偏科。比如如果发现前20个全是记账类后面就得主动调整到别的场景去。3. 技术选型把重复劳动压制到最低3.1 选型的底层逻辑上线速度优先如果一个人要做一个会长期维护的大型系统技术栈怎么选确实值得纠结。但我的目标是四个工作日交付一个应用所以技术选型的唯一标准是“从打开编辑器到能上线路径最短”。很多人会在这个环节犯一个错每个应用都从“今天适合什么新框架”出发。结果就是每做一个应用都要重新学一遍生态、重新踩一遍坑100个应用做完框架是学了不少产品却全废了。我的原则正好反过来90%的应用都用同一套我熟得不能再熟的栈剩下10%的新技术尝鲜只放在那些定位是“练手”的应用上。这样既保证速度又给新技术留了渠道。具体到方案我选择的是一条“一体化全栈”的路线一个前端框架配合一个可以直接写服务端逻辑的运行时再加上一个轻量级嵌入式数据库。这套组合的核心优势是消灭了前后端联调这一步——前端页面和服务端逻辑在同一个项目里不需要为每个应用单独搭API服务也不需要维护两套代码和两套部署。早期我试过“前端一套、后端一套、数据库一套、部署又一套”的复杂架构做完三个应用就发现这种模式根本跑不起量来。可能有人会担心“一体化方案会不会太简陋”说实话对个人开发的量产场景来说它的能力边界正好卡在够用的位置。有统计页、有数据表、有表单交互甚至能跑定时任务已经覆盖了我做100个应用里面至少95%的需求。3.2 我的“起手式”启动套件做前几个应用的时候我踩过一个大坑每个新项目都要重新写登录、注册、用户表、通知提示、上传组件。这些基础能力又烦又容易出错而且每个都挺费时间。于是我专门做了一个“起手式”项目模板把反复用到的能力全部预制好。这个套件里包含五样东西一套用户认证流程注册、登录、退出、重置密码一套通用的数据模型用户表、配置表、内容表一套统一的视觉风格颜色、字体、按钮、表单、卡片的最小集合一组常用的通用组件文件上传、富文本展示、数据表格、图表卡片、分享按钮以及一个简单的后台管理入口。有了这套起手式之后我开发一个新应用的第一步不再是“新建项目”而是“复制一套起手式”。复制过来之后先改产品名称和视觉标识再按照当前应用的需求调整数据字段最后加几段场景逻辑。实测下来一个标准应用的耗时从10到12小时降到了6到7小时。那两三个小时的差别就是100个应用里的两三百小时足够再造二十个应用了。3.3 部署、域名、数据库的批量管理方案做100个应用的整个生命周期里部署环节如果不照顾效率会变成巨大的时间黑洞。我最开始的教训是每个应用用单独的一套部署流程不同应用部署方式还不一样后来每次上线光折腾环境就要半天。现在我把所有应用的部署统一成了一套“批量化”方案。首先大多数轻量应用不需要一台完整云服务器而是选用那种“静态页面加轻量服务”的托管方式几乎零运维。需要一点后端能力或者定时任务的也尽量做成独立小服务彼此不互相拖累。其次我给所有应用统一用二级域名方案比如一个主域名下面挂几十个子路径。每个应用新增一行配置、加一条反向代理规则就完成上线不需要为每个应用单独买域名、配SSL证书。最后数据库层我强制统一用嵌入式数据库每个应用一个数据文件既免去了数据库服务的管理成本也让备份变得简单——直接把文件打包就走。这批基建我花了一个完整的周末去搭。搭完之后的效果是一个新应用从“开发完成”到“线上可访问”最慢不会超过20分钟基本就是执行一条发布脚本、等一两分钟、检查一下健康状态。4. 100个应用从哪里来选题池设计4.1 别拍脑袋用需求矩阵拼出应用雏形做100个应用最难的不是开发而是持续地产出“值得做”的选题。纯靠灵感一定会在第20个之后枯竭所以我花了相当大的精力搭了一套选题生成机制核心是一个“场景乘以痛点乘以形态”的矩阵。场景我列了几十个基本来自日常的切面通勤、排队、等人、记账、报销、收纳、学习打卡、睡前放松、做饭备菜、出门旅行、宠物照料、健身记录、兴趣收藏。痛点则是我从自己的抱怨和别人的吐槽里收集的文件不知道放哪、发票一大堆要拍照归档、总忘了按时吃药、存了十几个网页链接再也没打开过。形态这里再套一遍那三件套工具型解决一个操作、内容型整理并展示信息、互动型强反馈、适合分享。当场景和痛点结合之后加上一个形态就是一个应用雏形。比如场景是“通勤”痛点是“地铁上不知道看什么”形态是内容型落下来就是“一个每日通勤资讯卡片应用”场景是“健身”痛点是“每次要重新填训练记录”形态是工具型落下来就是“一个带常用动作库的快速训练记录本”。这套矩阵的价值在于它不会让你没得做它只会让你面对太多的潜在选题而需要筛选。灵感枯竭在量产流程里根本不存在存在的是“选择太多不知道怎么排优先级”。4.2 一套快速筛选好选题的评分表选题太多以后我给自己定了一个三问评分表每个应用上线前都必须过这关。第一问这个需求是否真实存在判断标准是“有没有人在网上问过、在帖子里求助过、或者你身边有人明确抱怨过”。一个真实的痛点特征是你不需要费力解释为什么这个应用值得存在。第二问用户会不会长期使用我更偏爱那种“会反复打开”的应用比如记账、打卡、进度追踪而不是“用一次就扔”的换算工具。第三问开发量能不能控制在两个到三天以内如果按我的能力估算需要超过三天我通常直接砍掉或者拆成两个小应用分开发。宁可做两个浅但完整的产品也不做一个深到做不完的残品。我给每问打一档分最终分高的一批排进最近一周的排期。这套筛选机制不是我拍脑袋想的是因为我过去的烂尾项目几乎全部败在了第二问和第三问要么做了一个根本没人需要的东西要么想得太大做到一半失去动力。4.3 第一批可直接照抄的二十个选题样例为了让你们对“100个应用到底做些什么”有体感我把我第一季度的选题池公开一部分。这二十个都是我按上面的评分表筛过的开发量都在两个工作日以内且没有一个是“大而全”的规划编号应用名暂定核心功能预计耗时1随手拍待办拍照生成待办条目支持定时提醒6小时2番茄攒分番茄钟与积分累计用作自我激励7小时3快递驿站取件码整理粘贴取件码自动分类和标注到期时间6小时4发票报销小助手发票拍照归档导出压缩包与汇总表8小时5小程序菜单生成器输入菜品生成手机点单链接7小时6桌面便签同步器跨设备同步便签支持番茄钟联动9小时7通勤资讯卡片订阅源简化成每日卡片流8小时8身体数据周报体重、血压、睡眠记录并生成周报7小时9送礼物灵感库按场景和预算推荐礼物创意6小时10面试追问生成器根据岗位与简历生成模拟追问9小时11家庭物品位置登记登记物品存放位置支持标签检索7小时12菜谱按冰箱食材筛选输入现有食材匹配可做菜谱8小时13学习进度可视化按科目画进度树生成打卡卡片6小时14宠物喂食记录多人协作记录喂养时间和异常7小时15聚会摊钱计算器群成员消费记录与分摊结果导出6小时16夜间阅读护眼模式调整阅读页面背景与字距可存文章7小时17旅行清单打包按出行天数和天气生成打包清单5小时18情绪打卡日记每天三选一记录心情生成月度情绪曲线6小时19不常用联系人提醒定期提醒你联系重要但久未联络的人8小时20离线地图标注在访问过的地点做个人足迹标注9小时这里我刻意排了一些“看起来有点小”的应用。在量产计划里小不是缺点小是保证能闭环的优势。等到这套流程运转起来其中一些应用会在后续迭代里变大另一些会直接淘汰都无所谓。5. 量产模式一条流水线走完一个应用5.1 标准生产流程六步走完一个应用我把每个应用的生命周期固定成六个步骤每步都有明确的开始和结束标准不做和这六步无关的事。第一步选题与需求卡时间预算半小时。在表格里创建新编号用一句话写明这个应用帮用户解决什么痛点再用三条以内列出核心功能同时写清楚“不做什么”。写“不做什么”是我觉得最关键的环节它直接决定这个应用能不能在规定时间内上线。第二步原型与交互半小时。不画精致的图就用线框把页面结构、按钮、跳转关系画出来理顺“用户从哪里进入、在哪里完成核心动作、完成后去哪里”。第三步前端骨架两到三个小时。基于起手式套件把页面搭出来先做静态界面不接数据。这里要逼自己用固定布局习惯界面上的组件全部优先从组件库调只有确实没有的才新写。第四步后端与数据两小时。设计数据表、接口把前端骨架和真实数据打通。因为用的是嵌入式数据库加一体化方案这一步通常很快。第五步联调与部署一小时。过一遍核心流程注册登录、创建数据、编辑、删除、统计展示。确认没有阻塞性问题后执行发布脚本把应用部署到测试地址再实际访问一遍。第六步用例与复盘半小时。把“这是一个什么东西、给谁用、当前有哪些已知不足”写进自带的文档里并给下一个应用留一条“下一次要改进的地方”。这六步加起来正好是我前面拆解的时间预算。这样刻意地把流程标准化目的就是把创意浪费降到最低。脑子里那些“要不顺便加个筛选功能”“不如换个配色”的念头都要在第二步到第四步之间挡住一切不被写进需求卡的功能一律不做。5.2 需求砍砍砍一个应用只保留一个灵魂功能量产最大的敌人是“顺手加个功能”。刚开始做的前三个应用我都栽在这里。本来计划做“一个带番茄钟的待办清单”做着做着就想既然都能记录时间了不如顺手做一个统计报表报表都做了离云同步也不远了吧结果一个应用做了两周上线遥遥无期。后来我给自己立了一条铁律一个应用只能有一个灵魂功能只能有一个。所谓灵魂功能就是用户在向别人推荐这个应用时能一句话说清楚的那个点。比如“能根据冰箱里的食材告诉你做什么菜”这就是灵魂“顺便还能记录采购价格”就不是。凡是被判定为“不是灵魂”的功能全部写进一个叫“后续版本池”的清单里等这个应用上线的版本有人真的使用了再考虑是否加回去。这个策略极其实用既帮我守住了排期也让我醒悟到一个应用能有一个让用户记住的点就已经比大多数“什么都做但什么都记不住”的应用强很多。5.3 配置化组件库一套代码渲染N种界面到做第20个左右的时候我开始有意识地把高频界面抽象成“配置化组件”。这不是什么高端技术就是把“月份选择”“列表筛选”“图表切换”这类高频交互封装成传一个配置对象就能渲染的通用组件。举个例子我做“月度情绪曲线”和“月度消费统计”时底层是完全一样的折线图组件只是传入的字段名和颜色不同。前端工作量因此削减了一大截。这批组件库成了我这套量产流水线最值钱的资产。我给自己定的方向是每当同一个可视化交互出现第二次就花最多半小时做一次抽象第三次出现时直接替换成通用组件。这样既不会为了“优雅架构”过度设计也能让第80个应用的界面开发速度和第20个基本一致甚至更快。6. 质量底线100个应用不能变成100个事故现场6.1 发布前必须过的四道质量门这是我一开始忽略、后来吃了大亏才补上的环节。前面我追求速度连续上线了十个应用结果收到很多莫名其妙的问题反馈有的页面在部分手机上布局错乱有的接口在弱网下请求直接超时还有的甚至没有做基本的数据备份一次误操作全没了。从那以后我强制要求每个应用在发布前过四道质量门。第一道是功能门核心流程必须全部走通注册、创建、查看、修改、删除这几个基本动作不允许出现报错。第二道是体验门页面必须做到几秒内能完成加载不应该出现大面积空白或者布局混乱至少用一种最严格的方式测一遍移动端显示。第三道是安全门涉及用户输入的地方要过滤特殊字符和脚本涉及敏感信息的地方要加密存储所有外部数据读取都要做边界校验。第四道是数据门发布前导出一份干净数据备份确认数据库文件能正常恢复这一步必须写进流程不能偷懒。这四道门听起来简单却能有效过滤掉我过去上线时常见的质量问题。它们不是为了让应用达到“完美”而是防止上线后立刻出洋相。量产计划里这四道门的检查时间加起来大约半小时成本完全可控。6.2 自动化冒烟与统一日志的轻量方案百个应用不可能每个都靠人肉点来点去测。我的做法是给每个应用部署时配一条“冒烟测试”脚本脚本会自动打开应用首页模拟一次核心流程操作然后检查关键页面是否返回正常。只要脚本通过就代表这个应用至少是“活着”的。不需要写很复杂的用例这套脚本的目的只是在每次部署之后把最低限度的“健康状态”确认一遍。日志方面我给所有应用接入了同一个统一日志服务日志按应用编号打标签。这样我只需要打开一个控制台就能看到当天这100个应用里有没有报错。报错信息会按严重级别给不同颜色关键错误还会推送到我的即时通讯工具上。上线初期我依然每天手动翻一遍各个应用的访问情况和错误列表后来发现为大多数轻量应用真的可以做到“部署完就不管出了问题再看日志”。这套轻量监控帮我守住了质量底线但几乎没有占用多少开发时间。6.3 上线不是终点要学会主动下架做100个应用的另一个容易踩的坑是“每个应用都要一直维护”。如果100个应用全部留在线上且不断迭代那会变成一场无休止的运维马拉松完全偏离了初衷。我给自己定了一个很残酷的规则应用上线满一个月如果同时满足“零反馈”和“零使用”就进入下架归档流程。下架不是删除而是把它的代码、数据、文档打包放进一个归档仓库标记为“已下架”。这样做的好处是我的注意力永远集中在少数几个真正被用户需要的应用上而不是被100个“僵尸应用”拖住。主动下架也需要勇气但它是这个挑战的一部分。有些人可能觉得做了100个就应该让它们都活着但我的判断标准是有价值的应用不需要靠数量证明自己没有价值的应用继续挂在线上只是消耗我的时间。7. 常见问题与避坑实录7.1 做着做着就想堆功能怎么办这是我在量产过程中遇到频率最高的问题几乎每个应用做到第四步的时候都会冒出来一种声音“这个功能不加这个应用是不是太单薄了”我的应对方式前面提到过就是用需求卡上的“不做什么”来管住自己。每次有加功能的冲动我就把那个功能写进“后续版本池”然后问自己一句如果用户只记住这个应用的一个功能我希望是当前这个核心功能还是刚想加的这个答案几乎永远是前者于是继续往前走。把加功能的冲动记录下来而不是消灭它才是最现实的策略——因为很多“冲动”其实来自你真正理解了用户场景只是它们不一定要在这个版本里落地。7.2 灵感枯竭时的三个“回收站”做到第40个以后哪怕有需求矩阵撑着也会感到一阵明显的“选题疲劳”。这时候我会去三个固定的地方翻找灵感。第一个是“我的真实生活记录”去看自己的支付账单、搜索记录、相册截图、备忘录。这些地方躺着大量没被解决的小问题比如我三个月前拍了一张快递面单的照片到现在还没整理成表格。第二个是“别人的抱怨现场”我在各种社区和论坛里看普通用户怎么抱怨软件难用、怎么描述自己一天里的麻烦事每一条真实抱怨都是一个潜在选题。第三个是“过去的烂尾项目”我把自己没做成的项目清单翻出来看看能不能拆成更小的应用再试一次。这三个回收站保证了选题池不会干涸。灵感不是等来的是翻出来的。我强烈建议每个人建一个属于自己的灵感池不管用什么工具只要能做到“随手记、每周整理、定期翻看”就行。7.3 某一环卡住如何防止全盘停摆量产过程中最害怕的一件事是“一个应用卡住整个进度停滞”。我做前几个应用时一旦遇到某个第三方接口调试不通就会一直死磕结果一个下午都没了排期直接塌掉。后来我给自己定了一个非常硬性的规则凡是单个问题排查超过两小时必须停止调试并立刻执行降级方案。降级方案可以是换一个更简单的技术实现也可以是直接砍掉那个功能甚至可以是明天换一个应用先做。这条规则看起来简单执行起来极难因为开发者的本能是“我一定要把这个弄明白”。但站在一年100个的全局视角看死磕一个技术点才是最大的奢侈。这个应用里搞不定的不代表整个计划要停摆。把问题记进“待研究清单”先推进下一个应用等有整块时间再回头处理。这样做还有一个额外收益很多技术在隔了几天之后回头看其实没那么难只是因为当时钻进了牛角尖。7.4 倦怠期与“发出去丢人”的心理关第20个到第30个应用之间我经历了最明显的一波倦怠和怀疑觉得自己做的全是“体积小、用处窄”的东西发出去会被人嘲笑。这种心理要不要克服我的答案是不需要强行克服但要调整评判标准。我把“是否丢人”的定义改了——不再看应用规模大不大、技术炫不炫而看两件事第一这个应用有没有解决哪怕一个小问题第二我有没有在承诺的时间范围内真的把它发出去。只要这两点为真它就不丢人反而是我量产计划的合格产出。而且我逐渐发现一个规律每当我对某个应用最没有信心的时候恰恰是它最容易在某类特定人群里被用起来的时候。因为越是垂直的痛点越不需要漂亮包装。度过倦怠期我的实际建议是把“公开进度”当成一个强制项。不需要发到人多的地方哪怕只是在自己的博客页面更新一张“百应用进度表”每周记录完成情况和体验这种公开承诺带来的心理压力就会变成驱动力。当你知道下周要更新进度表时这周就不太敢完全摆烂。最后再分享一个实操心得这套“一年100个应用”的计划目前我已经推进了相当一段距离期间做过工具、做过内容聚合、做过纯粹为了好玩的互动应用也主动下架过没用的应用。个人体会最深的一点是真正决定这个计划能不能成的不是技术能力而是“能否放下身段持续交付”的心态。每次想加功能、想重写架构、想追求完美的时候我都会想起这个计划的初衷用数量倒逼完成用完成倒逼判断用判断倒逼积累。如果你也想做类似的挑战我给一条最实际的建议不要把第一个应用排到下个月今天下午就做完它。哪怕是“随手拍待办”这种最朴素的应用只要你今天上线了它就已经完成了一年的1%。最难的不一定是第100个反而是你决定开始之后的第一个早晨。把这个早晨用掉剩下的99个都只是重复你已经会的动作。