Вайбкодинг и создание продуктов Спроектировать внедрение

Как делать спецификацию продукта с AI

Спецификация продукта — не документ, а живой контракт между бизнесом и разработкой. AI ускоряет её создание, но не заменяет ответственность. Разбираем, как выстраивать процесс от идеи до API и контрольных точек.

Что такое спецификация продукта в AI-интеграции

Спецификация продукта — это сжатый, проверяемый набор требований, описывающий, что делает MVP, как он взаимодействует с AI-агентами и людьми, и как его работа будет контролироваться. В отличие от традиционного ТЗ, она фокусируется на контексте агента, границах ответственности и fallback-сценариях.

Архитектура спецификации: 4 слоя

flowchart TD
    A[Цель MVP] --> B[Контекст агента]
    B --> C[API и инструменты]
    C --> D[Контроль: логи, аудит, fallback]
    
    subgraph Бизнес
      A
    end
    
    subgraph AI-интеграция
      B
      C
    end
    
    subgraph Контроль
      D
    end
    
    style A fill:#e6f7ff,stroke:#1890ff
    style B fill:#f6ffed,stroke:#52c41a
    style C fill:#f6ffed,stroke:#52c41a
    style D fill:#fff7e6,stroke:#fa8c16

Пример: спецификация для агента обработки заявок

Цель: автоматически классифицировать входящие заявки и направлять их на согласование или обработку.

  • Контекст агента: получает заявку (JSON), знает структуру полей, ограничения по типам (только юрлица), текущие правила фильтрации.
  • Инструменты: `classify_request`, `check_compliance`, `notify_approver`.
  • Контроль: логирование всех решений, аудит изменений правил, fallback на человека при confidence < 0.85.

Чек-лист спецификации: что проверить перед стартом

Что проверить Зачем
Есть ли однозначный входной формат (JSON Schema / OpenAPI)? Без этого агент не сможет стабильно парсить данные
Определены ли все fallback-сценарии (ошибки API, отсутствие данных, конфликт правил)? Предотвращает «тихие» сбои и утечки данных
Кто и как подтверждает действия агента? (Human-in-the-loop) Соблюдение регуляторных требований и доверие пользователей
Есть ли логирование: кто, когда, с каким контекстом вызывал агента? Аудит, отладка и улучшение правил
Как обновляются правила и контекст без перезапуска? Бизнес-изменения должны быть быстрыми

Псевдокод: структура спецификации как кода

// product_spec.json
{
  "mvp_id": "support-agent-v1",
  "goal": "Классифицировать заявки и направлять на обработку",
  "agent_context": {
    "allowed_types": ["legal_entity"],
    "rules_version": "2025-04",
    "max_retries": 2
  },
  "tools": [
    {
      "name": "classify_request",
      "schema": {
        "input": "RequestInput",
        "output": "ClassificationResult"
      }
    },
    {
      "name": "notify_approver",
      "schema": {
        "input": "ApprovalRequest",
        "output": "NotificationStatus"
      }
    }
  ],
  "controls": {
    "logging": {
      "level": "debug",
      "fields": ["request_id", "agent_id", "confidence", "timestamp"]
    },
    "fallback": {
      "on_confidence_below": 0.85,
      "action": "route_to_human"
    },
    "audit": {
      "changes": true,
      "reviewers": ["product_owner", "compliance"]
    }
  }
}

Типичные ошибки

  • «Спецификация как wish-list»: «Агент должен уметь всё» — приводит к нестабильности и росту cost-to-serve.
  • Игнорирование fallback: «Агент сам разберётся» — в реальности это означает «никто не разберётся».
  • Отсутствие версионирования: правила и контекст меняются, но не фиксируются — невозможно откатить или проанализировать инцидент.
  • Спецификация без контроля: если нельзя проверить, что агент делает — это не спецификация, а догадка.

Следующий шаг: от спецификации к MVP

После утверждения спецификации:

  1. Создать mock API для инструментов агента (согласно схемам в спецификации).
  2. Запустить валидацию на тестовых данных — проверить, что агент ведёт себя по спецификации.
  3. Подключить логирование и аудит — убедиться, что контрольные точки работают.
  4. Запустить пилот с Human-in-the-loop — фиксировать, где агент «просит помощи».

Готовы к переходу к вайбкодингу в действии.