我没有减少编码，只是把重心从"怎么写"改成了"写什么"
几个月前，我突然意识到一个有趣的现象。
当我在审阅同事提交的 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 会检查。
我在看的是：
抽象有没有泄露？—— 这个模块暴露的 API 是否只是必要的部分，还是把内部实现细节暴露了？
职责分配合理吗？—— 这个操作该在 service 层还是 controller 层？AI 往往会对这个搞混。
错误处理现实吗？—— 代码里 try-catch 的策略，在真实运行时能用吗？有没有忽视网络延迟、数据库超时这些东西？
会不会坑下一个维护者？—— 这行代码虽然能用，但看起来诡异，会不会被别人误解而改坏？
性能有没有优化错的地方？—— 有时 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 行的质量，取决于：
系统设计的清晰度（人做的）
接口定义的精确度（人做的）
错误处理的策略（人做的）
性能指标的界定（人做的）
代码审查的严谨度（人做的）
如果这 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 的标准也在调整，从"代码写得漂不漂亮"转向"架构思路合不合理"。
二三线公司还在用"产出代码行数"衡量效率，没有意识到这个游戏规则已经变了。
初创公司反而在快速迭代中受益最大，因为不用担心"技术债"的长期后果。
我的建议：
如果你现在在一个还在用旧思维评估效率的公司，这是你展示新能力的机会。
你可以：
保持原有的代码产出速度（用 AI 帮忙）
把节省下来的时间用在系统设计和代码审查上
逐渐体现出"架构设计能力"的价值
等到公司也开始用 AI 的时候，你已经是团队里"最会用 AI 的人"了
关键认知：责任并不会减轻，反而更集中
这个很重要，必须说清楚。
假设 AI 生成的代码导致了一个线上 bug：
这不是AI 的责任（AI 不会被问责）
这不是工具的问题（工具本身没错误）
这是你的责任（你审查并上线了它）
责任流向： AI 生成代码 → 你审查了吗？ ← 你的责任开始了 ↓ 你理解了吗？← 不理解就不该上线 ↓ 你测试了吗？← 这个逃不掉 ↓ 上线了 ↓ 出了问题 → 100% 你的责任使用 AI 不是在减少责任，而是在集中责任。
你不再为"怎么打字"负责，但要为"这段代码该不该存在"负全责。
从某个角度说，难度上升了。
结论：我没有停止编码，我只是改变了编码的方式
今天的我，比三年前写的代码行数更少。
但是：
📐 设计 API 的时间更多
🔍 审查代码的时间更多
💭 思考系统架构的时间更多
🚨 预见故障模式的时间更多
🛡️ 保护未来维护者的时间更多
这些事加起来，我对自己的代码的把握和信心，比以前高了一倍。
这不是一个"AI 替代人类"的故事，而是"人类学会了如何有效地利用工具"的故事。
一个硬核建议
如果你没办法清楚地解释一段 AI 生成的代码在干什么，那就别他TM的上线。
这句话听起来像废话，但我见过太多人违反这个规则。
理解是最后一道防线。一旦你跳过了这道防线，就意味着你对代码失去了控制权。
如果这篇文章对你有启发，我有三个请求：
点赞——算法公平的话，这能帮助更多开发者看到这个视角
留言分享你的想法——你现在用 AI 编程吗？用的话，你的工作流是什么样的？遇到过什么坑？
关注《前端达人》——我每周都会更新更多像这样的硬核技术思考，涵盖 React 深度、Web API、系统设计、职业发展等话题。在这个 AI 时代，比拼的不再是敲代码的速度，而是判断力和决策力。
想要了解更多关于现代前端开发的最佳实践？
关注《前端达人》，跟我一起探索 2026 年前端的新机遇。推荐给你的开发者朋友，让更多人准备好迎接这个变化的时代。
