wiki-ingest batch: n8n Docker / Cloud Operating Model / MinIO+Zipline / Trae Remote SSH (2026-04-15 PM)
This commit is contained in:
36
wiki/concepts/AI代码编辑器.md
Normal file
36
wiki/concepts/AI代码编辑器.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "AI代码编辑器"
|
||||
type: concept
|
||||
tags: [ai, code-editor, vibe-coding]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
集成 AI 辅助能力(代码生成/补全/审查/规划)的代码编辑器,相比传统 IDE 新增 AI 代理交互界面。
|
||||
|
||||
## 主流工具
|
||||
- [[Cursor]]:基于 VS Code,Composer 模型,多代理并行
|
||||
- [[Windsurf]]:Codeium 推出的 AI 代码编辑器
|
||||
- [[Trae]]:字节跳动推出的 AI 代码编辑器
|
||||
- [[Cline]]:VS Code 扩展,将 VS Code 变身为全自动 AI 工程师
|
||||
|
||||
## 核心功能对比
|
||||
| 功能 | Cursor | Windsurf | Trae | Cline |
|
||||
|------|--------|----------|------|-------|
|
||||
| 底层框架 | VS Code | VS Code | VS Code | VS Code |
|
||||
| 自研模型 | Composer(4倍速) | Codeium | 豆包/其他 | Claude |
|
||||
| 多代理 | ✅ | ✅ | ✅ | ✅ |
|
||||
| MCP 支持 | ✅ | ✅ | ✅ | ✅ |
|
||||
| Diff 审查 | ✅ | ❓ | ❓ | ✅ |
|
||||
|
||||
## 核心工作流
|
||||
明确需求 → AI 规划(Plan)→ 代码生成(Agent)→ Diff 审查 → Git 版本控制
|
||||
|
||||
## 关联
|
||||
- [[Vibe Coding]] 的工具层实现
|
||||
- [[AI编程]] 的具体工具形态
|
||||
|
||||
## Aliases
|
||||
- AI IDE
|
||||
- AI 代码生成器
|
||||
|
||||
28
wiki/concepts/Bind-Mount.md
Normal file
28
wiki/concepts/Bind-Mount.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: Bind-Mount
|
||||
title: "Bind Mount"
|
||||
type: concept
|
||||
tags: [docker, storage, development]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Bind Mount(绑定挂载)是 Docker 的一种存储卷类型,将宿主机文件系统上的特定目录/文件直接映射到容器内,容器内对此路径的读写操作直接作用于宿主机文件系统,实现代码修改实时生效。
|
||||
|
||||
## vs Named Volume
|
||||
| 维度 | Bind Mount | Named Volume |
|
||||
|------|-----------|-------------|
|
||||
| 数据位置 | 宿主机任意路径 | Docker 管理(/var/lib/docker/volumes) |
|
||||
| 适用场景 | 开发(代码热更新) | 生产(数据持久化) |
|
||||
| 可移植性 | 依赖宿主机路径 | Docker 自动管理 |
|
||||
| 备份 | 随宿主机备份 | 需单独备份 |
|
||||
|
||||
## Use Case
|
||||
- 开发环境:宿主机源码目录挂载到容器内,修改文件无需重建镜像
|
||||
- 生产环境:使用 Named Volume 或直接使用 Synology NAS 存储路径
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker Compose]]:定义 Bind Mount 的方式
|
||||
- [[Docker Attach模式]]:Attach 模式适合 Bind Mount 开发
|
||||
- [[Synology NAS]]:NAS 存储路径直接挂载到容器(/volume1/docker/...)
|
||||
31
wiki/concepts/Cloud-Operating-Model.md
Normal file
31
wiki/concepts/Cloud-Operating-Model.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: Cloud-Operating-Model
|
||||
title: "Cloud Operating Model"
|
||||
type: concept
|
||||
tags: [cloud, governance, strategy]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
云运营模型(Cloud Operating Model,COM)是一套标准化框架,用于组织管理云资源、安全、自动化和成本,确保云投资有效、安全和可持续。
|
||||
|
||||
## Core Pillars
|
||||
1. **治理与合规**:安全策略、访问控制、合规政策
|
||||
2. **自动化与编排**:IaC、CI/CD、事件驱动自动化
|
||||
3. **安全与风险管理**:Zero Trust、实时威胁检测、自动化安全修复
|
||||
4. **云财务管理(FinOps)**:实时成本追踪、Reserved Instances、Auto-Scaling
|
||||
|
||||
## Maturity Levels
|
||||
- Ad-hoc Cloud Adoption:无清晰战略,成本和安全问题突出
|
||||
- Cloud-First Strategy:有定义的流程,但需优化
|
||||
- Cloud-Native Enterprise:自动化驱动,多云复杂性管理
|
||||
|
||||
## Key Quotes
|
||||
> "A Cloud Operating Model is no longer optional—it is the backbone of modern cloud strategy." — Bacancy Technology
|
||||
|
||||
## Related Concepts
|
||||
- [[FinOps]]:云财务管理
|
||||
- [[Zero Trust]]:零信任安全模型
|
||||
- [[Multi-Cloud]]:多云策略
|
||||
- [[DevOps]]:DevOps 文化与 COM 高度重叠
|
||||
27
wiki/concepts/Composer模型.md
Normal file
27
wiki/concepts/Composer模型.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Composer模型"
|
||||
type: concept
|
||||
tags: [ai, code-generation, cursor, llm]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
Cursor 自研的 AI 代码生成模型,主打生成速度优势,官方声称比其他同类模型快 4 倍。
|
||||
|
||||
## 核心特点
|
||||
- **速度优势**:4 倍生成速度,降低等待成本
|
||||
- **深度集成**:与 Cursor 编辑器深度绑定,支持多代理并行
|
||||
- **上下文感知**:基于整个项目文件结构生成代码
|
||||
|
||||
## 技术定位
|
||||
- [[Cursor]] 的核心 AI 能力
|
||||
- 属于通用代码生成模型,非垂直领域定制
|
||||
|
||||
## 关联
|
||||
- [[Composer模型]] ← 属于 ← [[Cursor]]
|
||||
- [[AI代码编辑器]] ← 增强 ← [[Composer模型]]
|
||||
|
||||
## Aliases
|
||||
- Cursor Composer
|
||||
- Cursor 自研模型
|
||||
|
||||
36
wiki/concepts/Diff审查.md
Normal file
36
wiki/concepts/Diff审查.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Diff审查"
|
||||
type: concept
|
||||
tags: [code-review, cursor, ai, git]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过文件对比视图(Diff View)逐文件或整体审查 AI 生成代码改动的机制,是 AI 编程工具中的核心安全机制。
|
||||
|
||||
## 核心功能
|
||||
- **逐文件审查**:逐个查看每个文件的改动内容
|
||||
- **整体接收/撤销**:Accept All 或 Undo All
|
||||
- **逐文件操作**:Accept 或 Undo 单个文件
|
||||
|
||||
## 关键风险
|
||||
- AI 生成代码即写入文件,未点击撤销前持续保留
|
||||
- 关闭文件或多次修改后 Undo All 可能失效
|
||||
- **必须先测试再确认保存**
|
||||
|
||||
## 最佳实践
|
||||
1. 生成代码后进入"待审查"状态
|
||||
2. 使用 Diff 功能逐文件查看改动
|
||||
3. 运行测试验证代码正确性
|
||||
4. 确认无误后 Accept All
|
||||
5. 结合 Git 版本控制以便回滚
|
||||
|
||||
## 关联
|
||||
- [[Cursor]] 的核心审查机制
|
||||
- [[Git]] 版本控制的前置保障
|
||||
- [[AI代码编辑器]] 的标准安全流程
|
||||
|
||||
## Aliases
|
||||
- 代码改动审查
|
||||
- Diff View
|
||||
|
||||
31
wiki/concepts/Docker-Attach模式.md
Normal file
31
wiki/concepts/Docker-Attach模式.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: Docker-Attach-mode
|
||||
title: "Docker Attach模式"
|
||||
type: concept
|
||||
tags: [docker, development, remote]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Docker Attach 模式是一种远程开发方式:Trae/VS Code 直接"进入"已在服务器运行的 Docker 容器,在容器内部启动编辑器后端,实现完全隔离的开发环境。
|
||||
|
||||
## vs 宿主机编辑模式
|
||||
| 维度 | Attach 模式 | 宿主机编辑模式 |
|
||||
|------|------------|-------------|
|
||||
| 编辑器位置 | 容器内 | 宿主机(Ubuntu) |
|
||||
| 环境 | 容器定义的环境 | 宿主机环境 |
|
||||
| Git 凭证 | 需 SSH Agent 转发 | 自动复用宿主机配置 |
|
||||
| 文件权限 | 容器内生成文件属 root | 正常 |
|
||||
| 适合场景 | 深度定制化环境 | docker-compose 管理 |
|
||||
|
||||
## Workflow (Trae)
|
||||
1. Remote SSH 连接到 Ubuntu 服务器
|
||||
2. Docker 插件中找到目标容器
|
||||
3. 右键 → "Attach Visual Studio Code"
|
||||
4. Trae 在容器内安装 Trae Server
|
||||
|
||||
## Related Concepts
|
||||
- [[Remote SSH]]:Attach 模式的前置条件
|
||||
- [[Bind Mount]]:容器内文件与宿主机共享的挂载机制
|
||||
- [[Docker Compose]]:定义开发环境容器的配置文件
|
||||
40
wiki/concepts/Docker-Compose.md
Normal file
40
wiki/concepts/Docker-Compose.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: Docker-Compose
|
||||
title: "Docker Compose"
|
||||
type: concept
|
||||
tags: [docker, orchestration, containers]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Docker Compose 是一个定义和运行多容器 Docker 应用的工具,通过 YAML 文件声明式定义服务、网络、卷和依赖关系,使用 docker compose up 一键启动完整应用栈。
|
||||
|
||||
## Core Concepts
|
||||
- services:定义每个容器(image/build、ports、volumes、environment、depends_on)
|
||||
- volumes:持久化数据存储,named volumes 由 Docker 管理
|
||||
- networks:容器间通信网络,默认 bridge 模式
|
||||
- depends_on:声明服务启动顺序依赖
|
||||
|
||||
## MinIO/Zipline Stack Example
|
||||
```yaml
|
||||
services:
|
||||
minio:
|
||||
image: minio/minio:latest
|
||||
ports: ["9000:9000", "9001:9001"]
|
||||
volumes: [/volume1/docker/zipline-stack/minio/minio_data:/data]
|
||||
postgres:
|
||||
image: postgres:16
|
||||
volumes: [/volume1/docker/zipline-stack/zipline/pg_data:/var/lib/postgresql/data]
|
||||
zipline:
|
||||
depends_on: [minio, postgres]
|
||||
ports: ["3333:3000"]
|
||||
```
|
||||
|
||||
## Update Workflow
|
||||
docker compose pull && docker compose down && docker compose up -d
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker]]:容器化平台
|
||||
- [[MinIO]]:MinIO 部署示例
|
||||
- [[n8n]]:n8n 生产环境推荐 Docker Compose 部署
|
||||
27
wiki/concepts/FinOps.md
Normal file
27
wiki/concepts/FinOps.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: FinOps
|
||||
title: "FinOps"
|
||||
type: concept
|
||||
tags: [cloud, cost-optimization, financial-management]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
云财务运营(FinOps,Cloud Financial Operations)是通过实时追踪、分析和优化云成本,防止云超支并最大化投资回报的管理实践。
|
||||
|
||||
## Core Practices
|
||||
- **Reserved Instances + Spot Instances**:计算成本降低 40-70%
|
||||
- **Auto-Scaling + Right-Sizing**:资源按需匹配实际负载
|
||||
- **实时成本监控**:AWS Cost Explorer、Azure Cost Management、GCP Billing Reports
|
||||
- **资源标签化**:按团队、项目、工作负载追踪支出
|
||||
|
||||
## Key Stats
|
||||
- 59% 企业经历云成本管理困难(Flexera 2024)
|
||||
- 全球电商公司通过 AWS+Azure 双云 Reserved Instances 节省 $500,000/年
|
||||
- SaaS 公司通过 Auto-Scaling + Reserved Instances 降低 35% 云成本
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]:FinOps 是 COM 的四大支柱之一
|
||||
- [[Multi-Cloud]]:多云环境下的成本管理更复杂
|
||||
- [[DevOps]]:DevOps 团队需与 FinOps 协作
|
||||
31
wiki/concepts/Google-Workspace-CLI.md
Normal file
31
wiki/concepts/Google-Workspace-CLI.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Google Workspace CLI"
|
||||
type: concept
|
||||
tags: [cli, google-workspace, automation, macos]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过命令行界面(CLI)管理 Google Workspace 全部服务(Gmail/Calendar/Drive/Contacts/Docs/Sheets)的工具,支撑脚本化与自动化工作流。
|
||||
|
||||
## 核心工具
|
||||
- [[gog CLI]]:macOS 专属,Homebrew 安装,支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets
|
||||
|
||||
## 关键机制
|
||||
- **OAuth 双层验证**:OAuth 凭证(身份)+ API Enablement(权限)缺一不可
|
||||
- **账号级默认设置**:export GOG_ACCOUNT=ishenwei@gmail.com 避免每次指定账号
|
||||
- **故障排除关键**:403 accessNotConfigured 的根因是 API 未启用而非 OAuth 问题
|
||||
|
||||
## 应用场景
|
||||
- 邮件自动化(定时搜索/发送/归档)
|
||||
- 日历自动化(定时检查日程/创建事件)
|
||||
- 文档导出自动化(定时备份 Docs 内容)
|
||||
|
||||
## 关联
|
||||
- [[gog CLI]] 是 Google Workspace CLI 在 macOS 的具体实现
|
||||
- [[n8n Workflow自动化]] 可通过 gog CLI 作为节点调用 Google 服务
|
||||
|
||||
## Aliases
|
||||
- Google CLI
|
||||
- gog
|
||||
|
||||
35
wiki/concepts/Remote-SSH.md
Normal file
35
wiki/concepts/Remote-SSH.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: Remote-SSH
|
||||
title: "Remote SSH"
|
||||
type: concept
|
||||
tags: [development, remote, ssh, vscode]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Remote SSH 是 VS Code/Trae 的核心插件,允许通过 SSH 连接在远程服务器上运行编辑器后端(VS Code Server/Trae Server),开发者获得与本地开发几乎一致的体验,同时利用远程服务器的算力和存储。
|
||||
|
||||
## How It Works
|
||||
1. 本地机器通过 SSH Config 连接到远程服务器
|
||||
2. Trae 在远程服务器自动安装 Trae Server(首次连接约几十秒)
|
||||
3. 所有编辑、终端、插件操作均在远程服务器执行
|
||||
4. 本地仅作为 UI 终端渲染
|
||||
|
||||
## SSH Config Setup
|
||||
```
|
||||
Host ubuntu2
|
||||
HostName 192.168.3.45
|
||||
User shenwei
|
||||
Port 22
|
||||
IdentityFile ~/.ssh/id_rsa
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
- Git 凭证:Trae 自动转发本地 SSH Agent,需在本地启动 ssh-agent
|
||||
- 文件权限:容器内生成文件归属 root,通过 --user 参数或 Dockerfile 指定 UID 解决
|
||||
|
||||
## Related Concepts
|
||||
- [[Trae]]:支持 Remote SSH 的 AI 代码编辑器
|
||||
- [[SSH Agent转发]]:凭证传递机制
|
||||
- [[Docker Attach模式]]:Remote SSH 与 Docker 容器开发的结合
|
||||
29
wiki/concepts/S3协议.md
Normal file
29
wiki/concepts/S3协议.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: S3-Protocol
|
||||
title: "S3协议"
|
||||
type: concept
|
||||
tags: [storage, protocol, cloud]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
S3(Simple Storage Service)协议是 Amazon 发布的对象存储接口标准,通过 RESTful API 提供键值对形式的大规模对象存储。MinIO、Cloudflare R2、Backblaze B2 等均兼容 S3 协议。
|
||||
|
||||
## Core Operations
|
||||
- PUT/GET/DELETE Object:上传、下载、删除对象
|
||||
- ListBuckets/ListObjects:列举存储桶和对象
|
||||
- HEAD Object:获取对象元数据
|
||||
|
||||
## MinIO Configuration Parameters
|
||||
- S3_BUCKET:存储桶名称
|
||||
- S3_ENDPOINT:S3 API 端点 URL
|
||||
- S3_ACCESS_KEY:访问密钥(MINIO_ROOT_USER)
|
||||
- S3_SECRET_KEY:秘密密钥(MINIO_ROOT_PASSWORD)
|
||||
- S3_REGION:区域(MinIO 使用 us-east-1)
|
||||
- S3_FORCE_PATH_STYLE:true(MinIO 必需,R2 等云服务可 false)
|
||||
|
||||
## Related Concepts
|
||||
- [[MinIO]]:开源 S3 兼容对象存储
|
||||
- [[Zipline]]:使用 S3 协议连接 MinIO 的应用
|
||||
- [[向量数据库]]:与对象存储是完全不同的数据存储范式
|
||||
27
wiki/concepts/Zero-Trust.md
Normal file
27
wiki/concepts/Zero-Trust.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: Zero-Trust
|
||||
title: "Zero Trust"
|
||||
type: concept
|
||||
tags: [security, cloud, framework]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
零信任安全模型(Zero Trust)是一种安全框架,核心原则为"永不信任,始终验证"——不假设网络边界内的任何请求是安全的,要求每次访问都经过身份验证和授权。
|
||||
|
||||
## Core Principles
|
||||
- 永不隐式信任:无论请求来自内网还是外网,都需验证
|
||||
- 最小权限原则:仅授予完成任务的最低权限
|
||||
- 持续验证:动态评估访问上下文(设备状态、位置、行为)
|
||||
- 微分段网络:限制横向移动,即使边界被突破
|
||||
|
||||
## Cloud Implementation
|
||||
- AWS:IAM + Security Hub + GuardDuty
|
||||
- Azure:Azure AD + Microsoft Defender + Sentinel
|
||||
- GCP:Google IAM + Security Command Center
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]:Zero Trust 是 COM 安全支柱的核心
|
||||
- [[DevSecOps]]:Zero Trust 嵌入 DevOps 流程
|
||||
- [[Multi-Cloud Governance]]:跨云统一实施 Zero Trust
|
||||
32
wiki/concepts/多代理并行.md
Normal file
32
wiki/concepts/多代理并行.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "多代理并行"
|
||||
type: concept
|
||||
tags: [ai, multi-agent, cursor, concurrency]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
AI 编程工具中多个 AI 代理同时运行不同任务、互不干扰的工作模式。
|
||||
|
||||
## 核心价值
|
||||
- **效率提升**:同一时间并行生成多个模块
|
||||
- **上下文隔离**:每个代理独立上下文,避免相互干扰
|
||||
- **场景区分**:一个代理执行主任务,另一个代理同时构建配套页面/测试
|
||||
|
||||
## 实践方式(Cursor 2.0)
|
||||
1. 主代理:执行游戏开发等主要任务
|
||||
2. 副代理:新建代理创建 Landing Page 等独立模块
|
||||
3. 两种代理并行运行,互不阻塞
|
||||
|
||||
## 使用规范
|
||||
- 分散任务时创建新代理,避免在已有代理内继续先前任务
|
||||
- 同一代理内继续先前任务效果更佳
|
||||
|
||||
## 关联
|
||||
- [[Cursor]] 的多代理并行能力
|
||||
- [[Multi-Agent System Reliability]] 的理论与实践对照
|
||||
|
||||
## Aliases
|
||||
- Multi-Agent concurrency
|
||||
- 多 Agent 并行
|
||||
|
||||
37
wiki/concepts/多平台热点聚合.md
Normal file
37
wiki/concepts/多平台热点聚合.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "多平台热点聚合"
|
||||
type: concept
|
||||
tags: [research, social-media, trend-analysis]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
整合多个社交媒体平台(Reddit/X/YouTube/TikTok/Instagram/Hacker News/Polymarket/Web)的数据进行结构化趋势研究的方法论。
|
||||
|
||||
## 核心机制
|
||||
- **权重分层**:Reddit/X > YouTube > Polymarket > TikTok > Instagram > Web
|
||||
- **数据可信度**:Polymarket(真金白银押注)> Reddit/X(高互动)> Web(无互动)
|
||||
- **单次查询多平台覆盖**:用户输入一个话题,返回跨平台交叉验证的研究报告
|
||||
|
||||
## 执行流程
|
||||
1. 用户输入话题(可选:--x-handle 指定 X 账号、--days 回溯天数)
|
||||
2. ScrapeCreators 抓取 Reddit/TikTok/Instagram
|
||||
3. XAI API 或 AUTH_TOKEN 抓取 X
|
||||
4. Polymarket API 抓取预测市场数据
|
||||
5. Web 搜索补充博客/新闻
|
||||
6. 聚合输出:What I Learned + Key Patterns + Stats + Invitation
|
||||
|
||||
## 应用场景
|
||||
- 竞品分析("cursor vs windsurf" 对比模式)
|
||||
- 人物追踪(--x-handle 指定账号)
|
||||
- 行业周报(--days=7 --quick)
|
||||
- 热点发现(--deep 深度研究)
|
||||
|
||||
## 关联
|
||||
- [[Last30Days]] 是此方法论的自动化实现工具
|
||||
- [[社交信号权重]] 是此方法论的数据评估框架
|
||||
|
||||
## Aliases
|
||||
- 多源热点研究
|
||||
- 跨平台趋势分析
|
||||
|
||||
35
wiki/concepts/社交信号权重.md
Normal file
35
wiki/concepts/社交信号权重.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "社交信号权重"
|
||||
type: concept
|
||||
tags: [social-media, signal-analysis, credibility]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
基于用户互动质量而非单纯曝光量评估内容热度和可信度的评估框架。
|
||||
|
||||
## 权重分层
|
||||
| 平台 | 权重 | 核心指标 |
|
||||
|------|------|----------|
|
||||
| Polymarket | 最高 | 赔率(真金白银押注,最真实) |
|
||||
| Reddit | 高 | upvotes + comments |
|
||||
| X (Twitter) | 高 | likes + retweets |
|
||||
| YouTube | 高 | views + likes + transcripts |
|
||||
| TikTok | 中 | views + likes + 标题 |
|
||||
| Instagram | 中 | views + likes |
|
||||
| Hacker News | 中 | points + comments |
|
||||
| Web | 低 | 无互动数据,仅补充 |
|
||||
|
||||
## 核心洞察
|
||||
- **互动数据 > 曝光数据**:10万观看但无互动 ≠ 真实热度
|
||||
- **押注数据 > 投票数据**:Polymarket 赔率反映真实概率判断
|
||||
- **评论 > 帖子**:Reddit top comments 往往比标题更有价值
|
||||
|
||||
## 关联
|
||||
- [[多平台热点聚合]] 的数据评估基础
|
||||
- [[Last30Days]] 的权重体系来源
|
||||
|
||||
## Aliases
|
||||
- Engagement-weighted signal
|
||||
- 互动权重分析
|
||||
|
||||
36
wiki/concepts/项目规则.md
Normal file
36
wiki/concepts/项目规则.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "项目规则"
|
||||
type: concept
|
||||
tags: [cursor, ai, code-editor, rules]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
可自定义的配置文件(.cursorrules 等),用于约束 AI 代码生成行为,实现团队代码规范自动化。
|
||||
|
||||
## 实现方式
|
||||
在项目根目录创建规则文件,写入期望 AI 遵守的行为规范。
|
||||
|
||||
## 示例
|
||||
```markdown
|
||||
// .cursorrules
|
||||
Always generate doc strings for functions
|
||||
Use TypeScript strict mode
|
||||
Follow the team's naming conventions
|
||||
```
|
||||
|
||||
## 应用场景
|
||||
- 强制为函数生成 Doc 注释(规范文档)
|
||||
- 约束代码风格(命名/缩进/类型)
|
||||
- 定义项目特定的处理逻辑
|
||||
|
||||
## 关联
|
||||
- [[Cursor]] 的自定义规则机制
|
||||
- [[AI代码编辑器]] 的安全和质量控制层
|
||||
- [[Vibe Coding]] 规范化的工具保障
|
||||
|
||||
## Aliases
|
||||
- .cursorrules
|
||||
- Cursor 项目规则
|
||||
- AI 代码规范
|
||||
|
||||
Reference in New Issue
Block a user