Summary of "Как составлять промпты"

Overview

A practical guide to prompt engineering (referred to as “industrial engineering” in the video) that shows how to craft prompts for large language models (LLMs) using multiple real examples. The material demonstrates how prompt structure, specificity, formatting, examples, and explicit reasoning/verification steps affect output quality.

Key technical concepts and findings

LLMs frequently fill missing details with common defaults (e.g., product card fields, calculator parameters) — they generate according to learned templates.
Overloading a prompt with many specific blocks, roles, or context can reduce focus and cause the model to drop the original intent (an attention-management issue).
Numeric, concrete constraints and explicit formatting are more reliably honored than vague descriptive directives (for example, “without water” or “concise”).
Examples (one-shot / few-shot) carry more weight than textual descriptions; providing a correct example strongly steers output.
Reasoning techniques (chain-of-thought variants, verification steps, reflection) materially improve result quality; asking the model to check its work yields better, more consistent outputs.
For precise calculations, asking the LLM to generate code/programs (reasoning through code) is preferable to asking for direct numeric answers.
Diagrams and architecture sketches produced by LLMs can be inconsistent; notation matters (for example, solid vs dotted arrows in UML/Mermaid can convey dependency vs ownership).

Practical examples covered (what was tried and lessons)

Product card for headphones
- The LLM produced a typical card with defaults (name, rating, price) even with minimal input.
- Lesson: if defaults are acceptable, minimal prompts may suffice; otherwise specify unusual requirements.
Window calculator (HTML)
- With a minimal prompt the model produced a calculator with standard elements.
- Adding many roles/context/formatting blocks caused the model to output a general calculator and lose the “window” context.
- Lesson: extra details can crowd out the core intent; structure prompts deliberately.
Travel plan (week in St. Petersburg)
- Initial vague prompt produced a brochure-like list of attractions.
- Adding specific numeric budgets, a requested layout (table), and step-by-step verification produced a readable, pivot-like table with logistics and analysis.
- Lesson: structured formatting and explicit verification drastically improve usefulness and accuracy.
Software architecture (modular monolith vs microservices)
- A generic prompt produced a standard descriptive answer.
- Adding precise constraints and diagrams (Mermaid) plus few-shot examples produced more accurate architecture diagrams and explanations.
- Important nuance: correct diagram notation (dotted vs solid arrows) matters for expressing coupling and lifetime/dependency.
- Deeper prompts using reasoning techniques (few-shot with checks) yielded the best architecture outputs; however, generated diagrams may still be less reliable depending on the model and training data.

Prompt composition guidance (three-stage knowledge graph)

Stage 1 — Prompt formatting
- Use a standard multi-block structure.
- Use Markdown/layout to separate sections clearly.
Stage 2 — Requirements & content
- Be precise; remove unnecessary information.
- Use specific terms and numeric constraints where relevant.
Stage 3 — Reasoning techniques
- Choose and embed techniques that fit the task (examples, step checks, code generation, reflection).

Recommended prompt principles

Prefer specific numeric and structured instructions over vague adjectives.
Use examples (one-shot or few-shot) to define desired style and format.
Format outputs explicitly (tables, JSON, code blocks) to improve readability and post-processing.
Iterate: use intermediate checks and require the model to verify or reflect on outputs.
When accuracy is critical, request code (a program) to compute results.

Reasoning techniques listed

Chain-of-thought / step-by-step decomposition (best for problems solvable sequentially).
Reasoning through code (ask the model to write a program to compute precise values).
One-shot / few-shot / zero-shot (use examples to set expectations).
Contrastive thinking (ask the model to explain why alternative outputs would be wrong).
Knowledge tree (extract themes and how they interrelate).
Chain-of-notes (short, bullet-like notes for concise outputs).
Reflection / verification steps (ask the model to check and validate its own answers).

Pitfalls and limitations

Too many specific instructions can compete for the model’s attention and produce worse outputs.
Vague constraints (e.g., “no fluff”) are poorly interpreted by LLMs.
LLM-generated diagrams and architecture artifacts may be imperfect; model performance varies by task type and training data.

Actionable takeaways

Structure prompts in clear blocks; use concrete numbers and explicit output formats.
Provide one or more examples when you need a specific style or structure.
Use reasoning and verification steps and, for numeric accuracy, request code to compute values.
Iterate and test prompts: refine by observing how the model shifts attention when adding or removing constraints.

Main speaker / sources

Video host (channel author) — presents the examples, experiments, and compiled knowledge graph.
LLM used in demonstrations: Depsik / Deepsk (referenced as the model tested), with observations generalized to other LLMs.