2026年，程序员面临的转型之路

关注

原创最新推荐文章于 2026-09-16 14:43:24 发布 181 阅读 AI 写同款· GEO 优化 ›

2026年古法编程转型指南：从手写代码到AI协作的90天实战路线在AI辅助开发逐渐成为行业主流的今天，编程工作的定义正在被重新塑造。从传统手写代码到人机协同产出，其核心不再是简单的代码生成，而是通过提示词工程明确需求、借助代码审查把控质量，从而将开发者从重复劳动中解放出来，聚焦于系统设计与业务理解。这种技术价值正深入影响职场生态，催生了程序员技能评估与职业规划的新需求。当“古法编程”面临效率与市场价值的双重挑战，如何系统评估自身定位、选择升级路径并快速落地成为关键议题。本文基于五维评估模型与三条转型路线，为开发者提供从工作流重构到对外展示的90天实操指南，帮助其在AI时阅读详情

ClaudeCode和OpenClaw出来之后，很多人感叹程序员要被淘汰了，不少人感到沮丧。AI时代，我们该如何转型呢？

一、编码方式已经改变

ChatGPT刚推出时，大家还在质疑"AI到底行不行"，现在不会质疑了。前端页面、后端接口、测试脚本、SQL、运维脚本、文档整理，AI已经能又快又好地生成。不是毫无问题，而是有些场景确实比人干得好。

这几年的变化，大致是这样一条路：

flowchart LR
 A["2024以前 传统开发<br/>需求 → 人工编码 → 测试 → 上线"]
 --> B["2024 Copilot 阶段<br/>AI 辅助补全代码"]
 --> C["2025 Agent 阶段<br/>AI 执行多步骤任务"]
 --> D["2026 Agentic 阶段<br/>人定目标，AI 拆解执行"]

 style A fill:#444441,stroke:#2C2C2A,color:#ffffff
 style B fill:#1D9E75,stroke:#0F6E56,color:#ffffff
 style C fill:#534AB7,stroke:#3C3489,color:#ffffff
 style D fill:#D85A30,stroke:#993C1D,color:#ffffff

2026年，软件开发的方式变了。以前一个功能需要产品写文档、设计师画UI、前端写页面、后端写接口、测试补用例，五六个人一起转。现在更像是少数核心工程师定好目标和约束，AI负责大部分初稿，人负责决策、校正和验收，一个人可以身兼数职。

一些网络数据

Stack Overflow 2025：84% 开发者已使用或计划使用 AI，51% 每日使用
JetBrains 2025：约 85% 开发者使用 AI，62% 依赖 coding assistant
Anthropic Economic Index（2026）：AI 正在重塑软件开发，使用 AI 超 6 个月的开发者，任务成功率高出约 10%

标准化工作（CRUD、模板代码、测试脚本）容易被替代，工程师的价值可以往业务理解、系统设计、质量验证方向集中。

二、面对AI，程序员面临着两条路

一条是传统方式。程序员接需求、写代码、改 bug、交付，不用或用AI工具辅助编程。这在目前还是主流，几年后大概率会慢慢消失。

另一条是驱动AI开发。程序员厘清业务目标和边界，明确约束（成本、性能、风险），让AI快速出方案对比，自己专注决策、评审和验证，代码编写大部分交给AI。互联网大厂已经在这么做了。

flowchart TD
 A["程序员"] --> B["继续深耕执行层"]
 A --> D["向设计和决策层拓展"]

 B --> C["工作稳定<br/>但增长空间逐渐收窄"]
 D --> E["承担更多责任<br/>价值空间打开"]

 style A fill:#444441,stroke:#2C2C2A,color:#ffffff
 style B fill:#D85A30,stroke:#993C1D,color:#ffffff
 style C fill:#BA7517,stroke:#854F0B,color:#ffffff
 style D fill:#185FA5,stroke:#0C447C,color:#ffffff
 style E fill:#993556,stroke:#72243E,color:#ffffff

两条路都在"做开发"，但职责已经不一样。

AI擅长执行定义清楚的任务，定义越清晰执行越好。所以核心问题不是AI会不会取代程序员，而是你工作中有多少是"定义问题"、多少是"执行问题"。定义问题（设计和决策），AI暂时替代不了；执行问题（Coding），AI很可能干得比你好。

一句话说，决策力 > 执行力。

三、程序员不会消失，但价值在改变

AI强在执行，弱在决策。它可以给出十个方案，但不知道哪个更适合你的业务节奏、团队水平和项目预算。它能生成大段代码，但它不知道哪个更适合你。有些事AI目前还做不了或做不好：

这个需求到底值不值得做
哪些边界必须守住，约束条件是哪些
哪些复杂度属于过度设计
哪些性能问题将来可能会是隐患
这次交付到底算不算真解决了用户的痛点

程序员的价值，正在从"代码编写"往上迁移：

flowchart BT
 A("代码生成 正在被 AI 快速替代，执行层AI做的比人好")
 B("方案选择 — 需要工程知识判断，算法与设计模式的应用")
 C("系统设计与边界定义 — 需要架构思维,算法与设计模式的应用")
 D("需求理解与业务判断 — 需要行业经验，需要理解现状")

 A --> B --> C --> D

 style A fill:#BA7517,stroke:#854F0B,color:#ffffff
 style B fill:#185FA5,stroke:#0C447C,color:#ffffff
 style C fill:#534AB7,stroke:#3C3489,color:#ffffff
 style D fill:#1D9E75,stroke:#0F6E56,color:#ffffff

越往上层业务，越靠近需求、边界和约束，就越离不开人。

以前只是写代码，现在的要求是：

能不能把业务问题讲清楚
能不能定义好边界、约束和取舍
能不能判断 AI 的产出哪里靠谱、哪里有坑
能不能对最终交付结果负责

重心从"把代码写出来"移到"把问题定义好、把系统设计好、把结果验证好"。

四、几种程序员岗位的变革

程序员岗位有很多种，不同岗位受冲击的方式不一样。我们看下前端、客户端、后端、大数据和全栈，各自面临什么变化，可以往哪走。

角色	根本变化	需要投入的方向
前端工程师	从交互实现转向产品界面工程	设计系统、产品工程、AI UI 审查
客户端工程师	从功能开发转向终端体验负责	端侧架构、稳定性工程、跨端体验
后端工程师	从接口开发转向领域建模与系统设计	业务架构、平台治理、可观测性
大数据工程师	从跑任务转向数据资产与决策系统	指标治理、数据产品、智能分析
全栈工程师	从什么都要写转向一人交付业务	独立产品、微型 SaaS、技术合伙人

1. 前端工程师

还原设计稿、写交互、对接口、做兼容，这些AI已经能完成大半。前端得往更上层走，走到需求和UI交互那里。

flowchart TD
 subgraph past [" 传统职责 "]
 direction TB
 P1["还原设计稿"]
 P2["编写页面交互"]
 P3["接口联调"]
 P4["浏览器兼容适配"]
 end

 subgraph future [" 转型方向 "]
 direction TB
 F1["设计系统工程师<br/>组件库 / 设计规范 / 变体策略"]
 F2["产品界面工程师<br/>用户旅程 / 交互规则 / 状态建模"]
 F3["AI UI 审查工程师<br/>生成审查 / 质量兜底 / 可访问性"]
 end

 past -- "AI 承接执行层" --> future

 style past fill:none,stroke:#ffffff,color:#ffffff
 style future fill:none,stroke:#ffffff,color:#ffffff
 style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

拿电商前端来说。以前主要写商详、购物车、结算页面，现在更值钱的是定义这三个流程的交互规则、组件模型和状态流转，让AI针对不同渠道（PC、移动、小程序）快速生成页面变体。

转型后需要做到几件事：从用户旅程出发，识别哪些交互影响转化、哪些状态流转容易出错，而不只是按设计稿做；定义组件库、API 规范、变体策略，让一个组件系统支撑多个业务线；用状态机等方式定义复杂交互，而不是靠堆 flag 变量；用工具验证可访问性和兼容性，而不是手工测每个浏览器。

一个衡量方式：能不能用5个组件规范加一套状态规则，让AI生成一个完整业务流程的页面。通过引导AI来提升效率，尤其是全业务流程的交互验证。

2. 客户端工程师

客户端看起来也能被AI大量生成，但有个天然门槛：真实设备环境太复杂。弱网、低端机、系统版本碎片化、厂商定制，这些AI没法自己搞定。

flowchart TD
 subgraph past [" 传统职责 "]
 direction TB
 P1["功能页面开发"]
 P2["接口对接"]
 P3["UI 还原"]
 P4["手工测试适配"]
 end

 subgraph future [" 转型方向 "]
 direction TB
 F1["端侧架构师<br/>首屏策略 / 离线架构 / 缓存分层"]
 F2["稳定性工程师<br/>容灾降级 / 崩溃治理 / ANR 优化"]
 F3["终端体验工程师<br/>性能监控 / 设备适配 / 弱网优化"]
 end

 past -- "AI 承接执行层" --> future

 style past fill:none,stroke:#ffffff,color:#ffffff
 style future fill:none,stroke:#ffffff,color:#ffffff
 style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

拿电商App客户端来说，核心工作会变成设计首屏加载策略、离线缓存方案、网络异常时的UI降级和重试机制。代码让AI来，架构决策靠人。

转型后要做到的事：定义首屏、离线、缓存、网络分层的整体策略；网络异常时怎么补偿、版本不兼容时怎么降级、内存溢出时怎么恢复；用 Lighthouse、RUM 等工具定义可量化目标并持续追踪；理解 Android/iOS 版本差异和厂商坑点，提前规避而不是靠测试发现。

一个衡量方式：能不能独立设计一套完整的弱网加载方案，包括缓存、重试、降级和通知。

3. 后端工程师

后端跟前端一样受冲击很明显。接口开发、ORM映射、CRUD服务、脚手架代码，规则明确、重复度高，AI最擅长。继续在"写接口速度"上卷，性价比越来越低。

flowchart TD
 subgraph past [" 传统职责 "]
 direction TB
 P1["CRUD 接口开发"]
 P2["数据库表设计"]
 P3["业务逻辑编码"]
 P4["Bug 修复"]
 end

 subgraph future [" 转型方向 "]
 direction TB
 F1["领域架构师<br/>业务建模 / 事件设计 / 一致性边界"]
 F2["系统设计工程师<br/>服务切分 / API 契约 / 熔断策略"]
 F3["平台治理工程师<br/>可观测性 / 成本优化 / 容量规划"]
 end

 past -- "AI 承接执行层" --> future

 style past fill:none,stroke:#ffffff,color:#ffffff
 style future fill:none,stroke:#ffffff,color:#ffffff
 style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

拿交易系统来说，核心工作会变成设计订单、支付、库存的事件模型和状态机，定义库存扣减的一致性策略，设计补偿和重试机制。这些决策出错代价很高，代码可以交给AI，设计决策必须人来做。

需要补齐的能力：从业务流程反推数据模型、事件序列、一致性边界；服务怎么切、API 规范怎么定、熔断降级怎么处理、跨服务一致性以及高并发稳定性怎么保证；日志、链路追踪、指标体系要建好，系统出问题时 15 分钟内定位，而不是人工排查；缓存、索引、分片、数据库选型，每一个都是成本和性能的折衷。

从"CRUD工程师"到"系统设计工程师"，通常需要一定时间的沉淀，最好经历过一两次大规模的重构或性能优化。这类能力稀缺性最高，竞争也最激烈。一旦具备了较好的系统设计能力，AI就不好替代了。

4. 大数据工程师

数据工程师的日常是写SQL、搭ETL、配调度、做报表、修口径。模式化很强，AI非常擅长。

flowchart TD
 subgraph past [" 传统职责 "]
 direction TB
 P1["编写 SQL / ETL"]
 P2["配置调度任务"]
 P3["制作报表"]
 P4["修数据口径"]
 end

 subgraph future [" 转型方向 "]
 direction TB
 F1["指标治理工程师<br/>指标体系 / 口径统一 / 因果分析"]
 F2["数据产品工程师<br/>自助平台 / A/B 实验 / 数据服务化"]
 F3["决策系统架构师<br/>实时链路 / 特征工程 / 智能分析"]
 end

 past -- "AI 承接执行层" --> future

 style past fill:none,stroke:#ffffff,color:#ffffff
 style future fill:none,stroke:#ffffff,color:#ffffff
 style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

原来负责日报和埋点的工程师，可以转做"指标治理"或"增长分析平台"，定义GMV、漏斗、配送时长等关键指标的计算口径，建立从原始事件到指标的计算链路，让业务方能自己查数据。代码AI生成，但指标定义和业务逻辑的对错必须人把关。

需要补齐的能力：什么是关键指标、怎么分层、指标之间的因果关系是什么；不同系统对"用户""订单"等概念的定义不同，怎么统一；什么指标该实时算、什么该离线跑，成本和延迟怎么平衡；把数据管道包装成面向业务的自助工具。

从"数据工程师"到"数据架构师"需要深入理解业务。纯技术背景容易做出"技术正确但业务用不上"的东西，这点要特别注意。一旦拥有了业务能力，AI替代的可能性也很小了。

5. 全栈工程师

全栈在AI时代其实是最有机会的。前后端、脚本、部署、测试都能让AI代劳后，真正能把一个完整产品从需求做到上线的人，反而更稀缺。

flowchart TB
 subgraph past [" 传统职责 "]
 direction TB
 P1["前端页面开发"]
 P2["后端接口编写"]
 P3["简单运维部署"]
 P4["各种杂活兜底"]
 end

 subgraph future [" 转型方向 "]
 direction TB
 F1["独立产品工程师<br/>需求澄清 / 产品设计 / 一人交付"]
 F2["技术合伙人<br/>垂直 SaaS / 微型产品 / 商业闭环"]
 F3["AI 协作交付专家<br/>全链路 AI 协作 / 快速迭代"]
 end

 past -- "AI 承接执行层" --> future

 style past fill:none,stroke:#ffffff,color:#ffffff
 style future fill:none,stroke:#ffffff,color:#ffffff
 style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

比如给中小培训机构做"招生线索管理 + 课消分析 + 家长回访"的轻量SaaS。过去至少3-5人团队，现在一个人加AI可以做出第一版并上线收费。关键不在技术栈多全，而在能独立走完从业务分析到上线运维的全过程。

需要的能力更偏产品和交付：能跟业务方聊需求、做原型、定优先级；功能、性能、成本、速度之间怎么权衡，前后端一起考虑；从开发到上线、监控、迭代，整条链都能自己搞；知道怎么评估产品是不是真的解决了问题。

转型周期1-2年，最好在小团队或个人项目里完整试过。市场机会最大，垂直SaaS、内部工具、创业项目都缺这样的人。之前，中大型企业倾向专业分工，全栈的主战场在小公司、创业或者创新项目。现在AI兴起了，中大型企业也转向全栈开发了。

上面只是列举了几种工程师岗位，其他诸如算法、系统、运维、测试等工程师，也同样面临着转型，都需要转型为AI驱动者。

五、程序员可以转型的路线

AI时代下，个人公司越来越多，一个人或几个人干一个团队的活也很正常了。但也不是每个人都要做管理或创业，如果你还是继续奋斗一线，以下几条路也走得通。前两条是基于现有岗位转型，后三条是岗位之外的新路径。

flowchart TD
 A(["程序员转型路线"])
 A --> B["路线 1<br/>架构与系统设计"]
 A --> C["路线 2<br/>业务需求与产品工程"]
 A --> D["路线 3<br/>个人产品与独立开发"]
 A --> E["路线 4<br/>高效交付与自由职业"]
 A --> F["路线 5<br/>企业 AI 落地顾问"]

 style A fill:#444441,stroke:#2C2C2A,color:#ffffff
 style B fill:#185FA5,stroke:#0C447C,color:#ffffff
 style C fill:#1D9E75,stroke:#0F6E56,color:#ffffff
 style D fill:#D85A30,stroke:#993C1D,color:#ffffff
 style E fill:#BA7517,stroke:#854F0B,color:#ffffff
 style F fill:#534AB7,stroke:#3C3489,color:#ffffff

路线 1：架构设计和系统设计

对应第四章后端岗位的延伸，适合后端、资深全栈、基础架构工程师。价值不再是写服务，而是定义边界、切模块、做容量规划、定 SLA、控制成本，决定哪些交给 AI、哪些必须人工兜底。典型路径是从多年订单系统的后端工程师升级成业务架构负责人，拆业务域、定事件模型、做容灾策略。

路线 2：业务需求和产品工程

适合前端、客户端和做了很多年业务开发的人。AI 最怕的不是代码难写，而是问题说不清楚，真正理解业务的人在 AI 时代反而更值钱。比如长期做运营平台的前端，懂业务流程、权限模型、表单规则，完全可以升级成"产品工程师"，自己对需求、拉 AI 生成页面和接口、自己做验收。

路线 3：做个人产品，打造小而美的应用

这是AI时代给程序员最大的新增机会。

以前一个人做产品，难在人手不够、周期太长。现在门槛大幅降低。有技术底子加上AI协作，垂直行业SaaS、小型管理后台、内部工具、数据分析工具，一个人就能启动。

比如全栈工程师针对某个垂直行业做轻量管理工具。以前至少3-5人团队，现在一个人加AI可以做出MVP、上线、收费、迭代。核心竞争力不是技术多全面，而是对行业的理解和快速交付能力。

路线 4：高效交付和自由职业

以前做兼职，最大问题是时间不够、交付太慢。现在不一样了。

把AI用到交付流程里，很多中小项目变得可做，比如企业官网、CRM/ERP定制、小程序、数据报表平台、自动化脚本。

比如熟悉React和Java的工程师，以前接一个后台系统要6周。现在把需求拆清、让AI生成前后端主体代码、自己盯业务规则和部署，2-3周就能交第一版。单价未必更高，但单位时间产出明显提升。

路线 5：企业AI落地顾问

门槛不低，但适合资深工程师。

很多公司不缺"会用AI的人"，缺的是能把AI真正接进研发流程的人。怎么建团队提示词规范、搭内部知识库、让AI参与编码测试评审、定义自动化边界、把模型能力接进业务系统。

比如做过平台工程或数据平台的工程师，可以给中型企业做"AI研发效能改造"。不是卖概念，而是把需求模板、代码规范、知识库、测试策略、自动审查流程都具体落下来。

六、用好AI，实际能带来什么

学 AI 的收益大致在四个方向：交付效率提升、能承接更复杂的项目、晋升时有明显优势（架构师、技术负责人类位置会优先考虑既懂系统设计又能用 AI 提效的人）、职业自由度更高（兼职、独立开发、小团队门槛下降）。

现在会用 AI 是个优势，就像当初会用电脑一样。但当"用 AI"变成基本技能后，这个优势也会被拉平。真正长期升值的，是系统设计能力、业务理解能力、AI 协作能力的组合，而不是单纯的"我会用 AI，我掌握了 Agent 的工作流程"。

flowchart LR
 A["掌握 AI 协作"] --> B["交付更快更稳"]
 B --> C["进入设计与决策层"]
 C --> D["承担更高价值的工作"]
 D --> E["职业选择更多"]

 style A fill:#185FA5,stroke:#0C447C,color:#ffffff
 style B fill:#534AB7,stroke:#3C3489,color:#ffffff
 style C fill:#D85A30,stroke:#3C3489,color:#ffffff
 style D fill:#1D9E75,stroke:#0F6E56,color:#ffffff
 style E fill:#ff6600,stroke:#0F6E56,color:#ffffff

用好AI其实挺不容易的，这是一门新的学问。有了得心应手的工具，如何驾驭它，让它真正发挥高效价值，需要不断探索和实践。

七、以下四种能力值得增强

根据这两年的AI编程实践，尤其是2025年下半年来，以下四种能力很有价值，也能经得住时间的考验。

1. 把问题定义清楚

很多人觉得 AI 生成质量不高、不符合需求，但可能根本原因是问题没说清楚。可以按这五个维度来拆解需求：

What：具体做什么，关键词搜索、标签筛选还是组合查询
Who：给谁用，内部员工还是终端用户，技术水平如何
Scale：数据规模和并发量多大，这直接决定技术方案
Constraint：响应时间、成本、精度各要求多少
Edge：哪些边界必须处理，空值、超长输入、特殊字符、多语言

把这五个问题答清楚再让AI动手，产出质量会好很多。

2. 做好系统设计的权衡

AI 能快速产出几个方案，但选哪个、为什么，还是要靠人判断。

每次推进方案时，都认真思考一遍这几组权衡：

功能和时间：这个版本必须做什么、可以砍什么
性能和成本：缓存、CDN、数据库投入多少才划算
通用和特化：值不值得做通用方案，还是针对当前业务定制
简单和完善：第一版要多完善，容灾、监控、扩展性做到什么程度

这些没有标准答案，需要经验，更取决于公司的发展阶段、预算和风险承受力。AI是帮不了你做这个决定的。

3. 整理问题思路，给AI指方向

AI很强大，但都是按照已有的通用规则去解决问题。每个企业、每个项目并不相同，其中都需要很多个性化的考量。

比如遇到搜索问题，你得判断该用索引、倒排还是 B 树；遇到调度问题，得判断贪心够不够、要不要上动态规划；遇到实时计算，得决定时间窗口怎么划分、迟到数据怎么处理。

快速判断问题类型、给出方向，AI负责实现细节。方向对了，效率能翻好几倍；方向错了，代码生成再快也是白搭。

4. 验证AI的产出

AI 最常犯的错是"看起来对但其实有问题"。审查时至少扫一眼这几类：

业务逻辑：主路径、分支、边界、异常、并发与幂等，都是 AI 容易糊弄过去的地方
数据：输入分布、字段精度、时区编码、老数据兼容、跨服务一致性
性能：N+1 查询、索引命中、大数据量下的内存和响应、缓存策略
安全：注入与跨站攻击、权限校验、敏感信息日志、外部输入校验、依赖漏洞
可维护性：命名分层、魔法数字、测试覆盖、半年后能不能接手
其他：日志级别、遗留 TODO、上下游稳定性、自动化扫描是否跑过

细节不必每次全过，但出问题的地方大多落在这几类里。

八、程序员的转型实战路线

我们得做好准备，全面切换到驱动AI编程，自己很少或不写代码，完全利用AI来写。

flowchart LR
 A["第 1-2 个月<br/>把 AI 接入日常开发"]
 --> B["第 3-4 个月<br/>补需求、架构、验证能力"]
 --> C["第 5-6 个月<br/>做一个完整的实战项目"]

 A1["代码生成 / 测试生成 / 文档生成"]
 B1["需求拆解 / 系统设计 / 代码审查"]
 C1["从需求到上线<br/>沉淀知识库和模板"]

 A --> A1
 B --> B1
 C --> C1

 style A fill:#D85A30,stroke:#993C1D,color:#ffffff
 style B fill:#185FA5,stroke:#0C447C,color:#ffffff
 style C fill:#1D9E75,stroke:#0F6E56,color:#ffffff
 style A1 fill:#D85A30,stroke:#993C1D,color:#ffffff
 style B1 fill:#185FA5,stroke:#0C447C,color:#ffffff
 style C1 fill:#1D9E75,stroke:#0F6E56,color:#ffffff