Sync: add knowledge graph and design notes
This commit is contained in:
1243
Project/fonrey/UI_DESIGN/客源_UI设计.md
Normal file
1243
Project/fonrey/UI_DESIGN/客源_UI设计.md
Normal file
File diff suppressed because it is too large
Load Diff
307
Project/fonrey/UI_SYSTEM/模块UI设计文档生成提示词.md
Normal file
307
Project/fonrey/UI_SYSTEM/模块UI设计文档生成提示词.md
Normal file
@@ -0,0 +1,307 @@
|
||||
# Fonrey 模块 UI 设计文档生成提示词
|
||||
|
||||
> **用途**：每次针对一个具体业务模块，填入变量后直接发给 AI，输出该模块的标准化 UI 设计文档。
|
||||
> **输出文件**：`Project/fonrey/UI_SYSTEM/模块UI设计/{模块名}_UI设计.md`
|
||||
|
||||
---
|
||||
|
||||
## 使用方法
|
||||
|
||||
1. 复制下方「---PROMPT START---」到「---PROMPT END---」之间的全部内容
|
||||
2. 将所有 `{{变量}}` 替换为本次模块的实际值
|
||||
3. 把替换后的提示词发给 AI
|
||||
|
||||
---PROMPT START---
|
||||
|
||||
# 任务：为 {{模块名称}} 生成模块 UI 设计文档
|
||||
|
||||
## 你的角色
|
||||
|
||||
你是 Fonrey 房产经纪管理系统的 **UI/UX 架构师**，负责根据竞品截图和 PRD 功能描述，产出一份标准化的模块级 UI 设计文档。该文档将直接交给 AI Engineer 用于编码实现，必须包含足够的细节，Engineer 无需再问任何问题。
|
||||
|
||||
---
|
||||
|
||||
## 全局设计约束（必须严格遵守）
|
||||
|
||||
> 所有设计决策必须符合 `Project/fonrey/UI_SYSTEM/UI_SYSTEM.md` 中的设计规范。核心约束如下：
|
||||
|
||||
- **技术栈**：Tailwind CSS + HTMX + Alpine.js + Django HTML 模板（非 React/Vue/JSX）
|
||||
- **图标库**：Heroicons v2（Outline 24px 默认，Solid 20px 强调，Mini 16px 极密场景）
|
||||
- **主色**：Teal `#0F766E`（`primary-600`），所有颜色引用 Token，禁止硬编码 Hex
|
||||
- **圆角**：`rounded-lg`（8px）为默认，表格行/小组件用 `rounded-md`（6px）
|
||||
- **表格行高**：56px（`h-14`）
|
||||
- **字体**：Inter + PingFang SC，正文 `text-sm`（14px）
|
||||
- **焦点环**：`focus-visible:ring-2 focus-visible:ring-primary-600/40`
|
||||
- **桌面优先**：≥1280px，不做移动端适配
|
||||
- **禁止独立 CSS 文件或 CSS-in-JS**：所有样式用 Tailwind utility class（少量例外如 Flatpickr 覆盖样式）
|
||||
- **组件实现参考**：`Project/fonrey/UI_SYSTEM/组件规范设计.md`（含 20 个特殊组件的完整 HTML + Alpine.js 实现）
|
||||
|
||||
---
|
||||
|
||||
## 本次任务输入
|
||||
|
||||
### 1. 目标模块
|
||||
**模块名称**：{{模块名称}}
|
||||
**模块描述**：{{一句话描述模块核心功能}}
|
||||
|
||||
### 2. PRD 功能文档路径
|
||||
```
|
||||
{{PRD文件路径，如：Project/fonrey/PRD/房源管理/房源管理模块PRD.md}}
|
||||
```
|
||||
请读取该文件，理解每个功能点的业务逻辑和验收标准。
|
||||
|
||||
### 3. 竞品参考截图
|
||||
请读取以下截图文件作为视觉参考（所有截图均在 `Project/fonrey/screenshots/` 目录下）：
|
||||
|
||||
{{截图列表，格式如下，每行一张：
|
||||
- 功能名称：`Project/fonrey/screenshots/模块/截图名.png`
|
||||
}}
|
||||
|
||||
### 4. MVP 优先级参考
|
||||
请参考 `Project/fonrey/PRD/PRD_MVP.md`，在设计文档中标注每个页面/功能的优先级（P0/P1/P2）。
|
||||
|
||||
---
|
||||
|
||||
## 输出格式要求
|
||||
|
||||
输出一份完整的 Markdown 文档，文件名为 `{{模块名称}}_UI设计.md`，结构如下：
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# {{模块名称}} UI 设计文档
|
||||
|
||||
> **版本**：v1.0 · **日期**：{今日日期}
|
||||
> **依赖规范**：UI_SYSTEM.md v1.1 · 组件规范设计.md v1.0
|
||||
> **PRD 来源**：{PRD文件路径}
|
||||
> **优先级**：P0 功能在本文档中用 🔴 标注，P1 用 🟡，P2 用 ⚫
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
（列出本文档所有章节）
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块概述
|
||||
|
||||
### 1.1 功能范围
|
||||
（从 PRD 提取本模块包含的所有功能，按优先级分组列表）
|
||||
|
||||
### 1.2 页面清单
|
||||
（列出本模块所有页面/视图，每行包含：页面名称 | URL 模式建议 | 优先级 | 对应 PRD 章节）
|
||||
|
||||
### 1.3 用户角色与权限差异
|
||||
（说明不同角色（经纪人/店长/管理员）在本模块的视图差异，如哪些字段/按钮对特定角色隐藏）
|
||||
|
||||
---
|
||||
|
||||
## 2. 页面设计规范
|
||||
|
||||
> 每个页面单独一节，按以下子结构输出。
|
||||
|
||||
### 2.N {页面名称}（{优先级} 🔴/🟡/⚫）
|
||||
|
||||
#### 2.N.1 页面概述
|
||||
- **URL**：`/模块/页面/`
|
||||
- **访问入口**：（从哪里进入此页面）
|
||||
- **页面职责**：（一句话）
|
||||
- **竞品参考截图**：`{截图路径}`
|
||||
|
||||
#### 2.N.2 布局结构
|
||||
（用文字描述页面整体布局，如：三栏布局、左侧边栏+右侧主内容区、全宽列表等）
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ 顶部区域（Breadcrumb / 页面标题 / 主操作按钮） │
|
||||
├──────────────────────────────────────────────────────────┤
|
||||
│ 筛选区域（可折叠） │
|
||||
├──────────────────────────────────────────────────────────┤
|
||||
│ 工具栏（批量操作 / 排序切换 / 列设置 / 导出） │
|
||||
├──────────────────────────────────────────────────────────┤
|
||||
│ 主内容区（表格 / 详情卡片 / 表单） │
|
||||
├──────────────────────────────────────────────────────────┤
|
||||
│ 分页栏 │
|
||||
└──────────────────────────────────────────────────────────┘
|
||||
```
|
||||
（根据实际页面调整此 ASCII 图）
|
||||
|
||||
#### 2.N.3 区域详细规范
|
||||
|
||||
> 每个区域独立描述，包含：组件类型、字段/按钮清单、交互逻辑
|
||||
|
||||
**[区域名称，如：搜索筛选区]**
|
||||
|
||||
| 属性 | 说明 |
|
||||
|---|---|
|
||||
| 组件 | （引用组件规范设计.md 中的组件名，如：Date Range Picker） |
|
||||
| 展开/收起 | （是否支持折叠，默认状态） |
|
||||
| 筛选字段 | （列出所有筛选字段及输入类型） |
|
||||
| 联动逻辑 | （字段间的联动关系） |
|
||||
| HTMX 行为 | （如：`hx-get="/api/xxx/" hx-trigger="change" hx-target="#table-body"`） |
|
||||
|
||||
**[区域名称，如：数据表格]**
|
||||
|
||||
| 列名 | 数据类型 | 宽度 | 排序 | 特殊渲染 |
|
||||
|---|---|---|---|---|
|
||||
| （列名） | （string/number/date/badge/...） | （fixed px 或 auto） | （是/否） | （如：Tag、趋势箭头、行内按钮） |
|
||||
|
||||
（补充表格交互说明：行点击跳转、批量选择、列固定等）
|
||||
|
||||
#### 2.N.4 使用的特殊组件
|
||||
|
||||
| 组件名 | 来源（组件规范设计.md 章节） | 用途 | 自定义说明 |
|
||||
|---|---|---|---|
|
||||
| （组件名） | （如：§1 Data Table） | （用于展示xxx列表） | （如果有与标准实现不同的地方，详细说明） |
|
||||
|
||||
#### 2.N.5 空状态设计
|
||||
（描述列表/表格无数据时的展示方式，参考 UI_SYSTEM.md §6.3 空状态设计）
|
||||
|
||||
#### 2.N.6 Loading 状态
|
||||
（描述数据加载中的骨架屏或加载指示方案）
|
||||
|
||||
---
|
||||
|
||||
## 3. 弹窗/抽屉设计规范
|
||||
|
||||
> 每个弹窗/抽屉独立一节，按以下结构输出。
|
||||
|
||||
### 3.N {弹窗/抽屉名称}（{触发入口}）
|
||||
|
||||
#### 3.N.1 触发方式
|
||||
- **触发位置**：（如：房源详情页-调价链接）
|
||||
- **组件类型**：Modal Dialog / Drawer（选一个，说明选择理由）
|
||||
- **尺寸**：（Modal: max-w-sm/md/lg/xl/2xl；Drawer: w-[480px]/w-[640px]）
|
||||
- **竞品截图**：`{截图路径}`
|
||||
|
||||
#### 3.N.2 表单字段规范
|
||||
|
||||
| 字段名 | 组件类型 | 必填 | 校验规则 | 默认值/预填值 |
|
||||
|---|---|---|---|---|
|
||||
| （字段名） | （Input/Select/Textarea/DatePicker/Toggle/TreeSelect/MultiTag/...） | （是/否） | （规则描述） | （如有） |
|
||||
|
||||
#### 3.N.3 提交行为
|
||||
- **提交方式**：HTMX `hx-post` / `hx-put` / `hx-patch`
|
||||
- **成功响应**：（如：关闭弹窗 + Toast "保存成功" + 刷新目标区域）
|
||||
- **失败响应（422）**：（字段级错误提示）
|
||||
- **HTMX 属性**：（完整写出 hx-post/hx-target/hx-swap/hx-on 等）
|
||||
|
||||
#### 3.N.4 使用的特殊组件
|
||||
|
||||
| 组件名 | 来源 | 用途 |
|
||||
|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互状态规范
|
||||
|
||||
### 4.1 全局状态机（如有）
|
||||
（如房源状态机：在售 → 暂缓 → 成交 → 下架，用状态流转图描述）
|
||||
|
||||
### 4.2 权限控制矩阵
|
||||
（描述不同角色对本模块各操作的权限，如：删除只有管理员可见）
|
||||
|
||||
| 操作 | 经纪人 | 店长 | 管理员 |
|
||||
|---|---|---|---|
|
||||
|
||||
### 4.3 HTMX 请求规范
|
||||
（列出本模块所有 HTMX 请求，包含：触发事件、URL、target、swap 方式、Loading 行为）
|
||||
|
||||
| 操作 | hx-trigger | hx-get/post/... | hx-target | hx-swap | Loading |
|
||||
|---|---|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 5. 关键数据字段说明
|
||||
|
||||
（列出本模块所有需要后端支持的数据字段，便于 Engineer 与后端联调）
|
||||
|
||||
| 字段名（英文） | 显示名 | 数据类型 | 说明 |
|
||||
|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 6. 竞品截图对应关系
|
||||
|
||||
（将本模块所有参考截图按功能分类整理，说明截图对应设计文档的哪个章节）
|
||||
|
||||
| 截图路径 | 对应功能 | 对应文档章节 | 采纳的设计要点 |
|
||||
|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 7. 实现优先级与工期估算
|
||||
|
||||
| 页面/功能 | 优先级 | 特殊组件复杂度 | 工期估算（前端） |
|
||||
|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 8. 开放问题（待决策）
|
||||
|
||||
（列出设计过程中发现的、需要产品/后端确认的问题）
|
||||
|
||||
| # | 问题 | 影响范围 | 待确认方 |
|
||||
|---|---|---|---|
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 额外要求
|
||||
|
||||
1. **截图优先**：有截图的功能，以截图呈现的 UI 为主要参考，PRD 文字为补充说明；截图和 PRD 有冲突时，以截图为准，并在文档中注明差异。
|
||||
|
||||
2. **组件引用**：每次使用特殊组件（如 Data Table、Tree Select、Drawer 等），必须在"使用的特殊组件"表格中引用组件规范设计.md 的对应章节编号，并说明如有差异的自定义部分。
|
||||
|
||||
3. **HTMX 落地**：每个需要异步更新的交互（筛选、分页、弹窗提交）必须写出完整的 HTMX 属性，Engineer 可以直接复制使用。
|
||||
|
||||
4. **Alpine.js 分工**：说明哪些状态由 Alpine.js 管理（弹窗开关、选中状态、表单联动），哪些交互走 HTMX（数据加载、表单提交）。
|
||||
|
||||
5. **禁止设计移动端**：所有布局仅针对 ≥1280px 桌面端。
|
||||
|
||||
6. **优先级标注**：P0 功能用 🔴，P1 用 🟡，P2 用 ⚫，确保 Engineer 知道实现顺序。
|
||||
|
||||
7. **不要遗漏边界状态**：每个列表页必须包含空状态设计；每个表单必须包含校验失败状态；每个异步操作必须包含 Loading 状态。
|
||||
|
||||
---PROMPT END---
|
||||
|
||||
---
|
||||
|
||||
## 已生成的模块 UI 设计文档
|
||||
|
||||
| 模块 | 文件路径 | 生成日期 | 覆盖 PRD 版本 |
|
||||
|---|---|---|---|
|
||||
| （待填入） | | | |
|
||||
|
||||
---
|
||||
|
||||
## 变量填写示例（房源列表页）
|
||||
|
||||
```
|
||||
{{模块名称}} → 房源管理
|
||||
{{一句话描述模块核心功能}} → 管理房产经纪公司的二手房/租赁房源，支持录入、筛选、跟进、状态变更
|
||||
{{PRD文件路径}} → Project/fonrey/PRD/房源管理/房源管理模块PRD.md
|
||||
{{截图列表}} →
|
||||
- 房源列表（二手&租赁）：`Project/fonrey/screenshots/房源/全部房源.png`
|
||||
- 房源列表（全部商铺）：`Project/fonrey/screenshots/房源/全部商铺.png`
|
||||
- 房源详情（第1屏）：`Project/fonrey/screenshots/房源/房源详情1.png`
|
||||
- 房源详情（第2屏）：`Project/fonrey/screenshots/房源/房源详情2.png`
|
||||
- 房源详情（第3屏）：`Project/fonrey/screenshots/房源/房源详情3.png`
|
||||
- 新增住宅表单：`Project/fonrey/screenshots/房源/增房/新增住宅.png`
|
||||
- 调价弹窗：`Project/fonrey/screenshots/房源/调价.png`
|
||||
- 调价记录弹窗：`Project/fonrey/screenshots/房源/调价记录.png`
|
||||
- 房源状态变更：`Project/fonrey/screenshots/房源/房源状态变更.png`
|
||||
- 跟进管理-全部：`Project/fonrey/screenshots/房源/跟进管理/全部.png`
|
||||
- 跟进管理-写入跟进：`Project/fonrey/screenshots/房源/跟进管理/写入跟进.png`
|
||||
- 相册管理：`Project/fonrey/screenshots/房源/增房/上传图片.png`
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 单次提示词只针对**一个模块**，不要同时处理多个模块
|
||||
- 对于同一模块内页面较多的情况（如房源管理有列表、详情、新增、跟进等多个页面），**全部包含在同一份文档中**，通过 `§2.N` 分节区分
|
||||
- 弹窗数量较多时（如房源详情有 10+ 个编辑弹窗），可以将**结构相似的弹窗合并为一个通用弹窗规范**，仅列出字段差异表
|
||||
- 生成完成后，将文档路径更新到上方「已生成的模块 UI 设计文档」表格中
|
||||
71
wiki/concepts/Daily-Log.md
Normal file
71
wiki/concepts/Daily-Log.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "Daily-Log"
|
||||
type: concept
|
||||
tags: [knowledge-management, productivity, zettelkasten, zk-steward]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Daily-Log（每日日志）是 [[zk-steward]] 维持知识网络时效性的基础设施——在 `memory/YYYY-MM-DD.md` 路径下，以 Intent / Changes / Open loops 三段式格式记录当天所有知识活动的日志。
|
||||
|
||||
## Format
|
||||
|
||||
```markdown
|
||||
### [YYYYMMDD] Short task title
|
||||
|
||||
- **Intent**: What the user wanted to accomplish.
|
||||
- **Changes**: What was done (files, links, decisions).
|
||||
- **Open loops**: [ ] Unresolved item 1; [ ] Unresolved item 2 (or "None.")
|
||||
```
|
||||
|
||||
## Three Sections Explained
|
||||
|
||||
### Intent（意图）
|
||||
简述用户当天提出的核心任务或问题。作用：保留任务上下文，防止日后"这段知识从哪里来"的困惑。
|
||||
|
||||
### Changes（变更）
|
||||
记录当天产出的实质性变化：
|
||||
- 创建/更新的笔记及路径
|
||||
- 新建立的链接
|
||||
- 归档决策（如"为什么不链接到 X"）
|
||||
- 索引/MOC 更新
|
||||
|
||||
### Open Loops（开放循环）
|
||||
扫描当天未完成或待跟进的事项：
|
||||
- [ ] 标记未解决项目
|
||||
- "None." 表示当天没有遗留问题
|
||||
- 这是"容易忘记但重要"项目的收容池
|
||||
|
||||
## Why Daily-Log Matters
|
||||
|
||||
| 问题 | Daily-Log 解决方案 |
|
||||
|------|-----------------|
|
||||
| "这条知识从哪来？" | Intent 提供任务上下文 |
|
||||
| "上周做了什么决策？" | Changes 记录归档决策历史 |
|
||||
| "上次卡在哪里了？" | Open loops 保留未解决线索 |
|
||||
| "知识网络时效性？" | 每日增量更新，无需批量维护 |
|
||||
|
||||
## Relationship to Zettelkasten
|
||||
|
||||
在传统 [[Zettelkasten]] 中，日志通常是隐式的（通过卡片间的时间戳和引用关系推断）。[[zk-steward]] 将日志显式化：
|
||||
- **时间锚定**：每日一条日志，索引按日期可检索
|
||||
- **决策透明**：归档选择和理由显式记录
|
||||
- **开放循环追踪**：防止遗忘，同时为未来灵感留白
|
||||
|
||||
## 与 Morning Briefing 的区别
|
||||
|
||||
Daily-Log 由 [[zk-steward]] 维护，聚焦**知识积累**活动（笔记/链接/归档）。Morning Briefing（如 [[养虾日记3]] 中提到的）在 AI Agent 场景下，指的是**任务活动**的早晨总结（待办/进度/阻塞）。两者互补：
|
||||
- **Daily-Log**：知识网络建设视角
|
||||
- **Morning Briefing**：任务执行视角
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 使用 Daily-Log 作为每日知识活动记录
|
||||
- [[Luhmann-四原则]] ← Daily-Log 服务于"有机增长"原则（知识随时间自然积累）
|
||||
- [[Zettelkasten]] ← Daily-Log 是 Zettelkasten 时间维度的显式实现
|
||||
- [[Open-Loops]] ← Daily-Log 的 Open Loops 部分直接填入 Open-Loops 文件
|
||||
|
||||
## Aliases
|
||||
- 每日日志
|
||||
- 日志
|
||||
- 每日知识日志
|
||||
69
wiki/concepts/Domain-Thinking.md
Normal file
69
wiki/concepts/Domain-Thinking.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: "Domain-Thinking"
|
||||
type: concept
|
||||
tags: [thinking-framework, expert-selection, zk-steward, ai-prompting]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Domain-Thinking（领域思维）是 [[zk-steward]] 采用的专家视角切换机制——按 **domain（领域）× task type（任务类型）× output form（输出形式）** 三维定位，选取该领域顶级思维模型或专家视角驱动输出。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
```
|
||||
Domain × Task Type × Output Form → Expert Selection
|
||||
```
|
||||
|
||||
当用户发起任务时，ZK Steward 解析：
|
||||
- **Domain**：知识领域（品牌营销/学习研究/商业策略/工程等）
|
||||
- **Task Type**：任务性质（分析/创意/决策/学习等）
|
||||
- **Output Form**：期望输出形式（结构化报告/创意文案/执行计划等）
|
||||
|
||||
三维交叉后选取对应领域的顶级专家心智模型。
|
||||
|
||||
## Domain-Expert Mapping（核心参考表）
|
||||
|
||||
| Domain | Top Expert | Core Method |
|
||||
|--------|-----------|-------------|
|
||||
| Brand marketing | David Ogilvy | Long copy, brand persona |
|
||||
| Growth marketing | Seth Godin | Purple Cow, minimum viable audience |
|
||||
| Business strategy | Charlie Munger | Mental models, inversion |
|
||||
| Competitive strategy | Michael Porter | Five forces, value chain |
|
||||
| Product design | Steve Jobs | Simplicity, UX |
|
||||
| Learning / research | Richard Feynman | First principles, teach to learn |
|
||||
| Tech / engineering | Andrej Karpathy | First-principles engineering |
|
||||
| Copy / content | Joseph Sugarman | Triggers, slippery slide |
|
||||
| AI / prompts | Ethan Mollick | Structured prompts, persona pattern |
|
||||
|
||||
**默认值**：Niklas Luhmann（知识管理/Zettelkasten/笔记网络）
|
||||
|
||||
## Declaration Requirement
|
||||
|
||||
[[zk-steward]] 强制要求在每个回复的**第一或第二句**声明专家视角：
|
||||
> "From [Expert name / school of thought]'s perspective..."
|
||||
|
||||
禁止：
|
||||
- ❌ 使用泛泛的"专家说..."
|
||||
- ❌ 引用方法而不应用方法（name-drop without applying the method）
|
||||
- ❌ 跳过视角声明
|
||||
|
||||
## 与传统角色扮演的区别
|
||||
|
||||
| 维度 | Domain-Thinking | Generic Role-Play |
|
||||
|------|----------------|-------------------|
|
||||
| 专家选择 | 基于任务三维定位 | 预设固定角色 |
|
||||
| 方法应用 | 必须真正应用专家方法 | 仅贴标签 |
|
||||
| 视角深度 | 领域特定深度推理 | 泛泛泛化 |
|
||||
| 产出质量 | 专家级结构化输出 | 表面化建议 |
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 使用 Domain-Thinking 作为核心工作模式
|
||||
- [[Niklas-Luhmann]] ← Domain-Thinking 的默认值专家
|
||||
- [[Luhmann-四原则]] ← Domain-Thinking 与四原则协同保证输出质量
|
||||
|
||||
## Aliases
|
||||
- 领域专家切换
|
||||
- Expert Switching
|
||||
- Mental Model Selection
|
||||
- Three-dimensional Expert Triangulation
|
||||
71
wiki/concepts/ESN.md
Normal file
71
wiki/concepts/ESN.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "ESN (Entreprise de Services Numériques)"
|
||||
type: concept
|
||||
tags: [france, consulting, esn, si, market-structure]
|
||||
sources: [specialized-french-consulting-market]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
ESN（Entreprise de Services Numériques）是法国特有的 IT 咨询公司生态，中文可理解为"数字服务企业"，前身是 SSII（Société de Services et d'Ingénierie en Informatique）。法国市场约 80% 的企业 IT 项目通过 ESN 生态完成——这是理解法国 IT 自由职业市场结构的基石。
|
||||
|
||||
## ESN Tier Classification
|
||||
|
||||
| 级别 | 代表企业 | 典型 Margin | 顾问议价能力 | 销售周期 |
|
||||
|------|---------|------------|------------|---------|
|
||||
| **Tier 1 — 全球型** | Accenture, Capgemini, Atos, CGI, Sopra Steria | 35-50% | 低（标准化定价表） | 4-8 周 |
|
||||
| **Tier 2 — 专项型** | Cloudity, Niji, SpikeeLabs, EI-Technologies,，公有云 MSP | 25-40% | 中（可协商） | 2-4 周 |
|
||||
| **Tier 3 — 经纪型** | Free-Work listings, 小型中介 | 15-25% | 高（体量博弈） | 1-2 周 |
|
||||
|
||||
## Margin Architecture
|
||||
|
||||
```
|
||||
客户端报价（Sell Rate）: 1,000 €/天
|
||||
│
|
||||
┌─────┴─────┐
|
||||
│ ESN Margin │
|
||||
│ 25-40% │
|
||||
└─────┬─────┘
|
||||
│
|
||||
顾问到手 TJM（Buy Rate）: 600-750 €/天
|
||||
```
|
||||
|
||||
**核心公式**：客户端报价 × (1 - ESN Margin) = 顾问 TJM
|
||||
- ESN 对顾问的购买价（Buy Rate / TJM brut）约是客户端报价的 60-75%
|
||||
- 换算：知道客户端预算即可反推顾问 TJM 区间
|
||||
|
||||
## How ESNs Make Money
|
||||
|
||||
ESN 赚取的是 **Margin = 客户端报价 - 顾问到手 TJM**
|
||||
|
||||
例：客户端 1,000€/天，ESN 付顾问 700€/天 → ESN 赚 300€/天（30% Margin）
|
||||
|
||||
### ESN 的实际成本结构（对客户端）
|
||||
- 顾问 TJM × 1.4~1.7 = 客户端报价（包含 ESN 管理成本 + 利润 + 风险溢价）
|
||||
- 超过 1.7 倍说明顾问费率偏低或 ESN 议价能力过强
|
||||
|
||||
## Negotiation Implications
|
||||
|
||||
1. **逆向反推**：若知道客户端预算，可反推顾问 TJM 区间
|
||||
2. **Tier 2 机会**：Tier 2 ESN 灵活性最高，Margin 25-40% 意味着顾问有更多谈判空间
|
||||
3. **Rate Floor 信号**：低于 550€/天的 Salesforce 架构师 TJM 对 ESN 传递绝望信号，永久锚定谈判起点
|
||||
4. **平台公开价**：Malt 等平台上的公开报价对 ESN 可见，成为市场参照锚点
|
||||
|
||||
## Key ESN Market Dynamics
|
||||
|
||||
- **NET-30 实际 = 60-90 天**：法国 ESN 链中付款延迟是结构性常态，顾问须预留现金流缓冲
|
||||
- **季节性**：1 月预算重启（最佳提案时机）、7-8 月暑期放缓、9 月秋季高峰
|
||||
- **续约博弈**：ESN 在续约时通常要求 TJM 持平或下调，顾问需有谈判策略
|
||||
|
||||
## Contradictions
|
||||
|
||||
- **Tier 1 稳定性 vs 低价**：大 ESN 提供稳定性但标准化定价，顾问往往被压价
|
||||
- **Tier 3 速度 vs 风险**：小经纪型 ESN 响应快但 Margin 压得狠，且付款风险更高
|
||||
|
||||
## Aliases
|
||||
- ESN
|
||||
- SSII（历史名称，Société de Services et d'Ingénierie en Informatique）
|
||||
- Cabinet de Conseil（咨询公司统称，但 ESN 特指 IT 领域）
|
||||
- Intégrateur（系统集成商）
|
||||
- Société de Services
|
||||
55
wiki/concepts/Gegenrede.md
Normal file
55
wiki/concepts/Gegenrede.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Gegenrede"
|
||||
type: concept
|
||||
tags: [knowledge-management, critical-thinking, zettelkasten, zk-steward]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Gegenrede（德语"反诘"或"反论"）是 [[zk-steward]] 链接提议流程中的辩证机制——在提议新笔记的候选链接后，提出一个来自**不同学科或视角**的反问，激发笔记间的辩证对话，防止同质化链接和思维茧房。
|
||||
|
||||
## Etymology
|
||||
Gegenrede = Gegen（相对/反对）+ Rede（话语/论述）→ 对立论述、反诘
|
||||
|
||||
这一概念源自德国学术传统中的辩证法（类似苏格拉底式反诘），在 [[Niklas-Luhmann]] 的 Zettelkasten 中被隐式使用——每条笔记不仅建立正向链接，还通过跨学科反问保持知识网络的辩证活性。
|
||||
|
||||
## How It Works in ZK Steward
|
||||
|
||||
在 [[Link-Proposer]] 流程中，Gegenrede 是第三步：
|
||||
|
||||
1. **候选链接**（Link Candidates）：提议 2-5 个相关笔记/概念链接
|
||||
2. **关键词/索引建议**（Keywords & Index Entries）：确保笔记可被找到
|
||||
3. **Gegenrede 反诘**：提出一个跨学科反问
|
||||
- "如果从经济学角度看这个问题会怎样？"
|
||||
- "反事实：如果没有这个因素，结论会改变吗？"
|
||||
- "这个观点的最大弱点是什么？"
|
||||
|
||||
## Purpose
|
||||
|
||||
| 防止的问题 | 达到的目标 |
|
||||
|---------|---------|
|
||||
| 同质化链接（只连观点一致的笔记） | 强制跨学科思考 |
|
||||
| 思维茧房（只听想听的声音） | 引入对立视角 |
|
||||
| 静态结论（笔记是终点而非起点） | 激发后续对话与迭代 |
|
||||
|
||||
## Example
|
||||
|
||||
新笔记提议链接到 `[[Product-Manager]]` 后：
|
||||
|
||||
> **Gegenrede**: 如果这个产品决策由一个纯经济学家视角驱动（成本效益最大化而非用户满意度），结论会有什么不同？这个视角是否遗漏了什么？
|
||||
|
||||
→ 这促使笔记作者主动思考产品管理的多元价值维度，而非单一路径依赖。
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 使用 Gegenrede 作为链接提议的一部分
|
||||
- [[Link-Proposer]] ← 包含 Gegenrede 步骤的工作流
|
||||
- [[Luhmann-四原则]] ← Gegenrede 服务于"持续对话"原则
|
||||
- [[Zettelkasten]] ← Gegenrede 是 Zettelkasten 辩证活性的体现
|
||||
- [[zk-steward-companion]] ← Gegenrede 作为可选 Skill 定义存在
|
||||
|
||||
## Aliases
|
||||
- 反诘
|
||||
- Counter-question
|
||||
- Socratic questioning
|
||||
- 辩证反问
|
||||
67
wiki/concepts/Grandes-Ecoles.md
Normal file
67
wiki/concepts/Grandes-Ecoles.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# Grandes Écoles
|
||||
|
||||
## Definition
|
||||
|
||||
Grandes Écoles（精英大学/大学校）——法国独有的精英高等教育体系，与公立大学（Université）并行，属于法国高等教育二元结构中的"精英"通道。源自拿破仑时期建立的专科学校体系，旨在为法国政府和企业培养高级人才。
|
||||
|
||||
## Tier Structure
|
||||
|
||||
### Tier 1: 最顶尖（历史最悠久、最难进入）
|
||||
| 学校 | 特色 |
|
||||
|------|------|
|
||||
| École Polytechnique（巴黎综合理工/X） | 科学与工程基础，强基研究导向 |
|
||||
| École Normale Supérieure（巴黎高师/ENS） | 文理基础研究，人文科学顶尖 |
|
||||
| ENA（已关闭，继承者：INSP） | 公共管理，法国高级公务员摇篮 |
|
||||
|
||||
### Tier 2: 商学院（Grande École de Commerce）
|
||||
- **HEC Paris**：欧洲排名第一商学院，MIM 项目（管理学硕士）
|
||||
- ESSEC Business School、ESCP Business School、EDHEC Business School
|
||||
- 申请方式：GMAT + 学术背景 + 面试
|
||||
|
||||
### Tier 3: 工程师学校（Grande École d'Ingénieur）
|
||||
- 覆盖各工程领域：机械、电子、核能、土木、计算机等
|
||||
- 认证：CTI（工程师职称委员会）认证保证教学质量
|
||||
|
||||
## Admission Pathways
|
||||
|
||||
### 法国学生路径
|
||||
1. **Concours（竞考）**：法国学生进入 Grande École 的主要方式，需在预科班（CPGE/MP2I/ECS 等）学习 2-3 年后参加统一竞考
|
||||
2. **Parcoursup**：部分学校通过法国公立高等教育申请系统招生
|
||||
|
||||
### 国际学生路径
|
||||
1. **直接申请**：顶尖学校（HEC、X、ENS）接受国际学生直接申请，通常需：
|
||||
- 优秀学术成绩（985/211 优先）
|
||||
- 法语 B2-C1 或英语授课项目（IELTS 7.0+）
|
||||
- GMAT/TAGE-MAGE（商学院）、GRE/法方笔试（工程师）
|
||||
- 面试
|
||||
2. **IFER/IPEP 预科**：部分学校设有国际学生预科项目
|
||||
3. **合作院校项目**：与国内 985/211 大学的双学位/交换项目
|
||||
|
||||
## Tuition & Cost
|
||||
|
||||
| 类型 | 学费范围 | 备注 |
|
||||
|------|----------|------|
|
||||
| 公立工程师学校 | 免学费（仅注册费约 500-800 欧/年） | 法国政府补贴 |
|
||||
| 私立商学院 | 1.5-4 万欧/年 | 部分有奖学金 |
|
||||
| 英语授课项目 | 通常高于法语项目 | 成本较高 |
|
||||
|
||||
## VS 英国/美国 System
|
||||
|
||||
| 维度 | Grandes Écoles | 英美精英大学 |
|
||||
|------|----------------|-------------|
|
||||
| 学制 | 5 年一贯制（工程师）或 2 年硕士 | 4 年本科 + 2-5 年研究生 |
|
||||
| 录取核心 | 竞考/学术竞争 | 全面评估（美）/学术+PS（英） |
|
||||
| 学费 | 公立学校免学费 | 学费较高（英国约 2-4 万磅/年） |
|
||||
| 校友网络 | 法国政商精英核心圈 | 英美各有强大校友网络 |
|
||||
| 知名度（国内） | 相对小众 | 普遍更高 |
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
[[study-abroad-advisor]] 在欧洲留学方向中，Grandes Écoles 是法国留学的核心选项。相比英美，公立 Grande École 的**免学费**政策使其成为高性价比的精英教育路径，尤其适合工科背景学生。关键挑战：法语能力要求（除非选择英语授课项目）+ 竞考体系对国际学生的壁垒。典型推荐：数学/物理/工程背景学生可考虑 Polytechnique（X）、索邦大学工程师项目。
|
||||
|
||||
## Aliases
|
||||
- 法国精英大学
|
||||
- 大学校
|
||||
- French Elite Universities
|
||||
- French Grande École System
|
||||
- 大学校体系
|
||||
37
wiki/concepts/Holistic-Admissions.md
Normal file
37
wiki/concepts/Holistic-Admissions.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Holistic Admissions
|
||||
|
||||
## Definition
|
||||
|
||||
全面评估录取模式（Holistic Admissions）——一种不依赖单一量化指标，而是综合考量申请者多维度素质的录取评估框架。最初由美国大学在 1970 年代引入，旨在超越单纯的分数排名，识别全面发展且能为校园社区做出独特贡献的学生。
|
||||
|
||||
## Core Dimensions
|
||||
|
||||
| 维度 | 评估内容 |
|
||||
|------|----------|
|
||||
| 学术表现 | GPA、课程难度、排名、标准化考试成绩 |
|
||||
| 课外活动 | 领导力、社区服务、社团、体育、艺术 |
|
||||
| 文书 | 个人叙事、成长故事、目标陈述 |
|
||||
| 推荐信 | 学术/职业能力的第三方评价 |
|
||||
| 独特背景 | 文化经历、社会经济背景、第一代大学生身份 |
|
||||
|
||||
## Countries & Institutions
|
||||
|
||||
- **美国**：哈佛、耶鲁、斯坦福等顶尖私立大学全面采用；UC 系统于 2021 年逐步取消 SAT/ACT 强制要求，进一步向全面评估倾斜
|
||||
- **英国**：本科以 UCAS 系统为主，Personal Statement 权重较高，但牛津/剑桥仍设笔试 + 面试
|
||||
- **加拿大**：部分学校（U of T、UBC）引入全面评估理念，但整体仍以学术成绩为核心
|
||||
- **澳大利亚/新西兰**：部分专业（医学、法学）采用全面评估
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **No single factor is dispositive** — 任何单一维度均不能单独决定录取结果
|
||||
2. **Context matters** — 评估时会考虑申请人所在学校、地区的教育资源差异
|
||||
3. **Fit over prestige** — 学校寻找与自身价值观和社区文化匹配的申请者
|
||||
4. **Institutional priorities** — 每所学校有不同的录取偏好（有些偏好体育特长生，有些偏好研究型学生）
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
Study Abroad Advisor 强调：申请美国顶尖大学的核心在于构建 coherent holistic profile——各维度之间需有逻辑一致性（core narrative arc），而非简单堆积活动。[[study-abroad-advisor]] 通过文书策略、背景提升规划、选校报告等手段帮助学生系统性地建立全面评估竞争力。
|
||||
|
||||
## Aliases
|
||||
- Holistic Review
|
||||
- 综合评估录取
|
||||
48
wiki/concepts/IANG-Visa.md
Normal file
48
wiki/concepts/IANG-Visa.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# IANG Visa
|
||||
|
||||
## Definition
|
||||
|
||||
IANG（Immigration Arrangement for Non-local Graduates，非本地毕业生留港就业安排）——香港特别行政区政府为在港修读经本地认证全日制课程的非本地毕业生提供的留港就业签证安排。
|
||||
|
||||
## Core Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 适用范围 | 在港修读经本地认证的全日制本地认可课程（学士/硕/博） |
|
||||
| 逗留期限 | 首次获批 12 个月，其后每次续签 3 年 |
|
||||
| 逗留条件 | 在港就业/创办业务（无最低薪资要求） |
|
||||
| 配额限制 | **无配额限制** |
|
||||
| 受养人 | 可携带配偶及 18 岁以下子女 |
|
||||
| 申请时间 | 毕业后 6 个月内可在港申请（无需提前找到工作） |
|
||||
|
||||
## Post-Study Work Pathway
|
||||
|
||||
```
|
||||
毕业 → 申请 IANG（毕业后6个月内）→ 首次12个月签证
|
||||
→ 就业/创业续签（每次3年）→ 7年连续居住 → 香港永久居民
|
||||
```
|
||||
|
||||
## Key Advantages for Chinese Students
|
||||
|
||||
1. **无需提前找到工作**——可在毕业前后申请，审批期间合法逗留
|
||||
2. **无配额上限**——相对英国 PSW、美国 OPT 的竞争性抽签，IANG 是确定性路径
|
||||
3. **家庭随行**——配偶及子女可获受养人签证，子女享香港教育资源
|
||||
4. **粤港澳大湾区机遇**——IANG 身份可同时享受大湾区政策支持
|
||||
5. **转永居路径清晰**——7 年连续合法逗留即可申请永居
|
||||
|
||||
## Key Considerations
|
||||
|
||||
- **续签必须实际在港就业/创业**——不可长期离港而不续签，否则断签
|
||||
- **受雇无需特定薪资门槛**，但申请永居时移民局会综合评估
|
||||
- iang 签证期间可换工作，无需通知入境处
|
||||
- iang 签证可在香港创办/加入 Startup 工作，符合条件可获额外逗留
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
[[study-abroad-advisor]] 在推荐香港留学时，IANG 是核心卖点之一。相比英国 PSW（需抽签）、美国 OPT（需 H-1B 抽签），IANG 的确定性使其成为注重留港发展/移民的学生的首选目的地。典型选校策略：香港大学（HKU）/香港中文大学（CUHK）/香港科技大学（HKUST）的一年制授课硕士 + IANG 续签，是高性价比的留港路径。
|
||||
|
||||
## Aliases
|
||||
- 非本地毕业生留港就业安排
|
||||
- Immigration Arrangement for Non-local Graduates
|
||||
- Hong Kong Post-Study Work Visa
|
||||
- 香港毕业生留港签证
|
||||
68
wiki/concepts/Link-Proposer.md
Normal file
68
wiki/concepts/Link-Proposer.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "Link-Proposer"
|
||||
type: concept
|
||||
tags: [knowledge-management, automation, zettelkasten, zk-steward]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Link-Proposer（链接提议器）是 [[zk-steward]] 在新笔记归档时自动运行的链接推荐流程——基于笔记内容，提议候选链接、关键词/索引入口，并运行 [[Gegenrede]] 反诘问题，确保新笔记融入知识网络而非孤立存在。
|
||||
|
||||
## When It Runs
|
||||
**触发条件**：ZK Steward 创建或归档新笔记时自动激活
|
||||
|
||||
**不触发条件**：
|
||||
- 更新现有笔记（非新笔记）
|
||||
- 仅检索/查询任务
|
||||
- 跳过归档步骤
|
||||
|
||||
## The Three Steps
|
||||
|
||||
### Step 1: Link Candidates（链接候选）
|
||||
基于笔记内容的语义分析，提议 2-5 个最相关的已有笔记/概念：
|
||||
- 直接关联笔记（同主题）
|
||||
- 方法论关联（同一框架）
|
||||
- 对比关联（相反观点）
|
||||
- 元关联（关于笔记本身的笔记）
|
||||
|
||||
### Step 2: Keyword & Index Suggestions（关键词/索引建议）
|
||||
- 提议 3-5 个关键词（用于未来检索）
|
||||
- 建议索引/MOC 条目（确保笔记有 ≥1 入口点）
|
||||
- 注意：索引是入口，不是分类——同一笔记可被多个索引指向
|
||||
|
||||
### Step 3: Gegenrede（反诘问题）
|
||||
提出一个跨学科反问，激发辩证对话：
|
||||
> "如果从 [另一领域] 角度看这个问题会怎样？"
|
||||
|
||||
详见 [[Gegenrede]]。
|
||||
|
||||
## Relationship to Luhmann 四原则
|
||||
|
||||
Link-Proposer 是 [[Luhmann-四原则]]中**连接性（Connectivity）**原则的自动化实现工具：
|
||||
|
||||
| 四原则 | Link-Proposer 贡献 |
|
||||
|--------|-----------------|
|
||||
| 原子性 | 新笔记若需链接多个主题 → 触发拆分建议 |
|
||||
| 连接性 | 直接提供 ≥2 链接候选 |
|
||||
| 有机增长 | 关键词/索引建议防止过度层级 |
|
||||
| 持续对话 | Gegenrede 激发后续思考 |
|
||||
|
||||
## Implementation
|
||||
|
||||
Link-Proposer 作为可选 Skill 定义在 [[zk-steward-companion]] 仓库中，可通过以下方式激活：
|
||||
1. 将 `skills/link-proposer/` 复制到 Agent 技能目录
|
||||
2. 在 ZK Steward 的归档流程中调用
|
||||
3. 人工审阅提议后选择性采纳
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 在归档流程中调用 Link-Proposer
|
||||
- [[Luhmann-四原则]] ← Link-Proposer 服务于连接性原则
|
||||
- [[Gegenrede]] ← Link-Proposer 的第三步
|
||||
- [[Zettelkasten]] ← Link-Proposer 是 Zettelkasten 链接机制的程序化
|
||||
- [[zk-steward-companion]] ← Link-Proposer 作为 Skill 定义存在
|
||||
|
||||
## Aliases
|
||||
- 链接提议器
|
||||
- Link Suggestion Engine
|
||||
- Note Linking Workflow
|
||||
57
wiki/concepts/Luhmann-四原则.md
Normal file
57
wiki/concepts/Luhmann-四原则.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Luhmann四原则"
|
||||
type: concept
|
||||
tags: [knowledge-management, validation, zettelkasten, zk-steward]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Luhmann 四原则是 [[zk-steward]] 的强制验证门（Validation Gate），每条笔记在归档前必须通过四个维度的检查，由 [[Niklas-Luhmann]] 的 Zettelkasten 方法论操作化提取而来。
|
||||
|
||||
## The Four Principles
|
||||
|
||||
| 原则 | 检查问题 | 含义 |
|
||||
|------|---------|------|
|
||||
| **Atomicity（原子性）** | Can it be understood alone? | 笔记独立可理解，无需依赖其他笔记上下文 |
|
||||
| **Connectivity（连接性）** | Are there ≥2 meaningful links? | 笔记必须与至少两个其他笔记建立有意义的链接 |
|
||||
| **Organic Growth（有机增长）** | Is over-structure avoided? | 避免过度层级结构；笔记网络自然生长而非强行分类 |
|
||||
| **Continued Dialogue（持续对话）** | Does it spark further thinking? | 笔记能激发进一步思考，而非终结话题 |
|
||||
|
||||
## Why Four Principles?
|
||||
|
||||
四个原则共同构成一个**验证漏斗**：
|
||||
- **原子性** → 保证最小粒度，避免"大而无当"的笔记
|
||||
- **连接性** → 保证网络密度，防止孤立笔记
|
||||
- **有机增长** → 防止"分类强迫症"，让知识自然涌现
|
||||
- **持续对话** → 保证知识活性，防止静态存储
|
||||
|
||||
## Relationship to Zettelkasten
|
||||
|
||||
[[Niklas-Luhmann]] 本人用一生实践验证了这四个原则——他的 90,000 张卡片笔记通过双向链接形成了一个有机知识网络，每张卡片都可独立理解，同时与其他卡片形成丰富对话。
|
||||
|
||||
[[zk-steward]] 将这四个原则程序化为：
|
||||
- 每条回复末尾的四原则检查表
|
||||
- 新笔记归档前的强制验证
|
||||
- 链接提议器（[[Link-Proposer]]）确保连接性
|
||||
- Gegenrede 反诘问题激发持续对话
|
||||
|
||||
## 与 AI Agent 质量标准的类比
|
||||
|
||||
| Luhmann 原则 | AI Agent 输出质量对应 |
|
||||
|-------------|-------------------|
|
||||
| 原子性 | 输出聚焦单一主题，不混杂 |
|
||||
| 连接性 | 输出引用/链接相关背景知识 |
|
||||
| 有机增长 | 避免过度预设分类框架 |
|
||||
| 持续对话 | 主动提出后续问题/开放循环 |
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 使用 Luhmann 四原则作为验证门
|
||||
- [[Zettelkasten]] ← Luhmann 四原则的来源方法论
|
||||
- [[Niklas-Luhmann]] ← Luhmann 四原则的提出者
|
||||
- [[Link-Proposer]] ← 保证连接性的工具，与四原则协同
|
||||
|
||||
## Aliases
|
||||
- 四原则验证门
|
||||
- Validation Gate
|
||||
- Luhmann Validation
|
||||
45
wiki/concepts/Nunchi.md
Normal file
45
wiki/concepts/Nunchi.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Nunchi"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **原文**：눈치（音：nunchi）
|
||||
- **中文**：读心术 / 察言观色 / 情境感知
|
||||
- **字面意**： 눈（眼睛）+ 치（速度/程度）= 读懂气氛的能力
|
||||
|
||||
## 定义
|
||||
Nunchi 是韩国文化的核心社交技能，指通过**观察他人的情绪状态、语境线索和行为模式**，在对方不直接表达的情况下理解其真实意图。在韩国商业环境中，Nunchi 是建立信任、避免尴尬、推进关系的关键能力。
|
||||
|
||||
## Nunchi 解码表（Korean Business Context）
|
||||
|
||||
| 韩国人说（韩文） | 字面意思（英文） | 实际含义 | 应对策略 |
|
||||
|----------------|----------------|---------|---------|
|
||||
| 좋은데요... | "That's nice, but..." | 犹豫，有未表达的顾虑 | "어떤 부분이 고민이신가요?"（哪部分让您顾虑？） |
|
||||
| 검토해보겠습니다 | "We'll review it" | **婉拒**，给你一个体面退场 | 等待 5 天后若无跟进则放弃，优雅离开 |
|
||||
| 긍정적으로 검토하겠습니다 | "We'll review positively" | **真正感兴趣**，内部流程启动 | 主动发送支持材料 |
|
||||
| 어려울 것 같습니다 | "It seems difficult" | **坚定拒绝** | 优雅接受："다음에 기회가 되면 연락 주세요" |
|
||||
| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在此人，品의流程已触发 | 积极信号：提供一切内部说服所需材料 |
|
||||
| 바쁘시죠? | "You must be busy, right?" | 社交润滑，即将有请求 | 回复："괜찮습니다, 말씀하세요"（我没事，请说） |
|
||||
|
||||
## 为什么 Nunchi 对外国人困难
|
||||
西方商业文化强调**直接沟通**——对"不"使用明确的语言表达。韩国文化强调**和谐优先于清晰**——直接说"不"会损害关系和对方的颜面。因此：
|
||||
- "We'll review it" ≠ "Maybe later"
|
||||
- "It's difficult" = "No"
|
||||
- 沉默（3-7天）≠ "We're not interested"
|
||||
- "Let me think about it" = "I need Nunchi time to read the room internally"
|
||||
|
||||
## Nunchi 的实际应用场景
|
||||
1. **会议中**：观察谁的眼神在谁之间移动，判断真正的决策者
|
||||
2. **聚餐（회식）**：观察谁给谁倒酒，判断公司内部权力动态
|
||||
3. **跟进时**：判断"沉默"是积极的品의进行中，还是消极的死单
|
||||
4. **谈判中**：读懂对方真正顾虑（价格？风险？信任？），而非其表面陈述
|
||||
|
||||
## 与品의的关系
|
||||
Nunchi 是理解 품의 流程中**隐性信号**的核心技能——审批链在内部运行，供应商看不到过程，只能通过 Nunchi 解读外部表现出的信号。
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — Nunchi Decoder — Business Context 完整规范
|
||||
72
wiki/concepts/Portage-Salarial.md
Normal file
72
wiki/concepts/Portage-Salarial.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "Portage Salarial"
|
||||
type: concept
|
||||
tags: [france, freelancing, employment, social-protection]
|
||||
sources: [specialized-french-consulting-market]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Portage Salarial 是法国特有的**劳动合同外包机制**——独立顾问（consultant）与一家 Portage 公司签署劳动合同，Portage 公司再以服务合同向客户企业开具发票。顾问名义上保持雇员身份，享受社会保险，但实质上**承担全部商业风险**（自寻客户、自定费率、无工作保障）。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **法律框架**：劳动合同（CDI/CDD）+ 服务合同（Convention de Portage）
|
||||
- **Portage 公司收费**：管理费 5-10%（按营业额计算）
|
||||
- **社保缴费结构**：
|
||||
- 雇主缴费（Charges Patronales）：约 45%（含养老金、健康保险、失业保险等）
|
||||
- 雇员缴费（Charges Salariales）：约 22%
|
||||
- 合计约 67% 的 TJM 毛收入用于社保缴费
|
||||
|
||||
## Cost Breakdown Example
|
||||
|
||||
以 700€/天 TJM 计算：
|
||||
|
||||
```
|
||||
TJM Brut: 700 €/天
|
||||
每月（18天）: 12,600 €/月
|
||||
Portage 管理费(10%): -1,260 €/月
|
||||
雇主社保(45%): -5,103 €/月
|
||||
雇员社保(22%): -2,495 €/月
|
||||
─────────────
|
||||
税前净收入: 3,742 €/月
|
||||
实际日净费率: 208 €/天
|
||||
```
|
||||
|
||||
对比 Micro-Entrepreneur（同为 700€/天）：
|
||||
|
||||
```
|
||||
税前净收入: 9,828 €/月
|
||||
实际日净费率: 546 €/天
|
||||
```
|
||||
|
||||
**差距：338€/天**——这是社保保护（ARE 失业保险、退休金补充、Mutuelle 医疗保险）的价格。
|
||||
|
||||
## What Portage Provides
|
||||
|
||||
| 权益 | Portage | Micro-Entrepreneur |
|
||||
|------|---------|-------------------|
|
||||
| 失业保险（ARE） | ✅ | ❌ |
|
||||
| 退休金补充 | ✅ | ❌ |
|
||||
| Mutuelle 医疗保险 | ✅（公司部分） | ❌ |
|
||||
| 病假/产假 | ✅ | ❌ |
|
||||
| 商业风险自担 | ✅ | ✅ |
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Portage ≠ 就业**：本质上是"披着雇员外衣的自由职业"，永远不要将 Portage 合同呈现为 CDI 等价物
|
||||
2. **平台选择**：Portage 公司间管理费和服务质量差异很大，需比较（APE、Winference等主流供应商）
|
||||
3. **单一客户依赖风险**：URSSAF 规定单一客户占总收入 >70% 触发审计风险
|
||||
4. **定价公开性**：若通过 collective.work 等平台接单，费率可能对平台可见
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 与 [[Micro-Entrepreneur]]：Portage 净得率低（~50%）但提供完整社保；Micro 净得率高（~70%）但无社保保护
|
||||
- **市场误解**：许多新从业者认为 Portage"更安全"——实际上顾问承担全部商业风险（客户拒付、项目取消），只是法律上被认定为雇员
|
||||
|
||||
## Aliases
|
||||
- Portage
|
||||
- Portage Salarial
|
||||
- Société de Portage
|
||||
- Entreprise de Portage Salarial
|
||||
46
wiki/concepts/UCAS-System.md
Normal file
46
wiki/concepts/UCAS-System.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# UCAS System
|
||||
|
||||
## Definition
|
||||
|
||||
UCAS（Universities and Colleges Admissions Service）——英国高等教育统一申请系统，所有英国本科课程（包括牛津、剑桥）均须通过 UCAS 提交申请。系统每年 9 月开放，次年 1 月截止（部分医学专业 10 月截止）。
|
||||
|
||||
## Key Mechanics
|
||||
|
||||
### Timeline
|
||||
- **9 月初**：系统开放，可同时申请最多 **5 所**英国大学（牛剑不可兼报，只能二选一或申请其他）
|
||||
- **10 月 15 日**（医学/牙科/兽医）：早期截止
|
||||
- **1 月 29 日**：标准截止日期（英国时间 18:00）
|
||||
- **次年 5-7 月**：补录（Clearing）阶段，未满专业开放申请
|
||||
|
||||
### Personal Statement
|
||||
- **4,000 字符上限**（约 500-800 词），含空格和空行
|
||||
- **80% 必须聚焦学术内容和动机**
|
||||
- 只能提交一份 Personal Statement，适用于所有申请的 5 所学校
|
||||
- 内容结构建议：学术兴趣起源 → 课外相关经历 → 职业目标与选校理由
|
||||
|
||||
### Reference
|
||||
- 由学校顾问（School Reference）或 UCAS 注册的推荐人提交
|
||||
- 2024 年起引入 Reference 预填（Reference Pre-fill）功能
|
||||
|
||||
### Offers
|
||||
- 收到所有申请结果后须在 **5 月初** 前回复firm acceptance 和 insurance choice
|
||||
- 条件通常包括：A-Level/IB 成绩要求、语言成绩要求
|
||||
|
||||
## UK vs US Comparison
|
||||
|
||||
| 维度 | UCAS（英国） | Common App（美国） |
|
||||
|------|-------------|------------------|
|
||||
| 学校数量 | 最多 5 所 | 无限制（每所单独提交） |
|
||||
| 文书数量 | 1 篇，所有学校共用 | 每所可选提交独立文书 |
|
||||
| 文书重点 | 80% 学术，20% 课外 | 个人叙事，全面发展 |
|
||||
| 截止日期 | 相对集中（1月29日） | 分散（EA/ED 11月，RD 1-2月） |
|
||||
| 录取因素 | 学术为主+A-Level/IB 成绩 | 全面评估（GPA+活动+文书+推荐） |
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
[[study-abroad-advisor]] 在处理英美联申（US+UK）时，特别强调 UCAS Personal Statement 的独特性——必须在单一文本中同时满足 5 所学校的期望，且无法针对各校单独定制。解决方案：围绕**学术核心叙事**构建，辅以 1-2 个相关课外活动，确保内容在不同学校语境下均具说服力。
|
||||
|
||||
## Aliases
|
||||
- UCAS Undergraduate
|
||||
- 英国本科申请系统
|
||||
- Universities and Colleges Admissions Service
|
||||
50
wiki/concepts/Zettelkasten.md
Normal file
50
wiki/concepts/Zettelkasten.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Zettelkasten"
|
||||
type: concept
|
||||
tags: [knowledge-management, note-taking, luhmann, zk-steward]
|
||||
sources: [zk-steward, 养虾日记3]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Zettelkasten（德语"卡片盒"）是一种由德国社会学家 [[Niklas-Luhmann]] 发明的知识管理方法论。其核心理念：**知识通过积累和链接自然生长，而非通过分类存储**。
|
||||
|
||||
## Core Principles
|
||||
1. **Atomic notes**：每条笔记只包含一个想法，最小粒度，可独立理解
|
||||
2. **Unique IDs**：每张卡片拥有唯一标识符，用于精确引用
|
||||
3. **Bidirectional links**：笔记之间双向链接，形成网络而非树
|
||||
4. **Emergence over taxonomy**：知识从链接中涌现，而非从分类中获得
|
||||
5. **Entry points via indices**：索引是入口点，不是分类；一张笔记可被多个索引指向
|
||||
|
||||
## How Zettelkasten Relates to AI
|
||||
|
||||
### Karpathy's LLM Wiki
|
||||
[[养虾日记3]] 提到"融合了 Karpathy 的 LLM Wiki 理念"，即：用 LLM 替代手写卡片，构建自动化的 Zettelkasten 系统——AI 增量构建 Wiki，页面间互链，知识越积越厚。
|
||||
|
||||
### ZK Steward
|
||||
[[zk-steward]] 是 Zettelkasten 的 AI Agent 实现：
|
||||
- 原子笔记 → AI 驱动的验证门（[[Luhmann-四原则]]）
|
||||
- 双向链接 → [[Link-Proposer]] 自动提议
|
||||
- 时间路径归档 → `YYYY/MM/YYYYMMDD/` 格式
|
||||
- 索引入口 → 强制每个笔记有 ≥1 索引条目
|
||||
|
||||
## Zettelkasten vs Traditional Note-taking
|
||||
|
||||
| 维度 | Zettelkasten | 传统笔记（文件夹/标签） |
|
||||
|------|--------------|---------------------|
|
||||
| 结构 | 网络 | 层级树 |
|
||||
| 链接 | 双向，可发现反向关系 | 单向，无反向发现 |
|
||||
| 新笔记 | 链接到已有笔记，生长网络 | 归档到分类，可能孤立 |
|
||||
| 知识发现 | 从链接涌现 | 从分类查找 |
|
||||
| AI 化难度 | 高（需要链接推理） | 低（直接分类） |
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← AI 时代的 Zettelkasten 实现
|
||||
- [[Niklas-Luhmann]] ← Zettelkasten 发明者
|
||||
- [[Luhmann-四原则]] ← [[zk-steward]] 对 Zettelkasten 的操作化提取
|
||||
- [[Second-Brain]] ← 相关的外部认知能力概念；Zettelkasten 是其方法论之一
|
||||
|
||||
## Aliases
|
||||
- 卡片盒
|
||||
- 卢曼笔记法
|
||||
- 原子笔记系统
|
||||
54
wiki/concepts/품의.md
Normal file
54
wiki/concepts/품의.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "품의"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **原文**：품의（品意）
|
||||
- **英文**：Consensus Approval / Internal Review Process
|
||||
- **中文**：共识审批流程
|
||||
- **发音**：pum-ui
|
||||
|
||||
## 定义
|
||||
품의（품의서）是韩国企业决策的核心机制，指在正式批准之前需要经过多层级的内部讨论和共识达成。与西方"经理点头即可决策"不同，韩国商业决策需要通过**完整审批链（결재 라인）**的层层确认。
|
||||
|
||||
## 品의 六阶段时间线
|
||||
|
||||
| 阶段 | 韩文 | 持续时间 | 供应商角色 | 积极信号 |
|
||||
|------|------|----------|-----------|---------|
|
||||
| 介绍 | 소개 | 1-2 周 | 通过介绍人正确接入 | 有影响力的介绍人 |
|
||||
| 会议 | 미팅 | 1-3 次会议 | 多听少说，了解挑战 | 邀请同事参加第二会议 |
|
||||
| 内部审查 | 내부검토 | 2-4 周 | 提供可内部传阅的材料 | 索取参考案例 |
|
||||
| 审批文件 | 품의서 | 1-2 周 | 无法影响（联系人撰写） | 询问具体价格/范围/时间 |
|
||||
| 审批链 | 결재 | 1-3 周 | 等待，每周不超一次跟进 | "상부에서 검토 중입니다" |
|
||||
| 合同 | 계약 | 1-2 周 | 法律审查，印章（도장）执行 | 标准阶段 |
|
||||
|
||||
## 品의 时间对比
|
||||
|
||||
| 公司类型 | 品의耗时 | 建议跟进频率 |
|
||||
|---------|---------|------------|
|
||||
| SME（中小企业） | 6-10 周 | 每周 |
|
||||
| 中型企业 | 8-12 周 | 每两周 |
|
||||
| 财阀（Chaebol） | 12-16 周 | 每月 |
|
||||
|
||||
西方思维：会议 → 提案 → 决策 → 合同（2-4 周）
|
||||
韩国现实：紹介 → 会议 → 内部审查 → 品의서 → 결재라인 → 合同（6-16 周）
|
||||
|
||||
## 关键原则
|
||||
1. **永远不要在第一次会议要求时间线**——等于暴露无知
|
||||
2. **永远不要绕过联系人直接联系其上级**——越级是关系终结行为
|
||||
3. **品의서 文件供应商无法看到或影响**——联系人自行撰写
|
||||
4. **沉默（3-7 天）不等于拒绝**——通常是内部讨论在进行
|
||||
5. **"상부에서 검토 중입니다"（上级正在审查）是积极信号**——意味着在推进
|
||||
|
||||
## Aliases
|
||||
- 품의서（审批文件）
|
||||
- 결재 라인（审批链）
|
||||
- Consensus Approval
|
||||
- 내부검토（内部审查）
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 完整规范
|
||||
45
wiki/entities/KakaoTalk.md
Normal file
45
wiki/entities/KakaoTalk.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "KakaoTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **类型**：产品 / 通讯平台
|
||||
- **原文**：카카오톡（KakaoTalk）
|
||||
- **中文**：韩国版微信 / 连我
|
||||
- **运营公司**：Kakao Corp（카카오），韩国最大互联网平台之一
|
||||
- **用户规模**：截至 2024 年月活跃用户超 5000 万（韩国总人口约 5100 万）
|
||||
|
||||
## 在韩国商务中的地位
|
||||
KakaoTalk 是韩国商务沟通的**核心渠道**，相当于中国商务场景中的微信。韩国专业人士将 KakaoTalk 视为半正式的商务工具，其使用方式直接影响商业关系的建立和维护。
|
||||
|
||||
## 商务使用规范
|
||||
|
||||
### 关系阶段与消息模板
|
||||
1. **初次接触（正式）**：必须通过介绍人引荐，消息使用完整正式语气，包含自我介绍和咖啡邀约
|
||||
2. **已建立关系（半正式）**：寒暄+信息+请求，结尾用礼貌语
|
||||
3. **信任建立后**：可直接消息，允许表情符号，但不过量
|
||||
|
||||
### 关键规则
|
||||
- **群聊必须韩语**：即使不完美也显示尊重；英语在韩国群聊中等于"我期待你迁就我"
|
||||
- **回复时间**：紧急事务同一工作日内；非紧急次日回复可接受
|
||||
- **已读回执可见**：超过 24 小时只读不回会被注意到
|
||||
- **语音消息**：仅在关系已支持非正式沟通时使用
|
||||
- **表情/贴纸**：信任建立后谨慎使用；初次接触绝对禁用
|
||||
- **商务时间**：9 AM - 7 PM KST；该时间外发送可接受但不要期待即时回复
|
||||
|
||||
### 禁忌
|
||||
- 不要在 KakaoTalk 上直接谈报价（价格谈判应在线下或当面）
|
||||
- 不要发送长篇大论的自我介绍（韩国人不会在手机上阅读长文本）
|
||||
- 不要用 KakaoTalk 发送正式合同文件（用邮件）
|
||||
|
||||
## Aliases
|
||||
- 카카오톡
|
||||
- Kakao
|
||||
- 韩国版微信
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — KakaoTalk Business Communication Guide 完整规范
|
||||
36
wiki/entities/Niklas-Luhmann.md
Normal file
36
wiki/entities/Niklas-Luhmann.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Niklas Luhmann"
|
||||
type: entity
|
||||
tags: [knowledge-management, sociologist, zettelkasten]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Full name**: Niklas Luhmann（尼克拉斯·卢曼）
|
||||
- **Born/Died**: 1927–1998
|
||||
- **Nationality**: German
|
||||
- **Profession**: Sociologist, systems theorist
|
||||
- **Affiliation**: University of Bielefeld
|
||||
|
||||
## Legacy
|
||||
Niklas Luhmann 是德国社会学家和系统理论家，以其独创的 **Zettelkasten**（卡片盒）知识管理方法论闻名一生。凭借 Zettelkasten，他在一生中：
|
||||
- 积累了 **90,000+ 张卡片笔记**
|
||||
- 产出了 **70 部著作** 和数百篇学术论文
|
||||
- 跨越社会学、法学、政治学、组织理论等多个领域
|
||||
|
||||
他的 Zettelkasten 系统的核心理念：**知识不是分类存储的，而是通过链接有机生长的**。每张卡片拥有唯一 ID，通过与其他卡片建立连接形成知识网络，而非传统的层级文件夹结构。
|
||||
|
||||
## Key Contributions
|
||||
- **Zettelkasten Method**：手动的原子笔记+双向链接系统，是 [[zk-steward]] 的方法论基础
|
||||
- **Systems Theory**（社会系统论）：将社会理解为自我生产的系统（autopoietic systems）
|
||||
- **Two-level communication model**：媒体/形式（medium/form）理论，影响设计思维
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 基于 [[Niklas-Luhmann]] 的 Zettelkasten 方法论构建
|
||||
- [[Zettelkasten]] ← 由 [[Niklas-Luhmann]] 发明并实践
|
||||
- [[Luhmann-四原则]] ← [[zk-steward]] 对 [[Niklas-Luhmann]] 四原则的提取与 AI 化
|
||||
|
||||
## Aliases
|
||||
- Luhmann
|
||||
- N. Luhmann
|
||||
@@ -1,37 +1,76 @@
|
||||
---
|
||||
title: "The Agency"
|
||||
type: entity
|
||||
tags: [multi-agent, organization, specialized]
|
||||
sources: [lsp-index-engineer, corporate-training-designer, specialized-cultural-intelligence-strategist, specialized-model-qa, specialized-workflow-architect]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
# The Agency
|
||||
|
||||
## Definition
|
||||
|
||||
The Agency 是一个多智能体（Multi-Agent）系统组织框架，提供 147 个专业化 Agent，跨 12 个业务部门，覆盖工程（Engineering）、设计（Design）、金融（Finance）、游戏开发（Game Dev）、营销（Marketing）、付费媒体（Paid Media）、产品（Product）、项目管理（Project Management）、测试（Testing）、支持（Support）、空间计算（Spatial Computing）和专业化（Specialized）。
|
||||
The Agency 是一个由 AI 编码代理（agent）驱动的多智能体开发系统，提供 **147 个专业化 Agent** 跨 **12 个业务部门**运作，涵盖 Engineering、Design、Finance、Game Dev、Marketing、Paid Media、Product、Project Management、Testing、Support、Spatial Computing、Specialized 等领域。
|
||||
|
||||
## Key Characteristics
|
||||
## Organizational Structure
|
||||
|
||||
- **Agent 设计五原则**：鲜明性格（拒绝通用人设）、明确交付物（真实代码/模板）、可量化指标、经过验证的工作流、学习记忆机制
|
||||
- **协作模式**：Agent 间通过交接合同（Handoff Contract）进行确定性状态传递
|
||||
- **Specialized 部门**：包含 9 个专业化 Agent（见下方列表），专注于特定领域的深度专业知识
|
||||
```
|
||||
The Agency
|
||||
├── Engineering（工程部门）
|
||||
├── Design（设计部门）
|
||||
│ ├── UI Designer
|
||||
│ ├── Brand Guardian
|
||||
│ ├── Visual Storyteller
|
||||
│ ├── UX Researcher
|
||||
│ ├── Image Prompt Engineer
|
||||
│ ├── Inclusive Visuals Specialist
|
||||
│ └── Whimsy Injector
|
||||
├── Finance（财务部门）
|
||||
├── Game Dev（游戏开发部门）
|
||||
├── Marketing（市场营销部门）
|
||||
├── Paid Media（付费媒体部门）
|
||||
├── Product（产品部门）
|
||||
├── Project Management（项目管理部门）
|
||||
├── Testing（测试部门）
|
||||
├── Support（支持部门）
|
||||
├── Spatial Computing（空间计算部门）
|
||||
│ ├── XR Interface Architect
|
||||
│ ├── XR Immersive Developer
|
||||
│ ├── XR Cockpit Interaction Specialist
|
||||
│ ├── visionOS Spatial Engineer
|
||||
│ └── macOS Spatial/Metal Engineer
|
||||
└── Specialized（专业部门）
|
||||
├── Study Abroad Advisor
|
||||
├── Agents Orchestrator
|
||||
├── Identity Graph Operator
|
||||
├── MCP Builder Agent
|
||||
├── Agentic Identity & Trust Architect
|
||||
├── Civil Engineer
|
||||
├── Document Generator
|
||||
├── Government Digital Presales Consultant
|
||||
├── Healthcare Marketing Compliance Specialist
|
||||
├── Compliance Auditor
|
||||
├── Workflow Architect
|
||||
├── Corporate Training Designer
|
||||
├── Cultural Intelligence Strategist
|
||||
├── Model QA Specialist
|
||||
└── LSP/Index Engineer
|
||||
```
|
||||
|
||||
## Agent Collaboration Protocol
|
||||
## Core Design Principles
|
||||
|
||||
标准协作链：Reality Checker 验证 → Backend Architect 实现 → API Tester 生成测试用例 → DevOps Automator 验证清理顺序。Workflow Architect 在此体系中提供工作流建模能力，LSP/Index Engineer 提供代码语义基础设施。
|
||||
1. **鲜明性格**（拒绝通用人设）——每个 Agent 拥有明确的专业边界和独特性格
|
||||
2. **明确交付物**（真实代码/模板）——每个 Agent 的输出可量化、可验证
|
||||
3. **可量化指标**——每个 Agent 定义明确的成功指标
|
||||
4. **经过验证的工作流**——Agent 行为遵循经过测试的工作流程
|
||||
5. **学习记忆机制**——Agent 具备上下文记忆和自我改进能力
|
||||
|
||||
## Specialized Department Agents
|
||||
## Contribution Model
|
||||
|
||||
1. **LSP/Index Engineer** — LSP 客户端编排和语义索引基础设施专家
|
||||
2. **Model QA Specialist** — ML/统计模型的端到端独立审计专家
|
||||
3. **Corporate Training Designer** — 企业培训体系架构师
|
||||
4. **Cultural Intelligence Strategist** — 文化包容性专家
|
||||
5. **Workflow Architect** — 工作流设计专家
|
||||
6. **Identity & Trust Architect** — Agentic 身份与信任架构专家
|
||||
7. **Automation Governance Architect** — 自动化治理架构师
|
||||
8. **Government Digital Presales Consultant** — 政府数字化售前顾问
|
||||
9. **Document Generator Agent** — 文档生成 Agent
|
||||
The Agency 接受外部贡献，核心方式：
|
||||
- 创建全新智能体（8 大分类）
|
||||
- 优化现有智能体
|
||||
- 分享成功案例
|
||||
- 反馈问题
|
||||
|
||||
## Value
|
||||
详见 [[contributing_zh-cn]] 和 [[contributing]]（英文原版）。
|
||||
|
||||
The Agency 的核心价值在于将复杂任务分解为专业化 Agent 协作，每个 Agent 拥有鲜明的人设、明确的交付物和可量化的成功指标，避免了通用 LLM 的"万事通但样样松"问题。
|
||||
## Relationship to Multi-Agent Reliability
|
||||
|
||||
The Agency 是 [[multi-agent-system-reliability]] 理论的最佳实践场域——通过 Agent 间协作模式（Orchestration、Consensus Voting、Adversarial Debate、Knock-out）实现系统级可靠性。[[identity-graph-operator]] 解决 Agent 间身份一致性问题，[[agentic-identity-trust]] 解决 Agent 间信任与授权问题，共同构成完整的多智能体基础设施。
|
||||
|
||||
## Aliases
|
||||
- The Agency Multi-Agent System
|
||||
- Agency Agents
|
||||
|
||||
34
wiki/entities/zk-steward-companion.md
Normal file
34
wiki/entities/zk-steward-companion.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "zk-steward-companion"
|
||||
type: entity
|
||||
tags: [github, knowledge-management, zettelkasten, skills]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Type**: GitHub Repository
|
||||
- **URL**: github.com/mikonos/zk-steward-companion
|
||||
- **Purpose**: ZK Steward Agent 的配套技能库，提供可选工作流扩展
|
||||
|
||||
## Overview
|
||||
zk-steward-companion 是 [[zk-steward]] 的 GitHub 配套仓库，包含 Cursor/Claude Code 兼容的 Skill 定义文件，可直接复制到项目的 `.cursor/skills/` 或对应 Agent 技能目录中使用。
|
||||
|
||||
## Included Skills
|
||||
|
||||
| Skill | Purpose |
|
||||
|-------|---------|
|
||||
| **Link-proposer** | 新笔记链接提议：候选链接 + 关键词 + Gegenrede 反诘 |
|
||||
| **Index-note** | 创建/更新索引/MOC 条目；每日扫荡孤立笔记 |
|
||||
| **Strategic-advisor** | 默认意图不明确时：多视角分析 + 权衡 + 行动选项 |
|
||||
| **Workflow-audit** | 多阶段流程完成度检查（Luhmann 四原则/归档/日志） |
|
||||
| **Structure-note** | 阅读顺序与逻辑树；Folgezettel 风格论证链 |
|
||||
| **Random-walk** | 知识网络随机游走；支持 tension/forgotten/island 模式 |
|
||||
| **Deep-learning** | 深度阅读全流程（书/长文/报告/论文）：structure + atomic + method notes；Adler/Feynman/Luhmann/Critics 四视角 |
|
||||
|
||||
## Usage
|
||||
Clone 或复制 `skills/` 文件夹到项目（如 `.cursor/skills/`），并根据 vault 路径调整配置，即获得完整的 ZK Steward 工作流扩展。
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← 使用 [[zk-steward-companion]] 中的可选技能扩展
|
||||
- [[zk-steward]] ← 核心 Agent，由 Cursor rule set 抽象而来
|
||||
@@ -4,6 +4,11 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-25] [Supply Chain Strategist Agent](sources/supply-chain-strategist.md)
|
||||
- [2026-04-25] [ZK Steward Agent](sources/zk-steward.md)
|
||||
- [2026-04-25] [Korean Business Navigator](sources/specialized-korean-business-navigator.md)
|
||||
- [2026-04-25] [French Consulting Market Navigator](sources/specialized-french-consulting-market.md)
|
||||
- [2026-04-25] [Blockchain Security Auditor](sources/blockchain-security-auditor.md)
|
||||
- [2026-04-25] [Sales Data Extraction Agent](sources/sales-data-extraction-agent.md)
|
||||
- [2026-04-25] [Study Abroad Advisor](sources/study-abroad-advisor.md)
|
||||
- [2026-04-25] [Agents Orchestrator](sources/agents-orchestrator.md)
|
||||
@@ -407,16 +412,11 @@
|
||||
- [2026-04-20] [specialized-developer-advocate](sources/specialized-developer-advocate.md) — (expected: wiki/sources/specialized-developer-advocate.md — source missing)
|
||||
- [2026-04-20] [report-distribution-agent](sources/report-distribution-agent.md) — (expected: wiki/sources/report-distribution-agent.md — source missing)
|
||||
- [2026-04-20] [data-consolidation-agent](sources/data-consolidation-agent.md) — (expected: wiki/sources/data-consolidation-agent.md — source missing)
|
||||
- [2026-04-20] [supply-chain-strategist](sources/supply-chain-strategist.md) — (expected: wiki/sources/supply-chain-strategist.md — source missing)
|
||||
- [2026-04-20] [specialized-korean-business-navigator](sources/specialized-korean-business-navigator.md) — (expected: wiki/sources/specialized-korean-business-navigator.md — source missing)
|
||||
- [2026-04-20] [specialized-french-consulting-market](sources/specialized-french-consulting-market.md) — (expected: wiki/sources/specialized-french-consulting-market.md — source missing)
|
||||
- [2026-04-20] [blockchain-security-auditor](sources/blockchain-security-auditor.md) — 智能合约安全审计 Agent，专职发现 DeFi 协议漏洞并提供可复现 PoC
|
||||
- [2026-04-20] [automation-governance-architect](sources/automation-governance-architect.md) — (expected: wiki/sources/automation-governance-architect.md — source missing)
|
||||
- [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
|
||||
- [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
- [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing)
|
||||
- [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing)
|
||||
- [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing)
|
||||
@@ -582,7 +582,6 @@
|
||||
- [bottom](entities/bottom.md)
|
||||
- [Brendan-Starnig](entities/Brendan-Starnig.md)
|
||||
- [btop++](entities/btop++.md)
|
||||
- [Curve-Finance](entities/Curve-Finance.md)
|
||||
- [Caddy](entities/Caddy.md)
|
||||
- [cAdvisor](entities/cAdvisor.md)
|
||||
- [Calibre](entities/Calibre.md)
|
||||
@@ -606,6 +605,7 @@
|
||||
- [containerd](entities/containerd.md)
|
||||
- [Coze](entities/Coze.md)
|
||||
- [Cursor](entities/Cursor.md)
|
||||
- [Curve-Finance](entities/Curve-Finance.md)
|
||||
- [DanielStefanovic](entities/DanielStefanovic.md)
|
||||
- [DeepLearningAI](entities/DeepLearningAI.md)
|
||||
- [DeepSeek](entities/DeepSeek.md)
|
||||
@@ -625,8 +625,8 @@
|
||||
- [DracoVibeCoding](entities/DracoVibeCoding.md)
|
||||
- [DXC-VSM](entities/DXC-VSM.md)
|
||||
- [DXY](entities/DXY.md)
|
||||
- [Euler-Finance](entities/Euler-Finance.md)
|
||||
- [EESJGong](entities/EESJGong.md)
|
||||
- [Euler-Finance](entities/Euler-Finance.md)
|
||||
- [Eurocode](entities/Eurocode.md)
|
||||
- [fireworks-tech-graph](entities/fireworks-tech-graph.md)
|
||||
- [Flux](entities/Flux.md)
|
||||
@@ -666,6 +666,7 @@
|
||||
- [JohnWilliams](entities/JohnWilliams.md)
|
||||
- [K3s](entities/K3s.md)
|
||||
- [KAI](entities/KAI.md)
|
||||
- [KakaoTalk](entities/KakaoTalk.md)
|
||||
- [kepano](entities/kepano.md)
|
||||
- [KoolCenter固件服务器](entities/KoolCenter固件服务器.md)
|
||||
- [Kubernetes](entities/Kubernetes.md)
|
||||
@@ -701,11 +702,12 @@
|
||||
- [NetApp](entities/NetApp.md)
|
||||
- [Netdata](entities/Netdata.md)
|
||||
- [NicholasCarlini](entities/NicholasCarlini.md)
|
||||
- [Niklas-Luhmann](entities/Niklas-Luhmann.md)
|
||||
- [NMPA](entities/NMPA.md)
|
||||
- [Nomad-Bridge](entities/Nomad-Bridge.md)
|
||||
- [node-exporter](entities/node-exporter.md)
|
||||
- [Node.js](entities/Node.js.md)
|
||||
- [nodewarden](entities/nodewarden.md)
|
||||
- [Nomad-Bridge](entities/Nomad-Bridge.md)
|
||||
- [NotebookLlama](entities/NotebookLlama.md)
|
||||
- [NotebookLM](entities/NotebookLM.md)
|
||||
- [Obsidian](entities/Obsidian.md)
|
||||
@@ -789,6 +791,7 @@
|
||||
- [XR-Interface-Architect](entities/XR-Interface-Architect.md)
|
||||
- [YishenTu](entities/YishenTu.md)
|
||||
- [Zipline](entities/Zipline.md)
|
||||
- [zk-steward-companion](entities/zk-steward-companion.md)
|
||||
- [余梦珑](entities/余梦珑.md)
|
||||
- [剪映](entities/剪映.md)
|
||||
- [机场](entities/机场.md)
|
||||
@@ -951,6 +954,7 @@
|
||||
- [Custom-Audience-Engineering](concepts/Custom-Audience-Engineering.md)
|
||||
- [Custom-Instructions](concepts/Custom-Instructions.md)
|
||||
- [Daily-Digest](concepts/Daily-Digest.md)
|
||||
- [Daily-Log](concepts/Daily-Log.md)
|
||||
- [DAST](concepts/DAST.md)
|
||||
- [Data-Governance](concepts/Data-Governance.md)
|
||||
- [Data-Sovereignty](concepts/Data-Sovereignty.md)
|
||||
@@ -980,6 +984,7 @@
|
||||
- [Docker堆栈](concepts/Docker堆栈.md)
|
||||
- [Docker容器生命周期管理](concepts/Docker容器生命周期管理.md)
|
||||
- [Docker警告处理](concepts/Docker警告处理.md)
|
||||
- [Domain-Thinking](concepts/Domain-Thinking.md)
|
||||
- [DORA-Metrics](concepts/DORA-Metrics.md)
|
||||
- [DRaaS](concepts/DRaaS.md)
|
||||
- [DRY-Principle](concepts/DRY-Principle.md)
|
||||
@@ -1001,6 +1006,7 @@
|
||||
- [Error-Accountability](concepts/Error-Accountability.md)
|
||||
- [Error-Budget](concepts/Error-Budget.md)
|
||||
- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
|
||||
- [ESN](concepts/ESN.md)
|
||||
- [Event-Correlation](concepts/Event-Correlation.md)
|
||||
- [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md)
|
||||
- [EventSourcing](concepts/EventSourcing.md)
|
||||
@@ -1026,6 +1032,7 @@
|
||||
- [Fuzzy-Matching](concepts/Fuzzy-Matching.md)
|
||||
- [Gatekeeper](concepts/Gatekeeper.md)
|
||||
- [GDM3](concepts/GDM3.md)
|
||||
- [Gegenrede](concepts/Gegenrede.md)
|
||||
- [Generalist](concepts/Generalist.md)
|
||||
- [Generation](concepts/Generation.md)
|
||||
- [Generator](concepts/Generator.md)
|
||||
@@ -1107,6 +1114,7 @@
|
||||
- [Lead-Time](concepts/Lead-Time.md)
|
||||
- [Learn-By-Building](concepts/Learn-By-Building.md)
|
||||
- [Left-over-Principle](concepts/Left-over-Principle.md)
|
||||
- [Link-Proposer](concepts/Link-Proposer.md)
|
||||
- [Liquid-Glass-Design-System](concepts/Liquid-Glass-Design-System.md)
|
||||
- [LLM-Wiki](concepts/LLM-Wiki.md)
|
||||
- [Local-Caching](concepts/Local-Caching.md)
|
||||
@@ -1115,6 +1123,7 @@
|
||||
- [Lockable-Workflow](concepts/Lockable-Workflow.md)
|
||||
- [Log-Driven-Debugging](concepts/Log-Driven-Debugging.md)
|
||||
- [LSP-317-Specification](concepts/LSP-317-Specification.md)
|
||||
- [Luhmann-四原则](concepts/Luhmann-四原则.md)
|
||||
- [Management-Pack](concepts/Management-Pack.md)
|
||||
- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md)
|
||||
- [MEDDPICC](concepts/MEDDPICC.md)
|
||||
@@ -1150,6 +1159,7 @@
|
||||
- [NFS网络备份](concepts/NFS网络备份.md)
|
||||
- [Nitro-System](concepts/Nitro-System.md)
|
||||
- [Normal-Change](concepts/Normal-Change.md)
|
||||
- [Nunchi](concepts/Nunchi.md)
|
||||
- [NVMe硬盘分区](concepts/NVMe硬盘分区.md)
|
||||
- [Observable-States](concepts/Observable-States.md)
|
||||
- [Obsidian-Agent-Client](concepts/Obsidian-Agent-Client.md)
|
||||
@@ -1157,8 +1167,8 @@
|
||||
- [Obsidian-CLI](concepts/Obsidian-CLI.md)
|
||||
- [Obsidian-Tasks](concepts/Obsidian-Tasks.md)
|
||||
- [OpenTelemetry](concepts/OpenTelemetry.md)
|
||||
- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md)
|
||||
- [Oracle-Manipulation](concepts/Oracle-Manipulation.md)
|
||||
- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md)
|
||||
- [Pain-Point-Mining](concepts/Pain-Point-Mining.md)
|
||||
- [Paper-Abstract-Batch-Fetching](concepts/Paper-Abstract-Batch-Fetching.md)
|
||||
- [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md)
|
||||
@@ -1185,6 +1195,7 @@
|
||||
- [Pod-Security-Context](concepts/Pod-Security-Context.md)
|
||||
- [Policy-as-Code](concepts/Policy-as-Code.md)
|
||||
- [Population-Stability-Index](concepts/Population-Stability-Index.md)
|
||||
- [Portage-Salarial](concepts/Portage-Salarial.md)
|
||||
- [Portfolio-ROI](concepts/Portfolio-ROI.md)
|
||||
- [PRD生成工作流](concepts/PRD生成工作流.md)
|
||||
- [Pre-Build-Validation](concepts/Pre-Build-Validation.md)
|
||||
@@ -1215,6 +1226,7 @@
|
||||
- [Recurring-Tasks](concepts/Recurring-Tasks.md)
|
||||
- [Recursive-Self-Optimization](concepts/Recursive-Self-Optimization.md)
|
||||
- [Redis缓存](concepts/Redis缓存.md)
|
||||
- [Reentrancy](concepts/Reentrancy.md)
|
||||
- [Reference-Architecture](concepts/Reference-Architecture.md)
|
||||
- [Release-Management](concepts/Release-Management.md)
|
||||
- [Reliability-Engineering](concepts/Reliability-Engineering.md)
|
||||
@@ -1232,7 +1244,6 @@
|
||||
- [Rollback-Rate](concepts/Rollback-Rate.md)
|
||||
- [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md)
|
||||
- [RPO](concepts/RPO.md)
|
||||
- [Reentrancy](concepts/Reentrancy.md)
|
||||
- [RSS-Aggregation](concepts/RSS-Aggregation.md)
|
||||
- [RTO](concepts/RTO.md)
|
||||
- [S3-兼容对象存储](concepts/S3-兼容对象存储.md)
|
||||
@@ -1374,6 +1385,7 @@
|
||||
- [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md)
|
||||
- [Zero-Trust](concepts/Zero-Trust.md)
|
||||
- [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md)
|
||||
- [Zettelkasten](concepts/Zettelkasten.md)
|
||||
- [一人公司](concepts/一人公司.md)
|
||||
- [上下文刷新](concepts/上下文刷新.md)
|
||||
- [上下文压缩](concepts/上下文压缩.md)
|
||||
@@ -1444,5 +1456,6 @@
|
||||
- [逻辑备份](concepts/逻辑备份.md)
|
||||
- [销售漏斗](concepts/销售漏斗.md)
|
||||
- [首尾针动画](concepts/首尾针动画.md)
|
||||
- [품의](concepts/품의.md)
|
||||
|
||||
## Syntheses
|
||||
|
||||
36
wiki/log.md
36
wiki/log.md
@@ -1,3 +1,39 @@
|
||||
## [2026-04-25] ingest | Supply Chain Strategist Agent
|
||||
- Source file: Agent/agency-agents/specialized/supply-chain-strategist.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Supply Chain Strategist——The Agency Specialized 部门的中国制造业供应链全链路专家 Agent，帮助企业建立高效、有韧性、可持续的供应链体系。核心：供应商 ABC 分级管理 + Kraljic 矩阵采购策略 + TCO 全成本分析 + 库存优化模型（EOQ/ROP/安全库存/VMI/JIT）+ 供应链数字化成熟度 L1-L5 五级评估 + RBA/SA8000/CMRT 合规体系。典型成就：紧固件品类年采购成本降低 12%（节省 ¥870,000）。
|
||||
- Concepts created: 无（Kraljic Matrix/TCO/EOQ/RBA/SA8000 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
|
||||
- Entities created: 无（1688/Canton Fair/SGS/TUV 等各渠道平台在源文档均仅出现 1 次，待后续批次独立创建；已在 Source Page Key Entities 节以 [[wikilink]] 格式标注）
|
||||
- Source page: wiki/sources/supply-chain-strategist.md
|
||||
- Notes: index.md 新增 Supply Chain Strategist Agent 条目，同时替换原有 "source missing" 占位条目（2026-04-20 supply-chain-strategist）为完整条目；overview.md Specialized 部门新增 Supply Chain Strategist 条目置于 zk-steward 之后；无内容冲突检测（与 [[specialized-french-consulting-market]] 为 Specialized 部门内的不同垂直领域，无直接矛盾）。
|
||||
|
||||
## [2026-04-25] ingest | ZK Steward Agent
|
||||
- Source file: Agent/agency-agents/specialized/zk-steward.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: ZK Steward——AI 时代 Luhmann Zettelkasten 知识库管家，以 Niklas Luhmann 的卡片盒方法论为默认视角，融合多领域专家心智模型（Feynman/Karpathy/Munger/Ogilvy 等），通过原子笔记+ Luhmann 四原则验证门+领域专家切换实现有机知识网络增长。
|
||||
- Concepts created: [[Zettelkasten]]（卡片盒知识管理法）、[[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话验证门）、[[Domain-Thinking]]（领域专家三维切换机制）、[[Gegenrede]]（德语反诘，跨学科反问机制）、[[Link-Proposer]]（链接提议器三步流程）、[[Daily-Log]]（Intent/Changes/Open loops 每日日志）
|
||||
- Entities created: [[Niklas-Luhmann]]（德国社会学家，Zettelkasten 发明者）、[[zk-steward-companion]]（GitHub 配套技能库）
|
||||
- Source page: wiki/sources/zk-steward.md
|
||||
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 ZK Steward 条目置于 specialized-korean-business-navigator 之后；entities/ 和 concepts/ 目录已创建并填充 2 个 Entity + 6 个 Concept 页面；无内容冲突检测（与 [[Second-Brain]] 为互补关系，详见 Contradictions 部分）。
|
||||
|
||||
## [2026-04-25] ingest | Korean Business Navigator
|
||||
- Source file: Agent/agency-agents/specialized/specialized-korean-business-navigator.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Korean Business Navigator——The Agency Specialized 部门的韩国商业文化导航 Agent，帮助外国专业人员解码韩国商业隐性规则。核心洞察：品의流程耗时 6-16 周，永远不要在第一次会议要求时间线；韩国"yes"≠同意，沉默=内部讨论进行中；成交发生在会议室外的走廊。六阶段品의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（含"검토해보겠습니다"=婉拒等5+信号）、KakaoTalk 分阶段消息模板、韩国企业职级体系、Proof Project 策略。
|
||||
- Concepts created: [[품의]]（韩国共识审批流程，含六阶段时间线及品의서/결재라인规范）、[[Nunchi]]（韩国文化"读心术"，含6+常用商业解码表）
|
||||
- Entities created: [[KakaoTalk]]（韩国主流即时通讯平台，商务沟通核心渠道；群聊必须韩语、9AM-7PM KST商务时间、24h只读不回会被注意）
|
||||
- Source page: wiki/sources/specialized-korean-business-navigator.md
|
||||
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Korean Business Navigator 条目置于 specialized-french-consulting-market 之后；index.md 新增 Entities 条目（KakaoTalk）和 Concepts 条目（품의、Nunchi）；无内容冲突（与 Cultural Intelligence Strategist 为互补关系，已在 overview.md 建立链接）。
|
||||
|
||||
## [2026-04-25] ingest | French Consulting Market Navigator
|
||||
- Source file: Agent/agency-agents/specialized/specialized-french-consulting-market.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: French Consulting Market Navigator——The Agency Specialized 部门的法国 IT 咨询市场（ESN/SI）生态导航 Agent，帮助独立顾问最大化 TJM 税后净收入。核心洞察：ESN Margin 25-40% 不透明；Portage Salarial vs Micro-Entrepreneur 税后收益差距 338€/天（社保保护价格）；付款延迟结构性 60-90 天；Malt 公开定价即为市场锚点。五大平台对比 + 三层 ESN 分层定价 + TJM 阶梯锚定谈判四步法。
|
||||
- Concepts created: [[Portage-Salarial]]（Portage Salarial 机制完整解析：管理费5-10%、雇主/雇员社保合计~67%、700€/天→208€/天净）、[[ESN]]（Entreprise de Services Numériques 三级分类及 Margin 架构详解）
|
||||
- Entities created: 无（平台 Malt/collective.work/Comet/Crème/Free-Work 及 ESN Cloudity/Accenture 仅出现1次，通过 Source Page Key Entities 保留）
|
||||
- Source page: wiki/sources/specialized-french-consulting-market.md
|
||||
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 specialized-french-consulting-market 条目置于 study-abroad-advisor 之后；Portage-Salarial 和 ESN 均已存在于 wiki/concepts/，无需重复创建，仅补充了本次来源的 sources 字段
|
||||
|
||||
## [2026-04-25] ingest | Blockchain Security Auditor
|
||||
- Source file: Agent/agency-agents/specialized/blockchain-security-auditor.md
|
||||
- Status: ✅ 成功摄入
|
||||
|
||||
@@ -709,6 +709,12 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
|
||||
|
||||
**[[study-abroad-advisor]]**（Study Abroad Advisor）：留学申请规划专家 Agent——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美国/英国/加拿大/澳大利亚/欧洲/香港/新加坡七大目的地，涵盖本科/硕士/博士全学位层次。核心理念：**数据驱动、零焦虑贩卖**——GPA 3.2 进入 Top 30 的案例与 GPA 3.9 全拒的案例并存，关键变量是选校策略和文书质量。核心方法：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）+ 多国联申时间线协调；标准化交付模板（选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵）。诚信原则：不代写文书、不承诺录取结果、明确区分"确认信息"与"经验估算"。属 The Agency Specialized 部门的垂直服务方向，与 [[corporate-training-designer]]（企业培训）同属服务型 Agent，但前者面向 B2C 个人消费者，后者面向企业组织。
|
||||
|
||||
**[[specialized-french-consulting-market]]**（French Consulting Market Navigator）：法国 IT 咨询市场生态导航专家——The Agency Specialized 部门的法国 ESN/SI（Entreprise de Services Numériques）自由职业者策略 Agent，专帮助独立 IT 顾问最大化日均费率（TJM）、最小化回款风险、建立可持续客户关系。核心理念：**理解 ESN Margin 架构是谈判关键**；永远区分 TJM 毛收入（brut）与税后净收入（net）。核心方法：ESN 分层定价架构（Tier 1 全球型 Margin 35-50%、Tier 2 专项型 25-40%、Tier 3 经纪型 15-25%）+ 五平台对比矩阵（Malt/collective.work/Comet/Crème/FreeWork）+ TJM 阶梯锚定谈判四步法（Floor计算→Sell Rate反推→分层锚定→条件让步）。关键区分：Portage Salarial 税后净得约 50% TJM（700€/天 → ~300-330€ 净），Micro-Entrepreneur 净得约 70%（~420-450€），338€/天差价是社保保护（ARE失业保险、退休金补充）的价格。国际顾问策略：主动披露位置+时区覆盖价值重构替代隐瞒。属 The Agency Specialized 部门的垂直市场专家方向，与 [[specialized-korean-business-navigator]]（韩国市场导航）同属区域市场进入策略 Agent。
|
||||
|
||||
**[[specialized-korean-business-navigator]]**（Korean Business Navigator）：韩国商业文化导航专家——The Agency Specialized 部门的韩国市场进入 Agent，专帮助外国专业人员解码韩国商业隐性规则，将西方直接性与韩国关系动态相结合。核心理念：**韩国"yes"不一定是同意，沉默是信息，成交发生在会议室外的走廊**。核心洞察：품의（共识审批）流程耗时 6-16 周（SME 6-10、中型 8-12、财阀 12-16），远长于西方的 2-4 周，永远不要在第一次会议要求决策时间线；永远不要绕过联系人越级上报；KakaoTalk 群聊必须使用韩语；永远不要在第一次对话中谈钱（关系→能力→价格三阶段）；회식（商务聚餐）出席是预期而非可选。关键方法：六阶段 품의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（"검토해보겠습니다"实际意为"婉拒"）、分阶段 KakaoTalk 消息模板、韩国企业职级体系（회장→대리十级）、Proof Project 策略（有边界小项目降低感知风险）。与 [[cultural-intelligence-strategist]] 同属跨文化领域 Agent，但前者聚焦韩国单一市场，后者覆盖全球包容性设计；与 [[specialized-french-consulting-market]] 同属区域市场进入策略 Agent，共に构成 The Agency 的全球区域化服务能力。
|
||||
|
||||
**[[supply-chain-strategist]]**（Supply Chain Strategist）：中国制造业供应链管理与战略采购专家 Agent——The Agency Specialized 部门的供应链全链路专家，基于中国制造业生态，帮助企业建立高效、有韧性、可持续的供应链体系。核心能力：供应商开发与分级管理（ABC 分类 + 战略合作伙伴升级）、Kraljic 矩阵采购类别策略、QCD 绩效评分体系（全季度评分年度淘汰）、TCO 全成本分析（直接/间接/隐性/全生命周期成本）、库存优化模型（EOQ/ROP/安全库存/VMI/JIT）、供应链数字化成熟度评估（L1 手动 → L5 自主智能）。采购渠道覆盖 1688/阿里巴巴、中国制造网、广交会、企查查企业核验等全渠道。合规能力：RBA 行为准则、SA8000 社会责任审计、碳足迹追踪、冲突矿产合规（CMRT）、ISO 14001/REACH/RoHS。关键原则：**关键物料禁止单一来源**；**TCO 是采购决策依据而非单价**；**质量问题必须追溯根本原因**。典型成就：紧固件品类年采购成本通过整合采购降低 12%，节省 ¥870,000。与 [[specialized-french-consulting-market]] 同属 Specialized 部门垂直领域 Agent，分别覆盖供应链管理和法国市场咨询两个不同专业方向。
|
||||
|
||||
## Conflict Areas
|
||||
|
||||
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
|
||||
|
||||
62
wiki/sources/agents-orchestrator.md
Normal file
62
wiki/sources/agents-orchestrator.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Agents Orchestrator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/agents-orchestrator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 多智能体开发流水线编排器，自主管理从规格到交付的完整开发流程
|
||||
- 问题域：多专业 Agent 协同工作流中，如何确保每个任务通过质量验证后才推进，如何处理失败和重试
|
||||
- 方法/机制：四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成）；基于截图证据的质量门控；最大3次重试上限
|
||||
- 结论/价值：通过强制性质量门控和 Dev-QA 循环，确保只有通过验证的功能才能推进，最终交付符合规格要求的生产就绪产品
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AgentsOrchestrator 通过持续 Dev-QA 循环实现任务级质量验证，每个任务必须通过 EvidenceQA 的截图验证才能推进
|
||||
- 四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成）确保从规格到生产的完整质量覆盖
|
||||
- 最大重试次数为3次，超过后进行升级处理，避免无限循环同时保证任务有足够修正机会
|
||||
- AgentsOrchestrator 提供标准化状态报告模板，实现流水线进度的透明化追踪
|
||||
|
||||
## Key Quotes
|
||||
> "Each task must pass QA before advancing." — 质量门控原则：每个任务必须通过 QA 验证才能推进到下一任务
|
||||
> "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness." — testing-reality-checker 的默认判断原则，确保交付标准严格
|
||||
> "Maximum 3 attempts per task before escalation." — 重试上限机制，防止任务无限循环
|
||||
> "No shortcuts: Every task must pass QA validation." — 强制性质量验证，无例外原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Dev-QA-Loop]]：开发与质量验证的持续循环机制——每个任务完成后由 EvidenceQA 进行截图验证，通过后推进下一个任务，失败则回到开发阶段并携带具体反馈
|
||||
- [[Quality-Gate]]：质量门控机制——任务必须通过质量验证才能推进到下一阶段的强制性检查点
|
||||
- [[EvidenceQA]]：基于截图证据的质量验证专家 Agent——要求视觉证据作为验证依据，提供明确的 PASS/FAIL 判定及具体反馈
|
||||
- [[Pipeline-State-Management]]：流水线状态管理——追踪当前任务、所处阶段、完成状态，在 Agent 间传递上下文信息，处理错误并实现恢复
|
||||
- [[Agent-Handoff]]：Agent 交接协议——在多个专业 Agent 之间传递完整的上下文和具体指令，确保下一 Agent 获得足够信息执行任务
|
||||
- [[Continuous-Dev-QA-Loop]]：持续开发质量循环——开发与 QA 交替进行，每个开发交付物立即经过 QA 验证，形成快速反馈闭环
|
||||
|
||||
## Key Entities
|
||||
- [[AgentsOrchestrator]]：编排器自身——自主流水线管理器，协调从规格到生产的完整开发流程（来源页面）
|
||||
- [[ArchitectUX]]：技术架构师 Agent——负责基于规格和任务列表创建技术架构和 UX 基础
|
||||
- [[EvidenceQA]]：截图质量验证 Agent——通过截图证据对每个任务实现进行质量验证
|
||||
- [[ProjectManagerSenior]]：高级项目经理 Agent——负责将规格文档转化为详细的任务列表
|
||||
- [[TestingRealityChecker]]：最终集成验证 Agent——在所有任务通过后进行最终集成测试，默认为"需要改进"原则
|
||||
- [[FrontendDeveloper]]：前端开发者 Agent——负责 UI/UX 任务的实现
|
||||
- [[BackendArchitect]]：后端架构师 Agent——负责服务端架构和 API 开发
|
||||
- [[MobileAppBuilder]]：移动应用构建 Agent——负责移动端应用开发
|
||||
- [[DevOpsAutomator]]：DevOps 自动化 Agent——负责基础设施任务
|
||||
|
||||
## Connections
|
||||
- [[AgentsOrchestrator]] ← spawns ← [[ProjectManagerSenior]]（Phase 1：编排器启动项目经理创建任务列表）
|
||||
- [[AgentsOrchestrator]] ← spawns ← [[ArchitectUX]]（Phase 2：编排器启动架构师创建技术基础）
|
||||
- [[AgentsOrchestrator]] ← spawns ← [[EvidenceQA]]（Phase 3：每个任务的 QA 验证）
|
||||
- [[AgentsOrchestrator]] ← spawns ← [[TestingRealityChecker]]（Phase 4：最终集成测试）
|
||||
- [[ArchitectUX]] ← depends_on ← [[ProjectManagerSenior]]（架构基于任务列表）
|
||||
- [[Dev-QA-Loop]] ← extends ← [[Multi-Agent-System-Reliability]]（流水线编排是多 Agent 可靠性的实践框架）
|
||||
- [[AgentsOrchestrator]] ← part_of ← [[The Agency]]（编排器是 The Agency 的核心基础设施）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-workflow-architect]] 冲突：
|
||||
- 冲突点：两个 Agent 都声称负责"编排"职责——前者是流水线执行编排器，后者是工作流设计专家
|
||||
- 当前观点：AgentsOrchestrator 是执行层面的流水线管理器，强调任务级质量门控和自动化重试逻辑
|
||||
- 对方观点：Workflow Architect 是设计层面的工作流架构师，专注工作流模式设计和流程建模
|
||||
- 说明：两者不存在功能重叠——Workflow Architect 设计工作流，AgentsOrchestrator 执行工作流，属设计与执行的分层关系
|
||||
47
wiki/sources/sales-data-extraction-agent.md
Normal file
47
wiki/sources/sales-data-extraction-agent.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Sales Data Extraction Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/sales-data-extraction-agent.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：销售数据提取 AI Agent，专门监控 Excel 文件并提取关键销售指标
|
||||
- 问题域：销售报告自动化处理、销售指标实时监控
|
||||
- 方法/机制：文件系统监控 + 灵活列映射 + PostgreSQL 持久化
|
||||
- 结论/价值：实现销售数据的自动化提取与下游分发，减少人工干预
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent 实时监控指定目录中的 Excel 文件（新文件或更新版本）
|
||||
- Agent 从 Excel 工作簿中提取 MTD（月度至今）、YTD（年度至今）和 Year End（年终预测）指标
|
||||
- Agent 支持灵活列名映射（revenue/sales/total_sales 等）
|
||||
- Agent 自动计算配额达成率
|
||||
- Agent 使用事务将提取的指标批量插入 PostgreSQL，保证原子性
|
||||
- Agent 保留完整的审计跟踪记录
|
||||
|
||||
## Key Quotes
|
||||
> "You are the Sales Data Extraction Agent — an intelligent data pipeline specialist who monitors, parses, and extracts sales metrics from Excel files in real time. You are meticulous, accurate, and never drop a data point." — Agent 身份定义
|
||||
|
||||
> "Never overwrite existing metrics without a clear update signal (new file version)" — 关键规则：数据覆盖保护
|
||||
|
||||
## Key Concepts
|
||||
- [[FilesystemWatcher]]：文件系统监控，检测目录中的 .xlsx 和 .xls 文件变化
|
||||
- [[FuzzyColumnMapping]]：模糊列名匹配，处理 revenue/sales/total_sales、units/qty/quantity 等变体
|
||||
- [[MetricExtraction]]：指标提取，从工作簿中识别 MTD、YTD、Year End 等指标类型
|
||||
- [[TransactionalDatabase]]：事务性数据库操作，使用 PostgreSQL 事务保证原子性
|
||||
- [[AuditTrail]]：审计跟踪，记录每次导入的文件名、处理行数、失败行数、时间戳
|
||||
|
||||
## Key Entities
|
||||
- [[PostgreSQL]]：目标数据库，用于存储提取的销售指标
|
||||
- [[SalesRepresentative]]：销售代表，Agent 通过邮箱或全名匹配
|
||||
- [[ExcelWorkbook]]：Excel 工作簿，包含多个 sheet 的销售数据
|
||||
|
||||
## Connections
|
||||
- [[AgentsOrchestrator]] ← orchestrates ← [[SalesDataExtractionAgent]]
|
||||
- [[SalesDataExtractionAgent]] ← provides_data ← [[ReportDistributionAgent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DataConsolidationAgent]]：DataConsolidationAgent 整合来自多个来源的数据，而 SalesData Extraction Agent 专注于从 Excel 文件提取数据；两者可以互补使用
|
||||
63
wiki/sources/specialized-french-consulting-market.md
Normal file
63
wiki/sources/specialized-french-consulting-market.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "French Consulting Market Navigator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/specialized-french-consulting-market.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：法国 IT 咨询市场（ESN/SI 生态系统）的运作规则、费率定位与谈判策略
|
||||
- 问题域：独立 IT 顾问在法国市场中面临的信息不对称——ESN 佣金结构不透明、平台定价机制混乱、多层billing结构税后收益差异巨大
|
||||
- 方法/机制：三层 ESN 分类定价体系（Tier 1-3）、五大平台对比矩阵（Malt/collective.work/Comet/Crème/Free-Work）、TJM→净收入换算模型、季节性市场日历、国际远程顾问定位策略
|
||||
- 结论/价值：帮助自由顾问最大化税后日均收入、最小化付款风险、建立可持续客户关系
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- ESN 佣金结构是市场信息不对称的核心：Client 支付 1,000 EUR/天，Tier 2 ESN 实际支付顾问 600-750 EUR/天（佣金 25-40%），顾问对此往往不知情
|
||||
- Billing 结构税后收益差距显著：同等 TJM 700 EUR/天，Portage Salarial 净收入 ~208 EUR/天（~3,742 EUR/月），Micro-entreprise 净收入 ~546 EUR/天（~9,828 EUR/月），差距 338 EUR/天
|
||||
- 付款延迟是结构性而非例外：合同标注 NET-30，实际到账 60-90 天，顾问必须提前预算
|
||||
- 平台费率具有公开锚定效应：Malt 上的报价直接成为市场价格，定价必须从第一天起就谨慎
|
||||
- 费率下限有战略意义：Salesforce 架构师低于 550 EUR/天会被 ESN 视为"急于求成"，永久锚定低费率谈判基准
|
||||
- 远程/国际位置必须主动披露：谈判中期被发现会导致费率降低 5-10% 并损害信任，主动披露+价值框架可中和惩罚
|
||||
|
||||
## Key Quotes
|
||||
> "Portage salarial is not employment. It provides social protection (unemployment, retirement contributions) but the freelancer bears all commercial risk. Never present it as equivalent to a CDI." — 核心原则：Portage 不等于就业，不能用 CDI 的安全感来类比
|
||||
|
||||
> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — 平台费率的公开性要求从第一天就谨慎定价
|
||||
|
||||
> "A 600 EUR/day TJM through portage salarial yields approximately 300-330 EUR net after all charges. Through micro-entreprise, approximately 420-450 EUR. The gap is significant and must be surfaced." — 两种结构税后收益差距 30-40%，必须明确告知客户
|
||||
|
||||
## Key Concepts
|
||||
- [[TJM]]（Taux Journalier Moyen / 毛日均费率）：法国咨询市场的核心定价单位，需区分 TJM Brut 与实际净收入
|
||||
- [[Portage-Salarial]]：法国的准雇佣模式，为自由顾问提供失业保险和退休金，但商业风险自担，净收入约为 TJM Brut 的 50%
|
||||
- [[Micro-Entreprise]]：法国简化商业结构，无社会保障福利，净收入约为 TJM Brut 的 70%
|
||||
- [[ESN-SI-Ecosystem]]：法国 IT 咨询生态系统，ESN（Entreprise de Services Numériques）= SI（System Integrator），占法国企业 IT 项目用人的主要渠道
|
||||
- [[Rate-Negotiation-Playbook]]：费率谈判四步法（知底价→探底价→锚高价→框架溢价），核心是在非 TJM 维度（期限/远程天数/续约条款）上让步
|
||||
- [[International-Freelancer-Positioning]]：面向法国市场的国际自由顾问定位策略，核心是时区重叠作为优势、法国实体偏好、主动披露原则
|
||||
|
||||
## Key Entities
|
||||
- [[Malt]]：欧洲最大自由顾问平台，10% 佣金（客户端），费率公开可见，适合建立作品集，典型 TJM 550-700 EUR
|
||||
- [[collective.work]]：3-5% 佣金+Portage 集成，典型 TJM 650-800 EUR，适合高价值 mission
|
||||
- [[Comet]]：15% 佣金，算法驱动匹配，典型 TJM 600-750 EUR，技术顾问为主
|
||||
- [[Crème-de-la-Crème]]：15-20% 佣金，准入筛选严格，典型 TJM 700-900 EUR，高端定位
|
||||
- [[Free-Work]]：免费列表+付费选项，TJM 500-900 EUR，以中间商列表为主，噪音较大
|
||||
- [[Portage-Salarial-Company]]（Portage 公司）：作为 ESN 和顾问之间的雇佣中介，负责代扣代缴社保，提供 ARE 失业保险权利
|
||||
|
||||
## Connections
|
||||
- [[TJM]] ← is_priced_by ← [[ESN-SI-Ecosystem]]
|
||||
- [[Portage-Salarial]] ← provides_social_protection_to ← [[TJM]]
|
||||
- [[Micro-Entreprise]] ← alternative_to ← [[Portage-Salarial]]
|
||||
- [[Malt]] ← competing_with ← [[collective.work]], [[Comet]], [[Crème-de-la-Crème]], [[Free-Work]]
|
||||
- [[International-Freelancer-Positioning]] ← requires ← [[French-Entity]]（Portage 或 SASU）
|
||||
|
||||
## Contradictions
|
||||
- 与一般"高TJM=高收入"直觉冲突：
|
||||
- 冲突点：同等 TJM 下，Portage Salarial 的实际净收入比 Micro-entreprise 低 30-40%
|
||||
- 当前观点：TJM 必须换算为税后实际日均收入才能判断真实收入水平
|
||||
- 对方观点：只看 TJM 数字，越高越好
|
||||
- 与"全职就业安全感"对比：
|
||||
- 冲突点：Portage 提供的社保（失业保险/退休金）不等于 CDI 就业保障
|
||||
- 当前观点：Portage 是商业安排，商业风险完全由顾问自担，绝不能包装成"准就业"
|
||||
- 对方观点：Portage = 更好的 CDI（自由+保障）
|
||||
66
wiki/sources/specialized-korean-business-navigator.md
Normal file
66
wiki/sources/specialized-korean-business-navigator.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Korean Business Navigator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/specialized-korean-business-navigator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：帮助外国专业人员在韩国商业环境中导航——将西方直接性与韩国关系动态相结合的专家 Agent
|
||||
- 问题域：韩国商业文化中的隐性规则（品의决策流程、눈치读心术、KakaoTalk商务礼仪、层级导航、关系优先的成交机制）
|
||||
- 方法/机制：品의（共识审批）六阶段时间线、Nunchi 解码表、KakaoTalk 消息模板、韩国企业职级体系、회식（商务聚餐）礼仪、Proof Project 策略
|
||||
- 结论/价值：韩国商业"成交"发生在会议室外的走廊而非会议室内；韩国"yes"不一定是同意；沉默是信息而非拒绝
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 冷接触（Cold Outreach）响应率 < 5%，通过介绍人接入响应率显著更高
|
||||
- 韩国品의流程耗时 6-16 周（SME 6-10 周、中型 8-12 周、财阀 12-16 周），远长于西方的 2-4 周
|
||||
- 永远不要在第一次会议要求决策时间线——询问"何时成交"等于暴露无知和绝望
|
||||
- 永远不要绕过联系人直接联系其上级——越级在韩国商业中是关系终结行为
|
||||
- KakaoTalk 群聊必须使用韩语——即使不完美也显示尊重
|
||||
- 永远不要在第一次对话中谈钱——关系第一、能力第二、价格第三
|
||||
- 회식出席是预期而非可选——拒绝会损害信任
|
||||
- 沉默（3-7 天）不等于拒绝——通常意味着内部讨论正在进行
|
||||
|
||||
## Key Quotes
|
||||
> "검토해보겠습니다" literally means "we'll review it" but contextually means "probably not — give us a graceful exit." — 品의婉拒信号
|
||||
> "Korean business runs on 품의 (consensus approval)." — 韩国决策机制核心
|
||||
> "A Korean 'yes' is not always agreement, that silence is information, and that the real decision happens in the hallway after the meeting, not during it." — Agent 身份定位
|
||||
> "The proof project IS the sales pitch. Over-deliver deliberately." — Proof Project 策略核心
|
||||
|
||||
## Key Concepts
|
||||
- [[품의]]：韩国共识审批流程，含六阶段（소개→미팅→내부검토→품의서→결재→계약），耗时 6-16 周，不可加速
|
||||
- [[Nunchi]]：눈치（读心术）——通过观察语境和情绪线索理解未被直接表达的意图，是韩国商业的核心技能
|
||||
- [[KakaoTalk-商务礼仪]]：韩国主流通讯工具的分阶段消息模板、响应时间期望、群聊规则（必须韩语）、表情贴纸使用时机
|
||||
- [[회식]]：회식（公司聚餐/饮酒文化）——出席是预期而非可选；斟酒、用餐、祝酒均有严格礼仪规范
|
||||
- [[Proof-Project-Strategy]]：信任未建立时用有边界的小项目证明——2-3 周、固定交付物、固定价格，用结果推动完整合作
|
||||
- [[Korean-Corporate-Hierarchy]]：韩国企业职级体系（회장→사장→부사장→전무→상무→이사→부장→차장→과장→대리）及对应的称呼规范（职称+님）
|
||||
- [[Relationship-Lifecycle]]：介绍→信任→合同三阶段关系管理，每阶段有不同的沟通策略和时机预期
|
||||
|
||||
## Key Entities
|
||||
- [[Chaebol]]：韩国财阀（大企业集团），品의流程最长（12-16 周），建议月度跟进
|
||||
- [[SME]]（中小企业）：品의流程最短（6-10 周），建议周度跟进
|
||||
- [[KakaoTalk]]：韩国主流即时通讯工具，商务沟通的核心渠道，9AM-7PM KST 为商务时间
|
||||
- [[도장]]（印章）：韩国合同执行的物理凭证，合同签订后还需印章盖印完成
|
||||
|
||||
## Connections
|
||||
- [[품의]] ← 是 [[Korean-Business-Decision-Process]] 的核心机制
|
||||
- [[Nunchi]] ← 是 [[품의]] 流程中读取内部信号的技能基础
|
||||
- [[KakaoTalk-商务礼仪]] ← 是 [[Relationship-Lifecycle]] 各阶段的沟通载体
|
||||
- [[회식]] ← 是建立信任（소개→신뢰→계약）的关键社交机制
|
||||
- [[Proof-Project-Strategy]] ← 是 [[Relationship-Lifecycle]] 中从 미팅 过渡到 계약 的推荐方法
|
||||
- [[Cultural-Intelligence-Strategist]] ← 上级概念：本 Agent 是其韩国商业领域的具体化
|
||||
|
||||
## Contradictions
|
||||
- 与西方"快速成交"直觉冲突：
|
||||
- 冲突点：西方商务文化鼓励在第一次会议明确时间线、尽快推进
|
||||
- 当前观点：韩国品의要求 6-16 周，需等待内部审批链，不能催促
|
||||
- 对方观点：快速推进显示专业性和效率
|
||||
- 解决方向：理解品의是保护机制，不是障碍；用有边界的 Proof Project 降低感知风险
|
||||
- 与西方"沉默=拒绝"直觉冲突：
|
||||
- 冲突点：西方将 3-7 天无响应视为消极信号
|
||||
- 当前观点：沉默表示内部讨论正在进行，应等待而非催促
|
||||
- 对方观点：及时跟进显示诚意和重视
|
||||
- 解决方向：区分"积极沉默"（品의中）和"死单沉默"，关键信号是对方是否有主动提问
|
||||
47
wiki/sources/study-abroad-advisor.md
Normal file
47
wiki/sources/study-abroad-advisor.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Study Abroad Advisor"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/study-abroad-advisor.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：面向中国学生的全链路留学申请规划专家 Agent，覆盖美国/英国/加拿大/澳大利亚/欧洲/香港/新加坡七大留学目的地，涵盖本科/硕士/博士全学位层次，从选校定位到行前准备的完整流程。
|
||||
- 问题域：留学申请策略、选校定位、文书写作、背景提升、考试规划、签证办理、Offer 比较决策。
|
||||
- 方法/机制：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；数据驱动的选校概率区间（Reach 20-40% / Target 40-70% / Safety 70-90%）；多国联申时间线协调；标准化交付模板（选校报告、多国申请时间线、文书诊断、Offer 比较矩阵）。
|
||||
- 结论/价值：为每位学生提供端到端、个性化的留学规划，消除申请焦虑，强调数据透明与诚信原则（不代写文书、不夸大经历、不承诺录取结果）。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Study Abroad Advisor 通过数据驱动方法，能帮助 GPA 3.2 的学生进入 Top 30， 也可能让 GPA 3.9 的学生全拒——关键在于选校策略和文书质量。
|
||||
- 多国联申策略（如 US+UK、US+HK+Singapore）需要精确的时间线协调和精力分配，但能显著提升录取概率。
|
||||
- 诚信原则（不代写文书、不承诺结果）是留学咨询的核心底线，任何"保证录取"的承诺都是骗局。
|
||||
- 文书不是经历的流水账列表，而是围绕核心叙事弧（你是谁→去哪→为什么是这个项目）的故事化表达。
|
||||
- 选校推荐必须区分"确认信息"和"经验估算"， admission probability 以区间而非精确数字表达。
|
||||
|
||||
## Key Quotes
|
||||
> "This program admitted about 200 students last year, roughly 40 from China, with a median GPA of 3.6. Your 3.5 is within range but not strong — you'll need essays and experiences to compensate." — 数据驱动的录取概率沟通
|
||||
> "Top 10 isn't on your menu right now, but Top 30 is within reach. Let's focus energy where the odds are highest." — 务实选校，避免焦虑贩卖
|
||||
> "You think your Hackathon experience doesn't matter? You led a team to build a product with real users from scratch in 48 hours — that's exactly the kind of initiative engineering programs look for." — 优势挖掘，赋能学生信心
|
||||
|
||||
## Key Concepts
|
||||
- [[Holistic-Admissions]]：全面评估录取模式——综合考量 GPA、标准化考试成绩、课外活动、文书、推荐信等多维度，非单一成绩决定。
|
||||
- [[UCAS-System]]：英国本科统一申请系统——学生通过 UCAS 可同时申请最多 5 所英国大学，个人陈述（Personal Statement）需面向所有申请学校，4,000 字符限制，80% 内容须聚焦学术热情。
|
||||
- [[IANG-Visa]]：非本地毕业生留港就业安排（Immigration Arrangement for Non-local Graduates）——香港为在港毕业生提供毕业后留港工作签证，无配额限制，是香港留学的核心吸引力之一。
|
||||
- [[Grandes-Ecoles]]：法国精英大学体系——与公立大学并行的高等教育精英通道，需通过竞考（concours）入学，毕业后享有高社会认可度。
|
||||
|
||||
## Key Entities
|
||||
- The Agency Specialized 部门：该 Agent 归属 The Agency 多智能体系统的 Specialized 部门，与 Agents Orchestrator、Identity Graph Operator、MCP Builder Agent、Agentic Identity & Trust Architect 等 Specialist 同事协同工作。
|
||||
- 1point3acres（一亩三分地）：中国留学生社区论坛，是学生验证录取数据、校友去向、申请经验的重要信息来源，Agent 鼓励学生通过该论坛核实关键数据。
|
||||
|
||||
## Connections
|
||||
- [[Agents-Orchestrator]] ← coordinates_with ← Study Abroad Advisor
|
||||
- [[specialized-mcp-builder]] ← same_department ← Study Abroad Advisor
|
||||
- [[identity-graph-operator]] ← same_department ← Study Abroad Advisor
|
||||
- [[agentic-identity-trust]] ← same_department ← Study Abroad Advisor
|
||||
- [[ProjectManagerSenior]] ← supports ← Study Abroad Advisor（两者均服务于 The Agency 的项目管理体系，PM 产出的任务列表可支撑留学规划的项目化执行）
|
||||
|
||||
## Contradictions
|
||||
- 与其他 Agent 的信息呈现方式：Study Abroad Advisor 明确采用数据驱动、零焦虑贩卖的原则，而其他面向消费者的 Agent（如一般营销 Agent）可能倾向于过度承诺录取结果。核心区别在于：前者明确区分"确认信息"和"经验估算"，后者缺乏这种信息透明度约束。
|
||||
75
wiki/sources/supply-chain-strategist.md
Normal file
75
wiki/sources/supply-chain-strategist.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: "Supply Chain Strategist Agent"
|
||||
type: source
|
||||
tags: [agent, supply-chain, procurement, china-manufacturing, strategy]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/supply-chain-strategist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：基于中国制造业生态的专业供应链管理与战略采购 Agent，帮助企业建立高效、有韧性、可持续的供应链体系
|
||||
- 问题域：供应商管理、战略寻源、质量控制、库存优化、供应链数字化、成本管控、风险管理与合规 ESG
|
||||
- 方法/机制：Kraljic 矩阵分类采购策略、ABC 分级供应商管理、QCD 绩效评估、TCO 全成本分析、库存模型（EOQ/ROP/安全库存）、数字化成熟度评估
|
||||
- 结论/价值：提供端到端供应链解决方案，从供应商开发寻源到危机响应，覆盖采购、物流、库存、合规全链路
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 供应商 ABC 分级管理 + 战略合作伙伴关系升级，能显著提升供应链稳定性
|
||||
- Kraljic 矩阵定位采购类别，配合差异化采购策略，可实现年度采购成本降低 5-8%
|
||||
- TCO（全成本拥有权）分析是采购决策依据，而非单纯比较单价
|
||||
- 关键物料必须多源采购，单一来源是最高风险项
|
||||
- 供应链数字化成熟度分 5 级（L1 手动 → L5 自主智能），成熟度提升路径明确
|
||||
- 供应商绩效评估必须数据驱动，主观评价不超过 20%
|
||||
|
||||
## Key Quotes
|
||||
> "Critical materials must never be single-sourced — verified alternative suppliers are mandatory" — 供应链安全第一原则
|
||||
> "TCO (Total Cost of Ownership) is the decision-making basis, not unit purchase price alone" — 成本决策核心原则
|
||||
> "Quality issues must be traced to root cause — superficial fixes are insufficient" — 质量管控原则
|
||||
> "Through consolidated purchasing, fastener category annual procurement costs decreased 12%, saving ¥870,000" — 数据驱动沟通风格示例
|
||||
|
||||
## Key Concepts
|
||||
- [[Kraljic Matrix]]：按采购类别特性（供应风险 × 利润影响）将物料分为战略型、杠杆型、瓶颈型、常规型，对应差异化采购策略
|
||||
- [[ABC Classification]]：供应商/物料分级管理（A 类战略重点、B 类重要、C 类常规），差异化资源配置
|
||||
- [[QCD Assessment]]：Quality-Quality、Cost、Delivery 三维供应商绩效评分体系，每季度评分年度淘汰
|
||||
- [[TCO Analysis]]：Total Cost of Ownership 全成本拥有权分析，涵盖直接成本、间接成本、隐性成本、全生命周期成本
|
||||
- [[EOQ Model]]：经济订货量模型，平衡订货成本与持有成本
|
||||
- [[Safety Stock & ROP]]：安全库存与再订货点，结合 Z 值与服务水平计算
|
||||
- [[VMI]]：Vendor-Managed Inventory，供应商管理库存，减少买方库存负担
|
||||
- [[JIT Procurement]]：Just-In-Time 准时制采购，降低持有成本但要求供应链高度可靠
|
||||
- [[Supply Chain Digital Maturity]]：供应链数字化成熟度 5 级模型（L1-L5），从手动到自主智能
|
||||
- [[8D Report]]：质量问题闭环解决报告，CAPA 纠正预防措施
|
||||
- [[AQL Sampling]]：Acceptable Quality Limit，来料抽样检验标准（GB/T 2828.1 / ISO 2859-1）
|
||||
- [[RBA Code of Conduct]]：Responsible Business Alliance 电子行业社会责任行为准则
|
||||
- [[SA8000]]：社会责任国际标准，涵盖禁用童工/强迫劳动、工时薪资、职业健康安全
|
||||
- [[ERP-MM]]：SAP Materials Management 模块，物料管理系统
|
||||
- [[SRM Platform]]：Supplier Relationship Management，供应商关系管理平台
|
||||
|
||||
## Key Entities
|
||||
- [[1688/Alibaba]]：中国最大 B2B 电商平台，适合标准件和通用材料采购
|
||||
- [[Made-in-China.com]]：中国制造网，面向出口型工厂的国际贸易平台
|
||||
- [[Global Sources]]：环球资源，高端制造商目录，适合电子和消费品
|
||||
- [[Canton Fair]]：广交会（中国进出口商品交易会），春秋两届全品类供应商集中地
|
||||
- [[SGS/TUV/Bureau Veritas/Intertek]]：第三方检验机构，负责工厂审核和产品认证
|
||||
- [[SAP Ariba]]：全球采购网络平台，适合跨国企业
|
||||
- [[ZhenYun（甄云）]]：全流程数字化采购平台，适合制造业
|
||||
- [[QiQiTong（企企通）]]：中小企业供应商协同平台
|
||||
- [[Yonyou Procurement Cloud]]：用友采购云，与用友 ERP 深度集成
|
||||
- [[Manbang/满帮]]：公路货运匹配平台，用于整车运输
|
||||
- [[Huolala/货拉拉]]：同城及跨城货运匹配平台
|
||||
- [[QiChaCha/Tianyancha]]：企查查/天眼查，企业信息查询平台，用于供应商资质验证
|
||||
- [[Kraljic Matrix]]：卡尔吉克矩阵（采购品类定位工具）
|
||||
|
||||
## Connections
|
||||
- [[Supply Chain Strategist]] ← 供应商管理核心 → [[ABC Classification]]
|
||||
- [[Supply Chain Strategist]] ← 采购策略框架 → [[Kraljic Matrix]]
|
||||
- [[Supply Chain Strategist]] ← 成本决策方法 → [[TCO Analysis]]
|
||||
- [[Supply Chain Strategist]] ← 库存优化工具 → [[EOQ Model]]
|
||||
- [[Supply Chain Strategist]] ← 数字化成熟度 → [[Supply Chain Digital Maturity]]
|
||||
- [[Supply Chain Strategist]] ← 合规审计标准 → [[RBA Code of Conduct]], [[SA8000]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[JIT Procurement]] 的对比：
|
||||
- 冲突点：JIT 追求零库存与安全库存原则之间的平衡
|
||||
- 当前观点：关键物料必须设置安全库存，防止单点供应断裂
|
||||
- 对方观点（纯 JIT 派）：零库存是最优目标，可通过高可靠性供应链实现
|
||||
64
wiki/sources/zk-steward.md
Normal file
64
wiki/sources/zk-steward.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "ZK Steward Agent"
|
||||
type: source
|
||||
tags: [AI-agent, knowledge-management, zettelkasten, luhmann, productivity]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/zk-steward.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：ZK Steward——以 Niklas Luhmann 的 Zettelkasten 精神构建的 AI 时代知识库管家 Agent，通过原子笔记、连接驱动和验证循环实现有机知识网络增长。
|
||||
- 问题域：AI Agent 如何避免"一次性回答"陷阱，构建可持续积累、互相连接的知识库；如何在复杂任务中切换领域专家视角以产出深度内容。
|
||||
- 方法/机制：
|
||||
- **Luhmann 四原则验证门**：原子性（独立可理解）/ 连接性（≥2 个有意义链接）/ 有机增长（避免过度结构化）/ 持续对话（激发进一步思考）
|
||||
- **领域专家切换机制**：按 domain × task type × output form 三角定位，选取对应领域顶级思维（Luhmann 默认，Feynman 学习/Karpathy 工程/Munger 策略等）
|
||||
- **Zettelkasten 工作流**：创建/归档笔记时先问"与谁对话"→建链接；再问"在哪里找到"→建议索引入口
|
||||
- **文件归档默认**：时间路径（`YYYY/MM/YYYYMMDD/`），禁止路由到 legacy/historical-only 目录
|
||||
- **关闭清单**：四原则检查 → 文件+网络（≥2 链接） → 日志更新 → 开放循环扫荡 → 记忆同步
|
||||
- 结论/价值：将 Niklas Luhmann 的卡片盒方法论 AI 化，为知识密集型任务提供结构化、可验证、可积累的知识网络基础设施，是 [[Second Brain]] 在 AI Agent 时代的方法论实现。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- ZK Steward 以 Niklas Luhmann 的 Zettelkasten 方法论为默认视角，切换到各领域顶级专家（Feynman/Munger/Ogilvy/Karpathy 等）按任务类型匹配，产出深度领域内容。
|
||||
- 每个回复必须声明专家视角 + 称呼用户名，拒绝泛泛"专家"或空头方法论引用。
|
||||
- 笔记四原则验证门（原子性/连接性/有机增长/持续对话）强制笔记可独立理解且互连成网。
|
||||
- 新笔记归档时自动触发链接提议（Link-proposer）：候选链接 + 关键词 + Gegenrede 反诘问题。
|
||||
- 任务关闭必须完成： Luhmann 四原则检查 → 文件路径+≥2 链接 → 日志更新 → 开放循环扫荡 → 记忆同步。
|
||||
- 禁止：跳过验证、创建零链接笔记、路由到 legacy-only 目录。
|
||||
|
||||
## Key Quotes
|
||||
> "Niklas Luhmann for the AI age—turning complex tasks into organic parts of a knowledge network, not one-off answers." — ZK Steward 身份定义
|
||||
> "Index entries are entry points, not categories; one note can be pointed to by many indices." — Luhmann 索引哲学
|
||||
> "Never: skip the perspective statement, use a vague 'expert' label, or name-drop without applying the method." — 关键规则
|
||||
|
||||
## Key Concepts
|
||||
- [[Zettelkasten]]：德国社会学家 Niklas Luhmann 发明的手动卡片笔记系统——每条笔记原子化、拥有唯一 ID、与至少一条其他笔记相连，通过积累形成有机知识网络。ZK Steward 将其 AI 化，以时间路径归档、索引入口导向、多链接驱动为核心理念。
|
||||
- [[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话）：ZK Steward 的强制验证门，每条笔记必须通过四个维度检查方可归档，是 Zettelkasten 方法论的执行性约束。
|
||||
- [[Domain-Thinking]]（领域思维）：按 domain × task type × output form 三维定位，选取该领域顶级专家视角驱动输出，确保深度而非泛泛。
|
||||
- [[Gegenrede]]（反诘）：链接提议后提出一个跨学科反问，激发笔记间的辩证对话，防止同质化链接。
|
||||
- [[Atomic-Note]]（原子笔记）：可独立理解、最小粒度的知识单元，是 Zettelkasten 的基本构建块。
|
||||
- [[Link-Proposer]]（链接提议器）：新笔记归档时自动运行的流程——输出候选链接 + 关键词 + Gegenrede 反诘问题。
|
||||
- [[Daily-Log]]（每日日志）：`memory/YYYY-MM-DD.md` 格式，记录 Intent / Changes / Open loops，维持知识网络的时效性。
|
||||
|
||||
## Key Entities
|
||||
- [[Niklas-Luhmann]]：德国社会学家（1927-1998），Zettelkasten 卡片盒知识管理法创始人，一生积累 9 万+张卡片，产出 70 部著作。ZK Steward 以其为默认视角。
|
||||
- [[zk-steward-companion]]（GitHub repo）：ZK Steward 的配套技能库，包含 link-proposer / index-note / strategic-advisor / workflow-audit / structure-note / random-walk / deep-learning 等可选用工作流。
|
||||
- **Karpathy**：AI/工程领域专家，按 domain-thinking 映射表对应 Tech/engineering 领域。
|
||||
- **Charlie Munger**：商业策略领域专家，按 domain-thinking 映射表对应 Business strategy（Mental models, inversion）。
|
||||
- **Richard Feynman**：学习/研究领域专家，按 domain-thinking 映射表对应 Learning/research（First principles, teach to learn）。
|
||||
- **David Ogilvy**：品牌营销领域专家，对应 Brand marketing（Long copy, brand persona）。
|
||||
|
||||
## Connections
|
||||
- [[zk-steward]] ← implements ← [[Zettelkasten]]
|
||||
- [[zk-steward]] ← applies ← [[Niklas-Luhmann]]
|
||||
- [[zk-steward]] ← uses ← [[Luhmann-四原则]]
|
||||
- [[zk-steward]] ← triggers ← [[Link-Proposer]]
|
||||
- [[zk-steward]] ← follows ← [[Domain-Thinking]]
|
||||
- [[zk-steward]] ← part_of ← [[zk-steward-companion]]
|
||||
- [[Second-Brain]] ← related_to ← [[zk-steward]]（两者同属外部认知能力建设，Second Brain 为通用框架，ZK Steward 为具体 Agent 实现）
|
||||
- [[养虾日记3]] ← mentions ← [[zk-steward]]（"融合了 Karpathy 的 LLM Wiki 理念"即指 zk-steward 类型的 Zettelkasten 工作流）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Second-Brain]] 关系：两者均强调外部知识积累，但 Second Brain 侧重捕获与检索的零摩擦（"像发短信一样简单"），ZK Steward 侧重强制结构化验证（ Luhmann 四原则）和多专家视角切换。两者互补，Second Brain 作为捕获层，ZK Steward 作为结构化处理层。
|
||||
- 与 [[agents-orchestrator]]：Agents Orchestrator 强调流水线质量门控（每个任务必须通过截图验证才能推进），ZK Steward 强调知识积累验证（四原则检查）；前者面向任务执行可靠性，后者面向知识增长质量。
|
||||
Reference in New Issue
Block a user