Code is cheap, show me the prompt.
Code is cheap, show me the prompt
"Talk is cheap, show me the code." — Linus Torvalds, 2000
2026 年了，这句话该翻篇了。
先讲个事儿
2024 年，一个朋友的团队用 AI 辅助开发一个内部管理系统。三个人，两周，从零到上线——换成以前，这种体量的项目少说也要六七个人干两三个月。
项目上线那天，CTO 很开心，开发很兴奋，所有人都觉得找到了银弹。
三个月后，他们开始后悔。
不是因为系统不能用——能用，跑得好好的。问题在于：每次改需求，哪怕是很小的改动，都像在地雷阵里走路。一个接口改了，另一个模块莫名其妙报错；一个字段加了，三处报表的数据就不对了。到最后，没人敢说自己"完全理解"这个系统的数据流向——包括当初写它的人。
原因是什么？AI 写的每一行代码，单独拿出来看，质量都不差。命名规范，逻辑清晰，边界条件也处理了。但把这些代码放到一起看，就像十个装修工人分别装修了同一套房的十个房间——风格不统一，走线不对接，承重墙的位置没人对齐过。
这就是当下 AI 编程最真实的困境：局部极其优秀，全局稀烂。
而这篇要聊的，不是"AI 行不行"这种无聊的问题。是另一个更有意思的：
当"写代码"变得前所未有的廉价，什么才是真贵的东西？
一、AI 带来的变革：砖不要钱了，但你还是盖不起楼
1.1 以前值钱的东西，现在不值钱了
历史上的生产力革命，干掉的都是某个环节的高成本。印刷术干掉了抄书，流水线干掉了手工组装，Excel 干掉了会计扒拉算盘。
AI 干掉的是什么？是把想法变成可运行代码这件事的成本。
感受一下：过去你拿到一个需求，要想方案、选技术栈、写代码、调 bug、做测试。其中"写代码"这个环节，占了整个项目 60% 以上的时间和精力。现在 AI 能帮你把"写代码"这个环节压缩到原来的十分之一甚至百分之一。
但请注意——AI 降低的是"执行方案"的成本，不是"想清楚方案"的成本。
你仍然需要知道系统该怎么拆分、模块边界划在哪、数据流怎么走、这个接口应该返回什么。区别在于，过去你花三天想清楚方案、再花两周写代码；现在你花三天想清楚方案、再花三个小时让 AI 把代码生成出来。
这就引出一个根本性的变化："写代码"从目的变成了手段。
以前说一个人"技术好"，很大程度上是指"代码写得漂亮、写得快"。以后说一个人"技术好"，得是指"他知道该写什么、不该写什么"。
就像搬砖，以前砖头是稀缺资源，你能搞到砖就能盖房。现在砖头不要钱了随便搬，问题变成了：你会不会画图纸？你知不知道房子该盖几层？承重墙在哪？地基打多深？
1.2 "能跑"和"能信"之间隔着十万八千里
AI 生成的代码有一个非常危险的特征：它看起来永远是对的。
命名规范、结构清晰、该有的注释都有、测试用例也能通过。你拿给一个 junior 看，他会觉得"这代码写得比我好"。你拿给一个 senior 看，他可能会皱眉头说"这里有点不对劲，但具体哪不对，我要想想"。
这个"想想"就是核心。
举个例子：AI 生成了一个重试逻辑——请求失败后重试三次，每次间隔一秒。代码没毛病，跑起来也没问题。但一个有经验的人会追问：这个接口是幂等的吗？如果不是，重试三次意味着可能创建三个重复的订单。重试间隔一秒，在高并发下会不会把下游服务打挂？这个重试是同步阻塞的还是异步的？如果是同步的，调用方的超时设置够不够？
这些问题，AI 不会主动想。它只会按照"常见的做法"生成一个"看起来合理"的实现。 而"常见的做法"和"正确的做法"之间的差距，就是经验和判断力。
所以我说——AI 把"能跑"的成本打到了地板上，但把"能信"的价值抬到了天花板上。
1.3 审查速度跟不上生成速度，你就失控了
这是一个很少有人讨论但极其重要的问题：
AI 一秒钟能生成 200 行代码，你一秒钟能审查多少行？如果审查速度跟不上生成速度，结果就是——你的代码库在膨胀，你对它的掌控在收缩。
代码越来越多，但理解它的人越来越少。每一个 AI 生成的模块都是一个"我大概知道它干什么，但细节不太确定"的黑箱。等到有一天需要改一个核心逻辑的时候，你打开代码一看——3000 行，都是 AI 写的，没有任何一个人从头到尾读过一遍。
这就是新的技术债形式：不是代码写得烂，而是代码写得太快太多，快到没人来得及理解它。
以前的技术债是"为了赶工写了烂代码"。以后的技术债是"为了赶工生成了太多没人审查的代码"。病因不同，症状一样——系统变得不可维护。
二、对行业的影响：价值链在重组，值钱的东西搬家了
2.1 编码环节被挤扁，上游环节被顶上来
传统的软件开发价值链，大致是这样的：
需求 → 设计 → 编码 → 测试 → 部署 → 运维
每个环节都有对应的角色和成本。编码，是过去几十年里人力最密集、成本最集中的环节。一个项目预算的六七成花在"把设计稿变成代码"上。
现在这个环节被 AI 挤扁了。成本骤降，人力需求骤减。但需求、设计、测试、运维这些环节——它们的难度和重要性不但没有降低，反而被凸显出来了。
打个比方：你开了一家饭店，以前请了 20 个厨师炒菜（编码），3 个采购员买菜（需求），2 个经理管后厨（设计）。有一天你引进了炒菜机器人，20 个厨师的活 2 个就能干了。你开心吗？开心。但现在问题来了——采购员买错菜了，机器人照炒不误，速度快、量大、看起来专业，但做出来的菜方向就错了。以前买错菜，厨师会说"老板，这鱼不新鲜"，现在机器人不会说话，它只会高效地把不新鲜的鱼做成一盘精美的菜。
速度不等于方向对。AI 是一台极其高效的发动机，但它不知道该往哪开。方向盘仍然在人手里。
2.2 "全栈"这个词该重新定义了
以前说全栈，意思是"前端也会、后端也会、数据库也会、部署也会"。这个定义的基础假设是：各个技术栈之间有明确的壁垒，全栈意味着你能跨过这些壁垒。
AI 时代，这些壁垒正在消融——因为 AI 能帮你补任何技术栈的短板。你不懂 K8s？问 AI。你不会写 SQL 优化？问 AI。React 和 Vue 都没用过？AI 帮你各生成一版。
以后真正的"全栈"不再是"什么技术都会"，而是"能跨域"——在业务和技术之间自由翻译，在模糊和精确之间架桥。
这种人的核心能力是：
- 听到"用户体验不好"，能把它拆解成"列表页加载超过 3 秒且没有骨架屏和 loading 状态"
- 知道一个"简单的需求"背后隐藏着多少架构影响
- 能判断"AI 生成的这段代码在当前场景没问题，但如果明年业务扩展到海外就不行了"
AI 时代的全栈 = 理解问题的人，不是实现方案的人。 因为实现方案 AI 比你快一百倍。
2.3 新工种在冒出来，旧工种在变形
Prompt Engineer 是第一个被命名的新工种，但说实话这个名字太小了——它把一个本质上是"任务分解 + 约束定义 + 质量把控"的工作，降级成了"会写提示词"。
一个真正有价值的 prompt 工程师，应该做的事情是：
- 把模糊的业务需求拆解成 AI 能理解的子任务
- 为每个子任务定义清晰的约束和验收标准
- 审查 AI 输出，判断哪些能用、哪些需要改、哪些方向就错了
- 把成功的模式沉淀下来，变成可复用的模板
这跟"写提示词"的关系，就像"架构设计"跟"写代码"的关系——前者是思考，后者只是执行。
另一个正在成型的角色是 AI Output Auditor——专门审查 AI 生成的代码和方案。这个角色的门槛不是"比 AI 更会写代码"，而是"比 AI 更理解什么代码不该存在"。
往远了说，我相信会出现一类全新的角色：AI Workflow Architect，专门设计人和 AI 的协作流程——哪些环节让 AI 做主、哪些环节必须人类审查、错误信号怎么传递、知识怎么沉淀。这跟传统的项目管理不同，因为它需要对 AI 的能力边界有骨感的认知。
三、对企业管理模式的影响：你在管理一群"能力超强但毫无判断力"的员工
3.1 管理的核心变量变了
传统软件团队管理，管三件事：人、时间、代码质量。
"人"是最难的——因为人有情绪、有差异、有成长曲线、有办公室政治。管理者大量时间花在协调不同能力水平的成员、处理沟通摩擦、做绩效评估上。
AI 没消灭这些问题，但它往中间插了一个新变量：你的团队里多了一批"能力极强但毫无判断力"的新成员。 它们不累、不闹情绪、不请假、产出速度惊人——但它们会在你没注意的角落埋雷。
这就引出一个管理上前所未有的问题：你不再只是管理人做出来的东西，你还在管理机器做出来的东西。 而机器做出来的东西有一个危险的特性——它太完美了，完美到让人放松警惕。
想象一下你团队里新来了一个人，能力超强，什么活交给他都能秒级完成，代码质量看起来无可挑剔。你是不是会减少审查？是不是会把更多活堆给他？是不是会觉得"终于来了个靠谱的"？
三个月后你打开他写的代码一看——发现整个系统的架构已经被他用一种你没想到的方式"优化"了，所有模块之间多了一层你没授权的抽象，某些核心逻辑被他"重构"成了另一种风格。他不是故意的，他只是按他理解的"最优解"在做。但结果是，你的系统已经不是你原来理解的那个系统了。
这就是 AI 管理的核心挑战：你不能用管人的逻辑管 AI，也不能用信任人的逻辑信任 AI。
3.2 Code Review 从"好的实践"变成了"生存必需"
在 AI 之前，Code Review 在很多团队里是走形式——PR 太多，reviewer 点一下 approve 就完事了。它的主要价值是教育性的：帮助 junior 成长、知识共享、偶尔发现 bug。
AI 之后，Code Review 的性质变了。它不再是"锦上添花"，而是"最后一道防线"。
原因很简单：AI 生成代码的速度意味着你的代码库正在以过去 3-5 倍的速度膨胀。如果审查跟不上膨胀，你的系统就会变成一个你自以为了解、但实际上充满了你没见过的决策的黑箱。
但问题是——谁来审查？
如果审查的人能力不够，AI 生成的代码和人工写的代码对他来说没有区别——反正都看不懂，反正都 approve。审查仍然是形式化的，只是以前是形式化地审查人写的代码，现在是形式化地审查机器写的代码。
AI 时代，最需要投资的不是 AI 的能力，而是人类审查者的能力。 这是大多数企业管理者还没意识到的事。他们花大价钱买 AI 工具，却不愿意花时间培养团队的审查能力。就像买了一辆法拉利，却不愿意花钱学开车。
3.3 经验正在被重新定价
过去十年，软件行业的招聘市场有一个趋势：重"刷题能力"、轻"工程经验"。LeetCode 刷得好就能进大厂，十年架构经验可能在面试时还不如一个应届生。
AI 正在翻转这个不等式。
当算法实现可以被 AI 秒级完成时，"会写快速排序"就不再是区分度了。真正的区分度变成了：
- 你能不能判断这个系统该不该用排序？
- 排序结果缓存多久失效？
- 当数据量增长 100 倍时这个排序策略还成立吗？
- 如果排序逻辑是 AI 生成的，你怎么验证它在所有边界条件下都正确？
这些全是经验驱动的判断。AI 做不了这些，LeetCode 也练不出这些。它们来自在生产环境踩过的坑、背过的锅、半夜被 oncall 叫醒的痛苦经历。
对企业的启示：用人逻辑需要从"找到能写代码的人"转向"找到能驾驭 AI 写代码的人"。 前者是消耗品，后者才是核心资产。
3.4 知识管理从"有空再做"变成了"不做就死"
AI 没有长期记忆。每一个新会话，它都是从零开始理解你的系统。
这意味着什么？你的系统架构知识、业务规则、踩坑经验——如果只存在于人的脑子里或者 AI 的上下文窗口里，那就是脆弱的。人走了，知识就断了；AI 会话结束了，知识就清空了。
在 AI 时代，知识管理体系（架构决策记录、领域模型文档、API 契约、设计原则）不是锦上添花，而是核心基础设施。 它是你用来"初始化"AI 的 prompt 仓库，是你在人员流动时保持连续性的唯一手段。
换句话说——一个好的知识管理体系，本身就是最高质量的 prompt。
一个残酷的现实是：很多公司连基本的架构文档都没有，所有知识都在几个"元老"的脑子里。以前这只是风险，以后这就是死穴——因为你根本没法有效地利用 AI。
四、对项目流程的影响：敏捷没赢，瀑布也没死，该重新洗牌了
4.1 "快速迭代"的前提正在动摇
敏捷宣言诞生于 2001 年，核心假设是：需求是不确定的，所以用短周期、快反馈来逼近正确答案。 重实现轻设计，因为"先做出来看看"比"想清楚再做"更经济。重结果轻流程，因为流程往往会变成官僚主义。
这个假设在 AI 之前是成立的。改代码成本高，所以试错要快、反馈要早。
但 AI 改变了等式的一边。当"做出来看看"的成本暴跌时，它的诱惑力也暴涨——
"想那么多干嘛，先让 AI 生成一版看看？"
"这个方案不确定？没事，让 AI 各写一版，跑起来对比一下。"
"架构设计？先做出来再说，不行再改。"
这些想法每一个都很合理，每一个都很危险。因为 AI 让你高效地走弯路。你以前三天走一条弯路，发现不对回头重来。现在你三小时走五条弯路，每条都看起来很对，每条都不是最优解。你走得越多，离正确的路越远——因为你没有花时间站在高处看地图。
当"做"变快了，"想"的价值就变大了。 不是因为想比做难，而是因为做错的代价乘上了 AI 的速度杠杆。
4.2 设计先行在回归——但不是回到瀑布
这不意味着要回到写 200 页设计文档然后花半年实现的瀑布模型。
它意味着一种新的流程范式：
① 深入的领域分析和需求澄清（慢）
↓
② 清晰的架构约束和模块边界定义（慢）
↓
③ AI 驱动的并行实现（极快）
↓
④ 严格的人工验证和集成测试（慢）
↓
⑤ 在约束框架内的快速迭代（快）
注意这里面的节奏变化：① ② ④ 是慢的，③ ⑤ 是快的。 以前是全程中速——设计不充分、实现也不快、验证也马虎。现在是该慢的地方慢到位，该快的地方快到飞起。
而且第二步和第三步之间的间隔可以非常短——因为 AI 让实现几乎可以实时跟随设计。你不需要花三个月写详细设计文档然后花六个月编码。你可能花两天定义架构约束，然后用 AI 在一周内生成所有模块的骨架代码，再花两周打磨。
设计的时间占比变大了，但总周期变短了。 这才是 AI 带来的真正效率提升——不是让你在同样的时间里写更多代码，而是让你在更短的时间里做出更对的东西。
4.3 "重项目轻产品"的思维该翻篇了
"项目"思维的本质是：有开始、有结束、有交付物、有验收标准。这是工程思维的产物——把软件当成一栋楼来盖，盖完验收交钥匙。
但好的软件不是"交付"出来的，它是"长"出来的。它需要持续地理解用户、调整方向、做减法。
AI 让"交付项目"变得太容易了——你几乎可以在任何时间点交付一个"看起来完整"的产品。十个功能全有了，界面也漂亮，demo 也很流畅。但"看起来完整"和"真正有价值"之间的鸿沟，AI 填不上。
产品思维的核心——理解用户真正需要什么，而不是他们说他们需要什么——是 AI 替代不了的能力。 因为它需要同理心、需要对人性的理解、需要在模糊信息中做判断的勇气。
当实现不再是瓶颈，产品的权重自然上升。那些能把需求想清楚、把优先级排对、把"不该做的功能"砍掉的人——他们才是 AI 时代最贵的人。
4.4 测试策略需要全面升级，不能还停留在"写完再测"
AI 生成的代码有一种"应试教育"的特质：它擅长通过你明确指定的测试，但不擅长应对你没测到的场景。
你说"测试用户登录"，它生成的代码能通过登录测试。但它不会主动考虑：SQL 注入怎么办？会话固定攻击怎么办？并发登录时 session 管理会不会出 race condition？密码错误五次要不要锁账户？
如果测试用例是"考试题"，AI 就是一个刷题高手——它能确保你出的每道题都做对，但它不会主动去想"万一考到没练过的题呢"。
所以测试策略需要从"覆盖已知场景"升级到"发现未知风险"：
- 契约测试和类型约束的权重提升——它们是不需要运行就能施加的约束，是最廉价的"防弹衣"
- 模糊测试和属性测试变得更加重要——它们能发现 AI 在设计时没有考虑到的边界
- 混沌工程的价值被放大——因为你需要验证的不只是"代码对不对"，而是"系统在压力下是否仍然可控"
一句话：测试不再是"写完代码之后的事"，它得成为架构设计的一部分——在 AI 动手之前，你就要定义好验证的规则。
五、对个人的影响：重新定义"值钱"
5.1 初级开发者的困境——但不是绝路
直说吧：AI 对初级开发者的影响是最直接的。
过去一个 junior 的核心价值是"能把功能做出来"。不需要多优雅，能跑、能过测试、能交付就行。这个价值正在被 AI 直接替代——而且 AI 做得更快、bug 更少（至少表面如此）。
但这不意味着初级开发者没有未来。它意味着成长路径需要换一条。
旧路径：学语法 → 写小功能 → 写大功能 → 学设计 → 学架构
新路径：学系统思维 → 学验证方法 → 用 AI 做实现 → 学审查 AI 输出 → 学架构
入口变了。以前是从"写"开始，现在是从"判断"开始。
一个刚入行的开发者，如果能尽早建立系统思维和代码审查能力，用 AI 来加速学习而不是替代学习，反而可能成长得比以前更快。因为 AI 是一个随叫随到的老师——你问它"这段代码为什么这样写"，它能给你解释。你让它生成不同方案，你能对比学习。
危险的不是"AI 会写代码"，而是"以为会用 AI 写代码就等于会做软件"。 这两者之间的差距，就像"会用搜索引擎"和"会做研究"的差距一样大。
5.2 高级开发者：从"工匠"变成"指挥"
对有经验的开发者来说，AI 是杠杆，不是替代品。
一个 senior 的核心能力从来不是"写代码快"——而是知道什么该写、什么不该写、什么时候该重构、什么时候该推翻重来。这些判断力在 AI 时代不仅没贬值，反而在升值。
在 AI 时代，一个 senior 的工作方式可能变成这样：
- 60% 的时间在设计和审查上（而不是像以前那样 60% 时间写代码）
- 用 AI 生成实现的初稿，然后花时间审查、修改、重构
- 定义架构约束——不是写代码，而是写"规则"，让 AI 在规则内工作
- 建立嗅觉——对 AI 输出形成直觉，快速识别哪些结果需要深入审查
这本质上是一种角色转变：从"工匠"变成"指挥"。 你不再亲手砌砖，但你需要知道每一面墙为什么要这么砌。
一个类比：好的厨师和普通厨师的区别不在于谁切菜快——预制菜切得比谁都快——而在于谁更懂食材、谁更懂搭配、谁能吃出哪道菜里少了一味调料。AI 就是那个切菜飞快的帮厨，但决定菜单、把控出品的仍然是主厨。
5.3 架构师：AI 时代最稀缺的资源
"架构师"这个词在行业里被用得很烂——很多人的"架构师"头衔本质上是"高级开发+偶尔画个 PPT"。但在 AI 时代，真正的架构能力变得前所未有地重要。
原因有三：
第一，AI 无法做真正的权衡。
架构设计的本质是在多个维度之间做取舍：性能 vs 可维护性、一致性 vs 可用性、短期交付 vs 长期演进。这些取舍没有标准答案，依赖对业务上下文、团队能力、技术趋势的综合判断。AI 可以给你"业界常见的做法"，但它不能告诉你"在你的场景下，不常见的做法可能更好"。
第二，AI 缺乏"未来感"。
好的架构设计是为未来的变化留空间——不是预知未来，而是保持可选择性（optionality）。这需要一种反事实思维：如果明年需求变成 X，今天的这个设计还撑得住吗？AI 的训练数据是过去，它很难为尚未发生的变化做准备。
第三，架构是一种社会性活动。
架构不只是技术决策，它还是组织决策——决定了团队怎么分工、代码怎么归属、变更怎么协调。Conway 定律说系统结构反映组织结构，反过来也成立。这种组织层面的架构思维，AI 完全不具备。
经验丰富的架构师是 AI 时代最稀缺的资源。因为他们是那些知道什么时候该慢下来的人。
在一个什么都加速的时代，知道什么时候减速，是最稀缺的能力。
5.4 "软技能"正在变成"硬通货"
如果我只能给一个年轻人一条职业建议，我会说：学好沟通。
不是那种"会做 PPT"的沟通。而是：
- 能把模糊的想法变成精确的需求文档。 这是给 AI 下达有效指令的前提。
- 能在不同角色之间翻译。 业务方说"用户体验不好"，你能把它拆解成"列表页加载超过 3 秒且没有骨架屏"。
- 能写出清晰的架构决策记录。 让三个月后的自己、刚入职的新人、以及每一个 AI 会话都能理解"为什么这么做"。
- 能说服团队在"能做"和"该做"之间选择后者。 当 AI 让什么都能做时，"不做"的决策变得更难、也更重要。
这些能力在过去被认为是"加分项"。在 AI 时代，它们是核心竞争力。
因为 AI 可以帮你写任何代码，但它不能帮你做任何一个需要人际理解的决策。
六、现在能做什么：别光想，动手
说了这么多问题和趋势，最后聊点实在的。
短期：把约束前置，别让 AI 裸奔
- 先写约束，再让 AI 写代码。 类型定义、接口契约、架构规则——这些是给 AI 划的跑道。没有跑道，AI 跑得再快也是乱跑。
- 把架构经验 Skill 化。 团队里老人踩过的坑、总结的原则，整理成可被 AI 引用的知识库。这比培训十个新人有效得多。
- 审查流程不能省，还要加严。 代码库膨胀了，审查标准也得跟着升级。宁可慢一点出活，也不要快一倍埋雷。
- 测试前置。 先定义验收标准和测试策略，再让 AI 去实现。让测试成为约束而不是事后验证。
长期：把架构质量纳入模型训练
这是更远景的展望：目前的 AI 模型训练，reward 主要来自"代码是否通过测试"、"代码是否符合规范"。但很少有 reward 来自"这段代码六个月后是否仍然可维护"。
如果我们能把"长期可维护性"纳入模型训练的 reward 函数——比如通过大量真实项目的演化数据来训练模型理解什么是好的架构——那 AI 的能力边界就会从"写好局部代码"扩展到"做出好的全局决策"。
这还很远。但这是值得投资的方向。
结语
回到标题。
"Code is cheap, show me the prompt" 不是在说代码不重要。它是在说——代码的含金量正在从"怎么写"转移到"为什么写"和"写什么"。
"Prompt"在这里不只是"给 AI 的提示词"。它是一个隐喻——它代表所有在代码之前发生的思考：需求的澄清、架构的约束、设计的原则、验证的规则。这些东西才是 AI 时代真正的"源代码"。代码本身只是编译产物。
Linus 说"talk is cheap, show me the code"的时候，软件行业还处在"能把东西做出来就不错了"的阶段。那个时代，实现能力就是核心竞争力。
但现在，"把东西做出来"不再是难题。难题是——
- 做什么？
- 为什么做？
- 为谁做？
- 什么时候不该做？
- 做到什么程度该停下来？
这些问题，AI 回答不了。它们需要人的判断力、同理心、和在不确定性中做决策的勇气。
AI 是极其高效的执行者。但经验丰富的架构师仍然不可替代——因为他们知道什么时候该慢下来。
在一个一切都加速的时代，知道什么时候减速，是最稀缺的能力。
Redis 的作者 antirez 说过一段话，我觉得放到这里特别合适：
或许你会觉得，自己曾为学习编程付出了无数心血，可如今这些努力仿佛都被机器轻易取代。但请回想一下，当年你为了让项目成功运行而熬夜敲代码时，内心燃烧的那份热情究竟源于什么？是创造的乐趣。而现在，只要你能掌握与人工智能高效协作的方法，就能创造出更多、更棒的作品——那份创造的乐趣，从未改变。
是的。工具变了，但创造的冲动没变。AI 把执行的成本打下来了，但它也把你从重复劳动中解放出来——让你有更多时间去做那些真正需要创造力的事。
别害怕被取代。害怕的应该是：你花了十年练就了一身砌砖的手艺，却从来没学过怎么看图纸。
现在学，还来得及。
写于 2026 年 4 月。当 AI 能在一分钟内写出这篇文章的时候，花三个小时写它的意义是什么？也许是因为，有些思考只有在写的过程中才会发生。
浙公网安备 33010602011771号