AI 编程的真正价值：不是替你写代码，而是重组开发流程

关于 AI 编程，最常见的问题是“它会不会取代程序员”。我觉得这个问题太大，也太容易把讨论带偏。

更值得问的是：AI 改变了开发流程里的哪一段？它让哪些工作变快了？哪些风险被放大了？一个工程师应该如何重新组织自己的工作方式？

我的看法是，AI 编程的真正价值不是“替你写代码”，而是重组开发流程。它把很多原本低频、耗时、容易拖延的动作变得便宜：阅读陌生代码、比较方案、生成测试、写迁移脚本、做代码审查、整理文档。真正的分水岭不在于会不会用 AI 生成函数，而在于能不能把 AI 放进一套可靠的工程节奏里。

AI 最该介入的是写代码之前

很多人用 AI 的方式是：脑子里有一个大概想法，然后让它直接写代码。这当然能省时间，但也很容易把模糊需求固化成错误实现。

我现在更喜欢让 AI 在写代码之前介入：

• 让它阅读相关文件，梳理调用链
• 让它列出可能受影响的模块
• 让它比较几种实现方案
• 让它指出边界条件和异常路径
• 让它先写测试计划
• 让它找出已有代码里的相似模式

这些工作以前也应该做，但现实里经常被压缩。AI 的价值是把“认真分析”的成本降下来，让工程师更容易在动手前看清局面。

举个例子，用户说“搜索框输入不了”。如果直接改 CSS 或 JS，可能修了一个表面问题。但让 AI 先查事件绑定、遮罩层、z-index、按钮状态、主题切换逻辑，就更容易发现根因。AI 不一定一次判断正确，但它能快速展开排查面。

人负责判断，AI 负责展开

我对 AI 编程的基本分工是：人负责判断，AI 负责展开。

AI 擅长：

• 快速阅读大量代码
• 根据模式生成重复实现
• 补齐测试样例
• 解释错误栈
• 做机械重构
• 生成文档初稿
• 从 reviewer 角度找风险

人必须负责：

• 判断需求是否合理
• 判断抽象是否值得
• 判断用户体验是否顺
• 判断数据和权限风险
• 判断长期维护成本
• 对最终结果负责

最危险的用法是把判断权交给 AI。它给一个方案，你觉得“看起来挺合理”，然后直接接受。短期会很快，长期会出现很多不像人写的系统：抽象层级奇怪、边界条件缺失、错误处理不统一、命名看似专业但不贴业务。

AI 可以加速思考，但不能替代判断。

代码阅读变成日常能力

AI 对我最大的帮助之一，是降低阅读陌生代码的成本。

以前接手一个模块，第一步往往是自己全局搜索、画调用链、猜状态流。现在可以让 AI 先做一版地图：入口在哪里，数据怎么流，副作用在哪里，哪些函数是核心路径，哪些文件像是历史遗留。

但我不会完全相信这张地图。我会让它给出文件和行号，再自己抽查关键路径。这个过程像请一个速度很快的助理先把资料摊开，我再决定哪些值得细看。

这种能力对个人博客后台、管理系统、老项目维护都很有用。因为很多 bug 不是出在单个函数，而是出在“你不知道这个页面还依赖另一个共享脚本”。

实现阶段：小步提交比大段生成更可靠

AI 很容易一次生成很多代码。看起来效率高，但风险也高。我的经验是，越接近真实项目，越应该让 AI 小步修改。

一个更稳的节奏是：

1. 先让 AI 解释当前代码结构

2. 明确这一步只改哪个行为

3. 让它修改最小必要文件

4. 立即运行检查或测试

5. 再进入下一步

这样做的好处是，错误更容易定位，也更不容易把无关逻辑改坏。

如果一个改动涉及 UI、接口、数据库和权限，我会拆成几轮：先接口，再数据，再 UI，再联调。AI 可以持续推进，但每一步都要有可验证结果。

测试会变得更重要，而不是更不重要

AI 写代码越快，测试越重要。因为生成速度提升后，错误进入系统的速度也提升了。

让 AI 写测试是好事，但要注意两类“假测试”：

• 只验证当前实现，而不是验证业务行为
• 只覆盖 happy path，不覆盖失败路径

我会明确要求测试覆盖：

• 空数据
• 非法输入
• 权限不足
• 重复提交
• 并发或重复执行
• 旧数据兼容
• 外部服务失败
• 用户取消操作
• 移动端或窄屏场景

AI 很适合生成这些测试样例，但人要审查测试是否真的有意义。测试不是为了让覆盖率好看，而是为了约束行为。

Code Review 可以前移

传统 code review 发生在 PR 阶段。AI 介入后，审查可以前移到开发过程中。

我常用的方式是，每完成一个小改动，就让 AI 切换成 reviewer：

• 有没有破坏已有接口？
• 有没有遗漏错误处理？
• 有没有权限绕过？
• 有没有缓存问题？
• 有没有浏览器兼容问题？
• 有没有中文编码或乱码风险？
• 有没有重复抽象？

这种即时审查不能替代团队 review，但可以减少低级问题。团队 review 应该关注更高级的东西：产品语义、架构取舍、长期维护、线上风险。

AI 生成代码最大的问题是“看起来合理”

AI 的错误经常不是一眼假的。它会写出结构完整、命名自然、风格接近项目的代码，但业务语义可能错了。

比如它可能：

• 在前端隐藏按钮，但后端接口仍然开放
• 更新 JSON 文件，却忘了当前服务用的是 PostgreSQL
• 修了当前页面，却没修共享组件
• 改了缓存逻辑，却没有处理旧浏览器资源
• 写了删除接口，却没有审计日志
• 生成 SQL，却忽略迁移和回滚

这类问题最危险，因为它们看起来像完成了。

我的规则是：涉及权限、数据删除、资金、隐私、登录、后台入口、数据库迁移、并发一致性，必须人工逐行看。AI 可以帮我找问题，但不能替我承担责任。

AI 也会改变个人知识管理

AI 编程不只是写代码，还会改变知识沉淀方式。

以前很多经验停留在脑子里：这个模块为什么这样写，某个坑怎么绕过，某个配置为什么不能删。现在可以让 AI 在完成任务后整理成开发笔记、PRD 更新、设计规则、运维说明。

这对个人技术博客尤其重要。你可以把真实项目中的思考沉淀成文章：为什么选择 PostgreSQL，为什么后台入口要隐藏，为什么重启逻辑要兼容 Windows 和 Linux，为什么图片上传要考虑比例和富文本体验。

技术博客最有价值的内容，往往不是“我知道一个概念”，而是“我在一个真实系统里做了取舍”。

一个我现在认可的 AI 开发流程

如果让我总结一个稳定流程，大概是：

1. 让 AI 读代码，不急着改

2. 让 AI 复述需求和边界

3. 让 AI 列风险和测试点

4. 小步实现

5. 每步验证

6. 让 AI 做 reviewer

7. 人审关键路径

8. 更新文档和经验记录

这个流程看起来比“直接生成代码”慢，但实际更快。因为它减少了返工、误改和隐藏 bug。

我的结论

AI 编程不是把工程师变成提示词操作员。恰恰相反，它会放大工程师的判断力。

判断力强的人，会用 AI 更快地理解系统、比较方案、补齐测试、发现风险。判断力弱的人，会更快地产出一堆看起来合理但难以维护的代码。

所以 AI 编程的核心不是“让 AI 替我写”，而是“让我更早进入高质量思考”。AI 负责展开，人负责方向、边界和责任。