您在正常工作日打开笔记本电脑。有一个新请求，生成一个数据管道，用于同步客户数据、运行验证并提供分析就绪表。通常，你会开始绘制 DAG、编写样板代码、测试转换和优化分区。但今天不是。

今天，您在 Windsurf 中编写一个简短的提示，它会为您生成整个 DAG。同时，Cursor 已经编写了 SQL 转换，其中包含测试和文档字符串。单击运行。数据管道有效。没有配置文件，没有长时间的调试会话，没有切换选项卡五十次。感觉很高效。感觉很快。感觉......不同。如果您希望掌握这种新的人工智能优先数据工程方法，像 ProjectPro 这样的平台可以帮助您亲身体验实用的企业级项目，这些项目弥合了传统管道和现代人工智能工作流程之间的差距。

那是因为它不同。我们已经进入了数据工程的新阶段，在这个阶段，人工智能工具不仅支持数据工程师的工作，还支持数据工程师的工作。他们开始为你做这件事。这迫使人们提出一个令人不舒服但必要的问题：

这给数据工程师留下了什么？人工智能会取代数据工程师吗？

让我们澄清一件事：人工智能并不是为了取代数据工程师。它在这里取代不需要原创思维的任务。提示驱动的工具非常擅长编写代码，但它们无法推理业务逻辑、系统设计中的权衡或生产仪表板中缓慢查询的微妙成本。

此数据工程路线图是您在人工智能时代保持领先地位的指南。它将帮助您将注意力从做工作转移到思考系统。从修复管道到设计平台。从处理任务到驱动策略。因为未来属于数据工程师，他们不仅编写代码，还拥有架构、了解业务并指导可扩展的决策。

随着人工智能接管更多的执行工作，数据工程师必须专注于机器无法做的事情，例如理解上下文、设计更好的系统、提高数据质量和推动长期决策。本过渡指南将帮助您从基于任务的执行转变为战略思维。您将超越快速修复，开始构建可以与您的业务一起增长的更好系统。此数据工程路线图将帮助您专注于数据工程技能，即使在 AI 优先的世界中，这些技能仍然很重要。因为数据工程师的真正工作不仅仅是编写管道。它知道要建造什么，为什么它很重要，以及如何使其可持续。

人工智能数据工程师不断变化的角色

数据工程师的角色不再只是编写 ETL 脚本和管理仓库管道。随着 Windsurf 等工具根据自然语言提示生成 DAG，以及 Cursor 提供比同事的 Slack 建议更好的 SQL 自动完成功能，很明显人工智能正在开始做这件事。但这是否意味着您的工作面临风险？不完全是。

让我们将数据工程师的核心职责分解为四个象限：

现在，关键部分是：人工智能正在接管技术战术象限。编写基本的 Airflow DAG 等任务？风帆冲浪可以处理这个问题。需要跨表优化的 JOIN？Cursor 会建议它。
在低代码 ETL 中调试模式漂移？期待自动警报和补丁。

人工智能还做不到的是战略思维。它无法决定为什么您的模型应该优先考虑保留指标而不是参与度。它无法权衡实时管道中数据延迟和准确性之间的权衡。当分析逻辑影响定价模型时，它无法与利益相关者达成共识。因此，为了保持相关性，您需要从执行者到架构师，从问题解决者到决策制定者。

到 2025 年，数据工程师技能比以往任何时候都更重要

现在是 2025 年，你不是通过你编写 dbt 模型的速度来衡量的。正在评估您将数据工作与业务价值联系起来的程度，以及您是否可以指导 Windsurf 或 Cursor 等 AI 工具在不破坏生产过程中的繁重工作。

事实是，人工智能并没有取代数据工程师，但它已经使某些技能过时了。如果您的日常工作主要涉及编写样板 SQL、硬编码数据质量检查或将 Airflow DAG 拼接在一起，这些 DAG 已经由 AI 代理处理，这些 AI 代理永远不会感到疲倦、分心或阻塞。

那么这给你留下了什么呢？

它给你留下了一个更清晰的工作，一个优先考虑思考而不是实践、概念优先于语法、业务一致性优先于执行速度的工作。让我们探讨一下将定义数据工程师在人工智能时代取得成功的技能。

1. 数据建模是新的编码

人工智能可以编写代码。你仍然需要告诉它要编码什么。这就是为什么数据建模比以往任何时候都更加重要。像 Windsurf 这样的工具可以接受诸如“生成用于跟踪客户计划更改的 SCD 类型 2 DAG”之类的提示，并返回一个完全结构化的 Python DAG，其中包含暂存层和审计层。但是，如果您不了解 SCD 类型 2 要求的细微差别，例如在不覆盖先前记录的情况下处理历史更改，您将无法发现该工具何时出错。

优秀的数据工程师知道如何对缓慢变化的维度进行建模。优秀的数据工程师知道何时不使用它们。

简而言之，人工智能将构建您的要求，但您负责定义蓝图。您提示 Windsurf 生成 SCD2 DAG，它为您提供了一个跟踪客户地址变化的管道。但您的业务团队稍后解释说，只应跟踪有效的账单地址，而不是历史账单地址。人工智能听从你的命令。你没有遵循上下文。

2. 架构愿景胜过语法完美

如果您仍然沉迷于 Jinja 模板或 Snowflake SQL 格式，请停止。到 2025 年，增长最快的工程师是那些能够：

• 设计可扩展的数据平台
• 了解批处理与实时之间的权衡
• 规划不同工具如何跨堆栈集成

您可以培养的最有价值的技能是系统思维。您不需要编写每个连接器，但您应该了解组件如何交互，数据引入、存储、建模和服务层如何与延迟要求、数据协定和治理策略保持一致。

在纸上绘制团队的数据管道。您能解释一下沿袭、测试、可观测性、访问控制和调度如何交互吗？如果没有，是时候缩小范围了。

3. 提示工程是新的脚本

不再需要编写自定义 Python 脚本来验证 null 或检查时间戳漂移。如今，基于 Cursor 或代码解释器的代理等工具可以根据提示生成完整的测试框架，例如：

“编写 dbt 测试以检查事件时间戳是否在摄取时间的 5 分钟内。”

但这就是大多数数据工程师遇到的问题：模糊的提示会导致模糊的代码。您必须掌握提示工程作为一项技能，了解如何确定意图范围、定义边缘情况以及包含上下文。

最佳实践： 使用如下结构化提示：

“生成 SQL 以检查 时间戳是否至少在 之后 1 秒，忽略短于 5 秒的会话，并将它们标记为 QA 审查表。”session_endsession_start

请注意这包括：

• 清空状况
• 边缘情况处理
• 可作的结果

这就是初学者和使用 AI 作为副驾驶的高级数据工程师的区别。

4. 了解业务背景

初级和高级数据工程师之间最大的区别不在于代码质量;这是情境意识。除非你喂养它，否则人工智能无法理解业务逻辑。所以，如果你不知道：

• 哪些指标对销售团队很重要
• 为什么营销需要实时数据
• 财务部门如何解释“活跃客户”

…然后，你将继续构建看起来正确但未达到目标的管道。

您构建了一个转化漏斗表。AI 帮助您生成连接和事件逻辑。但事实证明，该企业根据点击率+添加到购物车+完成结账来定义“转化”，所有这些都在24小时内完成。您的漏斗错过了该规则，因为您没有询问。

5. 概念配对：2025 年有效的学习策略

这里有一个实用的提示：每当您使用 AI 工具时，请将其与概念模式配对。这是避免成为仅执行工程师的陷阱的最佳方法。

2025 年的学习不仅意味着使用工具，还意味着深入了解其构建背后的概念。你想训练你的大脑，而不仅仅是人工智能。

每个数据工程师都应该知道的设计模式

如果您真的想在 2025 年成为一名高绩效数据工程师，那么仅仅知道如何将数据从 A 点移动到 B 点已经不够了。真正的价值在于知道如何构建这些数据。为什么？因为设计模式决定了从数据仓库性能到 ML 功能的可用性以及实时管道的成功等一切。

如果您正在使用 dbt、Spark、Airflow 或 Apache Flink，则设计模式充当心智模型，可帮助您在压力下做出更快、更好的决策。让我们通过实际解释、权衡以及何时使用每种模式来了解每个数据工程师都应该深入了解的六种基本数据设计模式。本节是您的实践指南，而不仅仅是理论。

1. Kimball 维度建模：分析的黄金标准

如果您的团队运行仪表板、临时查询或 Looker 或 Tableau 等 BI 工具，那么即使您没有意识到，您也有可能依赖维度模型。Ralph Kimball 的维度建模框架将您的数据组织为：

• 事实表 — 可衡量的事件（如订单、交易、点击）
• 维度表 — 描述性上下文（用户、产品、位置）

目标是优化可理解性和速度，而不是事务处理。这意味着在需要时进行扁平化、非规范化和预聚合。

为什么有效：

• 使用星型模式提高查询性能
• 使分析师的数据更加直观
• 鼓励指标定义的一致性

何时使用：

• 报告系统
• BI 工具
• 非工程师的临时 SQL 分析

最佳实践：

始终记录每个事实数据表的粒度级别，例如：“此事实数据表每天每个订单有一行。

常见错误：

尝试将原始事件日志强制到事实数据表中，而不对查询行为进行建模。您最终会遇到缓慢的查询和困惑的消费者。

2. 缓慢变化的尺寸（SCD 类型 2）：处理历史变化

当客户更新地址或产品更改类别时，是否应该覆盖旧记录？如果是，您将丢失历史记录。如果没有，则需要一个系统来跟踪更改。这就是 SCD Type 2 的作用。

在 SCD2 中，每次发生更改时，都会添加一个新版本的维度，其中包含：

• 新的代理密钥
• 有效的开始和结束时间戳
• “is_current”标志

这确保了历史的准确性;例如，如果某人在购买时住在纽约，您的分析不会仅仅因为他们搬家后就突然显示他们在加利福尼亚。

真实用例：

银行使用 SCD 类型 2 来实现 KYC（了解您的客户）合规性，其中法律审计需要准确查看系统在每笔交易时对客户的了解。

关键提示：

不要尝试从头开始编写 SCD2 逻辑。使用久经考验的工具，例如 dbt 的宏或 Spark 的工具以及 Iceberg 的时间旅行支持。surrogate_key()merge

3. OLTP 归一化：不要过度非规范化一切

虽然分析有利于非规范化，但在线事务处理 （OLTP） 系统仍然依赖于第三范式 （3NF），其中数据被分解为带有外键的最小非冗余表。

为什么规范化仍然很重要：

• 减少更新异常
• 使事务符合 ACID 标准
• 避免冗余写入和不一致

如果您的公司运行用户生成的内容、支付或库存系统，则您的生产数据库很可能采用 3NF。

专业见解：

使用 Debezium 或 Airbyte 等变更数据捕获 （CDC） 工具的数据工程师应该知道如何从规范化日志中重建非规范化事件。除非你了解关系理论，否则这并不容易。

4. Apache Flink 的 Kappa 架构：无需批处理即可实时

忘记 Lambda 架构及其批处理层和速度层。到 2025 年，现代堆栈将使用由 Apache Flink 等流优先工具提供支持的 Kappa 架构。

核心思想：

• 所有数据都被视为实时流
• 您可以通过同一个 Flink 作业重放历史数据来重新处理历史数据

这意味着历史回填和实时扩充的代码路径降低了复杂性。

它的闪光点：

• 欺诈检测系统
• 点击流管道
• 金融报价数据处理

Flink 提示：

使用事件时间窗口（而不是处理时间）来确保高延迟环境中的正确性。并始终使用水印逻辑处理迟到。

5. ML 特征存储架构

您不能再将特征提取到 CSV 中。生产 ML 系统依靠特征存储来确保训练服务的一致性、版本控制和延迟保证。

一个好的 ML 功能存储包括：

• 离线存储：Parquet/Spark/Hive/Iceberg 中的批量计算功能
• 在线商店：通过 Redis、Cassandra 或 DynamoDB 进行低延迟查找
• 注册表：用于功能所有权、类型和世系的元数据存储

Feast、Tecton 和 Databricks Feature Store 等工具抽象了这种模式，但了解体系结构可以更轻松地进行调试和缩放。

假设您有一个流失预测模型使用的“customer_avg_spend_30d”功能。每晚在 Spark（离线）中计算它，并在用户登录（在线）时实时提供它。如果没有一致的定义，模型将受到训练/服务偏差的影响。

要避免的陷阱：

不要使用一次性模型输入使特征存储过载。将其用于多个模型可以从中受益的可重用通用功能。

6. 一张大桌子 （OBT） 建模：并不总是邪恶的

数据工程师经常被警告不要将所有内容转储到单个非规范化表中。但对于特定的高性能工作负载，One Big Table （OBT） 方法效果出奇地好。

为什么使用 OBT：

• 减少查询联接并加快仪表板加载速度
• 简化非技术团队的访问
• 与 BigQuery 或 DuckDB 等列式存储配合良好

何时使用：

• 具有多个维度的单个业务实体（例如，客户或产品）
• 读取密集型、写入稀有用例
• 用于分析的预计算聚合

真实案例：

一家金融科技公司的一个团队构建了一个 OBT，结合了用户档案、KYC 状态、交易聚合和风险评分。这为 100+ Looker 仪表板提供支持，他们永远不必担心连接中断。

只是不要使用 OBT 作为事实来源。始终将服务层与源模型分开。

设计模式是将生产级数据工程师与查询骑师区分开来的心智模型。2025 年，不是记住语法，而是识别模式、推理权衡以及做出明确的架构选择。因此，如果要调试不稳定的管道、生成特征存储或设计新的 DAG，请始终询问：

“我使用的是哪种设计模式，为什么它适合这里？”

掌握这六种模式，作为一名数据工程师，您不仅可以在人工智能的崛起中幸存下来，而且还会清晰而自信地领导它。

提示的力量：人工智能 + 上下文 = 数据工程超能力

试想一下，您打开终端并输入一个句子。

“给定此模式，使用 Trino 生成 SCD2 DAG，并包括幂等性检查 + 写入-审计-发布质量门。”

几秒钟后，该模型会为您提供一个有效的 DAG、审核检查点和用于缓慢变化的维度的 SQL。不仅仅是代码转储，而是生产可行的东西。现在暂停一下。

是人工智能让这种魔法成为可能吗？不完全是。

是你，有背景、有经验和正确的提示框架。

提示是数据工程师重塑数据工程工作方式的核心技能。模特很强大，但他们不思考。是吗。当您的上下文满足他们的模式识别时，奇迹就会发生。

将提示视为新的编程语言。就像编码一样，编写出色的提示不是要记住语法，而是要了解幕后应该发生什么。

这里最大的转变是这样的：

• 而不是手动将 SQL、YAML 和 Python 拼接在一起，
• 你正在使用语言作为业务流程协调器。

这效果很好，但前提是您不是盲目提示。

提示框架：技术→设计模式→最佳实践→输入

为了帮助您编写有效、可重用且生产感知的提示，下面是一个可以跨工具应用的心智模型：

1. 输入

首先清楚地说明您的业务上下文或模式。

“我有一张customer_orders桌，上面有customer_id、order_id、order_date和地位。”

这为人工智能提供了一些具体的东西来抓住。

2. 技术

下一步是命名您正在使用的堆栈。该模型将根据您说的是 Trino 与 BigQuery 还是 Airflow 与 Dagster 来更改其模式。

“我们正在 Iceberg 上使用 Trino 与 Airflow 和 Great Expectations 进行验证。”

具体点。不要说“数据管道”。说，“具有任务级重试和数据质量检查点的气流 DAG”。

3. 设计模式

然后，给出一个明确的模式来遵循。这就是浅层提示与真正的工程级提示的区别。

例如：

• “使用 SCD 类型 2 逻辑进行更改跟踪。”
• “实现写入-审计-发布模式。”

设计模式为您的提示结构提供。你不仅仅是在要求代码。您要求一个有条不紊的解决方案。

4. 最佳实践

最后，添加护栏。这些是 LLM 不会添加的内容，除非你问：

• “添加幂等检查。”
• “使 DAG 重试呈指数级”
• “使用远大期望包括测试”

结果？你不会把你的大脑委托给人工智能。你正在通过它扩展你的思维。

工具集成示例

让我们看看这在常用工具中是如何发挥作用的：

1. 特里诺

您可以提示：

“编写一个 Trino 查询，将每日订单连接到客户维度，并使用 Iceberg 合并应用 SCD2。”

Trino 是模式感知的。与正确的提示配对，它成为理解意图的 SQL 编译器。

2. 气流

AI 现在可以搭建 DAG，但关键在于细节：

“创建一个具有任务级重试、超时和 SCD2 逻辑的 Airflow DAG。包括任务以验证行计数一致性。

提示必须像生产数据工程师一样思考，而不是教程。

3. 远大的期望

与其花 30 分钟编写 YAML，不如问：

“为空检查、order_id唯一性和状态的正则表达式匹配生成远大期望测试。”

同样，这有效，因为你给出了结构 + 意图。

4. 写入-审计-发布 （WAP） 模式

数据工程中最容易被误解的模式之一，也是提示的一个很好的用例。

“使用暂存层、审计检查点并在订单表上实现 WAP 模式，并使用 Iceberg 快照提交进行发布。”

这产生了一个安全、幂等的管道。正是您在生产中想要的。

就像 SQL 或 Python 一样，提示工程正在成为现代数据工程师的核心素养。但写出出色的提示并不意味着您停止学习核心概念。事实上，它要求你了解更多，因为你正在指导一个并不真正了解它正在构建什么的系统。

未来不会让人工智能取代工程师。能够通过语言进行设计的工程师将取代那些不能进行设计的工程师。因此，下次打开编辑器时，请记住：

“人工智能 + 上下文 = 数据工程超能力。”

只有你带来背景。

到 2025 年，数据工程最佳实践比以往任何时候都更加重要

人工智能可能会加快我们搭建管道、生成 SQL 或设置 Airflow DAG 的速度，但它并没有改变这个事实：

糟糕的设计仍然会在生产中断。
良好的工程实践仍然可以拯救您。

围绕人工智能辅助开发的炒作是真实存在的。但没有结构的速度是一种错误的进步感。脱颖而出的工程师仍然是那些遵循清晰、一致的最佳实践的工程师。随着数据管道的复杂性和自动化程度的提高，这里仍然很重要，而且可以说比以往任何时候都更重要。

正确的分区、压缩和 PII 管理

让我们从基础开始。

1. 分区

• 你不能跳过这个。分区决定了数据读取的速度（或速度）。
• Iceberg、Delta Lake 和 Hive 兼容表都依赖于分区修剪来提高效率。
• 分区不佳的表（例如，对像 这样的高基数列进行分区）可能会导致扫描数百万个小文件，浪费计算并延迟作业。user_id
• 如果查询速度很慢，请在调整 Spark 配置之前检查分区策略。

2. 压缩

• Parquet + Snappy 通常是默认设置，但请了解何时切换到 ZSTD 以获得更好的压缩或 GZIP 进行存档。
• 不要压缩已压缩的字段（如 base64 图像或压缩日志）。

3. PII 管理

• 屏蔽、散列或隔离 PII 应烘焙到转换层中。
• Apache Ranger 或 Immuta 等工具有助于策略实施，但它始于架构设计。
• 示例：拆分为两个表 - 一个有 PII，一个没有。仅在需要时加入。customer_details

数据保留：成本、合规性与分析

每个企业都希望获得新的见解。但你真的需要 10 年的事件数据吗？

1. 冷数据与热数据

• 使用分层方法。将最近 6 个月存储在快速访问区域（如 Delta 或 Iceberg）中，其余部分存档在具有访问策略的 S3 Glacier 或 BigLake 中。

2. 合规驱动的保留

• GDPR 和 HIPAA 可能会强制规定删除窗口或保留上限。将这些检查构建到数据生命周期策略中。

3. 分析友好的保留

• 即使原始数据过期，也会保留聚合摘要（每月汇总）。它更便宜，而且通常足够。

“删除原始日志并不意味着删除洞察，而是意味着巧妙地总结。”

DAG 可靠性和幂等性

幂等性是那些听起来很学术的词之一，但在出现问题时可以节省您的管道。如果您的作业中途失败并重新启动它，它是否可以在不重复记录的情况下再次运行？

制作您的 DAG：

• 幂等：使用合并、更新插入或分区覆盖模式，而不是盲目追加。
• 重试安全：确保重试不会重新运行繁重的提取任务，除非需要。
• 可审计：包括行计数、哈希检查和元数据日志以检测异常。

“重试损坏的 DAG 不应给您带来损坏的数据集。”

预聚合商店的仪表板

如果您的仪表板直接连接到 Snowflake 或 Druid 中的原始表，请停下来重新考虑。

相反：

• 使用具体化视图、汇总表或 OLAP 多维数据集来支持仪表板。
• 预先汇总 ETL 层中的每周销售额、用户数量或每日流失率等指标。
• 这改进了：仪表板加载时间、查询成本和报表之间的一致性。

如何让您的数据工程职业生涯面向未来

让我们真正了解在人工智能数据繁重的世界中保持相关性意味着什么。当然，工具领域正在快速发展。人工智能现在可以生成 DAG、SQL，甚至代码审查。但这里有一个问题，您作为数据工程师的长期价值并不在于快速使用工具。它在于您设计持久系统、跨团队协作以及确保大规模数据质量的能力。

这是一个实用的细分，可帮助您保持领先地位而不会让自己精疲力尽。

专注于构建系统，而不仅仅是管道

编写管道不再是差异化因素，任何人都可以在 Airflow 上启动一个有效的 DAG 或在 Dagster 中构建一个基本的流程。让您与众不同的是设计的系统：

• 在模式更改中幸存下来，无需不断重构
• 处理错误或丢失的数据，而不会破坏下游依赖关系
• 提供仪表板、ML 模型和运营警报 — 所有这些都来自一致的来源
• 随着团队的成长和用例的扩展而扩展

从问“我可以部署这个 DAG 吗？”转变为“这是另一个团队一年后可以依赖的东西吗？

“管道是一个脚本。系统是一种带有契约的架构。

这种思维的转变使您不仅成为一名建设者，而且成为一名系统架构师，成为一位考虑到长寿的工程设计者。

更多而不是更少地协作

人们普遍误解人工智能工具将减少团队协作的需求。事实恰恰相反。人工智能生成的代码通常缺乏团队的约定。给两个人的相同提示可能会返回截然不同的结果，一个是强大的，另一个是脆弱的。当每个人都在孤岛中使用人工智能时，共享上下文变得更加重要。

示例：LLM 生成的气流 DAG 可能看起来不错。但在生产环境中，它会静默地跳过重试或错误处理空值。队友的眼睛可以比你的测试更快地发现这些盲点。

“有效的代码与在整个团队中运行良好的代码不同。”

使代码审查、架构讨论和结对调试变得不可协商。这些习惯是您在人工智能增强工作流程中的安全网。

加倍努力实现可观测性、测试和沿袭

随着越来越多的样板自动化，瓶颈转移到了解什么正在发生以及为什么发生故障。这就是成熟工程师脱颖而出的地方，他们投资于可观察性和主动验证。

这是它的样子：

可观测性工具：
使用 Monte Carlo、OpenLineage 或 Databand 来跟踪新鲜度、模式漂移和失败率。

测试框架：
在您的 CI/CD 管道中运行 Great Expectations 或 Deequ。验证行计数、联接、空值和类别一致性。

世系跟踪：
构建从源到仪表板的世系图。这不仅是为了合规性，还可以帮助您在仪表板行为不正常时更快地回答业务问题。

职业洞察：数据工程师角色正在不断发展，而不是消失

是的，人工智能让日常任务变得更加容易。但随着代码生成变得商品化，它提高了重要技能的门槛：

• 构建具有明确合同和 SLA 的强大系统
• 指导仍在学习什么是好数据代码的新工程师
• 使用内置的业务上下文对数据进行建模，而不仅仅是生成表

可以这样想：人工智能消除了繁重的工作，但您必须拥有系统设计、影响分析和长期稳定性。在这种转变中茁壮成长的工程师是那些缩小范围并进行整体思考的人。

“成为编写更少管道但更有弹性系统的工程师。”

通过 ProjectPro 的实际项目边做边学

如果您真的想让自己的职业生涯面向未来，那么没有什么比动手数据工程经验更好的了。这就是 ProjectPro 的数据工程项目的用武之地。这些已解决的端到端数据工程项目模拟了现实世界的场景，例如：

• 从 Spotify 或 YouTube API 构建 ETL 管道
• 使用 Apache Airflow 编排工作流
• 在 BigQuery 或 Snowflake 中处理架构演变
• 将 Apache Kafka、dbt 和 Spark 等工具集成到端到端系统

每个数据工程项目的结构都是为了帮助您练习系统级思维，而不仅仅是编写代码。你将学习如何管理故障场景、测试转换以及提供业务团队可以信任的干净数据集。

从一个项目开始。打破它。修复它。了解为什么在生产中会出现故障，这就是真正的数据工程师所做的。