AI越强，软件基本功越值钱：Agent工作法实战指南

前阵子看Matt Pocock聊AI时代的Agent工作法，有一句话特别戳我：AI越强，软件基本功越值钱。这句话直接点破了这波技术浪潮里最大的误区。很多人以为会写提示词就能做软件，但真正能驾驭Agent把活干漂亮的人，无一例外都是基本功扎实的老手。这篇文章想把这件事彻底讲透——什么才是AI时代的Agent工作法，软件基本功又该怎么理解、怎么练，以及像我这样的普通开发者，到底该怎样把这两样东西结合在一起用。

如果你现在正处于“用AI写代码一时爽，落地一跑火葬场”的状态，或者你已经在用Agent写项目，但总感觉产出不稳定、改来改去反而更累，那这篇内容就是写给你的。我会从原理拆解到实战案例，完整梳理一套可以直接复用的工作方法。

1. 先看清这波AI变化的本质：Agent不是自动补全的升级版

1.1 从Copilot到Agent，工作方式发生了什么变化

很多朋友对Agent的理解还停留在“一个更聪明的自动补全”。这其实是把一个范式级别的变化，缩小成了输入法层面的升级。要搞清楚Agent工作法，必须先看清它和传统Copilot式AI辅助的本质区别。

以前的Copilot类工具（包括各种IDE的AI插件）核心是“补全”。你写了一个函数开头，它帮你补完函数体；你写了一行注释，它帮你生成对应的代码。整个过程是逐行、逐块、围绕你当下光标位置展开的。你仍然是唯一的决策者、规划者和验收者，AI只是你的“高并发打字员”。

而Agent的本质是任务自治。你给它一个目标、一些上下文和可用工具的边界，它自己规划步骤、自己执行、自己检查结果、自己迭代修正。说得直白一点，Agent像一个“远程外包的实习生”，你交付需求说明，它给你交付产物，中间的过程你不必全程盯着。

这个变化带来三个关键影响。

第一个影响是错误前置。以前写错代码，错误发生在你敲键盘的那一刻；现在Agent写错代码，错误发生在它内部推理的某一环。也就是说，你要么在需求阶段就给出极其清晰的约束，要么就得在验收阶段火眼金睛。很多人在Agent项目里翻车，不是因为Agent不够强，而是因为需求太模糊、验收太随意。

第二个影响是确定性消失。你写代码，同样的需求你写一百次，核心逻辑是稳定的。但Agent是概率模型，同样的Prompt跑五次，五次可能给你五套完全不同的实现方案。这不是Bug，这是本质。所以Agent工作法里必须有一个“收敛机制”——通过拆细任务、固定上下文、套用测试用例，把概率性的输出压到确定性的结果上。

第三个影响是工作重心转移。以前写代码，时间花在“怎么写”上；现在用Agent，时间花在“写什么、怎么验收、怎么改”上。这个转移不是让程序员失业，而是把程序员从编码操作工重新拉回到架构师、审阅者、业务翻译者的位置上。

1.2 为什么说“会提需求”成了新的核心能力

既然Agent是外包实习生，那“提需求”就成了决定成败的关键。我见过太多人拿着一个一句话需求去跑Agent：“帮我写一个用户登录功能”，然后抱怨Agent写得不行。

这等同于你让一个刚入职的实习生“去搞一下用户登录”，然后他给你交了一堆你自己都看不懂的代码，最后你还得怪实习生能力差。问题不在实习生，在你这个需求提得太粗糙。

真正的Agent需求描述，至少要包含五个维度：

• 业务背景：这个模块为什么存在，服务对象是谁，上下游是什么。
• 明确交付物：是纯函数、API接口、完整页面，还是重构方案文档？
• 约束条件：语言版本、框架版本、编码规范、性能指标、安全要求。
• 负面清单：明确告诉Agent“不要做什么”，比如不要引入额外依赖、不要改公共类型、不要动数据库结构。
• 验收标准：你用什么方式判断这次交付是成功的？跑测试用例？看lint结果？还是人工代码走查？

把这五个维度写清楚，Agent的产出质量会有一个质的飞跃。Matt Pocock在他的实践分享里反复强调一个观点：Prompt不是写给你自己看的，是写给Agent看的，更是写给未来的你自己看的。一段好的任务描述，应该做到让另一个人类开发者也能拿着它直接开工，这样Agent才能做得好。

很多人觉得“会提需求”是产品经理的事，但在AI时代，这已经成了每个开发者的基本功。因为Agent把你的“实现能力”借走了，剩下的“定义能力”完全取决于你自己。

2. 软件基本功为何在AI时代反而更重要

2.1 基本功不是“背API”，而是“判断力”

一说基本功，很多人以为是要把API背得滚瓜烂熟、把设计模式图默写出来。真到了AI时代，这些记忆型知识恰恰是最不值钱的，因为Agent比任何人都记得全、记得准。

现在的基本功，重心在于判断力。AI可以瞬间给你一段代码，但你能不能判断这段代码好不好、适不适合当前项目、有没有坑，这完全依赖你的基本功。

举个最日常的例子。Agent给你生成一段代码，里面用到了某个库的某个API。你如果对那个库没有基本认知，你可能连它是不是维护活跃都不知道。但如果你以前读过那个库的源码，你会立刻意识到：诶，这个调用方式在高并发场景下有性能隐患。这种判断力绝不是背API能背出来的，它来自长期的代码阅读、项目实战和踩坑积累。

判断力具体分三层。

第一层是语法层判断：代码能不能跑、会不会报错。这层目前AI做得很好，你的基本功需求并不高。

第二层是逻辑层判断：并发安全吗？边界条件处理了吗？内存泄漏风险存在吗？失败回滚策略有没有？这层需要你真正理解编程语言的运行时机制和计算机系统原理。

第三层是设计层判断：这段代码放进这个项目里合适吗？它是过度设计了还是设计不足？它会影响未来的扩展性吗？它和现有代码风格一致吗？这层需要的就是软件工程功底。

Agent能帮你解决第一层的大部分问题，偶尔能帮你发现第二层的一些问题，但第三层几乎只能靠人。而且第三层的判断能力越强，你越能把Agent用在刀刃上。

2.2 代码阅读：AI时代最重要的基本功之一

我特别想强调的一项基本功是代码阅读能力。以前的代码阅读是为了“接手别人代码”，现在的代码阅读是为了给Agent建立上下文、为了高效验收Agent的产出。

你发现自己越难判断Agent写得怎么样。

所以我现在看一个候选人的水平，先不看他会多少框架，而是拉一段代码问他：这段代码哪里写得有问题？很多基本功不扎实的人上来就懵，因为他在学校根本没练过“读代码”，只练过“写代码”。

怎么练代码阅读？我有几个土办法：

• 每周定期找一个GitHub上的热门开源项目，不看文档直接看源码。
• 尝试给一个陌生的Module写README，只有读得懂才写得清。
• 带着“找茬”的心态读代码，每个函数先挑三个毛病再挑三个优点。
• 用Agent生成代码，然后强制自己逐行走读一遍，找出至少两处可优化点。

这些练习非常土，但坚持三个月，你对Agent产出质量的判断力绝对上一整个台阶。

2.3 调试、测试与审查：守住质量底线的三把锁

AI时代，写代码的活被Agent大量接管，但调试、测试、审查这三件事，反而比从前更重要。因为Agent天然会引入三样东西：不确定行为、信息幻觉、盲目自信。

我见过Agent写的“看起来很完美”的代码，一跑冒烟测试就崩。也见过Agent一本正经地引用了一个根本不存在的方法。更见过Agent自信满满地在一个关键事务里漏了回滚。这些都是概率模型的固有缺陷，不可根除，但可以拦截。

拦截的手段就是基本功三件套：

第一是调试能力。不要只会console.log看输出，要会断点、会看调用栈、会分析事件循环、会做条件断点。Agent说“代码写好了”，你连断点都不会打，怎么验证它的话？调试不只是定位Bug，更是理解程序运行时行为的唯一方式。

第二是测试能力。Agent生成的代码，你要会快速为它搭起测试用例框架。不是那种跑通就行的“happy path测试”，而是包含边界值、异常路径、并发场景的测试。如果你的测试功底太弱，你会发现Agent造的雷一个都炸不出来。

第三是代码审查能力。这是把关的最后一环，也是最需要工程经验的一环。审查时你要关注的不只是“有没有Bug”，更是“有没有延续团队的架构决策”“有没有引入不必要的复杂度”“有没有为了短期的通过测试而埋下长期的维护炸弹”。

这三把锁，每一把都锁在你的基本功上。工具越强，守门员越重要，这是Agent时代最简单的逻辑。

3. 一套可落地的Agent工作法实践指南

3.1 任务拆分：把需求拆成Agent看得懂、判得准的任务包

聊完了原理，进入实操。第一步，也是最关键的一步：任务拆分。

很多人在Agent项目上失败，根源在于一次性喂给一个超大的目标。“帮我把整个后端重构一遍”这种需求，对Agent来说就是灾难。因为它的上下文窗口有限、注意力会衰减、长链路规划会失真。你越是让它一口吃成胖子，它越容易在某个中间环节产生幻觉，然后一路错下去。

我推荐的做法是把大型任务拆成“任务包”，每个包必须满足三个条件：

• 独立性：这个包完成之后，可以独立验证。
• 连贯性：包与包之间有清晰的接口契约，不依赖中间态实现细节。
• 可验收性：你能够明确说出“这个包算做完”的判断标准。

拿最常见的“给现有项目加一个新功能”来举例。一个大需求“添加订单导出功能”，我不会直接扔给Agent。我会这样拆：

1. 设计订单导出数据的DTO结构，明确导出字段、格式、排序规则。
2. 编写订单查询逻辑，支持按时间范围、状态筛选，并做分页。
3. 实现CSV格式序列化器，含BOM头、流式写入、内存控制。
4. 新增导出任务接口，加基础鉴权。
5. 编写集成测试，覆盖空数据、筛选条件、权限校验失败的场景。

每个包的目标是具体、单一、可验证的。我给Agent下任务的时候，一次只发一个包。第一个包的产出验收通过后，再发下一个。

拆包过程非常考验你的架构能力。你必须在功能还没实现之前，就对模块边界、数据结构、接口形态有清晰的预判。这恰恰是要靠软件基本功的。拆得好的任务包，Agent执行效率高、返工率低；拆得烂的任务包，Agent大概率跑偏。

3.2 上下文管理：给Agent喂什么，决定它给你什么

Agent不是千里眼。你代码仓库里有什么，它是完全不知道的。除非你主动告诉它，否则它只能靠你Prompt里的只言片语，加自己训练数据里的“通用印象”来瞎猜。

所以上下文管理，是Agent工作法里最容易被忽视、但收益最高的一环。

我通常会在任务包里附加这样几类上下文：

• 相关的文件路径和代码片段：不要只说“去改一下那个工具函数”，直接把那个函数的完整源码贴在上下文里，再说明要改成什么行为。
• 接口契约：如果这个Agent要调用的上游接口或要实现的接口是现存代码里定义的，把接口定义原样贴给它。这让它的产出能严丝合缝地对接上你的系统，而不是凭空发明新接口。
• 编码规范摘要：你们的代码风格、命名习惯、禁止事项。你不是给它一本完整的规范手册，而是给它一份精简版：“用函数式风格”、“禁止any类型”、“文件内不需要export default”。这些约束直接写在需求里。
• 失败反馈：如果Agent的第一次产出不合格，不要只说“不对”，要把具体的报错信息、测试失败结果、你观察到的异常行为，全部喂回去。这会让它在下一轮修正时有的放矢，而不是换一种方式再错一遍。

内存不够用怎么办？非常现实的问题。上下文窗口总是有限，你不能把整个项目塞进去。解决办法是分层供给。

• 第一层：任务说明，一个人能看懂的目标+验收标准。
• 第二层：核心契约，接口定义、数据结构、约束清单。
• 第三层：样例片段，给它一到两个“正确写法”的示例，让它照着风格来。
• 第四层：引用资源，告诉它某个常量在哪个文件、某段逻辑可以参考哪个函数路径。它虽然在当前对话里看不到那个文件，但你可以给它指向，也可以在它生成之后再给它喂那段代码做校验。

这套分层逻辑，本质上是你在做“知识蒸馏”——把项目中海量的、杂乱的上下文，蒸馏成一个Agent能够高效处理的最小知识集。你能做好这个蒸馏，前提是你对项目本身足够熟。又回到基本功了，对吧？

3.3 验证与验收：永远把Agent当“外包实习生”，不当“专家”

任务拆好了、上下文喂足了，Agent把代码交上来了。然后呢？很多人的习惯是：看都不看直接合进主干，或者随便跑一下看能编译就合并。这是最危险的。

我的原则是：永远把Agent当“外包实习生”，永远不当“专家”。

你找实习生写代码，让他交上来之后你做什么？你肯定要自己过一遍代码、自己跑一遍测试、自己想想有没有影响到别的模块。对Agent更是如此。Agent的产出，默认是“疑似有问题”的，而不是“默认正确”。这是一种心态转变，它决定了你后续所有行为的严谨度。

我设计了一个三层验收清单，每一层都必须过：

• 第一层：编译与静态检查。代码能不能编译、TypeScript类型检查是否通过、Lint是否通过。这层最基础，也最容易被Agent忽略。它经常给你生成一个“看起来类型安全”但实际上某处存在隐式any的代码。
• 第二层：自动化测试。你自己写的测试用例（不是Agent写的），跑起来。这一步看功能是否正确，边界和异常是否被覆盖。这一点极其重要，要用自己的测试来校验Agent的代码，而不是只信Agent自己写的测试。
• 第三层：人工代码走读。把Agent生成的代码当作一个同事的Pull Request，逐行走读。你不需要只看“能跑”，而是看“这个实现是不是最优解”“有没有违反项目架构”“有没有隐藏的坑”。

我常用的一个走读心法叫“反向评审”：你会不会明确地把这段代码推荐给别人作为项目样板？如果会，说明质量真过关；如果心里有一点犹豫，那说明有问题没解决，打回去改。

三层验收跑完，合格的代码才是真正可合的。这套流程看起来繁琐，但它能把你从“被Agent带节奏”的被动状态，转为“让Agent在我画的框里高效产出”的主动状态。主动权在谁手里，决定了Agent是生产力还是生产事故。

4. 实战案例：用Agent重构一个TypeScript模块

4.1 案例背景与目标

理论讲了太多，不如看一个真实的项目。我最近在做的一个小工具项目里，有一个TypeScript写的API调用模块。这个模块是历史遗留代码，两千多行全写在一个文件里，各种重复代码、魔法字符串、游离的配置项，阅读和维护都很难受。

重构目标定得很清楚：把这个大文件拆分成结构清晰的模块，同时保持所有对外接口行为不变，并且补充基础的单元测试。这个重构任务非常适合演示Agent工作法，因为它既有技术含量、又有明确边界、还能通过测试来验证。

我先自己画了一张简单的现状图：这个模块里大概有十几个导出函数，内部共享了一套fetch调用封装。问题在于，这套封装散落各处，没有一个统一的类型定义，错误处理方式也不一致。有的函数用throw new Error，有的竟然用return { error: true }。

基于这个分析，我设计了三个任务包：

• 任务包一：整理现有核心类型定义，把所有接口请求、响应、错误相关的类型抽成一个独立的types.ts。
• 任务包二：实现一个统一的httpClient.ts封装，集中处理基础请求逻辑、超时、错误归一化。
• 任务包三：将原文件中的十余个业务函数逐一迁移到新结构上，确保行为不变。

每个包单独发给Agent处理。下面这是任务包一的实际过程。

4.2 分步实操过程

任务包一下达时，我写的任务说明大致是这样的（我消去了部分业务细节，保留核心结构）：

背景：我们有一个历史API模块src/api/legacy.ts，现在要开始渐进式重构。你是我的Agent协作者。 本次任务目标：创建src/api/types.ts，把现有文件里与接口请求、响应、错误相关的类型定义全部迁移进去，并按已有调用点补充缺失的类型声明。 约束： 1. 不得修改legacy.ts现有的任何逻辑行为。 2. 迁移后的类型名称不得改变，因为现有调用方已经import了这些类型。 3. 新文件遵循项目的lint规则，不使用any，不做任何业务实现。 4. 输出内容：新文件的完整代码 + 对legacy.ts中需要新增import类型的清单。 验收标准： 1. tsc --noEmit 通过。 2. 现有测试全部通过。

这段话不到两百字，但把背景、任务、边界、产出、验收都讲清楚了。

Agent第一次产出的结果，整体结构没问题，但犯了一个典型错误：它在types.ts里新增了很多原文件根本没有用到的“未来可能用到的类型”，比如一个泛型的ApiResponse<T>，原代码里根本没有对应使用点。

这看起来很专业，但违背了“不改变现状”的约束。它提前抽象了本不属于这次任务的类型，这会诱导后面的任务包跑偏。于是我把验收反馈发回去：

反馈：迁移类型时，必须严格与原文件同名同结构。新增非必要通用类型会导致后续调用方误用。请只迁移现有实际使用到的类型，不要为了“整洁”而超范围重构。 同时，注意legacy.ts里有一个ApiError接口，迁移后需要在该文件顶部注明来源，因为原文件依赖隐式全局类型。

这里体现了一个核心技巧：反馈要具体到“为什么错”，而不是只说“错了”。Agent收到正确的反馈后，第二次产出非常干净，只迁移了实际在用的类型，一个不多一个不少。tsc --noEmit通过，原有测试通过，任务包一验收完成。

任务包二也是类似的过程。唯一特殊的点是，我要求Agent的httpClient.ts统一错误处理逻辑，但它生成的第一版里错误处理的签名和原文件的各调用方不兼容，导致后面又要回去适配。这次问题出在我自己身上——我没有把原文件里所有调用方对错误处理方式的隐式依赖写清楚。教训就是：上下文准备不充分，Agent就只能在看不见的地方“自由发挥”，而自由发挥一定会出问题。

4.3 过程中踩过的坑和修正

三个任务包做完，整体重构完成，测试全绿。但过程中踩过几个很典型的坑，值得单独拿出来写。

第一个坑：Name冲突幻觉。Agent在某个业务函数迁移时，用了一个它自认为“等价”的本地函数名去调用原模块里的内部helper。因为那个helper在原文件里是模块私有函数，迁移到新文件后作用域改变了，Agent没意识到，就把同名函数定义重复了一份。这直接导致同一份逻辑在项目里存在两处，而且这两处行为还可能有细微差异。这种问题靠静态检查抓不到，必须走读发现。我当时是标记了一处“逻辑重复”反查才揪出来的。

第二个坑：类型收缩丢失。原来有一处if (data && typeof data === 'object')的运行时类型守卫，Agent迁移时认为既然是TS代码、类型上已经有data: SomeObject了，就没保留这个运行时判断。但TS的类型是编译期的，这份数据实际上是从JSON.parse得来的，运行时根本不保证结构可靠。这在客户端代码里是个真Bug，因为线上数据可能不遵守类型声明。后来我要求Agent在迁移纯函数时，必须保留一切运行时守卫逻辑，不得“优化”掉。

第三个坑：测试用例的陷阱。Agent给自己生成的测试，断言全都写得太弱，比如只判定“不抛错”，不判定“返回值内容正确”。这种测试跑了等于没跑。我后来把测试用例的编写也纳入了人工审核范围，不允许Agent单独决定断言标准，每个测试断言必须有明确的业务预期值。

这些坑，每一个都和软件基本功强相关：不读整体代码意识不到作用域问题，不写运行时思考体验不到类型收缩风险，不设计测试逻辑就容易被弱断言糊弄。Agent确实把“写代码”这个体力活代劳了，但判断和兜底的责任完全落回我们肩上。

5. 常见问题与排查技巧实录

基于我大量使用Agent项目的经历，整理了一份高频问题速查表。这些问题几乎每个深度使用Agent的团队都会遇到，我把排查思路写出来，供你直接套用。

5.1 Agent生成代码质量不稳定怎么办？

质量不稳定的根因通常不在Agent，而在任务定义。如果你发现自己需要反复纠正同一个问题，建议回头检查一下，是不是任务包里缺了某类关键上下文。

5.2 Agent陷入死循环或幻觉怎么办？

Agent在长任务里最典型的问题是自我强化式幻觉。它先引入了一个错误的假设A，然后基于A推导出B和C，最终产出整个建立在幻觉地基上。

最简单的止损办法：设置中间检查点。不要等Agent跑完整套流程才看结果，要求它在每个任务包里主动输出“我当前打算怎么做、为什么这么做”。收到它的思路之后，你先纠正方向再让它继续写。

如果发现Agent已经陷入幻觉，首先停止追问——继续追问往往会让它在错误方向上给出越来越“圆滑”的错误解释。正确做法是把对话改成新会话，重新提供一个干净清晰的任务描述，并把之前正确的那部分上下游接口重新粘贴进去。每次开新会话，就等于给Agent一次重新启动的机会。

这里要特别注意：Agent不会主动告诉你“我不确定”，它会基于缺失的信息“编造合理解释”。所以我的原则是：对Agent的每一个设计决策都问一句为什么，它说清楚了才算数。

5.3 团队协作中Agent工作法的落地建议

Agent工作法不是一个人的事，把它带到团队里，有几个关键环节必须达成共识。

• 统一任务包模板：团队必须用同一套结构来写任务描述，否则每个Agent的对话风格、信息密度、约束完整度都不同，很难做横向对比。
• 禁止Agent直接合主干：至少在最开始阶段，所有Agent产出必须走人工Review流程。等人均走读能力稳定了，再慢慢放开。
• 沉淀“反幻觉”经验库：团队里每次发现Agent的典型幻觉模式，记录下来，成为后续所有人的避坑指南。这比任何外部Prompt模板都有价值。
• 把验收标准写在开发任务里：不允许只写“把这个接口实现一下”，必须附带“通过什么测试就算完”。“能编译”和“能正确工作”之间隔着十万八千里。

还有一个很容易被忽视的点：让Agent留下的工作产物本身也要“人味十足”。它产生的提交信息、注释、文档，如果只有AI能看懂，你的团队就被绑架了。要在约束里要求所有输出都能让人直接理解。

6. 最后分享一点个人体会

把Agent工作法和软件基本功放在一起聊，其实是在说一件事：AI把“行活儿”变得不值钱，把“判断、设计、验收”这些真正的技术活变得值钱。Matt Pocock那句话的杀伤力就在这，它不是鸡汤，它是一个价值重估的信号。

我自己的体会是，用了Agent之后，我的阅读量反而变大了。以前写代码的时间，现在变成了走读Agent代码、分析它为什么这么写、思考它哪里没写到的时间。这个过程非常像以前给资深同事做Code Review——你被迫站在更高的维度审视代码。而看得越多，基本功越扎实，反过来就更能用好Agent。

如果你现在正准备大规模在项目里引入Agent，我给一条最接地气的建议：不要先从大型重构开始，找一个边界清晰的小模块，按我上面说的任务包方法跑完一遍。把流程走通了，把验收清单做扎实了，再逐步扩大Agent的授权范围。AI这波浪潮确实让工具变得更强了，但能走多远，最终取决于我们手里那把叫做“基本功”的尺子量得准不准。