公司项目水太深，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 团队。

"Teams can store and share commands, notebooks, env variables, and prompts in Drive. Drive objects are available to teammates -- especially useful during onboarding and firefighting -- as well as agents doing long running tasks. This is highly useful for standardizing your team's knowledge, workflows and conventions so that agents understand them and perform tasks in the same way a teammate would."

但注意到了关键词吗------"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 配置

还记得这篇文章吗，Agent 可不会管这种规范哦

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 目前还很难具备的。