1. 这句话到底在说什么“手写代码结束了做东西的人刚开始”——第一次看到这句话我盯着屏幕愣了好几秒。不是因为它多深奥恰恰相反它太直白了直白到像一盆冷水浇在每一个还在键盘上敲敲打打的人头上。我做了十多年一线开发从最早手写汇编优化、手撸数据结构到后来用框架、用脚手架、用低代码平台再到这两年看着AI辅助编程工具一点点渗透进日常工作流这句话几乎把我这些年的职业焦虑浓缩成了一行字。它说的其实是一个很朴素的事实代码的“手写”阶段正在被工具快速替代但“做东西”这件事——把一个想法变成真正能跑、能用、能解决问题的产品——才刚刚进入最难的阶段。这里的“手写代码”指的是传统意义上逐行敲语法、调API、拼逻辑的编码劳动“做东西”则涵盖了需求判断、架构设计、技术选型、质量把控、部署运维、迭代优化这一整条链路。换句话说AI和自动化工具把“写”这件事的门槛拉到了地板上但把“做”这件事的天花板顶到了天上。这篇文章适合谁看如果你是刚入行的开发者正在焦虑“AI会不会取代我”那这篇内容能帮你把焦虑转化成具体的行动方向如果你是有几年经验的工程师发现自己每天还在重复CRUD那这里会给你一套从“编码者”转向“构建者”的实操思路如果你是技术管理者或独立开发者正在琢磨怎么用更少的人力做出更完整的产品那下面的内容可以直接抄作业。我不打算讲空泛的趋势只讲我踩过的坑、试过的方案、以及那些真正让“做东西”变得可控的具体方法。2. 为什么“手写代码”正在退场2.1 编码劳动被替代的真实边界在哪里先说一个我自己的观察。三年前我做一个后台管理系统从建表、写实体类、写Mapper、写Service、写Controller、写前端页面一套CRUD下来至少两天。现在同样的需求我用代码生成工具加AI辅助半小时能出第一版可运行的原型。这不是夸张是每天都在发生的事。但问题在于——那半小时出来的东西和两天出来的东西差距不在代码量上而在“判断”上。代码生成工具能帮你写出符合语法的增删改查但它不知道这张表的索引该怎么建才合理不知道这个接口在高并发下会不会成为瓶颈不知道前端这个交互逻辑对用户来说是不是反直觉的。这些判断才是“做东西”的核心。我见过太多团队用工具生成了大量代码结果系统跑起来到处是坑数据库连接池没配好、缓存穿透没处理、前端状态管理一团糟。代码是有了东西没做成。所以“手写代码结束”不是说编码这件事消失了而是说编码从“核心技能”降级成了“基础操作”。就像现在做PPT没人会因为你会在PPT里插入图表而觉得你厉害大家看的是你的内容逻辑和视觉表达。编码也一样会写for循环、会调API、会配环境这些正在变成默认能力而不是竞争优势。2.2 工具链进化把门槛拉到了哪里我梳理了一下自己这些年用过的工具链变化大概能看出一个清晰的脉络阶段典型工具核心特征对人的要求纯手写期文本编辑器编译器逐行编码手动管理依赖语法熟练度、算法能力框架期Spring、React、Django约定优于配置脚手架生成框架理解、设计模式低代码期可视化搭建平台拖拽生成配置化开发业务抽象、组件设计AI辅助期智能编程助手自然语言生成代码自动补全需求描述、结果校验智能体期自主编程代理根据目标自主规划并执行目标定义、质量评估这个演进的核心逻辑是每一层工具都在把“怎么做”封装起来把“做什么”暴露给使用者。以前你要知道快速排序怎么实现现在你只需要知道什么时候该排序、数据量大概多大、对稳定性有没有要求。以前你要手写SQL优化现在你只需要告诉工具“这个查询要控制在50毫秒内”它帮你生成执行计划。但这里有个巨大的陷阱工具越强用错工具的代价越大。我见过一个团队用低代码平台搭了一个内部审批系统前期两周就上线了老板很满意。结果半年后业务逻辑复杂了平台不支持自定义流程分支整个系统推倒重来。省下来的编码时间加倍还回去了。这就是典型的“手写代码结束了但做东西的人还没准备好”。2.3 被解放出来的时间去了哪里理论上工具帮你省下了编码时间你应该有更多时间做“更重要的事”。但现实是很多人省下来的时间并没有流向价值更高的地方而是被稀释掉了。我观察到的几种典型情况第一种是时间被“调工具”吃掉了。AI生成的代码跑不通你得花大量时间调试、改提示词、换模型、对比结果。有时候调一个bug的时间比自己写还长。这不是工具的问题是你还没建立起“与工具协作”的工作流。第二种是时间被“补窟窿”吃掉了。工具生成的代码质量参差不齐命名混乱、边界条件缺失、异常处理草率。你省下了写代码的时间但花在了读代码、改代码、擦屁股上。我自己的经验是AI生成的代码审查时间至少是生成时间的三倍否则就是在给自己埋雷。第三种是时间被“选择困难”吃掉了。工具太多了今天这个框架明天那个平台每个都试试每个都浅尝辄止。最后什么都没做深什么都没做成。我见过一个独立开发者半年换了四套技术栈产品一行没写。所以真正的问题不是“手写代码结不结束”而是当编码不再是瓶颈时你的瓶颈变成了什么如果你的答案是“不知道”那说明你还没有进入“做东西”的状态。3. “做东西”的人需要补上哪些能力3.1 从“实现者”到“定义者”的思维转换我以前带过一个应届生技术底子很好LeetCode刷了五百多道框架源码也读过。给他一个明确的需求他能很快实现出来。但有一次我让他做一个“用户反馈收集功能”他直接开始建表、写接口、画页面。做完之后我问他用户为什么要反馈反馈之后谁来处理处理时效要求是多少反馈数据要不要和工单系统打通他愣住了说“你没告诉我这些”。这就是典型的“实现者思维”——你给我什么我做什么。而“做东西”需要的是“定义者思维”——在动手之前先把问题定义清楚把边界划出来把成功标准定下来。这个转换说起来简单做起来极难。因为它要求你从“技术视角”切换到“用户视角”和“业务视角”。我自己的做法是每次动手前强制问自己五个问题这个东西给谁用他们在什么场景下用不用这个东西他们现在怎么解决痛点在哪做完之后怎么判断它成功了有没有可量化的指标最核心的一个功能是什么如果只能做一个做哪个三个月后这个东西可能怎么变现在的设计能不能撑住这五个问题我称之为“做东西五问”。每次我跳过它们直接写代码最后都会返工。没有例外。3.2 需求翻译把“想要”变成“可执行”“做东西”最核心的能力是把模糊的“想要”翻译成清晰的“可执行”。这中间隔着巨大的鸿沟。用户说“我想要一个快一点的系统”这句话里至少包含三层信息多快算快在什么条件下快快不了的时候怎么办我常用的翻译框架是场景-行为-指标三层拆解场景用户在什么情况下会感受到“慢”是首页加载是搜索是导出报表行为用户在这个场景下的操作路径是什么点击了什么等待了多久指标可量化的目标是什么首屏加载小于1.5秒搜索响应小于500毫秒导出10万条数据小于30秒把这三层写清楚需求就从“想要”变成了“可执行”。然后你再去选技术方案就有依据了。首屏加载慢可能是图片太大、可能是接口太慢、可能是JS阻塞渲染每个原因对应的解法完全不同。没有指标你就是在瞎猜。这里有个实操技巧把需求写成验收用例。不要写“系统要支持高并发”而是写“在1000个用户同时在线的情况下核心接口的P95响应时间不超过800毫秒”。前者是愿望后者是合同。做东西的人要习惯签合同。3.3 技术选型的决策框架当编码不再是瓶颈技术选型就成了决定成败的关键。我见过太多项目技术选型拍脑袋后期填坑填到崩溃。分享一个我用了多年的选型框架四个维度打分维度核心问题权重建议匹配度这个技术解决当前核心问题的能力有多强35%成熟度社区活跃吗文档全吗出问题能搜到答案吗25%团队适配团队有人会用吗学习成本能接受吗25%演进空间未来业务变化时它能跟着长吗15%每个维度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 性能问题的排查路径性能问题是最让人头疼的因为它往往不是单一原因而是多个因素叠加。我总结了一套排查路径按顺序走基本能定位到根因步骤检查项常用工具典型发现1系统资源top、free、iostatCPU打满、内存泄漏、磁盘IO高2应用日志日志平台、grep慢查询、异常堆栈、GC频繁3数据库慢查询日志、执行计划缺索引、全表扫描、锁等待4缓存缓存命中率、内存使用缓存穿透、雪崩、大key5网络抓包、延迟测试DNS慢、带宽瓶颈、连接池不足6代码火焰图、Profiler死循环、重复计算、同步阻塞我自己的经验是80%的性能问题出在数据库和缓存上。所以排查的时候先看慢查询再看缓存命中率这两个查完大部分问题就清楚了。剩下的20%里又有一半是代码问题比如在循环里查数据库、在循环里发HTTP请求。这种问题用火焰图一看就出来。5.4 上线后的监控与回滚东西上线了不代表做完了。上线后的监控和回滚能力才是“做东西”的最后一公里。我见过太多团队上线靠手动回滚靠祈祷出了问题手忙脚乱。我的标准配置是监控三件套业务监控核心指标看板比如订单量、成功率、响应时间系统监控CPU、内存、磁盘、网络、JVM/运行时指标日志监控ERROR日志告警、异常堆栈聚合、关键路径追踪回滚三原则回滚包随时可用每次上线前上一个版本的包必须准备好回滚脚本一键执行不能靠手动敲命令必须脚本化回滚决策有依据什么情况下回滚谁来决定多久内决定提前定好我自己的习惯是上线后前30分钟盯盘。看核心指标有没有异常波动看ERROR日志有没有新增看响应时间有没有劣化。30分钟没问题基本就稳了。如果有问题立刻回滚不要犹豫。犹豫的代价往往比回滚大得多。6. 我个人的一些体会做了这么多年东西我越来越觉得“手写代码”的结束不是终点而是起点。以前我们花80%的时间写代码20%的时间想问题现在应该反过来20%的时间写代码或者让工具写80%的时间想问题。想什么问题想用户是谁、痛点在哪、怎么验证、怎么演进、怎么兜底。这个转变对很多人来说是痛苦的因为它要求你从“确定性”走向“不确定性”。写代码是确定的输入输出明确跑通就是跑通。但做东西是不确定的用户可能不买账市场可能不认技术方案可能走不通。你得学会和不确定性共处学会在信息不完整的情况下做决策学会为结果负责而不是为过程负责。我自己的应对方式是把每个“东西”都当成一个实验。实验就有假设、有验证、有迭代。假设错了调整验证失败重来。不把失败当成否定而是当成信息。这样心态会好很多动作也会快很多。最后分享一个我一直在用的小技巧每次做完一个东西写一份“复盘清单”。写清楚哪些做对了、哪些做错了、哪些可以复用、哪些下次绝对不碰。这份清单不发给别人只给自己看。积累下来就是你自己的“做东西方法论”。比任何教程都管用因为它是你用真金白银的时间和精力换来的。
