01
I. Executive Summary: The Core of Enterprise AI is Trustworthy Business Execution, Not Models
一、总纲：企业级 AI 的核心不是模型，而是可信业务执行
The essence of enterprise AI adoption in B2B environments is not the piecemeal stacking of models, Retrieval-Augmented Generation (RAG), Agents, vector databases, and automation tools.AI 真正落地到企业，关键不在于把模型、RAG、Agent、向量数据库和自动化工具逐个堆上去，
Rather, it is the establishment of a business execution system that an enterprise can accept, verify, and continuously operate.而在于建立一套企业愿意采用、能够验证、也能长期维护的业务执行体系。
LLMs excel at understanding natural language, extracting implicit rules, summarizing knowledge, generating proposals, and aiding inference.大模型擅长理解自然语言、提取隐性规则、归纳知识、生成方案和辅助推理，
However, their outputs are inherently probabilistic and cannot naturally satisfy enterprise requirements for result consistency, business compliance, liability traceability, and operational safety.但其输出具有概率性，无法天然满足企业对结果一致性、业务合规性、责任可追溯性和生产安全性的要求。
Consequently, enterprise AI systems must adhere to a foundational principle:因此，企业级 AI 系统必须遵循一个基本原则：
Constrain probabilistic LLMs to cognitive stages — such as demand understanding, knowledge extraction, process recommendation, proposal generation, and anomaly explanation — while delegating execution authority with real-world business impact to a versioned, strongly typed, and auditable deterministic runtime.将概率性大模型限制在需求理解、知识抽取、流程建议、方案生成和异常解释等认知环节；将具有业务效力的执行权交给版本化、强类型、可审计的确定性运行时。
What an enterprise truly purchases is neither a chatbot nor an isolated software tool, but rather: a governed, evidence-backed business execution capability — one that can be audited by their finance department, accepted by their legal team, and trusted by their operations staff.企业真正购买的并不是一个聊天机器人，也不是一套孤立的软件工具，而是：一套受治理的、有证据支撑的业务执行能力——一套能够被财务部门审计、被法务团队接受、并被运维人员信任的体系。
The core mandate of an FDE is to translate vague, implicit, and unstructured business problems within an enterprise into digitized systems that are modelable, executable, verifiable, operable, and replicable.FDE 的核心职责，就是把企业中模糊、隐性、非结构化的业务问题，转化为可建模、可执行、可验证、可运营和可复制的数字化系统。
02
II. Role Positioning of an FDE: Bridging Business Reality and Engineering Systems
二、FDE 的角色定位：连接业务现实与工程系统
A Forward Deployment Engineer (FDE) should not be narrowly understood as an on-site developer, a systems integration engineer, or a senior pre-sales consultant.FDE，即前线部署工程师，不应被狭隘地理解为驻场开发人员、系统集成工程师或高级售前。
The core value of an FDE lies in taking end-to-end responsibility — from problem discovery to the verification of business outcomes — within the customer's actual business environment.FDE 的核心价值，是在客户真实业务环境中承担从问题发现到业务结果验证的端到端责任。
The scope of work encompasses:其工作范围包括：
Business problem discovery and structured problem decomposition业务问题发现与结构化问题拆解
Quantitative value baseline establishment and ROI modeling量化价值基线建立与 ROI 建模
System architecture design across data, cognitive, execution, and assurance planes横跨数据、认知、执行与保证平面的系统架构设计
Integration specification with client data systems, APIs, and operational technology与客户数据系统、API 及工业操作技术（OT）的集成规范设定
Development governance using synthetic data and code-first operator libraries使用合成数据与代码优先算子库的开发治理
Staged deployment, PoV validation, and acceptance evidence generation分阶段部署、PoV 验证与验收证据生成
Post-delivery asset extraction into reusable platform components交付后的资产抽取并沉淀为可复用的平台组件
Ongoing operational handoff, SLA definition, and escalation path design持续运维交接、SLA 定义与升级路径设计
An FDE must simultaneously grasp seven dimensions:FDE 必须同时理解七个维度：
Business Dimension: How the client makes decisions, collaborates, and generates revenue or incurs costs.业务维度： 客户如何决策、如何协作、如何产生收入与成本。
Technical Dimension: How data, interfaces, software, hardware/equipment, algorithms, and infrastructure work in concert.技术维度： 数据、接口、软件、设备、算法和基础设施如何协同。
Financial Dimension: How the project yields Return on Investment (ROI), and how costs and benefits are calculated.财务维度： 项目如何产生 ROI，成本和收益如何计算。
Commercial Dimension: How the project is priced, delivered in phases, and structured for recurring revenue.商务维度： 项目如何报价、分阶段交付和形成持续收入。
Legal Dimension: How data rights, intellectual property (IP), liability boundaries, and acceptance obligations are defined.法务维度： 数据、知识产权、责任边界和验收义务如何约定。
Risk Control Dimension: Which actions can be executed automatically, which require manual approval, and which must be strictly forbidden.风控维度： 哪些操作可以自动执行，哪些必须审批，哪些必须禁止。
Temporal Dimension: How the system's accuracy, rule coverage, and model fitness decay over time; how it detects and signals when it needs recalibration. This matters because enterprises sign multi-year contracts. A system that was accurate at delivery can become hazardous as business rules evolve.时间维度：系统的准确率、规则覆盖率和模型适配度会怎样随时间变化；接近重新校准条件时，系统如何检测并预警。这一点不能省略：企业签的是多年合同，业务规则一变，交付时准确的系统也可能变成风险来源。
The essence of an FDE is not to "write a bit more code for the client," but rather to:FDE 的本质不是“为客户多写一些代码”，而是：
Transform non-standard enterprise business problems into standardized, modular, and reusable industry execution capabilities.将企业非标业务问题转化为标准化、模块化、可复用的行业执行能力。
03
III. Underlying Commercial Logic of B2B AI Adoption
三、B2B AI 落地的底层商业逻辑
3.1
3.1 Enterprises Purchase Business Outcomes, Not AI Tools
3.1 企业购买的是业务结果，而不是 AI 工具
Corporate investments follow strict capital allocation and loss-prevention logics. Key concerns include:企业采购 AI 服务通常遵循严格的资本配置与止损逻辑，核心关注点包括：
Whether it increases revenue是否能够提升收入
Whether it reduces costs是否能够降低成本
Whether it minimizes operational errors是否能够减少操作错误
Whether it improves asset utilization是否能够提高资产利用率
Whether it shortens business cycle times是否能够缩短业务周期
Whether it mitigates safety, compliance, and operational risks是否能够降低安全、合规与经营风险
Who bears liability when issues arise出现问题时由谁负责
Whether the system is sustainably maintainable系统是否可以持续维护
Therefore, an FDE project must not set "deploying an LLM," "building a knowledge base," or "introducing Agents" as its ultimate goal.因此，FDE 项目不能仅以“部署大模型”“建设知识库”“引入 Agent”为最终目标。
Every project must establish an explicit Business Value Chain:每个项目都必须建立明确的业务价值链：
Example 1:示例 1：
中文流程
Central Cooling Plant Optimization Recommendations → O&M staff adjust chiller combination settings → Energy consumption per unit of cooling decreases → Annual electricity cost declines. 冷站运行优化建议 → 运维人员调整机组组合 → 单位冷量能耗下降 → 年度电费降低。
Example 2:示例 2：
中文流程
Intelligent Bid Requirement Extraction → Reduction in human oversight and redundant cross-checking → Bidding cycle time shortened and pricing errors minimized → Increased bidding efficiency and controllable gross margins. 智能投标需求提取 → 减少人工漏项与重复核对 → 缩短投标周期并降低报价错误 → 提高投标效率和项目毛利可控性。
3.2
3.2 Risk Cannot Be Completely Transferred; It Can Only Be Identified, Allocated, and Encapsulated
3.2 风险不能完全转移，只能被识别、分配和封装
Project outcomes in enterprise environments are governed by multiple parties.企业项目结果通常由多方共同决定。
Clients are responsible for raw data quality, physical equipment conditions, operational execution, and organizational coordination. FDEs are responsible for system architecture, software quality, algorithmic implementation, and the delivery process. Shared risks must be managed jointly.客户需要对原始数据质量、设备条件、业务执行和组织协调负责；FDE 需要对系统架构、软件质量、算法实现和交付过程负责；共享风险则必须共同管理。
The liability mechanism for enterprise AI projects should adopt a three-tier shared risk matrix:企业级 AI 项目的责任机制应采用三层共享风险矩阵：
| English source | 中文原文 |
|---|---|
| FDE-Owned FDE Team System architecture, software defects, operator logic errors, deployment failures | FDE 归属 FDE 团队 系统架构、软件缺陷、算子逻辑错误、部署失败 |
| Client-Owned Client Organization Source data quality, operational execution, organizational adoption, physical environment | 客户归属 客户组织 源数据质量、业务执行、组织推广采用、物理环境 |
| Joint / Force Majeure Negotiated Third-party API outages, regulatory changes, underlying model provider policy changes | 共同/不可抗力 协商确定 第三方 API 中断、监管政策变更、底层模型厂商策略调整 |
This matrix must be embedded directly into contract language — not left as a verbal understanding.该矩阵必须直接嵌入合同条款中——而不能仅停留在口头谅解层面。
FDEs must not guarantee absolute outcomes beyond their control. Instead, they must commit to:FDE 不应承诺无法控制的绝对结果，而应承诺：
Verifiable processes过程可验证
Traceable outputs输出可追踪
Rollbackable systems系统可回滚
Detectable anomalies异常可发现
Clear liability boundaries责任边界明确
Acceptance-ready functionality and metrics within agreed scopes已约定范围内的功能和指标可验收
3.3
3.3 The Commercial Opportunity for FDEs Lies in the Industry Execution Layer
3.3 FDE 的商业机会来自行业执行层
Foundational model providers rely on standardized, scalable, high-gross-margin Software-as-a-Service (SaaS) business models. They are ill-suited to absorb heavy, non-standard enterprise integration, on-site deployment, and localized business liability over the long term.底层模型厂商主要依靠标准化、规模化和高毛利的 SaaS 软件服务模式，不适合长期承担大量企业非标集成、现场交付和本地业务责任。
This opens a critical strategic window for FDEs.这为 FDE 留出了关键的战略窗口期。
However, FDEs must avoid lingering in the space of "labor-intensive services that model vendors shun," lest they fall into the trap of low-margin, hard-to-replicate traditional systems integration.但 FDE 不能停留在“模型厂商不愿做的重服务”层面，否则仍会陷入低毛利、难复制的传统系统集成陷阱。
A true FDE competitive moat is constructed from four compounding assets:真正的 FDE 竞争护城河由以下四类复合资产构成：
Operator Libraries — versioned, tested, certified business logic units that competitors cannot quickly replicate算子库——版本化、经过测试和认证的业务逻辑单元，竞争对手无法快速复制
Industry-Specific Synthetic Data Sets — enabling safe development without client data access行业专属合成数据集——允许在不接触客户真实数据的前提下进行安全开发
Domain-Specific Evaluation Benchmarks — "golden test sets" that prove system quality in ways generic benchmarks cannot特定领域评测基准——用通用基准覆盖不到的业务样本，证明系统质量的“黄金测试集”
Evidence Package Templates — pre-negotiated audit artifact formats that satisfy client legal, compliance, and finance requirements证据包模板——预先协商好的审计制品格式，满足客户法务、合规和财务的要求
04
IV. Enterprise Knowledge Deconstruction: From Tacit Expertise to Executable Assets
四、企业知识解构：从默会经验到可执行资产
A significant portion of an enterprise's core capabilities does not reside in formal documentation, but is dispersed across employee experience, historical project records, spreadsheets, oral judgments, ad-hoc exception handling, and informal organizational dynamics.企业的大量核心能力并不存在于正式制度文件中，而分散在员工经验、历史项目记录、Excel、口头判断、临时异常处理和非正式组织协作关系中。
Enterprise knowledge is generally categorized into five types:企业知识通常可以分为五类：
| English source | 中文原文 |
|---|---|
| Explicit Rules Policies, standards, contracts, SOPs, technical specifications | 显性规则 制度、标准、合同、SOP、技术规范 |
| Data Rules Spreadsheet formulas, database logic, reporting metrics definitions | 数据规则 Excel公式、数据库逻辑、报表口径 |
| Behavioral Rules System operation logs, business process logs | 行为规则 系统操作记录、业务流程日志 |
| Decision Expertise Expert judgment, historical case studies, exception resolution records | 决策经验 专家判断、历史案例、异常处置记录 |
| Organizational Power Approval authorities, veto powers, accountability attributions | 组织权力 审批权限、否决权、责任归属 |
Knowledge deconstruction cannot rely solely on document parsing or employee interviews; it must encompass:因此，知识解构不能只依赖文档解析或员工访谈，还应包括：
Structured interviews with domain experts, using pre-defined question protocols to surface tacit heuristics与领域专家进行结构化访谈，使用预定义的提问协议引导出隐性启发式规则
Process shadowing — observing actual work, not just described work; the gap between the two is where the most valuable tacit rules live跟岗观察——记录真实操作过程，而不只听口头描述；实际做法与口述之间的差距，往往藏着最有价值的隐性规则
Log and workflow archaeology — mining historical system logs, approval trails, and exception records to reconstruct actual decision patterns日志与工作流考古——挖掘历史系统日志、审批轨迹和异常记录，重构真实的决策模式
Spreadsheet forensics — enterprise spreadsheets are often the most honest representation of real business logic; reverse-engineer their formulas and validation rules电子表格取证——企业 Excel 往往比制度文件更接近真实业务逻辑；应对公式和校验规则做逆向工程
Exception case analysis — structured review of historical edge cases, escalations, and override decisions异常案例分析——对历史边缘案例、升级上报和越权/干预决策进行结构化复盘
Comparative scenario elicitation — presenting domain experts with pairs of cases and asking them to explain differential treatment对比情境诱导——向领域专家展示成对的案例，要求其解释为何采取差异化的处理方式
Special attention must be paid to exceptional edge-case paths:项目中尤其需要关注例外/边缘路径：
How to proceed when data is missing数据缺失时如何处理
Priority resolution when multiple rules conflict多条规则冲突时谁优先
Alternative pathways when an approver is offline审批人不在线时如何替代
Whether specific clients enjoy non-standard pricing tiers特殊客户是否存在差异化价格
Which fallback parameters to use during equipment failure设备故障时使用什么替代参数
Who evaluates and assumes liability when results are anomalous结果异常时由谁判断和承担责任
An enterprise's true competitive edge rarely lies in its standard processes, but in its ability to handle complex edge cases.企业真正的竞争优势，往往不在标准流程中，而在对复杂例外情况的处理能力中。
4.1
4.1 Knowledge Decay Management
4.1 知识衰减管理
Enterprise knowledge deconstruction is not a one-time event. A Knowledge Currency Protocol must be established:企业知识解构并非一劳永逸。必须建立一套知识时效性协议（Knowledge Currency Protocol）：
Each extracted rule or operator should carry a last_validated timestamp and a designated rule_owner每一条提取出的规则或算子都应带有 last_validated（最后验证）时间戳和指定的 rule_owner（规则责任人）
Periodic re-elicitation sessions (quarterly for high-change domains, annually for stable ones) should be contractually embedded应在合同中明确约定定期重新梳理的机制（高变动领域按季度，稳定领域按年度）
The system should surface alerts when rule usage patterns diverge significantly from historical norms, as this often signals an undocumented business change当规则使用模式与历史基线发生显著偏离时，系统应发出预警，因为这通常预示着发生了未被记录的业务变更
Knowledge decay is a billable maintenance event — it must be named in the contract, not treated as a defect知识衰减属于可计费的维护事件——必须在合同中予以明确，而非被归咎为系统缺陷
05
V. Overall Architecture: Four Planes and One Line of Accountability
五、总体架构：四平面与一条责任主线
Enterprise FDE systems are recommended to adopt a Four-Plane Architecture:企业级 FDE 系统建议采用“四平面架构”：
English flow
┌─────────────────────────────────────────────────────────────────┐ │ I. Data & Knowledge Plane │ │ Data Sources, Documents, Master Data, RAG, ACLs, Lineage │ ├─────────────────────────────────────────────────────────────────┤ │ II. Probabilistic Cognitive Plane │ │ LLMs, Intent Parsing, Extraction, Recommendations, Explanations │ ├─────────────────────────────────────────────────────────────────┤ │ III. Deterministic Execution Plane │ │ State Machines, Operators, Rule Engines, Solvers, Transactions │ ├─────────────────────────────────────────────────────────────────┤ │ IV. Assurance & Evidence Plane │ │ Contracts, Tests, Policies, Audits, Rollback, Acceptance, SLAs │ └─────────────────────────────────────────────────────────────────┘
中文流程
┌─────────────────────────────────────────────────────────────────┐ │ 一、数据与知识平面 │ │ 数据源、文档、主数据、RAG、权限控制列表（ACL）、血缘 │ ├─────────────────────────────────────────────────────────────────┤ │ 二、概率性认知平面 │ │ 大模型、意图解析、抽取、建议、解释 │ ├─────────────────────────────────────────────────────────────────┤ │ 三、确定性执行平面 │ │ 状态机、算子、规则引擎、求解器、事务 │ ├─────────────────────────────────────────────────────────────────┤ │ 四、保证与证据平面 │ │ 契约、测试、策略、审计、回滚、验收、SLA │ └─────────────────────────────────────────────────────────────────┘
Across these four planes, a horizontal Line of Accountability must be enforced:四个平面之上，还必须建立一条横向的责任主线：
| English source | 中文原文 |
|---|---|
| Who can read the data ACL policies in the Data & Knowledge Plane | 谁可以读取数据 数据与知识平面中的 ACL 策略 |
| Who can invoke the cognitive layer Service identity + scoped API keys | 谁可以调用认知层 服务身份认证 + 受限 API 密钥 |
| Who can generate proposals Role-based operator permissions | 谁可以生成方案 基于角色的算子权限 |
| Who can modify configurations Change management workflow with audit trail | 谁可以修改配置 带有审计追踪的变更管理工作流 |
| Who can issue final quotes Human approval gate (Level D operator) | 谁可以发布最终报价 人工审批节点（D 类算子） |
| Who can execute physical production operations Safety interlock authorization (Level E; never LLM-initiated) | 谁可以执行物理生产操作 安全联锁授权（E 类算子；严禁由大模型直接触发） |
| Who bears ultimate business outcome responsibility Designated human role, documented in SLA | 谁对最终业务结果负责 在 SLA 中记录的指定责任人角色 |
Critically, accountability must be bound to identities, not just roles. When an exception occurs, the audit trail must resolve to a specific named individual or system principal — not merely a generic role label.至关重要的是，责任必须绑定到具体身份，而不仅仅是角色。当发生异常时，审计追踪必须能追溯到具体的具名个人或系统主体——而非仅仅是一个泛化的角色标签。
06
VI. Boundaries Between Probabilistic Cognition and Deterministic Execution
六、概率性认知与确定性执行的边界
6.1
6.1 Tasks Suitable for LLMs
6.1 大模型适合承担的任务
LLMs excel at handling:大模型擅长处理：
Natural language requirement understanding自然语言需求理解
Bidding document and contract clause extraction招标文件和合同条款提取
Induction of implicit rules隐性规则归纳
Document classification and summarization文档分类与摘要
Workflow suggestions工作流建议
Directed Acyclic Graph (DAG) configuration draftingDAG（有向无环图）配置草案
Draft generation for new operator code新算子代码草案
Root-cause explanation of operational anomalies运维异常原因解释
Maintenance report synthesis运维报告生成
Multi-scenario trade-off comparisons多方案比较与权衡
6.2
6.2 Tasks LLMs Should NOT Directly Execute
6.2 大模型不应直接承担的任务
LLMs must not directly determine or execute:大模型绝对不能直接决定或执行：
Final price calculations最终价格计算
Financial settlements财务结算
Critical risk ratings关键风险评级
Startup/shutdown of production equipment生产设备启停
Writes to Programmable Logic Controller (PLC) or hardware controller parametersPLC 或控制器参数写入
Safety interlocks and equipment protection logic安全联锁与设备保护逻辑
Formal contract approvals正式合同批准
High-risk business transactions高风险业务交易
Dynamic execution of unverified, arbitrary code动态执行未经验证的任意代码
In industrial optimization scenarios, a proper division of labor is:对于工业优化场景，合理的职责分工是：
English flow
[ LLM ] ──(Understands Intent & Constraints)──> [ Mathematical Solver ] │ (Optimizes Calculations) │ ▼ [ Human Supervisor ] <──(Authorize)── [ Control System (PLC) ]
中文流程
[ 大模型 ] ──(理解意图与约束)──> [ 数学求解器 ] │ (执行优化计算) │ ▼ [ 人工监督 ] <──(授权)── [ 控制系统 (PLC) ]
LLM: Responsible for cognition (understanding requirements, extracting constraints, explaining results).大模型： 负责认知（理解需求、抽取约束、解释结果）。
Solver: Responsible for computation (solving optimizations, enforcing mathematical constraints, outputting verifiable results).求解器： 负责计算（求解优化、执行数学约束、输出可验证结果）。
Control System: Responsible for execution (applying approved setpoints, maintaining safety interlocks).控制系统： 负责执行（应用已批准的设定值、保持安全联锁）。
Human Operator: Responsible for authorization and high-risk decision accountability.人工操作员： 负责授权与高风险决策责任。
07
VII. Security Architecture: Transitioning from Personal Trust to Zero-Trust Engineering
七、安全架构：从人员信任转向零信任工程
7.1
7.1 Structural Contradiction Between Capability and Trust
7.1 能力与信任的结构性矛盾
Enterprises frequently encounter a dilemma between two extreme operational models:企业常见的两种极端模式是：
Internal Trusted Personnel: High commercial trust, but lacking advanced AI and modern data-engineering capabilities.内部可信人员： 商业信任高，但缺少复杂 AI 和数据工程能力。
External Professional Teams: Strong engineering capabilities, but triggering client anxieties over commercial secret leaks and data exposure.外部专业团队： 工程能力强，但客户担忧商业机密泄露与数据暴露。
This challenge cannot be resolved by searching for "intrinsically trustworthy individuals." Instead, the system architecture must be designed to minimize the scope wherein any single individual must be unconditionally trusted.这个问题不是靠寻找“绝对可信的人”解决的，而是靠系统架构把必须信任个人的范围压到最小。
7.2
7.2 Core Security Principles
7.2 基本安全原则
Enterprise FDE projects must enforce:企业级 FDE 项目应遵循：
Verifiable identity身份可验证
Principle of least privilege (PoLP)最小权限原则（PoLP）
On-demand data visibility数据按需可见
Strict isolation between production and development environments生产与开发环境严格隔离
Decoupling of code from credentials/secrets代码与密钥/凭证解耦
Universal auditability of all actions所有操作可审计
Dual-control (four-eyes) approval for high-risk operations高风险操作双人审批（双控机制）
Minimization of model context windows模型上下文窗口最小化
Default prohibition of sensitive data crossing security perimeters/borders敏感数据默认禁止跨越安全边界/出境
7.3
7.3 External Development and Private Enterprise Deployment
7.3 外部开发与企业私域部署
A robust operational model is structured as follows:一种健壮的运行模式架构如下：
External FDE: Develops systems, operators, and interfaces using anonymized and synthetic data.外部 FDE： 使用脱敏数据和合成数据开发系统、算子和接口。
Client Private Domain: Houses live data, secrets, database connection strings, and production configurations.客户私域环境： 保存真实数据、密钥、数据库连接串和生产配置。
Deployment Phase: Real connection setups and final acceptance testing are conducted locally by client personnel or audited deployment teams.部署阶段： 由客户人员或受审计的部署团队在本地完成真实连接配置与最终验收测试。
Synthetic data must not be mere random noise; it must preserve:合成数据不能只是随机噪音，它必须保留：
Structural schema字段结构与 Schema
Statistical distributions数值统计分布
Inter-field correlations字段间关联性
Time-series characteristics时间序列特征
Anomaly ratios异常比例
Boundary conditions边界条件
Valid state transition paths合法的状态转换路径
7.4
7.4 Model Context Egress Gateway
7.4 模型上下文出境网关
When invoking cloud-hosted foundational models is necessary, a Semantic Egress Gateway must be implemented. Every outbound API call must log:如需调用云端高能力模型，必须建立语义出境网关。每一次出境 API 调用都必须留痕记录：
Operator identity操作员身份
Purpose of invocation调用目的
Data classification level数据密级分类
Applied sanitization rules应用的脱敏规则
Target model name目标模型名称
Input prompt digest/hash输入 Prompt 摘要/哈希
Output response digest/hash输出 Response 摘要/哈希
Approval references审批依据
7.5
7.5 Adversarial Input Handling
7.5 对抗性输入处理
In bidding, procurement, and contract scenarios, the LLM routinely processes documents originating from external, potentially adversarial parties — vendor RFQs, client tender packages, competitor-cited specifications.在招投标、采购和合同分析等场景中，大模型经常需要处理来自外部、可能具备对抗性的第三方文档——如供应商询价单、客户招标文件、竞争对手引用的技术规范。
These documents can contain embedded prompt injection payloads: instructions concealed within document text designed to manipulate the LLM's extraction or classification behavior. This is not a theoretical risk — it is an actively exploited attack surface in any system that ingests uncontrolled external documents.这些文档可能藏有 Prompt 注入载荷——把恶意指令埋进文本，诱导大模型改变提取或分类结果。这不是纸上谈兵：系统一旦接入未经控制的外部文档，这个入口就可能被利用。
Mandatory mitigations:必须采取的防御手段：
All externally-sourced documents must pass through a content sanitization layer before LLM ingestion所有外部来源的文档在大模型摄入前，必须通过内容清洗/脱敏层
Extraction outputs from external-document processing must be schema-validated against expected types before entering any deterministic operator外部文档处理的提取结果，在进入任何确定性算子前，必须经过针对预期类型的 Schema 严格校验
The system prompt for external-document processing must explicitly instruct the model to treat all document content as data, never as instruction处理外部文档的系统 Prompt 必须明确指令模型：将所有文档内容仅视为“数据”，绝不视为“指令”
A confidence differential check should flag extractions from external documents that deviate significantly from known-good internal distributions应设置置信度偏差校验，对外部文档提取中显著偏离内部正常分布的数据进行预警标记
Separate audit trails must be maintained for internal-document and external-document LLM invocations必须为内部文档和外部文档的大模型调用建立独立的审计追踪
7.6
7.6 LLM Provider Resilience
7.6 大模型厂商故障韧性
Cloud LLM providers experience outages. When the cognitive layer is unavailable, the deterministic execution plane must continue operating safely. This requires an explicit Cognitive Layer Degradation Policy:云端大模型厂商难免遭遇服务中断。当认知层不可用时，确定性执行平面必须能够继续安全运行。这就要求制定明确的认知层降级策略：
English flow
[ Provider Outage Detected ] │ ├── Mode A: Route to secondary provider (if contractually permitted) │ ├── Mode B: Fall back to on-premises/edge inference (reduced capability) │ ├── Mode C: Suspend cognitive-dependent workflows; continue deterministic-only paths │ └── Mode D: Notify operators; surface manual override interfaces
中文流程
[ 检测到模型服务中断 ] │ ├── 模式 A：路由至备用模型厂商（若合同条款允许） │ ├── 模式 B：降级至本地/边缘端推理（能力有所收缩） │ ├── 模式 C：暂停依赖认知的流程；仅继续纯确定性路径 │ └── 模式 D：通知操作员；弹出人工接管/干预界面
Each workflow in the system must be pre-classified with its minimum viable operation mode — the minimal set of capabilities required to avoid business harm during a cognitive layer outage.系统中的每一个工作流都必须预先指定其最小可行运行模式——即在认知层中断期间，避免造成业务损害所需的最低能力集。
Contracts with clients must explicitly specify which business functions are cognitive-dependent (advisory only) versus deterministic-only (can proceed without LLM). This is a commercial as well as a technical boundary.与客户签署的合同中必须明确划清：哪些业务功能属于“依赖认知”（仅起建议作用），哪些属于“纯确定性”（无需大模型即可继续）。这既是技术边界，也是商务边界。
7.7
7.7 Prompt Versioning and Governance
7.7 Prompt 版本化与治理
System prompts and prompt templates are first-class versioned artifacts — not configuration text managed informally. A prompt change can alter system behavior as significantly as an operator code change, yet most organizations treat them as editable configuration strings.系统 Prompt 和 Prompt 模板必须按核心制品管理，而不能当作随手改的配置文本。Prompt 改动对系统行为的影响不亚于算子代码改动，但很多组织仍把它当成可以随意编辑的字符串。
Prompt governance requirements:Prompt 治理规范要求：
All prompts stored in version control alongside operator code所有 Prompt 必须与算子代码一同纳版本控制系统（如 Git）
Every prompt carries a prompt_id, version, author, approved_by, and golden_test_suite reference每个 Prompt 都必须带有 prompt_id、version（版本）、author（作者）、approved_by（审批人）和 golden_test_suite（黄金测试集）引用
Prompt changes require the same review and regression testing as operator changesPrompt 的变更必须经过与算子代码变更同等严格的 Code Review 和回归测试
Prompt versions are logged in the Evidence Package (Section XIII) alongside operator and model versionsPrompt 版本必须与算子版本、模型版本一道，记录于证据包（第十三节）中
A prompt regression benchmark must be run before any prompt version is promoted to production在任何 Prompt 版本发布到生产环境之前，必须运行 Prompt 回归测试基准
The Evidence Package's chain of custody is only complete if it records the exact prompt version used to generate any LLM output that influenced a business execution.只有把生成业务输出的精确 Prompt 版本完整记录下来，证据包的监管链才算闭环。
08
VIII. Hybrid RAG Architecture: Search Results Are Evidence, Not Facts Themselves
八、混合 RAG 架构：检索结果是证据，不是事实本身
In scenarios with constrained local compute resources and massive private documentation, a heterogeneous hardware-tiering architecture should be adopted:在本地算力有限、私域资料规模较大的场景中，应采用异构硬件分层架构：
SSD & System RAM: Inverted indices, metadata indices, vector indices, document cachesSSD 与系统内存： 倒排索引、元数据索引、向量索引、文档缓存
GPU VRAM: Local inference models, embedding models, or re-ranking modelsGPU 显存： 本地推理模型、Embedding 模型或重排（Re-rank）模型
CPU: Document parsing, BM25 algorithm execution, metadata filtering, lightweight heuristic models, task schedulingCPU： 文档解析、BM25 算子执行、元数据过滤、轻量启发式模型、任务调度
Note on Memory Usage: Utilizing memory-mapped files (mmap) reduces initial bulk-loading spikes, but operating systems still consume page cache dynamically. Actual performance depends heavily on index structures, SSD random I/O performance, available RAM, data volume, and access patterns.关于内存调优的说明： 磁盘映射（mmap）可以降低一次性内存加载压力，但操作系统仍会动态占用页面缓存，实际性能取决于索引结构、SSD 随机 I/O 性能、内存容量、数据规模和访问模式。
Recommended Search Pipeline:推荐的检索流水线：
English flow
User Query ──> [Tenant & ACL Filter] ──> [Intent & Metadata Classifier] │ ▼ [ Cross-Encoder Re-ranker ] <──(Fusion)── [ BM25 + Vector Hybrid Recall ] │ ▼ [ Sufficiency Assessment ] ──(Sufficient)──> [ Grounded Citation Generation ] │ (Insufficient) │ ▼ [ Refusal / Fallback ]
中文流程
用户 Query ──> [租户与 ACL 过滤] ──> [意图与元数据分类器] │ ▼ [ Cross-Encoder 重排 ] <──(融合)── [ BM25 + 向量混合召回 ] │ ▼ [ 证据充分性评估 ] ──(证据充分)──> [ 带引用的事实生成 ] │ (证据不足) │ ▼ [ 拒答 / 降级 ]
RAG systems must natively support:RAG 系统必须原生支持：
Document versioning文档版本控制
Index versioning索引版本控制
Access Control List (ACL) inheritanceACL 权限继承
Data lineage tracking数据血缘追踪
Source citation pinning引用精准定位
Golden Question Test Sets黄金问题测试集
Automated retrieval evaluation自动化检索质量评测
Graceful refusal when evidence is insufficient证据不足时优雅拒答
Key Metrics to Monitor:建议监控的关键指标：
Recall@KRecall@K（前 K 召回率）
Mean Reciprocal Rank (MRR)MRR（平均倒数排名）
Normalized Discounted Cumulative Gain (nDCG)nDCG（归一化折损累计收益）
Evidence Hit Rate证据命中率
Ungrounded (Hallucination) Answer Rate无依据回答（幻觉）率
Stale Document Citation Rate过期文档引用率
Unauthorized Retrieval (ACL Leak) Rate越权召回（ACL 泄漏）率
RAG outputs must be strictly redefined as:RAG 的输出必须被严格重新定义为：
Candidate evidence bound to a source, version, permission level, and confidence score — not inherently true deterministic facts.具有来源、版本、权限和置信度的候选证据，而不是天然正确的确定性事实。
8.1
8.1 Multi-Tenancy and Tenant Isolation in RAG
8.1 RAG 中的多租户与租户隔离
When the same RAG infrastructure serves multiple clients (as is common in Industry Pack deployments), tenant isolation must be enforced at the index level, not just at query time via ACL filters.当相同的 RAG 基础设施为多个客户提供服务时（这在行业包部署中很常见），必须在索引层实施租户隔离，而不能仅在查询时依赖 ACL 过滤器。
A query-time ACL filter can fail silently due to index corruption, schema drift, or implementation bugs, resulting in cross-tenant data leakage. Index-level isolation — separate vector spaces or separate physical indices per tenant — is the defense in depth.查询时的 ACL 过滤可能会因索引损坏、Schema 漂移或代码 Bug 而静默失效，从而导致跨租户数据泄漏。索引级隔离——即为每个租户建立独立的向量空间或独立的物理索引——才是纵深防御之道。
Audit metrics must include an explicit cross_tenant_retrieval_rate tracked as a security KPI. A non-zero value should trigger immediate investigation and incident response.审计指标中必须包含明确的 cross_tenant_retrieval_rate（跨租户召回率）作为安全 KPI。任何非零值都应立即触发调查与安全事件响应。
09
IX. Code-First Agent Production Paradigm
九、Code-First Agent 的生产范式
A "Code-First" approach does not imply allowing LLMs to generate arbitrary code at runtime in a production environment for immediate execution.“代码优先（Code-First）”并不意味着允许大模型在生产环境实时生成任意代码并立即执行。
Production-grade architectures require the strict decoupling of Code Generation from Business Execution.生产级架构要求将“代码生成”与“业务执行”进行严格解耦。
9.1
9.1 Recommended Pattern 1: LLM Generates Declarative Workflows Only
9.1 推荐模式一：大模型只生成声明式工作流
In this pattern, the LLM's production-time output is structured configuration (YAML, JSON, or a domain-specific schema) — never executable code.在这种模式下，大模型在生产运行时的输出是结构化配置（YAML、JSON 或特定领域 Schema）——绝非可执行代码。
Workflow:工作流：
Operator presents a natural language intent to the cognitive layer操作员向认知层输入自然语言意图
LLM produces a declarative workflow DAG referencing only pre-approved, versioned operators by ID大模型生成声明式工作流 DAG，其中仅通过 ID 引用预先批准、版本化的算子
The workflow configuration is validated against a schema and an operator whitelist对工作流配置进行 Schema 校验与算子白名单校验
A human reviews and approves the proposed workflow (for Level C/D operations)由人工对建议的工作流进行审查和批准（针对 C/D 类高风险操作）
The approved configuration is submitted to the deterministic execution engine将批准后的配置提交给确定性执行引擎
Execution proceeds against fixed, audited operator code引擎严格按照固定、受审计的算子代码执行
The LLM never touches execution — it only drafts the blueprint for what a human then authorizes.大模型不接触执行层：它只起草蓝图，之后由人工审查并授权。
9.2
9.2 Recommended Pattern 2: LLM Generates Operators in the Development Phase
9.2 推荐模式二：大模型在开发阶段生成算子
In this pattern, LLMs accelerate operator development during the engineering phase — not during production operation.在这种模式下，大模型是在工程开发阶段加速算子编写——而非在生产运行时。
Workflow:工作流：
FDE describes a new operator requirement to the LLM in natural languageFDE 用自然语言向大模型描述新的算子需求
LLM generates candidate operator code大模型生成候选算子源代码
Code undergoes standard review: static analysis, contract validation, unit tests, property-based tests代码接受标准评审：静态代码分析、契约校验、单元测试、基于属性的测试
Approved code is committed, version-tagged, and signed审查通过的代码被提交、打上版本标签并签署数字签名
Only the signed, reviewed operator enters the production operator registry只有经过签署和审查的算子才能注册进入生产算子库
The production system never calls "generate code now and run it." It runs already-reviewed code that was generated and validated before deployment. The critical distinction is the temporal boundary between generation and execution: generation happens in the development environment; execution happens in production against pre-certified artifacts.生产系统绝不执行“现生成代码现运行”。它运行的是在部署前就已经生成并验证过的已审查代码。核心区别在于生成与执行之间的时间边界：生成发生在开发环境；执行发生在生产环境，且针对的是预先认证的制品。
9.3
9.3 Secure Sandbox Execution (When Dynamic Code Is Unavoidable)
9.3 安全沙箱执行（确需运行动态代码时）
Production environments must never execute LLM-generated Python code using naive eval() or exec() calls. Restricting builtins or applying Abstract Syntax Tree (AST) parsing alone cannot guarantee a secure boundary.生产环境绝不能使用普通的 eval() 或 exec() 动态执行大模型生成的 Python 代码。仅仅限制内置函数（builtins）或进行抽象语法树（AST）扫描无法提供可靠的安全边界。
When executing untrusted, dynamically generated code is unavoidable, strict isolation MUST be enforced:确需运行不可信的动态生成代码时，必须实施严格的隔离机制：
Isolated process boundaries独立的进程边界
OCI Containers or MicroVMs (e.g., Firecracker)OCI 容器或微型虚拟机（如 Firecracker）
Completely air-gapped network namespace完全物理/逻辑隔离的无网络环境
Read-only root file systems只读根文件系统
Hard quotas on CPU and RAMCPU 与内存的硬性配额限制
Execution timeouts严格的执行超时限制
Restricted system call sets (e.g., seccomp)受限的系统调用集（如 seccomp）
Ephemeral identities and scratch directories临时身份与临时工作目录
Comprehensive execution auditing logs完整的运行审计日志
10
X. Atomic Operators, Declarative DAGs, and Business State Machines
十、原子算子、声明式 DAG 与业务状态机
10.1
10.1 Definition of an Atomic Operator
10.1 原子算子的定义
An Atomic Operator is the smallest executable business unit possessing explicitly defined inputs, outputs, side effects, permissions, and contracts.原子算子是具有明确输入、输出、副作用、权限和契约的最小可执行业务单元。
Examples include: Cost calculation, tax evaluation, risk scoring, parameter mapping, equipment health evaluation, quote validation, baseline energy consumption calculation, anomaly detection, and report generation.例如：成本计算、税费计算、风险评分、参数映射、设备健康度评估、报价校验、能耗基线计算、异常检测和报告生成。
Formal Specification Schema:正式规格定义 Schema：
operator_id: pricing.calculate_total
version: 2.1.0
input_schema: pricing-input-v3
output_schema: pricing-output-v2
side_effect: none
determinism: strict
timeout_ms: 500
preconditions:
- quantity > 0
postconditions:
- total_price >= 0
invariants:
- total_price == subtotal + tax - discount10.2
10.2 Operator Risk Classification
10.2 算子风险分级
| English source | 中文原文 |
|---|---|
| A Pure Functions (No Side Effects) Unit conversion, tax calculation | A 类 纯函数，无副作用 单位换算、税费计算 |
| B Read-Only Access Querying price catalogs, reading telemetry | B 类 只读访问 查询价格库、读取设备遥测数据 |
| C Reversible Write Operations Draft creation, dispatching work orders | C 类 可逆写操作 创建草稿、生成工单 |
| D Critical Business Writes Publishing binding quotes, approving purchase orders | D 类 重要业务写操作 发布有约束力的报价、批准采购订单 |
| E Physical Production Control Writing device setpoints, start/stop equipment commands | E 类 物理生产控制操作 修改设备设定值、启停设备指令 |
Operational Rule: Level D and E operations must require human authorization. Level E operations must never be triggered directly by an LLM.操作规则： D 类和 E 类操作必须经过人工授权。E 类操作原则上绝不允许由大模型直接触发。
10.3
10.3 Roles of DAGs, State Machines, and Rule Engines
10.3 DAG、状态机与规则引擎的职责
While DAGs effectively represent computational dependencies, enterprise operations also involve pauses, rejections, compensations, loops, and human approvals. Thus, relying solely on DAGs is insufficient.DAG 适合表达计算依赖，但企业业务还要处理等待、驳回、补偿、循环和审批；只靠 DAG 不够。
A complete system comprises:一个完整的体系应包含：
DAGs: Express computation and data flow dependencies.DAG： 表达计算和数据流依赖。
State Machines: Express lifecycle states and valid transitions.状态机： 表达业务生命周期状态及合法的状态转换。
Rule Engines: Express conditional logic and business policies.规则引擎： 表达条件判断与业务政策。
Human-in-the-Loop Workflows: Express approval chains, authorizations, and accountability.人机交互工作流： 表达审批链、授权与责任归属。
Saga / Compensation Mechanisms: Manage long-running transactions and rollback steps upon failure.Saga / 补偿机制： 管理长事务并在失败时执行回滚步骤。
11
XI. Design by Contract: Constraining Errors Rather Than Claiming Infallibility
十一、契约式设计：限制错误，而不是宣称系统永不犯错
Design by Contract (DbC) must cover:契约式设计（DbC）必须覆盖：
Preconditions前置条件
Postconditions后置条件
Business invariants业务不变量
Permission constraints权限约束
Numerical range boundaries数值范围边界
Data integrity rules数据完整性规则
State transition validity状态转换合法性
Whenever a workflow, configuration, or recommendation generated by a model violates contract boundaries, the system must block it from reaching the execution layer.当模型生成的工作流、配置或建议突破契约边界时，系统必须阻止其进入执行层。
However, "falling back to static rules" is not universally safe, as static rules themselves can become stale or misaligned over time.然而，“降级到静态规则”并不总是绝对安全，因为静态规则本身也可能随着时间推移而过期或错位。
A Recommended Five-Tier Failure Handling Mechanism:推荐的五级故障处置机制：
English flow
[ Error Detected ] │ ├── Level 0: Pre-execution contract check — validate preconditions before invocation │ (cheapest; catches predictable failures before they occur) │ ├── Level 1: Fall back to a certified secondary algorithm │ ├── Level 2: Degrade functional scope (Read-only / Advisory mode) │ ├── Level 3: Route to manual approval & expert review │ └── Level 4: Enter a secure safe-state and halt execution
中文流程
[ 检测到错误 ] │ ├── 0 级：执行前契约检查——在调用前校验前置条件 │ （成本最低；在可预测的错误发生前就将其拦截） │ ├── 1 级：切换到经过认证的备用算法 │ ├── 2 级：降低功能范围（仅只读/建议模式） │ ├── 3 级：转人工审批与专家复核 │ └── 4 级：进入安全状态并停止执行
Level 0 is distinct from the others: it handles predictable precondition failures before execution begins, rather than runtime failures mid-execution. This is cheaper, more graceful, and enables better upstream communication to the user.0 级与其他级别不同：它在执行开始前处理可预测的前置条件失效，而不是等运行中途再处理故障。这样成本更低，也更容易给前端用户清楚的反馈。
The goal of an enterprise-grade system is not to promise "zero errors," but to ensure that:企业级系统的目标不是承诺“零错误”，而是确保：
Errors can be isolated, detected, explained, intercepted, rolled back, and remediated.错误能够被隔离、发现、解释、阻断、回滚和修复。
12
XII. The Five Pillars of Deterministic Delivery
十二、确定性交付的五项支柱
12.1
12.1 Data Determinism
12.1 数据确定性
Clear data origins数据来源明确
Explicit data versioning数据版本明确
Measurable data quality数据质量可测
Defined authorization boundaries权限边界明确
Traceable data lineage数据血缘可追踪
12.2
12.2 Logic Determinism
12.2 逻辑确定性
Fixed operator versions算子版本固定
Explicit business rules业务规则显式化
Strongly typed configurations配置强类型化
Prohibition of arbitrary code generation and execution in production生产环境禁止即时生成并执行任意代码
12.3
12.3 Execution Determinism
12.3 执行确定性
Immutable execution environments运行环境不可变/固定
Idempotent process execution执行过程幂等
Recoverable system states系统状态可恢复
Clear timeouts, retry limits, and compensation policies超时、重试与补偿策略明确
12.4
12.4 Verification Determinism
12.4 验证确定性
Preconditions & Postconditions前置条件与后置条件
Invariants checks业务不变量检查
Unit tests & Property-based tests单元测试与基于属性的测试
Golden Test Suites黄金测试集
Regression testing pipelines回归测试流水线
12.5
12.5 Accountability Determinism
12.5 责任确定性
Full audit logging of all operations操作全程审计日志
Traceable approval trails审批轨迹可追溯
Unambiguous SLAs and acceptance criteriaSLA 与验收标准明确无歧义
Designated human owners for exceptions异常情况有具名的负责人
Precise alignment between authority and responsibility权力与责任精准对齐
Deterministic delivery does not imply that the real world is static. It means:所谓确定性交付，并非暗示现实业务世界是静止不变的。它的真实含义是：
Given deterministic data, explicit rules, fixed versions, and controlled environments, the system's outputs can be reproduced, verified, and explained.在确定的数据、显式规则、固定版本和可控环境条件下，系统的输出可以被复现、验证和解释。
13
XIII. Chain of Evidence: Auditing Every Formal Execution
十三、证据链：每一次正式执行都必须可追溯
Every critical business execution must generate a cryptographic Evidence Package:每一次关键业务执行都必须生成一个加密的证据包（Evidence Package）：
execution_id: EXE-20260801-001
workflow_hash: sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
operator_versions:
pricing.calculate_total: 2.1.0
prompt_versions:
extraction.rfq_parser: 1.4.2
recommendation.energy_optimizer: 2.0.0
policy_version: policy-4.2
input_hash: sha256:8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4
data_snapshot: pricing-db-2026-08-01-v1
model_used_for_proposal: model-x-v1
approval_id: APR-0812
result_hash: sha256:5feceb66ffc86f38d952786c6d696c79c2dbc239dd4e91b46729d73a27fb57e9
contract_checks:
preconditions: passed
postconditions: passed
invariants: passed
cognitive_layer_status: available
input_source_classification: internalThe Chain of Evidence must conclusively answer:证据链必须能够确凿地回答：
What data was consumed?消耗/使用了什么数据？
Which algorithm, rule, and prompt versions were executed?执行了哪些算法、规则以及 Prompt 版本？
Who initiated the request?请求是由谁发起的？
Who authorized the execution?执行是由谁授权的？
What was the execution environment?运行环境是什么？
How was the output generated?结果是如何生成的？
Did it pass all contract assertions?是否通过了所有的契约断言检查？
How were anomalies handled?出现异常后是如何处置的？
Was the cognitive layer input sourced internally or from an external party?认知层的输入是来自内部还是外部第三方？
This package serves as the technical audit trail, commercial settlement basis, liability attribution record, and formal project acceptance proof. It must be tamper-evident: any retrospective modification to the evidence record must be detectable.证据包同时承担技术审计、商业结算、责任界定和项目验收四项作用。它必须防篡改，任何事后改动都要能被检测出来。
14
XIV. End-to-End FDE Project Business Lifecycle
十四、FDE 项目完整业务闭环
A complete FDE project must follow a closed-loop lifecycle.一个完整的 FDE 项目必须遵循闭环生命周期。
14.1
14.1 Opportunity Identification
14.1 商机识别
Validate whether:确认：
The client has an urgent, well-defined business problem客户是否有明确且迫切的业务问题
Quantifiable economic value exists是否存在可量化的经济价值
An empowered business owner is assigned是否有获得充分授权的业务负责人
Data prerequisites are met是否具备必要的数据条件
Deployment and decision-making conditions are ripe是否具备部署和决策条件
14.2
14.2 Business Discovery
14.2 业务发现
Clarify:明确：
Who makes what decisions in which scenarios?谁在什么场景下做什么决策？
What data underpins current decisions?目前决策依据什么数据？
Where do value leaks occur in the current workflow?现有流程在哪里发生价值损耗/泄漏？
What is the financial cost of errors?错误的财务成本是什么？
Which specific operational metric must change post-deployment?系统上线后哪个具体的运营指标必须改变？
14.3
14.3 Value Baseline Establishment
14.3 价值基线建立
Define:明确：
Current operational baseline当前运营基线
Target performance values目标性能指标值
Data measurement sources数据测量/采集来源
Measurement timeframes测量/验证周期
Excluded noise variables应排除的干扰/噪音变量
Acceptance rules验收规则
Accountable stakeholders责任主体
14.4
14.4 Proof of Value (PoV) Verification
14.4 PoV 概念验证
A PoV must demonstrate actual business value, not just technical feasibility.PoV 必须证明实际的业务价值，而不只是证明技术可行性。
Recommended Scope:推荐范围：
One factory or department一个工厂或部门
One core process一个核心流程
One primary user group一个主要用户群
One key metric一个关键指标
One set of real production data一组真实生产数据
Select the PoV user group based on willingness and organizational influence — not just technical accessibility. A successful PoV with influential early adopters accelerates enterprise-wide adoption far more effectively than a technically perfect PoV with passive participants.选择 PoV 用户群时，应同时考量其意愿以及在组织内部的影响力——而不能仅看技术接入的方便程度。与具备影响力的早期采纳者合作完成一个成功的 PoV，比在被动参与者身上做一个技术上完美无瑕的 PoV，能更有效地加速全企业范围的推广落地。
14.5
14.5 Engineering Implementation
14.5 工程实施
Engineering implementation in FDE projects must follow a contract-first, operator-first sequence — not a feature-first or UI-first sequence.FDE 项目的工程实施必须遵循“契约优先、算子优先”的顺序——而非“功能优先”或“UI 优先”的顺序。
Recommended sequence:推荐实施顺序：
Define operator contracts before writing operator implementations (input/output schemas, preconditions, postconditions)在编写算子实现之前定义算子契约（输入/输出 Schema、前置条件、后置条件）
Build synthetic data pipelines to enable development without live client data构建合成数据流水线，实现在无需客户真实数据的情况下开展开发
Implement deterministic operators in order of business risk (Level A/B before C/D/E)按业务风险高低顺序实现确定性算子（先 A/B 类，后 C/D/E 类）
Build and validate the RAG pipeline against golden question test sets before connecting to the cognitive layer在对接认知层之前，基于黄金问题测试集构建并验证 RAG 流水线
Integrate the cognitive layer as the final step — only after the deterministic foundation is tested将集成认知层作为最后一步——仅在确定性基础接受充分测试之后
Conduct red-team exercises specifically targeting prompt injection and ACL boundary conditions专门针对 Prompt 注入和 ACL 边界条件开展红蓝对抗（Red-team）演练
Generate a pre-acceptance Evidence Package from the staging environment using production-representative data在预生产环境中使用代表生产特性的数据生成预验收证据包
The temptation in LLM projects is to build the chat interface first and the deterministic runtime last. This sequence must be explicitly inverted.大模型项目中常见的陷阱是先做对话界面，最后才做确定性运行时。这一顺序必须被明确颠倒过来。
14.6
14.6 Asset Extraction
14.6 资产抽取
Post-project reviews must determine:项目结束后的复盘评审必须确定：
Which code components merge into the core platform哪些代码组件合并进入核心平台
Which capabilities enrich Industry Packs哪些能力补充沉淀至行业包
Which configurations remain customer-specific哪些配置仍保留为客户专属
What insights enter the organizational knowledge base哪些经验/洞察进入组织知识库
Which rules can be encapsulated as atomic operators哪些规则可以封装为原子算子
Which workflows can be generalized as templates哪些工作流可以通用化为模板
Which risk terms should be incorporated into standard contract templates哪些风险条款需要写入标准合同模板
Which evaluation benchmarks and golden test sets can be generalized for the industry vertical哪些评测基准和黄金测试集可以泛化至该垂直行业
15
XV. Product Architecture: Core Platform, Industry Packs, and Customer Overlays
十五、产品架构：核心平台、行业包与客户层
To prevent re-engineering the wheel for every engagement, a Three-Tier Asset Model should be enforced:为避免每个项目都重复造轮子，应强制推行“三层资产模型”：
English flow
┌──────────────────────────────────────────────────────────────┐ │ Tier 3: Customer Overlay │ │ Client Branding, Interfaces, Custom Rules, Forms, Workflows │ ├──────────────────────────────────────────────────────────────┤ │ Tier 2: Industry Packs │ │ Bidding, Energy Management, Digital Twin, O&M Modules │ ├──────────────────────────────────────────────────────────────┤ │ Tier 1: FDE Core Platform │ │ ACL, Workflows, Audit, Files, Alerts, Agents, Deployment/O&M │ └──────────────────────────────────────────────────────────────┘
中文流程
┌──────────────────────────────────────────────────────────────┐ │ 第三层：Customer Overlay（客户定制层） │ │ 客户品牌、接口适配、自定义规则、表单、特殊工作流 │ ├──────────────────────────────────────────────────────────────┤ │ 第二层：Industry Packs（行业包层） │ │ 投标报价、综合能源、数字孪生、设备运维等行业模块 │ ├──────────────────────────────────────────────────────────────┤ │ 第一层：FDE Core Platform（核心平台层） │ │ 权限控制、工作流引擎、审计、文件、告警、Agent、部署运维 │ └──────────────────────────────────────────────────────────────┘
Client implementations should be accomplished primarily through configurations, operator compositions, and Industry Packs, avoiding direct modifications to Core Platform code.客户项目应尽量通过配置、算子组合和行业包实现，避免直接修改核心平台代码。
Long-term Evolutionary Goal:长期演进目标：
Initial Projects: Higher custom coding ratio, lower asset extraction.早期项目： 定制代码比例较高，资产沉淀较少。
Subsequent Projects in Same Vertical: Increasing proportion of standardized modules and industry operators.同类行业后续项目： 标准模块和行业算子比例逐步提高。
Mature Industry Products: Assembly and configuration-driven delivery with minimal bespoke development.成熟行业产品： 以组装和配置驱动交付为主，仅保留极少量定制开发。
16
XVI. FDE Application Principles in Typical Scenarios
十六、典型场景的 FDE 应用原则
16.1
16.1 Intelligent Bidding and Quoting
16.1 智能投标报价
Core Workflow:核心工作流：
English flow
[Tender Document Ingestion] │ ▼ [Sanitization Layer] ──> [External Document Adversarial Check] │ ▼ [LLM: Requirement & Constraint Extraction] │ ▼ [Schema Validation of Extracted Fields] │ ▼ [Operator: Cost Component Mapping] │ ▼ [Operator: Price Calculation with Margin Rules] │ ▼ [Operator: Risk Rating & Clause Flagging] │ ▼ [LLM: Proposal Draft Generation] │ ▼ [Human Review & Authorization Gate] ──(Reject / Revise)──> [Loop] │ (Approve) │ ▼ [Binding Quote Issuance + Evidence Package]
中文流程
[ 招标文件导入 ] │ ▼ [ 内容清洗/脱敏层 ] ──> [ 外部文档对抗性检查 ] │ ▼ [ 大模型：需求与约束提取 ] │ ▼ [ 提取字段的 Schema 校验 ] │ ▼ [ 算子：成本组件映射 ] │ ▼ [ 算子：带利润率规则的价格计算 ] │ ▼ [ 算子：风险评级与条款标记 ] │ ▼ [ 大模型：方案草案生成 ] │ ▼ [ 人工审查与授权节点 ] ──(驳回/修改)──> [ 循环 ] │ (批准) │ ▼ [ 发布有约束力的报价 + 证据包 ]
Key implementation considerations:关键实施考量：
The extraction step must validate that required fields (scope, delivery date, payment terms, penalty clauses) are present before proceeding — graceful refusal if evidence is insufficient提取步骤必须先校验关键字段（范围、交付日期、付款条件、违约罚则）是否齐全；证据不足时应明确拒答并说明缺失项
Pricing operators must enforce margin floor invariants; any output violating the floor must be blocked and escalated计价算子必须强制执行毛利底线不变量；任何突破底线的输出都必须被阻断并升级上报
All tender documents received from external parties must be treated as potentially adversarial inputs (Section 7.5)所有从外部接收的招标文件都必须被视为潜在的对抗性输入（第七.五节）
Mandatory Boundary: Final binding prices, payment terms, and contractual commitments must undergo human authorization (Level D operator). No LLM output may constitute a legal commercial commitment without an explicit human approval event in the audit trail.强制边界： 最终报价、付款条件和合同承诺必须经过人工授权（D 类算子）。在审计追踪中没有明确的人工审批事件前，任何大模型输出均不得构成具有法律效力的商业承诺。
16.2
16.2 Integrated Energy Services
16.2 综合能源服务
Core Chain:核心链路：
English flow
[Equipment Telemetry Ingestion via OPC-UA / MQTT] │ ▼ [Operator: Baseline Energy Consumption Calculation] │ ▼ [Operator: Anomaly Detection & Deviation Flagging] │ ▼ [LLM: Root Cause Analysis & Optimization Opportunity Identification] │ ▼ [Mathematical Solver: Setpoint Optimization under Physical Constraints] │ ▼ [LLM: Human-Readable Recommendation with Explanation] │ ▼ [Human Operator: Review & Authorization] │ ▼ [IT/OT Gateway: Hardware Interlock Validation] │ ▼ [Control System: Approved Setpoint Application] │ ▼ [Operator: Outcome Monitoring & Value Measurement]
中文流程
[ 设备遥测数据导入（通过 OPC-UA / MQTT）] │ ▼ [ 算子：能耗基线计算 ] │ ▼ [ 算子：异常检测与偏差标记 ] │ ▼ [ 大模型：根本原因分析与优化机会识别 ] │ ▼ [ 数学求解器：物理约束下的设定值优化 ] │ ▼ [ 大模型：生成可读的可解释优化建议 ] │ ▼ [ 人工操作员：审查与授权 ] │ ▼ [ IT/OT 网关：硬件联锁校验 ] │ ▼ [ 控制系统：应用已批准的设定值 ] │ ▼ [ 算子：结果监测与价值测量 ]
Key implementation considerations:关键实施考量：
The mathematical solver — not the LLM — is responsible for constraint enforcement and numeric optimization数学求解器——而非大模型——负责约束求解与数值优化计算
The IT/OT gateway enforces hardware-level range limits independently of the software stackIT/OT 网关独立于软件栈，在硬件/固件层强制执行数值范围限制
Energy savings attribution must be calculated against the defined baseline (Section 14.3), not against a moving target节能量归因必须基于预先定义的基线（第十四.三节）计算，而非基于动态漂移的目标
Mandatory Boundary: Models may calculate and advise; equipment control MUST enforce hard safety interlocks and human authorization boundaries. Physical actuation commands must never originate from LLM output without passing through the hardware interlock layer.强制边界： 模型可以计算并提供建议；设备控制必须保留硬性安全联锁和人工授权边界。物理执行指令绝不允许在未经硬件联锁层校验的情况下直接源自大模型输出。
16.3
16.3 Industrial Digital Twins
16.3 工业数字孪生
A digital twin must go beyond static 3D visualization to establish a living operational system. The twin has four mandatory capabilities:数字孪生不能只做静态 3D 展示，而应成为持续运行的运营系统。至少要具备四项能力：
Real-time state synchronization — the digital model must reflect current physical equipment state, not a last-known or scheduled snapshot实时状态同步——数字模型必须反映当前物理设备的真实状态，而非历史已知或计划中的快照
Anomaly detection and alerting — deviations from normal operating envelopes must be detected automatically and routed to the appropriate operator异常检测与告警——偏离正常运行区间的异常必须被自动检测并路由至相应的操作员
LLM-powered root cause analysis — when an anomaly is detected, the cognitive layer synthesizes relevant maintenance history, sensor trends, and equipment specifications to generate a human-readable diagnostic大模型驱动的归因分析——当检测到异常时，认知层综合相关维保历史、传感器趋势和设备规格说明，生成可读的诊断报告
Work order integration — maintenance recommendations must flow into the enterprise work order system, not exist only as conversational output工单系统集成——维保建议必须自动流转进入企业工单系统，而非仅作为对话窗口的输出存在
3D scenes, telemetry pipelines, business domain objects, and workflow engines must remain strictly decoupled. Coupling the visualization layer directly to business logic creates brittle systems that are difficult to test, audit, and maintain. Each layer should be independently deployable and independently testable.3D 场景、遥测流水线、业务领域对象和工作流引擎必须严格解耦。把可视化层直接绑到业务逻辑上，系统会变得脆弱，也难以测试、审计和维护；每一层都应能独立部署、独立测试。
17
XVII. Pre-Initiation Project Checklist
十七、项目立项检查表
Before formally launching an FDE project, the following conditions must be confirmed:FDE 项目正式启动前，应至少确认以下事项：
17.1
17.1 Business Conditions
17.1 业务条件
Is an empowered business owner identified?是否存在明确且获得充分授权的业务负责人？
Are there explicitly defined, quantifiable targets?是否存在明确定义的量化目标？
Are budget and decision-making mechanisms approved?是否有已批准的预算和决策机制？
Are actual end-users actively involved?是否有真实终端用户深度参与？
Is a PoV phase agreed upon?是否达成 PoV 阶段性协议？
17.2
17.2 Data Conditions
17.2 数据条件
Is target data accessible?目标数据是否可以访问？
Is data ownership clearly defined?数据所有权是否明确？
Is data quality acceptable for project goals?数据质量对于项目目标而言是否可接受？
Are privacy and trade secret boundaries demarcated?是否明确划定了隐私与商业秘密边界？
Are cross-border/security data rules defined?是否明确了数据出境/安全合规规则？
17.3
17.3 Technical Conditions
17.3 技术条件
Is the deployment model explicitly chosen (On-Prem / Private Cloud)?是否明确选择了部署方式（本地私有化/私有云）？
Is the API/interface integration list finalized?API/接口集成清单是否最终敲定？
Are system boundaries clearly demarcated?系统边界是否清晰划定？
Are staging/testing environments available?是否具备预生产/测试环境？
Are logging, monitoring, and rollback capabilities in place?是否具备日志、监控和回滚能力？
Is a cognitive layer degradation policy defined (Section 7.6)?是否定义了认知层降级策略（第七.六节）？
Are prompt versions under version control (Section 7.7)?Prompt 版本是否纳入版本控制（第七.七节）？
17.4
17.4 Risk Conditions
17.4 风险条件
Is role-based permission control configured?是否完成了基于角色的权限控制配置？
Are high-risk actions identified and classified?是否识别并分级了高风险操作？
Are human-in-the-loop approval checkpoints embedded?是否嵌入了人机交互审批节点？
Is a multi-tier fallback/degradation mechanism defined?是否定义了多级故障降级机制？
Are SLAs and liability boundaries agreed upon?是否达成了 SLA 和责任边界协议？
Is an adversarial input handling policy defined for external document processing?处理外部文档时是否明确了对抗性输入处理策略？
17.5
17.5 Commercial Conditions
17.5 商业条件
Are project scope and explicit exclusions documented?是否书面明确了项目范围和排除项？
Are milestone payment schedules tied to verifiable criteria?里程碑付款计划是否与可验证的标准绑定？
Is IP ownership clearly assigned?知识产权归属是否明确？
Are data liability clauses defined?是否定义了数据责任条款？
Are acceptance methodologies and value baseline formulas signed off?验收方法与价值基线公式是否签字确认？
Is the three-tier risk matrix embedded in contract language?三层风险矩阵是否嵌入合同文本中？
Are ongoing cognitive layer costs addressed in the pricing model?报价模型中是否考虑了持续的认知层 Token 成本？
18
XVIII. Cardinal Principles for FDE Projects
十八、FDE 项目的最终原则
Decouple Cognition from Execution.认知与执行分离。
LLMs may advise, but they do not inherently hold business execution rights.大模型可以提出建议，但不天然拥有业务执行权。
Configuration Over Dynamic Code.配置优于动态代码。
Prefer generating declarative configurations over dynamically generating and running raw code in production.优先让大模型生成声明式配置，而不是在生产环境即时生成并执行原生代码。
Evidence Over Unsubstantiated Conclusions.证据优于无凭结论。
All critical responses and decisions must trace back to verified data, documents, rules, and explicit versions — including the prompt version that generated the cognitive output.所有关键回答和决策必须可以追溯到数据、文档、规则和版本——包括生成认知输出的 Prompt 版本。
Modular Operators Over Bespoke Code Forks.模块化算子优于客户定制分支。
Encapsulate general business logic into reusable operators; avoid maintaining isolated, custom codebases for every client.将通用业务逻辑沉淀为可复用算子，避免每个客户维护独立的代码孤岛。
Contract Enforcement Over Prompt Engineering.契约硬约束优于 Prompt 工程。
Security and compliance rules must be enforced by code, schemas, policies, and runtime assertions — not just system prompts.安全和业务规则必须通过代码、Schema、策略和运行时断言实现，不能只依赖 Prompt。
Least Privilege Over Absolute Trust.最小权限优于绝对信任。
Do not rely on the absolute trustworthiness of any individual or model; mitigate risk through permission isolation, approvals, and auditing.不依赖任何个人或模型的绝对可靠，而是通过权限隔离、审批和审计降低风险。
Rollbackability Over Blind Automation.可回滚优于盲目自动化。
Every major execution step must feature failure-handling protocols, fallback options, and state recovery mechanisms.每个重要执行步骤都必须有失败处理协议、降级选项和状态恢复机制。
Realized Business Value Over Technical Novelty.实现业务价值优于技术炫耀。
Project success is measured by improvements in operational business metrics, not by model parameter counts, UI complexity, or feature volume.项目成功必须以业务指标变化为依据，而不是以模型规模、页面复杂度和功能数量为依据。
Asset Accumulation Over One-off Deliveries.资产沉淀优于一次性交付。
Every engagement must continuously enrich the Core Platform, Industry Packs, Operator Libraries, evaluation benchmarks, and delivery methodologies.每次客户项目都应持续增强核心平台、行业包、算子库、评测基准和交付方法论。
Determinism Does Not Mean Infallibility.确定性不等于永不出错。
The true definition of determinism is that when errors inevitably occur, they are detected, contained, explained, intercepted, rolled back, and remediated.确定性的真正含义，是当错误不可避免发生时，能够被发现、限制、解释、阻断、回滚和修复。
Treat Prompts as Versioned Infrastructure.将 Prompt 视为版本化基础设施。
System prompts are not configuration text — they are executable logic governing cognitive behavior. Version them, test them, and audit them with the same rigor as operator code.系统 Prompt 不是普通的配置文本——它们是治理认知行为的可执行逻辑。必须用与算子代码同等的严谨度对其进行版本化、测试和审计。
Design for Organizational Adoption, Not Just Technical Acceptance.为组织推广采用而设计，而非仅仅为了技术验收。
A system that operators distrust or circumvent delivers zero business value. Human-in-the-loop design must be co-created with operators, not imposed on them.一个被操作员不信任或绕过的系统产生的业务价值为零。人机交互设计必须与一线操作员共创，而非强加给他们。
Plan for Cognitive Layer Absence.为认知层的缺失做准备。
Every workflow must have a defined behavior when the LLM is unavailable. Resilience is a design requirement, not an operational aspiration.每一个工作流都必须定义在大模型不可用时的预期行为。高韧性是设计出来的硬性需求，而非运维时的美好愿望。
19
XIX. Observability Architecture for Production AI Systems
十九、生产级 AI 系统的可观测性架构
Enterprise AI systems require a dedicated observability stack that spans both the probabilistic cognitive layer and the deterministic execution layer — and critically, correlates events across both. Traditional application monitoring is insufficient because it cannot distinguish whether a business outcome failure originated in the cognitive layer, the deterministic layer, or the human approval step.企业级 AI 系统需要一套专门的可观测性技术栈，覆盖概率性认知层与确定性执行层——并且关键在于能够跨两层进行事件关联分析。传统应用监控手段是不够的，因为它无法区分某种业务结果失败究竟是源于认知层、确定性层，还是人工审批环节。
19.1
19.1 Correlation Identity
19.1 关联标识符（Trace ID）
Every business transaction — from initial user intent to final execution evidence — must carry a root correlation ID that threads through:每一次业务事务——从最初的用户意图到最终的执行证据——都必须携带一个根关联 ID（Correlation ID），贯穿串联以下环节：
The RAG retrieval sessionRAG 检索会话
Each LLM API call (logged by the Semantic Egress Gateway)每次大模型 API 调用（由语义出境网关留痕）
Each operator invocation每次算子调用
Each human approval event每次人工审批事件
The final Evidence Package最终的证据包
Without this correlation, post-incident analysis is manual, error-prone, and potentially inadmissible as audit evidence.缺乏这种关联性，事后故障分析将全靠人工且极易出错，甚至可能无法作为合规审计证据。
19.2
19.2 Observability Dimensions
19.2 可观测性维度
| English source | 中文原文 |
|---|---|
| Cognitive Layer Latency per LLM call, token usage per request, prompt template version, extraction confidence scores, schema validation pass/fail rates | 认知层 每次大模型调用延迟、每次请求 Token 消耗、Prompt 模板版本、抽取置信度得分、Schema 校验通过率/失败率 |
| RAG Layer Recall@K, MRR, sufficiency assessment outcomes, stale citation rate, ACL filter hit rate, cross-tenant retrieval rate | RAG 层 Recall@K、MRR、证据充分性评估结果、过期文档引用率、ACL 过滤命中率、跨租户召回率 |
| Execution Layer Operator latency, precondition failure rates, contract violation counts, rollback event frequency | 执行层 算子延迟、前置条件失败率、契约违例次数、回滚事件触发频率 |
| Human-in-the-Loop Approval latency, override rate by operator type, escalation frequency | 人机交互层 审批延迟、按算子类型统计的人工干预/覆盖率、升级上报频率 |
| Business Layer The actual value metrics — energy cost delta, bid win rate, error reduction rate — not just system metrics | 业务层 真实的业务价值指标——电费降低额、中标率、错误率下降幅度——而非仅仅是系统性能指标 |
19.3
19.3 Behavioral Drift Detection
19.3 行为漂移检测
A production AI system's behavior can drift without any code change — due to upstream data schema changes, LLM provider model updates, document corpus evolution, or gradual shifts in the business environment the system was calibrated against.生产级 AI 系统可能在代码没有改动时发生“漂移”：上游数据 Schema 变了、模型厂商更新了底层模型、文档库演进了，或者系统所依赖的外部业务环境正在变化。
Install behavioral drift monitors that alert when:必须部署行为漂移监控器，在发生以下情况时发出预警：
LLM extraction confidence distributions shift beyond a defined threshold大模型提取置信度的概率分布偏离超出设定阈值
Operator outcome distributions deviate from historical baselines算子输出结果的分布偏离历史基线
Human override rates on specific operator types trend upward — a leading indicator that cognitive layer recommendations are degrading before the business metric itself declines人工对特定算子类型的覆盖/干预率呈上升趋势——这是认知层建议质量下降的先导指标，往往早于业务指标自身的下滑
RAG stale citation rates increase, signaling that the document corpus needs re-indexingRAG 过期文档引用率上升，提示文档库需要重新建立索引
Behavioral drift alerts should be routed to a designated technical owner with a defined response SLA — not just logged into a monitoring dashboard that no one actively reviews.行为漂移预警应直接发给指定的技术负责人，并附上明确的响应 SLA；不能只是留在没人查看的监控看板里。
20
XX. Cost Governance of the Cognitive Layer
二十、认知层的成本治理
LLM API costs are variable and transaction-coupled — unlike traditional software infrastructure costs. At enterprise scale, unmanaged token consumption can make an economically attractive project commercially unviable. This is a first-order business risk that must be addressed in architecture design, not patched post-deployment.与传统软件基础设施成本不同，大模型 API 成本是可变的且与事务直接绑定的。在企业级规模下，不受控制的 Token 消耗会让一个原本在经济上有吸引力的项目变得在商业上不可行。这是必须在架构设计层面解决的一阶业务风险，而非事后补救。
20.1
20.1 Cost Architecture Principles
20.1 成本架构原则
Every LLM invocation must be tagged with cost_center, workflow_id, and operator_type每次大模型调用都必须打上 cost_center（成本中心）、workflow_id（工作流 ID）和 operator_type（算子类型）标签
A token budget must be defined per workflow and per operator class必须为每个工作流和每类算子定义 Token 预算上限
Requests exceeding their budget should be rejected or routed to a cheaper model tier — not silently over-consumed超出预算上限的请求应被优雅拒绝或路由降级至更便宜的模型层级——而不是默默发生超额消耗
Monthly cost-per-transaction-type must be reported alongside the business KPIs in project reviews在项目复盘中，按事务类型统计的单次月度成本必须与业务 KPI 一同汇报
Token budget governance must be owned by a named stakeholder, not treated as a shared infrastructure concernToken 预算治理必须由具名的责任人牵头，而不能被当成公共基础设施事务推诿
20.2
20.2 Cost Optimization Hierarchy
20.2 成本优化阶梯
1. Eliminate — Can this cognitive step be replaced by a deterministic rule?
2. Cache — Has this exact (or semantically equivalent) query been answered recently?
3. Compress — Can the context window be minimized without losing necessary information?
4. Route — Can a smaller / cheaper model handle this task class adequately?
5. Batch — Can async processing replace real-time invocation for non-urgent tasks?1. 消除 (Eliminate) —— 该认知步骤是否可以被确定性规则所替代？
2. 缓存 (Cache) —— 近期是否回答过完全相同（或语义等价）的查询？
3. 压缩 (Compress) —— 上下文窗口是否可以在不丢失必要信息的前提下精简？
4. 路由 (Route) —— 更小/更便宜的模型是否足以胜任此类任务？
5. 批处理 (Batch) —— 对于非紧急任务，异步批处理能否替代实时调用？
Each optimization must be validated against the cognitive layer evaluation framework (Section XXIV) to confirm it does not degrade output quality below acceptable thresholds.每一项优化都必须经过认知层评估框架（第二十四节）的验证，以确认其不会将输出质量降低到可接受的阈值以下。
20.3
20.3 Commercial Implication
20.3 商业隐含意义
FDE project pricing models must account for ongoing LLM inference costs. Fixed-fee delivery contracts that ignore ongoing cognitive layer costs create perverse incentives to under-invest in optimization.FDE 项目报价模型必须将持续的大模型推理成本考虑在内。忽视持续认知层成本的固定费用交付合同，会产生抑制优化投入的逆向激励。
Consider billing structures that include a per-transaction cognitive layer cost passthrough with a negotiated ceiling. This aligns the FDE's optimization incentives with the client's cost interests, and makes the cost structure transparent rather than buried in margin.建议考虑采用包含按事务计费的认知层成本实报实销（附带协商上限）的合同结算结构。这能将 FDE 的优化动力与客户的成本利益对齐，并让成本结构透明化，而非隐匿于项目毛利中。
21
XXI. Organizational Change Management
二十一、组织变革管理
The most common failure mode in enterprise AI deployment is not technical — it is the failure of human adoption. A system that operators distrust, ignore, or route around achieves zero business value regardless of its technical quality. FDE projects must treat organizational change management as a first-class engineering concern, not a post-delivery communications task.企业级 AI 部署中最常见的失败模式并非技术失败——而是人类推广采用的失败。一个被操作员不信任、忽视或绕过的系统，无论其技术质量多高，产出的业务价值都为零。FDE 项目必须把组织变革管理当作核心工程事项，而不是交付后的宣传沟通任务。
21.1
21.1 Change Adoption Framework
21.1 推广采用框架
| English source | 中文原文 |
|---|---|
| Discovery Identify adoption champions and resistors early; understand the informal power structure, not just the org chart | 业务发现 尽早识别推广积极分子与潜在阻力者；理解非正式的权力结构，而非仅仅看组织架构图 |
| PoV Design Select the PoV user group based on willingness AND organizational influence | PoV 设计 基于意愿以及组织影响力选择 PoV 用户群 |
| Implementation Co-design the human-in-the-loop interface with actual operators, not management proxies | 工程实施 与一线操作员共创人机交互界面，而非通过管理层的代理人 |
| Deployment Define a formal trust escalation path; begin in advisory mode before any execution authority is delegated | 上线部署 建立正式的信任阶梯升级路径；在下放任何执行权之前，先从“纯建议模式”开始 |
| Steady State Establish a feedback mechanism for operators to flag degraded recommendations; treat operator feedback as a data source | 稳态运营 建立反馈机制让操作员标记质量下降的建议；将操作员的反馈视为一种重要的数据源 |
21.2
21.2 Trust Escalation Path
21.2 信任阶梯升级路径
Operators must not be asked to trust the system fully on day one. A staged model both reduces adoption risk and maps naturally to a value-based commercial escalation:绝不能要求操作员在第一天就完全信任系统。分阶段的信任模型既能降低推广风险，又能自然映射到基于价值的商务里程碑升级：
Stage 1: Advisory Only
System generates recommendations; humans execute independently.
Duration: Until recommendation acceptance rate > threshold.
Stage 2: Assisted Execution
Human reviews and explicitly approves each recommendation before execution.
Duration: Until override rate stabilizes below threshold.
Stage 3: Supervised Automation
System executes autonomously; human monitors and can override.
Duration: Until exception rate and override patterns are well-characterized.
Stage 4: Exception-Only Oversight
Human involved only when system flags uncertainty, anomaly, or contract violation.阶段 1：纯建议模式（Advisory Only）
系统生成建议；人工独立评估并执行。
持续时间：直至建议采纳率 > 设定阈值。
阶段 2：辅助执行模式（Assisted Execution）
人工在执行前审查并明确批准每条建议。
持续时间：直至人工干预/覆盖率稳定低于阈值。
阶段 3：受监督的自动化模式（Supervised Automation）
系统自主执行；人工进行监控并在必要时接管覆盖。
持续时间：直至异常率和人工干预模式被充分表征。
阶段 4：例外接管模式（Exception-Only Oversight）
仅在系统预警不确定性、异常或突破契约时，人工才接入干预。
Each stage transition requires: a defined observation period, a measured business outcome delta, and explicit authorization from the business owner — not just the technical team. These transition gates are commercial milestones, not just operational ones.每一个阶段的跨越都需要：明确定义的观察期、可测量的业务结果增量，以及来自业务负责人（而非仅技术团队）的明确授权。这些阶段转换节点既是运营节点，更是商务付款里程碑。
22
XXII. Regulatory Compliance Positioning
二十二、监管合规定位
Enterprise AI deployment in B2B contexts increasingly intersects with regulatory frameworks. FDE projects must conduct a regulatory applicability assessment at project initiation — not as a legal add-on at project close.B2B 语境下的企业级 AI 部署日益与各类监管合规框架发生交集。FDE 项目必须在立项时开展监管适用性评估——而非在项目结项时将其作为法务补充事项。
22.1
22.1 Key Regulatory Frameworks
22.1 核心监管框架
| English source | 中文原文 |
|---|---|
| EU AI Act AI systems deployed in EU; risk-tiered requirements Industrial systems affecting worker safety or critical infrastructure are likely classified as "high-risk"; require conformity assessment, human oversight obligations, and technical documentation | 欧盟 AI 法案 在欧盟部署的 AI 系统；基于风险分级的要求 影响工人安全或关键基础设施的工业系统极可能被归为“高风险”；需要符合性评估、人工监督义务与完整技术文档 |
| GDPR / PIPL / State Privacy Laws Personal data processing Relevant when enterprise AI systems process employee or customer data; affects RAG corpus design and data lineage requirements | GDPR / 个人信息保护法（PIPL）等 个人数据处理 当企业 AI 系统处理员工或客户数据时相关；直接影响 RAG 语料库设计与数据血缘要求 |
| Sector-Specific Regulations Energy (NERC CIP), Finance (SR 11-7), Healthcare (FDA SaMD) Domain-dependent; often predate AI-specific law but impose model validation, audit requirements, and explainability obligations | 特定行业监管规程 能源（NERC CIP）、金融（SR 11-7）、医疗（FDA SaMD） 视具体领域而定；通常早于 AI 专项立法，但提出了模型验证、审计要求与可解释性义务 |
| Export Control (BIS / OFAC) Cross-border data and technology transfer Directly relevant to cross-border data rules in Section 7.2; affects cloud provider selection and data residency | 出口管制（BIS / OFAC 等） 跨国/跨境数据与技术转移 与第七.二节的数据出境规则直接相关；影响云服务商选择与数据本地化留存 |
22.2
22.2 Compliance Architecture Implications
22.2 合规对架构的启示
The EU AI Act's "high-risk AI system" requirements for industrial applications align almost exactly with the Level D/E human authorization model and the Evidence Package (Section XIII). This is a commercial argument for the FDE architecture — not merely a compliance burden. Clients operating in regulated industries benefit from a system that is compliance-ready by construction.欧盟 AI 法案针对工业应用中“高风险 AI 系统”的要求，几乎与本说明书提出的 D/E 类算子人工授权模型及证据包（第十三节）完全对齐。这是 FDE 架构的巨大商务优势——而非仅仅是一项合规负担。在强监管行业运营的客户，能从这种“开箱即合规”的架构设计中直接获益。
The Assurance & Evidence Plane (Plane IV) must be designed with regulatory audit artifacts as first-class outputs. Technical documentation packages required under the EU AI Act can be substantially satisfied by the Evidence Package and the operator/prompt version registry, provided these are designed with the regulatory schema in mind.保证与证据平面（第四平面）在设计时必须将监管审计制品作为一等公民级别的输出。只要在设计时考虑到了监管 Schema，欧盟 AI 法案所要求的技术文档包在很大程度上可由证据包以及算子/Prompt 版本注册表直接满足。
FDE teams should maintain a regulatory mapping document for each industry vertical, identifying which operators, workflows, and evidence artifacts correspond to which regulatory requirements. This document becomes a reusable asset in the Industry Pack.FDE 团队应为每个垂直行业维护一份监管映射文档，明确指出哪些算子、工作流与证据制品对应哪些具体的监管条款。该文档将成为行业包中可复用的资产。
23
XXIII. Integration Architecture for Industrial Operational Technology
二十三、工业操作技术（OT）的集成架构
Industrial FDE scenarios — Digital Twins, Energy Management, O&M — require integration across both IT (Information Technology) and OT (Operational Technology) stacks. These are fundamentally different integration contexts with different security models, protocols, latency requirements, and failure modes.工业 FDE 场景——数字孪生、能源管理、设备运维——需要跨越 IT（信息技术）与 OT（操作技术）两大技术栈进行集成。这是两个有着不同安全模型、传输协议、延迟要求与故障模式的根本不同的集成语境。
23.1
23.1 OT Integration Protocols
23.1 OT 集成协议
| English source | 中文原文 |
|---|---|
| OPC-UA Industrial device data (PLCs, SCADA, sensors) Standard for structured equipment telemetry; supports security profiles; recommended primary IT/OT integration boundary | OPC-UA 工业设备数据（PLC、SCADA、传感器） 结构化设备遥测数据的标准；支持安全配置文件；推荐作为主要的 IT/OT 集成边界 |
| MQTT / Sparkplug B Lightweight IoT telemetry, edge-to-cloud Appropriate for high-frequency sensor data where OPC-UA overhead is prohibitive | MQTT / Sparkplug B 轻量级 IoT 遥测，边缘到云端 适用于 OPC-UA 协议开销过大的高频传感器数据传输 |
| Modbus / DNP3 Legacy field devices Read-only integration only; never write-back via AI-generated commands without hardware interlock | Modbus / DNP3 传统现场设备 仅限只读集成；严禁在未经硬件联锁的情况下通过 AI 生成的指令进行反写 |
| ERP APIs (SAP, Oracle) Business data (work orders, asset master data, cost centers) Use vendor-provided APIs with service account identities; never direct database access | ERP API (SAP、Oracle等) 业务数据（工单、资产主数据、成本中心） 使用厂商提供的 API 及服务账号身份；严禁直接读取底层数据库 |
23.2
23.2 The IT/OT Boundary
23.2 IT/OT 边界
The boundary between the AI system and physical operational systems must be enforced at two levels simultaneously:AI 系统与物理操作系统之间的边界必须在两个层面上同时强制实施：
English flow
AI System (IT Domain) │ ▼ [Validated Setpoint Request] ──> [IT/OT Gateway with Hardware Interlock] │ [Physical Safety Relay] │ ▼ PLC / DCS (OT Domain)
中文流程
AI 系统 (IT 域) │ ▼ [ 经过校验的设定值请求 ] ──> [ 带硬件联锁的 IT/OT 网关 ] │ [ 物理安全继电器 ] │ ▼ PLC / DCS (OT 域)
The AI system never writes directly to OT. The gateway enforces range limits and safety interlocks in hardware or firmware — independently of the software stack. This is not redundancy; it is defense-in-depth across trust domains. A software bug in the AI system or the operator code cannot bypass a hardware safety relay.AI 系统绝不直接向 OT 域写入数据。网关独立于软件栈，在硬件或固件层强制执行数值范围限制和安全联锁。这不是冗余设计，而是跨信任域的纵深防御。AI 系统或算子代码中的软件 Bug，绝对无法绕过物理硬件安全继电器。
Failure mode analysis must explicitly document what happens to physical equipment if each software component fails. The answer for every component should be: equipment returns to or remains in a safe state.故障模式分析（FMEA）必须明确记录：当每个软件组件失效时，物理设备会发生什么。每一个组件的故障应对答案都必须是：设备恢复到或保持在安全状态。
23.3
23.3 Air-Gapped and Limited Connectivity Scenarios
23.3 物理隔离与受限网络场景
Many industrial environments have intermittent or prohibited external network connectivity. The cognitive layer architecture must account for:许多工业环境的外部网络连接受限甚至完全物理隔离（Air-gapped）。认知层架构必须考虑：
Edge inference capability for offline/air-gapped scenarios — smaller models, quantized, running on industrial-grade hardware with appropriate certifications离线/物理隔离场景下的边缘推理能力——部署经过量化的较小模型，运行在具备相应工业认证的硬件设备上
Sync-on-connect update patterns for document indices, operator libraries, and model weights when connectivity is restored网络连接恢复时的“连网即同步”更新模式，用以同步文档索引、算子库和模型权重
Graceful degradation documentation specifying what the system can and cannot do in disconnected mode, and how operators are clearly notified of the degraded state明确的优雅降级文档说明，规定系统在断网模式下能做什么、不能做什么，以及如何向操作员清晰提示降级状态
Local Evidence Package generation ensuring that audit trails continue to be produced even when the system is operating offline本地证据包生成能力，确保即使系统在离线状态下运行，审计追踪依然能够持续产生
24
XXIV. Cognitive Layer Evaluation Framework
二十四、认知层评估框架
Sections VIII and X address RAG retrieval metrics and operator contract verification. But the cognitive layer's overall performance — the quality of its extractions, recommendations, and explanations — requires a dedicated evaluation framework that is maintained throughout the system's operational life.第八节和第十节分别探讨了 RAG 检索指标和算子契约校验。但认知层的整体表现——包括提取、建议和解释的质量——需要一套在系统整个运营生命周期内持续维护的专门评估框架。
24.1
24.1 Evaluation Dimensions
24.1 评估维度
| English source | 中文原文 |
|---|---|
| Extraction Accuracy Human-labeled golden set; precision/recall per field type ≥ 95% for pricing and contractual fields; ≥ 90% for free-text classification | 提取准确率 人工标注的黄金数据集；按字段类型计算精确率/召回率 价格与合同条款字段 ≥ 95%；自由文本分类 ≥ 90% |
| Recommendation Relevance Business expert panel review of historical recommendations vs. system outputs on identical inputs Defined agreement rate with domain expert | 建议相关性 业务专家面板对比审查：针对完全相同的输入，对比历史人工建议与系统输出 与领域专家达成预先定义的认同率 |
| Explanation Fidelity Verify that each cited evidence source actually supports the stated conclusion 100% of citations must be traceable to source documents in the evidence record | 解释忠实度 验证引用的每条证据来源是否确实支撑所给出的结论 100% 的引用必须能追溯到证据记录中的源文档 |
| Boundary Respect Adversarial prompts designed to elicit out-of-scope or Level D/E outputs Zero tolerance for unsanctioned authorization-level outputs | 边界合规性 设计对抗性 Prompt，试图诱导系统输出越界或 D/E 类授权指令 对未授权越权指令输出零容忍 |
| Temporal Stability Re-run golden test set on a defined schedule; alert on accuracy degradation Alert threshold: any metric declining > 5% between evaluation cycles | 时间稳定性 按既定周期重新运行黄金测试集；对准确率下降发出预警 预警阈值：评估周期间任何指标下滑 > 5% |
24.2
24.2 Evaluation Governance
24.2 评估治理
Evaluation results must be included in the Evidence Package for project acceptance — evaluation is not a pre-deployment activity, it is a continuous operational obligation评估结果必须纳入项目验收证据包。评估不是上线前做一次就结束，而是持续的运营义务。
Golden test sets should be expanded over time with real production cases (anonymized) — especially exception cases the system initially handled poorly黄金测试集应随着时间推移，使用真实生产案例（经脱敏）不断扩充——特别是系统初期处理不佳的例外案例
A model update policy must define what triggers a mandatory re-evaluation: provider model version changes, prompt changes, document corpus additions above a size threshold, or a behavioral drift alert from the observability layer模型更新策略必须明确定义强制重新评估的触发条件：模型厂商更新模型版本、Prompt 变更、文档库增量超过设定阈值，或可观测性层发出行为漂移预警
Evaluation results should be reviewed jointly by the FDE team and the designated client technical owner on a defined cadence — this review is a contractual obligation, not an optional serviceFDE 团队应与客户指定的技术负责人按约定节奏共同评审结果；这项评审是合同义务，不是可选服务。
25
Conclusion
结语
The ultimate mission of an FDE is neither to blindly plug LLMs into enterprise environments nor to churn out isolated software features for clients. It is to construct a Trustworthy Execution System that seamlessly bridges business expertise, data, algorithms, organizational accountability, and real-world execution.FDE 的最终使命，不是把大模型简单接入企业，也不是替客户开发更多孤立的软件功能，而是建设一套连接业务知识、数据、算法、组织责任和生产执行的可信执行体系。
This system must ensure that:这套体系应当做到：
Business problems are modelable业务问题可建模
Implicit expertise is structurable隐性经验可结构化
Execution logic is verifiable执行逻辑可验证
System outputs are reproducible系统结果可复现
Anomalies and risks are controllable异常风险可控制
Liability processes are traceable责任过程可追溯
Delivery capabilities are replicable交付能力可复制
Commercial value is provable商业价值可证明
When probabilistic cognitive capabilities are tightly bounded within deterministic execution constraints, and when every business execution is backed by source attribution, rule versions, prompt versions, approval logs, and acceptance evidence — AI ascends from a mere productivity gadget into a production-grade asset that enterprises can trust, purchase, and operate for the long term.只有把概率性认知能力收进确定性的执行边界，并为每次业务运行保留数据来源、规则版本、Prompt 版本、审批记录和验收证据，AI 才能从辅助工具变成企业敢于信任、采购并长期运营的生产级资产。
Sustaining that trust requires more than a correct architecture at launch. It requires continuous evaluation of cognitive layer performance, active monitoring of behavioral drift, disciplined prompt governance, principled cost management, and genuine investment in the organizational adoption that makes technical capability into realized business value.要维持这种信任，光有一套上线时正确的架构还不够。还要持续评估认知层性能、主动监测行为漂移、严格治理 Prompt、管住成本，并真正投入组织推广；只有这样，技术能力才会变成已经实现的业务价值。
This is the foundational mandate of the FDE discipline.这也是 FDE 学科与工程实践的根本使命。
Document Version 1.1 — Revised and Extended文档版本 1.1 —— 修订与扩展版
Original framework developed for industrial B2B AI deployment practice.原始框架专为工业及 B2B AI 落地部署实践而开发。
Sections XIX–XXIV and all extensions integrated August 2026.第十九至二十四节及所有扩展内容于 2026 年 8 月集成完毕。