想清楚再动手
阅读需约 12 分钟更新于 2026年5月19日
快速摘要
AI 让软件开发变得前所未有的快，但真正的瓶颈已从"能不能写出来"变成了"知不知道该写什么"。 文章会结合 AI、软件开发、职业思考、工程素养 讲清核心概念、实际取舍和适用场景，方便你先快速把握重点，再决定是否阅读全文。
主题：AI、软件开发、职业思考、工程素养
0%
前几天我在做一个新功能，需要实现一个带搜索、分页、批量操作的数据列表。按照以前的节奏，我会先翻项目里有没有类似实现，查文档，手写查询逻辑和状态管理，可能要花一两个小时。这次我在 Cursor 里描述了需求，AI 直接吐出了一整段代码——类型安全、边界情况处理，连 loading 和 empty 状态都帮我写了。
不到三十秒。
我看着这段代码，突然有点不安。不是因为代码写得不好——恰恰相反，它写得很好。我的不安来自一个念头：如果我只需要 30 秒就能得到这段代码，那么任何人也只需要 30 秒。那我的价值在哪？
AI 生成代码的速度已经快到不真实了。v0 能从截图生成页面，Cursor 能根据注释补全整个模块，Claude 能一口气写完测试和文档，各种 AI 工具正在重新定义什么叫「写代码」。软件开发的门槛从未这么低过。
但这里有一个很容易掉进去的陷阱：代码写出来了，不代表你想清楚了。
我见过太多次这样的场景——AI 生成了一个看起来能跑的模块，copy-paste 进去，跑通了，功能好像也正常。然后需求稍微变一下，你打开代码一看，发现完全不理解它的逻辑流转。因为不是你写的，你对它的心智模型是零。
这就像你让一个人帮你搬家，他把所有东西都塞进箱子搬过去了，但打开箱子的时候你发现锅和书放在一起，袜子和酱油混在一块。东西都在，但你对这个家失去了掌控。
更糟的是，AI 生成的代码经常有一些「微妙的不对」：
dayjs，它给你生成了一个 new Date().toLocaleDateString()这些问题单拿出来都不致命，但累积起来就变成了我们常说的「技术债」。而 AI 产生的技术债有一个特别阴险的特点：你不知道你不知道什么。传统技术债是你明知妥协的结果，AI 的技术债是你以为没问题的代码。
Anthropic 的创始人手册里提到了一个概念叫「Agentic Technical Debt」——AI 生成的代码可以运行，但开发者没有一个连贯的心智模型。我太有共鸣了。
前两个月我在做一个迁移项目，把 Next.js 应用从 Vercel 迁到 Cloudflare Workers。AI 帮我写了几乎所有 boilerplate——wrangler.jsonc、OpenNext 配置、构建脚本。实话实说，它省了我至少两三天的工作量。
但真正的难点没有一个被 AI 解决：
proxy.ts）在 Cloudflare 上还不支持，怎么办？这些不是你打字多快的问题，是你有没有在动手之前把坑都想过一遍的问题。
所以说，AI 时代的软件开发，真正的价值正在从「执行」转移到「判断」。执行几乎免费了，判断反而变贵了。
用 AI 写了这么久代码，我越来越觉得有几样东西是它替不了你的。
第一是理解问题本身。 AI 可以告诉你一个 Modal 怎么写、怎么管理焦点、怎么处理 Escape 键。但它不会告诉你这个地方到底该不该用 Modal——用户的注意力是不是已经被打断太多次了，换成 inline 展开会不会更好，移动端上的交互要不要跟桌面端不一样。好的工程师不只是执行需求，而是能在需求还没被写出来之前，就嗅到真正的问题在哪。
第二是架构决策。 Server Component 还是 Client Component？数据在哪个层级获取？状态怎么拆？数据怎么建模？模块之间怎么划分边界？这些决策的后果往往要几个迭代之后才会显现，而 AI 没有「几个迭代之后」这个概念。它活在单个请求里，你活在整个项目的生命周期里。
第三是品味。 品味这个词听起来虚，但其实很具体——设计稿上间距是 16px，AI 生成的代码间距就是 16px，但你知道这个间距应该抽象成一个 token，因为项目里其他地方也在用同样的间距。同样的，你知道这段代码虽然能跑，但它的抽象层级不对；你知道这个命名虽然描述了当前行为，但暗示了错误的责任归属。AI 写 CSS，你设计系统。AI 懂规则，你懂规则背后的理由。
这些东西的共同点是：它们需要你想清楚，而不是你写得快。
经过一段时间的摸索，我给自己定了几条原则：
先想清楚再打开 AI。 在让 AI 写任何代码之前，我会先在脑子里（或者草稿纸上）理清几件事：这个功能要解决什么问题？边界情况有哪些？跟现有代码的关系是什么？如果让我手写，大概的结构是什么样的？有时候这个思考过程只要五分钟，但效果惊人——带着清晰的思路去用 AI，你从「被它带着跑」变成了「你带着它跑」。
把 AI 当高级实习生。 我会给它明确的 spec——要做什么、不要做什么、有什么约束。我不期望它替我思考架构，但我信任它执行那些我已经想清楚的事情。就像一个靠谱的实习生，你可以放心把活交给它，但你得先想好这活该怎么干。
看不懂的代码不 merge。 这可能是最重要的一条。AI 生成的每一行代码我都要求自己能讲清楚：这是做什么的、为什么这么写、有没有更好的写法。如果一段代码我讲不清楚，它就不应该出现在代码库里。这不是不信任 AI，而是对项目和未来的自己负责。
让 AI 帮你 review，而不是替你想。 我现在经常让 AI 做 code review——不是让它写代码，而是让它读我写的代码，找问题、提建议。这个方向的体验非常好，因为 review 是在你已有的心智模型上查漏补缺，而不是在你空白的脑子上面建房子。
有一个比喻我觉得很贴切：AI 就像一个无限耐心的施工队，你说「盖房子」它就能盖。但盖成什么样，取决于你给它的图纸。
在 AI 出现之前，「画图纸」和「搬砖」是一个人干的。现在搬砖被自动化了，画图纸变成了核心能力——你定义问题的精度决定了输出质量的上限。
所以回到开头那个让我不安的问题：如果代码 30 秒就能生成，我的价值在哪？
答案逐渐清晰了：价值在于那 30 秒之前，我花了多长时间想清楚要生成什么。 以及那 30 秒之后，我花了多长时间去审视、理解、打磨它。
打字从来不是软件开发的核心竞争力。只是以前我们被「打字」这个动作占据了太多精力，以至于误以为那就是工作本身。现在 AI 把执行层的事情变得极其廉价，反而逼我们重新审视一个老问题：你到底是在写代码，还是在解决问题？
如果你只是在写代码，AI 确实可以比你更快。但如果你在解决问题——理解用户、做判断、设计系统、权衡取舍——那 AI 不是你的替代品，它是你用过的最好的工具。
但前提是，你要先想清楚。