Engineering Knowledge Map（工程知识地图）
知识库位置：
FDE Knowledge Base/03 Engineering/Engineering-Knowledge-Map.md术语不确定时，请查阅 Glossary（中英文术语表）。
FDE 的 Engineering（工程）不等于「会写代码」。
FDE 的工程能力，核心是：
能够在真实客户环境中，把业务需求（Business Requirement，业务需求）转化为可运行、可集成、可部署、可维护的系统。
建议把 Engineering 分为五层：
03 Engineering│├── Software Engineering（软件工程）├── Data Engineering（数据工程）├── AI Engineering（AI 工程）├── Cloud & DevOps（云与开发运维）└── Enterprise Integration（企业集成）它们解决的问题分别是：
Software Engineering（软件工程）
Section titled “Software Engineering（软件工程）”回答：
系统本身怎么构建？
包括：
- API（Application Programming Interface，应用程序编程接口）
- Backend（后端）
- Frontend（前端）
- Testing（测试）
- Error Handling（错误处理）
- Configuration（配置管理）
- Service Design（服务设计）
- Git（版本管理）
Data Engineering（数据工程）
Section titled “Data Engineering（数据工程）”回答：
数据从哪里来、如何流动、如何保证质量？
包括：
- Database（数据库）
- Data Pipeline（数据管道）
- SQL（Structured Query Language，结构化查询语言）
- ETL / ELT（Extract, Transform, Load / Extract, Load, Transform，抽取-转换-加载/抽取-加载-转换）
- Data Warehouse（数据仓库）
- Data Lake（数据湖）
- Kafka（分布式事件流平台）
- Batch（批量处理）
- Streaming（流式处理）
- Data Quality（数据质量）
- Data Modeling（数据建模）
AI Engineering（AI 工程）
Section titled “AI Engineering（AI 工程）”回答：
AI 能力如何进入产品和业务系统？
包括：
- LLM（Large Language Model，大语言模型）
- Prompt（提示词）
- RAG（Retrieval-Augmented Generation，检索增强生成）
- Agent（智能体）
- Tool Calling（工具调用）
- Evaluation（评估）
- Guardrails（护栏）
- Embedding（嵌入表示）
- Vector Database（向量数据库）
Cloud & DevOps（云与开发运维）
Section titled “Cloud & DevOps（云与开发运维）”回答：
系统如何稳定运行？
包括：
- Docker（容器化平台）
- Kubernetes（容器编排平台）
- AWS / Azure / GCP（亚马逊云/微软云/谷歌云）
- Cloud Provider Orientation（云厂商导向）
- Deployment（部署）
- CI/CD（Continuous Integration / Continuous Delivery，持续集成/持续交付）
- Environment（环境）
- Observability（可观测性）
- Secrets Management（密钥管理）
- Reliability（可靠性）
Enterprise Integration（企业集成）
Section titled “Enterprise Integration（企业集成）”回答：
如何让新系统与客户已有系统协同工作？
包括：
- API Integration（API 集成）
- API Gateway（API 网关）
- Authentication（身份认证）
- Authorization（授权）
- OAuth（Open Authorization，开放授权协议）
- SSO（Single Sign-On，单点登录）
- Webhook（Web 回调）
- Event Integration（事件集成）
- Legacy Integration（遗留系统集成）
- ERP / CRM / MES（企业资源计划/客户关系管理/制造执行系统）
- Enterprise Security（企业安全）
Business Requirement（业务需求） ↓Application Logic（应用逻辑） ↓ Data（数据） ↓ AI Capability（AI 能力） ↓Enterprise Integration（企业集成） ↓Cloud / Production（云/生产环境）FDE 需要的不一定是每个领域都达到专家级。
更重要的是：
能够理解系统端到端（End-to-End，端到端）如何工作，并在关键位置亲自解决问题。
从系统结构看：
User（用户） │ ↓ ┌─────────────┐ │ Application │（应用） └──────┬──────┘ │ Software Engineering（软件工程） │ ┌──────────────┼──────────────┐ │ │ │ ↓ ↓ ↓ Data（数据） AI（AI 工程） Integration（集成） │ │ │ └──────────────┼──────────────┘ │ ↓ Cloud Runtime（云运行时） │ ↓ Production（生产）从请求生命周期（Request Lifecycle，请求生命周期）看：
User（用户）↓Authentication（身份认证）↓Authorization（授权）↓API（应用程序编程接口）↓Business Logic（业务逻辑）↓Data / AI / External System（数据 / AI / 外部系统）↓Result Validation（结果校验）↓Logging / Metrics / Trace（日志 / 指标 / 链路追踪）↓Response（响应）一个成熟 FDE 至少应该能够理解这条完整链路。
五条基础连接链（v1.0 Hardening Impact，v1.0 加固影响）
Section titled “五条基础连接链（v1.0 Hardening Impact，v1.0 加固影响）”第十九批九篇核心缺口页补齐后，Engineering（工程域）形成了五条完整的知识链。
技术链（AI 能力链）：
Enterprise AI（企业 AI）↓Embedding（嵌入表示）↓Vector Search（向量检索）↓RAG（检索增强生成）↓Evaluation（评估）数据链：
Source（数据来源）↓SQL（结构化查询语言）↓ETL / ELT（抽取-转换-加载两种模式）↓Pipeline（数据管道）↓Serving（数据服务）运行链：
Git（版本管理）↓CI/CD（持续集成/持续交付）↓Docker（容器化）↓Kubernetes（容器编排）↓Observability（可观测性）企业集成链：
Identity（身份）↓API Gateway（API 网关）↓Application（应用）↓Enterprise Systems（企业系统）安全链：
Identity（身份）↓Authorization（授权）↓Data（数据）↓Tool Permission（工具权限）↓Audit（审计）这使 Engineering 从原来的「核心主题集合」进一步接近：
一套完整可用于现场判断、Build（构建）、Debug（调试）和 Production Delivery（生产交付）的工程知识系统。
Enterprise Field Primer 速查（企业环境入门页，第二十批 Wave 2）
Section titled “Enterprise Field Primer 速查（企业环境入门页，第二十批 Wave 2）”十篇 Enterprise Field Primer（企业环境入门页）的统一定位：
帮助 FDE 在真实企业环境中快速识别系统角色、数据所有权、集成方式、常见约束、失败模式和需要进一步找谁。
| Technology（技术） | FDE Needs to Understand（需理解什么） | Default Depth（默认深度） |
|---|---|---|
| ERP | Business transactions（业务交易）, source of truth（事实来源）, safe integration（安全集成） | A/B |
| CRM | Customer objects（客户对象）, permissions（权限）, data quality（数据质量）, write-back（写回） | B |
| MES | Production execution（生产执行）, ERP/OT boundary（ERP/运营技术边界） | A/B |
| AWS | Core cloud capabilities（核心云能力） and customer landing zone（客户着陆区） | A/B |
| Azure | Cloud capabilities（云能力） + enterprise identity（企业身份） | A/B |
| GCP | Cloud capabilities（云能力） + data/AI environment（数据/AI 环境） | A/B |
| Data Warehouse | Curated analytical data（精炼分析数据） and freshness（新鲜度） | A/B |
| Data Lake | Raw scalable data layer（原始可扩展数据层） and governance（治理） | A |
| Kafka | Event streaming（事件流） and consumer semantics（消费者语义） | B |
Enterprise Systems Mental Model（企业系统心智模型）
Section titled “Enterprise Systems Mental Model（企业系统心智模型）”FDE 进入客户环境后，可以先建立：
Business Systems（业务系统）├─ CRM（客户关系管理）├─ ERP（企业资源计划）└─ MES（制造执行）
Data Systems（数据系统）├─ Warehouse（数据仓库）├─ Lake（数据湖）└─ Streaming / Kafka（流式/事件流）
Cloud Platform（云平台）├─ AWS（亚马逊云）├─ Azure（微软云）└─ GCP（谷歌云）然后问：
Which system owns which truth?（哪个系统拥有哪份事实？）
How does data move?（数据怎么流动？）
Which systems are transactional?（哪些是事务系统？）
Which systems are analytical?（哪些是分析系统？）
Which systems are on the critical path?（哪些在关键路径上？）
Which systems can we safely write to?（哪些可以安全写入？）FDE Enterprise Integration Principle（企业集成原则）
Section titled “FDE Enterprise Integration Principle（企业集成原则）”企业现场建议始终区分：
Operational System（运营系统）Analytical System（分析系统）Knowledge System（知识系统）Event System（事件系统）例如：
CRM / ERP / MES→ Operational truth（运营事实）
Warehouse（数据仓库）→ Analytical truth（分析事实）
Knowledge Base（知识库）→ Document knowledge（文档知识）
Kafka→ Event movement（事件流动）不要让 AI 项目把这些边界全部模糊掉。
Data Platform Principle（数据平台原则）
Section titled “Data Platform Principle（数据平台原则）”Warehouse、Lake、Kafka 可以按时间和用途理解：
Kafka→ Events moving now（正在移动的事件）
Data Lake→ Raw / broad history（原始/广泛历史）
Data Warehouse→ Curated analytical view（精炼分析视图）这只是 Mental Model（心智模型），不代表所有企业架构都严格如此。
Common Cross-System Failure Pattern（常见跨系统失败模式）
Section titled “Common Cross-System Failure Pattern（常见跨系统失败模式）”大量 FDE 项目故障最终都能归类为：
Wrong Source of Truth（事实来源搞错）Wrong Identity（身份搞错）Wrong Environment（环境搞错）Wrong Freshness（新鲜度搞错）Wrong Permission（权限搞错）Wrong Integration Contract（集成契约搞错）Wrong Ownership（归属搞错）因此进入任何 Enterprise System（企业系统）时，都建议先回答：
Owner?（谁负责？）Truth?（事实在哪？）Access?（怎么访问？）Freshness?（多新鲜？）Contract?（契约是什么？）Risk?（风险多大？）Enterprise Field Primer Anti-patterns（企业环境入门页反模式）
Section titled “Enterprise Field Primer Anti-patterns（企业环境入门页反模式）”- Vendor Expertise Theater（厂商百科表演）：知道很多产品名称，却不知道客户数据和业务流程。
- “Just Connect the API”（「接个接口就行」）：没有确认 owner（负责人）、permission（权限）、source of truth（事实来源）、write risk（写风险）。
- Cloud Rebuild（重建云）：客户已经有标准平台，FDE 又为了 Prototype（原型）建一套独立基础设施。
- Warehouse as Live API（数仓当实时接口）：分析系统被错误用于实时交易流程。
- Kafka Means Real-time（有 Kafka 就是实时）：Kafka 存在不代表整个业务链路就是实时。
- Data Lake Means Data Ready（数据在湖里就是可用）：数据“在 Lake 里”不等于 discoverable（可发现）、clean（干净）、usable（可用）、governed（受治理）。
推荐导航（Cross-links to Architecture）
Section titled “推荐导航（Cross-links to Architecture）”ERP / CRM / MES↓Enterprise Integration（企业集成）↓API / Event / File / Legacy Adapter（接口/事件/文件/遗留适配器）
Warehouse / Lake↓Data Architecture（数据架构）
Kafka↓Event-driven Architecture（事件驱动架构）
AWS / Azure / GCP↓Deployment Architecture（部署架构）配套工具：Technical Discovery（技术调研手册） 中的 Enterprise System Inventory（企业系统盘点）与 System-of-Record Map（记录系统映射表）；Customer Context（客户上下文登记） 的 System Landscape（系统全景）表。
当前完整目录（v1.0 后，第十九批 Wave 1 + 第二十批 Wave 2）
Section titled “当前完整目录（v1.0 后，第十九批 Wave 1 + 第二十批 Wave 2）”03 Engineering/ 五条主线 + 决策支持 + 交付检查清单 + 问题排查（第十九批 Wave 1 补齐 Embedding / Vector Database / SQL / ETL vs ELT / Kubernetes / API Gateway / Enterprise Security / Git；第二十批 Wave 2 补齐 ERP / CRM / MES / AWS / Azure / GCP / Cloud Provider Orientation / Data Warehouse / Data Lake / Kafka）：
03 Engineering│├── Engineering-Knowledge-Map（工程知识地图）│├── Software Engineering│ ├── API│ │ └── API-Design（API 设计）│ ├── System Design│ │ └── Backend-Service-Design（后端服务设计）│ ├── Code Quality│ │ └── Error-Handling（错误处理）│ ├── Testing│ │ └── Testing-Strategy（测试策略）│ ├── Configuration Management│ │ └── Configuration-Management（配置管理）│ ├── Git│ │ └── Git-for-FDE（FDE 的版本管理）│ └── Database│ └── Database-Fundamentals（数据库基础）│├── Data Engineering│ ├── Data Pipeline│ │ ├── Data-Pipeline（数据管道）│ │ └── Batch-vs-Streaming（批量 vs 流式处理）│ ├── SQL│ │ └── SQL-for-FDE（FDE 的 SQL 技能）│ ├── ETL vs ELT│ │ └── ETL-vs-ELT（抽取-转换-加载两种模式）│ ├── Data Warehouse│ │ └── Data-Warehouse-for-FDE（FDE 的数据仓库入门）│ ├── Data Lake│ │ └── Data-Lake-for-FDE（FDE 的数据湖入门）│ ├── Kafka│ │ └── Kafka-for-FDE（FDE 的 Kafka 事件流入门）│ ├── Data Modeling│ │ └── Data-Modeling（数据建模）│ └── Data Governance│ └── Data-Quality（数据质量）│├── AI Engineering│ ├── LLM│ │ └── LLM-Fundamentals（大语言模型基础）│ ├── RAG│ │ └── RAG-Fundamentals（RAG 基础）│ ├── Tool Calling│ │ └── Tool-Calling（工具调用）│ ├── Evaluation│ │ └── AI-Evaluation（AI 评估）│ ├── Prompt Engineering│ │ └── Prompt-Engineering（提示词工程）│ ├── Structured Output│ │ └── Structured-Output（结构化输出）│ ├── Agent│ │ └── Agent-Fundamentals（智能体基础）│ ├── Guardrails│ │ └── AI-Guardrails（AI 护栏）│ ├── Model Selection│ │ └── Model-Selection（模型选型）│ ├── Embedding│ │ └── Embedding（嵌入表示）│ └── Vector Database│ └── Vector-Database（向量数据库）│├── Cloud & DevOps│ ├── Observability│ │ └── Observability（可观测性）│ ├── Docker│ │ └── Docker-Fundamentals（Docker 基础）│ ├── Kubernetes│ │ └── Kubernetes-for-FDE（FDE 的 Kubernetes 技能）│ ├── AWS│ │ └── AWS-for-FDE（FDE 的亚马逊云入门）│ ├── Azure│ │ └── Azure-for-FDE（FDE 的微软云入门）│ ├── GCP│ │ └── GCP-for-FDE（FDE 的谷歌云入门）│ ├── Cloud Provider Orientation│ │ └── Cloud-Provider-Orientation（云厂商导向）│ ├── CI-CD│ │ └── CI-CD（持续集成/持续交付）│ ├── Environment Management│ │ └── Environment-Management（环境管理）│ ├── Secrets Management│ │ └── Secrets-Management（密钥管理）│ └── Reliability│ └── Reliability-Fundamentals（可靠性基础）│├── Enterprise Integration│ ├── Identity│ │ └── Authentication-Authorization（认证与授权）│ ├── OAuth│ │ └── OAuth-2-Fundamentals（OAuth 2.0 基础）│ ├── SSO│ │ └── SSO（单点登录）│ ├── Webhook│ │ └── Webhook（Web 回调）│ ├── Event-Driven Integration│ │ └── Event-Driven-Integration（事件驱动集成）│ ├── Legacy System Integration│ │ └── Legacy-System-Integration（遗留系统集成）│ ├── API Gateway│ │ └── API-Gateway（API 网关）│ ├── Enterprise Security│ │ └── Enterprise-Security（FDE 的企业安全）│ ├── ERP│ │ └── ERP-for-FDE（FDE 的企业资源计划系统入门）│ ├── CRM│ │ └── CRM-for-FDE（FDE 的客户关系管理系统入门）│ └── MES│ └── MES-for-FDE（FDE 的制造执行系统入门）│├── Decision Guides（决策指南）│ ├── README（使用方式）│ ├── REST-vs-Event-Driven（REST vs 事件驱动）│ ├── Batch-vs-Streaming（批量 vs 流式）│ ├── SQL-vs-NoSQL（SQL vs 非关系型数据库）│ ├── RAG-vs-Database-Query（RAG vs 直接数据库查询）│ ├── Workflow-vs-Agent（工作流 vs 智能体）│ ├── Small-vs-Large-Model（小模型 vs 大模型）│ ├── Sync-vs-Async（同步 vs 异步 API）│ ├── Build-vs-Buy（自建 vs 购买）│ ├── Managed-vs-Self-Hosted（托管 vs 自托管）│ └── Polling-vs-Webhook（轮询 vs Web 回调）│├── Checklists（检查清单）│ ├── README（使用方式）│ ├── Production-Readiness-Checklist（生产就绪）│ ├── API-Integration-Checklist（API 集成）│ ├── AI-Security-Checklist（AI 安全）│ ├── RAG-Readiness-Checklist（RAG 就绪）│ ├── Agent-Tool-Design-Checklist（智能体工具设计）│ └── Data-Quality-Checklist（数据质量）│└── Troubleshooting（问题排查） ├── README（使用方式：Severity 严重等级 + Evidence Pack 证据包） ├── Troubleshooting-Methodology（方法论 + 三张决策树） ├── RAG-Answer-Quality-Is-Poor（RAG 回答质量差） ├── RAG-Retrieves-Wrong-Documents（RAG 检索错文档） ├── Agent-Chooses-Wrong-Tool（Agent 选错工具） ├── Agent-Loops-Repeatedly（Agent 反复循环） ├── LLM-Output-Is-Inconsistent（LLM 输出不稳定） ├── API-Integration-Is-Unstable（API 集成不稳定） ├── Data-Pipeline-Is-Missing-Records（数据管道丢记录） ├── Webhook-Duplicate-Events（Webhook 事件重复） ├── Production-Latency-Is-Too-High（生产延迟过高） ├── AI-Cost-Is-Too-High（AI 成本过高） ├── Authentication-Works-But-Authorization-Fails（认证成功但授权失败） └── Production-vs-Staging-Difference（生产与预发行为不一致）目录映射说明：本仓库按既有结构，Database Fundamentals（数据库基础）放在
Software Engineering/Database/（README 既定分类），Data Quality（数据质量）放在Data Engineering/Data Governance/，Backend Service Design（后端服务设计）放在Software Engineering/System Design/。
FDE Engineering Decision Framework（FDE 工程决策框架）
Section titled “FDE Engineering Decision Framework（FDE 工程决策框架）”遇到任何工程问题时，不要先问：
应该使用哪个技术？
而应该依次问：
1. Business Requirement（业务需求）
Section titled “1. Business Requirement（业务需求）”业务真正需要什么？
2. Functional Requirement（功能性需求）
Section titled “2. Functional Requirement（功能性需求）”系统需要完成什么行为？
3. Non-functional Requirement（非功能性需求）
Section titled “3. Non-functional Requirement（非功能性需求）”有什么约束？
例如：
- Latency（延迟）
- Security（安全）
- Reliability（可靠性）
- Cost（成本）
- Scale（规模）
4. Existing Environment（现有环境）
Section titled “4. Existing Environment（现有环境）”客户现在已经有什么？
5. Simplest Viable Design（最简可行设计）
Section titled “5. Simplest Viable Design（最简可行设计）”最简单可行设计是什么？
6. Failure Mode（失败模式）
Section titled “6. Failure Mode（失败模式）”失败之后会发生什么？
7. Operability（可运维性）
Section titled “7. Operability（可运维性）”上线之后谁维护？
最终：
Business Need（业务需要）↓Constraints（约束条件）↓Simplest Architecture（最简架构）↓Engineering Decision（工程决策）↓Operational Reality（运维现实）决策入口（Decision Flow）
Section titled “决策入口（Decision Flow）”统一决策入口：
Start（开始） ↓What business outcome is needed?（需要什么业务结果） ↓What data is involved?（涉及什么数据） ↓Structured or unstructured?（结构化还是非结构化） ↓Need AI?（需要 AI 吗） ↓Need action or only information?（需要执行动作还是仅获取信息） ↓Deterministic workflow or dynamic reasoning?（确定性工作流还是动态推理） ↓Sync or async?（同步还是异步） ↓Direct API or event?（直接 API 还是事件） ↓Managed or self-hosted?（托管还是自托管） ↓Security / Reliability / Operations Review（安全/可靠性/运维评审） ↓Production（生产）更具体地：
Need knowledge from documents?（需要从文档获取知识）→ RAG（检索增强生成）
Need exact transactional data?（需要精确事务数据）→ API / SQL
Need to perform action?（需要执行动作）→ Tool Calling（工具调用）
Known fixed process?（已知固定流程）→ Workflow（工作流）
Dynamic multi-step process?（动态多步流程）→ Agent（智能体）
Need immediate result?（需要立即结果）→ Sync（同步）
Long-running task?（长时间任务）→ Async（异步）
Point-to-point integration?（点对点集成）→ REST
Broadcast business event?（广播业务事件）→ Event-Driven（事件驱动）能力自检（Capability Check）
Section titled “能力自检（Capability Check）”完成这一批后，一个学习者至少应该能够回答：
Software（软件工程）
Section titled “Software（软件工程）”- 一个 Production Backend 应该如何分层？
- API 如何设计？
- 错误应该如何处理？
- 哪些地方应该测试？
- Config（配置）与 Secret（密钥）有什么区别？
Data（数据工程）
Section titled “Data（数据工程）”- 什么数据应该放在哪里？
- 数据应该如何建模？
- 什么时候需要 Streaming（流式处理）？
- 数据不可信时怎么办？
AI（AI 工程）
Section titled “AI（AI 工程）”- LLM 在系统中的角色是什么？
- RAG 与 Agent 有什么区别？
- Tool Calling 如何工作？
- Structured Output 为什么重要？
- 如何评估 AI？
- 如何建立 Guardrails？
- 如何选择模型？
Cloud（云与开发运维）
Section titled “Cloud（云与开发运维）”- 应用如何容器化？
- 如何自动部署？
- Dev / Staging / Prod（开发/预发/生产）为什么要分开？
- Secret 如何管理？
- 系统如何观察和恢复？
Integration（企业集成）
Section titled “Integration（企业集成）”- Authentication 与 Authorization 有什么区别？
- OAuth 与 SSO 分别解决什么问题？
- Webhook 与 Polling 如何选择？
- 什么情况下需要 Event-driven（事件驱动）？
- 如何面对 Legacy System（遗留系统）？
知识成熟度模型（Maturity Model）
Section titled “知识成熟度模型（Maturity Model）”Engineering 目前已经可以分为四层。
Level 1 — Concepts（概念）
Section titled “Level 1 — Concepts（概念）”回答：
这是什么？
例如：
- RAG（检索增强生成）
- Agent（智能体）
- OAuth（开放授权协议）
- Webhook（Web 回调）
Level 2 — Engineering Practice（工程实践）
Section titled “Level 2 — Engineering Practice（工程实践）”回答：
怎么使用？
例如：
- API Design（API 设计）
- Testing（测试）
- Observability（可观测性）
- Reliability（可靠性）
Level 3 — Decision Support（决策支持）
Section titled “Level 3 — Decision Support（决策支持）”回答：
应该选什么？
例如：
- Workflow vs Agent（工作流 vs 智能体）
- RAG vs Database Query（RAG vs 数据库查询）
- REST vs Event-driven（REST vs 事件驱动）
Level 4 — Troubleshooting（问题排查）
Section titled “Level 4 — Troubleshooting（问题排查）”回答：
出问题之后怎么办？
例如：
- RAG 为什么答错？
- Agent 为什么循环？
- API 为什么不稳定？
- 数据为什么丢了？
形成：
Understand（理解）↓Build（构建）↓Choose（选择）↓Diagnose（诊断）↓Fix（修复）这基本构成了 FDE 工程知识的完整闭环。
当前状态与下一步
Section titled “当前状态与下一步”03 Engineering
Version: v0.5Status: Operational Engineering Knowledge Base（可运营的工程知识库）Coverage:- Concepts（概念）- Engineering Fundamentals（工程基础）- Decision Guides（决策指南）- Delivery Checklists（交付检查清单）- Troubleshooting Playbooks（问题排查手册）此时 03 Engineering 已经完成四个层次（见上文成熟度模型），并且不再只是：
学习材料。
而开始具备三个实际用途：
Learn（学习）Build（构建）Operate（运营）与
11 Tools/Decision Guides/的关系：该目录聚焦具体工具选型（LangGraph vs 自写 Orchestrator、pgvector vs 专业 Vector Database 等）；03 Engineering/Decision Guides/聚焦通用工程决策模式，两者互补。
第一阶段 Engineering 建议暂时收口
Section titled “第一阶段 Engineering 建议暂时收口”到了 v0.5，建议暂时不要继续扩大 Engineering 的横向范围。
原因是当前已经覆盖：
Software（软件工程）Data（数据工程）AI（AI 工程）Cloud（云与开发运维）Integration（企业集成）Decision Guides（决策指南）Checklists（检查清单）Troubleshooting（问题排查）继续加大量：
- Kubernetes 深度教程
- Database 内核
- Networking 深度教程
- ML Theory（机器学习理论）
容易让知识库逐渐变成：
通用 Software Engineering Encyclopedia（软件工程百科）
而失去 FDE 主线。
第一阶段的 Engineering 应坚持：
Enough engineering knowledge to design, build, deploy and troubleshoot customer-facing systems. （足以设计、构建、部署和排查面向客户系统的工程知识。）
而不是：
覆盖所有计算机技术。
下一批建议：补强 Delivery（交付域）
Section titled “下一批建议：补强 Delivery（交付域）”完成 Engineering 后，第一阶段最大的短板会变成 05 Delivery。
目前 Delivery 只有主生命周期：
Discovery（客户调研）Scoping（范围界定）Solution Design（方案设计）Prototype（原型）Pilot（试点）Production（生产）Scale（规模化）下一步建议做 Delivery v0.2，把这七个阶段全部升级成真正可执行的 Playbook（交付手册）。
每个阶段统一包含：
Objective（阶段目标）Entry Criteria（进入条件）Inputs（输入）Activities（活动）Key Questions（必须回答的问题）Deliverables（交付物）Stakeholders（干系人）Engineering Activities（工程活动）Business Activities（业务活动）Risks（风险）Checklist（检查清单）Exit Criteria（退出条件）Common Failure Modes（常见失败模式）并增加几个横向条目：
Project Kickoff Playbook（项目启动手册）Weekly Customer Sync Playbook（每周客户同步手册）Architecture Review Playbook（架构评审手册）Technical Risk Register（技术风险登记表）POC Exit Criteria（概念验证退出标准）Pilot Readiness Checklist（试点就绪检查清单）Go-Live Checklist（上线检查清单）Hypercare Playbook（上线护航手册）这样才能把已经成熟的：
Business（业务）+Engineering（工程）+Architecture（架构）真正通过：
Delivery（交付）连接成完整的 FDE 工作体系。
Related Topics（关联知识）
Section titled “Related Topics（关联知识）”- FDE Capability Model（FDE 能力模型）
- FDE Knowledge Map（FDE 知识地图）
- API Design（API 设计）
- Backend Service Design（后端服务设计）
- Database Fundamentals（数据库基础）
- Data Quality（数据质量）
- Prompt Engineering（提示词工程）
- Agent Fundamentals（智能体基础）
- Docker Fundamentals（Docker 基础）
- OAuth 2.0 Fundamentals（OAuth 2.0 基础）
- Legacy System Integration（遗留系统集成）
- Glossary（中英文术语表）