AI Code 提效的陷阱

新闻

作者：微信文章
AI Code 提效的陷阱

身处大厂，时常会有一种割裂感。一方面可以依赖大厂的平台资源——充足的 LLM Token、成熟的 Agent 工具——可以快速体验和落地 AI 产品；但另一方面，大厂对 AI 的“执念”就像一场表演：汇报、KPI、所谓的鼓励创新，唯独真正的 AI 实践不被看见。

“降本增效”是如今最常听到的四个字。在 AI 出现之前，只有“降本”；而 AI 的到来，似乎终于补全了“增效”这两个字。但问题是：到底什么是真正的增效？

AI 天然提效：从一个简单的输入框开始，我们就能让 AI 翻译文章、优化文案、Review 代码、生成算法逻辑。进入 Agent 时代后，配合内置工具与 MCP，它甚至能完成更复杂的任务闭环。

然而，残酷的现实是：这些真正提效的场景，往往不被“看见”。因为它们不符合“宏大叙事”的标准——没有平台、没有整合、没有汇报 PPT 上闪亮的架构图。

于是，我们在追求“AI 提效”的路上，不知不觉陷入了多个陷阱。
“平台化”陷阱


进入 AI 时代，很多人做事的方式并没有发生本质变化：依旧妄图搭建一个统一的“AI 基座平台”来统一所有的人的 AI 实践，然后进行所谓对齐与共建……

但 AI 的本质是个性化助理，它的强大在于能根据每个人的思维习惯、工作流和上下文进行定制。个人的经验永远都优于平台上那些所谓的独特功能（本质上就是一段“保密”的 Prompt）。

个人看来，只需要选择一个你用起来顺手的工具（Cursor、Cline 或者 Claude Code），沉淀适合自己的知识库、模板、工作流，在合适的时机分享自己的经验，这才是真正提高效率的方式。
用 AI 解决本该由人解决的问题


AI 提效的最大陷阱，是人们寄希望于 AI 去弥补本该由人类完成的基础建设。

如果人类都不清楚该怎么做，凭什么指望 AI 自动推导出最优路径？

开发过程中，需求文档模糊不清、职责边界不清晰、设计稿件频繁改动，带来大量的讨论和时间浪费，没人关系其中的核心问题，反而在纠结：“AI 怎么理解不清楚需求？”。

于是，我们看到一堆人在研究“如何让 AI 更好地理解模糊需求”，而不是去思考：“为什么我们不能写出清晰的需求？”

这就像厨房漏水，不去修水管，反而训练一只狗去拖地。

真正需要结构化、可解析、可追溯的需求文档的，首先是人，其次才是 AI。AI 只是放大了原有系统的缺陷，而不是制造了新问题。同理，职责边界、团队合作、产品合理性等问题一样都被忽视了。
“开发速度不是瓶颈”


说到提效，人们总把焦点放在“开发提效”上——更快地写代码、更敏捷地迭代、用 AI 自动生成更多功能。仿佛只要开发够快，产品就能飞速前进。

但事实上，开发速度不是瓶颈。

Pawel Brodzinski 在其文章 https://pawelbrodzinski.substack.com/p/development-speed-is-not-a-bottleneck 中提到：

很多人认为，交付功能（或笼统地说，“开发”）的速度是产品发展的瓶颈。这其实是一种误解。

真正的瓶颈是“验证”
另一个瓶颈是“沟通”

更现实的情况是：验证和沟通的问题，最终都以“开发任务”的形式压到了我们开发身上。

就算没有 AI，以现在框架和工具的成熟度，开发早就已经不是产品的瓶颈了。而像上一段中提到的，真正该由人去解决的瓶颈不去解决，即使引入了 AI 辅助编码、持续增加人力投入、不断优化开发流程，项目依然不见起色。

---

总结：回归本质


AI 是工具，是杠杆，但肯定不是捷径。

我认为 AI 最革命性的意义，是极大的放大了个体的力量，过去需要依赖团队、平台或复杂流程才能完成的任务，如今只需一个清晰的 Prompt，个体就能独立完成内容生成、代码编写、数据分析等操作。

但同时，AI 或者 Agent 本质上可以看做是一个“人”：它无法超越人类在协作与认知上的局限。那些我们在现实中频繁遭遇的问题——模糊的需求、混乱的沟通、目标的不一致——在与 AI 协作时同样存在，甚至被放大。

所以不要掉进 AI 提效的陷阱，回归本质，我们到底需要 AI 解决什么问题？

否则，所谓的“AI 提效”，不过是消耗着昂贵的 Token，产出着廉价的 PPT，掩盖着陈旧的问题。