李昆謀：把 AI 融入零售業的日常流程

1. In one sentence

李昆謀 used a real 91APP case — automatically filling in specification fields when listing a product — to show how accuracy and coverage pull against each other, arriving at a formula for splitting the work between human brains, a rules engine and an AI agent, and then applying the same logic to software development's PRDs and team organisation.

2. The session

Listing a product: an underestimated piece of repetitive work

The slide starts by drawing retail's most basic path: a product enters the product master, which produces storefront records for each channel (the brand's own site, other channels), which finally becomes the product page a consumer sees. Then a calculation: a hundred new products, thirty fields to fill, five channels, multiplying to fifteen thousand field combinations. At an average of ten seconds each, fifteen thousand times ten is a hundred and fifty thousand seconds — two thousand five hundred minutes, forty-one hours, about five working days. The slide's heading reads "new products every week", implying this five-day workload is not a one-off but a recurring weekly burden, and is why the slide calls it "a large volume of manual work".

Internally 91APP calls the system that handles this IMS; the slide gives two renderings, "multi-platform management system" and "multi-platform product and order management system", with the function of centrally managing product data for the brand site (Brand.com) and other channels, importing in bulk or adding one at a time. The slide highlights a pain point: adding a product specification means "many fields to fill and many options to choose", and the flow requires first selecting "has options" and then manually entering the option content for every specification — thoroughly tedious.

A magic little button, and the first pothole

91APP added a button to the storefront management interface, which the slide calls "the magic little button", with a screenshot of the admin: an "auto-generate storefront specifications" button above the results list. The system prompt behind it reads: "I need you to infer specification options from the product description and from specification examples. Following the storefront information I provide and the specification requirements, give me suitable product specification options." The input is the product master, an agent sits in the middle, and the output is the storefront record.

The slide draws the whole optimisation as a loop: the product master goes into the agent, the agent produces a storefront record, that record is compared against a manually prepared "correct storefront record", an evaluation program runs, an evaluation result comes out, and the prompt is adjusted again — round and round. The heading on that diagram reads "intern training!", meaning prompt tuning is treated as training a new hire. This page also drops a heavyweight slogan: "the dataset *is* the PRD", replacing software engineering's product requirement document with a gold-standard dataset.

On the first evaluation's bar chart, out of a total of one hundred, coverage reached ninety-eight and accuracy only forty-five. The slide then shows what looks like a diff table, headed "there are seven thousand five hundred differences!" — meaning the AI's storefront record and the correct answer disagree in seven and a half thousand places. In other words the AI answered nearly every specification (high coverage) and got fewer than half right (low accuracy).

Should the AI be involved at all: two rules for one reversal

The slide uses an "AI do NOT help" flow diagram to make the point: even with the AI producing a storefront record, a manual "check the storefront record" step still has to be inserted before anything goes live — so the AI's output saved no labour at all, because the error rate is too high and every item has to be rechecked.

The fix was adding two rules to the prompt: "don't answer what you're not confident about" and "don't answer where there are no options". Evaluation result two: accuracy jumped from forty-five to ninety, coverage dropped from ninety-eight to fifty. The slide describes this state as "half written by AI, half by people": the AI answers only the half it is sure of, and the half it abandons goes back to a person. The flow diagram changes to "AI and human collaboration": the product master goes to the AI to produce a storefront record, a person then fills it in, fifty per cent each.

The slide asks "how do we raise accuracy further" and adds a third rule: "give your reasoning with the answer". Here it drops in a very everyday comparison screenshot: the same geometry question about similar trapezoids given to ChatGPT 4.5, where the model gives one answer at first and corrects it to another after the user pushes back. The slide uses this to explain that when the AI supplies reasoning with its answer, a human reviewing it can attack the reasoning directly rather than recomputing every item from scratch. Below that comes a real scoring table screenshot with columns for specification name, final score, discussion status, the AI's reasoning, and the product owner's confirmation — several specifications such as gender, textile, fit and upper material are marked "discuss", with the reasoning column carrying the AI's own inference like "the description mentions a loose fit, therefore selecting the larger option", and the confirmation column carrying rulings like "exclude if the source data has no answer".

The slide closes this stretch with a screenshot of 91APP's admin specification picker alongside product images of a pink tracksuit and a pair of leather work boots, showing concretely what a specification the AI has to answer looks like: "upper material", say, must be chosen from a long list of cowhide, sheepskin, pigskin, synthetic leather and so on, while the product description reads "the upper is made of premium waterproof leather, with a ReBOTL fabric lining containing at least fifty per cent recycled plastic" — and the AI has to infer the correct material option from that text.

The three-way split: rules engine, AI agent, human

The final answer is a three-way division of work: the customer rule application (rules engine) filters out the parts judgeable by explicit rules first, the AI agent produces the storefront record, and a human checks and fills in the rest. The accompanying bar chart splits the total of one hundred into forty for the rules engine, fifty for the AI agent and ten for humans — meaning the share genuinely requiring human intervention is down to a tenth. The page ends with an equation that closes the first half of the session: human brains, rules engine and AI agent map onto human brains, CPUs and GPUs as three kinds of computing resource.

Software has the same question: AI-driven development, and who a PRD is written for

The slide then moves from retail to software itself, deliberately inverting "using AI to build products" and "building AI products" in the title to suggest the two are two sides of one thing. Software's daily flow is drawn as: a requirement becomes a PRD, the PRD is split into stories, stories become code, and code assembles into a product. The slide deforms the same diagram repeatedly: first a "large volume of manual work" version with a person standing at every node; then an "AI can help" question version; then a "vibe coding" minimalist version jumping straight from AI to function/product with nothing in between.

The slide poses a question with two contrasting diagrams: "who is the PRD written for?" On the left, a product owner prompts the AI directly to build the feature; on the right, a product owner writes a PRD and hands it to an engineer who builds the feature. The implication is that if the PRD is ultimately fed to an AI, the way you write it may have to change. Then comes a table of non-functional requirements (NFRs) listing six types with quantified statements: performance requires handling a thousand requests per second; availability requires 99.9% uptime per year; security requires HTTPS and login authentication; maintainability requires over 80% unit test coverage; scalability requires the system to handle a tenfold increase in users; fault tolerance requires that no single service failure brings the whole thing down. The slide classes these as "enterprise-level software" requirements, meaning these non-functional requirements have to be written into an "AI-readable" PRD too, so the AI factors the constraints in at the planning stage.

The full AI-driven development flow diagram splits into a planning stage and a development stage: in planning, the product owner, UX and tech lead jointly produce the PRD and stories; in development, stories are assigned to B2E, F2E and QA (the slide gives only the abbreviations without expanding them) and finally merge into a release.

300 people, 300 AI assistants

The last stretch returns to organisational scale. The slide draws an org chart of a three-hundred-person development team, split into product line divisions A, B and C, each with product managers, UX, engineering and QA. The next slide duplicates the same chart as "a 300-person development team plus 300 AI assistants" — one AI assistant per head. The calculation that follows is twenty US dollars times three hundred equals six thousand, implying twenty dollars a month per assistant subscription and six thousand dollars a month across three hundred.

The slide then breaks the organisation down further into twenty-two feature teams of seven to fifteen people each, with each team subdivided into specialist groups: RD1, RD2, QA, UX, PO. The closing stretch lands on "Agile": first Agile drawn as "a method for connecting people to work together", then what "AI Agile" looks like in practice — a pile of plus signs stacked next to Agile, suggesting the current approach is cramming a lot of scattered AI tools into an existing agile process rather than genuinely redesigning the method. The slide sets that reality against a future ideal: the new normal should be "industrialised software (machines produce, humans supervise)", the same Agile-to-function/product diagram under a different heading.

3. Figures and cases

• The base case for product listing: a hundred new products times thirty fields times five channels equals fifteen thousand field combinations, with the slide noting "new products every week" as the recurring workload.
• Manual time conversion: fifteen thousand fields at ten seconds each is a hundred and fifty thousand seconds, or two thousand five hundred minutes, forty-one hours, about five working days (the speaker's own calculation, no external source).
• First evaluation (prompt without rules): 45% accuracy, 98% coverage, 7,500 differences in total.
• After adding the two rules "don't answer when unsure, don't answer where there are no options": 90% accuracy, coverage down to 50%, with AI and humans each carrying 50% of the output.
• The final three-way split: rules engine 40, AI agent 50, humans just 10 (out of a total of 100).
• Six NFR thresholds: a thousand requests per second, 99.9% annual availability, over 80% unit test coverage, and scalability for a tenfold increase in users.
• Organisational case: a 300-person development team with 300 AI assistants, costed at twenty dollars each times three hundred, or six thousand dollars a month (speaker's own account, no external source); the team breaks down further into twenty-two feature teams of seven to fifteen people each.

4. Lines worth keeping

All of these appeared directly on the slides as slogans or key lines rather than as spoken remarks:

• "The dataset *is* the PRD"
• "AI do 'NOT' help"
• "Half written by AI / half by people"
• "Human brain × CPU × GPU" (the equation for the three-way split between human brains, rules engine and AI agent)
• "We all want to become nouns, and rarely put the work into the verbs"
• "Turn the future tense into the present continuous" (on verification, 李昆謀's own write-up ends on exactly this line — "turn the future tense into the present continuous; only in the present continuous does AI become your new normal" — confirming it is not just a slide slogan but a conclusion he repeats, happylee.blog)

5. Tools and terms mentioned

• IMS: called "multi-platform management system" / "multi-platform product and order management system" on the slide; 91APP's internal system for centrally managing product data across the brand site and other channels — an internal product name.
• Agent: on the slide, the general term for the AI flow that infers specification options from the product master and produces the storefront record; no underlying model or framework is named.
• Rules engine: the component in the three-way split that applies the customer's existing rules first and filters out the clearly judgeable cases.
• PRD (product requirement document): which the slide redefines as "a dataset", and extends into the notion of an "AI-readable PRD".
• NFR (non-functional requirements): the slide lists six categories — performance, availability, security, maintainability, scalability and fault tolerance.
• Vibe coding: the slide's term for a minimal development mode that skips the PRD and stories and has the AI produce the feature directly.
• B2E / F2E: two abbreviated nodes on the development-stage flow diagram; the slide never expands them, and they are inferred to correspond to back-end and front-end engineering output (inferred here, no external source).

6. Wider observations

The most interesting thing in the session is the way the accuracy and coverage bar charts flip three times: from 98 coverage and 45 accuracy, to 90 accuracy and 50 coverage, and only then pulling coverage back up with the rules engine. It is easy for people building AI features to watch only "can the AI answer" without realising that "the AI dares to answer" and "the AI is right" are two metrics that have to be measured separately. That matches almost exactly the accuracy-and-coverage definitions in another developer conference session (吳剛志's), and the two are very likely the same internal 91APP case told once from the product officer's angle and once from the architect's.

The design of inverting "using AI to build products" and "building AI products" in the software section's title is neat, but the "AI-readable PRD" idea on the NFR page went by rather fast — the slide never shows what an actual AI-readable PRD looks like, so from the slides alone that block reads more as raising a question than giving an answer. The 300 people, 300 AI assistants and six thousand dollars a month figures also feel more declarative: nothing explains how much work those assistants actually carry, or whether that matches the forty-fifty-ten split from the product listing case earlier, so it is marked as the speaker's own account pending verification.

91APP had considerable visibility at this conference: on the developer conference day it had two speakers, 吳剛志 (Andrew) and 陳俊毅 (Levi) (陳俊毅's session is written up separately and not repeated here), plus 李昆謀's session here — three 91APP speakers across the two days. On verification, 李昆謀's own write-up mentions this too, saying he is especially pleased when the community mentions "the 91APP team" (happylee.blog). As for whether 91APP was a formal sponsor of this conference, no official 2025 named sponsor list could be found to corroborate it, so no call is made on that.

7. Sources