Empty Placeholder Resolution（空占位清理决策）

知识库位置：FDE Knowledge Base/00 Knowledge Map/13-Empty-Placeholder-Resolution.md 术语不确定时，请查阅 Glossary（中英文术语表）。

Scope（范围）：

01-Fundamentals（基础知识域）: 9
03-Engineering（工程域）: 23

Total（合计）: 32

目标：

v1.0 不允许 Core 域（核心域）存在无解释的 Empty Placeholder（空占位，指已建立目录但没有任何内容解释的知识节点）。

每个占位必须进入以下四种状态（Resolution，处理结论）之一：

WRITE（写入独立核心页）
→ 值得成为独立核心知识

FIELD PRIMER（领域入门页）
→ 保留独立页面，但只写 FDE 必需深度

MERGE / REDIRECT（合并/重定向）
→ 已有更合适 Canonical（权威页面，同一概念只写一次的唯一定义来源）页面

DEPRECATE（废弃）
→ 不值得作为独立知识条目继续存在

Resolution Principles（清理原则）

Principle 1 — 不建设技术百科

例如：

Python（Python 语言）
Java（Java 语言）
AWS（亚马逊云）
Kafka（分布式事件流平台）

知识库不应该回答：

Python 的所有语法是什么？

而应该回答：

FDE 为什么需要理解 Python？现场什么时候遇到？需要掌握到什么深度？常见判断和坑是什么？

Principle 2 — Technology Page ≠ Tutorial（技术条目不等于教程）

技术条目（Technology Page）的标准结构统一为：

What It Is（它是什么）

Why FDE Cares（FDE 为什么关心）

Where It Appears in Customer Environments（它在客户环境的哪里出现）

What You Need to Know（你需要知道什么）

Key Concepts（关键概念）

FDE Decisions（FDE 需要做的决策）

Common Failure Modes（常见失败模式）

Questions to Ask（应该问的问题）

How Deep Should an FDE Go?（FDE 应该掌握到多深）

Related Knowledge（关联知识）

Principle 3 — 现有 Canonical Concept 优先

如果已有：

Authentication-Authorization（认证与授权）
Event-Driven-Integration（事件驱动集成）
Data-Pipeline（数据管道）

就不要再创建一个高度重复的：

RBAC（基于角色的访问控制）
Kafka（Kafka 平台页）
ETL（抽取-转换-加载独立理论页）

长篇独立理论。

可以保留 Primer（入门页），但 Canonical 原理只写一次。

Fundamentals — Resolution（基础知识域处理结论）

知识库位置：

/01-Fundamentals/

9 个占位全部值得解决。

建议：

WRITE（写入独立核心页）: 8
MERGE / REDIRECT（合并/重定向）: 1

What is FDE / Working Model（FDE 定义/工作模式）

原占位：

/01-Fundamentals/What-is-FDE/Working-Model

Resolution（结论）：MERGE（合并）

Canonical（权威页面）：

/01-Fundamentals/01-What-is-FDE

原因：

What is FDE（什么是 FDE）和 Working Model（工作模式）强相关，不值得继续形成嵌套空目录。

建议在现有 01-What-is-FDE 增加：

## FDE Working Model（FDE 工作模式）

核心内容：

Customer Context（客户上下文）
↓
Problem（问题）
↓
Build（构建）
↓
Deploy（部署）
↓
Observe（观察）
↓
Iterate（迭代）

FDE 的工作模式不是：

Requirements（需求）
→ Build（构建）
→ Handoff（移交）

而更接近：

Discover（调研）
↔
Build（构建）
↔
Deploy（部署）
↔
Learn（学习）

FDE History（FDE 发展史）

知识库位置：

/01-Fundamentals/04-FDE-History

Resolution（结论）：WRITE（写入独立核心页）

Purpose（目的）

不是做完整行业史，而是解释：

为什么会出现 FDE 这种角色？

Evolution（演进）

传统企业软件大致有：

Product Company（产品公司）
↓
Sales（销售）
↓
Implementation / Consulting（实施/咨询）
↓
Customer（客户）

问题是：

产品团队与客户真实复杂环境之间距离太远。

随着：

Cloud（云计算）
Data Platforms（数据平台）
APIs（应用程序接口）
AI（人工智能）
Complex enterprise systems（复杂企业系统）

增长，越来越多产品需要：

Strong Engineer（强工程能力）
+
Customer Context（客户上下文）
+
Fast Adaptation（快速适应）

FDE 因此逐渐成为一种独立工作模式。

Core Historical Shift（核心历史转变）

Software shipped as product（软件作为产品交付）
↓
Software adapted in customer environment（软件在客户环境中被适配）
↓
Software co-developed with customer workflow（软件与客户工作流共同开发）

FDE Insight（FDE 洞察）

FDE 的出现本质上来自：

Product cannot anticipate every important enterprise context.（产品无法预见每一个重要的企业环境。）

FDE in AI Era（AI 时代的 FDE）

知识库位置：

/01-Fundamentals/05-FDE-in-AI-Era

Resolution（结论）：WRITE（写入独立核心页）— HIGH PRIORITY（高优先级）

AI 时代 FDE 的重要性反而提高。

原因：

AI Capability（AI 能力）
≠
Business Solution（业务解决方案）

模型能力必须结合：

Enterprise Data（企业数据）
+
Workflow（工作流）
+
Tools（工具）
+
Security（安全）
+
Human Judgment（人类判断）
+
Evaluation（评估）

Traditional Software（传统软件）

通常：

Requirement（需求）
→ Deterministic behavior（确定性行为）

AI 系统增加：

Probabilistic behavior（概率性行为）
+
Evaluation uncertainty（评估的不确定性）
+
Data dependency（数据依赖）
+
Trust（信任）
+
Human control（人工控制）

因此 FDE 需要同时处理：

Model（模型）
Data（数据）
Integration（集成）
Workflow（工作流）
Evaluation（评估）
Security（安全）
Adoption（用户采用）

AI-era FDE（AI 时代的 FDE）

核心能力不是：

Prompt Engineering（提示词工程）。

而是：

Where should AI be used?（AI 应该用在哪里？）

Where should AI NOT be used?（AI 不应该用在哪里？）

What context does it need?（它需要什么上下文？）

What action should it be allowed to take?（应允许它执行什么动作？）

How do we prove it works?（我们如何证明它有效？）

AI-era Principle（AI 时代原则）

Model Capability（模型能力）
×
Enterprise Context（企业上下文）
×
Workflow Fit（工作流契合度）
×
Trust（信任）
×
Adoption（用户采用）
=
Business Value（业务价值）

Company Variations（公司差异）

知识库位置：

/01-Fundamentals/06-FDE-Company-Variations

Resolution（结论）：WRITE（写入独立核心页）

“FDE” 在不同公司可能代表不同角色。

常见变体：

Product-heavy FDE（产品侧重型 FDE）
Engineering-heavy FDE（工程侧重型 FDE）
Deployment-heavy FDE（部署侧重型 FDE）
AI-heavy FDE（AI 侧重型 FDE）
Consulting-heavy FDE（咨询侧重型 FDE）
Solutions-heavy FDE（方案侧重型 FDE）

Dimension 1 — Coding Depth（维度一：编码深度）

有些公司：

70–90% engineering（工程占 70–90%）

另一些：

30–50% engineering（工程占 30–50%）
+
customer / architecture / delivery（客户/架构/交付）

具体比例不是标准定义。

Dimension 2 — Product Boundary（维度二：产品边界）

有些 FDE：

在固定产品上做客户集成。

另一些：

可以构建大量客户特定软件。

Dimension 3 — Customer Ownership（维度三：客户负责范围）

可能从：

Technical implementation only（仅技术实施）

到：

Discovery（调研）
→ Architecture（架构）
→ Build（构建）
→ Production（生产）
→ Value（价值）

Dimension 4 — Commercial Responsibility（维度四：商业责任）

有些团队接近：

Customer Engineering（客户工程）
Solutions Engineering（解决方案工程）

另一些完全属于：

Engineering（工程）

FDE Rule（FDE 判断规则）

判断岗位不要只看 Title（职位头衔）。

应该问：

What problems do I own?（我负责什么问题？）

How much do I code?（我写多少代码？）

How close am I to the customer?（我离客户多近？）

Can I change the product?（我能改变产品吗？）

Do I own production?（我对生产负责吗？）

Am I measured on delivery or revenue?（我按交付还是按营收考核？）

Role Comparison — FDE vs Software Engineer（角色对比：FDE vs 软件工程师）

知识库位置：

/01-Fundamentals/Role-Comparison/01-FDE-vs-SWE

Resolution（结论）：WRITE（写入独立核心页）

Dimension（维度）	FDE	SWE（Software Engineer，软件工程师）
Primary context（主要上下文）	Customer problem（客户问题）	Product/system（产品/系统）
Ambiguity（模糊性）	High（高）	Varies（视情况）
Customer contact（客户接触）	High（高）	Usually lower（通常较低）
Coding（编码）	High（高）	High（高）
Product boundary（产品边界）	Flexible（灵活）	Usually defined（通常已定义）
Delivery ownership（交付负责）	Often end-to-end（常为端到端）	Usually component/team（通常为组件/团队）
Business discovery（业务发现）	Important（重要）	Sometimes（有时）
Production（生产）	Customer-specific（客户特定）	Product-wide（产品全局）

核心区别不是：

FDE 会不会写代码。

而是：

FDE 的工程工作被客户上下文直接驱动。

Role Comparison — FDE vs Solutions Architect（角色对比：FDE vs 解决方案架构师）

知识库位置：

/01-Fundamentals/Role-Comparison/02-FDE-vs-Solution-Architect

Resolution（结论）：WRITE（写入独立核心页）

Solution Architect（解决方案架构师）通常更偏：

Design（设计）
Guidance（指导）
Architecture（架构）

FDE 通常更偏：

Design（设计）
+
Build（构建）
+
Debug（调试）
+
Deploy（部署）

最简单区别：

Architect often explains how it should work.（架构师常常解释系统应该如何工作。） FDE often has to make it actually work.（FDE 常常必须让它真正跑起来。）

实际边界随公司而变化。

Role Comparison — FDE vs Sales Engineer（角色对比：FDE vs 售前工程师）

知识库位置：

/01-Fundamentals/Role-Comparison/03-FDE-vs-Sales-Engineer

Resolution（结论）：WRITE（写入独立核心页）

Sales Engineer（售前工程师）通常偏：

Pre-sales（售前）
Demo（演示）
Technical qualification（技术资格判定）
Solution positioning（方案定位）

FDE 更常进入：

Post-sale / strategic pilot（售后/战略试点）
Implementation（实施）
Production（生产）
Customer-specific engineering（客户特定工程）

但一些组织中会有明显重叠。

关键问题：

Is success measured by closing the deal（成功按成交衡量）
or
making the deployed solution successful?（还是按已部署方案的成功衡量？）

Role Comparison — FDE vs Consultant（角色对比：FDE vs 顾问）

知识库位置：

/01-Fundamentals/Role-Comparison/04-FDE-vs-Consultant

Resolution（结论）：WRITE（写入独立核心页）

Consultant（顾问）通常强项：

Problem structuring（问题结构化）
Business analysis（业务分析）
Stakeholder management（干系人管理）
Recommendation（建议）

FDE 还必须具备：

Build（构建）
Test（测试）
Integrate（集成）
Debug（调试）
Operate（运营）

区别不是：

Consultant 不懂技术。

而是 FDE 的核心责任通常包含：

direct technical execution.（直接的技术执行。）

Role Comparison — FDE vs Product Manager（角色对比：FDE vs 产品经理）

知识库位置：

/01-Fundamentals/Role-Comparison/05-FDE-vs-Product-Manager

Resolution（结论）：WRITE（写入独立核心页）

PM（Product Manager，产品经理）主要优化：

Product（产品）
across（跨）
many customers（多个客户）

FDE 主要优化：

Solution（解决方案）
inside（在）
specific customer context（特定客户上下文内）

FDE 的现场学习可以反向影响 Product：

Customer Need（客户需求）
↓
FDE learns pattern（FDE 学到模式）
↓
Repeated pattern（模式重复出现）
↓
Product feedback（产品反馈）
↓
Product capability（产品能力）

Fundamentals Final Structure（基础知识域最终结构）

建议：

01-Fundamentals
│
├── 01-What-is-FDE
├── 02-FDE-Project-Lifecycle
├── 03-FDE-Capability-Model
├── 04-FDE-History
├── 05-FDE-in-AI-Era
├── 06-FDE-Company-Variations
│
└── Role-Comparison（角色对比）
    ├── 01-FDE-vs-SWE
    ├── 02-FDE-vs-Solution-Architect
    ├── 03-FDE-vs-Sales-Engineer
    ├── 04-FDE-vs-Consultant
    └── 05-FDE-vs-Product-Manager

原：

What-is-FDE/Working-Model

合并进：

01-What-is-FDE

Engineering Placeholder Strategy（工程域占位策略）

知识库位置：

/03-Engineering/README

这里最重要。

23 个占位不应该都升级成大型知识模块。

建议分成：

Core Engineering Concepts（核心工程概念）: 9

Enterprise Technology Primers（企业技术入门页）: 9

Language / Platform Orientation（语言/平台导向页）: 5

其中一部分实际是 Merge（合并）。

Engineering — AI / Embedding（工程域：AI/嵌入表示）

知识库位置：

/03-Engineering/AI/10-Embedding

Resolution（结论）：WRITE（写入独立核心页）

What It Is（它是什么）

Embedding（向量化/嵌入）将内容映射为 Vector（向量）表示，使系统能够根据 Semantic Similarity（语义相似性）进行比较。

Why FDE Cares（FDE 为什么关心）

主要出现于：

RAG（Retrieval-Augmented Generation，检索增强生成）
Semantic Search（语义检索）
Similarity（相似度计算）
Recommendation（推荐）
Deduplication（去重）

FDE Needs to Understand（FDE 需要理解什么）

至少理解：

Text（文本）
↓
Embedding Model（嵌入模型）
↓
Vector（向量）
↓
Similarity Search（相似度检索）

以及：

embedding model choice（嵌入模型选型）
dimensions（维度）
normalization（归一化）
similarity（相似度度量）
multilingual behavior（多语言行为）
domain vocabulary（领域词汇）
model migration（模型迁移）

Common Failure Modes（常见失败模式）

把 embedding similarity（嵌入相似度）当 business correctness（业务正确性）
不重新 embedding（重新向量化）就换 model（模型）
对 exact identifier（精确标识符，如订单号）过度依赖 semantic retrieval（语义检索）
忽略语言和领域词汇差异

Key Decision（关键决策）

Embedding 不是数据库替代品。

Engineering — Vector Database（工程域：向量数据库）

知识库位置：

/03-Engineering/AI/11-Vector-Database

Resolution（结论）：WRITE（写入独立核心页）

FDE Definition（FDE 定义）

Vector Database / Vector Search Engine（向量数据库/向量检索引擎）用于：

Store / index vectors（存储/索引向量）
↓
Nearest-neighbor search（近邻搜索）

FDE Questions（FDE 选型问题）

选择之前问：

Data volume?（数据量多大？）
Metadata filtering?（需要元数据过滤吗？）
ACL filtering?（需要 ACL，Access Control List，访问控制列表级别的权限过滤吗？）
Hybrid search?（需要 Hybrid Search，混合检索，即向量+关键词吗？）
Update frequency?（更新频率如何？）
Existing database?（已有数据库能否承担？）
Operational burden?（运维负担多大？）

Important Principle（重要原则）

不要默认：

做 RAG 必须新引入专门 Vector DB（向量数据库）。

对于很多规模：

Existing search engine（既有搜索引擎）
or
PostgreSQL + vector support（PostgreSQL 数据库 + 向量扩展）

可能已经足够。

优先：

Simplest viable infrastructure（最简可行基础设施）。

Engineering — SQL（工程域：结构化查询语言）

知识库位置：

/03-Engineering/Data/06-SQL

Resolution（结论）：WRITE（写入独立核心页）— CORE（核心）

SQL（Structured Query Language，结构化查询语言）是 FDE 最值得掌握的基础技能之一。

FDE 至少应独立处理：

SELECT（查询）
JOIN（关联）
GROUP BY（分组聚合）
CTE（Common Table Expression，公用表表达式）
Window Functions（窗口函数）
Aggregation（聚合）
Indexes basics（索引基础）
Query plan basics（查询计划基础）
Transactions basics（事务基础）

Typical FDE Usage（FDE 典型用法）

inspect customer data（检查客户数据）
debug pipeline（调试管道）
validate integration（验证集成）
calculate baseline metrics（计算基线指标）
build quick prototype（快速搭建原型）
investigate data quality（排查数据质量）

Principle（原则）

对于结构化精确查询：

SQL / API（结构化查询语言/应用程序接口）

通常优于：

RAG / LLM（检索增强生成/大语言模型）

Engineering — ETL / ELT（工程域：抽取-转换-加载）

知识库位置：

/03-Engineering/Data/07-ETL-vs-ELT

Resolution（结论）：WRITE（写入独立核心页）

ETL（Extract, Transform, Load，抽取-转换-加载）：

Extract（抽取）
→ Transform（转换）
→ Load（加载）

ELT（Extract, Load, Transform，抽取-加载-转换）：

Extract（抽取）
→ Load（加载）
→ Transform（转换）

核心判断不是缩写。

而是：

Transformation（数据转换）在什么环境发生，为什么？

FDE Questions（FDE 选型问题）

Source size?（源数据量多大？）
Warehouse capability?（数仓算力如何？）
Sensitive data?（有敏感数据吗？）
Transformation complexity?（转换复杂度如何？）
Raw data retention?（原始数据需要保留吗？）
Recovery requirement?（恢复要求是什么？）

Engineering — Data Warehouse（工程域：数据仓库）

知识库位置：

/03-Engineering/Data/08-Data-Warehouse

Resolution（结论）：FIELD PRIMER（领域入门页）

重点解释：

面向分析和整合的数据平台。

典型用途：

BI（Business Intelligence，商业智能）
historical analytics（历史分析）
business metrics（业务指标）
customer 360（客户 360 视图）
ML features（机器学习特征）

FDE 重点理解：

analytical vs transactional workloads（分析型 vs 事务型负载）
dimensional modeling basics（维度建模基础）
batch freshness（批量数据新鲜度）
source lineage（数据血缘）
cost（成本）

不需要建设完整 Data Warehouse（数据仓库）教科书。

Engineering — Data Lake（工程域：数据湖）

知识库位置：

/03-Engineering/Data/09-Data-Lake

Resolution（结论）：FIELD PRIMER（领域入门页）

重点：

Large-scale raw / semi-structured data（大规模原始/半结构化数据）
+
Object storage（对象存储）
+
Multiple downstream consumers（多个下游消费方）

FDE 关注：

schema（数据结构定义）
partitioning（分区）
governance（治理）
discoverability（可发现性）
lifecycle（生命周期）
data quality（数据质量）

最大 Anti-pattern（反模式）：

Data Lake 变 Data Swamp（数据湖变数据沼泽）。

Engineering — Kafka（工程域：Kafka 事件流平台）

知识库位置：

/03-Engineering/Data/10-Kafka

Resolution（结论）：FIELD PRIMER（领域入门页）+ CROSS-LINK（交叉链接）

Canonical concepts（权威概念页）：

/03-Engineering/Integration/05-Event-Driven-Integration

/03-Engineering/Decision-Guides/01-REST-vs-Event-Driven

Kafka 页面只解释：

客户系统里出现 Kafka 时 FDE 需要理解什么？

包括：

Topic（主题）
Partition（分区）
Producer（生产者）
Consumer（消费者）
Consumer Group（消费者组）
Offset（消费位移）
Retention（数据保留期）
Ordering（顺序保证）
Replay（重放）

以及典型问题：

duplicate（重复消息）
consumer lag（消费滞后）
schema（结构演化）
ordering（顺序）

不要做 Kafka 运维教程。

Engineering — Spark（工程域：Spark 分布式计算引擎）

知识库位置：

/03-Engineering/Data/11-Spark

Resolution（结论）：FIELD PRIMER（领域入门页）

保留原因：

FDE 可能频繁进入已有 Big Data（大数据）环境。

只需要理解：

distributed processing（分布式处理）
batch（批处理）
dataframe（数据帧）
partition（分区）
shuffle（混洗）
job（作业）
executor（执行器）
memory / skew basics（内存/数据倾斜基础）

FDE Boundary（FDE 边界）

如果项目需要深入调优 Spark 集群：

应与 Data Platform specialist（数据平台专家）合作。

不是每个 FDE 都需要成为 Spark 专家。

Engineering — AWS（工程域：亚马逊云）

知识库位置：

/03-Engineering/Cloud/07-AWS

Resolution（结论）：FIELD PRIMER（领域入门页）

不要写 AWS（Amazon Web Services，亚马逊云服务平台）产品目录。

统一围绕六类能力：

Compute（计算）
Storage（存储）
Database（数据库）
Networking（网络）
Identity（身份）
Observability（可观测性）

映射常见服务即可。

FDE 更重要的是理解：

Which capability do I need?（我需要哪类能力？）

而不是背服务名。

Engineering — Azure（工程域：微软云）

知识库位置：

/03-Engineering/Cloud/08-Azure

Resolution（结论）：FIELD PRIMER（领域入门页）

采用和 AWS 完全相同的结构。

重点加入：

enterprise identity context（企业身份环境）
Microsoft-heavy enterprise environments（微软技术栈为主的大型企业环境）
Azure AD / Entra concepts（微软 Entra ID，原 Azure Active Directory，企业目录与身份服务概念）
managed AI / data environment awareness（托管 AI/数据环境意识）

避免做认证考试型内容。

Engineering — GCP（工程域：谷歌云）

知识库位置：

/03-Engineering/Cloud/09-GCP

Resolution（结论）：FIELD PRIMER（领域入门页）

同样按：

Compute（计算）
Storage（存储）
Database（数据库）
Networking（网络）
Identity（身份）
Observability（可观测性）
AI/Data（AI/数据）

结构介绍。

Cloud Provider Comparison（云厂商对比）

知识库位置：

/03-Engineering/Cloud/10-Cloud-Provider-Orientation

建议 AWS / Azure / GCP 三页之外再提供一张映射表，但不新增空占位。

Capability（能力）	AWS	Azure	GCP（Google Cloud Platform，谷歌云平台）
Compute（计算）	compute service（计算服务）	compute service	compute service
Object Storage（对象存储）	object storage	object storage	object storage
Identity（身份）	IAM（身份与访问管理）	identity/IAM	IAM
Managed Kubernetes（托管容器编排）	managed K8s（Kubernetes）	managed K8s	managed K8s
Data Warehouse（数据仓库）	managed warehouse	managed analytics	managed warehouse

具体产品名称会变化，知识库应优先保存 capability model（能力模型），而不是产品目录。

Engineering — Kubernetes（工程域：容器编排平台）

知识库位置：

/03-Engineering/Cloud/11-Kubernetes

Resolution（结论）：WRITE（写入独立核心页）

FDE 至少理解：

Cluster（集群）
Node（节点）
Pod（容器组）
Deployment（部署）
Service（服务）
Ingress（入口路由）
ConfigMap（配置对象）
Secret（密钥对象）
Namespace（命名空间）

Why FDE Cares（FDE 为什么关心）

客户可能要求：

deploy into existing K8s（部署进既有 Kubernetes 集群）
private cluster（私有集群）
customer-managed environment（客户自管环境）
production scaling（生产扩容）

FDE Should Be Able To（FDE 应能做到）

read deployment manifest（读懂部署清单）
inspect pod health（检查容器组健康状态）
inspect logs（查看日志）
understand service exposure（理解服务暴露方式）
debug basic networking/config（排查基础网络/配置问题）
reason about scaling（推理扩容问题）

不要求：

成为 Kubernetes platform engineer（Kubernetes 平台工程师）。

Engineering — Terraform（工程域：基础设施即代码）

知识库位置：

/03-Engineering/Cloud/12-Terraform

Resolution（结论）：FIELD PRIMER（领域入门页）

核心理解：

Infrastructure（基础设施）
→ Declarative Configuration（声明式配置）
→ Plan（计划）
→ Apply（应用）
→ State（状态）

FDE 需要关注：

reproducibility（可复现性）
environment consistency（环境一致性）
secrets（密钥）
remote state（远程状态）
change review（变更评审）
drift（配置漂移）

Engineering — ERP（工程域：企业资源计划系统）

知识库位置：

/03-Engineering/Integration/07-ERP

Resolution（结论）：FIELD PRIMER（领域入门页）— HIGH VALUE（高价值）

不是讲如何实施 ERP（Enterprise Resource Planning，企业资源计划系统）。

而是让 FDE 理解：

ERP 通常承担：

Finance（财务）
Procurement（采购）
Inventory（库存）
Orders（订单）
Manufacturing（制造）
Master Data（主数据）

FDE Questions（FDE 调研问题）

Which module owns the data?（哪个模块拥有这份数据？）
Is ERP source of truth?（ERP 是唯一事实来源吗？）
API or batch?（接口还是批量？）
Customization level?（定制化程度如何？）
Transaction boundaries?（事务边界在哪里？）
Rate limits?（速率限制是什么？）
Change control?（变更管控流程是什么？）

Important Principle（重要原则）

ERP 通常属于：

high-criticality transactional system（高关键性事务系统）。

AI 不应绕过 ERP 的业务规则直接修改核心记录。

Engineering — CRM（工程域：客户关系管理系统）

知识库位置：

/03-Engineering/Integration/08-CRM

Resolution（结论）：FIELD PRIMER（领域入门页）

CRM（Customer Relationship Management，客户关系管理系统）常承担：

Accounts（客户账户）
Contacts（联系人）
Leads（线索）
Opportunities（商机）
Activities（活动记录）

FDE 高频场景：

Sales Copilot（销售副手）
Support（客服支持）
Customer 360（客户 360 视图）
RevOps（Revenue Operations，收入运营）

重点问题：

User permissions（用户权限）
Data quality（数据质量）
Custom fields（自定义字段）
Object model（对象模型）
API limits（接口限额）
Write-back controls（写回控制）

Engineering — MES（工程域：制造执行系统）

知识库位置：

/03-Engineering/Integration/09-MES

Resolution（结论）：FIELD PRIMER（领域入门页）

MES（Manufacturing Execution System，制造执行系统）。

FDE 至少理解：

ERP（企业资源计划）
↓
MES（制造执行）
↓
Production / Machines（生产/机器设备）

MES 通常管理：

production orders（生产工单）
shop-floor execution（车间现场执行）
work center（工作中心）
traceability（可追溯性）
production status（生产状态）

重点：

MES 属于 operational production path（生产运营路径），变更风险通常高。

Engineering — RBAC（工程域：基于角色的访问控制）

原占位：

/03-Engineering/Integration/RBAC

Resolution（结论）：MERGE / REDIRECT（合并/重定向）

Canonical（权威页面）：

/03-Engineering/Integration/01-Authentication-Authorization

新增 subsection（小节）：

## Role-Based Access Control（基于角色的访问控制）

并解释：

User（用户）
→ Role（角色）
→ Permission（权限）
→ Resource / Action（资源/操作）

同时补充：

RBAC（Role-Based Access Control，基于角色的访问控制）
ABAC（Attribute-Based Access Control，基于属性的访问控制）
group-based access（基于组的访问控制）

无需再维护独立 RBAC 页面。

Engineering — API Gateway（工程域：API 网关）

知识库位置：

/03-Engineering/Integration/10-API-Gateway

Resolution（结论）：WRITE（写入独立核心页）

FDE 需要理解 API Gateway（API 网关）常承担：

Routing（路由）
Authentication（认证）
Rate Limiting（限流）
TLS（Transport Layer Security，传输层安全协议加密）
Logging（日志）
Policy（策略）
Transformation（报文转换）

Common FDE Problems（FDE 常见问题）

401 / 403 来自 Gateway（网关），而非 Application（应用）
timeout（超时）配置不一致
payload size（报文大小限制）
rate limit（速率限制）
header stripping（请求头被剥离）
client identity lost（客户端身份丢失）

Debugging Rule（调试规则）

调用链：

Client（客户端）
↓
Gateway（网关）
↓
Service（服务）

必须知道错误发生在哪层。

Engineering — Enterprise Security（工程域：企业安全）

知识库位置：

/03-Engineering/Integration/11-Enterprise-Security

Resolution（结论）：WRITE（写入独立核心页）— CORE（核心）

不要做 Cybersecurity（网络安全）百科。

面向 FDE，只覆盖客户项目最常遇到的：

Identity（身份）
Authorization（授权）
Network（网络）
Secrets（密钥）
Data Protection（数据保护）
Audit（审计）
Vendor / Model Risk（供应商/模型风险）
Incident（事件响应）

FDE Security Model（FDE 安全模型）

每个项目至少问：

Who is the user?（用户是谁？）

What can they access?（他们能访问什么？）

What data enters the system?（什么数据进入系统？）

Where does data leave?（数据从哪里离开？）

What actions can the system perform?（系统可以执行什么动作？）

What gets logged?（什么被记录？）

What happens if credentials leak?（凭证泄漏会发生什么？）

AI-specific（AI 特有安全项）

增加：

prompt/data handling（提示词与数据处理）
model provider（模型供应商）
tool permissions（工具权限）
sensitive context（敏感上下文）
output risk（输出风险）
auditability（可审计性）

Engineering — Python（工程域：Python 语言）

知识库位置：

/03-Engineering/Software/06-Python-for-FDE

Resolution（结论）：FIELD PRIMER（领域入门页）

不写 Python 语言教程。

页面定位：

Python 在 FDE 工作中的典型用途和最低熟练度。

典型：

API prototype（接口原型）
data exploration（数据探索）
scripts（脚本）
AI（人工智能开发）
automation（自动化）
backend（后端）

Expected Skill（预期技能）

FDE 应能：

Read existing Python（读懂既有 Python 代码）
Write scripts（编写脚本）
Build basic API（搭建基础接口）
Handle JSON（处理 JSON 数据）
Use virtual environments（使用虚拟环境）
Debug errors（调试报错）
Write tests（编写测试）

Engineering — TypeScript（工程域：TypeScript 语言）

知识库位置：

/03-Engineering/Software/07-TypeScript-for-FDE

Resolution（结论）：FIELD PRIMER（领域入门页）

重点：

frontend / full-stack（前端/全栈）
Node backend（Node.js 后端）
typed API contracts（类型化 API 契约）
async programming（异步编程）
package ecosystem（包生态）

FDE 应能：

Read（读懂）
Modify（修改）
Debug（调试）
Build simple service/application（搭建简单服务/应用）

不需要语言规范百科。

Engineering — Java（工程域：Java 语言）

知识库位置：

/03-Engineering/Software/08-Java-for-Enterprise-FDE

Resolution（结论）：FIELD PRIMER（领域入门页）

Java 的意义主要来自：

大量 Enterprise backend（企业后端）/ legacy（遗留系统）/ regulated systems（强监管系统）。

FDE 至少需要：

read Java service structure（读懂 Java 服务结构）
understand build/dependencies（理解构建与依赖）
REST service basics（REST 服务基础）
logs/exceptions（日志与异常）
configuration（配置）
common JVM environment concepts（常见 JVM，Java Virtual Machine，Java 虚拟机环境概念）

Boundary（边界）

不是所有 FDE 都必须把 Java 作为主语言。

但在大型 Enterprise（企业）环境中：

能读懂往往比完全不会更重要。

Engineering — Git（工程域：版本管理）

知识库位置：

/03-Engineering/Software/09-Git-for-FDE

Resolution（结论）：WRITE（写入独立核心页）— FOUNDATION（基础）

至少覆盖：

clone（克隆）
branch（分支）
commit（提交）
merge（合并）
rebase basics（变基基础）
pull request（拉取请求）
conflict resolution（冲突解决）
tags（标签）
revert（回退）

FDE-specific Importance（FDE 特有重要性）

FDE 常在：

fast prototype（快速原型）
customer branches（客户分支）
configuration changes（配置变更）
deployment fixes（部署修复）

中工作。

必须避免：

Production fix（生产修复）
→ only exists on one engineer laptop（只存在于一台工程师笔记本上）

所有重要代码和配置变化都应可追踪。

Final Resolution Table — Fundamentals（基础知识域最终决策表）

Placeholder（占位）	Resolution（结论）	Priority（优先级）
Company Variations（公司差异）	WRITE	Medium（中）
FDE in AI Era（AI 时代的 FDE）	WRITE	High（高）
History（发展史）	WRITE	Medium（中）
What is FDE/Working Model（FDE 定义/工作模式）	MERGE	High（高）
vs Consultant（对比顾问）	WRITE	Medium（中）
vs Product Manager（对比产品经理）	WRITE	Medium（中）
vs SWE（对比软件工程师）	WRITE	High（高）
vs Sales Engineer（对比售前工程师）	WRITE	Medium（中）
vs Solution Architect（对比解决方案架构师）	WRITE	High（高）

结果：

8 WRITE（写入独立核心页）
1 MERGE（合并）

Final Resolution Table — Engineering（工程域最终决策表）

Placeholder（占位）	Resolution（结论）	Priority（优先级）
Embedding（嵌入表示）	WRITE	High（高）
Vector DB（向量数据库）	WRITE	High（高）
AWS（亚马逊云）	FIELD PRIMER	Medium（中）
Azure（微软云）	FIELD PRIMER	Medium（中）
GCP（谷歌云）	FIELD PRIMER	Medium（中）
Kubernetes（容器编排）	WRITE	High（高）
Terraform（基础设施即代码）	FIELD PRIMER	Medium（中）
SQL（结构化查询语言）	WRITE	High（高）
Kafka（事件流平台）	FIELD PRIMER	Medium（中）
Spark（分布式计算）	FIELD PRIMER	Low（低）
Data Warehouse（数据仓库）	FIELD PRIMER	Medium（中）
Data Lake（数据湖）	FIELD PRIMER	Medium（中）
ETL-ELT（抽取-转换-加载）	WRITE	High（高）
ERP（企业资源计划）	FIELD PRIMER	High（高）
CRM（客户关系管理）	FIELD PRIMER	High（高）
MES（制造执行系统）	FIELD PRIMER	Medium（中）
RBAC（基于角色的访问控制）	MERGE	High（高）
API Gateway（API 网关）	WRITE	High（高）
Enterprise Security（企业安全）	WRITE	High（高）
Python（Python 语言）	FIELD PRIMER	Medium（中）
TypeScript（TypeScript 语言）	FIELD PRIMER	Medium（中）
Java（Java 语言）	FIELD PRIMER	Low/Medium（低/中）
Git（版本管理）	WRITE	High（高）

结果：

8 WRITE（写入独立核心页）
14 FIELD PRIMER（领域入门页）
1 MERGE（合并）

Overall Resolution（总体结论）

32 个空占位最终：

WRITE（写入独立核心页）:
16

FIELD PRIMER（领域入门页）:
14

MERGE / REDIRECT（合并/重定向）:
2

DEPRECATE（废弃）:
0

也就是说：

所有原有占位都有明确归宿，但只有一半左右需要成为真正的独立核心知识页面。

Priority Order（优先级顺序）

不要同时写完所有页面。

建议按照 FDE 实际价值排序。

Wave 1 — Core Gaps（第一波：核心缺口）

第一批：

/01-Fundamentals/05-FDE-in-AI-Era

/01-Fundamentals/Role-Comparison/01-FDE-vs-SWE

/01-Fundamentals/Role-Comparison/02-FDE-vs-Solution-Architect

/03-Engineering/AI/10-Embedding

/03-Engineering/AI/11-Vector-Database

/03-Engineering/Data/06-SQL

/03-Engineering/Data/07-ETL-vs-ELT

/03-Engineering/Cloud/11-Kubernetes

/03-Engineering/Integration/10-API-Gateway

/03-Engineering/Integration/11-Enterprise-Security

/03-Engineering/Software/09-Git-for-FDE

Wave 2 — Enterprise Context（第二波：企业环境知识）

FDE Company Variations（FDE 公司差异）

ERP（企业资源计划）
CRM（客户关系管理）
MES（制造执行系统）

AWS（亚马逊云）
Azure（微软云）
GCP（谷歌云）

Data Warehouse（数据仓库）
Data Lake（数据湖）
Kafka（事件流平台）

Wave 3 — Orientation / Reference（第三波：导向/参考）

History（发展史）

vs Consultant（对比顾问）
vs PM（对比产品经理）
vs Sales Engineer（对比售前工程师）

Spark（分布式计算）

Terraform（基础设施即代码）

Python（Python 语言）
TypeScript（TypeScript 语言）
Java（Java 语言）

Engineering Page Standard（工程页标准结构）

知识库位置：

/99-Templates/Authoring/Engineering-Field-Primer

建议新增一个 Authoring Template（创作模板）：

# [Technology] for FDE（某技术 for FDE）

## What It Is（它是什么）

## Why FDE Cares（FDE 为什么关心）

## Where You Will See It（你会在哪里遇到它）

## Core Mental Model（核心心智模型）

## Key Concepts（关键概念）

## Typical FDE Tasks（FDE 典型任务）

## Decisions You May Need to Make（你可能需要做的决策）

## Questions to Ask the Customer（要问客户的问题）

## Common Failure Modes（常见失败模式）

## Troubleshooting Signals（排障信号）

## Security / Production Considerations（安全/生产注意事项）

## How Deep Should an FDE Go?（FDE 应掌握到多深？）

## Related Knowledge（关联知识）

Architecture（架构）:

Decision Guides（决策指南）:

Troubleshooting（问题排查）:

Patterns（解决方案模式）:

Case Studies（案例研究）:

这样 AWS、Kafka、Java 等页面不会失控成百科。

Depth Standard（深度标准）

每个 Engineering 技术条目建议明确一个 FDE Depth（FDE 深度等级）。

Level A — Recognize（A 级：认知）

知道它是什么、为什么存在。

适合：

Spark（分布式计算）
Java（Java 语言）

对于非相关项目。

Level B — Operate（B 级：操作）

能进行基本操作和 Debug（调试）。

适合多数 FDE：

Git（版本管理）
SQL（结构化查询语言）
API Gateway（API 网关）
Cloud（云平台）

Level C — Design（C 级：设计）

能进行架构选择。

例如：

RAG（检索增强生成）
Embedding（嵌入表示）
Vector Search（向量检索）
Integration（集成）
Security（安全）

Level D — Specialist（D 级：专家）

需要深度平台专家能力。

例如：

Deep Kubernetes platform engineering（深度 Kubernetes 平台工程）
Deep Kafka operations（深度 Kafka 运维）
Spark performance internals（Spark 性能内部机制）
Cloud network engineering（云网络工程）

FDE 不默认需要 Level D。

v1.0 Acceptance Rule for Empty Directories（空目录的 v1.0 验收规则）

知识库位置：

/00-Knowledge-Map/11-FDE-OS-v1-Quality-Gate

新增：

## Empty Placeholder Gate（空占位门禁）

- [ ] Core 域不存在 unexplained empty folders（无解释的空目录）
- [ ] 每个旧占位已完成 WRITE / PRIMER / MERGE / DEPRECATE（写入/入门页/合并/废弃）判定
- [ ] MERGE 条目有 canonical destination（权威合并目标页）
- [ ] FIELD PRIMER 有明确 FDE depth boundary（FDE 深度边界）
- [ ] 技术条目没有演化成通用技术百科
- [ ] 所有新页面拥有 Cross-links（交叉链接）

最终建议目录变更

Fundamentals（基础知识域）

从空占位整理成：

01-Fundamentals
├── 01-What-is-FDE
├── 02-FDE-Project-Lifecycle
├── 03-FDE-Capability-Model
├── 04-FDE-History
├── 05-FDE-in-AI-Era
├── 06-FDE-Company-Variations
└── Role-Comparison（角色对比）
    ├── 01-FDE-vs-SWE
    ├── 02-FDE-vs-Solution-Architect
    ├── 03-FDE-vs-Sales-Engineer
    ├── 04-FDE-vs-Consultant
    └── 05-FDE-vs-Product-Manager

Engineering additions（工程域新增）

03-Engineering
│
├── AI（AI 工程）
│   ├── ...
│   ├── 10-Embedding
│   └── 11-Vector-Database
│
├── Data（数据工程）
│   ├── ...
│   ├── 06-SQL
│   ├── 07-ETL-vs-ELT
│   ├── 08-Data-Warehouse
│   ├── 09-Data-Lake
│   ├── 10-Kafka
│   └── 11-Spark
│
├── Cloud（云与开发运维）
│   ├── ...
│   ├── 07-AWS
│   ├── 08-Azure
│   ├── 09-GCP
│   ├── 10-Cloud-Provider-Orientation
│   ├── 11-Kubernetes
│   └── 12-Terraform
│
├── Integration（企业集成）
│   ├── ...
│   ├── 07-ERP
│   ├── 08-CRM
│   ├── 09-MES
│   ├── 10-API-Gateway
│   └── 11-Enterprise-Security
│
└── Software（软件工程）
    ├── ...
    ├── 06-Python-for-FDE
    ├── 07-TypeScript-for-FDE
    ├── 08-Java-for-Enterprise-FDE
    └── 09-Git-for-FDE

RBAC：

MERGED INTO（合并进入）:
/03-Engineering/Integration/01-Authentication-Authorization

Hardening Decision（加固决策）

这 32 个占位不应当被当成：

32 篇待补文章。

更准确的定义是：

32 unresolved knowledge nodes（32 个未解决的知识节点）
↓
16 Core Pages（16 个核心页面）
+
14 Lightweight Field Primers（14 个轻量领域入门页）
+
2 Canonical Merges（2 个权威合并）

这是更符合 FDE OS v1.0 的处理方式。

否则 Engineering（工程域）很容易重新变成：

Cloud encyclopedia（云百科）
Programming tutorial（编程教程）
Big Data textbook（大数据教科书）

而偏离真正目标：

帮助 FDE 在客户项目中做出更好的判断并完成交付。