我没有减少编码，只是把重心从"怎么写"改成了"写什么"

几个月前，我突然意识到一个有趣的现象。

当我在审阅同事提交的 Pull Request 时，我发现，这份代码的 80% 是由 Claude 和 Sonnet 生成的。但这不是重点。

重点是——我对这份代码的信心，反而比自己完全手写的代码更高。

那一刻，我明白了什么叫"工作方式的转变"。

扎心真相：敲代码从来都不是最难的

作为一个在这个行业摸爬滚打的老兵，我必须说出一个很多人都知道但不太愿意承认的事实。

软件开发中最难的东西，从来不是语法和敲键盘。

真正需要拼脑力的部分是这些：

• 📍 理解用户的真实需求——而不是他们说出来的需求
• 🏗️ 设计合理的系统边界——让今天的决策不会成为未来的债务
• 🧩 抽象的合适程度——过度抽象和完全不抽象一样致命
• ⚖️ 权衡各种约束条件——性能、可维护性、成本、时间
• 🔮 预见系统六个月后的样子——并提前为其设计

AI 的出现，其实只是把这个本来就存在的真相，彻底暴露了出来。

不要误读：80% AI 代码 ≠ 80% 偷懒

在深入讨论之前，我得先干掉几个误解。

❌ 这个数字 不代表：

• 我盲目 copy-paste AI 的输出
• 我不看就直接上线
• 我不理解自己的代码
• 我把责任外包给了机器
• 我变成了一个"提示词工程师"

✅ 这个数字 真正代表：

• AI 负责实现细节，我负责决策方向
• 我对每一行代码都要承担责任
• 我审查的代码比生成的代码还多
• 我比以前拒绝更多的建议
• AI 是工具，而不是替身

一个恰当的比喻

如果把 AI 比作一个开发者的话，它就是：

┌─────────────────────────────────────────────┐│  一个能力强悍但上下文严重不足的实习生        ││                                             ││  优点：超快、不知疲倦、从不偷懒              ││  缺点：不懂业务、不知道长期后果              ││       不清楚老板真实想法、无法做决策          │└─────────────────────────────────────────────┘

关键是：给它明确的约束和边界，它就能发挥极致。放任它自由发挥，结果必然是一团糟。

这才是真正的转变：从"写"到"设计"

在讨论 AI 如何改变我的工作方式之前，你需要理解一个核心点。

最大的变化，不是谁来敲键盘，而是谁来定义"该敲什么"。

AI 超级擅长的事：

• ✅ 把一个想法展开成完整代码
• ✅ 生成模板和重复代码
• ✅ 按照清晰的指令工作
• ✅ 学习和复制已有的代码模式

AI 致命的弱点：

• ❌ 不知道你的业务背景
• ❌ 看不出这个决策未来会带来什么麻烦
• ❌ 不明白什么时候不应该抽象
• ❌ 无法预判系统在真实运行中会面临什么挑战

后者的这些事，才是真正需要人类判断力的地方。

我现在的工作流长什么样？

让我具体描述一下，今天我怎么开发，和三年前有什么不同。

第一阶段：设计系统架构（这是不可替代的）

在我打开任何 AI 工具之前，我会花时间回答这些问题：

系统设计清单：├─ 数据流：哪个模块拥有哪份数据？├─ 边界：这个模块的职责到底在哪里？├─ 故障模式：这个组件坏了，系统会怎样？├─ 演进性：半年后如果要加功能，麻不麻烦？└─ 可维护性：下一个维护这块代码的人能理解吗？

这个阶段很像建筑里的"出蓝图"。图纸的质量，直接决定了后续施工的质量。

我通常会：

• 用 ASCII 图或简单的流程图把系统画出来
• 列出模块间的依赖关系
• 定义清晰的接口契约
• 预设可能的故障场景和处理方式
• 思考"6 个月后的我"会不会诅咒"今天的我"

第二阶段：让 AI 去填补细节（高效且可控）

一旦架构图清晰了，我才会转向 AI。但关键的是——我给的不是模糊的需求，而是明确的约束。

我不会问：

"帮我写个用户认证系统"

我会问：

"基于这个接口定义（具体给出）和这些错误处理规范（具体给出），实现这个特定的 OAuth 流程。不要添加任何额外的日志库，所有日志用 console 替代。"

看到区别了吗？

第一个问题很容易生成出"高度设计但不适合当前项目"的代码。第二个问题能够精确控制输出。

这个阶段，AI 帮我：

• 实现 CRUD 端点（零有趣度的工作）
• 写表单验证逻辑（繁琐但简单）
• 生成 DTO 和数据模型（模板化工作）
• 写单元测试的框架（很多重复）
• 填补已有模式之间的空白

工作流示意图：清晰的系统设计      ↓  具体的接口定义      ↓明确的约束条件 ← (这些只有人能提供)      ↓  ↓ AI 在这里工作  ↓ 生成代码  ↓  ↓ 人工审查  ↓ 决策把关  ↓ 高质量输出

第三阶段：不是"检查语法"，而是"系统级审查"

这里是最容易被人误解的地方。

当我评审 AI 生成的代码时，我完全不看语法对不对。那些事 linter 会检查。

我在看的是：

1. 抽象有没有泄露？ —— 这个模块暴露的 API 是否只是必要的部分，还是把内部实现细节暴露了？

2. 职责分配合理吗？ —— 这个操作该在 service 层还是 controller 层？AI 往往会对这个搞混。

3. 错误处理现实吗？ —— 代码里 try-catch 的策略，在真实运行时能用吗？有没有忽视网络延迟、数据库超时这些东西？

4. 会不会坑下一个维护者？ —— 这行代码虽然能用，但看起来诡异，会不会被别人误解而改坏？

5. 性能有没有优化错的地方？ —— 有时 AI 会为了代码优雅而忽视性能，或者过度优化不重要的地方。

简单说：AI 写的是可运行的代码，但不一定是好代码。我的工作是确保它既可运行，又不会变成系统的技术债。

AI 真正擅长的领域（不吹不黑）

让我们给 AI 点实实在在的掌声。它确实在某些地方表现得惊人。

1. 样板代码和重复模式

这些东西最浪费时间：

• CRUD API 端点
• 数据传输对象（DTO）
• 表单验证逻辑
• 模型 schema 定义
• 重复的异步流程处理

这些工作 AI 生成的代码，我的拒绝率最低。为什么？因为这些本来就没有"聪明设计"的空间，就是"按套路来"。

2. 把想法快速转换成代码

我经常这样用 AI：

我的想法：需要一个输入框，用户停止输入 300ms 后才发送请求，         如果用户继续输入就取消前一个请求。我问 AI：实现这个 debounce 模式，用 AbortController         处理请求取消。AI 的输出：精准、可用、考虑周全的代码

这种"意图→代码"的转换速度，比我自己写快得多。我脑子里的想法往往不是一下子 100% 清晰的，需要一边写一边调整。AI 能把这个迭代周期从 5 遍变成 1-2 遍。

3. 快速探索多个方案

我经常问 AI：

你有什么办法实现「分页 API 客户端」这个功能？给我展示三种不同的架构方向。

然后 AI 会在 2 分钟内给出三个方案，有各自的 trade-off。我可以快速比较，选择最合适的。

如果自己从零想，可能需要 20 分钟才能想清楚这三个方案的区别。

AI 永远无法胜任的（这就是你的护城河）

这是区分"被淘汰的开发者"和"越来越值钱的开发者"的分界线。

1. 业务背景理解

AI 能学你的代码，但学不了：

• 你的用户真正想要什么（而不是产品经理说的）
• 你公司的法律约束（某些数据不能这样处理）
• 你的组织文化和技术品味
• 为什么上一任架构师会这样设计

这些需要在团队里摸爬滚打才能理解。

2. 长期系统设计

AI 总是局部优化。开发者需要全局思考。

你需要预见：

• 这个抽象方式，6 个月后加新功能时会不会成为瓶颈？
• 这个依赖库现在很火，但如果被收购了怎么办？
• 这个快速方案省了 2 天开发时间，但赠送了 2 个月的技术债？

AI 看不到这些。这种远期视野，来自无数次踩坑的经验。

3. 判断什么时候"不应该做"

这是最高级的判断力。

一个初级开发者的答案是"行"或"不行"。 一个高级开发者的答案是"现在不行，但这样可以"。

AI 永远只会说"可以"。 真正的价值是知道什么时候说"不需要"、"太复杂"、"这会卡你未来的手脚"。

常见的"不应该"场景：❌ 不要为暂时用不上的功能提前泛化❌ 不要引入"能用但学习成本高"的库❌ 不要在性能瓶颈真正出现之前优化❌ 不要为了"代码漂亮"而增加复杂度❌ 不要让一个微小功能引入新的外部依赖

这些判断，需要品味、直觉和恐惧（对未来代码债的恐惧）。

AI 使用者和非使用者，能力差别在哪儿？

这是个容易被误读的问题。

人们通常问："AI 是不是会让程序员贬值？"

我的答案是：AI 削平了技能分布的下半段，但抬高了上半段的天花板。

让我画个对比图：

┌─────────────────────────────────────────────────────────────┐│ 3 年前的技能分布：                                            ││                                                             ││   天才    超强   优秀   中等   初级                            ││   ◢▀▀▀▔   ◢▀    ◢▀    ◢▀    ◢▀▀▔▔▔▔▔▔▔                    ││  ▐                                                          ││  ▐  这段区间：靠打字速度和细节处理能力拉开差距                │└─────────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────────┐│ 今天的技能分布：                                              ││                                                             ││   建筑师   系统   设计   实施   模板                           ││   思维    思维    思维    思维    工人                         ││   ◢▀▀▔    ◢▀      ◢      ◢      ▔▔▔▔▔▔▔                    ││  ▐▐                                                         ││  ▐▐  这段区间：缩小，因为 AI 可以快速生成                      ││  ▐▐                                                         ││  ▐▐  顶端差距扩大，因为设计能力无法被 AI 替代                  │└─────────────────────────────────────────────────────────────┘

换句话说：

• 初级开发者：能更快地生成工作代码，但判断能力没变，反而更容易骄傲自满
• 中级开发者：能把更多精力放在架构和设计上，反而升级更快
• 高级开发者：能把 10% 的时间用来审查，90% 的时间用来思考，效率翻倍

**差别不是"会不会用 AI"，而是"有没有能力有效地利用 AI 的输出"**。

在我们公司的实际场景

我在一个项目中，整个前端模块大概 5000 行代码。其中大约 3500 行是 AI 生成的。

但这 3500 行的质量，取决于：

1. 系统设计的清晰度（人做的）
2. 接口定义的精确度（人做的）
3. 错误处理的策略（人做的）
4. 性能指标的界定（人做的）
5. 代码审查的严谨度（人做的）

如果这 5 个环节任何一个人做得不好，3500 行看似"优雅的代码"就会成为灾难。

我们团队的做法是：

产品经理提需求    ↓工程师出方案设计（纯手工）    ↓定义数据结构和 API（纯手工）    ↓列出关键的错误场景（纯手工）    ↓AI 生成实现代码    ↓三个工程师轮流审查（手工）    ↓自动化测试通过（机器）    ↓小范围灰度上线    ↓监控指标（机器 + 人工）

在这个流程里，AI 承担的只是第 5 个环节。其他 9 个环节，没有 AI，人工成本反而更高。

一个我强烈推荐的心态转变

如果你现在还在纠结"我该不该用 AI 写代码"，我给你一个简单的框架：

┌──────────────────────────────────────────┐│ AI 适合 "加法" ：                         ││  - 把一个想法展开成完整的代码             ││  - 快速试错和探索方案                    ││  - 批量生成样板代码                      │└──────────────────────────────────────────┘                    ↓         ┌──────────────────────┐         │  人类适合 "减法"：    │         │ - 删除不必要的代码   │         │ - 化简过度设计      │         │ - 提炼核心思想      │         │ - 找出隐藏的耦合    │         └──────────────────────┘

最终代码的质量，来自于：AI 添加的量 × 人类删除掉的垃圾的比例。

如果你只会用 AI 来"加"，完全不知道怎么"减"，那你生成的代码会越来越臃肿。

我看到很多团队在犯的错

错误 1：把 AI 输出当成"差不多可以"

这是最致命的态度。

AI 代码通常表面上看起来没问题：

• 语法正确
• 逻辑通顺
• 某些设计模式用得还不错

但往往暗藏着：

• 过度抽象（为了代码"优雅"）
• 多余的依赖（因为 AI 学的代码库就用这个）
• 不够清晰的错误处理（AI 的模板式处理）
• 忽视的边界场景（因为你没有明确指出）

的解决办法：激进地审查，狠狠地删除冗余代码。

我通常会把 AI 生成的 200 行代码压缩到 80 行。这个删除的过程，才是真正增加代码质量的时候。

错误 2：让 AI 来决定架构

这是完全倒过来了。

很多人的工作流是：

"我想要一个聊天系统，AI 你帮我设计一下架构"

这会导致什么？

AI 会给你一个"标准教科书架构"——看起来合理，但对你的业务背景一无所知。结果就是在做 6 个月后你会发现，某个关键的决策当初做反了。

正确做法：人类设计架构，AI 来实现。

错误 3：拿代码行数来衡量生产力

这是最老但最顽固的错误。

我用 AI 一天写了 5000 行代码！

然后呢？是高质量代码还是高债务代码？是解决了真实问题还是制造了新麻烦？

真正的生产力指标应该是：

• 解决了多少用户问题
• 系统的故障率有没有下降
• 代码有没有变得更容易维护
• 新需求来临时，需要修改多少地方

这些东西没有一个和"代码行数"成正比。

开发者的特殊处境

我专门想说一下国内的情况。

在字节、阿里这样的大厂，这个转变正在悄悄发生，但很多开发者还没反应过来。

国内的情况是：

• 一线大厂正在大规模使用 AI 编程。Code Review 的标准也在调整，从"代码写得漂不漂亮"转向"架构思路合不合理"。

• 二三线公司还在用"产出代码行数"衡量效率，没有意识到这个游戏规则已经变了。

• 初创公司反而在快速迭代中受益最大，因为不用担心"技术债"的长期后果。

我的建议：

如果你现在在一个还在用旧思维评估效率的公司，这是你展示新能力的机会。

你可以：

1. 保持原有的代码产出速度（用 AI 帮忙）
2. 把节省下来的时间用在系统设计和代码审查上
3. 逐渐体现出"架构设计能力"的价值
4. 等到公司也开始用 AI 的时候，你已经是团队里"最会用 AI 的人"了

关键认知：责任并不会减轻，反而更集中

这个很重要，必须说清楚。

假设 AI 生成的代码导致了一个线上 bug：

• 这不是 AI 的责任（AI 不会被问责）
• 这不是工具的问题（工具本身没错误）
• 这是你的责任（你审查并上线了它）

责任流向：AI 生成代码 → 你审查了吗？ ← 你的责任开始了              ↓              你理解了吗？← 不理解就不该上线              ↓              你测试了吗？← 这个逃不掉              ↓              上线了              ↓              出了问题 → 100% 你的责任

使用 AI 不是在减少责任，而是在集中责任。

你不再为"怎么打字"负责，但要为"这段代码该不该存在"负全责。

从某个角度说，难度上升了。

结论：我没有停止编码，我只是改变了编码的方式

今天的我，比三年前写的代码行数更少。

但是：

• 📐 设计 API 的时间更多
• 🔍 审查代码的时间更多
• 💭 思考系统架构的时间更多
• 🚨 预见故障模式的时间更多
• 🛡️ 保护未来维护者的时间更多

这些事加起来，我对自己的代码的把握和信心，比以前高了一倍。

这不是一个"AI 替代人类"的故事，而是"人类学会了如何有效地利用工具"的故事。

一个硬核建议

如果你没办法清楚地解释一段 AI 生成的代码在干什么，那就别他TM的上线。

这句话听起来像废话，但我见过太多人违反这个规则。

理解是最后一道防线。一旦你跳过了这道防线，就意味着你对代码失去了控制权。

如果这篇文章对你有启发，我有三个请求：

1. 点赞——算法公平的话，这能帮助更多开发者看到这个视角

2. 留言分享你的想法——你现在用 AI 编程吗？用的话，你的工作流是什么样的？遇到过什么坑？

3. 关注《前端达人》——我每周都会更新更多像这样的硬核技术思考，涵盖 React 深度、Web API、系统设计、职业发展等话题。在这个 AI 时代，比拼的不再是敲代码的速度，而是判断力和决策力。

想要了解更多关于现代前端开发的最佳实践？

关注《前端达人》，跟我一起探索 2026 年前端的新机遇。推荐给你的开发者朋友，让更多人准备好迎接这个变化的时代。