我们听到一种说法AI 正在替代工程师甚至“AI 做了 200 名工程师的工作”。这句话来自 Grindr CEO 的公开表态在科技圈迅速被放大成“编程岗位要消失了”的焦虑信号。但如果你真的在一线写代码、带团队、维护系统大概率会有一个更冷静的感受AI 确实在改变开发流程但它改变的不是“换人就完事”而是“工程师应该把时间花在哪”。这篇文章不打算继续渲染恐慌也不打算唱衰 AI。我想认真拆解几件事AI 编程到底在哪些环节真正提效了它背后依赖什么样的技术机制如果现在要引入 AI Agent 或 AI 编程工具到实际项目应该怎么落地、怎么验证、怎么避开坑最后我会给出适合团队实践的最小流程和工程建议。无论你是开发者、技术负责人还是正在学习编程的人这篇文章都能帮你建立一个更清醒的判断框架。1. 如何看待“AI 替代 200 名工程师”这句话先给一个明确的判断这句话更像是一个效率叙事的“锚点”而不是工程管理的现实清单。它的传播价值远大于技术价值。我们可以从三个层面去理解它。第一从技术层面看LLM 尤其是大参数代码模型确实可以自动完成部分重复性编码工作比如模板代码、CRUD 接口、单元测试、配置文件、简单的算法实现。这些工作如果集中在一个庞大的工程团队里可能确实需要大量初级工程师来维护。AI 接手这些高频低难度任务后团队产出确实会明显提升。但“提升产出”不等于“AI 替代了 200 个职位”因为 AI 生成的东西仍然需要人审查、修改、测试、部署、监控。第二从组织层面看CEO 说这句话的场景更接近“用 AI 放大团队产能”的营销或投资者沟通。一个精悍的团队配上 AI 工具理论上能做到过去一个大团队才能维护的产品迭代速度。这背后的真正变化不是岗位削减而是“工程师人均可维护的代码资产变多了”。第三从个体层面看这句话对普通开发者最大的提醒是重复性劳动的价值会快速归零但理解业务、设计架构、判断风险、调试复杂问题的能力会变得更加值钱。AI 不会让工程师失业但会让只写简单增删改查、不做深度思考的工程师越来越被动。所以别把这句话当成“AI 已经全面超越人类工程师”的证据。更稳妥的判断是AI 已经把软件工程推进到一个新阶段人类工程师的角色正在从“写代码的执行者”变成“定义问题、审查输出、保证质量的决策者”。这个认知会影响后面所有实操内容。我们在使用 AI 编程工具时优先应该关注的是“如何把任务拆到 AI 能高效完成的粒度”而不是“如何让 AI 一次性写出整个生产级系统”。2. AI 编程工具的核心原理与工程边界2.1 从代码补全到 AI AgentAI 编程工具不是凭空出现的。它的进化路径很清晰第一代是代码补全比如早期的 TabNine、GitHub Copilot 的雏形。它们基于语言模型预测下一个 token适合补充单行或小段代码。第二代是对话式编程代表是 ChatGPT、Cursor、Codeium 等。开发者可以描述需求模型生成整块代码或修改方案。这时候模型已经有上下文窗口能理解整个文件甚至多文件结构。第三代是 AI Agent代表是 Devin、OpenHands原 OpenDevin、AutoGPT 类的工程化 Agent以及集成在 IDE 里的 Agent 模式。它们不只是“回答问题”而是可以自主读取仓库、创建分支、修改文件、运行测试、提交 PR形成一个完整的自动化开发闭环。这里的 AI Agent 指的是以 LLM 为核心通过计划、工具调用、环境交互来完成任务循环的软件实体。它至少包含四个关键组件模型Model负责理解和生成代码。上下文管理Context聚合仓库结构、文件内容、代码搜索、终端输出、Issue 信息等。工具调用Tool Use比如执行 Shell 命令、读写文件、调用 Git、运行测试、调用 API。循环控制Loop确定什么时候停止、什么时候重试、什么时候请求人类确认。一个成熟的 AI Agent 开发或使用体验本质上就是把这四个组件组合得足够顺滑。2.2 LLM 和代码工程结合的关键上下文与工具为什么以前用 AI 写代码总是“看着对但跑不起来”核心原因有两个上下文不够、工具调用能力不足。先说上下文。代码不是孤立的文本它依赖工程结构、依赖库、环境变量、业务逻辑、测试基线。如果模型只能看到一两个文件它生成的代码大概率会和项目其他部分脱节。所以现代 AI 编程工具都在做“仓库级索引”把整个代码库向量化让模型能够按需检索相关文件再在生成时把检索结果塞进上下文。再说工具调用。模型自己不能直接操作代码它需要“手”。这个“手”就是 Shell、文件系统、Git、测试框架、包管理工具。AI Agent 通过工具调用能力把自然语言需求变成一连串的具体操作比如执行git status查看当前改动。使用文件读写工具定位OrderService.java。修改代码。执行mvn test验证。根据测试输出修复错误。这一套流程已经很像一个初级开发者的工作方式。以 OpenAI 的 function calling 和 Anthropic 的 tool use 接口为基础许多开源 Agent 框架如 LangChain、AutoGen、CrewAI 也提供了类似的编排能力。2.3 传统开发流程和 AI 开发流程的对比维度传统方式引入 AI Agent 后需求到代码人写 TDD再实现再重构人在 Prompt 中描述需求和验收标准Agent 生成代码和测试上下文获取人读代码、查文档、跑调试Agent 自动检索仓库结构、相关文件、依赖定义错误修复人看日志定位问题修改代码Agent 读日志定位问题修改代码重新运行测试代码审查人开 PR人工 reviewAgent 生成 PR人 review 变更必要时要求 Agent 修改时间消耗大量时间花在重复拼接上大量时间花在审查、验证、决策上从表格可以看到AI 并没有消灭“开发”这件事而是把人类的工作重心从“写”移到了“审”和“定”。这个转变恰好是这篇文章后面所有实操建议的底层逻辑。2.4 一个需要注意的边界AI Agent 并不是越自动越好。对于生产环境、支付链路、鉴权系统、数据删除、故障恢复这类高风险场景必须把人类的审批环节固化在流程里。后面第 8 章我会专门展开这里先提一个原则AI 负责生成人类负责授权和兜底。3. AI 编程场景拆解适合做什么不适合做什么很多团队引入 AI 编程失败不是因为工具不行而是因为场景选错了。如果让 AI Agent 去做一件“人类自己都没想清楚”的事结果必然混乱。这里直接给出适用性判断。3.1 适合 AI 的典型场景脚手架生成新建一个新模块、生成 CRUD 接口、生成项目基础结构。这种任务有大量模板特征AI 生成后再微调效率极高。单元测试补充给现有函数补测试用例。AI 可以快速生成正常路径、边界路径、异常路径的测试再人工确认断言是否正确。重构和重命名批量提取公共方法、修改变量命名、替换废弃 API。AI 能基于语法树做全局修改比人的 OCR 式替换更稳。文档生成和维护根据代码生成注释、README、接口文档。虽然质量需要人工校对但底稿效率很高。数据管道和小服务比如写一个 Python 脚本处理 CSV、写一个 Kafka 消费者、写一个简单的 API 网关配置。业务逻辑清晰、依赖少、验证方便。3.2 不适合 AI 的典型场景复杂业务架构设计团队还没想清楚模块边界、领域模型、一致性方案就急着让 AI 写代码大概率产出垃圾。遗留系统维护没有测试基线、文档缺失、业务规则散落在各种历史补丁里。AI 无法靠上下文索引理解这些隐性知识。高并发和分布式一致性这类问题依赖经验、监控数据和精细的压测不是靠生成代码就能解决的。安全敏感模块权限控制、密钥管理、支付、数据脱敏。AI 生成的代码可能存在隐藏漏洞必须由安全专家专门审查。需要人类判断的模糊需求用户故事里写“提高用户体验”AI 无法知道你在为哪个用户群做哪种改进。3.3 一个场景选择的决策表场景特征是否适合 AI原因有明确输入输出适合模型可以精确匹配有测试基线适合验证成本低技术栈主流适合训练数据丰富业务规则复杂且隐性不适合上下文无法覆盖安全风险高不适合需要人工深度审查需要长期维护和演进谨慎使用生成代码的可维护性取决于人的规范这个表可以当作团队初期选型的筛子。先把适合 AI 的场景做好再逐步扩大到有挑战的边缘场景。4. AI 编程工具链选择与环境准备如果要在实际项目中体验 AI Agent 的开发方式需要先选好工具链。目前主流方案大概有三类。第一类是 IDE 深度集成型以 GitHub Copilot 和 Cursor 为代表。它们把代码补全、对话、Agent 模式直接嵌入开发环境适合个人开发者快速上手。Cursor 的 Agent 模式可以读取整个工作区、运行命令、修改多文件体验非常接近“AI 结对编程”。第二类是独立 Agent 平台型比如 OpenHands、Devika、AutoGPT 等开源项目以及一些商业化的 AI 编程 Agent。它们通常以项目为单位工作可以 checkout 仓库、创建分支、运行测试、提 PR。适合对自动化程度要求更高的团队。第三类是自己用 LangChain、CrewAI 等框架搭建 Agent。这种方式灵活但需要自己管理模型 API、工具定义、权限边界和状态存储适合已经在做 AI 应用开发的团队。对于大多数 CSDN 读者我推荐从 Cursor 或 GitHub Copilot 这类 IDE 集成工具开始。它们的学习成本最低也能直接观察 AI Agent 是怎么和代码库交互的。如果你的团队已经在做 AI Agent 开发那么可以进一步研究 MCPModel Context Protocol这类标准化工具协议。环境准备部分以 Cursor 为例基本步骤如下安装 Node.js 20 或 Python 3.10取决于项目栈。安装 Git并配置好 SSH Key。安装 Docker如果 Agent 需要独立沙箱运行。安装 Cursor 客户端配置模型 API Key或者使用内置订阅。准备一个测试项目最好是 Git 仓库便于 Agent 使用版本控制。下面是一个最小的 Python 项目初始化命令适合让 AI Agent 在干净环境里工作mkdir ai-demo cd ai-demo git init python3 -m venv .venv source .venv/bin/activate pip install fastapi uvicorn httpx pytest注意这里不写死具体版本。实际使用时以当前稳定版为准。环境准备的目的是让 Agent 有明确的工作目录、可安装的依赖、可执行的测试命令。如果 Agent 连依赖都装不上后续代码验证就会失败。5. 完整示例用 AI Agent 生成一个 FastAPI 待办事项服务为了验证“AI 做了工程师的工作”这句话到底有多大水分我们用一个最小项目来走完整流程。假设我们的需求是生成一个 FastAPI 待办事项服务支持增删改查使用 SQLite 存储自带测试。这个任务非常适合 AI因为它边界清晰、依赖简单、验证容易。我们不需要手写代码而是通过 Prompt 驱动 AI Agent 完成。5.1 编写 Prompt在 Cursor 的 Agent 模式或任意 AI 编程工具中输入如下 Prompt请在当前项目目录中创建一个 FastAPI 待办事项服务要求如下 1. 使用 FastAPI 和 SQLAlchemy数据库使用 SQLiteORM 模型名为 Todo。 2. Todo 包含字段id(int, primary key)、title(str)、description(str)、completed(bool, defaultFalse)、created_at(datetime)。 3. 提供 REST API - POST /todos 创建待办事项 - GET /todos 获取列表 - GET /todos/{id} 获取单个事项 - PUT /todos/{id} 更新事项 - DELETE /todos/{id} 删除事项 4. 使用 Pydantic 做请求体校验。 5. 创建数据库表并在应用启动时自动初始化。 6. 在 requirements.txt 中声明所有依赖。 7. 编写 pytest 测试覆盖每个接口的正常和异常路径。 8. 运行所有测试。这个 Prompt 的价值在于把模糊需求转成了明确的验收标准。AI Agent 拿到任务后会自己拆解步骤创建文件、安装依赖、写测试、跑测试。如果中间出错它会尝试修复。5.2 预期生成的文件结构AI Agent 通常会生成以下文件ai-demo/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── models.py │ ├── schemas.py │ ├── database.py │ └── routers/ │ ├── __init__.py │ └── todos.py ├── tests/ │ ├── __init__.py │ ├── conftest.py │ └── test_todos.py ├── requirements.txt └── README.md文件结构可能略有差异但核心依赖会一致。这里我们重点关注代码质量而不是完全由 AI 决定结构。在实际项目中应该在 Prompt 中显式声明目录结构偏好否则 AI 生成的布局可能不符合团队规范。5.3 核心代码示例下面给出一个符合上述需求的参考实现。这段代码也可以理解为“AI 生成后经人工审查的版本”。# 文件路径app/database.py from sqlalchemy import create_engine from sqlalchemy.orm import declarative_base, sessionmaker SQLALCHEMY_DATABASE_URL sqlite:///./todos.db engine create_engine( SQLALCHEMY_DATABASE_URL, connect_args{check_same_thread: False} ) SessionLocal sessionmaker(autocommitFalse, autoflushFalse, bindengine) Base declarative_base()# 文件路径app/models.py from datetime import datetime from sqlalchemy import Boolean, Column, DateTime, Integer, String from .database import Base class Todo(Base): __tablename__ todos id Column(Integer, primary_keyTrue, indexTrue) title Column(String, indexTrue) description Column(String, default) completed Column(Boolean, defaultFalse) created_at Column(DateTime, defaultdatetime.utcnow)# 文件路径app/schemas.py from datetime import datetime from pydantic import BaseModel, ConfigDict class TodoCreate(BaseModel): title: str description: str class TodoUpdate(BaseModel): title: str | None None description: str | None None completed: bool | None None class TodoOut(BaseModel): model_config ConfigDict(from_attributesTrue) id: int title: str description: str completed: bool created_at: datetime# 文件路径app/main.py from fastapi import FastAPI from .database import Base, engine from .routers import todos Base.metadata.create_all(bindengine) app FastAPI(titleAI Todo Service, version1.0.0) app.include_router(todos.router) app.get(/) def read_root(): return {message: AI Todo Service is running}# 文件路径app/routers/todos.py from fastapi import APIRouter, Depends, HTTPException from sqlalchemy.orm import Session from ..database import SessionLocal from ..models import Todo from ..schemas import TodoCreate, TodoOut, TodoUpdate router APIRouter(prefix/todos, tags[todos]) def get_db(): db SessionLocal() try: yield db finally: db.close() router.post(, response_modelTodoOut, status_code201) def create_todo(todo_in: TodoCreate, db: Session Depends(get_db)): todo Todo(**todo_in.model_dump()) db.add(todo) db.commit() db.refresh(todo) return todo router.get(, response_modellist[TodoOut]) def list_todos(db: Session Depends(get_db)): return db.query(Todo).order_by(Todo.created_at.desc()).all() router.get(/{todo_id}, response_modelTodoOut) def get_todo(todo_id: int, db: Session Depends(get_db)): todo db.get(Todo, todo_id) if todo is None: raise HTTPException(status_code404, detailTodo not found) return todo router.put(/{todo_id}, response_modelTodoOut) def update_todo(todo_id: int, todo_in: TodoUpdate, db: Session Depends(get_db)): todo db.get(Todo, todo_id) if todo is None: raise HTTPException(status_code404, detailTodo not found) data todo_in.model_dump(exclude_unsetTrue) for field, value in data.items(): setattr(todo, field, value) db.commit() db.refresh(todo) return todo router.delete(/{todo_id}, status_code204) def delete_todo(todo_id: int, db: Session Depends(get_db)): todo db.get(Todo, todo_id) if todo is None: raise HTTPException(status_code404, detailTodo not found) db.delete(todo) db.commit() return None# 文件路径tests/test_todos.py from fastapi.testclient import TestClient from app.database import Base, engine from app.main import app client TestClient(app) def setup_function(): Base.metadata.drop_all(bindengine) Base.metadata.create_all(bindengine) def test_create_todo(): response client.post(/todos, json{title: Write article, description: AI engineering}) assert response.status_code 201 data response.json() assert data[title] Write article assert data[completed] is False def test_list_todos(): client.post(/todos, json{title: Todo 1}) response client.get(/todos) assert response.status_code 200 assert len(response.json()) 1 def test_get_todo_not_found(): response client.get(/todos/999) assert response.status_code 404 def test_update_todo(): created client.post(/todos, json{title: Old Title}).json() response client.put(f/todos/{created[id]}, json{title: New Title, completed: True}) assert response.status_code 200 data response.json() assert data[title] New Title assert data[completed] is True def test_delete_todo(): created client.post(/todos, json{title: Delete me}).json() response client.delete(f/todos/{created[id]}) assert response.status_code 204 assert client.get(f/todos/{created[id]}).status_code 404这段代码可以作为 AI 生成结果的“参考答案”。如果你用 AI Agent 跑同样的任务大概率会得到类似的实现但细节可能有差异。差异本身不是问题问题是你要有一套标准判断“生成的代码能不能合入主干”。5.4 使用 Shell 验证依赖安装如果 AI Agent 没有自动安装依赖你需要手动执行pip install -r requirements.txt然后启动服务uvicorn app.main:app --reload --port 8000打开浏览器访问http://127.0.0.1:8000/docs可以查看 Swagger 文档。这里需要注意的是AI 生成的代码不一定能一次通过。如果启动报错优先检查requirements.txt中的依赖是否匹配以及是否使用了当前环境不支持的语法特性。6. 运行结果与效果验证我们分两个层面验证第一服务本身是否正常运行第二AI 是否真正完成了“工程师的工作”。6.1 验证接口功能使用 curl 命令创建一个待办事项curl -X POST http://127.0.0.1:8000/todos \ -H Content-Type: application/json \ -d {title: Build AI demo, description: Test with curl}预期输出类似{ id: 1, title: Build AI demo, description: Test with curl, completed: false, created_at: 2025-04-10T12:00:00.123456 }再获取列表验证查询逻辑curl http://127.0.0.1:8000/todos如果返回包含刚才创建的记录说明服务端到端链路正常。6.2 运行自动化测试进入项目目录执行pytest -v预期看到 5 个测试全部通过test_create_todo PASSED test_list_todos PASSED test_get_todo_not_found PASSED test_update_todo PASSED test_delete_todo PASSED如果测试失败先看失败用例的名称再定位断言。比如test_get_todo_not_found失败很可能是因为 Pydantic 版本不同导致响应结构变化也可能是数据库没有正常清理。排查第一步永远看完整日志而不是让 AI 盲目重试。6.3 如何评估 AI 生成代码的质量仅通过测试还不够。你还要从这些维度评估可维护性命名是否清晰函数是否足够短是否有重复代码。一致性是否遵循了项目已有的代码风格、目录规范。安全性是否有 SQL 注入、敏感信息硬编码、越权问题。性能是否有明显的 N1 查询、不必要的同步等待。在这个示例中AI 生成的代码满足基本功能但还缺少分页、软删除、更细粒度的校验。这些需要工程师在审查时提出并让 AI 继续迭代。换句话说AI 完成了初稿但“代码评审改进”依然是人的核心工作。7. 常见问题与排查思路在实际使用 AI 编程工具和 Agent 时你会遇到很多和传统开发不一样的问题。下面这张表总结了最常见现象、原因和排查路径。问题现象可能原因排查方式解决方案AI 生成的代码无法编译依赖版本不匹配、使用了不存在的 API、上下文缺失查看编译错误日志检查 import 路径要求 AI 读取依赖文件并按版本调整代码或者人工修复后让 AI 学习测试跑不过但代码逻辑看起来正确测试环境未初始化、数据库状态污染、断言过期查看 pytest -v 的具体失败输出清理测试数据库审查断言逻辑必要时让 AI 重写测试Agent 在执行任务时卡住上下文太宽泛、模型无法定位目标文件、工具调用失败查看 Agent 的步骤日志和工具返回结果缩小任务粒度在 Prompt 中指定文件路径和验收标准生成的代码风格与项目不一致项目缺少风格指引模型默认按通用风格生成检查项目是否配置 formatter 和 lint 规则在 Prompt 中强调项目规范或在工程中强制使用 black、prettier、checkstyleAI 修改文件时破坏了其他功能Agent 上下文窗口有限没有理解全局依赖查看 git diff定位被意外修改的文件要求 Agent 在修改前先列出影响面或使用独立分支运行模型 API 返回超时或限流企业代理、Token 限额、网络不稳定查看 API 返回状态和配额监控配置超时重试使用更长上下文的模型或拆分任务这里有两条重要经验第一遇到失败先看日志不要盲目让 AI 重复执行。如果日志告诉你某个依赖不存在你再让 AI 去修依赖而不是让 AI 再生成一遍整个文件。第二给 AI 的最小任务粒度要足够小。一个任务如果包含“设计实现部署测试”四层目标Agent 很容易在中间环节迷失。正确做法是先让它实现某个接口通过测试后再让它继续扩展。这就是“原子化 Prompt”思想。8. 最佳实践与工程建议如果你现在开始把 AI 引入开发流程下面这些建议可以帮助你少走弯路。8.1 定义 AI 的工作边界在项目里提前约定哪些事情可以让 AI Agent 直接做哪些必须等人工批准。例如允许 AI 创建分支、修改代码、运行本地测试。禁止 AI 直接推送 master 分支。禁止 AI 操作生产数据库。禁止 AI 修改 CI/CD 配置。禁止 AI 删除数据或执行破坏性命令。这些边界可以通过 Agent 的权限配置或团队的流程规范来实现。就算工具本身支持无限制操作也要主动把权限收紧。8.2 保留代码评审环节AI 生成代码后必须经过至少一人评审。评审重点不是“代码能不能跑”而是“这个实现是否符合业务预期、是否存在安全漏洞、是否便于长期维护”。很多团队引入 AI 后速度很快但 bug 率也上升原因就是跳过了评审。建议把 AI 生成的代码提交为 PR并在 PR 描述中注明“由 AI Agent 生成人类已审查”。这样既能留下审计痕迹也能帮助团队积累对 AI 输出质量的经验。8.3 使用测试作为 AI 的护栏如果没有测试AI 生成代码的质量完全不可控。所以团队应该先建立测试基线再放开 AI 的自动生成权限。每个 AI 生成的功能模块都必须配套测试。CI 里强制执行“覆盖率不下降”和“测试全通过”规则。如果 AI 生成的代码无法通过测试优先判断是需求理解问题还是代码实现问题。需求理解问题说明 Prompt 不够清晰代码实现问题则可以让 AI 自己修复。8.4 把 Prompt 变成团队资产好的 Prompt 能大幅提升 AI 生成代码的质量。建议团队建立自己的 Prompt 模板库沉淀以下内容项目技术栈说明。目录结构约定。代码风格规范。常用任务的验收标准。禁止事项列表。比如对于一个 FastAPI 项目团队 Prompt 模板可能长这样你在为 [项目名] 贡献代码。技术栈FastAPI SQLAlchemy PostgreSQL。 代码风格使用类型注解、函数保持短小、服务层和路由层分离。 所有接口必须包含输入校验、错误处理和单元测试。 禁止修改数据库迁移文件禁止在生产环境运行自动迁移。 完成后运行 pytest 并确保全绿。这比每次临时写 Prompt 高效得多也能让 AI 的输出稳定在团队可接受的范围内。8.5 在安全敏感操作前增加人工审批对于涉及权限、支付、用户数据、生产环境的操作即使 AI 已经自动完成也需要设置人工审批节点。具体做法包括AI 生成“操作计划”而不是直接执行。人在确认计划后手动执行关键步骤。高权限命令由人运行AI 只提供命令建议。对 AI 的操作日志做审计。8.6 衡量 AI 引入效果不要只看“代码生成量”。建议团队记录四个指标需求交付周期。缺陷逃逸率。CI 通过率。工程师在代码评审、需求分析上的时间占比。如果引入 AI 后需求交付周期明显缩短缺陷率没有上升说明 AI 用对了。如果代码生成量很大但缺陷率飙升说明审查和规范没有跟上。9. 总结与后续学习方向回到最开始的问题AI 是否正在做 200 名工程师的工作从我们刚才的实操看AI 确实能够独立完成一个待办事项服务的代码生成、测试和修复这在过去确实需要好几个初级工程师的工时。但更重要的是这个过程中人的角色并没有消失而是变得更像“技术负责人”定义任务、审查输出、处理异常、做最终决策。如果你现在是一个开发者接下来最值得投入的三个方向是学习如何把复杂需求拆解成 AI 可以执行的原子化任务。学习如何审查 AI 生成的代码尤其是安全性和可维护性。学习 AI Agent 的开发原理包括上下文工程、工具调用、多 Agent 协作。这会是未来工程能力的重要分水岭。而如果你是一个技术管理者建议从小范围试点开始选定测试基础好、业务边界清晰的项目让 AI 先尝试低风险任务。在流程和审查机制健全之前不要盲目追求“全自动开发”。AI 不会取代工程师但会重塑工程师的能力结构。这篇文章讲到的示例、排查表和工程建议可以作为团队引入 AI 编程的一个起点。下一步你可以试着让 AI Agent 在真实仓库里完成一个小的 Issue从实践中感受它的能力边界再逐步把它引入到更核心的开发流程中。