The real hard part of meeting minutes: after a change of mind, which version counts?
A commercial meeting recording with planted changes of mind, budget misreadings, and unconfirmed requirements was used to test Ming-3.0-audio-flash. What is really worth examining is whether final decisions, to-dos, and unconfirmed items can be kept separate.
The most annoying part of meeting recordings comes after the meeting. Does the budget include newly added work? Has the delivery time changed? Was a certain requirement actually confirmed? Going back through the recording to verify these points can easily eat up half an hour.
Majiang AI Lab tested the Ming-3.0 audio model family open-sourced by Ant Ling in an X article. Original article link: Majiang AI Lab article; related tweet: gKev1n's tweet.
Ming-3.0 has three parts: asr-tiny performs speech recognition, audio-flash directly understands audio and handles follow-up questions, and tts performs speech synthesis. The test chose audio-flash because the old workflow usually involved first converting to a verbatim transcript and then feeding it to a large model; there were more steps, and information such as tone, pauses, and the acoustic environment was easily lost. The official cloud API documentation gives a maximum audio duration of 3,600 seconds, with separate constraints on file size and request body.
The test sample was a fictional three-person sponsored-content meeting: brand lead Lin Na, MCN lead A Sen, and project operations coordinator Xiao Zhou, discussing a FlowSnap promotion. It embedded several points where everyday meetings often go wrong: the brand side initially understood it as three influencers, with a budget of 6,500 covering everything; the MCN explained that 6,500 corresponded to two X influencers, did not include Xiaohongshu, and the third influencer would need the budget reconfirmed; the brand side explicitly said additional budget could not be confirmed for the time being, so the third influencer should not be scheduled yet. The delivery time was also changed from Tuesday noon to before 6 p.m. on October 27. There was also a negative requirement: 'There is a free trial, but it cannot be promoted as permanently free.'
The interesting part of this kind of test is checking against the answer key. What really matters is whether the final number of collaborators, the budget range, the deadline, and the owners are correct; whether the minutes read smoothly can take a back seat. Majiang AI Lab also designed follow-up questions: In the end, how many influencers? Was the third one approved? Does 6,500 include Xiaohongshu? Is the first draft due Tuesday noon or 6 p.m.? Was any registration conversion target promised? In real work, suddenly remembering 'Did the client actually agree to add budget?' is more common than reading the entire set of minutes.
For short speech recognition, asr-tiny was tested separately. The official cloud transcription API currently requires each audio clip to be no longer than 30 seconds and each file no larger than 10 MB, supports WAV and MP3, and cannot handle a one-hour meeting dropped in directly. The test audio was about 20 seconds long and included mixed Chinese/English speech and time-correction information such as FlowSnap, X Article, CTA, UTM tracking link, six thousand five hundred, two influencers, and before 6 p.m. on October 27.
The workflow was split into four steps: collect the audio, choose a model according to the task, organize it with a fixed template, and store it in the knowledge base after manual verification. The template includes meeting summary, final decisions, action list, unconfirmed items, key numbers, and risk alerts. The action list records owner, deadline, and deliverable, and leaves them blank if they are not explicitly stated. This detail is closer to real execution than 'summarize this for me.'
Some users mentioned in replies that audio understanding and meeting minutes should be viewed separately; others asked whether, when something is marked unconfirmed, the model truly leaves it blank or conveniently fills in numbers from the discussion. This question is worth keeping. Open-source models also do not mean free cloud use; open weights do not mean there are no costs for compute and API inference. The recording, collaboration, sharing, and task synchronization of mature products such as Feishu and Tencent Meeting are not something a single model can fully cover.
A more practical approach is to first get recording, understanding, manual verification, and storage working end to end, and only then consider automated integration. For people who meet across platforms, the value is that audio organization capabilities are no longer tied to a particular meeting app. If requirements change later, old conclusions can be kept, but they must not continue to be mixed into the current to-do list. Ideally, each conclusion should leave three things behind: the corresponding audio segment, the last confirmed time point, and the manual verification status. One more test could be added: process the same recording as a whole and in segments, with a change of mind falling right across a cut point, and see whether the system can keep the final decision and remove tasks that have been canceled.
Related links:
Ling Studio online demo
Ming-3.0-audio-flash open-source project
Ming-3.0-asr-tiny
Cloud API usage documentation
发布时间: 2026-11-09 01:29