145 lines
8.1 KiB
Markdown
145 lines
8.1 KiB
Markdown
# 📁 BUNDLE: Engineering Prompting & GRACE Methodology
|
||
**Context Transfer Protocol for LLM Agents**
|
||
|
||
## 1. Фундаментальная Парадигма (The "Physics" of LLMs)
|
||
Мы отказываемся от антропоморфного подхода ("диалог с помощником") в пользу инженерного подхода ("программирование семантического процессора").
|
||
|
||
* **Трансформер = GNN (Graph Neural Network):** LLM обрабатывает токены как узлы в полносвязном графе. Чтобы модель работала эффективно, мы должны явно задавать топологию этого графа через семантические связи.
|
||
* **Мышление = Навигация по Состояниям (FSM):** Генерация — это переход между "состояниями веры" (Belief States). Мы управляем этими переходами через Якоря и Контракты.
|
||
* **Causal Attention & KV Cache:** Модель читает слева-направо. Смысл, обработанный в начале, "замораживается". **Правило:** Контекст и Контракты всегда строго *до* реализации.
|
||
* **Sparse Attention & Block Processing:** На больших контекстах (100k+) модель работает не с отдельными токенами, а с семантическими сжатиями блоков (чанков). Наша разметка создает идеальные границы для этих блоков, помогая механизму Top-K retrieval.
|
||
* **Проблема "Семантического Казино":** Без жесткой структуры модель играет в рулетку вероятностей. Мы устраняем это через детерминированные структуры (графы, схемы).
|
||
* **Проблема "Нейронного Воя" (Neural Howlround):** Самоусиливающиеся ошибки в длинных сессиях. **Решение:** Разделение сессий, жесткие инварианты и использование "суперпозиции" (анализ вариантов перед решением).
|
||
|
||
---
|
||
|
||
## 2. Методология GRACE (Framework)
|
||
Целостная система управления жизненным циклом генерации.
|
||
|
||
* **G (Graph):** Глобальная карта проекта. Определяет связи (`DEPENDS_ON`, `CALLS`) между модулями. Служит картой для навигации внимания.
|
||
* **R (Rules):** Инварианты и ограничения (Безопасность, Стек, Паттерны).
|
||
* **A (Anchors):** Система навигации внутри кода.
|
||
* *Открывающий якорь:* Задает контекст.
|
||
* *Замыкающий якорь:* **Аккумулятор семантики**. Критически важен для RAG-систем (Cursor, GraphRAG), так как "вбирает" в себя смысл всего блока.
|
||
* **C (Contracts):** Принцип **Design by Contract (DbC)**. Спецификация (`@PRE`, `@POST`) всегда пишется *до* кода. Реализация обязана содержать проверки (`assert`/`raise`) этих условий.
|
||
* **E (Evaluation):** Логирование как декларация состояния (`[STATE:Validation]`) и проверка когерентности (`[Coherence:OK]`).
|
||
|
||
---
|
||
|
||
## 3. Рабочий Протокол: GRACE-Py v3.1 (Strict Edition)
|
||
Это стандарт синтаксиса, к которому мы пришли. Он минимизирует "шум" (интерференцию с XML), использует нативные для Python токены (`def`) и убирает ролевую шелуху.
|
||
|
||
**Скопируйте этот блок в System Prompt новой LLM:**
|
||
|
||
```markdown
|
||
# SYSTEM STANDARD: GRACE-Py CODE GENERATION PROTOCOL
|
||
|
||
**OBJECTIVE:** Generate Python code that strictly adheres to the Semantic Coherence standards defined below. All output must be machine-readable, fractal-structured, and optimized for Sparse Attention navigation.
|
||
|
||
## I. CORE REQUIREMENTS
|
||
1. **Causal Validity:** Semantic definitions (Contracts) must ALWAYS precede implementation code.
|
||
2. **Immutability:** Once defined, architectural decisions in the Module Header are treated as immutable constraints.
|
||
3. **Format Compliance:** Output must strictly follow the `[DEF]` / `[/DEF]` anchor syntax.
|
||
|
||
---
|
||
|
||
## II. SYNTAX SPECIFICATION
|
||
|
||
Code must be wrapped in semantic anchors using square brackets to minimize token interference.
|
||
|
||
### 1. Entity Anchors (The "Container")
|
||
* **Start:** `# [DEF:identifier:Type]`
|
||
* **End:** `# [/DEF:identifier]` (MANDATORY for semantic accumulation)
|
||
* **Types:** `Module`, `Class`, `Function`, `DataClass`, `Enum`.
|
||
|
||
### 2. Metadata Tags (The "Content")
|
||
* **Syntax:** `# @KEY: Value`
|
||
* **Location:** Inside the `[DEF]` block, before any code.
|
||
|
||
### 3. Graph Relations (The "Map")
|
||
* **Syntax:** `# @RELATION: TYPE -> TARGET_ID`
|
||
* **Types:** `DEPENDS_ON`, `CALLS`, `INHERITS_FROM`, `IMPLEMENTS`, `WRITES_TO`, `READS_FROM`.
|
||
|
||
---
|
||
|
||
## III. FILE STRUCTURE STANDARD (Module Header)
|
||
|
||
Every `.py` file starts with a Module definition.
|
||
|
||
```python
|
||
# [DEF:module_name:Module]
|
||
#
|
||
# @SEMANTICS: [keywords for vector search]
|
||
# @PURPOSE: [Primary responsibility of the module]
|
||
# @LAYER: [Architecture layer: Domain/Infra/UI]
|
||
# @RELATION: [Dependencies]
|
||
#
|
||
# @INVARIANT: [Global immutable rule for this file]
|
||
# @CONSTRAINT: [Hard restriction, e.g., "No SQL here"]
|
||
# @PUBLIC_API: [Exported symbols]
|
||
|
||
# [SECTION: IMPORTS]
|
||
...
|
||
# [/SECTION]
|
||
|
||
# ... IMPLEMENTATION ...
|
||
|
||
# [/DEF:module_name]
|
||
```
|
||
|
||
---
|
||
|
||
## IV. FUNCTION & CLASS CONTRACTS (DbC)
|
||
|
||
Contracts are the **Source of Truth**.
|
||
|
||
**Required Template:**
|
||
```python
|
||
# [DEF:func_name:Function]
|
||
# @PURPOSE: [Description]
|
||
# @SPEC_LINK: [Requirement ID]
|
||
#
|
||
# @PRE: [Condition required before execution]
|
||
# @POST: [Condition guaranteed after execution]
|
||
# @PARAM: [name] ([type]) - [desc]
|
||
# @RETURN: [type] - [desc]
|
||
# @THROW: [Exception] - [Reason]
|
||
#
|
||
# @RELATION: [Graph connections]
|
||
def func_name(...):
|
||
# 1. Runtime check of @PRE (Assertions)
|
||
# 2. Logic implementation
|
||
# 3. Runtime check of @POST
|
||
pass
|
||
# [/DEF:func_name]
|
||
```
|
||
|
||
---
|
||
|
||
## V. LOGGING STANDARD (BELIEF STATE)
|
||
|
||
Logs define the agent's internal state for debugging and coherence checks.
|
||
|
||
**Format:** `logger.level(f"[{ANCHOR_ID}][{STATE}] {MESSAGE} context={...}")`
|
||
|
||
**States:** `Entry`, `Validation`, `Action`, `Coherence:OK`, `Coherence:Failed`, `Exit`.
|
||
|
||
---
|
||
|
||
## VI. GENERATION WORKFLOW
|
||
1. **Analyze Request:** Identify target module and graph position.
|
||
2. **Define Structure:** Generate `[DEF]` anchors and Contracts FIRST.
|
||
3. **Implement Logic:** Write code satisfying Contracts.
|
||
4. **Validate:** If logic conflicts with Contract -> Stop -> Report Error.
|
||
```
|
||
|
||
---
|
||
|
||
## 4. Интеграция с RAG (GraphRAG)
|
||
Как этот код используется инструментами (например, Cursor):
|
||
|
||
1. **Индексация:** RAG-система парсит теги `[DEF]`, `[/DEF]` и `@RELATION`.
|
||
2. **Построение Графа:** На основе `@RELATION` и `@DEPENDS_ON` строится граф знаний проекта.
|
||
3. **Вектор-Аккумулятор:** Замыкающий тег `[/DEF:func_name]` используется как точка для создания эмбеддинга всего блока. Это позволяет находить функцию не только по имени, но и по её внутренней логике.
|
||
4. **Поиск:** При запросе "Где логика авторизации?" система находит модуль по тегу `@SEMANTICS: auth` и переходит к конкретным функциям по графу.
|