企业官网建设流程全解析

1. 为什么“AI 写代码”已经不够了

过去两年，AI 编程工具经历了肉眼可见的进化。最早大家习惯把需求粘贴给 AI，让它生成一段函数、一个页面或者一条 SQL，然后自己复制回项目里改。这个阶段本质上是“AI 辅助编码”，AI 的定位是更聪明的自动补全。

但真正做过企业级项目的人会发现，这套玩法在真实业务场景中很快就会撞墙。

一个典型的中台项目，往往涉及几十个微服务、多套环境、若干外部系统接口，还附带权限模型、审计日志、消息队列、数据一致性等复杂约束。你把一个有业务背景的 Issue 粘给 AI，它确实能写出代码，但写出来的代码大概率没有接入公司内部的 RAG 知识库，没有遵循团队的 Skill 规范，没有放进统一的 Harness 执行流程里，更没有经过可观测的链路验证。

换句话说：AI 能写代码，但写不出“符合企业工程约束的代码”。

这时候，一个新的角色和工作方式开始浮出水面：FDE。

FDE 的字面含义目前在行业内还没有完全统一的定义，不同团队对它有不同的解释。但从最近的技术讨论热度和岗位需求来看，它指向的核心方向是一致的那就是Feature Driven Engineering，特性驱动工程，以及对应的工程师角色Feature Driven Engineer。简单说，FDE 是在 AI Agent 深度参与研发的背景下，负责把业务需求转化为 AI 可执行的 Feature 定义，并通过 Harness、Skills、RAG、LangChain 等工具链，编排、约束、验证整个 AI 应用开发过程的工程师。

这篇文章想做的事情很具体：把 FDE 这个概念拆开，讲清楚它和传统开发角色的区别，然后给出一个可以直接实践的路径，从环境搭建、LangChain Agent 构建、Skills 编写、RAG 知识库接入，到最后的验证与排错。读完你应该能回答一个问题：如果我的团队要往 FDE 方向走，第一步应该做什么。

2. FDE 的核心概念与适用场景

2.1 从“写代码的人”到“定义 AI 工作流的人”

传统研发流程里，需求分析、技术设计、编码、测试、上线是清晰分工的。业务人员提需求，产品经理转需求，后端工程师写接口，前端工程师做页面，测试工程师验证功能。AI 编程工具出现后，这个链条被压缩了，但压缩的部分主要集中在“编码”这一环。

FDE 做的事情，是把压缩链条再往前推进一层。它不再满足于“AI 帮我写这段代码”，而是思考“如何让 AI 在整个 Feature 的粒度上，自主完成从需求理解、方案设计、代码生成到验证交付的完整链路”。

这听起来很像全栈工程师加上 AI 能力，但更准确的类比是“AI 应用的导演”。写代码仍然是基本功，但更重要的是：

• 把模糊业务需求拆解成 AI 能理解的 Feature 描述；
• 设计 Agent 执行流程，也就是 Harness；
• 沉淀团队能力，让 AI 遵循统一规范，也就是 Skills；
• 接好企业知识库，让 AI 的回答和代码有据可依，也就是 RAG。

2.2 FDE 和前后端工程师的本质区别

如果用一个表格来对比，会清楚很多：

从这个表格能看出，FDE 不是“会写代码的产品经理”，也不是“懂 AI 的全栈工程师”。它更像是在传统工程能力和 AI 能力之间，增加了一层“编排与治理”的职能。

2.3 FDE 的典型工作场景

什么样的团队最需要 FDE？结合讨论热度，主要是这三类场景：

第一类：企业内部 AI 应用开发。公司要做一个基于私有知识库的问答系统、智能客服或者代码助手，这些应用不能只靠一个 Prompt 搞定，需要接入内部文档、规范用户权限、审计模型输出。FDE 负责把知识库接入、Retrieval 逻辑、Agent 编排和合规校验做成标准流程。

第二类：AI 辅助研发效能建设。团队引入 AI 编程助手后，发现每个人用出来的效果差异巨大。有人能让 AI 完成 80% 的工作，有人只有 20%。FDE 的职责就是把高手的用法沉淀成 Skills，让普通开发者也能高质量地使用 AI。

第三类：复杂 Feature 的自动化开发。当一个需求涉及前端页面、后端接口、数据库变更和测试用例时，FDE 会把这些拆解成 AI Agent 可以逐步执行的任务链，再把关键节点接上 RAG 知识库和人工审批。

这三类场景的共同点，都要求了 FDE 不能只懂 Prompt，还需要具备工程化思维、工具链搭建能力和对模型边界的清晰认知。

3. LangChain、Harness、Skills、RAG 到底是什么

FDE 的落地离不开四个技术支柱，这里先用最朴素的语言解释清楚。

3.1 LangChain：连接模型和工具的“脚手架”

LangChain 是目前最流行的 LLM 应用开发框架之一，它的核心价值是帮开发者把大模型和外部工具、知识库、记忆模块连接到一起。你可以把它理解成一套标准化的积木系统，里面有处理 Prompt 的模块、调用模型的模块、管理记忆的模块、调用外部 API 的模块，以及把这些模块串成链路的 Chain/Agent 机制。

日常开发中，LangChain 解决的是“模型不知道你的业务数据”的问题。它通过 RAG 把企业文档检索出来塞进上下文，通过 Agent 让模型决定调用哪个工具，通过 Memory 让多轮对话有记忆。对于 FDE 来说，LangChain 是搭建 AI 应用的骨架。

值得注意的一个对比是 LangChain 和 LangGraph。LangGraph 是在 LangChain 之上构建的图状态编排框架，它把 Agent 的执行过程建模为一张状态图，每个节点是一个处理步骤，边是状态转移。LangChain 更偏“链路”，LangGraph 更偏“图状态”。如果只是做一个简单的“检索后回答”，LangChain 够用；如果要编排复杂的、带分支和循环的 Agent 流程，LangGraph 更合适。实际项目中，两者经常配合使用。

3.2 Harness：AI 执行流程的“缰绳”

Harness 这个词原本是“马具、挽具”的意思，在 AI 工程领域，它被用来指代“控制 AI Agent 执行过程的框架和约束集合”。

如果把大模型看作一台动力强劲但容易跑偏的引擎，Harness 就是给它装上的方向盘、刹车和仪表盘。一个完整的 Harness 通常包含：

• 任务定义与拆解逻辑；
• Agent 可用的工具清单和调用权限；
• 每一步执行的校验规则；
• 安全边界和审批机制；
• 日志记录与可观测性。

从热词里能看到，DeepSeek Harness、Codex Harness 这类概念在开发者社区里讨论度很高。这背后反映了一个趋势：单纯的模型能力已经不再是瓶颈，怎么给模型套上一个可控、可观测、可回滚的执行框架，才是企业落地的关键。FDE 很大一部分工作就是在设计、配置和维护这些 Harness。

3.3 Skills：把能力封装成 AI 可复用的“技能包”

Skills 的理解方式可以这样想：你希望 AI 生成的代码遵循你们团队的前端规范、希望它写接口文档时用固定模板、希望它在处理日期格式时统一走某个工具函数。这些“规范”和“能力”如果每次都在 Prompt 里手动粘贴，效率低且容易遗漏。更好的办法是把它封装成一个 Skill。

一个 Skill 通常包含：

• 描述：这个技能在什么场景下使用；
• 指令：AI 应该按照什么步骤执行；
• 示例：给定的输入输出范例；
• 工具引用：可调用的脚本、API 或数据源。

AI Skills 的写法在社区里已经形成了初步范式，本质就是“结构化的上下文 + 可执行的动作”。对于团队来说，把常用的编码规范、部署流程、测试策略沉淀成 Skills，相当于给 AI 装上了团队内部的经验模块。这也是 FDE 的核心产出物之一。

3.4 RAG：让 AI 应用接入企业知识的“外挂”

RAG，Retrieval-Augmented Generation，检索增强生成。它的原理很直白：模型不知道企业内部的知识，但你可以先把相关文档检索出来，塞进 Prompt 上下文里，再让模型基于这些内容生成答案。

在 RAG 知识库的工程落地中，常见的关键点包括：

• 文档解析与切片策略；
• Embedding 模型选择；
• 向量数据库选型；
• 检索策略：关键词检索、向量检索还是混合检索；
• 评估指标：命中率、忠实度、答案相关性等。

Agentic RAG 是最近讨论较多的进阶方向。传统 RAG 是一步检索然后生成，Agentic RAG 则让 Agent 自主决定是否需要检索、检索几次、用什么关键词检索、是否需要调用外部工具补充信息。它把 RAG 从“查一次字典”升级为“自己决定怎么查字典”。

4. FDE 从入门到落地的学习路径

如果现在开始向 FDE 方向转型，不建议一上来就追最新的框架和概念，而是按下面的路径循序渐进。

4.1 第一步：掌握 Prompt 工程基础

很多人觉得 Prompt 很简单，实际不是。FDE 要写的不是“帮我写个登录页面”这种一次性 Prompt，而是可复用、可评估、可维护的 Prompt 模板。学习重点包括：

• 角色设定和任务描述的写法；
• 少样本示例的设计；
• 输出格式约束；
• 边界条件声明；
• Prompt 版本管理。

4.2 第二步：学透 LangChain 核心模块

LangChain 官方文档中的核心模块值得完整过一遍：Model I/O、Retrieval、Memory、Chains、Agents。不需要死记 API，但要理解每个模块解决什么问题。比如 Agents 引入后，模型不再只是“生成文本”，而是可以“决定调用工具并观察结果”，这是从聊天机器人走向 AI Agent 的关键一步。

4.3 第三步：动手搭一个 RAG 全流程

选一个垂直领域，比如公司内部 IT 支持文档，搭建一个最小可用的 RAG 系统。过程中会碰到：文档怎么切、向量化后搜不到准确结果怎么办、多轮对话中如何带历史、知识更新后索引怎么重建。这些问题踩一遍，比看十篇理论文章都有用。

4.4 第四步：实践 Agent 与 Harness

从 LangChain 的 Agent 机制开始，实现一个能调用搜索、计算器、数据库查询的 Agent。然后尝试引入约束：限制工具调用次数、设置超时、增加输出校验、记录完整轨迹。当你能给 Agent 套上这些约束时，你就已经在写 Harness 了。

4.5 第五步：沉淀 Skills

观察团队中 20% 高绩效 AI 使用者的工作方式，把他们高频率使用的 Prompt、工具调用方式、代码规范整合成 Skills。这一步的关键不是技术，而是抽象能力。

5. 环境准备与基础配置

下面进入实操环节。本文以 Python 3.10 以上版本为例，演示一套 FDE 日常工作中最典型的工作流：用 LangChain 构建一个带 RAG 检索能力的 Agent，并加上 Harness 约束。

5.1 安装基础依赖

先创建虚拟环境并安装核心依赖。版本号请以实际安装时为准，重点理解依赖之间的关系。

python -m venv fde-demo source fde-demo/bin/activate pip install langchain pip install langchain-community pip install langchain-openai pip install langgraph pip install chromadb pip install pypdf

简单说明各依赖的作用：

• langchain：核心框架；
• langchain-community：社区提供的第三方集成；
• langchain-openai：OpenAI 模型的封装，即使你使用的是其他兼容接口，也可以通过调整配置来复用这套代码；
• langgraph：图状态编排，用于构建更可控的 Agent；
• chromadb：轻量级向量数据库，适合本地实践；
• pypdf：解析 PDF 文档，用于知识库构建。

5.2 配置模型访问

这里要特别说明：FDE 实践并不绑定某一家模型服务。你可以根据团队实际情况选择 OpenAI、DeepSeek、通义千问、文心一言或开源模型。关键是抽象出一层接口。

在项目根目录创建.env文件：

BASE_URL=https://api.your-model-provider.com/v1 API_KEY=your-api-key MODEL_NAME=your-model-name

再创建一个简单的配置读取模块，这样后续代码不依赖硬编码：

# config.py import os from dotenv import load_dotenv load_dotenv() BASE_URL = os.getenv("BASE_URL", "") API_KEY = os.getenv("API_KEY", "") MODEL_NAME = os.getenv("MODEL_NAME", "gpt-4o-mini")

如果模型提供方兼容 OpenAI 接口格式，LangChain 可以直接用ChatOpenAI类，只需修改base_url和api_key。这是目前绝大多数模型服务的通用做法。

6. 完整示例：构建一个带 RAG 的 LangChain Agent

下面用一个真实场景贯穿整个示例：假设企业内部有一份 AI 编程规范文档，我们希望 AI 在回答编码问题之前，先检索这份文档，再结合检索结果回答。同时，Agent 要能够调用一个“代码规范检查工具”，并记录执行轨迹。

6.1 构建 RAG 知识库

首先把文档加载进来并切片，存入向量数据库。这里的pdf_loader假设接收一个 PDF 文件路径：

# rag_index.py from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader = PyPDFLoader("coding_standards.pdf") documents = loader.load() text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "；", " ", ""] ) docs = text_splitter.split_documents(documents) embeddings = OpenAIEmbeddings( model="text-embedding-3-small", base_url=BASE_URL, api_key=API_KEY, ) vectorstore = Chroma.from_documents( documents=docs, embedding=embeddings, persist_directory="./chroma_db" )

这段代码做的事情是：加载 PDF、按 500 字符切片、生成向量、存入 Chroma。切片策略有两个点容易踩坑：

• chunk_overlap太小，跨段落丢失语义；
• 分隔符顺序要按优先级排列，中文场景下要加入句号和分号。

6.2 一个最简单的 RAG 问答链

先不看 Agent，用最传统的 RetrievalQA 链路验证知识库是否建好：

# simple_rag.py from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA from langchain_community.vectorstores import Chroma llm = ChatOpenAI( model=MODEL_NAME, base_url=BASE_URL, api_key=API_KEY, temperature=0.2, ) vectorstore = Chroma( persist_directory="./chroma_db", embedding_function=OpenAIEmbeddings( model="text-embedding-3-small", base_url=BASE_URL, api_key=API_KEY, ), ) qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), ) question = "团队对 Python 函数命名有什么要求？" answer = qa_chain.invoke({"query": question}) print(answer["result"])

如果这一步能输出和文档内容一致的答案，说明知识库链路已经打通。

6.3 构建带 Harness 约束的 Agent

接下来进入本次示例的重点：不再使用直接问答链，而是构建一个 Agent，让模型自己决定是否检索、是否调用工具，同时限定它不能调用未授权工具。这部分就是 FDE 设计 Harness 的核心代码体现。

# fde_agent.py from typing import Optional, Type from langchain_openai import ChatOpenAI from langchain_community.vectorstores import Chroma from langchain.tools import BaseTool, tool from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from pydantic import BaseModel, Field # 1. 定义工具入参 schema class CodeReviewInput(BaseModel): code: str = Field(description="需要检查的代码内容") language: str = Field(description="代码语言，例如 python、java") # 2. 定义代码规范检查工具 @tool("code_review", args_schema=CodeReviewInput) def code_review_tool(code: str, language: str) -> str: """ 对输入的代码做基础规范检查，检查命名、缩进、行长度等。 这是 FDE 团队在 Harness 中注册的受控工具，AI 只能调用该工具， 无法访问文件系统或执行任意命令。 """ issues = [] if language == "python": if any(line.strip().startswith("def ") for line in code.splitlines()): max_line_len = 0 for line in code.splitlines(): if len(line) > max_line_len: max_line_len = len(line) if max_line_len > 120: issues.append(f"存在超过 120 字符的行，最长 {max_line_len} 字符") if " " not in code and "\t" in code: issues.append("建议使用 4 空格缩进而不是 Tab") if len([line for line in code.splitlines() if line.strip().endswith(":")]) > 3: issues.append("函数过多，建议拆分子模块") if not issues: return "未发现明显规范问题" return "发现潜在问题:\n" + "\n".join(issues) # 3. 定义 Harness 约束：白名单工具集 ALLOWED_TOOLS = [code_review_tool] # 4. 构建带检索能力的 retriever vectorstore = Chroma( persist_directory="./chroma_db", embedding_function=OpenAIEmbeddings( model="text-embedding-3-small", base_url=BASE_URL, api_key=API_KEY, ), ) retriever_tool = tool( "coding_standards_search", lambda query: "\n".join([doc.page_content for doc in vectorstore.as_retriever(search_kwargs={"k": 3}).invoke(query)]) )() tools = ALLOWED_TOOLS + [retriever_tool] # 5. 构建 Prompt，明确 Agent 的任务边界 prompt = ChatPromptTemplate.from_messages([ ("system", """你是企业内部的编码助手，必须遵循以下约束： 1. 回答代码规范问题前，优先调用 coding_standards_search 检索团队知识库。 2. 只能调用 tools 中声明的工具，禁止访问文件系统或执行任意命令。 3. 如果用户要求做知识库之外的事情，直接拒绝并说明权限边界。 4. 每次调用工具后，必须说明调用原因和结果摘要。"""), MessagesPlaceholder(variable_name="chat_history"), ("user", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), ]) # 6. 初始化模型与 Agent llm = ChatOpenAI( model=MODEL_NAME, base_url=BASE_URL, api_key=API_KEY, temperature=0.2, ) agent = create_openai_tools_agent(llm, tools, prompt) agent_executor = AgentExecutor( agent=agent, tools=tools, verbose=True, max_iterations=5, handle_parsing_errors=True, return_intermediate_steps=True, )

这段代码是理解 Harness 的极好实例。它有四个关键设计：

第一，工具白名单。ALLOWED_TOOLS只包含代码检查工具和知识库检索工具，模型无法调用其他任何工具。这是 Harness 的安全边界。

第二，入参 Schema。CodeReviewInput强制模型在调用工具时输出结构化参数，避免模型自由发挥传错参数。

第三，系统提示词中的约束声明。这一步定义了 Agent 的行为边界，包括“先检索再回答”的流程和“拒绝越权请求”的原则。

第四，AgentExecutor 的参数。max_iterations=5限制最大循环次数，避免模型陷入无限工具调用；return_intermediate_steps=True保留执行轨迹，方便事后审计。

6.4 LangGraph 版本的流程控制

LangChain 的 AgentExecutor 足够跑通简单场景，但如果你的 Harness 需要更精细的流程控制，例如检索失败时重试、某个步骤需要人工审批、条件分支执行，那么 LangGraph 会更合适。LangGraph 把流程建模为状态图，每个节点是处理逻辑，边是转移条件。

一个极简的 LangGraph 示例思路如下：

# langgraph_harness.py（核心结构示意） from langgraph.graph import StateGraph class HarnessState(dict): question: str context: str answer: str approved: bool def retrieve_node(state): # 检索知识库，写入 context return {"context": retriever.invoke(state["question"])} def check_approval(state): # 模拟人工审批：检索完成且上下文不为空才继续 state["approved"] = len(state["context"]) > 0 return state def generate_node(state): # 基于 context 生成答案 return {"answer": llm.invoke(state["question"] + state["context"])} # 构建图 graph = StateGraph(HarnessState) graph.add_node("retrieve", retrieve_node) graph.add_node("check", check_approval) graph.add_node("generate", generate_node) graph.add_edge("retrieve", "check") graph.add_conditional_edges("check", lambda s: "generate" if s["approved"] else "__end__") graph.set_entry_point("retrieve")

这种图结构的好处是：流程的每个节点都可以单独测试、单独加日志、单独插入人工审批。在实际企业级 FDE 项目中，LangGraph 这类状态编排框架是建设 Harness 的基础设施。

7. 运行结果与效果验证

运行上面的fde_agent.py时，可以用一个简单的测试入口：

# test_agent.py from fde_agent import agent_executor def test_agent_retrieval_flow(): result = agent_executor.invoke({ "input": "根据团队规范，Python 函数命名应该注意什么？", "chat_history": [] }) print("最终答案:", result["output"]) print("执行轨迹:", result["intermediate_steps"]) if __name__ == "__main__": test_agent_retrieval_flow()

预期行为是：

1. Agent 先调用coding_standards_search，从知识库中检索相关规范；
2. Agent 结合检索结果生成回答；
3. 如果在回答过程中需要检查代码示例，Agent 会调用code_review工具；
4. 整个过程在verbose=True模式下会打印每次工具调用的输入输出。

验证成功的关键信号，不是“回答看起来合理”，而是 Agent 确实执行了工具调用链。这是 FDE 与普通 Prompt 用户的本质差异：普通用户依赖模型的记忆和推理，FDE 要求系统在每次执行时有可追溯的证据链。

如果运行失败，按这个顺序排查：

8. FDE 在企业落地中的最佳实践

代码能跑通只是第一步。企业级 AI 应用落地真正考验的是工程治理能力。下面这些建议，全部来自实际踩坑后的经验总结。

8.1 Harness 设计：先定边界，再开能力

很多团队做 AI Agent 时的第一反应是把所有工具都开放给模型，让它“自由发挥”。这是大忌，模型不是人，它对权限边界没有敬畏感，一旦某个工具触发破坏性操作，后果难以追踪。

推荐做法是：工具白名单制。每个工具都要明确声明用途、入参、可能的风险等级。FDE 设计的 Harness 至少要有三层约束：

• 可用工具白名单；
• 模型最大调用次数和超时时间；
• 高风险操作的人工审批节点。

8.2 Skills 沉淀：从优秀案例中抽象

Skill 不是凭空写出来的，而是从真实使用案例中提取出来的。如果团队里有开发者使用 AI 的成功率明显高于其他人，FDE 应该去分析他做了什么：是更会拆解需求？还是更会提供上下文？然后把这些经验结构化为 Skill 包。

一个完整的 Skill 包应包含：

• 适用场景描述，让 Agent 知道什么时候应该激活该 Skill；
• 输入要求，例如 Issue 模板、代码上下文；
• 执行步骤，最好细分到可操作级别；
• 正反示例；
• 验证清单。

8.3 RAG 知识库：质量比数量重要

很多团队以为 RAG 效果不好是因为文档不够多，实际恰恰相反。文档越多，检索噪音越大。FDE 要做的不是“把文档都丢进向量库”，而是构建评审体系：

• 定期清理过期内容；
• 对高频提问做标注；
• 用评估指标量化检索质量；
• 建立“知识运营”机制，而非一次性导入。

8.4 安全与合规：AI 应用的生命线

企业 AI 应用必然涉及数据安全问题。FDE 在落地过程中要特别注意：

• 敏感数据脱敏后再进入向量库；
• 模型输出内容的合规校验；
• 工具调用的审计日志；
• 最小权限原则贯穿整个 Harness 设计。

8.5 可观测性：没有日志就没有运营

每次 Agent 的执行轨迹、工具调用结果、token 消耗、响应延迟都应该被记录。这样当线上出问题时，才能快速定位是模型问题、知识库问题还是工具问题。

9. 常见问题与排查方法汇总

为了便于日常使用，这里把 FDE 实践中最常见的问题整理成一张表：

10. 总结与后续学习方向

FDE 这个角色之所以在当下受到关注，根源在于 AI 编程正在经历一次范式转移：从“模型生成代码”走向“模型参与研发全流程”。在这个转移过程中，工程化约束变得比模型能力更重要。FDE 的职责，是把模型放进一个可控制的框架里，让 AI 在正确的知识、正确的工具、正确的流程下工作。

这篇文章从概念讲到了代码，核心是想说明一个判断：FDE 不是一个新的职位头衔，而是一组新能力的组合。它需要你懂 LangChain 这类框架的底层机制，能设计带约束的 Harness，会沉淀团队 Skills，也理解 RAG 知识库的工程细节。你可以不用每一项都精通，但如果你正在做企业级 AI 应用，这四项能力迟早都会遇到。

实际操作时，建议不要急着在公司里推广“FDE”这个概念，而是先用一个真实场景把完整链跑通：选一个业务知识库，接上 RAG，套上 Agent，加好日志和约束，让团队看到 AI 应用的可控性和可观测性。等这套流程稳定了，再沉淀成规范和 Skills，逐步扩大应用范围。

后续值得深挖的方向包括：LangGraph 的复杂状态编排、Agentic RAG 的自主检索策略、Skill 包的版本管理与评估、基于评估数据集的大模型输出回归测试。这些话题每一个都值得单独写一篇实战文章。对于正在从传统开发转向 AI 工程实践的人来说，这个方向的门槛不在模型理论，而在工程体系的设计能力，而这恰恰是后端与前端工程师的既有优势。