企业官网建设流程全解析

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 下达指令、审查结果、纠正方向。

这个转变才是革命性的。用一张表可以看得很清楚：

从这个对比里能看出一个关键判断：在 Agentic Coding 模式下，开发者最核心的工作不再是“写代码”，而是“定义任务”和“验证结果”。而这恰恰是很多程序员在职场上最欠缺的能力。

这也是为什么吴恩达说“基本功更重要”——不是因为 AI 抢了你的饭碗，而是因为 Agent 把执行层的工作承接之后，你作为人的价值必须上移到判断层。判断力差的人，用 Agent 只会更快地生产出有问题的代码。

1.1 一次典型的 Agentic Coding 工作流

为了更直观地理解，我描述一个典型的 Agent 工作流。假设你的任务是：“给项目里的用户服务增加 Redis 缓存，缓存用户基本信息，TTL 设为 30 分钟”。

传统方式下，你会自己改接口、加依赖、写缓存工具类、处理序列化问题、然后联调。但在 Agent 模式下，流程变成：

1. Agent 扫描项目结构，理解现有用户服务的代码。
2. 它设计缓存方案：缓存 Key 怎么定义、缓存什么字段、哪些接口需要改。
3. 它自动修改代码，添加 Redis 配置。
4. 它运行编译和测试，发现报错后自己读日志、修 Bug。
5. 最终它把改动汇总，等开发者审查。

听起来很美好，对吗？但这里有一个容易被忽略的关键点：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 也有大量“看起来很美、实际踩坑”的地方。整理成一张表供排查参考。

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 就会流入生产环境。工具越强大，使用者的判断力就越关键，这不是矛盾，而是分工演化的必然结果。

建议你从今天开始做三件事：

1. 选一个自己熟悉的小项目，用 Agent 完成一个中等复杂度的任务，记录你的任务描述和 Agent 的执行过程，看看迭代中暴露了哪些认知空白。
2. 写一份属于你团队的AGENTS.md，把项目结构、编码规范、常用命令沉淀进去。
3. 下一次使用 Agent 时，刻意练习“先写验收标准，再让 Agent 动手”，让测试驱动你的 AI 工作流。

基本功这种东西，从来不会在风口期显得重要，但每到技术变革的关口，决定你能不能接住新工具的，恰恰就是这些平时看不上、关键时刻救命的东西。