需求驱动的快速开发思维
需求驱动的快速开发思维：就像点菜时先问“你饿不饿”
一句话定调
简单说，需求驱动的快速开发思维就是先弄清楚到底要解决什么问题，然后用最简单、最直接的办法解决它，而不是上来就琢磨用什么高级工具、写多少行代码。就像做饭前先看看冰箱里有什么、客人想吃什么，而不是先把全套米其林厨具买齐。
生活类比：你装修过房子吗？
假设你要装修一个卫生间。大部分人的第一反应是：找设计图、选瓷砖、定马桶、装浴霸……但如果你换一种思维，先问自己几个问题：这个卫生间主要给谁用？每天用几次？是出租还是自住？预算多少？
你会发现，很多“标配”其实根本不需要。比如浴霸，如果你家在南方，冬天洗澡本来就冷，但如果你装一个带暖风的小风扇，成本低一半，效果也不差；再比如瓷砖，如果你不打算在墙上贴花，纯白的普通瓷砖就能用十年。
这就是需求驱动：先定义“必要”，再考虑“想要”。而不是反过来，先列一圈“想要”，最后发现钱不够、工期长。
嵌入式软件开发更极端——硬件资源就那么点，内存、处理器、电池都有限。如果你一开始不想清楚需求，后面改起来比装修砸墙还痛苦（因为代码烧进芯片后没法轻易改，得重新擦除、烧录）。
故事时间：一个曾经踩坑的嵌入式小哥
小王刚毕业进了一家做智能家居的公司。接到第一个任务：做一个智能灯泡，手机能控制开关和亮度。他兴奋极了，立刻拿出STM32芯片，画好电路图，准备写个完整的Wi-Fi控制程序，还要支持远程、定时、情景模式……干了一周，代码写了两千行。
结果测试时发现根本连不上网，因为Wi-Fi模块的协议栈他调错了。老板来看进度，说：“你这灯能亮吗？在手机上能点一下亮吗？”他支支吾吾：“呃，理论上可以，但我还没写……”
老板说：“你先把这个搞出来，其他功能后面再说。就一个简单需求：手机点一下开，点一下关，亮度可调。三天内给我一个能用的原型。”
小王这才明白：需求驱动不是把所有需求都想全再动手，而是先把核心需求跑通。
他重新设计：用一个蓝牙模块（便宜、简单），配上一个简单的APP，只做开关和亮度调节。两天就搞定了。然后老板拿着这个原型去给客户看，客户说：“不错，但能不能再加个定时关灯？”——这时候他再改，只加一个定时器逻辑，很快。如果一开始就写两千行，改起来得拆了重做。
核心思维一：挖出“真需求”，砍掉“伪需求”
技术人最容易犯的错：把自己当用户，把“觉得酷”当成“必须做”。
比如一个智能门锁需求：用户说“我要用手机开锁”。很多人立刻想到：开发APP、注册账号、连接云平台、远程开门、指纹识别……但认真一聊，用户可能只是希望家人忘带钥匙时能临时用一下，或者快递小哥能远程开门。实际上，最简单的方案是：做一个蓝牙靠近自动开锁，配合一个临时密码生成器，连云端都不需要。
怎么挖真需求？就学记者采访：连续问五个“为什么”。
- 问：“为什么需要手机开锁？”
- 答：“有时候懒得掏钥匙。”
- 问：“那如果你手上拿着东西不便掏手机呢？”
- 答：“……那还是用钥匙吧。”
- 问：“所以其实只是偶尔忘记带钥匙？”
- 答：“对，一周一次吧。”
- 问：“那用固定密码锁行不行？”
- 答：“怕别人知道。”
- 问：“那临时密码呢？每次用完失效。”
- 答：“可以啊。”
你看，最终需求变成了“偶尔用一次、用完即失效的临时密码”，而不是“全功能智能门锁”。一个需求被拆解后，80%的“必要”其实是可以砍掉的。
嵌入式开发中，每砍一个需求，意味着少写几百行代码、少用一个硬件引脚、少用几KB内存，开发速度直接翻倍。
核心思维二：先做“最小可行方案”（MVP），让代码先跑起来
MVP（最小可行产品）是创业领域的词，放在嵌入式里特别管用。简单说：先让灯光亮起来，再研究怎么调亮度；先让电机转起来，再优化转速精度。
用一个常见的场景：你要做一个自动浇花器，检测土壤湿度，干了就浇水。
非需求驱动的做法（错误示范）：
- 选一款高性能微处理器
- 设计完整的电路板，带显示屏、按键、Wi-Fi、存储
- 编写多层软件架构：任务调度、数据记录、网络通信、异常处理
- 写了一个月，结果发现湿度传感器不防水，一浸水就坏
需求驱动的做法（正确示范）：
- 找一块最便宜的Arduino板子（几十块）
- 接一个土壤湿度传感器（几块钱）
- 写个最简单的程序：读传感器，如果低于阈值，就开继电器驱动水泵，浇5秒
- 用个矿泉水瓶当水箱，插根软管
- 一天就能让花盆滴水
- 然后发现：湿度阈值怎么设？那就加个电位器手动调（成本1毛钱）
- 再发现：下雨天不想浇？那就加个雨滴传感器（几块钱）
- 最后才考虑要不要联网看数据
每一步，都是因为“真实遇到了问题”才去解决，而不是“我觉得以后需要”。这样，90%的情况下你发现那些“以后需要”的从来不会出现——用户说“够了”。
核心思维三：用“原型验证”代替“文档评审”
传统开发模式：先写需求文档，再写设计文档，再编码，最后测试。在嵌入式里，这种模式像“盖楼前先写200页施工报告”，等你写完了，用户说“我想要个移动的楼”……
需求驱动强调：尽早给用户看一个能动的玩意儿。
比如做智能窗帘。不要先纠结电机类型、导轨设计、无线协议。拿一个玩具电机+一根绳子+一个蓝牙模块，手动控制正反转。让用户看到窗帘真的能拉开收拢。用户可能来一句：“不错，但我其实更喜欢手拉一下就能自动收，不需要每次按手机。”——这个需求比“远程控制”更强烈，而你用原型一下就发现了。
原型验证的诀窍：用最便宜最快的方式，造一个“看起来像那回事”的东西。比如用开发板、面包板、杜邦线、热熔胶枪。功能可以丑，但必须能用。用户看到后，给反馈，你改，再给，再改。两三次迭代后，真正的需求就浮出水面了。
总结：需求驱动的“三字诀”——少、快、真
- 少：砍掉伪需求，只做真正必要的功能
- 快：以最快速度做出能跑的原型，哪怕用胶带粘
- 真：让真实用户真实使用，从反馈中修正方向
嵌入式软件开发最大的绊脚石不是技术门槛，而是做了太多不必要的事情。就像你本来只想炒个蛋炒饭，结果跑去学养鸡、种水稻、烧砖建厨房——等你做完，饿死了。
下次你接到需求，先忍住写代码的冲动，拿支笔问自己：如果只能做一个功能，那是什么？如果只给我三天，我能交出什么？答案往往是那个最不起眼、但最能解渴的东西。把它做出来，剩下的，等用户催你的时候再说