企业官网建设流程全解析

《我重新梳理程序员就业后，先删掉了这些无效投入》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。

摘要

去年这时候，我还在纠结简历上写"熟悉 LangChain"能不能过筛。今年带小团队把 Claude Code 接入日常开发，才真正看清企业招人的逻辑变了。不是变难了，是筛法变了。

---

目录

• 就业市场变化：从"会不会写"到"能不能收"
• 代码解释
• 企业真实需求：能回滚的人比能写代码的人值钱
• 技能组合：AI 时代的能力重新排序
• 简历项目：从"用了什么"到"解决了什么"
• 面试策略：别只准备"标准答案"
• 适用边界
• 总结

就业市场变化：从"会不会写"到"能不能收"

2024 年到 2026 年，AI 编程工具经历了从个人玩具到团队基础设施的转变。Codex、Claude Code、Cursor 这些工具，个人开发者用起来确实快——一个 CRUD 接口几分钟生成。但真正进团队后，问题才浮出水面。

我团队当时接入 Claude Code，写了个内部工单系统。Demo 跑得很顺，业务逻辑、前后端联调、甚至单元测试都生成了。上线第一周，生产环境出现了权限越界问题——AI 生成的代码里，某个接口直接用了管理员 Token 去查用户数据，没有做租户隔离。

排查过程是这样的：先发现用户 A 能查到用户 B 的数据，以为是查询条件写错，加了 WHERE 语句，问题还在；接着怀疑缓存没清，清了 Redis，还是不对；最后逐层看调用链，才发现 AI 在生成数据库操作时，直接复用了初始化时注入的全局连接对象，没有按租户创建独立会话。

# 问题代码：AI 生成的版本 class TicketService: def __init__(self): # 全局单例连接，没有租户隔离 self.db = get_admin_connection() def get_tickets(self, user_id): # 查询条件漏了租户过滤 return self.db.query(Ticket).filter( Ticket.status == 'open' ).all()

# 修复后：加上租户上下文 class TicketService: def __init__(self, tenant_context): # 每个租户独立连接 self.db = get_tenant_connection(tenant_context.tenant_id) def get_tickets(self, user_id): return self.db.query(Ticket).filter( Ticket.tenant_id == self.db.tenant_id, Ticket.status == 'open' ).all()

这个问题暴露了一个现象：企业开始问"你能不能处理 AI 写出来的代码"，而不是"你会不会用 AI 写代码"。前者是工程能力，后者是工具使用能力。2026 年的就业市场，对后者的溢价在快速下降。

---

代码解释

这段关键代码展示了 AI 生成代码的典型缺陷，以及修复的实现原理。下面逐段拆解。

问题代码分析：

• 输入：__init__无参数，get_tickets只接收user_id。
• 核心逻辑：初始化时调用get_admin_connection()获取一个全局数据库连接，后续所有查询都复用这个连接。查询时只按status == 'open'过滤，完全忽略了租户维度。
• 输出：返回当前租户管理员视角下的所有工单，而非当前用户所属租户的工单。
• 异常处理：代码中没有任何异常捕获。如果数据库连接断开或查询超时，会直接抛出原始异常，调用方无法做降级或重试。

这段代码的问题根源在于：AI 在生成时没有理解"多租户隔离"这个业务约束，把单租户的写法直接套用到多租户场景。

修复后代码分析：

• 输入：__init__新增tenant_context参数，携带租户 ID 信息。
• 核心逻辑：每次初始化时根据tenant_context.tenant_id创建独立的数据库连接，查询时同时过滤tenant_id和status，确保数据隔离。
• 输出：只返回当前租户的工单，其他租户数据不可见。
• 异常处理：虽然修复版仍未显式处理异常，但独立连接的设计让故障隔离成为可能——某个租户的连接问题不会波及其他租户。

这个 case study 说明，AI 生成的代码在"能跑"和"能用"之间，差的是对业务约束的理解。面试时问候选人"这段代码有什么问题"，能说出"缺少租户隔离"的人，比只会说"应该加异常处理"的人更接近企业需求。

---

企业真实需求：能回滚的人比能写代码的人值钱

接完 AI 工具后，我们团队做了一个内部统计：AI 生成的代码，首次运行通过率从 30% 提升到 75%，但代码审查发现问题率反而从 15% 升到了 40%。问题类型集中在三类：权限配置错误、日志缺失、异常处理粗糙。

企业现在面试，更多在考察这三项能力：

第一，代码审查能力。 给你一个 AI 生成的 PR，你能不能快速定位风险点。我们面试时会直接给一段 AI 生成的代码，让候选人找问题。真正能过的人，不是背过多少安全规范，而是有"这段代码如果上线会怎样"的敏感度。

第二，回滚和修复能力。 AI 写错了，你怎么救场。是重写、打补丁、还是配置降级？我见过候选人面对 AI 生成的烂代码，第一反应是"我再写一遍"，结果时间不够。真正稳的人会说"先看影响范围，再决定是修还是绕"。

第三，工程边界意识。 什么该用 AI，什么不该用。我们的经验是：CRUD、模板代码、单元测试，交给 AI；权限模型、数据一致性、异常恢复，必须人手。面试时问"你什么时候不用 AI 工具"，比问"你会用什么 AI 工具"更能筛出人。

---

技能组合：AI 时代的能力重新排序

2026 年还在简历上写"熟练掌握 XX 框架"的人，竞争力在下降。不是因为框架不重要，是因为 AI 已经能把框架用得很熟练了。真正拉开差距的是：

调试和排查能力。 AI 生成的代码出问题，日志往往不完整。你得会看调用栈、会加临时日志、会用断点。我面试时会问："线上某个接口偶发超时，你怎么定位？"能答出"先看 P99 延迟分布，再抓慢请求的调用链，最后看数据库锁等待"的人，比只会说"加日志"的人强一个量级。

系统边界设计。 AI 擅长在边界内生成代码，但不擅长定义边界。面试常考的场景是：给你一个需求，画出数据流向和异常点。能清晰说出"这里需要幂等性保障""那里需要降级策略"的人，证明有系统思维。

运维和可观测性。 这是很多候选人的盲区。AI 生成的服务，没有健康检查、没有指标暴露、没有告警规则。面试时问"你的服务挂了怎么知道"，能答出 Prometheus 指标、Sentry 异常捕获、日志聚合的人，明显更有竞争力。

---

简历项目：从"用了什么"到"解决了什么"

我看过太多简历，项目经历写的是"基于 LangChain 实现了 XX 功能"。这种写法在 2024 年还行，2026 年基本等于没说——因为 AI 也能基于 LangChain 实现。

真正有用的写法是：问题是什么、约束条件是什么、你做了什么取舍、结果怎么验证。

举个例子，我团队做的一个工单系统，简历上可以这样写：

> 内部工单系统：面临多租户权限隔离问题，AI 生成代码存在全局连接对象复用风险。设计租户上下文传递方案，通过中间件注入 tenant_id，改造数据库连接池为租户隔离模式。上线后权限漏洞归零，P99 延迟从 120ms 降到 85ms。

这段描述里没有提"用了 Claude Code"，但能看出几个信息：你遇到过 AI 生成的问题、你知道怎么排查、你做了工程化改造、你有数据验证。这才是企业想看的。

失败原因可以拆成三类，面试时能区分这三类的人，说明有真实踩坑经验：

| 错误类型 | 典型表现 | 如何区分 |
|---------|---------|---------|
| 业务错误 | 逻辑跑通但结果不对 | 看输出是否符合需求描述 |
| 配置错误 | 启动失败或连接超时 | 看日志里的错误码和堆栈 |
| 环境问题 | 本地正常线上报错 | 对比部署环境的版本和配置差异 |

---

面试策略：别只准备"标准答案"

2026 年的面试，越来越像一次"协作场景模拟"。面试官会给你一个半成品代码，或者一段有问题的 PR，让你现场看、现场改。这种题没法背，只能靠真实项目经验。

我的建议是：准备一个你真正做过的项目，把里面的坑都过一遍。权限怎么设计的、异常怎么处理的、回滚怎么做的、日志怎么加的。面试时能说出"这里踩过坑，当时是这么解决的"，比背十个设计模式都有用。

还有一个容易被忽视的点：表达能力。你能不能把技术问题讲清楚，能不能说清取舍逻辑。面试最后往往有一轮"项目复盘"，让你讲一个做过的项目。能讲清楚"为什么这么做"的人，比只讲"做了什么"的人得分高很多。

---

适用边界

上面提到的所有建议，都有明确的适用边界，不能照搬。

适用场景：本文讨论的就业市场变化，主要针对 2-5 年经验的后端/全栈工程师。初级工程师（0-2 年）仍然需要证明基础编码能力，AI 工具对他们来说是加分项而非替代项。资深工程师（5 年+）的竞争力更多体现在架构设计和团队管理，AI 编程工具对他们的影响相对较小。

限制条件：不同行业差异很大。金融、医疗等强监管行业对代码安全性要求极高，AI 生成代码的审查成本更高，这类岗位对"能修 AI 代码"的能力溢价更明显。互联网创业公司可能更看重开发速度，对 AI 工具的接受度更高，面试侧重也会有所不同。

取舍建议：如果你正在准备面试，建议把 70% 的精力放在排查能力和工程边界意识上，30% 放在工具使用熟练度上。不要花大量时间背诵 AI 工具的 API——这些面试不会考，工作中随时可以查文档。

什么时候不应照搬：如果你的目标公司是传统企业数字化转型部门，他们的技术栈可能比较保守，AI 编程工具渗透率较低，此时传统的技术深度（数据库优化、分布式系统）仍然更重要。不要盲目跟风"AI 时代新玩法"，要根据自己的目标公司调整准备策略。

---

总结

AI 编程工具没有让程序员失业，但让一部分技能贬值了。会写代码不值钱，会修 AI 写的代码值钱；会用工具不值钱，知道工具在哪会出问题值钱。

2026 年拿到 offer 的人，通常有三样东西：能排查 AI 生成代码的工程能力、能判断什么该用 AI 什么不该用的边界意识、能把技术取舍讲清楚的表达能力。这三样，简历上写不出来，但面试时一问就知道你有没有。

我团队接入 AI 工具三个月，最大的收获不是开发效率提升了多少，而是看清了就业市场的筛选逻辑变了。那些还在用 2024 年的方式准备面试的人，可能会发现 offer 越来越难拿。不是因为要求变高了，是因为筛法变了。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。