搜索框里敲下“代码”两个字你大概率会看到满屏的教程和热点C语言文件读写、Python爱心代码、罗盘时钟、快速排序、各种网站源码……信息量大到让人更焦虑。而在B站我见过太多人在评论区里说同一句话“我也想做个自己的产品可我不会写代码啊。”两年前我就是其中一员唯一不同的是我没有停在“想”这一步。最终我做出的小程序累积了百万级用户——全程我没有自己写过一行完整的正式业务代码。今天这篇文章我会把整个过程掰开揉碎讲给你听从需求验证、选型、搭建、增长到自救每一步都尽量具体。如果你也认为自己“不会写代码”这篇文章就是为你准备的。1. 代码恐慌是常态但产品成功的第一道门槛不是代码1.1 先承认这件事代码本身就是一座信息围墙我不会一上来就灌鸡汤说“代码很简单你一定能学会”。事实上代码对很多人来说是真实存在的门槛。我自己买过编程书、收藏过一整套B站教学视频甚至跟着敲过几节课的代码。第一次配置Python环境变量时我对着报错信息愣了一个小时最后默默关掉了电脑。这种挫败感不是个例而是大量“想学编程但没学成”的人的共同经历。问题不在于智商而在于代码学习是一条需要持续投入的长线。今天看懂了一个语法明天不练又会忘跟着教程能做出“爱心代码”但离“自己设计一个产品”中间还隔着数据结构、框架、调试、部署等一整套体系。对绝大多数成年人来说时间精力根本不够走完这条路。所以我很快做了一个判断如果我想做的是“产品”代码不是唯一入口。这不是自我安慰。我后来接触了很多独立开发者发现一个规律技术再强的人如果做的是一个没人用的产品代码写得再漂亮也是零。反过来一个不懂技术但非常懂用户的人完全可以通过成熟的工具链把产品做出来。代码只是实现手段而产品本身是需求、体验、场景、传播和迭代的综合体。1.2 不会写代码的人反而被逼出了三种稀缺能力如果你真的“不会写代码”这不是你的短板而可能是一种变相的逼迫你必须用其他方式解决问题而这个过程会逼你长出三种程序员不一定具备的能力。第一种能力是“把需求说成人话”。因为我不会写代码所以我和任何开发、工具、外包沟通时都必须把一个功能拆到最细。我不会说“做个打卡功能”我会说“用户从首页点这个按钮进入打卡页面点击后记录今天的日期如果连续超过七天就展示一个徽章同时更新排行榜数据”。这种翻译能力本身就是产品经理的核心能力只是很多技术出身的人反而懒得做。第二种能力是“做减法”。正因为我没有能力实现复杂逻辑所以我的MVP必须砍掉所有不必要的东西。每次想加功能我都会问自己这个功能如果用户不用会不会导致核心体验崩塌不会就砍掉。这种被迫的极简主义让我避开了“功能堆砌但没人用”的典型陷阱。第三种能力是“更珍惜用户反馈”。因为改版成本高我不会随便拍脑袋开发。每次迭代前都会先问用户、先看数据把有限的资源投到刀刃上。很多技术强的团队会陷入“我能做所以我就做”的思维而我的思维是“我只能做一点所以必须做最对的那一点”。1.3 近三年工具环境的改变低代码、BaaS、AI辅助除了能力上的被迫成长外部环境也发生了很大变化。2020年之后小程序云开发这类免运维服务已经非常成熟。过去做一个产品你需要服务器、域名、备案、后端接口、数据库每一项都足以劝退非技术背景的人。现在呢前端有现成模板数据库有BaaS登录有云开发自带的openid体系连文件存储都不需要自己搭。更不要说AI工具的爆发。过去不会写代码的人想处理一个CSV文件只能求人或者手动复制粘贴现在只要能把需求描述清楚AI工具可以帮你生成一次性脚本来解决。我自己就用AI处理过几百个知识点的格式转换全程没写一行代码。所以现在的局面不是“会不会写代码”而是“会不会描述需求、会不会选择工具、会不会借力”。这三样东西每一个都是可以训练的而且不需要数学天赋。2. 真正开始做之前我花了三周验证“这到底是不是需求”2.1 需求不是拍脑袋想的是从B站评论区里挖出来的我最初的想法是做一个“考研时间管理工具”。听起来很合理备考的人确实需要规划时间。但我没有急着开工而是在B站连续刷了两周学习区的内容重点看两类东西评论区留言和私信提问。很快我发现用户真正高频出现的痛点根本不是“时间管理”而是“看视频的时候什么都懂了关掉视频全忘了”。我在多个学习UP主的视频评论区里看到了大量类似的话“收藏了就等于学会了”“看的时候觉得会了做题全错”“哪位大佬有可以刷题的地方”。这些原话非常有价值因为它们指向一个更具体、更持续的需求用户需要一个能随时检验自己“到底记住没有”的东西而不只是一个排时间表的工具。挖需求的方法其实很笨先选目标领域再搜关键词然后看评论区里被反复提起的“抱怨”。不要只记录关键词本身还要记录用户原话因为用户原话能还原真实场景。比如“看完视频过两天就忘”和“我想要错题本”这两句话前者描述的是场景和感受后者直接给了解决方案但真正的需求是前者。2.2 用表单加群打卡做了一次“最小真实性测试”需求听起来再真实也不能直接开做。我决定先用最原始的方式做一次验证。我没有写任何代码只建了三个微信群在B站动态和评论区发了入群链接然后做了一件事每天手动在群里发10道题让用户回复答案我再手动统计正确率。三天之内三个群全部满员500人进了群。这个测试给了我两个关键信息。第一愿意进群的人比我想象的多说明“刷题”这个方向确实有吸引力第二也是更重要的是参与率。我的群打卡每天有超过40%的人主动回复答案而且连续三天参与的人并不少。要知道一个“伪需求”的群通常第二天就开始安静能保持40%活跃度说明用户真的在持续使用这个场景。这次测试没有任何技术含量但它帮我验证了“用户是否愿意经常打开”这个核心问题。如果连一个免费群打卡都坚持不了那么做出产品后大概率也是三个月就死。所以我不建议任何非技术出身的人跳过这一步先用你手上的一切工具模拟产品最核心的闭环然后观察用户是否愿意一直回来。2.3 把所有信号整理成需求池验证结束后我整理了所有信号做成一个简单的需求池。我没有用什么专业工具就用一个多维表格字段是这样的需求描述出现频次用户原话示例真伪判断优先级学完没有地方检验120“总感觉收藏了就等于学会了”真实高频P0想要错题本40“做错的题能再练一次吗”真实但低频P1想要排行榜30“想看看别人学到哪了”表面热闹持续性存疑砍掉想要分类题库90“能不能按章节刷题”真实高频P0结论很简单只做P0和极少数P1其他全部砍掉。这个习惯我一直保持到今天每一个新功能进入开发前都要先在这个表格里找到对应的用户证据。没有用户证据的功能无论听起来多酷都不做。3. 零代码搭MVP我选的四套工具组合和踩过的坑3.1 我放弃“先学编程再做产品”的理由很多朋友问我为什么不花三个月学一下Python再做我的回答是成本收益完全不对等。三个月后我可能确实入门了Python但还是不会做小程序前端不会处理后端并发不会上线部署。而如果我用现成的低代码工具和云开发服务一周之内就能上线一个能用的产品。对非技术出身的人来说最重要的效率指标永远是“上线速度”而不是“技术自主率”。这个选择还有一个隐藏优势产品的反馈速度决定了迭代速度。早一个月上线就能早一个月接触真实用户也就早一个月知道这个产品到底行不行。如果我用三个月学编程、再用两个月开发等到上线已经是半年后可能连最初验证出来的需求都已经变了。3.2 我最终选定的工具组合以及为什么这个组合也是我反复折腾之后才定下来的给各位一个参考用途选型为什么选它用户端微信小程序 微信云开发免服务器自带登录和数据库用户打开就用不额外产生下载成本题库管理飞书多维表格像Excel一样维护题目非技术人员能轻松上手支持多表关联数据处理AI生成的一次性Python脚本用于CSV格式转换、文本清洗、批量打标签成本极低版本管理Gitee把每个版本的配置和素材快照存起来不懂Git也能用网页上传页面样式现成开源模板 可视化编辑器在开源的界面模板上改字改色不需要碰底层代码选型的核心逻辑是“减少运维”。我深知自己搭建服务器迟早会出问题所以凡是需要自己维护基础设施的方案全部不考虑。云开发提供服务端的登录、存储和数据库这些是产品最基础的底座交给成熟平台比自己折腾可靠得多。同时所有重要数据必须再同步一份到多维表格这其实是给自己留了一个“后悔药”。3.3 第一个版本我只做了四个功能因为没有技术团队我对自己有严格要求首版只能做四件事。题库浏览、每日一练、错题本、连续打卡。这四件事全部来自需求池没有一个是“我觉得以后用得上”的功能。搭建过程并不复杂。题库用多维表格维护一行一行录入题目和答案解析页面用现成模板改成自己的样式每日一练和错题本通过云开发的数据库查询实现不需要写复杂逻辑。虽然过程还是有点磕磕绊绊但我只需要理解一个核心抽象关系“表格里的一行对应页面里的一道题”。只要明白了这个关系增删改查都能通过配置完成。我特别想纠正一个误区很多人以为“零代码”等于“拖拽一下就自动生成App”其实不是。真正的工作量集中在内容准备和结构设计上。你要想清楚题目怎么分类、错题怎么记录、打卡怎么计算。这些想清楚了工具只是执行者。而“想清楚”恰恰是非技术出身者最应该发力的地方。3.4 上线前三天踩过的坑产品开发接近完成时我连续踩了三个坑差点让项目死在黎明前。第一个坑是云函数冷启动超时。首次打开页面时云端逻辑需要临时启动耗时可能好几秒用户在这个时间内就会流失。解决办法是把题库数据打包到小程序本地启动时秒开然后后台异步更新版本。这个优化让首屏加载时间从几秒降到一秒内。第二个坑是数据库权限设置太松。因为不太懂权限模型我一开始用了比较开放的权限配置导致用户理论上可以读到别人的答题记录。发现问题后我赶紧改成“用户只能读写自己的数据”。这个教训很吓人也提醒我不懂代码的人尤其要敬畏数据权限和安全问题。第三个坑才是真正让我长记性的。一次发布新版本时我没有做备份直接把旧题库表覆盖了几百道人工整理的知识点题目全部丢失虽然最后从多维表格里找回了一部分但还是损失了一天的数据。从那以后我强制自己每周把云端数据导出备份到本地同时在Gitee上保存每个版本的配置快照。4. 百万用户不是天上掉的B站内容运营和产品增长的循环4.1 冷启动靠一条“过程记录”视频不是广告产品上线后我没有钱投信息流广告也没有资源找大V直接推广。我的做法是发了一条B站视频标题大意是“不会写代码的我用零代码工具做了个免费刷题小程序”。视频内容不是产品功能介绍而是我整个创作过程的记录被评论区启发、建群验证、用多维表格录题、一次次被报错折磨、最后上线的全过程。这条视频发布后24小时内带来了第一批1000多个真实用户。我后来复盘为什么效果不错核心原因是“同类人信任”。用户看到一个和自己一样不会写代码的人一步一步把产品做出来不是站在台上喊“我的产品多好用”而是展示“我能做到你也可以试试”。这种信任感远远强于官方推广号或硬广。这里有一个容易踩的坑不要在产品最早的冷启动视频里塞进太多“求转发求点赞”的请求会让观众反感。我当时只做了一件事就是在简介里放了产品入口然后说“欢迎用完给我提意见”。把主动权还给用户他们反而更愿意帮你传播。4.2 增长靠“学习周报”卡片把分享内嵌在产品里产品有了第一批用户后我开始思考怎么获得更多自然增长。没有预算我只能把增长动作设计在产品内部。一个契机是有用户在反馈里说自己每天打卡后喜欢截图发到B站动态记录学习过程。这个细节启发了我为什么不主动为用户生成一张“值得晒出去”的卡片于是我做了一个“学习周报”功能。每周自动生成一张图片包含用户的连续打卡天数、本周做题数、战胜用户的百分比底部带一个小程序码。B站的学习区用户本来就有记录学习日常的习惯这张卡片自带数据可视化天生适合传播。结果发布后每周都能在B站动态和朋友圈看到大量周报分享这个小设计成了零成本的裂变入口。做这件事的关键不是技术而是理解用户的“晒”动机。人想炫耀的不是“我很努力”而是“我的努力被量化成一张好看的成绩单”。周报正好满足了这种心理同时又埋了产品入口用户看到后自然会点进来体验。4.3 没有技术团队怎么把迭代权握在自己手里很多非技术出身的人会担心产品上线后谁来维护迭代我的经验是把迭代权握在自己手里靠的是一套严格的筛选机制。每周我会固定一天从用户反馈池里捞需求。反馈池来自小程序内的反馈入口、B站评论区、私信和微信群聊天记录。捞出来之后用三个维度打分影响人数、实现成本、与核心场景的相关性。分数最高的才进入开发队列。因为没有技术团队我每周只允许自己新增一到两个小功能其余时间都花在修复问题和内容维护上。这个看起来“慢”的节奏反而保证了产品质量。用户最在意的不是功能多而是核心功能稳定好用。实际操作中我还会记录哪些反馈被拒绝了、为什么拒绝。这样做有两个好处一是避免自己反复纠结已经讨论过的功能二是下次用户再次提出时我可以清晰说明拒绝理由让用户感受到被尊重。4.4 从10万到100万的关键让学习区UP主参与感带动推荐用户增长到10万左右时光靠自己的内容已经不够了。我决定寻求学习区UP主的合作但我的思路和常见的“花钱投广告”完全不同。我先是私信联系了几位体量不算特别大、但粉丝黏性很强的学习区UP主请他们提前体验产品然后主动询问他们的使用感受和建议。有一个重要的细节我会在收集建议后真的把建议落地成新功能并在更新日志里标出“感谢某位UP主的建议”。这种做法带来的效果远超预期。当那些UP主发现自己提出的建议真的变成产品功能时他们会觉得自己参与了产品的成长而不是单纯被商家利用。于是他们中的好几位在自己后续的视频里主动提到了这个产品这种来自真实使用者的推荐质量远高于付费宣传。短短几个月用户量从10万级别冲到了百万级别。这个阶段我也付出了代价。用户量急速增长后一些早期没有注意到的数据问题开始暴露比如新版题库更新不及时、某些机型打开白屏等。所以如果你的产品也进入放量增长阶段一定要提前想清楚增长越快维护的压力越大没有稳定技术兜底时宁可放慢拉新节奏也不要让口碑崩掉。5. 不会写代码的人自救指南我的问题分级和外包经验5.1 遇到技术问题先分级别所有问题都自己扛非技术出身的人最怕的就是所有问题都堆到自己面前然后陷入“我看不懂、也不敢动”的瘫痪状态。我的自救方法是把所有技术问题分成四级不同级别用不同方式处理等级问题类型处理方式A配置、权限、样式调整自己查教程B站关键词一搜就有B增加字段、简单逻辑、一次性数据处理让AI写脚本或找现成模板改C支付、核心业务、数据迁移写清需求文档找靠谱外包D安全、隐私、高并发用成熟云服务不要自己DIY为什么要分级因为不懂技术的人最大的风险不是“处理不了”而是“用业余方法处理专业问题”。比如服务器高并发这种问题自己手动调配置很可能直接搞崩线上服务这种钱不能省应该交给云服务商或专业外包。而像改个页面颜色这类事情如果也找外包成本太高不说响应速度也跟不上。分级之后我的处理效率明显提高成本也大幅下降。5.2 给外包看的需求文档我踩过“一句话需求”的坑第一次外包时我犯过一个很低级的错误只发了一句“做一个打卡功能”。结果对方交付后我一看完全不是我想象的样子。不是对方不靠谱而是“打卡”这个词在每个人脑子里都不一样。有人认为是点个按钮就行有人想要连续天数计算有人还要排行榜联动。对方既没做错也没做对因为需求本身模糊。经历了这次返工我总结了一份外包需求文档的模板后来一直沿用第一用户从哪里进入这个功能放截图和录屏第二用户看到什么界面布局说明第三用户点击每个按钮后预期发生什么第四异常情况怎么处理比如断网、重复提交第五验收标准比如“在3秒内返回结果”“重复点击不会生成多条记录”。把需求写到这种颗粒度后返工率大幅降低客单价反而下降了因为对方不需要反复猜。这里也给所有非技术出身者一个忠告外包不是越便宜越好而是“把话说清楚”比什么都值钱。多花时间写需求文档就是给自己省钱、省时间、省情绪。5.3 AI辅助编程的合法边界能写脚本别乱动核心在AI辅助编程这件事上我的态度是既大胆又保守。大胆的地方在于我非常愿意让AI帮我处理那些“一次性”的脚本。比如批量清洗CSV数据、把Excel里的文本格式统一、提取多个文件里的关键词这些事情如果手动做可能耗时半天甚至根本做不了。但通过AI生成脚本我只要把需求描述清楚运行几秒就出结果。我处理过几百道题的格式转换就是靠这个方式完成的。保守的地方在于我绝不会让AI生成涉及核心业务逻辑的代码。登录、支付、数据权限、数据统计这些模块一旦出问题会直接影响所有用户而我没有能力验证AI生成的代码是否正确。万一代码里有漏洞我又看不懂出了问题也无法排查。这个风险不值得冒。所以我的原则是能用AI解决的低风险一次性任务放心用涉及用户核心资产和资金安全的任务永远找专业人士或者用成熟平台不要因为“AI很厉害了”就放松警惕。5.4 合规是产品的地基非技术出身最容易忽视产品做起来之后合规问题成了我思考最多的事情之一。非技术出身的人很容易忽视隐私政策、用户协议、数据最低采集原则等细节但对一个面向大众的产品来说这些不是“可有可无的文档”而是产品生死的根基。我的做法包括在用户注册时明确展示隐私说明只采集实现功能所必需的信息提供显眼的账号注销入口用户可以随时删除自己的数据对用户生成的内容建立基本审核机制及时处理违规内容。因为产品面向学习人群我还特别注意青少年保护相关设置避免过度收集未成年人信息。这件事看起来增加了不少工作量但从长远看是省了大麻烦。合规问题一旦爆雷轻则下架重则涉及法律责任对个人开发者几乎是毁灭性打击。找一个懂合规的朋友帮忙审核或者付费咨询一次比出事之后到处补救便宜太多。6. 回到标题不会写代码为什么反而成了我的杠杆再说回标题本身。“不会写代码的人在B站造出了百万用户产品”很多人看到这句话的第一反应是怀疑第二反应是问“怎么做到的”。其实答案就藏在“不会”这两个字里。因为不会写代码我被迫把每一个需求都想得非常清楚。跟任何开发、外包、工具打交道时我必须在短时间内把“用户从哪进来、看到什么、点击后发生什么、怎么算成功”全部翻译成人话。这种训练让我的产品判断力比很多只会写代码的人强。也因为不会写代码我从不觉得自己能搞定一切所以习惯性借力B站教程、低代码工具、AI脚本、模板、外援什么东西好用就用什么。真正让我走到百万用户的不是某一段代码而是把“挖需求—最小产品—内容传播—用户反馈—迭代”这个循环跑通并且愿意一遍一遍重复它。B站在这个循环里扮演的角色不是简单的流量渠道而是一个天然的“用户声音采集器”加“内容放大器”。评论区给我需求内容给我增长产品给我留存三者循环起来才是一个完整的增长飞轮。如果你想复制这条路我的建议不是先去学编程而是先做出来一个会被用户骂“怎么这么难用”的最小版本。被骂得越狠下一步越清晰。在这个过程里你不会写代码这个标签可能会成为你最大的差异化优势因为你会把注意力全部放在用户身上而不是炫技的代码上。不会写代码从来不是做不出产品的理由真正让你做不出产品的是“等我会了再开始”的那个念头。