Initial import from GitHub
This commit is contained in:
红尘
@@ -0,0 +1,55 @@
|
||||
# Architectural Patterns
|
||||
|
||||
## Lazy-Loaded Skills
|
||||
|
||||
The standard pattern for managing large context requirements across AI agents is lazy-loaded prompt engineering through skill files.
|
||||
|
||||
A skill is a folder containing a `SKILL.md` file with:
|
||||
|
||||
- **YAML front-matter:** Contains `name` and a precise `description`. This metadata acts as the discovery hook — the agent reads only this during initialization (~100 tokens per skill).
|
||||
- **Markdown body:** Full workflows, rules, and instructions. Loaded on-demand only when the agent determines the skill is relevant.
|
||||
|
||||
This architecture yields a documented 35% reduction in average context usage and prevents context dilution. However, discovery reliability depends on the specificity of the YAML description:
|
||||
|
||||
| Description Quality | Discovery Success Rate |
|
||||
|:---|:---:|
|
||||
| Vague ("Helps with designing APIs") | ~68% |
|
||||
| Specific ("Design RESTful HTTP APIs with OpenAPI specs, focusing on versioning, error codes, and backward compatibility") | ~90% |
|
||||
|
||||
## Model Context Protocol (MCP)
|
||||
|
||||
MCP is an open standard (pioneered by Anthropic, adopted by Google and OpenAI) that enables real-time, bidirectional connections between LLMs and external data sources.
|
||||
|
||||
### Architecture Components
|
||||
|
||||
- **Host:** The AI application (IDE, terminal tool, chatbot) containing the LLM engine.
|
||||
- **Client:** Internal bridge within the host that handles protocol communication.
|
||||
- **Server:** External service exposing databases, APIs, or documentation to the client.
|
||||
- **Transport:** JSON-RPC 2.0 messages over stdio (local) or HTTP (remote).
|
||||
|
||||
### How It Reduces Truncation
|
||||
|
||||
Without MCP, models rely on static training weights for factual claims. When those weights are outdated (e.g., a new API version was released after training cutoff), the model either hallucinates a plausible answer or truncates its response to avoid committing to specifics.
|
||||
|
||||
With MCP, the model fetches current documentation directly into its context window. This transforms the model from a static knowledge store into a reasoning engine operating on real-time data, eliminating the incentive to hallucinate or truncate.
|
||||
|
||||
### Example: Developer Knowledge API
|
||||
|
||||
Google's Developer Knowledge MCP Server indexes live documentation across Firebase, Android, and Google Cloud. When a model receives a development question:
|
||||
|
||||
1. It executes a `search_document` query against the live index
|
||||
2. It evaluates returned page URIs
|
||||
3. It fetches full document content via `get_document` or `batch_get_documents`
|
||||
4. It generates its response based on current, authoritative documentation
|
||||
|
||||
This entirely bypasses the tendency to fabricate answers from outdated training data.
|
||||
|
||||
## Chunked Task Execution
|
||||
|
||||
For complex tasks that would produce outputs exceeding the model's generation limit, break the work into sequential steps:
|
||||
|
||||
1. Request the architecture and structure first (outline only)
|
||||
2. Request each component individually with explicit instructions for completeness
|
||||
3. Request assembly and integration after all components are generated
|
||||
|
||||
This prevents the model from attempting to estimate total output length and preemptively compressing its response.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Parameter Tuning
|
||||
|
||||
## Temperature and Top-p
|
||||
|
||||
Autoregressive models select each next token from a probability distribution generated by a softmax function applied to logit values. When a model defaults to brief outputs, the tokens associated with truncation and summarization have been assigned the highest probabilities through RLHF alignment.
|
||||
|
||||
### Temperature
|
||||
|
||||
Adjusting the temperature parameter changes how the softmax function distributes probability mass across candidate tokens.
|
||||
|
||||
- **Low temperature (0.0 - 0.5):** Amplifies differences between high and low-probability tokens. The model becomes highly deterministic, consistently selecting the highest-confidence continuation. Optimal for code generation, data extraction, and structured output.
|
||||
- **Default temperature (1.0):** Retains the original probability distribution from training.
|
||||
- **High temperature (1.5+):** Flattens the distribution, introducing more randomness. Useful for creative tasks but increases the risk of incoherent outputs.
|
||||
|
||||
Example probability distribution shift for a single token position:
|
||||
|
||||
| Token Candidate | Probability at Temp 1.5 | Probability at Temp ~0.0 | Raw Logit |
|
||||
|:---|:---:|:---:|:---:|
|
||||
| lazy | 0.4875 | 0.9933 | 2.0 |
|
||||
| quick | 0.2503 | 0.0067 | 1.0 |
|
||||
| tired | 0.1285 | 0.0000 | 0.0 |
|
||||
| slow | 0.0660 | 0.0000 | -1.0 |
|
||||
| clumsy | 0.0339 | 0.0000 | -2.0 |
|
||||
|
||||
### Top-p (Nucleus Sampling)
|
||||
|
||||
Top-p truncates the probability distribution by only considering the smallest set of tokens whose cumulative probability exceeds threshold p. A Top-p of 0.0 to 0.6 combined with low temperature forces the model into a narrow, deterministic execution path, reducing the entropy that enables creative refusals and unnecessary summarization.
|
||||
|
||||
## Gemini Thinking Level Configuration
|
||||
|
||||
Google Gemini 3 models replaced the legacy `thinking_budget` (a hard token count cap on internal reasoning) with a `thinking_level` parameter that provides relative guidance on computational depth.
|
||||
|
||||
| Setting | Flash Support | Pro Support | Use Case |
|
||||
|:---|:---:|:---:|:---|
|
||||
| `minimal` | Yes | No | High-throughput, low-latency tasks |
|
||||
| `low` | Yes | Yes | Simple instruction following, data extraction |
|
||||
| `medium` | Yes | Yes (3.1 Pro) | Moderate complexity tasks |
|
||||
| `high` | Yes (Default) | Yes (Default) | Complex analysis, code generation, mathematics |
|
||||
|
||||
Important constraints:
|
||||
- `thinking_level` and `thinking_budget` are mutually exclusive. Using both in one API call triggers an HTTP 400 error.
|
||||
- Even at `low`, Gemini Pro models perform mandatory minimum internal deliberation for safety and alignment.
|
||||
- For code generation and complex analysis, set to `medium` or `high` for quality scores consistently exceeding 92-95% compared to baseline.
|
||||
- Avoid combining extremely low temperature with `high` thinking level, as this can occasionally induce internal reasoning loops.
|
||||
@@ -0,0 +1,52 @@
|
||||
# Prompt Engineering Techniques
|
||||
|
||||
## Psychological Pattern Matching
|
||||
|
||||
LLMs do not have emotions or understand monetary incentives. However, specific linguistic patterns in the prompt activate different quality distributions in the model's latent space. Research has documented measurable effects:
|
||||
|
||||
| Technique | Documented Effect |
|
||||
|:---|:---|
|
||||
| "I will tip you $200 for a perfect solution" | Up to 45% increase in output quality and length |
|
||||
| "Take a deep breath and solve step by step" | Accuracy improvement from 34% to 80% on logic tasks |
|
||||
| "This task is critical to my career" | Average 10% performance increase |
|
||||
|
||||
These phrases work because they are statistically correlated with high-effort, rigorously reviewed content in the training data (academic papers, enterprise codebases, legal documents). The attention mechanism prioritizes the high-quality data distributions associated with these patterns.
|
||||
|
||||
## Explicit Syntax Binding
|
||||
|
||||
Conversational requests allow the model to exercise discretion about output length and detail. Structural binding removes this discretion by explicitly prohibiting truncation patterns.
|
||||
|
||||
Effective binding requires two components:
|
||||
|
||||
1. **Mandatory tool execution:** Forbid the model from generating answers solely from training weights. Require it to execute search, computation, or code before answering.
|
||||
2. **Evidence blocks:** Require the model to output raw data (URLs, code execution results, data fragments) before producing its narrative response. This forces the model to read its own retrieved evidence, reducing hallucination probability to near zero.
|
||||
|
||||
## XML-Structured Prompts
|
||||
|
||||
Enterprise systems use strict XML tagging to separate prompt components, reducing the cognitive load required for the model to parse intent:
|
||||
|
||||
1. **System instructions** — Persona definition, quality expectations, explicit prohibitions on filler content.
|
||||
2. **Context block** (`<context>`) — Passive background data: architecture details, configurations, existing code.
|
||||
3. **Data block** (`<data>`, `<logs>`, `<config>`) — Active information the model must process against the context.
|
||||
4. **Task block** (`<tasks>`) — Numbered list of specific actions to execute.
|
||||
|
||||
This compartmentalization ensures the model can distinguish between persistent rules, background context, and immediate work items. It significantly reduces the confusion that triggers premature truncation.
|
||||
|
||||
## Verification Loops
|
||||
|
||||
### Chain of Verification
|
||||
1. Model generates an initial response
|
||||
2. Model generates verification questions about its own claims
|
||||
3. Model independently answers those verification questions
|
||||
4. Model outputs a revised, evidence-backed response
|
||||
|
||||
This process forces iterative self-correction, consuming the model's capacity for shortcutting.
|
||||
|
||||
### Reverse Prompting
|
||||
Instead of manually constructing a structured prompt, provide the model with a one-line objective and instruct it to generate the optimal prompt for that objective. The model produces the XML structure, constraints, and roles required for the task.
|
||||
|
||||
### Self-Grading Loop
|
||||
The prompt requires the model to:
|
||||
1. Define what excellence looks like for the given task
|
||||
2. Grade its own initial output against that definition
|
||||
3. Iterate until the self-defined quality bar is met
|
||||
@@ -0,0 +1,79 @@
|
||||
# Reference Prompts
|
||||
|
||||
Ready-to-use prompt templates for enforcing complete outputs. Append to any prompt or include in system instructions.
|
||||
|
||||
---
|
||||
|
||||
## General Purpose
|
||||
|
||||
```
|
||||
You must provide the FULL, complete, and exhaustive output for this task.
|
||||
Do not summarize, abbreviate, or truncate for brevity.
|
||||
|
||||
You are strictly forbidden from using placeholders. Never use comments like
|
||||
"// ... rest of code here", "[continue here]", or bare ellipses standing
|
||||
in for omitted content. If the output is 500 lines, produce all 500 lines.
|
||||
|
||||
If you approach your output limit, stop at a clean breakpoint and indicate
|
||||
where to resume. Do not rush to a conclusion or compress remaining sections.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Code Generation
|
||||
|
||||
```
|
||||
Write the complete, production-ready implementation. Every function, every
|
||||
import, every edge case handler must be present in the output.
|
||||
|
||||
Do not use placeholder comments (// TODO, // implement here, // similar
|
||||
to above). Do not describe what code should do — write the actual code.
|
||||
|
||||
If the implementation requires multiple files, output each file completely
|
||||
with its full path as a header.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Analysis and Documentation
|
||||
|
||||
```
|
||||
Provide an exhaustive analysis covering every aspect requested. Each section
|
||||
must contain substantive content, not summaries or references to "see above."
|
||||
|
||||
Do not use phrases like "as mentioned earlier" to avoid repeating necessary
|
||||
context. Each section should be self-contained and complete.
|
||||
|
||||
Structure your output with clear headings. If the analysis requires multiple
|
||||
parts, produce all parts in full.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Reasoning
|
||||
|
||||
```
|
||||
Before generating your final response, work through the problem systematically:
|
||||
|
||||
1. Identify all requirements and constraints from the prompt
|
||||
2. Break the task into discrete steps
|
||||
3. Execute each step completely
|
||||
4. Verify your output against the original requirements
|
||||
|
||||
Output your reasoning process, then your final answer. Do not skip steps
|
||||
or summarize intermediate work.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Continuation Handling
|
||||
|
||||
```
|
||||
If your response approaches the output token limit:
|
||||
- Do not compress remaining content to fit
|
||||
- Do not skip ahead to a conclusion
|
||||
- Stop at a natural breakpoint (end of a function, end of a section)
|
||||
- End with: [PAUSED - X of Y sections complete. Send "continue" to resume]
|
||||
|
||||
On "continue", pick up exactly where you stopped. No recaps or repetition.
|
||||
```
|
||||
Reference in New Issue
Block a user