程序员:在AI定义一切的时代,“能调”比“能写”更值钱

郭言被裁那天晚上，没有立刻回家。

他在公司楼下的便利店里坐了三小时。冷藏柜的电机声嗡嗡响着，每隔几秒就有一声轻微的滴答。他把店里所有热食都买了一遍，关东煮、饭团、咖喱鸡排饭，整整齐齐摆在面前的小桌板上，但一口没吃。他只是盯着那杯关东煮的汤，看着油花在汤面上慢慢凝固。

HR的话术很体面。“组织架构优化”，赔偿N+1，感谢三年的付出。但郭言记得部门里八个人走了四个，留下的是两个架构师和两个AI工具用得最熟练的人。他收拾工位时，瞥见其中一个留下的同事屏幕上的界面，不是他熟悉的VSCode，而是一个对话框，里面是密密麻麻的提示词。他没有走过去问，只是把显示器电源线卷好，把机械键盘装进背包，转身走了。走之前，他最后看了一眼自己工位旁边那片空着的区域，那三个被裁掉的同事的工位，HR连他们的座位都还没清理。

便利店里，他掏出手机，第一次打开了Claude。他用的是免费版，额度有限。他在对话框里输入了自己上个月花了两周写的那个组件，一个带有复杂表单校验的数据录入模块，含十个字段、六种校验规则、三个联动逻辑。他清楚地记得这个组件通宵调过两次，一次是因为日期选择器和表单提交存在异步延迟，另一次是因为边界条件没兜住。他调试时反复跑过几十种极端输入组合，最后才把它写到自己满意的状态。

现在，他在对话框里输入了需求文档的关键段落。三分钟后，Claude Code生成了一个完整的实现。他跑了测试，通过率98%。他盯着屏幕上的测试用例一一通过的提示，盯着那几行自己熬夜排查过的边界条件也被AI轻松覆盖。他忽然想不起那两个通宵自己具体做了什么，记得的只有天快亮时窗外的颜色，还有冲第三杯速溶咖啡时手抖洒在键盘上的一点水渍。

他抬起头，便利店的店员正在整理货架。冷藏柜的电机又响了一声。他把手机扣在桌上，靠在椅背上，盯着天花板上的日光灯管。那三小时里，他没有哭，但也没有离开那个便利店。

郭言今年二十九岁，前端开发，三年经验。他从入行那天起就相信写代码是一门手艺，写得越多越熟练，越熟练越值钱。他曾经用这个信念劝退过很多焦虑。但三分钟，从他点下“生成”到看到全部测试通过，只用了三分钟。这个数字把他三年的职业安全感碾成了粉末。

他不是没想过学AI工具。部门里早就有人在用GitHub Copilot，他也试过，代码补全确实快，他以为那就够了。但那天晚上他意识到，真正的冲击不是“AI帮你写代码”，而是“AI替你写代码之后，不需要你了”。留下来的那两个同事，不是因为会写代码，而是因为会用AI写代码，而且能在AI写完之后，判断它写得对不对、好在哪、差在哪。他和另外三个被裁掉的人，不是不努力，他们的代码提交量都不低，而是他们一直在做AI已经能做的事，而且做得比AI慢，成本比AI高。

后来他去社区里问了几个还在大厂的朋友。一个在广告部门的同行告诉他，以前自己写代码的时间占了八成，现在两成不到，更多时间在写提示词、看AI生成的结果、判断取舍。另一个已经在做AI编程团队管理的人告诉他，现在他的日常工作不是写代码，而是把模糊的需求拆解成AI能执行的子任务，然后检查AI的输出质量。“就像以前带实习生，只不过现在带的实习生不会抱怨，也不会辞职。”

郭言忽然意识到，他不是被AI替代了，他是被“会驾驭AI的人”替代了。

他想起陈默之前给他看过的那张坐标系，横轴是数据可用性，纵轴是任务标准化程度。他的工作，前端开发、CRUD（Create/Read/Update/Delete，即增删改查，是编程中最基础、最重复的数据操作）、组件搭建、API对接，几乎全落在右上角那个角落：高度数据化，高度标准化，是最先被冲击的那一格。他当时觉得自己看懂了，直到今夜，他才真正理解那张图背后的意思。

一、从“写代码的人”到“指挥AI写代码的人”的工作流重构

郭言重新找到一份工作，在一家外包公司帮电商客户做后台管理系统。上班第一周，他发现整个部门的工作流跟他被裁之前已经完全不一样了。部门里加上他一共四个前端，两个后端，一个架构师。没有人再像以前那样，早晨到工位就打开IDE，拉代码，开始敲。每个人的屏幕上，都开着一个AI对话框。但郭言很快发现，他们大多数只是在用它做代码补全和简单生成，AI写出什么就用什么，很少有人能在生成之后系统地审查输出质量、处理边界条件。架构师后来跟他承认：“大家都在用，但没人知道怎么用好。”

1.1 早晨：从“写”到“译”

郭言上班第一天，上午接到一个需求：给管理后台搭几个数据看板页面。他在飞书上打开产品经理发来的需求文档，产品经理写了两页，描述了要展示哪些指标、支持什么筛选条件、大概的页面布局。放在以前，郭言会打开VSCode，开始一行一行敲。但现在他花了一段时间把需求文档翻译成AI能理解的指令，包括定义接口输入输出、异常处理逻辑、权限校验规则，确认可复用的组件和需要新建的模块。

他以前不写这种东西。以前他的工作是从组长那里领任务卡，然后打开编辑器开始敲。现在他发现自己每天在做的，更像是在管理一个团队，只不过团队成员不是人，是AI。行业媒体陆续报道过，一些头部AI公司的代码已有相当比例由AI完成，白领员工的工作重心正从具体执行转向监督与决策。郭言以前看到这种新闻会觉得离自己很远，现在他发现自己正站在这个转变的起点上。

那天晚上，他打开日志。这个文档是他被裁当夜建的，从便利店回到家，他在里面写下了第一篇记录，标题是“AI三分钟复刻了我两周的工作”。从那天起，他每天回答几个固定的问题：今天AI生成的代码里，我发现了什么问题？我今天拒绝了AI的什么建议？理由是什么？我对AI的输出做了什么关键修正？

这一天的日志很短：“AI在权限校验部分漏了一个角色层级的判断。补上了。下次描述需求时要明确角色层级。”

1.2 下午：从“敲”到“审”

下午，郭言需要写一个比较复杂的业务模块，涉及数据导出、报表生成和权限过滤。他没有让AI一次性生成所有代码，而是先在白板上画了张图，把每个模块的输入输出、依赖关系、状态管理都标出来，然后逐模块生成、逐模块集成。画完之后，他对着AI对话框，用自然语言把每个模块的需求和约束描述了一遍。AI开始自动生成代码，一个模块完成，他把代码拉出来跑一遍测试，确认没问题，再让AI继续生成下一个模块。

他以前也用GitHub Copilot做代码补全，但那更像是“打字加速器”，AI提示几个词，他敲完剩下的逻辑。现在用Claude Code，他花在编码上的时间大幅下降，但花在架构设计和代码审查上的时间大幅上升。有些时候他甚至不打开IDE，直接在终端里跟Claude Code对话，让它跑命令、改文件、提交PR。这个转变在2026年的开发者社区已经不是个案。OpenAI创始成员、特斯拉前AI主管Andrej Karpathy就公开描述过，他自己的编程模式已经变成了以智能体编程为主、人工修改与润色为辅，“现在真的主要是在用英语编程了”。郭言还没到这个程度，但他能感觉到自己在朝同一个方向走。

1.3 晚上：从“交付”到“复盘”

下班前，郭言把今天AI生成的所有代码重新过了一遍。他发现AI在权限校验那一段漏了一个边界条件，不是bug，是假设不成立。AI默认“所有管理员角色都具有全部权限”，但实际业务里有个“超级管理员”角色，权限比其他管理员高一级。AI不知道这个差异。郭言把边界条件手动补上，然后把这个问题整理成一段简短的复盘，写进日志里。

那天晚上他翻回自己最早写的几篇日志，发现那时候他记录的还只是“AI在某处写错了”，而现在他开始能写“AI为什么会在这里出错”“它漏掉的前提假设是什么”“如果我换个说法描述需求，它会不会给更好的方案”。这种能力他自己没有刻意去练，是在每天复盘的过程中不知不觉长出来的。他意识到，这种判断力正在成为他职业能力里AI无法替代的部分。

二、从“能写”到“能调”的核心能力迁移

郭言上班第二周，接了一个需求：给管理后台加一个“数据导出”功能。

产品经理在飞书上写了一段话：“支持大数据量导出，用户体验友好。”郭言盯着这行字看了好一会儿。以前他看到这种需求，第一反应是打开编辑器开始写代码。现在他打开Claude Code，把这行需求翻译成了几段结构化的指令：定义导出文件格式、分页逻辑、异步任务队列、异常处理规则。

AI给了他三种方案。A方案用前端直接生成CSV，简单但大数据量会卡死；B方案用异步队列，用户体验好但架构复杂；C方案用服务端流式导出，平衡但前后端耦合深。他选了B方案。不是因为AI推荐，而是因为他知道这个管理后台面向的是运营团队，他们经常需要在周会上演示数据，用户体验不能崩。AI提供了可选项，但做选择的理由，是他自己的判断。

上线第二天，导出功能在特定数据量级下崩溃了。AI生成的错误日志写得很隐晦，只提示“任务队列超时”。郭言花了四个小时才定位到问题，是异步队列的并发控制没有处理好大数据量下的任务分片，几个导出任务同时挤进来，队列直接溢出。AI完全没有预判到这个边缘情况，因为它在训练数据里没遇到过这种量级的并发。

最后他发现，问题的根源其实更早。产品经理写的“大数据量”，在AI的理解里是几万行，而实际场景下用户会一次导出几十万行。这个语义鸿沟，AI没有追问，产品经理没有澄清，而郭言，他本该在翻译需求时就发现这个问题。他把这个教训写进了日志：“AI不会主动追问你的需求是否准确。能追问的人，只有我。”

这个故事同时展示了三种AI做不到的能力。一是选架构，就是在三种方案之间做取舍，依据是“运营团队要在周会上演示”，这个业务判断AI做不了；二是调Bug，就是在AI完全没预判到的边缘情况下，从隐晦的错误日志里定位到并发控制问题，这个调试能力AI不擅长；三是翻译需求，就是把模糊的“大数据量”翻译成精确的技术边界，这件事他这次没做好，但正是因为没做好，他更清楚地看到，能做好这件事的人，不会被AI替代。

行业分析机构普遍预测，到2026年前后，大量重复性编码工作将被AI替代。郭言以前看到这种预测会觉得焦虑，现在他不焦虑了。因为他发现被替代的那部分，恰好是他过去三年一直在做的那种工作，标准化的、重复的、不需要判断的；而剩下的那部分，选架构、调Bug、翻译需求，正在变成他每天工作的核心。

郭言在社区里看到一个帖子：一个初中生用AI生成了一个记账APP，功能齐全，评论区一片惊叹。他点进去看了代码，能跑，但架构混乱，没有异常处理，没有数据备份。他忽然意识到，这个APP和他用AI生成的后台管理系统的差距，不是“写代码的速度”，而是“这个系统在生产环境里崩溃时，谁负责”。

这个差距背后，是三种东西。第一种，AI能告诉你三种方案的区别，但它不知道这个系统三个月后会被业务方怎么拆、哪里会变成瓶颈。这种事只有被凌晨三点的报警电话吵醒过的人才会有直觉。第二种，产品经理说“大数据量”，AI以为是几万行，实际是几十万行；产品经理说“用户体验友好”，AI能生成几十种交互方案，但它不知道哪个方案在这个业务场景下不会触发其他模块的连锁反应。这个翻译，只能人来干。第三种，那个初中生是在执行别人定义好的需求；而郭言要判断的是，这个需求在技术上能不能实现、做了会不会埋雷、AI给的方案在生产环境里能不能扛住。这个判断，AI替不了。

“能写”从来不是壁垒，那种只能在“写代码的速度和产出量”维度上存在的壁垒，已经被AI碾平了。真正的壁垒在“能调”，调试、架构、需求翻译、问题定义。这些能力的共同底色，是程序员在无数次踩坑和调试中积累的隐性知识。

Andrej Karpathy曾在行业大会上总结过这个趋势。他说AI编程不只是工具迭代，而是“氛围编程”（Vibe Coding）与“代理工程”（Agentic Engineering）两种截然不同的工作模式正在分化。“氛围编程”让任何人都能写代码，但只在浅层工作；“代理工程”要求开发者像CTO一样管理AI团队，定义架构、制定规范、把握方向。郭言读到这段话的时候，想起自己之前在便利店里用Claude Code三分钟复刻两周工作的那个晚上。那时候他以为这就是AI编程的全部，像一个外挂，替你写代码。现在他才理解，那只是最浅的一层，真正的分水岭不在“会不会用AI”，而在“能不能在AI写完代码之后，判断它对不对、好在哪、差在哪”。

那天晚上他在日志里写了一行字：“我今天做的判断，AI能做吗？如果答案是‘不能’，那才是我真正值钱的地方。”

三、平台吞噬：当你的工作被AI的一次更新覆盖

郭言入职第一周，在修完那个权限校验的边界条件之后，想起一件事。

他在上一家公司写过一个自认为挺漂亮的权限模块。那是他入行第二年，花了两周时间把角色、资源、操作权限拆得清清楚楚，还加了一套定制化的审计日志逻辑，包括谁在什么时候操作了什么权限、操作前后的状态变化，全部可追溯。当时的架构师看完代码拍了拍他的肩膀，说“写得不错”。那是他职业生涯里为数不多觉得自己“真的在写有价值的东西”的时刻。

后来公司引入了一套企业级的身份认证中台。一键集成。他写的那个模块，整个被替换掉了。他不觉得愤怒，只是有点失落。他安慰自己说，中台是趋势，个人写的功能迟早会被平台收编。

现在他才意识到，那不是“趋势”，那是“平台吞噬”，而且AI时代的平台吞噬，比他经历过的那次要快得多，也狠得多。

他后来在社区里听到过一个故事。一个创业者团队花了很多时间，开发了一款AI驱动的代码审查工具，刚在市场验证阶段获得了一些用户，反馈不错。然后，主流AI编程工具通过一次更新内置了类似功能。不是“做得更好”，是“作为免费功能直接集成到已有的工作流里”。团队的所有技术投入，从模型调优到前端界面设计，瞬间变成了“重复造轮子”。

郭言问社区里那个发帖人：“后来呢？”对方说他们转向了金融行业合规审查。“因为那个领域有大量行业特化的规则，比如反洗钱的交易监控、跨境支付的合规要求。AI能生成通用审查，但它无法判断‘这笔交易的会计处理在这套监管框架下是否合规’。我们活下来了，不是因为我们技术更好，而是因为我们比AI更懂这个行业。”

郭言把这段话记在了心里。他想起自己被替换掉的那个权限模块，和那个创业团队被平台覆盖掉的产品，本质上是同一回事，他们把精力投在了“平台可以随时覆盖的功能”上，而不是“平台覆盖不了的行业判断”上。

这就是平台吞噬。不只是AI时代才有，移动互联网时代，苹果在iOS里内置手电筒功能，一夜之间所有手电筒APP都消失了。但AI时代的平台吞噬比移动互联网时代更致命。移动互联网时代，被吞噬的大多是“单一功能APP”，它们的护城河本来就不深。AI时代，被吞噬的范围扩展到了“需要一定技术门槛的复杂功能”，包括代码审查、自动化测试、数据标注、智能客服，这些过去需要专业团队才能做的事，现在可以被大模型的一次更新直接覆盖。一个独立开发者花了几个月打磨的功能，大模型团队可能用更短的时间、更多的算力、更好的训练数据，做出一个虽然粗糙但能用的内置版本。而一旦这个内置版本“够用”，大多数用户就不会再去找第三方工具了。

有科技媒体在一篇深度分析里描述过这种模式：创业团队花几个月验证市场需求，平台方用一次更新覆盖掉全部功能。郭言读到那篇文章时，想起那个做代码审查工具的团队。他们不是在和竞争对手赛跑，他们是在和平台本身赛跑，而平台手里有底层模型、海量用户、几乎无限的算力。这不是公平的竞赛。

但AI时代的平台吞噬有一个微妙的例外。如果你的产品不只是“功能”，而是“行业知识”的封装，你就不在平台吞噬的射程之内。大模型可以内置通用的代码审查，但内置不了“金融行业合规审查”，因为合规规则因国家而异、因监管框架而异、因业务类型而异，这些知识不在大模型的训练数据里，而在行业从业者的脑子里。

那天晚上，郭言在自己的日志里写下一条新的记录。不是关于代码的，是关于方向的：“不要在平台的地基上盖房子。把你的房子盖在行业知识的土地上，那块地，AI暂时还踩不进来。”

他写完这行字，又翻回到他记录权限模块被中台替代的那一页。他在那页的空白处补了一句话：“那时候我以为自己写的是代码。现在才知道，我写的是平台的一个功能扩展。功能会被覆盖，判断不会。”

四、从“按时计价”到“按判断力定价”的收入结构变化

郭言重新找工作的第一周，发现招聘软件上的岗位描述已经变了。

他以前投简历，JD上写的都是“精通React/Vue，熟悉前端工程化，三年以上开发经验”。现在他刷到的岗位，很多都加了一行新要求：“能高效使用AI编程工具，具备架构设计和AI协同能力。”还有一些更直接的，直接写“熟练使用Claude Code或Cursor，能独立管理AI编程工作流”。

他投了不少简历，收到三家公司的面试邀请。第一家公司的面试官问他：“你平时用Claude Code还是Cursor？”他愣了一下，说Claude Code。对方又问：“如果AI生成的代码在生产环境出bug，你的排查流程是什么？”他讲了那个数据导出功能的故事，异步队列并发溢出、隐晦的错误日志、四个小时的定位过程。面试官听完点了点头，在笔记本上记了一笔。第二家公司的面试官直接给他出了一道题，是一个模糊的业务需求，“做一个用户权限管理模块”，并让他现场演示怎么把需求翻译成AI能理解的指令、怎么判断AI输出的质量、怎么处理边界条件。他用了不到半小时，把需求拆成几个子任务，然后逐段让AI生成、逐段审查。面试官看着他的操作，问：“你以前在大厂做过架构吗？”他说没有，只是最近养成了一个习惯，每天记录AI协作日志。面试官说：“你这个习惯比架构经验更有说服力。”

第三家公司的面试他没通过。对方问：“你期望薪资多少？”他说了一个数字。对方说：“这个岗位是初级前端，AI工具用熟练的应届生也能做，薪资可能达不到你的预期。”

他挂了电话，忽然意识到一件事。市场已经分层了。愿意雇佣传统“代码熟练工”的公司越来越少，开出的薪资也在下降，因为“熟练工”能做的事，AI能做得更快、更便宜。而那些标注“能独立设计前端架构、能管理AI编程工作流”的岗位，薪资比他原来高出一大截。但那些岗位的门槛不是“写了多少年代码”，而是“能不能在AI写完代码之后，判断它对不对、好在哪、差在哪”。

他想起自己之前在便利店里用Claude Code三分钟复刻两周工作的那个晚上。那时候他把这当成威胁，直接感觉就是AI能替代我。现在他开始理解，那三分钟不是威胁，而是分水岭。三分钟能复刻的，是标准化代码；三分钟复刻不了的，是判断力。而判断力的价值，正在被市场重新定价。

程序员的收入结构，正在从“按时计价”转向“按判断力定价”。传统模型里，价值锚定在代码产出量，比如写了多少行、交付了多少模块。新模型里，价值锚定在判断力，比如架构咨询（帮团队设计AI编程工作流，按项目收费）、系统调试（处理AI无法定位的复杂bug，按问题收费）、AI编程培训（教传统团队转型，按课程或咨询收费）。这个转变的本质是，程序员从“劳动密集型”转向“判断力密集型”。

郭言最后选了那个给他出面试题的公司。不是因为薪资最高，而是因为面试官在他演示完AI编程工作流之后，说了一句话：“你来我们这儿，不只是写代码，是帮整个团队学会怎么和AI一起写代码。”他入职第一周，没有立刻开始接需求。他花了好几天时间，把自己过去两个月积累的AI协作日志整理成了一份文档，不是代码文档，是“AI编程协作指南”：怎么把需求翻译成AI指令、怎么检查AI输出的质量、怎么处理AI搞不定的边缘情况。他把这份文档发给了团队。架构师看完之后跟他说：“你这两个月踩的坑，帮我们省了半年的摸索时间。”

那天晚上他在日志里写道：“我现在做的工作，AI做不了。不是因为它不够聪明，是因为这些经验是从我的每一次失误、每一次修复、每一次复盘里长出来的。”

他忽然想起我们这个系列长文里反复讲的一个概念：作品集重于履历。以前他以为作品集就是GitHub上的项目仓库，那些绿色方块曾经是他职业安全感的来源。现在他发现，真正能证明他价值的东西，不是那些代码本身，而是他在AI搞不定的时候能介入并解决问题的记录，是他把每一次踩坑的教训整理成团队能用的指南。这份“AI编程协作指南”就是他新的作品集。它不说“我写过多少代码”，它说“我能帮团队学会和AI一起工作”。

五、常见死法与避坑指南

郭言入职第三周，在社区里看到一篇帖子。发帖人是一个独立开发者，用AI编程两年，最近决定把整个项目的核心模块全部重写。不是AI不够好，是他发现自己已经看不懂AI写的代码了。

帖子里有一句话让郭言盯着屏幕看了很久：“两年下来，我攒了一整座屎山。每一行代码单独看都对，拼在一起没人知道它为什么能跑。”

郭言把这篇帖子收藏了，他也正在经历自己的第一次代码反噬。

5.1 代码肥胖症

郭言入职后第一个独立负责的项目，是用AI搭一个后台管理系统的权限模块。他让Claude Code生成了整个权限校验逻辑，包括角色、资源、操作权限、审批流，功能齐全。演示那天，老板在会议室里看完说“不错，挺快”，前端组长在旁边点了点头。郭言觉得自己终于在新的职场里站稳了脚跟。

一周后，一个用户反馈说“我明明没有编辑权限，但能看到管理员才能看到的数据表”。郭言打开代码，开始排查。AI在权限校验里嵌套了四层条件判断，每一层都依赖不同的中间状态变量，逻辑路径复杂到他自己根本看不懂。他花了比重新写还长的时间来修复。那天晚上他在日志里写：“AI帮我做出了我不理解的东西，而我必须为我不理解的东西负责。”

他发现那个权限模块的代码量比人写的大了好几倍，真正的核心逻辑被淹没在大量冗余判断和重复检查里。这就是代码肥胖症。AI让代码量膨胀，但不让代码更清晰。有研究表明，使用AI编程工具的开发者，在代码产出速度提升后，如果不加节制，认知负担反而会增加，因为审核和理解AI生成的代码需要额外的脑力。更深远的影响是，AI生成的代码如果缺乏概念完整性，它非但没有减少工作量，反而通过制造“虚假的完成感”，将更多的工作量压缩到了最后的时间里，因为项目后期的“雪崩”比人力时代来得更猛烈。

那天晚上，郭言在日志里补了一行字：“不是AI生成的代码不能用在生产环境，而是你自己必须对每一行出现在生产环境里的代码负责。如果你看不懂它，你就不该用它。”

5.2 能力退化

郭言入职三周后，有一次Claude Code因为API配额用完暂时不可用。团队账户的免费额度跑完了，续费要走审批流程，预计要等两天。那天下午有个紧急需求，需要给一个表单组件加一段递归校验逻辑。郭言打开VSCode，开始手写。

写到第三层递归时，思路断了。

他坐在屏幕前，手指停在键盘上。以前递归对他来说就像呼吸一样自然，现在他发现自己已经不习惯在脑子里推演递归的完整调用栈了。他习惯了把需求描述给AI，然后检查AI的输出；当AI不在时，他忽然不会了。那天晚上他重新打开了LeetCode。

这不是他一个人的问题。开发者社区里有多项调研反映，相当比例的开发者在长期使用AI工具后，难以独立复现之前完成过的功能模块。有分析指出，在重度使用AI的用户中，已经出现了早期技能萎缩的迹象。对凡事依赖AI的初级开发者报告说，随着时间的推移，他们对解决问题能力的自信心正在下降。这就是编程上的“谷歌效应”：当你不断外包时，你的大脑就不再记忆了。

郭言在日志里写道：“如果明天AI工具全部停服，我还剩什么？”他问自己这个问题时心里很慌。但冷静下来之后他发现，这段时间他并不是只学会了“怎么给AI提需求”，他还学会了一件事：判断AI给的东西对不对。这个判断力，是他每天在日志里记录“AI今天在哪里出错了、我为什么觉得它不对、我做了什么修正”的过程中，一点一点积累下来的。手在退化，但脑在进化。他不知道这是赚了还是赔了，但他知道，如果不写日志，他连这个判断力都留不下来。

5.3 过度工程化

郭言有一次让AI生成一个用户管理模块，需求只是一个简单的CRUD操作，外加一个角色筛选功能。AI输出了一个包含几层抽象、依赖注入、工厂模式的复杂方案。

他差点就用了，因为看起来很专业。代码结构工整，设计模式用得恰到好处，注释也写得一丝不苟。他想起以前在大厂时，这种代码会被架构师表扬为“符合最佳实践”。但他盯着那段代码看了好一会儿，忽然觉得哪里不对。这个模块的用户只有几百人，操作频率一周不会超过几次。他花了十分钟自己重新写了一个简化版，只留两层逻辑：路由层处理权限校验和参数验证，服务层处理数据库操作。AI的方案最终被他全部放弃了。

他在日志里写道：“AI倾向于过拟合，给它一个简单需求，它可能输出一个过于复杂的方案。判断‘什么时候应该简单’，仍然是我自己的责任。”

郭言把这三种死法全部整理进了自己的日志里。代码肥胖是起点，AI写得快，你不审核，堆出屎山；能力退化是终点，长期依赖AI，屎山崩了你也修不了；过度工程化是陷阱，AI为了炫技生成复杂方案，你以为专业就用了，屎山不仅多，而且结构畸形。三种死法，每一刀都砍在同一个地方：AI能写代码，但不能替你为代码负责。

六、从“AI受害者”到“AI驾驭者”的转型路径

郭言入职满一个月那天，把自己这一段时间积累的AI协作日志从头到尾翻了一遍。

从被裁当夜在便利店第一次打开Claude，到被权限模块反噬的那个晚上，到Claude Code停服那天手写递归卡壳的窘迫，到过度工程化陷阱里那几层被他全部删掉的抽象逻辑，每一篇日志都记录着一个具体的判断：他当时发现了什么问题、他为什么觉得AI不对、他做了什么修正。

他翻到最早的那几篇，发现那时候他记录的东西还很浅：“AI在某处写错了”“AI漏掉了某个边界条件”。但最近几周的日志里，开始出现了不同的内容：“AI在这里出错，是因为它默认所有管理员角色具有相同权限，但实际业务里存在不同层级的管理员。这个差异不在它的训练数据里。”“我今天拒绝了这个方案，因为它用了三个状态来管理一个只需要两个状态的逻辑，过度设计。”他发现自己对AI的输出开始有了一种直觉，是那种“老医生看X光片，一眼就能看出哪里不对劲”的直觉。不是天赋，而是这一段时间的日志积累下来的。

他决定把这份日志整理成一份文档，不是给自己看，是给整个前端团队看。他花了几天时间，从几十篇日志里提炼出了几个最常见的AI协作陷阱和应对策略：怎么把模糊需求翻译成AI能理解的指令、怎么检查AI输出的代码质量、怎么处理AI搞不定的边缘情况。他把这份文档命名为“AI编程协作指南”，发给了团队。

架构师看完之后给他发了一条消息：“你这一段时间踩的坑，帮我们省了半年的摸索时间。”这句话他在郭言入职第一周的时候就说过一次了，但这次架构师又补了一句：“下周开始，你带两个新来的前端做AI编程工作流培训。他们之前没怎么用过Claude Code，你从头教。”

郭言愣了一下。他自己也才刚学会没多久。

那天晚上他在日志里写道：“我现在做的事，不是AI做不了，AI也能整理一份指南，但AI整理不出这些教训里的痛感。它不知道那个下午四点手写递归卡壳的窘迫是什么滋味，也不知道看到自己看不懂的代码出现在生产环境里有多后怕。这些痛感，是从我的每一次失误、每一次修复、每一次复盘里长出来的。”

6.1 重新定位你的工作流

郭言现在每天下班前做一件事：打开AI协作日志，回答那三个固定的问题。今天AI生成的代码里，我发现了什么问题？我今天拒绝了AI的什么建议？理由是什么？我对AI的输出做了什么关键修正？这个习惯他坚持了一段时间，从不间断。但他不是一开始就做得好的。第一周他写的东西自己回头看都觉得含糊，“AI这里写得不对”，什么叫“不对”？他没说清楚。第二周他才开始强迫自己在每一篇日志里回答三个精确的问题：错在哪里、为什么错、我做了什么修正。他发现，日志不只是记录工具，它是他训练自己判断力的方式。每次他写下“AI在这里出错了，因为……”，他都在强迫自己把隐性知识从模糊的感觉变成清晰的判断。

他的日志里有一段话，是入职第三周写的。那天他拒绝了AI的一个方案，AI建议用三层嵌套来管理权限状态，他想了很久，只用了两层，因为第三层嵌套处理的场景在实际业务中几乎不会出现。AI在过拟合，它在为一个小概率的边缘场景设计一个过于复杂的逻辑。他拒绝了它。那天他在日志里写道：“我今天拒绝了AI的一个建议。不是因为我知道更好的方案，而是因为我知道‘更简单的方案’对这个业务场景来说就是更好的方案。AI不懂什么是‘够用’，我懂。”

6.2 刻意训练你的调试能力

郭言开始刻意训练自己处理AI盲区的能力。他第一周挑了三个以前写过的模块，用AI重新生成，然后在极端边界条件下测试。前两个模块在极端数据量和并发场景下直接崩了，他连问题都定位不到，折腾了一整个下午也没找到根因。他一度怀疑这个方法是不是在浪费时间。但第三周，他开始能一眼看出AI的常见性能假设错误，比如AI在处理大数据量导出时，会默认将所有数据加载到内存中再导出，完全忽略流式处理的必要性。他把每次测试的结果整理成一个案例库，标注“AI已知盲区”“需要人工介入的信号”“排查流程”。他说这不只是提升技术能力，也是在建立自己的“作品集”，不是代码仓库，而是“你在AI搞不定的时候能介入并解决问题的记录”。

6.3 建立你的架构判断力

郭言从自己做过的一个后台管理系统里挑出一个模块，用AI生成了三种不同的架构方案。他自己分析每种方案的优劣，把分析结果和判断依据写下来，然后找架构师帮他验证。架构师看完之后说：“你选的方案方向是对的，但漏了一个维度，这个模块未来可能会被拆成微服务，你的架构没有预留接口边界。”郭言愣了一下，他确实没想过这个问题。他把架构师的话记在了日志里，在空白处补了一行：“AI能告诉我三种方案的区别，但它不知道未来这个模块会怎么演化。知道的人，是架构师。我还没到那个程度，但我至少知道该往哪个方向练了。”

6.4 从“代码贡献者”到“AI团队管理者”

准备培训内容的那几天，郭言发现自己这一段时间积累的东西，已经远远超过了一个普通使用者的范畴。他知道AI在什么类型的需求上表现最好，知道怎么检查AI输出的质量，知道怎么处理AI搞不定的边缘情况，知道哪些坑是他自己踩过的、别人也一定会踩。他忽然意识到，这些经验本身就是一种职业资产，不是“写代码的能力”，而是“判断AI输出的能力”。

培训第一天，他给两个新人看了自己最早写的几篇日志。新人们笑他那时候写的“AI在某个地方写错了”太笼统了。他说：“你们一开始也会写成这样。我第一周的日志，自己回头看都看不懂，什么叫‘不对’？我没说清楚。但你们很快就会学到，‘笼统’本身就是一个坑，你必须精确地描述AI错在哪里、为什么错、你怎么发现的、你做了什么修正，否则下一次它还是会错。”那天晚上他在日志里写道：“我现在做的事，不是‘写代码’，是‘教别人怎么和AI一起写代码’。这个岗位两年前不存在。”

七、尾声

培训结束后的那个周五，郭言一个人坐在工位上，翻到自己最早写的日志。那一页还留着被裁当夜的时间戳：凌晨零点四十七分。他记得自己在便利店里用Claude Code三分钟复刻了两周的工作，记得那种胃里翻涌的虚无感。

那个时候，他以为自己正在经历一场职业的终结。这几个月后，他发现那其实是一场价值迁移的开始。

他合上日志，走到窗前。楼下那条街上有家便利店的灯牌还亮着。他想起被裁那天晚上的自己，坐在便利店里，盯着一杯关东煮的汤，觉得学了三年的手艺突然不值钱了。那时候他以为编程的终点是“写出能跑的代码”，现在他才知道，那只是起点。真正的价值不在代码本身，而在写出代码之前的那一连串判断：这个方案在什么场景下最优？这段AI生成的代码，我能不能为它负责？这个边界条件，AI漏掉了，我能不能在它上线之前抓住它？

一个初中生能用AI生成一个能用的APP，但一个资深工程师用AI生成的是一个能扛住百万级并发的系统、一个能适应业务变化的架构、一个能在生产环境中安全运行的产品。这三种产出的差距，不是代码量的差距，不是AI熟练度的差距，而是三种隐性知识的差距，是在无数次系统崩溃里积累的架构体感、在无数次需求变更里磨出来的业务判断、在无数次“AI出错了，我来兜底”的瞬间里锻造的责任直觉。

他重新打开电脑，在今天的日志里写下了一行字：“我今天又拒绝了AI的一个建议。不是因为我有更好的方案，而是因为我知道，那个方案在这个业务场景下是过度设计。AI不懂什么是‘够用’，我懂。”

他盯着那行字看了一会儿，然后合上屏幕。

楼下的便利店还亮着灯，街灯把梧桐树叶的轮廓投射在人行道上。几个月前的那个晚上，他坐在那家便利店里，以为自己的职业走到了尽头。现在他知道了，那其实是一个转弯，从“手”到“脑”的转弯。他才刚转过这个弯，前面还有很长的路要走。

明天是周末。他打算把自己这段时间的日志再翻一遍，看看有没有遗漏的坑可以补进下一版团队协作指南里。

不是白领和蓝领，而是数据可用性和任务标准化程度

同一个“AI”，不同场景下的底层技术完全不同

没有社保的一人公司，如何构建自己的安全网？

一人公司完全指南：AI时代的超级个体，都在怎么赚钱？

这个暑假，别去刷实习，去造一个属于你的“作品”

三个人，一个项目频道，没有一张工位

最难毕业季，最怕“等靠要”

大学要不要增设“就业副校长”？