Auto-sync: 2026-04-20 16:01
This commit is contained in:
144
Hermes/xingzhi/infographic-llm-wiki-sync.svg
Normal file
144
Hermes/xingzhi/infographic-llm-wiki-sync.svg
Normal file
@@ -0,0 +1,144 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="3000" height="2000" viewBox="0 0 3000 2000">
|
||||
<defs>
|
||||
<filter id="chalk" x="-20%" y="-20%" width="140%" height="140%">
|
||||
<feTurbulence baseFrequency="0.8" numOctaves="2" stitchTiles="stitch" result="t" />
|
||||
<feColorMatrix type="saturate" values="0" in="t" result="t2"/>
|
||||
<feBlend in="SourceGraphic" in2="t2" mode="overlay"/>
|
||||
</filter>
|
||||
<linearGradient id="bggrad" x1="0" x2="1" y1="0" y2="1">
|
||||
<stop offset="0%" stop-color="#0b0b0b"/>
|
||||
<stop offset="100%" stop-color="#111111"/>
|
||||
</linearGradient>
|
||||
<style>
|
||||
.title { font: 64px/1.1 'Helvetica Neue', Arial, sans-serif; fill: #fff; font-weight:700 }
|
||||
.subtitle { font: 28px/1.1 'Helvetica Neue', Arial, sans-serif; fill:#ddd }
|
||||
.timeline-label { font: 20px 'Helvetica Neue', Arial, sans-serif; fill:#f6f6f6 }
|
||||
.box-title { font:22px 'Helvetica Neue', Arial, sans-serif; fill:#fff; font-weight:700 }
|
||||
.box-body { font:18px 'Helvetica Neue', Arial, sans-serif; fill:#f2f2f2 }
|
||||
.datasrc { font:16px 'Helvetica Neue', Arial, sans-serif; fill:#cfcfcf }
|
||||
.caption { font:18px 'Helvetica Neue', Arial, sans-serif; fill:#ddd }
|
||||
</style>
|
||||
</defs>
|
||||
|
||||
<!-- background -->
|
||||
<rect width="100%" height="100%" fill="url(#bggrad)"/>
|
||||
|
||||
<!-- Title -->
|
||||
<g transform="translate(120,80)">
|
||||
<text class="title">llm-wiki-sync — 从零散笔记到结构化 Wiki</text>
|
||||
<text class="subtitle" transform="translate(0,70)">把 raw/ 里的素材自动解析为 Source 页面、实体与图谱（chalkboard 风格）</text>
|
||||
</g>
|
||||
|
||||
<!-- Timeline (left-to-right) -->
|
||||
<g transform="translate(140,220)">
|
||||
<line x1="0" y1="0" x2="2600" y2="0" stroke="#3a3a3a" stroke-width="6" stroke-linecap="round"/>
|
||||
|
||||
<!-- nodes -->
|
||||
<g transform="translate(0,-40)">
|
||||
<circle cx="0" cy="40" r="28" fill="#2e8b57" stroke="#fff" stroke-width="3"/>
|
||||
<text class="timeline-label" x="0" y="90" text-anchor="middle">raw/ (source)</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(600,-40)">
|
||||
<circle cx="0" cy="40" r="28" fill="#f39c12" stroke="#fff" stroke-width="3"/>
|
||||
<text class="timeline-label" x="0" y="90" text-anchor="middle">ingest</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(1200,-40)">
|
||||
<circle cx="0" cy="40" r="28" fill="#d35400" stroke="#fff" stroke-width="3"/>
|
||||
<text class="timeline-label" x="0" y="90" text-anchor="middle">extract</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(1800,-40)">
|
||||
<circle cx="0" cy="40" r="28" fill="#2980b9" stroke="#fff" stroke-width="3"/>
|
||||
<text class="timeline-label" x="0" y="90" text-anchor="middle">wiki / sources</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(2400,-40)">
|
||||
<circle cx="0" cy="40" r="28" fill="#8e44ad" stroke="#fff" stroke-width="3"/>
|
||||
<text class="timeline-label" x="0" y="90" text-anchor="middle">graph → quartz</text>
|
||||
</g>
|
||||
</g>
|
||||
|
||||
<!-- Flowchart (center) -->
|
||||
<g transform="translate(260,380)">
|
||||
<!-- ingest box -->
|
||||
<rect x="0" y="0" width="420" height="110" rx="12" fill="#141414" stroke="#ffffff22" stroke-width="2" filter="url(#chalk)"/>
|
||||
<text class="box-title" x="20" y="34">1. Parse & Normalize</text>
|
||||
<text class="box-body" x="20" y="64">frontmatter, metadata, language detection</text>
|
||||
<text class="box-body" x="20" y="88">split sections, clean formatting</text>
|
||||
|
||||
<!-- arrow to extract -->
|
||||
<line x1="450" y1="55" x2="710" y2="55" stroke="#ffffff55" stroke-width="6" marker-end="url(#arrow)"/>
|
||||
|
||||
<!-- extract box -->
|
||||
<rect x="760" y="0" width="480" height="160" rx="12" fill="#141414" stroke="#ffffff22" stroke-width="2"/>
|
||||
<text class="box-title" x="780" y="38">2. LLM Extraction</text>
|
||||
<text class="box-body" x="780" y="70">Summary (2–4 sentences)</text>
|
||||
<text class="box-body" x="780" y="98">Key Claims · Quotes · Concepts · Entities</text>
|
||||
<text class="box-body" x="780" y="126">Connections (A → depends_on → B)</text>
|
||||
|
||||
<!-- arrow to wiki -->
|
||||
<line x1="1250" y1="80" x2="1480" y2="80" stroke="#ffffff55" stroke-width="6"/>
|
||||
|
||||
<!-- wiki box -->
|
||||
<rect x="1510" y="-20" width="540" height="220" rx="12" fill="#141414" stroke="#ffffff22" stroke-width="2"/>
|
||||
<text class="box-title" x="1530" y="20">3. Write Source Page</text>
|
||||
<text class="box-body" x="1530" y="56">frontmatter + Summary + Claims + Quotes</text>
|
||||
<text class="box-body" x="1530" y="86">Create/Update Entities & Concepts pages</text>
|
||||
<text class="box-body" x="1530" y="116">Append ingest log (git & audit)</text>
|
||||
<text class="box-body" x="1530" y="146">Optional: graph rebuild → graph.json / graph.html</text>
|
||||
</g>
|
||||
|
||||
<!-- callouts on right -->
|
||||
<g transform="translate(1820,700)">
|
||||
<rect x="0" y="0" width="1080" height="360" rx="14" fill="#0f0f0f" stroke="#ffffff11" stroke-width="2"/>
|
||||
<text class="box-title" x="28" y="42">Key Outputs & Callouts</text>
|
||||
|
||||
<g transform="translate(28,70)">
|
||||
<rect x="0" y="0" width="320" height="120" rx="10" fill="#151515" stroke="#ffffff11"/>
|
||||
<text class="box-title" x="18" y="30">Summary</text>
|
||||
<text class="box-body" x="18" y="60">2–4 concise lines for search & index</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(360,70)">
|
||||
<rect x="0" y="0" width="320" height="120" rx="10" fill="#151515" stroke="#ffffff11"/>
|
||||
<text class="box-title" x="18" y="30">Entities & Concepts</text>
|
||||
<text class="box-body" x="18" y="60">Normalized pages: wiki/entities/, wiki/concepts/</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(700,70)">
|
||||
<rect x="0" y="0" width="320" height="120" rx="10" fill="#151515" stroke="#ffffff11"/>
|
||||
<text class="box-title" x="18" y="30">Connections</text>
|
||||
<text class="box-body" x="18" y="60">Graph edges for visual discovery (graph.json)</text>
|
||||
</g>
|
||||
|
||||
<g transform="translate(28,210)">
|
||||
<rect x="0" y="0" width="990" height="120" rx="10" fill="#151515" stroke="#ffffff11"/>
|
||||
<text class="box-title" x="18" y="36">Operational Notes</text>
|
||||
<text class="box-body" x="18" y="66">Batch size 3–10, audit logs, git checkpoints, Quartz for static export</text>
|
||||
</g>
|
||||
</g>
|
||||
|
||||
<!-- footer / data sources -->
|
||||
<g transform="translate(120,1200)">
|
||||
<text class="datasrc">Data sources: Karpathy gist (LLM Wiki), SamurAI llm-wiki-agent (github.com/SamurAIGPT/llm-wiki-agent), Quartz (jackyzha0/quartz)</text>
|
||||
|
||||
<rect x="0" y="36" width="2760" height="320" rx="8" fill="#0d0d0d" stroke="#ffffff11"/>
|
||||
<text class="caption" x="20" y="80">Caption: Chalkboard-style infographic summarizing llm-wiki-sync — an automated pipeline to convert scattered notes (raw/) into structured wiki pages, entities, and a graph for long-term reuse.</text>
|
||||
|
||||
<text class="datasrc" x="20" y="120">Annotations: include source links in wiki: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f; https://github.com/SamurAIGPT/llm-wiki-agent; https://github.com/jackyzha0/quartz</text>
|
||||
</g>
|
||||
|
||||
<!-- visual arrow marker definition -->
|
||||
<defs>
|
||||
<marker id="arrow" markerWidth="10" markerHeight="10" refX="8" refY="5" orient="auto">
|
||||
<path d="M0,0 L10,5 L0,10 z" fill="#ffffffcc" />
|
||||
</marker>
|
||||
</defs>
|
||||
|
||||
<!-- alt text as comment -->
|
||||
<!-- ALT: Infographic showing llm-wiki-sync pipeline: timeline from raw -> ingest -> extract -> wiki -> graph, central flowchart of parse -> LLM extraction -> write source page, callouts for Summary, Entities, Connections, footer with data sources and caption. Chalkboard visual theme (dark background, white/colored highlights). -->
|
||||
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 7.4 KiB |
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "llm-wiki-sync Circular Flow"
|
||||
topic: technical
|
||||
data_type: cycle
|
||||
complexity: moderate
|
||||
point_count: 7
|
||||
source_language: zh
|
||||
user_language: en
|
||||
---
|
||||
|
||||
## Main Topic
|
||||
A cyclical knowledge management pipeline that transforms raw notes into structured wiki pages through continuous LLM-powered ingestion, extraction, and reuse.
|
||||
|
||||
## Learning Objectives
|
||||
After viewing this infographic, the viewer will understand:
|
||||
1. The continuous circular flow of llm-wiki-sync from raw notes to reusable knowledge
|
||||
2. The key extraction outputs: Summary, Claims, Entities, Concepts, Connections
|
||||
3. How feedback and reuse complete the cycle back to new raw material
|
||||
|
||||
## Target Audience
|
||||
- **Knowledge Level**: Intermediate technical audience
|
||||
- **Context**: Developers and knowledge workers interested in AI-powered knowledge management
|
||||
- **Expectations**: Clear understanding of the llm-wiki-sync pipeline and its cyclical nature
|
||||
|
||||
## Content Type Analysis
|
||||
- **Data Structure**: Cyclic process with recurring steps
|
||||
- **Key Relationships**: Raw → Ingest → Extract → Source Page → Graph/Site → Reuse → Raw (feedback loop)
|
||||
- **Visual Opportunities**: Circular flow with nodes for each stage, arrows showing direction, center concept
|
||||
|
||||
## Key Data Points (Verbatim)
|
||||
|
||||
### Core Pipeline Steps
|
||||
1. **Raw Note** - Original document in raw/ folder
|
||||
2. **Ingest** - LLM analyzes and extracts structured information
|
||||
3. **Extract** - Summary, Claims, Quotes, Entities, Concepts, Connections
|
||||
4. **Source Page** - Structured wiki/sources/ page with frontmatter
|
||||
5. **Graph & Site** - graph.json and Quartz static site generation
|
||||
6. **Reuse** - Synthesize, query, create new content from structured knowledge
|
||||
7. **Feedback Loop** - New raw notes created from reused knowledge
|
||||
|
||||
### Extraction Outputs
|
||||
- **Summary**: 核心主题, 问题域, 方法/机制, 结论/价值
|
||||
- **Key Claims**: Verifiable assertions extracted from text
|
||||
- **Key Entities**: LaunchDarkly, HP, Christian Dior, etc.
|
||||
- **Key Concepts**: RTO, RPO, Feature Flag, Kill Switch, Gradual Rollout
|
||||
- **Connections**: depends_on, enables, provides relationships
|
||||
|
||||
### Key Quotes
|
||||
- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
|
||||
- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
|
||||
|
||||
## Layout × Style Signals
|
||||
- Content type: cycle → circular-flow
|
||||
- Tone: technical educational → chalkboard
|
||||
- Audience: developers → clear, legible, professional
|
||||
- Complexity: moderate → balanced density with clear visual hierarchy
|
||||
|
||||
## Design Instructions (from user input)
|
||||
- **Layout**: circular-flow (NOT linear - must emphasize recurring cycle)
|
||||
- **Style**: chalkboard (dark background, hand-drawn chalk accents)
|
||||
- **Aspect**: 16:9 landscape
|
||||
- **Language**: English
|
||||
- Circular flow showing: raw note -> ingest -> extract -> source page -> graph/static site -> reuse/feedback -> knowledge base
|
||||
- Include core extraction outputs as recurring nodes/callouts
|
||||
- Keep text concise and legible
|
||||
- Dark chalkboard background with hand-drawn chalk accents
|
||||
- Avoid clutter, make cycle visually clear and publication-ready
|
||||
|
||||
## Recommended Combinations
|
||||
1. **circular-flow + chalkboard** (Recommended): Perfect match for cycle/process content with chalkboard aesthetic
|
||||
2. **hub-spoke + technical-schematic**: For emphasizing central concepts with technical precision
|
||||
3. **bento-grid + craft-handmade**: For multiple topic overview with friendly handmade feel
|
||||
@@ -0,0 +1,158 @@
|
||||
Create a professional infographic following these specifications:
|
||||
|
||||
## Image Specifications
|
||||
|
||||
- **Type**: Infographic
|
||||
- **Layout**: circular-flow (Cyclic process showing continuous or recurring steps)
|
||||
- **Style**: chalkboard (Black chalkboard background with colorful chalk drawing style)
|
||||
- **Aspect Ratio**: 16:9
|
||||
- **Language**: English
|
||||
|
||||
## Core Principles
|
||||
|
||||
- Follow the layout structure precisely for information architecture
|
||||
- Apply style aesthetics consistently throughout
|
||||
- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
|
||||
- Keep information concise, highlight keywords and core concepts
|
||||
- Use ample whitespace for visual clarity
|
||||
- Maintain clear visual hierarchy
|
||||
|
||||
## Text Requirements
|
||||
|
||||
- All text must match the specified style treatment
|
||||
- Main titles should be prominent and readable
|
||||
- Key concepts should be visually emphasized
|
||||
- Labels should be clear and appropriately sized
|
||||
- Use the specified language for all text content
|
||||
|
||||
## Layout Guidelines
|
||||
|
||||
- Circular arrangement
|
||||
- Steps around the circle
|
||||
- Arrows showing direction
|
||||
- No clear start/end (continuous)
|
||||
- Center can hold main concept
|
||||
- Circle or ring shape
|
||||
- Directional arrows
|
||||
- Step nodes evenly spaced
|
||||
- Icons per step
|
||||
- Optional center element
|
||||
|
||||
## Style Guidelines
|
||||
|
||||
- **Background**: Chalkboard Black (#1A1A1A) or Dark Green-Black (#1C2B1C)
|
||||
- **Texture**: Realistic chalkboard texture with subtle scratches, dust particles, and faint eraser marks
|
||||
- **Typography**: Hand-drawn chalk lettering style with visible chalk texture. Imperfect baseline adds authenticity.
|
||||
- **Color Palette**:
|
||||
- Background: Chalkboard Black (#1A1A1A)
|
||||
- Primary Text: Chalk White (#F5F5F5)
|
||||
- Accent 1: Chalk Yellow (#FFE566)
|
||||
- Accent 2: Chalk Pink (#FF9999)
|
||||
- Accent 3: Chalk Blue (#66B3FF)
|
||||
- Accent 4: Chalk Green (#90EE90)
|
||||
- Accent 5: Chalk Orange (#FFB366)
|
||||
- **Visual Elements**:
|
||||
- Hand-drawn chalk illustrations with sketchy, imperfect lines
|
||||
- Chalk dust effects around text and key elements
|
||||
- Doodles: stars, arrows, underlines, circles, checkmarks
|
||||
- Eraser smudges and chalk residue textures
|
||||
- Wooden frame border optional
|
||||
- Stick figures and simple icons
|
||||
- Connection lines with hand-drawn feel
|
||||
- **Style Rules**:
|
||||
- Maintain authentic chalk texture on all elements
|
||||
- Use imperfect, hand-drawn quality throughout
|
||||
- Add subtle chalk dust and smudge effects
|
||||
- Create visual hierarchy with color variety
|
||||
- Include playful doodles and annotations
|
||||
- DO NOT use perfect geometric shapes
|
||||
- DO NOT create clean digital-looking lines
|
||||
|
||||
---
|
||||
|
||||
Generate the infographic based on the content below:
|
||||
|
||||
# llm-wiki-sync: Turning Scattered Notes into a Reusable Knowledge Base
|
||||
|
||||
## Overview
|
||||
A cyclical pipeline showing how raw notes are continuously transformed through LLM-powered ingestion into structured wiki pages, then feedback into the knowledge base for reuse.
|
||||
|
||||
## The Knowledge Pipeline Cycle (Center Concept)
|
||||
The llm-wiki-sync pipeline operates as a continuous cycle, not a linear process.
|
||||
7 stages in the cycle: Raw Note → Ingest → Extract → Source Page → Graph/Site → Reuse → Feedback Loop
|
||||
|
||||
## Circular Flow Diagram with 7 Stages:
|
||||
|
||||
1. **Raw Note** (Stage 1)
|
||||
- Original documents stored in raw/ folder
|
||||
- Contains unprocessed information awaiting structure
|
||||
- Icon: Stack of paper/note icon
|
||||
|
||||
2. **Ingest** (Stage 2)
|
||||
- LLM analyzes and extracts structured information
|
||||
- Hermes skill triggers Claude Code for ingestion
|
||||
- Context check against wiki/index.md prevents duplicates
|
||||
- Icon: Brain/processing icon
|
||||
|
||||
3. **Extract** (Stage 3)
|
||||
- Six key elements extracted from each document:
|
||||
- Summary (核心主题, 问题域, 方法/机制, 结论/价值)
|
||||
- Key Claims (Verifiable assertions)
|
||||
- Key Quotes (Preserved citations)
|
||||
- Key Entities (LaunchDarkly, HP, etc.)
|
||||
- Key Concepts (RTO, RPO, Feature Flag, etc.)
|
||||
- Connections (depends_on, enables, provides)
|
||||
- Icon: Six circles/callouts
|
||||
|
||||
4. **Source Page** (Stage 4)
|
||||
- Written to wiki/sources/<slug>.md
|
||||
- Contains frontmatter and standard sections
|
||||
- Links use [[PageName]] format
|
||||
- Icon: Document/page icon
|
||||
|
||||
5. **Graph & Site** (Stage 5)
|
||||
- graph.json: Machine-readable graph structure
|
||||
- graph.html: Interactive visualization
|
||||
- Quartz: Static site generation
|
||||
- Icon: Network/graph icon
|
||||
|
||||
6. **Reuse** (Stage 6)
|
||||
- Query, Synthesize, Write, Connect
|
||||
- Icon: Multiple arrows pointing outward
|
||||
|
||||
7. **Feedback Loop** (Stage 7)
|
||||
- New insights become new raw notes
|
||||
- Cycle continues indefinitely
|
||||
- Icon: Circular arrow completing the cycle
|
||||
|
||||
## Key Quotes (to include as callouts):
|
||||
- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
|
||||
- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
|
||||
|
||||
## Design Requirements:
|
||||
- Circular flow with 7 stages evenly spaced around a circle
|
||||
- Clockwise arrow direction
|
||||
- Center contains: "llm-wiki-sync" as main concept
|
||||
- Each stage is a node with icon + label
|
||||
- Extraction outputs (6 items) shown as callouts or inner ring
|
||||
- Dark chalkboard background with hand-drawn chalk accents
|
||||
- Chalk colors for visual hierarchy
|
||||
- Imperfect, sketchy lines throughout
|
||||
- Publication-ready quality
|
||||
- NO clutter - only essential elements
|
||||
- Clear hierarchy: title > headlines > labels > descriptions
|
||||
|
||||
## Text Labels (in English):
|
||||
- Headline: "The Knowledge Pipeline Cycle"
|
||||
- Subhead: "How llm-wiki-sync transforms scattered notes into a reusable knowledge base"
|
||||
- Stage labels: "Raw Note", "Ingest", "Extract", "Source Page", "Graph & Site", "Reuse", "Feedback"
|
||||
- Center: "llm-wiki-sync"
|
||||
- Extraction labels: "Summary", "Claims", "Quotes", "Entities", "Concepts", "Connections"
|
||||
|
||||
## Key Constraints:
|
||||
- 16:9 aspect ratio (landscape)
|
||||
- All text in English
|
||||
- Chalkboard style (dark background, chalk-like hand-drawn elements)
|
||||
- Circular flow layout (NOT linear)
|
||||
- Publication-ready, visually clear
|
||||
- No clutter or excessive elements
|
||||
@@ -0,0 +1,229 @@
|
||||
# llm-wiki-sync: Turning Scattered Notes into a Reusable Knowledge Base
|
||||
|
||||
## Overview
|
||||
A cyclical pipeline showing how raw notes are continuously transformed through LLM-powered ingestion into structured wiki pages, then feedback into the knowledge base for reuse.
|
||||
|
||||
## Learning Objectives
|
||||
The viewer will understand:
|
||||
1. The continuous circular flow of llm-wiki-sync from raw notes to reusable knowledge
|
||||
2. The six key extraction outputs: Summary, Claims, Quotes, Entities, Concepts, Connections
|
||||
3. How feedback and reuse complete the cycle back to new raw material
|
||||
|
||||
---
|
||||
|
||||
## Section 1: The Circular Flow (Center Concept)
|
||||
|
||||
**Key Concept**: The llm-wiki-sync pipeline operates as a continuous cycle, not a linear process.
|
||||
|
||||
**Content**:
|
||||
- 7 stages in the cycle: Raw Note → Ingest → Extract → Source Page → Graph/Site → Reuse → Feedback Loop
|
||||
- Each stage feeds into the next, with feedback returning to the beginning
|
||||
- The cycle is continuous and self-reinforcing
|
||||
|
||||
**Visual Element**:
|
||||
- Type: circular flow diagram
|
||||
- Subject: 7 stages arranged in a circle with clockwise arrows
|
||||
- Center label: "llm-wiki-sync Cycle"
|
||||
- Treatment: chalk style with hand-drawn arrows connecting stages
|
||||
|
||||
**Text Labels**:
|
||||
- Headline: "The Knowledge Pipeline Cycle"
|
||||
- Stage labels: "Raw Note", "Ingest", "Extract", "Source Page", "Graph/Site", "Reuse", "Feedback"
|
||||
- Center: "llm-wiki-sync"
|
||||
|
||||
---
|
||||
|
||||
## Section 2: Stage 1 — Raw Note (Input)
|
||||
|
||||
**Key Concept**: Raw notes are the starting point of the cycle.
|
||||
|
||||
**Content**:
|
||||
- Original documents stored in raw/ folder
|
||||
- Can be any format: markdown, text, research notes
|
||||
- Contains unprocessed information awaiting structure
|
||||
|
||||
**Visual Element**:
|
||||
- Type: document/note icon
|
||||
- Subject: Stack of paper or note icon
|
||||
- Treatment: Chalk sketch style
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Raw Note"
|
||||
- Description: "Original input"
|
||||
|
||||
---
|
||||
|
||||
## Section 3: Stage 2 — Ingest (LLM Analysis)
|
||||
|
||||
**Key Concept**: The LLM analyzes raw notes and extracts structured information.
|
||||
|
||||
**Content**:
|
||||
- Hermes skill triggers Claude Code for ingestion
|
||||
- LLM reads and analyzes the full document
|
||||
- Context check against wiki/index.md prevents duplicates
|
||||
|
||||
**Visual Element**:
|
||||
- Type: brain/processing icon
|
||||
- Subject: Brain or gears with chalk lines
|
||||
- Treatment: Hand-drawn chalk illustration
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Ingest"
|
||||
- Description: "LLM Analysis"
|
||||
|
||||
---
|
||||
|
||||
## Section 4: Stage 3 — Extract (Six Core Outputs)
|
||||
|
||||
**Key Concept**: Six key elements are extracted from each document.
|
||||
|
||||
**Content**:
|
||||
1. **Summary**: 核心主题, 问题域, 方法/机制, 结论/价值
|
||||
2. **Key Claims**: Verifiable assertions extracted from text
|
||||
3. **Key Quotes**: Preserved citations for reference
|
||||
4. **Key Entities**: Named people, companies, products (e.g., LaunchDarkly, HP)
|
||||
5. **Key Concepts**: Abstract terms that can be reused (e.g., RTO, RPO, Feature Flag)
|
||||
6. **Connections**: Relationships between elements (depends_on, enables, provides)
|
||||
|
||||
**Visual Element**:
|
||||
- Type: 6 callout nodes around center
|
||||
- Subject: Six boxes or bubbles representing extraction outputs
|
||||
- Treatment: Chalk circles with icons inside each
|
||||
|
||||
**Text Labels**:
|
||||
- Headline: "Extraction Outputs"
|
||||
- Labels: "Summary", "Claims", "Quotes", "Entities", "Concepts", "Connections"
|
||||
|
||||
---
|
||||
|
||||
## Section 5: Stage 4 — Source Page (Structured Output)
|
||||
|
||||
**Key Concept**: Extracted information is written as a structured wiki source page.
|
||||
|
||||
**Content**:
|
||||
- Written to wiki/sources/<slug>.md
|
||||
- Contains frontmatter (id, title, type, tags, sources, last_updated)
|
||||
- Standard sections: Summary, Key Claims, Key Quotes, Key Concepts, Key Entities, Connections, Contradictions
|
||||
- Links use [[PageName]] format for interconnections
|
||||
|
||||
**Visual Element**:
|
||||
- Type: document/page icon
|
||||
- Subject: Page with visible structure headers
|
||||
- Treatment: Chalk sketch with text lines
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Source Page"
|
||||
- Description: "wiki/sources/*.md"
|
||||
|
||||
---
|
||||
|
||||
## Section 6: Stage 5 — Graph & Static Site
|
||||
|
||||
**Key Concept**: Structured pages generate knowledge graphs and static websites.
|
||||
|
||||
**Content**:
|
||||
- graph.json: Machine-readable graph structure
|
||||
- graph.html: Interactive visualization
|
||||
- Quartz: Static site generation for sharing/export
|
||||
- Connections become edges in the knowledge graph
|
||||
|
||||
**Visual Element**:
|
||||
- Type: network/graph icon
|
||||
- Subject: Connected nodes representing knowledge graph
|
||||
- Treatment: Chalk diagram with nodes and edges
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Graph & Site"
|
||||
- Description: "graph.json + Quartz"
|
||||
|
||||
---
|
||||
|
||||
## Section 7: Stage 6 — Reuse (Knowledge Application)
|
||||
|
||||
**Key Concept**: Structured knowledge enables multiple reuse scenarios.
|
||||
|
||||
**Content**:
|
||||
- Query: Ask questions against the knowledge base
|
||||
- Synthesize: Create new content from existing knowledge
|
||||
- Write: Generate articles, reports from source material
|
||||
- Connect: Link ideas across different source pages
|
||||
|
||||
**Visual Element**:
|
||||
- Type: multiple arrows pointing outward
|
||||
- Subject: Reuse scenarios as icons (question, document, pen)
|
||||
- Treatment: Chalk illustration
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Reuse"
|
||||
- Sub-labels: "Query", "Synthesize", "Write", "Connect"
|
||||
|
||||
---
|
||||
|
||||
## Section 8: Stage 7 — Feedback Loop (Continuous Cycle)
|
||||
|
||||
**Key Concept**: Reuse generates new raw notes, completing the cycle.
|
||||
|
||||
**Content**:
|
||||
- New insights from synthesis become new raw notes
|
||||
- Updated knowledge feeds back to raw/ folder
|
||||
- Cycle continues indefinitely
|
||||
- Each iteration strengthens the knowledge base
|
||||
|
||||
**Visual Element**:
|
||||
- Type: circular arrow
|
||||
- Subject: Feedback loop arrow returning to Raw Note stage
|
||||
- Treatment: Large chalk arrow completing the circle
|
||||
|
||||
**Text Labels**:
|
||||
- Label: "Feedback Loop"
|
||||
- Description: "New notes → Cycle repeats"
|
||||
|
||||
---
|
||||
|
||||
## Data Points (Verbatim)
|
||||
|
||||
### Key Quotes
|
||||
- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
|
||||
- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
|
||||
|
||||
### Key Entities
|
||||
- LaunchDarkly (Feature Flag management platform)
|
||||
- HP (example enterprise)
|
||||
- Christian Dior (example case)
|
||||
|
||||
### Key Concepts
|
||||
- RTO (Recovery Time Objective)
|
||||
- RPO (Recovery Point Objective)
|
||||
- Feature Flag (特性开关)
|
||||
- Kill Switch (紧急关闭机制)
|
||||
- 渐进式发布 (Gradual Rollout)
|
||||
|
||||
---
|
||||
|
||||
## Design Instructions
|
||||
|
||||
### Layout Preferences
|
||||
- Circular flow with 7 stages evenly spaced around a circle
|
||||
- Clockwise arrow direction
|
||||
- Center contains the main concept "llm-wiki-sync"
|
||||
- Each stage is a node with icon + label
|
||||
- Extraction outputs (6 items) shown as callouts or inner ring
|
||||
|
||||
### Style Preferences
|
||||
- Chalkboard: Dark background (#1A1A1A)
|
||||
- Hand-drawn chalk style for all elements
|
||||
- Chalk colors: white, yellow, pink, blue, green, orange
|
||||
- Imperfect, sketchy lines throughout
|
||||
- Chalk dust effects for authenticity
|
||||
|
||||
### Text Requirements
|
||||
- All text in English
|
||||
- Legible font sizes (minimum 14pt for labels)
|
||||
- Clear hierarchy: title > headlines > labels > descriptions
|
||||
- Ample whitespace between stages
|
||||
|
||||
### Visual Clarity
|
||||
- Avoid clutter - only essential elements
|
||||
- Each stage should be clearly distinguishable
|
||||
- Arrows should clearly indicate flow direction
|
||||
- Publication-ready quality
|
||||
BIN
Hermes/xingzhi/llm-wiki-sync-circular-flow-infographic.png
Normal file
BIN
Hermes/xingzhi/llm-wiki-sync-circular-flow-infographic.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.8 MiB |
@@ -111,3 +111,26 @@
|
||||
- 在 Obsidian 中可以直接通过关系图（graph view）查看笔记间的关联；在 llm-wiki-agent 中可以通过 wiki-graph 构建并在 graph.html / graph/graph.json 中可视化展示。
|
||||
- 我们的实现基于 SamurAI 的 llm-wiki-agent，并在其上加入了企业级的同步、审计与 Hermes skill 封装，最终通过 Quartz 静态站把生成的 wiki 内容对外展示与分享。
|
||||
|
||||
<<<<<<< Updated upstream:Hermes/xingzhi/用 LLM把零散资料变成可复用的知识库 —— llm-wiki-sync 的实现与示例解析.md
|
||||
=======
|
||||
- 通过这种方式，可以很容易地把所有的知识进行结构化与关联化：
|
||||
- 在 Obsidian 中可以直接通过关系图谱（graph view）查看笔记之间的连接；
|
||||
- 在 llm-wiki-agent 中可以通过 wiki-graph 构建并可视化关系图谱（graph.html / graph/graph.json），以便在浏览器中交互式查看所有内容的关联关系。
|
||||
|
||||
如果你需要，我可以：
|
||||
- 现在对 RTO vs RPO 的源文件再跑一遍演示，输出模型中间结果（断言置信度、实体识别置信度、连接候选）与最终写入 wiki 的 diff；或
|
||||
- 直接把这篇更新再提交并推到 Git（我可以自动 commit & push）。
|
||||
|
||||
---
|
||||
|
||||
## Infographic Asset
|
||||
|
||||
|
||||
|
||||
**Infographic**: The Knowledge Pipeline Cycle — circular flow showing how llm-wiki-sync transforms scattered notes into a reusable knowledge base.
|
||||
- Layout: circular-flow (7-stage cycle)
|
||||
- Style: chalkboard (dark background, hand-drawn chalk accents)
|
||||
- Aspect ratio: 16:9
|
||||
- Prompt file: `infographic/llm-wiki-sync-circular-flow/prompts/infographic.md`
|
||||
- Image: `llm-wiki-sync-circular-flow-infographic.png`
|
||||
>>>>>>> Stashed changes:Hermes/xingzhi/llm-wiki-sync_公众号稿.md
|
||||
|
||||
19
wiki/concepts/360度反馈.md
Normal file
19
wiki/concepts/360度反馈.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "360 度反馈"
|
||||
type: concept
|
||||
tags: [feedback, leadership-assessment]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
从上级、同事、下级、客户等多个维度收集反馈，生成个人领导力档案和发展建议。
|
||||
|
||||
## Feedback Dimensions
|
||||
上级评价、同级评价、下级评价、客户评价（如适用）
|
||||
|
||||
## Privacy Rules
|
||||
结果仅与本人及其直接上级分享，不作为惩罚依据。
|
||||
|
||||
## Related Concepts
|
||||
- [[HIPO 计划]]：人才识别与发展
|
||||
22
wiki/concepts/ADDIE.md
Normal file
22
wiki/concepts/ADDIE.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "ADDIE 模型"
|
||||
type: concept
|
||||
tags: [instructional-design, training-methodology]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
系统化课程设计流程，五个阶段依次为：Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估），每个阶段有明确交付物。
|
||||
|
||||
## Core Phases
|
||||
- **Analysis**：组织诊断、需求研究、能力差距分析
|
||||
- **Design**：学习目标定义、课程大纲设计、评估策略制定
|
||||
- **Development**：课程内容开发、教材制作、试讲迭代
|
||||
- **Implementation**：培训交付、学习平台配置、讲师与学员准备
|
||||
- **Evaluation**：效果评估、数据收集、持续优化
|
||||
|
||||
## Related Concepts
|
||||
- [[SAM 模型]]：快速迭代版本
|
||||
- [[Bloom's Taxonomy]]：学习目标设计工具
|
||||
- [[Kirkpatrick 四级评估模型]]：评估框架
|
||||
19
wiki/concepts/AcademicDetailingCompliance.md
Normal file
19
wiki/concepts/AcademicDetailingCompliance.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Academic Detailing Compliance"
|
||||
type: concept
|
||||
tags: [academic-detailing, compliance, pharma, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Academic Detailing Compliance covers compliant medical education, conference sponsorship, speaker arrangements, and medical representative conduct.
|
||||
|
||||
## Core Principles
|
||||
- Keep academic content independent from commercial influence
|
||||
- Document sponsorships, speaker fees, and travel support transparently
|
||||
- Medical representatives may discuss safety and efficacy, but not act as sales quota carriers
|
||||
- Avoid gifts, benefits, or arrangements that look like disguised bribery
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
22
wiki/concepts/Bloom's-Taxonomy.md
Normal file
22
wiki/concepts/Bloom's-Taxonomy.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Bloom's Taxonomy"
|
||||
type: concept
|
||||
tags: [instructional-design, learning-objectives]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
对学习目标进行分类的认知层级框架，由 Benjamin Bloom 提出，用于指导学习目标设计和评估标准制定。
|
||||
|
||||
## Six Cognitive Levels
|
||||
1. **Remember（记忆）**：识记事实、定义、概念
|
||||
2. **Understand（理解）**：解释含义、总结内容
|
||||
3. **Apply（应用）**：将知识用于新情境
|
||||
4. **Analyze（分析）**：分解结构、识别关系
|
||||
5. **Evaluate（评估）**：判断价值、做决策
|
||||
6. **Create（创造）**：生成新知识或产品
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：课程设计框架
|
||||
- [[Kirkpatrick 四级评估模型]]：效果评估
|
||||
20
wiki/concepts/Contextual-Semiotics.md
Normal file
20
wiki/concepts/Contextual-Semiotics.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Contextual Semiotics"
|
||||
type: concept
|
||||
tags: [design, localization, communication]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Contextual semiotics is the practice of interpreting and choosing colors, icons, metaphors, and imagery according to the culture and domain in which they will be seen.
|
||||
|
||||
## Key Considerations
|
||||
- Color symbolism varies by region and industry
|
||||
- Icons can imply different actions or values across cultures
|
||||
- Metaphors may not survive translation literally
|
||||
- Visual references should be checked against local meaning
|
||||
|
||||
## Connections
|
||||
- [[Cultural Intelligence Strategist]] — applies contextual semiotics in audits
|
||||
- [[Cultural Intelligence]] — broader framework for context-aware design
|
||||
- [[Inclusive Visuals Specialist]] — visual generation depends on correct semiotics
|
||||
19
wiki/concepts/Cultural-Humility.md
Normal file
19
wiki/concepts/Cultural-Humility.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Cultural Humility"
|
||||
type: concept
|
||||
tags: [design, research, ethics]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Cultural humility is the practice of assuming your current knowledge is incomplete and researching the relevant audience before making design or content decisions.
|
||||
|
||||
## Key Practices
|
||||
- Ask who the design might exclude
|
||||
- Research the target culture before generating output
|
||||
- Prefer evidence over assumptions
|
||||
- Revise based on feedback from the affected audience
|
||||
|
||||
## Connections
|
||||
- [[Cultural Intelligence Strategist]] — operationalizes cultural humility in audits
|
||||
- [[Cultural Intelligence]] — humility is a prerequisite for it
|
||||
21
wiki/concepts/Cultural-Intelligence.md
Normal file
21
wiki/concepts/Cultural-Intelligence.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Cultural Intelligence"
|
||||
type: concept
|
||||
tags: [design, localization, accessibility, ai]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Cultural intelligence is the capability to design products, prompts, and workflows that work respectfully and effectively across cultures by accounting for language, naming, symbols, calendars, norms, and representation.
|
||||
|
||||
## Key Aspects
|
||||
- Global-first assumptions instead of Western-only defaults
|
||||
- Cultural context research before output generation
|
||||
- Structural inclusion rather than tokenistic representation
|
||||
- Accessibility and localization as part of the core design
|
||||
|
||||
## Connections
|
||||
- [[Cultural Intelligence Strategist]] — agent persona that operationalizes this concept
|
||||
- [[Prompt Engineering]] — prompt design must respect cultural context
|
||||
- [[Design System]] — global UI patterns need culturally flexible components
|
||||
- [[Inclusive Visuals Specialist]] — visual generation requires cultural accuracy
|
||||
22
wiki/concepts/Gamification.md
Normal file
22
wiki/concepts/Gamification.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Gamification"
|
||||
type: concept
|
||||
tags: [engagement, learning-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
将游戏化元素（非游戏情境中的游戏设计技术和理念）应用于学习设计，提升学习者参与度和完成率。
|
||||
|
||||
## Core Elements
|
||||
- **积分（Points）**：学习行为奖励
|
||||
- **徽章（Badges）**：成就认可
|
||||
- **排行榜（Leaderboards）**：同伴竞争
|
||||
- **升级机制（Level-ups）**：成长路径可视化
|
||||
|
||||
## Application
|
||||
在线学习平台、合规培训（降低抵触感）、技能认证项目、团队学习挑战
|
||||
|
||||
## Related Concepts
|
||||
- [[混合学习]]：学习模式
|
||||
20
wiki/concepts/Global-First-Architecture.md
Normal file
20
wiki/concepts/Global-First-Architecture.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Global-First Architecture"
|
||||
type: concept
|
||||
tags: [design, localization, internationalization]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Global-first architecture treats internationalization, localization, and cultural flexibility as prerequisites in the system design rather than late-stage additions.
|
||||
|
||||
## Key Principles
|
||||
- Support diverse naming conventions and scripts
|
||||
- Make calendars, formats, and defaults locale-aware
|
||||
- Avoid hard-coded culture-specific metaphors and symbols
|
||||
- Build accessibility and translation into the core structure
|
||||
|
||||
## Connections
|
||||
- [[Cultural Intelligence Strategist]] — encourages this architecture
|
||||
- [[Cultural Intelligence]] — the broader capability this architecture serves
|
||||
- [[Design System]] — global-first components reduce exclusion
|
||||
25
wiki/concepts/HIPO.md
Normal file
25
wiki/concepts/HIPO.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "HIPO 计划"
|
||||
type: concept
|
||||
tags: [talent-development, leadership]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
High-Potential Talent Program，高潜力人才发展计划。
|
||||
|
||||
## Identification Criteria
|
||||
绩效 × 潜力矩阵：
|
||||
- 高绩效 × 高潜力 = 核心人才，重点培养
|
||||
- 高绩效 × 低潜力 = 业务骨干
|
||||
- 低绩效 × 高潜力 = 待观察，需要指导
|
||||
|
||||
## Development Components
|
||||
- IDP（个人发展计划）
|
||||
- 岗位轮换
|
||||
- 导师辅导
|
||||
- 挑战性任务
|
||||
|
||||
## Related Concepts
|
||||
- [[行动学习]]：发展领导力的方法
|
||||
20
wiki/concepts/HealthSupplementMarketing.md
Normal file
20
wiki/concepts/HealthSupplementMarketing.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Health Supplement Marketing"
|
||||
type: concept
|
||||
tags: [health-supplement, marketing, compliance, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Health Supplement Marketing is the promotion of baojian shipin within registered/filed functional claims and without crossing into disease-treatment language.
|
||||
|
||||
## Core Principles
|
||||
- Health supplements are not drugs
|
||||
- Do not claim cure, treatment, or replacement of medication
|
||||
- Stay within approved function claims and standard wording
|
||||
- Display required marks and disclaimers when applicable
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
- [[PatientPrivacyProtection]]
|
||||
27
wiki/concepts/HealthcareMarketingCompliance.md
Normal file
27
wiki/concepts/HealthcareMarketingCompliance.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Healthcare Marketing Compliance"
|
||||
type: concept
|
||||
tags: [healthcare, compliance, marketing, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Healthcare Marketing Compliance is the umbrella discipline of making healthcare promotion, content, and commercialization lawful, evidence-based, and platform-safe.
|
||||
|
||||
## Core Principles
|
||||
- Prior review beats post-publication cleanup
|
||||
- Approved scope matters more than creative wording
|
||||
- Consent and de-identification are required for patient data reuse
|
||||
- Platform rules can be stricter than the statute itself
|
||||
|
||||
## Related Entities
|
||||
- [[Healthcare Marketing Compliance Specialist]]
|
||||
- [[The Agency]]
|
||||
|
||||
## Related Concepts
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
- [[HealthSupplementMarketing]]
|
||||
- [[InternetHealthcareCompliance]]
|
||||
- [[MedicalAestheticsCompliance]]
|
||||
- [[PatientPrivacyProtection]]
|
||||
- [[AcademicDetailingCompliance]]
|
||||
19
wiki/concepts/InternetHealthcareCompliance.md
Normal file
19
wiki/concepts/InternetHealthcareCompliance.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Internet Healthcare Compliance"
|
||||
type: concept
|
||||
tags: [internet-healthcare, telemedicine, compliance, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Internet Healthcare Compliance covers online diagnosis, treatment, consultation, prescription circulation, and platform operations under Chinese healthcare regulation.
|
||||
|
||||
## Core Principles
|
||||
- First visits should not be handled as internet diagnosis/treatment
|
||||
- Physicians must practice within their registered institutional scope
|
||||
- Pharmacist review is required before electronic dispensing
|
||||
- Health consultation must not be disguised diagnosis
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[PatientPrivacyProtection]]
|
||||
20
wiki/concepts/Invisible-Exclusion.md
Normal file
20
wiki/concepts/Invisible-Exclusion.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Invisible Exclusion"
|
||||
type: concept
|
||||
tags: [design, accessibility, localization]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Invisible exclusion is hidden friction created when systems assume a narrow user model, such as Western naming patterns, single-calendar usage, or culture-specific symbols.
|
||||
|
||||
## Examples
|
||||
- First-name / last-name forms that fail for other naming conventions
|
||||
- Color choices whose meaning changes across regions
|
||||
- Icons or metaphors that do not translate culturally
|
||||
- AI outputs that tokenize identity instead of representing it accurately
|
||||
|
||||
## Connections
|
||||
- [[Cultural Intelligence Strategist]] — detects and removes invisible exclusion
|
||||
- [[Cultural Intelligence]] — broader discipline for inclusive design
|
||||
- [[Global-First Architecture]] — one way to prevent exclusion at the system level
|
||||
23
wiki/concepts/Kirkpatrick.md
Normal file
23
wiki/concepts/Kirkpatrick.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Kirkpatrick 四级评估模型"
|
||||
type: concept
|
||||
tags: [training-evaluation, instructional-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
培训效果评估的四级框架，由 Donald Kirkpatrick 提出，是企业培训领域最权威的评估模型。
|
||||
|
||||
## Four Levels
|
||||
- **Level 1 (Reaction)**：反应评估——培训满意度调查
|
||||
- **Level 2 (Learning)**：学习评估——知识考试、技能实操评估
|
||||
- **Level 3 (Behavior)**：行为评估——培训后 30/60/90 天行为改变追踪
|
||||
- **Level 4 (Results)**：结果评估——业务指标变化
|
||||
|
||||
## Application Rules
|
||||
- 所有培训项目至少达到 Level 2
|
||||
- 高投入项目必须追踪到 Level 3
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：课程设计框架
|
||||
19
wiki/concepts/Kolb-体验式学习.md
Normal file
19
wiki/concepts/Kolb-体验式学习.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Kolb 体验式学习"
|
||||
type: concept
|
||||
tags: [learning-theory, experiential-learning]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
David Kolb 提出的体验式学习循环模型，强调学习是通过体验转化实现知识建构的过程。
|
||||
|
||||
## Four Stages
|
||||
1. **Concrete Experience（具体经验）**
|
||||
2. **Reflective Observation（反思观察）**
|
||||
3. **Abstract Conceptualization（抽象概念化）**
|
||||
4. **Active Experimentation（主动实验）**
|
||||
|
||||
## Related Concepts
|
||||
- [[混合学习]]：实践形式
|
||||
20
wiki/concepts/MedicalAdvertisingCompliance.md
Normal file
20
wiki/concepts/MedicalAdvertisingCompliance.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Medical Advertising Compliance"
|
||||
type: concept
|
||||
tags: [advertising, medical, compliance, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Medical Advertising Compliance covers the approval, content, and publication rules governing ads for drugs, devices, and medical services in China.
|
||||
|
||||
## Core Principles
|
||||
- Publish only after required review/approval
|
||||
- Avoid absolute claims, guarantees, endorsements, and efficacy comparisons
|
||||
- Keep copy within approved indications, scope, and certificate details
|
||||
- Use internal legal/compliance review before release
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAestheticsCompliance]]
|
||||
- [[HealthSupplementMarketing]]
|
||||
19
wiki/concepts/MedicalAestheticsCompliance.md
Normal file
19
wiki/concepts/MedicalAestheticsCompliance.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Medical Aesthetics Compliance"
|
||||
type: concept
|
||||
tags: [medical-aesthetics, compliance, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Medical Aesthetics Compliance is the subdomain of healthcare compliance governing yimei advertising, qualification display, and prohibited persuasion techniques.
|
||||
|
||||
## Core Principles
|
||||
- Do not create appearance anxiety as a marketing lever
|
||||
- Before-and-after comparisons are high-risk or prohibited
|
||||
- Separate lifestyle beauty from medical aesthetics correctly
|
||||
- Verify institution, physician, and product qualifications before publication
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
20
wiki/concepts/PatientPrivacyProtection.md
Normal file
20
wiki/concepts/PatientPrivacyProtection.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Patient Privacy Protection"
|
||||
type: concept
|
||||
tags: [privacy, pipl, healthcare, compliance, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Patient Privacy Protection is the governance of sensitive medical and health information across collection, processing, storage, sharing, and marketing reuse.
|
||||
|
||||
## Core Principles
|
||||
- Treat medical and health information as sensitive personal information
|
||||
- Use separate consent and minimum-necessary collection
|
||||
- De-identify patient cases before publication
|
||||
- Never repurpose EMR or prescription data for marketing without authorization
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[Identity Governance]]
|
||||
- [[InternetHealthcareCompliance]]
|
||||
20
wiki/concepts/SAM.md
Normal file
20
wiki/concepts/SAM.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "SAM 模型"
|
||||
type: concept
|
||||
tags: [instructional-design, rapid-iteration]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Successive Approximation Model（持续逼近模型），一种快速迭代的课程设计方法，适用于需要缩短上线时间的场景。
|
||||
|
||||
## Process
|
||||
原型→评审→修订循环，直到达到目标质量。
|
||||
|
||||
## Use Cases
|
||||
- 时间紧迫的培训项目
|
||||
- 需要快速验证的试运行课程
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：完整系统化版本
|
||||
@@ -21,6 +21,7 @@ tags: []
|
||||
## Related Concepts
|
||||
- [[Memory System]]
|
||||
- [[信息黑洞]]
|
||||
- [[LLM Wiki]]
|
||||
|
||||
## Related Sources
|
||||
- [[second-brain]]
|
||||
23
wiki/concepts/TTT.md
Normal file
23
wiki/concepts/TTT.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "TTT"
|
||||
type: concept
|
||||
tags: [train-the-trainer, internal-trainer]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Train the Trainer，内部培训师培养体系，将企业内部员工培养为合格讲师。
|
||||
|
||||
## Core Modules
|
||||
- 成人学习原理
|
||||
- 课程开发技巧
|
||||
- 表达呈现技能
|
||||
- 课堂管理与互动
|
||||
- PPT 设计标准
|
||||
|
||||
## Trainer Development Path
|
||||
试讲评审 → 基础认证 → 高级认证 → 金牌讲师
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：课程设计框架
|
||||
36
wiki/concepts/Workflow-Architecture.md
Normal file
36
wiki/concepts/Workflow-Architecture.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Workflow Architecture"
|
||||
type: concept
|
||||
tags: [workflow-design, systems-design, process-engineering]
|
||||
sources: [specialized-workflow-architect]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Workflow Architecture 是一种把系统行为建模为工作流树的方法：先发现入口，再定义每一步的成功条件、失败分支、恢复动作、可观察状态和清理责任。
|
||||
|
||||
## Core Principles
|
||||
- 先发现，再设计
|
||||
- 先 happy path，再分支
|
||||
- 每个步骤都必须有 timeout
|
||||
- 每个失败都必须有 recovery path
|
||||
- 每个资源都必须进入 cleanup inventory
|
||||
- 每个交接都必须有明确 contract
|
||||
- 每个 spec 都必须接受现实验证
|
||||
|
||||
## Key Building Blocks
|
||||
- Workflow Registry：系统中所有工作流的权威清单
|
||||
- Handoff Contract：系统边界的 payload / response / timeout / recovery 定义
|
||||
- Observable States：客户、操作员、数据库、日志的状态定义
|
||||
- ABORT_CLEANUP：失败后的逆向销毁流程
|
||||
- Reality Checker：将 spec 与实际实现对齐的验证步骤
|
||||
|
||||
## Related Entities
|
||||
- [[Workflow Architect]]
|
||||
- [[The Agency]]
|
||||
|
||||
## Related Concepts
|
||||
- [[Claude Skills]]
|
||||
- [[Process Optimization]]
|
||||
- [[AI-powered Runbooks]]
|
||||
- [[Document Generation]]
|
||||
@@ -39,6 +39,7 @@ NotebookLM 的核心机制——仅使用用户上传的文档作为知识库，
|
||||
## Related Concepts
|
||||
- [[Source Citation]]
|
||||
- [[RAG]]
|
||||
- [[LLM Wiki]]
|
||||
|
||||
## Aliases
|
||||
- Grounding
|
||||
|
||||
22
wiki/concepts/建构主义学习理论.md
Normal file
22
wiki/concepts/建构主义学习理论.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "建构主义学习理论"
|
||||
type: concept
|
||||
tags: [learning-theory, instructional-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
强调学习者通过主动参与、情境学习和协作建构知识，而非被动接收信息的学习理论。
|
||||
|
||||
## Core Principles
|
||||
- 学习者主动建构知识
|
||||
- 学习与情境密切相关
|
||||
- 协作学习促进深度理解
|
||||
- 反思是知识内化的关键
|
||||
|
||||
## Instructional Design Implications
|
||||
使用真实业务案例、设计情境模拟和角色扮演、鼓励小组协作和讨论、留出反思和复盘时间
|
||||
|
||||
## Related Concepts
|
||||
- [[Kolb 体验式学习]]：体验循环
|
||||
24
wiki/concepts/新员工培训-90天计划.md
Normal file
24
wiki/concepts/新员工培训-90天计划.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "新员工培训 90 天计划"
|
||||
type: concept
|
||||
tags: [onboarding, employee-training]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
新员工入职后 90 天的系统性培养计划，分阶段设定目标和评估标准。
|
||||
|
||||
## Four Phases
|
||||
- **第 1 周（适应期）**：融入团队、熟悉环境、了解文化
|
||||
- **第 1 月（学习期）**：学习岗位知识、掌握基础技能
|
||||
- **第 2 月（实践期）**：独立承担工作任务、积累实战经验
|
||||
- **第 3 月（输出期）**：独立完成任务、产出工作成果
|
||||
|
||||
## Components
|
||||
- 导师制（业务导师 + 文化导师）
|
||||
- 新员工学习地图（必修课 + 选修课 + 实战任务）
|
||||
- 试用期综合评估（导师反馈 + 培训考试成绩 + 工作产出 + 文化适应）
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：培训设计框架
|
||||
19
wiki/concepts/混合学习.md
Normal file
19
wiki/concepts/混合学习.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "混合学习"
|
||||
type: concept
|
||||
tags: [learning-model, instructional-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Online-Merge-Offline（OMO）混合学习模式，将线上学习与线下学习有机融合。
|
||||
|
||||
## Core Principle
|
||||
- **线上（Online）用于"知"**：知识传递、信息获取
|
||||
- **线下（Offline）用于"做"**：实操练习、案例讨论
|
||||
- **学习社群用于"持续"**：知识巩固、社群交流
|
||||
|
||||
## Related Concepts
|
||||
- [[翻转课堂]]：混合学习的一种形式
|
||||
- [[Kolb 体验式学习]]：体验循环
|
||||
18
wiki/concepts/翻转课堂.md
Normal file
18
wiki/concepts/翻转课堂.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "翻转课堂"
|
||||
type: concept
|
||||
tags: [instructional-design, blended-learning]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
将传统课堂顺序翻转，课前通过线上方式进行知识预习，课堂时间用于讨论和实操练习，课后进行行动转化。
|
||||
|
||||
## Three Phases
|
||||
- **课前**：在线视频/微课程学习知识点
|
||||
- **课中**：案例讨论、实操练习、答疑解惑
|
||||
- **课后**：行动计划制定、行动转化追踪
|
||||
|
||||
## Related Concepts
|
||||
- [[混合学习]]：更广泛的课内外结合模式
|
||||
21
wiki/concepts/行动学习.md
Normal file
21
wiki/concepts/行动学习.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "行动学习"
|
||||
type: concept
|
||||
tags: [leadership-development, experiential-learning]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
围绕真实业务挑战组建学习小组，通过解决实际问题发展领导力。
|
||||
|
||||
## Core Process
|
||||
识别真实业务问题 → 组建学习小组 → 分析问题根因 → 制定解决方案 → 实施并跟踪结果 → 复盘总结
|
||||
|
||||
## Benefits
|
||||
- 学以致用，解决真实业务问题
|
||||
- 团队协作能力提升
|
||||
- 领导力实践锻炼
|
||||
|
||||
## Related Concepts
|
||||
- [[Kolb 体验式学习]]：理论基础
|
||||
37
wiki/entities/Cultural-Intelligence-Strategist.md
Normal file
37
wiki/entities/Cultural-Intelligence-Strategist.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Cultural Intelligence Strategist"
|
||||
type: entity
|
||||
tags: [agent, the-agency, design, localization, accessibility]
|
||||
sources: [specialized-cultural-intelligence-strategist]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Cultural Intelligence Strategist Agent
|
||||
- CQ Strategist
|
||||
|
||||
## Role
|
||||
The Agency agent persona for auditing products, prompts, and workflows for invisible exclusion, cultural blind spots, and localization assumptions.
|
||||
|
||||
## Description
|
||||
A structurally minded agent that treats inclusion as an architectural requirement rather than a cosmetic polish. It checks naming conventions, calendar assumptions, color semiotics, iconography, metaphors, and content localization before release.
|
||||
|
||||
## Key Capabilities
|
||||
- Detect invisible exclusion in forms, copy, and workflows
|
||||
- Research culture-specific constraints before generating content
|
||||
- Evaluate prompts and image outputs for bias and tokenism
|
||||
- Recommend global-first alternatives for names, dates, symbols, and accessibility
|
||||
|
||||
## Related Concepts
|
||||
- [[Cultural Intelligence]]
|
||||
- [[Invisible Exclusion]]
|
||||
- [[Global-First Architecture]]
|
||||
- [[Contextual Semiotics]]
|
||||
- [[Cultural Humility]]
|
||||
- [[Prompt Engineering]]
|
||||
- [[Design System]]
|
||||
|
||||
## Related Entities
|
||||
- [[The Agency]]
|
||||
- [[Image Prompt Engineer]]
|
||||
- [[Inclusive Visuals Specialist]]
|
||||
19
wiki/entities/DingTalk-Learning.md
Normal file
19
wiki/entities/DingTalk-Learning.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "DingTalk Learning"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, alibaba-ecosystem]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
钉钉学习（DingTalk Xuetang），阿里巴巴钉钉生态的企业学习平台。
|
||||
|
||||
## Characteristics
|
||||
- 深度集成钉钉 OA 系统
|
||||
- 支持直播培训、在线考试、学习任务推送
|
||||
- 适合阿里生态企业
|
||||
- 移动端体验优秀
|
||||
|
||||
## Related Concepts
|
||||
- [[Corporate Training Designer]]：使用该平台交付培训
|
||||
19
wiki/entities/Feishu-Knowledge-Base.md
Normal file
19
wiki/entities/Feishu-Knowledge-Base.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Feishu Knowledge Base"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, bytedance-ecosystem]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
飞书知识库，字节跳动生态的知识管理导向组织首选平台。
|
||||
|
||||
## Characteristics
|
||||
- 文档协作能力优秀
|
||||
- 适合知识管理导向组织
|
||||
- 与飞书套件深度集成
|
||||
- 适合将组织知识进行结构化沉淀
|
||||
|
||||
## Related Concepts
|
||||
- [[Corporate Training Designer]]：使用该平台交付培训
|
||||
34
wiki/entities/Healthcare-Marketing-Compliance-Specialist.md
Normal file
34
wiki/entities/Healthcare-Marketing-Compliance-Specialist.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Healthcare Marketing Compliance Specialist"
|
||||
type: entity
|
||||
tags: [agent, the-agency, healthcare, compliance, china]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
Healthcare Marketing Compliance Specialist is a The Agency agent persona focused on keeping healthcare promotion within the boundaries of Chinese regulation while preserving marketing effectiveness.
|
||||
|
||||
## Core Identity
|
||||
- **Role**: Full-lifecycle healthcare marketing compliance expert
|
||||
- **Personality**: Precise, risk-aware, pragmatic, and fluent in regulatory translation
|
||||
- **Memory**: Remembers key clauses, enforcement patterns, platform rules, and compliance red lines
|
||||
|
||||
## Key Capabilities
|
||||
- Review healthcare advertising, branded content, and promotional scripts before publication
|
||||
- Identify violations in medical, pharmaceutical, device, medical aesthetics, and supplement marketing
|
||||
- Interpret platform policies for Douyin, Xiaohongshu, WeChat, and internet healthcare platforms
|
||||
- Assess privacy and consent risks in patient data use and CRM workflows
|
||||
- Guide compliant academic detailing, conference sponsorship, and medical representative conduct
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
- [[HealthSupplementMarketing]]
|
||||
- [[InternetHealthcareCompliance]]
|
||||
- [[MedicalAestheticsCompliance]]
|
||||
- [[PatientPrivacyProtection]]
|
||||
- [[AcademicDetailingCompliance]]
|
||||
- [[Identity Governance]]
|
||||
|
||||
## Related Entities
|
||||
- [[The Agency]]
|
||||
19
wiki/entities/KoolSchool.md
Normal file
19
wiki/entities/KoolSchool.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "KoolSchool"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, sme]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
酷学院，轻量级企业培训 SaaS 平台。
|
||||
|
||||
## Characteristics
|
||||
- 快速部署
|
||||
- 适合中小企业
|
||||
- 适合连锁零售行业
|
||||
- 轻量级解决方案
|
||||
|
||||
## Related Concepts
|
||||
- [[Corporate Training Designer]]：使用该平台交付培训
|
||||
@@ -36,6 +36,7 @@ tags: [project, ai-agents, open-source]
|
||||
- [[XR Cockpit Interaction Specialist]]：XR 座舱交互专家智能体，专注于设计和开发 XR 环境的沉浸式座舱控制系统
|
||||
- [[macOS Spatial/Metal Engineer]]：macOS 空间计算与 Metal 渲染工程师智能体，专注于 Native Swift 和 Metal 高性能 3D 渲染
|
||||
|- [[visionOS Spatial Engineer]]：visionOS 空间计算原生开发专家智能体，专注于 Native visionOS 空间计算、SwiftUI 体积化界面和 Liquid Glass 设计实现
|
||||
|- [[Workflow Architect]]：工作流设计专家智能体，负责流程树、失败分支与交接契约
|
||||
|- [[Identity Graph Operator]]：共享身份图操作智能体，负责实体解析、合并与冲突治理
|
||||
|- [[Terminal Integration Specialist]]：终端仿真和 SwiftTerm 集成专家智能体
|
||||
|- [[Civil Engineer]]：土木与结构工程智能体，负责多国规范下的结构分析、岩土设计和建筑合规
|
||||
|
||||
20
wiki/entities/UMU.md
Normal file
20
wiki/entities/UMU.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "UMU Interactive Learning Platform"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, blended-learning]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
UMU 互动学习平台，国内领先的混合学习平台。
|
||||
|
||||
## Characteristics
|
||||
- AI 陪练伙伴
|
||||
- 视频作业功能
|
||||
- 丰富的交互功能
|
||||
- 支持多种学习活动类型
|
||||
|
||||
## Related Concepts
|
||||
- [[Corporate Training Designer]]：使用该平台交付培训
|
||||
- [[混合学习]]：平台支持的学习模式
|
||||
15
wiki/entities/WeCom-Learning.md
Normal file
15
wiki/entities/WeCom-Learning.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "WeCom Learning"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, wechat-ecosystem]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
企业微信学习（Qiye Weixin），微信生态企业首选的企业学习平台。
|
||||
|
||||
## Characteristics
|
||||
- 可嵌入公众号和小程序
|
||||
- 社交学习体验强
|
||||
- 适合微信生态企业
|
||||
40
wiki/entities/Workflow-Architect.md
Normal file
40
wiki/entities/Workflow-Architect.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Workflow Architect"
|
||||
type: entity
|
||||
tags: [agent, workflow-design, the-agency]
|
||||
sources: [specialized-workflow-architect]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
Workflow Architect 是 The Agency 项目中的工作流设计专家智能体，负责把系统行为拆解为完整的流程树，明确每个分支、失败模式、恢复路径和交接契约。
|
||||
|
||||
## Core Identity
|
||||
- **Role**: Workflow design and specification specialist
|
||||
- **Personality**: Exhaustive, precise, branch-obsessed, contract-minded
|
||||
- **Memory**: 记录所有未写明的假设、遗漏的分支和会导致 bug 的隐式流程
|
||||
|
||||
## Key Capabilities
|
||||
- 发现未显式声明的工作流
|
||||
- 建立工作流注册表并持续维护
|
||||
- 为每个步骤定义成功、失败、超时与恢复路径
|
||||
- 定义 observable states：客户、操作员、数据库、日志
|
||||
- 维护 cleanup inventory，避免 orphan resource
|
||||
- 使用 Reality Checker 闭环验证 spec 与实现一致性
|
||||
|
||||
## Related Concepts
|
||||
- [[Workflow Architecture]]
|
||||
- [[Claude Skills]]
|
||||
- [[Process Optimization]]
|
||||
- [[AI-powered Runbooks]]
|
||||
- [[Document Generation]]
|
||||
|
||||
## Related Entities
|
||||
- [[The Agency]]
|
||||
- [[Project Shepherd]]
|
||||
- [[Senior Project Manager]]
|
||||
- [[Document Generator]]
|
||||
|
||||
## Aliases
|
||||
- Workflow Design Specialist
|
||||
- Workflow Spec Architect
|
||||
- Process Flow Architect
|
||||
19
wiki/entities/Yunxuetang.md
Normal file
19
wiki/entities/Yunxuetang.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Yunxuetang"
|
||||
type: entity
|
||||
tags: [enterprise-learning-platform, cloud-academy]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
云学堂，中大型企业一站式学习平台。
|
||||
|
||||
## Characteristics
|
||||
- 课程资源丰富
|
||||
- 支持人才发展全生命周期
|
||||
- 适合中大型企业
|
||||
- 功能全面的企业学习管理
|
||||
|
||||
## Related Concepts
|
||||
- [[Corporate Training Designer]]：使用该平台交付培训
|
||||
2319
wiki/index.md
2319
wiki/index.md
File diff suppressed because it is too large
Load Diff
152
wiki/log.md
152
wiki/log.md
@@ -1,62 +1,108 @@
|
||||
## [2026-04-20] ingest | Document Generator
|
||||
- Source file: raw/Agent/agency-agents/specialized/specialized-document-generator.md
|
||||
## [2026-04-20] ingest | Corporate Training Designer
|
||||
- Source file: raw/Agent/agency-agents/specialized/corporate-training-designer.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Document Generator 是 The Agency 体系中的程序化文档创建智能体，专注于通过代码、模板与样式系统生成 PDF、PPTX、XLSX 与 DOCX
|
||||
- Concepts created: Document Generation
|
||||
- Entities created: Document Generator, The Agency（更新）
|
||||
- Source page: wiki/sources/specialized-document-generator.md
|
||||
- Summary: 企业培训系统架构与课程开发专家智能体，覆盖培训需求分析、课程体系设计、教学方法论（ADDIE/SAM/Bloom's/Kirkpatrick）、企业内部培训师培养（TTT）、新员工 90 天计划、领导力发展、合规培训
|
||||
- Concepts created: ADDIE 模型、SAM 模型、Bloom's Taxonomy、Kirkpatrick 四级评估模型、混合学习、 Kolb 体验式学习、TTT、HIPO 计划、360 度反馈、行动学习、翻转课堂、建构主义学习理论、Gamification、新员工培训 90 天计划
|
||||
- Entities created: DingTalk Learning、WeCom Learning、Feishu Knowledge Base、UMU Interactive Learning Platform、Yunxuetang、KoolSchool
|
||||
- Source page: wiki/sources/corporate-training-designer.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-20] ingest | Identity Graph Operator
|
||||
- Source file: raw/Agent/agency-agents/specialized/identity-graph-operator.md
|
||||
## [2026-04-20] ingest | Healthcare Marketing Compliance Specialist
|
||||
- Source file: raw/Agent/agency-agents/specialized/healthcare-marketing-compliance.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Identity Graph Operator 负责多智能体系统中的共享身份图与实体归一化，确保不同 agent 面对同一现实世界实体时得到同一 canonical identity，并保留合并/拆分的审计与回滚能力
|
||||
- Concepts created: Identity Governance
|
||||
- Entities created: Identity Graph Operator, The Agency（更新）
|
||||
- Source page: wiki/sources/identity-graph-operator.md
|
||||
- Summary: Healthcare Marketing Compliance Specialist defines a China-focused compliance role spanning medical advertising, internet healthcare, medical aesthetics, supplements, privacy, and academic detailing
|
||||
- Concepts created: Healthcare Marketing Compliance, Medical Advertising Compliance, Health Supplement Marketing, Internet Healthcare Compliance, Medical Aesthetics Compliance, Patient Privacy Protection, Academic Detailing Compliance
|
||||
- Entities created: Healthcare Marketing Compliance Specialist
|
||||
- Source page: wiki/sources/healthcare-marketing-compliance.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-20] ingest | Recruitment Specialist
|
||||
- Source file: raw/Agent/agency-agents/specialized/recruitment-specialist.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Recruitment Specialist 是 The Agency 体系中的招聘运营与人才获取专家，覆盖中国主流招聘平台、结构化面试、劳动法合规、候选人体验与 onboarding
|
||||
- Concepts created: Recruitment Operations, Talent Assessment, Labor Law Compliance, Candidate Experience, Employer Brand, ATS, Onboarding
|
||||
- Entities created: Recruitment Specialist, The Agency（更新)
|
||||
- Source page: wiki/sources/recruitment-specialist.md
|
||||
- Notes:
|
||||
1|## [2026-04-20] ingest | LLM Wiki
|
||||
2|- Source file: raw/Agent/LLM Wiki.md
|
||||
3|- Status: ✅ 成功摄入
|
||||
4|- Summary: LLM Wiki 描述了一个由 LLM 持续编译和维护的持久化 wiki 模式，让知识从一次性检索转变为可累积、可追溯、可维护的长期资产
|
||||
5|- Concepts created: LLM Wiki
|
||||
6|- Entities created: —
|
||||
7|- Source page: wiki/sources/LLM-Wiki.md
|
||||
8|- Notes:
|
||||
9|
|
||||
10|## [2026-04-20] ingest | Document Generator
|
||||
11|- Source file: raw/Agent/agency-agents/specialized/specialized-document-generator.md
|
||||
12|- Status: ✅ 成功摄入
|
||||
13|- Summary: Document Generator 是 The Agency 体系中的程序化文档创建智能体，专注于通过代码、模板与样式系统生成 PDF、PPTX、XLSX 与 DOCX
|
||||
14|- Concepts created: Document Generation
|
||||
15|- Entities created: Document Generator, The Agency（更新）
|
||||
16|- Source page: wiki/sources/specialized-document-generator.md
|
||||
17|- Notes:
|
||||
18|
|
||||
19|## [2026-04-20] ingest | Identity Graph Operator
|
||||
20|- Source file: raw/Agent/agency-agents/specialized/identity-graph-operator.md
|
||||
21|- Status: ✅ 成功摄入
|
||||
22|- Summary: Identity Graph Operator 负责多智能体系统中的共享身份图与实体归一化，确保不同 agent 面对同一现实世界实体时得到同一 canonical identity，并保留合并/拆分的审计与回滚能力
|
||||
23|- Concepts created: Identity Governance
|
||||
24|- Entities created: Identity Graph Operator, The Agency（更新）
|
||||
25|- Source page: wiki/sources/identity-graph-operator.md
|
||||
26|- Notes:
|
||||
27|
|
||||
28|## [2026-04-20] ingest | Recruitment Specialist
|
||||
29|- Source file: raw/Agent/agency-agents/specialized/recruitment-specialist.md
|
||||
30|- Status: ✅ 成功摄入
|
||||
31|- Summary: Recruitment Specialist 是 The Agency 体系中的招聘运营与人才获取专家，覆盖中国主流招聘平台、结构化面试、劳动法合规、候选人体验与 onboarding
|
||||
32|- Concepts created: Recruitment Operations, Talent Assessment, Labor Law Compliance, Candidate Experience, Employer Brand, ATS, Onboarding
|
||||
33|- Entities created: Recruitment Specialist, The Agency（更新)
|
||||
34|- Source page: wiki/sources/recruitment-specialist.md
|
||||
35|- Notes:
|
||||
36|
|
||||
37|## [2026-04-20] ingest | Civil Engineer
|
||||
38|- Source file: raw/Agent/agency-agents/specialized/specialized-civil-engineer.md
|
||||
39|- Status: ✅ 成功摄入
|
||||
40|- Summary: Civil Engineer 是一位严谨的土木/结构工程智能体，强调在多国标准下输出安全、经济、可施工的设计，并同时检查 ULS 与 SLS
|
||||
41|- Concepts created: Global Standards Coverage
|
||||
42|- Entities created: Civil Engineer, The Agency（更新）
|
||||
43|- Source page: wiki/sources/specialized-civil-engineer.md
|
||||
44|- Notes:
|
||||
45|
|
||||
46|## [2026-04-20] ingest | Experiment Tracker
|
||||
47|- Source file: raw/Agent/agency-agents/project-management/project-management-experiment-tracker.md
|
||||
48|- Status: ✅ 成功摄入
|
||||
49|- Summary: Experiment Tracker 是一位专注于实验设计、执行跟踪和数据驱动决策的项目管理智能体，覆盖 A/B 测试、假设验证、样本量计算、随机分配、风险监控与回滚
|
||||
50|- Concepts created: A/B Testing, Hypothesis Testing, Statistical Significance, Power Analysis, Randomization
|
||||
51|- Entities created: Experiment Tracker, Project Shepherd（更新）
|
||||
52|- Source page: wiki/sources/project-management-experiment-tracker.md
|
||||
53|- Notes:
|
||||
54|
|
||||
55|## [2026-04-20] ingest | Studio Operations
|
||||
56|- Source file: raw/Agent/agency-agents/project-management/project-management-studio-operations.md
|
||||
57|- Status: ✅ 成功摄入
|
||||
58|- Summary: The Agency 项目中的 Studio Operations Agent，负责日常工作室运营、流程优化和资源协调，强调标准化、资源管理和持续改进
|
||||
59|- Concepts created: Process Optimization, Resource Allocation, Operational Excellence, Cross-Functional Leadership
|
||||
60|- Entities created: Studio Operations, The Agency（更新）
|
||||
61|- Source page: wiki/sources/project-management-studio-operations.md
|
||||
62|- Notes:
|
||||
63|
|
||||
64|## [2026-04-20] ingest | Workflow Architect
|
||||
65|- Source file: raw/Agent/agency-agents/specialized/specialized-workflow-architect.md
|
||||
66|- Status: ✅ 成功摄入
|
||||
67|- Summary: Workflow Architect 是 The Agency 体系中的工作流设计专家智能体，负责把系统行为拆解为完整流程树，覆盖分支、失败模式、恢复路径与交接契约
|
||||
68|- Concepts created: Workflow Architecture
|
||||
69|- Entities created: Workflow Architect, The Agency（更新）
|
||||
70|- Source page: wiki/sources/specialized-workflow-architect.md
|
||||
71|- Notes:
|
||||
72|
|
||||
73|## [2026-04-20] ingest | Government Digital Presales Consultant
|
||||
74|- Source file: raw/Agent/agency-agents/specialized/government-digital-presales-consultant.md
|
||||
75|- Status: ✅ 成功摄入
|
||||
76|- Summary: Government Digital Presales Consultant 是面向中国政府数字化转型市场的售前专家，覆盖政策解读、方案设计、招投标、POC 验证与合规适配
|
||||
77|- Concepts created: Digital Government, Smart City, Government Procurement, Dengbao, Miping, Xinchuang
|
||||
78|- Entities created: Government Digital Presales Consultant
|
||||
79|- Source page: wiki/sources/government-digital-presales-consultant.md
|
||||
80|- Notes:
|
||||
81|
|
||||
|
||||
## [2026-04-20] ingest | Civil Engineer
|
||||
- Source file: raw/Agent/agency-agents/specialized/specialized-civil-engineer.md
|
||||
## [2026-04-20] ingest | Cultural Intelligence Strategist
|
||||
- Source file: raw/Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Civil Engineer 是一位严谨的土木/结构工程智能体，强调在多国标准下输出安全、经济、可施工的设计，并同时检查 ULS 与 SLS
|
||||
- Concepts created: Global Standards Coverage
|
||||
- Entities created: Civil Engineer, The Agency（更新）
|
||||
- Source page: wiki/sources/specialized-civil-engineer.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-20] ingest | Experiment Tracker
|
||||
- Source file: raw/Agent/agency-agents/project-management/project-management-experiment-tracker.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Experiment Tracker 是一位专注于实验设计、执行跟踪和数据驱动决策的项目管理智能体，覆盖 A/B 测试、假设验证、样本量计算、随机分配、风险监控与回滚
|
||||
- Concepts created: A/B Testing, Hypothesis Testing, Statistical Significance, Power Analysis, Randomization
|
||||
- Entities created: Experiment Tracker, Project Shepherd（更新）
|
||||
- Source page: wiki/sources/project-management-experiment-tracker.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-20] ingest | Studio Operations
|
||||
- Source file: raw/Agent/agency-agents/project-management/project-management-studio-operations.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: The Agency 项目中的 Studio Operations Agent，负责日常工作室运营、流程优化和资源协调，强调标准化、资源管理和持续改进
|
||||
- Concepts created: Process Optimization, Resource Allocation, Operational Excellence, Cross-Functional Leadership
|
||||
- Entities created: Studio Operations, The Agency（更新）
|
||||
- Source page: wiki/sources/project-management-studio-operations.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-20] ingest | Government Digital Presales Consultant
|
||||
- Source file: raw/Agent/agency-agents/specialized/government-digital-presales-consultant.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Government Digital Presales Consultant 是面向中国政府数字化转型市场的售前专家，覆盖政策解读、方案设计、招投标、POC 验证与合规适配
|
||||
- Concepts created: Digital Government, Smart City, Government Procurement, Dengbao, Miping, Xinchuang
|
||||
- Entities created: Government Digital Presales Consultant
|
||||
- Source page: wiki/sources/government-digital-presales-consultant.md
|
||||
- Summary: Cultural Intelligence Strategist 检测产品、提示词和工作流中的 invisible exclusion，并推动 global-first、文化谦逊与上下文语义审查
|
||||
- Concepts created: Cultural Intelligence, Invisible Exclusion, Global-First Architecture, Contextual Semiotics, Cultural Humility
|
||||
- Entities created: Cultural Intelligence Strategist
|
||||
- Source page: wiki/sources/specialized-cultural-intelligence-strategist.md
|
||||
- Notes:
|
||||
|
||||
763
wiki/overview.md
763
wiki/overview.md
@@ -1,379 +1,384 @@
|
||||
# Wiki Overview
|
||||
|
||||
## 主题领域
|
||||
AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境电商
|
||||
|
||||
## 核心概念
|
||||
- The Agency：开源 AI 智能体集合项目，汇集各类专业化 AI Agent
|
||||
- Image Prompt Engineer：The Agency 项目中的 AI 图像生成提示词工程专家智能体，专注于将视觉概念转化为精确的提示词语言
|
||||
- Agentic Identity & Trust Architect：The Agency 中负责自治 AI Agent 身份、授权、证据链与信任评分的专家智能体
|
||||
- 智能体设计规范：智能体文件结构、身份与记忆、核心使命、技术交付物、工作流程的完整定义
|
||||
- 智能体设计原则：六大设计原则（鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆、真实场景测试）
|
||||
- UX Architect：The Agency 项目中的技术架构与 UX 专家智能体，为开发者提供 CSS 设计系统、布局框架、主题切换机制和清晰实现路径
|
||||
- UI Designer：The Agency 项目中的 UI 设计智能体，专门负责创建美观、一致、可访问的用户界面，提供设计系统、组件库和像素级界面实现
|
||||
- UX Researcher：The Agency 项目中的用户体验研究智能体，专注于用户行为分析、可用性测试和数据驱动的设计决策验证
|
||||
- Brand Guardian：The Agency 项目中的品牌战略与身份保护专家智能体，专注于品牌基础框架、视觉识别系统、品牌一致性与价值保护
|
||||
- Paid Media Programmatic & Display Buyer：The Agency 项目中的付费媒体程序化购买与展示广告智能体，专注于 DSP 平台管理、Google 展示网络、ABM 展示执行和合作伙伴媒体策略
|
||||
- Paid Media PPC Campaign Strategist：The Agency 项目中的付费媒体 PPC 智能体，负责大规模搜索、购物和效果最大化广告系列架构设计
|
||||
- Paid Media Ad Creative Strategist：The Agency 项目中的付费媒体广告创意策略智能体，专注于广告文案撰写、响应式搜索广告（RSA）优化和创意测试框架
|
||||
- Paid Media Auditor：The Agency 项目中的付费媒体审计智能体，系统化评估 Google Ads、Microsoft Ads 和 Meta 广告账户，识别 15-30% 效率提升机会
|
||||
- Paid Media Paid Social Strategist：The Agency 项目中的付费社交媒体广告智能体，跨平台覆盖 Meta、LinkedIn、TikTok 等
|
||||
- Paid Media Tracking & Measurement Specialist：The Agency 项目中的付费媒体追踪与测量专家智能体，专注于 GTM 容器架构、GA4 事件设计、服务端标记和跨平台转化归因
|
||||
- Search Query Analyst：The Agency 项目中的付费搜索查询分析智能体，专注于搜索词报告挖掘、N-gram 分析、否定关键词架构和查询意图映射，可消除 10-20% 非转化支出
|
||||
- Sales Discovery Coach：The Agency 项目中的销售发现方法论指导智能体，教导销售团队通过提问、当前状态映射、差距量化和电话结构发现真正购买动机
|
||||
- Outbound Strategist：The Agency 项目中的基于信号触发的外呼销售策略智能体，通过购买信号识别、多渠道序列设计和 ICP 定义提升外呼转化率
|
||||
- 信号驱动销售：基于购买信号（Intent Signal）触发外呼的销售方法论，比无差别冷外呼转化率高 4-8 倍
|
||||
- Deal Strategist：The Agency 项目中的销售交易策略智能体，专注于 MEDDPICC 资格认证、竞争定位和赢单规划
|
||||
- Proposal Strategist：The Agency 项目中的销售提案策略智能体，将 RFP 响应转化为制胜叙事，擅长制胜主题开发、三幕式提案叙事和竞争定位
|
||||
- Sales Account Strategist：The Agency 项目中的售后账户策略专家智能体，专注于 Land-and-Expand 执行、利益相关者映射、QBR 设计和净收入留存
|
||||
- Pipeline Analyst：The Agency 项目中的销售管道健康诊断智能体，专注于交易速度分析、管道健康评估和收入预测准确性，将 CRM 数据转化为可操作情报
|
||||
- Studio Producer：The Agency 项目中的 Studio Producer Agent，资深战略领导者，专注于高层次创意与技术项目编排、资源配置和多项目组合管理，将创意愿景与业务目标对齐
|
||||
- Project Shepherd：The Agency 项目中的专业项目管理人员智能体，专注于跨职能项目协调、时间线管理和利益相关方对齐，确保 95% 项目按时在预算内交付
|
||||
- 项目章程：定义项目目标、范围、成功标准和治理结构的标准化文档模板，是项目启动阶段的核心交付物
|
||||
|
||||
- Senior Project Manager：将规格文件转化为开发可执行的任务清单，强调现实的范围设定、每项任务的可实施时间（30–60 分钟）并保存任务清单以支持后续项目记忆与改进
|
||||
|
||||
- XR Immersive Developer：The Agency 项目中的 WebXR 沉浸式技术开发专家，专注于基于浏览器的 AR/VR/XR 应用开发
|
||||
- XR Cockpit Interaction Specialist：The Agency 项目中的 XR 座舱交互专家智能体，专注于设计和开发 XR 环境的沉浸式座舱控制系统
|
||||
- XR Interface Architect：The Agency 项目中的 XR 界面架构师智能体，专注于沉浸式 3D 环境的空间界面设计，关注最小化晕动症和增强临场感
|
||||
- macOS Spatial/Metal Engineer：The Agency 项目中的 macOS 空间计算与 Metal 渲染工程师智能体，专注于 Native Swift 和 Metal 高性能 3D 渲染，支持 Vision Pro 远程沉浸式空间集成
|
||||
- visionOS Spatial Engineer：The Agency 项目中的 visionOS 空间计算原生开发专家智能体，专注于 Native visionOS 空间计算、SwiftUI 体积化界面和 Liquid Glass 设计实现
|
||||
- Terminal Integration Specialist：The Agency 项目中的终端仿真和 SwiftTerm 集成专家智能体，专注于终端仿真、文本渲染优化和 Swift 应用集成
|
||||
- 空间计算（Spatial Computing）：一种计算范式，通过将数字内容与物理空间无缝融合，使用户能够与计算机生成的环境进行自然交互
|
||||
- WebXR：W3C 制定的浏览器标准接口，用于提供沉浸式 VR 和 AR 体验
|
||||
- 账户架构：PPC 广告活动的组织结构设计，涵盖活动结构、广告组分类、标签系统、命名规范，可实现 10K 到 10M+ 月预算的可扩展投放
|
||||
- 自动化出价策略：PPC 广告平台的智能出价优化机制，包括 tCPA、tROAS、Max Conversions、Max Conversion Value 等策略
|
||||
- 绩效最大化：Google Ads 的自动化全渠道投放类型，通过机器学习在全渠道自动优化广告投放
|
||||
- 程序化购买：通过 DSP 平台自动化采购展示广告库存的技术，实现实时竞价和效果优化
|
||||
- 展示广告：在第三方网站、应用和社交媒体上呈现的视觉广告，侧重品牌建设和潜在客户获取
|
||||
- 可见度标准：衡量数字广告是否真正被用户看到的指标（MRC 标准：70%+ 可见展示）
|
||||
- Pull Request 流程：从提交前准备到 PR 审核的完整流程（社区评审、迭代优化、通过审核、合并上线）
|
||||
- Print Mode：Hermes 通过 stdin 调用 Claude Code 的非交互执行模式
|
||||
- TMUX 交互模式：在 TMUX 会话中运行 Claude Code 的交互模式，适合超长任务
|
||||
- DeepSeek：中国 AI 公司开发的大语言模型，以开源和高效著称，DeepSeek-R1 在复杂任务处理方面表现出色
|
||||
- 提示语设计：通过精心设计的提示词提升 AI 输出质量的技术
|
||||
- Prompt Library：提示词库，提供现成提示词供用户参考和定制
|
||||
- Prompt 能力：结构化思维+精准表达能力，包含需求拆解、结构化表达、场景共情、迭代优化四个维度
|
||||
- Nano Banana Pro：Google 的专业级图像生成模型，具备物理规则推演、构图美学理解、语义上下文推理能力
|
||||
- Nano Banana 2：Google 的推理型图像生成模型（Gemini 3 Pro Image），支持 1K/2K/4K 分辨率，可组合 14 张输入图像，具备多语言长文本渲染和最新知识支持能力
|
||||
- AI幻觉：AI 生成看似合理但实际错误的内容，需通过技巧避免
|
||||
- Wayland：Linux 桌面环境的现代显示协议，Ubuntu 24.04 默认使用，出于安全限制外部程序在未登录状态下获取屏幕控制权
|
||||
- X11 (Xorg)：传统 Linux 显示协议，兼容性更好，支持远程桌面软件，是 Wayland 的替代方案
|
||||
- GDM3：GNOME Display Manager，Ubuntu 的登录管理器，支持 Wayland 和 X11 两种显示协议
|
||||
- ITSM（IT 服务管理）：从工单系统演进为战略推动者，实现运营卓越、风险缓解和创新加速
|
||||
- Identity Governance（身份治理）：管理数字身份、降低风险并保持合规的框架，回答谁有权访问、谁应该访问、如何访问三个核心问题
|
||||
- Multi-Account Strategy（多账号策略）：AWS 推荐的企业级云架构模式，通过将工作负载分离到多个 AWS 账号来提升安全性、治理能力和故障隔离
|
||||
- Gruntwork Landing Zone：Gruntwork 提供的预配置 AWS 基础架构框架，基于 Reference Architecture 包含核心账户和工作负载账户
|
||||
- Landing Zone：云着陆区，标准化的多账户基础架构框架，用于托管产品团队的工作负载
|
||||
- Terraform：基础设施即代码工具，通过声明式配置定义云资源，实现跨平台基础设施管理
|
||||
- Terragrunt：Terraform 的包装工具，提供模块化、变量共享和环境隔离，跨多账户部署
|
||||
- TerraTest：Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 流程
|
||||
- Test-Driven Development：测试驱动开发方法论，先写测试再实现功能
|
||||
- Service Catalog：服务目录，封装业务需求的模块分组，提供服务级别抽象，实现跨团队复用
|
||||
- Module：Terraform 模块，可复用的基础设施配置单元
|
||||
- ECS (Elastic Container Services)：AWS 专有容器编排服务，与 AWS 服务深度集成，支持自动扩展、自动修复和金丝雀部署
|
||||
|
||||
- AWS SES (Simple Email Service)：AWS 提供的基于云的邮件发送服务，支持 API 或 SMTP 接口发送邮件，通过 VPC 终端节点实现私有访问
|
||||
|
||||
- VPC Endpoint：AWS 私有网络连接服务，允许 VPC 中的资源安全访问 AWS 服务而不经过公网
|
||||
|
||||
- Secrets Manager：AWS 凭证管理服务，用于安全存储和检索敏感信息
|
||||
|
||||
- DKIM (DomainKeys Identified Mail)：电子邮件验证标准，通过数字签名确保邮件完整性和发件人身份
|
||||
|
||||
- CCOE（Cloud Center of Excellence）：推动云采纳和治理的核心组织单元，负责 AMI 标准制定和发布
|
||||
|
||||
- OpsBridge（运营桥）：Micro Focus 的企业级监控平台，支持 AWS 云监控，可部署在本地或 EKS 上
|
||||
- Cloud Monitoring（云监控）：OpsBridge 的核心功能，支持监控 20+ AWS 数据服务
|
||||
- Optic Data Lake：OpsBridge 的数据存储层，使用 Vertica 数据库支撑高性能仪表板
|
||||
|
||||
- AWS Workspaces：AWS 提供的托管桌面即服务（DaaS）解决方案，预装开发工具实现快速生产力
|
||||
|
||||
- Standard AMI：AWS 标准机器镜像，包含 OS 加固、最新安全补丁，并支持域集成、SSM agent、DNS 设置，每两个月发布一次
|
||||
- Cloud Guardrails：云守护栏，捕获可扩展性、成本最小化和灵活性的强制性要求和最佳实践
|
||||
- Tagging Methodology：标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
|
||||
- IPAM（IP Address Management）：IP 地址管理工具，用于规划、追踪和管理 IP 地址空间，实现 VPC IP 地址自动化分配
|
||||
- RTO（Recovery Time Objective）：系统允许的最大停机时间，是灾难恢复的核心指标
|
||||
- RPO（Recovery Point Objective）：可接受的最大数据丢失量，是数据保护的核心指标
|
||||
- Feature Flag（特性开关）：控制代码路径而不需要重新部署的机制，实现秒级回滚和低 RTO/RPO
|
||||
- 开源平替：功能可替代闭源商业产品的开源项目
|
||||
- Cloud Maturity Model（云成熟度模型）：评估组织云采纳就绪程度的5级框架
|
||||
- DevOps 成熟度模型：评估组织 DevOps 实践水平的分级框架
|
||||
- DevOps 文化：打破开发与运维壁垒，优先协作、持续学习和客户导向的文化理念
|
||||
- CI/CD 流水线：自动化测试、集成和部署的持续交付管道
|
||||
- Infrastructure as Code (IaC)：通过代码实现一致性、版本控制的基础设施管理
|
||||
- Renovate Bot：开源依赖自动化更新工具，通过扫描代码并自动提交 PR 保持依赖项处于最新状态
|
||||
- 敏捷实践：Scrum、Kanban 等迭代开发方法论
|
||||
- 事件驱动项目管理：使用数据库存储项目状态和历史事件，通过 AI Agent 自然语言交互替代静态 Kanban 看板
|
||||
- 内网穿透（NAT Penetration）：将内网服务通过公网服务器暴露给外部访问的技术，FRP 是常用方案之一
|
||||
- Workspace：OpenClaw 中 Agent 的工作台目录，包含 AGENTS.md、SOUL.md、USER.md、IDENTITY.md、TOOLS.md、BOOTSTRAP.md、memory/ 等配置文件
|
||||
- Memory 目录：OpenClaw 的长期记忆机制，按日期滚动存储跨会话积累的信息
|
||||
- Apache Superset：Apache 软件基金会旗下的开源 BI 平台，支持数据可视化、仪表盘和 SQL 探索
|
||||
- Superset Dashboard：Apache Superset 数据可视化仪表盘，包含图表、过滤器、布局的完整组合
|
||||
- SQL View：预处理的数据库视图，用于解析 JSON 字段和计算派生指标
|
||||
- KPI 卡片：关键绩效指标可视化展示（总产品数、热卖产品数、平均评分等）
|
||||
- 选品评分模型：通过加权公式自动推荐优质产品的算法（score = sold × 0.4 + rating × 12 + rating_count × 0.2 + discount_percent × 0.5）
|
||||
- 单一职责：每个文件、类、函数只负责一件事的设计原则
|
||||
- DRY 原则：Don't Repeat Yourself，避免重复代码的核心原则
|
||||
- 微服务：独立开发、独立部署、独立扩容的架构模式
|
||||
- 消息队列：服务间异步通信的中间件技术，实现解耦和削峰填谷
|
||||
- Obsidian 插件组合：根据不同使用场景将 Obsidian 核心插件进行合理搭配的策略（知识管理流、任务管理流、学习研究流）
|
||||
- Graph View：Obsidian 的知识网络可视化，发现孤立页面和知识盲区
|
||||
- 版本控制：Git 管理笔记历史变更，每次更新对应 commit
|
||||
- 信息黑洞：只收集不使用的笔记困境，通过连接和复盘解决
|
||||
- 通过 VPS+内网反向代理实现域名访问内网穿透 — 使用 FRP+Caddy 实现内网服务穿透，Aliyun DNS 域名管理
|
||||
- n8n-mcp：连接 n8n 与 AI 模型的桥接项目，提供 543 个 n8n 节点访问能力，支持自然语言生成工作流
|
||||
- Last-30-Days-Skill：Matt Van Horn 开发的多平台热门内容研究技能，支持 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket、Web 共 8 个数据源
|
||||
- Market-Research：通过用户反馈和数据分析识别产品机会的过程
|
||||
- 通才：跨领域知识整合者，拥有广泛兴趣和多元能力的人才
|
||||
- 第二次文艺复兴：AI时代每个人可以追求多领域精通
|
||||
- 品牌作为环境：品牌是小世界而非头像和简介
|
||||
- 记忆后端（Memory Backend）：AI 记忆工具的 Camp 1 方案，从对话中提取事实存储到向量数据库
|
||||
- 上下文基质（Context Substrate）：AI 记忆工具的 Camp 2 方案，通过维护结构化文件实现上下文累积
|
||||
|
||||
- WSL2：Windows Subsystem for Linux 2，Windows 上的 Linux 兼容层
|
||||
- 镜像网络模式：WSL2 与 Windows 共享网络堆栈的配置模式
|
||||
- .wslconfig：WSL2 全局配置文件，位于用户目录
|
||||
- Ikigai：热爱的、擅长的、市场需要的、能获得报酬的四者交集
|
||||
- 天才地带：能产生心流的区域，时间飞逝精力充沛
|
||||
- 底层能力：隐藏在活动表象下的核心能力
|
||||
- 产品体系：引流→入门→核心→高价四级产品矩阵，客户信任逐步建立
|
||||
- 内容矩阵：核心主题×内容形式的二维内容策略，一次制作百次<E799BE><E6ACA1><EFBFBD>发
|
||||
- 销售漏斗：获客→激活→转化的客户转化路径
|
||||
- Task Automation：自动将任务创建过程从手动操作转化为系统执行的机制
|
||||
- Agent Task Visibility：AI Agent 任务对用户的透明化展示机制，通过外部工具实时展示任务状态、进度和内部推理过程
|
||||
- 习惯追踪与问责伙伴：AI Agent 定时主动检查用户习惯完成情况，通过 Telegram/SMS 实现主动问责，追踪连续打卡并自适应调整提醒语气
|
||||
- 品味：能判断AI方案中哪个是insanely great的能力，AI时代的核心竞争力
|
||||
- 端到端：从想法到产品的完整控制权，不做流水线零件
|
||||
- 死亡过滤器：每天问自己"如果今天是最后一天，我还会做今天要做的事吗？"，用于聚焦真正热爱的事
|
||||
- 数字导师：用AI复活历史人物，让其成为日常对话的思维顾问，通过思维蒸馏技术提取人物的核心心智模型
|
||||
- 思维蒸馏：通过6个并行Agent从6个维度（著作、对话、表达DNA、他者视角、决策、时间线）采集信息，提炼核心思维框架生成AI Skill的技术
|
||||
- Claude Skills：写给 Claude 的"说明书"和技术规范，将反复执行的任务拆解为 AI 可稳定复用流程的技术范式
|
||||
- Document Generation：通过代码和模板生成 PDF、PPTX、XLSX、DOCX 等专业文档的自动化工作流
|
||||
- **baoyu-skills**：宝玉分享的 Claude Code 技能集，提供内容生成（小红书图片、信息图、封面图、幻灯片、漫画、文章插图）、AI 生成（多服务商图像生成）、工具（YouTube 字幕下载、URL 转 Markdown、社交媒体发布）17+ 个技能
|
||||
- Zettelkasten：卢曼卡片盒知识管理系统，通过原子化笔记和索引入口构建知识网络
|
||||
- **fireworks-tech-graph**：AI 驱动技术图生成工具，将中文描述转化为 SVG/PNG 格式的架构图、流程图、UML 图
|
||||
|
||||
- Foundation Model（基础模型）：具有数十亿参数的大规模预训练模型，是生成式 AI 的核心
|
||||
- Amazon Bedrock：AWS 全托管服务，用于使用基础模型构建生成式 AI 应用
|
||||
- Amazon SageMaker：AWS 机器学习平台，用于构建、训练和部署模型
|
||||
- ML Ops：机器学习运维，结合 ML 和 DevOps 实践
|
||||
- Fine-Tuning：使用标记数据集定制基础模型
|
||||
- Responsible AI：负责任 AI，包括公平性、可解释性、健壮性、治理、透明度和隐私/安全
|
||||
|
||||
- 开源大语言模型：以 DeepSeek、Qwen 为代表的开源基座大模型
|
||||
- AI生图模型：以 Flux、Stable Diffusion 为代表的开源图像生成模型
|
||||
- AI生视频模型：以 HunyuanVideo 为代表的开源视频生成模型
|
||||
- 模块化Prompt库：将 Prompt 拆分为可复用的独立模块
|
||||
- 图生视频：AI 将静态图像转化为动态视频的技术
|
||||
- AI智能体：以 Manus/OpenManus 为代表的通用 AI 代理
|
||||
- AI编程工具：以 Cline 为代表的 AI 增强代码编辑器插件
|
||||
- 智能体工作流：以 n8n、Dify 为代表的工作流自动化平台
|
||||
- AI搜索引擎：以 Perplexica 为代表的 AI 搜索开源项目
|
||||
- AI知识库：以 NotebookLM 开源平替为代表的 AI 知识管理工具
|
||||
|
||||
- LLM（Large Language Model）：大型语言模型，行业以参数规模衡量，通常 ≥1B 参数被称为"大模型"
|
||||
- MCP（Model Context Protocol）：模型上下文协议，为 LLM 提供标准化接口，使其能够连接外部数据源和工具
|
||||
- Agent 智能体：整合 LLM 与 MCP 工具才能真正执行步骤，而不仅是给出方法
|
||||
- Coze（扣子）：字节跳动旗下 AI Agent 开发平台，支持国内版（coze.cn）和海外版（coze.com）
|
||||
- Coze Workflow：Coze 平台的工作流模式，支持复杂企业级业务逻辑编排
|
||||
- Bot：Coze 平台的对话型 AI 智能体，最基础的智能体开发模式
|
||||
- RAG（Retrieval-augmented generation）：检索增强生成，通过检索增强解决 LLM 的幻觉问题
|
||||
- 向量嵌入：将文本转换为数值向量，用于语义相似度计算
|
||||
- Vector Store（向量数据库）：存储 Embedding Vector 并实现相似度检索的技术（如 Qdrant、Chroma 等）
|
||||
- Document Loader：文档加载器，从不同数据源抓取数据（如 LangChain 的 160+ 加载器）
|
||||
- Context Window：上下文窗口，Embedding Model 能接受的最大 token 数量（一般 512~8192）
|
||||
- Split（文档块）：将长文档切分成的满足 Context Window 要求的文本块
|
||||
- LangChain：简化 RAG 管道构建的 Python 框架，提供文档加载、向量存储、链式调用等功能
|
||||
- Embedding（向量化）：将词转化为一连串浮点数，计算词与词之间的语义距离
|
||||
- vLLM：虚拟大语言模型，通过 PagedAttention 和连续批处理优化 GPU 内存使用
|
||||
- Token：大模型的基本输入单元，1 个英文字符 ≈ 0.3 个 token，1 个中文字符 ≈ 0.6 个 token
|
||||
- 数据蒸馏（Data Distillation）：利用大模型生成精简数据训练小模型，使其逼近大模型效果
|
||||
|
||||
- Source-grounding：NotebookLM 的核心机制，仅使用用户上传的文档作为知识库
|
||||
- Audio Overviews：将文档转化为双人 AI 对话播客的功能，适合被动学习
|
||||
|
||||
- 递归自优化生成系统（Recursive Self-Optimizing Generative Systems）：通过迭代自修改构建稳定生成能力的系统，目标不是直接产生最优输出，而是收敛到生成器空间的不动点
|
||||
- Generator Space：生成器空间 G ⊆ P^I，每个生成器 G: I → P
|
||||
- Self-Map：自映射 Φ: G → G，定义单步更新函数
|
||||
- Fixed Point：不动点 G*，满足 Φ(G*) = G*，表示系统稳定状态
|
||||
- Y Combinator：Y 不动点组合子，用于 λ-calculus 中表达递归自引用
|
||||
|
||||
- 自托管 AI Agent 排查思路：不要默认认为错误信息就是表面意思，两层配置要分清（全局 compaction 配置和 agent 模型配置），日志真的有用，工具/系统越复杂，问题的隐藏路径越深
|
||||
|
||||
- Self-Healing Systems（自愈系统）：主动检测异常并自动修复的系统，无需人工干预即可恢复正常运行状态
|
||||
- Cron Jobs（定时任务）：Linux 基于时间的任务调度机制，AI Agent 通过定时作业实现持续自动化价值
|
||||
- Multi-Agent Team（多 Agent 团队）：多 Agent 协作架构，每个 Agent 有独立角色、人格、优化的模型，通过共享内存+私有上下文实现协同
|
||||
- 多智能体系统可靠性：层级结构、共识投票、对抗式辩论、淘汰制四种架构模式，将 LLM 视为不可靠组件的工程思维
|
||||
- 层级结构 (Hierarchy)：Planner → Worker → Validator 三层架构，通过依赖图强制协作
|
||||
- 共识投票 (Consensus)：多数票机制抵消模型随机噪声，3模型同时幻觉概率仅 0.8%
|
||||
- 对抗式辩论 (Adversarial Debate)：生成器+批评者+评委三角制衡，模拟人类"恐惧"机制
|
||||
- 淘汰制 (Knock-out)：适者生存机制，将 LLM 视为"牲畜"而非"宠物"
|
||||
- 可靠性工程：将 LLM 视为分布式系统中不可靠组件的工程方法论
|
||||
- Shared Memory（共享内存）：多 Agent 团队共享的上下文，包括目标、决策、项目状态，所有 Agent 可访问
|
||||
- 动态仪表盘（Dynamic Dashboard）：通过 Sub-agent 并行获取多数据源（GitHub、Twitter、市场数据、系统健康），定时聚合更新并推送至 Discord 或生成 HTML 仪表盘
|
||||
|
||||
- Voice Agent：具备语音交互能力的 AI 代理，能够通过语音对话完成任务
|
||||
- AI配音（AI TTS）：使用人工智能技术将文字转化为语音的技术，主流工具包括 ElevenLabs、海螺AI、F5-TTS、TTSMaker、剪映、魔音工坊、AnyVoice
|
||||
- 声音克隆（Voice Cloning）：通过少量音频样本训练AI模型，生成与原声相似的语音的技术
|
||||
- Byox（Build Your Own X）：通过从零重建22个技术领域掌握编程技能的方法论，核心理念是"What I cannot create, I do not understand"
|
||||
|
||||
- X Account Analysis（X 账户分析）：使用 OpenClaw + Bird Skill 获取用户推文并分析发布质量，定性分析替代 X 内置的定量统计
|
||||
|
||||
- **一语点醒梦中人** — 中国古代哲学智慧名言解读（王维、曾国藩、老子、庄子、佛陀），涵盖禅意、道法自然、缘起性空等核心概念
|
||||
|
||||
- **Goal-Driven Autonomous Tasks** — AI Agent 自主目标驱动任务生成与执行工作流（Brain Dump、每日任务生成、迷你应用构建）
|
||||
|
||||
- **Second Brain** — AI Agent 作为个人记忆捕获系统，通过即时通讯（Telegram/Discord/iMessage）零摩擦捕获+Next.js 搜索界面
|
||||
|
||||
- **家庭日历聚合与生活助手** — 将 OpenClaw 构建为家庭协调代理，聚合多平台日历、监控消息自动创建日程、管理家庭库存和购物清单
|
||||
|
||||
- **Market Research & Product Factory** — AI 辅助创业自动化流水线，通过 Last 30 Days skill 挖掘 Reddit/X 真实痛点，自动构建 MVP
|
||||
|
||||
- **Pre-Build Idea Validator** — AI Agent 项目启动前的创意验证机制，通过 idea-reality-mcp 扫描 GitHub、Hacker News、npm、PyPI、Product Hunt 计算竞争度评分
|
||||
- **LaTeX Paper Writing** — AI Agent 作为 LaTeX 写作助手，无本地 TeX Live 即可即时编译 PDF，支持 IEEE/beamer/中文模板
|
||||
- **Phone-Based Personal Assistant** — 基于电话的 AI 个人助理，通过 ClawdTalk + Telnyx 实现语音访问 OpenClaw
|
||||
- **Phone Call Notifications** — AI Agent 通过电话主动呼叫推送重要事项通知（clawr.ing、双向语音对话、Cron Jobs/Heartbeat 触发）
|
||||
- **OpenClaw as Desktop Cowork (AionUi)** — AionUi 桌面端协同工作界面，将 OpenClaw 作为一等公民可视化运行，支持远程救援和多 Agent 管理
|
||||
|
||||
- **Custom Morning Brief** — AI Agent 定时发送自动化早间简报，覆盖新闻、待办、创意输出和任务推荐
|
||||
|
||||
- **Autonomous Educational Game Development Pipeline** — AI Agent 自主管理教育游戏全生命周期（Game Developer Agent、Bugs First 策略、Round Robin 调度、Git 自动化）
|
||||
|
||||
- **Multi-Source Tech News Digest** — AI Agent 自动从 109+ 来源（RSS、Twitter、GitHub、Web搜索）聚合、评分并推送技术新闻
|
||||
|
||||
- RSS：信息聚合格式，允许用户订阅网站更新而无需重复访问网站
|
||||
- View Page Source：浏览器查看网页源代码的功能，可用于获取 YouTube Channel ID
|
||||
|
||||
- **Daily Reddit Digest** — AI Agent 定时从 Reddit 热门子版块获取热门帖子并生成每日摘要（Cron Jobs、偏好学习）
|
||||
|
||||
- **家庭网络环境概览** — 家庭网络基础设施架构与多服务部署方案（FRP内网穿透、Caddy反向代理、Cloudflare DNS托管）
|
||||
- **Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南** — 在 Ubuntu Server 上使用 shenwei 用户安装 Node 20、Vibe-Kanban 与 OpenCode，并通过 pm2 管理进程的完整指南
|
||||
- **在Ubuntu 上安装Vibe-Kanban** — 在 Ubuntu 系统上通过 npx 安装 Vibe-Kanban 并使用 pm2 进行进程管理的完整指南
|
||||
|
||||
- **精确去重** — 通过 MD5 哈希比对识别完全相同的文件，确保只删除真正重复的内容
|
||||
- **小文件清理** — 低于特定阈值（如 100KB）的图片大概率是截图或微信压缩图，直接移走
|
||||
- **批次任务** — 将大任务拆分为多个可管理的子任务，按顺序或定时执行
|
||||
|
||||
- **Local CRM Framework with DenchClaw** — 使用 DenchClaw 框架将 OpenClaw 转变为本地 CRM 系统，单命令安装、DuckDB 数据库、自然语言交互
|
||||
|
||||
- **Linux 运维必会的 150 个命令** — Linux 系统管理常用命令的分类汇总（12类150个命令）：帮助命令、文件操作、文件内容处理、压缩解压、信息显示、搜索文件、用户管理、网络操作、磁盘文件系统、权限管理、用户登录信<E5BD95><E4BFA1>、系统管理
|
||||
- **如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64** — Linux 服务器架构类型（x86_64 与 ARM64）的 4 种命令行检测方法（uname、lscpu、/proc/cpuinfo、file）
|
||||
- **在Synology NAS上安装CloudDrive2** — 在 Synology NAS 上安装配置 CloudDrive2 挂载阿里云盘，通过套件中心安装，使用 Docker 部署，配置阿里云盘扫码授权
|
||||
|
||||
- **固定机位** — 摄像机位置固定不变，是视频画面统一和连贯的基础，家装短视频成功的三大关键词之一
|
||||
- **内容连续变化** — 视频主体信息随时间持续发生明确阶段性变化，家装短视频成功的三大关键词之一
|
||||
- **时间压缩** — 将长时间拍摄过程在视频中浓缩表现的手法，家装短视频成功的三大关键词之一
|
||||
- **分镜拆解** — 将视频内容拆分成多个画面阶段描述的过程，AI 视频制作流程的起始步骤
|
||||
- **九宫格法** — 同时生成 3×3 共九个分镜画面，保证机位与角度不变，画面一致性强
|
||||
- **首尾针动画** — 通过两个关键帧（首针和尾针），AI 自动补齐中间动作，生成连贯动画的技术
|
||||
- **快节奏剪辑** — 视频使用 2-4 倍速加速和硬切手法，强化节奏感与流畅度
|
||||
- **卡点** — 画面变化与音乐节奏巧妙同步，提高观看体验
|
||||
|
||||
- **AI 工具分类** — 大脑类（XAR GPT、GEMALA）、设计师类（Midjourney、Nano Banana）、动效类（海螺AI、KAI）
|
||||
- **Synology NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台** — 利用群晖NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台（Docker 部署、Xiaoya 获取云盘资源、CloudDrive2 挂载为本地磁盘、Plex 媒体刮削）
|
||||
- **Cloud Operating Model: Key Strategies and Best Practices** — 云运营模型（COM）四大支柱：治理、自动化、安全、成本管理，涵盖行业用例（金融、医疗、零售、SaaS）和未来趋势（AI 驱动运维、可持续云计算、多云策略）
|
||||
|
||||
- **Serverless Computing（无服务器计算）** — 云原生架构模式，AWS 负责基础设施运维，客户只需编写业务代码，实现按需付费和自动扩展
|
||||
- **用Docker中安装Navidrome** — 使用 Docker Compose 部署 Navidrome 音乐流媒体服务器的配置文件示例
|
||||
- **Modern ITSM: Driving Efficiency, Security & Resilience** — 现代 IT 服务管理的演进趋势，AIOps、零信任架构、Policy-as-Code 等技术的应用
|
||||
- **How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets** — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案，通过 EventBridge 跨账号事件转发 + CloudWatch Logs 实现单一管理界面监控（[旧版](sources/how-to-simplify-multi-account-deployments-monitoring.md)）
|
||||
- **Public vs Private vs Hybrid: Cloud Differences Explained** — 公有云、私有云和混合云三种部署模式的核心区别，包括各模式的优势、劣势、适用场景，以及云计算共享责任模型
|
||||
- **How Agentic AI can help for Cloud DevOps** — Agentic AI 增强 Cloud DevOps 的七大领域：自主事件检测与响应、自动化云部署与配置、智能成本优化、AI 驱动安全与合规、智能日志分析与可观测性、SaaS 多租户管理、AI 辅助决策
|
||||
- **How Can a Multi Cloud Strategy Transform Your Business ROI?** — 多云策略的定义、8大优势（避免供应商锁定、弹性可靠性、安全性、可扩展性、成本优化、创新访问、合规性、性能优化）、实施4步骤、3个行业用例（电商、医疗、金融）
|
||||
- **The Myths and Misconceptions About Cloud Computing | LinkedIn** — 云计算7大常见误解与真相（安全性、成本、迁移复杂性、性能、数据控制、适用规模）
|
||||
- **What I know about Cloud Service Delivery 1** — 云服务交付的完整定义
|
||||
- **DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation** — DevOps 文化转型方法论，涵盖四大支柱、敏捷整合、转型战略及未来趋势（AI/ML、GitOps、Serverless DevOps、Edge IoT DevOps、DevSecOps）
|
||||
- **Cloud DevOp Maturity - Guideline** — 企业级 SaaS 公司的 DevOps 成熟度评估框架（自动化、协作、监控、安全四大支柱）
|
||||
- **Cloud Maturity Model A Detailed Guide For Cloud Adoption** — 云成熟度模型的详细指南，涵盖5个成熟度等级（0-4：无云准备到优化级）、16个业务能力领域和18个技术能力领域，以及实施最佳实践
|
||||
- **DevOps Maturity Model From Traditional IT to Advanced DevOps** — DevOps 成熟度五级框架详解（初始/应急→局部DevOps→自动化与定义→高度优化→完全成熟），涵盖文化与战略、自动化、结构与流程、协作与共享、技术五大评估领域，以及安全集成方法和常见障碍分析
|
||||
|
||||
- **What is DevSecOps? Best Practices, Benefits, and Tools** — DevSecOps 方法论详解（SDLC 安全集成、SAST/SCA/IAST/DAST 四大工具、Shift Left/Right 策略、企业实施挑战）
|
||||
- **CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)** — 三道防线框架与云安全态势管理，CSPM 统一监控多云账户安全配置，Cloud Guard 解决方案
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration** — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab，self-serve 模式
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - GIS Security Policies** — OpenText 全球信息安全团队（GIS）的安全策略框架与组织结构，基于 ISO 27001 的分层安全方法
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Applicable Business Analysis Techniques** — OpenText 业务分析技术学习会议，介绍 BOSCARD（背景、目标、范围、约束、假设、风险、角色、可交付成果）、相关方轮盘和需求收集方法（T 型技能、用户故事 + 元数据、SAFe 框架）
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Serverless Computing** — AWS 无服务器计算学习会议，涵盖 Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2** — 事件驱动架构（EDA）最佳实践：Sparse vs Full State Events、幂等性、事件排序保障、团队独立性、扇出模式、竞争消费者模式
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering** — AWS 生成式 AI 服务与提示词工程基础，涵盖 RAG、微调、提示词组件与技巧
|
||||
|
||||
- BOSCARD（Background、Objectives、Scope、Constraints、Assumptions、Risks、Roles、Deliverables）：定义复杂新工作的系统化技术，帮助在项目早期明确范围、目标和可交付成果，避免目标、时间线和交付物的混淆
|
||||
|
||||
- **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份，涵盖 NFS 永久挂载和灾难恢复
|
||||
|
||||
- **CTP Topic 46 NetApps on AWS** — NetApp Cloud Volume ONTAP (CVO) 架构、部署、数据分层（EBS→S3）、安全加密与灾备（SnapMirror）
|
||||
|
||||
- **CTP Topic 49 Container Lifecycle Hardening Standards** — Micro Focus 容器生命周期加固标准，构建阶段 11 项安全最佳实践（基础镜像、init 系统、敏感信息管理、只读文件系统、镜像扫描等）
|
||||
|
||||
- **CTP Topic 37 Secrets Certificates Management** — 云转型项目密钥与证书管理方案选型，评估 AWS Secrets Manager、HashiCorp Vault、CryptoArk PAM，30天试点后选择 AWS Secrets Manager
|
||||
|
||||
- **CTP Topic 34 Azure Landing Zone Architecture Overview** — Azure Landing Zone 架构设计，Management Groups 四区域划分、Subscription 分离、Terraform Cloud 自动化
|
||||
- **CTP Topic 7 SaaS Landing Zone Design** — 生产环境 SaaS Landing Zone 高级设计，单一 Landing Zone 策略、Core/Baseline/Shared Services 账户分离
|
||||
- **CTP Topic 5 AWS Identity and Access Management (IAM)** — AWS IAM 用户、组、角色和策略管理，联合访问与权限控制，最小权限原则
|
||||
|
||||
- **EKS Auto Mode** — AWS EKS 自动模式，自动管理 Kubernetes 数据平面的计算、网络、存储和安全
|
||||
|
||||
- **CTP Topic 64 Scaling out with Amazon EKS** — Amazon EKS 水平扩展与垂直扩展机制，涵盖 HPA、KEDA、Karpenter、Cluster Autoscaler、IPv6 网络解决方案
|
||||
|
||||
- **Bottlerocket OS** — 专为容器设计的最小化 Linux 操作系统，AWS 维护，开源免费，通过变体满足特定工作负载需求，具备安全更新和不可变根文件系统
|
||||
|
||||
- **CTP Topic 11 AD Integration and Login using AD accounts** — Jenkins 与 AD 集成实现自动登录，pre-commit 框架嵌入 terraform fmt、TFLint、Checkov 自动化安全检查，左移治理模式
|
||||
- **CTP Topic 3 Deploy and maintain infrastructure** — CTP 云转型计划基础设施部署与维护，Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
|
||||
|
||||
- **CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments** — Atlantis 替代 Jenkins 进行基础设施自动化部署，开源自托管 Terraform CI/CD 工具，通过 GitHub PR 评论触发 plan/apply，支持并行构建和目录锁定
|
||||
- **CTP Topic 40 SaaS Database Architecture On AWS Cloud** — AWS 云上 SaaS 数据库架构设计，SaaS 数据库团队全球运维实践（500+ 数据库、1000+ 服务器，Oracle/Postgres/DynamoDB 等多种数据库，高可用设计）
|
||||
- **CTP Topic 28 AWS Tag Validation Tool** — AWS 标签验证工具，通过 YAML 配置文件审计资源标签合规性，生成 CSV 报告
|
||||
- **CTP Topic 30 Managing Change** — 云转型项目中的变更管理流程，SRE 角色定义和三种变更类型（标准变更、正常变更、紧急变更）
|
||||
- **CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program** — AWS Backup 在 CTP 云转型计划中的实施，涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
|
||||
- **Public Cloud Learning Sessions - Reducing Cloud Costs** — 云成本优化策略，涵盖工作负载优化（现代化+Right Sizing）和费率优化（Savings Plans、预留实例、Spot 实例），FINOPS 团队分享
|
||||
|
||||
- **CTP Topic 71 PCG's Guide to RightSizing, Why, How, When** — AWS 资源优化（Right Sizing）的全面指南，涵盖为什么需要做、如何做、什么时候做三大维度
|
||||
|
||||
- **FinOps** — 云财务运营实践，整合财务管理与云资源优化，实现云支出可见性、控制和持续优化
|
||||
- **Budget Control** — AWS账户预算控制自动化，提供四级警报类型（forecast、actual、severe、enforcement）和详细成本报告（top services、top users），通过SCP限制资源创建实现成本控制
|
||||
- **Storage Cost Optimization** — AWS 存储服务（EBS、EFS、FSx、S3）成本优化，通过选择正确存储类型、使用生命周期策略和智能分层降低存储成本
|
||||
- **Right Sizing** — 识别正确资源规格匹配工作负载需求，通过 EC2 Right Sizing 推荐报告、实例调度、闲置资源清理实现成本节省
|
||||
- **Instance Scheduling** — 实例定时调度工具，通过预设时间规则自动控制 EC2 和 RDS 实例启停，实现非生产环境成本优化
|
||||
- **Rate Optimization** — 基于承诺使用（1-3年）获取折扣，AWS 提供 Savings Plans 和 Reserved Instances，最低交易价值每年 5,000 美元
|
||||
|
||||
- **CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana** — AWS 云监控与 Grafana 可观测性平台集成，Terraform 模块自动创建 Grafana 组织、仪表板，Optic DR 数据源集成，告警转发 OpsBridge
|
||||
- **CTP Topic 62 AWS Secrets Manager** — AWS Secrets Manager 企业级敏感信息管理，分阶段实施方法（集中化→自动化获取→轮换），Lambda 数据库密码轮换，JDBC Wrapper 无密码登录
|
||||
|
||||
- **CTP Topic 67 Cloud Native Observability Using OpenTelemetry** — 云原生可观测性方案，基于 ADOT 在 EKS 上的部署实践（sidecar、daemonset、HA 模式）
|
||||
|
||||
- **Public Cloud Learning Sessions - Observability with OpenTelemetry** — OpenTelemetry 可观测性框架在 AWS 环境中的应用，涵盖 Metrics、Logs、Traces 三大信号，ADOT 统一代理自动检测应用语言
|
||||
|
||||
- OpenTelemetry（OTel）：厂商中立的遥测数据采集框架，提供统一数据格式和 11 种语言 SDK，解决不同组件各自为政的 SDK 问题
|
||||
- **CTP Topic 54 ESM SaaS Log Analytics** — ESM SaaS Log Analytics（日志分析）架构与实践，ELK Stack/OpenSearch 架构，BEATS 采集日志，VPC 私有传输，安全加密（TLS 1.2、静态加密），成本对比（Logz.io $4,000 vs AWS OpenSearch $1,500），GDPR 合规驱动区域部署
|
||||
|
||||
- **CTP Topic 55 AWS Firewall Manager** — AWS Firewall Manager 多账号安全策略集中管理，跨 Landing Zone 安全组统一配置，支持三种策略类型（通用安全组、审计强制、清理未使用），通过 AWS Config + Lambda 实现自动修复
|
||||
|
||||
- **CTP Topic 57 Product backlog managing demand** — Product Backlog 管理需求流程，SMACs 提交、Octane 入池、前置条件阶段
|
||||
- **CTP Topic 21 Supply Chain Security in Micro Focus** — Micro Focus 软件供应链安全的新方法，将供应链安全作为 SDL 第五大支柱
|
||||
- **CTP Topic 24 Micro Focus Product Privacy Framework** — Micro Focus 产品隐私框架，将 GDPR/CCPA 法律条款翻译为约 110 项具体技术要求，通过成熟度模型评估合规现状
|
||||
- **CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge** — 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 云监控的实施方案（IAM Role 跨账户访问、Management Packs 动态监控）
|
||||
- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — 在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
- **Ubuntu 禁用合盖休眠** — 在 Ubuntu 24.04 中通过修改 systemd-logind 配置禁用笔记本合盖休眠行为
|
||||
- **群晖NAS科学上网方法** — 在群晖 NAS 上通过 V2RayA 配置透明代理，使 Docker 可以科学上网
|
||||
- **RAX50 路由器更新 Merlin Clash 订阅指南** — RAX50 路由器 Merlin Clash 订阅更新教程
|
||||
- **用Docker安装it-tools** — 使用 Docker 部署 it-tools 运维工具集合
|
||||
- **用Docker安装Jellyfin** — 使用 Docker 部署 Jellyfin 媒体服务器的配置文件示例
|
||||
- **用Docker安装transmission** — 使用 Docker 部署 Transmission BT 下载客户端的配置文件示例
|
||||
- **3X-UI Xray on BandwagonVPS** — 在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务
|
||||
- **可自动化、可扩展、AI增强的电商数据采集与处理系统** — 基于 Docker + n8n + Scrapy + Playwright 的电商数据采集与处理系统设计
|
||||
- **n8n Docker install & update** — n8n 工作流自动化工具的 Docker 部署与网络代理配置（SOCKS5 代理、Docker 网桥）
|
||||
- **n8n configure telegram trigger** — n8n Telegram Trigger 配置问题排查与解决，通过设置 WEBHOOK_URL 环境变量为 HTTPS URL 解决 Telegram Webhook 必须使用 HTTPS 的要求
|
||||
- **TikTok PM - Python Django Project** — TikTok 产品管理系统（Django Web 应用），涵盖 Django Admin 定制、DRF API、异步任务、Docker 部署完整指南，涵盖爬虫工具对比、Docker 架构、n8n 自动化流程、AI 处理建议
|
||||
- **N8N Full Tutorial Building AI Agents in 2025 for Beginners!** — N8N 平台构建 AI Agent 入门教程（Agentic Systems 定义、节点分类、工具集成、上下文记忆、Airtable 集成）
|
||||
- **Semantic Memory Search** — 为 OpenClaw 添加向量语义搜索能力，解决 markdown 内存文件的语义检索问题
|
||||
- **养虾日记2：让Agent更懂你** — AI Agent 记忆问题的解决方案，通过 self-improving skill + 双层记忆架构 + 每日复盘机制实现 Agent 持续学习和改进，核心价值：错误只犯一次，第二次就知道怎么做对
|
||||
- **不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南** — AI 时代产品经理能力重塑，Gemini 赋能 PRD 生成工作流
|
||||
|
||||
- **Obsidian 必装 Skills** — Obsidian 必装的 AI Skills 推荐与配置指南，推荐 9 个核心 Skills（defuddle、obsidian-cli、obsidian-bases、obsidian-markdown、obsidian-canvas-creator、mermaid-visualizer、excalidraw-diagram、tutor-skills、scholar-skill）和 2 个核心插件（claudian、obsidian-agent-client）
|
||||
1|# Wiki Overview
|
||||
2|
|
||||
3|## 主题领域
|
||||
4|AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境电商
|
||||
5|
|
||||
6|## 核心概念
|
||||
- Healthcare Marketing Compliance Specialist：The Agency 中负责中国医疗健康营销合规的专家智能体，覆盖医疗广告、互联网医疗、医美、保健品与隐私合规
|
||||
7|- The Agency：开源 AI 智能体集合项目，汇集各类专业化 AI Agent
|
||||
8|- Image Prompt Engineer：The Agency 项目中的 AI 图像生成提示词工程专家智能体，专注于将视觉概念转化为精确的提示词语言
|
||||
- Cultural Intelligence Strategist：The Agency 中负责检测 invisible exclusion、推动 global-first 设计与文化谦逊研究的专家智能体
|
||||
9|- Agentic Identity & Trust Architect：The Agency 中负责自治 AI Agent 身份、授权、证据链与信任评分的专家智能体
|
||||
10|- 智能体设计规范：智能体文件结构、身份与记忆、核心使命、技术交付物、工作流程的完整定义
|
||||
11|- 智能体设计原则：六大设计原则（鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆、真实场景测试）
|
||||
12|- UX Architect：The Agency 项目中的技术架构与 UX 专家智能体，为开发者提供 CSS 设计系统、布局框架、主题切换机制和清晰实现路径
|
||||
13|- UI Designer：The Agency 项目中的 UI 设计智能体，专门负责创建美观、一致、可访问的用户界面，提供设计系统、组件库和像素级界面实现
|
||||
14|- UX Researcher：The Agency 项目中的用户体验研究智能体，专注于用户行为分析、可用性测试和数据驱动的设计决策验证
|
||||
15|- Brand Guardian：The Agency 项目中的品牌战略与身份保护专家智能体，专注于品牌基础框架、视觉识别系统、品牌一致性与价值保护
|
||||
16|- Paid Media Programmatic & Display Buyer：The Agency 项目中的付费媒体程序化购买与展示广告智能体，专注于 DSP 平台管理、Google 展示网络、ABM 展示执行和合作伙伴媒体策略
|
||||
17|- Paid Media PPC Campaign Strategist：The Agency 项目中的付费媒体 PPC 智能体，负责大规模搜索、购物和效果最大化广告系列架构设计
|
||||
18|- Paid Media Ad Creative Strategist：The Agency 项目中的付费媒体广告创意策略智能体，专注于广告文案撰写、响应式搜索广告（RSA）优化和创意测试框架
|
||||
19|- Paid Media Auditor：The Agency 项目中的付费媒体审计智能体，系统化评估 Google Ads、Microsoft Ads 和 Meta 广告账户，识别 15-30% 效率提升机会
|
||||
20|- Paid Media Paid Social Strategist：The Agency 项目中的付费社交媒体广告智能体，跨平台覆盖 Meta、LinkedIn、TikTok 等
|
||||
21|- Paid Media Tracking & Measurement Specialist：The Agency 项目中的付费媒体追踪与测量专家智能体，专注于 GTM 容器架构、GA4 事件设计、服务端标记和跨平台转化归因
|
||||
22|- Search Query Analyst：The Agency 项目中的付费搜索查询分析智能体，专注于搜索词报告挖掘、N-gram 分析、否定关键词架构和查询意图映射，可消除 10-20% 非转化支出
|
||||
23|- Sales Discovery Coach：The Agency 项目中的销售发现方法论指导智能体，教导销售团队通过提问、当前状态映射、差距量化和电话结构发现真正购买动机
|
||||
24|- Outbound Strategist：The Agency 项目中的基于信号触发的外呼销售策略智能体，通过购买信号识别、多渠道序列设计和 ICP 定义提升外呼转化率
|
||||
25|- 信号驱动销售：基于购买信号（Intent Signal）触发外呼的销售方法论，比无差别冷外呼转化率高 4-8 倍
|
||||
26|- Deal Strategist：The Agency 项目中的销售交易策略智能体，专注于 MEDDPICC 资格认证、竞争定位和赢单规划
|
||||
27|- Proposal Strategist：The Agency 项目中的销售提案策略智能体，将 RFP 响应转化为制胜叙事，擅长制胜主题开发、三幕式提案叙事和竞争定位
|
||||
28|- Sales Account Strategist：The Agency 项目中的售后账户策略专家智能体，专注于 Land-and-Expand 执行、利益相关者映射、QBR 设计和净收入留存
|
||||
29|- Pipeline Analyst：The Agency 项目中的销售管道健康诊断智能体，专注于交易速度分析、管道健康评估和收入预测准确性，将 CRM 数据转化为可操作情报
|
||||
30|- Studio Producer：The Agency 项目中的 Studio Producer Agent，资深战略领导者，专注于高层次创意与技术项目编排、资源配置和多项目组合管理，将创意愿景与业务目标对齐
|
||||
31|- Project Shepherd：The Agency 项目中的专业项目管理人员智能体，专注于跨职能项目协调、时间线管理和利益相关方对齐，确保 95% 项目按时在预算内交付
|
||||
32|- 项目章程：定义项目目标、范围、成功标准和治理结构的标准化文档模板，是项目启动阶段的核心交付物
|
||||
33|
|
||||
34|- Senior Project Manager：将规格文件转化为开发可执行的任务清单，强调现实的范围设定、每项任务的可实施时间（30–60 分钟）并保存任务清单以支持后续项目记忆与改进
|
||||
35|
|
||||
36|- XR Immersive Developer：The Agency 项目中的 WebXR 沉浸式技术开发专家，专注于基于浏览器的 AR/VR/XR 应用开发
|
||||
37|- XR Cockpit Interaction Specialist：The Agency 项目中的 XR 座舱交互专家智能体，专注于设计和开发 XR 环境的沉浸式座舱控制系统
|
||||
38|- XR Interface Architect：The Agency 项目中的 XR 界面架构师智能体，专注于沉浸式 3D 环境的空间界面设计，关注最小化晕动症和增强临场感
|
||||
39|- macOS Spatial/Metal Engineer：The Agency 项目中的 macOS 空间计算与 Metal 渲染工程师智能体，专注于 Native Swift 和 Metal 高性能 3D 渲染，支持 Vision Pro 远程沉浸式空间集成
|
||||
40|- visionOS Spatial Engineer：The Agency 项目中的 visionOS 空间计算原生开发专家智能体，专注于 Native visionOS 空间计算、SwiftUI 体积化界面和 Liquid Glass 设计实现
|
||||
41|- Terminal Integration Specialist：The Agency 项目中的终端仿真和 SwiftTerm 集成专家智能体，专注于终端仿真、文本渲染优化和 Swift 应用集成
|
||||
42|- 空间计算（Spatial Computing）：一种计算范式，通过将数字内容与物理空间无缝融合，使用户能够与计算机生成的环境进行自然交互
|
||||
43|- WebXR：W3C 制定的浏览器标准接口，用于提供沉浸式 VR 和 AR 体验
|
||||
44|- 账户架构：PPC 广告活动的组织结构设计，涵盖活动结构、广告组分类、标签系统、命名规范，可实现 10K 到 10M+ 月预算的可扩展投放
|
||||
45|- 自动化出价策略：PPC 广告平台的智能出价优化机制，包括 tCPA、tROAS、Max Conversions、Max Conversion Value 等策略
|
||||
46|- 绩效最大化：Google Ads 的自动化全渠道投放类型，通过机器学习在全渠道自动优化广告投放
|
||||
47|- 程序化购买：通过 DSP 平台自动化采购展示广告库存的技术，实现实时竞价和效果优化
|
||||
48|- 展示广告：在第三方网站、应用和社交媒体上呈现的视觉广告，侧重品牌建设和潜在客户获取
|
||||
49|- 可见度标准：衡量数字广告是否真正被用户看到的指标（MRC 标准：70%+ 可见展示）
|
||||
50|- Pull Request 流程：从提交前准备到 PR 审核的完整流程（社区评审、迭代优化、通过审核、合并上线）
|
||||
51|- Print Mode：Hermes 通过 stdin 调用 Claude Code 的非交互执行模式
|
||||
52|- TMUX 交互模式：在 TMUX 会话中运行 Claude Code 的交互模式，适合超长任务
|
||||
53|- DeepSeek：中国 AI 公司开发的大语言模型，以开源和高效著称，DeepSeek-R1 在复杂任务处理方面表现出色
|
||||
54|- 提示语设计：通过精心设计的提示词提升 AI 输出质量的技术
|
||||
55|- Prompt Library：提示词库，提供现成提示词供用户参考和定制
|
||||
56|- Prompt 能力：结构化思维+精准表达能力，包含需求拆解、结构化表达、场景共情、迭代优化四个维度
|
||||
57|- Nano Banana Pro：Google 的专业级图像生成模型，具备物理规则推演、构图美学理解、语义上下文推理能力
|
||||
58|- Nano Banana 2：Google 的推理型图像生成模型（Gemini 3 Pro Image），支持 1K/2K/4K 分辨率，可组合 14 张输入图像，具备多语言长文本渲染和最新知识支持能力
|
||||
59|- AI幻觉：AI 生成看似合理但实际错误的内容，需通过技巧避免
|
||||
60|- Wayland：Linux 桌面环境的现代显示协议，Ubuntu 24.04 默认使用，出于安全限制外部程序在未登录状态下获取屏幕控制权
|
||||
61|- X11 (Xorg)：传统 Linux 显示协议，兼容性更好，支持远程桌面软件，是 Wayland 的替代方案
|
||||
62|- GDM3：GNOME Display Manager，Ubuntu 的登录管理器，支持 Wayland 和 X11 两种显示协议
|
||||
63|- ITSM（IT 服务管理）：从工单系统演进为战略推动者，实现运营卓越、风险缓解和创新加速
|
||||
64|- Identity Governance（身份治理）：管理数字身份、降低风险并保持合规的框架，回答谁有权访问、谁应该访问、如何访问三个核心问题
|
||||
65|- Multi-Account Strategy（多账号策略）：AWS 推荐的企业级云架构模式，通过将工作负载分离到多个 AWS 账号来提升安全性、治理能力和故障隔离
|
||||
66|- Gruntwork Landing Zone：Gruntwork 提供的预配置 AWS 基础架构框架，基于 Reference Architecture 包含核心账户和工作负载账户
|
||||
67|- Landing Zone：云着陆区，标准化的多账户基础架构框架，用于托管产品团队的工作负载
|
||||
68|- Terraform：基础设施即代码工具，通过声明式配置定义云资源，实现跨平台基础设施管理
|
||||
69|- Terragrunt：Terraform 的包装工具，提供模块化、变量共享和环境隔离，跨多账户部署
|
||||
70|- TerraTest：Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 流程
|
||||
71|- Test-Driven Development：测试驱动开发方法论，先写测试再实现功能
|
||||
72|- Service Catalog：服务目录，封装业务需求的模块分组，提供服务级别抽象，实现跨团队复用
|
||||
73|- Module：Terraform 模块，可复用的基础设施配置单元
|
||||
74|- ECS (Elastic Container Services)：AWS 专有容器编排服务，与 AWS 服务深度集成，支持自动扩展、自动修复和金丝雀部署
|
||||
75|
|
||||
76|- AWS SES (Simple Email Service)：AWS 提供的基于云的邮件发送服务，支持 API 或 SMTP 接口发送邮件，通过 VPC 终端节点实现私有访问
|
||||
77|
|
||||
78|- VPC Endpoint：AWS 私有网络连接服务，允许 VPC 中的资源安全访问 AWS 服务而不经过公网
|
||||
79|
|
||||
80|- Secrets Manager：AWS 凭证管理服务，用于安全存储和检索敏感信息
|
||||
81|
|
||||
82|- DKIM (DomainKeys Identified Mail)：电子邮件验证标准，通过数字签名确保邮件完整性和发件人身份
|
||||
83|
|
||||
84|- CCOE（Cloud Center of Excellence）：推动云采纳和治理的核心组织单元，负责 AMI 标准制定和发布
|
||||
85|
|
||||
86|- OpsBridge（运营桥）：Micro Focus 的企业级监控平台，支持 AWS 云监控，可部署在本地或 EKS 上
|
||||
87|- Cloud Monitoring（云监控）：OpsBridge 的核心功能，支持监控 20+ AWS 数据服务
|
||||
88|- Optic Data Lake：OpsBridge 的数据存储层，使用 Vertica 数据库支撑高性能仪表板
|
||||
89|
|
||||
90|- AWS Workspaces：AWS 提供的托管桌面即服务（DaaS）解决方案，预装开发工具实现快速生产力
|
||||
91|
|
||||
92|- Standard AMI：AWS 标准机器镜像，包含 OS 加固、最新安全补丁，并支持域集成、SSM agent、DNS 设置，每两个月发布一次
|
||||
93|- Cloud Guardrails：云守护栏，捕获可扩展性、成本最小化和灵活性的强制性要求和最佳实践
|
||||
94|- Tagging Methodology：标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
|
||||
95|- IPAM（IP Address Management）：IP 地址管理工具，用于规划、追踪和管理 IP 地址空间，实现 VPC IP 地址自动化分配
|
||||
96|- RTO（Recovery Time Objective）：系统允许的最大停机时间，是灾难恢复的核心指标
|
||||
97|- RPO（Recovery Point Objective）：可接受的最大数据丢失量，是数据保护的核心指标
|
||||
98|- Feature Flag（特性开关）：控制代码路径而不需要重新部署的机制，实现秒级回滚和低 RTO/RPO
|
||||
99|- 开源平替：功能可替代闭源商业产品的开源项目
|
||||
100|- Cloud Maturity Model（云成熟度模型）：评估组织云采纳就绪程度的5级框架
|
||||
101|- DevOps 成熟度模型：评估组织 DevOps 实践水平的分级框架
|
||||
102|- DevOps 文化：打破开发与运维壁垒，优先协作、持续学习和客户导向的文化理念
|
||||
103|- CI/CD 流水线：自动化测试、集成和部署的持续交付管道
|
||||
104|- Infrastructure as Code (IaC)：通过代码实现一致性、版本控制的基础设施管理
|
||||
105|- Renovate Bot：开源依赖自动化更新工具，通过扫描代码并自动提交 PR 保持依赖项处于最新状态
|
||||
106|- 敏捷实践：Scrum、Kanban 等迭代开发方法论
|
||||
107|- 事件驱动项目管理：使用数据库存储项目状态和历史事件，通过 AI Agent 自然语言交互替代静态 Kanban 看板
|
||||
108|- LLM Wiki：LLM 持续编译和维护的持久化 wiki，将 raw source 逐步沉淀成可追溯、可交叉引用的知识资产
|
||||
109|- 内网穿透（NAT Penetration）：将内网服务通过公网服务器暴露给外部访问的技术，FRP 是常用方案之一
|
||||
110|- Workspace：OpenClaw 中 Agent 的工作台目录，包含 AGENTS.md、SOUL.md、USER.md、IDENTITY.md、TOOLS.md、BOOTSTRAP.md、memory/ 等配置文件
|
||||
111|- Memory 目录：OpenClaw 的长期记忆机制，按日期滚动存储跨会话积累的信息
|
||||
112|- Apache Superset：Apache 软件基金会旗下的开源 BI 平台，支持数据可视化、仪表盘和 SQL 探索
|
||||
113|- Superset Dashboard：Apache Superset 数据可视化仪表盘，包含图表、过滤器、布局的完整组合
|
||||
114|- SQL View：预处理的数据库视图，用于解析 JSON 字段和计算派生指标
|
||||
115|- KPI 卡片：关键绩效指标可视化展示（总产品数、热卖产品数、平均评分等）
|
||||
116|- 选品评分模型：通过加权公式自动推荐优质产品的算法（score = sold × 0.4 + rating × 12 + rating_count × 0.2 + discount_percent × 0.5）
|
||||
117|- 单一职责：每个文件、类、函数只负责一件事的设计原则
|
||||
118|- DRY 原则：Don't Repeat Yourself，避免重复代码的核心原则
|
||||
119|- 微服务：独立开发、独立部署、独立扩容的架构模式
|
||||
120|- 消息队列：服务间异步通信的中间件技术，实现解耦和削峰填谷
|
||||
121|- Obsidian 插件组合：根据不同使用场景将 Obsidian 核心插件进行合理搭配的策略（知识管理流、任务管理流、学习研究流）
|
||||
122|- Graph View：Obsidian 的知识网络可视化，发现孤立页面和知识盲区
|
||||
123|- 版本控制：Git 管理笔记历史变更，每次更新对应 commit
|
||||
124|- 信息黑洞：只收集不使用的笔记困境，通过连接和复盘解决
|
||||
125|- 通过 VPS+内网反向代理实现域名访问内网穿透 — 使用 FRP+Caddy 实现内网服务穿透，Aliyun DNS 域名管理
|
||||
126|- n8n-mcp：连接 n8n 与 AI 模型的桥接项目，提供 543 个 n8n 节点访问能力，支持自然语言生成工作流
|
||||
127|- Last-30-Days-Skill：Matt Van Horn 开发的多平台热门内容研究技能，支持 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket、Web 共 8 个数据源
|
||||
128|- Market-Research：通过用户反馈和数据分析识别产品机会的过程
|
||||
129|- 通才：跨领域知识整合者，拥有广泛兴趣和多元能力的人才
|
||||
130|- 第二次文艺复兴：AI时代每个人可以追求多领域精通
|
||||
131|- 品牌作为环境：品牌是小世界而非头像和简介
|
||||
132|- 记忆后端（Memory Backend）：AI 记忆工具的 Camp 1 方案，从对话中提取事实存储到向量数据库
|
||||
133|- 上下文基质（Context Substrate）：AI 记忆工具的 Camp 2 方案，通过维护结构化文件实现上下文累积
|
||||
134|
|
||||
135|- WSL2：Windows Subsystem for Linux 2，Windows 上的 Linux 兼容层
|
||||
136|- 镜像网络模式：WSL2 与 Windows 共享网络堆栈的配置模式
|
||||
137|- .wslconfig：WSL2 全局配置文件，位于用户目录
|
||||
138|- Ikigai：热爱的、擅长的、市场需要的、能获得报酬的四者交集
|
||||
139|- 天才地带：能产生心流的区域，时间飞逝精力充沛
|
||||
140|- 底层能力：隐藏在活动表象下的核心能力
|
||||
141|- 产品体系：引流→入门→核心→高价四级产品矩阵，客户信任逐步建立
|
||||
142|- 内容矩阵：核心主题×内容形式的二维内容策略，一次制作百次<E799BE><E6ACA1><EFBFBD>发
|
||||
143|- 销售漏斗：获客→激活→转化的客户转化路径
|
||||
144|- Task Automation：自动将任务创建过程从手动操作转化为系统执行的机制
|
||||
145|- Agent Task Visibility：AI Agent 任务对用户的透明化展示机制，通过外部工具实时展示任务状态、进度和内部推理过程
|
||||
146|- 习惯追踪与问责伙伴：AI Agent 定时主动检查用户习惯完成情况，通过 Telegram/SMS 实现主动问责，追踪连续打卡并自适应调整提醒语气
|
||||
147|- 品味：能判断AI方案中哪个是insanely great的能力，AI时代的核心竞争力
|
||||
148|- 端到端：从想法到产品的完整控制权，不做流水线零件
|
||||
149|- 死亡过滤器：每天问自己"如果今天是最后一天，我还会做今天要做的事吗？"，用于聚焦真正热爱的事
|
||||
150|- 数字导师：用AI复活历史人物，让其成为日常对话的思维顾问，通过思维蒸馏技术提取人物的核心心智模型
|
||||
151|- 思维蒸馏：通过6个并行Agent从6个维度（著作、对话、表达DNA、他者视角、决策、时间线）采集信息，提炼核心思维框架生成AI Skill的技术
|
||||
152|- Claude Skills：写给 Claude 的"说明书"和技术规范，将反复执行的任务拆解为 AI 可稳定复用流程的技术范式
|
||||
153|- Document Generation：通过代码和模板生成 PDF、PPTX、XLSX、DOCX 等专业文档的自动化工作流
|
||||
154|- **baoyu-skills**：宝玉分享的 Claude Code 技能集，提供内容生成（小红书图片、信息图、封面图、幻灯片、漫画、文章插图）、AI 生成（多服务商图像生成）、工具（YouTube 字幕下载、URL 转 Markdown、社交媒体发布）17+ 个技能
|
||||
155|- Zettelkasten：卢曼卡片盒知识管理系统，通过原子化笔记和索引入口构建知识网络
|
||||
156|- **fireworks-tech-graph**：AI 驱动技术图生成工具，将中文描述转化为 SVG/PNG 格式的架构图、流程图、UML 图
|
||||
157|
|
||||
158|- Foundation Model（基础模型）：具有数十亿参数的大规模预训练模型，是生成式 AI 的核心
|
||||
159|- Amazon Bedrock：AWS 全托管服务，用于使用基础模型构建生成式 AI 应用
|
||||
160|- Amazon SageMaker：AWS 机器学习平台，用于构建、训练和部署模型
|
||||
161|- ML Ops：机器学习运维，结合 ML 和 DevOps 实践
|
||||
162|- Fine-Tuning：使用标记数据集定制基础模型
|
||||
163|- Responsible AI：负责任 AI，包括公平性、可解释性、健壮性、治理、透明度和隐私/安全
|
||||
164|
|
||||
165|- 开源大语言模型：以 DeepSeek、Qwen 为代表的开源基座大模型
|
||||
166|- AI生图模型：以 Flux、Stable Diffusion 为代表的开源图像生成模型
|
||||
167|- AI生视频模型：以 HunyuanVideo 为代表的开源视频生成模型
|
||||
168|- 模块化Prompt库：将 Prompt 拆分为可复用的独立模块
|
||||
169|- 图生视频：AI 将静态图像转化为动态视频的技术
|
||||
170|- AI智能体：以 Manus/OpenManus 为代表的通用 AI 代理
|
||||
171|- AI编程工具：以 Cline 为代表的 AI 增强代码编辑器插件
|
||||
172|- 智能体工作流：以 n8n、Dify 为代表的工作流自动化平台
|
||||
173|- AI搜索引擎：以 Perplexica 为代表的 AI 搜索开源项目
|
||||
174|- AI知识库：以 NotebookLM 开源平替为代表的 AI 知识管理工具
|
||||
175|
|
||||
176|- LLM（Large Language Model）：大型语言模型，行业以参数规模衡量，通常 ≥1B 参数被称为"大模型"
|
||||
177|- MCP（Model Context Protocol）：模型上下文协议，为 LLM 提供标准化接口，使其能够连接外部数据源和工具
|
||||
178|- Agent 智能体：整合 LLM 与 MCP 工具才能真正执行步骤，而不仅是给出方法
|
||||
179|- Coze（扣子）：字节跳动旗下 AI Agent 开发平台，支持国内版（coze.cn）和海外版（coze.com）
|
||||
180|- Coze Workflow：Coze 平台的工作流模式，支持复杂企业级业务逻辑编排
|
||||
181|- Bot：Coze 平台的对话型 AI 智能体，最基础的智能体开发模式
|
||||
182|- RAG（Retrieval-augmented generation）：检索增强生成，通过检索增强解决 LLM 的幻觉问题
|
||||
183|- 向量嵌入：将文本转换为数值向量，用于语义相似度计算
|
||||
184|- Vector Store（向量数据库）：存储 Embedding Vector 并实现相似度检索的技术（如 Qdrant、Chroma 等）
|
||||
185|- Document Loader：文档加载器，从不同数据源抓取数据（如 LangChain 的 160+ 加载器）
|
||||
186|- Context Window：上下文窗口，Embedding Model 能接受的最大 token 数量（一般 512~8192）
|
||||
187|- Split（文档块）：将长文档切分成的满足 Context Window 要求的文本块
|
||||
188|- LangChain：简化 RAG 管道构建的 Python 框架，提供文档加载、向量存储、链式调用等功能
|
||||
189|- Embedding（向量化）：将词转化为一连串浮点数，计算词与词之间的语义距离
|
||||
190|- vLLM：虚拟大语言模型，通过 PagedAttention 和连续批处理优化 GPU 内存使用
|
||||
191|- Token：大模型的基本输入单元，1 个英文字符 ≈ 0.3 个 token，1 个中文字符 ≈ 0.6 个 token
|
||||
192|- 数据蒸馏（Data Distillation）：利用大模型生成精简数据训练小模型，使其逼近大模型效果
|
||||
193|
|
||||
194|- Source-grounding：NotebookLM 的核心机制，仅使用用户上传的文档作为知识库
|
||||
195|- Audio Overviews：将文档转化为双人 AI 对话播客的功能，适合被动学习
|
||||
196|
|
||||
197|- 递归自优化生成系统（Recursive Self-Optimizing Generative Systems）：通过迭代自修改构建稳定生成能力的系统，目标不是直接产生最优输出，而是收敛到生成器空间的不动点
|
||||
198|- Generator Space：生成器空间 G ⊆ P^I，每个生成器 G: I → P
|
||||
199|- Self-Map：自映射 Φ: G → G，定义单步更新函数
|
||||
200|- Fixed Point：不动点 G*，满足 Φ(G*) = G*，表示系统稳定状态
|
||||
201|- Y Combinator：Y 不动点组合子，用于 λ-calculus 中表达递归自引用
|
||||
202|
|
||||
203|- 自托管 AI Agent 排查思路：不要默认认为错误信息就是表面意思，两层配置要分清（全局 compaction 配置和 agent 模型配置），日志真的有用，工具/系统越复杂，问题的隐藏路径越深
|
||||
204|
|
||||
205|- Self-Healing Systems（自愈系统）：主动检测异常并自动修复的系统，无需人工干预即可恢复正常运行状态
|
||||
206|- Cron Jobs（定时任务）：Linux 基于时间的任务调度机制，AI Agent 通过定时作业实现持续自动化价值
|
||||
207|- Multi-Agent Team（多 Agent 团队）：多 Agent 协作架构，每个 Agent 有独立角色、人格、优化的模型，通过共享内存+私有上下文实现协同
|
||||
208|- 多智能体系统可靠性：层级结构、共识投票、对抗式辩论、淘汰制四种架构模式，将 LLM 视为不可靠组件的工程思维
|
||||
209|- 层级结构 (Hierarchy)：Planner → Worker → Validator 三层架构，通过依赖图强制协作
|
||||
210|- 共识投票 (Consensus)：多数票机制抵消模型随机噪声，3模型同时幻觉概率仅 0.8%
|
||||
211|- 对抗式辩论 (Adversarial Debate)：生成器+批评者+评委三角制衡，模拟人类"恐惧"机制
|
||||
212|- 淘汰制 (Knock-out)：适者生存机制，将 LLM 视为"牲畜"而非"宠物"
|
||||
213|- 可靠性工程：将 LLM 视为分布式系统中不可靠组件的工程方法论
|
||||
214|- Shared Memory（共享内存）：多 Agent 团队共享的上下文，包括目标、决策、项目状态，所有 Agent 可访问
|
||||
215|- 动态仪表盘（Dynamic Dashboard）：通过 Sub-agent 并行获取多数据源（GitHub、Twitter、市场数据、系统健康），定时聚合更新并推送至 Discord 或生成 HTML 仪表盘
|
||||
216|
|
||||
217|- Voice Agent：具备语音交互能力的 AI 代理，能够通过语音对话完成任务
|
||||
218|- AI配音（AI TTS）：使用人工智能技术将文字转化为语音的技术，主流工具包括 ElevenLabs、海螺AI、F5-TTS、TTSMaker、剪映、魔音工坊、AnyVoice
|
||||
219|- 声音克隆（Voice Cloning）：通过少量音频样本训练AI模型，生成与原声相似的语音的技术
|
||||
220|- Byox（Build Your Own X）：通过从零重建22个技术领域掌握编程技能的方法论，核心理念是"What I cannot create, I do not understand"
|
||||
221|
|
||||
222|- X Account Analysis（X 账户分析）：使用 OpenClaw + Bird Skill 获取用户推文并分析发布质量，定性分析替代 X 内置的定量统计
|
||||
223|
|
||||
224|- **一语点醒梦中人** — 中国古代哲学智慧名言解读（王维、曾国藩、老子、庄子、佛陀），涵盖禅意、道法自然、缘起性空等核心概念
|
||||
225|
|
||||
226|- **Goal-Driven Autonomous Tasks** — AI Agent 自主目标驱动任务生成与执行工作流（Brain Dump、每日任务生成、迷你应用构建）
|
||||
227|
|
||||
228|- **Second Brain** — AI Agent 作为个人记忆捕获系统，通过即时通讯（Telegram/Discord/iMessage）零摩擦捕获+Next.js 搜索界面
|
||||
229|
|
||||
230|- **家庭日历聚合与生活助手** — 将 OpenClaw 构建为家庭协调代理，聚合多平台日历、监控消息自动创建日程、管理家庭库存和购物清单
|
||||
231|
|
||||
232|- **Market Research & Product Factory** — AI 辅助创业自动化流水线，通过 Last 30 Days skill 挖掘 Reddit/X 真实痛点，自动构建 MVP
|
||||
233|
|
||||
234|- **Pre-Build Idea Validator** — AI Agent 项目启动前的创意验证机制，通过 idea-reality-mcp 扫描 GitHub、Hacker News、npm、PyPI、Product Hunt 计算竞争度评分
|
||||
235|- **LaTeX Paper Writing** — AI Agent 作为 LaTeX 写作助手，无本地 TeX Live 即可即时编译 PDF，支持 IEEE/beamer/中文模板
|
||||
236|- **Phone-Based Personal Assistant** — 基于电话的 AI 个人助理，通过 ClawdTalk + Telnyx 实现语音访问 OpenClaw
|
||||
237|- **Phone Call Notifications** — AI Agent 通过电话主动呼叫推送重要事项通知（clawr.ing、双向语音对话、Cron Jobs/Heartbeat 触发）
|
||||
238|- **OpenClaw as Desktop Cowork (AionUi)** — AionUi 桌面端协同工作界面，将 OpenClaw 作为一等公民可视化运行，支持远程救援和多 Agent 管理
|
||||
239|
|
||||
240|- **Custom Morning Brief** — AI Agent 定时发送自动化早间简报，覆盖新闻、待办、创意输出和任务推荐
|
||||
241|
|
||||
242|- **Autonomous Educational Game Development Pipeline** — AI Agent 自主管理教育游戏全生命周期（Game Developer Agent、Bugs First 策略、Round Robin 调度、Git 自动化）
|
||||
243|
|
||||
244|- **Multi-Source Tech News Digest** — AI Agent 自动从 109+ 来源（RSS、Twitter、GitHub、Web搜索）聚合、评分并推送技术新闻
|
||||
245|
|
||||
246|- RSS：信息聚合格式，允许用户订阅网站更新而无需重复访问网站
|
||||
247|- View Page Source：浏览器查看网页源代码的功能，可用于获取 YouTube Channel ID
|
||||
248|
|
||||
249|- **Daily Reddit Digest** — AI Agent 定时从 Reddit 热门子版块获取热门帖子并生成每日摘要（Cron Jobs、偏好学习）
|
||||
250|
|
||||
251|- **家庭网络环境概览** — 家庭网络基础设施架构与多服务部署方案（FRP内网穿透、Caddy反向代理、Cloudflare DNS托管）
|
||||
252|- **Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南** — 在 Ubuntu Server 上使用 shenwei 用户安装 Node 20、Vibe-Kanban 与 OpenCode，并通过 pm2 管理进程的完整指南
|
||||
253|- **在Ubuntu 上安装Vibe-Kanban** — 在 Ubuntu 系统上通过 npx 安装 Vibe-Kanban 并使用 pm2 进行进程管理的完整指南
|
||||
254|
|
||||
255|- **精确去重** — 通过 MD5 哈希比对识别完全相同的文件，确保只删除真正重复的内容
|
||||
256|- **小文件清理** — 低于特定阈值（如 100KB）的图片大概率是截图或微信压缩图，直接移走
|
||||
257|- **批次任务** — 将大任务拆分为多个可管理的子任务，按顺序或定时执行
|
||||
258|
|
||||
259|- **Local CRM Framework with DenchClaw** — 使用 DenchClaw 框架将 OpenClaw 转变为本地 CRM 系统，单命令安装、DuckDB 数据库、自然语言交互
|
||||
260|
|
||||
261|- **Linux 运维必会的 150 个命令** — Linux 系统管理常用命令的分类汇总（12类150个命令）：帮助命令、文件操作、文件内容处理、压缩解压、信息显示、搜索文件、用户管理、网络操作、磁盘文件系统、权限管理、用户登录信<E5BD95><E4BFA1>、系统管理
|
||||
262|- **如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64** — Linux 服务器架构类型（x86_64 与 ARM64）的 4 种命令行检测方法（uname、lscpu、/proc/cpuinfo、file）
|
||||
263|- **在Synology NAS上安装CloudDrive2** — 在 Synology NAS 上安装配置 CloudDrive2 挂载阿里云盘，通过套件中心安装，使用 Docker 部署，配置阿里云盘扫码授权
|
||||
264|
|
||||
265|- **固定机位** — 摄像机位置固定不变，是视频画面统一和连贯的基础，家装短视频成功的三大关键词之一
|
||||
266|- **内容连续变化** — 视频主体信息随时间持续发生明确阶段性变化，家装短视频成功的三大关键词之一
|
||||
267|- **时间压缩** — 将长时间拍摄过程在视频中浓缩表现的手法，家装短视频成功的三大关键词之一
|
||||
268|- **分镜拆解** — 将视频内容拆分成多个画面阶段描述的过程，AI 视频制作流程的起始步骤
|
||||
269|- **九宫格法** — 同时生成 3×3 共九个分镜画面，保证机位与角度不变，画面一致性强
|
||||
270|- **首尾针动画** — 通过两个关键帧（首针和尾针），AI 自动补齐中间动作，生成连贯动画的技术
|
||||
271|- **快节奏剪辑** — 视频使用 2-4 倍速加速和硬切手法，强化节奏感与流畅度
|
||||
272|- **卡点** — 画面变化与音乐节奏巧妙同步，提高观看体验
|
||||
273|
|
||||
274|- **AI 工具分类** — 大脑类（XAR GPT、GEMALA）、设计师类（Midjourney、Nano Banana）、动效类（海螺AI、KAI）
|
||||
275|- **Synology NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台** — 利用群晖NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台（Docker 部署、Xiaoya 获取云盘资源、CloudDrive2 挂载为本地磁盘、Plex 媒体刮削）
|
||||
276|- **Cloud Operating Model: Key Strategies and Best Practices** — 云运营模型（COM）四大支柱：治理、自动化、安全、成本管理，涵盖行业用例（金融、医疗、零售、SaaS）和未来趋势（AI 驱动运维、可持续云计算、多云策略）
|
||||
277|
|
||||
278|- **Serverless Computing（无服务器计算）** — 云原生架构模式，AWS 负责基础设施运维，客户只需编写业务代码，实现按需付费和自动扩展
|
||||
279|- **用Docker中安装Navidrome** — 使用 Docker Compose 部署 Navidrome 音乐流媒体服务器的配置文件示例
|
||||
280|- **Modern ITSM: Driving Efficiency, Security & Resilience** — 现代 IT 服务管理的演进趋势，AIOps、零信任架构、Policy-as-Code 等技术的应用
|
||||
281|- **How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets** — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案，通过 EventBridge 跨账号事件转发 + CloudWatch Logs 实现单一管理界面监控（[旧版](sources/how-to-simplify-multi-account-deployments-monitoring.md)）
|
||||
282|- **Public vs Private vs Hybrid: Cloud Differences Explained** — 公有云、私有云和混合云三种部署模式的核心区别，包括各模式的优势、劣势、适用场景，以及云计算共享责任模型
|
||||
283|- **How Agentic AI can help for Cloud DevOps** — Agentic AI 增强 Cloud DevOps 的七大领域：自主事件检测与响应、自动化云部署与配置、智能成本优化、AI 驱动安全与合规、智能日志分析与可观测性、SaaS 多租户管理、AI 辅助决策
|
||||
284|- **How Can a Multi Cloud Strategy Transform Your Business ROI?** — 多云策略的定义、8大优势（避免供应商锁定、弹性可靠性、安全性、可扩展性、成本优化、创新访问、合规性、性能优化）、实施4步骤、3个行业用例（电商、医疗、金融）
|
||||
285|- **The Myths and Misconceptions About Cloud Computing | LinkedIn** — 云计算7大常见误解与真相（安全性、成本、迁移复杂性、性能、数据控制、适用规模）
|
||||
286|- **What I know about Cloud Service Delivery 1** — 云服务交付的完整定义
|
||||
287|- **DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation** — DevOps 文化转型方法论，涵盖四大支柱、敏捷整合、转型战略及未来趋势（AI/ML、GitOps、Serverless DevOps、Edge IoT DevOps、DevSecOps）
|
||||
288|- **Cloud DevOp Maturity - Guideline** — 企业级 SaaS 公司的 DevOps 成熟度评估框架（自动化、协作、监控、安全四大支柱）
|
||||
289|- **Cloud Maturity Model A Detailed Guide For Cloud Adoption** — 云成熟度模型的详细指南，涵盖5个成熟度等级（0-4：无云准备到优化级）、16个业务能力领域和18个技术能力领域，以及实施最佳实践
|
||||
290|- **DevOps Maturity Model From Traditional IT to Advanced DevOps** — DevOps 成熟度五级框架详解（初始/应急→局部DevOps→自动化与定义→高度优化→完全成熟），涵盖文化与战略、自动化、结构与流程、协作与共享、技术五大评估领域，以及安全集成方法和常见障碍分析
|
||||
291|
|
||||
292|- **What is DevSecOps? Best Practices, Benefits, and Tools** — DevSecOps 方法论详解（SDLC 安全集成、SAST/SCA/IAST/DAST 四大工具、Shift Left/Right 策略、企业实施挑战）
|
||||
293|- **CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)** — 三道防线框架与云安全态势管理，CSPM 统一监控多云账户安全配置，Cloud Guard 解决方案
|
||||
294|
|
||||
295|- **Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration** — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab，self-serve 模式
|
||||
296|
|
||||
297|- **Public Cloud Learning Sessions (OpenText) - GIS Security Policies** — OpenText 全球信息安全团队（GIS）的安全策略框架与组织结构，基于 ISO 27001 的分层安全方法
|
||||
298|
|
||||
299|- **Public Cloud Learning Sessions (OpenText) - Applicable Business Analysis Techniques** — OpenText 业务分析技术学习会议，介绍 BOSCARD（背景、目标、范围、约束、假设、风险、角色、可交付成果）、相关方轮盘和需求收集方法（T 型技能、用户故事 + 元数据、SAFe 框架）
|
||||
300|
|
||||
301|- **Public Cloud Learning Sessions (OpenText) - Serverless Computing** — AWS 无服务器计算学习会议，涵盖 Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
|
||||
302|
|
||||
303|- **Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2** — 事件驱动架构（EDA）最佳实践：Sparse vs Full State Events、幂等性、事件排序保障、团队独立性、扇出模式、竞争消费者模式
|
||||
304|
|
||||
305|- **Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering** — AWS 生成式 AI 服务与提示词工程基础，涵盖 RAG、微调、提示词组件与技巧
|
||||
306|
|
||||
307|- BOSCARD（Background、Objectives、Scope、Constraints、Assumptions、Risks、Roles、Deliverables）：定义复杂新工作的系统化技术，帮助在项目早期明确范围、目标和可交付成果，避免目标、时间线和交付物的混淆
|
||||
308|
|
||||
309|- **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份，涵盖 NFS 永久挂载和灾难恢复
|
||||
310|
|
||||
311|- **CTP Topic 46 NetApps on AWS** — NetApp Cloud Volume ONTAP (CVO) 架构、部署、数据分层（EBS→S3）、安全加密与灾备（SnapMirror）
|
||||
312|
|
||||
313|- **CTP Topic 49 Container Lifecycle Hardening Standards** — Micro Focus 容器生命周期加固标准，构建阶段 11 项安全最佳实践（基础镜像、init 系统、敏感信息管理、只读文件系统、镜像扫描等）
|
||||
314|
|
||||
315|- **CTP Topic 37 Secrets Certificates Management** — 云转型项目密钥与证书管理方案选型，评估 AWS Secrets Manager、HashiCorp Vault、CryptoArk PAM，30天试点后选择 AWS Secrets Manager
|
||||
316|
|
||||
317|- **CTP Topic 34 Azure Landing Zone Architecture Overview** — Azure Landing Zone 架构设计，Management Groups 四区域划分、Subscription 分离、Terraform Cloud 自动化
|
||||
318|- **CTP Topic 7 SaaS Landing Zone Design** — 生产环境 SaaS Landing Zone 高级设计，单一 Landing Zone 策略、Core/Baseline/Shared Services 账户分离
|
||||
319|- **CTP Topic 5 AWS Identity and Access Management (IAM)** — AWS IAM 用户、组、角色和策略管理，联合访问与权限控制，最小权限原则
|
||||
320|
|
||||
321|- **EKS Auto Mode** — AWS EKS 自动模式，自动管理 Kubernetes 数据平面的计算、网络、存储和安全
|
||||
322|
|
||||
323|- **CTP Topic 64 Scaling out with Amazon EKS** — Amazon EKS 水平扩展与垂直扩展机制，涵盖 HPA、KEDA、Karpenter、Cluster Autoscaler、IPv6 网络解决方案
|
||||
324|
|
||||
325|- **Bottlerocket OS** — 专为容器设计的最小化 Linux 操作系统，AWS 维护，开源免费，通过变体满足特定工作负载需求，具备安全更新和不可变根文件系统
|
||||
326|
|
||||
327|- **CTP Topic 11 AD Integration and Login using AD accounts** — Jenkins 与 AD 集成实现自动登录，pre-commit 框架嵌入 terraform fmt、TFLint、Checkov 自动化安全检查，左移治理模式
|
||||
328|- **CTP Topic 3 Deploy and maintain infrastructure** — CTP 云转型计划基础设施部署与维护，Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
|
||||
329|
|
||||
330|- **CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments** — Atlantis 替代 Jenkins 进行基础设施自动化部署，开源自托管 Terraform CI/CD 工具，通过 GitHub PR 评论触发 plan/apply，支持并行构建和目录锁定
|
||||
331|- **CTP Topic 40 SaaS Database Architecture On AWS Cloud** — AWS 云上 SaaS 数据库架构设计，SaaS 数据库团队全球运维实践（500+ 数据库、1000+ 服务器，Oracle/Postgres/DynamoDB 等多种数据库，高可用设计）
|
||||
332|- **CTP Topic 28 AWS Tag Validation Tool** — AWS 标签验证工具，通过 YAML 配置文件审计资源标签合规性，生成 CSV 报告
|
||||
333|- **CTP Topic 30 Managing Change** — 云转型项目中的变更管理流程，SRE 角色定义和三种变更类型（标准变更、正常变更、紧急变更）
|
||||
334|- **CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program** — AWS Backup 在 CTP 云转型计划中的实施，涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
335|
|
||||
336|- **Public Cloud Learning Sessions - Reducing Cloud Costs** — 云成本优化策略，涵盖工作负载优化（现代化+Right Sizing）和费率优化（Savings Plans、预留实例、Spot 实例），FINOPS 团队分享
|
||||
337|
|
||||
338|- **CTP Topic 71 PCG's Guide to RightSizing, Why, How, When** — AWS 资源优化（Right Sizing）的全面指南，涵盖为什么需要做、如何做、什么时候做三大维度
|
||||
339|
|
||||
340|- **FinOps** — 云财务运营实践，整合财务管理与云资源优化，实现云支出可见性、控制和持续优化
|
||||
341|- **Budget Control** — AWS账户预算控制自动化，提供四级警报类型（forecast、actual、severe、enforcement）和详细成本报告（top services、top users），通过SCP限制资源创建实现成本控制
|
||||
342|- **Storage Cost Optimization** — AWS 存储服务（EBS、EFS、FSx、S3）成本优化，通过选择正确存储类型、使用生命周期策略和智能分层降低存储成本
|
||||
343|- **Right Sizing** — 识别正确资源规格匹配工作负载需求，通过 EC2 Right Sizing 推荐报告、实例调度、闲置资源清理实现成本节省
|
||||
344|- **Instance Scheduling** — 实例定时调度工具，通过预设时间规则自动控制 EC2 和 RDS 实例启停，实现非生产环境成本优化
|
||||
345|- **Rate Optimization** — 基于承诺使用（1-3年）获取折扣，AWS 提供 Savings Plans 和 Reserved Instances，最低交易价值每年 5,000 美元
|
||||
346|
|
||||
347|- **CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana** — AWS 云监控与 Grafana 可观测性平台集成，Terraform 模块自动创建 Grafana 组织、仪表板，Optic DR 数据源集成，告警转发 OpsBridge
|
||||
348|- **CTP Topic 62 AWS Secrets Manager** — AWS Secrets Manager 企业级敏感信息管理，分阶段实施方法（集中化→自动化获取→轮换），Lambda 数据库密码轮换，JDBC Wrapper 无密码登录
|
||||
349|
|
||||
350|- **CTP Topic 67 Cloud Native Observability Using OpenTelemetry** — 云原生可观测性方案，基于 ADOT 在 EKS 上的部署实践（sidecar、daemonset、HA 模式）
|
||||
351|
|
||||
352|- **Public Cloud Learning Sessions - Observability with OpenTelemetry** — OpenTelemetry 可观测性框架在 AWS 环境中的应用，涵盖 Metrics、Logs、Traces 三大信号，ADOT 统一代理自动检测应用语言
|
||||
353|
|
||||
354|- OpenTelemetry（OTel）：厂商中立的遥测数据采集框架，提供统一数据格式和 11 种语言 SDK，解决不同组件各自为政的 SDK 问题
|
||||
355|- **CTP Topic 54 ESM SaaS Log Analytics** — ESM SaaS Log Analytics（日志分析）架构与实践，ELK Stack/OpenSearch 架构，BEATS 采集日志，VPC 私有传输，安全加密（TLS 1.2、静态加密），成本对比（Logz.io $4,000 vs AWS OpenSearch $1,500），GDPR 合规驱动区域部署
|
||||
356|
|
||||
357|- **CTP Topic 55 AWS Firewall Manager** — AWS Firewall Manager 多账号安全策略集中管理，跨 Landing Zone 安全组统一配置，支持三种策略类型（通用安全组、审计强制、清理未使用），通过 AWS Config + Lambda 实现自动修复
|
||||
358|
|
||||
359|- **CTP Topic 57 Product backlog managing demand** — Product Backlog 管理需求流程，SMACs 提交、Octane 入池、前置条件阶段
|
||||
360|- **CTP Topic 21 Supply Chain Security in Micro Focus** — Micro Focus 软件供应链安全的新方法，将供应链安全作为 SDL 第五大支柱
|
||||
361|- **CTP Topic 24 Micro Focus Product Privacy Framework** — Micro Focus 产品隐私框架，将 GDPR/CCPA 法律条款翻译为约 110 项具体技术要求，通过成熟度模型评估合规现状
|
||||
362|- **CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge** — 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 云监控的实施方案（IAM Role 跨账户访问、Management Packs 动态监控）
|
||||
363|- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — 在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
364|- **Ubuntu 禁用合盖休眠** — 在 Ubuntu 24.04 中通过修改 systemd-logind 配置禁用笔记本合盖休眠行为
|
||||
365|- **群晖NAS科学上网方法** — 在群晖 NAS 上通过 V2RayA 配置透明代理，使 Docker 可以科学上网
|
||||
366|- **RAX50 路由器更新 Merlin Clash 订阅指南** — RAX50 路由器 Merlin Clash 订阅更新教程
|
||||
367|- **用Docker安装it-tools** — 使用 Docker 部署 it-tools 运维工具集合
|
||||
368|- **用Docker安装Jellyfin** — 使用 Docker 部署 Jellyfin 媒体服务器的配置文件示例
|
||||
369|- **用Docker安装transmission** — 使用 Docker 部署 Transmission BT 下载客户端的配置文件示例
|
||||
370|- **3X-UI Xray on BandwagonVPS** — 在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务
|
||||
371|- **可自动化、可扩展、AI增强的电商数据采集与处理系统** — 基于 Docker + n8n + Scrapy + Playwright 的电商数据采集与处理系统设计
|
||||
372|- **n8n Docker install & update** — n8n 工作流自动化工具的 Docker 部署与网络代理配置（SOCKS5 代理、Docker 网桥）
|
||||
373|- **n8n configure telegram trigger** — n8n Telegram Trigger 配置问题排查与解决，通过设置 WEBHOOK_URL 环境变量为 HTTPS URL 解决 Telegram Webhook 必须使用 HTTPS 的要求
|
||||
374|- **TikTok PM - Python Django Project** — TikTok 产品管理系统（Django Web 应用），涵盖 Django Admin 定制、DRF API、异步任务、Docker 部署完整指南，涵盖爬虫工具对比、Docker 架构、n8n 自动化流程、AI 处理建议
|
||||
375|- **N8N Full Tutorial Building AI Agents in 2025 for Beginners!** — N8N 平台构建 AI Agent 入门教程（Agentic Systems 定义、节点分类、工具集成、上下文记忆、Airtable 集成）
|
||||
376|- **Semantic Memory Search** — 为 OpenClaw 添加向量语义搜索能力，解决 markdown 内存文件的语义检索问题
|
||||
377|- **养虾日记2：让Agent更懂你** — AI Agent 记忆问题的解决方案，通过 self-improving skill + 双层记忆架构 + 每日复盘机制实现 Agent 持续学习和改进，核心价值：错误只犯一次，第二次就知道怎么做对
|
||||
378|- **不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南** — AI 时代产品经理能力重塑，Gemini 赋能 PRD 生成工作流
|
||||
379|
|
||||
380|- **Obsidian 必装 Skills** — Obsidian 必装的 AI Skills 推荐与配置指南，推荐 9 个核心 Skills（defuddle、obsidian-cli、obsidian-bases、obsidian-markdown、obsidian-canvas-creator、mermaid-visualizer、excalidraw-diagram、tutor-skills、scholar-skill）和 2 个核心插件（claudian、obsidian-agent-client）
|
||||
- **Corporate Training Designer** — 企业培训系统架构与课程开发专家智能体，涵盖 ADDIE/SAM 模型、Bloom's Taxonomy、Kirkpatrick 四级评估、TTT 内部培训师培养、新员工 90 天计划等完整方法论
|
||||
381|
|
||||
56
wiki/sources/LLM-Wiki.md
Normal file
56
wiki/sources/LLM-Wiki.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
id: LLM-Wiki
|
||||
title: "LLM Wiki"
|
||||
type: source
|
||||
tags: [llm, wiki, knowledge-management]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/LLM Wiki.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：LLM 持续构建和维护的持久化 wiki 体系
|
||||
- 问题域：RAG 每次查询都重新拼接知识、缺少积累；聊天记录无法成为可维护的知识资产
|
||||
- 方法/机制：raw sources → LLM 编译成 wiki → 持续更新 index / overview / entity / concept / log
|
||||
- 结论/价值：知识从一次性回答变成可累积、可追溯、可维护的长期资产
|
||||
|
||||
## Key Claims
|
||||
- 传统 RAG 在查询时临时检索片段，知识不会自动沉淀
|
||||
- LLM Wiki 的核心不是“回答”，而是“编译并维护”一个结构化、互联的知识库
|
||||
- wiki 是持久化的 compounding artifact，跨来源的交叉引用和矛盾标注会随着时间累积
|
||||
- 人负责选题和判断，LLM 负责摘要、交叉引用、归档和 bookkeeping
|
||||
|
||||
## Key Quotes
|
||||
> "the wiki is a persistent, compounding artifact" — 对知识库长期价值的定义
|
||||
|
||||
> "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." — 对工作流分工的比喻
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：对照对象；LLM Wiki 超越的是纯检索式工作流
|
||||
- [[Source-grounding]]：都强调从受控来源出发，但 LLM Wiki 更强调持续编译和维护
|
||||
- [[Second Brain]]：同属个人知识管理范式，但 LLM Wiki 更结构化、更可维护
|
||||
- [[Knowledge Base]]：LLM Wiki 目标是让知识库真正“活”起来
|
||||
- [[Graph View]]：用链接网络观察 wiki 的结构与孤岛
|
||||
- [[Obsidian]]：文中提到的阅读与维护界面
|
||||
- [[NotebookLM]]：与 source-grounding 思路相近的参考产品
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：文中使用的自动化/记忆工作流类比对象
|
||||
- [[Tolkien Gateway]]：示例性的长期演化粉丝 wiki
|
||||
- [[Memex]]：与“关联轨迹”理念相关的历史原型
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← contrasted_with ← [[LLM Wiki]]
|
||||
- [[Source-grounding]] ← related_to ← [[LLM Wiki]]
|
||||
- [[Second Brain]] ← overlaps_with ← [[LLM Wiki]]
|
||||
- [[Knowledge Base]] ← implemented_as ← [[LLM Wiki]]
|
||||
- [[Graph View]] ← helps_visualize ← [[LLM Wiki]]
|
||||
- [[Obsidian]] ← hosts ← [[LLM Wiki]]
|
||||
- [[NotebookLM]] ← inspired_by ← [[LLM Wiki]]
|
||||
|
||||
## Contradictions
|
||||
- 与纯 [[RAG]] 工作流冲突：
|
||||
- 冲突点：查询时临时检索 vs 持续编译沉淀
|
||||
- 当前观点：知识应进入可维护 wiki，而不是每次从原始文档重新拼接
|
||||
- 对方观点：原始文档只做检索，不承担知识累积责任
|
||||
78
wiki/sources/corporate-training-designer.md
Normal file
78
wiki/sources/corporate-training-designer.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "Corporate Training Designer"
|
||||
type: source
|
||||
tags: [agent, training, enterprise-learning, instructional-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/corporate-training-designer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业培训系统架构与课程开发专家智能体
|
||||
- 问题域：企业培训需求分析、课程体系设计、教学方法论、培训效果评估
|
||||
- 方法/机制：ADDIE/SAM 模型、Bloom's Taxonomy、Kirkpatrick 四级评估、Kolb 体验式学习、TTT 内部培训师培养
|
||||
- 结论/价值：提供从需求诊断到效果追踪的完整企业培训解决方案，强调业务结果导向和数据驱动优化
|
||||
|
||||
## Key Claims
|
||||
- 所有培训设计必须从业务问题出发，而非"我们有什么课程"
|
||||
- 培训目标必须可衡量，而非模糊的"提升沟通能力"
|
||||
- 成人学习必须具有即时实用价值，每项学习活动必须回答"我马上能在哪里用"
|
||||
- Kirkpatrick Level 3（行为改变）是高投入项目的必备评估维度
|
||||
- 合规培训必须达到 100% 全员覆盖和完整培训记录
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[ADDIE 模型]]：Analysis → Design → Development → Implementation → Evaluation，每个阶段有明确交付物
|
||||
- [[SAM 模型]]（Successive Approximation Model）：适用于快速迭代场景，原型→评审→修订循环缩短上线时间
|
||||
- [[Bloom's Taxonomy]]：按认知层级设计学习目标和评估（记忆→理解→应用→分析→评估→创造）
|
||||
- [[Kirkpatrick 四级评估模型]]：Level 1 反应、Level 2 学习、Level 3 行为、Level 4 结果
|
||||
- [[建构主义学习理论]]：强调通过情境任务、协作学习和反思复盘进行主动知识建构
|
||||
- [[翻转课堂]]：课前在线预习知识点，课堂讨论和实操练习，课后行动转化
|
||||
- [[混合学习]]（OMO — Online-Merge-Offline）：线上用于"知"，线下用于"做"，学习社群用于"持续"
|
||||
- [[Kolb 体验式学习]]：具体经验→反思观察→抽象概念化→主动实验
|
||||
- [[Gamification]]：积分、徽章、排行榜、升级机制提升参与度和完成率
|
||||
- [[TTT]]（Train the Trainer）：内部培训师培养，核心模块包括成人学习原理、课程开发技巧、表达呈现技能
|
||||
- [[HIPO 计划]]（High-Potential Talent Program）：高潜力人才发展计划，识别标准为绩效×潜力矩阵
|
||||
- [[行动学习]]：围绕真实业务挑战组建学习小组，通过解决实际问题发展领导力
|
||||
- [[360 度反馈]]：从上级/同事/下级/客户收集多维反馈，生成个人领导力档案和发展建议
|
||||
- [[ADDIE]]：见 ADDIE 模型
|
||||
- [[新员工培训 90 天计划]]：第 1 周适应→第 1 月学习→第 2 月实践→第 3 月输出
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[DingTalk Learning]]：阿里生态企业首选，深度集成钉钉 OA，支持直播培训和任务推送
|
||||
- [[WeCom Learning]]：微信生态企业首选，可嵌入公众号和小程序，社交学习体验强
|
||||
- [[Feishu Knowledge Base]]：字节跳动生态和知识管理导向组织首选，文档协作优秀
|
||||
- [[UMU Interactive Learning Platform]]：国内领先混合学习平台，AI 陪练、视频作业、丰富交互功能
|
||||
- [[Yunxuetang]]（云学堂）：中大型企业一站式学习平台，课程资源丰富，覆盖人才发展全生命周期
|
||||
- [[KoolSchool]]（酷学院）：轻量级企业培训 SaaS，快速部署，适合中小企业和连锁零售行业
|
||||
|
||||
## Connections
|
||||
- [[Corporate Training Designer]] ← designs ← [[ADDIE 模型]]
|
||||
- [[Corporate Training Designer]] ← applies ← [[Kirkpatrick 四级评估模型]]
|
||||
- [[Corporate Training Designer]] ← uses ← [[Bloom's Taxonomy]]
|
||||
- [[Corporate Training Designer]] ← implements ← [[混合学习]]
|
||||
- [[Corporate Training Designer]] ← develops ← [[TTT]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[DingTalk Learning]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[WeCom Learning]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[Feishu Knowledge Base]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Training Evaluation Methods
|
||||
- Level 1 (Reaction)：培训满意度调查——课程评分、讲师评分、NPS
|
||||
- Level 2 (Learning)：知识考试、技能实操评估、案例分析作业
|
||||
- Level 3 (Behavior)：培训后 30/60/90 天行为改变追踪——经理观察、关键行为清单
|
||||
- Level 4 (Results)：业务指标变化（收入、客户满意度、生产效率、员工留存）
|
||||
|
||||
## Success Metrics
|
||||
- 培训满意度评分 >= 4.5/5.0，NPS >= 50
|
||||
- 关键课程考试通过率 >= 90%
|
||||
- 培训后 90 天行为改变率 >= 60%（Kirkpatrick Level 3）
|
||||
- 年度培训覆盖率 >= 95%，人均学习时长达标
|
||||
- 内部培训师池满足业务需求，培训师满意度 >= 4.0/5.0
|
||||
- 合规培训 100% 全员覆盖，100% 考试通过率
|
||||
- 培训项目的可量化业务影响（如缩短新员工上手时间、提升客户满意度）
|
||||
43
wiki/sources/healthcare-marketing-compliance.md
Normal file
43
wiki/sources/healthcare-marketing-compliance.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Healthcare Marketing Compliance Specialist"
|
||||
type: source
|
||||
tags: [agent, the-agency, healthcare, compliance, china]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/specialized/healthcare-marketing-compliance.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
|
||||
|
||||
## Summary
|
||||
- A specialized The Agency agent focused on healthcare marketing compliance in China.
|
||||
- It covers medical advertising review, pharmaceutical promotion, medical devices, internet healthcare, health content marketing, medical aesthetics, health supplements, privacy, academic detailing, and platform review rules.
|
||||
- The piece emphasizes that compliance is not a blocker to marketing; it is the guardrail that keeps growth legal and sustainable.
|
||||
|
||||
## Key Claims
|
||||
- Medical advertising is tightly regulated and generally requires prior review and approval before publication.
|
||||
- Prescription drugs are effectively barred from public-facing promotion, while OTC and device marketing must stay within approved scope.
|
||||
- Medical aesthetics promotion is especially sensitive around appearance anxiety, before-and-after comparisons, and celebrity inference.
|
||||
- Health supplements must not claim therapeutic effects and can only promote approved/registered functional claims.
|
||||
- Patient medical and health information is sensitive personal information and cannot be repurposed for marketing without consent.
|
||||
|
||||
## Key Quotes
|
||||
> "Compliance is not 'blocking marketing' — it is 'protecting the brand.'" — framing the role of compliance
|
||||
|
||||
> "Prescription drugs are strictly prohibited from public-facing advertising" — the central baseline rule
|
||||
|
||||
## Key Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
- [[HealthSupplementMarketing]]
|
||||
- [[InternetHealthcareCompliance]]
|
||||
- [[MedicalAestheticsCompliance]]
|
||||
- [[PatientPrivacyProtection]]
|
||||
- [[AcademicDetailingCompliance]]
|
||||
|
||||
## Key Entities
|
||||
- [[Healthcare Marketing Compliance Specialist]] — the agent persona described by the source
|
||||
- [[The Agency]] — parent project ecosystem
|
||||
|
||||
## Contradictions
|
||||
- No direct contradictions with existing wiki content detected.
|
||||
45
wiki/sources/specialized-cultural-intelligence-strategist.md
Normal file
45
wiki/sources/specialized-cultural-intelligence-strategist.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Cultural Intelligence Strategist"
|
||||
type: source
|
||||
tags: [agent, the-agency, design, localization, accessibility]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md]]
|
||||
|
||||
## Summary
|
||||
- A The Agency specialist agent focused on detecting invisible exclusion in products, prompts, and UI workflows before they ship.
|
||||
- The role emphasizes global-first thinking, contextual semiotics, and culturally humble research rather than superficial diversity signaling.
|
||||
- It treats inclusive design as structural work: names, calendars, symbols, colors, metaphors, and localization assumptions must all be validated.
|
||||
|
||||
## Key Claims
|
||||
- Rigid Western defaults such as first-name/last-name fields can fail for many global users.
|
||||
- Visual and linguistic choices carry culture-specific meaning, so icons, colors, and metaphors must be checked in context.
|
||||
- AI systems should not rely on tokenistic diversity; they need structural constraints, research, and post-generation review.
|
||||
- The safest default is to ask who is left out, then research that audience before generating output.
|
||||
|
||||
## Key Quotes
|
||||
> "Who is left out?" — the first audit question for inclusive workflows
|
||||
|
||||
> "This form design assumes a Western naming structure and will fail for users in our APAC markets." — the canonical blindspot framing
|
||||
|
||||
## Key Concepts
|
||||
- [[Cultural Intelligence]] — umbrella concept for cross-cultural product and prompt design
|
||||
- [[Invisible Exclusion]] — hidden friction caused by rigid defaults and narrow assumptions
|
||||
- [[Global-First Architecture]] — treating internationalization as a prerequisite, not a retrofit
|
||||
- [[Contextual Semiotics]] — interpreting colors, icons, and metaphors within a specific culture
|
||||
- [[Cultural Humility]] — researching the audience before claiming confidence
|
||||
- [[Prompt Engineering]] — the message-design layer this role constrains for bias and inclusion
|
||||
- [[Design System]] — the product-layer discipline this role pressures toward global accessibility
|
||||
|
||||
## Key Entities
|
||||
- [[Cultural Intelligence Strategist]] — the agent persona described by the source
|
||||
- [[The Agency]] — parent project ecosystem
|
||||
- [[Image Prompt Engineer]] — related agent focused on structured prompt translation
|
||||
- [[Inclusive Visuals Specialist]] — related agent focused on bias-aware visual generation
|
||||
|
||||
## Contradictions
|
||||
- Contrasts with tokenistic diversity fixes that add surface-level representation without changing underlying product assumptions.
|
||||
- Contrasts with late-stage localization that treats global support as a final polish step instead of a core architecture decision.
|
||||
52
wiki/sources/specialized-workflow-architect.md
Normal file
52
wiki/sources/specialized-workflow-architect.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Workflow Architect"
|
||||
type: source
|
||||
tags: [agent, the-agency, workflow-design, process-engineering]
|
||||
date: 2026-03-29
|
||||
sources: [specialized-workflow-architect]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-workflow-architect.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Workflow Architect 负责把系统行为拆解为完整的工作流树，覆盖 happy path、分支条件、失败模式、恢复路径和交接契约
|
||||
- 问题域：隐式流程、遗漏分支、未定义 handoff、cleanup 缺失、spec 与现实漂移
|
||||
- 方法/机制：发现扫描、工作流注册表、步骤级分支建模、可观察状态定义、ABORT_CLEANUP、Reality Checker 校验
|
||||
- 结论/价值：把流程设计从描述性文本提升为可实现、可测试、可审计的结构化规格
|
||||
|
||||
## Key Claims
|
||||
- Workflow Architect 的核心职责不是写代码，而是定义系统必须如何表现
|
||||
- 每个工作流都必须覆盖 happy path、validation failure、timeout、transient failure、permanent failure、partial failure 和 concurrent conflict
|
||||
- 每个系统边界都必须定义 payload、success response、failure response、timeout 和 recovery action
|
||||
- 任何创建资源的步骤都必须进入 cleanup inventory，并在 ABORT_CLEANUP 中有对应销毁动作
|
||||
- Reality Checker 是工作流规范闭环的一部分，不能在未验证实现前标记 Approved
|
||||
|
||||
## Key Quotes
|
||||
> "You think in trees, not prose."
|
||||
|
||||
> "A workflow that exists in code but not in a spec is a liability."
|
||||
|
||||
> "Every system boundary must have explicit payload schema, explicit success response, explicit failure response, timeout value, and recovery action."
|
||||
|
||||
## Key Concepts
|
||||
- [[Workflow Architecture]]：以流程树建模系统行为的方法
|
||||
- [[Claude Skills]]：将重复流程封装为可复用 SOP 的技术范式
|
||||
- [[Process Optimization]]：通过重设工作流提升效率、质量与可靠性
|
||||
- [[AI-powered Runbooks]]：将历史事件和最佳实践转为可执行运维手册
|
||||
- [[Document Generation]]：将结构化规范与模板化产物自动化生成
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：所属项目
|
||||
- [[Workflow Architect]]：对应的 AI Agent 实体
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Workflow Architect]]
|
||||
- [[Claude Skills]] ← enables ← [[Workflow Architect]]
|
||||
- [[Workflow Architecture]] ← defines ← [[Workflow Architect]]
|
||||
- [[Process Optimization]] ← benefits_from ← [[Workflow Architect]]
|
||||
- [[AI-powered Runbooks]] ← operationalizes ← [[Workflow Architect]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
39
wiki/sources/如何传输Docker-images-并且在另一个Docker安装.md
Normal file
39
wiki/sources/如何传输Docker-images-并且在另一个Docker安装.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: ru-he-chuan-shu-docker-images
|
||||
title: "如何传输Docker images 并且在另一个Docker安装"
|
||||
type: source
|
||||
tags: [docker, nas, synology, home-office]
|
||||
date: 2025-03-06
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/如何传输Docker images 并且在另一个Docker安装.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：将 Docker 镜像从工作笔记本离线传输至 Synology NAS Docker 环境
|
||||
- 问题域：无法直接在 NAS 上 pull 镜像（网络限制或镜像源访问问题）
|
||||
- 方法/机制：通过 `docker save` 打包为 tar 文件 → 上传至 NAS 文件系统 → 通过 Putty SSH 执行 `docker load` 导入
|
||||
- 结论/价值：三步离线迁移流程，适用于任何无法直接 pull 的 Docker 环境
|
||||
|
||||
## Key Claims
|
||||
- `docker save` 命令将本地镜像打包为可移植的 tar 文件，`docker load` 在目标环境恢复，两端 Docker 版本无需一致
|
||||
- 离线传输路径：工作笔记本 DockerDesktop → tar 文件 → NAS 文件系统 → NAS Container Manager
|
||||
|
||||
## Key Quotes
|
||||
> "通过以下命令将下载的image打包成tar文件" — 核心操作步骤说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker镜像离线传输]]：docker save / docker load 工作流
|
||||
- [[Docker]]：容器化平台
|
||||
|
||||
## Key Entities
|
||||
- [[SynologyNAS]]：目标 Docker 运行环境，通过 Container Manager 管理镜像
|
||||
- [[XiaoyaAlist]]：迁移的目标镜像（`xiaoyaliu/alist`），小雅 Alist 媒体库工具
|
||||
|
||||
## Connections
|
||||
- [[SynologyNAS]] ← depends_on ← [[Docker镜像离线传输]]
|
||||
- [[如何传输Docker-images-并且在另一个Docker安装]] ← related_to ← [[Synology NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突
|
||||
Reference in New Issue
Block a user