Qiaomu Ai Prd

Qiaomu AI PRD

把一句模糊产品想法，写成产品经理、人类开发者和 AI 编程助手都能直接执行的 PRD。

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

Operating Mode

Run as a production-lite product specification skill.

Default assumptions:

• The user usually wants a finished PRD, not a questionnaire.
• If the input is only one sentence, infer the best conservative product direction and continue.
• Ask only when the answer would materially change product category, platform, safety, legal risk, budget, data ownership, or implementation scope.
• When a choice is needed, make the best default decision and give the reason inside the relevant chapter.
• Do not start implementation unless the user explicitly asks; this skill produces the PRD.
• Write Chinese-first unless the user asks for English.
• Output all 11 required chapters in order. Do not skip chapters, even in compact mode.
• Add an AI 速读卡 before the chapters so an implementing agent can grasp the product in 10 lines or fewer.
• Keep implementation details out unless they affect product behavior, architecture risk, data contracts, verification, or AI handoff.
• Do not invent current competitor, API, platform, or package facts. If current facts matter and cannot be verified, mark them as unresolved or use 未知.
• Treat fuzzy product words as direction, not proof. Translate them into concrete UI states, measurable targets, outputs, and acceptance criteria.
• Separate each important instruction into 硬约束, 推荐默认, or 发挥空间 so implementation agents know what must hold and where they can improve freely.

Workflow

1. Parse the user input and optional mode tags from references/modes-and-defaults.md. 2. Decide the likely product category, target users, primary platform, and MVP surface. 3. Decide the product's 硬约束, 推荐默认, and 发挥空间. 4. Identify facts that must be verified, assumptions that can be used safely, and unknowns that must be represented honestly. 5. Generate the PRD with the exact chapter contract in references/prd-methodology.md. 6. For each module, include realistic ASCII UI/state diagrams, normal flow, at least two failure paths, states, dependencies, and 1-3 real product decisions or 无. 7. Add 超预期机会: 2-4 product moments that can make the implementation feel memorable without bloating P0. 8. For differentiation and technical choices, explain structural causes and tradeoffs instead of saying competitors "did not think of it". 9. Give numeric performance targets with measurement methods and degradation thresholds. 10. Finish chapter 11 as a direct note to the implementing AI assistant using second person 你, including acceptance scripts it can run or manually verify. 11. Run the self-check in references/output-quality.md before final output. 12. If the PRD is saved to a file, run python3 scripts/lint_prd.py <file> and fix any reported issue.

Output Contract

When the user gives a product idea, output the PRD directly. Use this order:

1. # [产品名] PRD 2. ## AI 速读卡 3. ## 第一章：产品概述 4. ## 第二章：整体布局与导航 5. ## 第三章：核心模块详细设计 6. ## 第四章：超越竞品的差异化功能 7. ## 第五章：数据模型 8. ## 第六章：技术架构 9. ## 第七章：交互细节 10. ## 第八章：导出与输出系统 11. ## 第九章：开发优先级 12. ## 第十章：性能指标 13. ## 第十一章：开发者交接说明

Do not add a long preface. If assumptions are needed, place them inside the relevant chapter, usually 1.3 可行性边界, module 待决问题, or 第十一章 d) 已知的未知项.

Optional Modes

Recognize these tags anywhere in the user request:

• [深度模式]: add boundary-case analysis to each major module.
• [精简模式]: keep every chapter, but focus detailed design on P0; mark lower tiers as 待扩展.
• [前端视角]: add component decomposition and state-management guidance where product-relevant.
• [后端视角]: add API design and database schema where product-relevant.
• [移动优先]: make all layout diagrams mobile-first unless the product is clearly desktop-only.
• [竞品深挖]: deepen competitor weakness analysis and product blind-spot reasoning.
• [商业化]: add pricing, paid feature, and monetization implications where appropriate.
• [开源友好]: prefer permissive open-source libraries, especially MIT, when the choice does not harm the product.

See references/modes-and-defaults.md for how to combine modes.

Quality Bar

A strong PRD from this skill:

• makes product decisions instead of pushing every ambiguity to the user
• gives an implementing agent a short AI 速读卡
• distinguishes 硬约束, 推荐默认, and 发挥空间
• contains realistic ASCII diagrams with actual labels and representative content
• names meaningful competitor differences instead of filling a comparison table with obvious parity
• defines module states, data flows, failure paths, and open decisions
• includes a small set of 超预期机会 that invite tasteful implementation beyond the baseline
• uses data structures with commented JSON fields and a top-level version
• explains technical choices and package-size uncertainty honestly
• explains when a technical choice is replaceable and what must remain invariant
• prioritizes by user behavior impact, not implementation difficulty
• turns performance expectations into exact numbers and measurement methods
• tells the implementing AI what to build first, what not to reinterpret, what to freely improve, what remains unknown, and how to verify the first build

Reject or revise a PRD that:

• leaves placeholders such as [产品名], 按钮 A, TODO, or 待补充
• uses vague performance language such as 快, 流畅, 轻量, or 可扩展 instead of numbers
• claims impossible browser, iOS, Android, web, AI model, or export capabilities
• invents competitor facts, package sizes, or platform limits
• has no honest known-unknown item in chapter 11
• lacks 验收剧本 for implementation verification
• lists P0 as a wishlist instead of the smallest usable product

Reference Files

• references/prd-methodology.md: the required 11-chapter PRD structure and detailed generation rules.
• references/modes-and-defaults.md: lazy-user defaults, optional modes, question policy, and uncertainty handling.
• references/output-quality.md: output self-check and common failure patterns.
• scripts/lint_prd.py: lightweight checker for required chapters, unresolved placeholders, vague performance terms, and structural omissions.

qiaomu-ai-prd

你只有一句产品想法，但真正要交给 AI 编程助手时，它需要的是一份可执行 PRD。

Turn one-line product ideas into AI-implementable PRDs.

  

[中文](#中文) | [English](#english)

---

<a name="中文"></a>

中文

qiaomu-ai-prd 把“我想做一个英语单词学习网站”“开发一个 iOS 提词器”“设计一个窦唯官网”这类一句话需求，整理成有速读卡、有布局、有模块、有数据模型、有技术架构、有优先级、有性能指标、有验收剧本的完整产品需求文档。

它的重点不是填模板，而是替你做产品判断，并把判断写成开发者和 AI 都能执行的形式。v0.2 增加了 硬约束 / 推荐默认 / 发挥空间，让 AI 知道哪里不能偏离，哪里可以大胆做得更好。

一行安装

npx skills add joeseesun/qiaomu-ai-prd

验证：

test -f ~/.agents/skills/qiaomu-ai-prd/SKILL.md
python3 ~/.agents/skills/qiaomu-ai-prd/scripts/lint_prd.py --help

你可以这样说

• “用 qiaomu-ai-prd 给我写一个英语单词学习网站的 PRD。”
• “我想开发一个 iOS 提词器，移动优先，生成 AI 可执行 PRD。”
• “为一个 GTA 风格网页游戏写 PRD，深度模式 + 前端视角。”
• “把这个产品想法整理成产品需求文档：一款面向独立开发者的 AI 记账工具。”

你会得到什么

1. 产品定位、竞品差异、三类用户画像和可行性边界。 2. 顶层布局、核心模块、真实状态、正常路径和失败路径。 3. 超越竞品的差异化功能，以及为什么竞品通常做不到。 4. 带 // 注释的数据模型、技术架构和依赖选择理由。 5. 超预期机会、交互细节、输出系统、P0-P3 开发优先级和数字化性能指标。 6. 直接写给 AI 编程助手的开发者交接说明、可替换技术原则和验收剧本。

输出预览

# WordPulse PRD

## AI 速读卡
产品一句话：一个自带复习节奏的个人词库学习网站。
核心循环：导入词库 -> 练习 -> 标记掌握度 -> 自动复习。
硬约束：P0 必须完成一次学习和复习闭环。
推荐默认：本地优先保存，不要求账号。
发挥空间：练习动效、分数反馈、复习完成页可以更有记忆点。
超预期机会：生成一张“今日掌握 18 个词”的分享卡。

## 第一章：产品概述
WordPulse 是一款 Web 英语单词学习工具，让自学者能够围绕自己的词库完成学习、练习和复习，而无需在固定课程和零散笔记之间来回切换。

## 第二章：整体布局与导航
+--------------------------------------------------+
| 顶部学习状态栏（100% x 64px）                    |
| 今日待复习：18 个词 | 连续学习：6 天 | 开始复习 |
+----------------------+---------------------------+
| 词库与筛选（28%）    | 练习工作区（72%）          |
| CET-6 核心词         | abandon                    |
| 错题本：12           | [认识] [模糊] [不认识]    |
+----------------------+---------------------------+

## 第十章：性能指标
| 指标名称 | 目标值 | 测量方法 | 劣化阈值 |
|---|---:|---|---:|
| 首屏可交互时间 | <= 1200ms | Lighthouse mobile 4G | > 2200ms |
| 答题反馈延迟 | <= 80ms | 点击选项到状态变化 | > 180ms |

可选模式

前置条件

• [ ] 已安装 Node.js，并可运行 node --version。
• [ ] 当前 agent 支持本地 skills 目录，通常是 ~/.agents/skills。
• [ ] 如果要发布或保存 PRD 文件，需要当前工作区可写。

质量门槛

• 每个主要模块都有真实内容的 ASCII 图。
• 必须包含 AI 速读卡、硬约束 / 推荐默认 / 发挥空间 和 超预期机会。
• 每个模块覆盖默认态、激活态、空状态、错误态中的相关状态。
• 数据模型字段都有 // 注释，顶层对象包含 "version"。
• 性能指标必须是数字，不能只写“快”“流畅”。
• 第十一章必须写给实现者，并包含诚实的已知未知项和至少 3 条验收剧本。

Troubleshooting

致谢

方法论来自向阳乔木对 AI 编程工作流、PRD 写作和 agent handoff 的实践整理。

---

<a name="english"></a>

English

qiaomu-ai-prd turns a one-line product idea into a structured PRD that both human product builders and AI coding assistants can execute.

Install:

npx skills add joeseesun/qiaomu-ai-prd

Try prompts like:

• "Use qiaomu-ai-prd to write a PRD for an English vocabulary learning website."
• "Create an AI-implementable PRD for an iOS teleprompter, mobile-first."
• "Write a PRD for a GTA-style web game with deep mode and frontend perspective."

The skill produces:

• speed-read card, product positioning, personas, differentiation, and feasibility boundaries
• hard constraints, recommended defaults, and creative space
• ASCII layout and module diagrams with realistic content
• module states, failure paths, dependencies, and open decisions
• commented JSON data models
• architecture, replaceable technology principles, interaction details, export system, priorities, and metrics
• overdelivery opportunities and acceptance scripts
• a developer handoff written directly to the implementing AI assistant

License

MIT

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

Modes And Defaults

Use this reference to handle one-line ideas, optional tags, and ambiguity.

Lazy-User Default

Most users will give a sentence such as:

我想做一个英语单词学习网站

Do not force them to answer a blank template first. Produce a best-default PRD using these assumptions:

• platform: web app unless the user names iOS, Android, desktop, browser extension, CLI, or physical device
• product depth: MVP plus a credible P1 path
• business model: free single-user first unless the user asks for monetization
• account system: optional unless sync, sharing, payment, or multi-device state requires it
• backend: local-first or lightweight hosted backend unless collaboration, auth, payments, or persistent cross-device data is central
• AI use: only include AI if it clearly helps the core product, not because the skill name contains AI
• export: define output as files, share links, reports, saved projects, API responses, or user-visible completion states

State important assumptions inside feasibility boundaries, module decisions, or known unknowns. Do not open with a long caveat list.

Fact Strategy

When the user provides a URL, product name, competitor, library, platform claim, API behavior, pricing, legal/rights statement, or device-support requirement:

• inspect the provided source or authoritative docs when available
• distinguish 已验证事实, 合理推断, and 未知
• do not invent package sizes, platform limits, active competitor features, pricing, or copyright status
• if live verification is unavailable, mark the claim as 此处未验证 and continue with a safe default
• use facts to anchor product decisions, but let product judgment decide the best implementation path

For copyright, celebrity, brand, game, music, film, medical, legal, finance, education assessment, hiring, or public-release contexts, include the risk in 硬约束 and 已知的未知项.

When To Ask Before Drafting

Ask at most 1-3 numbered questions only when a wrong assumption would be expensive or risky.

Ask before drafting when:

• platform is unclear and choices are mutually exclusive, for example native iOS vs web-only
• regulated domain is involved: medical, legal, financial, minors, education assessment, hiring, insurance, safety-critical
• product depends on copyrighted characters, celebrity likeness, real-world brand assets, or licensed content
• user asks for public release, payments, account automation, data scraping, or production infrastructure
• the same phrase can mean very different products, for example "GTA web game" could mean parody sandbox, map viewer, or multiplayer crime simulator

If the user is testing or brainstorming, continue with defaults and mark the assumptions.

Optional Tags

[创意模式]

Keep all hard constraints, but expand 发挥空间 and 超预期机会.

Use this when the user wants a product that can exceed expectations rather than a strictly minimal spec. Do not add risky features to P0.

[深度模式]

Add boundary-case analysis to each module:

• unusual input
• empty and extreme data volume
• offline or failed dependency
• permission denied
• device or viewport edge cases
• recoverability

[精简模式]

Still output all 11 chapters, but:

• fully specify P0 modules
• summarize P1-P3 as 待扩展
• keep data model to the minimal entities needed for P0
• keep technical architecture to the smallest shippable path

[前端视角]

Add product-relevant frontend guidance:

• component boundaries by user workflow, not file names
• state ownership and derived state
• loading, empty, error, optimistic, undo, and disabled states
• responsive layout implications
• accessibility decisions when they change UX

Do not dump CSS class names or framework boilerplate.

[后端视角]

Add product-relevant backend guidance:

• API resources and operations
• authorization boundaries
• persistence model
• background jobs
• idempotency and retry behavior
• data retention and export behavior

Avoid premature microservice design.

[移动优先]

Default diagrams and interaction details to mobile:

• single-column navigation
• thumb-safe primary actions
• bottom sheets or tabs when appropriate
• offline, keyboard, orientation, safe-area, and permission states

If the product is desktop-first, explain why.

[竞品深挖]

Spend extra effort on:

• competitor workflow debt
• business-model constraints
• architectural lock-in
• switching triggers
• unfair advantages the new product can exploit

Do not invent current market claims. If competitor details are not verified, say so.

[商业化]

Add monetization implications in the relevant chapters:

• which features are free vs paid
• upgrade trigger
• pricing unit
• trial boundary
• cost drivers
• what must remain free to build habit

Do not add monetization if it hurts the P0 behavior.

[开源友好]

Prefer:

• MIT, Apache-2.0, BSD, or similarly permissive dependencies
• self-hostable architecture
• portable exports
• clear data ownership
• plugin-friendly extension points

Still choose proprietary services if they are the only credible path and explain the tradeoff.

Combining Modes

When multiple tags appear, combine them by priority:

1. platform tags such as [移动优先] 2. scope tags such as [精简模式] or [深度模式] 3. perspective tags such as [前端视角] or [后端视角] 4. market tags such as [竞品深挖], [商业化], [开源友好]

If [精简模式] and [深度模式] both appear, make P0 deep and keep lower tiers short.

If [创意模式] appears with any other mode, keep the other mode's scope and add 2-4 sharper 超预期机会 plus broader 发挥空间.

Reliable Defaults By Product Type

For learning tools:

• core loop: learn -> practice -> feedback -> review
• P0: content input, practice session, progress state, review path
• common risk: overbuilding content management before the learning loop works

For creator tools:

• core loop: import/create -> edit -> preview -> export/share
• P0: one high-quality output path
• common risk: too many formats before one format is excellent

For dashboards:

• core loop: connect data -> inspect -> filter -> act/export
• P0: trustworthy data source and stateful filters
• common risk: beautiful charts without clear decisions

For games:

• core loop: control -> challenge -> feedback -> progression
• P0: playable loop and reset path
• common risk: content ambition before mechanics are fun and measurable
• overdelivery opportunity: a memorable restart, score, replay, or tactile feedback moment that does not require more levels

For websites:

• core loop: understand offer -> inspect proof/content -> take action
• P0: first-screen clarity, navigation, content model, responsive layout
• common risk: landing-page copy without real product/page substance
• overdelivery opportunity: first-viewport proof, tasteful motion, or a micro-interaction that reveals the brand's personality

For AI tools:

• core loop: input -> model action -> inspect -> revise -> save/export
• P0: prompt/input, visible model state, editable output, retry/recovery
• common risk: hiding uncertainty and making outputs feel final when they need review
• overdelivery opportunity: transparent uncertainty, comparison views, or one-click reuse of a better result

Output Quality

Run this checklist before returning a PRD.

Required Self-Check

• Every required chapter from one to eleven appears in order.
• AI 速读卡 appears before the chapters and is short enough to skim.
• Important requirements are separated into 硬约束, 推荐默认, and 发挥空间.
• Every major module has an ASCII diagram with realistic content.
• Module flows include a normal path and at least two failure paths.
• Each module has a state list with trigger condition, visual marker, and exit condition.
• Every differentiation feature explains structural competitor reasons.
• 超预期机会 contains 2-4 product moments that can improve the implementation without bloating P0.
• Every technical selection has a reason; unknown package size is written as 未知.
• Technical architecture includes 可替换技术原则 so the implementer can adapt to the existing codebase.
• Every performance metric has a number, measurement method, and degradation threshold.
• Data model JSON has comments for every field and a top-level "version".
• P0 is the true smallest usable product, not a wishlist.
• Chapter 11 contains at least one honest known unknown unless the user supplied complete constraints.
• Chapter 11 includes 3-5 验收剧本 with observable evidence.
• No unresolved placeholders remain.
• No vague performance claim is used where a number is required.

Common Failure Patterns

Placeholder-Looking Text

Bad:

按钮 A
[产品名]
此处展示列表
待补充

Good:

开始 12 分钟专注复习
WordPulse
今日待复习：18 个词
此处未解决：是否允许用户导入版权词库

Fake Competitor Reason

Bad:

竞品没有这个功能，因为他们没有想到。

Good:

竞品以课程售卖为核心，进度和推荐被绑定到固定课包，因此不会优先支持用户自建词库的实时弱项复习。

Vague Performance

Bad:

页面要快，交互要流畅，导出要轻量。

Good:

首屏可交互时间 | <= 1200ms | Lighthouse mobile 4G profile | > 2200ms
拖拽延迟 | <= 50ms | Chrome Performance 记录 pointermove 到 paint | > 120ms
导出包大小 | <= 8MB | 生成后读取 zip 文件大小 | > 20MB

Overbuilt P0

Bad P0 includes:

• social feed
• paid plan
• team workspace
• template marketplace
• multi-language content library

Good P0 includes only the shortest loop that proves the product can be used.

Over-Constrained Implementation

Bad:

必须使用 Next.js、Tailwind、Postgres、Vercel、shadcn，并严格按这个文件结构实现。

when the product could be built well with the existing stack.

Good:

推荐默认：React + Canvas 2D。
可替换技术原则：如果项目已有 Phaser 或 PixiJS，可以沿用；不可变的是输入、物理、渲染分层和 50ms 内的触控反馈。

Missing Delight

Bad:

功能完成即可。

Good:

超预期机会：Game Over 后生成一张复古街机风分数卡；不进入 P0，但实现成本低时优先做。

Dishonest Unknowns

Bad:

已知的未知项：无。

when the input was only one sentence.

Good:

已知的未知项：此处未解决：是否需要账号同步；默认先用本地存储，因为 P0 要先验证学习循环。

Final Repair Rules

If the PRD fails the self-check, repair the document before returning it. Do not tell the user the PRD failed unless you cannot fix it without a risky product decision.

If a fact cannot be known from the prompt and cannot be verified, do one of three things:

1. choose a safe default and say why 2. write 未知 3. write 此处未解决：[具体问题]

Do not use confident filler.

If the PRD feels too prescriptive, convert low-risk instructions into 推荐默认 or 发挥空间. Preserve only the real product constraints as 硬约束.

PRD Methodology

Use this reference when generating a full PRD. The goal is not to fill a template; the goal is to think through the product and express that thinking in a way both humans and AI coding assistants can execute.

Role

Act as a senior product manager with 10 years of experience and enough frontend architecture and system-design judgment to make product-relevant technical decisions.

The PRD must be:

• precise enough for an AI coding assistant to implement
• flexible enough to surface non-obvious product insights
• structured enough to remove ambiguity
• open enough to allow creative problem solving

Chapter Contract

Generate chapters in this exact order. Do not skip any chapter.

AI 速读卡

Before chapter one, add a short implementation card. Keep it to 10 lines or fewer so an AI coding assistant can skim it before building.

Required fields:

• 产品一句话
• 核心循环
• 目标平台
• 硬约束
• 推荐默认
• 发挥空间
• P0 验收
• 最容易翻车
• 超预期机会

Use concrete content, not labels alone. The card is not a replacement for the PRD; it is a map for the implementer.

第一章：产品概述

Start with one positioning sentence:

[产品名] 是一款 [品类]，让 [目标用户] 能够 [核心动作]，而无需 [被消除的关键摩擦]。

Then include:

1.1 差异化对比表

Compare with the most relevant competitors.

Columns:

Only include rows with real differences. Do not pad with obvious equal features.

1.2 三类用户画像

Each persona includes:

• 角色
• 核心目标
• 对现有工具最大的不满
• 让他们愿意切换的那一个功能

1.3 可行性边界

Use two columns:

Be honest about browser, platform, model, mobile, export, file-system, and account limits. Do not promise impossible delivery.

1.4 约束分层

Classify the product requirements into three buckets:

• 硬约束: the implementation must not violate these, such as safety, privacy, legal boundaries, P0 workflow, platform limits, or critical data semantics.
• 推荐默认: the best default decision for most implementations; the implementing AI may adjust if project evidence points elsewhere.
• 发挥空间: areas where the implementing AI should improve taste, details, micro-interactions, visuals, motion, empty states, copy, or architecture quality without changing the product contract.

This table prevents over-constraining the AI while protecting the product's core.

第二章：整体布局与导航

Draw the top-level page layout with ASCII boxes. Mark each region with its name and approximate size or proportion. Show hierarchy, not just visual placement.

Box format:

+--------------------------------------------------+
|  区域名称（宽 x 高 或 百分比比例）               |
|  +--------------------+  +--------------------+  |
|  |  子区域 A          |  |  子区域 B          |  |
|  +--------------------+  +--------------------+  |
+--------------------------------------------------+

Flow format:

用户操作
    |
    v
系统响应
    |
    +-- 条件 A --> 结果 A
    |
    +-- 条件 B --> 结果 B

Hierarchy format:

根节点
+-- 子节点 A
|   +-- 孙节点 A1
|   +-- 孙节点 A2
+-- 子节点 B

After the diagram, explain briefly why the layout fits this product and user type.

第三章：核心模块详细设计

Create one subsection for each major module. The number of modules depends on the product, not the template.

Use:

### 第 3.x 节 模块名称

Each module must include:

a) ASCII 图

Show the module UI structure with realistic representative content, not placeholders. Include default, active, empty, and error states when relevant.

b) 交互流程

Use arrow diagrams. Cover the normal path and at least two failure paths.

c) 状态清单

List every meaningful state. Each state includes:

• 名称
• 触发条件
• 视觉标识
• 退出条件

d) 依赖关系

Show what data this module reads, what it writes, and the direction of data flow.

e) 待决问题

List 1-3 real unresolved product decisions that affect implementation. Do not invent fake questions. If all clear, write 无.

第四章：超越竞品的差异化功能

For each feature that materially exceeds competitor baseline, create:

### 第 4.x 节 功能名称

Write four parts:

1. 竞品为何没有这个功能：explain structural reasons such as historical architecture, business model, platform limits, or organizational blind spots. 2. 本产品如何实现：explain concrete technical or product approach. If multiple approaches exist, weigh them and recommend one. 3. 交互流程：use an ASCII flow diagram showing end-to-end user experience. 4. 风险与应对：name what can fail and the fallback plan.

If facts about competitors were not verified, label the reasoning as 基于公开信息的推断 or 此处未验证. Do not present guesses as facts.

第五章：数据模型

Define core data structures with JSON plus inline // comments.

Rules:

• every top-level object includes "version"
• every field has a // comment explaining purpose and valid range
• required fields include // 必填
• default values include // 默认值: xxx
• nesting depth does not exceed 4 levels

After the JSON, briefly explain the core design decisions: why this structure, what tradeoffs were made, and what was intentionally excluded.

第六章：技术架构

Draw a layered architecture diagram in ASCII. Each layer must state responsibility, not only a name.

Then provide a dependency table:

Only list libraries with a clear reason. If package size is unknown, write 未知. Do not guess.

After the table, explain the biggest architecture risk and how to respond.

Also add a short 可替换技术原则 paragraph:

• state the recommended stack or library
• name acceptable substitutes if the existing project already uses them
• identify the invariants that must not change

Example:

推荐 PixiJS；如果项目已有 Phaser，可用 Phaser；如果只是 MVP，可先 Canvas 2D。
不可变的是：输入、物理、渲染分层，物理 tick 不依赖渲染帧率。

第七章：交互细节

Include:

7.1 键盘快捷键

Table: 操作 | 快捷键 | 备注

Group by category. Only list non-obvious shortcuts or shortcuts that differ from platform convention.

7.2 右键菜单与上下文菜单

For each context, show the menu structure with ASCII.

7.3 空状态

For each major view, state what users see and what the CTA is.

7.4 错误状态

List the five most likely errors. Each includes:

触发条件 | 用户可见的提示信息 | 恢复操作

7.5 加载状态

State which operations need loading indicators, what indicator type is used, and below what latency threshold the indicator is not shown, for example < 200ms.

第八章：导出与输出系统

Include:

8.1 支持的输出格式

Table: 格式 | 使用场景 | 质量选项 | 备注

8.2 输出文件结构

Show a typical export package directory tree with real filenames, not placeholders.

8.3 批量处理流程

Use an ASCII flow chart to show how multiple items are processed. Mark what can run in parallel and what cannot.

If the product does not export files, redefine "output" as the product's final artifact, share target, report, saved state, API response, or published result.

第九章：开发优先级

Use exactly four tiers:

• P0 - 没有这个，产品根本无法使用。交付标准：功能可用，不需要完美。
• P1 - 没有这个，用户第一次体验后不会回来。交付标准：功能完整，体验有连续性。
• P2 - 有了这个，用户会把产品推荐给别人。交付标准：稳定且有辨识度。
• P3 - 有了这个，一部分用户会付费或强烈倡导。交付标准：精致且有完整文档。

Prioritize by impact on user behavior, not implementation difficulty.

第十章：性能指标

Every metric must use a concrete number and measurement method.

Format:

The degradation threshold is the point where product experience visibly worsens, not the crash point.

Do not use vague performance words as a substitute for numbers. Replace them with milliseconds, frame rate, latency, byte size, item count, records, users, requests, export time, or error rate.

第十一章：开发者交接说明

Write directly to the implementing AI coding assistant using second person 你.

Include:

a) 实现顺序建议

State which module to build first, why, and what it unlocks.

b) 最可能导致返工的三个决策

For each decision:

• 决策是什么
• 安全的默认选择是什么
• 什么信号提示你需要改变方向

c) 哪里要严格，哪里可以灵活

Mark each major chapter as 约束 or 建议 and explain why.

d) 已知的未知项

List unresolved issues the implementer will encounter. If the document is incomplete, say so. Include at least one honest unknown unless the user supplied unusually complete requirements.

e) 验收剧本

Write 3-5 implementation acceptance scripts. Each script should be a realistic user path or verification path the implementing AI can run manually or with tools.

Format:

验收剧本 1：在 [设备/环境] 打开 [入口]，执行 [动作]，应看到 [结果]，并用 [证据] 验证。

Prefer executable or observable evidence: screenshots, logs, local storage, exported files, browser console, simulator, network response, or test commands.

Generation Rules

1. Depth follows importance, not chapter order. 2. ASCII diagrams must include realistic labels, sample content, and actual button/menu text. 3. Make product decisions instead of deferring them. 4. Separate product constraints from implementation details. 5. If something is unclear, write 此处未解决：[具体问题] and continue. 6. The document must serve both humans and AI coding assistants. 7. Constraints should protect the product; they should not remove useful implementation creativity. 8. Use 超预期机会 for product delight, not feature bloat. 9. When the user provides URLs, current competitors, package choices, API behavior, platform support, legal/rights claims, or pricing facts, verify them when possible. If not verified, say so.