AI Coding 到底改变了什么

约 1676 字大约 6 分钟

2026-05-25

AI Coding 不是“让 AI 替你写代码”，而是工程师从纯执行者转向任务定义者、上下文管理者和结果审查者。

01补全增强

IDE 内联补全

AI 做什么: 根据当前文件续写函数、变量名和局部逻辑。
人负责什么: 负责设计函数边界、类型、命名和上下文。

看起来很快，但只理解局部。

02Chat 生成

聊天窗口生成片段

AI 做什么: 根据描述生成代码块、解释报错、给出方案草稿。
人负责什么: 负责补充背景、粘贴错误、筛选方案并搬回项目。

回答可能正确，但不一定适配当前仓库。

03Agentic Coding

Agent 进入项目执行

AI 做什么: 读取项目、修改文件、运行命令、观察错误并继续修复。
人负责什么: 负责定义目标、控制权限、审查 diff 和验收结果。

速度更快，错误扩散也更快。

ROLE CHANGE

工程师不是退出执行，而是上移到控制层。

拆任务把目标、约束、验收标准讲清楚
写代码监督 Agent 分步修改并控制范围
调试错误让错误输出回到下一轮上下文
自己判断完成用构建、预览、测试和 diff 验收

三个阶段

阶段	典型形态	AI 做什么	人要负责什么
补全增强	IDE 内联补全、函数补全	根据当前文件续写局部代码	写清函数边界、命名和类型
Chat 生成	聊天窗口、片段生成	根据描述生成代码块、解释错误	给出上下文、粘贴错误、审查输出
Agentic Coding	Codex、Claude Code、Gemini CLI 等	读取项目、改文件、跑命令、修复错误	定义目标、控制权限、看 diff、验证结果

补全增强解决的是“少敲一点代码”。Chat 生成解决的是“更快得到一个代码片段或解释”。Agentic Coding 解决的是“让 AI 在项目里完成一段可观察、可回滚、可验证的工程动作”。

真正的变化发生在第三阶段：AI 不只输出文本，而是开始进入你的项目环境里行动。它可能会读 package.json，修改组件文件，运行构建命令，再根据报错继续修复。此时你面对的不再是一个问答窗口，而是一个会影响工作区状态的执行者。

工程师角色的变化

过去的工作重心是“我来拆任务、写代码、调试”。现在更像是“我定义目标和边界，让 Agent 执行，再审查它的过程和结果”。

这不意味着工程师变轻松了。相反，模糊需求、缺少验收标准、上下文不完整、没有验证都会被 Agent 放大。AI 速度越快，错误扩散也越快。

你需要从“我能不能写出来”，切换到几个更工程化的问题：

目标是否足够小，能在一次任务里验收？
项目上下文是否足够明确，比如技术栈、目录约定、已有组件和禁止操作？
AI 是否需要修改文件、安装依赖、运行命令或访问外部系统？
每一步的输出如何被检查：看 diff、跑测试、打开页面、检查日志，还是让人做最终判断？

控制闭环

很多人第一次接触 AI Coding，会把注意力放在“怎么写提示词”。提示词当然重要，但更关键的是闭环：目标进入上下文，AI 执行动作，结果被观察，再决定下一步。

如果没有闭环，AI 只是在生成答案；有了闭环，AI 才能根据真实项目反馈继续工作。比如它运行 pnpm build 后看到类型错误，再回到对应文件修复；或者你指出移动端按钮溢出，它根据截图和 CSS 继续调整。

最小控制闭环

一个可靠的 AI Coding 任务至少包含四件事：目标、上下文、权限、验收。缺一个，结果都会变得不可控。

常见翻车点

一句话让 AI 生成整个项目，没有分阶段验收。
没告诉 AI 技术栈、目录约定、禁止操作和完成标准。
不看 diff，直接接受大范围修改。
看到能跑就结束，没有移动端、构建、测试或安全检查。

AI 擅长什么，不擅长什么

更适合交给 AI	仍要人工主导
样板代码、页面结构、CRUD、测试草稿、文档初稿、局部重构建议	业务判断、安全边界、长期架构取舍、隐性需求、合规和生产风险

AI 很适合处理已经有明确目标和明显反馈的任务。比如补一个表单页面、根据现有组件写一个新列表、修复构建报错、给函数补测试草稿、把 README 里的启动命令和 package.json 对齐。

AI 不适合替你做没有边界的判断。比如“这个业务到底该不该做”“这套权限模型是否满足合规要求”“这个架构能否支撑未来一年变化”。这些问题可以让 AI 帮你列选项、找风险、写评审清单，但最终责任仍在人。

最小心智模型是：你不是在提问，而是在管理一个会写代码的执行者。执行者需要目标、上下文、工具权限和验收标准。

第一次练习

第一次练习不要选“重构整个项目”“接入真实支付”“优化线上性能”这种高风险任务。更适合选一个小而完整的任务：

练习任务	为什么适合
阅读项目结构并总结技术栈	只读、低风险，能观察 AI 如何理解项目
检查 README 启动命令是否准确	有明确文件和验证目标
复刻一个静态页面区块	能练习需求描述、视觉反馈和移动端检查
给已有函数补测试草稿	修改范围小，便于人工审查

第一次练习的目标不是“让 AI 一次成功”，而是熟悉它如何读取上下文、提出计划、执行命令、展示 diff，以及你如何让它停下来、缩小范围或重新解释。

最小实操

把同一个需求分别用两种方式交给 AI：

模糊版：帮我写一个登录页。

明确版：用 Vue 3 写一个登录页，只包含邮箱、密码、记住我、登录按钮。
要求移动端不溢出，表单校验错误用中文，不接真实接口，不新增依赖。
完成后说明改了哪些文件，并告诉我如何预览。

对比两次输出时，不要只看页面是否“像登录页”，而要看四个结果：

AI 是否明确了文件修改范围？
是否遵守“不新增依赖”和“不接真实接口”？
是否考虑移动端、校验错误和中文提示？
是否告诉你如何预览、如何检查结果？

你会看到 AI Coding 的核心不在“提示词漂亮”，而在目标、约束和验收标准是否清楚。

核心结论

AI Coding 的本质变化，是把开发从“我直接写代码”变成“我设计一个可执行、可检查的任务闭环”。模型越强，这个闭环越重要；工具越能执行命令，权限和验收越不能省。

下一篇会进入工具和模型选择。先不要急着问“哪个最强”，而要问：当前任务需要补全、聊天、多模态理解，还是一个能在项目里执行的 Agent？