使用 Cursor 重写 stt demo

原创于 2025-05-28 21:52:52 发布 · 1k 阅读

CC 4.0 BY-SA版权

文章标签：

在 3 月的时候，为了方便自测，笔者使用 cursor 实现了一个 stt demo ，以简化测试流程。但是计划总是没有变化快，在 5 月的时候，产品做了整体的重构升级，连 api 接口名称都大变样。

做人心态要好，大不了就重新实现一个 stt 的 demo，毕竟现在有了 cursor 的支持，想想应该不复杂了。

注：重构的版本，当然在体验感上必须由于之前的版本。

笔者自己的思路是

最终实现的效果：

输入频道名、appid 、测试的环境 api 信息后，可以开启一个支持 stt 频道
进入频道后，可以看到「转录翻译展示」、「转录和翻译的历史回溯」、「启停 stt」的 button

注：这个语言统计分析，原本的设计是想做一个转录和翻译的延迟的分析，但是笔者暂时还没有更好的思路，暂时留白了

相较于 3 月分实现的 demo ，这个测试 demo 的功能更加丰富，不仅支持请求 staging 、prod 环境，还支持了翻译设置。

笔者复盘了一下使用 cursor 实现这个 demo 的耗时，前前后后挤出来的时间大概要 3 ~ 4h，感觉这个极简的 demo 实现，以 cursor 能力，不应该耗时这么久。

回想了之前 AWS 宣传 Q AI 编程助手时，讲解的一些例子。大概问题应该在：

如果过分压榨人的价值，人会反抗；但是如果过分压榨机器呢？比如，笔者反反复复的让 cursor 基于 stt demo 的问题，进行修复。

《千与千寻》里说「吃太胖会被杀掉」，那如果被 AI 训练的不再思考，会怎么样呢？

注：AI 应该是作为人的助力，而不应该人变成助力。不过照着这个趋势下去，AI 似乎取代人成功主力也没什么不可能的。

随处可见的机械手臂，取代了人工搬运，是好事！

复盘过之后，笔者在思考，假如真的需要重新再再再次实现一个 demo ，这次的实现是否可以压缩到 1 ~ 2h 呢？

想想应该也没有什么不可能的，毕竟 AI 强大的记忆存储系统和推理能力，是人类不能达到的。

让 cursor 的实现思路优化版本：

首先，需要实现一个 demo ，demo 需要使用 xx 公司的 rtc & stt 两个产品，需要支持 stt 转录和翻译的语种设置，实现的时候要充分考虑测试 prod & staging 两个环境的可能，以上述信息生成一个基础的设计文档。
其次，在设计文档中如果有不明确，需要补充的部分，人工补充进去，比如暂未对外部发布的 stt api 等。
最后，按照这个设计文档逐步实现 stt demo ，注意实现时需确保所有 button 等功能可以被访问。

如果下次版本升级或者 api 变化，笔者就按照这个思路再实现一次，争取 1h 内能速成！

如果一个问题总是出现，并且需要消耗大部分的时间，就要想办法做成自动化。人的精力有限，应该花在做有意义的事情上，今天也是努力的一天吖！

后来我才知道，前程似锦是告别的意思。
在最艰难的时刻，我们总想寻找一个依靠，但最终会发现，有的山布满荆棘，有的山满是野兽。所以，你应该成为自己的那座山。
我站在人潮中央，思考这日日重复的生活。我突然想，如果有一天，垂老和年轻都难以惊起心中连漪，一潭死水的沉闷，鲜花和蛋糕也撼动不了。如果人开始不能为微小事物而感动。那么地震山洪的噩耗想必也惊闻不了。如果活着和死亡的本质无异，那便没有了存在的意义。