Agentic Coding时代，基本功为什么比提示词更重要？

最近吴恩达关于 Agentic Coding 的几次公开分享，又把 AI 编程的话题推到了开发者面前。他讲了一个和很多人的直觉相反的判断：当 AI 能写越来越多的代码，程序员的基本功反而更重要。这个观点听起来像是在唱反调，但放到实际的研发流程里，它可能是当下最值得认真对待的提醒。

Agentic Coding 不是一个新造出来的营销词。它描述的是 AI 编程从“逐行补全”走向“自主执行任务”的阶段转变：AI 不再等你敲一个函数名再补全下一行，而是直接接收一个任务描述，自己读仓库、改多文件、跑测试、修错误，甚至自己提交代码。Copilot 时代的 AI 是“副驾驶”，Agentic Coding 时代的 AI 更接近一个“实习生”：它能干很多活，但需要有人明确任务边界、验收结果、发现它自作聪明的地方。

这篇文章会把 Agentic Coding 到底改变了什么拆开讲清楚，然后重点回答一个问题：为什么这个时代基本功反而更重要。文章会覆盖 Agentic Coding 的核心能力、工作流搭建、质量保障手段、接口化批量任务、常见误区和风险边界。如果你正在用 AI 编程工具，或者正准备把 AI 编程接入团队流水线，这篇内容可以直接作为参考起点。

1. Agentic Coding 核心认知速览

这张表不需要记住。你只需要抓住一个核心判断：Agentic Coding 提升的是“写代码”的效率，没有提升“判断代码对不对”的能力。后者依然依赖人。

2. 什么是 Agentic Coding：从自动补全到多智能体协作

2.1 三个阶段的演进

AI 编程大致经历了三个阶段，理解这个演进过程，才能理解为什么基本功问题被重新摆上台面。

第一阶段是语法补全和单行提示。AI 根据当前文件上下文，预测下一段代码。它的工作范围被严格限制在光标附近，即使出错，影响也很局部。

第二阶段是对话式代码生成。开发者把需求用自然语言描述，AI 生成一段完整函数或文件。常见的做法是开发者复制粘贴到编辑器里，再手动调整。这个阶段的问题在于：代码一旦超过一个文件，AI 就容易丢失上下文，生成的代码往往“形似而神不似”。

第三阶段就是 Agentic Coding。AI 不再只读你当前打开的文件。它可以扫描整个仓库，理解模块之间的依赖关系，然后自己决定改哪里、怎么改、改完怎么验证。它还能执行命令、读取测试结果、分析日志、重复修复。这意味着 AI 具备了一部分“工程闭环”能力。

2.2 Agent 和 Copilot 的本质区别

一个很直观的对比是工作流差异。

传统 Copilot 工作流：

开发者写一个函数名 -> AI 补全函数体 -> 开发者审查 -> 手动粘贴 -> 手动运行测试

Agentic Coding 工作流：

开发者描述任务 -> AI 读仓库、制定修改计划 -> 修改多个文件 -> 运行测试 -> 根据失败信息修复 -> 输出结果 -> 开发者验收

差异不在“写代码”这一步，而在“自主性”。Agent 会自己做决策，而做决策意味着它会做错误决策。关键问题来了：谁来发现它的错误决策？只能是具备基本功的人。

2.3 多智能体协作形态

再往后一步，是多个 Agent 分工协作。比如一个 Agent 负责写功能代码，另一个 Agent 负责写测试，还有一个 Agent 负责审查前两者的输出。这种多角色协作的好处是能在一定程度上模拟真实团队的制衡，但坏处也很明显：Agent 之间共享同一个模型能力上限，它们会犯同一种类型的错误。

多智能体不是银弹。它只是把“人的判断”延后，并没有替代“人的判断”。最终验收依然要落到一个懂代码、懂业务、懂边界的人身上。

3. 为什么 Agentic Coding 时代基本功更重要

3.1 AI 生成代码的“高置信度错误”

传统程序员犯错，通常会在测试阶段暴露，因为人对自己写的代码有不确定性，会谨慎验证。Agent 的麻烦在于：它生成的代码非常流畅，表面结构完整，变量命名规范，甚至注释都写好了。这种“高置信度的错误”最容易骗过经验不足的开发者。

一个真实的教训是：AI 生成了一个看起来正确的配置文件解析函数，但在遇到没有等号的行时出现了逻辑错误。代码编译通过、单元测试也通过，因为测试用例没有覆盖这种脏数据。一旦上线，解析器在真实数据上直接抛异常。

如果开发者基本功不够，他无法在审查阶段发现这个边界漏洞。他会以为“AI 写的代码，测试都过了，应该没问题”。问题恰恰出在这里。

3.2 提示词的本质是“任务拆解”

很多人以为 Agentic Coding 时代要学会写提示词，所以拼命研究 Prompt 技巧。这个方向没有错，但不完整。

真正有效的提示词，核心是任务拆解的颗粒度。举个例子：

请帮我优化这个函数的性能。

这是一个不合格的任务描述。Agent 可能会去修改算法，也可能会去加缓存，甚至可能重构整个模块。结果不可控。

请优化 parse_config 函数中读取大文件的性能。当前实现使用 readlines() 一次性读入内存。请改为按行迭代读取，并保留原有错误处理逻辑。修改前先说明你的方案，修改后运行 tests/test_config.py 验证。

这是一条更好的任务描述。为什么你能写出来？因为你知道 Python 文件读取的基本差异，知道 readlines() 和逐行迭代的性能区别，知道测试用例在哪里。这就是基本功。

提示词写得好不好，背后是任务拆解能力；任务拆解能力背后，是数据结构、算法复杂度、系统设计等基础素养。Prompt 只是表面，基本功才是底层。

3.3 代码审查从“可做可不做”变成“必做”

在 Agentic Coding 工作流中，代码审查的地位被提高了。以前开发者写完代码，审查者要检查逻辑是否正确、风格是否统一。现在审查者要面对的是：AI 可能修改了计划之外的文件，可能引入了隐式依赖，可能用了不存在的 API，可能绕过已有的安全策略。

这意味着审查者必须能快速理解代码库的全局结构，识别 AI 的修改边界，判断一个改动是否引入副作用。这些都不是“会用提示词”能解决的。

吴恩达在相关讨论中把 Agent 比作“超级实习生”，一个重要理由是：实习生需要有人给出清晰任务、检查交付物、指出错误、建立反馈闭环。AI Agent 也是一样。如果你不具备“带实习生”的能力，你就无法安全地使用 Agent。

3.4 调试能力是最后的防线

Agentic Coding 最理想的状态是一次生成、一次通过。但实际开发中，AI 经常陷入“改一个 bug 引入另一个 bug”的循环。它会根据测试报错信息去修复代码，但如果它不理解错误根因，只做表面修补，问题就会被反复触发。

这时候需要开发者介入：查看完整调用栈，分析日志上下文，定位是数据问题还是逻辑问题还是环境问题。这份能力，无法通过让 AI 更强大来代替。因为调试的本质是“建立对系统运行过程的因果理解”，而 Agent 往往只看到局部信息。

4. 基本功不只是写代码：可迁移的硬技能清单

4.1 语言与框架基础

不要因为 AI 可以写代码，就放弃学习语法和框架。你需要能读懂 AI 生成的代码，判断它是否用了过时的 API，是否在错误的位置做了类型转换，是否忽略了异常分支。没有语言基础，这些审查工作完全无法展开。

4.2 数据结构与算法

Agent 生成代码时经常面临选择：用列表还是集合、用递归还是迭代、用哈希索引还是全表扫描。它通常会选一个“看起来合理”的方案，但未必适合你的数据规模和访问模式。你要能看出复杂度差异，要能在代码审查中提出“这里换成集合能把查询从 O(n) 降到 O(1)”。

4.3 系统设计与架构意识

多文件修改是 Agent 的强项，但也是风险来源。一个没有系统设计意识的 Agent，可能为了完成局部功能，破坏了模块之间的边界，甚至绕过了原有的分层结构。开发者需要能识别这种“局部正确、全局混乱”的改动。

4.4 调试与排查能力

日志分析、断点调试、二分定位、复现最小案例，这些能力在 Agentic Coding 时代不会贬值，反而会变成核心竞争力。因为 AI 可以快速产出大量代码，但问题越复杂，越需要人来找到根因。

4.5 版本控制与团队协作

Agent 修改代码后，你需要能看懂 diff，能处理冲突，能决定哪些改动合入主干。Git 操作和代码评审流程是基本功的一部分。如果一个开发者连 rebase 和 merge 的区别都说不清楚，他很难安全地把 AI 生成的代码集成进团队项目。

4.6 领域知识与业务理解

AI 不理解你的业务。它不理解这个接口的调用方是谁，不理解为什么这里要延迟三秒再重试，不理解某个字段的历史兼容性要求。只有具备领域知识的开发者，才能把这些隐性约束条件写进任务描述，或者在审查中发现 Agent 破坏了这些约束。

5. 一套可落地的 Agentic Coding 工作流与质量保障

5.1 环境准备

在真正使用 Agentic Coding 之前，建议先准备好基础环境，这样 Agent 才能自主运行命令、测试、查看错误信息。

以 Python 项目为例，建议准备：

• Git 仓库，分支清晰，方便回滚。
• 一套可快速运行的测试用例，pytest或同类工具。
• 代码检查和格式化工具，比如ruff。
• 一个隔离的 Python 环境，避免依赖污染。
• 数据目录和输出目录分开管理，方便 Agent 读写。

# 创建虚拟环境并安装依赖 python -m venv .venv source .venv/bin/activate pip install -r requirements.txt

这套环境不只是给你用，更是给 Agent 用。Agent 能自己跑通命令，它才有机会在提交代码前发现问题。

5.2 任务下发模板

建议给 Agent 的任务描述使用固定结构，降低自由发挥空间：

任务目标：一句话说明要完成什么。 背景约束：涉及哪些文件、哪些不可改动、哪些接口必须兼容。 完成标准：如何验证，运行哪个测试命令。 禁止事项：明确列出不允许修改的范围。 输出要求：先说明方案，再执行修改。

实际提示词示例：

任务目标：修复 config_loader.py 中解析无等号行时的崩溃问题。 背景约束：只允许修改 src/config_loader.py，禁止修改 tests 目录。 完成标准：运行 python -m pytest tests/test_config_loader.py -q 全部通过。 禁止事项：不要改变公开函数的签名，不要引入新的第三方依赖。 输出要求：先简述根因，再修改代码，最后运行测试并汇报结果。

模板的作用是缩小 Agent 的决策空间。决策空间越小，出错概率越低。

5.3 质量门禁实践

Agent 生成的代码，必须经过机器检查和个人审查两道闸门。

机器检查可以覆盖：

# 运行测试 python -m pytest tests/ -q # 代码风格与常用问题检查 ruff check src/ # 检查代码格式 ruff format --check src/

个人审查需要关注：

• 改动范围是否超出任务边界。
• 是否有不符合项目现状的“过度设计”。
• 异常分支和边界条件是否处理。
• 性能是否满足实际场景。
• 是否有安全、合规风险。

机器检查负责“显性错误”，个人审查负责“隐性风险”。两者缺一不可。

5.4 小步验证策略

不要让 Agent 一次性完成大而全的任务。更稳妥的做法是把一个大型重构拆成多个小任务，每完成一个就验证一次。比如先让 Agent 提取函数，再改调用方，最后删除旧代码。每一步都能独立测试和回滚，风险就小得多。

6. Agentic Coding 的接口化与批量任务场景

6.1 为什么需要接口化

当 Agentic Coding 进入团队协作后，你通常不希望每个开发者自己启一个交互式终端，然后用各自的 Prompt 风格操作 Agent。更工程化的方式是：把 Agent 封装成接口服务，让任务通过 HTTP 请求或命令行批量下发。这样日志可以统一收集，权限可以统一控制，结果可以统一审查。

6.2 通用 API 调用示例

下面是一个“代码审查服务”的调用模板。注意，这是通用示例，具体路径和参数以你实际使用的工具为准：

import requests # 示例：调用一个假设存在的代码审查服务接口 # 实际接口路径、字段名、鉴权方式需要按你使用的工具文档调整 url = "http://127.0.0.1:8000/api/review" payload = { "language": "python", "code": "def parse_config(content): ...", "rules": ["security", "performance", "edge_cases", "style"] } resp = requests.post(url, json=payload, timeout=120) if resp.status_code == 200: result = resp.json() print(result["suggestions"]) else: print("审查失败", resp.status_code, resp.text)

6.3 批量任务与队列设计

接入批量任务时，建议设计一个简单的队列结构：

{ "task_queue": [ { "repo_path": "./services/order", "task": "为 order_service.py 补充边界条件测试", "verify_command": "python -m pytest tests/test_order_service.py -q" }, { "repo_path": "./services/user", "task": "优化 user_query.py 中 N+1 查询问题", "verify_command": "python -m pytest tests/test_user_query.py -q" } ] }

批量任务最容易出现的问题是一个任务卡死，导致后面所有任务排队。建议每个任务设置超时，记录详细日志，失败时自动跳过并标记，方便后续人工重试。

6.4 接口服务的权限与安全

接口服务一旦对外开放，必须控制访问范围：

• 绑定内网地址，不要默认暴露到公网。
• 加上鉴权 Token，避免任何人调用。
• 配置最大并发数和超时时间。
• 接口只暴露最小必要路径，不要在接口里开放任意 Shell 命令。

Agent 的能力是“执行”，接口的职责是“限制执行范围”。这是接口化接入中最容易忽略的部分。

7. 风险与合规边界

7.1 代码正确性风险

Agent 生成代码的正确性，无法通过“AI 很强”来保证。它受到训练数据、上下文长度、任务描述质量的影响，必然存在错误率。上线前必须结合代码审查、自动化测试和灰度发布来降低风险。

7.2 版权与许可风险

使用 Agent 生成代码时，需要关注训练数据中可能包含的开源代码许可问题。如果生成结果与某些开源项目代码高度相似，可能带来许可证兼容性风险。商用项目尤其需要谨慎，建议对关键模块做代码相似度检查，并记录生成过程。

7.3 数据隐私风险

不要把敏感的业务数据、用户隐私数据、未公开的源代码片段直接粘贴给外部 AI 服务。建议优先使用企业内部部署的模型或经过合规评估的服务。本地部署时，也要限制 Agent 的文件系统访问权限，避免它读取密钥、环境变量等敏感信息。

7.4 人机协作边界

明确哪些工作可以交给 Agent，哪些工作必须由人完成。一个基本的划分是：

• 可以交给 Agent：生成样板代码、补充测试用例、执行重复性重构、分析报错日志。
• 必须由人完成：架构决策、技术选型、安全评估、对外承诺、最终代码验收。

这不是效率问题，而是责任问题。代码出问题后，责任主体是人和团队，不是 Agent。

8. 常见误区与排查方法

这张表可以打印出来，贴在团队看板上。排错的第一步不是“重来一次”，而是确认是哪一类问题。

9. 总结与下一步

Agentic Coding 正在把 AI 编程从“工具辅助”推向“智能体执行”。它对开发者的真实要求不是学会更多花哨的提示词技巧，而是把基本功练得更扎实：任务拆解、代码审查、调试定位、系统设计、版本控制、领域理解。这些能力决定了你能否驾驭 Agent，而不是被 Agent 的表面流畅误导。

如果只能记住一句话：Agentic Coding 不会淘汰会写代码的人，但会加速淘汰不会验收代码的人。

建议先用一个非核心模块做试验。这周可以做三件事：

• 用你常用的 AI 编程助手，给一个没有测试覆盖的模块补上测试，然后逐行审查每一处改动。
• 挑一个你曾经写过的复杂代码块，让 Agent 尝试重构，并让它解释每一步为什么这样改。
• 把代码仓库接入强制测试和代码检查，让 Agent 生成的代码先过机器检查，再进代码审查。

做完这三件事，你会发现“基本功更重要”不是一个口号，而是一条真实的工作流规则。再往后，可以把这套流程逐步扩展到团队的其他项目，同时记录每一次 Agent 失败的根因。这些记录，会比任何 AI 教程都有用。