Glossary（中英文术语表）
知识库位置：
FDE Knowledge Base/Glossary.md本表覆盖 v0.1 – v1.0（Phase 1 六批 + Phase 2 十一批）及 v1.0 后第十八至二十批全部 419 篇文章、知识地图与99 Templates全部模板文件（含 v1.0 Canonical 规范模板体系）中出现的英文术语。
- 知识库文章中，英文术语在每篇文章首次出现时以「English（中文）」形式标注中文定义。
- 本表是唯一定义来源（Single Source of Truth，唯一可信来源）；文章中的标注应与本表保持一致。
- 新增文章时，若引入新术语，请同步补充到本表对应分类。
- 排序约定：每个分类内按英文术语字母序排列。
0. 缩略语速查表（Acronyms，缩略语）
Section titled “0. 缩略语速查表（Acronyms，缩略语）”| 缩略语 | 英文全称 | 中文 |
|---|---|---|
| ABAC | Attribute-Based Access Control | 基于属性的访问控制 |
| ACL | Access Control List | 访问控制列表 |
| ADR | Architecture Decision Record | 架构决策记录 |
| AI | Artificial Intelligence | 人工智能 |
| AML | Anti-Money Laundering | 反洗钱 |
| API | Application Programming Interface | 应用程序编程接口 |
| ARR | Annual Recurring Revenue | 年度经常性收入 |
| AWS | Amazon Web Services | 亚马逊云服务平台 |
| BI | Business Intelligence | 商业智能 |
| CAPA | Corrective and Preventive Action | 纠正与预防措施 |
| CDC | Change Data Capture | 变更数据捕获 |
| CDP | Customer Data Platform | 客户数据平台 |
| CI/CD | Continuous Integration / Continuous Delivery | 持续集成/持续交付 |
| CMMS | Computerized Maintenance Management System | 计算机化维护管理系统 |
| CNI | Container Network Interface | 容器网络接口（Kubernetes 网络插件标准） |
| CRM | Customer Relationship Management | 客户关系管理 |
| CRO | Chief Revenue Officer | 首席营收官 |
| CSAT | Customer Satisfaction | 客户满意度 |
| CSV | Comma-Separated Values | 逗号分隔值文件 |
| DNS | Domain Name System | 域名系统 |
| DPA | Data Processing Agreement | 数据处理协议 |
| DMS | Distribution Management System | 配电管理系统 |
| ELT | Extract, Load, Transform | 抽取-加载-转换 |
| EAM | Enterprise Asset Management | 企业资产管理 |
| EHR | Electronic Health Record | 电子健康档案 |
| EHS | Environment, Health and Safety | 环境、健康与安全 |
| EMR | Electronic Medical Record | 电子病历 |
| EMS | Energy Management System | 能源管理系统 |
| ERP | Enterprise Resource Planning | 企业资源计划 |
| ETL | Extract, Transform, Load | 抽取-转换-加载 |
| FDE | Forward Deployed Engineer | 前沿部署工程师 |
| GCP | Google Cloud Platform | 谷歌云服务平台 |
| GIS | Geographic Information System | 地理信息系统 |
| HITL | Human-in-the-Loop | 人在环 |
| IaC | Infrastructure as Code | 基础设施即代码 |
| IAM | Identity and Access Management | 身份与访问管理 |
| IoT | Internet of Things | 物联网 |
| JVM | Java Virtual Machine | Java 虚拟机 |
| JWT | JSON Web Token | JSON 网络令牌 |
| KPI | Key Performance Indicator | 关键绩效指标 |
| KYC | Know Your Customer | 客户身份识别 |
| LLM | Large Language Model | 大语言模型 |
| LIS | Laboratory Information System | 实验室信息系统 |
| MAU | Monthly Active Users | 月活跃用户 |
| MES | Manufacturing Execution System | 制造执行系统 |
| MFA | Multi-Factor Authentication | 多因素认证 |
| ML | Machine Learning | 机器学习 |
| MTBF | Mean Time Between Failures | 平均故障间隔时间 |
| MTTD | Mean Time to Detect | 平均检测时间 |
| MTTR | Mean Time to Repair / Resolve | 平均修复/解决时间（制造语境为 Repair，运维语境为 Resolve） |
| NAT | Network Address Translation | 网络地址转换 |
| OAuth | Open Authorization | 开放授权协议 |
| OEE | Overall Equipment Effectiveness | 设备综合效率 |
| OCR | Optical Character Recognition | 光学字符识别 |
| OIDC | OpenID Connect | 基于 OAuth 的身份认证层标准 |
| OLTP | Online Transaction Processing | 联机事务处理 |
| OMS | Order Management System | 订单管理系统 |
| OT | Operational Technology | 运营技术 |
| PII | Personally Identifiable Information | 个人身份信息 |
| PLC | Programmable Logic Controller | 可编程逻辑控制器 |
| PACS | Picture Archiving and Communication System | 医学影像存档与通信系统 |
| PIM | Product Information Management | 产品信息管理 |
| PO | Purchase Order | 采购订单 |
| POC | Proof of Concept | 概念验证 |
| POS | Point of Sale | 销售点系统 |
| QMS | Quality Management System | 质量管理系统 |
| RAG | Retrieval-Augmented Generation | 检索增强生成 |
| RCA | Root Cause Analysis | 根本原因分析 |
| RACI | Responsible, Accountable, Consulted, Informed | 责任分配矩阵 |
| RBAC | Role-Based Access Control | 基于角色的访问控制 |
| REST | Representational State Transfer | 表述性状态转移（HTTP API 风格） |
| ROI | Return on Investment | 投资回报率 |
| RPA | Robotic Process Automation | 机器人流程自动化 |
| RPS | Requests per Second | 每秒请求数 |
| SaaS | Software as a Service | 软件即服务 |
| SCADA | Supervisory Control and Data Acquisition | 数据采集与监控系统 |
| SFTP | SSH File Transfer Protocol | 安全文件传输协议 |
| SKU | Stock Keeping Unit | 最小存货单位 |
| SLA | Service Level Agreement | 服务等级协议 |
| SLI | Service Level Indicator | 服务等级指标 |
| SLO | Service Level Objective | 服务等级目标 |
| SME | Subject Matter Expert | 领域专家 |
| SOAP | Simple Object Access Protocol | 简单对象访问协议 |
| SQL | Structured Query Language | 结构化查询语言 |
| SSO | Single Sign-On | 单点登录 |
| STP | Straight-through Processing | 直通式处理 |
| SWE | Software Engineer | 软件工程师 |
| TLS | Transport Layer Security | 传输层安全协议 |
| UI | User Interface | 用户界面 |
| VPC | Virtual Private Cloud | 虚拟私有云 |
| WMS | Warehouse Management System | 仓库管理系统 |
1. 角色与基础（Fundamentals，基础知识）
Section titled “1. 角色与基础（Fundamentals，基础知识）”| 英文 | 中文 | 说明 |
|---|---|---|
| Ambiguous Problem | 模糊问题 | 没有明确边界和定义的问题，需要 FDE 自行定义 |
| Business Context | 业务背景 | 客户所在行业、业务模式、系统使用者与业务目标 |
| Business Goal | 业务目标 | 客户希望达成的可衡量经营目标 |
| Business Impact | 业务影响 | 问题对业务造成的损失或机会成本 |
| Business Maturity Model | 业务能力成熟度模型 | FDE 业务能力五级：Requirement Taker → Strategic FDE |
| Business Outcome | 业务结果 | FDE 工作的最终衡量标准：问题是否被真正解决 |
| Business Problem | 业务问题 | 从业务视角出发定义的问题，区别于技术问题 |
| Business Requirement | 业务需求 | 业务侧对系统的要求，工程化的输入 |
| Business Value | 业务价值 | 方案为客户创造的可量化价值 |
| Capability Model | 能力模型 | 对 FDE 五大能力维度（工程/业务/架构/交付/沟通）的结构化描述 |
| Competency Model | 胜任力模型 | 六维能力评价体系（工程/架构/业务/交付/沟通/领导力与杠杆） |
| Closed Loop / Full Loop | 完整闭环 | 从问题定义到业务结果的端到端负责 |
| Consultant | 顾问 | 强项在问题结构化、业务分析与建议；FDE 区别在于核心责任还包含直接技术执行（Build/Test/Debug/Operate） |
| Custom Development | 定制开发 | 针对单一客户进行的专门开发，FDE 的核心不是做定制开发 |
| Executive | 高管 | 客户方决策层人员，需要专门的高管沟通方式 |
| Hero Project | 英雄项目 | 靠一次孤例支撑的晋升依据，缺乏一致性 |
| FDE / Forward Deployed Engineer | 前沿部署工程师 | 深入客户业务场景，用软件、数据、AI 和系统工程能力解决真实业务问题的工程师 |
| FDE Company Variations | FDE 公司差异 | “FDE”在不同公司代表的不同角色侧重（产品型/工程型/部署型/AI 型/咨询型/方案型），按编码深度、产品边界、客户负责范围、商业责任四维判断，而非只看 Title（职位头衔） |
| Fundamentals | 基础 | 知识库第一域：FDE 定义、生命周期、能力模型、角色对比 |
| Lifecycle | 生命周期 | 项目从调研到规模化的全过程阶段划分 |
| Leverage | 杠杆 | 影响力超出亲手完成工作的程度，Senior/Staff 定级核心变量 |
| Mentoring | 导师辅导 | 有经验者对其他 FDE 的系统性指导 |
| Platform Engineer / Platform Specialist | 平台工程师/平台专家 | 负责 Kubernetes、Kafka、云平台等深度平台工程的角色；FDE 达到操作/设计级即可，深度平台问题应拉入该角色 |
| Product Manager / PM | 产品经理 | 主要优化跨多客户的产品；FDE 主要优化特定客户上下文中的解决方案，现场学习可反向成为产品反馈 |
| Problem Definition | 问题定义 | 对问题边界、成因和影响的明确表述 |
| Role Comparison | 角色对比 | FDE 与 SWE、解决方案架构师、售前工程师、顾问、产品经理的职责区别 |
| Sales Engineer | 售前工程师 | 偏 Pre-sales（售前）演示、技术资格判定与方案定位；FDE 更常进入售后实施与生产，区别在成功按成交还是按已部署方案衡量 |
| Senior / Junior FDE | 高级/初级 FDE | 核心区别：能否独立面对模糊问题并负责完整闭环 |
| Solution Architect | 解决方案架构师 | 偏设计、指导与架构；FDE 还要构建、调试、部署——架构师解释系统应如何工作，FDE 让它真正跑起来 |
| Stretch Assignment | 挑战性任务 | 略超当前能力级别的成长性任务 |
| Stakeholder | 干系人 | 与项目结果有利害关系的各方人员 |
| System Engineering | 系统工程 | 将多个技术组件组合为完整系统的工程学科 |
| Working Model | 工作模式 | FDE 的典型工作方式与协作模式 |
2. 交付流程（Delivery，交付）
Section titled “2. 交付流程（Delivery，交付）”| 英文 | 中文 | 说明 |
|---|---|---|
| Acceptance Criteria | 验收标准 | 双方约定的、判断交付是否合格的标准 |
| Action Log | 行动日志 | 记录需要执行的任务及其负责人 |
| Adoption | 用户采用 | 让真实用户在日常工作中真正使用系统 |
| Architecture Review | 架构评审 | 对技术方案的正式评审与决策流程 |
| Artifact | 交付工件 | 每次现场活动产生的结构化产出（会议纪要/画布/章程等） |
| Baseline | 基线 | 改进前业务指标的当前值，用于对比 |
| Backlog | 待办清单 | 不属于当前验证范围、留待后续处理的需求池 |
| Business Validator | 业务验证人 | 上线时代表业务方验证关键流程的人员 |
| Champion | 内部推广者 | 客户内部推动系统采用的关键用户 |
| Change Freeze | 变更冻结 | Go-Live（正式上线）前 T-1 起停止一切变更的冻结窗口 |
| Change Management | 变革管理 | 推动客户组织接受新系统、新流程的管理活动 |
| Change Request | 变更请求 | 项目中提出的新需求/变更，须经评估决策 |
| Demo | 演示 | 向客户展示系统能力的演示；Demo 好看不等于可上线 |
| Demo Driven Development | 演示驱动开发 | 反模式：为演示效果牺牲真实性与工程质量的开发方式 |
| Demo Script | 演示脚本 | 保证演示覆盖关键场景的脚本 |
| Decision Log | 决策日志 | 记录已做决策及其原因、负责人 |
| Deliverables | 交付物 | 阶段结束时必须产出的工件 |
| Delivery Handover | 交付移交 | 向客户运营团队移交系统与知识的过程 |
| Deployment Window | 部署窗口 | 与客户约定的允许部署变更的时间段 |
| Discovery | 客户调研 | 项目起点：理解客户现状、流程、系统与痛点 |
| Entry Criteria | 进入条件 | 满足什么条件才能进入该阶段 |
| Executive Sponsor | 高管发起人 | 客户方发起并支持项目的高层决策者 |
| Exit Criteria | 退出条件 | 满足什么条件才能进入下一阶段 |
| Fake Data | 假数据 | 原型中使用的不真实数据，会掩盖真实数据质量问题 |
| Feedback Loop | 反馈闭环 | 收集用户反馈并持续改进的机制 |
| Go Live | 正式上线 | 系统正式投入生产使用的时间点 |
| Go / No-Go | 上/不上线决策 | 基于证据决定是否进入下一阶段/上线 |
| Go / No-Go Board | 放行决策板 | 上线决策板：逐项核对 Owner / Status / Evidence 并给出 GO / NO-GO / GO WITH CONDITIONS（放行/不放行/有条件放行）结论 |
| Go-Live Toolkit | 上线工具 | T-7 / T-1 / T0 三阶段检查 + 放行决策板 + 回滚触发条件的上线工具 |
| Green / Amber / Red | 红黄绿状态 | 项目状态三级标识：正常/有风险/严重受阻 |
| Human Approval | 人工审批 | 高风险动作执行前必须由人确认的机制 |
| Human Review | 人工复核 | 把机器处理结果交由人工检查确认的环节 |
| Hypercare | 上线护航 | 上线初期的加强支持阶段，完成后移交长期运营 |
| Hypothesis | 假设 | 原型阶段要验证的核心技术或业务假设 |
| Incident Commander | 事故指挥官 | 重大事故时统一指挥处置的角色 |
| In Scope | 范围内 | 本阶段明确承诺交付的内容（与 Out of Scope 对应） |
| Iterative Delivery | 迭代交付 | 允许基于证据在阶段间回退纠偏的交付方式 |
| Issue Log | 问题日志 | 记录已发生问题及其处理状态 |
| Kickoff | 项目启动会 | 对齐目标、范围、角色与计划的启动会议 |
| Lessons Learned | 经验教训 | 项目复盘沉淀的经验记录 |
| Milestone | 里程碑 | 项目中的关键检查点 |
| Minimum Scope | 最小范围 | 仅实现验证假设所必需的功能 |
| Multi-tenant | 多租户 | 一套系统服务多个客户/组织的架构模式 |
| Non-Scope | 明确不做的事项 | 与 Scope 对应，明确列出本阶段不做的内容，防止范围蔓延 |
| Operational Handover | 运营移交 | 生产稳定后向运营团队移交职责的过程 |
| Out of Scope | 范围外 | 本阶段明确不交付的内容 |
| Pilot | 试点 | 在真实用户、真实数据的小范围内验证系统 |
| Pilot Decision Sheet | 试点决策表 | 试点结束时汇总成功/失败/未解决风险/指标/反馈，给出 Go / Go with Conditions / Rework / Stop（放行/有条件放行/返工/终止）结论 |
| Pilot Tracking Toolkit | 试点跟踪工具 | 同时追踪技术/采用/工作流/业务四类指标的试点看板工具 |
| POC / Proof of Concept | 概念验证 | 验证概念可行性的小型实验 |
| POC Charter | 概念验证章程 | 约定 POC 假设、范围、边界与结论标准的文档 |
| Problem Framing | 问题定义 | 从客户表述中提炼出真正值得解决的问题 |
| Project Triangle | 项目三角形 | 范围/时间/资源三重约束，通常不能同时无限固定 |
| Production | 生产环境（阶段） | 建立可靠、可维护、可运维的正式系统；注意：在状态字段中 Production 指「定稿」 |
| Project Charter | 项目章程 | 界定目标、范围、验收与责任的纲领文档 |
| Project Execution | 项目执行 | 按计划推进项目落地的能力 |
| Project Health | 项目健康度 | 从 Scope / Schedule / Engineering / Customer / Risk / Value（范围/进度/工程/客户/风险/价值）六维评价项目状态 |
| Project Health Toolkit | 项目健康度工具 | 六维 Scorecard（计分卡）+ Green / Amber / Red 评级；关键维度 Red（红）足以让整体 Red，不因多数 Green（绿）自动转绿 |
| Project Plan | 项目计划 | 里程碑、任务、负责人与时间线的计划文档 |
| Prototype | 原型 | 用最低成本验证最关键假设的早期版本 |
| Quarterly Value Review | 季度价值评审 | 上线后每季度对照目标验证价值并决策的评审会 |
| RACI Matrix | 责任分配矩阵 | 按执行/负责/被征询/被知会标注每项工作的责任 |
| Ready with Conditions | 有条件就绪 | 在明确限制下进入下一阶段的评审结论 |
| Release Lead | 发布负责人 | War Room 中最终协调上线的人员 |
| Release Notes | 发布说明 | 记录本次发布包含的变更 |
| Risk List | 风险清单 | Solution Design 必须产出的风险列表 |
| Risk Management | 风险管理 | 识别、评估、应对项目风险的过程 |
| Risk Register | 风险登记表 | 含概率、影响、负责人、缓解措施的持续跟踪表 |
| Risk Register Toolkit | 风险登记表工具 | 记录 ID / 风险 / 类别 / 概率 / 影响 / 分值 / 责任人 / 缓解措施 / 触发条件 / 状态的风险登记工具 |
| Risk Tiering | 风险分层 | 按已知供应商/金额阈值/异常信号等把审批分为低/中/高三层，匹配不同处理路径 |
| Risk Trigger | 风险触发条件 | 风险即将变为现实的可观测信号（如「11 月 15 日前仍未排定评审日期」），让风险可操作 |
| Rollback | 回滚（交付语境） | 上线出现问题时退回上一稳定版本 |
| Rollback Plan | 回滚计划 | 上线前验证过的回退方案 |
| Rollback Trigger | 回滚触发条件 | 上线前预先约定的回滚标准，避免事故发生后才决定标准 |
| Rubber Stamping | 橡皮图章式审批 | 人工复核流于形式、不加判断即通过的反模式，自动化后尤其常见 |
| Scale | 规模化 | 从单一场景扩展到更多用户、部门或业务线 |
| Scaling Roadmap | 扩展路线图 | 分批扩展用户、场景与能力的计划 |
| Scoping | 范围界定 | 明确第一阶段到底做什么、不做什么 |
| Scope Change Toolkit | 范围变更工具 | 变更请求统一记录 11 项字段，决策限于 Add / Swap / Defer / Reject（加入/置换/推迟/拒绝） |
| Scope Creep | 范围蔓延 | 未经显式决策而持续扩大的项目范围 |
| Scope Statement | 范围说明书 | 书面化的范围定义（含范围内/范围外） |
| Smoke Test | 冒烟测试 | 部署后快速验证核心功能可用的测试 |
| Solution Design | 方案设计 | 将业务问题转换为系统设计的过程 |
| Stage-Gate | 阶段门禁 | 每阶段设进入/退出条件并经评审推进的机制 |
| Stakeholder Map | 干系人地图 | 项目干系人及其关注点、影响力的映射 |
| Standardization | 标准化 | 规模化阶段将方案沉淀为可复用标准 |
| Success Criteria | 成功标准 | 判断原型/项目是否成功的明确标准 |
| Success Metrics | 成功指标 | 衡量项目成功的量化指标 |
| User Training | 用户培训 | 帮助用户掌握系统使用的培训活动 |
| War Room | 作战室 | 上线期间集中指挥、沟通与处置的作战机制 |
| Weekly Status Report | 周报 | 每周项目状态与计划的标准化报告 |
| Working Demo | 可运行演示 | 原型阶段产出的可实际运行的演示 |
| Workstream | 工作流线 | 按职能划分的项目工作线（业务/工程/安全等） |
3. 业务域（Business，业务）
Section titled “3. 业务域（Business，业务）”| 英文 | 中文 | 说明 |
|---|---|---|
| 5 Whys | 五问法 | 连续追问「为什么」以逼近根本原因的调研方法 |
| Account Executive / AE | 大客户销售 | 负责端到端成交的销售角色，Sales Copilot（销售副手）典型用户 |
| Action | 操作 | 工作流中执行人完成的动作 |
| Attribution | 归因 | 判断业务指标变化由哪些因素贡献，避免全归功于 AI |
| Automation Potential | 自动化潜力 | 流程步骤可被自动化的程度 |
| Business Case | 商业论证 | 论证项目为什么值得做的文档（问题/基线/收益/成本/风险） |
| Business Case Builder | 商业论证构建器 | 把 Business Case 拆成七个 Block（问题/基线/拟议变更/收益/成本/不确定性/决策）的工具，可压缩为一页纸格式 |
| Business Metrics | 业务指标 | 衡量业务结果的指标（如响应时间、转化率） |
| Business Opportunity | 业务机会 | Discovery 输出：解决问题的价值机会 |
| Business Owner | 业务责任人 | 对业务结果与 KPI 负责的干系人 |
| Business Process | 业务流程 | 客户完成业务目标的端到端流程 |
| Business Process Mapping | 业务流程映射 | 把业务活动从「大家平时就这么做」变成可观察、可分析的流程 |
| Change Management Framework | 变革管理框架 | Awareness→Desire→Knowledge→Ability→Reinforcement 五阶段模型 |
| Claims Processing | 理赔处理 | 保险/保修场景从申请到赔付的流程，Document AI 典型场景 |
| Constraints | 约束条件 | 时间、预算、合规、技术等限制 |
| Contributing Factor | 促成因素 | 加重问题但非根本原因的因素 |
| Current State | 现状 | Discovery 输出：客户当前的工作与系统状态 |
| Current Workflow | 现有工作流 | 客户今天实际的工作流程 |
| Customer Discovery | 客户调研 | 系统性理解客户业务、流程、系统、数据与痛点的方法 |
| Customer Success | 客户成功 | 负责客户留存、续约与价值实现的职能，CRM 高频干系人 |
| Deal | 商机 | 销售流程中正在推进的潜在交易 |
| Deal Velocity | 交易速度 | 商机在管道中推进的速度，销售副手长期指标（归因需谨慎） |
| Decision | 决策 | 工作流中做出判断的环节 |
| Decision Rights | 决策权 | 谁对范围/架构/安全/上线/规模化拥有最终决定权 |
| Discovery Question Bank | 调研问题库 | 十类客户调研问题库（业务背景/流程/痛点/影响/用户/数据/系统/成功/风险/采用），会前按 Must Ask（必问）标记 |
| Enablement | 赋能 | 培训、指南与支持，使用户真正能上手使用 |
| End User | 最终用户 | 直接使用系统完成工作的一线人员 |
| Fishbone Analysis | 鱼骨分析 | 从人员/流程/技术/数据/政策等维度归因问题的方法 |
| Follow-up | 跟进 | 会议或接触后的后续沟通动作（如跟进邮件） |
| Forecast | 销售预测 | 对销售收入或商机的预测 |
| Gap Analysis | 差距分析 | 对比现状与目标状态，识别流程/数据/技术等差距 |
| Happy Path | 正常路径 | 一切顺利时的主流程；真实业务复杂度常藏在异常路径 |
| Invoice | 发票 | 供应商开具的账单凭证 |
| Known–Assumption–Unknown | 已知-假设-未知 | 早期 ROI 沟通框架：区分已知数据、当前假设与待验证未知 |
| Latency Ladder | 延迟阶梯 | 逐级追问可接受延迟以找到真实时效需求的提问法 |
| Line Item | 行项目 | 发票/订单中的明细行 |
| Manage Closely / Keep Satisfied / Keep Informed / Monitor | 四象限管理策略 | 权力/利益矩阵四类干系人的差异化策略：重点管理/保持满意/保持知情/监视 |
| MoSCoW | 需求四级优先法 | Must / Should / Could / Won’t Have 需求分级方法 |
| Opportunity | 商机 | CRM 中的销售机会记录 |
| Outcome | 结果 | 工作流最终产生的业务结果 |
| Pain Points | 痛点 | 时间浪费、人工步骤、数据断点、决策瓶颈、系统摩擦 |
| Payback Period | 回收期 | 投资被累计收益收回所需的时间 |
| Persona | 用户画像 | 代表典型用户的虚构角色，用于演示叙事与设计 |
| Power / Interest Matrix | 权力/利益矩阵 | 按权力与利益将干系人分为四类并匹配管理策略 |
| Pre-meeting Brief | 会前简报 | 为客户会议准备的结构化背景摘要 |
| Problem Framing Toolkit | 问题定义工具 | Problem Statement（问题陈述）构建器 + 质量检验 + 根本原因守则 |
| Problem Statement | 问题陈述 | 描述用户、任务、问题与业务影响的规范化陈述 |
| Pushback | 客户异议 | 客户不同意 FDE 建议时的意见分歧，应用选项+权衡+证据应对 |
| Process Mapping Toolkit | 流程映射工具 | 五步把客户流程拆成可量化步骤表：定义起终点 → 统一字段 → 标注类型 → 量化 → 标记机会 |
| Process Owner | 流程责任人 | 对工作流设计与运营负责的干系人 |
| Purchase Order / PO | 采购订单 | 企业向供应商下达的正式采购凭证 |
| Requirement Engineering | 需求工程 | 从 Request 提炼分层、可验收 Requirement 的方法 |
| Requirement Traceability | 需求追溯 | 业务目标→需求→架构→测试→指标的链路可追踪 |
| Requirements | 需求 | 对要解决问题的正式化描述 |
| RevOps | 收入运营 | Revenue Operations，管理收入流程、数据与工具的团队 |
| Rework | 返工 | 工作因质量、数据或需求问题被退回重做 |
| ROI Calculator | ROI 计算器 | 生产力价值 / 成本 / ROI / 回本周期计算模型，强制 Low / Base / High（悲观/基准/乐观）三情景 |
| Root Cause | 根本原因 | 造成问题的本质原因，区别于表面现象 |
| Root Cause Analysis | 根本原因分析 | 识别导致问题反复出现的真正原因的方法论 |
| ROI Theater | ROI 表演 | 为让项目通过而使用过度乐观假设的反模式 |
| Sales Cycle | 销售周期 | 从初次接触到成交的平均时长，销售副手长期指标 |
| SDR / BDR | 销售/业务拓展代表 | Sales Development Representative / Business Development Representative，负责外拓商机的角色 |
| Solution Gap | 方案缺口 | 把「缺少某个方案」误当作问题的表述（如「我们没有 AI 聊天机器人」） |
| Solution Statement | 方案陈述 | 客户以解决方案口吻提出的要求，需追问还原为问题 |
| Stakeholder Management | 干系人管理 | 识别并管理各方期望与关系 |
| Stakeholder Mapping Toolkit | 干系人映射工具 | 识别角色 → Power / Interest / Support / Impact 四维评分 → 四象限分类 → 立场标注 |
| Symptom | 症状 | 问题的表面现象，区别于根本原因 |
| Systems Landscape | 系统全景 | 客户现有系统与相互关系的整体图景 |
| Target State | 目标状态 | Discovery 输出：期望达到的未来状态 |
| Target User | 目标用户 | 问题直接影响的使用者群体 |
| Task | 任务 | 用户需要完成的工作 |
| Ticket | 工单 | 客服/支持请求的记录单元 |
| Trigger | 触发事件 | 启动一个工作流的事件 |
| Vendor | 供应商 | 提供产品或服务的外部公司 |
| Use Case | 用例 | 一个具体的应用场景 |
| Use Case Canvas | 用例画布 | 结构化定义用例的 16 字段模板 |
| Use Case Prioritization | 用例优先级排序 | 决定先做哪个用例的评估方法 |
| Use Case Scoring Model | 用例评分模型 | 八维加权评分（业务价值 25% / 痛点 15% / 可行性 15% / 频率 10% / 数据 10% / 采用 10% / 风险 10% / 战略 5%），让优先级讨论变透明 |
| User Requirement | 用户需求 | 需求四层之一：用户需要完成什么 |
| Value Realization | 价值实现 | 验证项目上线后承诺的价值是否真实发生 |
| Value Realization Review | 价值实现评审 | 定期对照基线/目标/实际值的价值复盘会 |
| Value Realization Toolkit | 价值实现工具 | 价值链（技术能力→用户行为→流程指标→业务指标）+ 技术/采用/流程/业务四层看板 + 评审决策输出 |
| Value Scenarios | 价值情景 | Low / Base / High 三档价值预估，优于单点预测 |
| Value Tree | 价值树 | 从技术能力→用户行为→流程改善→业务结果的因果链 |
| Workflow Fit | 工作流契合度 | 方案与用户真实工作流程的契合程度，采用公式因子之一 |
3.1 成功指标与优先级（Success Metrics & Prioritization）
Section titled “3.1 成功指标与优先级（Success Metrics & Prioritization）”| 英文 | 中文 | 说明 |
|---|---|---|
| Active Users | 活跃用户 | 在统计周期内真实使用系统的用户数 |
| Adoption Rate | 采用率 | 目标用户中实际使用系统的比例 |
| Adoption Readiness | 采用就绪度 | 用户是否真的愿意改变工作方式 |
| Approval Cycle Time | 审批周期时长 | 申请从提交到最终批准/驳回的平均耗时，审批自动化核心指标 |
| Asset Availability | 设备可用性 | 设备处于可用状态的时间比例，维护类项目核心指标 |
| Auto-approval Rate | 自动审批率 | 申请被系统自动批准的比例，审批自动化核心指标 |
| Automation Rate | 自动化率 | 任务被系统自动完成、无需人工介入的比例 |
| Average Handle Time / AHT | 平均处理时长 | 完成单次任务（如一个客服会话）的平均耗时 |
| Complexity | 复杂度 | 优先级矩阵中衡量实施难度的维度 |
| Conversion | 转化率 | 完成目标行为（如下单、注册）的比例 |
| Cost Savings | 成本节约 | 方案带来的运营成本下降 |
| Customer Satisfaction | 客户满意度 | 用户对服务结果的满意程度 |
| Customer Trust | 客户信任 | 首批 Use Case 的重要目标：让客户建立对方案的信任 |
| Data Readiness | 数据就绪度 | 数据是否存在、可用、合法 |
| Error Reduction | 错误减少 | 上线后业务差错率下降幅度 |
| Human Override | 人工改写率 | 用户不采纳 AI 建议而人工改写的比例 |
| Escalation Rate | 转人工率 | 任务升级转交人工处理的比例 |
| Exception Rate | 异常率 | 无法按标准流程自动处理、需人工介入的比例 |
| False Positive | 误报 | 系统误判为有风险/阳性但实际正常的案例 |
| First Contact Resolution | 首次接触解决率 | 第一次交互即解决问题的比例 |
| First-time Fix Rate | 一次修复率 | 现场技师首次上门即完成修复的比例，现场服务核心指标 |
| First-use Value | 首次使用价值 | 用户第一次使用即获得的价值，决定留存的关键 |
| Lagging Metric | 滞后指标 | 较晚才能看到的指标（如收入、成本节约、留存） |
| Leading Metric | 先行指标 | 较早就能看到的指标（如使用量、任务成功率） |
| Manual Touch Rate | 人工触达率 | 业务处理中需要人工介入的比例 |
| Mean Time to Diagnose | 平均诊断时长 | 从故障出现到确定原因的平均时间，现场技师副手核心指标 |
| Monthly Active Users / MAU | 月活跃用户 | 一个月内真实使用系统的用户数 |
| Milestone Completion | 里程碑完成率 | 按期完成的里程碑比例，交付健康度指标 |
| Open Blockers | 未解决阻塞项 | 当前阻塞项目推进的事项数量 |
| Processing Time Reduction | 处理时间下降 | 单笔业务处理耗时缩短幅度 |
| Productivity Improvement | 生产力提升 | 人均产出提升幅度 |
| Quick Win | 速赢项目 | 高价值、低复杂度、可快速见效的项目 |
| Response Time | 响应时间 | 系统返回响应所需的时间 |
| Retention | 留存率 | 用户/客户持续使用的比例 |
| Revenue | 收入 | 业务收入 |
| Revenue Impact | 收入影响 | 方案对收入的贡献 |
| Schedule Variance | 进度偏差 | 实际进度与计划的偏差 |
| Straight-through Processing Rate | 直通式处理率 | 无需人工干预端到端自动完成的业务比例（STP Rate） |
| Strategic Bet | 战略性投入 | 高价值但高复杂度、需长期投入的项目 |
| Support Cost | 支持成本 | 客户支持环节的人力与运营成本 |
| Task Completion Rate | 任务完成率 | 用户任务被成功完成的比例 |
| Technical Feasibility | 技术可行性 | 技术上能否实现及其成熟度 |
| Ticket Resolution Time | 工单解决时长 | 工单从创建到解决所需的时间 |
| True Positive | 命中 | 被系统正确识别出的阳性/风险案例 |
| Unplanned Downtime | 非计划停机 | 未预料故障导致的生产停机时间，预测性维护的核心目标指标 |
| Uptime | 正常运行时间 | 系统可用运行的时间比例 |
| Usage | 使用量 | 系统被实际使用的频度 |
| Usage Funnel | 使用漏斗 | 从邀请到习惯性使用的逐级转化分析 |
| User Satisfaction | 用户满意度 | 用户对系统使用体验的满意程度 |
4. 沟通（Communication，沟通）
Section titled “4. 沟通（Communication，沟通）”| 英文 | 中文 | 说明 |
|---|---|---|
| Communication | 沟通 | FDE 第五项核心能力维度 |
| Customer Communication | 客户沟通 | 与客户日常层面的沟通 |
| Customer Meeting Toolkit | 客户会议工具 | 会前目标模板 + 会中 Fact / Decision / Action / Open Question（事实/决策/行动/待定问题）四类记录 + 会议结束四问检验 |
| Demo Preparation Toolkit | 演示准备工具 | Demo Story（演示故事线）+ 情景表 + 演示前检查清单 + A/B/C 三级失败预案 |
| Demo Story | 演示故事线 | Persona（用户画像）→ 问题 → 旧工作流 → 新工作流 → 结果 的演示叙事结构 |
| End-of-Meeting Test | 会议结束检验 | 会议结束前必须能回答：学到什么/决定什么/谁做什么/下一步是什么 |
| Escalation Packet | 升级包 | Issue / Impact / Evidence / What We Tried / Options / Recommendation / Decision Needed / Deadline 结构化升级材料 |
| Escalation Toolkit | 升级工具 | 以升级包结构向上求助，必须明确 Decision Needed（需要的决策），不让领导反问「要我做什么」 |
| Executive Communication | 高管沟通 | 面向客户决策层的汇报与沟通 |
| Executive Update Toolkit | 高管汇报工具 | 一页六块：目标/状态/成果/风险/需要的决策/下一里程碑；技术事实须翻译成业务影响 |
| Facilitation | 引导 | 组织 Workshop 使其有效产出过程的技能 |
| Meeting Notes | 会议纪要 | 会议记录；注意 Discovery 的输出不应只是会议纪要 |
| Synthesis | 综合复述 | 向客户归纳复述所听内容以确认双方理解一致 |
| Technical Communication | 技术沟通 | 面向技术团队的设计讲解与方案讨论 |
| Translation Rule | 翻译规则 | 高管沟通原则：不是隐藏技术，而是把技术事实翻译成业务影响 |
5. 工程域（Engineering，工程）
Section titled “5. 工程域（Engineering，工程）”| 英文 | 中文 | 说明 |
|---|---|---|
| Access Pattern | 访问模式 | 系统读写数据的方式特征，是选型的核心依据 |
| Account（ERP） | 会计科目 | ERP 财务主数据对象；注意与 CRM 的 Account（客户账户）一词多义 |
| Adapter | 适配器 | 转换新旧系统接口的中间组件 |
| AI Cost Analysis Toolkit | AI 成本分析工具 | 成本构成 + 单位成本指标（单请求/单用户/单任务/单成功任务/单业务成果）+ Agent 与 RAG 成本模型 + 优化漏斗 |
| AI Engineering | AI 工程 | 将 AI 能力工程化并接入业务系统的学科 |
| AI Orchestration | AI 编排 | 在应用层组织模型调用、工具与流程的协调逻辑 |
| Agent Runtime | 智能体运行时 | 承载 Agent 状态、循环、步数控制与终止的运行组件 |
| Aggregate | 聚合 | 将数据按维度汇总计算 |
| Analytical Model | 分析型模型 | 面向分析场景的事实/维度建模 |
| Analytics | 数据分析 | 对数据的分析利用（BI、统计等） |
| Anti-Corruption Layer | 防腐层 | 用适配器隔离遗留系统复杂性的设计模式 |
| API | 应用程序编程接口 | 系统间交互的标准接口 |
| API Contract | API 契约 | 接口对输入、输出、错误、权限与版本的明确约定 |
| API Debugging Toolkit | 接口调试工具 | 捕获请求 → 失败分类 → 状态码速查 → 对比已知良好请求 → 分段计时 → 可重试性判定 |
| API Design | API 设计 | 设计稳定、可复用系统接口的工程实践 |
| API Endpoint | 接口端点 | API 的具体调用地址与操作（如 GET /customers/{id}） |
| API Gateway | API 网关 | 统一承担路由/认证/限流/TLS/日志/策略/报文转换的入口层；调试 401/403/超时时必须先分清错误发生在 Gateway（网关）还是 Service（服务）层 |
| API Integration | API 集成 | 通过 API 与外部系统连接 |
| API Versioning | API 版本管理 | 对接口变更做版本隔离，避免破坏调用方 |
| API Wrapper | API 封装层 | 在遗留系统前包装出的现代 API 层 |
| Approximate Nearest-neighbor Search | 近似最近邻搜索 | 向量数据库/向量检索系统的核心检索操作，按相似度返回最接近的向量（常缩写 ANN） |
| Async Processing | 异步处理 | 任务提交与结果获取分离的处理模式 |
| Auto-scaling | 自动扩容 | 根据负载自动增减计算资源；原型阶段不应过早实现 |
| AWS / Azure / GCP | 亚马逊云/微软云/谷歌云 | 三大公有云厂商；FDE 应按能力模型（计算/存储/数据库/网络/身份/可观测）理解而非背产品目录，具体产品名会变化 |
| Backend | 后端 | 承载业务逻辑与数据处理的服务端程序 |
| Backup | 备份 | 数据的定期备份与恢复能力 |
| Backpressure | 背压 | 下游处理能力不足时向上游传导的流量反压机制 |
| Backward Compatibility | 向后兼容 | 新版本结构/接口不破坏旧消费者正常工作的属性 |
| Block Storage / File Storage | 块存储/文件存储 | 块存储接近虚拟机磁盘，文件存储为共享文件系统；与对象存储互补 |
| Broker | 代理节点 | Kafka 集群的服务节点；Broker/Replication/Controller 的深度调优属平台专家范围 |
| Bronze Layer / Raw Layer | 原始层（铜层） | 数据湖保留未加工数据的分层（常配 Silver/Gold 银层/金层），支撑重放、调试、审计与重新加工 |
| Bulk API | 批量接口 | CRM/云平台提供的批量读写接口，规避逐条调用的限额与低效 |
| Business Logic | 业务逻辑 | 系统承载业务规则与流程的部分 |
| Business Rules | 业务规则 | 业务方定义的规则与约束 |
| Business View | 业务视图 | 按业务语义组织的数据视图 |
| Cache | 缓存 | 加速数据读取的临时存储 |
| Canonical Model | 规范化模型 | 统一定义多源数据实体的标准数据模型 |
| Capability Equivalence | 能力等价 | 跨云厂商按能力而非产品名映射（三家都有托管 Kubernetes、对象存储等）；先学能力等价再记服务矩阵 |
| Cloud | 云计算 | 基于云基础设施的计算与服务模式 |
| Cloud Capability Model | 云能力模型 | 按 Compute/Storage/Database/Networking/Identity/Observability（计算/存储/数据库/网络/身份/可观测）六类能力理解云平台；知识库优先保存能力模型而非产品目录 |
| Cloud Portability | 云可移植性 | 应用跨云迁移的能力；过度追求 100% cloud agnostic（云无关）会带来大量抽象复杂度，应「有价值处可移植，有用处用原生」 |
| Code Coverage | 代码覆盖率 | 测试覆盖代码的比例；不应单纯追求 100% |
| Cold Start | 冷启动 | 容器/函数首次启动带来的额外延迟 |
| Command | 命令 | 要求执行某动作的消息；区别于表达已发生事实的 Event（事件），事件命名应为过去式 |
| Compensation | 补偿机制 | 流程某步失败后执行反向操作恢复一致性的机制 |
| Coding | 编码 | 编写代码的工程基础能力 |
| Completeness | 完整性 | 数据质量维度：数据是否无缺失 |
| Configuration | 配置 | 随环境、客户或部署变化、不应硬编码的值 |
| Config Drift | 配置漂移 | 环境之间配置逐渐不一致的现象 |
| Configuration Management | 配置管理 | 管理系统运行参数与环境配置的实践 |
| Consistency | 一致性 | 数据质量维度：不同系统中的数据是否一致 |
| Consumer | 消费者 | 事件/消息的处理方 |
| Consumer Group | 消费者组 | Kafka 中共同消费一组分区的消费者集合，实现水平扩展与负载均衡 |
| Consumer Lag | 消费滞后 | 消费者处理速度落后于事件产生速度的累积差距 |
| Context Compression | 上下文压缩 | 精简进入模型的内容以降低延迟与成本（同 Context Reduction） |
| Container | 容器 | 镜像的运行实例，标准化部署单元 |
| Controller | 控制器 | 接收请求并分发的入口组件 |
| Cost Center | 成本中心 | ERP 主数据中费用归集与分摊的组织单元 |
| CrashLoopBackOff / ImagePullBackOff / OOMKilled / Pending | Kubernetes 常见故障状态 | 分别对应崩溃循环、镜像拉取失败、内存不足被终止、待调度；排查入口是日志/配置/密钥/依赖与资源约束 |
| CTE / Common Table Expression | 公用表表达式 | SQL 中命名的临时结果集，用于拆解复杂查询，FDE 应熟练使用 |
| Curated Data | 精炼数据 | 经过清洗与转换、可直接服务下游分析和消费的数据层 |
| Customer 360 | 客户 360 视图 | 跨系统统一客户视图，数据集成的典型交付物 |
| Data | 数据 | 客户数据的统称 |
| Data Catalog | 数据目录 | 登记数据集、负责人、结构、血缘与权限的可发现性组件，防止数据湖变沼泽 |
| Data Engineering | 数据工程 | 数据采集、流转、加工与服务的工程学科 |
| Data Drift | 数据漂移 | 数据分布随时间偏离建模时分布的现象，需持续监控 |
| Data Inventory | 数据清单 | Technical Discovery 产出的数据源盘点（来源/责任人/质量/访问方式） |
| Data Lake | 数据湖 | 存储原始、多格式数据的仓储 |
| Data Leakage | 数据泄漏（建模语境） | 训练特征混入预测时点不可得的信息，导致离线指标虚高 |
| Data Lineage | 数据血缘 | 数据从来源系统到下游消费方的流转与加工链路，数仓/数据湖的关键关注点 |
| Data Modeling | 数据建模 | 定义数据结构与关系的设计活动 |
| Data Owner | 数据责任人 | 对某类数据质量与口径负责的角色 |
| Data Platform | 数据平台 | 企业统一存储与处理数据的平台 |
| Data Pipeline | 数据管道 | 数据从来源到下游系统的移动与转换流程 |
| Data Quality | 数据质量 | 数据的准确性、完整性、一致性程度 |
| Data Serving | 数据服务 | 将数据提供给 BI、AI、搜索、应用等下游消费方 |
| Data Source | 数据源 | 数据的来源系统 |
| Data Swamp | 数据沼泽 | 数据湖反模式：只进不出、无治理无编目，数据找不到也不可信 |
| Data Warehouse | 数据仓库 | 面向分析的结构化数据集中存储 |
| Database | 数据库 | 结构化数据存储系统 |
| Database View | 数据库视图 | 数据库中预定义的查询投影；ERP 常见只读集成方式 |
| Dead Letter Queue | 死信队列 | 存放反复处理失败事件的队列 |
| Debugging | 调试 | 定位并修复缺陷的过程 |
| Decision Logic | 决策逻辑 | 系统中做出判断的逻辑 |
| Deduplication | 去重 | 去除重复的数据记录 |
| Deployment | 部署 | 将系统安装并运行到目标环境 |
| DevOps | 开发运维一体化 | 打通开发与运维的研发模式 |
| Dimensional Modeling | 维度建模 | 面向分析的事实表+维度表建模方法，数据仓库基础，FDE 理解基础即可 |
| Direct Database Query | 直接数据库查询 | 结构化查询场景下比 RAG 更可靠的方式 |
| Distributed Search | 分布式搜索 | 将索引分散到多节点并行执行的搜索架构 |
| Docker | 容器化平台 | 将应用及其依赖打包为标准化容器的工具 |
| Dockerfile | 镜像构建文件 | 定义镜像构建步骤的脚本 |
| Document Database | 文档数据库 | 存储灵活结构文档的数据库 |
| Document Classification | 文档分类 | 自动识别文档类型（发票/合同/收据等）的环节 |
| Document Parser | 文档解析器 | 将 PDF、发票等文档转换为结构化数据的组件 |
| Duplicate Delivery | 重复投递 | 同一事件/回调被发送多次的现象 |
| Duplicate Action Detection | 重复动作检测 | 检测并阻止 Agent 重复执行同一动作的机制 |
| End-to-End Test | 端到端测试 | 验证完整业务流程的测试 |
| Enterprise Integration | 企业集成 | 与客户既有企业系统的连接与打通 |
| Enterprise System Inventory | 企业系统盘点 | Technical Discovery 产出的系统清单（类别/用途/负责人/关键性/事实来源/读写接口/认证/新鲜度/生产约束） |
| Entity Matching | 实体匹配 | 判断不同记录是否指向同一实体的策略 |
| Environment Diff | 环境差异比对 | 逐项比较两个环境配置与依赖的诊断活动 |
| Error Handling | 错误处理 | 对错误的捕获、返回与恢复机制 |
| ETL / ELT | 抽取-转换-加载 / 抽取-加载-转换 | 数据加工管线的两种模式 |
| Evaluation Dataset | 评测数据集 | 含问题/预期答案/相关文档与章节/权限上下文/难度/类别的测试集，RAG 与 Agent 评估的基础 |
| Evidence Lineage | 证据溯源链 | 调查类系统中每条证据可追溯到来源系统与记录的链路，防 AI 编造证据 |
| Exact Match | 精确匹配 | 按字段值精确相等的实体匹配策略 |
| Event Bus | 事件总线 | 传递事件的中间设施 |
| Event Envelope | 事件信封 | 事件消息中除业务载荷外的标准元数据（编号/类型/时间戳/版本等） |
| Event-Driven Integration | 事件驱动集成 | 通过事件触发系统间协作的集成方式 |
| Event Stream | 事件流 | 持续产生的事件数据序列 |
| Fact / Dimension Table | 事实表/维度表 | 分析型建模的两类核心表 |
| Failure Mode | 故障模式 | 设备或系统失效的典型方式，预测性维护的建模对象 |
| Feature Flag | 功能开关 | 不发版即可启停功能的配置项 |
| Feature Store | 特征存储 | 统一存储与在线服务模型特征的组件 |
| Field Extraction | 字段抽取 | 从文档中提取指定业务字段值的过程 |
| File Exchange | 文件交换 | 通过 CSV、SFTP 等文件方式进行的集成 |
| Freshness | 新鲜度 | 数据质量维度：数据是否够新 |
| Frontend | 前端 | 用户直接交互的界面层 |
| Full Load / Incremental Load | 全量/增量加载 | 数据管道的两种加载方式；每天全量复制大数据量通常不合理，增量/CDC/流式需按新鲜度需求选择 |
| Git | 版本管理工具 | FDE 基础技能：克隆/分支/提交/合并/变基/拉取请求/冲突解决/标签/回退；避免「生产修复只存在于一台工程师笔记本上」 |
| Golden Signals | 黄金信号 | 生产监控首要看的四个信号：Traffic（流量）/ Errors（错误）/ Latency（延迟）/ Saturation（饱和度） |
| Goods Receipt | 收货单 | 采购到付款流程中的收货凭证，三单匹配的一环 |
| Hardcode | 硬编码 | 把本应可配置的值写死在代码中 |
| High Availability | 高可用 | 系统持续可用的能力；原型阶段不应过早实现 |
| Hybrid Search | 混合检索 | 向量检索与关键词检索结合的方式 |
| Hypothesis Log | 假设日志 | 以假设/支持证据/反对证据/验证/结果四列记录排查过程，避免多人随机试改 |
| Identity Resolution | 实体识别 | 将多系统中的不同记录解析为同一业务实体的过程，Customer 360 的核心问题 |
| Image（镜像） | 镜像 | 容器运行所需的只读模板 |
| Ingestion | 数据摄取 | 将数据从来源系统采集进数据系统 |
| Impute | 插补 | 用估计值填补缺失数据的处理方式 |
| Integration Layer | 集成层 | 后端中负责对接外部系统的层 |
| Internet Egress | 互联网出口流量 | 从私有网络流向公网的流量；企业环境常默认禁止，直接影响外部 AI 服务架构 |
| Integration Test | 集成测试 | 验证系统之间是否正确连接的测试 |
| Integration Inventory | 集成清单 | Technical Discovery 产出的集成方式盘点（认证/限流/沙箱/延迟） |
| Internal API | 内部 API | 客户内部系统提供的接口 |
| Java | Java 语言 | 大量企业后端、遗留与强监管系统使用；FDE 至少要能读懂服务结构、构建依赖、REST 基础与日志异常（JVM 常识） |
| Job | 异步任务 | 后台异步执行的工作单元 |
| Join | 关联 | 按关联键将多份数据连接 |
| Join Cardinality | 关联基数 | 表间 1:1 / 1:N / N:N 的对应关系；误解会导致类笛卡尔积的行数膨胀，严重污染指标 |
| Kafka | 分布式事件流平台 | 高吞吐的事件流与消息中间件 |
| Kubernetes | 容器编排平台 | 客户常要求部署进既有集群；FDE 需理解 Cluster/Node/Pod/Deployment/Service/Ingress/ConfigMap/Secret/Namespace 并能排查基本健康、日志与网络问题，无需成为平台工程师 |
| Key-Value Store | 键值存储 | 按键高速读写的存储 |
| Keyword Search | 关键词检索 | 基于词项精确匹配的检索方式，弥补向量检索在编号/缩写上的不足 |
| Knowledge Governance | 知识治理 | 企业知识的所有权、版本、时效与质量治理，企业 RAG 的前置问题 |
| Known-good Request | 已知良好请求 | 与失败请求对比的正常样本，通过逐项差异定位问题层 |
| Lakehouse | 湖仓一体 | 融合数据仓库与数据湖特征的现代数据平台，ELT 模式的典型目标环境 |
| Landing Zone | 企业着陆区 | 大型客户的标准化云基础环境：账号/订阅/项目结构、网络、IAM、安全策略、日志、标签与成本管控；原型也不应绕开 |
| Late-arriving Data | 迟到数据 | 晚于管道预期时间到达的数据 |
| Legacy System | 遗留系统 | 客户仍在使用、技术栈老旧的系统 |
| Lint | 静态代码检查 | 自动检查代码风格与常见问题的工具 |
| Liveness / Readiness Probe | 存活/就绪探针 | Kubernetes 两类健康检查：前者判断应用是否活着，后者判断是否准备好接流量；就绪探针设计错误会让未就绪的 Pod 接收请求 |
| Loose Coupling | 松耦合 | 系统间依赖程度低的设计目标 |
| Machine Learning | 机器学习 | 从数据中学习规律的 AI 分支 |
| Mainframe | 大型机 | 传统集中式大型主机系统 |
| Maintenance Record | 维修记录 | 设备维修历史记录，其质量决定预测性维护可行性 |
| Managed Service | 托管服务 | 由供应商负责部署与运维的服务模式 |
| Master Data | 主数据 | 企业核心共享参考数据（客户/物料/供应商/科目等），ERP 等系统的核心资产 |
| Master Record / Golden Record | 主记录/黄金记录 | 实体识别后形成的唯一权威记录，Customer 360 的核心产物 |
| Message Broker | 消息代理 | 在生产者与消费者之间传递并缓冲消息的中间件 |
| Metadata | 元数据 | 描述数据的结构化信息（部门/版本/状态/权限组等）；业务过滤条件应存为元数据而非只靠向量语义 |
| Metadata Partitioning | 元数据分区 | 按元数据（部门/租户/时间）划分索引以提升检索与隔离性 |
| Middleware | 中间件 | 系统间传递消息与转换连接的中间软件层，ERP/遗留集成常见 |
| Micro-batch | 微批处理 | 以很小批次接近实时效果的批处理方式 |
| Nearest-neighbor Search | 近邻搜索 | 向量数据库/向量检索引擎的核心检索操作（k-NN），按相似度找最接近的向量 |
| Network Policy | 网络策略 | Kubernetes 中限制 Pod 间流量的规则，是集群内连接问题的常见原因 |
| NoSQL | 非关系型数据库 | 泛指文档、键值等非关系型数据库 |
| Object Storage | 对象存储 | 以对象形式存储非结构化数据的存储服务 |
| OCR | 光学字符识别 | 将扫描件/图片中的文字转换为可处理文本的技术 |
| Offset | 消费位移 | Kafka 中标记消费者在分区内读取位置的编号，重放与跳过都基于它 |
| Operational Model | 操作型模型 | 面向业务事务流程的建模方式 |
| Optimization Funnel | 优化漏斗 | AI 成本优化顺序：去除浪费 → 压缩上下文 → 缓存 → 模型路由 → 减少步数 → 调整架构；不要第一步就换最便宜模型 |
| Ordering | 事件顺序 | 事件到达顺序的保证问题 |
| Pagination | 分页 | API 分批返回大量数据的机制 |
| Parallelization | 并行化 | 相互独立的调用同时执行以降低总耗时 |
| Parameter Validation | 参数校验 | 对接口输入参数合法性的检查 |
| Partition | 分区 | Kafka Topic（主题）的并行与顺序单位，顺序只在分区内保证；也是数据湖按目录/字段切分数据的手段 |
| Partition Key | 分区键 | 决定事件写入哪个分区的键；同一实体的相关事件应使用同键以保序，忽略它是常见顺序失控原因 |
| Permission Filter | 权限过滤器 | 在检索前按用户权限过滤内容的组件，Permission Before Retrieval 的实现 |
| Poison Message | 毒消息 | 导致消费者反复失败、需要隔离处理的消息 |
| Polling | 轮询 | 定时主动拉取数据的集成方式 |
| Prediction Window | 预测窗口 | 预测模型目标所覆盖的未来时间范围，须与训练窗口严格分离 |
| Predictive Maintenance | 预测性维护 | 基于传感器与维修数据预测故障风险并提前维护 |
| Producer | 生产者 | 事件的发布方 |
| Production Debugging Toolkit | 生产调试工具 | 黄金信号 → 分层请求分解 → 变更检查 → 假设日志；缓解（先恢复服务）与根治（解决根因）分离 |
| Python | Python 语言 | FDE 高频语言：接口原型、数据探索、AI、自动化与脚本；应能读写代码、用虚拟环境、调错并写测试 |
| Quality Regression | 质量回归 | 数据/输出质量随时间劣化的现象 |
| Query Plan | 查询计划 | 数据库执行 SQL 的步骤说明，慢查询排查的基础 |
| Queue | 队列 | 缓冲并传递任务/消息的中间设施 |
| Question Router | 问题路由器 | 按问题类型（知识/状态/事务）分发到不同处理通道的组件 |
| Rate Limit | 速率限制 | API 单位时间允许的调用次数上限 |
| Read-only Mode | 只读模式 | 事故期间禁止写入、仅保留查询的降级状态 |
| Real-time / Batch | 实时/批量 | 数据处理的两种时效模式 |
| Reconciliation | 对账 | 定期核对两侧系统状态一致的机制 |
| Reference Data | 参考数据 | 币种、国家、税码、付款条款等低频变化的标准数据，与主数据/交易数据并列的 ERP 数据域 |
| Registry | 镜像仓库 | 存储与分发容器镜像的服务 |
| Reliability | 可靠性 | 系统在规定条件下稳定运行的能力 |
| Replay | 重放 | 从持久化存储重新消费历史事件以重建状态或恢复处理 |
| Reranker | 重排序器 | 对初检结果做二次排序以提升相关性的组件 |
| Repository（分层） | 仓储层 | 封装数据访问的组件（后端分层语境） |
| Repository（Git） | 代码仓库 | Git 管理的代码与提交历史存储；注意与后端分层的仓储层区分 |
| Reprocessing | 重新处理 | 对历史数据重跑管道以修复结果 |
| Request | 请求 | 客户端传给 API 的数据 |
| Requests / Limits | 资源请求/上限 | 容器的 CPU/内存申请值与上限值；配置错误会导致调度失败、节流或 OOMKilled |
| Retention | 数据保留期 | Kafka 按时间/大小保留事件的窗口，决定可重放的范围 |
| Revert | 回退提交 | 创建一个反向提交撤销原变更并保留历史，比 reset（重置，可能改写历史）更适合生产环境 |
| Retryability | 可重试性 | 错误是否适合自动重试的属性 |
| Risk Score | 风险评分 | 预测模型输出的风险概率分数，供人工复核决策 |
| Rules Engine | 规则引擎 | 集中执行业务规则的引擎 |
| Sandbox | 沙箱环境 | 第三方提供的隔离测试环境（如 CRM Sandbox） |
| Scalability | 可扩展性 | 系统应对负载增长的能力 |
| Schema | 数据结构定义 | 数据的结构与约束定义 |
| Schema Coupling | 结构耦合 | 直接依赖他人库表结构导致的强耦合 |
| Schema Drift | 结构漂移 | 实际数据结构逐渐偏离定义结构的现象，数据湖常见劣化来源 |
| Schema Evolution | 结构演进 | 事件/接口结构随时间演进时的版本与兼容管理 |
| Stage / Staging Area | 暂存区 | Git 中提交前准备变更的区域（git add 后进入暂存区） |
| State Persistence | 状态持久化 | 将流程/任务状态落盘以便故障恢复的机制 |
| Security | 安全 | 覆盖认证、授权、加密、审计等的工程能力 |
| Security Group | 安全组 | 云实例级虚拟防火墙规则（AWS 语境）；Azure 对应网络安全规则 |
| Self-hosted | 自托管 | 团队自行部署与运维的部署方式 |
| Semantic Search | 语义检索 | 基于向量相似度而非关键词精确匹配的检索；对精确标识符（如订单号）反而不可靠 |
| Sensor Data | 传感器数据 | 设备传感器采集的时序数据 |
| Sensor Drift | 传感器漂移 | 传感器读数随时间偏离真实值的现象，需定期校准 |
| Separation of Concerns | 关注点分离 | 按职责拆分系统的设计原则 |
| Serverless | 无服务器 | 事件驱动、按需执行、免管理服务器的运行模式，适合短任务与可变负载 |
| Service Design | 服务设计 | 定义服务边界、职责与接口的设计 |
| Service Discovery | 服务发现 | 服务间通过名称自动找到彼此实例的机制，Kubernetes 的核心能力之一 |
| Session | 会话 | 用户与系统一次交互的状态 |
| Small-file Problem | 小文件问题 | 数据湖中小文件过多导致查询变慢、成本升高的劣化现象 |
| Software Engineering | 软件工程 | 软件构建的工程学科 |
| Spark | 分布式计算引擎 | 大数据批处理引擎；FDE 只需认知级（Level A）理解分布式处理/数据帧/分区/混洗/执行器，深度调优交给数据平台专家 |
| Source Connector | 源连接器 | 从来源系统抽取数据的连接组件 |
| Source of Truth | 唯一事实来源 | 数据发生冲突时最终采信的来源 |
| Status Code | 状态码 | HTTP 响应状态编码（200 成功、400 客户端错误等） |
| Storage | 存储 | 数据持久化保存的设施 |
| Streaming | 流式处理 | 实时/准实时地逐条处理数据流 |
| Streaming Response | 流式响应 | 逐步返回输出、让用户更早看到结果的响应方式 |
| Structured Data | 结构化数据 | 具有固定结构的数据 |
| Structured Query | 结构化查询 | 如 SQL 的精确数据查询 |
| Subnet | 子网 | VPC/虚拟网络内的 IP 网段划分单元 |
| Sync / Async | 同步/异步 | 调用方是否等待任务完成的两种模式 |
| Synthetic Data | 合成数据 | 人工生成的替代数据，可验证流程但不能证明真实效果 |
| System Design | 系统设计 | 对系统结构与行为的工程设计 |
| System of Record | 权威记录系统 | 某类数据的官方权威来源系统 |
| System-of-Record Map | 记录系统映射表 | 业务实体 × 唯一事实来源 × 读写接口 × 负责人的表，比系统架构图更易暴露归属与集成边界 |
| System | 系统 | 参与业务流程的软件系统 |
| Terraform | 基础设施即代码工具 | 声明式配置 → Plan（计划）→ Apply（应用）→ State（状态）管理云资源；关注可复现性、远程状态与配置漂移 |
| Testing | 测试 | 验证系统行为符合预期的工程活动 |
| Ticket System | 工单系统 | 管理客服/运维工单流转的系统 |
| Time to Value | 见效时间 | 从投入到产生业务价值所需的时间 |
| Topic | 主题 | Kafka 中消息的逻辑分类，生产者写入、消费者订阅的单位 |
| Transaction Data | 交易数据 | 业务动作产生的记录（采购订单、发票、收付款等），与主数据/参考数据对应 |
| Transactional API | 事务型 API | 查询或操作实时业务状态的接口，与 RAG 知识问答互补 |
| Training Window | 训练窗口 | 构建训练样本特征的时间范围，不得包含预测时点之后的信息 |
| Transactions | 事务 | 保证一组操作原子执行的机制 |
| Transformation | 数据转换 | 清洗、格式转换、Join、聚合、去重等加工 |
| TypeScript | TypeScript 语言 | 带类型的 JavaScript 超集，前端/全栈/Node 后端常用；FDE 应能读懂、修改、调试并搭建简单服务 |
| Uniqueness | 唯一性 | 数据质量维度：数据是否无重复 |
| Unit Test | 单元测试 | 验证单个逻辑单元的测试 |
| Validation | 校验 | 检查输入/输出合法性的过程 |
| Vendor Lock-in | 供应商锁定 | 更换供应商时的高昂迁移成本 |
| Watermark | 水位线 | 标记已处理数据时间点、支持增量处理的机制 |
| Webhook | Web 回调 | 事件发生时通过 HTTP 回调主动通知对方系统 |
| Window Function | 窗口函数 | SQL 中跨行计算（排名/累计/滑动窗口）的函数，FDE 应熟练使用 |
| Worker | 工作进程 | 从队列取任务并执行的处理进程 |
| Workflow Engine | 工作流引擎 | 驱动业务流程自动执行与状态流转的引擎 |
5.1 常见企业系统
Section titled “5.1 常见企业系统”| 英文 | 中文 | 说明 |
|---|---|---|
| CRM | 客户关系管理系统 | 管理客户与销售流程的系统 |
| ERP | 企业资源计划系统 | 管理企业核心资源与流程的系统 |
| Identity System | 身份系统 | 管理用户身份与凭证的系统 |
| MES | 制造执行系统 | 制造业车间层的执行管理系统 |
| SaaS | 软件即服务 | 以订阅方式提供的云端软件 |
| SCADA | 数据采集与监控系统 | 工业现场数据采集、监视与控制的平台 |
6. 架构域（Architecture，架构）
Section titled “6. 架构域（Architecture，架构）”| 英文 | 中文 | 说明 |
|---|---|---|
| ADR Toolkit | 架构决策记录工具 | 记录「为什么当时这么决定」而不仅是最后用了什么；难逆转/有明显权衡/影响多团队/成本高的决策应建 ADR |
| Agent Architecture | 智能体架构 | 能执行动作的 AI 系统架构 |
| Anti-Pattern | 反模式 | 看似合理、在实践中反复导致失败的做法 |
| Application Architecture | 应用架构 | 应用内部结构与分层设计 |
| Architecture | 架构 | 系统整体结构与组合方式 |
| Architecture Composition | 架构组合 | 多个参考架构模式在真实项目中的组合使用 |
| Architecture Decision Record / ADR | 架构决策记录 | 记录决策、原因、权衡与复核时点的文档 |
| Architecture Diagram | 架构图 | 表达系统结构的图示，Solution Design 必备产出 |
| Architecture Diagramming Guide | 架构图绘制指南 | 一图一问原则 + 四种推荐图（上下文/组件/数据流/时序）+ 原型期 5–10 个主要组件的简化规则 |
| Architecture Pattern | 架构模式 | 针对一类重复问题的可复用架构方案 |
| Architecture Review Toolkit | 架构评审工具 | 八个 Lens（业务契合/数据/安全/集成/可靠性/规模/运维/成本）评审 + 五类结论输出 |
| Architecture Selection Toolkit | 架构选型工具 | 八个问题快速定位主/次模式 + 组合表，快速组合参考架构 |
| Component Diagram | 组件图 | 回答「系统内部有哪些主要模块」的视图 |
| Composition Sheet | 组合表 | 架构选型工具中填写主模式/次模式/数据模式/集成模式/人工控制/部署六项的表 |
| Components | 组件 | 架构中的功能单元 |
| Context Diagram | 系统上下文图 | 回答「系统和谁交互」的最外层视图 |
| Control Plane | 控制平面 | 负责允许/拒绝/限制等管控决策的逻辑层，应保持确定性 |
| Critical Path | 关键路径 | 决定系统整体表现与可用性的最小依赖链 |
| Decision Gate | 决策门控 | 按风险/置信度将请求分流到自动或人工路径的关卡 |
| Data Architecture | 数据架构 | 数据存储、流转与治理的整体设计 |
| Data Flow | 数据流 | 数据在系统间的流动路径 |
| Data Flow Diagram | 数据流图 | 回答「数据从哪里来、到哪里去」的图 |
| Deployment Model | 部署模型 | 系统部署环境与方式的定义 |
| Enterprise Integration Architecture | 企业集成架构 | 企业系统间集成的整体设计 |
| Event-Driven Architecture | 事件驱动架构 | 以「事件已发生」为协作基础的架构风格 |
| Failure Modes | 失败模式 | 系统可能失败的典型方式 |
| Functional Requirement | 功能性需求 | 系统应具备的功能 |
| High-Level Architecture | 总体架构 | 系统顶层的结构视图 |
| Implementation Path | 实施路径 | 参考架构从最小版本逐步演进的分阶段路线 |
| Implementation Plan | 实施计划 | 落地架构的分步计划 |
| Integration | 集成 | 系统间的连接与协作 |
| Integration Diagram | 集成图 | 表达系统间集成关系的图示 |
| Integration Plan | 集成计划 | 与企业系统集成的方案 |
| Key Decisions | 关键决策 | 架构或方案中的关键技术判断 |
| Non-functional Requirement | 非功能性需求 | 性能、安全、可用性等质量属性需求 |
| Operability | 可运维性 | 系统上线后易于运维的程度 |
| Reference Architecture | 参考架构 | 某类重复业务问题的高概率可行起点，用于「选模式、改模式」而非照抄 |
| Security Model | 安全模型 | 认证、授权、审计的安全设计 |
| Sequence Diagram | 时序图 | 按时间顺序回答「一个请求怎么执行」的图 |
| Simplest Viable Design | 最简可行设计 | 满足需求的最简单设计，避免过度工程 |
| Technical Requirement | 技术需求 | 由功能需求推导出的技术约束与要求 |
| Trade-offs | 权衡取舍 | 方案选择中收益与代价的平衡 |
| Trust Boundary | 信任边界 | 架构图中标出的不同信任级别分界线，每张图应能回答它在哪里 |
| Workflow Architecture | 工作流架构 | 业务流程自动化系统的架构 |
7. AI / RAG / Agent 专项
Section titled “7. AI / RAG / Agent 专项”| 英文 | 中文 | 说明 |
|---|---|---|
| Abstain | 拒答 | 无足够依据时允许模型不回答 |
| Acceptance Threshold | 验收阈值 | 评估指标必须达到的最低标准，AI 系统验收不能只靠「看起来不错」 |
| Accuracy | 准确率 | 输出正确的比例 |
| Agent | 智能体 | 不只回答问题、还能执行动作的 AI 系统 |
| Agent Assist | 坐席辅助 | AI 向人工坐席提供建议、由人最终确认的模式 |
| Agent Evaluation Toolkit | 智能体评估工具 | 七维评估（目标完成/工具选择/参数/策略合规/效率/恢复/终止），必须测完整轨迹而非仅最终答案 |
| Agent Trace Evaluation | 智能体轨迹评估 | 对 Agent 每步「决策→工具→参数→结果→下一决策」逐步评分 |
| Agent Permission | 智能体权限 | 授予 Agent 的权限，原则上不应超过当前用户权限 |
| Agent Productivity | 坐席人效 | 人类客服/销售等人员在 AI 辅助下的人均产出（注意与 AI Agent 区分） |
| AI-safe Context | AI 安全上下文 | 经过裁剪、可安全提供给模型的数据范围 |
| Answer Accuracy | 回答准确率 | RAG 答案与事实一致的程度 |
| Attention Dilution | 注意力稀释 | 上下文过长导致模型忽略重点信息的现象 |
| Autonomy Level | 自主等级 | L0 建议到 L4 边界内广泛自主的自动化分级，应凭证据逐级开放 |
| Benchmark | 基准测试 | 公开任务集上的模型评测结果，选型时不能只看它 |
| Business Evaluation | 业务级评估 | 从业务结果（工单时长、满意度、自动化率）衡量 AI 系统 |
| Business Guardrails | 业务护栏 | 按业务规则拦截或转人工的控制（如退款超限额需审批） |
| Business Validation | 业务校验 | 校验模型输出是否符合业务规则 |
| Bounded Autonomy | 有界自主 | Agent 行为受步数、权限、确认等约束的设计原则 |
| Chatbot | 聊天机器人 | 以对话方式回答问题的应用 |
| Chunking | 分块 | 将文档切分为适合检索的片段 |
| Chunk Overlap | 分块重叠 | 相邻内容块之间保留的重叠内容 |
| Citation | 引用溯源 | 答案能追溯到来源文档的能力 |
| Citation Accuracy | 引用准确性 | RAG 生成评估维度：答案中的引用来源是否指向正确文档 |
| Clustering | 聚类 | 按相似度把内容自动分组，Embedding 的典型用途之一 |
| Component Evaluation | 组件级评估 | 对 Retriever、模型等单个组件的评估 |
| Cosine Similarity / Dot Product / Euclidean Distance | 余弦相似度/点积/欧氏距离 | 常见向量相似度度量；FDE 无需手工实现，但要知道所用向量库与模型对距离和归一化的约定 |
| Confidence Indicator | 置信度指示 | 向用户展示系统对答案/建议置信程度的标识 |
| Copilot | 智能副手 | 嵌入工作流、辅助人完成任务的 AI 助手，核心是工作流集成而非聊天界面 |
| Completion Criteria | 完成判定条件 | 明确任务何时算完成的信号，防止 Agent 循环 |
| Context | 上下文 | 提供给模型的背景信息 |
| Context Construction | 上下文构建 | 决定放入多少、哪些检索内容到 Prompt |
| Context Dependency | 上下文依赖 | AI 项目的特点：同一模型在不同客户环境（数据/知识/系统/权限/工作流/风险）表现可能完全不同 |
| Context Window | 上下文窗口 | 模型单次可处理的 Token 数量上限 |
| Data Freshness | 数据新鲜度 | 索引/知识库内容相对源系统的滞后程度，常见 RAG 失败根因之一 |
| Determinism | 确定性 | 相同输入产生稳定、可预期输出的程度 |
| Dimension | 向量维度 | Embedding 向量的维度数；更高维度不自动更好，会增加存储/索引/计算成本 |
| Context Reduction | 上下文缩减 | 精简进入模型的内容以降低延迟与成本 |
| Domain Router | 领路由器 | 按业务领域选择工具集/模型的路由层 |
| Embedding | 向量化/嵌入 | 将文本转换为向量的表示方法 |
| Embedding Model | 嵌入模型 | 专门生成向量表示的模型 |
| End-to-End Success Rate | 端到端成功率 | 从用户请求到最终完成的整体成功率 |
| Enterprise Knowledge | 企业私有知识 | 企业内部文档与数据知识 |
| Evaluation | 评估 | 对系统效果的量化测量 |
| Evaluation Score | 评估得分 | 对单次请求/回答的质量打分 |
| Failure Taxonomy | 失败分类 | 为每次失败标注所属环节（解析/分块/元数据/查询改写/检索/重排序/上下文/提示词/模型/引用/权限/新鲜度） |
| Failure to Escalate | 未升级 | Agent 遇到超权限或失败场景未转人工的失败类型 |
| Few-shot Example | 少样本示例 | Prompt 中给出的输入输出示例 |
| Fine-tuning | 微调 | 在已有模型上继续训练以适配任务 |
| Foundation Model | 基础模型 | 大规模预训练得到的通用模型 |
| Fully Autonomous Agent | 全自主智能体 | 无需人工确认即可端到端完成任务的 Agent，多数业务场景不应从它起步 |
| Generation | 生成 | 模型基于上下文产出回答的阶段 |
| Generation Quality | 生成质量 | 模型依据检索内容回答的质量 |
| Golden Dataset | 黄金数据集 | 人工标注的高质量评估数据集 |
| Goal Completion | 目标完成度 | Agent 评估维度：任务最终是否完成 |
| Groundedness | 事实有据性 | 回答是否基于检索到的内容，而非模型幻觉 |
| Guardrails | 护栏 | 限制模型行为边界的安全防护机制 |
| Hallucination | 幻觉 | 模型生成看似合理但不符合事实的内容 |
| Hallucinated Tool | 幻觉工具 | Agent 试图调用并不存在的工具的失败模式 |
| High-risk Operation | 高风险操作 | 可能造成损失、需人工确认的操作 |
| Hit@K | Top-K 命中率 | 正确文档出现在检索结果前 K 条的比例，检索评估核心指标 |
| Human Judgment | 人类判断 | AI 系统中不可替代的责任主体；高风险决策应保留人类判断与问责 |
| Indexing | 索引 | 为切分后的内容建立可检索索引的过程 |
| Information Extraction | 信息抽取 | 从非结构化文本中提取结构化信息 |
| Input Guardrails | 输入护栏 | 对用户输入的检查与防护 |
| Intent | 意图 | 用户输入背后的真实目的 |
| Intent Classification | 意图分类 | 判断问题属于知识型/事务型等类别的机制 |
| Latency | 延迟 | 请求到响应的耗时 |
| LLM | 大语言模型 | 以大规模文本训练的生成式模型 |
| Max Step Limit | 最大步数限制 | 限制 Agent 单任务执行步数的护栏 |
| Metadata Filter | 元数据过滤 | 按元数据（如部门、日期）缩小检索范围 |
| Model Evaluation | 模型级评估 | 对模型回答质量（准确率、相关性等）的评估 |
| Model-first Thinking | 模型优先思维 | 反模式：「我们有大模型」→ 找问题；正确顺序是业务问题 → 选择能力 |
| Model Routing | 模型路由 | 按任务把请求路由到不同模型以平衡成本与质量 |
| Model Selection | 模型选型 | 按准确率、延迟、成本、隐私等维度为任务选择模型 |
| Multimodal Model | 多模态模型 | 可处理图像等多种模态输入的模型 |
| Observation | 观测结果 | 工具执行后返回给 Agent 的结果 |
| Offline Evaluation | 离线评估 | 基于测试数据集的批量评估 |
| Online Evaluation | 在线评估 | 生产环境中基于真实使用与反馈的评估 |
| Output Guardrails | 输出护栏 | 对模型输出的检查与防护 |
| Parsing | 解析 | 将原始文档转换为可处理结构 |
| Parent-child Retrieval | 父子检索 | 检索细粒度子块、返回更大父块的策略 |
| Permission-aware Retrieval | 权限感知检索 | 按用户权限过滤检索结果的机制 |
| Planner | 规划器 | Agent 中负责拆解与规划步骤的模块 |
| Policy Compliance | 策略合规 | Agent 评估维度：是否越权或违反使用策略 |
| Policy Engine | 策略引擎 | 集中执行策略规则的组件，护栏不应只靠 Prompt |
| Policy Layer | 策略层 | 应用层中决定是否、如何执行工具的管控层 |
| Premature Stop | 过早停止 | Agent 未完成任务即自行终止的失败类型 |
| Probabilistic Model | 概率模型 | 输出具有不确定性的模型；AI 系统相较确定性软件新增的不确定性来源 |
| Prompt | 提示词 | 输入给模型的指令文本 |
| Prompt Version | 提示词版本 | Prompt 的版本标记，用于定位问题与对比效果 |
| Query | 查询 | 用户输入的检索/对话请求 |
| Query Processing | 查询处理 | 对用户查询的改写与预处理 |
| Query Reformulation | 查询重构（用户行为） | 用户反复改写查询的行为，是搜索质量不佳的负向信号；区别于系统侧的 Query Rewrite（查询改写） |
| Query Rewrite | 查询改写 | 改写用户查询以提高检索命中的技术 |
| RAG / Retrieval-Augmented Generation | 检索增强生成 | 先检索私有知识再生成回答的架构 |
| RAG Evaluation Toolkit | RAG 评估工具 | 评测数据集 + 检索评估（Hit@K / 召回 / 精确）+ 生成评估（正确/依据/相关/完整/引用/拒答）+ 失败分类；不只记 Pass / Fail，还要记为什么失败 |
| Re-embedding | 重新向量化 | 更换嵌入模型后必须对全量内容重建向量，否则新旧向量空间不兼容；大规模迁移带来时间/存储/成本与双索引复杂度 |
| Reasoning | 推理 | 模型逐步思考得出结论的过程 |
| Regression Evaluation | 回归评估 | 改动后重跑评估集、防止效果劣化的机制 |
| Relevance | 相关性 | 回答与用户问题的相关程度 |
| Response | 响应 | 系统返回给用户的结果 |
| Retrieval | 检索 | 从知识库取回相关内容的过程 |
| Retrieval Precision | 检索精确率 | 检回内容中真正相关的比例 |
| Retrieval Quality | 检索质量 | 检索环节找到正确内容的能力 |
| Retrieval Recall | 检索召回率 | 应检出的内容中被检出的比例 |
| Retrieval Trace | 检索链路记录 | 记录每次检索的查询、结果与得分的日志 |
| Retriever | 检索器 | 负责从知识库取回相关内容的组件 |
| Routing | 路由 | 将请求分配到目标处理路径 |
| Safety | 安全性 | 输出内容的安全合规程度 |
| Schema Validation | 结构校验 | 校验模型输出是否符合预定数据结构 |
| Semantic Boundary | 语义边界 | 按语义完整性切分内容块的依据 |
| Solution Boundary | 方案边界 | AI 项目真实解构成（如工作流+RAG+接口+人工审批）与客户表述（「想做 Agent」）往往不同，界定边界是 FDE 核心职责 |
| Stale Index | 过期索引 | 来源数据已更新而向量索引未同步，产生过期知识；需要定义更新与删除策略 |
| Structured Output | 结构化输出 | 让模型按固定格式（如 JSON）输出结果 |
| System Evaluation | 系统级评估 | 对端到端成功率、延迟、成本、工具成功率等的评估 |
| Task Classification | 任务分类 | 判断请求属于哪类任务，用于路由 |
| Temperature | 温度参数 | 控制模型生成随机性的参数 |
| Termination | 终止条件 | 定义 Agent 任务何时结束的判据，缺失会导致循环 |
| Test Dataset | 测试数据集 | 评估用的问题、期望答案、期望来源集合 |
| Ticket Replay | 工单回放 | 用历史工单重放验证 AI 客服行为的评估方法 |
| Token | 词元 | 模型处理文本的最小计量单位 |
| Tool | 工具 | Agent 可调用的外部能力（API、函数等） |
| Tool Calling | 工具调用 | 模型发起对外部工具的调用 |
| Tool Design | 工具设计 | 设计工具的功能、参数、权限与返回结构 |
| Tool Execution | 工具执行 | 实际运行工具并获取结果 |
| Tool Guardrails | 工具护栏 | 对可用工具、允许参数与需确认动作的控制 |
| Tool Permission | 工具权限 | Agent 可调用工具的白名单控制 |
| Tool Registry | 工具注册表 | 集中定义工具、描述、参数与权限的组件 |
| Tool Result | 工具结果 | 工具执行后返回给模型的内容 |
| Tool Selection | 工具选择 | Agent 决定调用哪个工具 |
| Tool Success Rate | 工具成功率 | 工具调用成功执行的比例 |
| Top-K | Top-K 检索数量 | 每次检索返回的前 K 条结果数 |
| User Permission | 用户权限 | 以用户身份校验其可执行的操作 |
| Vector Database | 向量数据库 | 存储与检索向量的数据库 |
| Vector Index | 向量索引 | 支持近邻搜索的向量数据结构；索引设计还需关注集合/分区/命名空间/租户与元数据结构 |
| Vector Search | 向量检索 | 基于向量相似度的检索方式 |
| Vector Store | 向量存储 | 存储向量的存储组件（通常即向量数据库） |
8. 生产与运维（Production & Operations）
Section titled “8. 生产与运维（Production & Operations）”| 英文 | 中文 | 说明 |
|---|---|---|
| Alerting / Alerts | 告警 | 异常发生时通知相关人员 |
| Audit Trail | 审计轨迹 | 可完整追溯每一步操作及其决策依据的记录链 |
| Backoff | 退避 | 重试之间逐渐延长等待时间 |
| Build | 构建 | 编译与产出构建物的过程 |
| Capacity Planning | 容量规划 | 预估并准备扩容后所需资源的过程 |
| Circuit Breaker | 熔断器 | 连续失败时快速截断请求、防止雪崩的机制 |
| CI/CD | 持续集成/持续交付 | 自动化构建、测试与发布流水线 |
| Cost | 成本 | 系统运行的资源开销 |
| Cost per Successful Task | 单次成功任务成本 | 按成功任务计量的综合成本，比仅看 Token 成本更合理 |
| Cost per Task | 单任务成本 | 完成单个任务的平均成本 |
| Correlation ID | 关联标识 | 贯穿网关与应用日志的请求级标识，把 Gateway Log（网关日志）与 Application Log（应用日志）连接起来排查问题 |
| CPU | 处理器 | 处理器资源使用率指标 |
| Detection Gap | 检测盲区 | 问题发生到被发现的间隔与遗漏，事故复盘产物 |
| Distributed Trace | 分布式链路追踪 | 跨服务记录请求各段耗时与路径的追踪 |
| Embedding Cost | 嵌入成本 | 向量化调用产生的费用 |
| Encryption | 加密 | 数据的加密保护 |
| Environment Management | 环境管理 | Dev（开发）/ Staging（预发）/ Prod（生产）环境隔离与管理 |
| Error Rate | 错误率 | 失败请求占总请求的比例 |
| Evidence Pack | 证据包 | 问题升级前准备的标准上下文包（时间、复现、证据、已试措施） |
| Failover | 故障切换 | 主节点故障时切换到备用节点 |
| Failure Recovery | 故障恢复 | 故障后恢复服务的机制 |
| Fallback | 降级备选 | 主路径失败时使用的替代策略 |
| Graceful Degradation | 优雅降级 | 部分依赖失败时仍保留核心功能 |
| Human Escalation | 转人工升级 | 系统无法处理时交给人工处理 |
| Idempotency | 幂等性 | 同一操作重复执行不产生额外影响 |
| Incident Count | 事故数 | 统计周期内生产事故的数量 |
| Incident Response | 事故响应 | 生产事故的应急处理流程 |
| Infrastructure Cost | 基础设施成本 | 计算、存储、网络等资源开销 |
| Initial Evaluation | 初始评估 | 原型阶段的初步效果评估 |
| Logs | 日志 | 系统运行事件的记录 |
| Logging | 日志记录 | 产生与收集日志的活动 |
| Memory | 内存 | 内存资源使用率指标 |
| Metrics | 指标 | 可量化的系统运行数据 |
| Model Cost | 模型成本 | 调用模型产生的费用 |
| Model Monitoring | 模型监控 | 对线上模型效果（准确率、漂移等）的持续监测 |
| Monitoring | 监控 | 对系统状态的持续观测 |
| MTTD / MTTR | 平均检测/解决时间 | Mean Time to Detect / Resolve，Hypercare 关键指标 |
| Observability | 可观测性 | 通过 Logs（日志）、Metrics（指标）、Traces（链路追踪）理解系统内部状态的能力 |
| On-call | 值班待命 | 随时响应生产问题的职责安排 |
| Operational Metrics | 运营指标 | 试点阶段衡量系统运行表现的指标 |
| Operations | 运维 | 系统上线后的日常运营维护 |
| P50 / P95 / P99 | 分位延迟 | 第 50/95/99 百分位的响应时间，衡量长尾延迟 |
| Package | 打包 | 将构建产物组织为可部署单元 |
| Patch | 补丁更新 | 为缺陷或安全漏洞发布的修复版本 |
| Production Deployment | 生产部署 | 将系统正式部署到生产环境 |
| Production Monitoring | 生产监控 | 上线后对系统运行的持续监测 |
| Production System | 生产系统 | 面向真实用户与真实数据的正式系统 |
| Requests per Second / RPS | 每秒请求数 | 系统吞吐量指标 |
| Retry | 重试 | 请求失败后自动重发 |
| Rollback | 回滚 | 恢复到上一稳定版本 |
| Rollout | 滚动发布 | Kubernetes Deployment 逐步替换 Pod 完成版本更新；生产前需考虑就绪检查/向后兼容/数据库迁移/回滚 |
| Runbook | 运维手册 | 标准运维操作与应急处理的手册 |
| Security Check | 安全检查 | CI/CD 流水线中的安全扫描环节 |
| Severity | 严重等级 | 按业务影响划分的问题级别（SEV-1 至 SEV-4） |
| SLA | 服务等级协议 | 与客户约定的服务可用性/性能承诺 |
| SLO | 服务等级目标 | 团队对延迟/可用性设定的量化目标（如 P95 < 5s） |
| Support | 支持体系 | 上线后的用户支持机制 |
| System Availability | 系统可用性 | 系统对用户可用的比例 |
| Technical Findings | 技术结论 | 原型阶段得出的技术验证结论 |
| Timeout | 超时 | 请求超过时限即失败返回 |
| Token Cost | Token 成本 | LLM 按 Token 计量的调用成本 |
| Token Usage | Token 用量 | 模型调用消耗的 Token 数量 |
| Traces / Tracing | 链路追踪 | 跨服务请求全链路的追踪 |
| Triage | 分诊 | 快速判断问题类别与严重度并路由到正确处理路径 |
| User Feedback | 用户反馈 | 用户对系统使用的评价与意见 |
| User Identity Propagation | 用户身份透传 | 把最终用户身份沿调用链传递到工具与下游系统，用于权限校验与审计 |
9. 安全（Security）
Section titled “9. 安全（Security）”| 英文 | 中文 | 说明 |
|---|---|---|
| ABAC | 基于属性的访问控制 | 按用户、资源、环境属性动态判定权限 |
| Access Control | 访问权限 | 对数据与操作的访问控制 |
| Access Token | 访问令牌 | OAuth 中用于访问资源的短期凭证 |
| ACL / Access Control List | 访问控制列表 | 按列表显式列出可访问主体的权限形式，文档级权限常用 |
| Allowlist | 白名单 | 仅允许显式列出的对象通过的机制（网络访问/工具调用/出口流量） |
| Anonymous Access | 匿名访问 | 未经验证的访问，需明确限制 |
| At-most-once / Exactly-once | 至多一次/精确一次 | 消息投递语义；业务常用 At-least-once + 幂等消费替代 Exactly-once |
| API Key | API 密钥 | 用于识别调用方身份的密钥凭证 |
| At-least-once Delivery | 至少一次投递 | 不排除重复送达的消息投递保证 |
| Audit | 审计 | 对操作行为的可追踪记录 |
| Authentication | 身份认证 | 验证「你是谁」 |
| Authn / Authz | 认证/授权缩写 | Authentication（认证）与 Authorization（授权）的行业缩写；网关常完成前者，业务资源级判断仍需后端 |
| Authorization | 授权 | 验证「你能做什么」 |
| Authorization Server | 授权服务器 | OAuth 中负责认证用户并签发令牌的服务 |
| Client Secret | 客户端密钥 | OAuth 应用方保管的密钥，用于证明应用身份 |
| Data Access | 数据访问控制 | 控制谁能访问哪些数据 |
| Data Access Request | 数据访问申请 | 正式申请数据访问权限的文档化流程 |
| Data Classification | 数据分级 | 按敏感度对数据分级以确定保护与流转要求 |
| Data Masking | 数据脱敏 | 对敏感字段进行遮蔽或泛化处理的技术 |
| Defense in Depth | 纵深防御 | 不把安全控制放在单一位置（如只靠 API 网关），而是多层设防：应用授权/数据控制/审计/服务凭证 |
| Document Retention | 文档保留策略 | 规定文档保存期限与销毁方式的合规策略 |
| DPA | 数据处理协议 | 与数据处理方签订的数据保护协议 |
| Identity Provider | 身份提供方 | 集中提供认证与身份服务的企业系统 |
| Individual Identity | 个人身份 | 绑定到具体个人的身份凭证，区别于共享凭证 |
| Index Isolation | 索引隔离 | 按权限/租户物理或逻辑隔离索引，防止越权检索 |
| JWT | JSON 网络令牌 | 自包含身份声明的令牌，常用于 API 认证 |
| Least Privilege | 最小权限 | 只授予完成任务所需的最小权限原则 |
| Malicious Input | 恶意输入 | 试图攻击或滥用系统的输入 |
| Malware Scanning | 恶意软件扫描 | 对上传文档进行病毒/恶意代码检测的安全环节 |
| Managed Identity | 托管标识 | Azure 自动管理的应用身份，平台负责凭证轮换，免长期密钥 |
| Model Risk | 模型风险 | 模型输出错误、偏差或被滥用带来的风险类别 |
| MFA | 多因素认证 | 结合多种因素（密码+手机等）的认证方式 |
| Microsoft Entra ID | 微软企业身份平台 | 原 Azure Active Directory（Azure AD），提供企业目录、SSO 与身份管理 |
| OAuth | 开放授权协议 | 第三方授权访问的开放标准 |
| Permission Audit | 权限审计 | 对权限分配与使用的定期审查 |
| Permission Check | 权限检查 | 接口执行前校验调用方是否有权执行 |
| Permission List | 权限列表 | 显式列出可执行操作的授权形式 |
| Permission Test Matrix | 权限测试矩阵 | 角色 × 操作的权限验证表 |
| PII | 个人身份信息 | 可识别个人身份的敏感数据（Personally Identifiable Information） |
| Policy-Based Access Control | 基于策略的访问控制 | 以策略规则集中管理权限的模型 |
| Privacy | 数据隐私 | 数据收集、使用与流转的隐私合规要求 |
| Prompt Injection | 提示词注入 | 通过构造输入操纵模型行为的攻击方式 |
| Purpose Limitation | 目的限制 | 数据仅可用于收集时声明的目的的隐私原则 |
| RBAC | 基于角色的访问控制 | 按角色分配权限的模型 |
| Red Team | 红队 | 模拟攻击方检验系统安全的团队；FDE 不需要成为红队，但需要威胁导向思维 |
| Refresh Token | 刷新令牌 | OAuth 中用于换取新访问令牌的凭证 |
| Resource Owner | 资源所有者 | OAuth 中拥有数据、可授权访问的用户 |
| Resource Server | 资源服务器 | OAuth 中持有资源并接受访问令牌的服务 |
| Revocation | 吊销 | 使凭证立即失效的操作 |
| Role | 角色 | 权限分配的载体，RBAC 的核心概念 |
| Role Mapping | 角色映射 | 身份系统角色到应用角色的转换关系 |
| Rotation | 轮换 | 定期更换密钥凭证的机制 |
| Runtime Injection | 运行时注入 | 运行时才注入密钥/配置，避免打进镜像或代码 |
| Scope | 权限范围 | OAuth 中对授权范围的限定（如 crm.read） |
| Secret Management | 密钥管理 | 安全存储与管理密钥凭证 |
| Secret Manager | 密钥管理服务 | 集中保管与下发密钥的系统 |
| Security Controls | 安全控制措施 | 上线前必须落实的安全措施集合 |
| Sensitive Data | 敏感数据 | 泄露会造成损害、需特殊保护的数据 |
| Service Account | 服务账号 | 供程序/服务间调用使用的机器身份 |
| Service Identity | 服务身份 | 绑定到服务本身的身份，用于服务间调用 |
| Service Principal | 服务主体 | Azure 中代表应用/服务的身份对象；权限过大是常见失败模式 |
| Shared Admin Account | 共享管理员账号 | 多人共用管理员账号的反模式 |
| Shared Credential | 共享凭证 | 多人共用的凭证，是危险的技术债 |
| Short-lived Credential | 短期凭证 | 有效期很短、自动轮换的凭证 |
| Signature Validation | 签名校验 | 验证回调请求来源真实性的机制 |
| SSO | 单点登录 | 一次登录访问多个系统 |
| Tenant Isolation | 租户隔离 | 多租户系统中隔离不同客户数据与资源的机制，向量检索与多客户部署的基本要求 |
| TLS | 传输层安全协议 | 加密传输通道的安全协议（Transport Layer Security） |
| User-scoped Access | 用户级数据访问 | 以当前用户身份限定可访问数据范围 |
| Username / Password | 用户名/密码 | 最基础的身份认证方式 |
| Vendor Risk | 供应商风险 | 第三方供应商（含模型服务商）引入的安全与合规风险 |
| Workload Identity | 工作负载身份 | 绑定到工作负载本身的云身份（IAM 角色/托管标识），替代长期硬编码 Access Key |
10. 知识库元数据与模板（KB Metadata & Templates）
Section titled “10. 知识库元数据与模板（KB Metadata & Templates）”| 英文 | 中文 | 说明 |
|---|---|---|
| Activities | 活动 | Playbook 中该阶段要做的事 |
| Architecture Decision Record Template | 架构决策记录模板 | 记录架构决策的标准模板（第 14 个模板） |
| Architecture ID | 架构编号 | 参考架构模式唯一标识（如 ARCH-001），用于索引与关联 |
| Business Case Template | 商业论证模板 | 论证项目价值的标准模板（第 18 个模板） |
| Career Evidence Portfolio Template | 职业证据作品集模板 | 按六维胜任力组织证据的模板（第 24 个模板） |
| Checklist | 检查清单 | 逐项勾选的核查列表 |
| Common Issues | 常见问题 | 操作指南中的高频问题 |
| Common Mistakes | 常见错误 | 该知识条目下易犯的错误 |
| Concept Template | 概念模板 | 解释概念类条目的标准模板 |
| Core（状态） | 核心骨架 | 已成为知识库核心结构，后续继续补充 |
| Core Working Set | 核心工作集 | 26 个工具中最值得日常熟练使用的 10 个，覆盖调研→理解→排序→设计→评审→管理风险→沟通→决策 |
| Current State / Target State Template | 现状/目标状态模板 | 对比业务前后状态的标准模板（第 17 个模板） |
| Customer Meeting Notes Template | 客户会议纪要模板 | 记录客户会议的标准模板（第 21 个模板） |
| Decision Drivers | 决策驱动因素 | ADR 中推动决策的业务/安全/成本/延迟等考量 |
| Decision Guides | 决策指南 | 对比选型类知识条目（Engineering 下一阶段重点） |
| Definition | 定义 | 概念的定义 |
| Delivery Playbook Template | 交付手册模板 | 交付阶段手册的标准模板 |
| Diagnostic Steps | 诊断步骤 | 逐步缩小问题范围的检查序列 |
| Diagram | 图示 | 表达架构或流程的图 |
| Draft（状态） | 草稿 | 初步想法，结构未定 |
| Escalation Criteria | 升级条件 | 何时将问题升级给其他团队的判定标准 |
| Example | 示例 | 真实业务例子 |
| Expanded（状态） | 已扩充 | 已补充案例、图示、检查清单 |
| Fake Precision | 伪精确 | 反模式：把评分小数差（4.37 vs 4.21）当成真实优先级差异；评分辅助讨论，不替代判断 |
| 30-60-90 Day Plan | 30-60-90 天计划 | 新 FDE 分学习/贡献/拥有三阶段融入的计划 |
| FDE Context | FDE 场景 | 概念在客户项目中的使用场景 |
| FDE Development Plan Template | FDE 发展计划模板 | 个人能力发展计划模板（第 25 个模板） |
| FDE Interview Case Template | FDE 面试案例模板 | 设计客户情景面试题的模板（第 26 个模板） |
| FDE Project Workspace Template | 项目工作空间模板 | 新建 Project OS 项目时复制的工作空间骨架（第 31 个模板） |
| FDE Weekly Operating Review Template | 每周运营评审模板 | 每周运营评审的 11 节结构（成果/里程碑/业务/工程/风险/问题/实验/决策/依赖/下周/升级，第 30 个模板） |
| FDE Operating Loop | FDE 操作循环 | 理解→调研→定义机会→排序→设计架构→构建→评估→交付→运营→度量价值→学习→复用的完整循环 |
| FDE Operating System | FDE 操作系统 | 知识+方法论+手册+情景应对+工具+成长的完整 FDE 工作体系，从静态知识库走向可操作系统 |
| Field Guide ID | 速查指南编号 | 现场情景指南唯一标识（如 FG-001），用于索引与关联 |
| Field Guide Template | 现场速查指南模板 | 编写现场情景应对指南的标准模板（第 23 个模板） |
| Field Playbook Template | 现场手册模板 | 编写现场执行手册的标准模板（第 20 个模板） |
| Frontmatter | 文件头部元数据 | Markdown 文件顶部的 YAML 元数据块 |
| Glossary | 术语表 | 中英文术语对照表（即本文件） |
| Goal | 目标 | 操作指南要达成的最终结果 |
| High-Level Architecture | 总体架构 | 架构模板中的顶层结构章节 |
| How It Works | 工作原理 | 概念的核心机制 |
| How-To Template | 操作指南模板 | 操作类条目的标准模板 |
| Impact | 影响 | 问题对业务造成的实际影响 |
| Industry ID | 行业编号 | 行业条目唯一标识（如 IND-001），用于索引与关联 |
| Industry Knowledge Template | 行业知识模板 | 新增行业条目的标准模板（第 22 个模板） |
| Inputs | 输入 | 开始前需要的信息 |
| Knowledge Map | 知识地图 | 知识库整体结构与导航 |
| Legend | 图例 | 图中符号与术语的对照说明 |
| Minimum Artifact Principle | 最小工件原则 | 只创建支撑下一个重要决策所必需的最少工件；工具应该服务项目，不是项目服务工具 |
| New Pattern Proposal Template | 新模式提案模板 | 发现新的重复模式时提交提案的标准模板，要求列出案例证据与重复要素（第 29 个模板） |
| Objective | 阶段目标 | Playbook 中该阶段的目标 |
| Output | 输出 | 完成后应得到的结果 |
| Phase | 阶段 | 知识库建设阶段标记（如 Phase 1） |
| Playbook | 行动手册 | 某一场景的标准操作手册 |
| Playbook ID | 手册编号 | 现场手册唯一标识（如 PB-001），用于索引与关联 |
| Prerequisites | 前置条件 | 开始之前必须满足的条件 |
| Production（状态） | 定稿 | 可作为标准参考资料；注意与「生产环境」区分 |
| Project Operating System | 项目操作系统 | 13 Operating System 域：用一个统一项目工作空间管理客户上下文、问题、用例、架构、决策、风险、实验、交付、生产运营、价值与项目学习 |
| Project Overview Dashboard Template | 项目总览看板模板 | 项目首页控制面板模板：阶段/健康度/主用例/指标/下一门禁/头部风险/需要的决策（第 32 个模板） |
| Project Workspace | 项目工作空间 | 统一组织客户上下文/干系人/问题/用例/架构/ADR/计划/风险/评估/指标/事件/价值/经验教训的项目容器 |
| Registry Record Template | 登记记录通用模板 | 所有登记表条目的统一元数据（编号/类型/责任人/状态/关联/证据），使不同登记表可互相引用（第 33 个模板） |
| Questions | 必须回答的问题 | Playbook 中该阶段必须回答的问题 |
| Related Topics | 关联知识 | 与本条目相关的其他知识条目 |
| Reproduction Steps | 复现步骤 | 稳定重现问题的操作序列 |
| Reviewed（状态） | 已评审 | 经过评审修改 |
| Revisit Conditions | 重新评估条件 | ADR 中约定何种变化时应重新审视决策 |
| Risk Accepted | 风险已接受 | Checklist 结论之一，须记录风险、责任人、缓解措施与复核日期 |
| Risks | 风险 | 该阶段的主要风险 |
| Stakeholder Map Template | 干系人地图模板 | 记录干系人权力/利益/关注点的标准模板（第 16 个模板） |
| Skill Matrix | 技能矩阵 | 按 Aware/Working/Independent/Leading 四级 × 职级的能力地图 |
| Solution Pattern | 解决方案模式 | 反复出现的客户问题通常可采用的业务+架构+工程+交付组合方案（12 Patterns 域，区别于回答系统构成的 Architecture Pattern 架构模式） |
| Solution Pattern Review Template | 模式评审模板 | 评审模式对当前客户适用性的标准模板，结论为采用/大幅定制后采用/不采用（第 28 个模板） |
| Solution Pattern Template | 解决方案模式模板 | 编写新模式的标准 28 字段结构：问题签名→业务信号→…→关联行业（第 27 个模板） |
| Spreadsheet as Reality | 表格即现实 | 反模式：模型里 ROI 很好不代表 Pilot 一定实现，所有模型都依赖假设 |
| Status | 状态 | 文章状态字段 |
| Steps | 步骤 | 操作指南的执行步骤 |
| Superseded | 被取代 | ADR 状态之一：该决策已被后续 ADR 替代 |
| Symptoms | 症状 | 用户或监控直接观察到的问题现象 |
| Technical Working Set | 技术工作集 | 偏技术执行 FDE 的第二套核心组合（8 个工具），形成构建→评估→调试→部署→运营 |
| Template | 模板 | 标准化的文章结构 |
| Template Theater | 模板表演 | 反模式：所有模板都填了，但项目依然没人知道下一步是什么 |
| Toolkit | 工具箱 | 把方法论转化为可直接填写、计算、判断、评审和执行的工作工具；核心链路：知识→框架→手册→工具→工件→决策 |
| Toolkit ID | 工具编号 | 工具箱条目唯一标识（如 TK-001），用于索引与关联 |
| Toolkit Maturity Model | 工具箱成熟度模型 | Ad Hoc（临时自发）→ Standardized（标准化）→ Integrated（集成化）→ Instrumented（可测量化）四级演进 |
| Toolkit Metadata | 工具元数据 | 每个工具的编号/类别/主要目标/适用场景/输入/输出/典型耗时/关联手册与模板等描述字段 |
| Tool Proliferation | 工具泛滥 | 反模式：每个项目都创造新模板，导致不一致、重复、找不到正确版本；优先复用标准工具 |
| Use Case Canvas Template | 用例画布模板 | 结构化定义用例的标准模板（第 15 个模板） |
| Value Realization Dashboard Template | 价值实现看板模板 | 对照基线/目标/实际值的价值看板模板（第 19 个模板） |
| Version | 版本 | 内容版本号（如 v0.1） |
| When NOT to Use | 不适用场景 | 不应该使用的情况 |
| When to Use | 适用场景 | 应该使用的情况 |
| Why It Matters | 为什么重要 | 该知识对 FDE 的意义 |
11. 案例研究（Case Studies，案例研究）
Section titled “11. 案例研究（Case Studies，案例研究）”| 英文 | 中文 | 说明 |
|---|---|---|
| Anonymized Real Case | 匿名真实案例 | 经脱敏处理的真实项目案例，须删除客户名、敏感数据与保密指标 |
| Case ID | 案例编号 | 案例唯一标识（如 CS-001），用于索引与关联 |
| Case Study | 案例研究 | 记录一个项目从客户背景到可复用经验的端到端全过程的知识形式 |
| Case Type | 案例类型 | 案例真实性等级：Reference Scenario / Anonymized Real Case / Public Case / Internal Case |
| Cross-Case Comparison | 横向案例对比 | 多个案例跨问题、模式、风险的对比分析 |
| Cross-Case Lessons | 横向案例经验 | 从多个案例中提炼的跨项目通用规律 |
| Internal Case | 内部案例 | 来自本团队内部项目的案例 |
| Public Case | 公开案例 | 来自公开来源（新闻、博客、会议分享）的案例 |
| Reference Scenario | 参考情景 | 用于教学和方法论说明的综合情景案例，不得包装为真实客户项目 |
| Reusable Lessons | 可复用经验 | 从案例中提炼、可迁移到其他项目的规律 |
12. 行业知识（Industries，行业）
Section titled “12. 行业知识（Industries，行业）”| 英文 | 中文 | 说明 |
|---|---|---|
| Activation | 激活 | 新用户完成关键行为、开始获得价值的比例 |
| Assets Under Management / AUM | 管理资产规模 | 财富管理业务管理的客户资产总额 |
| Average Order Value / AOV | 客单价 | 零售平均每笔订单金额 |
| Cart Abandonment | 购物车弃单率 | 加购后未完成结算的比例 |
| Churn | 流失率 | 客户/订阅停止使用或续约的比例 |
| Claim Denial Rate | 拒赔率 | 理赔被拒绝的比例，医疗收入循环关键指标 |
| Clickstream | 点击流 | 用户在站内的点击行为序列数据 |
| Clinical Decision Support | 临床决策支持 | 辅助医护人员决策的系统类别，与直接临床决策风险等级不同 |
| Consent | 数据授权 | 用户对数据特定用途的明确同意 |
| Control Path | 控制路径 | 直接影响物理设备运行的执行链路，AI 不应直接进入 |
| Cycle Time | 周期时间 | 完成单个生产单元的耗时 |
| Default Rate | 违约率 | 贷款未能按约偿还的比例 |
| Demand Forecasting | 需求预测 | 预测未来需求以优化库存与补货 |
| Device Identity | 设备身份 | 绑定到物理设备的身份标识，OT 安全基础 |
| Expansion | 增购扩展 | SaaS 中扩大现有客户价值（更多席位/用量/模块） |
| Explainability | 可解释性 | 模型结果可被解释和追溯的程度，金融/医疗强要求 |
| Field Service | 现场服务 | 到现场（设备/设施侧）执行的安装、维修类服务 |
| Fulfillment | 履约 | 从下单到交付的执行过程 |
| Genealogy | 产品谱系 | 制造中批次与序列号的父子关系追溯链，MES 核心能力之一 |
| Gross Margin | 毛利率 | 收入扣除商品成本后的利润率 |
| Historian | 工业历史数据库 | 高频保存工业时序数据的专用数据库 |
| Inventory Turnover | 库存周转率 | 库存被销售和补充的速度 |
| Length of Stay | 住院时长 | 患者单次住院天数 |
| Lifetime Value / LTV | 客户终身价值 | 客户全生命周期贡献的价值 |
| Material Lot / Batch | 物料批次 | 同一批次物料的制造追踪单元 |
| Merchandising | 商品企划 | 决定卖什么商品、如何定价与陈列的职能 |
| Minimum Necessary Access | 最小必要访问 | 仅访问完成当前任务所需最少患者数据的隐私原则 |
| Model Governance | 模型治理 | 对模型开发、验证、监控与使用的组织化管控 |
| Net Interest Margin | 净息差 | 银行利息收入与成本之差占生息资产的比率 |
| No-show Rate | 爽约率 | 患者预约未到的比例 |
| Non-conformance | 不合格品 | 不符合质量标准的产品或流程偏差，QMS 核心对象 |
| Onboarding | 入驻/开户 | 新客户从签约到正常使用的启动过程 |
| Outage | 停运 | 电力/公用事业的供中断事件 |
| Payer | 支付方 | 医疗体系中承担费用的保险方或机构 |
| Pipeline | 销售管道 | 各阶段商机的集合与金额 |
| Prior Authorization | 事先授权 | 治疗或用药前需获得支付方批准的流程 |
| Readmission | 再入院率 | 患者出院后短期内再次入院的比例 |
| Renewal | 续约 | 订阅到期后的再次购买 |
| Revenue Cycle | 收入循环 | 医疗从就诊到收款的全流程 |
| Scrap Rate | 报废率 | 因缺陷报废的比例 |
| Segregation of Duties | 职责分离 | 关键操作由不同角色分权执行的内控原则 |
| Shop Floor | 车间现场 | 工厂生产执行的一线环境 |
| Stockout Rate | 缺货率 | 有需求但无库存可售的比例 |
| Traceability | 可追溯性 | 制造语境：产品与批次全程可追踪，MES 核心能力 |
| Underwriting | 核保/承保 | 评估并决定是否承接贷款或保险风险 |
| Win Rate | 赢单率 | 商机最终成交的比例 |
| Work Center | 工作中心 | MES 中承担具体生产活动的资源单元 |
| Work Order | 维修工单 | 设备维护任务的派工与记录单元（区别于客服 Ticket） |
| Yield | 良率 | 合格产出占总产出的比例 |
| Zero-result Rate | 零结果率 | 搜索返回空结果的比例，零售搜索健康度指标 |
13. 解决方案模式（Solution Patterns，解决方案模式）
Section titled “13. 解决方案模式（Solution Patterns，解决方案模式）”| 英文 | 中文 | 说明 |
|---|---|---|
| Approval Automation Pattern | 审批自动化模式 | 数据校验 + 风险分级 + 策略规则分流：低风险自动批、中风险人工审、高风险专家审；AI 只做抽取/分类/建议，策略独立控制 |
| Business Signals | 业务信号 | 客户描述问题时常用的原话特征（如「我们想做企业 ChatGPT」），用于识别适用的 Solution Pattern |
| Case Investigation Pattern | 案件调查模式 | 欺诈/反洗钱/理赔等多系统证据调查：AI 做摘要、时间线与建议，人做定性决策；系统必须区分事实/证据/推论/建议/决策 |
| Customer 360 Pattern | 客户 360 模式 | 跨系统统一客户视图：标准化→实体识别→规范化客户→血缘→服务层；核心是数据建模与治理而非 AI |
| Customization Canvas | 定制画布 | 模式定制的 15 字段画布（模式/客户/用户/现状与目标流程/价值/数据/系统/AI 与人工角色/风险/变体/试点/指标/运营责任人） |
| Document Processing Pattern | 文档处理模式 | PDF/表单/发票的解析→分类→AI 抽取→双重校验→按风险置信度分流人工的自动化；算术与规则交给确定性逻辑 |
| Enterprise AI Search Pattern | 企业 AI 搜索模式 | 跨系统统一检索（关键词/语义/元数据/排序 + 权限过滤），摘要可选；有时搜索结果本身比生成答案更可靠 |
| Field Technician Copilot Pattern | 现场技师副手模式 | 设备排障知识助手：汇集资产历史/告警/传感器/手册给出排障指引；AI 建议但技师对安全与维修决策负责 |
| Golden Questions | 黄金问题集 | 试点前收集的最有代表性问题集合，用于原型验证与评估，避免只测演示问题 |
| Hammer Looking for Nail | 拿着锤子找钉子 | 反模式：团队已有某个 Pattern 后把所有客户问题都套进它；Pattern 是起始假设不是预设答案 |
| Internal Operations Copilot Pattern | 内部运营副手模式 | 财务/人力/采购/IT/收入运营的多系统请求处理：人工操作员 + 上下文 + AI + 受控工具，从只读逐步演进到低风险自动化 |
| Knowledge Assistant Pattern | 知识助手模式 | 员工快速找到可信内部知识答案：企业搜索 + RAG + 权限感知检索 + 引用，事务型问题路由到 API |
| Pattern + Variants | 模式加变体 | 问题签名、架构与交付路径高度相似的两个模式应合并为一个 Pattern 加多个 Variants（变体） |
| Pattern Composition | 模式组合 | 真实项目组合多个 Solution Pattern 的方式：当前痛点 → 最小模式 → 验证 → 扩展；每个模式须有明确业务 Owner |
| Pattern Customization | 模式定制 | Reference Pattern（参考模式）不能直接复制，须过六层定制：用户/工作流/数据/系统/风险/运营模型 |
| Pattern Economics | 模式经济学 | 用到原型/试点/生产时间、工程工时、定制代码比例、可复用组件比例衡量模式的交付成本收益 |
| Pattern Evidence Model | 模式证据模型 | 一个项目成功不等于 Pattern：需积累案例/架构/业务/交付/失败五类重复证据 |
| Pattern Lifecycle | 模式生命周期 | 现场观察 → 重复案例 → 模式假设 → 成文 → 跨项目验证 → 标准化 → 工具化 → 产品化 → 监控 → 演进/废弃 |
| Pattern Library Governance | 模式库治理 | 每个模式必须有 Owner/状态/版本/证据/最近评审/关联架构与案例；明确何时合并、何时拆分 |
| Pattern Maturity Model | 模式成熟度模型 | Hypothesis（假设）→ Documented（已成文）→ Repeated（已重复）→ Standardized（已标准化）→ Productized（已产品化）五级 |
| Pattern Owner | 模式责任人 | 对某个 Solution Pattern 的维护、评审与演进负责的人或团队 |
| Premature Productization | 过早产品化 | 反模式：模式只在一个客户出现就建设大型平台；应先验证是否真的重复 |
| Problem Signature | 问题签名 | 什么样的客户问题通常符合这个 Pattern 的结构化描述，模式匹配的首要判断依据 |
| Reuse Ratio | 复用率 | 可复用组件 / 方案总组件；不必追求 100%，高价值项目仍会有客户特定部分 |
| Sales Copilot Pattern | 销售副手模式 | 减少销售行政工作：会前简报 + 会议纪要 + CRM 更新建议；必须嵌入 CRM 既有工作流而非独立门户 |
| Solution Pattern Flywheel | 解决方案模式飞轮 | 客户项目 → 案例 → 重复洞察 → 模式 → 参考架构 → 手册 → 工具 → 更快交付 → 更多证据 → 更好的模式 |
| Support Agent Pattern | 客服智能体模式 | 降低客服处理时长：从坐席辅助起步（意图分类 + 上下文检索 + 建议方案 + 策略检查 + 人工审核），逐步扩大自动化边界 |
| Value Hypothesis | 价值假设 | 该模式中价值从哪里产生的明确假设（如更少搜索时间 + 更少重复提问） |
14. 项目操作系统（Project OS，项目操作系统）
Section titled “14. 项目操作系统（Project OS，项目操作系统）”| 英文 | 中文 | 说明 |
|---|---|---|
| Architecture Registry | 架构登记 | 记录项目当前架构及其演进：五类图 + 版本化 + 模式关联 + 关键依赖 + 架构待解问题 |
| Architecture Versioning | 架构版本化 | 按阶段给架构打版本（ARCH-v0.1 原型 / v0.2 试点 / v1.0 生产） |
| Assumption Registry | 假设登记 | 轻量登记假设内容/重要性/置信度/验证方法/责任人；FDE 大量失败源于假设被当成事实 |
| Closeout Package | 收尾包 | 项目收尾的完整交付集：业务/技术/交付/运营/学习五部分；最终必须回答「解决了原来的问题吗」 |
| Contingency | 应急预案 | 风险触发后的备用应对方案，与缓解措施（事前降低概率/影响）互补 |
| Customer Context Registry | 客户上下文登记 | 稳定维护客户业务背景/组织/干系人/系统与数据全景/约束，成为客户级组织记忆 |
| Dashboard Theater | 看板表演 | 反模式：首页全绿但关键决策根本没做 |
| Data Landscape | 数据全景 | 数据来源/责任人/新鲜度/敏感性/访问方式的登记表 |
| Decision Aging | 决策老化 | 记录需要决策的时间/截止/延迟影响/责任人；关键决策长期未决应进入项目健康评估 |
| Decision Debt | 决策债 | 重要决定一直没人做所累积的项目风险，如 Source of Truth 未定、生产支持无人负责 |
| Decision Record | 决策记录 | 决策/背景/备选/驱动因素/权衡/重评条件/批准人的结构化记录 |
| Decision Status | 决策状态 | Proposed（提议）/ Accepted（已接受）/ Superseded（已被取代）/ Reversed（已推翻） |
| Dependency Criticality | 依赖关键性 | Critical Path / Important / Non-blocking 三级，避免被低价值事项分散注意力 |
| Dependency Health | 依赖健康 | 依赖五状态：Not Started / In Progress / At Risk / Blocked / Complete |
| Delivery Tracker | 交付跟踪 | 统一管理调研到规模化七阶段 + 阶段记录/里程碑/依赖/行动四类跟踪 |
| Documentation Graveyard | 文档坟场 | 反模式：项目开始创建很多页面，此后没人更新 |
| Evidence Before Opinion | 证据先于观点 | 任何主张须附证据；写「17/20 用户本周使用超两次」而非「用户很喜欢」 |
| Evidence-based Progress | 基于证据的进展 | 用「不确定性减少了什么」描述进展，而非「做了什么」的活动清单（Activity-based） |
| Experiment Registry | 实验登记 | 显式记录 Unknown → Hypothesis → Experiment → Evidence → Decision 闭环 |
| Fact / Assumption / Hypothesis / Decision | 事实/假设/待验证/决策分层 | Project OS 必须区分的四类信息，混在一起是项目失败的主要来源 |
| Gate Decision | 门禁决策 | 阶段门禁的统一结论：GO / GO WITH CONDITIONS / REWORK / STOP |
| Incident Registry | 事件登记 | 生产事件登记表：严重度/起止时间/影响/责任人/缓解/根因/纠正措施/事后复盘 |
| Infinite Open Items | 无限未决项 | 反模式：大量风险/问题/行动永远未决；应定期 Close / Escalate / Accept / Drop |
| Issue Registry | 问题登记 | 已发生问题的登记表：严重度/责任人/缓解/根因状态/目标解决时间 |
| Knowledge Promotion | 知识晋升 | 重要经验回填 Case Study / Pattern / Field Guide / Playbook / Toolkit / Architecture，形成项目与知识库的反馈闭环 |
| Known Issues | 已知问题 | 生产系统已接受的问题：影响/临时规避/责任人/优先级/计划修复 |
| Minimum Useful Documentation | 最小有用文档 | 只维护能支持决策、交付、运营和学习的工件，Project OS 不制造文档负担 |
| Operating Cadence | 运营节奏 | 每日阻塞处理 + 每周项目评审 + 每周客户同步 + 阶段门禁评审 + 月/季度价值评审 |
| Primary Use Case | 主用例 | 项目主线用例，与 Secondary / Backlog / Out of Scope 明确区分 |
| Problem Registry | 问题登记 | 标准字段：用户/现状工作流/痛点/根因/业务影响/证据/责任人/状态 |
| Project Health Model | 项目健康模型 | 七维：业务/范围/交付/工程/客户/风险/价值；总体状态不是简单平均，关键红可定全局红 |
| Project ID System | 项目编号体系 | PRJ/PROB/UC/ADR/RISK/ISS/EXP/EVAL/INC/LESSON 前缀统一编号，让跨表引用可靠 |
| Project OS Core Model | 项目操作系统核心模型 | 十个核心对象（客户/问题/用例/架构/决策/风险/实验/交付/运营/价值）及主链关系 |
| Project OS Maturity Model | 项目操作系统成熟度模型 | Personal Notes → Standard Workspace → Evidence-driven → Team OS → Instrumented 五级 |
| Project State Machine | 项目状态机 | Opportunity → … → Closed 状态链 + Paused/Blocked/Stopped 特殊状态 |
| Registry | 登记表 | 一类对象（问题/决策/风险/实验等）的统一结构化登记，条目元数据遵循登记记录通用模板 |
| Service Ownership | 服务归属 | 生产上线后明确业务/技术/运营/安全/数据五类责任人 |
| Single Source of Project Truth | 项目唯一事实来源 | 关键信息不散落于聊天/邮件/会议纪要/个人笔记，统一在 Project OS 中回答「当前项目事实是什么」 |
| Stage Gate System | 阶段门禁系统 | 六道门禁（调研→界定→设计→原型→试点→生产→规模化），每道门禁明确证据与门禁决策 |
| State Transition Rule | 状态转换规则 | 任何项目状态转换都需 Evidence + Gate Decision，不能靠「大家觉得差不多了」 |
| Traceability Model | 端到端追溯模型 | 问题 → 用例 → 需求 → 架构 → 决策 → 实现 → 评估 → 指标 → 业务结果全链可追 |
| Unknowns Registry | 未知项登记 | 未知项/重要性/责任人/解决方式/截止时间，适合早期调研与架构阶段 |
| Use Case Registry | 用例登记 | 用例标准字段（目标用户/触发/目标工作流/价值/风险/基线/状态） |
| Use Case Status | 用例状态 | Idea / Discovery / Prioritized / Scoped / Prototype / Pilot / Production / Scaled / Paused / Stopped |
| Value Status | 价值状态 | Unproven / Early Signal / Validated / Scaling / At Risk / Not Realized |
| Value Tracker | 价值跟踪 | 持续追踪业务价值：基线/目标/机制/测量方法 + 价值看板 + 定期五选一决策 |
| Weekly Operating Review | 每周运营评审 | 30–60 分钟按序检视健康/里程碑/风险/问题/实验/决策/行动，区别于普通状态会议 |
| Workspace Overview | 工作区总览 | 工作区顶部速答：阶段/健康度/主要问题/主用例/下一里程碑/下一门禁/前三大风险/所需决策 |
15. 知识治理与 v1.0 加固（Governance & Hardening）
Section titled “15. 知识治理与 v1.0 加固（Governance & Hardening）”| 英文 | 中文 | 说明 |
|---|---|---|
| Activation Guide | 激活指南 | 项目起步包的十步启用顺序（创建工作空间→填总览章程→干系人→问题→风险→决策日志→调研→用例→架构实验→按需激活试点/生产模块） |
| Authoring Template | 创作模板 | 用于编写知识条目本身（概念/操作指南/手册/案例/行业/现场指南/模式）的模板，区别于产出项目工件的 Canonical Template |
| Canonical Page | 权威页面 | 同一概念只在一个页面写透的唯一定义来源；高度重复的新页面应降级为 Primer（入门页）+ 交叉链接，原理只写一次 |
| Canonical Template | 规范模板 | 每种核心项目工件唯一保留的权威模板（编号 CT-001~018），六原则：一工件一模板/默认最小化/元数据标准化/必填可选清晰/有输出目的/可组合 |
| Canonical Template Catalog | 规范模板目录 | 18 个规范模板的四组目录（调研与业务/架构与工程/交付/项目操作系统），含旧模板迁移去向 |
| Cross-link | 交叉链接 | 知识条目间按 15 种标准链接类型（前置/概念/决策/架构/工程/交付/手册/速查/行业/案例/模式/工具/模板/排查/项目 OS）建立的连接 |
| Cross-link Hub | 交叉链接枢纽 | 三张核心导航图：业务问题→执行、架构决策→验证、生产问题→学习 |
| Cross-module Contract | 跨模块契约 | v1.0 对十四个一级模块各自职责的明确定义，避免重叠 |
| DEPRECATE | 废弃（占位结论） | 空占位处理结论之一：不再值得作为独立知识条目存在，按废弃标准处理 |
| Deprecation Standard | 废弃标准 | 不直接删除旧知识，标记 Status/Reason/Deprecated By/Effective Date 后保留历史 |
| Empty Placeholder | 空占位 | 已建立目录但没有任何内容解释的知识节点；v1.0 不允许 Core 域存在无解释的空占位 |
| Empty Placeholder Resolution | 空占位清理决策 | 对 32 个空占位（Fundamentals 9 + Engineering 23）逐一给出 WRITE / FIELD PRIMER / MERGE / DEPRECATE 结论的 v1.0 收尾决策：16 核心页 + 14 入门页 + 2 权威合并 |
| Enterprise Field Primer | 企业环境入门页 | 帮助 FDE 在真实企业环境中快速识别系统角色、数据所有权、集成方式、常见约束、失败模式与该找谁（ERP/CRM/MES/三大云/数仓/湖/Kafka 十篇即为此类） |
| FDE Depth Level | FDE 深度分级 | Level A Recognize（认知）→ Level B Operate（操作）→ Level C Design（设计）→ Level D Specialist（专家）；FDE 默认不需要 Level D |
| FDE OS Golden Path | FDE OS 黄金路径 | 新项目默认 20 步运营路径：创建工作空间→采集上下文→调研→验证问题→定义用例→排序→选模式→组合架构→记 ADR→实验→原型→门禁→试点→度量→生产就绪→上线→运营→价值评审→沉淀经验→更新知识 |
| FIELD PRIMER | 领域入门页（占位结论） | 空占位处理结论之一：保留独立页面但只写 FDE 必需深度，明确深度边界，不演化成技术百科 |
| Full Project OS | 完整项目操作系统 | 复杂企业项目启用的全部十五类登记表与跟踪器，与最小可用项目操作系统对应 |
| Gold Standard Reference Project | 黄金标准参考项目 | 完整展示项目全貌 + 维护的 OS 工件 + 决策 + 证据 + 知识复用的参考项目（首个：企业知识助手），当作整个系统的集成测试 |
| Knowledge Contribution Flow | 知识贡献流程 | 现场观察→证据→经验→提案→评审→核心知识更新；防止「有趣想法→立即建新目录」 |
| Knowledge Graph | 知识图谱 | v1.0 目标形态：从依赖目录浏览的树变成从任何问题都能沿关联走到下一步行动的图 |
| Knowledge Maturity | 知识成熟度 | 与状态分开的五级：M0 Hypothesis（假设）→ M1 Documented（成文）→ M2 Applied（已应用）→ M3 Repeated（已重复）→ M4 Standardized（已标准化） |
| Knowledge Metadata Standard | 知识元数据标准 | 核心知识页统一元数据：编号/类型/域/成熟度/状态/版本/责任人/最近评审/前置/关联/被谁使用/证据 |
| Knowledge Review Cadence | 知识评审节奏 | 每季度评审手册/模式/工具/模板，每半年评审架构/工程/行业，重大事件驱动即时更新 |
| MERGE / REDIRECT | 合并/重定向（占位结论） | 空占位处理结论之一：并入已有 Canonical（权威）页面并新增小节，不另立独立页面 |
| Minimum Viable Project OS | 最小可用项目操作系统 | 小型项目最低维护的七件套：总览/问题用例/架构/决策日志/风险登记/评估证据/价值指标 |
| Navigation Block | 导航块 | 核心页面底部的统一导航模板（前置/下一步/决策指南/手册/工具/模式/案例/排查/项目 OS），降低知识碎片化 |
| Post-v1 Growth Principles | v1 后成长原则 | 不再以页面数量衡量成熟度，改用项目复用/决策质量/交付速度/生产成功/业务价值/知识复用；新内容优先级以重复现场问题为最高 |
| Project Starter Pack | 项目起步包 | 新项目直接复制的 17 文件工作空间（00 总览~16 收尾），文件分立即可用/稍后激活/可选三态，按阶段启用 |
| Quality Gate (v1.0) | v1.0 质量门禁 | 标记 v1.0 前的结构/模板/交叉链接/项目 OS/参考项目/治理六类检查清单，完成定义是五个使用场景可顺畅完成 |
| Reference Project Package | 参考项目包 | 黄金标准参考项目的完整文件包（20 个登记文件 + README + 追溯图），置于 06 Case Studies/Reference-Projects 之下以免新增一级目录 |
| Technology Page Standard | 技术条目标准结构 | 技术类条目统一结构：What It Is / Why FDE Cares / Where It Appears / Key Concepts / FDE Decisions / Common Failure Modes / Questions to Ask / How Deep Should an FDE Go / Related Knowledge，防止演化成百科 |
| Template Migration Map | 模板迁移映射 | 现有 33 个模板到 18 个规范模板/创作模板/专用模板的去向对照表 |
| WRITE | 写入独立核心页（占位结论） | 空占位处理结论之一：值得成为真正的独立核心知识页面 |
- 新增术语：新文章引入新英文术语时，在对应分类表中按字母序插入一行。
- 标注规范：文章内首次出现使用「English（中文）」，再次出现可直接使用英文。
- 一词多义：如 Production（生产环境/定稿状态），在说明中明确区分语境。
- 缩略语：新缩略语需同时补入第 0 节速查表。