写代码的门槛确实在降，但你是不是也发现：AI 给的方案能跑，却没人敢直接上线。卡住你的不再是语法，而是拆需求、定边界、算成本、扛故障这些活。这篇不谈恐慌也不灌鸡汤，只把工程师的能力拆成几层，告诉你哪层正在贬值、哪层在升值，以及具体往哪练。
先说结论：写代码这段活的门槛确实在降，但「能不能上线」这件事的门槛没降。你大概也遇到过这种场景——AI 给的方案跑起来没问题，评审会上却没人敢拍板上线，因为没人说得清它上线后会先崩在哪。卡住你的不是语法，是拆需求、定边界、算成本、扛故障这些活。
这篇不聊恐慌也不灌鸡汤，只把工程师的活拆成几层，说清哪层正在贬值、哪层在升值，以及具体该往哪练。涉及价格、跑分、榜单这类会变的东西，一律让你去站内对应页面看当时的数字，我不写死。
AI 真正替掉的是哪一段活
被接走的，是「把已经说清楚的需求翻译成代码」这一段。凡是能被写成一段清晰的输入输出描述的任务，都容易被拿走。反过来，需求本身就模糊、需要有人拍板定方向的部分，还是得人来扛。
有个不适用的情况要记住：强合规、强实时、涉及资金和人身安全的系统，就算 AI 写得再顺，最后也得有人签字负责。这种系统的评审流程不会因为工具有多强就简化。
- 给自己做次盘点：把最近一周的任务按「说得清」和「说不清」分成两堆
- 说得清的那堆占比越高，你当前的工作被接走的风险越大
- 说不清的那堆里，如果大部分是你在拍板而不是在等指令，这是好信号
- 连续几个月两堆比例不变，说明你在原地踏步，不管工具有没有变
能力分四层：从写函数到定边界
把工程师的能力粗略分成四层来看：第一层是语法和框架，第二层是模块和接口，第三层是系统和取舍，第四层是业务和责任。AI 对第一层的替代最彻底，对第二层是加速器，对第三层只能提供选项让你挑，第四层基本交不出去。
| 层级 | 典型活 | AI 介入程度 | 自查问法 |
|---|---|---|---|
| 语法与框架 | 写函数、调库、改样式 | 替代最明显 | 这段代码我还能比它写得更快吗 |
| 模块与接口 | 拆模块、定接口、写测试 | 明显加速 | 接口的异常路径我讲得清吗 |
| 系统与取舍 | 选方案、算成本、定降级 | 只给选项 | 这个选择我为什么这么定 |
| 业务与责任 | 背指标、扛故障、签字 | 基本交不出去 | 线上炸了我能不能第一时间定位 |
自查方法很土但有用：随便挑一个线上故障，问自己「我能定位到哪一层」。只能定位到某个函数报错，说明还停在前两层；能顺着链路说清是哪次取舍埋的雷，才摸到第三层。
系统设计的核心是取舍，不是画图
很多人把系统设计理解成画架构图，图好看就算设计好。其实设计真正的输出是一串「选 A 不选 B、代价是什么」的记录。图只是这些决定的副产品，换个角度画，背后的取舍不会变。
每一处取舍至少写清三件事：约束是什么（预算、人力、时间、合规），备选有哪些，最后为什么放弃其他几个。写不出第三点，说明这个决定是拍脑袋定的。
- 挑一个模块选现有系统里你熟的一块，不要求复杂，要求你真的知道它怎么跑
- 列三条路径给出三种实现方式，哪怕其中两种你觉得不现实也要写出来，这是训练视野
- 写崩点每条路径分别写「如果流量翻三倍、或换个人维护、或依赖的服务挂了，它会先崩在哪」
- 回填到文档把结论补进模块说明里，三个月后自己回看，看当时的判断对不对
不适用的情况也要说清：纯探索性原型阶段，过早写取舍说明会拖慢验证速度。但要在转正式开发前补齐，否则原型直接上线的坑都是这么埋的。
把 AI 当实习生：验收标准得你先立
换个心态就顺了：把 AI 当成一个手很快、但从没进过你公司系统的实习生。你不给它讲清输入输出、边界条件、失败时该怎么表现，它交回来的东西就大概率是废码——因为含糊的需求只能得到含糊的实现。
- 能否复现：同一份输入给两次，结果是否稳定，不确定的部分要标出来
- 异常路径：超时、空值、超大输入、依赖服务报错，有没有对应处理
- 依赖是否可信：它有没有偷偷引入新包、新服务、新权限
- 数据边界：有没有把不该传的字段传出去，日志里有没有记敏感信息
- 评审同标准：AI 生成的代码和人写的代码走同一套流程，别因为它快就开绿灯
例外情况也说一句：一次性脚本、临时验证代码可以只做最低限度检查，别为了跑个验证写一堆流程。但只要这段代码要进主仓库、要长期维护，就按上面的清单来。
成本、延迟、可维护性：三种工程嗅觉
这三种嗅觉不容易在课本上学到，但决定了你在第三层站不站得住。价格和延迟的具体数字一直在变，去站内对应页面看当时的记录，别背旧数。
- 成本嗅觉
- 清楚一次调用、一次重试、一份缓存各花在哪，别等账单来了才回头追
- 延迟嗅觉
- 知道链路上哪一步是瓶颈，首字慢和整体慢是完全两种处理方式
- 可维护性嗅觉
- 能判断这段代码三个月后换个人还能不能改得动
具体抓手可以看站内的 编程客户端为什么特别烧钱（/coding-client-token-burn） 和 日志该记哪几个字段（/api-log-fields-replay），两篇配合着读，成本和排障的直觉会快很多。
怎么练：把日常任务当训练场
不用专门找项目练，日常任务本身就是训练场，关键是有没有刻意加动作。下面三条可以按周执行，不用一次全上。
- 每周一个模块挑一个「本来能凑合过」的模块，补一份取舍说明和失败预案，写给自己看
- 先自己画再问接新需求时先自己出一版方案，再拿去和 AI 的输出对比，差异点就是你该补的认知
- 季度复盘每季度写一次能力复盘：这季度在哪一层有新东西。写不出来，就是没长
术语卡壳的话，可以翻 技术栈图谱（/stacks） 和 模型底层概念随手对照（/ai-dict/category/tech），把名字和实际场景对上号，比硬背定义有用。
几种常见的走偏方式
焦虑期最容易走的两条弯路，一种是只顾刷工具和插件，另一种是完全不碰 AI 还把效率差当骨气。中间那条路才是对的：把 AI 用在第一二层，把省下的时间投到第三四层。
- 只顾刷工具和插件，把熟练度当成能力提升，工具换一茬就归零
- 只会调接口不懂边界，出了故障只能等别人救
- 把「AI 写得快」当成自己的产出，评审时说不出为什么这么写
- 反向走偏：完全不碰 AI，把效率差当成骨气，最后被团队节奏甩开
看市场信号，而不是看情绪
判断行情别只看短视频结论。招聘描述里出现的词在变，注意「负责系统稳定性」「做技术取舍」「能独立定位线上问题」这类要求的比重，比看多少个框架关键词更有参考价值。
行业与岗位的冷热，可以到 AI 产品榜（/ai-rankings） 和 厂商与平台目录（/providers） 看实际动向，那里能看到哪些方向在持续投入。「程序员会被 AI 取代吗」这种问题的答案一直在变，建议直接看站内当时的记录，而不是记某个固定结论。
| 信号 | 说明什么 | 你的动作 |
|---|---|---|
| 岗位描述里稳定性、取舍类词变多 | 市场在为第三层能力付钱 | 把做过的取舍案例写进简历 |
| 同类岗位开始要求跨端、跨栈 | 单点技能在被合并 | 补一个相邻模块的完整链路经验 |
| 面试开始问故障定位过程 | 纯编码能力不再稀缺 | 准备两三个真实排障的复盘 |
常见问题
我现在只会写业务代码，是不是已经晚了？
不晚，但方向要调。业务代码本身就含大量取舍和边界判断，把这些显性化，就是系统设计能力的起点。从给现有模块补一份取舍说明开始，比报课更实际。
AI 生成的代码到底能不能直接上线？
能上线，前提是它走完了和人写代码完全一样的评审流程。关键不在谁写的，而在有没有人能为它的失败路径负责。没人能解释清楚逻辑的那段，就别合并。
系统设计能力具体怎么量化？
看三件事：能不能说清一个模块为什么这么拆、故障时先崩在哪、换个人接手要多久。这三问答得利索，说明能力在；答不上来，图画得再漂亮也没用。
非科班出身需要补哪些基础？
优先补三块：网络与请求生命周期、数据一致性与并发、错误处理与可观测性。这三块直接决定你能不能判断 AI 给的方案哪里会出问题，其余可以边做边补。
要不要为了不被淘汰去学模型训练？
取决于你的岗位。多数应用开发者更需要的是懂模型的边界和成本口径，而不是自己训模型。先去模型库和价格页把调用成本这件事摸清，收益更直接。
