AI 能写代码，但工程决策和结果归属仍由人负责
AI 擅长生成样板代码、测试、文档和重构建议，但定义正确问题、评估技术权衡、验证输出、保护安全可靠性的责任仍由工程师承担。
完整中文译文
AI 编码工具可以快速生成函数、解释陌生的代码、编写测试、重构文件、提出修复建议。
这种能力给开发者带来了一个棘手的问题：
如果 AI 都能写代码了，软件工程师还能做什么？
答案并非"无事可做"。写语法只是工程工作的一个环节。真正困难的工作在第一行代码生成之前就已经开始，并在代码编译之后长期持续。
本文将解释工程师仍然掌控着什么、角色如何演变，以及在 AI 融入日常软件开发后，开发者应该加强哪些技能。
AI 在以下方面越来越有用：
- 重构建议
- 遗留代码解释
软件工程师仍然负责：
- 定义正确的问题
- 评估技术权衡
- 验证 AI 生成的输出
- 保障安全性和可靠性
- 长期维护软件
- 响应生产系统故障
AI 可以生成实现，却无法为结果负责。
代码生成不等于软件工程
一个 prompt 可以产出一个能跑的函数。但这不意味着这个函数就适合放在生产系统中。
工程师仍然需要回答以下问题：
- 这真的解决了用户的实际问题吗？
- 它与现有架构一致吗？
- 当输入不完整或存在恶意时会发生什么？
- 团队能在六个月后维护这段代码吗？
- 在真实流量下它能正确运行吗？
- 它是否引入了安全、许可或隐私方面的问题？
- 有没有更简单的解决方案？
这些问题需要业务上下文、技术判断和责任感。AI 可以辅助分析，但拍板仍是工程团队的活儿。
1. 工程师定义真实问题
AI 通常只会响应交给它的任务。结果的质量很大程度上取决于任务本身是否正确。
比如这样一个需求：
为 API 添加缓存来提速。
immediate 实现可能很简单，但工程师应该先调查：
- 哪个端点慢？
- 数据库查询是真正的瓶颈吗？
- 延迟是由外部服务导致的吗？
- 数据能容忍过期吗？
- 缓存值如何失效？
- 系统真的需要缓存吗？
在理解问题之前就生成代码，可能让系统更复杂，却解决不了根本原因。
工程师的首要职责不是写代码，而是确保团队在解决正确的问题。
2. 工程师设计系统，而非孤立函数
AI 工具在生成局部解决方案时往往很有效。但生产软件需要更宏观的视角。
一个功能可能影响到：
一段代码在一个文件里看起来正确，却可能在系统的其他地方制造问题。
架构工作要求工程师理解组件如何交互、故障可能发生在哪里、以及项目中哪些权衡是可以接受的。
例如，添加一个新的 AI 功能可能需要决策：
- prompt 存在哪里
- 如何验证模型的响应
- 哪些数据可以发送给第三方提供商
- 请求失败时如何重试
- 如何监控使用成本
- 何时需要人工审核结果
代码只是设计的一部分。
3. 工程师验证 AI 生成的输出
AI 生成的代码应该被视为一个提案，而不是自动可信的答案。
输出可能包含：
- 错误的假设
- 安全漏洞
- 与项目不匹配的依赖
一个有用的 AI 辅助工作流如下：
- 在请求代码之前先定义预期行为
- 让 AI 解释它的假设
- 逐行审查输出
- 测试正常、无效和边界输入
- 检查安全性和性能影响
- 将解决方案与项目现有模式对比
- 记录为什么最终方案被采纳
AI 生成代码的速度越快，严格的审查就越重要。没有验证的速度只会更快地制造缺陷。
4. 工程师承担安全和可靠性责任
生成的解决方案可能编译通过，但仍然不安全。
工程师必须检查以下领域：
- 认证和授权
- 文件上传限制
- 敏感数据暴露
AI 并不知道所有的安全需求、业务规则或合规约束，除非这些上下文被提供。即使提供了上下文，结果仍然需要人工审核。
可靠性问题类似。在演示中工作的功能可能在以下情况失败：
- 外部 API 超时
- 队列重复处理同一个任务
- 数据库连接断开
- 流量突然增加
- 模型返回意外格式
- 部署引入不兼容的变更
生产工程关注的是为这些情况做准备，而不仅仅是让成功路径走通。
5. 工程师做权衡
大多数工程决策没有一个完美的答案。
团队可能需要在以下之间做选择：
- 更快交付和更清晰的架构
- 更低成本和更高可靠性
- 灵活性和简单性
- 托管服务和更大控制权
- 单体和微服务
- 新依赖和自研代码
AI 可以列出利弊，但后果仍由人来承担。
正确的决策取决于团队的经验、截止日期、用户、预算、现有系统和对运维复杂性的容忍度。
强的工程师不只是问"我们能建成吗？"，还会问：
- 这是适合这个团队和这个产品的正确解决方案吗？
6. 工程师在发布后维护软件
软件开发不会在 PR 合并后就结束。
工程师继续：
- 监控生产行为
- 调查事故
- 响应用户反馈
- 向未来的团队成员解释决策
AI 可以帮助完成其中许多任务，但长期可维护性取决于一致的架构、文档、测试和团队知识。
一个充斥着快速生成解决方案的代码库，当这些解决方案不遵循共同模式时，会变得越来越难维护。
目标不是生成尽可能多的代码。目标是构建团队能够安全运维和修改的软件。
初开发者面临什么？
初开发者面临一个真实的挑战。许多曾经提供早期经验的日常任务，现在可以用 AI 快速完成。
这并没有让编程基础变得不重要。恰恰相反，它们变得更加重要，因为开发者必须足够理解，才能识别生成的代码何时出错。
初级工程师应该练习：
- 把大问题拆分成小任务
- 阅读陌生的代码
- 调试，而不是立刻要求一个替代解决方案
- 编写和评估测试
- 解释技术决策
- 理解数据在系统中的流动
- 从安全性和可维护性角度审查代码
- 在保留独立判断的前提下使用 AI
一个能生成代码的初级开发者很常见。一个能验证、解释、测试和改进代码的初级开发者更有价值。
AI 时代值得加强的技能
开发者不需要在打字速度上和 AI 竞争。他们需要在下述工作中变得更强：这些工作环绕在代码生成之外。
系统设计：了解服务、数据库、队列、API、缓存和客户端如何协作。
安全：理解常见漏洞，将安全融入设计和审查，而不是事后补救。
测试和调试：学会证明软件能正常工作，以及当它不工作 时如何隔离原因。
产品和业务：理解用户、业务目标和解决错误问题的代价。
沟通：工程师必须向技术和非技术队友解释风险、需求、权衡和决策。
AI 辅助开发：学会提供有用的上下文、审查生成的输出、保护敏感信息，以及判断何时不该用 AI。
审查 AI 生成代码的实用清单
在接受 AI 生成的代码之前，问自己：
- 它是否满足了实际需求？
- 假设是否清晰陈述？
- 边界情况是否被处理？
- 测试是否验证了行为而不仅仅是执行？
- 所有外部输入都被验证了吗？
- 权限在服务端检查了吗？
- 密钥或敏感数据可能被暴露吗？
- 新依赖是否必要且可信？
- 代码是否遵循现有项目模式？
- 命名和抽象是否清晰？
- 解决方案是否比问题本身更复杂？
- 另一位工程师日后能理解和修改它吗？
- 依赖失败时会发生什么？
- 错误日志是否记录了足够的上下文？
- 重试会制造重复工作吗？
- 有安全的降级方案吗？
- 实现是否产生了不必要的数据库查询或 API 调用？
- 随着使用量增长，它表现如何？
- 它是否引入了持续的基础设施或模型成本？
- 你能解释解决方案的每个重要部分吗？
- 你愿意在生产环境支持它吗？
如果最后一个问题的答案是"否"，那这段代码还没准备好合并。
AI 在改变工程，而非消除责任
AI 可以让开发者更快。它可以减少重复工作，帮助团队更快地探索解决方案。
但它也可能生成令人信服的错误，增加需要审查的代码量，并鼓励团队在充分理解问题之前就行动。
这不是在论证每个工程角色或任务都将保持不变。日常工作在持续演变，对开发者的期望也在提高。最强的工程师将是那些把 AI 速度与技术基础、产品理解和审慎判断结合起来的人。
在 Techifive，我们把 AI 视为工程工作流的一部分，而不是工程所有权的替代品。
自从你开始使用 AI 编码工具以来，哪项工程技能对你来说变得更加重要了？
某些评论可能只对登录访客可见。登录后查看所有评论。