Created
July 31, 2026 12:14
-
-
Save Dimon70007/3c576591902398e69e8ca9a692f1a955 to your computer and use it in GitHub Desktop.
Keywords for ai as commands
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| To give you an accurate picture, it is important to clarify one key thing: a language model does not have a static, universal list of words with fixed weights built into its source code. | |
| Instead, weights are calculated dynamically in real time every time you send a message, using the Attention mechanism. The weight of a word depends entirely on the context of your prompt, the words surrounding it, and the patterns the AI learned during training. | |
| However, based on how LLMs (like Claude, GPT-4, or DeepSeek) are trained on human texts (code, legal documents, military manuals, casual forums), we can group semantic anchors into tiers of statistical priority. | |
| Here is a sorted breakdown of how different types of directives influence the AI's internal attention vector, from strongest to weakest. | |
| ------------------------------ | |
| ## Tier 1: Absolute Structural Constraints (Highest Priority) | |
| These are terms associated with hard programming boundaries, logical definitions, and strict legal or military protocols in the training data. They create the strongest mathematical "gravity" in the prompt. | |
| * CRITICAL_DO_NOT / NEVER / ЗАПРЕЩЕНО — Negative constraints always receive the highest weight because they act as logical gates. In safety training (RLHF), breaking a "NEVER" rule is heavily penalized, making these tokens mathematically dominant. | |
| * MANDATORY / REQUIRED / ОБЯЗАТЕЛЬНО — Associated with system requirements and validation code. The model treats these as conditions that must evaluate to true before the text generation loop can close. | |
| * COMMAND / INSTRUCTION / ПРИКАЗ — Anchors the model into a strict execution state. It signals to the attention heads that the text following it is a meta-rule governing the entire generation, rather than conversational text. | |
| ## Tier 2: Standard Requirements and Specifications (Medium-High Priority) | |
| These words are common in Technical Specifications (RFCs) and Project Documentation. The AI treats them as high-priority goals, but they allow for more flexible implementation paths. | |
| * REQUIREMENT / ТРЕБОВАНИЕ — Tells the model to cross-reference its output against this specific point, but lacks the absolute blocking weight of "MANDATORY". | |
| * ALWAYS / ВСЕГДА — A strong frequency modifier. It forces the attention mechanism to look back at this rule at every single step (token) of the generation loop. | |
| * EXPECTED / ОЖИДАЕТСЯ — Signals a target output state. The model uses this to align its probabilistic trajectory toward a specific end result. | |
| ## Tier 3: Preferences and Guidelines (Medium Priority) | |
| These tokens appear frequently in style guides, advice, and tutorials. They guide the model's tone and style but can be easily overwritten if the prompt becomes too long or conflicting. | |
| * SHOULD / СЛЕДУЕТ — Interpreted as a strong recommendation. However, if a Tier 1 or Tier 2 constraint conflicts with it, the "SHOULD" rule will be mathematically sacrificed. | |
| * PREFER / ПРЕДПОЧТИТЕЛЬНО — Tells the AI which statistical path to choose if two options have roughly equal probability. | |
| * RECOMMENDED / РЕКОМЕНДУЕТСЯ — Soft guidance. It gently nudges the weights of certain associated words up by a small percentage. | |
| ## Tier 4: Optional and Permissive Terms (Lowest Priority) | |
| These words weaken constraints. They open up the mathematical search space, giving the model the freedom to ignore the suggestion if the underlying language patterns suggest a different path. | |
| * MAY / МОЖНО — Opens a branch in the probability tree but applies almost zero driving force to make the AI actually take it. | |
| * OPTIONAL / НЕОБЯЗАТЕЛЬНО — The model notes the option but assigns it a low priority. In long prompts (close to the context limit), these are the first rules the attention mechanism filters out. | |
| * IF_POSSIBLE / ПО ВОЗМОЖНОСТИ — The AI will only follow this if it doesn't require extra "effort" (i.e., if it aligns perfectly with the easiest, most common linguistic template available). | |
| ------------------------------ | |
| ## 💡 The Prompt Engineer's Golden Rule | |
| If you want to ensure your OpenClaw setup never misses a rule, do not rely on a single word. Instead, stack the mathematical probability by combining three factors: | |
| 1. Use Tier 1 Words: Use ТРЕБОВАНИЕ: ЗАПРЕЩЕНО... instead of Пожалуйста, не делай.... | |
| 2. Use Visual Anchors: Wrap the rule in uppercase XML tags (e.g., <STRICT_RULE>...</STRICT_RULE>). LLMs assign massive structural weight to code-like syntax. | |
| 3. Punish Gallucination: Explicitly tell the model what a "failure" looks like (e.g., "If you say 'File created' without running step 2, it is a critical violation of your protocol"). | |
| Would you like me to rewrite your OpenClaw soul.md file block using the exact XML structure and Tier 1 keywords that match the specific model (e.g., Claude 3.5 Sonnet or GPT-4o) you are currently running? |
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
В [OpenClaw](https://openclaws.io/) поведение модели и логика использования инструментов (skills) регулируются файлами soul.md (глобальные инструкции поведения), SKILL.md (описание конкретных навыков), а также системными промптами.
Чтобы превратить этот математический инструмент в отказоустойчивый конвейер и заставить его физически проверять факт создания файла перед отправкой сообщения, примените следующий комплекс решений.
Шаг 1. Настройка жесткого алгоритма в soul.md или системном промпте
Модель склонна «галлюцинировать» об успехе, потому что текстовый ответ о выполнении задачи имеет высокий статистический приоритет. Нужно принудительно разорвать эту цепочку и связать генерацию финального ответа с результатом работы функции.
Добавьте в ваш рабочий soul.md следующее жесткое правило (лучше использовать разметку XML, так как современные LLM, вроде Claude или GPT-4, воспринимают её как непреодолимый программный синтаксис):
<file_creation_protocol>1. ПРИКАЗ: ТЕБЕ ЗАПРЕЩЕНО писать пользователю фразы вида "Я создал файл", "Файл успешно записан" или "Готово", основываясь только на факте вызова инструмента записи (например, write_file или bash-скрипта).2. ОБЯЗАТЕЛЬНЫЙ ДВУХШАГОВЫЙ АЛГОРИТМ (Strict Two-Step Execution):
ls -la path/to/fileчерез bash-терминал).3. УСЛОВИЕ ФИНАЛЬНОГО ОТВЕТА:Шаг 2. Исправление SKILL.md (Описания инструментов)
В OpenClaw инструменты вызываются на основе их текстового описания. Если модель «считает», что инструмент write_file автоматически гарантирует результат, она не будет перепроверять.
Отредактируйте SKILL.md для вашего инструмента работы с файлами. Прямо в описание функции (docstring / metadata) добавьте требование возвращать подтверждение.
Шаг 3. Внедрение "Few-Shot Prompting" (Примеры правильного поведения)
Модели — мастера подражания. Дайте инструменту в системном контексте явный пример того, как выглядит правильный цикл работы. Добавьте это в секцию примеров вашего промпта:
<example_behavior>
Пользователь: "Создай отчет report.txt со списком задач"
Правильный ход мыслей и действий ИИ:1. Вызываю инструмент: write_file(path="report.txt", content="...")2. Получаю ответ от системы: "Запрос обработан"3. (Критически важно!) Вызываю инструмент: check_file_exists(path="report.txt")4. Получаю ответ от системы: {exists: true, size: 2450}5. Финальный ответ пользователю: "Файл report.txt успешно создан, проверен на диске и занимает 2450 байт."</example_behavior>
Шаг 4. Диагностика скрытых багов OpenClaw
Если даже после этого ИИ продолжает галлюцинировать, проблема лежит на стыке кода и окружения (Docker, права доступа):