TutorialsBuild and Verify: Ship the First Version with Baidu Dumate
Install the tool, hand over the checklist and prompt, decide the open questions one at a time, then run your own acceptance table against what it built.
This lesson goes from a filled checklist to a tool you can open. Baidu Dumate owns the interface, interaction, technical approach and code; you own every fork in the road and the final acceptance. One rule throughout: discuss as you build, do not dump every requirement at once.
Step 0 · Install Baidu Dumate
The course uses Baidu Dumate (DuMate), desktop client:
Download and sign in: go to dumate.cn, download the desktop installer, sign in with a phone number.
Prepare your material: the filled checklist, the build prompt, and one anonymised sample input in the same folder.
Start a task: upload the checklist and sample, paste the prompt, and keep working inside the same task. Switching tasks loses the context.
Instructor invite code: KUC83CY
In the client, open Settings, find the invite section, and enter it under invite-code redemption. Eligibility and benefits follow the campaign page, and it is optional — if you can start a task normally, you can begin.
Step 1 · Hand over the checklist and the prompt
The checklist is your requirement. The prompt tells AI how to work with you. This is the version from the handout:
I am a product manager focused on product requirements and user experience. Act as my product design and development partner: based on the three lists I filled in, build a first version that runs and can be accepted.
I own the product goal, requirement trade-offs and final acceptance. You own UI design, UX flow, technical approach, implementation and the necessary testing. Explain trade-offs in plain language and how they affect actual use.
First read the options I ticked and what I actually wrote. Unticked options, grey placeholder text, teaching examples and placeholder images are not my requirements. If you cannot read the file, the tick states or an image, tell me exactly what to supply — do not guess.
Restate the goal in one sentence, list the product form, device and input/output you read, then proceed with what is certain. If two single-choice options are ticked, or a required field is empty, ask instead of guessing. When I chose "let AI suggest", recommend the easiest-to-try option for the core task and explain why.
Ask one key question at a time, with two or three plain-language options, recommend one with a one-line reason, and wait for my answer before continuing that part. Do not re-ask what is already clear. Routine interface, interaction and technical details are yours to decide; anything that changes the core flow or the scope comes to me first.
The layout should be clear, text legible and styling consistent on the chosen device. Keep the flow short, and add input guidance, progress, success or error messages and a retry path where needed. If I supplied reference images, borrow from them for this task; if not, propose a simple clear option first.
If an account, extra install, external service or publishing step is needed, explain it before the step. Anything involving cost, data storage or transfer, or publishing waits for my decision. Build something tryable first; never publish without my confirmation.
Version one completes the core task only; extra features wait. Each time I make an important choice, update the corresponding list, tell me briefly what changed, then continue.
Give me something I can see or try as early as possible, and say where to open it and how to operate it. Core features must genuinely work; state clearly what is unfinished or unverified. Never pass off a static page or simulated result as working functionality.
Walk me through checking the result, the display and the flow with my own example, and add the checks this version needs. If my example or expected result is vague, help me turn it into something checkable. Anything not actually run stays "untested" — do not write pass in advance, and do not tick acceptance items on my behalf.The point to catch: check the restated goal first. It will list the product form, device and input/output it read — if that is wrong, everything after it is wrong, so correct it before continuing.
Step 2 · Decide the open questions one at a time
It will not build everything in one go; it asks one question at a time. That is by design, not stalling.
For example: "Are 'sign-in sheet' and 'event sign-in sheet' duplicates?"
- A: keep both, remove only exact matches
- B: merge similar items, which needs a clearer rule
It recommends A because version one is easier to verify. If you agree, reply:
Use A for this version, update the checklist and continue.
Every answer should be written back into the checklist. Five or six such forks in one session will contradict each other if they only live in the chat.
Step 3 · Run the acceptance table
Once version one exists, resist adding features. Walk these six items with your own example:
| Check | What to look at |
|---|---|
| Core result | Does your example produce the expected output |
| Display | Are text and buttons clear on the chosen device |
| Flow | Can the core task be completed end to end |
| Bad input | Are empty or invalid inputs explained |
| Taking the result | Do copy, download or retention work |
| Reuse | Does a new input update the result correctly |
Anything you did not actually click stays "untested". Reading the code is not a pass, and neither is a page that opens.
Step 4 · When the result is wrong
Two kinds of feedback; naming which one you mean makes the fix faster.
Change the page — location, appearance, purpose:
Change [where] to [what], so it is easier to [do what].
For example: make the result area font larger and put the copy button to its right, so the result is easier to read and take away.
Wrong result — input, action, expected, actual:
I entered [input], did [action], expected [result], and got [actual].
For example: entered "poster, sign-in sheet, poster", clicked clean, expected two lines, still shows three — please fix.
Retest that case first, then the features it touched. Adding "do not add other features" saves half the rework.
Step 5 · Use it for something real
Not a test case — give it the actual annoying task once.
Then note three things: did it remove the original pain? Which step still needs a manual patch? What is the single most worthwhile change for version two?
Those three lines are the entire basis for the next version. The value of version one is not feature count; it is that you finally have something you can keep improving.
Three red lines during the build: check the rules yourself (test deduplication, filtering and sorting against a known answer), anonymise material (no credentials, keys or customer data in the chat or in screenshots), mark untested as untested (anything not actually run in the acceptance table).
Filling the Three Lists: Six Questions That Make It Clear
Two questions each for requirement, design and acceptance. Tick the common options, add a few sentences, and AI has a brief it can read.
Build Your Own First Small Tool
Choose your own topic, fill the three lists, build it with Baidu Dumate, fix at least one problem, and use it for one real task.