现象背后的度量缺口
硅谷在2024到2025年间出现了规模罕见的裁员潮，累计涉及四十万人量级。有意思的是，被裁人群里相当一部分并不是抗拒新工具的人，恰恰是AI编码工具的重度使用者。舆论习惯把这件事解释成机器换人，但从工程管理视角看，真正发生的事情是另一件更冷静的事：组织的人效核算口径变了，而多数团队还没建立起能证明增量价值的新口径。
传统人效指标就那么几个，人均营收、人均交付故事点、人均合并请求数、人均缺陷修复数。这些指标在人力成本占比稳定的年代足够用，因为它们假设产出与人数近似线性。AI工具打破的正是这个假设。当一个人的产出可以借助工具放大，分母不变而分子膨胀，旧指标立刻失去可比性，管理者面对一堆上涨的数字却无法判断这些数字对应的是真实交付还是统计噪声。
失真来自三个方向。第一是产出计数膨胀，工具让提交更容易生成，提交数量与解决的实际问题数量脱钩。第二是质量成本外移，缺陷不再在编码阶段暴露，而是推迟到集成与线上，成本被记在了别的团队账上。第三是协调成本未计入，代码写得快意味着评审、测试、发布环节的排队更长，这部分等待从来不出现在任何个人指标里。
这三个方向叠加的结果很讽刺。一个团队用了最好的工具，个体感受是明显的效率提升，但组织看到的交付周期没有同比例缩短，缺陷率甚至上升。在这种数据面前，管理层最容易得出的结论不是工具没用，而是人多余。这就是为什么擅长用AI的人反而进入名单，不是因为他们效率低，而是因为组织无法把他们创造的增量从整体噪声里分离出来。
AI编码工具的收益计量方法
要把这件事说清楚，先得有能落地的计量方法。收益计量必须分三层做，缺一层都会得出错误结论。编辑器层看建议质量，会话层看任务完成度，仓库层看真实交付变化。三层的数据采集点不同，口径也必须分开定义，混在一起算平均值是最常见的错误。
编辑器层的核心指标是建议采纳率与采纳后留存率。采纳率单独看没有意义，因为一个总在补全括号的工具也能拿到很高的采纳率。真正有信息量的是采纳后留存，也就是被接受的建议在提交前没有被删除或重写的比例。经验上采纳率在四成而留存率不足五成的团队，说明工具在生成大量看似合理但实际不可用的片段，这种状态下的提效是负的，因为开发者要花时间阅读再丢弃。
会话层的指标是任务级完成时长与轮次。一个任务从描述到可用代码，需要几轮交互，每轮之间人工修改的比例是多少。这层最能反映提示与上下文的组织水平。同一个模型，在文档齐全的仓库里可能三轮就出可用结果，在文档缺失的仓库里十轮还在猜表结构。把这两个团队的数字放在一起比较，得到的结论只会误导人。
仓库层的指标才是给管理层看的，包括合并请求的平均规模、从提交到合并的时长、合并后三十天内的改动率。做前后对照时有一个必须遵守的原则，就是控制任务复杂度分布。让同一个团队在三个月里自然前后对比，几乎一定会把季节性业务高峰误判成工具收益。靠谱的做法是从历史工单里抽样，按复杂度分层，同一批类型的任务在新旧流程下各跑一遍，样本量不少于五十个任务，才能把噪声压到可以讨论的范围。
下面是一段度量埋点的伪代码结构，只描述字段，不涉及具体实现。
event_code_completion
repo_id
user_id
suggestion_length
accepted_flag
accepted_then_deleted_flag
time_to_accept_ms
event_task_session
task_id
turns_count
manual_edit_ratio
task_done_flag
elapsed_seconds
event_pull_request
pr_id
files_changed
lines_added
lines_deleted
review_wait_minutes
merged_flag
churn_within_30d字段设计上有一个容易忽略的点，就是必须记录人工编辑比例。这个字段是判断工具输出可用性的关键，它比任何满意度问卷都可靠。另一个点是必须给每条记录打上仓库标识，否则跨仓库聚合会把基础设施代码与业务代码混在一起，两类代码对工具的敏感度差了一个量级。
采集本身也是有成本的。埋点要落在编辑器插件与代码托管平台两侧，两侧的用户标识需要做映射，映射表不准会造成采纳率虚高。建议先用两周做口径校准，让同一条提交在两侧都能对上，再开始正式统计。跳过校准直接出报表，几乎一定会得到一个漂亮但无法解释的数字。
还有一个绕不开的约束是隐私。记录到人粒度的使用数据容易演变成监控，团队一旦感觉被监视，行为会立刻变形，比如刻意不接受建议以保持指标好看。可行的折中是个人数据只对本人可见，管理层只看团队聚合，聚合口径下人少于五人的小组不单独出数。这个规则要在采集之前就公布，事后补说明效果很差。
个体提效与组织提效的落差机制
几乎所有团队都观察到同一个落差，个体自评提效三成到四成，组织端测出来只有百分之几。这个落差不是测量误差，而是系统结构的必然结果。可以用一个简单的模型解释，交付周期由若干环节串联组成，编码只是其中一段，整条链的提速幅度受限于最长的那一段。
假设一个需求从提出到上线平均二十天，其中编码五天，评审三天，测试环境等待四天，回归测试三天，发布审批与灰度五天。编码占比四分之一。如果AI工具让编码提速四成，编码从五天降到三天，总周期从二十天降到十八天，缩短百分之十。这个数字与很多团队实测的组织端提效非常接近。它说明的是同一件事，只优化编码环节的边际收益天然有限。
更麻烦的是，编码段被压缩之后，原来被编码时间掩盖的问题会暴露出来。评审排队变长，测试环境争抢加剧，发布窗口不够用。这些环节在编码慢的年代处于半饥饿状态，编码一快就立刻饱和。于是团队会看到一个反直觉的现象，工具用得越狠，工程师主观上越累，因为他们的节奏被上游加快了，但下游没有同步扩容。
这个模型还有一个推论值得记住。当编码占比降到很低时，继续提升编码速度对总周期几乎没有影响，此时投在编码工具上的钱应该转向瓶颈环节。判断瓶颈在哪不需要复杂分析，看每个环节的排队长度与等待时间占比就够了。多数团队的真实瓶颈在测试环境准备与评审，而不在写代码。
瓶颈转移与协调成本上升
瓶颈转移最先出现在评审环节。编码速度提升之后，合并请求的产生速率上升，而评审者的数量没有变。评审者的处理能力受限于上下文切换成本，一个评审者同时处理五个请求，每个请求都需要重新建立对代码上下文的理解，实际有效评审时间会被压缩到很低。
评审队列变长之后，团队通常会采取两个动作，一个是放宽评审标准，一个是让作者自己找人快速过一遍。这两个动作都会降低评审的实际拦截率。评审从质量关卡退化成流程签章，缺陷就这样流到了下游。这个过程没有明显的告警，因为评审数量指标看起来非常健康，甚至更好看了。
规模也是一个问题。AI生成的改动往往集中在少数几个文件但改动量大，一个请求动辄上千行。评审者对超过四百行的改动，注意力会急剧下降，实际只看了开头和结尾。有团队做过统计，改动超过八百行的请求，评审意见密度不到小改动的一半，而缺陷密度是大改动的两倍以上。这个数据足以支持一条硬规则，超过阈值必须拆分。
可落地的参数大致是这样。单个请求改动行数上限设为四百行，超过则需要说明理由并在评审记录里标注。评审响应时间目标设为四小时，超过八小时自动升级到备选评审人。同一模块的在途请求数上限设为三，超过则排队。评审人同时负责的在途请求不超过两个。这些数字不是绝对标准，但每一条都能对应一个具体的失效模式，比笼统要求提高评审质量有效得多。
协调成本还会以另一种形式出现，就是沟通轮次。当代码不再由一个人从头写到尾，而是由工具生成再由人修改，代码的意图就变得模糊。后续维护者要理解一段逻辑，需要问作者当时想解决什么，而作者可能已经记不清，因为那段代码他只花了十分钟审阅。这种意图丢失在短期看不出来，六个月后会以改动风险的形式集中爆发。
返工率与质量成本的隐藏项
质量成本必须单独计量，否则所有提效结论都不成立。核心指标有四个，三十天内改动率、缺陷逃逸率、回滚率、平均修复时长。三十天内改动率指合并后一个月内被再次修改的代码行占比，这个指标最能反映首次提交的完成度。经验上健康的团队在百分之十到十五，超过二十五说明大量提交是半成品。
缺陷逃逸率指上线后发现的缺陷占全部缺陷的比例。AI工具普及之后这个指标普遍上升，原因不是工具本身差，而是测试环节没有同步升级。AI生成的实现与AI生成的测试往往同源，测试断言基于实现细节而不是需求边界，结果是实现有偏差时测试依然全绿。这种假绿比没有测试更危险，因为它消耗了团队的信心。
典型的AI生成缺陷有几类固定模式。边界条件缺失，比如空集合、超长字符串、并发重入这些情况没有处理。错误处理空壳，捕获异常后只打日志不改变状态，导致失败被吞掉。依赖版本幻觉，引用了不存在的API或参数。可观测缺失，新增逻辑没有埋点也没有关键日志，出问题只能靠猜。事务边界错误，把多个写操作放在非事务上下文里。这几类缺陷的共同点是编译器与静态检查都拦不住，只能靠有针对性的评审清单。
成本折算能让讨论回到同一把尺子上。一个线上缺陷的完整成本包括发现、定位、修复、回归、沟通、信誉损失，中型团队的经验值在十到二十人日之间。如果一个月新增五个逃逸缺陷，相当于吃掉了一个人的整月产能。这时候再看工具带来的编码提效，账就不那么好看了。真正划算的做法是把一部分提效收益主动投到测试与可观测建设上，换取返工率下降。
工程上还有一层防线是开关与灰度。工具生成的逻辑默认走新路径时，必须包在功能开关里，开关要有明确的默认值、生效范围与回滚动作。开关不是万能药，它本身会带来配置组合爆炸，所以要有配套的清理机制，上线稳定两周后删除旧分支，避免代码里长期并存两套逻辑。经验上开关的作用不是防止出错，而是把出错的代价从整体回滚压到局部关闭，这个差别在高峰期非常关键。
与之配套的是可观测。新增分支必须至少有指标、日志、链路三件套里的两件，指标要能区分新旧路径，否则灰度期无法判断哪条路径出的问题。这条要求写进评审清单后，逃逸缺陷的平均定位时间通常能降一半，因为排查不再依赖猜测与复现。
能力门槛下移带来的岗位结构变化
工具最直接的作用是降低能力门槛。过去写一个带重试与超时控制的客户端调用，需要几年经验才能处理好细节，现在工具可以给出接近可用的骨架。这意味着初级工程师的产出下限被显著抬高，中级工程师在样板代码这一维度上不再有优势。
岗位结构随之变化。原来金字塔中段最厚，也就是大量承担执行型任务的中级工程师。当执行型任务的边际成本被工具压低，这个层级的数量需求就下降。两端反而保留，一端是需要快速响应的初级岗位，成本低且愿意做琐碎工作，另一端是能定义问题、做架构权衡、承担故障责任的高级岗位。中间被抽空，这正是裁员名单看起来很奇怪的原因。
这个变化解释了一个困惑。为什么AI用得很好的人也在名单里。因为当一种能力被工具吸收成默认能力，它就不再是稀缺能力。会用工具写代码在2023年是加分项，在2025年接近岗位基本要求。组织付薪水买的是稀缺性，不是熟练度。熟练使用工具的人如果没有把熟练度转化为判断力与责任承担，他的可替代性反而比过去更高，因为工具让接替他的人上手更快。
招聘与面试的评估方式也必须跟着改。过去面试靠让候选人手写一段算法，考察的是编码熟练度，现在这个信号几乎失效，因为工具能在几秒内写出同等质量的实现。有效的考察点变成了三个，给一段有隐含缺陷的设计让候选人找问题，给一个模糊需求让候选人问出关键约束，给一次线上故障的日志片段让候选人给出排查顺序。这三类问题的共同点是答案不在公开语料里，工具无法直接生成，能反映真实的判断力。
内部晋升与绩效评估同样受影响。以产出数量为主要依据的评级体系会迅速失衡，因为数量可以被工具放大，而责任承担无法被放大。可行的调整是把评级重心前移到问题选择与结果负责，看这个人选择解决什么问题，选择不做什么，出问题时是解释还是解决。这类评价主观性更强，需要用多来源交叉验证来压住偏差，但总比用一个已经被工具污染的数量指标要好。
对个体而言，这个判断有实际指导意义。把时间投在工具技巧上的回报正在快速下降，因为工具每半年就换一代，技巧会过期。把时间投在系统边界判断、失败模式识别、验收标准设计上的回报在上升，因为这些能力依赖对具体业务与具体系统的理解，工具无法替代，也难以速成。这个结论听起来像鸡汤，但它有明确的检验方式，就是看你做的事情在换一个模型之后是否还成立。
交付链路的可自动化边界
不是所有环节都值得投自动化，判断标准可以归结为三条。输入能否完全形式化，反馈能否在秒级获得，错误代价是否可回滚。三条都满足的环节，自动化的收益最确定。任意一条不满足，收益就会大打折扣甚至为负。
按这三条看，样板代码生成、单测补全、批量迁移脚本、文档与注释同步、依赖版本升级、格式与静态检查修复，这些属于高可自动化区。它们的共同点是输入明确，错误可以立刻发现，最坏情况是提交被拒。团队在这些环节上的投入回报比最高，而且风险可控。
架构决策、故障根因定位、跨系统权衡、需求澄清、性能瓶颈判断，这些属于低可自动化区。它们的输入包含大量隐含信息，反馈周期以天计，错误代价可能是数据不一致或长时间不可用。在这些环节上让工具给建议是可以的，让工具做决定是危险的。这个界限一旦模糊，团队就会陷入反复返工的循环。
一个常见的误判是把调试当成高可自动化环节。工具读日志给出假设很快，但假设的验证要靠人去构造复现条件。很多团队在调试环节投入大量工具能力，结果发现定位时间没降，反而因为错误假设增多，走了更多弯路。判断方法很简单，看这个环节的单次尝试成本，如果每次验证都要几分钟以上，自动化的迭代速度就撑不起来。
人效度量体系的指标设计
度量体系要能同时回答两个问题，交付有没有变快，交付有没有变差。只回答一个的体系一定会被优化到失真。建议按四层设计，交付吞吐、交付质量、系统稳定性、能力沉淀，每层两到三个指标，总数控制在十二个以内。
交付吞吐层用需求前置时间与合并请求吞吐。前置时间从需求进入开发队列算起，到上线可观测为止，这个口径比编码时长更能反映真实体验。合并请求吞吐看每周合并数，但要与平均规模一起看，否则会鼓励拆小刷量。
交付质量层用缺陷逃逸率与三十天改动率。这两个指标互补，一个看漏出去的，一个看进来的。再加一个测试有效性指标，也就是测试能在多大比例上捕获人为注入的缺陷，这个指标可以直接测，做法是在预发环境注入已知缺陷看测试是否报警。
系统稳定性层用可用性、平均恢复时长、变更失败率。变更失败率是判断交付流程健康度的好指标，它把问题归因到变更而不是人。能力沉淀层用上下文完备度与交接周期。上下文完备度可以用抽样评估，随机抽十个模块，看新人能否在不问人的情况下完成一次小改动。交接周期指接手模块到能独立改动所需天数，这个数字在裁员期特别有参考价值。
度量体系必须配反指标，否则一定被博弈。代码行数会诱发冗长，提交数会诱发拆分，评审数量会诱发走过场。反指标的用法是成对出现，提交数与平均改动规模一起看，评审数量与评审意见密度一起看，工具采纳率与采纳后留存率一起看。任何单项指标上升而配对的指标恶化，都应该视为无效改进。
上下文工程作为组织资产
工具输出质量的上限由上下文决定，这件事在工程上已经被反复验证。同一个模型，在文档齐全的仓库里能直接给出可用实现，在文档缺失的仓库里只能给出通用套路。差别不在模型，在于模型能否知道这个仓库的约定。
上下文工程的产出物包括几类。仓库级规则文件，写明分层约束、命名约定、依赖使用规范、禁止的写法。架构决策记录，说明关键选择的背景与被否决的方案，这类文档对工具特别有用，因为它能防止工具推荐已经被否掉的做法。领域术语表，把业务黑话与代码实体的对应关系固定下来。故障复盘库，记录历史故障的触发条件与修复手法。代码示例集，给出符合本仓库风格的正例与反例。
这些资产的维护成本不低，而且必须指定所有者。没有所有者的文档三个月就会过期。可行的做法是把它纳入变更流程，任何影响接口或分层的改动，必须同时更新对应上下文文件，否则评审不通过。这个约束听起来重，但它替代的是更贵的口头传承。
过期上下文比没有上下文更有害。团队会发现工具开始给出违反现行规范的实现，而新人无法分辨这是规范变了还是工具错了。防范手段是给每条规则加生效日期与来源人，评审时只信最近半年内更新过的条目，超期条目降级为参考。这条规则让上下文保持可维护，也让人知道该找谁确认。
上下文文件的结构建议用扁平的键值形式，便于工具读取也便于人工维护。下面是一个示意结构。
repo_rule_layer
controller_must_not_access_database true
all_external_calls_need_timeout true
timeout_default_ms 3000
retry_max_attempts 2
forbidden_pattern select_all_without_limit
naming_rule
service_suffix Service
repository_suffix Repository
event_suffix Event
decision_record
id 0042
topic message_queue_choice
chosen kafka
rejected rabbitmq
reason ordering_and_replay一个实测经验是，上下文完备之后，同一批任务的首次可用率能从三成提升到六成，人工修改比例从七成降到四成。这个提升幅度远大于换模型带来的差异，所以在预算有限时，优先投上下文而不是追新模型。
评测集与回归门禁的建设
工具链的任何变更都需要回归验证，否则无法判断是变好还是变坏。评测集的构建方法是从历史工单里抽样，把任务描述与验收标准整理成可重复执行的用例。样本量不少于一百条，按难度分四档，简单、中等、复杂、跨模块，每档二十五条左右。
每条用例需要三个要素，任务描述、初始仓库状态、验收判据。验收判据尽量用可执行的形式，比如指定测试通过、指定接口返回结构正确、指定性能阈值满足。无法自动判定的用例也要保留，用人工打分，但要固定评分人，否则分数不可比。
门禁的触发条件包括模型版本变更、提示词模板变更、上下文规则变更、工具插件变更。每次触发跑全量评测集，比对通过率、人工修改比例、生成代码的静态检查违规数。任何一项相对基线退化超过五个百分点，就阻止上线。这个阈值不是拍脑袋，五个点大约对应返工率上升一个点，是团队还能承受的范围。
评测集有一个必须防范的风险，就是泄漏。如果用例被无意间放进仓库的示例目录，后续模型可能通过检索直接命中答案，评测结果虚高。防护做法是把评测集放在独立仓库，不进入日常检索范围，同时定期换题，每季度替换三成用例。
评测集的另一项价值是让争论变成数据。团队内部对某个工具或某种提示写法的好坏常有分歧，跑一遍评测集就能收敛。这项投入通常只要两三个人日，比开三次会争论划算得多。维护上要指定一名负责人，每季度复核一次用例是否还代表真实分布，业务形态变化后旧用例会迅速失效。
知识断层与交接成本
裁员叠加AI生成代码，会产生一种新的组织病，就是代码所有权模糊。一段逻辑是谁写的，为什么这么写，改动会影响谁，这些问题在人员流动之后变得难以回答。工具生成的代码尤其如此，因为它没有作者在写的过程中形成的心理模型。
表现是具体的。接手人打开一个模块，发现有三套风格并存，注释与实际行为不符，异常处理层层包裹但没人知道哪层生效。想改动一个参数，需要先做三天的影响面排查。这种模块在团队里会被贴上不要碰的标签，逐渐变成技术债的黑洞。
缓解手段不复杂，但需要强制执行。变更说明必须写清动机与影响面，不能只写修复问题。关键决策必须有记录，记录里要包含被否决的方案。AI参与生成的代码在提交信息里标注，标注的目的不是追责，而是提示后续维护者这段逻辑可能缺少人工推演。模块负责人制要落到人，一个模块一个负责人，负责人离职必须完成交接验收。
交接成本可以量化，用接手到能独立改动的天数衡量。健康值在两到三周，超过六周说明知识没有沉淀在仓库里而是沉淀在人脑里。这个指标在裁员期应当被当作风险指标盯住，因为它会滞后暴露，等发现时往往已经影响了交付。
三个典型失败场景复盘
第一个场景是全量放开。某团队一次性给所有人开通AI补全，三个月后发现缺陷率上升三成，回滚次数翻倍。排查根因有两个，一是测试与实现同源导致假绿，二是评审因为请求量激增而走过场。修正动作是引入测试有效性检查，同时设定请求规模上限与评审响应目标。两个月后缺陷率回到基线，合并请求吞吐保持在提升后的水平。这个案例的教训是放开速度必须与门禁建设同步。
第二个场景是考核错位。某团队把合并请求数纳入个人考核，结果两周内请求数上涨六成，交付需求数没变。拆分明细显示大量请求是把一个改动拆成三到四个小提交，每个都能独立合并但合起来才构成一个完整功能。修正动作是把考核改成前置时间与缺陷逃逸率的组合，请求数只作为观察指标。指标调整后请求数回落，前置时间下降了百分之十二。
第三个场景是结构失衡。某团队裁掉了大部分中级执行岗位，保留高级工程师与少量初级。短期成本下降明显，但三个月后交付周期反而变长。原因是高级工程师的时间被评审、救火、跨团队对齐占满，实际写代码的时间不到三成，而初级工程师缺少能带他们做判断的人，产出质量不稳定。修正动作是恢复部分中级岗位，并把评审职责显式分配给固定的几个人，而不是所有人轮流。这个案例说明人效不是简单的人数除法，中间层的协调价值在纸面上看不见，去掉之后才显形。
团队层面的落地步骤
落地节奏建议八到十二周，分六步，每步都有明确产出物与验收标准，不要跳步。跳步的典型后果是数据不可比，最后谁也说不清改进来自哪里。
第一步基线测量，收集四周的交付数据，包括前置时间分布、请求规模分布、缺陷逃逸率、三十天改动率。产出物是一页基线报告，验收标准是数据口径写清楚且可复算。
第二步场景筛选，按前面三条判据把团队的工作拆成高可自动化与低可自动化两类，选出三个高价值场景试点。产出物是场景清单与预期收益估算。
第三步试点，选一个五人左右的小组，跑四周。产出物是试点组的对比数据与失败案例记录。验收标准是对比组与试点组的任务复杂度分布一致。
第四步门禁建设，把评测集、测试有效性检查、请求规模上限、评审响应目标这四件事落地。这一步最容易被跳过，也最不该跳过。
第五步扩面，按小组逐批推开，每批之间留两周观察期。扩面期间保持度量口径不变，只增加样本。
第六步复盘，做归因分析，把收益拆成工具贡献、流程贡献、上下文贡献三部分。产出物是下一季度的投入建议，明确钱该花在编码工具还是瓶颈环节。
个体能力建设与常见误区
个体层面的能力建设有明确的优先级。第一位是问题定义，能把模糊需求拆成可验收的边界，这件事工具做不了，因为它不知道业务方的真实约束。第二位是验收标准设计，能写出既不过严也不过松的判据，这直接决定工具输出能不能被有效筛选。第三位是系统边界判断，知道一个改动会影响哪些下游，这需要在具体系统里泡够时间。第四位是失败模式识别，看到一段代码能立刻想到它在什么情况下会坏。第五位是上下文组织，能把自己的领域知识整理成别人和工具都能用的形式。
这五项能力的共同点是都需要在真实系统里积累，且都有明确的检验方式。判断自己有没有问题定义能力，看接手一个模糊需求时能不能在两小时内列出验收清单。判断有没有失败模式识别能力，看别人给你看一段陌生代码，你能不能说出三个可能的失效场景。
误区清单值得单独列出来，因为它们出现的频率太高。把会用工具当成核心竞争力，这是最普遍的一个，工具每半年换一代，技巧的保鲜期很短。把速度当成产出，快但不解决问题的代码是负资产。把采纳率当成质量，采纳率只反映建议被接受的比例，不反映建议是否正确。忽视可观测建设，工具生成的分支往往没有埋点，出问题时无法定位。忽视回滚设计，新逻辑没有开关，出事只能整体回退。以量代质，用提交数、行数、请求数证明价值，这些数字最容易被工具放大，也最容易被识破。
回到最初那个现象。四十万人的调整里，真正被工具替代的是执行环节的熟练度，而执行环节的熟练度从来不是组织付高薪的理由。组织付薪水买的是判断、责任与对具体系统的理解。AI把这些能力的产出成本压低了，同时也把没有这些能力的人的稀缺性抹平了。这个结论对个体不算友好，但它是可以被验证的，验证方式就是看自己在换一个模型之后，还剩下什么是不可替代的。