不行哈，这个因为是朋友提供的接口，然后它是有一定的使用限制的。单纯读一读歌词这种小量文本还可以，但是真的要做于生产环境，像是屏幕阅读器和一些合成类比较长的文本的话，会触发讯飞崩控，导致用不了的。

没有哦，除非做成系统TTS给宝箱调用的

应该不太行，在线的延迟很大的，而且离线也用不了，这个不具有那种快速的跟随和响应速度，我其实不太建议大家用在屏幕阅读器上，大家可以用来听小说

更新啦https://www.guangyapan.com/s/1925921723620978719_aeWhjBu726g3wbT0

6

光压云盘

很简单的，比如你要唱周杰伦的《告白气球》，那只需要点开我们的软件，点击搜索，搜索《告白气球》，回车，然后点击搜出来的《告白气球》，然后会进入歌曲的歌词详情页，点击开始播报按钮，软件会尝试自动检测后台有没有音乐在播放。如果有伴奏在播放，就会自动开始朗读歌词，会根据歌词的实际歌曲的某一句时间来智能判断，会提前它几秒钟朗读，来帮助我们跟唱。

对，就是整理自此前和群里的一起的一些零碎的聊天记录。如果不整理，我觉得会忘。所以写出来等于也是一个加深印象的过程。

怎么说呢？我其实教大家的是一种方法论。这种方法论的前提是教你们如何去用 AI 协作，或者说如何高效的用 AI 协作。在这个与 AI 不断的沟通和让 AI 不断拷问我们的过程中，不可避免是需要触动我们思考，进而把我们脑中的那些抽象的思想给表达出来。而这个过程我觉得也是一个思考和思辨的过程。还有一个是和 AI 的沟通过程中，并不是意味着你一点都不学习的。它一定是会逼着你，或主动或被动的去学习一些东西。比如当你自己都不知道某一个现象是具体怎么导致的时候，比如说缺失无障碍标签这句话你都不会表达，那对于 AI 来说，它也是 get 不到你的。所以说，我不认为使用 AI 会让我们脑子变笨，合理利用工具是非常有必要的，不用太过焦虑。

第四章 别急——软件是一点点叠出来的

我最早做这个音乐播放器，花了一周多才出第一个正式版。中间无数次“感觉又做砸了”——崩溃日志不生效、某个逻辑跑不通、无障碍改完跟没改一样。这都是正常的。

不要一次性把所有需求塞给AI

AI的能力有上限，一个Bug就可能让它产生幻觉，你把整个工程一次性扔给它，幻觉相当于叠满了。

正确做法：一点一点来，一个功能一个功能地叠加。普通人写一个像样的软件本来就需要很长时间，AI已经大大缩短了，但依然不可能一蹴而就。

逻辑跑通之前别碰UI和无障碍

核心逻辑没跑通之前，绝对不要碰UI，更不要碰无障碍适配。后面很可能因为逻辑问题重构页面，一重构，前面所有UI工作和无障碍适配全返工。

先把功能跑起来。逻辑稳定了、数据层服务层都OK了，再让AI优化界面。整个项目结构稳定了，再考虑无障碍适配。

不确定的时候让AI先问清楚

不确定某个问题该怎么描述，或者不确定AI是否理解了你的意思，停下来。让AI先问你，而不是你直接命令它怎么做。

比如AI应该问你：“你觉得什么样的UI风格适合你的需求？”“你希望读取文件是直接读源文件，还是复制一份到APP目录？”“这个功能希望支持哪些操作手势？”

当AI用一系列问题把抽象想法具象化之后，做出来的东西才准确。不懂编程的情况下，不要限定AI发挥，让AI通过提问来榨干你脑海里的想法。

关于充钱

还没想清楚要做什么，不建议先花钱买Token或买服务器。AI产品不便宜，额度买了不用就是浪费。明确要落地某一个具体需求时，再投入资源会好一些。

写在最后

不要因为自己不懂，就放弃表达和确认的权利。

不懂代码，但你懂自己的需求。不懂无障碍的技术实现，但你懂TalkBack摸上去是什么感受。不懂架构设计，但你懂“这个软件用起来顺不顺手”。

把这些“你懂的东西”清晰地说给AI听——用客观、中性、不带情绪的语言描述现象，把解决方案的判断权留给AI，然后在一个功能一个功能的迭代中慢慢打磨。你不是在写代码，是在用自然语言做产品设计。

这条路注定不会太快，但只要你坚持“先跑通逻辑、再打磨细节、最后优化UI”的顺序，坚持“不把需求一次性塞完、一个功能一个功能叠”的节奏，坚持“用客观描述代替主观评价、用现象代替指令”的沟通方式，你一定能做出一个真正能用的东西。

我已经做到了，你也可以。