目录

AI Coding 实战指南:基础功比工具更重要

AI Coding 实战指南:基础功比工具更重要

📺 视频来源


前言

Matt Pocock 最近发布了两个视频,提出了一个反直觉但重要的观点:

「AI 编程工具被过度炒作,同时又被严重低估。问题在于:工具从来不是瓶颈,流程才是。」

这两个视频在 YouTube 上获得了极高播放量,说明整个行业都在想同一件事:有了 AI 编程工具,软件基础功还重要吗?

答案:比以往更重要——AI 放大你已有的流程,好流程放大出好结果,坏流程放大出更坏的结果。


一、两个视频的观点

视频一:为什么基础功比工具更重要

Matt Pocock 在第一个视频中指出:

「AI 编程工具用得好,能产生惊人的效果。用得不好,它们会比任何人类团队更快地把你的代码库埋葬在意大利面条代码里。」

要点:

  • AI 工具放大你已有的流程——好流程放大出好结果,坏流程放大出更坏的结果
  • 没有基础功,AI 只会让你更快地走向混乱

视频二:完整 AI Coding 工作流

第二个视频是一个实战工作坊,展示了:

「从模糊的需求到 Agent 可执行的计划,再到运行自主 Coding Agent 交付生产功能——完整的 AI 辅助开发周期。」

这不再是玩具级别的演示,而是一个跑得通的工程实践。


二、AI Coding 的现状:过度炒作与被低估并存

过度炒作的部分

市面上充斥着「AI 将取代程序员」的言论。实际呢:

场景AI 能做到AI 做不到
简单 CRUD 代码✅ 快速生成❌ 设计架构
代码补全✅ 多行建议❌ 理解业务逻辑
Bug 修复✅ 常见模式❌ 复杂调试
单元测试✅ 基础覆盖❌ 高质量边界测试

被严重低估的部分

与此同时,真正掌握 AI Coding 的开发者发现:10 倍效率提升不是神话,前提是流程正确;AI 让你专注于决策而不是打字;基础功最扎实的人用 AI 也最强。


三、为什么软件基础功从未过时

基础功决定你向 AI 提什么要求

当你向 AI 描述需求时,你的表述质量直接决定输出质量:

没有基础功的开发者

「帮我写个用户模块」→ AI 生成一套混乱的 CRUD

有基础功的开发者

「帮我实现一个用户注册流程,包含邮箱验证、密码强度校验(8 位以上,大小写+数字),使用 Strategy 模式支持多种验证方式,Repository 模式隔离数据访问」→ AI 生成一套清晰的领域驱动设计

差异来自人类工程师的概念能力和抽象思维,AI 只负责执行。

基础功让你发现 AI 生成的错误

AI 生成的代码看起来正确,但可能藏着并发问题、不符合团队规范、存在安全漏洞、架构选择不适合当前规模。只有懂基础功的人才能发现。

基础功是调试 AI 代码的前提

当 AI 生成了一段你完全不理解代码时,你根本无法判断它是否正确、调试它的问题、优化它的性能、重构它的结构。

「你无法维护你无法理解的代码」——AI 时代这句话只会更成立。


四、Matt Pocock 的 AI Coding 工作流

根据第二个视频的实战演示,这是一套从需求到交付的完整流程:

第一阶段:需求分析 → Agent 可执行的计划

输入:模糊的业务需求 输出:清晰的实现计划

原始需求:「用户反馈系统」
    ↓ 分析
分解任务:
  1. 设计反馈实体(类型、优先级、状态)
  2. 设计数据模型(SQL/NoSQL?)
  3. API 设计(REST/GraphQL?)
  4. 前端表单设计
  5. 通知机制
    ↓ 验证
Agent-ready Plan:每一步都有明确的输入输出和验收标准

第二阶段:Agent 执行 → 代码生成

AI Agent 不会一次性生成整个系统,它的做法是:

  1. 单文件生成:一次只关注一个文件
  2. 即时反馈:每步生成后等待人类确认
  3. 迭代优化:根据反馈调整代码

第三阶段:人工 review → 生产就绪

关键的人工介入点:

  • 架构决策点:技术选型、数据结构设计
  • 边界情况:错误处理、并发控制
  • 安全审计:权限校验、数据保护
  • 代码审查:规范遵循、可读性

五、实战:从零构建 AI Coding 流程

第一步:建立基础认知

在用 AI 编程之前,确保你理解:

  • SOLID 原则:单一职责、开闭原则、里氏替换、接口隔离、依赖倒置
  • 设计模式:策略模式、工厂模式、观察者模式等常见模式
  • 架构风格:分层架构、Clean Architecture、六边形架构
  • 测试金字塔:单元测试、集成测试、端到端测试

第二步:定义你的 AI Coding 协议

Matt 建议每个团队建立自己的 AI 使用协议:

## 我们的 AI Coding 协议

### 允许 AI 做的
- 生成样板代码(Boilerplate)
- 重构指定的代码段
- 生成单元测试
- 解释复杂的代码逻辑
- 翻译语言或框架

### 不允许 AI 做的
- 架构决策
- 安全相关的代码
- 数据库迁移脚本
- 未审查直接提交到 main

第三步:构建你的 Agent 工作流

一个实用的 AI Coding 工作流示例:

# 1. 任务分解
$ ai-breakdown "实现用户权限系统"
任务分解:
  → 用户实体设计
  → 角色-权限映射
  → 中间件实现
  → API 端点
  → 前端集成

# 2. 逐个执行
$ ai-implement "用户实体设计" --spec=specs/user-entity.md

# 3. 代码审查
$ ai-review --file=user/entity.go --rules=security,performance

# 4. 测试生成
$ ai-test --coverage=80% --file=user/entity.go

# 5. 人工确认后提交
$ human-approve && git commit

六、AI Coding 的常见陷阱

陷阱一:盲目信任 AI 的第一次输出

AI 生成的代码往往看起来正确,但可能有边界情况未处理、性能问题、安全漏洞、不符合团队规范。始终 review AI 生成的代码,不要直接提交。

陷阱二:用 AI 生成你不理解的代码

「如果不能用自然语言解释这段代码在做什么,你就不应该让它进入你的代码库。」

解法:每段 AI 代码理解了再提交。

陷阱三:让 AI 替你做决策

架构、技术选型、设计模式——这些是人类的职责。AI 只执行,不决策。

陷阱四:过度依赖 AI

当 AI 不可用时,你会什么?把 AI 当加速器,不是依赖项。自己的编程能力不能丢。


七、团队如何落地 AI Coding

建立 AI 使用规范

角色AI 使用范围审批流程
Junior Dev样板代码、测试生成、代码解释需要 Senior review
Senior Dev重构、架构建议、复杂逻辑需要架构师 review
Tech Lead架构决策辅助、设计评审团队讨论

度量 AI Coding 效果

正向指标

  • 代码提交频率提升了多少?
  • Bug 率降低了多少?
  • 代码审查周期缩短了多少?

负向指标

  • AI 生成的代码占比多少?(警惕过度依赖)
  • 返工率增加了多少?
  • 技术债务增长了多少?

持续学习

AI 工具在快速迭代,今天的做法可能在 6 个月后过时:每月评估新的 AI 编程工具,分享团队内部的 AI Coding 经验,建立 AI 使用案例库。


八、资源推荐

视频

基础功强化

AI Coding 工具

  • Cursor / Copilot:IDE 集成
  • Claude / GPT-4:代码生成和 review
  • Continue.dev:开源 AI coding 插件

结语

Matt Pocock 的两个视频说了一件事:

「AI 编程工具不会取代你,但会用 AI 的同行正在取代你。」

基础功是地基,没有它 AI 只是加速你失败的工具。流程决定结果——把 AI 用在哪、怎么用、谁来审查,写清楚比选什么工具更重要。架构决策、安全边界、代码审查,这些始终需要人。