TutorialsTake-Home Practice: Five Templates and the Red Lines
Five prompt templates ordered by when you use them, two blank tables you can use immediately, three general red lines and two specific to this lesson.
How to use the five templates
You are not meant to run all five at once — take the one that matches the moment you are in:
| When | Which one | What it solves |
|---|---|---|
| You want to write down a piece of experience | Template 1: pouring your experience into AI | From "only I know it" to "structured and handover-ready" |
| You need to see what a process actually looks like | Template 2: one sentence into a state machine | Turning spoken description into states and transitions |
| It looks ready to launch | Template 3: probe the boundaries | Finding the pits before real data falls into them |
| Deciding which work goes to AI | Template 4: automation assignment table | Levels plus criteria instead of gut feeling |
| It has been running for a while | Template 5: post-launch review | Diagnosing whether the design or the execution is at fault |
Template 1: pouring your experience into AI (capturing a new process)
When to use it: a process exists only in someone's head and needs to be handed over or written down, but you do not know where to start.
I am a [role], responsible for [one-line summary of the work].
A new colleague is about to take over my work, and I need to hand over this piece of work completely:
[work name / trigger scenario]
The usual way to do it is:
[describe in plain speech where it starts, what each step does and who it goes to afterwards — do not format it, write it like a chat message]
Please structure the above into:
1. A step list (number + one line + responsible role)
2. Which documents, tables and systems are involved
3. The hidden steps or decision points you think I did not mention but probably exist
Requirement: mark the hidden steps as [to confirm] so I can verify and fill them in.The most valuable part is item 3: let it guess what you left out and mark those items [to confirm]. Then you only verify "yes / no" for each — far faster than recalling from scratch.
Template 2: one sentence into a state machine (the core breakdown)
When to use it: you roughly know the steps but the states and branches are still messy.
You are a process modelling expert. I have a business object: [describe it, e.g. "a material request ticket" or "an expense claim"].
Its life cycle is described as follows:
[plain description of the process from creation to end]
Please output:
1. A complete state list (each state summarised in two words, e.g. "awaiting review", "in execution")
2. A transition diagram (text arrows: State A ->[trigger condition]-> State B)
3. Mark which states are "waiting states" (need an external action to advance) and which are "processing states" (the system is working)
4. Are there any bypass states (skipping steps to reach another state directly)?
Format requirement: states in Chinese, transition conditions under 15 characters.Item 3 matters most. You often cannot tell "running" from "waiting" — once the waiting states are marked, you discover that most of a process's elapsed time is not spent doing the work but waiting for other people to reply.
Template 3: probing the boundaries (crash prevention)
When to use it: the design looks complete and you are about to go live.
Here is a workflow I have designed:
[paste the state machine and step table]
Assume this process is already live. Please sweep it for possible failure scenarios from these angles:
- What if the user submits repeatedly?
- What if someone in the middle stops replying or leaves the company?
- What if a system or tool call fails?
- What if the rules conflict (condition A and condition B both hit)?
- What if this process needs to be rolled back or cancelled?
For each scenario give: [problem description -> impact (high/medium/low) -> recommended handling]
Sort by impact.This pair with the classroom Prompt B: B sweeps six classes from a QA angle, Template 3 sweeps five scenarios from a "what if it is already live" angle. Running both gives better coverage.
Template 4: the automation assignment table (deciding what to do and not do)
When to use it: whenever the question "should we automate this?" comes up, use it instead of guessing.
For the following process steps:
[step table]
Please make a three-way judgement for each step:
- AI can do it: inputs and outputs are clear, rules can be encoded
- Human-AI collaboration: AI drafts, a person reviews and decides
- Must be human: physical operations, complex judgement, interpersonal trust
Judgement criteria:
1. Is this step's input fully structured, or does it require understanding fuzzy information?
2. Is this step's output unique, or does it need aesthetic or business judgement?
3. Would a mistake here have serious consequences?
4. Does this step depend on an external system, or is it pure information processing?
Finally output a summary table: | step | level | reason | suggested implementation || Level | Criterion | Typical steps |
|---|---|---|
| AI can do it | Inputs and outputs clear, rules encodable | Information extraction, format conversion, rule-based dispatch |
| Human-AI collaboration | AI drafts, a person decides | Quotation notes, first drafts, acceptance material checks |
| Must be human | Physical work, complex judgement, interpersonal trust | On-site repair, commercial negotiation, final fault attribution |
Criterion 3 is the one most often ignored: would a mistake have serious consequences? Judging whether materials are complete for closure means redoing the process if wrong, while publishing a notice wrong only means reposting it — the first should stay with a person, the second can go straight to AI.
Template 5: post-launch review
When to use it: the process has been running a while and you start hearing "why is it stuck here again".
Here is the actual situation after our process ran for [N days/weeks]:
[describe: which steps got stuck, which branches turned out more common than expected, where human involvement is too much or too little]
Please help me:
1. Diagnose the root cause (a design gap or a drift in execution?)
2. Suggest improvements (which steps can be merged, split or given an earlier check)
3. Update the state machine (add any states the original design missed)
4. Assess whether more automation is needed, or less (too much defeats the purpose)
Output format: | current problem | root cause | improvement | priority | expected gain |Two blank tables you can use immediately
One-page workflow breakdown
| Step | Trigger | Input (what is read) | Action | Output (what is written) | Executor | Next |
|---|---|---|---|---|---|---|
| S1 | person / system / AI | -> S_ | ||||
| S2 | -> S_ | |||||
| S3 | -> S_ | |||||
| S4 | -> S_ | |||||
| S5 | end / rollback -> S_ |
State transition log
| Current state | Trigger event | Condition | Target state | Notify whom | Exception handling |
|---|---|---|---|---|---|
Print both tables and fill them in by hand. Wherever you cannot write a cell, that is a part of the process you have not thought through — easier to expose on paper than on screen.
The red lines
Three general ones
- AI makes things up with a straight face: numbers, dates and names must be checked by hand — it sounds just as confident when it is wrong;
- Never feed it confidential or sensitive information: anonymise first, or do not feed it at all — what you send out cannot be taken back;
- The output is not the final version: your name is on it, and so is the responsibility — review it once yourself before it goes out.
Two specific to this lesson
-
Do not skip the raw description and let AI design the process: describe the current situation first, and let AI structure it. If you simply say "design a process for X", it gives you industry best practice, not your reality.
-
Always run the breakdown on a real case: a first pass misses at least 30% of the boundary cases — without real data you will never find them.
Tool selection reference
| Tool | Fits | Notes |
|---|---|---|
| DingTalk AI Tables | Process status tracking, team boards | Fields as states, views as boards, good for light workflows |
| Yida | Approval flows, forms, cross-system integration | Drag-and-drop, supports complex conditions and role permissions |
| Qwen Office | Process breakdown practice, AI image / email / notification | Natural-language driven, chains end-to-end automation with skills |
| Diagram tools (draw.io / ProcessOn) | Drawing state machines for the team | Visual aid for communication, does not carry execution logic |
Break down the process with AI first, then choose the tool. Tools solve "how it runs"; the breakdown solves "what runs" — reverse the order and the tool only automates confusion.
Key points from this lesson
| Remember this | Because |
|---|---|
| The five templates map to five moments; do not run them all at once | Take the one that matches the moment |
| Template 1's [to confirm] is the real labour saver | You verify instead of recalling |
| Mark the waiting states explicitly | That is usually where the time really goes |
| "How bad is a mistake" decides ownership | The same step with different consequences deserves a different level |
| Tools come last | Break it down clearly first, then choose |
Hands-On: Three Prompts That Open the Process Up
Working through a customer repair ticket as the main case, three prompts in relay produce the state machine, step table, boundary list and automation assignment — with each prompt in full and the one thing to watch.
Assignment: Turn One of Your Processes into a Runnable SOP
Three levels in one assignment — reproduce the classroom result with Prompt A, run the full six-step formula on a process that keeps stalling, then build a minimum viable version. All three parts required.