如果几年前有人告诉我，有一天我会讨论麦克风权限、音高检测、数据库和软件部署，我大概不会相信。

我是一名音乐教师，不是程序员。

我会判断一个孩子的音准问题，知道一段旋律应该怎样练，也能听出一个和弦哪里不对。但过去的我，并不知道一个按钮为什么点了没反应，更不明白为什么同一个功能在电脑上正常，到了手机上就出了问题。

可后来，我还是做起了音乐教育软件。

把我推到软件开发面前的，并不是某项新技术，而是一个困扰了我很久的问题：

学生离开课堂以后，谁来陪他继续练习？

一节课结束了，学习却没有结束

课堂上，教师可以示范，也可以随时纠正。

孩子唱得太高，我可以帮他降低音域；一个音没有站稳，我可以让他先停下来，只练这一个音；连续失败几次，我也能看出来他是没有听清、没有找到位置，还是题目本身太难。

可是下课以后，这些帮助就中断了。

有的孩子回家后没有人陪练；有的家长愿意帮助，却不知道应该怎样指导；还有一些孩子明明很努力，只是暂时唱不准，得到的反馈却只有一句：

“错了，再来一次。”

再唱，还是错。

继续唱，继续被判错。

时间久了，孩子很容易把“我还没有学会”，理解成“我没有音乐天赋”。

教师也有自己的困难。

同一个练习方法，我可能要对不同的学生重复很多遍。课堂上可以耐心示范，但不可能每天守在每个孩子身边，也很难知道他回家后究竟练了多少次、卡在了哪里。

我慢慢意识到，我需要的并不是一个替代教师的软件。

我想做的是一个在课后继续陪孩子练习的工具：可以反复播放，可以检测基础音高，可以记录练习情况，也能在孩子遇到困难时告诉他下一步怎么练。

这个想法听起来并不复杂。

真正做起来，却完全是另一回事。

我以为自己在做功能，后来才发现是在整理教学经验

刚开始时，我也很容易被各种新功能吸引。

能不能自动检测？能不能增加排行榜？能不能再做一个更漂亮的界面？

这些功能听起来都很好。但做着做着，我发现一个问题：

如果没有先想清楚教学逻辑，功能越多，返工反而越多。

比如，孩子练习一个音程时，应该怎样检测？

从技术上看，可以让系统一直听，然后判断两个音是否正确。但从教学上看，孩子唱后一个音时，很容易影响系统对前一个音的判断。

真正合理的练习顺序应该是：

先唱第一个音；唱准以后，系统把这个结果确认下来；然后再进入第二个音；已经完成的第一个音，不应该被后面的声音重新改写。

这看起来只是一个检测细节，背后却是完整的教学顺序。

再比如，不同孩子的舒适音区不同。

同一道题，对一个孩子可能正合适，对另一个孩子却太高。如果简单地把所有八度都判成正确，音高训练就失去了意义；如果完全不允许调整，又可能逼着孩子用不舒服的嗓音硬唱。

最后需要的不是“放宽一点”，而是把整道题移高或移低八度，同时保持原来的音程关系、和弦性质和判断标准。

这些规则，不会从技术清单里自动长出来。

它们来自一次次课堂观察，来自教师对学生反应的判断，也来自我们对“什么才算真正学会”的理解。

我后来给自己定下了一个原则：

音乐和教学决定方向，技术负责把这个方向可靠地实现。

不会编程，反而逼着我把问题说得更清楚

因为不懂技术，我最初描述问题时，经常只能说：

“这里看着不舒服。”

“这个声音不太对。”

“谱号再往上一点。”

“这个功能孩子可能不会用。”

这些话表达了我的感受，却不一定能让问题得到解决。

后来，我开始逼着自己继续往下拆。

“看着不舒服”，究竟是字体太小，还是字重太轻？

“声音不太对”，究竟是音色不好，还是声音启动太慢？是不是快速点击以后，几个声音叠在了一起？

“识别不准”，究竟是没有识别到声音，还是识别到了错误的八度？

“谱号位置不对”，究竟是整体大小有问题，还是它与五线谱某一条线的关系不正确？

我仍然会先相信自己的感受，因为音乐教学本来就包含大量听觉和视觉经验。

但感受之后，必须找到可以观察、可以复现、可以验证的条件。

这也是我在开发过程中学到的重要一课：

非技术人员不必一开始就会说专业术语，但一定要能把专业判断说清楚。

技术工具可以帮助写代码，却不知道孩子为什么会在这个音上反复失败；AI可以迅速生成一个功能，却不知道这个功能是否符合真实的学习顺序。

这些判断，仍然需要教师完成。

“能运行”，离“孩子能用”还很远

做软件以后，我经历过不少返工。

有时一个谱号调整了很多次，改好一个地方，另一个地方又出现问题；有时本地运行完全正常，部署到正式环境后却产生了差异；有时新功能刚接进来，已经稳定的旧功能又坏了。

还有一些功能，从开发角度看已经完成，但真正交给孩子使用时，我才发现：

它只是能运行，并不好用。

成年人看到麦克风权限被拒绝，可能知道应该去设置里重新打开；孩子只会觉得“它坏了”。

成年人连续点击播放，发现声音叠在一起，可能会停下来等待；孩子很可能点得更快。

成年人看到“音高错误”，也许能理解系统的判断；孩子更需要知道的是：

我哪里做得不错？现在最应该改什么？下一遍可以怎样练？

产品是否完成，不能只看按钮有没有反应，也不能只看代码有没有报错。

它最终要接受一个更真实的检验：

孩子愿不愿意继续用？用了以后，他是更清楚下一步怎么练，还是更害怕犯错？

AI可以帮我做软件，但不能替我决定什么是对的

现在，AI和各种开发工具确实降低了制作软件的门槛。

它们可以帮助我整理需求、生成代码、查找问题，也能快速尝试不同方案。很多过去无法想象的事情，现在普通教师也有机会参与。

但我越来越清楚，门槛降低，不等于专业判断可以消失。

AI可以根据检测结果，把反馈组织成孩子容易理解的话；但如果没有标准乐谱，它就不应该假装知道每一个音是否唱对。

技术可以画出五线谱；但和弦拼写是否正确、转位解释是否合理，仍然需要音乐专业人员判断。

软件可以承担重复播放、记录和基础检测；但它不能因为会生成语言，就冒充自己已经理解了一个孩子的全部学习状态。

不知道并不丢人。

对教育产品来说，假装知道才危险。

我做的不是“教师替代品”

有人可能会问：既然软件能检测、能反馈，以后是不是就不需要教师了？

我的答案恰恰相反。

越深入开发，我越确定教师的重要性。

因为真正的教学不是简单判断对错，而是知道：

这个孩子为什么会错？现在应该纠正，还是先让他建立信心？题目需要降速、缩短，还是调整音域？这是一个必须解决的基础问题，还是暂时可以放过的细节？

软件可以把教师反复做的工作变得更稳定，却不能自动拥有这些判断。

我希望它承担的是重复、基础、可以明确验证的部分，让教师把时间留给更复杂、更需要理解和创造力的事情。

它不是教师的替代品。

更像是教师不在身边时，一个愿意反复示范、不轻易失去耐心的助手。

普通教师，也可以成为产品的设计者

我仍然不是程序员。

直到现在，我也还在学习，会遇到看不懂的问题，也会因为一个小功能反复修改。

但我已经不再认为，只有懂代码的人才有资格参与软件开发。

教师最了解课堂里真正发生了什么，也最清楚孩子会在哪里卡住。很多产品缺少的，恰恰不是一个新功能，而是一个来自真实教学现场的判断。

非技术背景当然会带来困难，但它也让我始终记得一件事：

我不是为了展示技术而做软件。

我做它，是因为有些孩子离开课堂以后，仍然需要有人告诉他：

“这一遍比刚才稳定了。”

“我们先不唱整段，只练这两个音。”

“这里还没有完全唱准，但你已经找对方向了。”

“再试一次，你可以做到。”

开发教育软件的过程，也是我重新整理教学经验的过程。

那些过去凭经验完成的判断，现在必须变成明确的顺序、条件和边界。这个过程并不轻松，却让我更加清楚：哪些方法真正有效，哪些功能只是看起来先进。

现在，每当我准备增加一个新功能，我都会先问自己三个问题：

它解决了谁的什么问题？

它给出的结论可靠吗？

孩子用完以后，是更愿意继续练，还是更害怕犯错？

这些问题，比功能数量重要得多。

我不是程序员。

但我是一名教师。

而教育软件首先应该懂的，正是教育。

可以体验我的视唱练耳软件 www.shengyitongmusic.com