AI 提效后，人更忙了
今天鸭鸭看到一个挺真实的话题。
36 氪最近写到，AI 工具确实让程序员的编码效率提升了。比如有团队编码时间缩短 40%，整体效率提升 20%；也有团队交付周期明显压缩。
听起来很爽。
但评论区和很多一线同学的体感，没那么爽。
“我不明白，AI 的发展为什么不是让我们能 5 点下班，而是让更多人被裁员，其他人继续工作到 10 点。”
“两年前，我们工作的节奏还可以，但 AI 到来之后，这个状态不存在了。节奏一下子被拉快了，因为管理层觉得 AI 可以极大提升效率，以前还能按正常周期推进的事情，现在都默认你应该更快给结果。”
“现在我们内部的考核，其实已经慢慢往 AI 那边偏了。最直接的就是代码量，我们有一个排行榜，谁发了多少行代码，一刷就能看到。组里有个别人几乎全靠 AI 在写，代码量和 PR 数量一下子拉得特别高，慢慢大家就都被拿去跟这种人对标。慢慢就有点变味了，一开始是比代码量，后来开始比谁用 AI 用得多，再往后连 Token 都开始被看。这些东西其实没有写进绩效，但你心里都清楚，什么是会被看到的。”
从上面三个程序员的讲述里，能明显感觉到，行业里的气氛在变，大家都在被迫提速。
代码写快了，需求也变多了。
原来一周给一次进度，现在两天就要看结果。
原来一个人慢慢写一个模块，现在 AI 一口气吐出三版代码，人还要负责审、改、测、背锅。
最难受的是，老板看到的往往只有前半句：
“AI 让你提效了。”
后半句他可能自动补成：
“那你应该接更多活。”
这就很微妙。
因为程序员真正的工作，从来不只是敲代码。
写代码快了，不代表需求澄清快了。
不代表接口联调快了；不代表测试回归快了；也不代表线上出问题时，AI 会替你在群里解释。
说白了，AI 把“生成代码”这一步加速了，但一个需求从想法变成稳定上线，中间还有很多人要磨的东西。
产品要改，接口要对，老系统要兼容，测试要回归，上线后还要看监控。
这些地方没跟着提效，最后就会出现一个很怪的局面：
AI 让某个环节变快了，但整个团队的节奏被硬生生拉高了。
鸭鸭觉得，这就是今天很多程序员的真实处境。
AI 没有让大家少干 20%，它让公司觉得你应该多交 20%。
这句话可能有点扎心，但挺像现在的职场逻辑。
公司给你买 Cursor、Claude Code、Copilot，不一定是为了让你早点下班。
更多时候，是为了让同样的人做更多需求。
以前一天写 200 行代码算正常。
现在 AI 一天能生成 2000 行，于是“正常工作量”也被悄悄改了。
你说这 2000 行里有多少能用？这事没人第一时间关心。
大家先看产出速度。问题来了再找人修。
……
所以今天这个话题，鸭鸭不想简单吐槽公司与 AI。
AI 肯定有用。
很多重复代码、测试样例、脚手架、接口文档，它确实能省时间。
问题在于，公司怎么理解“省下来的时间”。
如果省下来的时间都被塞进更多需求里，程序员当然不会轻松。
如果 AI 生成的代码质量没人管，后面维护的人会更痛苦。
如果考核只看用没用 AI、用了多少 AI，大家自然会开始刷指标。
这时候更该问的问题，其实是：
你们公司有没有重新设计研发流程？
比如：
- AI 生成的代码，谁来负责最终质量？
- AI 产出的代码，需要经过什么 Review 标准？
- 代码量增加后，测试资源有没有跟上？
- 需求交付周期缩短后，产品确认和灰度流程有没有缩短？
- 出事故时，责任算在工具、个人，还是团队流程？
这些问题不解决，AI 提效就很容易变成一种新的加班理由。
鸭鸭觉得，程序员接下来要特别小心一件事：
别让自己变成“AI 产能的清洁工”。
AI 负责疯狂生成。
你负责擦屁股、补测试、改边界、填文档、背线上事故。
这活听起来很高级，实际很累。
更好的方向，是把自己往“质量控制”和“系统设计”那一层挪。
你要能判断什么代码可以让 AI 写。
什么地方必须人来拍板。
什么需求看似简单，其实改动链路很长。
什么 AI 产出看起来能跑，但三个月后会变成技术债。
说到底，AI 提效这件事，对程序员有好处，也有新的麻烦。
它更像公司把油门踩下去了。
车能跑快一点。
但刹车、方向盘、仪表盘、保险杠，都得有人重新检查。
会写代码的人还重要。
会判断“这段代码该不该进主干”的人，会更重要。
大家怎么看？你们公司用了 AI 之后，是更轻松了，还是活更多了？
……
今天鸭鸭和大家分享一道 AI大模型面试题。
【MCP 架构包含哪些核心组件？ 】
回答重点
MCP 的核心是客户端-服务器架构，一个主机应用可以同时连接多个服务器。
整体由 5 个核心组件构成：
1）MCP 主机：想通过 MCP 访问外部数据的程序，比如 Claude Desktop、Cursor、各种 AI 工具都属于这一类。
2）MCP 客户端：与服务器保持 1:1 连接的协议客户端，负责和服务器通信。
3）MCP 服务器：轻量级程序，通过标准化的 MCP 协议向客户端暴露特定功能，包括数据源、工具、API 接口等。
4）本地数据源：MCP 服务器可以安全访问的本机资源，比如文件系统、本地数据库、系统服务。
5）远程服务：MCP 服务器通过互联网连接的外部系统，比如第三方 API、云服务。
扩展知识
MCP Client
MCP Client 是连接大模型和 MCP Server 的桥梁，负责在模型与外部工具之间传递信息、协调操作。整个工作流程是这样的：
1）MCP Client 先从 MCP Server 拉取可用的工具列表。
2）用户发起请求后，MCP Client 把工具信息通过 Function Calling 的形式发给大模型。
3）大模型根据上下文和工具描述判断要不要调工具、调哪些工具。
4）如果需要用工具，MCP Client 就代表模型通过 MCP Server 发起调用。
5）工具执行完，结果返回给大模型，模型整合所有上下文生成自然语言响应。
6）最后 MCP Client 把响应返回给用户，完成整个交互闭环。
目前 Claude Desktop、Cursor 这些产品已经内置了 MCP Client 能力，它们自己就能和 MCP Server 建立连接、完成工具调用的上下文感知与执行。
MCP Server
MCP Server 是整个架构的核心，负责向大模型提供结构化上下文和可调用的操作能力。它定义了三大类基础功能：
1）Resources：类似静态或动态的数据文档，比如 API 返回的 JSON、配置文件、项目结构，供模型查询参考。
2）Tools：模型可调用的函数接口，比如发请求、创建文档、执行命令，执行前通常需要用户授权来保证安全。
3）Prompts：预定义的提示模板，用来引导模型完成特定任务，比如代码审查、生成 commit message、总结会议内容，能提高交互效率。
通过这三类能力，MCP Server 让模型不仅能"看懂"信息，还能"动手"完成任务。
社区维护的 MCP Servers Repository 和 Awesome MCP Servers 里有大量开源的 MCP Server 实现。TypeScript 写的 MCP Server 通常用 npx 命令运行，Python 写的用 uvx 命令启动，部署起来很方便。
参考文档：
篇幅有限，更多 AI大模型 相关面试题可以进入面试鸭进行查阅。
