1. 先把话说透：AI 冲击的到底是什么

这两年聊 AI 和程序员，聊到最后往往变成两种极端：一种是“三个月后全行业清零”，另一种是“工具而已，不必惊慌”。这两种说法我都觉得没说到点子上。我带的团队从两年前开始把 AI 工具嵌进日常开发流程，从最初大家偷偷用它写正则，到现在代码补全、单测生成、日志排查、SQL 调优全流程都在用，中间踩过的坑和看到的变化相当具体。我的结论是：被冲击的不是“编程”这件事本身，而是编程里那一段最机械、最容易被语言描述的环节——把一句已经想清楚的话，翻译成某种语言的语法。

这件事为什么重要？因为它决定了你该往哪儿挪。很多人一听 AI 冲击，第一反应是“我要学更多框架、更多语言”，方向恰好反了。框架和语法恰恰是 AI 最擅长的部分，你在这条赛道上加码，等于跟一台不会累、不会忘、读了全网文档的机器比谁背得多。真正值钱的东西往上游走了一步：搞清楚要解决什么问题、这个问题值不值得解、解到什么程度算够、出了问题谁兜底。说白了就是从“写代码的人”变成“解决问题的人”。

这篇文章我想讲清楚三件事：AI 到底吃掉了哪些工作、剩下哪些工作是它短期吃不掉的、以及一个普通程序员在接下来一两年里可以照着做的能力重构路径。里面会有一个完整的模拟项目实操记录，包含参数怎么算、方案怎么取舍、和 AI 协作时提示词怎么写、上线前查什么。适合刚入行一两年、正在焦虑方向的人看，也适合做了五六年、发现自己“手很快但说不出价值”的人看。

1.1 被替代的从来不是“编程”，而是“翻译式编码”

我把日常编码拆成四层：意图层（要解决什么业务问题）、设计层（用什么结构解、边界在哪）、翻译层（把设计写成具体语法）、验证层（确认它真的对）。AI 现在在翻译层是碾压级别的，在设计层能给建议但给不出取舍，在意图层基本是零，在验证层能帮你写测试但判断不了“这个测试测的到底是不是重点”。

翻译层被吃掉，感受最明显的是这三类活：写 CRUD 接口、写数据转换脚本、写胶水代码把 A 系统的格式转成 B 系统要的格式。这些活的共同特征是——需求已经精确到不需要理解业务，只需要理解语法。你想想自己上周写的代码，有多少行是这种性质？我统计过自己一个月的提交，纯翻译性质的代码大概占 55%，包含设计判断的占 30%，剩下 15% 是排查和沟通。这个比例意味着什么，不用我多说。

但这里有个反直觉的点：翻译层被吃掉，不等于你的工作量减少一半。实际情况是，翻译变快了，验证变多了。AI 十秒钟给你 80 行代码，你得花二十分钟确认这 80 行在边界条件下不会把生产库写坏。我见过太多人跳过这一步，直接把生成结果贴进项目，然后在一个月后的某个凌晨被报警电话叫醒。

注意：AI 生成的代码有个隐蔽特征——它在“正常路径”上几乎总是对的，错都错在异常路径、并发时序、空值、超长输入、字符编码、时区这些地方。这些恰好是线上事故的高发区。

1.2 三个正在被压缩的工作环节

我把这两年观察到的变化整理成一张表，按“被压缩程度”排序。这张表是我跟几个不同规模团队的人聊完之后汇总的，不一定精确，但趋势应该没错。

看这张表你会发现一个规律：越是“可以被清晰语言描述、且答案唯一”的环节，压缩得越狠；越是“信息不全、需要拍板、需要承担后果”的环节，权重越高。这不是鸡汤，是分工逻辑的必然结果。

我特别想强调最后一行“跨角色沟通与推动”。很多人觉得这是“软技能”，不如技术硬。但在 AI 把技术实现的门槛拉平之后，能把一个模糊的业务抱怨翻译成三条可执行的验收标准，并且让业务方点头认可，这个能力的稀缺度会直线上升。因为它是唯一一个 AI 完全无法代劳的环节——它需要有人坐在会议室里，看着对方的脸色判断“他说的这个需求其实不是他真正想要的”。

1.3 一个自测标准：你的工作里有多少“不可验证的确定性”

我给你一个粗糙但好用的自测方法。把你上周做的所有事情列出来，逐条问三个问题：

1. 这件事的输入是不是已经完全明确？（需求文档写死了字段、格式、边界）
2. 这件事的正确性能不能用一段测试自动验证？
3. 这件事做错了，后果是什么？

如果三条答案分别是“是、能、没什么后果”，那这条工作大概率在两年内会被大幅压缩。反过来，如果输入模糊、正确性需要人来判断、做错了要担责任，那这条工作的价值在上升。

我自己用这个方法筛了一遍，发现真正让我不可替代的，是那些“输入模糊 + 需要判断 + 有后果”的事。比如判断一个需求该不该做、某个技术债现在还是半年后还、这次上线要不要带这个功能。这些事没法写成工单，也没法交给 AI，但它们决定了一个系统三年后是资产还是负债。

提示：别把“我很忙”当成安全信号。忙的如果是第 1 类工作，那只是被消耗得快一点而已。

2. 角色重定位：从“代码生产者”到“问题定义者”

“解决问题的人”这个说法听起来很虚，容易被讲成职场鸡汤。我把它拆成三个可以练的具体能力：问题定义、方案取舍、结果兜底。这三样东西有个共同点——它们都不是“知识”，而是“判断”，而判断只能靠反复做决策、承担后果、复盘来长出来，看视频看文章长不出来。

这也是为什么很多人在 AI 时代感到无力：过去十年他积累的是“知识型资产”（会几个框架、记得多少 API），这类资产贬值速度极快；而“判断型资产”反而在升值，因为当实现成本趋近于零时，决策的杠杆被放大了——你选错一个方案，AI 会以十倍的速度帮你把错误实现出来。

2.1 问题定义：把一句抱怨变成三条验收标准

我见过的最典型场景：业务方跑过来说“这个报表太慢了，能不能优化一下”。新手程序员的第一反应是打开代码看有没有索引、有没有 N+1 查询。这个反应不能算错，但它跳过了最关键的一步——“慢”到底是多慢？谁觉得慢？慢在哪个环节？

我通常会追问四句话，这四句话几乎能解决 80% 的需求模糊问题：

• “你现在打开这个页面要等多久？你期望多久？”（量化基线）
• “你是每次都觉得慢，还是月底这几天？”（定位场景）
• “慢的时候你在做什么？是等结果，还是等它加载完再筛选？”（拆解链路）
• “如果只能快一半，你能接受吗？”（确定目标，避免过度设计）

问完这四句，通常会发现真实问题跟“SQL 慢”没关系。有次追问下来，发现是业务方每次都要手动改五个筛选条件，改完还要等刷新——真正的痛点是“操作步骤多”，不是“查询慢”。最后加了个筛选条件预设，工作量半天，效果比优化查询好得多。

这就是问题定义的价值：它把“解决方案”往后推了一步，先把“问题”钉死。AI 在这一步帮不上忙，因为它不知道你的业务方昨天在会上被谁骂了、不知道这个报表是给谁看的、不知道公司下季度的考核指标是什么。

2.2 方案取舍：AI 给不出“为什么选 A 不选 B”

我可以让 AI 在十秒内给我五种实现方案，每种都写得头头是道，还附优缺点对比。但它给的所有对比都是通用对比——性能、复杂度、生态、学习成本。而真实世界里的取舍，往往是这些之外的脏东西：团队里只有一个人会这门技术、下个月要交付、老系统还得兼容三年、采购流程走不通、运维不愿意多维护一个中间件。

我举个具体的。模拟项目里要做个数据对账，方案一是全量拉取到内存算，方案二是分批流式比对，方案三是丢到数据库里用 SQL 做差集。AI 会说方案三最简洁、方案二最省内存、方案一最快。都对，但它不知道：这个库是共享的，DBA 不允许在上面跑大查询；团队没人熟悉流式框架；交付时间只有两周。

最后我选了方案二的简化版——手写分批游标，不上框架。理由是：在约束条件下，最“土”但团队里三个人都能看懂的方案，优于最优雅但只有一个人能维护的方案。这个判断 AI 给不了，因为它不承担“半年后那个人离职了”的后果。

2.3 结果兜底：AI 最薄弱的那一环

这条我要多说两句，因为它是最容易被忽略、也最能体现价值的地方。AI 生成的代码有个特点：它永远“看起来”是对的。变量名工整、注释齐全、异常处理也写了 try-catch，你扫一眼觉得没问题，就合并了。然后它在某个特定条件下炸了。

我踩过的一个坑：让 AI 写一段“读取配置文件，如果不存在就用默认值”的逻辑。它写得漂漂亮亮，try-except 包着，读不到就返回默认字典。问题是它把“文件不存在”和“文件存在但格式错了”都吞进了同一个 except 里。结果有次运维改配置时手滑多打了个逗号，服务静默降级到默认配置跑了两天，所有人都以为配置生效了。

后来我们定了个规矩：凡是 AI 生成的异常处理，逐行确认它捕获的异常类型是不是精确的。不允许裸 except，不允许把“可恢复错误”和“配置错误”混在一起。这条规矩写进了团队的代码评审清单，比什么“最佳实践”都管用。

兜底还包括另一层意思：上线之后出问题，你得能说得清。AI 生成的代码你如果不完全理解，出事的时候你连从哪儿查都不知道。我的做法是，凡是合并进主干的关键逻辑，我必须能在不看代码的情况下，用嘴把它的数据流讲一遍。讲不出来的，说明我没真正拥有这段代码，那就别合。

2.4 影响范围：哪些角色受冲击最大

我把常见的岗位类型列一下，按我观察到的“被压缩速度”排个序。这个排序不代表谁高谁低，只反映工作内容里“可被清晰描述”的比例。

注意最后一行。我带过一个做供应链对账的同事，他对“什么情况下两笔单子应该算匹配”的理解，到了能跟业务专家掰扯细节的程度。这种人 AI 替代不了，因为那些规则有一半根本没写在文档里，是在无数次对账差异里磨出来的。

3. 能力重构：一份可以照着做的升级清单

前面讲的是“该往哪儿走”，这节讲“怎么走”。我不太喜欢给那种“多读书多思考”的建议，太虚。我给的是四条能落到每周行动上的东西，每条都配了具体的做法和判断标准。

3.1 领域纵深：选一个业务场景扎到能听懂黑话

这是我认为投入产出比最高的一条。选一个你手上有真实数据的业务方向——订单、结算、库存、风控、投放、内容审核，随便哪个——然后用三个月时间，做到能听懂业务方的黑话，能判断他们说的需求合不合理。

具体怎么做？我给三个可执行的动作：

• 每次需求评审，只记“为什么”不记“做什么”。记下业务方为什么要这个功能、不做会怎样、现在他们是怎么手工凑合的。三个月后你会发现，同一个业务痛点会以不同需求的形式反复出现。
• 主动去跟一线使用者聊半小时。不是跟提需求的经理聊，是跟真正用这个系统的人聊。你会听到大量“这个按钮位置不对”“每次都要重复填”这种琐碎抱怨，这些就是问题定义的原材料。
• 把业务规则整理成一张表。什么条件下走哪个分支、哪些是硬规则、哪些是历史遗留的妥协。这张表是你最核心的资产，也是 AI 永远拿不到的东西。

我做对账那阵子，硬是把“什么算差异”整理出了十七种情况：金额差一分以内算舍入误差、时间差超过跨天阈值算跨日单、状态不一致但流水匹配算异步延迟……这些规则没有任何一份文档写全过，全靠一个个差异单磨出来。后来我换团队，这套东西带不走，但“怎么把灰色规则问出来”的方法带走了。

3.2 工程判断：从“能跑”到“能维护、能回滚、能观测”

AI 让“能跑”变得极其廉价，于是“能维护”的相对价值飙升。我在评审 AI 生成代码时，看的不再是语法对不对，而是这四个问题：

1. 出错了能不能一眼看出来？有没有关键路径的日志、有没有可观测的指标。
2. 出错了能不能快速止血？有没有开关、能不能降级、回滚要几步。
3. 半年后的人能不能看懂？不是为了好看，是为了改的时候不炸。
4. 成本可不可控？这段代码会不会在数据量涨十倍时突然变成灾难。

这四个问题的答案，往往决定了同一个功能是“三天上线”还是“上线后三个月天天救火”。我见过太多团队，功能上线速度飞快，然后百分之六十的人力耗在维护上。

注意：给 AI 提需求时，把这四条直接写进提示词里，效果比事后改好得多。比如明确要求“关键分支必须有结构化日志，日志里带上单号”，它就会照做。你不说，它不会主动加。

3.3 与 AI 协作的实操工作流

这块我讲得细一点，因为我发现大部分人用 AI 的方式还停留在“问一句答一句”，效率其实很低。我现在的工作流是四步：先写约束、再要骨架、然后逐块填、最后自己验。

第一步“写约束”是最关键的。我不会说“帮我写个对账功能”，我会这么写：

背景：每天约 200 万条订单流水需要与上游系统比对，输出差异清单。 约束条件： 1. 分页读取，单页 5000 条，不允许一次性加载全量； 2. 数据库连接池上限 8，必须复用连接，不允许循环内新建连接； 3. 每条差异记录需要保留原始流水号和比对时间； 4. 单个分页处理失败不允许整批中断，要记录失败页码继续； 5. 关键步骤打日志，日志格式 JSON，字段包含 batch_no、page、diff_count、cost_ms； 6. 不要引入新的第三方依赖。 输出：先只给函数签名和主流程伪代码，不要给完整实现。

注意最后一句——先只要骨架。这一步的价值在于让我能快速判断它理解得对不对，成本只有几十秒。如果骨架错了，改骨架比改两百行实现便宜得多。很多人跳过了这一步，直接要完整代码，然后在一堆细节里挑错，效率极低。

第二步拿到骨架后，我逐块让它填，一次只要一个函数。每个函数我都会问一句“这个函数的边界条件有哪些”，逼它把异常路径列出来。它列得不全，我再补。这个动作看起来繁琐，但比事后 debug 省时间。

第三步是自己验。这一步绝对不能省。我的习惯是先写三到五个必测场景（正常、空数据、超长、边界值、异常中断），跑一遍再合并。AI 生成的代码在正常路径上几乎不出错，所以测试重点一定放在异常路径上。

第四步是留痕。我会在提交信息里写清楚哪部分是生成的、哪部分是我改的、改的理由是什么。不是为了甩锅，是为了半年后自己看得懂。

3.4 表达与文档：把思考变成别人能接住的东西

这条被严重低估。AI 时代，代码的生产成本趋近于零，但**“让别人理解你要做什么”的成本没有下降，反而上升了**——因为生成的东西多了，需要对齐的东西也多了。

我的做法是写“三句话文档”：任何一件稍大的事，先用三句话写清楚——要解决什么问题、我打算怎么做、怎么算做完了。三句话写不出来的，说明我还没想清楚，别急着让 AI 写代码，先想清楚。

这个习惯帮我省了大量返工。有次我准备给一个报表加缓存，三句话写到第二句就卡住了：“我打算加一层缓存减少查询压力”——减少多少？现在压力多大？加了之后数据延迟能接受吗？写不下去，说明这个方案我根本没想明白，后来一查发现瓶颈根本不在查询，在导出文件生成。差点白干一周。

4. 实操：把一个需求从零推到上线

理论讲完，我拿一个模拟项目完整走一遍，让你看到前面那些方法在真实场景里长什么样。项目背景：某公司内部有一套订单流水系统，每天产生约 200 万条记录，需要跟上游系统做每日对账，输出差异清单供财务核查。原来靠人工导出 Excel 用公式比对，两个人要干一整天，还经常漏。

4.1 需求澄清与约束梳理

我先按 2.1 的方法追问了四个问题，得到的答案是：现在每天两个人从早上九点干到下午五点，最怕的是月底数据量翻倍；他们最痛的不是“比对慢”，是“比对完了不知道哪儿错了，要一行行找”；期望是“早上上班就能看到昨天的差异清单”。

这里有个关键发现：真正的需求不是“快”，是“早上能看到结果 + 差异要能定位”。前者意味着可以离线跑批，不需要实时；后者意味着输出必须带足够的上下文，不能只给个“不一致”的标记。

基于这个，我定了三条验收标准：

1. 每天凌晨自动跑完，早上八点前差异清单可查；
2. 每条差异必须包含：流水号、差异类型、两边原始值、发现时间；
3. 单条记录比对失败不能影响整批。

约束条件梳理出来是这样的：数据源是关系型数据库，共享实例，不允许跑大查询；团队三个人，只能上最简方案，不引入新中间件；部署环境只有一台 4 核 8G 的应用机。

4.2 方案设计与参数计算

方案取舍我列了三个候选，用一张表对比：

选 C。理由写在设计文档里：在共享数据库不允许跑重查询、机器内存有限这两个硬约束下，只有分批方案可行；复杂度的代价换的是可控性，值得。

接下来算参数。这块很多人跳过，但算一遍之后心里会踏实很多：

• 日增量：200 万条，单条平均 400 字节 → 约 800MB 的原始数据。月底峰值按 2.5 倍算，500 万条。
• 单页条数：定 5000。为什么不是 1 万？5000 条 × 400 字节 = 2MB 原始数据，转成对象后约 8 到 10MB，一页在内存里停留时间短，GC 压力小。定 1 万也能跑，但单页失败重试的成本翻倍。
• 批次数：200 万 / 5000 = 400 批。峰值 500 万 / 5000 = 1000 批。
• 单批耗时目标：如果每批 150ms，400 批约 60 秒，1000 批约 150 秒。给数据库的压力是每 150ms 一次查询，连接池 8 个，完全在安全范围。
• 时间窗口：凌晨 1 点到 5 点，四小时。按 150 秒算，余量非常充足，可以再保守一点把单页降到 3000。
• 差异率预估：历史数据看大约 0.3%，200 万条 → 6000 条差异，峰值 1.5 万条。清单表按每天 5 万条容量设计，够用。
• 超时设置：单页查询超时定 30 秒。这个值的依据是正常 P99 在 200ms 以内，30 秒是 150 倍余量，既能容忍偶发慢查询，又不会让单页卡死拖垮整批。

算完之后有个意外收获：估算出来的总耗时远小于时间窗口，说明不需要做并发。这一点很重要，很多人一上来就想着多线程加速，结果引入了并发问题。算一遍就知道没必要。

4.3 编码过程记录：和 AI 怎么配合

我按 3.3 的流程走。第一步只让它出骨架，提示词里把约束全写进去，并且明确“不要给完整实现”。

它给的骨架大体是对的：主流程是“算总页数 → 循环拉取 → 逐条比对 → 收集差异 → 批量写入”。但有两处我要改：一是它建议先 count 总数再算页数，这在 200 万条的表上是一次全表扫描，我改成按主键游标翻页，不依赖总数；二是它的失败处理是“记录日志后抛出”，我要求改成“记录页码后继续”，因为单页失败不该中断整批。

这两处修改就是 2.2 说的“取舍”——AI 给的是通用最优解，我要的是在这套约束下的可行解。

拿到骨架后逐块填。核心比对函数我让它写了两版：第一版用两个字典做键值匹配，简单；第二版加了“金额容差”和“跨日单”的判断。我特意要求它把“什么情况算差异”列成一张显式的判断表，而不是散在 if-else 里。这样做的原因是——这些规则以后一定会变，散在代码里改起来必漏。

# 差异判定规则（示意，非完整实现） DIFF_RULES = [ # (条件函数, 差异类型码, 是否阻断) (lambda a, b: abs(a.amount - b.amount) > 0.01, "AMOUNT_MISMATCH", True), (lambda a, b: a.amount != b.amount, "ROUNDING_DIFF", False), (lambda a, b: a.status != b.status, "STATUS_MISMATCH", True), (lambda a, b: abs(a.ts - b.ts) > 86400, "CROSS_DAY_SUSPECT", False), ]

写成这张表之后，业务方后来要加一条新规则，改一行就完事，不用动主流程。这就是 3.2 说的“能维护”。

日志部分我按提示词里的要求让它输出结构化 JSON，字段固定为 batch_no、page、total、diff_count、cost_ms、error_code。上线后排查问题基本靠这几个字段就能定位到具体哪一批哪一页。

整个过程我一共让它生成了大概 300 行，我自己改了 80 行左右，改动集中在翻页逻辑、失败处理和规则表结构。合并前我写了 6 个测试用例：正常比对、空批次、金额容差边界（差 0.01 和 0.02）、跨日边界（86399 秒和 86401 秒）、单页异常中断、全量差异（极端情况）。

4.4 验证、压测与上线检查

本地跑通不算完。我用历史数据造了一份 200 万条的模拟数据集，在预发环境完整跑了一遍，记录了几个关键指标：

上线前我列了张检查清单，一共七条：任务调度有没有配失败告警、差异清单表有没有建索引（按日期 + 差异类型）、历史数据保留策略定了没有（保留 90 天，定时清理）、跑批期间会不会跟其他任务抢资源（错开到 2 点后）、清单页面有没有分页、异常时有没有兜底通知、回滚方案是什么（关掉调度即可，无数据污染风险）。

最后一条特别重要。这个方案最大的优点是回滚成本为零——它只读不写业务库，输出到独立的清单表，关掉调度就完全停止。这也是选方案时考虑的因素之一：能随时停掉的方案，比需要数据修复的方案安全得多。

上线第一周我每天早上八点看一遍清单，确认条数和人工抽查结果对得上。第三周业务方说“现在九点上班第一件事是看清单，不用再导 Excel 了”，这个需求才算真正交付。

5. 常见误区与排查清单

这节是我踩过的坑和见过的坑，整理成能直接对照查的形式。有些坑我自己掉进去过，有些是看同事掉进去的。

5.1 五类高频误区

误区一：把“会用 AI 工具”当成核心竞争力。这玩意儿三个月就会被拉平，所有人都会用。真正的差距在“问什么”和“信不信它给的答案”。我见过简历上写“熟练使用各类 AI 编程工具”的，面试一问“你怎么判断生成结果能不能用”，答不上来。

误区二：追新框架来对抗焦虑。学一个新框架的安全感很强，但边际收益在快速下降。因为框架的语法和用法恰恰是 AI 最熟的部分，你花三个月学的东西，可能不如把现有系统的数据流画清楚有价值。

误区三：跳过验证直接合并。这条前面说过，但还是最常见。我见过一个团队，AI 生成的代码合并率 90%，评审平均时长 4 分钟。三个月后他们的技术债清单长到没人敢看。

误区四：只优化“写代码”的速度，不优化“等结果”的时间。真实项目里，写代码可能只占 30% 时间，剩下是等评审、等环境、等联调、等上线窗口。把自己的编码速度提了一倍，整体交付时间可能只快了 15%。真正该优化的是流程瓶颈，不是打字速度。

误区五：以为“业务理解”是产品经理的事。这个想法在五年前也许成立，现在不成立了。当实现成本被拉平，理解业务的人和不理解业务的人，产出差距会被放大。因为前者能用同样的工具做出“刚好解决问题”的东西，后者只能做出“看起来像那么回事”的东西。

5.2 问题排查速查表

这张表我不是让你背，是让你在卡住的时候对照一下，往往能想起漏掉的那个维度。特别是第一行和第七行，前者是环境问题，后者是提示词问题，都是“看起来是技术问题，其实是信息问题”。

5.3 一条可执行的学习路径

如果你现在想动手，我给一个三个月的粗排期，按周算：

• 第 1 到 4 周：选定一个业务场景，把它的核心规则整理成一张表。目标是能跟业务方对上话，能指出他们需求里不合理的地方。
• 第 5 到 8 周：把这个场景里的一个真实痛点，从需求澄清到上线完整做一遍。重点不是写多少代码，是走完“定问题 → 定方案 → 算参数 → 验证 → 上线 → 观察”的闭环。
• 第 9 到 12 周：复盘。把这次做的决策记下来：当时为什么选这个方案、放弃了什么、如果重来会怎么改。这份复盘比任何教程都有价值，因为它是你自己的判断记录。

我不建议把时间花在“学更多语言”上。语言是最容易被替代的一层，你现在多学一门，明年可能只是多一个 AI 更熟的领域而已。

6. 一点个人体会

我这两年最大的转变，不是学会了用哪些工具，而是评价自己工作的标准变了。以前我看今天写了多少行、关了几个工单；现在我看今天做了几个判断、这些判断有没有被验证是对的。前者是消耗，后者是积累。

还有个具体的小习惯，我觉得挺有用：每次准备让 AI 干活之前，先花两分钟用中文把要做的事写成三句话——解决什么问题、打算怎么做、怎么算做完。写不出来就别开始。这两分钟经常帮我省掉半天返工，因为它逼我在动手之前把问题想清楚，而不是指望在写的过程中想清楚。

最后一个观察：那些在 AI 冲击下最不慌的人，往往不是技术最强的，而是最清楚自己解决的问题值多少钱的人。他们知道自己的时间花在哪儿有杠杆，也知道哪些活看着热闹其实没价值。这种清醒，工具给不了，只能自己练。