Skip to content
Steven Chou
← Back
2026-04-03

AI 不是取代工程师，而是重新定义什么叫「专家」

一个正在发生的变化

我在 Shopee 负责推动团队内部的 AI 工程化落地。最近半年最深的感受是：AI 不是在某个环节帮你提速，而是在重新定义整条流水线上每个角色的工作内容。

从最开始的可行性分析，到 PRD、TD、Code Review、Case Design、Case Review、Testing、UAT、Launch、Live Verification、Maintenance——这条我们每天都在走的路，AI 正在逐个环节渗透进来。

不是取代你，而是把你从「执行者」变成「决策者」。

文章中的 SDLC 全景：从左到右是常见交付链路（可横滑 / 点击放大）

AI 在 SDLC 各阶段能做什么

我把目前市面上比较成熟的 AI 应用，按软件开发生命周期的阶段梳理了一遍：

可行性分析 & 需求定义

  • 市场调研与竞品分析：用 ChatGPT / Claude 快速生成市场分析报告、竞品功能对比矩阵。过去需要 PM 花一周做的调研，现在一天可以出初稿。
  • PRD 生成：我们公司内部有辅助开发平台，把需求描述输进去，直接生成结构化的 PRD。PM 的工作从「写文档」变成「审文档」。

设计 → 代码（Design to Code）

  • Figma MCP：这是最近让我最兴奋的变化。Figma 推出了 MCP Server，AI 编程工具（如 Cursor、Claude Code）可以直接读取 Figma 设计文件的结构化数据——不是截图，而是组件、变量、布局的完整信息。
  • 实际效果：设计稿 → 代码的转化过程，从「开发手动还原」变成「AI 自动生成 + 人工调整」。提速非常明显。
  • Figma 的 /implement-design、/create-design-system-rules 等命令可以直接把设计意图转化为对齐实际代码库的实现。

TD 生成 & 代码开发

  • PRD → TD → Code：我们内部平台支持把 PRD 输入后自动生成 Technical Design，再根据 TD 生成代码框架。这个流程非常顺滑。
  • Cursor / Claude Code / GitHub Copilot：2026 年的 AI 编程工具已经不是简单的自动补全。Claude Code 现在每天贡献了 GitHub 上大约 4% 的公开 commit（约 13.5 万个/天），预计到年底超过 20%。Cursor 2.0 支持最多 8 个并行 Agent，每个在独立的 git worktree 中操作。

Code Review

  • Cursor Bugbot：自动在 PR 上运行 AI 代码审查，bug 修复率超过 70%，低误报率，可适配团队自定义规范。
  • Prompt 工程模板：我们团队设计了专门的 Code Review 提示词模板，AI 输出可用率从 50% 提升到 85%。

测试设计 & 测试执行

  • AI 用例生成：基于 PRD 和 TD 自动生成测试用例。我们搭建了团队专属知识库来降低大模型幻觉，测试用例输出准确率达到 90%。
  • Case Review 辅助：AI 可以检查用例覆盖率、边界条件遗漏、与需求的对齐程度。
  • 自动化回归：AI 辅助生成和维护自动化测试脚本，我们团队核心业务回归覆盖率从 65% 提升到 95%。

UAT & Launch & Live Verification

  • 发布门禁：Pipeline 自动门禁系统，集成风险扫描、合规校验与自动化回归卡点。
  • Verification 辅助：AI 可以根据变更内容自动生成验证清单，减少人工遗漏。
  • 监控告警分析：线上问题出现后，AI 可以辅助分析日志、定位根因，缩短 MTTR。

维护 & 持续改进

  • 知识沉淀：AI Agent 对接后台和知识库，实现规范咨询、流程流转、数据查询自动化。
  • 技术债务识别：AI 可以扫描代码库，自动识别重复代码、过时依赖、潜在风险。

本质变化：从工程性工作到研发性工作

上面这些工具和实践指向同一个结论：重复性的工程工作正在被 AI 接管。

产品经理不再需要手写每一行 PRD，设计师不再需要逐个像素标注，开发不再需要从零搭建样板代码，测试不再需要手动编写每一条用例。

这更像是传统互联网职责的一次根本转变——我们从做工程性工作（Engineering Work），转变为做研发性工作（Research Work）。

什么意思？

  • 工程性工作：按照已知的方法和规范，重复执行。调参数、写 CRUD、手动回归、格式化文档。
  • 研发性工作：面对未知的问题，设计方案、权衡取舍、做判断。架构决策、风险预判、质量策略设计。

这和算法工程师的处境是一样的。训练模型过程中最耗时的往往是调参——如果 AI 能帮你做，你就可以把时间花在思考模型设计和数据策略上。软件工程师也是同样的逻辑。

「专家」的定义正在改变

这是我最近思考最多的问题。

AI 之前，我们怎么定义一个领域的专家？

至少 5-10 年的行业经验。因为你需要积累足够多的 case——遇到过什么问题、怎么分析的、怎么解决的。没有真正接触过，你就不知道该怎么处理。这种「经验壁垒」是专家的护城河。

AI 之后呢？

Case 的经验价值在降低。因为无论面对的是一个什么样的 case，只要我有相关的分析框架和方法论，借助 AI 的能力，我都可以把它分析出来。

一个入行 2 年的工程师，如果掌握了正确的思维框架，配合 AI 工具，可以输出接近资深工程师质量的分析和方案。

这不是说经验完全没有价值。经验的价值在于帮你更快识别问题的本质。但它不再是唯一的路径——AI 提供了一条替代路径。

真正重要的是第一性原理思考

如果经验壁垒在降低，什么在变得更重要？

第一性原理思考——把你的能力抽象成一个框架，这样不管你面对的东西是什么，你都可以完成。

举个例子：

  • 面对一个从没见过的线上事故，你不需要「恰好处理过同类问题」，你需要的是一套从现象到根因的分析框架：收集信号 → 缩小范围 → 形成假设 → 验证 → 修复 → 复盘。
  • 面对一个全新的业务系统，你不需要「恰好做过类似项目」，你需要的是一套质量设计的通用模型：理解业务目标 → 识别风险点 → 设计验证策略 → 建立度量体系。

这些框架是可迁移的。不管你面对的是反爬系统还是支付系统，不管是 50 亿请求还是 5000 万请求，框架不变，只是参数在变。

AI 时代成为专家没有之前那么困难——但前提是你要学会第一性原理的思考方式。

给同行的建议

  1. 不要抵触 AI，拥抱它。 AI 不会取代工程师，但会取代不用 AI 的工程师。
  2. 投资思维框架，而不只是经验积累。 把你做过的每个项目抽象成方法论，形成可复用的框架。
  3. 关注每个 SDLC 环节的 AI 化进展。 Figma MCP、Cursor Bugbot、AI 用例生成——每一个都是效率杠杆。
  4. 从「执行者」转型为「决策者」。 当 AI 能写代码、生成用例、审查 PR，你的价值在于判断：这个方案对不对？这个风险值不值得承担？这个架构能不能支撑未来的规模？

作者：Steven Chou 网站：stevenchouai.github.io GitHub：stevenchouai X：@StevenChouAI

AI软件工程职业发展第一性原理SDLC认知升级