Вайбкодинг и создание продуктов Спроектировать внедрение
Как делать спецификацию продукта с 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
После утверждения спецификации:
- Создать mock API для инструментов агента (согласно схемам в спецификации).
- Запустить валидацию на тестовых данных — проверить, что агент ведёт себя по спецификации.
- Подключить логирование и аудит — убедиться, что контрольные точки работают.
- Запустить пилот с Human-in-the-loop — фиксировать, где агент «просит помощи».
Готовы к переходу к вайбкодингу в действии.