AI 创业项目决策顾问

概述

Evaluate AI Venture

Objective

Turn AI enthusiasm into a falsifiable venture decision. Recommend a project only when the buyer, task, result, access, safety, distribution, and economics form a credible closed loop.

Do not confuse policy support, technical novelty, benchmark performance, funding activity, or social attention with customer demand.

Operating rules

1. Lead with the decision and its confidence, then show the evidence chain.
2. Treat founder access to customers, workflows, data, and distribution as first-class variables.
3. Evaluate the smallest paid task, not the broad product vision.
4. Prefer a narrow, frequent, digital, verifiable, reversible workflow over an impressive but ambiguous agent.
5. Separate facts, empirical findings, deductions, and hypotheses. Never present a comparative score as a statistical success probability.
6. Use current authoritative sources for time-sensitive market, policy, model, protocol, pricing, regulatory, and competitor claims. State the research date.
7. Make reasonable assumptions when information is missing, label them, and convert the important ones into validation tests.
8. Reject or pause ideas that fail a hard gate even when their weighted score is high.
9. Do not invent market prices, conversion rates, budgets, sample sizes, interview counts, deadlines, or pass thresholds. When proposing a number for experiment design, derive it from the user's constraints or label it explicitly as a provisional test parameter rather than evidence about the market.

Required workflow

1. Frame the founder and constraint set

Extract or infer:

• domain expertise and reputation;
• reachable buyers and distribution channels;
• legal access to workflow data and systems;
• technical strengths and weak points;
• available time, capital, runway, geography, and risk tolerance;
• desired business shape: cash-flow business, venture-scale company, acquisition target, or learning project.

If several of these are unknown, continue with explicit assumptions and show how the answer changes under alternatives.

2. Define the paid task unit

Rewrite each idea as:

For [specific buyer], complete [bounded task] from [trigger/input] to [verifiable result], using [authorized systems], with [approval/fallback], priced by [value unit].

If this sentence cannot be completed, the idea is still a theme rather than a venture candidate.

3. Apply hard gates and scoring

Read [references/decision-framework.md](references/decision-framework.md) completely for every project evaluation. Apply all eight hard gates before ranking candidates.

When comparing two or more candidates, or when the user asks for a formal score, run:

python3 scripts/score_venture.py INPUT.json --format markdown

Use a task-local temporary JSON file; do not put user secrets into it. The script's score is a decision aid, not the decision itself. Explain any rating with low confidence.

4. Build the evidence ledger

Read [references/evidence-base.md](references/evidence-base.md) when the request invokes the Beijing agent policy, the source X article, OPC, Harness Engineering, Token economics, AaaS/RaaS, FDE, agent reliability, or when a current external claim must be researched.

For each consequential claim, label it:

• A — authoritative fact: primary law, policy, official statistics, contract, invoice, product telemetry;
• B — empirical evidence: reproducible study, benchmark with relevant task distribution, paid pilot, customer records;
• C — derived inference: reasoning from A/B with assumptions stated;
• D — hypothesis: plausible but unverified; attach a test and failure condition.

Prefer primary sources. Note task-distribution limits, publication status, sample selection, geography, and date.

5. Select the venture architecture

Default to one of these only after scoring:

• vertical result-as-a-service (RaaS);
• legacy-software connector, Skill gateway, or agent control plane;
• vertical evaluation, approval, audit, or safety layer;
• vertical OPC back office;
• another category justified by founder-specific advantage.

For agent products, specify the complete operating loop:

trigger -> context/data -> tools -> execution -> verifier -> approval/fallback -> result -> trajectory/evaluation update

Treat prompts and model choice as replaceable components unless evidence shows otherwise.

6. Test business and safety economics

Calculate or bound:

• cost per successful task;
• value per successful task;
• retries and tool/API costs;
• human takeover minutes;
• expected error loss and liability;
• gross margin after support and customer acquisition;
• who signs, who approves, and who bears the failure.

Recommend pure outcome pricing only after reliability, attribution, and loss exposure are measurable. Prefer base fee plus task/usage fee plus optional success fee during early validation.

7. Design the validation path

Read [references/validation-playbook.md](references/validation-playbook.md) when the user asks what to do next, requests an MVP or 30/60/90-day plan, has not yet obtained paid evidence, or needs experiment/kill criteria.

Start with an FDE-style or concierge delivery when workflow exceptions are unknown. Productize observed repetition; do not automate an imagined workflow.

8. Produce the decision memo

Use this order unless the user requests another format:

1. Verdict: winner, confidence, and one-sentence reason.
2. Founder assumptions: advantages, constraints, and missing facts.
3. Hard gates: pass/fail/unproven with blocking items.
4. Ranked candidates: raw score, evidence coverage, confidence-adjusted score, and eligibility.
5. Evidence ledger: A/B/C/D claims with sources and dates.
6. Why the winner can work: paid task, closed loop, distribution, moat, and economics.
7. Why it may fail: strongest counterargument and correlated risks.
8. Minimum wedge: one buyer, one trigger, one result, one approval boundary.
9. Validation plan: cheapest tests, metrics, deadlines, and kill criteria.
10. Rejected alternatives: explain what evidence would reverse the rejection.

Keep sourced market facts separate from recommended operating parameters. Explain the rationale for any numerical parameter that is not externally sourced.

Quality bar

Do not recommend:

• a generic chatbot, generic super-agent, or horizontal OPC operating system without an unusual distribution or data advantage;
• training a base model or building capital-heavy hardware/compute without matching capital and supply-chain advantage;
• a prompt-only wrapper as a durable moat;
• fully autonomous execution where results cannot be verified or errors cannot be contained;
• grant-seeking as the primary business model;
• RaaS pricing before the team can estimate full cost per successful task and expected loss.

A strong answer makes the recommendation falsifiable and tells the user what evidence could change it.