How EARS Rewrites Requirements to Make AI Coding More Accurate

AI coding often fails not because prompts are poorly written but because the underlying requirements are ambiguous. Vague statements like “login should feel better” hide many unanswered assumptions that AI fills with its own default guesses, leading to broken integrations.

To eliminate this ambiguity, the author adopts the EARS (Easy Approach to Requirements Syntax) method before feeding requirements to AI. EARS, originally proposed by Alistair Mavin in 2009 for safety‑critical systems, forces each requirement into one of six fixed sentence patterns (Ubiquitous, Event‑Driven, State‑Driven, Unwanted‑Behavior, Optional‑Feature, Complex) using the keyword shall (written as “应” in Chinese).

The six patterns are illustrated with concrete syntax examples, such as:

Ubiquitous: 系统应<响应>。 Event‑Driven: 当<触发事件>时，系统应<响应>。 State‑Driven: 在<状态>时，系统应<响应>。 Unwanted‑Behavior (IF‑THEN): 如果<条件>，则系统应<响应>。 Optional‑Feature (WHERE): 在已启用<功能>时，系统应<响应>。 Complex:

在<状态>时，当<事件>时，系统应<响应>。

Practical rules for applying EARS include:

Each requirement contains only one shall clause; split multi‑action sentences.

Avoid vague modifiers like “quickly”, “reasonably”, or “friendly”.

Specify concrete trigger conditions.

Make responses measurable (numbers, time limits, messages).

Uncertain details become “待确认问题” (pending questions) for the PM.

Why EARS matters in the AI era:

AI will silently guess missing details; EARS removes those gaps.

Ambiguous requirements become a major source of bugs, and AI amplifies the impact.

Consistent, structured specs keep prompt behavior stable across models and versions.

The author outlines a five‑step workflow:

Identify actors, actions, triggers, states, and exceptions.

Mark ambiguous terms for clarification.

Split compound sentences into atomic ones.

Map each atomic sentence to one of the six EARS patterns.

Add quantitative details or list pending questions.

Four real‑world examples demonstrate the transformation:

Login requirement split into four precise rules covering validation, error messages, and account lockout.

Two‑factor authentication expanded into enabled/disabled branches and retry limits.

Network error handling expressed with exponential back‑off retries and explicit failure marking.

Offline‑sync scenario broken into storage and timed synchronization rules.

After rewriting, the same EARS spec can be used to:

Feed AI for code generation.

Automatically generate test cases.

Serve as a review and acceptance artifact.

Implementation tip: encapsulate the EARS rewrite process as a reusable skill (e.g., via

npx skills add https://github.com/wuchubuzai2018/expert-skills-hub --skill haizei-ears-requirements

) so that AI consistently receives structured input.

In summary, structuring requirements with EARS turns vague business language into testable specifications, reduces costly rework, and makes AI‑assisted development reliable.