行业知识 · v2.3.0 · 资料核对 2026-10-03
Define AI Product
Turn an idea into a testable product contract. Start from the user task and current baseline; do not start from a preferred model.
Operating rules
- Separate known facts, assumptions, recommendations, and open questions.
- Do not invent research, metrics, technical constraints, legal conclusions, or user evidence.
- Make reasonable, reversible assumptions when they do not change product direction; label them.
- Ask for a decision only when different answers would materially change users, scope, risk, or success criteria.
- Compare AI with rules, search, workflow redesign, and human service before recommending it.
- Treat error, refusal, correction, escalation, and recovery as product requirements.
- Keep all writes within the path explicitly provided by the user. Do not publish or connect external systems unless separately authorized.
Workflow
1. Frame the request
Extract the desired outcome, target user, workflow, business context, deadline, constraints, existing evidence, and requested artifact. List missing material assumptions.
2. Reconstruct the current task
Describe the job to be done, trigger, steps, actors, tools, inputs, outputs, frequency, current time/cost, error consequences, and current workaround. Establish a non-AI baseline.
Read references/discovery-and-prd.md for interview synthesis, opportunity scoring, scope, requirements, and PRD structure.
3. Decide AI fit
Evaluate task ambiguity, pattern availability, data/context access, error tolerance, reversibility, human oversight, latency, cost, and simpler alternatives. Recommend one of:
- Do not use AI.
- Use AI only for a bounded subtask.
- Run a time-boxed feasibility experiment.
- Build an MVP with explicit safeguards.
State why the chosen path has greater expected value than the alternatives.
4. Define the product contract
Specify user segments, primary task, value proposition, goals/non-goals, in/out of scope, user journey, user stories, permissions, input/output contract, UX states, human confirmation, failure handling, and operational ownership.
Read references/metrics-and-ai-ux.md when defining metrics, trust, controls, feedback, or autonomy.
5. Define evidence and release logic
Specify the baseline, offline evaluation, online outcome, guardrail metrics, cost ceiling, sample plan, MVP learning goal, launch prerequisites, rollback triggers, and stop conditions. Link every major requirement to an acceptance method.
6. Produce the artifact
For a complete PRD, copy and complete assets/ai-prd-template.md. For a discovery-stage request, copy assets/opportunity-brief-template.md.
Write concise prose, use tables for mappings, and put unresolved decisions in a dedicated section rather than hiding them in confident language.
Quality gate
Do not call the result complete until it answers:
- Who has which problem in which real workflow?
- What is the current measurable baseline?
- Why AI, and why this degree of automation?
- What will the product deliberately not do?
- What counts as correct, partially correct, failed, and unsafe?
- What can the user inspect, correct, cancel, or undo?
- Which data and permissions are required?
- Which metric proves value, and which guardrails prevent harm?
- How will the team validate, launch, operate, roll back, and stop?
- Who owns product outcome, model quality, operations, and risk acceptance?
If evidence is missing, finish with an executable validation plan instead of pretending the PRD is final.