鄭晴元：以柔制剛：從混沌走向脈絡

1. In one sentence

STR Network co-founder 鄭晴元 used three scales — macro, micro and management — to take apart how a forty-person entertainment company, with no management system built for its industry, used an inventory of "human–machine" and "machine–machine" information nodes, domain-driven design and Mermaid diagrams to turn spoken-word experience into a clear structure that can be argued over continuously and handed to AI to take part in.

2. The session

The speaker's background

鄭晴元 is a co-founder of 薩泰爾娛樂股份有限公司 (STR Network externally, from "satire"), founded in 2018, a content company whose main products are online comedy — *The Night Night Show* and the *BURN* series — and live comedy shows (verified against Wikipedia and Global Views Monthly). He is responsible for the company's operational back office design, knowledge system work and AI tool integration.

He first recapped last year's session: that deck accumulated about forty thousand views, and the talk title in the official programme was "building an organic management 'system' with AI", while on stage he called its English title "Drafting and Crafting with Generative AI". In one sentence, it was about how he, a muggle, learned Apps Script and reshaped the logic of the company's contract issuance and labour insurance forms, and tried to build an accounting system; that adoption was not yet complete in May last year, only finishing in the fourth quarter.

Three scales: macro, micro and management

He came in through "AI first", the industry's current slogan, noting that Shopify and Duolingo have both issued similar declarations: to open a new role, you first have to prove AI cannot do it before recruitment is approved. He took the problem apart across three scales: at the macro scale, the anxiety induced by big tech's relentless acceleration, with new models and products announced daily; at the micro scale, that entertainment and the performing arts remain relatively traditional industries with traditional management, because no ERP or management system exists for this industry to adopt off the shelf (he joked that otherwise he would not have had to deal with labour insurance forms himself); and at the management scale, STR Network's own actual situation — only by coming back to what you can handle yourself does the world's acceleration genuinely become relevant to you.

He introduced the company's scale with some self-deprecation: STR Network is a forty-person entertainment company whose main products are online and live comedy production, serving general audiences, corporate clients and comedians themselves; its core capabilities are experience design, brand and programme planning, and how to marshal talent across the comedy industry at a scale of forty people. He also mentioned that at seven that evening STR Network had a comedy show at the same venue — on verification, this was 《炎不由衷 Feat. Generative AI 年會》, performed by 藍恩, 壯壯 and 學仁.

Seeing the complexity of information flow through one simple question

He used the seemingly simple question "how many tickets is STR Network currently selling" to demonstrate a complex truth: the company has several shows on sale at once, on ticketing systems with different conditions and different APIs, and the most homespun approach is a person opening each back office at a fixed time every day to fill in the numbers. But behind that single question, each role actually wants to ask something different — which is the same phenomenon as questions branching endlessly when you converse with a large language model.

They therefore inventoried three kinds of collaboration node: between people, verbal alignment is needed (is everyone using the same word, the same "project", to mean the same thing — which is why you need a kick-off meeting to align expectations); between people and machines, he made a concrete argument — stop working across organisations over LINE, because as long as you are still on LINE, automation is very hard to push; and between machines, API integration should be as smooth and accurate as possible. He also noted that people and machines read differently by nature: people like diagrams, tables and summaries, while machines want unpivoted raw data row by row — and the same data, in different situations, needs presenting differently for what the user actually wants to see. A manager typically wants an aggregated intermediate table, but when they just want to check ticket sales casually over lunch, even a table is too much trouble.

Turning ticketing configuration into a schema: DDD and Mermaid in practice

The concrete case is configuring ticket prices and seating zones: screenshot the back office configuration screen, hand it to a large language model and ask it to convert it into the schema the database needs (each zone's ID, its configuration), then use that schema to talk to the ticketing system. Behind this is a framework STR Network has been adopting for about three months — domain-driven design (DDD), turning spoken, organic interview material into a clear structure you can keep discussing and keep working with.

He was candid that he can no longer do much front-line execution himself, and the flows he designs often fail to match what the front line actually does, so he has to rely on a great many interviews (sometimes just a question or two by the water cooler, or asking a colleague to send over a document or two) to understand what the front line genuinely relies on when executing. The interviews get drawn out first by hand, on whiteboards with sticky notes, and then converted into Mermaid flow diagrams — because Mermaid satisfies both machine readability (a text syntax) and human readability (the rendered diagram). They have in fact been drawing flow diagrams in Mermaid since around 2021 or 2022, including analysing contract structures; the new realisation this time is that AI can further help convert a hand-drawn flow into Mermaid syntax, and he included a link in the deck to a GPTs tool you can try directly, photographing a flow sketch and uploading it to get Mermaid syntax out automatically. The goal is a clear business process diagram, a unified domain vocabulary (words like 貴賓, 邀請人 and 代表人 that only the front line understands and managers may not) and defined key events; his lesson is that only once the context is visible and the language is defined does technology have somewhere to land.

The real issue is not productivity but attrition

He argues the question worth asking now is not "can we produce more" but "can we lose less". He said outright that he dislikes AI-generated storytelling content — "you have no responsibility toward the whole environment"; and back in his own workplace he is often challenged by colleagues with "is this data analysis actually meaningful?" If something will not drive any change, do not do it. His simple test: will the next step of this action affect anybody? If it will produce no positive effect, do not do it — one of the ways he protects his own limited energy.

He also splits attrition across the nodes into three kinds: between people there are gaps in understanding (ask "how are ticket sales going" and the asker may want the number of tickets while the answerer talks revenue, and different price tiers have different fill rates anyway); between people and machines there are operational obstacles; between machines it is relatively simple. He restated that the real purpose is collaboration, not productivity itself.

Grading the issues: frameworks top-down, solutions bottom-up

He noted that although the company has a dedicated team to inventory issues, what he really wants to spread is across the whole organisation — and not every problem deserves a hundred per cent of the effort. He distilled a three-tier division of labour: tier one is individual development, where the company subsidises AI software and does not interfere in how colleagues build or what the output is used for, which is how quite a few Slack automations have already grown; tier two is development to a standard, where management defines the shared language for collaboration between departments, and after colleagues build to that standard the team helps adjust whatever can be related between databases; tier three is team-led development, usually involving more complex data integration and needing further assessment of whether a good front end is warranted. He believes that when a flow spans management end to end and the steps and situations are complex, setting the standard and following the process actually makes the executor's job easier — not everything needs that much freedom. His hope is a virtuous circle: clear language from the top down, solutions growing from the bottom up.

The year's change: from drafting toward crafting

Last year he compared the whole journey to a dramatic arc; this year he considers himself finishing off the drafting and beginning to move toward crafting — turning the flows he decomposed last year gradually into pages and practices that hold up. What has not changed is "make it fun"; what he has given up is chasing adoption speed, focusing instead on decomposing the details of the setting, and staying flexible about any front-end form (Slack, web or app), ready at any moment to pair the same data with a different front end.

Closing echo

He closed by saying that if STR Network were to issue an "AI first" press release, he would not stress how AI replaces people but how AI enables the people in the organisation, so that bottom-up contributions become visible. He also shared that he has spent much of the past six months reading novels, coming to understand that stories like *Harry Potter* stick in the memory in such detail because they create a complete world — which he sees as the same thing as "magic has to be imaginable before its details can be managed", and so encourages everyone, alongside pursuing efficiency, to rediscover the pleasure of literature. Finally he closed the session by echoing what 李怡志 had shared earlier the same day: this is also a response to 李怡志's point about how you take responsibility for the messages that pass through you and the messages you create, and about not provoking the whole world with too much emotion (see "李怡志：如何生成有效的圖騙").

3. Figures and cases

4. Lines worth keeping

• "Once the whole context is visible and your language is defined, that's when this technology has somewhere to land."
• "The real issue isn't productivity, it's attrition."
• "Who does the next step of this action affect? If it won't produce any positive effect, don't do it."
• "Let the framework come top-down, and let the solutions come bottom-up."

5. Tools and terms mentioned

• DDD (domain-driven design): the framework for turning spoken experience into a clear structure
• Mermaid: the flow diagram syntax that is both machine-readable and human-readable, used by the team since around 2021 or 2022
• Schema: the field definitions once the ticketing system's data is structured
• GPTs: the tool he mentioned for converting a hand-drawn flow diagram into Mermaid syntax
• Apps Script: the tool used in last year's session to reshape the company's contract and accounting logic

6. Wider observations

The most distinctive thing about this session is that it showed almost no AI-generated output, spending most of its time instead on "how do you turn spoken experience in a group of people's heads into a schema everyone recognises". Underneath, that is the same argument as 張志祺's session (Simpleinfo) the same day — whether AI genuinely lands depends not on how strong the model is but on whether the organisation has defined its own language and flows clearly. 張志祺 comes at it from experience design and 鄭晴元 from domain-driven design and tiered governance, two routes to the same place.

His insistence on retiring the LINE group in favour of structured data communication sits alongside his line that "machines want unpivoted data, people want pivot tables", which identifies why so many organisations get stuck adopting AI: not that model capability is insufficient, but that the form the data is presented in was never designed separately for the two kinds of user in the first place.

7. Sources