大模型不是魔法:软件工程原则在 AI 时代的生存指南

凌晨两点，某公司的生产环境告警响了。

不是数据库挂了，不是缓存穿透了，是 AI 客服系统返回的 JSON 突然多了个逗号。解析异常像多米诺骨牌一样倒下去，用户投诉工单在十分钟内堆了 200 多张。

根因？开发团队把大模型当成普通 HTTP API 来调。没有超时，没有降级，没有输出校验，模型说什么就信什么。

这个事故暴露了一个行业性的幻觉：太多人把 AI 当魔法，太少人把它当工程。

一、祛魅：AI 架构师不是新物种

打开招聘网站搜"AI Platform Architect"，JD 里写满了什么？

Transformer 原理、Attention 机制、Prompt Engineering、RLHF、模型微调...

听起来像是要招一个科学家。但面试的时候问："如果主模型 API 返回 429，你的系统怎么兜底？" 候选人愣住了。他能背出 Multi-Head Attention 的公式，却不知道什么叫 Circuit Breaker。

问题出在哪？我们在招科学家，但需要的是工程师。

大模型到底是什么？剥掉所有 hype 的外衣：

它是一个函数。输入字符串，输出字符串。中间是个黑盒。这个黑盒有三个特征：

第一，极其昂贵。 2026 年的推理模型（如 o3、DeepSeek R2）在 high-compute 模式下，单次复杂问题推理可消耗数千万 Token，运行时间以分钟计。推理成本正在逼近训练成本。

第二，响应极慢。 传统 API 毫秒级返回，LLM 推理动辄几秒甚至几十秒。加载一个推理模型到显存需要数分钟，K8s 的 CPU 阈值扩容逻辑在这里像个笑话。更麻烦的是，2026 年的 Agent 工作流动辄 10-50 步推理链，单步 99% 的可靠性在串联后会断崖式下跌。

第三，输出不确定。 同样的输入，两次调用可能得到不同结果。JSON 格式可能今天对明天错，推理过程可能这次严谨下次胡说。2026 年还多了一个维度：Agent 之间的协调可能产生级联错误，一个 Agent 的幻觉会被下一个 Agent 当成事实继续传播。

这三个特征听起来很新鲜？

换个角度：一个大文件上传服务——耗时极长、吃满 I/O 带宽、不能简单堆并发。一个视频转码集群——极度消耗 CPU、需要异步队列、用户不能在线死等。一个第三方支付网关——外部依赖不可靠、需要熔断降级、输出必须校验。一个分布式微服务编排——多步骤串联、单点失败级联、需要状态持久化和断点续传。

大模型推理服务，本质上就是这四者的叠加态。

高级的架构师看 AI，眼里没有魔法。只有数据流、状态机、系统边界——和一张月底的 GPU 账单。

二、经典原则没有过时，只是换了战场

有人说，SOLID、KISS、DRY 是上个时代的古董，不适用于 AI 系统。

错。它们不是某种语言的专利，是软件工程的底层操作系统。AI 只是跑在这套系统上的一个新应用。

SOLID：面向对象的原则，AI 系统的骨架

S - 单一职责（Single Responsibility）

一个 Agent 应该只做一件事。意图识别就识别意图，格式化就格式化，工具调用就调用工具。

反模式是什么？"万能 Agent"——一个 Prompt 里塞了五个任务："你先理解用户意图，然后查数据库，再生成报告，最后发邮件。" 结果每个任务都做得稀烂，上下文窗口被无关信息撑爆，推理成本翻倍。

这和传统架构里"一个微服务干了五个域的事情"是同一个坏味道。2026 年更隐蔽的版本是"万能 MCP Server"——一个 MCP 服务暴露 30 多个工具，Agent 每次调用都在噪声里翻找，延迟和错误率双双飙升。

O - 开闭原则（Open/Closed）

对扩展开放，对修改封闭。今天用 GPT-5，明天切 Claude 4.x，后天换本地 DeepSeek R2——业务代码应该一个字都不用改。

2026 年这个原则有了新名字：MCP（Model Context Protocol）。Anthropic 在 2024 年底提出，16 个月内 SDK 月下载量从 10 万飙到 9700 万，OpenAI、Google、Microsoft 全部跟进，2025 年底捐赠给 Linux Foundation。MCP 的本质就是一个标准化抽象层：工具定义一次，任何模型都能调用。

反模式？代码里写死 openai.ChatCompletion.create，换模型时改 100 处。这和传统架构里直接依赖具体数据库驱动是一个级别的架构债。

L - 里氏替换（Liskov Substitution）

模型 A 和模型 B 对同一个 Prompt，输出格式应该一致。你不可能因为换了模型，下游的 JSON 解析逻辑就炸。

2026 年的新挑战是推理模型的兼容性。o3 的推理过程是黑盒（私有推理 Token），DeepSeek R2 的推理过程是白盒（可见 <think> 标签）。如果你的系统依赖解析推理链来做审计或调试，这两种模型不能无脑互换。

I - 接口隔离（Interface Segregation）

Prompt 只给模型需要的信息，别塞整本说明书。

我见过一个 RAG 系统的 Prompt 里塞了 8 万 Token 的上下文，其中 90% 是噪声。模型在垃圾里找金子，推理时间拉长三倍，成本翻倍，准确率反而下降。

2026 年的更隐蔽版本是MCP 工具过载。一个 Agent 被赋予 20 个 MCP 工具，每次决策都要在 20 个选项里筛选，工具调用准确率直线下降。正确的做法是一个 Agent 只暴露它真正需要的 3-5 个工具。

D - 依赖倒置（Dependency Inversion）

依赖抽象的 LLM 网关（如 LiteLLM、MCP），不依赖具体的 OpenAI、Anthropic 或本地模型。

这是最容易被忽视的一条，也是最重要的一条。没有这层抽象，你的系统就是被供应商绑架的人质。2026 年的行业现实是：模型供应商格局每季度都在变，今天的最优选择明天可能就涨价或降质。

KISS：保持简单， stupid

KISS 原则在 AI 时代的杀伤力，比在传统架构里更大——因为 AI 给了你一个"把事情做复杂"的完美借口。

反模式一：为了 Agentic 而 Agentic。

某团队要做一个"从邮件提取待办事项"的功能。方案 A：一个 Prompt 直接让模型解析邮件、提取任务、输出 JSON。方案 B：Planner Agent 分析邮件 → Researcher Agent 补充上下文 → Writer Agent 生成任务 → Critic Agent 审核质量 → 最终输出。

方案 B 用了 5 个 Agent，Token 消耗是方案 A 的 15 倍，延迟从 2 秒变成 30 秒，准确率反而因为级联错误下降了。

这不是架构，这是炫技。 能用一句话说清楚的需求，别用一个工作流来解决。

反模式二：Prompt 里写程序。

有人在 Prompt 里塞了 500 行伪代码，让模型"按这个逻辑执行"。模型不是编译器，它会在 500 行逻辑里迷失，跳过关键步骤，把第 3 步的条件判断和第 47 步混为一谈。

正确的做法：复杂的业务逻辑写在代码里，Prompt 只负责"做什么"，代码负责"怎么做"。Prompt 是意图表达，不是程序实现。

反模式三：RAG 过度工程。

一个内部知识库问答系统，文档总量不到 1000 页。团队上了向量数据库 + 重排序模型 + 查询扩展 + 多路召回 + 融合排序——五层架构，部署文档 50 页。

实际效果？Elasticsearch 全文检索 + 一个精心调优的 Prompt，准确率差不多，延迟低一半，维护成本降 90%。

KISS 的核心是：先问"必须这么复杂吗"，而不是"还能更复杂吗"。

DRY：别重复自己，也别重复模型

DRY 原则在 AI 系统里有两层含义。

第一层：别在代码里重复同样的模型调用逻辑。

三个微服务各自封装了一套 OpenAI 调用代码，各自的超时策略不同，各自的错误处理不同，各自的日志格式不同。有一天 OpenAI 改了 API 版本，三个团队同时加班。

这是经典的 DRY 违反。正确的做法：一个共享的 LLM Client 库，统一封装调用、重试、日志、监控。所有业务服务只依赖这个库。

第二层：别让模型重复做同样的事。

一个 Agent 工作流里，Step 1 的模型输出了一个分析结论，Step 3 的模型又从头分析了一遍同样的问题。Step 5 的模型再次总结了 Step 1 已经总结过的内容。

Token 在燃烧，GPU 在哀嚎，用户在等待——而结论早就有了。

正确的做法：Agent 之间共享状态（Shared State），前一个节点的输出直接作为后一个节点的输入。模型是昂贵的计算资源，不是无限供应的自来水。

2026 年的最佳实践是推理结果缓存：同样的输入（或语义相似的输入），直接命中缓存返回，不再调用模型。实测可减少 30-50% 的重复推理开销。

三、各种 *ility 的 AI 映射

传统微服务治理讲四大金刚：Availability、Scalability、Robustness、Observability。但完整的软件工程 *ility 框架远不止这四个。

下面把经典 *ility 在 2026 年 AI 场景下的映射和反模式一次性说清：

Availability：从"多活架构"到"多模型备胎 + Agent 容错"

传统高可用靠多实例部署 + 负载均衡。但 LLM 供应商的 API 经常区域性抖动或大面积限流，这不是你多部署几个实例能解决的。

2026 年的正确做法是在网关层配置 Failover 链：主模型（如 Claude 4.x）→ 超时/429 → 自动降级到备用模型（如 GPT-5）→ 仍失败 → 本地开源模型（如 DeepSeek R2）→ 全部失败 → 静态兜底响应。

这和传统架构里的"多机房多活"是一个思路。主通道挂了切备用通道，只是这里的"通道"从机房变成了模型供应商。

2026 年的新挑战：推理模型的"慢失败"。 传统 API 失败是瞬时的——连接超时、返回 500，你知道它失败了。但推理模型的失败可能是"慢性的"：它正在思考，已经烧了 30 秒、5000 个 Token，然后告诉你"我无法回答这个问题"。你的系统已经付了钱、等了时间，却一无所获。

应对策略是预算熔断（Budget Fuse）：给每个请求设定最大 Token 预算和最大等待时间，无论模型是否"正在努力思考"，超限即中断并触发降级。这和金融交易的"止损单"是一个逻辑。

2026 年还多了一层：Agent 编排的容错。一个 10 步的 Agent 工作流，第 7 步失败了怎么办？错误的 Orchestrator 会从头重来——前面 6 步的 Token 全部浪费。正确的 Orchestrator 断点续传：保存前 6 步的状态，第 7 步重试或降级，继续执行第 8 步。Temporal 这类持久化执行引擎在 2026 年已经成为 Agent 基础设施的标准配置，它的核心能力就是"崩溃后从断点恢复"，而不是"从头再来"。

一个真实的对比：

某金融公司的客服 Agent，没有 Failover 设计，某天 OpenAI 区域性故障 2 小时，客服系统完全停摆，直接损失订单转化率 15%。另一家电商公司的客服 Agent，网关层配置了 Claude → GPT-5 → 本地 Qwen 的三级 Failover，同样的故障下，切换耗时 200 毫秒，用户无感知，订单转化率零损失。

Availability 的核心不是"永不失败"，而是"失败时用户无感知"。

Scalability：从"CPU 弹性"到"算力/预算分级调度"

传统微服务靠 K8s 监听 CPU 利用率自动扩容。但 LLM 服务扩容极慢——加载一个模型到显存需要数分钟，且受限于显卡库存。推理模型更夸张：o3 在 high-compute 模式下，单次推理可以跑 14 分钟，消耗 5700 万 Token。

这意味着什么？意味着水平扩容对 LLM 几乎无效。你不能像扩 Web 服务一样"加机器就行"，因为新机器加载模型需要几分钟，而用户的耐心只有几秒。

解决方案和文件转码服务一样：队列机制 + 预算分级。

核心业务采用生产者-消费者模型。用户的 Prompt 丢进队列，LLM 服务根据自己的算力上限（如同时处理 4 个长文本推理）去消费。同时按优先级隔离：VIP 用户的请求在高优先级队列里优先处理，免费用户在低优先级队列里排队。

这和传统架构的线程池 + 优先级队列是一个思路。只是这里的"线程"变成了 GPU 显存中的模型实例，"任务"变成了推理请求。

2026 年更精细的做法是Query Classifier 路由：一个轻量级分类器（几毫秒延迟，可以用规则引擎或小模型）先判断查询复杂度，自动分配推理预算。简单问题给 1000 Token 预算走 fast 模式，复杂证明题给 16000 Token 预算走 deep 模式。实测可减少 40-60% 的平均推理开销。

另一个 2026 年的现实：多租户成本分摊。 一个 GPU 集群服务多个业务线，怎么算钱？传统云计算按 CPU/内存计费，但 LLM 的计费维度是 Token。正确的做法是按 Token 用量分摊成本，每个业务线的请求都记录输入/输出 Token 数，月底按 Token 账单分摊。这和传统架构的"按 API 调用量计费"是一个思路，只是计量单位从"请求数"变成了"Token 数"。

Scalability 的核心不是"无限扩容"，而是"在资源约束下做最优调度"。

Robustness：从"强校验"到"容错自愈 + 防失控"

传统服务的鲁棒性靠入参校验，格式不对直接弹回。但 LLM 的返回结果天生带有随机性，不确定性极高。

2026 年还多了一个维度：Agent 可能陷入无限循环。两个 Agent "辩论" 50 轮没有结论，或者一个 Agent 反复调用同一个工具获取相同结果，Token 账单像滚雪球一样膨胀。

应对策略是四层递进：

第一层：json_repair 自动修复。 模型输出的 JSON 缺了个引号、多了个逗号？先修，别急着报错。2026 年的 json_repair 库已经相当成熟，能处理 90% 以上的格式错误。

第二层：Retry Loop 自愈环。 修不好？换温度参数（temperature）重试，最多 3 次。注意：重试不是简单地"再发一次同样的请求"，而是调整参数（如降低 temperature 增加确定性，或切换模型版本）后重试。

第三层：Circuit Breaker 防失控。 Agent 迭代超过阈值（如 5 轮无结论）或工具调用重复？强制中断，触发人工介入。2026 年的最佳实践是**"预算熔断 + 迭代上限"双保险**：无论哪个先到，都立即停止。

第四层：静态兜底 JSON。 全部失败？返回预定义的默认响应，绝不抛异常到前端。兜底响应不是"抱歉，系统出错了"，而是业务上可接受的默认行为。比如客服系统的兜底是"我已记录您的问题，人工客服将在 10 分钟内联系您"，而不是一个 500 错误页面。

这和支付系统的"对账不平自动冲正"是一个逻辑——假设外部依赖会犯错，提前设计好容错路径。

2026 年的新威胁：Prompt Injection。 攻击者通过构造特殊输入，让模型执行非预期操作（如删除数据、泄露隐私）。传统的入参校验（如正则表达式过滤）对 Prompt Injection 几乎无效，因为攻击载荷可以伪装成正常文本。

应对策略是多层防御：输入层的语义过滤（检测异常意图）、模型层的指令隔离（系统 Prompt 与用户输入严格分离）、输出层的权限控制（Agent 只能执行白名单内的操作）。这和传统安全的"纵深防御"是一个思路。

Robustness 的核心不是"永不犯错"，而是"犯错时系统不崩"。

Observability：从"全链路追踪"到"语义审计 + 推理透视"

传统微服务用 Prometheus + Grafana 看 CPU、内存、QPS，用 SkyWalking 看 TraceID 全链路追踪。这些工具在 LLM 场景下依然有用，但远远不够。

指标转换：从 QPS 到 Token 经济学。

把 QPS 监控面板换成 TTFT（首字响应时间） 和 TPS（每秒 Token 数）。TTFT 超过 1 秒，用户会觉得"系统坏了"；低于 200 毫秒，感觉即时。2026 年还要加一个新指标：推理 Token 占比——一个请求消耗了 1000 Token，其中 800 是推理过程的"思考"，只有 200 是最终输出。这个比例决定了你的成本结构。

更关键的是成本归因：每个请求记录"哪个业务线、哪个功能、哪个用户"消耗了多少 Token。月底你不仅知道"本月烧了 10 万美元"，还知道"客服功能烧了 3 万、内容生成功能烧了 5 万、实验环境烧了 2 万"。这和传统架构的"按接口计费分析"是一个思路。

Trace 升级：从"服务调用链"到"思维过程链"。

以前一个 TraceID 记录"A 服务 → B 服务 → 数据库"。现在一个 TraceID 还要记录"Agent → 思考节点 → 工具调用 → 格式化节点"，并且把中间每一阶段模型吐出的草稿明文、消耗的 Token 额度、调用的 MCP 工具及参数全部持久化。

2026 年的监管现实（EU AI Act）让这层可观测性从"可选"变成了"强制"：高风险 AI 系统必须提供可审计的决策链，否则面临最高 6% 全球营收的罚款。

语义审计：从"查日志"到"查思维"。

用户投诉"AI 昨天胡说八道了"，传统可观测性只能告诉你"昨天 14:23 有一个请求，耗时 3.2 秒，返回 200"。语义审计能告诉你"昨天 14:23，模型在处理这个请求时，第一步推理认为用户要的是 A，第二步调用了查询工具得到结果 B，第三步基于 B 得出结论 C——但 B 其实是过期的数据，所以 C 是错误的"。

这种级别的可观测性不是"锦上添花"，而是生产排障的必需品。没有它，你就是在黑盒里修黑盒。

Observability 的核心不是"监控一切"，而是"能回答为什么出错"。

Maintainability：Prompt 是代码，不是配置

太多团队把 Prompt 当成配置文件随手改，没有版本控制，没有 Code Review，没有回滚能力。

这是灾难。Prompt 的改动和代码改动一样，可能引入回归问题。今天加了一句"请用友好语气回复"，明天模型就开始在财务报告里加表情符号。上周改了一个输出格式要求，本周下游解析逻辑全炸。

Prompt 版本管理的正确姿势：

• 每个 Prompt 有版本号（v1.2.3），Git 管理。
• 改动走 Pull Request，至少两人 Review。
• 灰度发布：5% 流量 → 20% → 50% → 全量，每步监控关键指标（准确率、延迟、Token 消耗）。
• 回滚能力：发现 regression，一键切回上一个版本，耗时不超过 30 秒。

这和传统代码发布的"蓝绿部署"是一个思路。

2026 年的新维度：MCP Server 的接口契约。

一个 MCP 工具的 schema 变了（比如参数名从 query 改成 search_term），所有调用它的 Agent 都会炸。MCP Server 必须有版本控制和兼容性策略，就像 REST API 的 v1/v2 一样。

更隐蔽的问题是Prompt 漂移（Prompt Drift）：同一个 Prompt，模型供应商在后台更新了模型版本（如 GPT-5 从 5.0 升级到 5.1），输出行为变了，你的系统没有任何改动却开始出问题。应对策略是模型版本锁定：生产环境必须指定具体模型版本（如 gpt-5-2026-05-15），而不是模糊的 gpt-5。

Maintainability 的核心不是"代码整洁"，而是"改动可预测、可回滚"。

Portability：模型无关 + 框架无关

你的业务代码里不应该出现 openai、anthropic 或任何具体供应商的 SDK 调用。也不应该绑死 LangGraph、CrewAI 或任何特定 Agent 框架。

2026 年的正确架构是两层抽象：

业务代码 → LLM Gateway（MCP / LiteLLM）→ 具体模型（GPT-5 / Claude 4.x / DeepSeek R2）

Agent 编排 → Orchestrator 抽象层 → 具体框架（LangGraph / Temporal / 自研）

今天接 GPT-5，明天切 Claude，后天换本地模型——业务代码一行不改。今天用 LangGraph 做原型，明天用 Temporal 做生产级持久化——编排逻辑最小化改动。

这和传统架构里用 ORM 屏蔽数据库差异、用接口屏蔽框架差异是一个道理。

2026 年的新现实：模型供应商格局每季度都在变。 今天的最优选择明天可能就涨价、降质、或退出市场。没有抽象层的团队，每次换模型都是一次"小型重构"。有抽象层的团队，换模型只是改一行网关配置。

Portability 的核心不是"技术中立"，而是"选择权"。

Testability：模型输出不是不能测

最常见的借口："模型输出随机，怎么测？"

答案是：测确定性部分，评估不确定性部分，Mock 外部依赖。

确定性部分（必须 100% 通过）：

• 输出格式是否合法 JSON？
• MCP 工具调用是否符合 schema？
• Agent 是否调用了白名单内的工具？

不确定性部分（设定阈值，持续优化）：

• 输出内容是否符合预期？——用评估集（Evaluation Set）做回归测试，设定通过率阈值（如 90%）。
• 模型是否出现幻觉？——用 LLM-as-a-Judge 或规则引擎做自动化评估。
• Agent 工作流是否可复现？——固定种子 + 轨迹回放，确保同样的输入产生同样的执行路径。

Mock 外部依赖：

• MCP 工具调用是否正确？——Mock MCP Server，测试 Agent 的调用逻辑和参数传递，不依赖真实的第三方服务。
• 模型响应是否 handled 正确？——用固定的 mock 响应测试错误处理逻辑（如 429、500、格式错误）。

"测不了"是懒惰的借口。分布式系统的对账逻辑比 LLM 输出复杂十倍，照样能测。2026 年的行业共识是：没有评估集（Eval Set）的 AI 系统不能上生产——就像没有单元测试的代码不能合并一样。

Testability 的核心不是"消除随机性"，而是"在随机性中建立确定性边界"。

四、一个成熟架构师的 AI 落地 Checklist

如果你正在把 LLM 接入生产系统，不要问"这个模型有多强"，先问这六个问题：

1. 抽象层先行： 有没有统一 LLM 网关（MCP/LiteLLM）？换模型时业务代码改几处？Agent 编排有没有框架抽象层？

2. 假设模型会犯错： 所有输出有没有过校验层？JSON 坏了能不能修？修不好有没有兜底？Agent 有没有 Circuit Breaker 防失控？

3. 成本是第一类公民： 每个请求有没有记录 Token 消耗（包括推理 Token）？有没有预算告警？实验环境会不会烧掉一个月预算？Query Classifier 有没有按复杂度分级调度？

4. 延迟分层： 交互场景卡 TTFT（目标 <300ms），批处理卡吞吐，复杂推理卡 Budget Token。有没有为不同场景设不同的 SLA？

5. Prompt 和 MCP 是代码： 有没有版本控制？有没有 Code Review？能不能灰度发布和回滚？MCP Server 的 schema 变更有没有兼容性策略？

6. 可观测性穿透黑盒： 不仅看"请求成功没有"，还要看"模型当时在想什么"。用户投诉时能不能像查日志一样回溯？Agent 决策链是否满足审计要求？

这六个问题里没有一个是"AI 专属"的。它们分别是：依赖倒置、防御式编程、容量规划、SLA 设计、版本控制、可观测性——软件工程 101 的内容。

五、结语：用已知的确定性，驯服未知的不确定性

2026 年的 AI 行业有一个危险的倾向：把大模型和 Agent 包装成"颠覆一切的黑魔法"，仿佛不重新学一遍计算机科学就没法入局。

这是贩卖焦虑。

大模型确实强大，Agent 确实改变了交互范式，但它们不是新物种。大模型是一个有状态的、资源密集型的、输出不确定的第三方服务。Agent 是多步骤编排的、可能级联失败的、需要持久化状态的分布式工作流——这类东西我们在软件工程里治理了二十年。

SOLID 原则没有过时。KISS 原则没有过时。DRY 原则没有过时。各种 *ility——Availability、Scalability、Robustness、Observability、Maintainability、Portability、Testability——没有过时。

技术会过时，原则不会。

AI 只是跑在软件工程操作系统上的一个新应用。用已知的、成熟的软件工程确定性，去驯服未知的、不确定的大模型——这才是企业级 AI 架构升级的正确姿势。

高级的架构师看 AI，眼里没有魔法。

只有数据流、状态机、系统边界。

和一张月底的 GPU 账单。

预告：这个系列还有两篇

这篇是祛魅篇——破除"AI 需要全新知识体系"的幻觉，证明经典软件工程原则依然有效。

下一篇是进阶篇——我们会深入具体的架构模式：如何设计一个生产级的 LLM Gateway？Agent 工作流的编排模式有哪些（Sequential、Parallel、Hierarchical）？推理缓存和 Prompt 缓存怎么实现？多租户场景下的资源隔离和成本分摊怎么做？从原则到模式，从道到术。

第三篇是升华篇——当 AI 基础设施成熟之后，架构师的终极价值是什么？我们会讨论 AI 时代的系统思维升级：从"确定性系统"到"概率性系统"的设计范式转变，从"控制"到"引导"的治理哲学，以及一个核心命题——当机器开始思考，人应该思考什么？

三篇连读，从"AI 没什么特别的"到"AI 确实改变了一切"——但改变的方式，和你想的不一样。

"大模型不是魔法，它只是一个输出不确定的、昂贵的、有状态的第三方 API。"

"技术会过时，原则不会。"