How to Convert Rough PRDs into Structured AI‑First Specifications

Why Rough PRDs Fail with AI Coding Tools

When a loosely written PRD is handed directly to an AI coding assistant, the generated code may appear correct but suffers from unclear boundaries, unstable acceptance criteria, and missing exception paths, requiring manual rework. The root cause is that the PRD is not in an "executable specification" state; humans fill in business context, historical conventions, and product judgments automatically, while the agent can only read the literal facts present in the document, code, tests, and tooling outputs.

AI‑First PRD Concept

An AI‑First PRD restructures vague wishes into a machine‑readable input, enabling the agent to split tasks, locate relevant code, modify implementations, write tests, and run verification. The output still serves humans, but the machine now has a stable execution basis.

AI‑First PRD Conversion Flow

Rough PRD → AI clarification & rewrite → Structured AI‑First PRD

Structured PRD → Task decomposition → Spec/plan/tasks

Tasks → Minimal code slice / existing patterns → Implementation

Implementation → Test / build / human review → Acceptance verification

Feedback → Update PRD if ambiguities are discovered → Continue

1. Expand Implicit Context in a Rough PRD

Human teams rely on meetings and reviews to supplement hidden information such as button placement, legacy data compatibility, exception wording, and retry policies. An AI coding tool treats these gaps as guesses, which can lead to arbitrarily named database fields, missing role‑based permission checks, incomplete state enums, and tests that only cover the happy path. The first step is to make explicit the parts that humans would normally supplement; the tool can surface gaps, but product owners must confirm the business decisions.

2. Four Types of Information to Add Before Implementation

Goal: User problem, business benefit, success metrics.

Boundary: What is in scope, what is deferred, explicit exclusions.

State: Page, data, permission, and exception states.

Acceptance: Visible results, system behavior, test and manual‑check standards.

3. Organise an AI‑First PRD into Five Blocks

Goals & Metrics – Who’s the problem for and how is success measured? Prevents drift from business purpose.

Scope & Boundary – What is included, postponed, or explicitly excluded? Reduces over‑implementation and omissions.

State & Rules – How do normal, empty, loading, failure, permission, and edge‑case states appear? Aligns UI branches with code paths.

Interface & Data – Fields, permissions, idempotency, error codes, migration and compatibility strategies? Lowers front‑end/back‑end misunderstanding.

Acceptance & Verification – What behaviour counts as done, which tests run, and what manual checks apply? Makes deliverables traceable.

4. Two‑Round Requirement Review Before Coding

First round: review only the requirement, no code changes. The tool reads the original PRD, project description, relevant code directories, and existing patterns, then outputs four parts: clear facts, ambiguities & gaps, product‑confirmation questions (ranked by blocking severity), and a recommended AI‑First PRD structure.

Second round: rewrite the clarified content into an AI‑First PRD. This prevents the pitfall where an unstable requirement leads the agent to fill in implementation details prematurely.

Supported agents include Claude Code, Codex, Cursor, and GitHub Copilot Coding Agent. Project‑level rules can be stored in files such as AGENTS.md, CLAUDE.md, Cursor Rules, or Copilot repository instructions, allowing the tool to read constraints during both review and planning phases.

需求审稿指令示例

请只审查需求，不要写代码。

阅读这份粗略 PRD 和当前仓库中相关模块。
输出四部分：
1. 需求中已经明确的事实
2. 影响实现的歧义和缺口
3. 需要产品确认的问题，按阻塞程度排序
4. 推荐的 AI First PRD 结构

要求：
每个问题都说明它会影响哪个实现决策。
不要自行替产品做业务判断。
不要进入代码修改。

5. Write Acceptance Criteria as Observable Behaviour

Ordinary PRDs state vague goals such as “support order filtering” or “show error on failure”. Acceptance criteria must describe concrete, observable actions:

Object: Roles such as admin, regular member, guest, system task.

Condition: Data present, empty, API failure, insufficient permission, duplicate submission, etc.

Action: Click, submit, filter, refresh, import, undo, retry.

Result: Page feedback, data change, error message, log entry, test assertion.

6. Example: From Vague Requirement to AI‑First PRD Fragment

Vague input:

粗略写法

订单列表增加一个导出功能。
用户可以按时间筛选订单，然后导出 Excel。
导出失败时给一个提示。

Structured AI‑First PRD fragment:

AI First PRD 片段

Feature
订单列表支持导出筛选结果。

User
具备订单管理权限的运营人员。

Scope
本期只支持按创建时间导出当前筛选结果。
本期不支持自定义导出字段，不支持异步导出中心。

Data
导出字段包括订单号、创建时间、支付状态、订单金额、收货人和手机号脱敏值。
时间范围最长 31 天。
单次导出最多 10000 条。

Interaction
用户选择时间范围后点击导出按钮。
系统生成 xlsx 文件并触发下载。
没有数据时按钮可点击，导出文件只包含表头。

Error
无权限时隐藏导出按钮。
接口超时或生成失败时展示可重试错误提示。
超过 10000 条时提示缩小筛选范围。

Acceptance
管理员能导出 31 天内订单。
普通成员看不到导出入口。
空结果导出文件只包含表头。
超过上限时不会生成文件，并展示明确提示。

Verification
补充导出字段映射单元测试。
补充权限和上限的接口测试。
手工检查下载文件名、字段顺序和手机号脱敏。

7. Feasibility Review Before Implementation

After the AI‑First PRD is written, the tool should locate similar modules, identify files that may need changes, list test entry points, and highlight risk areas. The focus is on whether the specification can be applied to the existing codebase, not on polishing prose.

If the repository already contains rule files (e.g., AGENTS.md, CLAUDE.md), the tool should incorporate those constraints into the implementation plan. The requirement defines "what to do"; the project description defines "how to do it in this repo".

Implementation‑pre‑review checklist:

Existence of similar functionality, interfaces, or tests in current code.

Need for new dependencies, database fields, permission points, or background jobs.

Mapping of each acceptance criterion to a test, build step, or manual check.

Items that require product judgment and human confirmation.

Risks that should be split into separate tasks or deferred to later versions.

8. Product Judgment Remains Human

AI coding tools can organise requirements and surface implementation risks, but final business decisions—such as the 31‑day export limit, member export permissions, or phone‑number masking format—must be confirmed by the product owner.

The mature workflow treats the agent as a requirement‑structuring assistant and risk reviewer, while humans handle trade‑offs, conflict resolution, scope approval, and accountability.

Conclusion

Rough PRDs cause agents to guess context; AI‑First PRDs turn that context into executable specifications.

An effective process is: review → rewrite → implement, exposing ambiguities early when the requirement is unstable.

Acceptance criteria must be observable and directly mappable to tests, builds, or manual checks, with evidence of completion.

Tools handle structuring and risk exposure; product owners retain the final decision‑making authority.