How BP Claw Solves AI Coding Input Challenges in FlinkSpec’s Real‑Time Data Warehouse

BP Claw in FlinkSpec

BP Claw is positioned upstream of FlinkSpec as an “AI data business partner” that converts non‑standard product‑requirement documents (PRDs) into structured, AI‑coding‑ready specifications.

Problem

Unstable AI coding, repeated requirement clarifications, and inconsistent PRD quality cause downstream failures: vague definitions lead to repeated Intake rejections, missing technical specifications block the Flink‑SQL Agent, and unclear acceptance criteria cause regressions in the Review stage.

Core capabilities

Semantic retrieval – queries the OpenViking knowledge base for historical modeling decisions and detects multi‑granularity ambiguities.

Constraint injection – explicitly writes detected ambiguities into the PRD before FlinkSpec processes it.

Segmented generation – splits documents larger than 10 metrics into a skeleton plus incremental metric modules; every five metrics a progress update is sent, preventing context overflow and reducing token consumption.

Skill orchestration – a dynamic scheduler composes three independent Skills (conversion, scoring, group creation) and executes them strictly in sequence: STEP 1 → STEP 2 → STEP 3 → STEP 4.

Token‑saving techniques

Segmented generation as above.

Layered calling architecture isolates each Skill’s context, avoiding token bloat.

Template‑driven prompts enforce a fixed output structure.

Hallucination prevention – multi‑layer prompt constraints require fidelity to source material; unknown fields are marked with a ⚠️ “to‑be‑filled” tag. A separate prd-quality-scorer Skill cross‑validates the output and flags logical contradictions.

PRD quality scoring

After conversion BP Claw evaluates the standardized PRD on five dimensions and produces a composite score (max 100). Key rules:

Technical‑specification veto: score < 15 (out of 25) triggers a hard block, preventing the Flink‑SQL Agent from running.

Missing acceptance criteria deducts 20 points (or 10 points if partially missing).

Overflow scoring allows a dimension to exceed its max, but the overall cap remains 100.

The score is advisory; it mirrors current PRD quality for continuous improvement.

Operational mechanisms

Maturity scoring system – tracks domain‑level PRD maturity scores to raise the baseline.

Quality‑trend dashboard – visualizes score trends per business domain, highlights frequent deficiencies, and supports monthly retrospectives.

Best‑practice consolidation – PRDs scoring ≥ 90 are archived as templates; improvement guides are generated for common deduction items; new engineers are onboarded using the scoring reports.

Quick start command

@BusinessMOSS @Reviewer1 @Reviewer2 …需求拉群 Feishu PRD_document_link

The bot reads the link, generates the structured PRD, runs the quality scorer, creates a review group, and posts the document with a diagnostic report within 1–5 minutes.

Impact examples

Scenario 1 – a PRD with complete technical specifications scores ≥ 90, passes the Define stage on the first attempt, and the Flink‑SQL Agent generates code without human intervention, reducing delivery time to days.

Scenario 2 – a PRD missing technical specifications scores < 60, triggers the veto rule, causing repeated Define‑stage blocks and extending delivery to weeks.

Empirically, each 10‑point increase in PRD quality correlates with an approximate 30 % boost in coding‑stage efficiency.

Technical challenges and solutions

Token consumption – segmented generation, layered Skill calls, and template prompts keep token usage within API limits.

Hallucination avoidance – strict “faithful to source” rules, explicit “to‑be‑filled” markers, and a cross‑validation scorer prevent fabricated business definitions.

Skill coordination – a strict serial execution model (STEP 1 → STEP 2 → STEP 3 → STEP 4) ensures that a failure in any critical step aborts the workflow and notifies the user.

Domain knowledge injection – the OpenViking knowledge base supplies historical decisions, enabling disambiguation of multi‑granularity metrics (e.g., advertiser‑level vs platform‑level impression counts).

Integration with FlinkSpec

BP Claw’s output becomes the input to FlinkSpec’s Define stage. When technical specifications are present, the Flink‑SQL Agent can generate DDL and INSERT logic directly; when they are absent, the veto rule stops the pipeline, forcing upstream clarification.

Future work

This article is the first in the FlinkSpec series; subsequent posts will dive deeper into each capability, provide additional case studies, and explore further automation of the real‑time data‑warehouse lifecycle.