工程师的AI工程化实践：从工具熟练到价值闭环

1. 这不是技术革命，是一场工作方式的“静默升级”

你有没有过这种感觉：早上九点走进公司茶水间，听见两个后端同事在讨论“RAG pipeline怎么调召回率”，隔壁组的前端刚用Copilot三分钟生成了整套React状态管理逻辑，而你昨天还在为一个遗留系统的Spring Boot版本兼容性问题查了六小时文档？这不是科幻片片场，这是2025年国内一线互联网公司、中型SaaS团队甚至传统行业IT部门里每天真实发生的晨间快照。 AI没有敲锣打鼓地宣布“我来了”，它已经坐在你的工位旁，默默帮你补全了第7个if判断的else分支，顺手把单元测试覆盖率从68%拉到了83%。 关键词里的“Towards AI”不是指某家媒体平台，而是指向一种正在发生的、不可逆的工程实践演进方向——它不取代你写代码的手，但正在重定义你思考问题的路径、分配注意力的方式，以及交付价值的节奏。

这和当年Git取代SVN、Docker普及、微服务架构落地完全不同。那些是工具链的切换，你可以按部就班学命令、配环境、改配置；而AI带来的是一场“认知带宽”的再分配。过去你花40%时间在查文档、写样板代码、机械式调试，现在这部分被压缩到15%，腾出来的25%时间，你准备用来做什么？是继续深挖JVM GC调优细节，还是去理解业务方真正卡在哪儿、为什么这个报表导出要等17秒、那个用户流失漏斗里第三步的跳出率为何异常高？ 真正的分水岭从来不是“会不会用Copilot”，而是“腾出来的时间，你选择填进技术纵深，还是业务纵深”。 我带过的十几个工程师转型案例里，最成功的那几个，都不是算法题刷得最多、模型调参最熟的，而是最早开始用AI把重复劳动自动化，然后把省下的时间系统性地泡在业务日志、用户反馈、销售话术里的人。他们没变成AI专家，却成了业务方开口第一句就想找的“那个懂技术也懂我们痛点”的人。这篇文章不教你从零训练大模型，也不堆砌Transformer架构图，它只讲一件事：一个有五年以上经验、日常写Java/Python/Go、维护着几万行存量代码的普通工程师，如何在接下来三个月内，把AI真正变成自己键盘上最顺手的“第六个手指”，而不是茶水间里焦虑的谈资。

2. 核心设计思路：拒绝“AI专家化”，专注“AI工程化”

2.1 为什么坚决不走“成为AI研究员”的路线？

很多工程师一接触AI，本能反应是打开Hugging Face，下载Llama-3-8B，本地跑起LoRA微调，试图用自己熟悉的“编译-部署-压测”那一套去征服AI。我试过，花了整整两周，最终产出一个在内部测试集上准确率比基线高0.3%的定制模型，但上线后发现，它处理真实业务请求的延迟比调用OpenAI API高4倍，且对输入格式极其敏感——用户多打一个空格，返回结果就完全错乱。 这暴露了一个残酷现实：绝大多数软件工程师的日常工作场景，根本不需要、也不适合去碰模型层。 就像你不会为了给网页加个轮播图，就从头手写WebGL渲染管线一样。AI工程化的第一铁律是： 永远优先使用成熟、稳定、有明确SLA的服务接口，而非自建模型。 我们团队目前所有AI相关功能，95%以上调用的是云厂商提供的API（如阿里云百炼、腾讯混元、火山引擎的模型服务），剩下5%是基于开源模型做极轻量级适配（比如用LangChain封装一个RAG检索器）。原因很实际：云服务的模型迭代速度远超个人学习速度，其推理优化、安全防护、合规审计能力，是单个工程师或小团队无法企及的。把精力耗在模型微调上，不如花两天时间研究如何用Prompt Engineering把API调用成功率从92%提升到99.5%——后者直接决定线上功能是否可用。

2.2 “AI工程化”的三层金字塔结构

我把工程师能落地的AI能力，拆解成一个稳固的三层金字塔，每一层都对应可量化、可验证的产出：

这个结构的关键在于： 它不追求“全栈AI”，而强调“精准切口”。 你不必同时掌握三层，但必须清晰知道当前阶段该攻哪一层。我见过太多工程师卡在底层——反复纠结Copilot的提示词是否完美，却从不尝试把它用在真实的PR Review中。结果就是，工具用得很溜，但工作流毫无变化。真正的突破点，永远在“第一次把AI输出粘贴进生产环境代码库”的那一刻。那个时刻，你面对的不再是技术参数，而是责任、风险和实实在在的业务影响。

2.3 为什么“Prompt Engineering”是工程师的必修课，而非选修？

很多人把Prompt Engineering当成玄学，觉得是“跟AI聊天的艺术”。错了。它本质上是一种 结构化需求表达能力 ，和你写PRD、画UML序列图、设计数据库ER图，是同一类技能。区别只在于，过去你面对的是人（产品经理、DBA），现在你面对的是一个概率模型。它的底层逻辑非常朴素： LLM是一个巨大的统计机器，它只能复现训练数据中出现过的模式组合。你给的约束越具体，它可选的错误路径就越少。 举个真实例子：我们有个支付回调验签模块，需要解析不同渠道（微信、支付宝、银联）的异构JSON。最初工程师写的Prompt是：“解析支付回调JSON，提取订单号和金额”。Copilot生成的代码，对微信格式有效，但遇到支付宝的 total_amount 字段（单位是分）就直接崩溃。后来我们改成：“请生成一个Python函数，接收原始JSON字符串，根据 channel 字段值（'wechat'/'alipay'/'unionpay'）动态解析：1) 微信：取 out_trade_no 和 total_fee （单位：分，需转为元）；2) 支付宝：取 out_trade_no 和 total_amount （单位：元）；3) 银联：取 orderId 和 amount （单位：分，需转为元）。函数必须包含完整的try-catch，对缺失字段返回None，对金额转换失败返回0.0。仅使用标准库json，禁止引入第三方包。”——生成的代码一次通过单元测试。 看到区别了吗？前者是模糊指令，后者是精确的契约。 工程师的核心竞争力，从来不是“知道什么”，而是“如何把模糊的需求，转化为可执行、可验证、可交付的精确指令”。Prompt Engineering，就是这个能力在AI时代的最新形态。

3. 核心细节解析：从“会用”到“用好”的实操要点

3.1 工具链选型：为什么我们弃用ChatGPT，主推企业级Copilot？

市面上AI编程工具五花八门，但工程师真正需要的不是“最强大”，而是“最可靠”。我们团队经过三个月的AB测试，最终锁定了GitHub Copilot Enterprise（搭配内部知识库）作为主力工具，原因如下：

• 上下文感知深度碾压通用模型 ：Copilot能实时读取你当前打开的文件、所在分支的Git历史、甚至整个仓库的依赖关系图。当你在一个Spring Boot Controller里写 @PostMapping ，它推荐的DTO类名、Service调用方法，90%以上是项目里真实存在的，而非凭空捏造。而ChatGPT即使上传了代码，其上下文窗口有限，对跨文件引用的支持极弱，常推荐出项目里根本不存在的类。

• 企业知识库集成无感 ：我们将内部Wiki、Confluence技术文档、关键API文档、甚至过往重大Bug的根因分析报告，全部向Copilot Enterprise的知识库索引。当工程师在写一个新接口时，Copilot不仅推荐代码，还会在侧边栏显示：“参考文档：《支付网关对接规范V3.2》第5.1节，要求所有回调必须进行幂等性校验”。这种“带着组织记忆编码”的能力，是任何通用大模型无法复制的护城河。

• 安全与合规兜底 ：Copilot Enterprise默认禁用代码外传，所有提示词和生成内容均在企业网络内处理。而使用ChatGPT，工程师可能无意中将含敏感字段名（如 user_credit_card_hash ）的代码片段粘贴进去，存在数据泄露风险。在金融、政务类客户项目中，这点是红线。

提示：不要迷信“免费即正义”。我们测算过，一个工程师因Copilot Enterprise节省的上下文切换时间（查文档、翻旧代码、问同事），每月约12小时。按资深工程师时薪估算，半年即可覆盖License成本。而它避免的一次因API误用导致的线上故障，损失远超此数。

3.2 Prompt Engineering实战：四步法构建“工业级提示词”

把Prompt Engineering当作一门手艺来打磨。我们总结出一套可复用的四步法，已沉淀为团队内部《AI协作手册》第一章：

第一步：锚定角色与边界（Role & Boundary）
在Prompt开头，用一句话明确定义AI的身份和权限。例如：“你是一名有10年Java后端经验的高级工程师，专注于高并发、分布式系统。你只负责提供代码建议和架构思路，不参与业务决策，不猜测未明确说明的需求。”

第二步：注入精准上下文（Context Injection）
提供最小但充分的背景信息。避免大段粘贴代码，而是提炼关键约束：

• 当前技术栈：Spring Boot 3.2, JDK 17, MySQL 8.0
• 关键依赖： spring-cloud-starter-openfeign , mybatis-plus
• 业务规则：订单创建必须满足“库存预扣减+分布式事务”双保险
• 现有代码位置： com.example.order.service.impl.OrderServiceImpl.createOrder()

第三步：定义输出契约（Output Contract）
明确要求生成物的格式、粒度、质量标准：

• 输出必须是完整、可运行的Java代码块，包含必要的import
• 函数签名必须与现有接口一致（如 public Result<OrderVO> createOrder(OrderDTO dto) ）
• 必须包含详细的JavaDoc，说明每个参数含义、返回值场景、可能抛出的异常
• 对于复杂逻辑，需附带简短的中文注释，解释关键步骤的设计意图

第四步：设置防御性约束（Defensive Constraints）
主动规避常见陷阱：

• “禁止使用 Thread.sleep() 、 System.exit() 等危险API”
• “所有数据库操作必须通过MyBatis-Plus的 save() 或 updateById() 方法，禁止原生SQL”
• “如果涉及外部HTTP调用，必须使用 @FeignClient 声明的客户端，禁止 RestTemplate ”

这套方法看似繁琐，但实测效果惊人。我们曾用它将一个原本需要3天开发的“用户行为埋点上报聚合服务”，压缩到半天完成核心逻辑编码，且一次通过Code Review。关键不是AI变聪明了，而是我们学会了如何给它一张清晰的“施工图纸”。

3.3 工作流嵌入：如何让AI成为PR流程的“隐形Reviewer”

PR（Pull Request）是代码质量的守门员，也是工程师最耗时的环节之一。我们改造了PR流程，让AI承担70%的机械审查工作，人类Reviewer专注高价值判断：

改造前流程：
工程师提交PR → 同事手动检查：1) 代码风格是否符合CheckStyle；2) 是否有空指针风险；3) 新增SQL是否加了索引；4) 单元测试覆盖率是否达标；5) 文档是否更新 → 耗时2-4小时/PR

改造后流程（AI增强版）：
工程师提交PR → AI自动触发三重扫描：

1. 静态规则扫描 ：调用SonarQube + 自定义规则集（如“所有Controller层方法必须有 @Valid 注解”），生成结构化报告；
2. 语义风险扫描 ：用微调后的CodeLlama模型分析代码变更，识别潜在问题（如“新增的Redis缓存key未加业务前缀，可能导致跨服务冲突”）；
3. 文档一致性扫描 ：对比PR中修改的代码与Confluence文档，标记出“代码已支持批量导入，但文档仍描述为单条导入”的不一致项。

→ AI生成一份带链接的Markdown报告，附在PR评论区，标注“高危”、“中危”、“建议”三级；
→ 人类Reviewer只需聚焦：1) AI标记的高危项是否真有问题；2) 业务逻辑是否符合需求文档；3) 架构演进方向是否正确。

注意：AI绝不拥有Merge权限。它的角色是“超级助理”，不是“决策者”。我们明确规定：任何AI提出的修改建议，必须由人类工程师确认、理解、并手动应用。这既保障了质量底线，也强制工程师在过程中学习AI的思考逻辑。

4. 实操过程：一个真实项目的AI赋能全流程复盘

4.1 项目背景：为某银行客户重构“智能投顾”后台服务

客户原有系统是典型的单体Java应用，核心功能是根据用户风险测评结果，匹配基金组合。但存在严重问题：1) 组合生成算法硬编码在Service层，每次策略调整需发版；2) 用户咨询记录散落在不同系统，无法关联分析；3) 投顾建议缺乏个性化，同风险等级用户收到完全相同的组合。客户要求：3个月内上线新版本，支持策略热更新、用户画像驱动的个性化推荐、以及可追溯的建议生成日志。

4.2 AI赋能的四个关键节点

节点一：需求澄清与技术方案设计（节省2人日）
传统做法：开3轮需求评审会，产品经理讲PPT，工程师记笔记，会后各自消化。这次，我们让AI介入：

• 将客户原始需求文档（PDF）、历史沟通纪要、竞品分析报告，全部喂给Copilot Enterprise；
• 输入Prompt：“作为首席架构师，请基于上述材料，输出一份技术方案概要，包含：1) 推荐的微服务拆分边界（用户中心、策略中心、组合引擎）；2) 策略热更新的技术选型对比（Spring Cloud Config vs Apollo vs 自研规则引擎）；3) 用户画像数据源整合方案（CRM、APP行为日志、客服系统）；4) 关键风险点及应对建议。”
  AI输出了一份12页的方案草稿，覆盖了80%的技术要点。工程师在此基础上，重点深化了策略引擎的容错设计和灰度发布方案。 最大的价值不是AI写了多少，而是它帮团队在方案初期就对齐了技术共识，避免了后期返工。

节点二：核心策略引擎开发（节省5人日）
策略引擎需支持YAML格式的规则配置，如：

risk_level: "conservative"  
rules:  
  - condition: "user_age < 30 && user_income > 50000"  
    action: "add_fund('FOF-001', weight: 0.4)"  
  - condition: "user_assets > 1000000"  
    action: "add_fund('QDII-002', weight: 0.3)"  

工程师用Copilot Enterprise，输入Prompt：“请生成一个Spring Boot组件，能动态加载上述YAML规则，解析condition表达式（支持<,>,&&,||），执行action中的基金添加逻辑。要求：1) 使用SpEL表达式引擎；2) condition解析失败时记录警告日志并跳过；3) action执行前校验基金代码是否存在；4) 提供REST API供前端调用。”
AI生成了90%的骨架代码，工程师主要工作是：1) 补充基金代码存在性校验的DAO层调用；2) 完善日志埋点；3) 编写边界条件的单元测试。 从零开发预计需1周，实际3天完成核心功能。

节点三：用户画像数据融合（节省3人日）
需将CRM的静态属性（年龄、职业）、APP行为日志（点击、停留时长）、客服系统文本（投诉关键词）融合为统一画像。传统ETL开发复杂。我们采用AI辅助：

• 用ChatGPT（开启代码解释器）处理样本数据：上传CSV格式的CRM数据和APP日志，Prompt：“分析这两份数据的字段重叠度，识别可用于关联的用户ID字段（如crm_id, app_user_id, phone_md5），并生成一个Python脚本，用pandas合并它们，对缺失值用‘未知’填充，对数值型字段计算Z-score标准化。”
• AI生成的脚本经简单修改后，直接用于数据探查，快速确认了主键关联方案。
• 后续用LangChain构建RAG系统，将客服投诉文本向量化，与基金知识库匹配，实现“用户说‘手续费太高’，自动推荐低费率指数基金”。 AI在这里不是替代数据工程师，而是把“数据探索”这个最耗时的环节，从3天压缩到2小时。

节点四：上线前的混沌工程测试（节省1人日）
为验证策略引擎在异常场景下的稳定性，需模拟大量错误输入：无效YAML、恶意SpEL表达式、超长用户ID等。工程师编写了20个测试用例。Copilot Enterprise则生成了127个边界case，包括：

• YAML缩进错误（2空格vs4空格）
• SpEL表达式中使用 #context 访问未授权上下文
• 用户ID包含Unicode控制字符
• 规则文件大小超过1MB
  这些case帮助我们在预发环境发现了2个内存泄漏隐患。 AI的价值，在于它能穷举人类思维盲区。

4.3 成果与反思：效率提升之外的隐性收益

项目最终提前5天上线，客户验收时特别表扬了三点：1) 策略调整无需发版，运营人员后台配置即可生效；2) 用户收到的组合建议明显更贴合其近期行为（如频繁查看新能源基金的用户，获得更高权重的ESG主题基金）；3) 所有建议生成过程可追溯，审计日志清晰记录了“为何推荐此基金”。

但比KPI数字更珍贵的，是团队能力的悄然进化：

• 工程师的提问质量显著提升 ：以前问“这个报错怎么解决？”，现在问“这个异常堆栈指向Redis连接池耗尽，结合我们最近增加的缓存Key数量，是否应该调整maxIdle参数？”。他们开始习惯用AI分析日志，再提出精准的技术假设。
• 技术文档的“活”了起来 ：过去文档写完就过期，现在Copilot Enterprise的知识库会自动索引每次PR的变更描述，当新工程师搜索“如何添加新基金类型”，AI不仅能给出代码路径，还能关联到3个月前那次策略升级的决策会议纪要。
• 跨职能协作更顺畅 ：产品经理不再需要“翻译”业务语言为技术需求，她可以直接把用户访谈录音转文字，喂给AI，让它生成带业务上下文的User Story。工程师拿到的，不再是干瘪的“增加筛选条件”，而是“老年用户反映字体太小，希望增加‘大字模式’开关，参考竞品XXApp的实现”。

这印证了最初的判断：AI不是要取代谁，而是把工程师从“翻译器”和“执行者”的角色中解放出来，让他们回归到最本质的工作——理解问题、权衡利弊、做出判断。 当你不再为写10行样板代码而分心，你才有余力去思考：这个功能，真的解决了用户最痛的那个点吗？

5. 常见问题与排查技巧实录：来自真实战场的避坑指南

5.1 “Copilot生成的代码总在关键地方出错，是模型不行吗？”

现象 ：Copilot在生成数据库操作代码时，经常忘记加事务注解，或在循环中错误地复用同一个对象实例，导致数据错乱。工程师因此质疑模型可靠性，转而放弃使用。

真相与排查 ：这不是模型缺陷，而是 上下文缺失导致的“责任错配” 。Copilot看到的只是当前文件片段，它不知道你这个Service方法被调用的场景（是用户下单？还是后台定时任务？），也不知道你的全局事务传播规则（ @Transactional(propagation = Propagation.REQUIRED) 是默认？还是 REQUIRES_NEW ？）。它只能基于局部代码模式猜测。

解决方案 ：

• 前置声明契约 ：在方法上方的JavaDoc中，明确写出事务要求。例如：

  /**  
   * 创建用户订单，需保证库存扣减与订单创建的原子性  
   * @Transactional(propagation = Propagation.REQUIRED)  
   */  
  public OrderVO createOrder(OrderDTO dto) { ... }  
  

  Copilot会优先遵循JavaDoc中的@Transactional声明。
• 启用“代码块级”上下文 ：在VS Code中，右键点击代码块，选择“Ask Copilot about this code”，它会将选中区域作为强上下文，生成更精准的补全。
• 建立“防错模板” ：在团队共享代码片段库中，预置常用模式的模板，如：

  // [事务模板] - 复制此段，AI将自动继承事务语义  
  @Transactional(rollbackFor = Exception.class)  
  public Result<?> doSomething() {  
      try {  
          // TODO: AI will fill logic here  
      } catch (Exception e) {  
          log.error("doSomething failed", e);  
          throw new BusinessException("操作失败");  
      }  
  }  
  

  实操心得 ：AI不是万能的“代码生成器”，而是“契约执行助手”。你给它越清晰的契约（JavaDoc、模板、注释），它越能精准履约。把精力放在定义契约上，而非抱怨执行结果。

5.2 “AI生成的文档初稿看起来很美，但全是废话，怎么用？”

现象 ：用Copilot为新模块生成技术文档，得到一篇辞藻华丽、结构完整但内容空洞的文章，充斥着“该模块具有高可用、高性能、可扩展等优势”这类正确的废话，缺乏具体参数、调用示例、错误码说明。

真相与排查 ：这是典型的 Prompt颗粒度不足 。AI无法凭空创造事实，它只能重组已有信息。你没告诉它“事实”是什么，它就只能用通用话术填充。

解决方案 ：采用“三明治Prompt法”：

• 底层（事实层） ：粘贴该模块的真实代码片段、API Swagger定义、关键配置项截图；
• 中层（结构层） ：明确指定文档结构：“必须包含：1) 接口列表（Method/Path/Description）；2) 请求示例（curl命令）；3) 响应字段详解（含type、required、example）；4) 常见错误码（code/message/cause）；5) 性能指标（P95响应时间≤200ms）”；
• 顶层（风格层） ：限定语气：“用简洁、直接的工程师语言，避免形容词，每句话必须有信息增量。举例：不说‘提供便捷的查询功能’，而说‘支持按user_id和order_status组合查询，QPS≥500’”。

我们团队还做了个狠招：把AI生成的文档初稿，直接作为Code Review的检查项。Review Checklist第一条就是：“文档中所有性能指标、错误码、示例数据，是否能在代码或配置中找到对应来源？找不到则打回重写。” 这倒逼工程师在写代码时，就同步思考可文档化的事实。

5.3 “团队里有人用AI，有人不用，协作效率反而下降了，怎么办？”

现象 ：部分工程师积极拥抱AI，快速产出代码；另一些人坚持手写，认为AI代码“不可控”。结果是：AI使用者写的代码，其他同事看不懂（因为用了新语法、新库），Review时争议不断；手写者觉得AI代码“过度设计”，AI使用者觉得手写者“效率低下”，团队氛围紧张。

真相与排查 ：这是 技术文化断层 ，而非工具问题。AI暴露了团队在“代码可读性”、“技术债治理”、“新人培养”上的深层矛盾。

解决方案 ：推行“AI协作公约”，核心三条：

1. “透明化”原则 ：所有AI生成的代码，必须在提交时的Commit Message中明确标注，如 [AI] Generated by Copilot v4.2 for order validation logic 。这并非追责，而是建立信任——让Review者知道“这段精巧的Stream链式调用，是AI的功劳，不是作者炫技”。
2. “可解释”原则 ：AI生成的复杂逻辑（如一段正则表达式、一个递归算法），必须附带一行中文注释，解释其作用。例如： // [AI] 此正则匹配所有带UTM参数的URL，用于流量归因 。
3. “可退化”原则 ：当AI生成的代码被证明不稳定（如某个库的API在新版本中废弃），团队必须共同维护一个“降级方案库”，里面存放手写版的等效实现。这样，当AI失效时，切换成本趋近于零。

实操心得 ：技术变革的阻力，从来不在工具本身，而在人的习惯与安全感。与其争论“该不该用AI”，不如一起制定“怎么用得更好、更安心”的规则。我们试行公约一个月后，团队代码Review通过率从68%提升到89%，因为大家不再争论“谁对谁错”，而是聚焦于“如何让这段代码，无论是AI写还是人写，都更健壮、更易懂”。

6. 最后一点体会：AI时代，工程师的终极护城河是“问题定义力”

写完这篇长文，我关掉编辑器，泡了杯茶。窗外是北京初夏的傍晚，楼下程序员们正匆匆赶往地铁站。他们中的很多人，此刻或许正焦虑于“要不要学大模型”、“是不是该转行做AI产品经理”、“我的Java经验还有没有价值”。我想说的是： 别被“AI”这个词吓住。它不是一道需要你重新考取的资格证，而是一把正在被所有人握在手中的新扳手。 扳手本身不重要，重要的是你手里要拧的那颗螺丝，是否真的在支撑着一栋大楼。

过去十年，我们靠“把需求翻译成代码”的能力立足；未来十年，真正的稀缺能力，是“在一团混沌的业务噪音中，精准定义出那个值得用代码去解决的、最小但最关键的真问题”。AI可以帮你瞬间写出100种排序算法，但它无法告诉你：用户抱怨“加载慢”，到底是首页瀑布流图片太大，还是购物车接口的N+1查询没解决，抑或是CDN缓存策略出了问题？这个判断，需要你读懂用户反馈里的潜台词，看懂监控图表里的异常拐点，问出那个让产品经理愣住的“为什么”。 AI放大了你的执行效率，但无法替代你的问题嗅觉。 我见过最厉害的工程师，不是代码写得最快的，而是每次需求评审，他总能第一个指出：“等等，这个功能上线后，我们的风控系统会误判30%的正常交易为欺诈，因为规则引擎没覆盖这个新场景。”——这种穿透表象、直击本质的能力，才是任何模型都无法习得的工程师灵魂。

所以，放下对“被淘汰”的恐惧吧。把Copilot装上，从今天下午的下一个PR开始，用它帮你写完那10行枯燥的DTO映射代码。然后，腾出那15分钟，去读一读用户在App Store里最新的差评，去翻一翻上周的慢SQL日志，去问问销售同事：“最近客户最常问的三个问题是什么？”
AI不会给你答案，但它会给你更多时间，去提出更好的问题。而提出好问题的能力，永远是工程师最坚固的护城河。