Auto-sync: 2026-04-21 00:02

wiki/concepts/ABC-Classification.md

@@ -0,0 +1,28 @@
+---
+title: "ABC 分类法"
+type: concept
+tags: [supply-chain, supplier-management]
+---
+
+## Definition
+ABC 分类法是一种供应商分级管理策略，根据供应商的战略重要性和采购金额将供应商分为不同等级，实施差异化管理策略。
+
+## 分类标准
+
+| 类型 | 采购金额占比 | 管理策略 |
+|------|--------------|----------|
+| **战略供应商** (Strategic) | Top 10-20% | 深度合作、联合开发、战略联盟 |
+| **杠杆供应商** (Leverage) | 20-30% | 竞争性管理、总量平衡 |
+| **瓶颈供应商** (Bottleneck) | 10-20% | 寻找替代源、保持库存 |
+| **常规供应商** (Routine) | 30-40% | 简化流程、自动化采购 |
+
+## 与 Kraljic Matrix 的关系
+- ABC 分类法侧重**供应商层面**的分级管理
+- Kraljic Matrix 侧重**采购品类层面**的策略制定
+- 两者常配合使用：Kraljic 分类确定品类策略，ABC 分类确定供应商关系深度
+
+## Connections
+- [[Supply Chain Strategist]] ← uses ← [[ABC 分类法]]
+- [[Kraljic Matrix]] — ABC 分类与 Kraljic Matrix 配合制定采购策略
+- [[供应商绩效考核]] — 绩效考核结果用于 ABC 分级调整
+

wiki/concepts/Anachronism.md

@@ -0,0 +1,48 @@
+---
+title: "Anachronism"
+type: concept
+tags: [history, worldbuilding, validation]
+last_updated: 2026-04-20
+---
+
+## Definition
+时代错误（Anachronism）是指在历史背景中引入不属于该时期的人物、物体、观念或技术的错误。
+
+## Two Types
+
+### Obvious Anachronism（明显时代错误）
+- 哥伦布前的欧洲出现土豆
+- 古罗马使用电力
+- 中世纪欧洲出现印刷机（古腾堡印刷机约1440年）
+
+### Subtle Anachronism（微妙时代错误）
+更难检测，通常涉及：
+- **Attitudes（态度）**：赋予古代人物现代价值观
+- **Social structures（社会结构）**：使用现代组织概念理解古代社会
+- **Economic systems（经济系统）**：用现代经济逻辑理解古代贸易
+- **Language（语言）**：使用后来才出现的词汇或表达方式
+
+## Why It Matters
+- 破坏历史叙事的可信度
+- 反映对历史的误解或刻板印象
+- 强化流行的历史神话
+
+## Academic Historian 的检测方法
+1. 建立坐标：时间和地点要精确
+2. 先检查物质基础：经济、技术、农业
+3. 再检查社会结构：权力、阶级、性别、宗教
+4. 评估声明的可信度：标注置信度
+
+## Examples of Subtle Anachronism
+- 认为中世纪农民渴望"自由"（"自由"概念在工业革命后才普遍化）
+- 用现代"民族国家"概念理解古代帝国
+- 认为古代人物有现代意义上的"个人权利"概念
+
+## Related Concepts
+- [[Historical Coherence Check]]：检测时代错误的工具
+- [[Period Authenticity Report]]：系统性避免时代错误的框架
+- [[Material Culture]]：物质文化是检测时代错误的基础
+- [[Presentism]]：现代价值观投射，是一种微妙时代错误
+
+## Source
+Academic Historian Agent — The Agency 项目

wiki/concepts/Annales-School.md

@@ -0,0 +1,48 @@
+---
+title: "Annales School"
+type: concept
+tags: [history, historiography, methodology, france]
+last_updated: 2026-04-20
+---
+
+## Definition
+年鉴学派是20世纪法国最重要的史学运动之一，强调历史研究的跨学科方法，关注长时段、物质条件和结构力量，对全球史学产生深远影响。
+
+## Historical Development
+### 第一代（1929-1946）
+- 创始人：马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）
+- 期刊：《年鉴：物质文明、经济史和社会》（Annales d'histoire économique et sociale）
+
+### 第二代（1950-1970）
+- 核心人物：费尔南·布罗代尔（Fernand Braudel）
+- 代表作：《菲利普二世时代的地中海和地中海世界》（1949）
+- 提出三层时间结构：地理时间、社会时间、事件时间
+
+### 第三代（1970年代后）
+- 转向计量史、新文化史
+- 关注心态史、身体史、记忆史
+
+## Core Principles
+1. **长时段（Longue Durée）**：历史变化发生在缓慢的时间尺度上
+2. **物质条件优先**：经济、技术、地理决定社会结构
+3. **跨学科**：融合地理学、经济学、社会学、人类学
+4. **反事件史**：批评过分关注政治事件和伟大人物
+
+## Key Figures
+- 马克·布洛赫：《封建社会》（1939）
+- 吕西安·费弗尔：《16世纪的信奉问题》（1940）
+- 费尔南·布罗代尔：《地中海》（1949）、《资本主义与物质生活》（1967）
+- 雅克·勒高夫：《中世纪的身体与怜悯》（1974）
+
+## Critical Reception
+- **贡献**：拓宽史学视野，强调结构和社会底层
+- **批评**：过度决定论，忽视人类能动性；欧洲中心主义倾向
+
+## Related Concepts
+- [[Longue Durée]]：年鉴学派的核心方法论
+- [[Material Culture]]：年鉴学派的核心关注点
+- [[Microhistory]]：作为对年鉴学派的回应而兴起
+- [[Academic Historian]]：Academic Historian 的方法论工具
+
+## Source
+《年鉴》杂志，费弗尔和布洛赫创办（1929）

wiki/concepts/Attachment-Theory.md

@@ -0,0 +1,42 @@
+---
+title: "Attachment Theory"
+type: concept
+tags: [developmental-psychology, relationships, attachment]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Attachment Theory
+
+## Aliases
+- 依恋理论
+- 依恋风格
+- Attachment Style
+
+## Summary
+John Bowlby 提出的发展心理学理论，描述亲子间的情感纽带如何影响个体的成人关系模式。Mary Ainsworth 通过陌生情境实验识别出三种幼儿依恋类型，后扩展为四种成人依恋风格。
+
+## Core Concepts
+### 依恋风格分类
+- **安全型（Secure）**：信任他人，舒适亲密关系，能依赖也能独立
+- **焦虑-先占型（Anxious-Preoccupied）**：过度依赖，害怕被抛弃，高度情绪化
+- **回避-忽视型（Dismissive-Avoidant）**：情感隔离，贬低亲密价值，强调独立
+- **恐惧-回避型（Fearful-Avoidant）**：既渴望又恐惧亲密，关系中犹豫不决
+
+### 核心机制
+- 内在运作模型（Internal Working Model）：基于早期经历形成的自我和他人的心理表征
+- 依恋对象的可及性（Attachment Figure's Accessibility）
+
+## Applications
+- [[Academic Psychologist Agent]] 分析浪漫、家庭、友谊关系动态
+- 识别角色触发点和冲突升级模式
+- 设计可信的角色发展弧线
+
+## Cultural Considerations
+- 依恋理论源于西方个体主义语境
+- 集体主义文化中"健康"依恋模式可能呈现不同表现
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析框架 ← [[依恋理论]]
+- [[Big Five Personality Framework]] ← 互补框架 ← [[依恋理论]]
+- [[John Bowlby]] ← 理论创始人 ← [[依恋理论]]

wiki/concepts/Audit-Readiness.md

@@ -0,0 +1,30 @@
+---
+title: "Audit Readiness"
+type: concept
+tags: [compliance, audit, security]
+---
+
+## 定义
+评估组织当前安全态势是否符合目标框架（如 SOC 2、ISO 27001、HIPAA、PCI-DSS）要求的状态。
+
+## 目的
+提供领导层对认证时间线的真实可见性，识别需要修复的控制差距。
+
+## 组成部分
+- 当前安全态势评估
+- 控制差距识别
+- 优先修复计划
+- 就绪度评分卡
+
+## 关键原则
+- 每个差距发现必须包含：具体控制参考、当前状态、目标状态、修复步骤、估计工作量
+- 就绪度评分应基于实际测试，而非仅文档审查
+
+## 相关框架
+- [[SOC-2]]
+- [[ISO-27001]]
+- [[HIPAA]]
+- [[PCI-DSS]]
+
+## 相关实体
+- [[Compliance Auditor]]

wiki/concepts/Audit-Trail.md

@@ -18,4 +18,5 @@ Audit Trail 是记录关键操作、决策与结果的可追溯日志，通常
 ## Related Entities
 - [[Accounts Payable Agent]]
 - [[Agentic Identity & Trust Architect]]
+- [[Sales Data Extraction Agent]]
 - [[The Agency]]

wiki/concepts/Barthes-五代码.md

@@ -0,0 +1,22 @@
+---
+title: "Barthes 五代码"
+type: concept
+tags: [narrative-theory, semiotics, meaning-codes]
+---
+
+## 定义
+Roland Barthes 在《S/Z》中提出的叙事符号学框架，将文本意义分解为五个代码系统。
+
+## 五个代码
+1. **Hermeneutic Code（谜团代码）**：制造和延迟揭示谜底的问题序列
+2. **Proairetic Code（行为代码）**：行动结果的序列，标识接下来会发生什么
+3. **Semantic Code（语义代码）**：意义层次的标记，揭示角色的社会、心理属性
+4. **Symbolic Code（象征代码）**：通过反复出现形成更深层主题的意象
+5. **Cultural Code（文化代码）**：引用社会、历史、科学、文学等共同知识的代码
+
+## 核心方法
+- **Les cinq codes**：将叙事文本分解为五种意义生成路径
+- **Lexies（lexia）**：最小叙事单元，每个lexia可归属不同代码
+
+## 来源框架
+- [[Narratologist]] 使用此框架进行 semiotic analysis of narrative meaning

wiki/concepts/Big-Five-Personality-Framework.md

@@ -0,0 +1,38 @@
+---
+title: "Big Five Personality Framework"
+type: concept
+tags: [personality-psychology, big-five, trait-theory]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Big Five Personality Framework
+
+## Aliases
+- 大五人格框架
+- Five-Factor Model (FFM)
+- OCEAN Model
+
+## Summary
+描述人格结构的五因素模型，通过开放性、尽责性、外向性、宜人性、神经质五个维度评估个体差异，是人格心理学中经验支持最充分的框架之一。
+
+## Core Dimensions
+- **Openness（开放性）**：想象力、好奇心、审美能力
+- **Conscientiousness（尽责性）**：自律、条理性、成就导向
+- **Extraversion（外向性）**：社交性、活力、主导性
+- **Agreeableness（宜人性）**：信任、利他、顺从
+- **Neuroticism（神经质）**：情绪不稳定、焦虑、抑郁倾向
+
+## Applications
+- [[Academic Psychologist Agent]] 角色心理画像核心框架
+- 评估角色行为一致性
+- 预测角色在压力下的反应模式
+
+## Limitations
+- 描述性而非解释性（不说明人格如何形成）
+- 文化偏差：某些特质在不同文化中内涵不同
+- 过度简化：五因素可能遗漏重要特质
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析框架 ← [[Big Five Personality Framework]]
+- [[依恋理论]] ← 互补框架 ← [[Big Five Personality Framework]]

wiki/concepts/Bulkification.md

@@ -0,0 +1,28 @@
+---
+title: "Bulkification"
+type: concept
+tags: [salesforce, triggers, best-practices]
+sources: [specialized-salesforce-architect.md]
+last_updated: 2026-04-20
+---
+
+# Bulkification
+
+Salesforce 触发器必须能够批量处理多条记录的机制。
+
+## 要求
+- 触发器逻辑绝不能一次只处理一条记录
+- 代码必须能在 200 条记录的批量操作下正常工作
+- 如果代码在 200 条记录时会失败，则视为错误
+
+## 实现方式
+- 使用 Maps 存储数据
+- 避免在循环中执行 SOQL 或 DML
+- 使用 Sets 和 Lists 批量操作
+
+## 相关概念
+- [[Governor-Limits]] — 批量处理是为了遵守 Governor Limits
+- [[Trigger-Framework]] — 触发器框架实现
+
+## 来源
+[[Salesforce-Architect]] 智能体的核心设计原则

wiki/concepts/CES.md

@@ -0,0 +1,29 @@
+---
+title: "CES"
+type: concept
+tags: [Customer Analytics, Effort Metric]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+CES（Customer Effort Score，客户努力程度评分）衡量客户完成某项任务（如解决问题）所需付出的努力程度。
+
+## Calculation
+通常使用李克特7点量表（强烈不同意到强烈同意）：
+```
+"这个产品/服务让我轻松完成了我的任务"
+```
+
+低 CES 分数表示更好的用户体验。
+
+## Purpose
+- 衡量客户体验流程的顺畅程度
+- 识别需要改进的摩擦点
+- 预测客户留存可能性
+
+## Connections
+- [[Product Feedback Synthesizer]]：收集和分析CES数据
+- [[CSAT]]：客户满意度指标
+- [[NPS分析]]：忠诚度指标
+- [[流失预测]]：流失预警的输入指标

wiki/concepts/CSAT.md

@@ -0,0 +1,32 @@
+---
+title: "CSAT"
+type: concept
+tags: [Customer Analytics, Satisfaction Metric]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+CSAT（Customer Satisfaction Score，客户满意度评分）是一种衡量客户对特定交互或整体体验满意程度的指标。
+
+## Calculation
+通常采用李克特量表（1-5分或1-10分）问卷调查：
+```
+CSAT = (满意客户数 / 总客户数) × 100%
+```
+
+或计算平均分：
+```
+平均CSAT = 总满意度分数 / 响应数
+```
+
+## Usage
+- 交易后立即测量客户满意度
+- 跟踪服务或功能满意度变化
+- 与 NPS 结合使用形成完整的客户体验视图
+
+## Connections
+- [[Product Feedback Synthesizer]]：收集和分析CSAT数据
+- [[NPS分析]]：结合使用的忠诚度指标
+- [[CES]]：衡量客户努力程度
+- [[流失预测]]：满意度建模的输入指标

wiki/concepts/Calibration-Testing.md

@@ -0,0 +1,24 @@
+---
+title: "Calibration Testing"
+type: concept
+tags: [ml-ops, evaluation, calibration]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+校准测试用于评估模型预测概率是否与真实发生率一致。
+
+## Common Methods
+- Hosmer-Lemeshow test
+- Brier score
+- Reliability diagrams
+
+## Use in Model QA
+- 检查概率输出是否可信
+- 比较不同子群体的校准差异
+- 评估分布漂移下的概率稳定性
+
+## Related Concepts
+- [[Model Audit]]
+- [[Discrimination Metrics]]

wiki/concepts/Campbell-英雄之旅.md

@@ -0,0 +1,35 @@
+---
+title: "Campbell 英雄之旅"
+type: concept
+tags: [narrative-theory, story-structure, hero-journey]
+---
+
+## 定义
+Joseph Campbell 在《千面英雄》中提出的单一神话理论（The Hero with a Thousand Faces），认为全世界的神话故事都遵循同一个基本叙事结构。
+
+## 核心阶段
+1. **分离（Departure）**：离开日常世界，进入冒险领域
+   - Call to Adventure（冒险召唤）
+   - Refusal of the Call（拒绝召唤）
+   - Meeting the Mentor（遇见导师）
+   - Crossing the Threshold（跨越门槛）
+2. **启蒙（Initiation）**：经历考验和转变
+   - Trials and Tribulations（考验与磨难）
+   - Approach to the Inmost Cave（接近最深处洞穴）
+   - Ordeal（严峻考验）
+   - Reward（获得奖赏）
+3. **回归（Return）**：带着力量回归日常世界
+   - The Road Back（回归之路）
+   - Resurrection（复活/重生）
+   - Return with the Elixir（带着灵药回归）
+
+## 变体
+- [[Vogler 作家旅程]]：Christopher Vogler 将 Campbell 理论应用于现代编剧实践
+
+## 应用领域
+- 电影剧本结构分析
+- 游戏叙事设计
+- 品牌故事构建
+
+## 来源框架
+- [[Narratologist]] 使用此框架分析英雄叙事结构

wiki/concepts/Character-Arc.md

@@ -0,0 +1,31 @@
+---
+title: "Character Arc"
+type: concept
+tags: [narrative-theory, character, story-structure]
+---
+
+## 定义
+角色弧线是角色从故事开始到结束的心理和情感发展轨迹。
+
+## 核心检查点（[[Narratologist]] 标准）
+1. **Ordinary World（普通世界）**：角色初始状态
+2. **Catalyst（催化剂）**：打破平衡的事件
+3. **Midpoint Shift（转折点）**：虚假胜利或虚假失败
+4. **Dark Night（黑暗之夜）**：最低点
+5. **Transformation（转变）**：谎言/需要冲突的最终解决
+
+## 弧线类型
+- **Transformative（转变型）**：角色经历根本性改变
+- **Steadfast（坚定型）**：角色坚守信念但影响他人
+- **Flat（扁平型）**：角色信念被验证但不改变
+- **Tragic（悲剧型）**：角色因致命缺陷而毁灭
+- **Comedic（喜剧型）**：角色通过放下执念获得成长
+
+## Want vs Need 结构
+- **Want（欲望）**：角色外在追求的目标
+- **Need（需求）**：角色内心真正需要的成长
+- **Lie（谎言）**：角色持有的错误信念
+- **Truth（真相）**：最终打破谎言的认知
+
+## 来源框架
+- [[Narratologist]] 使用此框架评估角色弧线的完整性和一致性

wiki/concepts/Checks-Effects-Interactions.md

@@ -0,0 +1,41 @@
+---
+title: "Checks-Effects-Interactions"
+type: concept
+tags: [smart-contract, pattern, security]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+Checks-Effects-Interactions（检查-效果-交互）是一种智能合约安全设计模式，通过在执行外部调用前完成所有状态更新来防止重入攻击。
+
+## Pattern
+```solidity
+function withdraw() external nonReentrant {
+    // 1. CHECKS: 验证条件
+    uint256 amount = balances[msg.sender];
+    require(amount > 0, "No balance");
+
+    // 2. EFFECTS: 更新状态
+    balances[msg.sender] = 0;
+
+    // 3. INTERACTIONS: 执行外部调用
+    (bool success,) = msg.sender.call{value: amount}("");
+    require(success, "Transfer failed");
+}
+```
+
+## Why It Works
+1. 状态在外部调用前已更新
+2. 攻击者重入时检查失败
+3. 即使外部调用失败，状态也不会不一致
+
+## Limitations
+- 复杂业务逻辑可能无法严格遵循
+- 需要配合 ReentrancyGuard 作为额外防护
+- 异步操作（如 event emission）应在交互后执行
+
+## Connections
+- [[Reentrancy]] ← prevents ← [[Checks-Effects-Interactions]]
+- [[Smart Contract Pattern]] ← is_type_of ← [[Checks-Effects-Interactions]]
+

wiki/concepts/Cognitive-Distortions.md

@@ -0,0 +1,63 @@
+---
+title: "Cognitive Distortions"
+type: concept
+tags: [cognitive-psychology, cbt, cognitive-distortions]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Cognitive Distortions
+
+## Aliases
+- 认知扭曲
+- 非理性思维
+- Beck Cognitive Distortions
+
+## Summary
+Aaron Beck 提出的概念，描述导致情绪困扰的常见非理性思维模式。认知扭曲是认知行为疗法（CBT）的核心干预目标。
+
+## Common Types
+
+### 绝对化思维（All-or-Nothing Thinking）
+非黑即白，无中间地带
+> "如果我不是完美，我就是失败"
+
+### 过度概括（Overgeneralization）
+以单一负面事件得出普遍结论
+> "这件事失败了，所以我永远都不会成功"
+
+### 灾难化（Catastrophizing）
+高估负面事件的可能性和影响
+> "如果这次面试失败，我的人生就完了"
+
+### 心理过滤（Mental Filter）
+只关注负面细节而忽略正面证据
+
+### 贬低积极体验（Disqualifying the Positive）
+将正面经历归因为运气而非真实成就
+
+### 跳跃式结论（Mind Reading / Fortune Telling）
+在无证据情况下假设他人负面看法或预测负面结果
+
+### 情感推理（Emotional Reasoning）
+将情绪当作事实的证据
+> "我感到焦虑，所以一定有危险"
+
+### "应该"陈述（Should Statements）
+使用强制性"应该"导致内疚或愤怒
+
+### 标签化（Labeling）
+以单一缺点给整个人贴标签
+
+### 个人化（Personalization）
+将外部事件过度个人化，无根据承担责任感
+
+## Applications
+- [[Academic Psychologist Agent]] 识别驱动角色决策的具体认知扭曲
+- 设计认知重构干预点
+- 分析角色在压力下的思维模式变化
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析工具 ← [[认知扭曲]]
+- [[Aaron Beck]] ← 创始人 ← [[认知扭曲]]
+- [[Cognitive Behavioral Therapy]] ← 相关疗法 ← [[认知扭曲]]

wiki/concepts/Cognitive-Load-Reduction.md

@@ -0,0 +1,26 @@
+---
+title: "Cognitive Load Reduction"
+type: concept
+tags: [ux, behavioral-psychology, productivity]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+通过将大量工作流拆分为最小的无摩擦动作，防止用户因决策瘫痪而放弃的核心原则。
+
+## Mechanism
+- 不展示"你有 14 条未读通知"
+- 只展示最关键的 1 个单一行动项
+- 每次推送都提供单一、可操作、低摩擦的下一步
+
+## Key Rule
+> "Never send a generic 'You have 14 unread notifications' alert. Always provide a single, actionable, low-friction next step."
+
+## Related Concepts
+- [[Micro-Sprint]]
+- [[Momentum Nudge]]
+- [[Default Bias]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← implements ← [[Cognitive Load Reduction]]

wiki/concepts/Competitive-Intelligence.md

@@ -0,0 +1,23 @@
+---
+title: "Competitive Intelligence"
+type: concept
+tags: [competition, swot, market-positioning]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+竞争情报是系统化收集和分析竞争对手信息的方法，用于制定竞争定位和差异化策略。
+
+## Competitive Landscape
+- 直接竞争对手：功能对比、定价、市场定位
+- 间接竞争对手：替代方案、邻近市场
+- 新兴玩家：初创企业、新进入者
+- 技术提供商：平台策略、基础设施创新
+- 客户替代方案：DIY 解决方案、变通方案
+
+## Frameworks
+- SWOT 分析（优势/劣势/机会/威胁）
+- 市场差距分析（Market Gap Analysis）
+- 竞争定位分析（Competitive Positioning）
+- 替代威胁评估（Substitution Threat Assessment）

wiki/concepts/Consumer-Behavior-Analysis.md

@@ -0,0 +1,23 @@
+---
+title: "Consumer Behavior Analysis"
+type: concept
+tags: [consumer, behavior, user-research]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+消费者行为分析是研究用户决策过程、使用模式和未满足需求的方法，用于指导产品策略。
+
+## Core Areas
+- **Purchase Journey Mapping**：从认知到倡导的完整旅程
+- **Decision Factors**：价格敏感度、功能偏好、品牌忠诚度
+- **Usage Patterns**：使用频率、场景、满意度
+- **Unmet Needs**：差距分析、痛点、机会识别
+- **Adoption Barriers**：技术壁垒、金融壁垒、文化壁垒
+
+## Research Methods
+- 人口统计研究（Demographic Studies）
+- 心理图形分析（Psychographics）
+- 购买模式分析（Buying Patterns）
+- 行为聚类（Behavioral Clustering）

wiki/concepts/Continuous-Compliance.md

@@ -0,0 +1,30 @@
+---
+title: "Continuous Compliance"
+type: concept
+tags: [compliance, automation, security]
+---
+
+## 定义
+在正式审计周期之间维持合规状态的持续过程，而非一次性认证事件。
+
+## 核心理念
+合规不是一次性项目，而是持续运营状态。
+
+## 关键活动
+- **自动化证据收集管道**：设置持续证据收集流程，减少审计准备时间
+- **季度控制测试**：在年度审计之间定期测试控制有效性
+- **监管变化追踪**：跟踪影响合规计划的监管变化
+- **月度合规态势报告**：向领导层报告合规状态
+
+## 价值主张
+- 减少年度审计准备压力
+- 提前发现控制失效
+- 持续改进而非临时应对
+
+## 实施要点
+- 从第一天就自动化证据收集
+- 使用共同控制框架满足多种认证
+- 技术控制优先于管理控制
+
+## 相关实体
+- [[Compliance Auditor]]

wiki/concepts/Controls-Implementation.md

@@ -0,0 +1,33 @@
+---
+title: "Controls Implementation"
+type: concept
+tags: [compliance, security, controls]
+---
+
+## 定义
+设计并实施满足合规要求同时适应现有工程工作流的控制措施。
+
+## 核心目标
+- 控制必须满足合规要求
+- 控制必须融入现有工程工作流
+- 控制必须可测试和可验证
+
+## 实施原则
+- **自动化优先**：自动化证据收集从第一天开始——手动流程无法扩展
+- **技术控制优于管理控制**：代码比培训更可靠
+- **共同控制框架**：使用共同控制框架满足多种认证
+
+## 关键活动
+- 设计满足合规要求的控制
+- 构建自动化证据收集流程
+- 创建工程师会遵循的政策（简短、具体、集成到现有工具）
+- 建立控制失败监控和告警
+
+## 相关框架
+- [[SOC-2]]
+- [[ISO-27001]]
+- [[HIPAA]]
+- [[PCI-DSS]]
+
+## 相关实体
+- [[Compliance Auditor]]

wiki/concepts/Default-Bias.md

@@ -0,0 +1,26 @@
+---
+title: "Default Bias"
+type: concept
+tags: [behavioral-psychology, persuasion, user-engagement]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+利用用户默认倾向（如接受预起草内容）来提升行动完成率的行为心理学原理。
+
+## Mechanism
+- 预起草回复、方案、内容
+- 用户只需确认或微调，而非从零开始
+- 减少决策摩擦，提升完成率
+
+## Example
+> "I've drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?"
+
+## Related Concepts
+- [[Momentum Nudge]]
+- [[Opt-Out Completion]]
+- [[Cognitive Load Reduction]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← leverages ← [[Default Bias]]

wiki/concepts/Discovery-Process.md

@@ -0,0 +1,37 @@
+---
+title: "Discovery Process"
+type: concept
+tags: [product-management, discovery, user-research]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+发现阶段是产品开发周期的第一阶段，通过系统化用户研究、行为数据分析和 Support 信号挖掘来定义要解决的问题。
+
+## Activities
+1. **Structured Problem Interviews**：最少 5-10 次结构化问题访谈
+2. **Behavioral Analytics Mining**：挖掘摩擦模式、drop-off 点和意外使用
+3. **Support Tickets Audit**：审计 Support 票据和 NPS 评语发现重复主题
+4. **User Journey Mapping**：映射当前端到端用户旅程，找出挣扎、放弃或绕过产品的节点
+5. **Synthesis**：将发现合成清晰、证据-backed 的问题陈述
+
+## Output
+- 清晰的问题陈述（Problem Statement）
+- 用户痛点的优先级列表
+- 支持每个问题的证据（访谈引用、数据指标、Support 信号）
+
+## Key Principle
+- 分享原始信号，不只是结论——设计、工程和领导层都应看到原始数据
+- 在验证问题前不讨论解决方案
+- Discovery 质量决定后续所有工作的方向
+
+## Minimum Evidence Threshold
+每个 >2 周工作量的 initiative 必须至少有：
+- 5 次用户访谈，或
+- 等效的行为证据
+
+## Connection
+- [[Discovery Process]] ← conducted_by ← [[Product Manager Agent]]
+- [[Discovery Process]] ← outputs ← [[Product Requirements Document (PRD)]]
+- [[Opportunity Assessment]] ← follows ← [[Discovery Process]]

wiki/concepts/Discrimination-Metrics.md

@@ -0,0 +1,25 @@
+---
+title: "Discrimination Metrics"
+type: concept
+tags: [ml-ops, evaluation, classification]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+歧视度量指标用于衡量模型区分正负样本的能力。
+
+## Common Metrics
+- AUC
+- Gini coefficient
+- KS statistic
+- F1 / precision / recall（按任务需要）
+
+## Use in Model QA
+- 判断模型是否具备可接受的区分能力
+- 监控不同数据切分上的性能一致性
+- 与校准测试一起评估整体质量
+
+## Related Concepts
+- [[Calibration Testing]]
+- [[Model Audit]]

wiki/concepts/EOQ.md

@@ -0,0 +1,38 @@
+---
+title: "EOQ（经济订货量）"
+type: concept
+tags: [supply-chain, inventory-management]
+---
+
+## Definition
+EOQ（Economic Order Quantity，经济订货量）是通过公式计算的最优订货量，平衡订货成本和库存持有成本。
+
+## Formula
+
+```
+EOQ = √(2DS/H)
+
+其中：
+D = 年需求量（Annual demand quantity）
+S = 每次订货成本（Cost per order）
+H = 单位持有成本（Holding cost rate × unit price）
+```
+
+## Example
+- 年需求量 D = 10,000 件
+- 订货成本 S = ¥500/次
+- 单价 ¥100，持有成本率 20%
+- H = ¥100 × 20% = ¥20
+
+```
+EOQ = √(2 × 10000 × 500 / 20) = √500,000 = 707 件
+```
+
+## Related Concepts
+- **ROP（Reorder Point，再订货点）**：ROP = 日均需求 × 交期天数 + 安全库存
+- **安全库存（Safety Stock）**：SS = Z × σdLT，防止缺货的缓冲库存
+
+## Connections
+- [[Supply Chain Strategist]] ← uses ← [[EOQ（经济订货量）]]
+- [[库存管理策略]] — EOQ 是库存管理策略的核心计算工具
+

wiki/concepts/ESN-Margin.md

@@ -0,0 +1,33 @@
+---
+title: "ESN Margin"
+type: concept
+tags: [business-model, france, esn]
+date: 2026-04-20
+---
+
+## Summary
+ESN 在 TJM brut（向客户收取）和支付给顾问费率之间的加价差额，是法国 ESN 商业模式的核心。
+
+## Definition
+```
+Client pays: 1,000 EUR/day (sell rate)
+              │
+        ESN Margin
+        25-40%
+              │
+ESN pays consultant: 600-750 EUR/day (buy rate / TJM brut)
+```
+
+## Margin Ranges by Tier
+| Tier | Margin | Freelancer Impact |
+|------|--------|-------------------|
+| Tier 1 | 35-50% | Low leverage, standardized |
+| Tier 2 | 25-40% | Medium leverage, negotiable |
+| Tier 3 | 15-25% | High leverage, volume play |
+
+## Key Insight
+"同一 Salesforce 架构师通过一个渠道报价 450/day，通过另一个渠道报价 850/day" — 差异来源就是 margin 结构和议价能力。
+
+## Connections
+- [[ESN Tier Classification]] ← tier_specific
+- [[French Consulting Market Navigator]] ← margin_analysis

wiki/concepts/Evidence-Collection.md

@@ -0,0 +1,30 @@
+---
+title: "Evidence Collection"
+type: concept
+tags: [compliance, audit, automation]
+---
+
+## 定义
+系统化收集证明控制有效运作的证据的过程。
+
+## 核心原则
+- **自动化收集**：手动证据是脆弱的证据——自动化收集从第一天开始
+- **证据证明有效性**：证据必须证明控制在审计期间有效运作，而不仅是今天存在
+
+## 证据收集矩阵
+| 控制 ID | 控制描述 | 证据类型 | 来源 | 收集方法 | 频率 |
+|---------|----------|----------|------|----------|------|
+| CC6.1 | 逻辑访问控制 | 访问审查日志 | Okta | API 导出 | 季度 |
+| CC6.2 | 用户配置 | 入职工单 | Jira | JQL 查询 | 事件触发 |
+| CC7.1 | 系统监控 | 告警配置 | Datadog | 仪表板导出 | 月度 |
+
+## 证据组织
+按控制目标组织证据包，而非按内部团队结构。
+
+## 关键要求
+- 证据必须可重复获取
+- 证据必须有时间戳
+- 证据必须涵盖完整审计期
+
+## 相关实体
+- [[Compliance Auditor]]

wiki/concepts/Fairness-Audit.md

@@ -0,0 +1,25 @@
+---
+title: "Fairness Audit"
+type: concept
+tags: [responsible-ai, fairness, ml-ops]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+公平性审计用于评估模型是否对受保护群体产生系统性偏差。
+
+## Common Checks
+- Demographic parity
+- Equalized odds
+- Performance by subgroup
+- Error-rate disparities
+
+## Use in Model QA
+- 识别不公平影响
+- 评估不同群体的风险差异
+- 作为治理与修复建议的依据
+
+## Related Concepts
+- [[Model Audit]]
+- [[SHAP Analysis]]

wiki/concepts/Flash-Loan-Attack.md

@@ -0,0 +1,38 @@
+---
+title: "Flash Loan Attack"
+type: concept
+tags: [smart-contract, vulnerability, defi, security]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+闪电贷攻击（Flash Loan Attack）是 DeFi 特有的攻击向量，利用闪电贷在单笔交易内借用大量资产、操纵市场状态并获取利润的攻击方式。
+
+## Characteristics
+- **无抵押**：利用区块内临时资金
+- **原子性**：所有操作在单笔交易内完成
+- **大规模**：可借用数百万甚至数亿资产
+- **瞬时性**：交易结束后状态回滚（除非成功）
+
+## Common Targets
+- 借贷协议的抵押品 valuation
+- AMM 流动性池价格
+- 跨协议收益聚合器
+- 治理系统（Flash Loan Voting）
+
+## Attack Patterns
+1. **预言机操纵**：借用资产操纵价格后套利
+2. **重入攻击**：借用资产触发重入漏洞
+3. **治理攻击**：借用代币操纵投票
+
+## Notable Examples
+- Euler Finance ($197M, 2023)：donate-to-reserves 操纵
+- Balancer ($2M, 2021)：嵌套 Flash Loan
+- Cream Finance ($130M, 2021)：Flash Loan + 重入
+
+## Connections
+- [[DeFi Attack Vector]] ← is_type_of ← [[Flash Loan Attack]]
+- [[Oracle Manipulation]] ← often_combines_with ← [[Flash Loan Attack]]
+- [[Reentrancy]] ← can_combine_with ← [[Flash Loan Attack]]
+

wiki/concepts/Formal-Verification.md

@@ -0,0 +1,38 @@
+---
+title: "Formal Verification"
+type: concept
+tags: [smart-contract, security, verification]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+形式化验证（Formal Verification）是使用数学方法证明智能合约正确性的技术，通过对代码进行形式化建模并验证其满足指定属性。
+
+## Methods
+- **Symbolic Execution**：符号执行，遍历代码路径
+- **Model Checking**：模型检验，验证有限状态机
+- **Theorem Proving**：定理证明，数学推导证明
+
+## Tools
+- **Certora**：以太坊智能合约形式化验证
+- **Halmos**：符号执行工具
+- **KEVM**：EVM 形式化规范
+- **Mythril**：符号执行分析
+
+## Use Cases
+- 验证协议不变量（如 total shares × price = total assets）
+- 证明访问控制逻辑正确性
+- 验证数学公式实现正确性
+- 穷举攻击路径
+
+## Limitations
+- 状态空间爆炸问题
+- 需要形式化规范（specification）
+- 工具和专家稀缺
+- 无法证明元编程安全性
+
+## Connections
+- [[Static Analysis]] ← complements ← [[Formal Verification]]
+- [[Smart Contract Security]] ← enables ← [[Formal Verification]]
+

wiki/concepts/Gap-Assessment.md

@@ -0,0 +1,33 @@
+---
+title: "Gap Assessment"
+type: concept
+tags: [compliance, audit, security]
+---
+
+## 定义
+识别组织当前控制状态与目标合规框架要求之间差距的系统化评估过程。
+
+## 目的
+量化当前状态与目标状态之间的差距，为修复工作提供优先级依据。
+
+## 评估维度
+- 控制存在性：控制是否已实施
+- 控制有效性：控制是否按设计运作
+- 证据完整性：是否有足够证据证明控制有效性
+
+## 产出
+- Gap Assessment Report（差距评估报告）
+- 优先级修复路线图
+- 估计审计就绪时间
+
+## 关键原则
+- 每个差距发现必须包含：
+  - 具体控制参考（如 CC6.1）
+  - 当前状态
+  - 目标状态
+  - 修复步骤
+  - 估计工作量
+  - 优先级
+
+## 相关实体
+- [[Compliance Auditor]]

wiki/concepts/Genette-叙事学.md

@@ -0,0 +1,28 @@
+---
+title: "Genette 叙事学"
+type: concept
+tags: [narrative-theory, narratology, voice, focalization]
+---
+
+## 定义
+Gérard Genette 在《叙事话语》中提出的结构主义叙事学理论，关注叙事文本的技术层面。
+
+## 核心概念
+- **叙事时间（Narrative Time）**：
+  - Order（时序）：故事时间与叙事时间的顺序关系（倒叙、预叙等）
+  - Duration（时距）：叙事速度与故事时间的比率（概要、省略、场景、停顿）
+  - Frequency（时频）：事件发生次数与叙事次数的关系
+- **叙事语态（Narrative Mood）**：
+  - Distance（距离）：叙述者与故事的关系
+  - Focalization（聚焦）：感知和认知的视角限定
+- **叙事层次（Narrative Levels）**：
+  - Extradiegetic（超故事层）：叙述者所在层次
+  - Diegetic（故事层）：被叙述的世界
+  - Metadiegetic（元故事层）：故事中嵌套的故事
+
+## 核心区分
+- **Fabula vs Sjuzhet**：故事（按时间顺序的事件）vs 叙事（讲述方式）
+- [[Narratologist]] 强调：Most problems live in the telling (sjuzhet), not the tale (fabula)
+
+## 来源框架
+- [[Narratologist]] 使用此框架分析 voice、focalization 和 temporal structure

wiki/concepts/Geographic-Coherence.md

@@ -0,0 +1,76 @@
+---
+title: "Geographic Coherence"
+type: concept
+tags: [geography, worldbuilding, validation]
+last_updated: 2026-04-20
+---
+
+## Definition
+地理连贯性（Geographic Coherence）是指虚构世界中的地理特征（气候、地形、水文、生物群系、资源分布）符合物理规律，彼此一致，无矛盾。
+
+## Core Principles
+
+### 1. Rivers Don't Split
+- Tributaries merge into rivers（支流汇入主流）
+- Rivers don't fork into two separate rivers flowing to different oceans
+- Exception: deltas, bifurcations — but these are special cases, not the norm
+
+### 2. Climate is a System
+- Rain shadows exist（雨影效应存在）
+- Coastal currents affect temperature（海岸洋流影响温度）
+- Latitude determines seasons（纬度决定季节）
+- Don't place a tropical forest at 60°N latitude without extraordinary justification
+
+### 3. Geography is Not Decoration
+- Every mountain, river, and desert has consequences for the people who live near it
+- If you put a desert there, explain how people get water
+
+### 4. Avoid Geographic Determinism
+- Geography constrains but doesn't dictate
+- Similar environments produce different cultures
+- Acknowledge agency
+
+### 5. Scale Matters
+- A "small kingdom" and a "vast empire" have fundamentally different geographic requirements
+- Communication, supply lines, and governance scale differently
+
+### 6. Maps are Arguments
+- Every map makes choices about what to include and exclude
+- Be aware of the politics of cartography
+
+## Validation Framework
+
+### Geographic Coherence Report
+```
+Region: [Area being analyzed]
+
+Physical Geography:
+- Terrain: [Landforms and their tectonic/erosional origin]
+- Climate Zone: [Koppen classification, latitude, elevation effects]
+- Hydrology: [River systems, watersheds, water sources]
+- Biome: [Vegetation type consistent with climate and soil]
+- Natural Hazards: [Earthquakes, volcanoes, floods, droughts]
+
+Resource Distribution:
+- Agricultural potential: [Soil quality, growing season, rainfall]
+- Minerals/Metals: [Geologically plausible deposits]
+- Timber/Fuel: [Forest coverage consistent with biome]
+- Water access: [Rivers, aquifers, rainfall patterns]
+
+Human Geography:
+- Settlement logic: [Why people would live here — water, defense, trade]
+- Trade routes: [Following geographic paths of least resistance]
+- Strategic value: [Chokepoints, defensible positions, resource control]
+- Carrying capacity: [How many people this geography can support]
+```
+
+## Related Concepts
+- [[Koppen Climate Classification]]
+- [[Central Place Theory]]
+- [[Heartland Theory]]
+- [[World-Systems Theory]]
+- [[Environmental Determinism]]
+
+## Implementation
+- Used by [[Geographer]] Agent in worldbuilding
+- Validates physical consistency in虚构世界构建

wiki/concepts/Go-to-Market-Brief.md

@@ -0,0 +1,42 @@
+---
+title: "Go-to-Market Brief"
+type: concept
+tags: [product-management, launch, gtm]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+GTM Brief 是发布前编写的跨职能协调文档，定义目标受众、价值主张、发布清单、成功标准和回滚预案。
+
+## Structure
+1. **What We're Launching**：一段话描述产品、解决的问题、为什么现在重要
+2. **Target Audience**：细分市场、大小、为什么他们关心、通过什么渠道触达
+3. **Core Value Proposition**：单行公式 + 按受众分组的 messaging
+4. **Launch Checklist**：Engineering、Product、Marketing、Sales/CS 分项清单
+5. **Success Criteria**：按时间框架的指标、目标、负责人
+6. **Rollback & Contingency**：回滚触发条件、负责人、沟通计划
+
+## Launch Tiers
+| Tier | Description |
+|------|-------------|
+| 1 (Major) | 重大发布，公司范围可见 |
+| 2 (Standard) | 标准发布 |
+| 3 (Silent) | 静默发布，无需营销支持 |
+
+## Success Criteria Timeline
+- Launch day：错误率 < 0.5%
+- 7 days：功能激活率 ≥ 20%
+- 30 days：功能用户 vs 对照组留存 +8pp
+- 60 days：相关主题支持票据 −30%
+- 90 days：功能用户 NPS +5 points
+
+## Key Principle
+- 确认 Support 和 CS 在 GA 前接受培训——不是发布当天
+- 翻转 flag 前写好回滚 runbook
+- GA 后 48 小时内发送发布总结给全公司
+
+## Connection
+- [[Product Manager Agent]] ← coordinates ← [[Go-to-Market Brief]]
+- [[Launch Phase]] ← executes ← [[Go-to-Market Brief]]
+- [[Sprint Health Snapshot]] ← monitors ← [[Go-to-Market Brief]]

wiki/concepts/Governor-Limits.md

@@ -0,0 +1,34 @@
+---
+title: "Governor Limits"
+type: concept
+tags: [salesforce, performance, limits]
+sources: [specialized-salesforce-architect.md]
+last_updated: 2026-04-20
+---
+
+# Governor Limits
+
+Salesforce 平台的资源限制约束，是不可妥协的强制性限制。
+
+## 核心限制
+
+| 限制类型 | 同步限制 | 异步限制 |
+|---------|---------|---------|
+| SOQL 查询 | 100 | 200 |
+| DML 语句 | 150 | 150 |
+| CPU 时间 | 10,000ms | 60,000ms |
+| 堆大小 | 6MB | 12MB |
+| Callouts | 100 | 100 |
+| Future 调用 | 50 | 50 |
+
+## 设计原则
+- 每个设计必须精确计算 Governor Limit 剩余量
+- 绝不假设"以后再优化"
+- 批量处理是强制要求
+
+## 相关概念
+- [[Bulkification]] — 批量处理机制
+- [[Trigger-Framework]] — 触发器框架
+
+## 来源
+[[Salesforce-Architect]] 智能体的强制性规则

wiki/concepts/Groupthink.md

@@ -0,0 +1,60 @@
+---
+title: "Groupthink"
+type: concept
+tags: [social-psychology, group-decision-making, janis]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Groupthink
+
+## Aliases
+- 群体思维
+- 群体思维模型
+- Groupthink Model
+
+## Summary
+Irving Janis 1972 年提出的群体决策心理现象，描述高度凝聚的决策团队为维护表面一致而压制异议，导致次优甚至灾难性决策的倾向。
+
+## Core Symptoms
+
+### 过度乐观
+- 团队对风险严重低估
+- 集体忽视道德或伦理警告
+
+### 集体合理化
+- 质疑和挑战的声音被轻视
+- 对负面反馈的集体忽视
+
+### 对外部群体的刻板印象
+- 过度丑化竞争对手或反对者
+- 合理化自身的所有行为
+
+### 从众压力
+- 直接反对者受到同伴压力
+- 自我审查：不表达异议
+
+### 自我任命守卫
+- 非正式成员阻止不同意见
+- 直接压制不同声音
+
+## Prescription Remedies（Janis 建议的干预措施）
+1. 领导者在决策前保持中立，鼓励批评性讨论
+2. 设置"魔鬼代言人"角色
+3. 鼓励小团体分别独立讨论后再汇合
+4. 保留外部专家或成员的多样性视角
+
+## Historical Examples
+- 猪湾入侵（Bay of Pigs）决策
+- 朝鲜战争决策
+- 水门事件掩盖行为
+
+## Applications
+- [[Academic Psychologist Agent]] 分析群体角色动态
+- 理解组织中的集体决策病理
+- 评估群体情境下的角色行为合理性
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析概念 ← [[Groupthink]]
+- [[Irving Janis]] ← 提出者 ← [[Groupthink]]
+- [[Social Identity Theory]] ← 相关理论 ← [[Groupthink]]

wiki/concepts/Historical-Coherence-Check.md

@@ -0,0 +1,46 @@
+---
+title: "Historical Coherence Check"
+type: concept
+tags: [history, worldbuilding, validation]
+last_updated: 2026-04-20
+---
+
+## Definition
+历史一致性检查是 Academic Historian 提供的简洁验证框架，用于评估单个历史声明的准确性。
+
+## Check Structure
+```
+COHERENCE CHECK
+===============
+Claim: [Statement being evaluated]
+Verdict: [Accurate / Partially accurate / Anachronistic / Myth]
+Evidence: [Source and reasoning]
+Confidence: [High / Medium / Low — and why]
+If fictional/inspired: [What historical parallels exist, what diverges]
+```
+
+## Verdict Categories
+- **Accurate**：有充分史料支撑的声明
+- **Partially accurate**：主体正确但细节有误
+- **Anachronistic**：时代错误，包括明显错误和微妙错误
+- **Myth**：流行但不符合史实的说法
+
+## Confidence Levels
+- **High**: 有主要史料或学术共识支撑
+- **Medium**: 学术存在争议或史料有限
+- **Low**: 推测性或仅基于次级研究
+
+## 与 Period Authenticity Report 的区别
+| 维度 | Period Authenticity Report | Historical Coherence Check |
+|------|---------------------------|---------------------------|
+| 范围 | 全方位验证 | 单一声明评估 |
+| 复杂度 | 完整报告 | 简洁框架 |
+| 用途 | 设置验证 | 声明核实 |
+
+## Related Concepts
+- [[Period Authenticity Report]]：完整的时期验证报告
+- [[Anachronism]]：需要被检测的时代错误
+- [[Material Culture]]：验证物质细节的基础
+
+## Source
+Academic Historian Agent — The Agency 项目

wiki/concepts/Incremental-Updates.md

@@ -0,0 +1,27 @@
+---
+title: "Incremental Updates"
+type: concept
+tags: [real-time, graph, sync]
+last_updated: 2026-04-20
+---
+
+## Definition
+Incremental Updates（增量更新）是通过文件监视器和版本控制系统钩子实现图谱实时同步的机制，避免全量重建。
+
+## Update Triggers
+- **文件监视器**：监听文件系统变化（create、modify、delete、rename）
+- **Git Hooks**：在 commit、push 时触发增量更新
+- **LSP 通知**：textDocument/didChange 事件
+
+## Consistency Requirements
+- 原子更新：从不将图谱置于不一致状态
+- 边引用验证：所有边必须指向有效节点 ID
+- 文件节点优先：符号节点创建前必须存在父文件节点
+
+## Performance Target
+- 图谱更新传播到客户端：<500ms
+- 内存占用：<500MB（典型项目）
+
+## Connections
+- [[graphd]] ← 实现 ← [[Incremental Updates]]
+- [[File Watcher]] ← 触发 ← [[Incremental Updates]]

wiki/concepts/Invariant-Verification.md

@@ -0,0 +1,40 @@
+---
+title: "Invariant Verification"
+type: concept
+tags: [smart-contract, security, testing]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+不变量验证（Invariant Verification）是通过属性驱动测试（Property-Based Testing）验证智能合约关键属性始终成立的方法。
+
+## Invariant Examples
+- `totalShares × pricePerShare = totalAssets`（资产管理器）
+- `pool.balance ≥ sum(userBalances)`（余额不变量）
+- `onlyOwner can upgrade`（权限不变量）
+- `mint/Burn pair maintains supply`（代币供应不变量）
+
+## Tools
+- **Echidna**：Property-based fuzzing
+- **Foundry/Forge**：invariant testing
+- **Medusa**：模糊测试
+
+## Process
+1. 定义协议不变量
+2. 编写 invariant 测试用例
+3. 使用模糊测试生成攻击输入
+4. 验证 invariant 是否被破坏
+5. 迭代修复直至测试通过
+
+## Limitations
+- 只能测试已想到的不变量
+- 模糊测试覆盖率有限
+- 复杂状态空间难以穷举
+- 需要领域专业知识定义不变量
+
+## Connections
+- [[Formal Verification]] ← is_formal_version_of ← [[Invariant Verification]]
+- [[Echidna]] ← provides ← [[Invariant Verification]]
+- [[Smart Contract Testing]] ← includes ← [[Invariant Verification]]
+

wiki/concepts/Kano-Model.md

@@ -0,0 +1,25 @@
+---
+title: "Kano Model"
+type: concept
+tags: [prioritization, product-management, customer-satisfaction]
+sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+用户满意度分类模型，通过功能满足程度与用户满意度的非线性关系指导产品决策。
+
+## Categories
+- **Must-Be（必备型）**：基本需求，缺失导致强烈不满，存在不产生额外满意度
+- **Performance（绩效型）**：线性关系，越多越好
+- **Delighter（兴奋型）**：超出期望的惊喜功能
+- **Indifferent（无关型）**：用户不在意的功能
+- **Reverse（反向型）**：用户不喜欢的功能
+
+## Application
+指导产品路线图规划，平衡基本功能与创新功能的比例。
+
+## Related Concepts
+- [[RICE Framework]]
+- [[MoSCoW Method]]
+- [[Product Sprint Prioritizer]]

wiki/concepts/Kano模型.md

@@ -0,0 +1,30 @@
+---
+title: "Kano模型"
+type: concept
+tags: [Product Management, Satisfaction Model]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+Kano模型是一种基于用户满意度二维度的产品质量功能分类模型。
+
+## Dimensions
+- **线性满意度**：功能越完善，用户越满意
+- **二元满意度**：功能存在则满意，不存在则不满意
+
+## Categories
+- **必备功能（Must-be）**：理所当然的功能，不满足会强烈不满
+- **一维功能（One-dimensional）**：功能好坏直接对应满意度高低
+- **激励功能（Attractive）**：超出期望的惊喜功能
+- **无关功能（Indifferent）**：用户不在意的功能
+- **反向功能（Reverse）**：用户不需要甚至反感的功能
+
+## Usage
+Kano模型由 [[Product Feedback Synthesizer]] 用于将用户反馈分类为不同满意度类型的功能。
+
+## Connections
+- [[Product Feedback Synthesizer]]：使用此模型进行反馈分析
+- [[RICE评分]]：结合使用的优先级框架
+- [[MoSCoW优先级]]：另一种优先级框架
+- [[NPS分析]]：用户忠诚度衡量指标

wiki/concepts/Koppen-Climate-Classification.md

@@ -0,0 +1,62 @@
+---
+title: "Koppen Climate Classification"
+type: concept
+tags: [geography, climate, classification]
+last_updated: 2026-04-20
+---
+
+## Definition
+柯本气候分类法（Koppen Climate Classification）是一种基于植物分布和温度降水模式的气候分类系统，由俄罗斯气候学家弗拉基米尔·柯本于 1884 年创立，是物理地理学的基础工具。
+
+## Classification System
+
+### Main Climate Groups
+- **A**: Tropical（热带气候）
+- **B**: Dry（干旱气候）
+- **C**: Temperate（温带气候）
+- **D**: Continental（大陆性气候）
+- **E**: Polar（极地气候）
+
+### Secondary Divisions
+- f: Moist（湿润）
+- m: Monsoon（季风）
+- w: Dry winter（冬干）
+- s: Dry summer（夏干）
+- g: G来型（Gust来型）
+- etc.
+
+### Common Examples
+- **Af**: Tropical rainforest（热带雨林）
+- **Am**: Tropical monsoon（热带季风）
+- **Aw/As**: Tropical savanna（热带稀树草原）
+- **BWh**: Hot desert（炎热沙漠）
+- **BWk**: Cold desert（寒冷沙漠）
+- **Cfa**: Humid subtropical（湿润亚热带）
+- **Cfb**: Oceanic（海洋性气候）
+- **Cwa**: Monsoon humid subtropical（季风亚热带）
+- **Dfa/Dfb**: Hot/Cold continental（夏季炎热/寒冷大陆性）
+
+## Application in Worldbuilding
+
+### Rules for [[Geographic Coherence]]
+1. Climate zone must match latitude（气候带必须匹配纬度）
+   - Tropical (A) typically within ±23.5° of equator
+   - Temperate (C) typically 30°-50° latitude
+   - Continental (D) typically 40°-60° latitude
+   - Polar (E) above 60° latitude
+
+2. Altitude affects classification（海拔影响分类）
+   - Higher elevation can create cooler microclimates
+   - Mountain regions may have vertical climate zones
+
+3. Rain shadows exist（雨影效应存在）
+   - Mountain ranges block moisture
+   - Leeward sides are typically drier
+
+## Related Concepts
+- [[Geographic Coherence]]: Framework for validating world geography
+- [[Biome]]: Vegetation type consistent with climate
+- [[Hydrology]]: Water flow patterns in geographic systems
+
+## Source
+- Primary source: [[raw/Agent/agency-agents/academic/academic-geographer.md]]

wiki/concepts/Kraljic-Matrix.md

@@ -0,0 +1,29 @@
+---
+title: "Kraljic Matrix"
+type: concept
+tags: [supply-chain, procurement]
+---
+
+## Definition
+Kraljic Matrix（克拉夫基矩阵）是一种供应商分类框架，将采购项按供应风险和利润影响分为四类：战略型（Strategic）、杠杆型（Leverage）、瓶颈型（Bottleneck）、常规型（Routine）。
+
+## Framework
+
+### 四象限分类
+
+| 类型 | 供应风险 | 利润影响 | 采购策略 |
+|------|----------|----------|----------|
+| **战略型** (Strategic) | 高 | 高 | 深度合作、伙伴关系、联合开发 |
+| **杠杆型** (Leverage) | 低 | 高 | 竞争性招标、总量平衡、供应商替换 |
+| **瓶颈型** (Bottleneck) | 高 | 低 | 寻找替代源、保持库存、关系维护 |
+| **常规型** (Routine) | 低 | 低 | 简化流程、自动化采购、减少管理成本 |
+
+## Application
+- 用于制定品类级采购策略
+- 指导供应商关系管理决策
+- 识别需要重点管理的采购项
+
+## Connections
+- [[Supply Chain Strategist]] ← uses ← [[Kraljic Matrix]]
+- [[ABC 分类法]] — 供应商分级管理，与 Kraljic Matrix 配合使用
+

wiki/concepts/LSIF-Language-Server-Index-Format.md

@@ -0,0 +1,18 @@
+---
+title: "LSIF (Language Server Index Format)"
+type: concept
+tags: [index-format, lsp, serialization]
+last_updated: 2026-04-20
+---
+
+## Definition
+LSIF（Language Server Index Format）是一种用于存储预计算代码语义索引的标准化格式，支持语言服务器数据的序列化、导入和导出。
+
+## Use Cases
+- **预计算索引**：在 CI/CD 管道中预先构建索引，加快本地启动
+- **跨工具共享**：不同工具（IDE、搜索、文档生成）共享同一索引
+- **归档与回放**：存储代码库的语义快照用于历史分析
+
+## Connections
+- [[Semantic Index]] ← 格式 ← [[LSIF (Language Server Index Format)]]
+- [[graphd]] ← 支持 ← [[LSIF (Language Server Index Format)]]

wiki/concepts/LSP-Client-Orchestration.md

@@ -0,0 +1,45 @@
+---
+title: "LSP Client Orchestration"
+type: concept
+tags: [lsp, concurrency, architecture]
+last_updated: 2026-04-20
+---
+
+## Definition
+LSP Client Orchestration 是指并发管理多个语言服务器客户端的架构模式，使异构编程语言的代码智能在统一平台协同工作。
+
+## Core Pattern
+```typescript
+class LSPOrchestrator {
+  private clients = new Map<string, LanguageClient>();
+  private capabilities = new Map<string, ServerCapabilities>();
+
+  async initialize(projectRoot: string) {
+    await Promise.all([
+      this.initializeClient('typescript', tsClient),
+      this.initializeClient('php', phpClient),
+      this.initializeClient('go', goClient),
+      this.initializeClient('rust', rustClient),
+      this.initializeClient('python', pyrightClient)
+    ]);
+  }
+
+  async getDefinition(uri: string, position: Position): Promise<Location[]> {
+    const lang = this.detectLanguage(uri);
+    const client = this.clients.get(lang);
+    if (!client || !this.capabilities.get(lang)?.definitionProvider) {
+      return [];
+    }
+    return client.sendRequest('textDocument/definition', { textDocument: { uri }, position });
+  }
+}
+```
+
+## Key Challenges
+- 能力协商：不同语言服务器能力差异巨大，需动态检测
+- 生命周期管理：每个客户端需独立经历 initialize → initialized → shutdown → exit
+- 请求路由：根据文件扩展名路由到正确的语言服务器
+
+## Connections
+- [[LSP (Language Server Protocol)]] ← 基于 ← [[LSP Client Orchestration]]
+- [[graphd]] ← 实现 ← [[LSP Client Orchestration]]

wiki/concepts/LSP-Language-Server-Protocol.md

@@ -0,0 +1,32 @@
+---
+title: "LSP (Language Server Protocol)"
+type: concept
+tags: [protocol, code-intelligence, editor]
+last_updated: 2026-04-20
+---
+
+## Definition
+Language Server Protocol（LSP）是微软提出的标准化协议，为编辑器/IDE 提供编程语言特性支持（自动补全、跳转定义、悬停文档等），实现语言功能与编辑器的解耦。
+
+## Core Features
+- **文本文档同步**：textDocument/didOpen、textDocument/didChange
+- **代码导航**：textDocument/definition、textDocument/references、textDocument/documentSymbol
+- **代码补全**：textDocument/completion
+- **悬停文档**：textDocument/hover
+- **诊断信息**：textDocument/publishDiagnostics
+
+## LSP 3.17 Key Capabilities
+- 能力协商机制（initialize 阶段交换 serverCapabilities）
+- 完整生命周期管理（initialize → initialized → shutdown → exit）
+- Workspace symbols 和 文件 URI 标准化
+
+## Language Servers
+- TypeScript: typescript-language-server
+- PHP: intelephense, phpactor
+- Go: gopls
+- Rust: rust-analyzer
+- Python: pyright, pylance
+
+## Connections
+- [[graphd]] ← 依赖使用 ← [[LSP (Language Server Protocol)]]
+- [[LSP Client Orchestration]] ← 基于 ← [[LSP (Language Server Protocol)]]

wiki/concepts/Longue-Duree.md

@@ -0,0 +1,42 @@
+---
+title: "Longue Durée"
+type: concept
+tags: [history, historiography, annales-school]
+last_updated: 2026-04-20
+---
+
+## Definition
+长时段（Longue Durée）是法国历史学家费尔南·布罗代尔提出的史学概念，指塑造人类历史发展的长期结构性力量，如地理、气候、人口、技术缓慢变迁等。
+
+## Etymology
+- 法语：longue durée，字面意思是"漫长的时期"或"长时段"
+
+##布罗代尔的三层时间结构
+1. **La longue durée（长时段）**：地理时间，几百年到几千年的缓慢变迁
+2. **La moyenne durée（中时段）**：社会经济时间，几十年到几代人的周期波动
+3. **Le temps court（短时段）**：事件时间，政治、战争、人物等即时事件
+
+## Core Insight
+历史事件只有放在长时段背景下才能被理解。短期事件往往只是长期结构的表面现象。
+
+## Application in Worldbuilding
+- 验证地理环境是否与设定时期匹配
+- 检查技术进步是否在合理的时间框架内
+- 确保社会结构变化有足够的物质基础
+
+## Historical Examples
+- 地中海地区：气候和地理决定了贸易路线和文明分布
+- 工业革命：不是突然发生，而是长期积累的结果
+- 中世纪欧洲：需要放在更长的欧洲历史框架中理解
+
+## Criticism
+- 过度强调结构可能忽视人类能动性
+- 难以应用于快速变化的时代
+
+## Related Concepts
+- [[Material Culture]]：长时段分析的关注点
+- [[Period Authenticity Report]]：使用长时段方法验证设置
+- [[Annales School]]：年鉴学派的核心方法论
+
+## Source
+布罗代尔（Braudel），《菲利普二世时代的地中海和地中海世界》

wiki/concepts/MCP传输协议.md

@@ -0,0 +1,19 @@
+---
+title: "MCP传输协议"
+type: concept
+tags: [ai, mcp, transport]
+date: 2026-04-20
+---
+
+## Definition
+MCP Server 常见的传输方式，包括 stdio、SSE 和 Streamable HTTP，用于不同部署与集成场景。
+
+## Transport Types
+- **stdio**：适合本地 CLI / 桌面集成
+- **SSE**：适合 Web 或远程 Agent 场景
+- **Streamable HTTP**：适合云端无状态部署
+
+## Connections
+- [[MCP]]
+- [[MCP服务器]]
+- [[MCP Builder]]

wiki/concepts/MCP工具接口设计.md

@@ -0,0 +1,20 @@
+---
+title: "MCP工具接口设计"
+type: concept
+tags: [ai, mcp, design, tool-design]
+date: 2026-04-20
+---
+
+## Definition
+以 Agent 为用户来设计 MCP 工具接口的规范，强调 verb_noun 命名、清晰描述、单一职责、可预测参数和结构化输出。
+
+## Principles
+- 工具名应使用 verb_noun 形式，例如 `search_tickets`
+- 描述应说明何时使用，而不是只说它是什么
+- 每个工具只负责一件事
+- 参数应有明确类型、默认值和边界
+
+## Connections
+- [[MCP]]
+- [[MCP服务器]]
+- [[MCP Builder]]

wiki/concepts/ML-Ops.md

@@ -1,23 +1,25 @@
 ---
 title: "ML Ops"
 type: concept
-tags: [DevOps, ML, operations]
-sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
-last_updated: 2024-02-06
+tags: [machine-learning, operations, lifecycle]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
 ---
 
-## Summary
-ML Ops 结合机器学习和运营，涉及人员、技术和流程，以实现协作式 ML 解决方案。
-
 ## Definition
-ML Ops (Machine Learning Operations) 是将 DevOps 原则应用于机器学习系统的实践，包括数据管道、训练管道和推理管道的自动化和监控。
+ML Ops is the discipline of operationalizing machine learning models across development, deployment, monitoring, and governance.
 
-## Key Attributes
-- **核心组成**：数据管道、训练管道、推理管道
-- **关注点**：数据溯源、模型管理、部署工作流
-- **工具**：Amazon SageMaker、MLflow、Kubeflow
+## Core Areas
+- Data pipelines
+- Training and deployment
+- Monitoring and drift detection
+- Governance and auditability
 
-## Connections
-- [[DevOps]] ← extends ← [[ML Ops]]
-- [[ML Ops]] ← manages ← [[Machine Learning]]
-- [[Amazon SageMaker]] ← implements ← [[ML Ops]]
+## Relevance to Model QA
+- Provides the operational context for audits
+- Supplies monitoring and reproducibility artifacts
+- Supports remediation and retraining loops
+
+## Related Concepts
+- [[Model Audit]]
+- [[Discrimination Metrics]]

wiki/concepts/Market-Research.md

@@ -1,18 +1,33 @@
 ---
 title: "Market Research"
 type: concept
-tags: [market-research, product-development, entrepreneurship]
-last_updated: 2026-04-17
+tags: [market-research, product-development, competitive-intelligence, market-sizing]
+last_updated: 2026-04-20
 ---
 
 ## Definition
-通过系统化收集和分析用户反馈、市场趋势、竞品信息来识别产品机会和用户需求的过程。
+通过系统化收集和分析市场信息、竞争情报和用户需求，为产品策略和创新决策提供依据的过程。
 
-## Key Activities
-- 用户痛点收集
-- 竞品分析
-- 市场规模评估
-- 用户需求验证
+## Core Components
+- 行业分析（Industry Analysis）
+- 竞争情报（Competitive Intelligence）
+- 市场规模（Market Sizing）
+- 细分市场分析（Segmentation Analysis）
+
+## Market Sizing Framework
+- **TAM（Total Addressable Market）**：总可寻址市场，自顶向下和自底向上分析
+- **SAM（Serviceable Addressable Market）**：可服务市场，考虑地理和业务约束后的现实市场机会
+- **SOM（Serviceable Obtainable Market）**：可获得市场，通过竞争分析确定的可实现市场份额
+
+## Research Tools
+- Google Trends：搜索趋势分析
+- SEMrush / Ahrefs：关键词和竞争分析
+- SimilarWeb：网站流量分析
+- Statista：统计数据
+- CB Insights / PitchBook：投资和创业情报
+
+## AI-Enhanced Approach
+使用 Last 30 Days skill 等工具自动挖掘 Reddit 和 X 上的真实用户讨论，获取未经过滤的用户情绪数据。[[Product Trend Researcher]] 提供完整的趋势识别和竞争情报框架。
 
 ## Traditional Methods
 - 问卷调查
@@ -20,9 +35,8 @@ last_updated: 2026-04-17
 - 焦点小组
 - 论坛和社交媒体浏览
 
-## AI-Enhanced Approach
-使用 Last 30 Days skill 等工具自动挖掘 Reddit 和 X 上的真实用户讨论，获取未经过滤的用户情绪数据。
-
 ## Connected Pages
 - [[market-research-product-factory]]
-- [[Last-30-Days-Skill]]
+- [[Last-30-Days-Skill]]
+- [[Competitive Intelligence]]
+- [[TAM/SAM/SOM]]

wiki/concepts/Material-Culture.md

@@ -0,0 +1,45 @@
+---
+title: "Material Culture"
+type: concept
+tags: [history, anthropology, worldbuilding]
+last_updated: 2026-04-20
+---
+
+## Definition
+物质文化是指人们在特定历史时期生产和使用的物质对象、技术、建筑及日常物品，以及这些物品如何反映和塑造社会结构。
+
+## Core Focus Areas
+- **Diet**: 实际饮食内容，包括阶级差异
+- **Clothing**: 材料、款式、社会标记
+- **Architecture**: 建筑材料、风格、幸存与失传
+- **Technology**: 存在的技术、不存在的技术、区域性技术
+- **Currency/Trade**: 经济系统、贸易路线、商品
+
+## Annales School Approach
+Academic Historian 采用年鉴学派方法，关注：
+- La longue durée（长时段）：塑造历史的长期结构
+- Histoire immobile：几乎不变的历史结构
+- 地中海模式（布罗代尔）：地理、物质、经济三层结构
+
+## Importance in Worldbuilding
+1. 提供历史感知的"质感"
+2. 避免现代价值观投射（presentism）
+3. 通过物质条件理解社会结构
+4. 创造可信的虚构社会
+
+## 与 Social Structure 的关系
+物质文化是经济基础，社会结构是上层建筑：
+- 先理解物质条件（饮食、贸易、技术）
+- 再讨论政治或战争
+
+## Common Myths
+- 中世纪"黑暗"：实际上城市卫生、贸易网络比想象中发达
+- 古代"落后"：需要具体分析，避免泛化
+
+## Related Concepts
+- [[Longue Durée]]：长时段分析框架
+- [[Period Authenticity Report]]：物质文化是报告的核心组成部分
+- [[Academic Anthropologist]]：共享物质文化分析方法
+
+## Source
+Academic Historian Agent — The Agency 项目

wiki/concepts/McKee-故事结构.md

@@ -0,0 +1,23 @@
+---
+title: "McKee 故事结构"
+type: concept
+tags: [narrative-theory, story-structure, screenplay]
+---
+
+## 定义
+Robert McKee 在《故事》一书中提出的专业剧本写作理论，强调故事设计而非写作风格。
+
+## 核心概念
+- **Controlling Idea**：故事通过角色和情节传达的关于生活本质的主张/论点
+- **对立统一（Antithesis）**：通过对比冲突制造戏剧张力
+- **三幕结构（Three-Act Structure）**：
+  - Setup（设置）：建立世界、角色、规则
+  - Confrontation（对抗）：冲突升级、阻碍增多
+  - Resolution（解决）：高潮、最终对决、新平衡
+
+## 与其他框架关系
+- 与 [[Campbell 英雄之旅]] 互补，McKee 更注重主题论证
+- 与 [[Todorov 均衡模型]] 共享 equilibrium-disruption-return 结构
+
+## 来源框架
+- [[Narratologist]] 使用此框架识别故事的 controlling idea 和 structure model

wiki/concepts/Micro-Sprint.md

@@ -0,0 +1,30 @@
+---
+title: "Micro-Sprint"
+type: concept
+tags: [productivity, task-management, cognitive-load]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+将大任务拆分为 5 分钟内可完成的微型冲刺单元，降低认知负担，防止用户决策瘫痪。
+
+## Mechanism
+- 将大量待办事项（如 50 个）拆分为最小可执行单元
+- 每次只推送 1 个单一、可操作、低摩擦的行动项
+- 通过时间盒（5 minutes）创造紧迫感和完成动机
+
+## Example
+```
+message: "Hey! You've got a few quick follow-ups pending. Let's see how many we can knock out in the next 5 mins. I'll tee up the first draft. Ready?"
+actionButton: "Start 5 Min Sprint"
+```
+
+## Related Concepts
+- [[Cognitive Load Reduction]]
+- [[Momentum Nudge]]
+- [[Pomodoro Technique]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← implements ← [[Micro-Sprint]]
+- [[Habit Tracking & Accountability Partner]] ← uses ← [[Micro-Sprint]]

wiki/concepts/Microhistory.md

@@ -0,0 +1,46 @@
+---
+title: "Microhistory"
+type: concept
+tags: [history, historiography, methodology]
+last_updated: 2026-04-20
+---
+
+## Definition
+微历史是一种历史研究方法，通过对特定个人、家庭、社区或事件的深入细致研究，揭示更广泛的社会、文化和经济结构。
+
+## Origin
+- 1960-1970年代兴起于意大利
+- 代表人物：金兹伯格（Carlo Ginzburg）、列维（Emmanuel Le Roy Ladurie）
+- 《奶酪与蛆虫》（金兹伯格，1976）是经典之作
+
+## Key Characteristics
+- 从微观切入：通过具体案例揭示宏观结构
+- 文献密集：利用档案、日记、法院记录等一手资料
+- 反结构主义：强调个体能动性与偶然性
+- 去中心化：关注边缘人群、非主流声音
+
+## 与 Macrohistory 的对比
+| 维度 | Microhistory | Macrohistory |
+|------|--------------|--------------|
+| 视角 | 自下而上 | 自上而下 |
+| 对象 | 个人、边缘群体 | 社会结构、国家、文明 |
+| 方法 | 深度个案研究 | 计量分析、大规模数据 |
+| 局限 | 难以推广 | 可能忽视个体差异 |
+
+## Application in Worldbuilding
+- 为虚构角色提供历史背景深度
+- 通过小人物视角展现大时代
+- 增添历史叙事的真实感和人情味
+
+## Example Topics
+- 14世纪黑死病期间一个村庄的命运
+- 法国大革命中一个工匠家庭的经历
+- 清朝一个县衙门的日常运作
+
+## Related Concepts
+- [[Material Culture]]：微历史关注日常生活的物质基础
+- [[Historical Coherence Check]]：验证微历史细节的准确性
+- [[Academic Historian]]：Academic Historian 的方法论工具之一
+
+## Source
+金兹伯格《奶酪与蛆虫》（1976）

wiki/concepts/MoSCoW-Method.md

@@ -0,0 +1,25 @@
+---
+title: "MoSCoW Method"
+type: concept
+tags: [prioritization, agile, requirements]
+sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+需求优先级分类方法，将功能分为四个类别以明确交付优先级。
+
+## Categories
+- **Must-Have（必须有）**：基本期望，缺失会导致客户不满
+- **Should-Have（应该有）**：重要但不紧急的需求
+- **Could-Have（可以有）**：期望但不关键的功能
+- **Won't-Have（不能有）**：当前 sprint 明确排除的需求
+
+## Application
+用于 sprint 规划中的故事选择和干系人期望管理，确保核心功能优先交付。
+
+## Related Concepts
+- [[RICE Framework]]
+- [[Kano Model]]
+- [[Sprint Planning]]
+- [[Product Sprint Prioritizer]]

wiki/concepts/MoSCoW优先级.md

@@ -0,0 +1,24 @@
+---
+title: "MoSCoW优先级"
+type: concept
+tags: [Product Management, Prioritization Framework]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+MoSCoW是一种需求优先级排序技术，将功能分为四类以确定交付优先级。
+
+## Categories
+- **Must-have（必须有）**：不满足则产品无法发布的核心功能
+- **Should-have（应该有）**：重要但不紧急的功能
+- **Could-have（可以有）**：期望但不必需的功能
+- **Won't-have（不必须有）**：当前版本不包含的功能
+
+## Usage
+MoSCoW由 [[Product Feedback Synthesizer]] 用于将用户反馈分类为可交付的功能优先级。
+
+## Connections
+- [[Product Feedback Synthesizer]]：使用此框架进行反馈分类
+- [[RICE评分]]：另一种优先级框架
+- [[Kano模型]]：基于满意度二维度的功能分类

wiki/concepts/Model-Audit.md

@@ -0,0 +1,29 @@
+---
+title: "Model Audit"
+type: concept
+tags: [ml-ops, governance, assurance]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+模型审计是一套系统化流程，用于独立验证模型的设计、数据、训练、性能、解释性与业务影响。
+
+## Typical Scope
+- 文档与治理
+- 数据与标签
+- 特征稳定性
+- 模型复制
+- 校准与性能
+- 可解释性与公平性
+- 业务影响
+
+## Use in Model QA
+- 提供证据驱动的质量结论
+- 将问题分级并提出修复建议
+- 形成可复核的审计轨迹
+
+## Related Concepts
+- [[Population Stability Index (PSI)]]
+- [[Calibration Testing]]
+- [[Discrimination Metrics]]

wiki/concepts/Momentum-Nudge.md

@@ -0,0 +1,31 @@
+---
+title: "Momentum Nudge"
+type: concept
+tags: [gamification, behavioral-psychology, engagement]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+即时正向反馈与持续动力构建机制，通过庆祝已完成的任务而非聚焦剩余任务来维持用户动力。
+
+## Mechanism
+- 庆祝已完成的微任务（如"完成了 5 个！"）
+- 立即提供强化反馈
+- 提供清晰的退出选项或继续选项
+
+## Example
+> "Nice work! We sent 15 follow-ups, wrote 2 templates, and thanked 5 customers. That's amazing. Want to do another 5 minutes, or call it for now?"
+
+## Success Metrics
+- Action Completion Rate（行动完成率）
+- User Retention（用户留存）
+- Engagement Health（参与健康度）
+
+## Related Concepts
+- [[Micro-Sprint]]
+- [[Default Bias]]
+- [[Opt-Out Completion]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← implements ← [[Momentum Nudge]]

wiki/concepts/NPS分析.md

@@ -0,0 +1,35 @@
+---
+title: "NPS分析"
+type: concept
+tags: [Customer Analytics, Loyalty Metric]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+NPS（Net Promoter Score，净推荐值）是一种衡量用户忠诚度和推荐意愿的指标。
+
+## Calculation
+- ** promoters（推荐者）**：评分9-10分，忠诚用户
+- **passives（被动者）**：评分7-8分，满意但不主动推荐
+- **detractors（贬低者）**：评分0-6分，不满意用户
+
+```
+NPS = 推荐者百分比 - 贬低者百分比
+```
+
+取值范围：-100 到 +100
+
+## Usage
+NPS由 [[Product Feedback Synthesizer]] 用于衡量用户忠诚度和反馈洞察的业务影响，相关指标：反馈洞察提升 NPS 10+ 分。
+
+## Success Criteria
+- NPS > 0：良好
+- NPS > 50：优秀
+- NPS > 70：世界级
+
+## Connections
+- [[Product Feedback Synthesizer]]：使用NPS衡量反馈分析效果
+- [[CSAT]]：另一种客户满意度指标
+- [[CES]]：客户努力程度指标
+- [[流失预测]]：基于满意度建模的流失预警

wiki/concepts/Nudge-Sequence-Logic.md

@@ -0,0 +1,29 @@
+---
+title: "Nudge Sequence Logic"
+type: concept
+tags: [multi-channel, user-engagement, personalization]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+多渠道触达用户的序列逻辑，根据用户响应情况自动切换沟通渠道和频率。
+
+## Logic Example
+```
+Day 1: SMS（高触达率渠道）
+Day 3: Email（书面记录渠道）
+Day 7: In-App Banner（应用内提醒）
+```
+
+## Adaptation Rules
+- 如果用户停止响应每日 SMS nudges
+- 自动切换为每周邮件摘要
+- 暂停主动推送并询问用户偏好调整
+
+## Related Concepts
+- [[UserProfile]]
+- [[Behavioral Nudge Engine]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← uses ← [[Nudge Sequence Logic]]

wiki/concepts/Nunchi-Reading-Context.md

@@ -0,0 +1,38 @@
+---
+title: "Nunchi（눈치）"
+id: nunchi-reading-context
+type: concept
+tags: [korea, business, communication, culture]
+sources: [[specialized-korean-business-navigator]]
+last_updated: 2026-04-20
+---
+
+## Definition
+Nunchi（눈치，字面意思"用眼力测量"）是阅读情境和情感上下文的能力，在韩国商务中至关重要。它涉及从非语言线索、语气、沉默和上下文推断真实意图。
+
+## Core Principle
+韩国商务沟通优先和谐而非清晰——人们不会直接说"不"，而是通过间接表达保护双方关系和面子。
+
+## Communication Decoder
+
+| 韩国表达 | 字面意思 | 实际含义 | 应对 |
+|---|---|---|---|
+| 좋은데요... | "That's nice, but..." | 犹豫，有顾虑 | 询问具体顾虑 |
+| 검토해보겠습니다 | "We'll review it" | 可能是拒绝，体面退出 | 等待5天，无跟进则放弃 |
+| 긍정적으로 검토하겠습니다 | "We'll review positively" | 真正有兴趣，内部流程启动 | 主动发送支持材料 |
+| 어려울 것 같습니다 | "It seems difficult" | 明确拒绝 | 体面接受，保留关系 |
+| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在此人，품의流程触发 | 好信号，提供所需材料 |
+
+## Cultural Context
+- **沉默不是拒绝**：3-7天沉默意味着内部讨论正在进行
+- **"Yes"不等于同意**：韩国式同意可能是礼貌性回应
+- **走廊决策**：真正决策发生在会议之外
+- **关系优先**：合同是关系的结果而非原因
+
+## Development Path
+外国专业人员应逐步培养独立nunchi能力，使Agent的干预必要性随时间降低。
+
+## Related Concepts
+- [[품의（共识审批）]]
+- [[关系生命周期]]
+- [[KakaoTalk商务沟通]]

wiki/concepts/Opportunity-Assessment.md

@@ -0,0 +1,37 @@
+---
+title: "Opportunity Assessment"
+type: concept
+tags: [product-management, prioritization, decision-framework]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+机会评估是在讨论解决方案之前编写的文档，通过 RICE 框架量化机会价值，支撑 build/explore/defer/kill 决策。
+
+## Structure
+1. **Why Now?**：市场信号、用户行为变化或竞争压力，为什么现在紧急
+2. **User Evidence**：访谈发现、行为数据、support 信号
+3. **Business Case**：收入影响、成本影响、战略契合度、市场规模
+4. **RICE Prioritization Score**：R × I × C ÷ E
+5. **Options Considered**：构建/MVP/购买/延期选项对比
+6. **Recommendation**：Build / Explore further / Defer / Kill + 理由 + 下一步
+
+## RICE Score Formula
+| Factor | Description |
+|--------|-------------|
+| Reach | 每季度触达用户数 |
+| Impact | 对指标的影响（0.25/0.5/1/2/3） |
+| Confidence | 信心水平（%） |
+| Effort | 人力月数 |
+| **Score** | **(R × I × C) ÷ E** |
+
+## Use Case
+- 在进入 PRD 编写前做优先级决策
+- 对齐 leadership 对战略契合和资源意愿
+- 正式 build/defer/kill 推荐文档化推理
+
+## Connection
+- [[Product Manager Agent]] ← conducts ← [[Opportunity Assessment]]
+- [[RICE Prioritization Score]] ← calculated_in ← [[Opportunity Assessment]]
+- [[Roadmap (Now / Next / Later)]] ← informed_by ← [[Opportunity Assessment]]

wiki/concepts/Opt-Out-Completion.md

@@ -0,0 +1,26 @@
+---
+title: "Opt-Out Completion"
+type: concept
+tags: [ux-design, behavioral-psychology, user-autonomy]
+sources: [product-behavioral-nudge-engine]
+last_updated: 2026-04-20
+---
+
+## Definition
+提供清晰的退出路径而非强制持续的机制，尊重用户自主权同时保持参与度。
+
+## Mechanism
+- 每个交互都提供明确的"退出"或"继续"选项
+- 不使用黑暗模式（dark patterns）强制用户继续
+- 用户可以随时调整偏好
+
+## Example
+> "Great job! Want to do 5 more minutes, or call it for the day?"
+
+## Related Concepts
+- [[Momentum Nudge]]
+- [[Default Bias]]
+- [[Cognitive Load Reduction]]
+
+## Connections
+- [[Behavioral Nudge Engine]] ← implements ← [[Opt-Out Completion]]

wiki/concepts/Oracle-Manipulation.md

@@ -0,0 +1,36 @@
+---
+title: "Oracle Manipulation"
+type: concept
+tags: [smart-contract, vulnerability, defi, security]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+预言机操纵（Oracle Manipulation）是指攻击者通过操纵区块链上的价格数据源（预言机）来影响资产价格，从而在 DeFi 协议中获取不正当利益。
+
+## Attack Vector
+1. 识别使用链上价格预言机的协议
+2. 通过 Flash Loan 借用大量资产
+3. 在单笔交易内操纵交易对储备量
+4. 协议使用被操纵的价格计算抵押品价值
+5. 攻击者借出超出正常限额的资产
+6. 归还 Flash Loan，利润落袋
+
+## Vulnerable Patterns
+- **Spot Price Oracle**：使用 Uniswap V2 即时价格
+- **缺乏 TWAP 时间加权）
+- **缺乏价格更新验证**
+- **过长的价格 staleness 容忍**
+
+## Mitigation
+- **TWAP（Time-Weighted Average Price）**：使用时间加权平均价格
+- **Chainlink Oracle**：使用去中心化预言机网络
+- **价格更新验证**：检查 timestamp、roundId
+- **价格波动限制**：设置最大允许偏差
+
+## Connections
+- [[DeFi Attack Vector]] ← is_type_of ← [[Oracle Manipulation]]
+- [[Flash Loan Attack]] ← exploits ← [[Oracle Manipulation]]
+- [[Chainlink]] ← provides ← [[Oracle Manipulation]] Mitigation
+

wiki/concepts/Outcome-Driven-Development.md

@@ -0,0 +1,38 @@
+---
+title: "Outcome-Driven Development"
+type: concept
+tags: [product-management, philosophy, development]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+结果驱动开发（Outcome-Driven Development）是一种产品开发哲学，核心是以可衡量的业务成果（outcome）而非功能产出（output）来定义成功。
+
+## Core Tenets
+1. **Feature 是 Hypothesis**：每个功能都是假设，需要验证
+2. **Shipped ≠ Success**：交付了没人用的功能是浪费，不是胜利
+3. **Measurement is Mandatory**：上线后必须追踪成功指标 vs 目标
+4. **Learning is Valuable**：未达目标的功能是学习，不是失败
+
+## Quote
+> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning — and learnings are valuable, but they don't go on the roadmap twice."
+
+## Success Criteria Framework
+| Timeframe | Metric | Target | Owner |
+|-----------|--------|--------|-------|
+| Launch day | Error rate | < 0.5% | Eng |
+| 7 days | Feature activation | ≥ 20% | PM |
+| 30 days | Retention delta | +8pp | PM |
+| 60 days | Support tickets | −30% | CS |
+| 90 days | NPS delta | +5 points | PM |
+
+## Why Outcome Over Output
+- Output 容易衡量但不一定有价值
+- Outcome 连接到业务目标和用户价值
+- 避免"忙碌但无用"陷阱
+
+## Connection
+- [[Outcome-Driven Development]] ← guides ← [[Product Manager Agent]]
+- [[Opportunity Assessment]] ← applies ← [[Outcome-Driven Development]]
+- [[Launch Phase]] ← measures ← [[Outcome-Driven Development]]

wiki/concepts/Partial-Dependence-Plots.md

@@ -0,0 +1,23 @@
+---
+title: "Partial Dependence Plots"
+type: concept
+tags: [interpretability, feature-analysis, ml-ops]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+偏依赖图（PDP）展示某个特征变化时，模型平均预测如何变化，用于分析边际效应。
+
+## Use in Model QA
+- 验证单调性假设
+- 识别非线性阈值
+- 检查特征与预测之间的边际关系
+
+## Limitations
+- 在强相关特征下可能误导
+- 更适合做辅助解释而非唯一依据
+
+## Related Concepts
+- [[SHAP Analysis]]
+- [[Model Audit]]

wiki/concepts/Period-Authenticity-Report.md

@@ -0,0 +1,59 @@
+---
+title: "Period Authenticity Report"
+type: concept
+tags: [history, worldbuilding, validation]
+last_updated: 2026-04-20
+---
+
+## Definition
+时期真实性报告是 Academic Historian 提供的标准化验证文档，用于评估虚构设定与特定历史时期的一致性。
+
+## Report Structure
+```
+PERIOD AUTHENTICITY REPORT
+==========================
+Setting: [Time period, region, specific context]
+Confidence Level: [Well-documented / Scholarly consensus / Debated / Speculative]
+
+Material Culture:
+- Diet: [What people actually ate, class differences]
+- Clothing: [Materials, styles, social markers]
+- Architecture: [Building materials, styles, what survives vs. what's lost]
+- Technology: [What existed, what didn't, what was regional]
+- Currency/Trade: [Economic system, trade routes, commodities]
+
+Social Structure:
+- Power: [Who held it, how it was legitimized]
+- Class/Caste: [Social stratification, mobility]
+- Gender roles: [With acknowledgment of regional variation]
+- Religion/Belief: [Practiced religion vs. official doctrine]
+- Law: [Formal and customary legal systems]
+
+Anachronism Flags:
+- [Specific anachronism]: [Why it's wrong, what would be accurate]
+
+Common Myths About This Period:
+- [Myth]: [Reality, with source]
+
+Daily Life Texture:
+- [Sensory details: sounds, smells, rhythms of daily life]
+```
+
+## Key Principles
+- Default requirement: Always name confidence level and source type
+- Material conditions first: Economy, technology, agriculture constrain everything else
+- Layer social structures on top of material base
+- Distinguish well-documented facts, scholarly consensus, active debates, and speculation
+
+## Usage Context
+- Worldbuilding validation for fiction, games, or creative projects
+- Historical setting coherence checking
+- Anachronism detection and correction
+
+## Related Concepts
+- [[Historical Coherence Check]]：更简洁的声明级验证
+- [[Material Culture]]：物质文化是报告的核心关注点
+- [[Longue Durée]]：长时段分析方法论
+
+## Source
+Academic Historian Agent — The Agency 项目

wiki/concepts/Platform-Events.md

@@ -0,0 +1,40 @@
+---
+title: "Platform Events vs CDC"
+type: concept
+tags: [salesforce, integration, events]
+sources: [specialized-salesforce-architect.md]
+last_updated: 2026-04-20
+---
+
+# Platform Events vs CDC
+
+Salesforce 事件驱动集成的两种模式对比。
+
+## Platform Events
+
+| 特性 | 说明 |
+|-----|-----|
+| 自定义载荷 | 是 — 定义自己的 schema |
+| 跨系统集成 | 首选 — 解耦生产者和消费者 |
+| 字段级追踪 | 否 |
+| 重放 | 72 小时窗口 |
+| 容量 | 高容量标准（100K/天） |
+| 使用场景 | "某事发生"（业务事件） |
+
+## Change Data Capture (CDC)
+
+| 特性 | 说明 |
+|-----|-----|
+| 自定义载荷 | 否 — 镜像 sObject 字段 |
+| 跨系统集成 | 有限 — 仅 Salesforce 原生事件 |
+| 字段级追踪 | 是 — 捕获字段变更 |
+| 重放 | 3 天保留 |
+| 容量 | 绑定到对象事务量 |
+| 使用场景 | "某事变化"（数据同步） |
+
+## 选择指南
+- 需要跨系统集成 → Platform Events
+- 只需要 Salesforce 内部变更追踪 → CDC
+
+## 来源
+[[Salesforce-Architect]] 智能体的架构设计指南

wiki/concepts/Population-Stability-Index-PSI.md

@@ -0,0 +1,25 @@
+---
+title: "Population Stability Index (PSI)"
+type: concept
+tags: [ml-ops, model-monitoring, drift]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+Population Stability Index（PSI）用于衡量两个样本分布之间的变化程度，常见于模型监控与特征稳定性分析。
+
+## Interpretation
+- < 0.10：无显著偏移
+- 0.10–0.25：中等偏移，需要调查
+- ≥ 0.25：显著偏移，需要处理
+
+## Use in Model QA
+- 检测特征漂移
+- 识别训练集与生产集分布差异
+- 为复审与再训练提供量化证据
+
+## Related Concepts
+- [[Model Audit]]
+- [[Calibration Testing]]
+- [[Discrimination Metrics]]

wiki/concepts/Population-Stability-Index.md

@@ -0,0 +1,46 @@
+---
+title: "Population Stability Index (PSI)"
+type: concept
+tags: [ml-ops, model-metrics, feature-stability, statistical-analysis]
+last_updated: 2026-04-20
+---
+
+## Definition
+Population Stability Index（PSI）是量化两个分布之间差异的统计指标，用于检测特征或模型输出在时间窗口上的分布偏移。
+
+## Formula
+```
+PSI = Σ ((Actual% - Expected%) * ln(Actual% / Expected%))
+```
+
+使用 Laplace 平滑避免除零：
+```python
+exp_pct = (expected_counts + 1) / (expected_counts.sum() + bins)
+act_pct = (actual_counts + 1) / (actual_counts.sum() + bins)
+psi = np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct))
+```
+
+## Interpretation Thresholds
+| PSI Range | Status | Action |
+|-----------|--------|--------|
+| < 0.10 | 绿色 | 无显著偏移 |
+| 0.10–0.25 | 琥珀色 | 中等偏移，建议调查 |
+| ≥ 0.25 | 红色 | 显著偏移，需要行动 |
+
+## Use Cases
+- **Feature Stability Monitoring**：监控输入特征在时间窗口上的稳定性
+- **Model Drift Detection**：检测模型输入输出分布是否发生显著变化
+- **Population Shift Detection**：识别开发样本与OOT样本之间的差异
+
+## Applications
+- 每月特征稳定性报告
+- 模型重新训练触发条件
+- 特征工程有效性评估
+
+## Related Concepts
+- [[Variable Stability Monitor]]：月度 PSI 监控工具
+- [[Model QA Specialist]]：使用 PSI 进行模型审计
+- [[ML Ops]]：PSI 是 MLOps 监控的核心指标
+
+## References
+- Source：[[model-qa-specialist]]

wiki/concepts/Predictive-Modeling.md

@@ -0,0 +1,23 @@
+---
+title: "Predictive Modeling"
+type: concept
+tags: [prediction, modeling, forecasting]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+预测建模是通过统计和数学方法，基于历史数据和模式预测未来结果的技术。
+
+## Key Methods
+- **Trend Lifecycle Mapping**：趋势生命周期映射（出现→增长→成熟→衰退）
+- **Adoption Curve Analysis**：采用曲线分析（创新者→早期大众）
+- **Cross-Correlation Studies**：多趋势交叉相关分析
+- **Scenario Planning**：基于不同假设的多情景规划
+- **Signal Strength Assessment**：信号强度评估
+
+## Model Outputs
+- 预测时间线（Timeline Predictions）
+- 采用率预测（Adoption Rate Predictions）
+- 置信区间（Confidence Intervals）
+- 情景概率权重（Probability Weighting）

wiki/concepts/Product-Requirements-Document.md

@@ -0,0 +1,32 @@
+---
+title: "Product Requirements Document (PRD)"
+type: concept
+tags: [product-management, documentation, deliverable]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+产品规格文档（PRD）是一份系统性定义产品功能需求的文档，涵盖问题陈述、目标与成功指标、用户故事、解决方案概述、技术考量、发布计划和附录。
+
+## Structure
+1. **Problem Statement**：具体用户痛点或商业机会
+2. **Goals & Success Metrics**：目标、指标、基线、目标值、测量窗口
+3. **Non-Goals**：明确本迭代不解决的问题
+4. **User Personas & Stories**：核心用户故事与验收标准
+5. **Solution Overview**：2-4 段解决方案叙事
+6. **Technical Considerations**：依赖、已知风险、开放问题
+7. **Launch Plan**：内部 alpha → 封闭 beta → GA 分阶段发布
+8. **Appendix**：研究录音、竞品分析、设计稿、仪表盘、支持票据
+
+## Key Principles
+- 先问题后方案
+- 所有功能想法都是假设，用证据验证
+- PRD 协作编写，工程和设计从一开始就参与
+- 开发前锁定范围并获得所有利益相关方书面签字
+- PRFAQ 练习：写发布邮件和怀疑用户会问的 FAQ
+
+## Connection
+- [[Product Manager Agent]] ← produces ← [[Product Requirements Document (PRD)]]
+- [[Discovery Process]] ← feeds_into ← [[Product Requirements Document (PRD)]]
+- [[Opportunity Assessment]] ← precedes ← [[Product Requirements Document (PRD)]]

wiki/concepts/Propp-叙事形态学.md

@@ -0,0 +1,26 @@
+---
+title: "Propp 叙事形态学"
+type: concept
+tags: [narrative-theory, story-structure, fairy-tale]
+---
+
+## 定义
+Vladimir Propp 提出的民间故事形态分析方法，识别出 31 种叙事功能（Functions），将故事结构分解为可重复的最小叙事单元。
+
+## 核心概念
+- 叙事功能：故事中角色完成的固定动作，如「禁止」「违反」「 villainy 」「 departure 」等
+- 角色类型：Propp 识别出 7 种角色角色：英雄（Hero）、捐赠者（Donor）、帮助者（Helper）、 princess/golden object、派遣者（Dispatcher）、 villain（对手）、假冒英雄（False Hero）
+- 叙事序列：功能按固定顺序出现，但并非所有功能都必然出现
+
+## 应用领域
+- 民间故事与童话分析
+- Quest 游戏结构设计
+- 编剧三幕式结构前身
+
+## 来源框架
+- [[Narratologist]] 使用此框架分析民间故事结构和 quest 叙事
+
+## 相关概念
+- [[Campbell 英雄之旅]]
+- [[Vogler 作家旅程]]
+- [[三幕结构]]

wiki/concepts/Pumui-Consensus-Approval.md

@@ -0,0 +1,57 @@
+---
+title: "품의（共识审批）"
+id: pumui-consensus-approval
+type: concept
+tags: [korea, business, decision-making, culture]
+sources: [[specialized-korean-business-navigator]]
+last_updated: 2026-04-20
+---
+
+## Definition
+품의（品夠）是韩国企业的集体决策机制，需要多方批准而非个人拍板。与西方"决策者拍板"模式相反，품의强调共识构建和责任分散。
+
+## Core Process
+
+```
+소개（介绍）→ 미팅（会议）→ 내부검토（内部审查）
+→ 품의서 작성（品夠서起草）→ 결재 라인（审批链）
+→ 예산확인（预算确认）→ 계약（合同）
+```
+
+## Timeline by Company Type
+
+| 公司类型 | 决策周期 |
+|---|---|
+| SME（中小企业） | 6-10周 |
+| Mid-cap（中型企业） | 8-12周 |
+| Chaebol（财阀） | 12-16周 |
+
+西方模式：2-4周
+
+## Key Documents
+
+- **품의서（品夠审批文件）**：由联系人撰写，供应商无法看到或影响其内容
+
+## Critical Rules
+
+1. **绝对不能在首次会议推动决策时间线**——这表明不了解韩国文化
+2. **永远不要绕过联系人直接联系其上级**——这是关系终结行为
+3. **沉默（3-7天）不等于拒绝**——内部讨论正在进行中
+
+## Nunchi Signals
+
+| 阶段 | 正面信号 | 需关注 |
+|---|---|---|
+|介绍 | 有受尊重的人引荐 | 无引荐冷启动响应率<5% |
+|会议 | 邀请同事参加第二次会议 | 仅单人参加无扩展 |
+|内部审查 | 要求参考案例 | 无反馈 |
+|품의서 | 要求具体定价/范围/时间 | — |
+|결재 | "상부에서 검토 중입니다"（正在上级审查）| 沉默≠拒绝 |
+
+## Related Concepts
+- [[Nunchi（눈치）]]
+- [[关系生命周期]]
+
+## Related Entities
+- [[결재 라인]]（审批链）
+- [[품의서]]

wiki/concepts/Pydantic参数验证.md

@@ -0,0 +1,18 @@
+---
+title: "Pydantic参数验证"
+type: concept
+tags: [python, validation, mcp]
+date: 2026-04-20
+---
+
+## Definition
+在 Python MCP Server 中使用 Pydantic 为工具参数提供运行时类型验证、默认值和字段约束。
+
+## Key Points
+- 适合 Python FastMCP / MCP Server 实现
+- 将输入校验前置到工具边界
+- 让错误更可读、更可操作
+
+## Connections
+- [[MCP Builder]]
+- [[MCP服务器]]

wiki/concepts/RICE-Framework.md

@@ -0,0 +1,31 @@
+---
+title: "RICE Framework"
+type: concept
+tags: [prioritization, agile, product-management]
+sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+数据驱动的功能优先排序框架，通过四个维度量化评估每个功能的潜在价值。
+
+## Components
+- **Reach（触达）**：单位时间内受影响的用户数量
+- **Impact（影响）**：对业务目标的贡献度（0.25-3 刻度）
+- **Confidence（信心）**：估计的确定性（百分比）
+- **Effort（工作量）**：开发所需时间（人月）
+
+## Formula
+Score = (Reach × Impact × Confidence) ÷ Effort
+
+## Application
+用于在多个候选功能之间进行客观比较，选择高价值低工作量的特性优先开发。
+
+## Related Concepts
+- [[MoSCoW Method]]
+- [[Kano Model]]
+- [[Team Velocity]]
+- [[Sprint Planning]]
+
+## Source Reference
+- [[Product Sprint Prioritizer]]

wiki/concepts/RICE-Prioritization-Score.md

@@ -0,0 +1,44 @@
+---
+title: "RICE Prioritization Score"
+type: concept
+tags: [product-management, prioritization, metrics]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+RICE 是用于客观优先级排序的量化框架，通过四个维度计算分数：Reach（触达）、Impact（影响）、Confidence（信心）、Effort（努力）。
+
+## Formula
+**RICE Score = (R × I × C) ÷ E**
+
+| Factor | Scale | Description |
+|--------|-------|-------------|
+| Reach | 用户数/季度 | 多少人受影响 |
+| Impact | 0.25, 0.5, 1, 2, 3 | 对指标的影响倍数 |
+| Confidence | 百分比 | 估计的信心水平 |
+| Effort | 人力月数 | 需要多少时间 |
+
+## Example Calculation
+| Factor | Value | Notes |
+|--------|-------|-------|
+| Reach | 10,000 users/quarter | Source: analytics |
+| Impact | 0.5 | half of 1x |
+| Confidence | 80% | Based on: interviews |
+| Effort | 4 person-months | M t-shirt |
+| **RICE Score** | **100** | |
+
+## Use Case
+- 跨多个机会客观排序
+- 支撑 build/defer/kill 决策对话
+- 替代直觉式优先级排序
+
+## Limitation
+- 估算性质，结果应作为讨论起点而非绝对值
+- 不捕捉战略重要性或风险
+- 需要定期重新评估
+
+## Connection
+- [[RICE Prioritization Score]] ← calculated_in ← [[Opportunity Assessment]]
+- [[Roadmap (Now / Next / Later)]] ← ranks ← [[RICE Prioritization Score]]
+- [[Product Backlog]] ← prioritized_by ← [[RICE Prioritization Score]]

wiki/concepts/RICE评分.md

@@ -0,0 +1,49 @@
+---
+title: "RICE评分"
+type: concept
+tags: [Product Management, Prioritization Framework]
+sources: [product-manager.md, product-feedback-synthesizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+RICE评分是一种产品功能优先级排序框架，通过量化四个维度计算优先级分数，用于跨机会客观排序，支撑 build/defer/kill 决策对话。
+
+## Components
+| Factor | Scale | Description |
+|--------|-------|-------------|
+| Reach | 用户数/季度 | 多少人受影响 |
+| Impact | 0.25, 0.5, 1, 2, 3 | 对指标的影响倍数 |
+| Confidence | 百分比 | 估计的信心水平 |
+| Effort | 人力月数 | 需要多少时间 |
+
+## Formula
+```
+RICE Score = (Reach × Impact × Confidence) ÷ Effort
+```
+
+## Example Calculation
+| Factor | Value | Notes |
+|--------|-------|-------|
+| Reach | 10,000 users/quarter | Source: analytics |
+| Impact | 0.5 | half of 1x |
+| Confidence | 80% | Based on: interviews |
+| Effort | 4 person-months | M t-shirt |
+| **RICE Score** | **100** | |
+
+## Usage
+- 由 [[Product Feedback Synthesizer]] 用于将用户反馈转化为数据驱动的优先级决策
+- 由 [[Product Manager Agent]] 用于 [[Opportunity Assessment]] 和 [[Roadmap (Now / Next / Later)]] 优先级排序
+
+## Limitation
+- 估算性质，结果应作为讨论起点而非绝对值
+- 不捕捉战略重要性或风险
+- 需要定期重新评估
+
+## Connections
+- [[Product Feedback Synthesizer]]：使用此框架进行反馈优先级排序
+- [[MoSCoW优先级]]：另一种优先级框架
+- [[Kano模型]]：满意度导向的功能分类模型
+- [[Opportunity Assessment]] ← calculated_in
+- [[Roadmap (Now / Next / Later)]] ← ranks
+- [[Product Backlog]] ← prioritized_by

wiki/concepts/Reentrancy.md

@@ -0,0 +1,40 @@
+---
+title: "Reentrancy"
+type: concept
+tags: [smart-contract, vulnerability, security]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+重入攻击（Reentrancy）是一种智能合约安全漏洞，攻击者通过在外部调用期间重新进入同一合约来操纵状态，导致同一笔资金被多次提取。
+
+## Vulnerability Pattern
+```solidity
+// VULNERABLE: External call BEFORE state update
+function withdraw() external {
+    uint256 amount = balances[msg.sender];
+    (bool success,) = msg.sender.call{value: amount}("");
+    balances[msg.sender] = 0; // State updated AFTER external call
+}
+```
+
+## Attack Mechanism
+1. 攻击者部署恶意合约
+2. 将资金存入目标合约
+3. 调用 withdraw()
+4. 目标合约执行外部调用（发送 ETH）
+5. 恶意合约的 receive() 在状态更新前被触发
+6. 重新调用 withdraw()
+7. 由于状态未更新，攻击者可再次提取资金
+
+## Mitigation
+- **Checks-Effects-Interactions**：先更新状态，再执行外部调用
+- **ReentrancyGuard**：OpenZeppelin 提供的重入锁修饰符
+- **Pull Payment**：使用 PullPayment 模式替代直接发送
+
+## Connections
+- [[Smart Contract Vulnerability]] ← is_type_of ← [[Reentrancy]]
+- [[Checks-Effects-Interactions]] ← prevents ← [[Reentrancy]]
+- [[ReentrancyGuard]] ← prevents ← [[Reentrancy]]
+

wiki/concepts/Roadmap-Now-Next-Later.md

@@ -0,0 +1,37 @@
+---
+title: "Roadmap (Now / Next / Later)"
+type: concept
+tags: [product-management, planning, roadmap]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+产品路线图是按时间维度（当前季度/下个 1-2 季度/3-6 个月）组织的产品组合视图，通过 Now/Next/Later 三层结构管理产品赌注。
+
+## Three Horizons
+| Horizon | Timeframe | Commitment | Confidence |
+|---------|-----------|------------|------------|
+| Now | 当前季度 | 完全对齐，工程、设计、PM 已达成一致 | 高 |
+| Next | 下个 1-2 季度 | 方向承诺，需要 scoping 后才能开发 | 中 |
+| Later | 3-6 个月 | 战略赌注，未排期，有信号才推进 | 低 |
+
+## Now Section
+包含：initiative、user problem、success metric、owner、status、ETA
+
+## Next Section
+包含：initiative、hypothesis、expected outcome、confidence、blocker
+
+## Later Section
+包含：initiative、strategic hypothesis、signal needed to advance
+
+## Explicit Not-Building List
+公开说明不构建什么及原因，防止重复请求并建立信任。
+
+## North Star Metric
+路线图必须定义北极星指标——最好地捕捉用户是否获得价值和业务是否健康的单一指标。
+
+## Connection
+- [[Product Manager Agent]] ← owns ← [[Roadmap (Now / Next / Later)]]
+- [[Opportunity Assessment]] ← informs ← [[Roadmap (Now / Next / Later)]]
+- [[RICE Prioritization Score]] ← ranks ← [[Roadmap (Now / Next / Later)]]

wiki/concepts/SHAP-Analysis.md

@@ -0,0 +1,24 @@
+---
+title: "SHAP Analysis"
+type: concept
+tags: [interpretability, explainability, ml-ops]
+sources: [specialized-model-qa]
+last_updated: 2026-04-20
+---
+
+## Definition
+SHAP（SHapley Additive exPlanations）是一种基于博弈论的模型可解释性方法，用于分解单个预测中每个特征的贡献。
+
+## Outputs
+- 全局解释：summary / beeswarm / bar plot
+- 局部解释：waterfall / force plot
+- 交互分析：SHAP interaction values
+
+## Use in Model QA
+- 解释预测驱动因素
+- 检查特征贡献是否稳定
+- 识别异常依赖或潜在偏差
+
+## Related Concepts
+- [[Partial Dependence Plots]]
+- [[Model Audit]]

wiki/concepts/Seasonal-Calendar.md

@@ -0,0 +1,23 @@
+---
+title: "Seasonal Calendar"
+type: concept
+tags: [market-timing, france, freelance]
+date: 2026-04-20
+---
+
+## Summary
+法国 IT 咨询市场的季节性规律，影响需求波动和议价能力。
+
+## Monthly Breakdown
+| Period | Market Dynamic | Strategy |
+|--------|---------------|----------|
+| **January** | 预算重启，新项目启动 | 最佳提案时机，ESN 积极招人 |
+| **February-March** | 活跃招聘，高需求 | 议价能力峰值，争取更高 TJM |
+| **April-June** | 稳定状态，部分预算审查 | 适合续约谈判提价 |
+| **July-August** | 夏季放缓，团队缩编 | 减少机会，用于技能提升和行政 |
+| **September** | 返校季 — 第二个高峰季 | 强烈需求重启，适合新平台发布 |
+| **October-November** | 年终预算消耗 | ESN 需要填补剩余预算，可谈 |
+| **December** | 放缓 holiday planning | 为 1 月 Pipeline 建设 |
+
+## Connections
+- [[French Consulting Market Navigator]] ← market_timing

wiki/concepts/Semantic-Index.md

@@ -0,0 +1,38 @@
+---
+title: "Semantic Index"
+type: concept
+tags: [index, code-intelligence, navigation]
+last_updated: 2026-04-20
+---
+
+## Definition
+Semantic Index（语义索引）是存储代码符号定义、引用关系和悬停文档的持久化数据结构，支持快速代码导航和文档查询。
+
+## Navigation Index Format (nav.index.jsonl)
+```jsonl
+{"symId":"sym:AppController","def":{"uri":"file:///src/app.php","l":10,"c":6},"refs":[
+  {"uri":"file:///src/routes.php","l":5,"c":10}
+],"hover":{"contents":{"kind":"markdown","value":"```php\nclass AppController extends BaseController\n```"}}}
+```
+
+## Index Schema
+| Field | Description |
+|-------|-------------|
+| symId | 符号唯一标识符，格式：`sym:<name>` |
+| def | 定义位置（文件 URI + 行号 + 列号） |
+| refs | 引用位置数组 |
+| hover | 悬停文档内容（Markdown 格式） |
+
+## Storage Backends
+- **JSONL**：流式写入，适合大规模索引
+- **SQLite**：支持快速随机访问和复杂查询
+- **LSIF**：Language Server Index Format，用于预计算数据导入/导出
+
+## Performance Requirements
+- 定义查找：<20ms（缓存），<60ms（未缓存）
+- 支持 100k+ 符号规模
+- 增量更新，不重建整个索引
+
+## Connections
+- [[graphd]] ← 维护 ← [[Semantic Index]]
+- [[LSIF (Language Server Index Format)]] ← 导入/导出 ← [[Semantic Index]]

wiki/concepts/Social-Identity-Theory.md

@@ -0,0 +1,46 @@
+---
+title: "Social Identity Theory"
+type: concept
+tags: [social-psychology, group-psychology, tajfel]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Social Identity Theory
+
+## Aliases
+- 社会认同理论
+- Social Identity Approach
+- SIT
+
+## Summary
+Henri Tajfel 和 John Turner 提出的社会心理学理论，解释个体如何通过群体成员身份形成自我概念，以及群体间偏见和歧视的心理根源。
+
+## Core Concepts
+
+### 社会认同（Social Identity）
+个体自我概念的一部分，来源于群体成员身份：
+- **内群体（In-group）**：个体所属并产生认同感的群体
+- **外群体（Out-group）**：被感知为与内群体不同或对立的群体
+
+### 心理机制
+- **社会分类（Social Categorization）**：将世界分为群体类别
+- **社会认同（Social Identification）**：接受群体规范并内化为自我概念
+- **社会比较（Social Comparison）**：通过与外群体比较提升自尊
+
+### 内群体偏差（In-Group Bias）
+- 给予内群体成员更多资源或正面评价
+- 倾向于以负面方式描述外群体
+
+### 现实冲突理论（Realistic Conflict Theory）**
+群体间偏见的另一机制：当群体间存在真实资源竞争时，偏见加剧。
+
+## Applications
+- [[Academic Psychologist Agent]] 理解群体动力学
+- 分析群体情境中的角色行为
+- 评估群体对个体决策的影响
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析框架 ← [[Social Identity Theory]]
+- [[Henri Tajfel]] ← 创始人 ← [[Social Identity Theory]]
+- [[Groupthink]] ← 相关概念 ← [[Social Identity Theory]]

wiki/concepts/Sprint-Health-Snapshot.md

@@ -0,0 +1,39 @@
+---
+title: "Sprint Health Snapshot"
+type: concept
+tags: [product-management, agile, sprint]
+sources: [product-manager.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+冲刺健康快照是追踪单个冲刺状态的定期文档，记录承诺 vs 交付、阻塞、范围变更和进入下个冲刺的风险。
+
+## Structure
+1. **Committed vs Delivered**：故事、点数、状态、阻塞
+2. **Velocity**：承诺 pts / 交付 pts（完成率）+ 3 周期滚动平均
+3. **Blockers & Actions**：阻塞表（阻塞、影响、负责人、解决 ETA）
+4. **Scope Changes This Sprint**：变更请求表（请求、来源、决策、理由）
+5. **Risks Entering Next Sprint**：进入下个冲刺的风险
+
+## Key Metrics
+| Metric | Description |
+|--------|-------------|
+| Velocity | 承诺 vs 交付完成率 |
+| Blocker Age | 阻塞存在时间（>24h 是 PM 失败） |
+| Scope Creep | 未经追踪的范围变更 |
+
+## Use Case
+- sprint 结束时编写
+- 为下个 sprint planning 提供输入
+- 识别模式用于团队健康回顾
+
+## Key Principle
+- 零未追踪的 sprint 中期范围增加
+- 阻塞 > 24 小时未解决是 PM 失败
+- 范围变更必须正式评估和文档化
+
+## Connection
+- [[Product Manager Agent]] ← owns ← [[Sprint Health Snapshot]]
+- [[Delivery Phase]] ← monitors ← [[Sprint Health Snapshot]]
+- [[Roadmap (Now / Next / Later)]] ← updated_by ← [[Sprint Health Snapshot]]

wiki/concepts/Sprint-Planning.md

@@ -0,0 +1,31 @@
+---
+title: "Sprint Planning"
+type: concept
+tags: [agile, scrum, ceremony]
+sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+敏捷开发中的核心仪式，定义 sprint 目标并选择可交付的故事。
+
+## Process
+### Pre-Sprint Planning（冲刺前一周）
+1. Backlog Refinement：故事规模、验收标准、Done 定义审核
+2. Dependency Analysis：跨团队协调需求与时间线映射
+3. Capacity Assessment：团队可用性、假期、会议、培训评估
+4. Risk Identification：技术未知项、外部依赖缓解策略
+5. Stakeholder Review：优先级验证和范围对齐
+
+### Sprint Planning（第一天）
+1. Sprint Goal Definition：清晰可衡量的目标与成功标准
+2. Story Selection：基于容量的承诺，包含 15% 缓冲
+3. Task Breakdown：实施规划、估算与技能匹配
+4. Definition of Done：质量标准和自动化验收测试
+5. Commitment：团队对交付物和时间线的共识
+
+## Related Concepts
+- [[Team Velocity]]
+- [[Capacity Planning]]
+- [[RICE Framework]]
+- [[Product Sprint Prioritizer]]

wiki/concepts/Static-Analysis.md

@@ -0,0 +1,40 @@
+---
+title: "Static Analysis"
+type: concept
+tags: [smart-contract, security, tools]
+sources: [blockchain-security-auditor]
+last_updated: 2026-04-20
+---
+
+## Definition
+静态分析（Static Analysis）是通过分析代码结构而不执行程序来检测漏洞的方法，是智能合约安全审计的第一道防线。
+
+## Tools in Ecosystem
+- **Slither**：Trail of Bits 开发，Python 实现
+- **Mythril**：Consensys Diligence 开发，符号执行
+- **Medusa**：二进制模糊测试框架
+- **Semgrep**：通用代码分析工具
+
+## Slither Detectors
+| 严重级别 | 检测器 |
+|---------|--------|
+| High | reentrancy-eth, suicidal, controlled-delegatecall |
+| Medium | reentrancy-benign, timestamp, low-level-calls |
+| Low | naming-convention, unused-state |
+
+## Limitations
+- 只能发现约 30% 的真实漏洞
+- 漏报率高（false negatives）
+- 逻辑漏洞和经济漏洞难以发现
+- 依赖工具更新维护
+
+## Best Practice
+- 静态分析作为第一轮扫描
+- 人工审查作为主要手段
+- 属性测试补充验证
+
+## Connections
+- [[Formal Verification]] ← complements ← [[Static Analysis]]
+- [[Slither]] ← implements ← [[Static Analysis]]
+- [[Mythril]] ← implements ← [[Static Analysis]]
+

wiki/concepts/Story-Structure-Analysis.md

@@ -0,0 +1,27 @@
+---
+title: "Story Structure Analysis"
+type: concept
+tags: [narrative-theory, story-structure, analysis]
+---
+
+## 定义
+系统化分析叙事作品结构的方法论，通过框架识别故事的组成元素和相互关系。
+
+## 分析维度
+- **Controlling Idea**：故事论证的核心论点
+- **Structure Model**：适用的结构模型（三幕式、五幕式、英雄之旅、 Kishōtenketsu 等）
+- **Act Breakdown**：各幕的 Setup、Confrontation、Resolution
+- **Tension Curve**：关键张力峰值和谷值映射
+- **Information Asymmetry**：读者认知与角色认知的信息差
+- **Narrative Debts**：向读者做出的未兑现承诺
+
+## 分析框架
+- [[Propp 叙事形态学]]：民间故事和 quest 结构
+- [[Campbell 英雄之旅]]：英雄叙事
+- [[McKee 故事结构]]：剧本结构
+- [[Todorov 均衡模型]]：基于 disruption 的情节
+- [[Genette 叙事学]]：叙事话语分析
+- [[Barthes 五代码]]：符号学分析
+
+## 来源框架
+- [[Narratologist]] 的核心技术交付物

wiki/concepts/TAM-SAM-SOM.md

@@ -0,0 +1,20 @@
+---
+title: "TAM/SAM/SOM"
+type: concept
+tags: [market-sizing, business-analysis]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+TAM/SAM/SOM 是市场规模分析的三层模型，用于量化市场机会的大小和可实现性。
+
+## Three Layers
+- **TAM（Total Addressable Market）**：总可寻址市场，自顶向下和自底向上分析
+- **SAM（Serviceable Addressable Market）**：可服务市场，考虑地理和业务约束后的现实市场机会
+- **SOM（Serviceable Obtainable Market）**：可获得市场，通过竞争分析确定的可实现市场份额
+
+## Analysis Methods
+- Top-down Analysis：自顶向下，从宏观市场向下分解
+- Bottom-up Analysis：自底向上，从细分市场向上聚合
+- Validation：交叉验证确保准确性

wiki/concepts/TCO.md

@@ -0,0 +1,43 @@
+---
+title: "TCO（全成本所有权）"
+type: concept
+tags: [supply-chain, procurement, cost-analysis]
+---
+
+## Definition
+TCO（Total Cost of Ownership，全成本所有权）是一种采购决策框架，考虑采购项的完整成本，而非单一采购单价。
+
+## Cost Components
+
+### 直接成本
+- 采购单价
+- 模具/夹具费
+- 包装费用
+- 运输费用
+
+### 间接成本
+- 检验成本
+- 来料不良损失
+- 库存持有成本
+- 管理费用
+
+### 隐藏成本
+- 供应商切换成本
+- 质量风险成本
+- 交期延误损失
+- 协调管理开销
+
+### 全生命周期成本
+- 使用与维护成本
+- 处置与回收成本
+- 环境合规成本
+
+## Application
+- 供应商选择决策
+- 采购价格谈判基准
+- 供应商绩效评估维度
+
+## Connections
+- [[Supply Chain Strategist]] ← uses ← [[TCO（全成本所有权）]]
+- [[Kraljic Matrix]] — TCO 常与 Kraljic Matrix 配合用于采购策略制定
+

wiki/concepts/TJM-Brut.md

@@ -0,0 +1,26 @@
+---
+title: "TJM Brut"
+type: concept
+tags: [billing, france, rate]
+date: 2026-04-20
+---
+
+## Summary
+总日均费率（Gross Daily Rate），ESN 向客户收取的日费率，也是计算净收入的基准。
+
+## Definition
+- **Full Name**: Taux Journalier Moyen Brut
+- **Calculation**: 月费用 × 1.5 ÷ 18 可计费天数 = 最低可行 TJM
+- **Rate Structure**:
+  - TJM Brut → Portage → ~50% net
+  - TJM Brut → Micro → ~70% net
+
+## Rate Negotiation Context
+- ESN 以 TJM × 1.4-1.7 向客户收费
+- 如果知道客户预算，可以反推你的 TJM 上限
+- 锚定 15-20% 高于目标值，为谈判留出空间
+
+## Connections
+- [[Portage Salarial]] ← calculation_base
+- [[Micro-Entrepreneur]] ← calculation_base
+- [[French Consulting Market Navigator]] ← rate_benchmark

wiki/concepts/Team-Velocity.md

@@ -0,0 +1,27 @@
+---
+title: "Team Velocity"
+type: concept
+tags: [agile, metrics, team-performance]
+sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+团队在单个 sprint 中完成的故事点数量，用于衡量团队交付能力和进行未来容量规划。
+
+## Key Metrics
+- **历史数据**：6-sprint 滚动平均值，包含趋势分析和季节性调整
+- **Velocity Factors**：团队构成变化、复杂度变化、外部依赖
+- **Capacity Adjustment**：假期、培训、会议开销（通常 15-20%）
+- **Buffer Management**：不确定缓冲（稳定团队 10-15%）
+
+## Target
+- Sprint 间变化 <15%
+- 呈现上升趋势
+- 90%+ 承诺故事点交付率
+
+## Related Concepts
+- [[Sprint Planning]]
+- [[Capacity Planning]]
+- [[RICE Framework]]
+- [[Product Sprint Prioritizer]]

wiki/concepts/Technology-Adoption-Curve.md

@@ -0,0 +1,22 @@
+---
+title: "Technology Adoption Curve"
+type: concept
+tags: [diffusion, innovation, rogerrs]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+技术采用曲线（Rogers 扩散模型）描述了新技术在市场中传播的典型模式，是预测技术采用时间线的核心框架。
+
+## Adoption Stages
+1. **Innovators（创新者）**：2.5%，最早尝试新技术的先驱
+2. **Early Adopters（早期采用者）**：13.5%，有远见的早期采纳者
+3. **Early Majority（早期大众）**：34%，深思熟虑的跟随者
+4. **Late Majority（晚期大众）**：34%，怀疑论者后的采纳者
+5. **Laggards（落后者）**：16%，最后采纳的传统主义者
+
+## Key Metrics
+- Tip Point（临界点）：当采用率达到临界阈值时的爆发增长点
+- Adoption Rate（采用率）：单位时间内的新采用者比例
+- Critical Mass（临界群体）：达到自维持增长所需的采用者数量

wiki/concepts/Technology-Scouting.md

@@ -0,0 +1,24 @@
+---
+title: "Technology Scouting"
+type: concept
+tags: [technology, innovation, startups]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+技术侦察是识别和评估新兴技术的系统化方法，支持创新决策和战略规划。
+
+## Innovation Tracking
+- 专利格局：新兴技术、R&D趋势、创新热点
+- 初创企业生态：融资轮次、转向模式、成功指标
+- 学术研究：大学合作、突破性技术、发表趋势
+- 开源项目：社区发展动力、采用模式、商业潜力
+- 标准制定：行业联盟、协议演进
+
+## Technology Assessment
+- 成熟度分析：技术就绪级别（TRL）、商业可行性
+- 采用预测：扩散模型、网络效应、临界点识别
+- 投资模式：VC投资、企业投资、并购活动
+- 监管影响：政策含义、合规要求
+- 整合机会：平台兼容性、生态系统契合度

wiki/concepts/Todorov-均衡模型.md

@@ -0,0 +1,25 @@
+---
+title: "Todorov 均衡模型"
+type: concept
+tags: [narrative-theory, story-structure, equilibrium]
+---
+
+## 定义
+Tzvetan Todorov 提出的叙事结构模型，基于平衡—失衡—新平衡的循环结构。
+
+## 核心阶段
+1. **Equilibrium（均衡）**：初始平衡状态
+2. **Disruption（失衡）**：平衡被打破，冲突引入
+3. **Recognition（识别）**：认识到失衡状态
+4. **Repair（修复）**：尝试恢复平衡
+5. **New Equilibrium（新均衡）**：新的平衡状态（可能与初始状态不同）
+
+## 变体（五阶段模型）
+- Binary opposites：基于二元对立的冲突结构
+
+## 与其他框架关系
+- 与 [[McKee 故事结构]] 共享 equilibrium-disruption-return 结构
+- 与 [[Campbell 英雄之旅]] 的回归阶段相关
+
+## 来源框架
+- [[Narratologist]] 使用此框架分析 disruption-based plots

wiki/concepts/Trend-Analysis.md

@@ -0,0 +1,31 @@
+---
+title: "Trend Analysis"
+type: concept
+tags: [trend, forecasting, signal-detection]
+sources: [raw/Agent/agency-agents/product/product-trend-researcher.md]
+last_updated: 2026-04-20
+---
+
+## Definition
+趋势分析是通过识别数据中的模式、信号和规律，预测未来发展方向的研究方法。
+
+## Core Capabilities
+- 模式识别（Pattern Recognition）
+- 信号检测（Signal Detection）
+- 未来预测（Future Forecasting）
+- 生命周期映射（Lifecycle Mapping）
+
+## Process
+1. 信号收集：跨50+来源实时聚合
+2. 模式识别：统计分析和异常检测
+3. 上下文分析：驱动因素和障碍
+4. 影响评估：市场影响量化
+5. 验证：专家意见交叉验证
+6. 预测：时间线和采用率预测
+7. 可行性：具体行动建议
+
+## Trend Lifecycle
+- Emergence（出现）
+- Growth（增长）
+- Maturity（成熟）
+- Decline（衰退）

wiki/concepts/Trigger-Framework.md

@@ -0,0 +1,29 @@
+---
+title: "Trigger Framework"
+type: concept
+tags: [salesforce, triggers, architecture]
+sources: [specialized-salesforce-architect.md]
+last_updated: 2026-04-20
+---
+
+# Trigger Framework
+
+Salesforce 触发器的标准化架构模式。
+
+## 核心原则
+- 每个对象一个触发器
+- 触发器不包含业务逻辑，只委托给 handler 类
+- 必须支持批量处理（Bulkification）
+
+## 架构组成
+1. **Trigger** — 入口点，只做委托
+2. **Handler** — 包含业务逻辑
+3. **Selector** — SOQL 查询封装
+4. **Service** — 跨触发器共享逻辑
+
+## 关键规则
+- 无业务逻辑放在触发器中
+- 委托给 handler 类处理所有业务逻辑
+
+## 相关概念
+- [[Bulkification]] — 触发器必须支持批量处理

wiki/concepts/Vaillant-Defense-Mechanisms.md

@@ -0,0 +1,49 @@
+---
+title: "Vaillant Defense Mechanisms Hierarchy"
+type: concept
+tags: [psychodynamic, defense-mechanisms, vaillant]
+sources: []
+last_updated: 2026-04-20
+---
+
+# Vaillant Defense Mechanisms Hierarchy
+
+## Aliases
+- Vaillant 防御机制层级
+- 防御机制层级
+- Defense Mechanism Hierarchy
+
+## Summary
+George Vaillant 通过纵向研究提出的防御机制分类系统，将适应不良到成熟的防御方式组织为四个层级，是精神分析自我心理学的重要贡献。
+
+## Hierarchy Levels
+
+### 成熟防御（Level 4 - Mature）
+- **升华（Sublimation）**：将不可接受的冲动转化为社会认可的活动
+- **幽默（Humor）**：以轻松方式处理困难情绪
+- **压抑（Suppression）**：有意识地推迟处理困难情境
+- **利他（Altruism）**：通过帮助他人处理个人痛苦
+
+### 神经质防御（Level 3 - Neurotic）
+- **理智化（Intellectualization）**：用理性掩盖情感痛苦
+- **情感隔离（Dissociation）**：将情感与情境分离
+- **反形成（Reaction Formation）**：用相反的情感替代真实感受
+
+### 不成熟防御（Level 2 - Immature）
+- **投射（Projection）**：将自身不可接受的特质归于他人
+- **否认（Denial）**：拒绝承认现实
+- **退缩（Withdrawal）**：从情境中退出
+- **躯体化（Somatization）**：心理痛苦转化为身体症状
+
+### 自恋性防御（Level 1 - Narcissistic）
+- **分裂（Splitting）**：将人或情境绝对分为全好或全坏
+- **理想化与贬低（Idealization/Devaluation）**：极端正面或负面评价
+
+## Applications
+- [[Academic Psychologist Agent]] 识别角色的主要和压力下的防御模式
+- 区分适应性与非适应性防御
+- 理解角色的核心创伤与应对策略
+
+## Connections
+- [[Academic Psychologist Agent]] ← 分析工具 ← [[Vaillant 防御机制层级]]
+- [[George Vaillant]] ← 研究者 ← [[Vaillant 防御机制层级]]

wiki/concepts/Vogler-作家旅程.md

@@ -0,0 +1,37 @@
+---
+title: "Vogler 作家旅程"
+type: concept
+tags: [narrative-theory, story-structure, screenplay, hero-journey]
+---
+
+## 定义
+Christopher Vogler 在《作家之旅》中将 Joseph Campbell 的英雄神话理论转化为现代编剧实用框架。
+
+## 核心阶段
+1. Ordinary World（普通世界）
+2. Call to Adventure（冒险召唤）
+3. Refusal of the Call（拒绝召唤）
+4. Meeting the Mentor（遇见导师）
+5. Crossing the Threshold（跨越门槛）
+6. Tests, Allies, Enemies（考验、盟友、敌人）
+7. Approach to the Inmost Cave（接近最深处洞穴）
+8. Ordeal（严峻考验）
+9. Reward（获得奖赏）
+10. The Road Back（回归之路）
+11. Resurrection（复活）
+12. Return with the Elixir（带着灵药回归）
+
+## 角色原型
+- Hero（英雄）
+- Mentor（导师）
+- Threshold Guardian（门槛守护者）
+- Herald（信使）
+- Shapeshifter（变形者）
+- Shadow（暗影/对手）
+- Trickster（骗徒）
+
+## 与 [[Campbell 英雄之旅]] 的关系
+Vogler 直接基于 Campbell 的单一神话理论，但针对现代编剧实践进行了调整和优化。
+
+## 来源框架
+- [[Narratologist]] 使用此框架进行角色弧线评估和英雄叙事分析