公司项目水太深，AI Agent它把握不住！

前言

最近，AI Agent 成了技术圈最火的话题之一。Claude 推出了 Claude Code，Warp 发布了 2.0 版本，各大厂商都在争相推出自家的 Agent 产品。朋友圈和社交媒体里时不时就能看到有人晒出”AI 帮我完成了一整个功能模块“、”我用 AI 三个小时写出了 XXX“的截图，评论区里充斥着”程序员要失业了“的调侃。

作为一名在一线搬砖的前端开发，我也尝试过在公司项目中使用 AI Agent。最开始的时候确实很兴奋，但实际用下来，发现事情远没有想象中那么美好。本文想和大家聊聊，为什么我认为现阶段的 AI Agent 还不太适合直接接管公司项目的开发工作，以及我们应该如何更合理地使用它。

AI Agent 的理想与现实

AI Agent 需要什么？

我们先来聊聊 AI Agent 的工作原理。不同于传统的 Copilot 式的代码补全，Agent 最大的特点是能够理解更大的上下文，并基于这些上下文做出更智能的决策。简单来说就是：上下文越丰富，提示词越详细，产出的代码质量就越高。

这个逻辑听起来很完美——我只需要把需求、业务规则、技术规范等信息喂给 Agent，它就能帮我生成高质量的代码，对吧？

理论上是这样，但实际情况要复杂得多。

公司项目的三个现实困境

1. 上下文的碎片化困局

让我们设想一个真实的场景：你接到一个新需求，需要在现有的订单系统中增加一个营销模块。

要理解这个需求，你可能需要：

• 去语雀查看产品的业务梳理文档
• 翻阅几个月前的 PRD（而且可能是那种只有产品经理自己能看懂的版本）
• 在公司自建的知识库里找技术方案
• 查看分散在 3 个不同仓库中的相关代码
• 询问已经转岗的老员工当初为什么要这么设计

这些信息分散在不同的系统、不同的文档、甚至不同人的脑子里。即便是工作了两三年的老员工，有时候也需要花大半天时间才能理清楚整个业务逻辑。

那么问题来了：如何把这些为人类阅读而写的、散落在各处的信息，整理成 AI Agent 能够理解的上下文？

我尝试过手动整理这些信息，发现整理的时间成本，往往比直接写代码还要高。更何况，很多隐含的业务规则和历史包袱，连文档都没有记录，只存在于老员工的经验中。

2. 稳定性的责任重量

公司项目和个人项目最大的区别，不在于代码量的多少，而在于对稳定性的要求不同。

当线上出现问题时，我们需要在极短的时间内定位并修复。这要求开发者对代码有足够的熟悉程度——不仅要知道代码做了什么，还要理解为什么要这么做，以及可能会在什么情况下出现问题。

使用 AI Agent 生成代码后，开发者的工作重心从编写代码转移到了阅读和审查代码。表面上看，似乎节省了编码时间，但实际上：

1. 阅读理解的成本可能更高：理解别人（包括 AI）写的代码，往往比自己写要花更多时间
2. 思路容易被打断：审查代码需要连续的注意力，但公司里总有各种会议和琐事打断你
3. 心理负担更重：使用 AI 生成的代码上线后，你会不会总是担心某个边界情况没有覆盖到？

这里想提一个可能被大家忽视的心理学现象：

如果你参加过 Code Review 会议，可能会发现一个有趣的事情：当代码作者侃侃而谈地讲解他的实现思路时，你往往很难发现其中深层次的问题。

这背后其实涉及两个心理学效应：

1. **锚定效应：**人们在决策时，会过度依赖最先获得的信息作为“锚点”，即使这个信息可能并不完全准确。
2. 框架效应： 信息的表述方式会显著影响我们的判断，而不仅仅是信息的内容本身。

当代码作者开始讲解时，他实际上为你设定了一个强大的“认知框架”。他的语言、逻辑和侧重点，会引导你按照他的思路去理解代码。你的思维被“锚定”在了他构建的这个框架上，很难跳出来从一个全新的、独立的视角去审视。

这使得我们在 Review 代码时，很难保持完全客观的判断。当讲解者能够头头是道地论证他的代码实现有多么优秀时，你往往会下意识地认为他是对的。

这种情况在面对“权威”时会更加突出。而 AI Agent，恰恰正在成为某种“权威”。

现在很多人已经接受了“AI 写的代码一定比人好”这样的观念。当你看到 AI Agent 在总结栏里洋洋洒洒地列举出一大段优势和价值——“使用了更高效的算法”、“考虑了边界情况”、“代码可读性更强”……你会不会下意识地降低审查的标准？

问题的根源在于：AI 的“自信”具有迷惑性。它不会像人类开发者那样说“我不太确定这个地方”、“这里可能需要再讨论一下”，而是总能给出看似完美的解释。这反而让我们放松了警惕。

当线上出现问题需要紧急修复时，如果你对 AI 生成的代码并不完全理解，定位问题的效率会大打折扣。你可能需要花更多时间去理解代码的逻辑，而不是直接凭借对业务和代码的熟悉快速定位。

这也是我为什么强调：对于公司项目，稳定性的责任重量要求我们对代码有足够的掌控感。而这种掌控感，目前还很难从审查 AI 生成的代码中获得。

3. 架构设计的长期视角

一个优秀的开发者，在实现需求时不会只考虑当前的功能，而是会结合产品的长期规划，做有前瞻性的设计。

举个例子：产品让你做一个简单的列表页，展示订单信息。有经验的开发者可能会这样思考：

• 这个模块，后端底层和另一个页面的接口是同一套，两个页面完全可以复用，只需要对现有页面进行改造即可，后续如果新增其他页面，也可以直接适配
• 产品后续会在页面上展示 XXX，需要预留口子，现有组件不支持，新起一个组件来承载，并且将旧组件标记为废弃，后续逐步做迁移

而 AI Agent 通常只会针对当前的需求做最直接的实现。它不会去猜测产品下一步可能要什么功能，也不会基于过往经验做前瞻性设计。

这就导致：当新需求来的时候，你可能需要大范围重构 AI 之前生成的代码，反而增加了工作量。

理想与现实的距离

说到这里，可能有同学会问：那是不是投入足够多的资源，就能让 AI Agent 在公司项目中发挥价值？

理论上是可以的，事实上，有大量的公司都自称完全使用 Agent 进行编码了，例如 Claude 和 Warp 团队。

但注意到了关键词吗——“standardizing”，想要最大程度发挥 Agent 的能力，你需要：

• 建立完善的知识库，把所有业务文档、技术规范统一管理
• 制定标准化的需求文档格式，让 AI 更容易理解
• 开发配套工具，自动提取和聚合项目的上下文信息（各种各样的 MCP）
• 持续积累和优化针对本团队的 Prompt 模板

但这需要什么？需要一个专门的团队，甚至多个部门的配合。需要产品、开发、测试、运维等多个角色共同参与，持续投入时间和精力去建设和维护这套体系。

对于大多数团队来说，这个成本是难以承受的。与其投入这么多资源去“教会” AI 理解我们的项目，不如把这些资源用在提升团队自身的开发效率上。

现阶段的 AI Agent 并非”无所不能“，想要 Agent 像人类开发者一样发挥最大作用，所需要的成本远超想象。这不是一个人、一个小团队能够做到的。

务实的使用策略

虽然 AI Agent 还不能完全接管公司项目的开发，但这不代表我们就应该彻底放弃使用它。关键在于找到合适的使用场景，发挥它的长处，规避它的短板。

以下是我在实践中总结的几个比较实用的场景：

1. 业务逻辑梳理

当接手一个陌生模块时，我们可以利用 Agent 的代码索引能力，快速理清业务逻辑。

示例 Prompt：

请分析 {} 目录下的代码，梳理出 {} 页面的完整业务流程，包括：
1. 页面的数据流转（从接口请求到数据展示）
2. 用户可以进行哪些操作
3. 各个操作对应的处理逻辑
4. 涉及到的状态管理
5. 外链和跳转情况（哪些页面会跳入/会跳转至哪些页面）

请以流程图的形式输出，并标注关键的代码位置。

这样可以大大缩短熟悉代码的时间，特别是在接手别人的代码时。

2. 影响面分析

在公司项目中，我们经常会遇到”牵一发而动全身“的情况——改动一个公共方法，可能影响十几个页面。我们可以通过 Agent 快速进行影响面的分析。

示例 Prompt：

我计划修改 {} 中的 {} 函数，新增/删除函数中的 {}

请帮我分析：
1. 哪些文件调用了这个函数
2. 这些调用场景下，新增/删除参数是否会影响现有逻辑
3. 是否有潜在的兼容性问题
4. 给出测试和回归建议，确保不会遗漏边界情况

分析时请考虑：
- 直接调用和间接调用
- TypeScript 类型检查是否能覆盖所有情况
- 是否有通过字符串动态调用的场景

这种影响面分析，人工做起来既繁琐又容易遗漏，而 Agent 可以通过代码索引快速完成。

3. 生成 Mock 数据

在开发阶段，我们经常需要 Mock 接口数据。手写 Mock 数据不仅繁琐，还容易遗漏一些边界情况。

示例 Prompt：

请你针对 {} 请求，包括其出入参的类型定义，以及使用场景，为我生成一份 Mock 数据

要求：
1. 针对详情接口，生成至少 5 组数据，覆盖所有可能的分支状态（例如状态）
2. 针对列表数据，同详情接口的要求，生成至少 5 条数据
3. 考虑边界情况：金额为 0/负数/空值、列表项为空数组/空值等
4. 数据要符合真实业务场景（例如一个已经取消的订单支付状态不应为已支付）
5. 使用中文生成富有语义的业务相关字段（如商品名称、门店名称、省市区等）

请直接输出 JSON 格式的字符串数据，不要有额外说明。

Agent 可以根据类型定义和代码逻辑，生成更贴合实际使用场景的 Mock 数据。

提升 Agent 编码表现的实用技巧

虽然让 Agent 完全理解公司项目需要很高的成本，但我们仍然可以通过一些小技巧，用较低的成本显著提升 Agent 的编码表现。

关键是利用 IDE 的全局配置功能（比如 Cursor 的 User Rules），提前告诉 Agent 一些基本的规范和约定。

1. 编码规范速查

在项目根目录或 IDE 配置中，维护一份简要的编码规范：

# 团队编码规范

## 命名约定
- 文件名使用 kebab-case，如 order-list.tsx
- TypeScript 类型不要添加 T、I、E 等前缀
- 类型字段注释格式： `/** 订单ID */`
- 常量和类型使用 PascalCase

## 文件组织
- 表格列定义、枚举等常量抽离到 config.ts（x）
- 接口参数格式化、复杂逻辑抽离到 helper.ts（x）
- 组件拆分原则：单个文件不超过 300 行

## React 规范
- 使用函数式组件和 Hooks
- 状态管理优先使用 zustand
- 避免在 useEffect 中做复杂逻辑

## 三方库使用
- 日期处理统一使用 dayjs，禁止修改全局 locale 配置

2. 项目特定约定

针对你主要负责的项目，沉淀一些基本信息：

# {} 工程

## 项目结构
主要关注 {} 模块，对应 {} 目录

## 业务规则
- 金额计算必须使用 lodash-es 的 multiply/divide 等方法，不要用 JS 原生运算
- 所有金额保留两位小数，使用 toFixed（2）

## 技术栈
- 表单组件优先使用 formily-mini （文档： xxx）
- 基础组件优先使用 gudesign （文档： xxx）
- 状态管理使用 mobx

## 目录约定
- 类型定义： src/types/order/
- 接口定义： src/api/order/
- 公共组件： src/components/order/
- 工具方法： src/utils/order/

## 注意事项
- 不要使用标为已弃用的方法和数据
- 尽可能使用现成的组件，谨慎创造新的组件

这样做的好处是：

1. Agent 生成的代码会自动符合团队规范
2. 能够避免一些常见的业务错误
3. 减少了后期的代码审查工作量

3. 场景化的 Prompt 模板

针对常见的开发场景，可以准备一些 Prompt 模板，例如重构代码：

请帮我重构 src/components/order-card.tsx 组件。

背景:
- 当前组件承担了数据获取、状态管理、UI 展示等多个职责
- 组件内部有 200+ 行代码,难以维护
- 多处使用了该组件,需要保证重构后的接口兼容性

重构要求:
1. 拆分出数据获取逻辑到自定义 Hook (useOrderCard)
2. 拆分出子组件:OrderCardHeader、OrderCardBody、OrderCardFooter
3. 使用 TypeScript 严格类型约束
4. 保持原有的 Props 接口不变

请先输出重构方案和文件结构,确认后再逐个文件生成代码。

在编写 Prompt 时，尽可能地按照 Prompt 工程的要求，这样可以显著提高 AI 的生成质量。如果你有其他非常牛X的提示词，也欢迎在评论区一起交流讨论～

总结

AI Agent 的出现，确实为开发工作带来了新的可能性。但我们要认识到，技术的进步不是一蹴而就的，工具的应用也需要因地制宜。

现阶段，AI Agent 更适合作为开发者的辅助工具，而非替代方案。它可以帮我们：

• 更快地理解陌生代码
• 自动化一些繁琐的工作
• 提供思路和参考实现

但核心的业务理解、架构设计、问题定位，仍然需要人来完成。

与其期待 AI 完全接管开发工作，不如思考如何更好地与 AI 协作：

• 在合适的场景使用 Agent
• 通过规范和约定提升 Agent 的产出质量
• 把节省下来的时间用在更有价值的工作上

最后想说的是，技术圈总是充满各种焦虑——前几年是”移动端开发要被取代“，现在是”AI 要让程序员失业“。但回过头看，真正优秀的开发者从来不是靠写代码的速度取胜，而是靠对业务的理解、对架构的把控、对问题的洞察。

这些能力，恰恰是 AI 目前还很难具备的。