Name First, Body Second, Then Storyboards: Turning a Film into Enumerable Records

Name first, body second, then storyboards—these three steps in order form the complete data flow of the Yuncao Academy system from zero to a finished film. The first operation occurs in the dbvideo_bookidx table. Here you insert a row, fill in the book title "The First Avenue," and the system automatically assigns a globally unique bookcode, such as BK001. This bookcode is the root node of the entire project. All subsequent chapters, characters, locations, storyboards, and image and video tasks are linked to it through foreign keys. After insertion, a single row in the bookidx table represents the existence of this film. At this moment, you have no content yet, but the database has already marked out a namespace for the entire work. The next step is body second: the full text of 93,000 characters is split by chapter into 69 records, written one by one into the dbvideo_article table. Each record contains article_id, bookcode, chapter title, body text, the atctype style field, and a status marker. Each time a chapter is entered, the article table gains one row, meaning the novel's complete body is gradually placed into the database. By this point, all the story's content information has entered the system, but no visual derivative data exists yet. The third stage, then storyboards, is the most technically involved step in the entire flow. You call the funx.atctoscene function, pass in an article_id, and the function synchronously calls the large model to read the full text of that chapter, automatically recognizing character names, appearance traits, dialogue snippets, and scene location descriptions. The recognition results land in the dbvideo_roles table, one row per character, containing role_id, name, appearance field, personality tags, and the article_id of the chapter where the character first appears. Meanwhile, scene descriptions land in the dbvideo_places table, one row per location, containing place_id, location name, description text, and the article_id of the chapter where the scene first appears. Finally, the function splits the entire chapter text into individual scene descriptions based on narrative units, and each scene description is written into the dbvideo_process storyboard table, containing scene_code, article_id, rolex, placecode, action, and other related fields. This step perfectly corresponds to two formulas: scene equals character plus location, and dbvideo_process equals dbvideo_roles plus dbvideo_places, because every row in process carries both a character reference and a location reference, and only when both exist is the storyboard complete and executable. Take Chapter 5 of "The First Avenue" as an example to illustrate the concrete timeline. At 7:00 PM, you insert the Chapter 5 body into dbvideo_article, with the title "The Night Before the Siege in Five Elements Dragon Flag." The body is about 1,200 characters, mainly describing Lin Xuan standing before the East Gate, conversing with Liu Ruyan, and then gazing into the distance alone. At 7:02 PM, you call atctoscene, and the large model takes about 15 seconds to respond. At 7:02:30 PM, the system automatically inserts two rows into dbvideo_roles: one for Lin Xuan, with appearance described as black hair tied in a high ponytail, wearing an indigo narrow-sleeved long robe, with a black iron long blade at his waist; another for Liu Ruyan, with appearance described as a woman in white, long hair reaching her waist, holding a green-steel sword. At the same moment, the dbvideo_places table gains a record for the East Gate, described as a gate tower built of blue-gray city bricks, a stone-carved plaque above the gate arch, stone slab road on the ground, with stone lions and flagpoles on both sides. At 7:03:05 PM, the dbvideo_process table receives five storyboard records at once: Lin Xuan approaches the city gate, Liu Ruyan pauses and looks back, Lin Xuan grips his blade and gathers force, Liu Ruyan turns and swings her sword, and Lin Xuan watches Liu Ruyan leave through the city gate. In just three minutes, Chapter 5 has gone from plain text to a storyboard data chain. Each process record carries all the information that storyboard should have, including the role_id of the character reference, the place_id of the scene location reference, the text description of the on-screen action, and the article_id of the corresponding chapter. At this point, you can export these three tables to Excel and immediately obtain a readable storyboard sheet, clearly listing each shot's character, location, and action, along with its parent chapter and corresponding original text position. How is this different from traditional manual storyboard writing? In the traditional approach, a storyboard sheet is a hand-drawn table in a Word document with no structural constraints and no easy way to automatically link back to the original text paragraphs. Here, the storyboard sheet is structured rows in a database that can be directly read by subsequent image and video generation tasks and concurrently processed by different clients. When you inspect the dbvideo_process table, each row's modification time and operator are recorded, so any step can be traced. This database-driven creative workflow makes the journey from creation to finished film no longer a black box. Directors or producers no longer need to rely on memory or scattered notes to manage project status; they simply query the record counts and status fields of each table periodically to grasp the overall progress. For example, you can run a simple SQL statement to count, across all 69 chapters, which chapters have completed storyboard splitting, which are still at the text entry stage, and which chapters have many characters but few locations, helping you estimate downstream image generation workloads. When a character changes in a chapter, you only need to update one row in dbvideo_roles, and all storyboard records referencing that character will automatically use the new character description on the next image generation run, with no need to edit storyboards one by one. This traceable, rollback-capable, replayable engineering process means the director can revisit any operation at any time—for example, checking the backend logs to review a specific atctoscene call result on a specific day, or rolling back bad data caused by an erroneous split. For a scenario where one person completes an entire work independently, this database-driven approach provides a level of end-to-end control that manual project management cannot achieve. Without system support, one person must either manually maintain relationships among hundreds of files using documents and spreadsheets, or rely entirely on memory and temporary folders, inevitably harming efficiency and quality. But in the Yuncao Academy workflow, all your creative decisions settle into rows of database records—starting from a single sentence in bookidx, through the full text of each chapter in article, to every character and location in roles and places, and finally to every shot in process. The entire project's data model has clear hierarchy and interlocking layers. Once all 69 chapters have completed splitting, you possess an ordered data set of every shot in the film, and this data set itself becomes the planning foundation and traceability bedrock for all subsequent generation tasks. Before this, creation was an instantaneous inspiration happening in the mind, a process that cannot be replicated; here, creation has been explicitly transformed into database records that are enumerable, countable, sortable, and batch-operable. And that is the true meaning of those three phrases—name first, body second, then storyboards. They are not just an operational sequence but a data engineering philosophy that constrains the vague chaos of film creation into a clear hierarchical structure.