企业官网建设流程全解析

1. FDE 模式到底在解决什么问题

第一次听到 FDE 这个词，是在一个做企业级 AI 落地的群里。有人丢了一句“我们这边 FDE 驻场三周，把 Agent 的意图识别准确率从 61% 拉到 89%”，底下瞬间炸出一堆人问 FDE 是什么、怎么招、怎么报价。那会儿市面上关于 FDE 的中文资料几乎为零，能搜到的只有零星几条招聘 JD 和几篇英文博客。我自己带过两个 FDE 性质的交付项目，也踩过不少坑，所以想借这篇把 FDE 这个模式从头到尾拆一遍——它是什么、为什么现在火、怎么落地、坑在哪。

FDE 全称 Forward Deployed Engineer，直译过来叫“前线部署工程师”。这个角色最早在 Palantir 被大规模使用，核心逻辑是：把工程能力直接推到客户现场，让懂技术的人贴着业务问题干活。传统交付模式是“销售谈需求 → 产品经理写文档 → 研发在后方开发 → 实施去现场部署”，中间隔着好几层信息损耗。FDE 模式把这根链条压扁了——工程师本人就在客户会议室里，听到的是原始需求，看到的是真实数据，改的是当场能跑的代码。

为什么这两年 FDE 突然被频繁提起？因为 AI Agent 的落地场景和传统软件完全不是一回事。传统 SaaS 的需求相对确定，你卖一套 CRM，功能边界是清晰的。但 Agent 项目不一样，客户说“我要一个能自动处理工单的智能体”，这句话背后藏着几十个未定义的细节：工单从哪来、意图怎么分类、什么情况转人工、知识库怎么更新、失败了怎么兜底。这些细节在办公室里拍脑袋是想不出来的，必须有人蹲在现场，看着真实数据流、听着真实用户抱怨，才能把 Agent 的边界一点点磨出来。

所以 FDE 模式的核心价值可以概括成一句话：用工程能力换业务理解的速度。它解决的不是技术问题，而是“技术能力和业务场景之间的翻译损耗”问题。适合谁参考？三类人：一是正在做 AI Agent 交付的团队负责人，二是想转型做 FDE 的工程师，三是企业里负责 AI 项目落地的技术管理者。哪怕你暂时不打算搞 FDE，理解这套逻辑对做任何 B 端项目都有帮助。

2. FDE 模式的核心设计与选型逻辑

2.1 为什么是“前线”而不是“远程支持”

很多人第一反应是：现在远程协作工具这么发达，为什么非要派人去现场？视频会议不香吗？我一开始也这么想，直到有一次远程支持一个客服 Agent 项目，客户说“识别不准”，我们查了三天日志没找到问题。后来我飞到现场，坐在客服工位上看了两个小时，发现客服在跟用户对话时会频繁切换三个系统，而我们的 Agent 只接了其中一个系统的数据。这个问题远程永远发现不了，因为客户自己都没意识到这是个问题。

前线部署的本质是获取“未被言说的上下文”。业务方描述需求时，会自动过滤掉他们觉得“理所当然”的信息。比如“工单要自动分类”——他们不会告诉你，实际上有 30% 的工单是重复提交的，有 15% 的工单分类标签是错的，还有 5% 的工单根本不该进系统。这些脏数据不亲眼看到，你的 Agent 设计就是空中楼阁。

从成本角度算一笔账：一个 FDE 驻场三周的成本，大约等于后方团队远程磨两个月的沟通成本。而且远程模式下，需求变更的响应周期是“天”级别，FDE 现场是“小时”级别。对于 Agent 这种需要高频迭代调优的项目，这个速度差是决定性的。

2.2 FDE 和传统实施、售前的区别

这里必须把几个容易混淆的角色掰清楚，不然招人时会出大问题。

FDE 和售前最大的区别是：售前负责“让客户相信能做”，FDE 负责“真的做出来”。FDE 和实施最大的区别是：实施是“把标准产品装上去”，FDE 是“现场写代码把非标问题解决掉”。FDE 和产品经理最大的区别是：产品经理输出文档，FDE 输出可运行的系统。

我见过最失败的 FDE 招聘，是招了一个纯售前背景的人去做 FDE。他能把方案讲得天花乱坠，但客户说“这个字段要加个校验规则”时，他得回头问研发。FDE 必须能自己动手，这是底线。

2.3 Agent 项目为什么特别需要 FDE

Agent 项目和传统软件有一个本质区别：它的行为是概率性的，不是确定性的。传统软件你输入 A 就得到 B，测试用例写清楚就行。Agent 你输入 A，它可能返回 B、C、D，甚至胡言乱语。这意味着 Agent 的“需求”不是一次性定义清楚的，而是在反复试错中收敛的。

我做过一个合同审核 Agent，客户一开始的需求是“自动识别风险条款”。听起来很简单对吧？但驻场第一天就发现：法务部说的“风险”和业务部说的“风险”完全不是一回事。法务关注的是法律合规风险，业务关注的是商业条款风险。而且同一个条款，在不同合同类型里的风险等级不一样。这些规则如果不在现场跟两拨人分别聊，你永远不知道。

FDE 在 Agent 项目里的典型工作节奏是这样的：上午跟业务方聊，把他们的口头规则翻译成 Prompt 或规则引擎；下午改代码、跑测试；晚上把结果拿给业务方看，收集反馈；第二天继续迭代。这个循环一天能跑两到三轮，三周下来就是四五十轮迭代。远程模式下，这个循环一周能跑一轮就不错了。

2.4 工具选型：FDE 的“随身工具箱”

FDE 不是赤手空拳上阵的，需要一套能快速搭建、快速修改的工具链。基于我自己的实践，推荐这么几类：

Agent 开发框架：LangChain 和 LlamaIndex 是绕不开的，但现场开发我更倾向用轻量级的方案。因为客户现场的网络环境、数据安全要求千奇百怪，重型框架的依赖太多，装都装不上。我通常带一个基于 FastAPI 的最小 Agent 骨架，核心逻辑自己写，只依赖最基础的库。这样到了现场，半小时就能跑起来第一个 Demo。

Prompt 管理：现场改 Prompt 是家常便饭，千万别把 Prompt 硬编码在代码里。我用的是一个简单的 YAML 文件管理所有 Prompt 模板，改完重启服务就生效。更讲究一点可以用 PromptLayer 这类工具做版本管理，但现场环境不一定允许。

数据探查：FDE 到现场第一件事是看数据。我习惯带一套 Jupyter Notebook 模板，里面预置了数据概览、字段分布、缺失值统计这些常用分析。客户给个 CSV 或数据库连接，十分钟内就能对数据质量有个底。

快速原型：Streamlit 是 FDE 的好朋友。一个下午就能搭出一个能交互的 Agent Demo，业务方点一点就能给反馈。比画原型图高效十倍。

注意：工具选型的第一原则是“能在客户环境里跑起来”。再先进的框架，装不上就是零。我每次驻场前都会问清楚客户的内网环境、Python 版本、有没有 GPU，然后准备一个降级方案。

3. FDE 驻场实操全流程拆解

3.1 驻场前的准备：别打无准备之仗

FDE 驻场不是拎包入住，前期准备决定了现场效率。我一般提前一周做四件事：

第一，要数据样本。跟客户要一批脱敏的真实数据，哪怕只有几百条。提前跑一遍数据探查，把字段含义、数据分布、明显脏数据都摸清楚。这样到现场第一天就能直接聊具体问题，而不是花时间理解数据结构。

第二，列问题清单。基于数据样本，列出所有需要现场确认的问题。比如“这个 status 字段有 7 个取值，每个取值对应的业务含义是什么”“这两张表的关联键在业务上是什么关系”。问题清单越具体，现场沟通效率越高。

第三，准备可演示的基线。带一个能跑的最小 Agent，哪怕功能很粗糙。现场演示一个能跑的东西，比讲一小时方案更能激发业务方的反馈。他们会指着屏幕说“这个不对”“那个应该这样”，这些反馈就是需求。

第四，确认环境和权限。客户的数据能不能导出？开发机能不能连外网？能不能装 Python 包？这些看似琐碎的问题，现场卡住就是半天。我吃过一次亏，到了现场发现开发机是 Windows 且没有管理员权限，装个库折腾了一下午。

3.2 现场第一周：建立信任与快速出活

第一周的目标不是做出完美方案，而是建立信任。业务方对 FDE 的态度通常是“又来一个讲 PPT 的”，你要用最快速度证明自己是来干活的。

我的做法是：第一天上午跟业务方开个短会，不聊方案，只聊他们每天的工作流程。让他们演示一遍实际操作，你在旁边看、记、问。下午把数据接进来，跑一个最基础的版本。第二天上午把结果拿给他们看，哪怕准确率只有 50%，也要让他们看到“昨天说的东西今天就能跑”。

这一周的关键动作：

• 跟一线操作人员混熟。他们是最了解真实痛点的人，而且往往最愿意说真话。我通常会请他们喝杯咖啡，问“你觉得现在最烦的事情是什么”。
• 建立快速反馈通道。拉个群，业务方发现问题随时丢进来，你当天改完当天反馈。这个通道的响应速度就是 FDE 的价值体现。
• 记录所有“例外情况”。业务方说“一般是这样，但有时候……”的时候，后面那句话才是重点。这些例外情况就是 Agent 需要处理的边界。

3.3 第二到三周：迭代收敛与规则固化

进入第二周，基本的需求轮廓已经清楚了，开始进入密集迭代期。这个阶段的核心工作是把业务规则翻译成 Agent 能执行的逻辑。

以我做的工单分类 Agent 为例，业务流程是这样的：

# 简化的 Agent 处理流程 def process_ticket(ticket): # 第一步：意图识别 intent = classify_intent(ticket.text) # 第二步：根据意图路由到不同处理分支 if intent == "退款申请": return handle_refund(ticket) elif intent == "技术故障": return handle_tech_issue(ticket) elif intent == "咨询": return handle_inquiry(ticket) else: # 兜底：转人工 return escalate_to_human(ticket)

看起来简单，但每个分支里都有大量细节。比如“退款申请”里，要判断订单是否在退款期内、是否已经发货、用户历史退款次数。这些规则不是拍脑袋定的，是跟业务方一条条对出来的。

这个阶段我习惯用一个“规则对照表”来管理：

这个表每天更新，跟业务方对齐。到第三周末，这张表就是 Agent 的“需求文档”，而且是被验证过的。

3.4 交付与知识转移：让客户能自己跑

FDE 驻场是有期限的，最终目标是让客户团队能自己维护这套系统。所以最后一周要花大量时间做知识转移。

我通常会做三件事：

写一份“运维手册”，不是那种官方文档，而是“如果 Agent 识别不准了，先检查这三个地方”这种实操指南。包括常见问题的排查步骤、Prompt 的修改方法、数据更新的流程。

做一次“影子操作”，让客户的工程师当着我的面改一次 Prompt、跑一次测试、部署一次更新。有问题当场解决，确保他们真的会。

留一个“扩展接口”，把 Agent 的各个模块解耦，告诉客户“如果你想加一个新的意图分类，在这里加一个函数就行”。这样他们后续可以自己迭代，不用每次都找原厂。

实操心得：知识转移最怕的是“我讲了你听了但你没动手”。一定要让客户的人亲手操作一遍，哪怕慢一点、出错也没关系。我见过太多项目，FDE 一走系统就没人敢动了。

4. FDE 模式下的 Agent 技术要点

4.1 Agent 架构：够用就好，别过度设计

现场开发最忌讳的是“架构先行”。我见过一个团队，驻场第一周就在设计微服务架构、消息队列、分布式部署，结果三周过去连一个能跑的 Demo 都没有。FDE 场景下的 Agent 架构原则是：能跑通业务闭环的最小架构就是最好的架构。

我常用的 Agent 架构分三层：

接入层：负责接收输入，可能是 API、可能是文件、可能是数据库轮询。这一层越薄越好，一个 FastAPI 的 endpoint 就够了。

决策层：Agent 的核心，包括意图识别、实体抽取、路由决策。这一层用 Prompt + 规则引擎混合实现。纯 Prompt 方案灵活但不可控，纯规则方案可控但不灵活，混合方案是现场开发的最优解。

执行层：具体动作，比如查数据库、调 API、生成回复。这一层要设计成可插拔的，每个动作一个函数，方便现场快速增删。

# 一个典型的混合决策实现 def decide_action(user_input, context): # 先用规则处理高确定性场景 if is_clear_refund_request(user_input): return {"action": "refund", "confidence": 0.95} # 规则覆盖不了的，走 LLM 判断 llm_result = llm_classify(user_input, context) # 低置信度的转人工 if llm_result["confidence"] < 0.7: return {"action": "human", "confidence": llm_result["confidence"]} return llm_result

这个架构的好处是：规则部分业务方看得懂、能参与；LLM 部分处理长尾；兜底机制保证不会出大错。

4.2 Prompt 工程：现场迭代的核心技能

FDE 在现场改得最多的就是 Prompt。分享几个我踩坑总结出来的经验：

Prompt 要短，规则要外置。很多人喜欢把一堆规则塞进 System Prompt，结果改一条规则要动整个 Prompt，容易引入意外。我的做法是 System Prompt 只定义角色和输出格式，具体规则用 Few-shot 示例或外部规则表注入。

每个 Prompt 都要有“不知道”选项。Agent 最危险的行为是“自信地胡说”。在 Prompt 里明确写“如果不确定，输出 UNKNOWN”，然后在代码里处理 UNKNOWN 的情况。

版本管理要轻量但严格。我用的是最简单的方案：Prompt 存在 YAML 文件里，每次修改前先复制一份加时间戳备份。现场改 Prompt 的频率太高，没有版本管理会乱套。

测试用例要跟着 Prompt 走。每改一次 Prompt，跑一遍回归测试。我通常维护一个 50 条左右的测试集，覆盖典型场景和边界情况。这个测试集是现场最宝贵的资产。

4.3 数据闭环：让 Agent 越用越准

Agent 上线不是终点，而是起点。FDE 要设计一个数据闭环，让 Agent 在使用中持续优化。

闭环的核心是收集反馈。反馈来源有三个：一是用户的显式反馈（点赞/点踩），二是人工修正记录（转人工后客服怎么处理的），三是隐式信号（用户是否重复提问、是否直接关闭）。

收集到反馈后，要有一个归因流程：是意图识别错了？是知识库缺失？是回复模板不合适？不同原因对应不同的修复动作。这个流程我通常做成一个简单的看板，每周跟业务方过一遍。

# 反馈收集的简化实现 def log_feedback(ticket_id, agent_response, human_response, feedback_type): record = { "ticket_id": ticket_id, "agent_response": agent_response, "human_response": human_response, "feedback_type": feedback_type, # "correction" / "escalation" / "positive" "timestamp": now() } save_to_db(record) # 如果是修正，加入待分析队列 if feedback_type == "correction": add_to_analysis_queue(record)

这个闭环跑起来后，Agent 的准确率会随着使用量增长而提升。我做过的一个项目，上线第一个月准确率 72%，第三个月到了 88%，靠的就是这个闭环。

4.4 并发与稳定性：现场必须考虑的工程问题

Agent 项目 Demo 阶段通常没什么并发，但一旦上线，流量可能瞬间上来。FDE 在现场就要考虑这个问题，不能等出事再补。

限流是第一道防线。不管后端多强，入口必须有限流。我用的是最简单的令牌桶算法，每个用户每分钟最多 N 次请求。超过的直接返回“请稍后再试”，保护后端。

LLM 调用要加超时和重试。LLM API 偶尔会慢或者失败，必须设置合理的超时时间（我一般设 10 秒），超时后走降级逻辑（返回预设回复或转人工）。重试最多两次，避免雪崩。

缓存高频请求。很多用户问的问题是重复的，把高频问题的答案缓存起来，能大幅降低 LLM 调用量。缓存 key 可以用问题的 embedding 做相似匹配，相似度超过阈值就返回缓存结果。

监控要简单直接。现场不需要复杂的监控系统，一个能看到 QPS、响应时间、错误率、LLM 调用量的面板就够了。我用 Streamlit 搭过一个简易监控页，业务方也能看懂。

注意：Agent 的并发瓶颈通常在 LLM 调用，不在你的代码。所以优化重点是把能缓存的缓存、能批量的批量、能异步的异步。我试过把 10 个独立的 LLM 调用改成批量调用，响应时间从 8 秒降到 2 秒。

5. 常见问题与排查技巧实录

5.1 Agent 识别不准，怎么系统性排查

这是现场最高频的问题。业务方说“识别不准”，你不能盲目改 Prompt，要有系统性的排查思路。

我的排查顺序是：先看数据，再看 Prompt，最后看模型。

第一步，把识别错误的 case 全部拉出来，人工看一遍。通常会发现错误集中在某几类场景。比如我遇到过一次，错误全部集中在“用户同时问了两个问题”的情况。这就是数据层面的模式，不是 Prompt 能解决的。

第二步，检查 Prompt 是否有歧义。把出错的 case 和 Prompt 对照看，经常发现是 Prompt 里的示例和实际数据分布不匹配。比如 Prompt 里的示例都是长文本，实际用户输入都是短句。

第三步，如果数据和 Prompt 都没问题，才考虑换模型或调参数。但说实话，我经手的项目里，80% 的问题出在前两步。

5.2 业务方需求频繁变更，怎么管理

FDE 现场最头疼的就是需求变来变去。今天说“要加一个字段”，明天说“这个逻辑不对”。我的应对策略是建立变更缓冲区。

具体做法：所有变更请求先记录到一个列表里，不立即动手。每天固定两个时间点（比如中午和下班前）集中处理变更。这样避免被频繁打断，也让业务方有时间想清楚自己到底要什么。

同时，每个变更都要问一句“这个变更影响哪些已有功能”。很多时候业务方只看到自己提的需求，没意识到会影响其他部分。你帮他们梳理清楚，他们自己就会更谨慎。

还有一个技巧：用 Demo 代替讨论。业务方说“我想要一个更智能的回复”，这句话没法执行。你花半小时做一个 Demo 给他们看，他们立刻就能说“对，就是这样”或者“不对，我要的是那样”。Demo 是最高效的沟通语言。

5.3 客户数据不能出内网，怎么破

这是企业级项目的常见约束。数据不能出内网，意味着不能用公有云的 LLM API。解决方案有几个：

方案一：本地部署开源模型。现在 7B 到 14B 的模型在消费级显卡上就能跑，效果对于很多场景够用了。我用过 Qwen 和 Llama 系列，在意图分类任务上表现不错。缺点是部署和维护成本高，需要客户有 GPU 资源。

方案二：混合方案。敏感数据在本地处理，非敏感的部分调云端 API。比如实体抽取在本地做，回复生成调云端。这个方案需要仔细设计数据流，确保敏感信息不泄露。

方案三：规则引擎兜底。对于确定性高的场景，完全用规则引擎处理，不依赖 LLM。LLM 只处理规则覆盖不了的长尾。这个方案效果最可控，但覆盖范围有限。

我通常建议客户从方案三起步，快速上线看到效果，再逐步引入方案一或方案二。

5.4 FDE 驻场结束后的持续支持怎么做

驻场结束不代表项目结束。我一般会安排一个“过渡期”，通常是驻场结束后两周到一个月，提供远程支持。

过渡期的支持分三个级别：

一级：操作指导。客户遇到问题，我远程看一下，告诉他们怎么操作。这个级别的问题通常一周内会集中出现，之后快速下降。

二级：Bug 修复。发现代码问题，我远程改或者给补丁。这个级别的问题应该越来越少，如果一直很多，说明交付质量有问题。

三级：功能扩展。客户想加新功能，这个通常要重新评估工作量，不属于过渡期支持范围。

过渡期结束后，我会做一次复盘，把常见问题整理成 FAQ 文档留给客户。同时建立一个定期回访机制，比如每月一次视频会议，了解系统运行情况。

实操心得：过渡期最怕的是“客户不好意思打扰你”。要主动问、主动跟进，别等客户憋出大问题才来找你。我通常会在驻场结束后的第三天、第一周、第二周分别主动联系一次。

6. FDE 工程师的能力模型与成长路径

6.1 硬技能：什么技术栈是必须的

FDE 的技术栈和纯研发不一样，讲究“广而不深，够用就行”。

编程能力：Python 是必须的，因为 AI 生态基本都在 Python 上。不需要写到架构师水平，但要能快速写脚本、改代码、调 API。SQL 也要熟练，现场查数据是家常便饭。

Agent 开发：LangChain、LlamaIndex 这些框架要会用，但更重要的是理解 Agent 的基本原理——意图识别、工具调用、记忆管理、多轮对话。框架会变，原理不变。

Prompt 工程：这是 FDE 的核心技能。要能写出稳定、可控、可维护的 Prompt。这个能力没有捷径，就是多写多调多总结。

数据处理：Pandas 要熟，数据清洗、特征分析、可视化这些基本操作要能快速完成。现场经常需要临时分析一批数据来支撑决策。

部署运维：Docker 要会用，基本的 Linux 命令要熟。现场部署环境千奇百怪，能自己搞定环境问题能省大量时间。

6.2 软技能：比技术更重要的事

FDE 和纯研发最大的区别是：你要直接面对业务方，而且往往是业务方的高层。这意味着沟通能力、业务理解能力、项目管理能力，可能比技术能力更重要。

听懂“话外音”。业务方说“这个功能不急”，可能意思是“这个功能不重要”或者“这个功能我不满意但不想说”。你要能分辨。我的做法是：重要的事情当面确认，不要只靠文字沟通。

管理预期。业务方往往对 AI 有不切实际的期待，觉得“AI 应该什么都能做”。你要在项目早期就把边界划清楚：什么能做、什么做不了、什么需要时间。我通常会在第一周结束时就给一个“能力边界说明”，避免后期扯皮。

快速学习业务。FDE 可能今天做金融，明天做医疗，后天做制造。你不可能成为每个行业的专家，但要能在短时间内理解业务的核心逻辑。我的方法是：找一线操作人员聊，让他们用最朴素的语言解释业务流程，比看文档快得多。

抗压能力。现场环境往往很紧张，业务方盯着你出活，后方团队可能支持不及时，客户环境各种限制。心态要稳，遇到问题先拆解再解决，不要慌。

6.3 从传统工程师转型 FDE 的路径

如果你现在是后端工程师、算法工程师或者实施工程师，想转 FDE，我的建议是分三步走：

第一步：补齐 AI 基础。不用学到能训模型的程度，但要理解 Transformer 的基本原理、LLM 的能力边界、Prompt 的工作机制。吴恩达的 Agent 教程是不错的入门材料，看完能建立基本认知。

第二步：做一个完整的 Agent 项目。从需求定义到上线运维，完整走一遍。可以是一个小工具，比如自动整理会议纪要、自动回复常见问题。重点不是做多大，而是走通全流程。

第三步：找机会驻场。哪怕不是正式的 FDE 岗位，也可以争取去客户现场支持几天。体验一下现场的工作节奏，看看自己是否适应。我见过技术很强的人不适应现场，也见过技术一般但现场如鱼得水的人。

6.4 FDE 的职业发展天花板在哪

FDE 不是终点，而是一个很好的跳板。从 FDE 出发，有几个发展方向：

方向一：解决方案架构师。对业务和技术都有深入理解，能设计整体方案。这个方向需要更强的抽象能力和方案表达能力。

方向二：AI 产品经理。FDE 背景的产品经理非常稀缺，因为既懂技术又懂业务。这个方向需要补产品方法论和商业思维。

方向三：创业。FDE 在驻场过程中会看到大量未被满足的需求，这些就是创业机会。我认识好几个 FDE 后来自己做了垂直领域的 AI 产品。

方向四：继续深耕 FDE。随着 AI 落地需求爆发，资深 FDE 的稀缺性会持续上升。这个方向需要不断积累行业知识和最佳实践。

不管选哪个方向，FDE 的经历都会让你对“技术如何创造业务价值”有更深刻的理解。这种理解是坐在办公室里写代码永远得不到的。

7. 我对 FDE 模式的一些个人判断

FDE 模式不是万能的。它适合“需求不明确、需要快速探索”的场景，不适合“需求清晰、标准化程度高”的场景。如果你做的是标准 SaaS 产品，FDE 模式反而会拖累效率。

FDE 模式对组织能力要求很高。不是招几个 FDE 就能跑起来的，需要后方有强大的平台支持、知识沉淀机制、以及合理的项目筛选标准。我见过一些公司盲目跟风搞 FDE，结果 FDE 在前线孤军奋战，后方支持跟不上，项目做得很痛苦。

FDE 的核心竞争力是“现场学习速度”。谁能更快地理解业务、更快地迭代方案、更快地建立信任，谁就能赢。技术能力是基础，但不是决胜因素。

最后分享一个我在驻场时养成的习惯：每天结束前花十分钟写“驻场日志”，记录今天发现了什么、明天要验证什么、有什么风险。这个日志后来成了项目复盘和知识沉淀的重要素材。如果你刚开始做 FDE，强烈建议从这个习惯开始。