1. 这句话到底在说什么

“手写代码结束了，做东西的人刚开始”——第一次看到这句话，我盯着屏幕愣了好几秒。不是因为它多深奥，恰恰相反，它太直白了，直白到像一盆冷水浇在每一个还在键盘上敲敲打打的人头上。我做了十多年一线开发，从最早手写汇编优化、手撸数据结构，到后来用框架、用脚手架、用低代码平台，再到这两年看着AI辅助编程工具一点点渗透进日常工作流，这句话几乎把我这些年的职业焦虑浓缩成了一行字。

它说的其实是一个很朴素的事实：代码的“手写”阶段正在被工具快速替代，但“做东西”这件事——把一个想法变成真正能跑、能用、能解决问题的产品——才刚刚进入最难的阶段。这里的“手写代码”指的是传统意义上逐行敲语法、调API、拼逻辑的编码劳动；“做东西”则涵盖了需求判断、架构设计、技术选型、质量把控、部署运维、迭代优化这一整条链路。换句话说，AI和自动化工具把“写”这件事的门槛拉到了地板上，但把“做”这件事的天花板顶到了天上。

这篇文章适合谁看？如果你是刚入行的开发者，正在焦虑“AI会不会取代我”，那这篇内容能帮你把焦虑转化成具体的行动方向；如果你是有几年经验的工程师，发现自己每天还在重复CRUD，那这里会给你一套从“编码者”转向“构建者”的实操思路；如果你是技术管理者或独立开发者，正在琢磨怎么用更少的人力做出更完整的产品，那下面的内容可以直接抄作业。我不打算讲空泛的趋势，只讲我踩过的坑、试过的方案、以及那些真正让“做东西”变得可控的具体方法。

2. 为什么“手写代码”正在退场

2.1 编码劳动被替代的真实边界在哪里

先说一个我自己的观察。三年前我做一个后台管理系统，从建表、写实体类、写Mapper、写Service、写Controller、写前端页面，一套CRUD下来至少两天。现在同样的需求，我用代码生成工具加AI辅助，半小时能出第一版可运行的原型。这不是夸张，是每天都在发生的事。但问题在于——那半小时出来的东西，和两天出来的东西，差距不在代码量上，而在“判断”上。

代码生成工具能帮你写出符合语法的增删改查，但它不知道这张表的索引该怎么建才合理，不知道这个接口在高并发下会不会成为瓶颈，不知道前端这个交互逻辑对用户来说是不是反直觉的。这些判断，才是“做东西”的核心。我见过太多团队，用工具生成了大量代码，结果系统跑起来到处是坑：数据库连接池没配好、缓存穿透没处理、前端状态管理一团糟。代码是有了，东西没做成。

所以“手写代码结束”不是说编码这件事消失了，而是说编码从“核心技能”降级成了“基础操作”。就像现在做PPT，没人会因为你会在PPT里插入图表而觉得你厉害，大家看的是你的内容逻辑和视觉表达。编码也一样，会写for循环、会调API、会配环境，这些正在变成默认能力，而不是竞争优势。

2.2 工具链进化把门槛拉到了哪里

我梳理了一下自己这些年用过的工具链变化，大概能看出一个清晰的脉络：

这个演进的核心逻辑是：每一层工具都在把“怎么做”封装起来，把“做什么”暴露给使用者。以前你要知道快速排序怎么实现，现在你只需要知道什么时候该排序、数据量大概多大、对稳定性有没有要求。以前你要手写SQL优化，现在你只需要告诉工具“这个查询要控制在50毫秒内”，它帮你生成执行计划。

但这里有个巨大的陷阱：工具越强，用错工具的代价越大。我见过一个团队用低代码平台搭了一个内部审批系统，前期两周就上线了，老板很满意。结果半年后业务逻辑复杂了，平台不支持自定义流程分支，整个系统推倒重来。省下来的编码时间，加倍还回去了。这就是典型的“手写代码结束了，但做东西的人还没准备好”。

2.3 被解放出来的时间去了哪里

理论上，工具帮你省下了编码时间，你应该有更多时间做“更重要的事”。但现实是，很多人省下来的时间并没有流向价值更高的地方，而是被稀释掉了。我观察到的几种典型情况：

第一种是时间被“调工具”吃掉了。AI生成的代码跑不通，你得花大量时间调试、改提示词、换模型、对比结果。有时候调一个bug的时间，比自己写还长。这不是工具的问题，是你还没建立起“与工具协作”的工作流。

第二种是时间被“补窟窿”吃掉了。工具生成的代码质量参差不齐，命名混乱、边界条件缺失、异常处理草率。你省下了写代码的时间，但花在了读代码、改代码、擦屁股上。我自己的经验是，AI生成的代码，审查时间至少是生成时间的三倍，否则就是在给自己埋雷。

第三种是时间被“选择困难”吃掉了。工具太多了，今天这个框架明天那个平台，每个都试试，每个都浅尝辄止。最后什么都没做深，什么都没做成。我见过一个独立开发者，半年换了四套技术栈，产品一行没写。

所以真正的问题不是“手写代码结不结束”，而是当编码不再是瓶颈时，你的瓶颈变成了什么？如果你的答案是“不知道”，那说明你还没有进入“做东西”的状态。

3. “做东西”的人需要补上哪些能力

3.1 从“实现者”到“定义者”的思维转换

我以前带过一个应届生，技术底子很好，LeetCode刷了五百多道，框架源码也读过。给他一个明确的需求，他能很快实现出来。但有一次我让他做一个“用户反馈收集功能”，他直接开始建表、写接口、画页面。做完之后我问他：用户为什么要反馈？反馈之后谁来处理？处理时效要求是多少？反馈数据要不要和工单系统打通？他愣住了，说“你没告诉我这些”。

这就是典型的“实现者思维”——你给我什么，我做什么。而“做东西”需要的是“定义者思维”——在动手之前，先把问题定义清楚，把边界划出来，把成功标准定下来。这个转换说起来简单，做起来极难。因为它要求你从“技术视角”切换到“用户视角”和“业务视角”。

我自己的做法是，每次动手前强制问自己五个问题：

1. 这个东西给谁用？他们在什么场景下用？
2. 不用这个东西，他们现在怎么解决？痛点在哪？
3. 做完之后，怎么判断它成功了？有没有可量化的指标？
4. 最核心的一个功能是什么？如果只能做一个，做哪个？
5. 三个月后，这个东西可能怎么变？现在的设计能不能撑住？

这五个问题，我称之为“做东西五问”。每次我跳过它们直接写代码，最后都会返工。没有例外。

3.2 需求翻译：把“想要”变成“可执行”

“做东西”最核心的能力，是把模糊的“想要”翻译成清晰的“可执行”。这中间隔着巨大的鸿沟。用户说“我想要一个快一点的系统”，这句话里至少包含三层信息：多快算快？在什么条件下快？快不了的时候怎么办？

我常用的翻译框架是场景-行为-指标三层拆解：

• 场景：用户在什么情况下会感受到“慢”？是首页加载？是搜索？是导出报表？
• 行为：用户在这个场景下的操作路径是什么？点击了什么？等待了多久？
• 指标：可量化的目标是什么？首屏加载小于1.5秒？搜索响应小于500毫秒？导出10万条数据小于30秒？

把这三层写清楚，需求就从“想要”变成了“可执行”。然后你再去选技术方案，就有依据了。首屏加载慢，可能是图片太大、可能是接口太慢、可能是JS阻塞渲染，每个原因对应的解法完全不同。没有指标，你就是在瞎猜。

这里有个实操技巧：把需求写成验收用例。不要写“系统要支持高并发”，而是写“在1000个用户同时在线的情况下，核心接口的P95响应时间不超过800毫秒”。前者是愿望，后者是合同。做东西的人，要习惯签合同。

3.3 技术选型的决策框架

当编码不再是瓶颈，技术选型就成了决定成败的关键。我见过太多项目，技术选型拍脑袋，后期填坑填到崩溃。分享一个我用了多年的选型框架，四个维度打分：

每个维度1-5分，加权算总分。我自己的经验是，总分低于3.5的技术，坚决不用。哪怕它看起来再酷、再新、再有前景。因为做东西不是做实验，你要对结果负责。

举个例子，前两年有个项目要做实时协作编辑，团队有人提议用CRDT方案，有人提议用OT方案。我们用这个框架打分：CRDT在匹配度上得分高（天然支持离线），但成熟度偏低（当时可参考的落地案例少），团队适配也一般（没人真正用过）。OT方案匹配度稍低，但成熟度和团队适配都高。最后选了OT，虽然实现起来麻烦一点，但踩坑的时候能找到人问。后来证明这个选择是对的，CRDT方案在复杂文档结构下出现了性能问题，而OT方案稳住了。

3.4 质量把控：没有代码审查的“做东西”是赌博

工具生成的代码越多，质量把控就越重要。我以前觉得代码审查是形式主义，后来被坑了几次才明白：审查不是为了挑错，是为了建立共识。当团队里每个人都在用不同的AI工具生成代码，如果没有统一的审查标准，最后代码库会变成一锅粥。

我现在的做法是，不管代码是人写的还是工具生成的，审查必须过三关：

第一关是逻辑关：这段代码在做什么？边界条件处理了吗？异常路径覆盖了吗？我通常会问作者“如果输入是空、是负数、是超大值，会发生什么？”答不上来的，回去补测试。

第二关是风格关：命名清晰吗？函数职责单一吗？有没有重复代码？这一关我允许工具辅助，用静态分析工具扫一遍，但最终判断还是靠人。因为工具不知道业务语义，它不知道这个变量叫data和叫userProfile的区别。

第三关是演进关：这段代码三个月后要改，好改吗？依赖是不是太深？耦合是不是太紧？这一关最容易被忽略，但恰恰是“做东西”和“写代码”的分水岭。写代码的人想的是“现在能跑就行”，做东西的人想的是“以后还能改”。

4. 从零到一构建一个“东西”的完整流程

4.1 第一步：定义最小可交付价值

很多人做东西失败，不是因为技术不行，是因为一开始就想做太大。我见过一个独立开发者，想做一个“个人知识管理工具”，规划了笔记、标签、双向链接、图谱视图、协作分享、版本历史……做了半年，第一个版本还没上线。最后放弃了。

我的建议是，第一个版本只做一个核心场景，做到极致。什么叫核心场景？就是用户最痛的那个点，不用这个功能他就活不下去的那个。其他所有功能，都是锦上添花，第一版统统砍掉。

怎么找核心场景？我通常用“减法测试”：假设这个产品只能保留一个功能，你保留哪个？如果用户只能用一次，他会用哪个功能？如果这个功能没了，产品还有存在价值吗？这三个问题问下来，核心场景基本就浮出来了。

定义最小可交付价值的时候，还要同步定义“不做什么”。我习惯列一个“明确不做清单”，写清楚这一版不碰哪些功能、不解决哪些问题、不支持哪些场景。这个清单比“要做清单”更重要，因为它防止你中途跑偏。我自己的经验是，项目延期的主要原因不是做得慢，是做得太多。

4.2 第二步：搭建可演进的技术骨架

最小可交付价值定义清楚之后，技术骨架要能撑住未来的演进。这里的关键词是“可演进”，不是“可扩展”。可扩展是说你能加更多功能，可演进是说你能改现有功能而不推倒重来。

我搭骨架的时候，会重点考虑三个东西：

第一是数据模型。数据模型是系统的地基，地基打歪了，上面怎么盖都别扭。我通常会花至少半天时间画ER图，把核心实体、关系、关键字段想清楚。特别是状态字段，一定要穷举所有可能的状态和流转路径。我见过太多系统，状态机没设计好，后期加一个状态就要改十几处代码。

第二是接口契约。前后端分离也好，微服务也好，接口是协作的边界。我习惯先用OpenAPI或类似工具把接口定义写出来，包括请求参数、响应结构、错误码。写完之后让调用方确认，确认了再动手实现。这一步花的时间，后期会加倍省回来。

第三是配置管理。数据库连接、缓存地址、第三方密钥、功能开关，这些东西绝对不能硬编码。我通常用环境变量加配置文件的方式，本地开发、测试环境、生产环境各一套配置，通过环境变量切换。这样部署的时候不会因为改配置改出bug。

4.3 第三步：用工具加速但不依赖工具

工具是用来加速的，不是用来替代思考的。我自己的工具使用原则是：重复劳动交给工具，判断决策留给自己。

具体来说，以下场景我会用工具：

• 生成样板代码：实体类、DTO、Mapper、基础CRUD接口
• 生成测试用例：基于接口定义生成边界测试
• 生成文档：基于代码注释生成API文档
• 代码格式化：统一风格，减少审查噪音
• 简单bug修复：拼写错误、空指针检查、日志补充

以下场景我坚决自己来：

• 核心业务逻辑：这是产品的灵魂，必须自己写
• 数据模型设计：地基不能外包
• 异常处理策略：什么错该吞、什么错该抛、什么错该重试，这是判断
• 性能关键路径：工具生成的代码往往不是最优的
• 安全相关代码：认证、授权、加密，不能有半点马虎

这里有个实操心得：用工具生成代码后，不要直接提交。先通读一遍，改命名、补注释、删冗余，然后再提交。这个过程看起来费时间，但能帮你保持对代码库的掌控感。一旦你开始“反正工具生成的，不管了”，代码质量就会断崖式下跌。

4.4 第四步：部署与验证的闭环

东西做完了，得能跑起来，得能验证。我见过太多项目，代码写完了，部署卡住了，或者部署上去了，没人知道怎么验证它是否正常。

我的做法是，部署脚本和验证脚本一起写。部署脚本负责把代码送到服务器、装依赖、启服务；验证脚本负责检查服务是否健康、核心接口是否正常、关键数据是否正确。两个脚本都纳入版本管理，每次部署都跑一遍。

验证脚本我通常包含这几项：

• 健康检查：服务进程在不在？端口通不通？
• 接口冒烟：核心接口能不能返回200？返回结构对不对？
• 数据校验：关键表有没有数据？数据量级对不对？
• 日志检查：有没有ERROR级别的日志？有没有异常堆栈？

这套东西搭起来之后，每次部署心里就有底了。出问题能快速定位，是部署没成功，还是代码有bug，还是数据有问题。没有这套东西，部署就是开盲盒。

5. 实操中踩过的坑与排查技巧

5.1 工具生成代码的典型陷阱

我用AI辅助编程这两年，踩过的坑比前五年加起来都多。总结下来，工具生成的代码有几个高频陷阱：

陷阱一：过度设计。你让它写一个简单的用户查询，它给你整出Repository模式、Service层、DTO转换、缓存注解、事务管理，一套下来两百行。你只是想查个用户而已。我的应对方法是，提示词里明确说“用最简单的方式实现，不要引入额外抽象”。

陷阱二：边界条件缺失。工具生成的代码通常只处理“正常路径”，空值、越界、类型错误、并发冲突，它默认不会考虑。我现在的习惯是，生成之后立刻问自己“如果输入是null会怎样？如果列表是空的会怎样？如果两个请求同时来会怎样？”然后手动补上。

陷阱三：依赖版本混乱。工具可能给你生成一个依赖，但版本号是它训练数据里的旧版本，和你项目里的其他依赖冲突。我遇到过生成的代码用了某个库的新API，但项目里装的是旧版本，编译直接报错。所以生成之后，一定要检查依赖版本。

陷阱四：安全漏洞。工具生成的代码可能有SQL注入风险、XSS漏洞、敏感信息硬编码。我见过生成的代码直接把用户输入拼接到SQL里，也见过把密钥写在代码里的。安全相关的代码，必须人工审查。

5.2 需求变更时的应对策略

做东西的过程中，需求变更是常态。我见过最夸张的一个项目，三个月改了七次核心需求。应对变更，我的策略是区分“方向性变更”和“细节性变更”。

方向性变更是指核心场景变了、目标用户变了、价值主张变了。这种变更，我的建议是停下来，重新评估。不要试图在旧代码上改，大概率改不动。我自己的经验是，方向性变更如果超过两次，这个项目就该考虑重启了。

细节性变更是指交互调整、字段增减、流程微调。这种变更，用配置化、开关化的方式消化。比如字段增减，用动态表单；流程微调，用状态机配置；交互调整，用组件化。核心思路是把变化的部分隔离出来，让不变的部分保持稳定。

这里有个实操技巧：每次变更都记录决策日志。写清楚为什么变、变了什么、影响范围是什么、谁拍的板。这个日志在后期排查问题的时候极其有用。我遇到过一个问题，查了半天发现是三个月前一次需求变更引入的，如果没有日志，根本想不到。

5.3 性能问题的排查路径

性能问题是最让人头疼的，因为它往往不是单一原因，而是多个因素叠加。我总结了一套排查路径，按顺序走，基本能定位到根因：

我自己的经验是，80%的性能问题出在数据库和缓存上。所以排查的时候，先看慢查询，再看缓存命中率，这两个查完，大部分问题就清楚了。剩下的20%里，又有一半是代码问题，比如在循环里查数据库、在循环里发HTTP请求。这种问题用火焰图一看就出来。

5.4 上线后的监控与回滚

东西上线了，不代表做完了。上线后的监控和回滚能力，才是“做东西”的最后一公里。我见过太多团队，上线靠手动，回滚靠祈祷，出了问题手忙脚乱。

我的标准配置是：

监控三件套：

• 业务监控：核心指标看板，比如订单量、成功率、响应时间
• 系统监控：CPU、内存、磁盘、网络、JVM/运行时指标
• 日志监控：ERROR日志告警、异常堆栈聚合、关键路径追踪

回滚三原则：

• 回滚包随时可用：每次上线前，上一个版本的包必须准备好
• 回滚脚本一键执行：不能靠手动敲命令，必须脚本化
• 回滚决策有依据：什么情况下回滚，谁来决定，多久内决定，提前定好

我自己的习惯是，上线后前30分钟盯盘。看核心指标有没有异常波动，看ERROR日志有没有新增，看响应时间有没有劣化。30分钟没问题，基本就稳了。如果有问题，立刻回滚，不要犹豫。犹豫的代价，往往比回滚大得多。

6. 我个人的一些体会

做了这么多年东西，我越来越觉得，“手写代码”的结束不是终点，而是起点。以前我们花80%的时间写代码，20%的时间想问题；现在应该反过来，20%的时间写代码（或者让工具写），80%的时间想问题。想什么问题？想用户是谁、痛点在哪、怎么验证、怎么演进、怎么兜底。

这个转变对很多人来说是痛苦的，因为它要求你从“确定性”走向“不确定性”。写代码是确定的，输入输出明确，跑通就是跑通。但做东西是不确定的，用户可能不买账，市场可能不认，技术方案可能走不通。你得学会和不确定性共处，学会在信息不完整的情况下做决策，学会为结果负责而不是为过程负责。

我自己的应对方式是，把每个“东西”都当成一个实验。实验就有假设、有验证、有迭代。假设错了，调整；验证失败，重来。不把失败当成否定，而是当成信息。这样心态会好很多，动作也会快很多。

最后分享一个我一直在用的小技巧：每次做完一个东西，写一份“复盘清单”。写清楚哪些做对了、哪些做错了、哪些可以复用、哪些下次绝对不碰。这份清单不发给别人，只给自己看。积累下来，就是你自己的“做东西方法论”。比任何教程都管用，因为它是你用真金白银的时间和精力换来的。