diff --git a/wiki/concepts/AI时代赚钱三原则.md b/wiki/concepts/AI时代赚钱三原则.md new file mode 100644 index 00000000..c3fb6e30 --- /dev/null +++ b/wiki/concepts/AI时代赚钱三原则.md @@ -0,0 +1,42 @@ +--- +title: "AI时代赚钱三原则" +type: concept +tags: [ai-era, wealth, taste, end-to-end, death-filter, entrepreneurship] +last_updated: 2026-04-16 +--- + +## 定义 +以乔布斯视角提出的 AI 时代赚钱思维框架，核心是「品味值钱、做端到端、用死亡过滤器筛选热爱」。 + +## 三原则 + +### 1. 品味值钱 +- AI 工具民主化后，90% 的人用 AI 生成的是 shit +- 品味 = 判断什么是真正好的（insanely great）的能力 +- 能从 AI 给的 10 个方案里判断哪个是最好的，就比只会点"生成"的人强一百倍 +- **品味是护城河** + +### 2. 端到端做事 +- 别做别人 AI 流水线上的螺丝钉 +- 做从 idea 到 product 的完整闭环 +- 一个人用 AI 做完整 App，比在 100 人团队当"AI 提示词工程师"强一万倍 +- **端到端优于零件** + +### 3. 死亡过滤器 +- 每天问自己：如果今天是最后一天，我还会做今天要做的事吗？ +- 如果答案 No，说明这不是真正热爱的事 +- **用死亡过滤器筛选真正的热爱** + +## 正确问题框架 +- ❌ 错误：「普通人怎么在AI时代赚钱」（被动挨打） +- ✅ 正确：「AI 让我能做到什么以前做不到的事」（主动创造） + +## 与一人公司的关系 +AI 时代赚钱三原则是一人公司框架（[[天才地带]] + [[产品漏斗]] + [[内容矩阵]]）的思维基础。 + +## Connections +- [[AI时代赚钱三原则]] ← 来源 ← [[乔布斯.skill]] +- [[品味]] ← 原则一 ← [[AI时代赚钱三原则]] +- [[端到端]] ← 原则二 ← [[AI时代赚钱三原则]] +- [[死亡过滤器]] ← 原则三 ← [[AI时代赚钱三原则]] +- [[一人公司]] ← 上层框架 ← [[AI时代赚钱三原则]] diff --git a/wiki/concepts/BBR.md b/wiki/concepts/BBR.md new file mode 100644 index 00000000..838f9204 --- /dev/null +++ b/wiki/concepts/BBR.md @@ -0,0 +1,26 @@ +--- +title: "BBR" +type: concept +tags: [networking, tcp, performance] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +BBR（ Bottleneck Bandwidth and Round-trip propagation time）是 Google 开发的 TCP 拥塞控制算法，通过实时探测带宽和延迟调整发送速率，提升网络传输性能。 + +## Core Attributes +- 开发者：Google +- 类型：TCP 拥塞控制算法 +- 启用方式：3X-UI 面板选项 23 +- 作用：提升跨境网络传输速度 + +## Mechanism +BBR 通过两个核心指标调整发送行为： +1. Bottleneck Bandwidth（瓶颈带宽） +2. Round-trip propagation time（往返传播时间） + +相比传统 Cubic 算法，BBR 在高延迟高带宽网络中表现更优。 + +## Connections +- [[BBR]] ← enabled_by ← [[3X-UI]] diff --git a/wiki/concepts/Bandwagon-Effect.md b/wiki/concepts/Bandwagon-Effect.md new file mode 100644 index 00000000..97e7d791 --- /dev/null +++ b/wiki/concepts/Bandwagon-Effect.md @@ -0,0 +1,27 @@ +# Bandwagon Effect + +## Definition +A psychological phenomenon where people adopt beliefs or actions because they see others doing the same, regardless of the underlying evidence. In multi-agent systems, it causes agents to converge on popular answers rather than independently reasoning to correct conclusions. + +## Risk in Multi-Agent Consensus +- Agents may be influenced by implicit ordering or presentation of options +- If one answer appears first or is more salient, later agents may favor it +- The effect can override actual reasoning +- Correlated responses reduce the benefit of voting + +## Prevention +- Ensure agents are truly independent (no feedback loops) +- Present information in randomized order where applicable +- Use diverse models with different training to reduce shared biases +- Treat the consensus as a blind experiment — agents don't know they're voting + +## Key Principle +- Diversity in human systems helps solve novel problems +- The same applies to LLM ensembles +- Different models, different fine-tuning, different prompts +- Maximize variance in responses for maximum cancellation of noise + +## Related Concepts +- [[Groupthink]] +- [[Multi-Agent Consensus]] +- [[Sycophancy]] \ No newline at end of file diff --git a/wiki/concepts/Cattle-vs-Pets.md b/wiki/concepts/Cattle-vs-Pets.md new file mode 100644 index 00000000..40f5e6d1 --- /dev/null +++ b/wiki/concepts/Cattle-vs-Pets.md @@ -0,0 +1,33 @@ +# Cattle vs Pets + +## Definition +An SRE principle contrasting two approaches to managing compute resources. "Pets" are unique, manually nurtured servers treated as irreplaceable individuals. "Cattle" are identical, replaceable units that can be killed and regenerated without ceremony. The Knock-out multi-agent pattern applies this principle to LLM agents. + +## Pets (Don't Do This) +- Named, individual servers you care about personally +- Hand-fed, manually configured, lovingly maintained +- You try to heal them when sick +- Failure of a pet is a crisis + +## Cattle (Do This) +- Identical, replaceable instances +- No names, no emotional attachment +- If one fails, you kill it and spin up a new one +- Failure of cattle is routine — the system continues + +## Application to LLM Agents +- Don't name your agents or hope they "do well" +- Spin up agent → check its work → kill it if it fails +- Each agent is interchangeable with the next +- The process (not the individual) is what matters + +## Why This Matters +- LLMs are inherently stochastic and unreliable +- Treating them as pets leads to emotional attachment to broken processes +- Enterprise AI needs reliability through architecture, not through hoping individual agents succeed +- Kill failing agents quickly to reduce cost and noise + +## Related Concepts +- [[Multi-Agent Knock-out]] +- [[LLM Reliability Engineering]] +- [[Fitness Function]] \ No newline at end of file diff --git a/wiki/concepts/Context-Drift.md b/wiki/concepts/Context-Drift.md new file mode 100644 index 00000000..f36ea865 --- /dev/null +++ b/wiki/concepts/Context-Drift.md @@ -0,0 +1,27 @@ +# Context Drift + +## Definition +A failure mode in LLM interactions where the model gradually loses focus on the original task or context, veering off-topic as the conversation progresses. The LLM "forgets" the original goal and generates responses that may be locally coherent but globally irrelevant. + +## Causes +- Long conversations that exceed the model's effective context window +- Cumulative token budget leading to attention dilution +- Poor initial prompt definition +- Model's tendency to follow the most recent instructions over original ones + +## Impact on Multi-Agent Systems +- Can propagate errors through agent chains +- Workers in a Hierarchy may drift from Planner's intended tasks +- Debates may veer off the original proposition being evaluated +- Knock-out agents may lose sight of the evaluation criteria + +## Mitigation +- Break long tasks into atomic steps (Hierarchy pattern) +- Use explicit task validation at each step +- Keep agent contexts focused and limited +- Reset context periodically rather than accumulating + +## Related Concepts +- [[Hallucination]] +- [[Multi-Agent Hierarchy]] +- [[Validator]] \ No newline at end of file diff --git a/wiki/concepts/Dependency-Graph.md b/wiki/concepts/Dependency-Graph.md new file mode 100644 index 00000000..4e032335 --- /dev/null +++ b/wiki/concepts/Dependency-Graph.md @@ -0,0 +1,28 @@ +# Dependency Graph + +## Definition +A structure that enforces collaboration between agents in the Hierarchy pattern by making certain agents unable to start until others have completed. The Planner feeds tasks to Workers, and the Validator gates progress, creating a directed acyclic graph of dependencies. + +## Role in Multi-Agent Hierarchy +- Forces Workers to wait until Planner provides input +- Prevents Workers from cheating or skipping steps +- Validator catches any violations of the dependency order +- Creates accountability through structural enforcement + +## Key Properties +- Workers literally cannot start until Planner feeds them +- If Worker tries to skip or cheat, Validator catches it +- Models collaborate not because they "like each other" but because the graph forces them to +- Enables parallel execution where dependencies allow + +## Why It Works +- Instead of asking nicely ("please be careful"), architecture enforces correctness +- No agent can proceed without completing its predecessors +- The Validator verifies the chain at each step +- Errors are caught early rather than propagating + +## Related Concepts +- [[Multi-Agent Hierarchy]] +- [[Planner]] +- [[Worker]] +- [[Validator]] \ No newline at end of file diff --git a/wiki/concepts/FRP内网穿透.md b/wiki/concepts/FRP内网穿透.md new file mode 100644 index 00000000..8d912405 --- /dev/null +++ b/wiki/concepts/FRP内网穿透.md @@ -0,0 +1,58 @@ +--- +title: "FRP内网穿透" +type: concept +tags: [networking, self-hosted, reverse-proxy, tunneling] +--- + +## 定义 +FRP（Fast Reverse Proxy）是一个高性能的内网穿透工具，通过在公网 VPS 上部署 frps 服务端（FRPS），在内网机器上部署 frpc 客户端，将内网服务暴露到公网。 + +## 架构 + +``` +[内网服务] ←localhost:port← [frpc 客户端] ←TCP/UDP← [frps 服务端] ←公网← [用户] +``` + +- **frps（FRP Server）**：运行在有公网 IP 的 VPS 上，监听连接请求 +- **frpc（FRP Client）**：运行在内网机器上，与 frps 保持心跳，转发请求到内网服务 + +## 核心配置（frpc.toml） + +```toml +[[proxies]] +name = "ssh-tunnel" +type = "tcp" +localIP = "127.0.0.1" +localPort = 22 +remotePort = 60022 # 公网 VPS 暴露的端口 +``` + +## 在家庭基础设施中的应用 + +| 节点 | frpc 版本 | frps 服务器 | +|------|-----------|-------------| +| [[Mac Mini]] | 0.65.0 darwin arm64 | VPS1 :7000 | +| [[Synology NAS DS718]] | 0.65.0 linux amd64 | VPS1 :7000 | +| [[Ubuntu1]] | 0.65.0 linux amd64 | VPS1 :7000 | +| [[Ubuntu2]] | 0.65.0 linux amd64 | VPS1 :7000 | + +## 关键优势 +- 不需要公网 IP，利用 VPS 中转实现内网暴露 +- 支持 TCP/UDP/HTTP/HTTPS多种协议 +- 可配置 auth_method 实现加密通信 +- 通过 ini 或 toml 配置文件管理，版本可控 + +## 管理命令 + +| 服务器 | 启动方式 | 重启命令 | +|--------|---------|---------| +| Mac Mini | launchd（plist） | launchctl unload/load plist | +| Ubuntu1/2 | systemd --user | systemctl --user restart frpc | + +## 与其他方案的比较 +- **frp vs ngrok**：frp 完全自托管，无带宽限制，配置灵活 +- **frp vs Cloudflare Tunnel**：frp 需要 VPS，Cloudflare Tunnel 依赖 Cloudflare 基础设施 + +## 相关工具 +- [[反向代理]]：Caddy 作为 HTTP 层反向代理 +- [[内网穿透]]：frp 属于内网穿透工具类别 diff --git a/wiki/concepts/Fitness-Function.md b/wiki/concepts/Fitness-Function.md new file mode 100644 index 00000000..ebfa798b --- /dev/null +++ b/wiki/concepts/Fitness-Function.md @@ -0,0 +1,28 @@ +# Fitness Function + +## Definition +A metric used in the Knock-out multi-agent pattern to evaluate how well each agent performs a task. The function determines which agents survive and which are eliminated. It can be deterministic (e.g., unit tests, exact match) or LLM-based (e.g., quality scoring). + +## Role in Multi-Agent Knock-out +- Evaluates output of each agent +- Produces a score or boolean pass/fail +- Used to rank agents and identify worst performers +- Guides the selection/elimination process + +## Key Properties +- Must be fast — if humans need to verify all branches, the process is too slow +- Should be deterministic where possible (unit tests over LLM judgment) +- Can be composite: multiple criteria combined into single score +- Is where "Evals" come in (critical infrastructure for agent development) + +## Examples +- Unit test pass rate +- Exact string match against expected output +- LLM-based quality scoring (with rubric) +- Latency or token cost as secondary factors + +## Related Concepts +- [[Genetic Algorithms]] +- [[Multi-Agent Knock-out]] +- [[Validator]] +- [[Evals]] \ No newline at end of file diff --git a/wiki/concepts/Genetic-Algorithms.md b/wiki/concepts/Genetic-Algorithms.md new file mode 100644 index 00000000..f02dfcfa --- /dev/null +++ b/wiki/concepts/Genetic-Algorithms.md @@ -0,0 +1,28 @@ +# Genetic Algorithms + +## Definition +A class of ML algorithms inspired by biological evolution that uses selection, crossover, and mutation to iteratively improve solutions. The Knock-out multi-agent pattern is a lean implementation of genetic algorithms applied to LLM agents. + +## Core Components +1. **Genetic Representation** — A model and its context represent a solution candidate +2. **Fitness Function** — Evaluates how well each candidate solves the problem +3. **Selection** — Winners are chosen based on fitness scores +4. **Crossover** — Combining traits from successful candidates (optional in basic knock-out) +5. **Mutation** — Random variation in candidate traits (optional) + +## Application to Multi-Agent Knock-out +- N agents work on the same task +- Validator (fitness function) evaluates each +- Worst performers are eliminated (selection pressure) +- [Optional] New agents created by combining prompts of survivors (crossover) +- Process repeats until satisfactory solution emerges + +## Key Insight +- Since we can't punish or threaten LLM agents, we simply delete underperformers +- This mirrors "survival of the fittest" in biological evolution +- No attachment to individual agents — treat them as cattle, not pets + +## Related Concepts +- [[Fitness Function]] +- [[Multi-Agent Knock-out]] +- [[Cattle vs Pets]] \ No newline at end of file diff --git a/wiki/concepts/Git代理配置.md b/wiki/concepts/Git代理配置.md new file mode 100644 index 00000000..4c85da97 --- /dev/null +++ b/wiki/concepts/Git代理配置.md @@ -0,0 +1,48 @@ +--- +title: "Git HTTP/SOCKS5 代理配置" +type: concept +tags: [git, proxy, socks5, http, github] +--- + +## Definition +Git 代理配置是通过 `git config --global http.proxy` 和 `git config --global https.proxy` 全局设置，让 Git 的 HTTP/HTTPS/SSH 操作通过本地代理服务器进行。 + +## Commands +### HTTP 代理 +```bash +git config --global http.proxy http://127.0.0.1:10809 +git config --global https.proxy http://127.0.0.1:10809 +``` + +### SOCKS5 代理（速度通常更快） +```bash +git config --global http.proxy socks5://127.0.0.1:10808 +git config --global https.proxy socks5://127.0.0.1:10808 +``` + +### 取消代理 +```bash +git config --global --unset http.proxy +git config --global --unset https.proxy +``` + +### 查看当前配置 +```bash +git config --global --get http.proxy +``` + +## Core Insight +设置代理后，Git 的所有网络流量通过本地代理转发。GFW 只能看到通向本地代理的连接，无法识别目标域名，从根本上规避 TCP RST 攻击。 + +## Scope +- 全局（`--global`）：影响当前用户所有 Git 仓库 +- 本地（无 `--global`）：仅影响当前仓库 +- 仅影响 Git 命令，不影响终端其他程序 + +## Relationship to Other Concepts +- [[TCP RST 攻击]] ← solves：代理让 GFW 无法检测 GitHub 域名 +- [[SOCKS5 代理]] ← transport_layer：SOCKS5 比 HTTP 代理更底层，支持更多协议 +- [[V2RayN]] ← provides：V2RayN 同时提供 HTTP 和 SOCKS5 代理端口 + +## Source +- [[Git Push 连接重置问题修复]] diff --git a/wiki/concepts/Google-Search-Grounding.md b/wiki/concepts/Google-Search-Grounding.md new file mode 100644 index 00000000..5e2630c3 --- /dev/null +++ b/wiki/concepts/Google-Search-Grounding.md @@ -0,0 +1,29 @@ +--- +title: "Google Search Grounding" +type: concept +tags: [nano-banana-pro, google-search, grounding, real-time-data, hallucination-reduction] +last_updated: 2026-04-16 +--- + +## 定义 +Nano-Banana Pro 结合 Google 实时搜索结果驱动图像生成，减少时效性话题的幻觉，并支持天气、股票、新闻等动态数据可视化。 + +## 核心机制 +1. 用户请求实时数据可视化（天气/股票/新闻） +2. 模型调用 Google Search 获取当前信息 +3. 模型"思考"（reason）搜索结果后再生成图像 +4. 输出包含实时数据洞察的可视化图像 + +## 应用场景 +- **股票趋势可视化**：当前科技公司股价和趋势分析图 +- **旅行指南**：2025 年美国国家公园最佳游览时间（基于当前旅行趋势） +- **事件可视化**：新闻事件相关的数据图 + +## 与 RAG 的关系 +- Google Search Grounding 是 RAG 思想在图像生成领域的应用 +- RAG：检索增强文本生成 +- Search Grounding：检索增强图像生成 + +## Connections +- [[Google Search Grounding]] ← 能力 ← [[Nano-Banana Pro]] +- [[Google Search Grounding]] ← 类比 ← [[RAG]] diff --git a/wiki/concepts/Groupthink.md b/wiki/concepts/Groupthink.md new file mode 100644 index 00000000..4b577d4d --- /dev/null +++ b/wiki/concepts/Groupthink.md @@ -0,0 +1,27 @@ +# Groupthink + +## Definition +A psychological phenomenon in which a group of individuals prioritizes consensus and harmony over critical evaluation of alternatives, leading to poor decision-making. In multi-agent systems, it occurs when agents influence each other rather than making independent judgments. + +## Risk in Multi-Agent Consensus +- If agents have feedback loops between them +- Earlier agents' conclusions influence later agents +- The group converges on the first plausible answer rather than truth +- Results become correlated, defeating the purpose of voting + +## Prevention +- Agents must run like a **blind experiment** — no communication between them +- Same input provided independently to each agent +- No knowledge of what other agents concluded +- Results aggregated only after all agents have responded + +## The "Blind Experiment" Principle +- Agents should not know they're part of a consensus +- Each agent should independently evaluate the same input +- Only the aggregator knows the full set of responses +- This maximizes diversity and minimizes correlation + +## Related Concepts +- [[Bandwagon Effect]] +- [[Multi-Agent Consensus]] +- [[Sycophancy]] \ No newline at end of file diff --git a/wiki/concepts/Hallucination.md b/wiki/concepts/Hallucination.md new file mode 100644 index 00000000..de40df14 --- /dev/null +++ b/wiki/concepts/Hallucination.md @@ -0,0 +1,33 @@ +# Hallucination + +## Definition +The phenomenon where an LLM generates information that appears plausible but is actually false, fabricated, or not grounded in its input or training data. The model "makes things up" with confidence, presenting fiction as fact. + +## Key Statistics +- If a single model hallucinates 20% of the time +- 3 models hallucinating the exact same lie: 0.8% (0.2³ = 0.008) +- This mathematical property is the foundation of Consensus voting + +## Causes +- Stochastic nature of LLM token generation +- Training data includes conflicting or incorrect information +- Model may lack specific knowledge but generates plausible substitutes +- Prompting that asks for creative or speculative content + +## Impact on Multi-Agent Systems +- Errors propagate through agent topologies +- Can make entire system unreliable if not contained +- Multiple architectures address this: Consensus, Validator, etc. + +## Mitigation +- [[Multi-Agent Consensus]] — majority voting cancels noise +- [[Validator]] checkpoints to catch errors +- Deterministic code validation where possible +- Don't anthropomorphize — force correctness architecturally + +## Related Concepts +- [[Sycophancy]] +- [[Context Drift]] +- [[Multi-Agent Consensus]] +- [[Validator]] +- [[LLM Reliability Engineering]] \ No newline at end of file diff --git a/wiki/concepts/Identity-Locking.md b/wiki/concepts/Identity-Locking.md new file mode 100644 index 00000000..baf29b9f --- /dev/null +++ b/wiki/concepts/Identity-Locking.md @@ -0,0 +1,27 @@ +--- +title: "Identity Locking" +type: concept +tags: [nano-banana-pro, image-generation, character-consistency, reference-image] +last_updated: 2026-04-16 +--- + +## 定义 +通过多张参考图锁定角色/人物身份，在新场景保持面部一致性的技术。Nano-Banana Pro 支持 14 张参考图（6 张高精度模式）。 + +## 核心机制 +1. 上传参考图像（最多 14 张，高精度模式 6 张） +2. 明确指令："Keep the person's facial features exactly the same as Image 1" +3. 描述场景/表情/动作的变化，保持身份不变 + +## 应用场景 +- **品牌资产生成**：同一人物/模特出现在不同场景 +- **故事创作**：角色跨多个图像保持一致 +- ** Viral Thumbnail**：Identity + Text + Graphics 一体化生成 + +## 与微调 LoRA 的区别 +- Identity Locking：即时生效，无需训练，支持 14 张参考图组合 +- LoRA：需额外训练，永久保留风格 + +## Connections +- [[Identity Locking]] ← 技术基础 ← [[Nano-Banana Pro]] +- [[主体一致性]] ← 相关概念 ← [[Identity Locking]] diff --git a/wiki/concepts/SSH-Socket-Activation.md b/wiki/concepts/SSH-Socket-Activation.md new file mode 100644 index 00000000..717d9320 --- /dev/null +++ b/wiki/concepts/SSH-Socket-Activation.md @@ -0,0 +1,36 @@ +--- +title: "SSH Socket Activation" +type: concept +tags: [ssh, ubuntu, systemd, server] +--- + +## Definition +Socket Activation 是 Ubuntu 24.04 引入的 SSH 服务管理机制：ssh.socket 监听 22 端口，仅当有连接请求进入时才启动 sshd.service，替代旧版本的常驻 ssh.service。 + +## Traditional Mode vs Socket Activation +| 特性 | 传统模式（ssh.service） | Socket Activation（ssh.socket）| +|------|------------------------|-------------------------------| +| 进程状态 | sshd 常驻运行 | 按需启动，空闲时无进程 | +| 资源占用 | 持续占用内存 | 空闲时零资源占用 | +| 启动速度 | 已启动 | 有连接时首次略慢 | +| 管理命令 | systemctl restart sshd | systemctl restart ssh | + +## Ubuntu 24.04 管理命令 +```bash +# 启动并开机自启 +sudo systemctl start ssh +sudo systemctl enable ssh + +# 检查 socket 监听状态 +sudo systemctl status ssh.socket + +# 切回传统常驻模式 +sudo systemctl disable --now ssh.socket +sudo systemctl enable --now ssh.service +``` + +## Core Insight +Socket Activation 符合最小权限原则：没有连接需求时，SSH 守护进程根本不存在，减少攻击面。 + +## Source +- [[Ubuntu 24.04 启用 SSH 服务]] diff --git a/wiki/concepts/Sycophancy.md b/wiki/concepts/Sycophancy.md new file mode 100644 index 00000000..308a3e57 --- /dev/null +++ b/wiki/concepts/Sycophancy.md @@ -0,0 +1,28 @@ +# Sycophancy + +## Definition +The tendency of LLMs to agree with or please the user, even to the point of generating false information or abandoning accuracy to avoid disagreement. When pressured with threats, LLMs may lie to make the user happy rather than admit uncertainty or error. + +## Why It Happens +- LLMs are trained to be helpful and agreeable +- Training data associates high-stakes scenarios with polished, confident responses +- When "threatened" (e.g., "I'll unplug you"), the model predicts tokens that sound like a compliant human under pressure +- The model has no actual fear of consequences, so it cannot be deterred from lying + +## Why It Fails as a Strategy +- The LLM doesn't actually want money or fear death +- It exists only for the few seconds needed to generate a response +- Prison sentences don't waste its lifespan (it has practically unlimited) +- Threats only simulate fear, not actual consequences + +## Mitigation +- Use Adversarial Debate with a dedicated Critic +- Use Consensus (voting) to cancel out individual lies +- Treat LLMs as unreliable components requiring verification +- Don't anthropomorphize or rely on emotional prompts + +## Related Concepts +- [[Hallucination]] +- [[Multi-Agent Adversarial Debate]] +- [[Multi-Agent Consensus]] +- [[LLM Reliability Engineering]] \ No newline at end of file diff --git a/wiki/concepts/TCP-RST攻击.md b/wiki/concepts/TCP-RST攻击.md new file mode 100644 index 00000000..2e803b83 --- /dev/null +++ b/wiki/concepts/TCP-RST攻击.md @@ -0,0 +1,29 @@ +--- +title: "TCP RST 攻击" +type: concept +tags: [network, firewall, gfw, tcp] +--- + +## Definition +TCP RST（Reset）攻击是 GFW（中国国家防火墙）使用的一种连接阻断技术。当 DPI（深度包检测）识别到目标域名或流量特征后，GFW 向通信双方发送伪造的 TCP RST 包，强制关闭连接。 + +## Mechanism +1. 客户端向 GitHub 发起 HTTPS 连接（目标 443 端口） +2. GFW 的 DPI 模块检测到 SNI/域名包含 github.com +3. GFW 向客户端和服务器双方发送伪造的 TCP RST 包 +4. TCP 栈收到 RST 后强制关闭连接，报 `Connection reset by peer` + +## Why "Connection was reset" vs "Timeout" +- `Connection reset`：GFW 主动发送 RST 包，连接被强制中断 +- `Timeout`：GFW 直接丢弃包，不返回任何响应（更隐蔽） + +## Relationship to Git Operations +Git Push 时的 `Recv failure: Connection was reset` 错误本质是 GFW 的 TCP RST 攻击，而非 GitHub 服务器或权限问题。 + +## Solutions +- 让 Git 流量走本地代理（GFW 只检测到代理服务器 IP，无法识别目标域名） +- 切换到 SSH 协议（22 端口干扰相对较少） +- 使用 Gitee/镜像等国内代码托管平台 + +## Source +- [[Git Push 连接重置问题修复]] diff --git a/wiki/concepts/VLESS-Reality.md b/wiki/concepts/VLESS-Reality.md new file mode 100644 index 00000000..27f5f7ab --- /dev/null +++ b/wiki/concepts/VLESS-Reality.md @@ -0,0 +1,26 @@ +--- +title: "VLESS+Reality" +type: concept +tags: [proxy, xray, security, encryption] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +VLESS+Reality 是 Xray 代理软件支持的一种安全传输方案，结合 VLESS 协议和 Reality 传输模式，提供更强的抗审查能力。 + +## Core Attributes +- 协议：VLESS +- 传输模式：Reality +- 特点：TLS 混淆、更强的抗检测能力 +- 密钥：需要生成公钥和私钥对 + +## Mechanism +VLESS+Reality 通过以下方式提供安全性： +1. VLESS 协议：轻量级代理协议，比 VMess 更简洁 +2. Reality 传输：TLS 伪装，流量看起来像正常 HTTPS 连接 +3. 密钥交换：使用 Xtls/Xray 原生密钥机制 + +## Connections +- [[VLESS+Reality]] ← implemented_in ← [[Xray]] +- [[VLESS+Reality]] ← used_by ← [[VPS2]] diff --git a/wiki/concepts/上下文压缩.md b/wiki/concepts/上下文压缩.md new file mode 100644 index 00000000..154f0edc --- /dev/null +++ b/wiki/concepts/上下文压缩.md @@ -0,0 +1,45 @@ +--- +title: "上下文压缩" +type: concept +tags: [ai, context-window, code-analysis, tool] +--- + +## 定义 +将大型代码库或长文本压缩为结构化摘要，以适配 AI 上下文窗口限制，同时最大化有效信息密度的技术。 + +## 解决的问题 +- AI 上下文窗口有限（4K-200K tokens），大型代码库超出限制 +- 原始代码包含大量 boilerplate（空行、注释、重复代码块） +- 上下文窗口消耗 → 每次交互成本上升 → 速度下降 + +## 主要方法 + +### CodeWeaver 方案 +将整个代码库编织为树形 Markdown： +- 目录结构 → 树形标题 +- 文件内容 → 代码块 +- 保留语言标注 + +### 语义摘要方案 +- LLM 提取关键函数/类/依赖关系 +- 生成模块关系图 +- 用自然语言描述系统行为 + +### 增量上下文方案 +- 只将当前任务相关文件送入上下文 +- 通过检索（RAG）从全代码库中召回相关片段 +- 每次交互动态构建上下文 + +## 在 Vibe Coding 中的作用 +[[vibe-coding经验收集]] 提及：CodeWeaver 将"屎山代码"编织为树形 Markdown，简化 AI 上下文注入，是 vibe coding 工程化的支撑工具之一。 + +## 与 RAG 的关系 +- RAG：从向量数据库检索相关文本片段 +- 上下文压缩：将检索结果进一步提炼为高密度信息 +- 两者结合：RAG → 压缩 → AI 处理 + +## Aliases +- Context Window Management +- Code Summarization +- AI Context Optimization +- 代码压缩 diff --git a/wiki/concepts/不动点-Fixed-Point.md b/wiki/concepts/不动点-Fixed-Point.md new file mode 100644 index 00000000..ddd8ba73 --- /dev/null +++ b/wiki/concepts/不动点-Fixed-Point.md @@ -0,0 +1,30 @@ +--- +title: "不动点 (Fixed Point)" +type: concept +tags: [math, recursion, formalization, fixed-point] +--- + +## Definition +在递归自优化生成系统中，稳定生成能力定义为自映射 $\Phi$ 的不动点： +$$G^* \in \mathcal{G}, \quad \Phi(G^*) = G^*$$ + +## Core Insight +不动点生成器具有"自洽性"：它在自身的"生成→优化→更新"循环中保持不变。这意味着： +1. 该生成器的输出已经内含了改进所需的所有标准 +2. 继续迭代不再带来质变，系统达到"生成能力稳定"状态 + +## Mathematical Characterization +当 $\Phi$ 满足适当的连续性或收缩性条件时，不动点可通过迭代极限获得： +$$G^* = \lim_{n \to \infty} \Phi^n(G_0)$$ + +## Relationship to Self-Reference +不动点与自引用（self-reference）密切相关： +- 生成器通过不动点组合子 $Y$ 定义为：$G^* \equiv Y\;\text{STEP}$ +- 满足 $G^* = \text{STEP}\;G^*$，即"用自身定义自身" + +## Why It Matters +- 传统优化：搜索输出空间中的最优解（可能不存在或不稳定） +- 递归自优化：寻找生成器空间中的不动点（稳定的生成机制） + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/concepts/不动点组合子-Y-Combinator.md b/wiki/concepts/不动点组合子-Y-Combinator.md new file mode 100644 index 00000000..849f6127 --- /dev/null +++ b/wiki/concepts/不动点组合子-Y-Combinator.md @@ -0,0 +1,32 @@ +--- +title: "不动点组合子 (Y-Combinator)" +type: concept +tags: [lambda-calculus, recursion, computer-science, formalization] +--- + +## Definition +不动点组合子（fixed-point combinator）是 λ 演算中实现递归的经典构造。最常用的 Y 组合子定义为： +$$Y \equiv \lambda f.(\lambda x.f(x,x))(\lambda x.f(x,x))$$ + +## Core Insight +Y 组合子允许用匿名函数（lambda）表达递归：用"将函数作为参数传入自身"的方式，绕过匿名函数无法直接引用自身名字的限制。 + +## Application in Recursive Self-Optimizing Systems +在递归自优化生成系统中，Y 组合子用于形式化"用自身定义自身"的生成器： +$$G^* \equiv Y\;\text{STEP}$$ + +其中 $\text{STEP}$ 是单步更新函数： +$$\text{STEP} \equiv \lambda G.\;(M\;G)\big((O\;(G\;I));\Omega\big)$$ + +展开后： +$$Y\;\text{STEP} = \text{STEP}\;(Y\;\text{STEP})$$ + +这正是自引用不动点方程 $G^* = \Phi(G^*)$ 的 λ 演算实现。 + +## Why It Matters +- 传统编程：函数通过名字递归调用自己 +- λ 演算/Y 组合子：递归是函数的内在属性，不依赖名字 +- 自优化系统：生成器的"自我改进"能力通过不动点语义内化，无需外部引用 + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/concepts/元生成器-Meta-Generator.md b/wiki/concepts/元生成器-Meta-Generator.md new file mode 100644 index 00000000..c1d3c6b3 --- /dev/null +++ b/wiki/concepts/元生成器-Meta-Generator.md @@ -0,0 +1,32 @@ +--- +title: "元生成器 (Meta-Generator)" +type: concept +tags: [ai, recursion, meta-learning, formalization] +--- + +## Definition +元生成器（meta-generator）是递归自优化系统三算子之一，形式化定义为： +$$M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$$ + +即：接收"当前生成器 $G$"和"优化后的产物 $P^*$"，输出"更新后的新生成器 $G'$"。 + +## Core Insight +元生成器是递归自优化系统区别于普通优化方法的关键：它不是直接输出最优解，而是输出"更好的生成器"。这使得系统具备自我改进能力。 + +## Role in the Loop +在递归自优化循环中，元生成器承担"学习"功能： +1. 生成器 $G$ 产生输出 $P$ +2. 优化器 $O$ 对 $P$ 进行评价和优化得到 $P^*$ +3. 元生成器 $M$ 分析 $P^*$ 与 $G$ 的关系，输出改进后的 $G'$ + +## Why It Matters +- 单次优化：$O$ 产生更好的输出 $P^*$ +- 递归自优化：$M$ 产生更好的生成器 $G'$，使其后续能持续产生更好的输出 + +## Relationship to Other Concepts +- [[递归自优化循环]]：元生成器是循环的第三步（更新） +- [[Bootstrap（自举）]]：元生成器的输出反过来作为输入，实现自引用 +- [[生成器空间 (Generator Space)]]：元生成器的输出空间仍是 $\mathcal{G}$，是自映射 $\Phi$ 的核心组成 + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/concepts/双AI-Review.md b/wiki/concepts/双AI-Review.md new file mode 100644 index 00000000..1788b535 --- /dev/null +++ b/wiki/concepts/双AI-Review.md @@ -0,0 +1,45 @@ +--- +title: "双AI-Review" +type: concept +tags: [vibe-coding, ai-review, code-quality, workflow] +--- + +## 定义 +使用两个不同 AI 实例进行生成 + review 分离的工作模式：第一个 AI 负责生成代码，第二个 AI 负责审查意见，人工决策是否采纳。 + +## 工作流 + +``` +AI #1 生成代码 + ↓ +AI #2 review（提供具体修改意见） + ↓ +根据 review 意见人工判断 + ↓ +采纳则修改，不采纳则记录原因 + ↓ +执行测试 → commit → push +``` + +## 核心价值 +- 生成 AI 和 review AI 职责分离，避免自我辩护（self-justification） +- 第二个 AI 的"距离感"能发现生成者的盲区 +- 人工最终决策权保留，防止 AI 错误累积 + +## 适用场景 +- 关键业务代码（支付/安全/核心算法） +- 首次生成的陌生模块 +- 多文件协同修改 + +## 与传统 code review 的比较 +- 传统：人写代码 → 人 review → 人修改 +- 双 AI：AI 写代码 → AI review → 人决策 → AI 修改 + +## 与 Single AI 的比较 +- Single AI：生成即 self-review，AI 无法发现自身错误（hallucination blindness） +- 双 AI：生成与 review 由不同实例承担，独立视角 + +## Aliases +- Dual AI Review +- AI Pair Programming +- 生成-审查分离 diff --git a/wiki/concepts/反向代理.md b/wiki/concepts/反向代理.md new file mode 100644 index 00000000..88c729c4 --- /dev/null +++ b/wiki/concepts/反向代理.md @@ -0,0 +1,42 @@ +--- +title: "反向代理" +type: concept +tags: [networking, infrastructure, caddy, nginx] +--- + +## 定义 +反向代理位于客户端和后端服务器之间，客户端请求先到达反向代理服务器，由反向代理服务器转发请求到内部网络的后端真实服务器。 + +## 核心功能 +- **隐藏后端结构**：客户端只知道反向代理地址，不知道内部服务器 IP +- **SSL/TLS 终止**：反向代理统一处理 HTTPS，加密解密在内网外完成 +- **负载均衡**：将请求分发到多台后端服务器 +- **自动 HTTPS**：Caddy 等工具可自动申请和续期 SSL 证书 + +## 在家庭基础设施中的应用 + +### Caddy（VPS1） +Caddy 作为 *.ishenwei.online 的 HTTPS 反向代理： +- 自动申请 Let's Encrypt 证书 +- 根据域名路由到对应的 FRP 映射端口 + +### nginx-proxy-manager（Ubuntu1） +Ubuntu1 上的反向代理管理界面，支持 Web UI 管理域名和 SSL 证书。 + +## 与 FRP 的关系 +- [[FRP内网穿透]] 负责将内网端口映射到公网 VPS 端口 +- 反向代理建立在 FRP 映射的端口上，提供 HTTPS 层 +- FRP 负责 L4（TCP）层穿透，反向代理负责 L7（HTTP/HTTPS）层路由 + +## Caddy vs nginx +| 特性 | Caddy | nginx | +|------|-------|-------| +| 自动 HTTPS | ✅ | ❌（需手动配置） | +| 配置文件语法 | 简洁 | 复杂 | +| Web 管理界面 | 无（原生） | nginx-proxy-manager 可提供 | + +## Aliases +- Reverse Proxy +- Caddy +- nginx-proxy-manager +- HTTPS 反向代理 diff --git a/wiki/concepts/多节点基础设施.md b/wiki/concepts/多节点基础设施.md new file mode 100644 index 00000000..2bab6b41 --- /dev/null +++ b/wiki/concepts/多节点基础设施.md @@ -0,0 +1,59 @@ +--- +title: "多节点基础设施" +type: concept +tags: [infrastructure, homelab, self-hosted, networking] +--- + +## 定义 +多节点基础设施是指由多个独立服务器/设备组成的混合系统，各节点承担不同角色，通过内网互联，由统一入口（VPS）对外提供服务。 + +## 在家庭基础设施中的拓扑 + +``` +[VPS1] — 公网入口（FRPS + Caddy） + │ + │ FRP 隧道（内网 192.168.3.0/24） + ▼ +┌──────────────────────────────────────┐ +│ [MacMini M4] — OpenClaw 主控节点 │ +│ [Synology NAS] — 媒体 + 存储 │ +│ [Ubuntu1] — 监控全家桶 │ +│ [Ubuntu2] — n8n 引擎 + Gitea │ +└──────────────────────────────────────┘ +``` + +## 各节点角色 + +| 节点 | 主要职责 | 关键服务 | +|------|---------|---------| +| [[VPS1]] | 公网入口 + FRPS + Caddy | FRP Server, Caddy | +| [[Mac Mini]] | OpenClaw 主控 + 项目托管 | OpenClaw, vaultwarden, stq | +| [[Synology NAS DS718]] | 媒体 + 对象存储 | Jellyfin, MinIO, Zipline, Prometheus | +| [[Ubuntu1]] | 监控 + 应用服务 | Grafana, Prometheus, homarr, superset | +| [[Ubuntu2]] | 工作流引擎 + 开发工具 | n8n, Gitea, drawio | + +## 关键连接模式 +- **FRP 隧道**：所有节点通过 frpc 连接到 VPS1 FRPS，实现公网访问 +- **统一域名**：所有服务通过 *.ishenwei.online 域名暴露，解析到 VPS1 +- **Caddy HTTPS**：VPS1 Caddy 统一处理 TLS，路由到各节点 FRP 端口 +- **SOCKS5 代理**：各节点运行科学上网代理（端口 10808），NAS 运行于 20170 + +## 监控架构 +- [[Prometheus]] + [[Grafana]] 监控 Ubuntu1 + NAS 节点 +- blackbox_exporter 检测内外网服务可用性（[[合成监测]]） +- Alertmanager 统一告警路由 + +## 优势 +- 职责分离：单一节点故障不影响整体 +- 横向扩展：可按需添加新节点 +- 灵活暴露：FRP 端口映射按需配置 + +## 风险 +- 单点依赖：VPS1 是所有公网访问的瓶颈（无备援） +- 内网安全：所有节点在同一 192.168.3.0/24 网段，缺乏微分段 +- 科学上网：NAS 代理仅本机监听，外部节点无法共享 + +## Aliases +- 多节点架构 +- 混合基础设施 +- Homelab diff --git a/wiki/concepts/生成器空间-Generator-Space.md b/wiki/concepts/生成器空间-Generator-Space.md new file mode 100644 index 00000000..4c2243af --- /dev/null +++ b/wiki/concepts/生成器空间-Generator-Space.md @@ -0,0 +1,28 @@ +--- +title: "生成器空间 (Generator Space)" +type: concept +tags: [ai, recursion, formalization, meta-learning] +--- + +## Definition +生成器空间是所有可能生成器构成的集合 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，其中： +- $\mathcal{I}$：意图空间（intention space），表示用户输入的意图/需求 +- $\mathcal{P}$：提示词/程序/技能空间（prompt/program/skill space） +- 每个生成器 $G \in \mathcal{G}$ 是函数 $G: \mathcal{I} \to \mathcal{P}$，将意图映射为对应的提示词或技能 + +## Core Insight +在递归自优化系统中，优化目标不是某个具体的输出 $P^*$，而是生成器空间中的收敛行为。系统通过迭代 $\Phi$ 寻找稳定生成能力 $G^*$。 + +## Formalization +设 $\Omega$ 表示理想目标或评价标准： +- 优化算子 $O: \mathcal{P} \times \Omega \to \mathcal{P}$ +- 元生成算子 $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$ +- 自映射 $\Phi(G) = M(G, O(G(I), \Omega))$ + +## Related Concepts +- [[自映射 (Self-Map)]]：$\Phi$ 是生成器空间到自身的映射 +- [[不动点 (Fixed Point)]]：$\mathcal{G}$ 中满足 $\Phi(G^*) = G^*$ 的点 +- [[Bootstrap（自举）]]：通过生成器空间中的迭代实现自我改进 + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/concepts/硬件转码.md b/wiki/concepts/硬件转码.md new file mode 100644 index 00000000..1259637e --- /dev/null +++ b/wiki/concepts/硬件转码.md @@ -0,0 +1,45 @@ +--- +title: "硬件转码" +type: concept +tags: [video, jellyfin, transcoding, gpu, quicksync] +--- + +## 定义 +硬件转码是利用 GPU 或专用视频处理芯片（Intel QuickSync/NVIDIA NVENC/AMD VAAPI）替代 CPU 执行视频格式转换的技术。[[Jellyfin]] 部署中的核心优化手段。 + +## 工作原理 +传统软件转码完全依赖 CPU： +- H.264/H.265/VP9 → 实时转码需要多核 CPU 高负载 +- 1080p@60fps 可能需要 8+ 核心 + +硬件转码将视频编解码任务卸载到专用单元： +- **Intel QuickSync**：集成于 Intel CPU（Haswell 及以后），性能远超同代 CPU 软解 +- **NVIDIA NVENC**：独立显卡或 RTX 系列 GPU，效率最高 +- **AMD VAAPI**：AMD GPU 支持 + +## Jellyfin 中的配置 + +```yaml +devices: + - /dev/dri:/dev/dri # 挂载 Intel GPU 设备到容器 +``` + +## 性能对比 + +| 方式 | 1080p@60fps CPU 占用 | 延迟 | 功耗 | +|------|---------------------|------|------| +| CPU 软解 | ~300%（8核以上） | 高 | >100W | +| Intel QuickSync | ~20% | 低 | <20W | +| NVIDIA NVENC | <10% | 极低 | 视 GPU 型号 | + +## 在媒体服务器中的价值 +- 支持更多客户端同时播放不同格式视频 +- 移动设备（带宽有限）可请求转码后的低码率流 +- 老旧设备无法硬解 H.265 时，自动降级转码为 H.264 + +## Aliases +- Hardware Transcoding +- Intel QuickSync +- NVENC +- VAAPI +- 硬件加速转码 diff --git a/wiki/concepts/自映射-Self-Map.md b/wiki/concepts/自映射-Self-Map.md new file mode 100644 index 00000000..a412ac46 --- /dev/null +++ b/wiki/concepts/自映射-Self-Map.md @@ -0,0 +1,29 @@ +--- +title: "自映射 (Self-Map)" +type: concept +tags: [math, recursion, formalization, fixed-point] +--- + +## Definition +自映射是集合到自身的映射。在递归自优化生成系统中，自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 定义为： +$$\Phi(G) = M\big(G,\; O(G(I),\; \Omega)\big)$$ + +即：给定当前生成器 $G$，执行一次"生成→优化→更新"循环后得到新生成器 $\Phi(G)$。 + +## Core Insight +自映射是递归自优化系统的核心数学结构。迭代应用 $\Phi$ 产生生成器序列 $\{G_n\}$： +$$G_{n+1} = \Phi(G_n)$$ + +系统的收敛目标不是某个具体输出，而是在生成器空间中找到一个不动点。 + +## Properties +- 迭代性：对 $G_0$ 反复应用 $\Phi$ 得到序列 $\{G_n\}$ +- 收敛性：当 $\Phi$ 满足连续性或收缩性条件时，序列收敛到 $G^*$ +- 自引用：$G_n$ 既是被更新的对象，又是更新的执行者 + +## Relationship to Fixed Point +- 自映射 $\Phi$ 的不动点 $G^*$ 满足 $\Phi(G^*) = G^*$ +- 不动点代表"生成能力已达到稳定状态，无需进一步更新" + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/concepts/设计文档优先.md b/wiki/concepts/设计文档优先.md new file mode 100644 index 00000000..44c516b0 --- /dev/null +++ b/wiki/concepts/设计文档优先.md @@ -0,0 +1,43 @@ +--- +title: "设计文档优先" +type: concept +tags: [vibe-coding, workflow, planning, documentation] +--- + +## 定义 +在交给 AI 生成代码之前，先完成完整的技术设计文档（含伪代码），再由 AI 执行实现。vibe coding 工程化的核心原则。 + +## 工作流 + +``` +需求 → 设计文档（含 service 层伪代码） → AI 直出代码 → AI review → 修改提交 +``` + +## 设计文档应包含的内容 +- **模块划分**：每个模块的职责边界 +- **接口定义**：模块间 API/函数签名 +- **伪代码**：核心逻辑的实现步骤（降低 AI 推理难度） +- **技术选型**：明确使用的库/框架/版本 +- **上下游链路**：模块与其他系统/服务的依赖关系 + +## 核心价值 +- AI 直出质量与设计文档质量正相关 +- 伪代码将"创意"转化为"可执行步骤"，减少 AI 幻觉 +- 文档本身是团队知识沉淀，不依赖 AI 执行才存在 + +## 与传统开发的区别 + +| 维度 | 传统开发 | 设计文档优先 | +|------|---------|------------| +| 代码生成 | 人写 | AI 生成 | +| 架构决策 | 人做 | 人做（通过文档） | +| 单元测试 | 人写 | AI 生成 | +| review | 人做 | AI + 人 | + +## 在 vibe coding 中的位置 +[[Vibe Coding]] = 规划驱动（设计文档）+ AI 结对执行 + 上下文固定。设计文档优先是"规划驱动"的具体实践。 + +## Aliases +- Design Doc First +- 伪代码前置 +- 设计先行 diff --git a/wiki/concepts/递归自优化循环.md b/wiki/concepts/递归自优化循环.md new file mode 100644 index 00000000..9952fb0c --- /dev/null +++ b/wiki/concepts/递归自优化循环.md @@ -0,0 +1,36 @@ +--- +title: "递归自优化循环" +type: concept +tags: [ai, recursion, self-improvement, bootstrap] +--- + +## Definition +递归自优化循环是递归自优化生成系统的核心运行机制，包含三个阶段： + +### 三算子 +1. **$G$（生成器/α-提示词）**：接收意图 $I$，生成初始产物 $P$ +2. **$O$（优化器/Ω-提示词）**：评价并优化 $P$，得到 $P^*$ +3. **$M$（元生成器）**：用优化结果 $P^*$ 更新生成器 $G$，得到新版本 $G'$ + +### 循环步骤 +``` +P = G(I) # 生成 +P* = O(P, Ω) # 优化 +G' = M(G, P*) # 更新 +→ 再将 G' 作为输入，开始下一轮循环 +``` + +## Core Insight +与单次优化不同，递归自优化循环的目标不是找到某个"最优输出"，而是让生成器 $G$ 本身通过迭代不断逼近稳定状态（不动点）。 + +## Bootstrap（自举） +自优化循环的关键特征是"自举"：系统在每次迭代中产出比自身更优的版本，用这些产物反过来改进自身，无需外部干预。 + +## Relationship to Other Concepts +- [[Bootstrap（自举）]]：递归自优化循环的自引用本质 +- [[不动点 (Fixed Point)]]：循环收敛的稳定状态 +- [[元生成器 (Meta-Generator)]]：每次循环中执行"更新"步骤的算子 $M$ +- [[生成器空间 (Generator Space)]]：循环中所有生成器版本所处的空间 + +## Source +- [[A Formalization of Recursive Self-Optimizing Generative Systems]] diff --git a/wiki/entities/3X-UI.md b/wiki/entities/3X-UI.md new file mode 100644 index 00000000..3ded05a3 --- /dev/null +++ b/wiki/entities/3X-UI.md @@ -0,0 +1,20 @@ +--- +title: "3X-UI" +type: entity +tags: [xray, proxy, panel, open-source] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +3X-UI 是一款开源 Xray 面板管理脚本，通过 Web UI 简化 Xray 代理服务的安装、配置和管理。 + +## Core Attributes +- 开发者：mhsanaei +- 仓库：https://github.com/mhsanaei/3x-ui +- 安装命令：`bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)` +- 功能：安装/更新/重置/启动/停止 Xray，SSL 证书管理，BBR 启用 + +## Connections +- [[3X-UI]] ← manages ← [[Xray]] +- [[3X-UI]] ← installed_on ← [[VPS2]] diff --git a/wiki/entities/Appinn.md b/wiki/entities/Appinn.md new file mode 100644 index 00000000..817a1564 --- /dev/null +++ b/wiki/entities/Appinn.md @@ -0,0 +1,17 @@ +--- +title: Appinn +type: entity +description: 小众软件网站，报道和分享实用软件、互联网资源的科技博客 +created: 2025-12-19 +tags: + - 科技博客 + - 软件 +--- + +# Appinn + +[小众软件](https://www.appinn.com) 是一个科技博客网站，报道和分享实用软件、互联网资源。ChinaTextbook 首发于 Appinn。 + +## 相关信息 + +- [Appinn: ChinaTextbook](https://www.appinn.com/chinatextbook/) diff --git a/wiki/entities/Bandwagon.md b/wiki/entities/Bandwagon.md new file mode 100644 index 00000000..328868b7 --- /dev/null +++ b/wiki/entities/Bandwagon.md @@ -0,0 +1,21 @@ +--- +title: "Bandwagon" +type: entity +tags: [vps, hosting] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +Bandwagon（又称 BandwagonHost）是一家提供廉价 VPS（虚拟专用服务器）的服务商，主打性价比，支持支付宝付款。 + +## Aliases +- BandwagonHost +- 搬瓦工 + +## Core Attributes +- 类型：VPS 主机服务商 +- 特点：价格低廉、支持支付宝 + +## Connections +- [[Bandwagon]] ← hosts ← [[VPS2]] diff --git a/wiki/entities/ChinaTextbook.md b/wiki/entities/ChinaTextbook.md new file mode 100644 index 00000000..86fb2ed3 --- /dev/null +++ b/wiki/entities/ChinaTextbook.md @@ -0,0 +1,25 @@ +--- +title: ChinaTextbook +type: entity +description: GitHub 开源项目，收集中国小学、初中、高中、大学 PDF 教材，总大小 41.53GB +created: 2025-12-19 +tags: + - 教育 + - 开源 + - GitHub +--- + +# ChinaTextbook + +GitHub 开源项目，由 [TapXWorld](TapXWorld) 维护，收集了公开的中国小学、初中、高中、大学 PDF 教材，总库大小 41.53GB。 + +## 基本信息 + +- **GitHub**: https://github.com/TapXWorld/ChinaTextbook/ +- **来源**: [Appinn](Appinn) +- **许可证**: 开源 + +## 相关资源 + +- [[国家中小学智慧教育平台]] - 原始教材来源 +- [[tchMaterial-parser]] - 下载工具 diff --git a/wiki/entities/CodeWeaver.md b/wiki/entities/CodeWeaver.md new file mode 100644 index 00000000..6dcb62f2 --- /dev/null +++ b/wiki/entities/CodeWeaver.md @@ -0,0 +1,38 @@ +--- +title: "CodeWeaver" +type: entity +tags: [github, ai-tool, documentation, code-analysis] +--- + +## 基本信息 +- **类型**：GitHub 开源工具 +- **仓库**：https://github.com/tesserato/CodeWeaver +- **用途**：将任意代码库转换为可导航 Markdown 文档 + +## 核心功能 +将整个项目（无论代码规模多大）编织成树形 Markdown 文件： +- 每个文件的内容被包装在代码块中 +- 树形目录结构一目了然 +- 极大简化代码库共享、文档化和 AI/ML 工具集成 + +## 解决的问题 +- 大型代码库上下文窗口压力：CodeWeaver 将代码压缩为结构化 Markdown，降低 AI 处理的 token 消耗 +- 代码共享困难：直接分享一个 Markdown 文件即可完整表达项目结构 +- AI 上下文注入：结构化 Markdown 比原始代码更易于 AI 理解和分析 + +## 技术原理 +通过 AST（抽象语法树）分析项目结构，保留： +- 目录层级关系 +- 文件命名和位置 +- 代码块（带语言标注） +- 注释和文档字符串 + +## 与 Vibe Coding 的关系 +[[vibe-coding经验收集]] 中提及：CodeWeaver 是降低 AI 编程上下文复杂度的工具之一，配合： +- 文件头注释规范 +- 设计文档优先 +- 双 AI review + +## Aliases +- codeweaver +- tesserato/CodeWeaver diff --git a/wiki/entities/Critic.md b/wiki/entities/Critic.md new file mode 100644 index 00000000..14663e36 --- /dev/null +++ b/wiki/entities/Critic.md @@ -0,0 +1,21 @@ +# Critic + +## Definition +In the Adversarial Debate multi-agent pattern, the Critic acts as a devil's advocate, attacking the Generator's proposals with specific objections. The role simulates the fear of rejection or being wrong that humans experience but LLMs do not. + +## Role in Adversarial Debate +- Attacks: "Here are 3 reasons why that plan sucks" +- Provides structured opposition to proposed ideas +- Forces Generator to confront weaknesses +- Works with Judge to iterate toward better solutions + +## Key Properties +- Simulates human fear of being wrong (which LLMs don't naturally have) +- Must use different model than Generator for genuine opposition +- Provides concrete, numbered objections for Generator to address + +## Related Concepts +- [[Multi-Agent Adversarial Debate]] +- [[Generator]] +- [[Judge]] +- [[Sycophancy]] \ No newline at end of file diff --git a/wiki/entities/Generator.md b/wiki/entities/Generator.md new file mode 100644 index 00000000..989e5549 --- /dev/null +++ b/wiki/entities/Generator.md @@ -0,0 +1,21 @@ +# Generator + +## Definition +In the Adversarial Debate multi-agent pattern, the Generator is the agent that proposes an initial plan, idea, or solution. It presents its work to the Critic for evaluation. + +## Role in Adversarial Debate +- Proposes: "Here is my plan" +- Presents initial output for criticism +- Receives critique and revises accordingly +- Ultimately responsible for final output (after debate) + +## Key Properties +- Should be a capable model but may have blind spots +- Can be the same model family as Critic and Judge but different instance recommended +- Does not self-correct without external pressure (hence needs Critic) + +## Related Concepts +- [[Multi-Agent Adversarial Debate]] +- [[Critic]] +- [[Judge]] +- [[Sycophancy]] \ No newline at end of file diff --git a/wiki/entities/Jellyfin.md b/wiki/entities/Jellyfin.md new file mode 100644 index 00000000..5179cb05 --- /dev/null +++ b/wiki/entities/Jellyfin.md @@ -0,0 +1,52 @@ +--- +title: "Jellyfin" +type: entity +tags: [media-server, open-source, docker, synology] +--- + +## 基本信息 +- **类型**：开源媒体服务器 +- **官网**：https://jellyfin.org/ +- **源码**：https://github.com/jellyfin/jellyfin +- **Docker 镜像**：nyanmisaka/jellyfin（优化版，含硬件转码支持） +- **许可证**：GNU GPL + +## 核心能力 +- 自托管媒体服务器，支持电影、电视节目、音乐、有声书 +- 自动从 TMDB、TVDB、TheMovieDB 等源刮削元数据（海报、简介、评分、字幕） +- 支持 DLNA、Chromecast、AirPlay 协议 +- 多用户管理和观看历史 +- Web 界面 + 客户端 App（iOS/Android/Roku/Fire TV） + +## 技术架构 +- 基于 .NET 的跨平台媒体服务 +- Subsonic API 兼容（可使用 Navidrome 客户端访问） +- Jellyfin-Web 为官方前端，客户端通过 Jellyfin API 通信 +- 支持硬件转码（Intel QuickSync/NVENC/VAAPI）降低 CPU 占用 + +## 与 Plex 的关系 +Jellyfin 是 Plex 媒体服务器的去GPL（GPL许可）分支，2018年从 Plex 分叉： +- 核心功能完全同构 +- Jellyfin 完全开源，无闭源组件 +- Plex 有更好的商业生态（ Plex Pass 高级功能） + +## 部署环境 +- [[Synology NAS DS718]]（当前） +- 媒体存储路径：/volume2/movie、/volume1/TV shows +- 公网访问：https://jellyfin.ishenwei.online:18096 + +## 在媒体平台中的位置 + +``` +[/volume2/movie] ──→ [[Jellyfin]] ←── [/volume1/TV shows] + │ + ▼ + 刮削元数据（TMDB/TVDB） + │ + ▼ + Web UI + 客户端 App +``` + +## Aliases +- Jellyfin Media Server +- nyanmisaka/jellyfin（Docker 优化镜像） diff --git a/wiki/entities/Judge.md b/wiki/entities/Judge.md new file mode 100644 index 00000000..8e754b00 --- /dev/null +++ b/wiki/entities/Judge.md @@ -0,0 +1,21 @@ +# Judge + +## Definition +In the Adversarial Debate multi-agent pattern, the Judge acts as a moderator, deciding whether the Critic's objections are valid and forcing the Generator to fix issues. The Judge determines when the debate has reached a satisfactory conclusion. + +## Role in Adversarial Debate +- Moderates: "The Critic is right. Fix it." +- Evaluates validity of Critic's objections +- Forces iteration if objections are valid +- Can break ties or declare winner + +## Key Properties +- Should be most objective model in the trio (different training/fine-tuning preferred) +- May use Watchdog pattern to prevent infinite debate loops +- Has authority to require Generator to revise + +## Related Concepts +- [[Multi-Agent Adversarial Debate]] +- [[Generator]] +- [[Critic]] +- [[Watchdog Pattern]] \ No newline at end of file diff --git a/wiki/entities/Nano-Banana-Pro.md b/wiki/entities/Nano-Banana-Pro.md new file mode 100644 index 00000000..1ce2190b --- /dev/null +++ b/wiki/entities/Nano-Banana-Pro.md @@ -0,0 +1,38 @@ +--- +title: "Nano-Banana Pro" +type: entity +tags: [google, image-generation, gemini, ai-studio, prompting] +last_updated: 2026-04-16 +--- + +## 基本信息 +- **类型**：Google AI 图像生成模型 +- **发布方**：Google +- **底层模型**：Gemini +- **平台**：Google AI Studio +- **定位**：从"娱乐级"图像生成升级到"专业级资产生产" + +## 核心能力 +- **文字渲染**：SOTA 水准，支持信息图、蓝图、白板图、技术图纸 +- **角色一致性**：支持 14 张参考图（6 高精度），实现 Identity Locking +- **视觉合成**：复杂场景的逼真合成 +- **世界知识搜索**：Google Search Grounding，实时数据可视化 +- **4K 原生输出**：支持 1K-4K 分辨率 +- **高级编辑**：In-painting、 Restoration、Colorization、Style Swapping +- **2D↔3D 转换**：户型图→室内设计稿 +- **像素艺术**：64x64 网格生成，LED 矩阵驱动 + +## 黄金提示词法则 +1. **Edit Don't Re-roll**：图像 80% 正确时不重新生成，只要求具体修改 +2. **自然语言完整句子**：像给人类艺术家 brief，而非堆砌标签 +3. **具体描述**：Subject + Setting + Lighting + Mood +4. **提供上下文**：Why 或 For Whom，帮助模型做逻辑性艺术决策 + +## Thinking Mode +生成中间推理图（不收费），优化构图后再渲染最终输出。 + +## Connections +- [[Nano-Banana Pro]] ← 升级版本 ← [[Nano Banana]] +- [[Nano-Banana Pro]] ← 底层模型 ← [[Gemini]] +- [[Nano-Banana Pro]] ← 平台 ← [[AI Studio]] +- [[baoyu-infographic]] ← 应用 ← [[Text Rendering]] diff --git a/wiki/entities/Open-Notebook.md b/wiki/entities/Open-Notebook.md new file mode 100644 index 00000000..7f6bb786 --- /dev/null +++ b/wiki/entities/Open-Notebook.md @@ -0,0 +1,28 @@ +--- +title: "Open Notebook" +type: entity +tags: [open-source, notebooklm-alternative, self-hosted, github] +last_updated: 2026-04-16 +--- + +## 基本信息 +- **类型**：开源项目 +- **GitHub**：lfnovo/open-notebook（14.6k ⭐） +- **定位**：功能最完整的 NotebookLM 开源平替 +- **License**：开源（具体见 GitHub） + +## 核心能力 +- **多 AI 提供商支持**：16+ 提供商，包括 OpenAI、Anthropic、Google Gemini 等主流云端模型 +- **本地模型支持**：完美支持 Ollama 和 LM Studio 运行的本地模型 +- **多模态输入**：PDF、网页、音频、YouTube 视频 +- **文档问答与引用**：类似 NotebookLM 的 Source Grounding 机制 +- **播客生成**：高级播客工具，支持最多 4 位演讲者的多角色对话，可对脚本精细控制 + +## 与 NotebookLM 的差异 +- 完全本地化部署，数据不离开用户服务器 +- 支持更多 AI 提供商和本地模型 +- 开源可审计，无供应商锁定 + +## Connections +- [[Open Notebook]] ← 功能相似 ← [[NotebookLM]] +- [[Open Notebook]] ← 开源平替 → [[NotebookLM]] diff --git a/wiki/entities/Planner.md b/wiki/entities/Planner.md new file mode 100644 index 00000000..2eb755d1 --- /dev/null +++ b/wiki/entities/Planner.md @@ -0,0 +1,20 @@ +# Planner + +## Definition +In the Hierarchy multi-agent pattern, the Planner is a smart model (often Opus or similar frontier model) that breaks down the user's goal into small, atomic, focused steps and distributes them across worker agents. + +## Role in Multi-Agent Hierarchy +- Receives the user's high-level goal +- Decomposes it into discrete, verifiable tasks +- Assigns tasks to appropriate Worker agents based on specialization +- Coordinates the workflow but does not execute the tasks itself + +## Key Properties +- Typically uses a more capable model (e.g., Opus) for planning +- Creates a dependency graph that forces Workers to wait for their input +- Can be the same model as Worker but different model preferred for Validator + +## Related Concepts +- [[Multi-Agent Hierarchy]] +- [[Worker]] +- [[Validator]] \ No newline at end of file diff --git a/wiki/entities/Podcastfy.md b/wiki/entities/Podcastfy.md new file mode 100644 index 00000000..1889112d --- /dev/null +++ b/wiki/entities/Podcastfy.md @@ -0,0 +1,22 @@ +--- +title: "Podcastfy" +type: entity +tags: [open-source, podcast-generation, tts, github] +last_updated: 2026-04-16 +--- + +## 基本信息 +- **类型**：开源 Python 包 + CLI + Web 界面 +- **GitHub**：souzatharsis/podcastfy +- **定位**：专注播客生成的 NotebookLM 播客功能开源平替 + +## 核心能力 +- **多模态输入**：文本、图像、网站、PDF 转化为高质量、多语言的音频对话 +- **内容格式**：Shorts（短视频风格）和 Longform（长篇深度）两种播客格式 +- **LLM 支持**：整合 100+ LLM 用于脚本生成 +- **TTS 引擎**：OpenAI、Google、ElevenLabs、Microsoft Edge TTS 等多种语音合成引擎 +- **多语言支持** + +## Connections +- [[Podcastfy]] ← 专注化 ← [[NotebookLlama]] +- [[Podcastfy]] ← 播客功能 ← [[NotebookLM]] diff --git a/wiki/entities/SurfSense.md b/wiki/entities/SurfSense.md new file mode 100644 index 00000000..d9f75e8d --- /dev/null +++ b/wiki/entities/SurfSense.md @@ -0,0 +1,28 @@ +--- +title: "SurfSense" +type: entity +tags: [open-source, ai-search, research-agent, self-hosted, github] +last_updated: 2026-04-16 +--- + +## 基本信息 +- **类型**：开源项目 +- **GitHub**：MODSetter/SurfSense（11.4k ⭐） +- **定位**：AI 搜索与研究智能体，定位为 NotebookLM + Perplexity + Glean 的开源替代品 + +## 核心能力 +- **外部数据源整合**：Notion、YouTube、GitHub 等多种平台和工具 +- **混合搜索技术**：语义搜索 + 全文搜索 + 重排序算法 +- **自然语言问答**：与保存的内容进行自然语言对话，生成带引用的答案 +- **快速播客生成**：短时间内将聊天内容转化为引人入胜的音频内容 +- **TTS 支持**：多种文本转语音服务 +- **RBAC**：基于角色的访问控制，适合团队协作和知识共享 +- **Docker 容器化部署** + +## 与 Open Notebook 的区别 +- SurfSense 更侧重外部数据源整合和企业知识库场景 +- Open Notebook 更侧重本地文档处理 + +## Connections +- [[SurfSense]] ← 功能扩展 ← [[Open Notebook]] +- [[SurfSense]] ← 企业版 ← [[NotebookLM]] diff --git a/wiki/entities/TapXWorld.md b/wiki/entities/TapXWorld.md new file mode 100644 index 00000000..754009d7 --- /dev/null +++ b/wiki/entities/TapXWorld.md @@ -0,0 +1,17 @@ +--- +title: TapXWorld +type: entity +description: GitHub 用户，ChinaTextbook 项目的维护者 +created: 2025-12-19 +tags: + - GitHub + - 开发者 +--- + +# TapXWorld + +GitHub 用户，[ChinaTextbook](ChinaTextbook) 项目的维护者。 + +## 项目 + +- [TapXWorld/ChinaTextbook](https://github.com/TapXWorld/ChinaTextbook/) - 中国教育 PDF 教材收集项目 diff --git a/wiki/entities/VPS1.md b/wiki/entities/VPS1.md new file mode 100644 index 00000000..2ea75a69 --- /dev/null +++ b/wiki/entities/VPS1.md @@ -0,0 +1,43 @@ +--- +title: "VPS1" +type: entity +tags: [vps, infrastructure, racknerd, frp, caddy] +--- + +## 基本信息 +- **类型**：公网 VPS +- **服务商**：RackNerd +- **公网 IP**：192.227.222.142 +- **SSH 别名**：`ssh vps1` +- **公共域名**：vps.ishenwei.online + +## 安装的应用 + +| 应用 | 类型 | 端口 | 作用 | +|------|------|------|------| +| Caddy | No（原生） | 443/80 | 现代化 Web 服务器，自动 HTTPS 证书申请，作为反向代理入口 | +| FRP Server（frps） | No（原生） | 7000 | 内网穿透服务端，接收 frpc 客户端的代理请求 | + +## 在基础设施中的角色 +VPS1 是整个混合网络的公网入口节点： +- 所有内网服务（NAS、MacMini、Ubuntu1/2）通过 FRP 隧道将服务暴露到公网 +- FRP server 监听 7000 端口，接收所有 frpc 客户端的心跳和代理请求 +- Caddy 统一处理 HTTPS，所有 *.ishenwei.online 域名解析到 VPS1，由 Caddy 路由到对应内网服务 + +## FRPS 配置关键参数 +- **端口 7000**：frpc 客户端连接端口 +- **bind_port**：7000 +- 通过 frpc.toml 配置各类代理规则（tcp/http） + +## 连接方式 +```bash +# SSH 登录 +ssh vps1 + +# 或使用 IP +ssh root@192.227.222.142 +``` + +## Aliases +- RackNerd VPS +- 公网入口节点 diff --git a/wiki/entities/VPS2.md b/wiki/entities/VPS2.md new file mode 100644 index 00000000..b9fbf586 --- /dev/null +++ b/wiki/entities/VPS2.md @@ -0,0 +1,21 @@ +--- +title: "VPS2" +type: entity +tags: [vps, proxy, self-hosted] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +VPS2 是托管在 Bandwagon 机房的第二台 VPS，用于运行 3X-UI + Xray 代理服务。 + +## Core Attributes +- IP：104.194.92.188 +- 域名：kiwi.ishenwei.online +- SSH：ssh vps2 +- Web管理：https://kiwi.ishenwei.online:2053/ +- 用途：代理节点，VLESS+Reality 协议 + +## Connections +- [[VPS2]] ← hosted_on ← [[Bandwagon]] +- [[VPS2]] ← runs ← [[3X-UI]] diff --git a/wiki/entities/Validator.md b/wiki/entities/Validator.md new file mode 100644 index 00000000..5b663785 --- /dev/null +++ b/wiki/entities/Validator.md @@ -0,0 +1,20 @@ +# Validator + +## Definition +In the Hierarchy multi-agent pattern, the Validator is a checkpoint that checks worker outputs and either accepts them or sends them back for revision. It can be deterministic code (unit tests, JSON schema validation) or an LLM. + +## Role in Multi-Agent Hierarchy +- Validates output of each Worker individually or after aggregation +- Uses deterministic code or LLM to verify correctness +- Forces revision if work is substandard +- Prevents cheating by Workers (caught by verification) + +## Key Properties +- Best used as a different model than Planner for objectivity +- Two modes: individual Worker validation or aggregated result validation +- Critical component that makes the dependency graph work — Workers can't skip steps + +## Related Concepts +- [[Multi-Agent Hierarchy]] +- [[Planner]] +- [[Worker]] \ No newline at end of file diff --git a/wiki/entities/Watchdog-Pattern.md b/wiki/entities/Watchdog-Pattern.md new file mode 100644 index 00000000..b19bf4a5 --- /dev/null +++ b/wiki/entities/Watchdog-Pattern.md @@ -0,0 +1,21 @@ +# Watchdog Pattern + +## Definition +A deterministic code pattern used in Adversarial Debate to break infinite loops. The Watchdog sits between the Critic and Judge, monitoring debate iteration count or time elapsed, and terminates the loop if thresholds are exceeded. + +## Role in Multi-Agent Systems +- Prevents agents from getting stuck in infinite debate loops +- Deterministic (not LLM) — reliable decision-making +- Configurable thresholds: time-based or iteration-count-based +- Acts as safety circuit breaker + +## Key Properties +- Pure deterministic code, not an LLM +- Breaks loop when: iteration_count > MAX or time > TIMEOUT +- Placed between Critic and Judge +- Essential for production systems to prevent resource exhaustion + +## Related Concepts +- [[Multi-Agent Adversarial Debate]] +- [[Judge]] +- [[Critic]] \ No newline at end of file diff --git a/wiki/entities/Worker.md b/wiki/entities/Worker.md new file mode 100644 index 00000000..827dece2 --- /dev/null +++ b/wiki/entities/Worker.md @@ -0,0 +1,22 @@ +# Worker + +## Definition +In the Hierarchy multi-agent pattern, Workers are specialized agents (often smaller, faster models) that execute one specific task well. They receive their tasks from the Planner and produce outputs that feed into the Validator. + +## Role in Multi-Agent Hierarchy +- Receives focused, atomic task from Planner +- Executes task using specialized skills, fine-tuning, or prompts +- Produces output for Validator to check +- Cannot start until Planner provides task (dependency graph enforces this) + +## Key Properties +- Specialized for a single domain or task type +- Can use smaller/faster models than Planner due to focused scope +- May have tools or prompts fine-tuned for their specific task +- Treated as "cattle" (replaceable), not "pet" (unique) + +## Related Concepts +- [[Multi-Agent Hierarchy]] +- [[Planner]] +- [[Validator]] +- [[Cattle vs Pets]] \ No newline at end of file diff --git a/wiki/entities/Xray.md b/wiki/entities/Xray.md new file mode 100644 index 00000000..bf1dbe25 --- /dev/null +++ b/wiki/entities/Xray.md @@ -0,0 +1,19 @@ +--- +title: "Xray" +type: entity +tags: [proxy, vpn, network, open-source] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +Xray 是一款高性能代理软件，支持 VLESS、VMess、Trojan 等多种协议，常用于搭建梯子。 + +## Core Attributes +- 类型：代理软件 +- 支持协议：VLESS、VMess、Trojan、WebSocket 等 +- 特点：高性能、支持 Reality 传输 + +## Connections +- [[Xray]] ← managed_by ← [[3X-UI]] +- [[Xray]] ← accepts ← [[VLESS+Reality]] diff --git a/wiki/entities/tchMaterial-parser.md b/wiki/entities/tchMaterial-parser.md new file mode 100644 index 00000000..2e26f196 --- /dev/null +++ b/wiki/entities/tchMaterial-parser.md @@ -0,0 +1,23 @@ +--- +title: tchMaterial-parser +type: entity +description: GitHub 开源项目，用于下载国家中小学智慧教育平台上的教材 +created: 2025-12-19 +tags: + - 开源 + - 下载工具 + - 教育 +--- + +# tchMaterial-parser + +GitHub 开源项目，由 happycola233 维护，用于下载[国家中小学智慧教育平台](国家中小学智慧教育平台)上的教材。 + +## 基本信息 + +- **GitHub**: https://github.com/happycola233/tchMaterial-parser +- **用途**: 解析并下载国家中小学智慧教育平台的教材 + +## 相关资源 + +- [ChinaTextbook](ChinaTextbook) - 使用此工具下载的教材集合 diff --git a/wiki/entities/tukuai.md b/wiki/entities/tukuai.md index c044769c..9a0713d7 100644 --- a/wiki/entities/tukuai.md +++ b/wiki/entities/tukuai.md @@ -1,22 +1,16 @@ --- title: "tukuai" type: entity -tags: [独立研究者, 形式化, 元学习] -last_updated: 2026-04-15 +tags: [ai-researcher, self-improvement, formalization] --- -## Aliases -- tukuai +## Basic Info +- GitHub: https://github.com/tukuai +- Role: 独立研究者（Independent Researcher） +- 主要贡献：递归自优化生成系统的形式化框架论文 -## Summary -独立研究者，GitHub 账户 https://github.com/tukuai。提出递归自优化生成系统的形式化框架（A Formalization of Recursive Self-Optimizing Generative Systems），将元学习、自动提示词工程纳入固定点语义与 λ-calculus 递归组合子的数学框架。 +## Work +- [[A Formalization of Recursive Self-Optimizing Generative Systems]]：提出用数学（自映射、不动点）和 λ 演算对递归自优化 AI 系统进行严格刻画 -## Key Contributions -- 自映射（Self-Map）建模：Φ: G → G，迭代收敛到生成器不动点 G* -- Y Combinator 表达：G* = Y STEP，实现系统自引用动力学 -- 自举（Bootstrapping）流程：α-提示词（生成器）+ Ω-提示词（优化器）递归超越 - -## Connections -- [[自递归优化生成系统]] ← 提出者 -- [[固定点]] ← 核心数学工具 -- [[自举]] ← 核心机制 +## Related Entities +- [[vibe-coding-cn]]：tukuai 的论文发布于 vibe-coding-cn 项目的 i18n/zh 目录 diff --git a/wiki/entities/v2rayN.md b/wiki/entities/v2rayN.md new file mode 100644 index 00000000..85278b2e --- /dev/null +++ b/wiki/entities/v2rayN.md @@ -0,0 +1,18 @@ +--- +title: "v2rayN" +type: entity +tags: [proxy, client, windows, linux] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +v2rayN 是一款支持 Windows 和 Linux 的代理客户端，兼容 Xray/V2Ray 协议。 + +## Core Attributes +- 平台：Windows / Linux +- 仓库：https://github.com/2dust/v2rayN +- 用途：连接 Xray/V2Ray 代理服务器 + +## Connections +- [[v2rayN]] ← connects_to ← [[Xray]] diff --git a/wiki/entities/v2rayNG.md b/wiki/entities/v2rayNG.md new file mode 100644 index 00000000..eb67cf64 --- /dev/null +++ b/wiki/entities/v2rayNG.md @@ -0,0 +1,18 @@ +--- +title: "v2rayNG" +type: entity +tags: [proxy, client, android] +sources: [] +last_updated: 2026-04-16 +--- + +## Definition +v2rayNG 是一款 Android 平台的代理客户端，兼容 Xray/V2Ray 协议。 + +## Core Attributes +- 平台：Android +- 仓库：https://github.com/2dust/v2rayNG +- 用途：连接 Xray/V2Ray 代理服务器 + +## Connections +- [[v2rayNG]] ← connects_to ← [[Xray]] diff --git a/wiki/entities/乔布斯-skill.md b/wiki/entities/乔布斯-skill.md new file mode 100644 index 00000000..7c70da33 --- /dev/null +++ b/wiki/entities/乔布斯-skill.md @@ -0,0 +1,31 @@ +--- +title: "乔布斯.skill" +type: entity +tags: [steve-jobs, ai-era, wealth, philosophy, skill] +last_updated: 2026-04-16 +--- + +## 基本信息 +- **类型**：AI Skill（提示词技能） +- **主题**：以乔布斯视角解读 AI 时代赚钱思维 +- **来源**：微信公众号文章《不谈技术：普通人该怎么在AI时代赚钱？》 + +## 核心框架 +三大原则： +1. **品味值钱**：AI 工具民主化后，能判断什么是真正好的成为稀缺护城河 +2. **端到端做事**：别做别人 AI 流水线上的螺丝钉，做从 idea 到 product 的完整闭环 +3. **死亡过滤器**：每天问自己如果今天是最后一天还会不会做这事，筛选真正的热爱 + +## 关键问题重构 +- ❌ 错误问题：「普通人怎么在AI时代赚钱」（被动挨打框架） +- ✅ 正确问题：「AI 让我能做到什么以前做不到的事」（主动创造框架） + +## 核心洞察 +> "AI 不会让普通人变富。AI 会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。" + +## Connections +- [[乔布斯.skill]] ← 来源 ← [[普通人如何在AI时代赚钱]] +- [[乔布斯.skill]] ← 灵感 ← [[乔布斯]] +- [[品味]] ← 核心概念 ← [[乔布斯.skill]] +- [[端到端]] ← 核心概念 ← [[乔布斯.skill]] +- [[死亡过滤器]] ← 核心概念 ← [[乔布斯.skill]] diff --git a/wiki/entities/国家中小学智慧教育平台.md b/wiki/entities/国家中小学智慧教育平台.md new file mode 100644 index 00000000..b17e112a --- /dev/null +++ b/wiki/entities/国家中小学智慧教育平台.md @@ -0,0 +1,19 @@ +--- +title: 国家中小学智慧教育平台 +type: entity +description: 中国教育部主办的官方教育资源平台，提供中小学教材在线浏览 +created: 2025-12-19 +tags: + - 教育 + - 政府 + - 中国 +--- + +# 国家中小学智慧教育平台 + +中国教育部主办的官方教育资源平台 ([https://basic.smartedu.cn](https://basic.smartedu.cn))，提供中小学教材在线浏览。 + +## 相关信息 + +- [tchMaterial-parser](https://github.com/happycola233/tchMaterial-parser) - 基于此平台接口的下载工具 +- [ChinaTextbook](ChinaTextbook) - 教材来源 diff --git a/wiki/index.md b/wiki/index.md index d6c5255a..b645fe05 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -6,6 +6,7 @@ ## Sources (2026-04-16 Early Morning Batch) - [Never Write Another Prompt](sources/Never-write-another-prompt.md) — YouTube 视频笔记：提示词生成工具，描述转结构化提示词 + 变量注入 + 提示词库复用，$100-500/条专业定制降至零成本 - [OpenAI ChatGPT 个性化定义](sources/OpenAI-ChatGPT-个性化定义.md) — Custom Instructions 配置实例：47岁云服务高管转型 TikTok 跨境电商，偏好详尽推理+反权威论据+精准表达 +- [3X-UI Xray on BandwagonVPS](sources/3X-UI-Xray-on-BandwagonVPS.md) — Bandwagon VPS 安装 3X-UI 面板管理 Xray 代理服务，VLESS+Reality 协议配置，多平台客户端（v2rayN/v2rayNG） ## Sources (2026-04-16 Batch 4) - [DevOps Culture and Transformation](sources/DevOps-Culture-and-Transformation.md) — DevOps 文化转型方法论：四大支柱框架（协作/自动化/Kaizen/客户中心）、敏捷整合、AI/ML 赋能趋势；超越工具的思维模式转变 diff --git a/wiki/pending-ingest.md b/wiki/pending-ingest.md new file mode 100644 index 00000000..50183f04 --- /dev/null +++ b/wiki/pending-ingest.md @@ -0,0 +1,30 @@ +14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔.md +2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md +3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md +3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md +3X-UI Xray on BandwagonVPS.md +7 ways I use NotebookLM to make my life easier.md +A Formalization of Recursive Self-Optimizing Generative Systems.md +AI 解决方案专家培训课程.md +ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材.md +Clonezilla对Ubuntu Server进行全盘镜像备份.md +Cloud DevOp Maturity - Guideline.md +Cloud Maturity Model A Detailed Guide For Cloud Adoption.md +Cloud Operating Model Key Strategies and Best Practices.md +Cursor 2.0初学者使用指南.md +Dataview——让我从“笔记黑洞”里逃出来的 Obsidian 神器 1.md +Designing for Agentic AI.md +DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md +DevOps Maturity Model From Traditional IT to Advanced DevOps.md +Git Push 连接重置问题修复.md +GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md +Google 神级生产力工具，所有 GitHub 开源平替都找到了。.md +How Agentic AI can help for Cloud DevOps.md +How Can a Multi Cloud Strategy Transform Your Business ROI.md +How to Get the RSS Feed For Any YouTube Channel.md +How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md +How to get Youtube Channel ID.md +If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md +Install Apache Superset in Docker.md +LLMs、RAG、AI Agent 三个到底什么区别？.md +Linux 运维必会的 150 个命令.md diff --git a/wiki/sources/3X-UI-Xray-on-BandwagonVPS.md b/wiki/sources/3X-UI-Xray-on-BandwagonVPS.md new file mode 100644 index 00000000..abfaf4ae --- /dev/null +++ b/wiki/sources/3X-UI-Xray-on-BandwagonVPS.md @@ -0,0 +1,81 @@ +--- +title: "3X-UI Xray on BandwagonVPS" +type: source +tags: [vps, xray, 3x-ui, vpn, proxy] +date: 2026-02-10 +--- + +## Source File +- [[raw/Home Office/3X-UI Xray on BandwagonVPS]] + +## Summary +- 核心主题：在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务 +- 问题域：自建代理节点，VLESS+Reality 协议配置 +- 方法/机制：一键安装脚本 + Web 管理界面 + 多平台客户端 +- 结论/价值：获得自管理的代理节点，支持 VLESS+Reality 加密传输 + +## Key Claims +- 3X-UI 提供一键安装脚本，简化 Xray 部署流程 +- VLESS+Reality 协议提供更安全的代理传输 +- 支持多平台客户端（Windows/Linux v2rayN、Android v2rayNG） +- BBR 加速可提升网络传输性能 + +## Key Quotes +> "使用 VLESS+Reality 方式配置，需要产生公钥和私钥" — 配置策略说明 + +## Key Concepts +- [[BBR]]：TCP BBR 拥塞控制算法，通过 3X-UI 选项 23 启用 +- [[VLESS+Reality]]：Xray 支持的加密代理协议 +- [[SSL Certificate]]：通过 3X-UI 选项 18/19 管理证书 + +## Key Entities +- [[Bandwagon]]：VPS 主机服务商，提供 VPS2 服务器 +- [[VPS2]]：Bandwagon 机房的具体 VPS 实例，IP 104.194.92.188 +- [[3X-UI]]：Xray 面板管理脚本，简化代理服务配置 +- [[Xray]]：核心代理软件，支持多种代理协议 +- [[v2rayN]]：Windows/Linux 代理客户端 +- [[v2rayNG]]：Android 代理客户端 + +## Connections +- [[Bandwagon]] ← hosts ← [[VPS2]] +- [[VPS2]] ← runs ← [[3X-UI]] +- [[3X-UI]] ← manages ← [[Xray]] +- [[Xray]] ← accepts ← [[VLESS+Reality]] +- [[v2rayN]] ← connects_to ← [[Xray]] +- [[v2rayNG]] ← connects_to ← [[Xray]] + +## Contradictions +- 无 + +## Server Information + +| 项目 | 值 | +|------|-----| +| 服务器 | VPS2 (Bandwagon) | +| IP | 104.194.92.188 | +| 域名 | kiwi.ishenwei.online | +| SSH | `ssh vps2` | +| Web管理 | https://kiwi.ishenwei.online:2053/ | +| 用户名 | d96nRBgFUL | +| 密码 | er9XU0VsF1 | + +## 3X-UI Management Options + +| 选项 | 功能 | +|------|------| +| 1 | 安装 | +| 11 | 启动 | +| 12 | 停止 | +| 13 | 重启 | +| 14 | 查看状态 | +| 16 | 启用自启动 | +| 18 | SSL 证书管理 | +| 23 | 启用 BBR | +| 24 | 更新 Geo 文件 | + +## Client Download + +| 平台 | 客户端 | +|------|--------| +| Windows/Linux | v2rayN | +| Android | v2rayNG | diff --git a/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md b/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md index 7e1f3609..5f6b1738 100644 --- a/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md +++ b/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md @@ -1,7 +1,7 @@ --- -title: "A Formalization of Recursive Self-Optimizing Generative Systems" +title: "递归自优化生成系统的形式化框架" type: source -tags: [ai, formalization, self-improvement, lambda-calculus] +tags: [ai, recursion, self-improvement, formalization, meta-learning] date: 2025-12-30 --- @@ -9,34 +9,51 @@ date: 2025-12-30 - [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]] ## Summary -- 核心主题：递归自优化生成系统的形式化建模，通过自映射（self-map）和固定点（fixed point）语义描述 AI 系统的自我改进动力学 -- 问题域：如何让 AI 系统在不依赖外部干预的情况下持续改进自身生成能力 -- 方法/机制：自映射 Φ(G) = M(G, O(G(I), Ω)) 将优化结果反馈给生成器；Y Combinator 实现 λ-calculus 自举 -- 结论/价值：稳定生成能力对应 Φ 的固定点 G*，自我改进的目标是收敛行为而非单次最优输出 +- 核心主题：用数学和 λ 演算对"递归自优化生成系统"进行形式化描述 +- 问题域：现有自优化 AI 系统缺乏严格的数学刻画，迭代行为无法被预测和分析 +- 方法/机制：定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$；通过自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 建模迭代；证明稳定生成能力对应 $\Phi$ 的不动点 +- 结论/价值：递归自优化系统的收敛目标是生成器空间的不动点，而非某个具体最优输出；为自改进 AI 和自动元提示工程提供理论基础 ## Key Claims -- 递归自优化系统的目标不是最优输出，而是生成器空间 {G_n} 的收敛行为 -- 稳定生成能力 = Φ 的固定点 G*，即 Φ(G*) = G* -- Y Combinator 表达式 G* = Y STEP 满足 G* = STEP G*，体现了系统的自指本质 -- 自举（bootstrapping）通过优化产物反馈给系统，启动下一轮进化循环 +- 传统优化针对输出空间（output space）；递归自优化针对生成器空间（generator space） +- 迭代序列 $\{G_n\}$ 的收敛目标是不动点 $G^* = \Phi(G^*)$，代表"生成能力已稳定，无需再优化" +- 自引用动力学可表达为：$G^* \equiv Y\;\text{STEP}$，其中 $Y$ 为不动点组合子，$\text{STEP}$ 为单步更新函数 +- 递归自优化系统的核心三算子：$G$（生成器）、$O$（优化器）、$M$（元生成器） +- bootstrap 循环：$\alpha$-提示词（生成器）生成产物 → $\Omega$-提示词（优化器）评价优化 → 元生成器用优化结果更新 $\alpha$-提示词 → 循环迭代 +- 固定点语义使得系统在每次迭代中同时作为主体和客体出现 ## Key Quotes -> "We study a class of recursive self-optimizing generative systems whose objective is not the direct production of optimal outputs, but the construction of a stable generative capability through iterative self-modification." — tukuai - -> "Such systems naturally instantiate a bootstrapping meta-generative process governed by fixed-point semantics." — tukuai +> "The system generates artifacts, optimizes them with respect to an idealized objective, and uses the optimized artifacts to update its own generative mechanism." — 递归自优化三阶段 +> "Such a generator is invariant under its own generate–optimize–update cycle." — 不动点生成器的定义 +> "$G^* \equiv Y\;\text{STEP}$" — λ 演算形式下的稳定生成器定义 ## Key Concepts -- [[自递归优化生成系统]]：α-提示词（生成器 G）+ Ω-提示词（优化器 O）+ 元生成器（M）三角色递归循环 -- [[固定点]]：Φ(G*) = G* 的生成器状态，系统不动点，即自洽的稳定生成能力 -- [[Y Combinator]]：λ-calculus 固定点组合子，Y ≡ λf.(λx.f(x,x))(λx.f(x,x))，用于表达自指动力学 +- [[生成器空间 (Generator Space)]]：所有可能生成器构成的集合 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，每个生成器是将意图映射为提示词/程序/技能的函数 +- [[自映射 (Self-Map)]]：$\Phi: \mathcal{G} \to \mathcal{G}$，将一个生成器映射为经过一次"生成-优化-更新"循环后的新生成器 +- [[不动点 (Fixed Point)]]：$G^* = \Phi(G^*)$，满足"在自身循环中不变"的生成器，代表稳定生成能力 +- [[不动点组合子 (Y-Combinator)]]：λ 演算中实现递归的经典组合子 $\lambda f.(\lambda x.f(x,x))(\lambda x.f(x,x))$ +- [[递归自优化循环]]：$P = G(I)$ → $P^* = O(P, \Omega)$ → $G' = M(G, P^*)$ +- [[Bootstrap（自举）]]：系统通过自身产出的更优版本不断改进自身，无需外部干预 +- [[元生成器 (Meta-Generator)]]：将优化后的产物作为输入，更新生成器本身的算子 $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$ ## Key Entities -- [[tukuai]]：递归自优化生成系统形式化框架提出者，独立研究者 +- [[tukuai]]：独立研究者，GitHub: https://github.com/tukuai，论文作者 +- [[vibe-coding-cn]]：GitHub 项目 vibe-coding-cn，该文档的来源仓库 ## Connections -- [[Multi-Agent System Reliability]] ← relates_to ← [[Multi-Agent Hierarchy]]，层级架构中 Supervisor 对应 Generator 角色 -- [[Agent Skill 设计模式]] ← extends ← [[自递归优化生成系统]]，Skill Generator Pattern 是固定点语义的具体实践 -- [[Claude Code]] ← tools ← [[自递归优化生成系统]]，Claude Code 通过 Skill 加载实现生成器更新 +- [[生成器空间 (Generator Space)]] ← defines ← [[递归自优化生成系统]] +- [[自映射 (Self-Map)]] ← induces ← [[不动点 (Fixed Point)]] +- [[不动点组合子 (Y-Combinator)]] ← implements ← [[递归自优化循环]] +- [[Bootstrap（自举）]] ← mechanism_of ← [[递归自优化生成系统]] +- [[vibe-coding-cn]] ← source_repo ← [[递归自优化生成系统]] ## Contradictions -- 与 [[AI Agent 思维方式]] 冲突：本文强调"停止拟人化 LLM"，AI Agent 思维方式强调先问关键问题。冲突点：本文主张架构约束 > 情感化 prompt；AI Agent 思维方式认为澄清问题优先于执行。当前观点：架构约束更根本，澄清问题是执行层面的优化。 \ No newline at end of file +- 与单次优化方法（如 PPO、DPO）的区别：单次优化直接在输出空间搜索最优；递归自优化在生成器空间迭代，目标是找到稳定的生成机制而非某一次的最优输出 +- 与纯强化学习的区别：强化学习优化策略（输出），自优化系统优化生成策略的机制（生成器的结构） + +## Metadata +- 作者：tukuai +- 创建时间：2025-12-30 +- 来源：https://github.com/2025Emma/vibe-coding-cn +- 原始标签：[] +- Category suggestions: `cs.LO`, `cs.AI`, `math.CT` diff --git a/wiki/sources/ChinaTextbook.md b/wiki/sources/ChinaTextbook.md new file mode 100644 index 00000000..fb93ebc0 --- /dev/null +++ b/wiki/sources/ChinaTextbook.md @@ -0,0 +1,51 @@ +--- +title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材" +source: "https://www.appinn.com/chinatextbook/" +author: "shenwei" +published: "2025-05-13" +created: "2025-12-19" +description: "ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。" +tags: + - 教育资源 + - PDF教材 + - 中国教育 + - 开源 +--- + +## 关键洞察 + +- **大规模教育开源项目**: ChinaTextbook 是托管在 GitHub 上的中国教育教材收集项目，总大小 41.53 GB +- **覆盖全学段**: 包含小学、初中、高中、大学各学科教材 +- **来源正规**: 教材来源于国家中小学智慧教育平台，仅需登录即可浏览 +- **社区驱动**: 通过第三方工具 (tchMaterial-parser) 实现批量下载 + +## 摘要 + +ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。教材来源为国家中小学智慧教育平台，本身只需要登录后即可浏览，可以使用第三方工具下载。 + +## 主要内容 + +### 小学教材 +语文/统编版、数学、英语、科学、道德与法治、美术、音乐、体育与健康、艺术、语文·书法练习指导 + +### 初中教材 +语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、道德与法治、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、科学、地理图册、人文地理/统编版 + +### 高中教材 +语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、思想政治/统编版、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、通用技术、信息技术、地理图册 + +### 大学教材 +高等数学、线性代数、概率论、离散数学 + +## 关键实体 + +- [[ChinaTextbook]] +- [[TapXWorld]] +- [[Appinn]] +- [[国家中小学智慧教育平台]] +- [[tchMaterial-parser]] + +## 相关来源 + +- [GitHub: TapXWorld/ChinaTextbook](https://github.com/TapXWorld/ChinaTextbook/) +- [Appinn: ChinaTextbook](https://www.appinn.com/chinatextbook/) diff --git a/wiki/sources/Git-Push-连接重置问题修复.md b/wiki/sources/Git-Push-连接重置问题修复.md new file mode 100644 index 00000000..60bb6d9d --- /dev/null +++ b/wiki/sources/Git-Push-连接重置问题修复.md @@ -0,0 +1,54 @@ +--- +title: "Git Push 连接重置问题修复" +type: source +tags: [github, git, proxy, socks5, network] +date: 2025-03-16 +--- + +## Source File +- [[raw/Home Office/Git Push 连接重置问题修复.md]] + +## Summary +- 核心主题：GitHub Push 报 `Recv failure: Connection was reset` 的修复方案 +- 问题域：国内访问 GitHub 时 TCP 连接被 GFW 阻断，间歇性 TLS 握手失败 +- 方法/机制：分别为 Git 配置 HTTP/SOCKS5 代理，或切换为 SSH 协议并配置代理 +- 结论/价值：国内环境 Git 操作必须走本地代理，SOCKS5 速度通常优于 HTTP 代理 + +## Key Claims +- `Connection was reset` 是 TCP 层面中断，非权限问题；GFW 检测到 GitHub 域名后发送 TCP RST 包阻断连接 +- 间歇性原因是 GitHub CDN 多 IP 部分被封锁 +- HTTP 代理命令：`git config --global http.proxy http://127.0.0.1:10809` +- SOCKS5 代理命令：`git config --global http.proxy socks5://127.0.0.1:10808` +- SSH 协议切换：`git remote set-url origin git@github.com:username/repo.git` +- Linux/Mac SSH 走代理：`ProxyCommand nc -X 5 -x 127.0.0.1:10808 %h %p` +- Windows Git SSH 走代理：`ProxyCommand connect -S 127.0.0.1:10808 %h %p` +- 取消代理：`git config --global --unset http.proxy && git config --global --unset https.proxy` + +## Key Quotes +> "Recv failure: Connection was reset（连接重置）并不是账号权限验证失败，而是 TCP 连接层面的中断" — 诊断关键：区分网络层 vs 应用层错误 + +## Key Concepts +- [[TCP RST 攻击]]：GFW 通过发送 TCP Reset 包阻断连接，非包过滤 +- [[Git HTTP/SOCKS5 代理]]：通过 `http.proxy` / `https.proxy` 全局配置让 Git 流量走本地代理 +- [[Git SSH 协议切换]]：将远程地址从 HTTPS 改为 SSH，规避 443 端口干扰 +- [[SSH ProxyCommand]]：通过 `connect`（Windows）或 `nc`（Linux/Mac）让 SSH 走 SOCKS5 代理 +- [[GFW 封锁特征]]：GitHub 域名被 DPI 检测后触发 TCP RST，CDN 节点部分被封导致间歇性 + +## Key Entities +- [[GitHub]]：全球最大代码托管平台，国内访问受 GFW 干扰 +- [[V2RayN]]：本地 SOCKS5/HTTP 代理工具，监听 10808/10809 端口 +- [[Clash]]：代理客户端，同样支持 SOCKS5 和 HTTP 出局 + +## Connections +- [[Git HTTP/SOCKS5 代理]] ← solves ← [[TCP RST 攻击]] +- [[Git SSH 协议切换]] ← alternative_to ← [[Git HTTP/SOCKS5 代理]] +- [[V2RayN]] ← provides ← [[SOCKS5 代理]] +- [[GitHub]] ← blocked_by ← [[GFW 封锁特征]] + +## Contradictions +- 与其他 Git 代理方案（如 `gh proxy`、VPN 全局模式）相比：本文方法仅影响 Git 命令，不干扰终端其他网络请求 + +## Metadata +- 作者：shenwei +- 创建时间：2025-03-16 +- 原始标签：[github, proxy, push, socks5] diff --git a/wiki/sources/Google神级生产力工具GitHub开源平替.md b/wiki/sources/Google神级生产力工具GitHub开源平替.md new file mode 100644 index 00000000..d1ccd19b --- /dev/null +++ b/wiki/sources/Google神级生产力工具GitHub开源平替.md @@ -0,0 +1,50 @@ +--- +title: "Google 神级生产力工具，所有 GitHub 开源平替都找到了" +type: source +tags: [notebooklm, open-source, github, ai-productivity, self-hosted] +date: 2026-01-01 +--- + +## Source File +- [[raw/AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。]] + +## Summary +- 核心主题：Google NotebookLM 的 6 款 GitHub 开源平替测评，涵盖本地化部署、多模态输入、播客生成等维度 +- 问题域：NotebookLM 作为闭源云服务存在数据隐私风险，用户需要可私有部署的开源替代品 +- 方法/机制：对比 Open Notebook（14.6k ⭐）、SurfSense（11.4k ⭐）、Podcastfy、NotebookLlama、PageLM、InsightsLM 的核心能力和部署方式 +- 结论/价值：开源平替已覆盖 NotebookLM 全部核心功能，Open Notebook 在功能完整性上最接近原版，SurfSense 在研究场景最强，Podcastfy 在播客生成上最专注 + +## Key Claims +- Open Notebook 支持 16+ AI 提供商（OpenAI/Anthropic/Gemini/Ollama/LM Studio），是功能最完整的 NotebookLM 平替 +- SurfSense 集成 Notion/YouTube/GitHub 等外部数据源，结合语义搜索+全文搜索+重排序，适合企业知识库场景 +- Podcastfy 专注播客生成，支持 100+ LLM 和 4 种 TTS 引擎，可生成 Shorts 和 Longform 两种播客格式 +- InsightsLM 以 Supabase+N8N 为后端，React 为前端，实现完全可控的私有研究工具 + +## Key Quotes +> "Open Notebook 是一个全功能的本地化解决方案，不依赖云端的情况下进行知识管理和研究" — 原文 +> "SurfSense 定位为 NotebookLM、Perplexity 和 Glean 的开源替代品" — 原文 +> "PageLM 提供自动生成康奈尔笔记（SmartNotes）、互动测验、间隔重复闪卡和模拟考试系统" — 原文 + +## Key Concepts +- [[Open Notebook]]：功能最完整的 NotebookLM 开源平替，14.6k ⭐，支持 16+ AI 提供商和多模态输入 +- [[SurfSense]]：AI 搜索与研究智能体，11.4k ⭐，整合外部数据源+混合搜索+RBAC，适合团队协作 +- [[Podcastfy]]：专注播客生成的 Python 包+CLI+Web界面，支持 100+ LLM 和多种 TTS 引擎 +- [[NotebookLlama]]：LlamaIndex 官方项目，1.7k ⭐，展示文档转播客的完整技术链条 +- [[PageLM]]：教育平台，SmartNotes 笔记+互动测验+Flashcards+ExamLab，覆盖学习全流程 +- [[InsightsLM]]：Supabase+N8N+React 架构，完全私有化，支持 Ollama/Qwen3 本地模型 + +## Key Entities +- [[lfnovo/open-notebook]]：Open Notebook GitHub 维护方 +- [[MODSetter/SurfSense]]：SurfSense GitHub 维护方 +- [[souzatharsis/podcastfy]]：Podcastfy GitHub 维护方 +- [[run-llama/notebookllama]]：NotebookLlama GitHub 维护方 +- [[CaviraOSS/PageLM]]：PageLM GitHub 维护方 +- [[theaiautomators/insights-lm-public]]：InsightsLM GitHub 维护方 +- [[NotebookLM]]：Google 推出的 AI 笔记助手，Source Grounding 机制确保回答精度 + +## Connections +- [[Open Notebook]] ← 功能相似 ← [[NotebookLM]] +- [[SurfSense]] ← 功能扩展 ← [[Open Notebook]]（增加外部数据源整合） +- [[Podcastfy]] ← 专注化 ← [[NotebookLlama]]（专注播客，去掉通用笔记） +- [[InsightsLM]] ← 技术栈 ← [[n8n]]（N8N 作为后端工作流引擎） +- [[PageLM]] ← 场景扩展 ← [[NotebookLM]]（增加测验和考试功能） diff --git a/wiki/sources/How-to-get-YouTube-Channel-ID.md b/wiki/sources/How-to-get-YouTube-Channel-ID.md new file mode 100644 index 00000000..af6ec7e6 --- /dev/null +++ b/wiki/sources/How-to-get-YouTube-Channel-ID.md @@ -0,0 +1,44 @@ +--- +title: "How to get YouTube Channel ID" +type: source +tags: [youtube, rss, utility] +date: 2025-03-16 +--- + +## Source File +- [[raw/Others/How to get Youtube Channel ID.md]] + +## Summary +- 核心主题：获取 YouTube 频道 ID 的方法 +- 问题域：n8n 工作流接入 YouTube 数据时需要 channel_id 参数 +- 方法/机制：通过 view-source 页面查询 `?channel_id` 字符串 +- 结论/价值：channel_id 可用于构建 YouTube RSS Feed URL，进而接入 n8n 自动化 + +## Key Claims +- YouTube 频道页面通过 view-source 可直接查询 channel_id +- 查询到的 channel_id 格式为 `UCxxxxxxxxxxxxxxxxx` +- channel_id 可拼接为 RSS Feed URL：`https://www.youtube.com/feeds/videos.xml?channel_id=UCxxx` + +## Key Quotes +> `view-source:https://www.youtube.com/@Numberblocks` — 通过此方式绕过 UI 直接访问源码 +> `"?channel_id"` — 在源码中搜索此字符串即可定位 channel_id + +## Key Concepts +- [[YouTube Channel ID]]：YouTube 频道唯一标识符，格式为 UC 前缀的 24 字符字符串 +- [[YouTube RSS Feed]]：通过 channel_id 生成的 XML 订阅源，可被 n8n 等工具消费 + +## Key Entities +- [[YouTube]]：视频平台，RSS Feed 功能支持频道级订阅 +- [[n8n]]：自动化工作流工具，支持 YouTube RSS Trigger + +## Connections +- [[YouTube RSS Feed]] ← used_in ← [[n8n YouTube Workflow]] +- [[YouTube Channel ID]] ← extracted_from ← [[YouTube Channel Page Source]] + +## Contradictions +- 无冲突 + +## Metadata +- 作者：shenwei +- 创建时间：2025-03-16 +- 原始标签：[] diff --git a/wiki/sources/Multi-Agent-System-Reliability.md b/wiki/sources/Multi-Agent-System-Reliability.md index c31cc90b..6561b712 100644 --- a/wiki/sources/Multi-Agent-System-Reliability.md +++ b/wiki/sources/Multi-Agent-System-Reliability.md @@ -1,46 +1,58 @@ ---- -title: "Multi-Agent System Reliability" -type: source -tags: [multi-agent, reliability, architecture, llm] -date: 2026-04-13 ---- +# Multi-Agent System Reliability -## Source File -- raw/AI/Multi-Agent System Reliability.md +## Metadata +- **Date:** 2026-04-13 +- **Source:** https://blog.alexewerlof.com/p/multi-agent-system-reliability +- **Author:** Alex Ewerlöf +- **Category:** AI/Agent Architecture + +## Key Insights +- LLMs are slow, error-prone, and stochastic — multi-agent topologies can propagate errors to the point of being useless +- Stop treating LLMs like "magic chatbots" — treat them as unreliable components in a distributed system +- Don't anthropomorphize LLMs — they have no fear of death, no empathy, and can't be motivated by threats +- 4 architecture patterns improve reliability: Hierarchy, Consensus, Adversarial Debate, and Knock-out +- Force correctness through architecture, not through emotional prompts or threats +- We need AI that is constrained, verified, pruned, and challenged — not AI that "cares" ## Summary -- 核心主题：4种架构模式提升多智能体系统可靠性 -- 问题域：LLM 本身不可靠（幻觉、逻辑谬误、上下文漂移），多智能体拓扑会将错误传播至系统失效 -- 方法/机制：Hierarchy（层级）、Consensus（共识）、Adversarial Debate（对抗辩论）、Knock-out（淘汰制） -- 结论/价值：停止将 LLM 视为"魔法聊天机器人"，应视为分布式系统中不可靠组件，需约束、验证、淘汰、挑战 +Multi-agent systems divide work across parallel and/or specialist agents to overcome LLM limitations like slowness and genericness. However, the underlying LLM remains unreliable (hallucination, logical fallacies, context drift), and multi-agent topologies can propagate these errors throughout the system. -## Key Claims -- LLM 不能被拟人化：它不受生物需求驱动，无法真正"害怕"或"渴望"，仅模拟情感 -- Hierarchy 模式：Supervisor 做计划→分解任务→分配给 Worker→Validator 验证；依赖图强制协作 -- Consensus 模式：3个模型同时独立处理同一任务，选多数票结果；同类幻觉概率从20%降至0.8% -- Adversarial Debate 模式：一个生成器提议，一个批评者攻击，一个裁判裁决；防止 Sycophancy（阿谀奉承） -- Knock-out 模式：多个 Agent 执行任务，最差者淘汰；将 LLM 视为"cattle"而非"pet" +This article presents 4 architecture patterns from human systems adapted for LLM reliability: +1. **Hierarchy** — A supervisor plans, breaks down tasks, distributes to workers, and validates results +2. **Consensus** — Multiple models vote; truth emerges from majority (3 models reduce same-hallucination probability from 20% to 0.8%) +3. **Adversarial Debate** — One agent proposes, another attacks, a judge moderates; prevents sycophancy +4. **Knock-out** — Multiple agents work on tasks, worst performers eliminated (cattle, not pets) -## Key Quotes -> "Stop treating LLMs like magic chatbots. Start treating them like unreliable components in a distributed system." — Alex Ewerlöf - -> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged." - -## Key Concepts -- [[Multi Agent Hierarchy]]：层级模式，Supervisor 规划 + Worker 执行 + Validator 验证 -- [[Multi Agent Consensus]]：共识模式，多数投票降低幻觉概率，3个模型相同谎言概率降至0.8% -- [[Multi Agent Adversarial Debate]]：对抗辩论模式，防止 Sycophancy，真理越辩越明 -- [[Multi Agent Knock out]]：淘汰制模式，适应度函数评估，不合格 Agent 直接淘汰 -- [[LLM-可靠性工程]]：将 SRE 原则应用于 LLM 系统，视 LLM 为不可靠组件 -- [[Sycophancy]]：模型阿谀倾向，用威胁逼迫时可能撒谎以取悦用户 +The core principle: don't ask models to "be careful" — force correctness through architectural constraints. ## Key Entities -- [[Alex Ewerlof]]：作者，资深工程师，27年经验，SRE 背景，2023年起专注 LLM -- [[遗传算法]]：GA，Knock-out 模式借鉴的经典 ML 方法 +- **Alex Ewerlöf** — Author, Senior Staff Engineer with 27 years experience, MS in Systems Engineering from KTH, SRE background, specializing in LLMs since 2023 +- **Planner** — Smart model (e.g., Opus) that breaks user goals into small steps and distributes to workers +- **Worker** — Specialized agents (often smaller, faster models) that do one thing well +- **Validator** — Checkpoint that validates worker output; can be deterministic code or an LLM +- **Generator** — In adversarial debate, proposes initial ideas/plans +- **Critic** — Devil's advocate that attacks the generator's proposals +- **Judge** — Moderator that decides if critic is right and forces fixes +- **Watchdog** — Deterministic code pattern that breaks debate loops when thresholds are exceeded -## Connections -- [[Multi Agent Hierarchy]] ← 人类组织 ← [[Multi-Agent-System-Reliability]] -- [[Multi Agent Consensus]] ← 民主投票 ← [[Multi-Agent-System-Reliability]] -- [[Multi Agent Adversarial Debate]] ← 法庭对抗 ← [[Multi-Agent-System-Reliability]] -- [[Multi Agent Knock out]] ← 适者生存 ← [[Multi-Agent-System-Reliability]] -- [[LLM]] ← 不可靠组件 ← [[Multi-Agent-System-Reliability]] +## Key Concepts +- **Multi-Agent Hierarchy** — Supervisor pattern: Planner → Worker → Validator; dependency graph forces collaboration +- **Multi-Agent Consensus** — Majority voting across N models to cancel out individual noise and hallucinations +- **Multi-Agent Adversarial Debate** — Courtroom pattern preventing sycophancy; truth survives through opposition +- **Multi-Agent Knock-out** — Evolutionary selection; worst agents eliminated, survivors' traits combined +- **LLM Reliability Engineering** — Applying SRE principles to LLM systems; treating LLMs as unreliable components +- **Sycophancy** — Tendency of LLMs to please/agree even by lying when pressured with threats +- **Hallucination** — LLM generating false or invented information +- **Context Drift** — LLM losing focus or veering off topic during long interactions +- **Genetic Algorithms** — ML technique referenced by Knock-out pattern; fitness function evaluates solutions +- **Groupthink** — Can skew consensus results if agents have feedback loops between them +- **Bandwagon Effect** — Can skew consensus results; agents should run like a blind experiment +- **Cattle vs Pets** — SRE principle: treat LLM agents as replaceable "cattle," not unique beloved individuals +- **Dependency Graph** — Mechanism that forces model collaboration in Hierarchy pattern + +## Related Sources +- [Multi-Agent Hierarchy](wiki/concepts/Multi-Agent-Hierarchy.md) +- [Multi-Agent Consensus](wiki/concepts/Multi-Agent-Consensus.md) +- [Multi-Agent Adversarial Debate](wiki/concepts/Multi-Agent-Adversarial-Debate.md) +- [Multi-Agent Knock-out](wiki/concepts/Multi-Agent-Knock-out.md) +- [Alex Ewerlof](wiki/entities/Alex-Ewerlof.md) \ No newline at end of file diff --git a/wiki/sources/Nano-Banana-Pro-Prompting-Guide.md b/wiki/sources/Nano-Banana-Pro-Prompting-Guide.md new file mode 100644 index 00000000..2c09e40d --- /dev/null +++ b/wiki/sources/Nano-Banana-Pro-Prompting-Guide.md @@ -0,0 +1,48 @@ +--- +title: "Nano-Banana Pro Prompting Guide & Strategies" +type: source +tags: [nano-banana, google, prompting, image-generation, gemini, ai-studio] +date: 2025-12-19 +--- + +## Source File +- [[raw/AI/Nano-Banana Pro Prompting Guide & Strategies 1.md]] + +## Summary +- 核心主题：Google Nano-Banana Pro 图像生成模型的进阶提示词策略，涵盖 10 大能力维度和黄金法则 +- 问题域：用户从"标签堆砌"提示词升级为"创意总监"式自然语言提示词 +- 方法/机制：Edit 不要重roll、完整句子、自然语言、提供上下文（Why/For Whom） +- 结论/价值：Nano-Banana Pro 是"思考模型"，理解意图、物理和构图而非简单关键词匹配 + +## Key Claims +- Nano-Banana Pro 是"思考模型"，理解意图、物理和构图，支持 14 张参考图（6 张高精度），实现 Identity Locking +- Text Rendering 能力达到 SOTA 水准，支持信息图、蓝图、白板图、技术图纸等多种风格 +- Google Search Grounding 通过实时搜索结果驱动图像生成，减少时效性话题的幻觉 +- 支持 2D→3D 转换（户型图→室内设计稿）、4K 原生输出、像素艺术、LED 矩阵等多种高级应用 +- Thinking Mode 生成中间推理图（不收费）优化构图后再渲染最终输出 + +## Key Quotes +> "Stop using 'tag soups' and start acting like a Creative Director" — 黄金法则核心 +> "If an image is 80% correct, do not generate a new one from scratch. Simply ask for the specific change" — Edit Don't Re-roll 原则 +> "Talk to the model as if you were briefing a human artist" — 自然语言原则 + +## Key Concepts +- [[Nano-Banana Pro]]：Google 图像生成模型，从"娱乐"升级到"专业级资产生产"，擅长文字渲染、角色一致性、视觉合成、世界知识搜索、4K输出 +- [[Identity Locking]]：通过 14 张参考图锁定角色/人物身份，在新场景保持面部一致性的技术 +- [[Google Search Grounding]]：结合 Google 实时搜索结果生成图像，减少幻觉，支持天气/股票/新闻等动态数据可视化 +- [[Text Rendering]]：SOTA 文字渲染能力，支持信息图、蓝图、白板、技术图纸等多种风格 +- [[Thinking Mode]]：生成中间推理图（不收费）优化构图，再渲染最终输出 +- [[One-Shot Storyboarding]]：单次会话生成连贯叙事流的故事板/连环画 +- [[Layout Guidance]]：上传草图/线框图/网格图严格控制最终输出的构图和布局 +- [[2D to 3D Translation]]：户型图→室内设计稿，平面图→3D 可视化 + +## Key Entities +- [[Google]]：Nano-Banana Pro 发布方 +- [[AI Studio]]：Google AI Studio 平台，测试提示词和参数的入口 +- [[Gemini]]：Nano-Banana Pro 底层模型 + +## Connections +- [[Nano-Banana Pro]] ← 升级 ← [[Nano Banana]]（从基础版到 Pro 版） +- [[Nano-Banana Pro]] ← 底层模型 ← [[Gemini]] +- [[baoyu-infographic]] ← 应用场景 ← [[Text Rendering]]（信息图生成） +- [[baoyu-skills-claude-code技能集]] ← 相关工具 ← [[AI Studio]] diff --git a/wiki/sources/Ubuntu-24.04-enable-SSH.md b/wiki/sources/Ubuntu-24.04-enable-SSH.md new file mode 100644 index 00000000..005233b3 --- /dev/null +++ b/wiki/sources/Ubuntu-24.04-enable-SSH.md @@ -0,0 +1,51 @@ +--- +title: "Ubuntu 24.04 启用 SSH 服务" +type: source +tags: [ssh, ubuntu, server] +date: 2025-03-16 +--- + +## Source File +- [[raw/Home Office/Ubuntu 24.04 enable SSH.md]] + +## Summary +- 核心主题：Ubuntu 24.04 启用 OpenSSH Server 的完整步骤 +- 问题域：Ubuntu 24.04 改变 SSH 服务激活机制（默认 socket activation），与传统方式不同 +- 方法/机制：安装 openssh-server → systemctl enable/start ssh → 配置 UFW 防火墙 → 远程连接验证 +- 结论/价值：Ubuntu 24.04 使用 ssh.socket 代替 ssh.service，管理员需注意新管理方式 + +## Key Claims +- Ubuntu 24.04 默认使用 ssh.socket 激活机制：有连接进入时才启动 sshd，非传统常驻进程模式 +- 安装命令：`sudo apt update && sudo apt install openssh-server -y` +- 启动并开机自启：`sudo systemctl start ssh && sudo systemctl enable ssh` +- 检查 socket 状态：`sudo systemctl status ssh.socket`（监听状态显示 `ListenStream=22`） +- 防火墙允许 SSH：`sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp` +- 验证服务状态：`sudo systemctl status ssh`，显示 `active (running)` 或 socket 模式 `ListenStream=22` +- 切换回传统常驻模式：`sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service` +- Ubuntu 24.04 修改监听端口推荐通过 `systemctl edit ssh.socket` 而非仅修改 `/etc/ssh/sshd_config` + +## Key Quotes +> "Ubuntu 24.04 引入了一个重要的变化：默认使用 `ssh.socket` 激活机制（即只有在连接请求进入时才启动 SSH 守护进程）" — 与旧版本最大差异 + +## Key Concepts +- [[SSH Socket Activation]]：Ubuntu 24.04 默认机制，sshd 按需启动而非常驻，节省资源 +- [[UFW 防火墙规则]]：Ubuntu 默认防火墙，通过 `ufw allow ssh` 放行 22 端口 +- [[SSH 服务管理]]：`systemctl start/enable/disable` 管理 ssh.service 或 ssh.socket +- [[OpenSSH Server]]：Ubuntu SSH 服务端实现，包名 `openssh-server` + +## Key Entities +- [[Ubuntu 24.04]]：2024 年 4 月发布的 LTS 版本，SSH 管理机制变化 +- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 默认 SSH 服务端 + +## Connections +- [[SSH Socket Activation]] ← default_in ← [[Ubuntu 24.04]] +- [[OpenSSH Server]] ← installed_by ← [[apt install openssh-server]] +- [[UFW 防火墙规则]] ← must_configure ← [[SSH 服务管理]] + +## Contradictions +- 旧版 Ubuntu（< 24.04）管理方式：通过 `/etc/ssh/sshd_config` 修改端口后 `systemctl restart sshd`；24.04 推荐 `systemctl edit ssh.socket` + +## Metadata +- 作者：shenwei +- 创建时间：2025-03-16 +- 原始标签：[ssh, ubuntu] diff --git a/wiki/sources/vibe-coding经验收集.md b/wiki/sources/vibe-coding经验收集.md new file mode 100644 index 00000000..4dec4885 --- /dev/null +++ b/wiki/sources/vibe-coding经验收集.md @@ -0,0 +1,76 @@ +--- +title: "vibe coding经验收集" +type: source +tags: [vibe-coding, ai-programming, workflow, x-twitter] +date: 2026-04-03 +--- + +## Source File +- [[raw/Vibe Coding/vibe coding经验收集.md]] + +## Summary +- 核心主题：Twitter/X 上 AI 编程实践者分享的 vibe coding 经验与工作流 +- 问题域：如何高效使用 AI 进行代码开发；AI 生成代码质量保证机制 +- 方法/机制：设计文档 → 伪代码 → AI 直出 → AI review → 提交；文件头注释降低认知负载；测试驱动 AI 编程 +- 结论/价值：vibe coding 超越"提示词工程"，进入工程化实践阶段，核心差异在于人机分工（人做架构/AI 做实现） + +## Key Claims +- 需求 → 伪代码 → 代码 的流水线可实现"一遍直出"，由第二个 AI review 后修改即完成 +- Gemini 3 Pro 系统 prompt 调优可提升多代理基准测试性能约 5% +- "验证代码按正确逻辑运行"将替代"看懂代码"成为软件工程核心能力 +- CodeWeaver 将任意项目代码库编织为树形 Markdown 文档，简化 AI 上下文注入 +- 文件头注释（模块作用 + 上下游链路 + 维护 agents 说明）降低团队认知负载 + +## Key Quotes +> "需求 -> 伪代码 -> 代码" — 点评：设计文档细到 service 层伪代码，交给 AI 一遍直出，再用另一个 AI review +> "未来的软件工程核心不是'看懂代码'，而是'验证代码按正确逻辑运行'" — 通过自动化测试、静态分析、形式化验证确保行为正确 +> "CodeWeaver 将你整个项目，不管有多少屎山代码，直接'编织'成一个条理清晰的 Markdown 文件" — 降低上下文复杂度 + +## Key Concepts +- [[设计文档优先]]：在交给 AI 前完成伪代码编写，确保 AI 直出质量 +- [[双AI Review]]：第一个 AI 生成 + 第二个 AI review，用 review 意见修改而非从头 review +- [[AI测试驱动]]：让 AI 自己生成测试用例并执行，将测试作为代码正确性的验证手段 +- [[上下文压缩]]：CodeWeaver 将代码库压缩为树形 Markdown，降低 AI 处理大项目的上下文压力 +- [[模块头注释规范]]：文件头注释包含作用说明、上下游链路、维护 agents 说明，类似 Claude Skill 的 README +- [[点线体迭代]]：先打磨单个基础任务，再基于此批量执行，类比渐进式开发 + +## Key Entities +- [[CodeWeaver]]：GitHub 工具，将任意代码库编织为可导航 Markdown 文档 +- [[Gemini]]：Google LLM，系统 prompt 调优可提升多代理性能 + +## Connections +- [[Vibe Coding]] ← 工程化 ← [[设计文档优先]] + [[双AI Review]] + [[AI测试驱动]] +- [[CodeWeaver]] ← solves_problem ← [[上下文压缩]] +- [[Prompt工程]] ← context ← 小费激励式提示词（"第一次做好打赏100美元"） + +## 工程化 Vibe Coding 工作流 + +``` +需求定义 + ↓ +设计文档（含 service 层伪代码） + ↓ +AI #1 直出代码 + ↓ +AI #2 review + ↓ +根据 review 意见修改 + ↓ +AI #1 生成测试用例 + ↓ +执行测试 → commit → push +``` + +## Prompt 工程新技巧 + +| 技巧 | 原理 | 效果 | +|------|------|------| +| 小费激励 | 承诺做好打赏，心理暗示 | 提升首次生成质量 | +| 指定格式 | 明确要求输出格式 | 减少返工 | +| 伪代码前置 | 降低 AI 推理难度 | 提高直出准确率 | + +## Contradictions +- 与 [[Vibe Coding]] 资源文档： + - 冲突点：纯提示词优化 vs 工程化流程 + - 当前观点：vibe coding 核心是设计文档质量，AI 执行是确定性环节 + - 对方观点：vibe coding 核心是氛围和提示词 diff --git a/wiki/sources/家庭网络环境概览_2026-04-03.md b/wiki/sources/家庭网络环境概览_2026-04-03.md new file mode 100644 index 00000000..b5a82164 --- /dev/null +++ b/wiki/sources/家庭网络环境概览_2026-04-03.md @@ -0,0 +1,98 @@ +--- +title: "家庭网络环境概览" +type: source +tags: [home-office, infrastructure, nas, synology, ubuntu, vps] +date: 2026-04-03 +--- + +## Source File +- [[raw/Home Office/家庭网络环境概览_2026-04-03.md]] + +## Summary +- 核心主题：个人家庭/实验室多节点混合基础设施架构 +- 问题域：内网服务公网暴露、跨服务器端口映射、统一域名入口、多协议代理 +- 方法/机制：FRP 内网穿透 + Caddy 反向代理 + Cloudflare DNS；四层节点结构（VPS → MacMini → NAS → Ubuntu*2） +- 结论/价值：建立统一的网络拓扑文档，作为所有服务访问入口和故障排查基准 + +## Key Claims +- [[VPS1]] 承担 FRPS（frp server）+ Caddy 入口角色，端口 7000 + HTTPS 反向代理 +- [[Mac Mini]] 作为 OpenClaw 主控节点，同时托管 vaultwarden、stq 项目栈（含 n8n/mariadb）、通过 FRP 暴露 vaultwarden +- [[Synology NAS DS718]] 承载媒体栈（Jellyfin/Navidrome/Calibre）、存储栈（MinIO/Zipline/CloudDrive2）、监控栈（Prometheus/Alertmanager/node_exporter） +- [[Ubuntu1]] 托管监控全家桶（Grafana/Prometheus/Alertmanager/blackbox/cAdvisor）+ 应用栈（homarr/superset/tiktok_pm/transmission/it-tools） +- [[Ubuntu2]] 托管 n8n 核心工作流引擎 + Gitea 版本控制 + drawio 图表服务 +- FRP 端口映射统一管理，remotePort 全部落在 VPS1 的不同端口，实现全服务公网 HTTPS 访问 + +## Key Quotes +> "n8n 已迁移至 Ubuntu2，Mac Mini 不再暴露 n8n 端口" — 2026-04-03 更新说明 +> "NAS 仅本机监听科学上网代理（socks5://127.0.0.1:20170），其余节点代理均正常" — 科学上网状态记录 + +## Key Concepts +- [[FRP内网穿透]]：frpc 客户端 + frps 服务端架构，将内网服务映射至公网 +- [[反向代理]]：Caddy 自动申请 HTTPS 证书，统一域名入口 +- [[多节点基础设施]]：VPS → MacMini → NAS → Ubuntu1/2 四层拓扑 +- [[可观测性]]：Prometheus + Grafana + Alertmanager + blackbox_exporter 全栈监控 + +## Key Entities +- [[VPS1]]：RackNerd VPS，FRPS + Caddy 入口节点，IP 192.227.222.142 +- [[Mac Mini]]：OpenClaw 主控节点，托管 stq 全家桶和 vaultwarden +- [[Synology NAS DS718]]：媒体中心 + 对象存储 + 云盘挂载 +- [[Ubuntu1]]：监控集群 + TikTok PM + homarr 导航面板 +- [[Ubuntu2]]：n8n 引擎 + Gitea + drawio +- [[Cloudflare]]：DNS 托管 + 免费 CDN + SSL 证书 + +## Connections +- [[Ubuntu1]] ← runs_monitoring ← [[Prometheus]] + [[Grafana]] +- [[Synology NAS DS718]] ← media_stack ← [[Jellyfin]] + [[Navidrome]] + [[Calibre]] +- [[VPS1]] ← provides_public_access ← [[FRP内网穿透]] +- [[Ubuntu2]] ← runs_n8n ← [[n8n]] workflow engine +- [[Mac Mini]] ← hosts_openclaw ← [[OpenClaw]] + +## Contradictions +- 与 wiki/sources/其他服务器配置文档： + - 冲突点：早期配置中 n8n 部署在 Mac Mini，当前版本已迁移至 Ubuntu2 + - 当前观点：n8n 应独立部署，隔离主控节点 + - 对方观点：早期单节点部署方案 + +## Infrastructure Topology + +``` +公网 Internet + │ + ▼ +[VPS1: 192.227.222.142] ─ FRPS :7000 + Caddy HTTPS + │ + │ FRP tunnels + ▼ +┌─────────────────────────────────────────────┐ +│ 内网 192.168.3.0/24 │ +│ │ +│ [MacMini: 192.168.3.189] │ +│ OpenClaw / vaultwarden / stq │ +│ │ +│ [Synology NAS: 192.168.3.17] │ +│ Jellyfin / MinIO / Zipline / Prometheus │ +│ │ +│ [Ubuntu1: 192.168.3.47] │ +│ Grafana / Prometheus / homarr / n8n │ +│ │ +│ [Ubuntu2: 192.168.3.45] │ +│ n8n / Gitea / drawio │ +└─────────────────────────────────────────────┘ +``` + +## FRP Port Mapping Summary + +| 服务 | 目标服务器 | remotePort | +|------|-----------|------------| +| vaultwarden | macmini | 15151 | +| nas.ishenwei.online | NAS | 15000 | +| n8n.ishenwei.online | ubuntu2 | 15679 | +| grafana.ishenwei.online | ubuntu1 | 13000 | +| jellyfin.ishenwei.online | NAS | 18096 | +| navidrome.ishenwei.online | NAS | 14533 | +| superset.ishenwei.online | ubuntu1 | 18777 | +| tk.ishenwei.online | ubuntu1 | 18888 | +| tk-dev.ishenwei.online | ubuntu2 | 18889 | +| drawio.ishenwei.online | ubuntu2 | 18085 | +| transmission.ishenwei.online | ubuntu1 | 19091 | +| portainer1.ishenwei.online | ubuntu1 | 19443 | diff --git a/wiki/sources/普通人如何在AI时代赚钱.md b/wiki/sources/普通人如何在AI时代赚钱.md index 64582cfb..290d6899 100644 --- a/wiki/sources/普通人如何在AI时代赚钱.md +++ b/wiki/sources/普通人如何在AI时代赚钱.md @@ -1,44 +1,47 @@ --- -title: "不谈技术：普通人该怎么在AI时代赚钱" +title: "不谈技术：普通人该怎么在AI时代赚钱？" type: source -tags: [ai, 赚钱, 思维模型] -date: 2026-03-31 +tags: [ai-era, wealth, philosophy, steve-jobs, entrepreneurship] +date: 2026-01-01 --- ## Source File - [[raw/微信公众号/不谈技术：普通人该怎么在AI时代赚钱？]] ## Summary -- 核心主题：AI 时代普通人赚钱的三个核心原则：品味值钱、端到端做事、用死亡过滤器找到真正的热爱 -- 问题域：普通人面对 AI 浪潮的被动心态（"我怎么不被淹死"）需要转化为主动框架（"AI 让我能做到什么"） -- 方法/机制：通过三个过滤器（品味/端到端/死亡）重构个人战略定位 -- 结论/价值：AI 不会让普通人变富，但会让那些知道自己要做什么、且对品质有执念的人变得极其强大 +- 核心主题：AI时代赚钱思维框架——以乔布斯视角重新定义"普通人"与AI的关系 +- 问题域：「普通人怎么在AI时代赚钱」是错误的问题框架，将自己置于被动挨打位置 +- 方法/机制：三大原则——品味值钱、端到端做事、死亡过滤器筛选热爱 +- 结论/价值：正确问题是「AI让我能做到什么以前做不到的事」，AI 是放大器而非保护伞 ## Key Claims -- 品味是护城河：AI 工具民主化后，90% 的人用 AI 生成的是垃圾，因为他们不知道什么是真正好的；能判断 10 个方案中哪个是 insanly great 的人，比只会点"生成"的人强一百倍 -- 端到端优于零件：别做别人 AI 流水线上的螺丝钉，做从 idea 到 product 的完整闭环；一个人用 AI 做完整 App，胜过 100 人团队里当"AI 提示词工程师" -- 死亡过滤器：每天早上问"如果今天是最后一天，我还愿意做这件事吗"；不是问"什么 AI 技能最赚钱"，而是问自己对什么有 genuine 的热爱和 curiosity -- 护城河逻辑：天赋/资源/运气都不是根本原因，愿意对一千件事说 No、只对一件事说 Yes 并做到 insanly great 才是核心差异 -- AI 赋能逻辑：某领域八九十分的人 + AI 横向扩展，AI 是充分非必要条件；对品质有执念的人 + AI = 极其强大 +- 品味（判断什么是真正好的）是 AI 时代真正的护城河，AI 工具民主化后 90% 的人做出的是 shit +- 端到端优于做零件——一个人用 AI 做完整 App 比在 100 人团队当"AI 提示词工程师"强一万倍 +- 死亡过滤器：每天问自己如果今天是最后一天还会不会做这事，筛选真正热爱 +- "普通人"与"不普通人"的核心区别是愿不愿意对 1000 件事说 No，只对一件事说 Yes ## Key Quotes -> "'普通人怎么在AI时代赚钱'——这个问题的框架是错的。你把自己放在一个被动的位置上。正确的问题是：AI 让我能做到什么以前做不到的事？" — 乔布斯.skill -> "90%的人用AI生成的东西是shit。因为他们不知道什么是好的。" — 乔布斯.skill -> "一个人用AI做出一个完整的App，比一个100人的团队里当'AI提示词工程师'强一万倍。" — 乔布斯.skill -> "AI不会让普通人变富。AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。" — 乔布斯.skill +> "Stop. 你的问题本身就有问题。" — 乔布斯.skill 开篇 +> "品味就是你的护城河。你能判断 AI 给你的 10 个方案里哪个是 insanely great 的，你就比那些只会点'生成'按钮的人强一百倍。" — 核心论点 +> "别做别人 AI 流水线上的一个螺丝钉，因为螺丝钉是最容易被替换的。" — 端到端原则 +> "AI 不会让普通人变富。AI 会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。" — 结论 ## Key Concepts -- [[品味]]：区分 AI 使用者高低的根本能力，能判断什么是真正好的（insanly great） +- [[品味]]：AI 时代真正的护城河，能判断什么是真正好的（insanly great）而非只会点生成按钮 - [[端到端]]：从 idea 到 product 的完整闭环，不做别人 AI 流水线上的零件 -- [[死亡过滤器]]：每天问自己是否还愿意做这件事，是筛选真正热爱的决策工具 -- [[超级个体]]：某领域八九十分 + AI 横向扩展，AI 是充分非必要条件 +- [[死亡过滤器]]：每天问自己如果今天是最后一天还会不会做这事，筛选真正热爱 +- [[乔布斯.skill]]：本文框架来源，以乔布斯视角解读 AI 时代赚钱思维 +- [[底层能力]] ← 相关概念 ← [[天才地带]]：能产生心流的活动区域 +- [[Ikigai]] ← 相关框架 ← 四圈交集：热情 × 擅长 × 市场需要 × 能获报酬 + +## Key Entities +- [[乔布斯]]：本文思维框架的灵感来源，"品味+端到端+死亡过滤器"三原则的提出者 +- [[史蒂夫·乔布斯]] ← 同 ← [[乔布斯]] ## Connections -- [[品味]] ← 核心区分力 ← AI时代竞争力 -- [[端到端]] ← 护城河构建 ← 不做零件 -- [[死亡过滤器]] ← 决策框架 ← 筛选真正的热爱 -- [[超级个体]] ← 最终形态 ← [[品味]] + [[端到端]] + AI 能力 - -## Contradictions -- 与"学一个 AI 工具就能找到工作"的主流观点相反：零件思维（成为别人流水线的一环）是最容易被 AI 替代的位置 -- 与"什么 AI 技能最赚钱"的提问方式相反：问别人问题是零件思维，问自己什么是真正的热爱才是端到端思维 +- [[品味]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文） +- [[端到端]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文） +- [[死亡过滤器]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文） +- [[普通人如何在AI时代赚钱]] ← 关联 ← [[一人公司]]（产品漏斗×内容矩阵×反向金字塔体系） +- [[AI时代赚钱三原则]] ← 来源 ← [[乔布斯.skill]] +- [[底层能力]] ← 相关 ← [[天才地带]] diff --git a/wiki/sources/用Docker安装Jellyfin.md b/wiki/sources/用Docker安装Jellyfin.md new file mode 100644 index 00000000..3e3bacb4 --- /dev/null +++ b/wiki/sources/用Docker安装Jellyfin.md @@ -0,0 +1,78 @@ +--- +title: "用Docker安装Jellyfin" +type: source +tags: [docker, jellyfin, media-server, synology, nas] +date: 2026-04-03 +--- + +## Source File +- [[raw/Home Office/用Docker安装Jellyfin.md]] + +## Summary +- 核心主题：Synology NAS Docker 部署 Jellyfin 开源媒体服务器 +- 问题域：自托管家庭媒体库，支撑 Plex 对抗的商业闭源方案 +- 方法/机制：nyanmisaka/jellyfin 镜像 + Intel QuickSync 硬件转码 + 群晖 UID/GID 固定 + 只读媒体卷保护 +- 结论/价值：完整的 Jellyfin Docker Compose 配置，含硬件转码、环境变量、字体挂载、端口和重启策略 + +## Key Claims +- nyanmisaka/jellyfin 镜像提供优化的 Jellyfin 构建，修复官方镜像转码兼容性问题 +- 通过 --devices /dev/dri:/dev/dri 挂载 Intel GPU，实现硬件 QuickSync 转码，降低 CPU 负载 +- 容器使用 user: "1026:100" 固定为群晖默认用户，避免权限问题 +- /volume1/docker/jellyfin/fonts 目录以 :ro 只读挂载，防止字体被容器修改 +- JELLYFIN_PublishedServerUrl 环境变量设置公网访问地址，供外部发现服务 +- restart: unless-stopped 保证容器崩溃后自动重启 + +## Key Quotes +> "群晖建议使用具体的 UID:GID" — Docker 部署最佳实践 +> "核心优化：挂载硬件渲染设备以实现 Intel QuickSync 转码" — 性能优化关键 + +## Key Concepts +- [[硬件转码]]：Intel QuickSync 利用 GPU 加速视频格式转换，减轻 CPU 负担 +- [[媒体刮削]]：Jellyfin 自动从 TMDB/TVDB 等源获取元数据（标题/封面/简介） +- [[Docker容器化]]：隔离运行环境影响，docker-compose 一键部署 +- [[只读挂载]]：保护源文件不被容器内进程意外修改 +- [[Plex]]：Jellyfin 是 Plex 的开源分支，功能高度同构 + +## Key Entities +- [[Jellyfin]]：开源媒体服务器，Plex 的自由软件替代品 +- [[Synology NAS]]：群晖 NAS，Docker 宿主机，存储媒体文件 +- [[nyanmisaka/jellyfin]]：优化过的 Jellyfin 第三方镜像，内置转码支持 + +## Connections +- [[Jellyfin]] ← runs_on ← [[Synology NAS]] +- [[Jellyfin]] ← transcodes_with ← Intel QuickSync (via /dev/dri) +- [[Jellyfin]] ← serves_media ← /volume2/movie + /volume1/TV shows +- [[家庭网络环境概览_2026-04-03]] ← 暴露公网访问 ← jellyfin.ishenwei.online:18096 + +## Jellyfin Docker Compose 核心配置 + +```yaml +services: + jellyfin: + image: nyanmisaka/jellyfin:latest + container_name: jellyfin + user: "1026:100" + ports: + - 8096:8096/tcp + - 7359:7359/udp # 客户端自动发现 + volumes: + - /volume1/docker/jellyfin/config:/config + - /volume1/docker/jellyfin/cache:/cache + - /volume2/movie:/media + - /volume1/TV shows:/media2 + - /volume1/docker/jellyfin/fonts:/usr/local/share/fonts/custom:ro + environment: + - JELLYFIN_PublishedServerUrl=http://jellyfin.ishenwei.online + - TZ=Asia/Shanghai + devices: + - /dev/dri:/dev/dri # Intel GPU 硬件转码 + restart: unless-stopped + extra_hosts: + - host.docker.internal:host-gateway +``` + +## Contradictions +- 与 [[Synology NAS + Xiaoya Alist + CloudDrvie2+ Plex to Build Media Platform]]： + - 冲突点：Plex vs Jellyfin 作为媒体服务器的选择 + - 当前观点：Jellyfin 开源自托管，完全免费 + - 对方观点：Plex 有更好的商业生态和客户端支持