2024年以来“AI编程”这个词在开发圈里几乎成了流量密码。各种 Agent 工具层出不穷从自动补全到自动修 Bug再到一键生成整个项目看起来程序员只需要动动嘴代码就能自己写完。但就在这股热潮里吴恩达偏偏提出了一个“反潮流”的判断Agentic Coding 时代基本功更重要。这句话乍一听像是老一辈的谆谆教诲但如果你真的把 Agentic Coding 的工作方式跑通一遍就会明白它根本不是一句正确的废话。恰恰相反它踩中了当前 AI 编程落地时最真实的断层工具能力上去了使用者的工程判断力没跟上。这篇文章想聊透三件事Agentic Coding 到底改变了开发流程的哪个环节为什么工具越强反而越考验基本功以及一个普通开发者怎么在 Agentic 工作流里系统性地补齐这些基本功。文章会有概念拆解、流程对比、提示词模板和工程化建议希望读完之后你不只是多了一个“会用 AI 写代码”的标签而是真正能在项目里把它用好。1. Agentic Coding 和“用 AI 补全代码”根本不是一回事很多人对 AI 编程的认知还停留在 Copilot 时代光标停在某一行AI 给出下一段代码开发者看一眼Tab 键接受。这种模式本质上是“AI 辅助编码”人依然是整个开发流程的驱动者AI 只是你的输入法。Agentic Coding 则完全不同。它的核心单元从“代码补全”变成了“任务执行”。你给 Agent 一个目标比如“修复登录接口的并发问题”Agent 会自己完成一系列动作读取相关代码、定位问题、搜索依赖、修改文件、运行测试、根据报错再迭代。整个过程里开发者不再逐行编写代码而是像一个“技术负责人”一样给 Agent 下达指令、审查结果、纠正方向。这个转变才是革命性的。用一张表可以看得很清楚维度传统 AI 辅助编程Agentic Coding交互单位代码片段任务目标开发者角色代码编写者任务管理者与审查者工作流程人写AI 补全人规划AI 执行人验证核心技术代码生成模型多步推理、工具调用、自我纠错主要风险代码质量问题目标理解偏差、连锁性错误对能力要求语法熟悉度需求拆解、代码审查、系统设计从这个对比里能看出一个关键判断在 Agentic Coding 模式下开发者最核心的工作不再是“写代码”而是“定义任务”和“验证结果”。而这恰恰是很多程序员在职场上最欠缺的能力。这也是为什么吴恩达说“基本功更重要”——不是因为 AI 抢了你的饭碗而是因为 Agent 把执行层的工作承接之后你作为人的价值必须上移到判断层。判断力差的人用 Agent 只会更快地生产出有问题的代码。1.1 一次典型的 Agentic Coding 工作流为了更直观地理解我描述一个典型的 Agent 工作流。假设你的任务是“给项目里的用户服务增加 Redis 缓存缓存用户基本信息TTL 设为 30 分钟”。传统方式下你会自己改接口、加依赖、写缓存工具类、处理序列化问题、然后联调。但在 Agent 模式下流程变成Agent 扫描项目结构理解现有用户服务的代码。它设计缓存方案缓存 Key 怎么定义、缓存什么字段、哪些接口需要改。它自动修改代码添加 Redis 配置。它运行编译和测试发现报错后自己读日志、修 Bug。最终它把改动汇总等开发者审查。听起来很美好对吗但这里有一个容易被忽略的关键点Agent 做的每一步决策都依赖你对任务的描述是否足够精确。如果目标描述里没有说明“缓存 Key 需要包含用户 ID”Agent 可能就会设计出全局共用一个 Key 的缓存方案——代码能跑业务全错。这就是基本功的价值所在只有足够懂系统设计、缓存一致性、序列化细节的人才能把任务拆得足够清楚并且一眼看出 Agent 的方案哪里有问题。2. 吴恩达强调的“基本功”到底指哪些能力“基本功”这个词听起来很虚但把它放到 Agentic Coding 的上下文里其实是几项非常具体的能力。2.1 需求拆解能力这是整个流程的地基。Agent 能完成多复杂的任务取决于你能把它拆到什么粒度。一个模糊的目标“优化这个接口的性能”Agent 根本不知道从哪下手而一个清晰的目标“将用户查询接口的数据库访问改为先查本地缓存缓存未命中再查数据库并设置 10 分钟过期时间”Agent 就能精准执行。需求拆解的本质是把系统设计思维前置。你需要先想清楚约束条件、边界情况、外部依赖然后再把拆好的任务交给 Agent。2.2 代码阅读与审查能力在 Agentic Coding 时代“读代码”比“写代码”更重要。因为你不再需要从零敲每一行代码但必须能快速看懂 Agent 生成的内容。代码审查关注的点包括逻辑是否正确、异常是否处理、资源是否释放、是否引入了不必要的依赖。更关键的是Agent 的代码审查比人工审查更吃经验。AI 生成的代码往往“看起来完全正确、实则藏着逻辑漏洞”尤其是边界情况的处理比如空指针、并发竞态、超时重试导致的数据重复。2.3 调试与验证能力Agent 帮你写了 80% 的代码剩下 20% 的调试才是最要命的。因为你没见过它生成代码的“中间过程”只能从结果反推。这比调试自己写的代码难得多——自己写的代码至少知道当初为什么这么写Agent 的代码只能靠试错。所以会设计验证方案的人在 Agentic 工作流里优势巨大。你会给 Agent 提出明确的验收标准“运行以下 10 个测试用例全部通过才算完成”。这比让 Agent 自己“觉得完成了”可靠得多。2.4 系统化与工程化思维Agent 处理的是局部任务但你的系统是整体。一个简单的改动可能影响鉴权模块、影响缓存一致性、影响数据库事务。只有具备系统化思维才能在给 Agent 下达指令时把可能受影响的模块都纳入考量。3. Agentic Coding 时代开发流程发生了哪些真实变化要理解基本功为什么重要可以先看看 Agent 介入后开发流程本身的变化。3.1 从“写代码”变成“写上下文”传统开发中代码本身就是交流的载体。但 Agent 并不能“看见”你的整个项目它只能根据你提供的上下文来工作。比如直接说“在 utils.py 里加一个时间格式化函数”Agent 并不知道这个项目的时间格式标准是什么是yyyy-MM-dd HH:mm:ss还是yyyy/MM/dd是本地时区还是 UTC。所以Agentic Coding 的首要技能是写上下文。你需要把自己的设计意图、约束条件、相关代码位置、依赖关系、验收标准全部“喂”给 Agent。上下文写得越清楚Agent 的执行越少出错。在实际工程里很多团队开始维护一个AGENTS.md文件专门记录项目的结构、编码规范、常用命令、特殊约束。每次启动 Agent 时先让它读这个文件再开始干活。这类文件的本质就是把团队积累的项目知识沉淀成 Agent 能理解的格式。3.2 从“一次写完”变成“多轮迭代”传统 AI 补全追求“一次生成正确代码”Agent 则天然是多轮迭代的。你给它一个目标它执行、报错、修改、重跑循环往复直到测试通过。这意味着开发者的工作方式也要改不能再期待 Agent 一步到位而是要学会在每一轮迭代中不断收紧输入条件。比如第一轮让 Agent 实现“登录功能”发现它没有做密码加密第二轮就补充“使用 BCrypt 加密密码”第三轮发现它没有处理账号锁定再补充规则。这个“挤牙膏”的过程本质上就是在验证你对系统的理解是否完整。3.3 从“人工验证”变成“自动化验收”以前代码写完了自己跑一遍、点几个页面就行了。但 Agent 写的代码你根本不知道它动了哪些地方光靠人工点一遍根本不够。所以 Agentic Coding 工作流对自动化测试的要求极高。你必须有足够多的单元测试、接口测试、契约测试才能在 Agent 每轮改动后快速自动判断有没有破坏功能。测试覆盖不足的项目用 Agent 就是开盲盒运气好能跑通运气不好上线就炸。这就是工程化基本功的意义——自动化测试体系是 Agentic Coding 的安全网。没有这张网Agent 越是“能干”你心里越没底。4. Agentic Coding 的典型实践从任务描述到验证闭环光讲概念没有说服力下面用一个尽量贴近真实场景的示例演示 Agentic Coding 的完整闭环。我们以一个常见的“给 Python 项目添加日志功能”任务为例。4.1 第 1 步任务描述给 Agent 的描述不能是这样给项目加日志。至少要写成这样目标给 src/order_service.py 中的所有接口添加操作日志。 要求 1. 使用 structlog 库输出 JSON 格式日志。 2. 日志至少包含时间、日志级别、接口名、请求参数、耗时、用户 ID登录后才有。 3. 不修改业务逻辑只在函数入口和出口添加日志。 4. 所有新代码必须通过 python -m pytest tests/ 中的现有测试。 5. 项目依赖文件在 requirements.txt如缺少 structlog请添加并说明原因。 验收标准 - 运行 python -m pytest tests/ -v 全部通过。 - 运行 python src/order_service.py --demo控制台输出包含 JSON 日志。注意这里每一项要求都在限定 Agent 的行为边界用什么库、输出什么字段、不能改什么、怎么验证。有了这些约束Agent 生成的代码才具备可控性。4.2 第 2 步Agent 执行与中途检查Agent 执行的时候它可能会自动读src/order_service.py分析所有函数。尝试在项目里安装structlog。生成多段代码修改。运行测试。作为开发者你不能全程盯着它但必须在几个关键节点介入改动文件列表、新增依赖、测试结果。有些 Agent 工具会生成“执行计划”你可以先检查计划再让它继续。如果 Agent 打算给每个函数都加一行logger.info(start)这种机械日志其实不符合需求因为你要求的是“结构化、含耗时、含用户 ID”的日志应该有统一的包装函数。这时候就可以在下一轮给 Agent 补充规则注意 - 避免在每个函数里手写 logger 调用应该抽取一个 log_with_context 装饰器。 - 耗时统计使用 time.perf_counter。 - 用户 ID 从 request.user如存在获取。这就是前文说的多轮迭代先让 Agent 出初稿你审核后给结构化反馈再让它改。4.3 第 3 步验证与回滚设计Agent 完成改动后会自动运行测试。但测试通过不代表彻底正确你需要额外人工核对以下几点git diff --stat这条命令可以快速看它动了哪些文件评估改动范围是否符合预期。python -m pytest tests/ -v这是自动回归确认没有破坏现有功能。python src/order_service.py --demo这是手动冒烟测试确认实际输出是否符合预期的 JSON 格式。如果有问题最简单的回滚方式是git checkout -- file把特定文件恢复到改动前。因此在启动 Agent 前务必确认当前工作区是干净的先提交一次。5. 基础功的系统化训练三个可落地的操作理论说完了下面给出行之有效的训练方法。不需要你换个新工具只需要在日常工作里刻意改变几个习惯。5.1 用“费曼式任务”训练需求拆解费曼学习法的核心是“用自己的话讲清楚一件事”。应用到 Agentic Coding 上就是要求自己用不超过 5 句话说清楚一个任务。说不清楚说明你还没想透。训练方法是每天挑一个小需求禁止直接写代码先用纯文字把它写成一段任务描述要求包含目标、约束、验收标准。然后对比这段描述与实际代码之间的距离。你会发现自己漏掉了很多隐性约束比如事务边界、幂等性、权限校验。写任务描述本身就是一种设计活动。你写得越精确越说明你对系统的理解接近真实。5.2 用“代码审查清单”训练审查能力每次 Agent 生成代码不要急着“看起来没问题就合并”。准备一份审查清单逐个检查有无新增不必要的依赖异常处理是否有吞异常的情况有无硬编码的 IP、密钥、数据库地址有无绕过事务或权限校验的逻辑是否修改了与任务无关的代码并发场景下是否存在竞态条件你不用每次全都检查但至少要能说出“这次改动的风险点在哪”。长期训练下来你审查 Agent 代码的速度会越来越快判断力也会越来越准。5.3 用“测试先行”训练验证能力Agentic Coding 时代没有测试的代码就是灾难。因为 Agent 自己判断“完成”的标准往往是“测试通过”。如果没有测试它可能只凭“代码不报错”就认为完成这种代码上线后往往瞬间炸裂。所以一个非常重要的基本功是测试设计能力。接到任务后先想清楚这个功能需要哪些测试用例最好自己先写测试再让 Agent 实现功能。这样 Agent 的目标就变成了“让测试通过”而不是“让代码看起来能跑”。6. Agentic Coding 的常见误区与排查思路和任何新技术一样Agentic Coding 也有大量“看起来很美、实际踩坑”的地方。整理成一张表供排查参考。问题现象可能原因排查方式解决方案Agent 频繁修改无关文件项目上下文缺失Agent 无法判断范围查看改动文件列表git diff --stat在任务描述中明确“不得修改与任务无关的文件”用.gitignore和路径约束限制 AgentAgent 陷入循环无法结束验证标准不明确Agent 自行判断成功查看 Agent 每轮输出与测试结果给出明确验收标准例如指定测试命令和预期输出Agent 生成的代码风格与项目不一致未提供编码规范上下文检查新增代码的命名与格式在项目根目录维护AGENTS.md写入代码风格、命名约定、目录结构测试通过但功能错误测试覆盖不足Agent 只跑了已有测试检查测试用例是否覆盖新功能先手写功能测试再让 Agent 实现增加契约测试依赖冲突项目无法启动Agent 自动安装了不兼容依赖查看依赖变更记录约束 Agent“如需新增依赖先说明理由”由开发者决定是否安装上下文太长导致 Agent 漏掉关键信息所有信息一次性堆给 Agent检查上下文中的关键约束是否被后续步骤覆盖采用阶段性任务描述一次只给一个子目标逐步推进敏感信息泄露到代码中密钥、数据库地址被 Agent 写进代码检索代码中的关键词强调密钥必须从环境变量读取启动前用grep扫描新增代码6.1 最常见的失败上下文缺失在实践中Agentic Coding 失败的首要原因通常是上下文不够。因为 Agent 不像老同事一样知道“这个项目为什么要这么设计”“那个模块的历史包袱”。它只能看到你给它的那点资料。所以最有效的排查动作是检查你给 Agent 的上下文是否包含以下内容项目结构说明相关代码文件路径业务规则和约束条件编码规范与依赖清单验收标准和测试方式如果你发现自己写不清楚这些那问题不在 AI而在你对项目的理解。7. Agentic Coding 时代工程化最佳实践建议工具用好靠流程流程跑通靠规范。最后给出一套适合团队落地 Agentic Coding 的最佳实践清单。7.1 建立项目级别的 Agent 上下文文件参考AGENTS.md模式在项目根目录维护一份文件内容应包含# 项目概述 一句话说明项目是做什么的。 # 技术栈 Python 3.11、FastAPI、PostgreSQL、Redis。 # 常见命令 - 启动开发服务uvicorn app.main:app --reload - 运行全部测试python -m pytest tests/ -v - 代码格式ruff check . # 项目结构 - src/业务代码 - tests/测试代码 - scripts/运维脚本 # 编码规范 - 使用类型注解。 - 所有函数必须写 docstring。 - 禁止在代码中硬编码密钥。 - 数据库操作必须使用 SQLAlchemy 的 session 管理。 # 约束 - 本项目兼容 Python 3.11 及以上版本。 - 如无必要不新增第三方依赖。启动 Agent 时第一句话就是请先阅读项目根目录下的 AGENTS.md然后按其中的规范完成以下任务...这样 Agent 的知识体系就与你站在同一起点生成代码的有效性会大幅提升。7.2 小步提交频繁验证不要把一个大需求丢给 Agent 跑一整天。建议把它拆成多个小任务每个任务做完立即运行测试、代码审查通过后提交一次。这样一旦出错回滚范围非常小。推荐的提交粒度是“一次任务一个 commit”commit message 用feat(module): description格式方便将来追溯这个改动是 Agent 完成的还是人工完成的。7.3 强制安全边界使用 Agent 时必须给它设置安全边界。例如警告 - 禁止使用 sudo 或管理员权限执行命令。 - 禁止访问 /etc、.env 等敏感文件。 - 禁止执行删除数据库、清空生产环境的操作。 - 如某个操作涉及危险命令先停下来询问开发者。这种限制看似多余但能防止 Agent 在“试图解决问题”的过程中做出不可逆操作。特别是当你给 Agent 的权限很大比如允许它执行 shell 命令时风险会成倍增加。建议在测试环境或本地环境跑通流程再考虑放宽权限。7.4 从“代码交付”转向“标准交付”在 Agentic Coding 模式成熟后你的核心产出不再是代码而是一套能让 Agent 安全、稳定执行的标准。例如需求模板什么样的任务描述能让 Agent 高效执行审查清单什么样的代码必须人工复核验收标准什么样的测试能证明功能完成失败预案Agent 跑偏时如何快速回滚当你把这套标准沉淀成团队文档Agentic Coding 就真正成了团队的工程能力而不是靠个人“AI 炫技”碰运气。8. 总结与下一步实践方向回到开头的问题为什么 Agentic Coding 时代基本功更重要因为 Agent 接管的是执行层而人的价值必须上移到决策层。需求拆解不清晰Agent 就会跑偏测试覆盖不充分Agent 的“成功”就没有凭据代码审查不到位AI 生成的隐藏 Bug 就会流入生产环境。工具越强大使用者的判断力就越关键这不是矛盾而是分工演化的必然结果。建议你从今天开始做三件事选一个自己熟悉的小项目用 Agent 完成一个中等复杂度的任务记录你的任务描述和 Agent 的执行过程看看迭代中暴露了哪些认知空白。写一份属于你团队的AGENTS.md把项目结构、编码规范、常用命令沉淀进去。下一次使用 Agent 时刻意练习“先写验收标准再让 Agent 动手”让测试驱动你的 AI 工作流。基本功这种东西从来不会在风口期显得重要但每到技术变革的关口决定你能不能接住新工具的恰恰就是这些平时看不上、关键时刻救命的东西。 Agentic Coding时代，为什么基本功比AI编程工具更重要？
2024年以来“AI编程”这个词在开发圈里几乎成了流量密码。各种 Agent 工具层出不穷从自动补全到自动修 Bug再到一键生成整个项目看起来程序员只需要动动嘴代码就能自己写完。但就在这股热潮里吴恩达偏偏提出了一个“反潮流”的判断Agentic Coding 时代基本功更重要。这句话乍一听像是老一辈的谆谆教诲但如果你真的把 Agentic Coding 的工作方式跑通一遍就会明白它根本不是一句正确的废话。恰恰相反它踩中了当前 AI 编程落地时最真实的断层工具能力上去了使用者的工程判断力没跟上。这篇文章想聊透三件事Agentic Coding 到底改变了开发流程的哪个环节为什么工具越强反而越考验基本功以及一个普通开发者怎么在 Agentic 工作流里系统性地补齐这些基本功。文章会有概念拆解、流程对比、提示词模板和工程化建议希望读完之后你不只是多了一个“会用 AI 写代码”的标签而是真正能在项目里把它用好。1. Agentic Coding 和“用 AI 补全代码”根本不是一回事很多人对 AI 编程的认知还停留在 Copilot 时代光标停在某一行AI 给出下一段代码开发者看一眼Tab 键接受。这种模式本质上是“AI 辅助编码”人依然是整个开发流程的驱动者AI 只是你的输入法。Agentic Coding 则完全不同。它的核心单元从“代码补全”变成了“任务执行”。你给 Agent 一个目标比如“修复登录接口的并发问题”Agent 会自己完成一系列动作读取相关代码、定位问题、搜索依赖、修改文件、运行测试、根据报错再迭代。整个过程里开发者不再逐行编写代码而是像一个“技术负责人”一样给 Agent 下达指令、审查结果、纠正方向。这个转变才是革命性的。用一张表可以看得很清楚维度传统 AI 辅助编程Agentic Coding交互单位代码片段任务目标开发者角色代码编写者任务管理者与审查者工作流程人写AI 补全人规划AI 执行人验证核心技术代码生成模型多步推理、工具调用、自我纠错主要风险代码质量问题目标理解偏差、连锁性错误对能力要求语法熟悉度需求拆解、代码审查、系统设计从这个对比里能看出一个关键判断在 Agentic Coding 模式下开发者最核心的工作不再是“写代码”而是“定义任务”和“验证结果”。而这恰恰是很多程序员在职场上最欠缺的能力。这也是为什么吴恩达说“基本功更重要”——不是因为 AI 抢了你的饭碗而是因为 Agent 把执行层的工作承接之后你作为人的价值必须上移到判断层。判断力差的人用 Agent 只会更快地生产出有问题的代码。1.1 一次典型的 Agentic Coding 工作流为了更直观地理解我描述一个典型的 Agent 工作流。假设你的任务是“给项目里的用户服务增加 Redis 缓存缓存用户基本信息TTL 设为 30 分钟”。传统方式下你会自己改接口、加依赖、写缓存工具类、处理序列化问题、然后联调。但在 Agent 模式下流程变成Agent 扫描项目结构理解现有用户服务的代码。它设计缓存方案缓存 Key 怎么定义、缓存什么字段、哪些接口需要改。它自动修改代码添加 Redis 配置。它运行编译和测试发现报错后自己读日志、修 Bug。最终它把改动汇总等开发者审查。听起来很美好对吗但这里有一个容易被忽略的关键点Agent 做的每一步决策都依赖你对任务的描述是否足够精确。如果目标描述里没有说明“缓存 Key 需要包含用户 ID”Agent 可能就会设计出全局共用一个 Key 的缓存方案——代码能跑业务全错。这就是基本功的价值所在只有足够懂系统设计、缓存一致性、序列化细节的人才能把任务拆得足够清楚并且一眼看出 Agent 的方案哪里有问题。2. 吴恩达强调的“基本功”到底指哪些能力“基本功”这个词听起来很虚但把它放到 Agentic Coding 的上下文里其实是几项非常具体的能力。2.1 需求拆解能力这是整个流程的地基。Agent 能完成多复杂的任务取决于你能把它拆到什么粒度。一个模糊的目标“优化这个接口的性能”Agent 根本不知道从哪下手而一个清晰的目标“将用户查询接口的数据库访问改为先查本地缓存缓存未命中再查数据库并设置 10 分钟过期时间”Agent 就能精准执行。需求拆解的本质是把系统设计思维前置。你需要先想清楚约束条件、边界情况、外部依赖然后再把拆好的任务交给 Agent。2.2 代码阅读与审查能力在 Agentic Coding 时代“读代码”比“写代码”更重要。因为你不再需要从零敲每一行代码但必须能快速看懂 Agent 生成的内容。代码审查关注的点包括逻辑是否正确、异常是否处理、资源是否释放、是否引入了不必要的依赖。更关键的是Agent 的代码审查比人工审查更吃经验。AI 生成的代码往往“看起来完全正确、实则藏着逻辑漏洞”尤其是边界情况的处理比如空指针、并发竞态、超时重试导致的数据重复。2.3 调试与验证能力Agent 帮你写了 80% 的代码剩下 20% 的调试才是最要命的。因为你没见过它生成代码的“中间过程”只能从结果反推。这比调试自己写的代码难得多——自己写的代码至少知道当初为什么这么写Agent 的代码只能靠试错。所以会设计验证方案的人在 Agentic 工作流里优势巨大。你会给 Agent 提出明确的验收标准“运行以下 10 个测试用例全部通过才算完成”。这比让 Agent 自己“觉得完成了”可靠得多。2.4 系统化与工程化思维Agent 处理的是局部任务但你的系统是整体。一个简单的改动可能影响鉴权模块、影响缓存一致性、影响数据库事务。只有具备系统化思维才能在给 Agent 下达指令时把可能受影响的模块都纳入考量。3. Agentic Coding 时代开发流程发生了哪些真实变化要理解基本功为什么重要可以先看看 Agent 介入后开发流程本身的变化。3.1 从“写代码”变成“写上下文”传统开发中代码本身就是交流的载体。但 Agent 并不能“看见”你的整个项目它只能根据你提供的上下文来工作。比如直接说“在 utils.py 里加一个时间格式化函数”Agent 并不知道这个项目的时间格式标准是什么是yyyy-MM-dd HH:mm:ss还是yyyy/MM/dd是本地时区还是 UTC。所以Agentic Coding 的首要技能是写上下文。你需要把自己的设计意图、约束条件、相关代码位置、依赖关系、验收标准全部“喂”给 Agent。上下文写得越清楚Agent 的执行越少出错。在实际工程里很多团队开始维护一个AGENTS.md文件专门记录项目的结构、编码规范、常用命令、特殊约束。每次启动 Agent 时先让它读这个文件再开始干活。这类文件的本质就是把团队积累的项目知识沉淀成 Agent 能理解的格式。3.2 从“一次写完”变成“多轮迭代”传统 AI 补全追求“一次生成正确代码”Agent 则天然是多轮迭代的。你给它一个目标它执行、报错、修改、重跑循环往复直到测试通过。这意味着开发者的工作方式也要改不能再期待 Agent 一步到位而是要学会在每一轮迭代中不断收紧输入条件。比如第一轮让 Agent 实现“登录功能”发现它没有做密码加密第二轮就补充“使用 BCrypt 加密密码”第三轮发现它没有处理账号锁定再补充规则。这个“挤牙膏”的过程本质上就是在验证你对系统的理解是否完整。3.3 从“人工验证”变成“自动化验收”以前代码写完了自己跑一遍、点几个页面就行了。但 Agent 写的代码你根本不知道它动了哪些地方光靠人工点一遍根本不够。所以 Agentic Coding 工作流对自动化测试的要求极高。你必须有足够多的单元测试、接口测试、契约测试才能在 Agent 每轮改动后快速自动判断有没有破坏功能。测试覆盖不足的项目用 Agent 就是开盲盒运气好能跑通运气不好上线就炸。这就是工程化基本功的意义——自动化测试体系是 Agentic Coding 的安全网。没有这张网Agent 越是“能干”你心里越没底。4. Agentic Coding 的典型实践从任务描述到验证闭环光讲概念没有说服力下面用一个尽量贴近真实场景的示例演示 Agentic Coding 的完整闭环。我们以一个常见的“给 Python 项目添加日志功能”任务为例。4.1 第 1 步任务描述给 Agent 的描述不能是这样给项目加日志。至少要写成这样目标给 src/order_service.py 中的所有接口添加操作日志。 要求 1. 使用 structlog 库输出 JSON 格式日志。 2. 日志至少包含时间、日志级别、接口名、请求参数、耗时、用户 ID登录后才有。 3. 不修改业务逻辑只在函数入口和出口添加日志。 4. 所有新代码必须通过 python -m pytest tests/ 中的现有测试。 5. 项目依赖文件在 requirements.txt如缺少 structlog请添加并说明原因。 验收标准 - 运行 python -m pytest tests/ -v 全部通过。 - 运行 python src/order_service.py --demo控制台输出包含 JSON 日志。注意这里每一项要求都在限定 Agent 的行为边界用什么库、输出什么字段、不能改什么、怎么验证。有了这些约束Agent 生成的代码才具备可控性。4.2 第 2 步Agent 执行与中途检查Agent 执行的时候它可能会自动读src/order_service.py分析所有函数。尝试在项目里安装structlog。生成多段代码修改。运行测试。作为开发者你不能全程盯着它但必须在几个关键节点介入改动文件列表、新增依赖、测试结果。有些 Agent 工具会生成“执行计划”你可以先检查计划再让它继续。如果 Agent 打算给每个函数都加一行logger.info(start)这种机械日志其实不符合需求因为你要求的是“结构化、含耗时、含用户 ID”的日志应该有统一的包装函数。这时候就可以在下一轮给 Agent 补充规则注意 - 避免在每个函数里手写 logger 调用应该抽取一个 log_with_context 装饰器。 - 耗时统计使用 time.perf_counter。 - 用户 ID 从 request.user如存在获取。这就是前文说的多轮迭代先让 Agent 出初稿你审核后给结构化反馈再让它改。4.3 第 3 步验证与回滚设计Agent 完成改动后会自动运行测试。但测试通过不代表彻底正确你需要额外人工核对以下几点git diff --stat这条命令可以快速看它动了哪些文件评估改动范围是否符合预期。python -m pytest tests/ -v这是自动回归确认没有破坏现有功能。python src/order_service.py --demo这是手动冒烟测试确认实际输出是否符合预期的 JSON 格式。如果有问题最简单的回滚方式是git checkout -- file把特定文件恢复到改动前。因此在启动 Agent 前务必确认当前工作区是干净的先提交一次。5. 基础功的系统化训练三个可落地的操作理论说完了下面给出行之有效的训练方法。不需要你换个新工具只需要在日常工作里刻意改变几个习惯。5.1 用“费曼式任务”训练需求拆解费曼学习法的核心是“用自己的话讲清楚一件事”。应用到 Agentic Coding 上就是要求自己用不超过 5 句话说清楚一个任务。说不清楚说明你还没想透。训练方法是每天挑一个小需求禁止直接写代码先用纯文字把它写成一段任务描述要求包含目标、约束、验收标准。然后对比这段描述与实际代码之间的距离。你会发现自己漏掉了很多隐性约束比如事务边界、幂等性、权限校验。写任务描述本身就是一种设计活动。你写得越精确越说明你对系统的理解接近真实。5.2 用“代码审查清单”训练审查能力每次 Agent 生成代码不要急着“看起来没问题就合并”。准备一份审查清单逐个检查有无新增不必要的依赖异常处理是否有吞异常的情况有无硬编码的 IP、密钥、数据库地址有无绕过事务或权限校验的逻辑是否修改了与任务无关的代码并发场景下是否存在竞态条件你不用每次全都检查但至少要能说出“这次改动的风险点在哪”。长期训练下来你审查 Agent 代码的速度会越来越快判断力也会越来越准。5.3 用“测试先行”训练验证能力Agentic Coding 时代没有测试的代码就是灾难。因为 Agent 自己判断“完成”的标准往往是“测试通过”。如果没有测试它可能只凭“代码不报错”就认为完成这种代码上线后往往瞬间炸裂。所以一个非常重要的基本功是测试设计能力。接到任务后先想清楚这个功能需要哪些测试用例最好自己先写测试再让 Agent 实现功能。这样 Agent 的目标就变成了“让测试通过”而不是“让代码看起来能跑”。6. Agentic Coding 的常见误区与排查思路和任何新技术一样Agentic Coding 也有大量“看起来很美、实际踩坑”的地方。整理成一张表供排查参考。问题现象可能原因排查方式解决方案Agent 频繁修改无关文件项目上下文缺失Agent 无法判断范围查看改动文件列表git diff --stat在任务描述中明确“不得修改与任务无关的文件”用.gitignore和路径约束限制 AgentAgent 陷入循环无法结束验证标准不明确Agent 自行判断成功查看 Agent 每轮输出与测试结果给出明确验收标准例如指定测试命令和预期输出Agent 生成的代码风格与项目不一致未提供编码规范上下文检查新增代码的命名与格式在项目根目录维护AGENTS.md写入代码风格、命名约定、目录结构测试通过但功能错误测试覆盖不足Agent 只跑了已有测试检查测试用例是否覆盖新功能先手写功能测试再让 Agent 实现增加契约测试依赖冲突项目无法启动Agent 自动安装了不兼容依赖查看依赖变更记录约束 Agent“如需新增依赖先说明理由”由开发者决定是否安装上下文太长导致 Agent 漏掉关键信息所有信息一次性堆给 Agent检查上下文中的关键约束是否被后续步骤覆盖采用阶段性任务描述一次只给一个子目标逐步推进敏感信息泄露到代码中密钥、数据库地址被 Agent 写进代码检索代码中的关键词强调密钥必须从环境变量读取启动前用grep扫描新增代码6.1 最常见的失败上下文缺失在实践中Agentic Coding 失败的首要原因通常是上下文不够。因为 Agent 不像老同事一样知道“这个项目为什么要这么设计”“那个模块的历史包袱”。它只能看到你给它的那点资料。所以最有效的排查动作是检查你给 Agent 的上下文是否包含以下内容项目结构说明相关代码文件路径业务规则和约束条件编码规范与依赖清单验收标准和测试方式如果你发现自己写不清楚这些那问题不在 AI而在你对项目的理解。7. Agentic Coding 时代工程化最佳实践建议工具用好靠流程流程跑通靠规范。最后给出一套适合团队落地 Agentic Coding 的最佳实践清单。7.1 建立项目级别的 Agent 上下文文件参考AGENTS.md模式在项目根目录维护一份文件内容应包含# 项目概述 一句话说明项目是做什么的。 # 技术栈 Python 3.11、FastAPI、PostgreSQL、Redis。 # 常见命令 - 启动开发服务uvicorn app.main:app --reload - 运行全部测试python -m pytest tests/ -v - 代码格式ruff check . # 项目结构 - src/业务代码 - tests/测试代码 - scripts/运维脚本 # 编码规范 - 使用类型注解。 - 所有函数必须写 docstring。 - 禁止在代码中硬编码密钥。 - 数据库操作必须使用 SQLAlchemy 的 session 管理。 # 约束 - 本项目兼容 Python 3.11 及以上版本。 - 如无必要不新增第三方依赖。启动 Agent 时第一句话就是请先阅读项目根目录下的 AGENTS.md然后按其中的规范完成以下任务...这样 Agent 的知识体系就与你站在同一起点生成代码的有效性会大幅提升。7.2 小步提交频繁验证不要把一个大需求丢给 Agent 跑一整天。建议把它拆成多个小任务每个任务做完立即运行测试、代码审查通过后提交一次。这样一旦出错回滚范围非常小。推荐的提交粒度是“一次任务一个 commit”commit message 用feat(module): description格式方便将来追溯这个改动是 Agent 完成的还是人工完成的。7.3 强制安全边界使用 Agent 时必须给它设置安全边界。例如警告 - 禁止使用 sudo 或管理员权限执行命令。 - 禁止访问 /etc、.env 等敏感文件。 - 禁止执行删除数据库、清空生产环境的操作。 - 如某个操作涉及危险命令先停下来询问开发者。这种限制看似多余但能防止 Agent 在“试图解决问题”的过程中做出不可逆操作。特别是当你给 Agent 的权限很大比如允许它执行 shell 命令时风险会成倍增加。建议在测试环境或本地环境跑通流程再考虑放宽权限。7.4 从“代码交付”转向“标准交付”在 Agentic Coding 模式成熟后你的核心产出不再是代码而是一套能让 Agent 安全、稳定执行的标准。例如需求模板什么样的任务描述能让 Agent 高效执行审查清单什么样的代码必须人工复核验收标准什么样的测试能证明功能完成失败预案Agent 跑偏时如何快速回滚当你把这套标准沉淀成团队文档Agentic Coding 就真正成了团队的工程能力而不是靠个人“AI 炫技”碰运气。8. 总结与下一步实践方向回到开头的问题为什么 Agentic Coding 时代基本功更重要因为 Agent 接管的是执行层而人的价值必须上移到决策层。需求拆解不清晰Agent 就会跑偏测试覆盖不充分Agent 的“成功”就没有凭据代码审查不到位AI 生成的隐藏 Bug 就会流入生产环境。工具越强大使用者的判断力就越关键这不是矛盾而是分工演化的必然结果。建议你从今天开始做三件事选一个自己熟悉的小项目用 Agent 完成一个中等复杂度的任务记录你的任务描述和 Agent 的执行过程看看迭代中暴露了哪些认知空白。写一份属于你团队的AGENTS.md把项目结构、编码规范、常用命令沉淀进去。下一次使用 Agent 时刻意练习“先写验收标准再让 Agent 动手”让测试驱动你的 AI 工作流。基本功这种东西从来不会在风口期显得重要但每到技术变革的关口决定你能不能接住新工具的恰恰就是这些平时看不上、关键时刻救命的东西。