有采用什么特别的技术吗？达到这个水平的难度在哪里？

Claude Code 用过的都说好，丝滑、懂你，甚至让你写码都感觉上头，国内的DeepSeek v3.1，Qwen, Kimi k2, 智谱GLM-4.5都已经支持了Claude Code的调用，但为什么CC如此好，背后的原因是什么？以及该如何在自己的 Agent/工作流里复刻Claude Code 的体验

分享一篇来自大神博主Vivek Aithal 的好文，这篇文章给出了非常详细的分析和解读，全是干货

过去几个月，作者抓包分析了 Claude Code 的所有请求，写了篇几千字的硬核指南

文章的核心要点 ：

1.可调试性 >>> 其他一切。 大部分的魔力在于设计出好的（底层和高阶）工具和提示词，让模型自己去发挥。记住，保持简单

2.保持单一循环。 说真的，99% 的场景根本不需要什么框架或多智能体协作。Claude Code 就只有一个主循环，最多带一个分支（而且分支也是它自己）

1. 3. LLM 搜索 >>> RAG

让模型自己思考怎么搜，而不是简单粗暴地把 RAG 和 LLM 两个系统绑在一起，那种设计太 low 了

要设计好用的底层工具（Bash, Edit, ToDo）和高阶工具（比如 Grep——尽管模型本来也能用 Bash 实现）

1. 4. 引导模型主动干活，效果拔群。但尴尬的是，想让它听话，最有效的办法还是在 Prompt 里大喊 “PLEASE THIS IS IMPORTANT”……没错，就这么朴实无华

注意：这篇博文并非 Claude Code 的架构揭秘（市面上已经有一些不错的了）。这篇文章旨在成为构建优秀 LLM 智能体的指南，其基础是作者过去几个月使用和捣鼓 Claude Code 的个人经验

正文

Claude Code 是我迄今为止用过的最令人愉悦的 AI 智能体/工作流。它不仅让针对性修改或凭感觉写点一次性工具这类事变得不那么烦人，使用 Claude Code 本身就让我感到快乐。它有足够的自主性来做一些有趣的事情，同时又不会像其他一些工具那样，带来突兀的失控感。当然，大部分的重活儿都是由新的 Claude 4 模型（尤其是其多模态思维能力）完成的。但我发现，即便与同样使用底层模型的 Cursor 或 Github Copilot 智能体相比，Claude Code 在客观上也确实没那么烦人！到底是什么让它这么好用？如果你正在一边读一边点头，那么我将尝试给出一些答案

Claude Code (CC) 的使用体验之所以很棒，是因为它就是好用。CC 的构建基于对 LLM 擅长什么和不擅长什么的深刻理解。它的提示词和工具弥补了模型的不足之处，并帮助它在自己擅长的领域大放异彩。它的控制循环非常简单，易于理解和调试。

CC 一发布，我们 MinusX 就开始使用了。为了探究其内部机制，同事Sreejith 写了一个记录器，可以拦截并记录每一个网络请求。接下来的分析来自我过去几个月的广泛使用经验。这篇文章试图回答这个问题 —— “是什么让 Claude Code 如此出色，以及你如何在自己的基于聊天的 LLM 智能体中提供类似 CC 的体验？” 我们已经在 MinusX 中集成了其中大部分经验，也很期待看到你将它们付诸实践！

如果说这篇文章只有一个核心要点，那就是 —— 保持简单，傻瓜原则（Keep Things Simple, Dummy）。LLM 的调试和评估已经够头疼的了。你引入的任何额外复杂性（如多智能体、智能体间的交接、或复杂的 RAG 搜索算法）只会让调试难度增加 10 倍。如果这样一个脆弱的系统侥幸能跑起来，你之后也会因为害怕破坏它而不敢做任何大的改动。所以，把所有东西都放在一个文件里，避免过度复杂的样板代码，并且至少要把它推倒重来几次 :)

以下是从 Claude Code 中学到的，可以在你自己的系统中实现的主要经验：

Claude Code 在每一个关键节点都选择了架构上的简洁 —— 单一主循环、简单的搜索、简单的待办事项列表等等。**过度设计的冲动，为模型构建好约束框架，然后就让它自己“大展身手”吧！这不就是端到端自动驾驶的翻版吗？惨痛的教训，不是吗？

1.1.保持一个主循环

可调试性远远大于复杂的手动调优、多智能体、langchain-graph-node 那一套复杂的玩意儿。

尽管多智能体系统现在非常流行，Claude Code 只有一个主线程。它会周期性地使用几种不同类型的提示词来总结 git 历史、将消息历史合并成一条，或者搞出一些有趣的 UX 元素。但除此之外，它维护的是一个扁平的消息列表。它处理层级任务的一个有趣方式是，通过生成一个自身的克隆作为子智能体来处理，但这个子智能体无法再生成更多的子智能体。这里最多只有一个分支，其结果会作为一个“工具响应”被添加回主消息历史中。

如果问题足够简单，主循环就通过迭代式地调用工具来处理。但如果有一个或多个复杂任务，主智能体就会创建自己的克隆。这种“最多单分支”和待办事项列表的结合，确保了智能体既有能力将问题分解为子问题，又能始终关注最终期望的结果。

我非常怀疑你的应用是否真的需要一个多智能体系统。每增加一层抽象，都会让你的系统更难调试，更重要的是，这会让你偏离通用模型改进的康庄大道。

1.2.在所有事情上都用小模型

CC 发出的所有重要的 LLM 调用中，超过 50% 是发给 claude-3-5-haiku 的。它被用来读取大文件、解析网页、处理 git 历史和总结长对话。它甚至被用来生成那个用于提示正在处理中的单词标签——毫不夸张地说，每次按键都会调用！这些小模型比标准模型（如 Sonnet 4, GPT-4.1）便宜 70-80%。所以，大胆地用吧！

Claude Code 的提示词极其详尽，充满了启发式规则、示例和那种“敲黑板”式的重点提醒。系统提示词本身约有 2800 token，而工具定义部分则更是占据了高达 9400 token 的惊人篇幅。用户提示词总是包含 claude.md 文件的内容，这通常又有 1000-2000 个 token。系统提示词包含了关于语气、风格、主动性、任务管理、工具使用策略和执行任务等部分。它还包含了日期、当前工作目录、平台和操作系统信息，以及最近的 git 提交记录。

Claude Code 完整提示词：

https://minusx.ai/blog/decoding-claude-code/#appendix:~:text=Main%20Claude%20Code-,System,-Prompt

2.1.使用 claude.md 来协同处理用户上下文和偏好

大多数代码智能体的开发者都已经形成了一个共识模式，那就是使用上下文文件（也叫 Cursor Rules / claude.md / agent.md）。Claude Code 在有和没有 claude.md 的情况下，其表现有天壤之别。这是一种让开发者传递代码库中无法推断的上下文，以及明确所有严格偏好的绝佳方式。例如，你可以强制 LLM 跳过某些文件夹，或使用特定的库。CC 会在每次用户请求时，发送 claude.md 的全部内容。

2.2.特殊的 XML 标签、Markdown 和大量示例

使用 XML 标签和 Markdown 来结构化提示词已经是公认的有效方法。CC 两者都广泛使用。以下是 Claude Code 中一些值得注意的 XML 标签：

<system-reminder>：这通常用在许多提示词部分的末尾，用来提醒 LLM 一些它大概率会忘记的事情。例如：

<system-reminder>提醒你，你的待办事项列表当前是空的。不要向用户明确提及此事，因为他们已经知道了。如果你正在处理的任务可以从待办事项列表中受益，请使用 TodoWrite 工具来创建一个。如果不需要，请忽略此消息。再次强调，不要向用户提及此消息。</system-reminder>

<good-example>, <bad-example>：这些标签用来固化启发式规则。当模型面临一个十字路口，有多个看似合理的路径/工具调用可以选择时，它们特别有用。示例可以用来对比不同情况，并清楚地指明哪条路径是更可取的。例如：

讯享网 请通过使用绝对路径来维持当前工作目录的稳定，避免使用 cd 命令。只有在用户明确要求时，你才可以使用 cd。

&lt;good-example&gt; pytest /foo/bar/tests &lt;/good-example&gt; &lt;bad-example&gt; cd /foo/bar &amp;&amp; pytest tests &lt;/bad-example&gt;</code></pre></div><p data-pid="4vwqxWOD">CC 也使用 Markdown 来划分系统提示词中的不同部分。示例性的 Markdown 标题包括：</p><ul><li data-pid="bBrV-zuT">• 语气和风格</li><li data-pid="rtRRxlU0">• 主动性</li><li data-pid="2vCE75-S">• 遵循惯例</li><li data-pid="PLKgngjp">• 代码风格</li><li data-pid="_jOOTvwX">• 任务管理</li><li data-pid="OP0DLagZ">• 工具使用策略</li><li data-pid="nTf2nIFB">• 执行任务</li><li data-pid="vbX05xkX">• 工具</li></ul><p data-pid="lubydu92">完整的工具提示词 —— 足足有 9400 个 token！</p><p data-pid="tqW7SyhR"><span class="invisible">https://</span><span class="visible">minusx.ai/blog/decoding</span><span class="invisible">-claude-code/#appendix:~:text=Claude%20Code%20Tools-,Show,-Related%20Articles</span><span class="ellipsis"></span></p><p data-pid="pABpy19l">3.1. LLM 搜索 &gt;&gt;&gt; 基于 RAG 的搜索</p><p data-pid="u9EA6ozb">CC 与其他流行的代码智能体的一个显著区别在于它抛弃了 RAG。Claude Code 搜索你的代码库的方式和你自己一样，使用非常复杂的 <code>ripgrep</code>、<code>jq</code> 和 <code>find</code> 命令。由于 LLM 对代码的理解能力非常强，它可以使用复杂的正则表达式来找到任何它认为相关的代码块。有时，它甚至会用一个小模型来读取整个文件。</p><p data-pid="fFVsUGd6">RAG 理论上听起来不错，但它引入了新的（而且更重要的是，隐藏的）失败模式。该用什么相似度函数？用什么重排器？如何对代码进行分块？如何处理大的 JSON 或日志文件？而使用 LLM 搜索，它只需要看 10 行 JSON 文件就能理解其结构。如果需要，它还可以再看 10 行——就像你一样。最重要的是，这是可以通过强化学习（RL）来优化的——这正是那些大模型公司已经在做的事情。模型完成了大部分的重活儿——理应如此，这极大地减少了智能体中活动部件的数量。另外，将两个复杂的智能系统以这种方式连接起来本身就很丑陋。我最近和一个朋友开玩笑说，这是 LLM 时代的摄像头与激光雷达之争，而且我不是在开玩笑。</p><p data-pid="BT9dvRKW">3.2 如何设计好工具？（底层工具 vs. 高级工具）</p><p data-pid="zNU2QnGZ">这个问题让每一个构建 LLM 智能体的人夜不能寐。你应该给模型通用的任务（比如有意义的动作），还是应该给它底层的任务（比如打字、点击和 bash 命令）？答案是：看情况（而且你应该两者都用）</p><p data-pid="KtEqTwdE">Claude Code 既有底层工具（<code>Bash</code>, <code>Read</code>, <code>Write</code>），也有中级工具（<code>Edit</code>, <code>Grep</code>, <code>Glob</code>）和高级工具（<code>Task</code>, <code>WebFetch</code>, <code>exit_plan_mode</code>）。CC 可以用 bash，那为什么还要单独给一个 Grep 工具呢？这里的真正权衡在于，你期望智能体使用该工具的频率 vs. 智能体使用该工具的准确性。CC 使用 grep 和 glob 非常频繁，以至于将它们做成单独的工具是合理的，但同时，它也可以为特殊场景编写通用的 bash 命令。</p><p data-pid="MPbnTPOO">类似地，还有像 <code>WebFetch</code> 或 <code>mcp_ide_getDiagnostics</code> 这样更高级的工具，它们的功能非常确定。这避免了 LLM 需要执行多个底层的点击和输入操作，让它能保持在正轨上。工具描述中有详尽的提示词和大量示例。系统提示词中还有关于“何时使用某个工具”或如何在两个可以完成相同任务的工具之间进行选择的信息。</p><p data-pid="Mz7sND0i"><b>Claude Code 中的工具：</b></p><ul><li data-pid="hH94gX5R">• Task</li><li data-pid="9unv4EPR">• Bash</li><li data-pid="aDgnhlns">• Glob</li><li data-pid="Z5f-TFXC">• Grep</li><li data-pid="Hv8SOBru">• LS</li><li data-pid="sqeQv6_G">• ExitPlanMode</li><li data-pid="BRrcda7L">• Read</li><li data-pid="0A33oHOW">• Edit</li><li data-pid="XSipemcO">• MultiEdit</li><li data-pid="A3yBN8ty">• Write</li><li data-pid="_G9ib0Ok">• NotebookEdit</li><li data-pid="cTCoRq6_">• WebFetch</li><li data-pid="Nd6XWYqa">• TodoWrite</li><li data-pid="PzDAOk5n">• WebSearch</li><li data-pid="B_hyn4cm">• mcp_ide_getDiagnostics</li><li data-pid="CW3rMOvh">• mcp_ide_executeCode</li></ul><p data-pid="la8H9QnC">3.3 让智能体管理一个待办事项列表</p><p data-pid="eqm_h1x9">这样做有很多好处。上下文退化是长时运行的 LLM 智能体中的一个常见问题。它们一开始满怀热情地解决一个难题，但随着时间的推移，它们会迷失方向，最终输出一堆垃圾。</p><p data-pid="9T97z6yt">目前智能体设计中有几种方法来解决这个问题。许多智能体尝试过明确的待办事项（一个模型生成待办事项，另一个模型实现它们），或者多智能体交接+验证（PRD/PM 智能体 → 实现者智能体 → QA 智能体）。</p><p data-pid="BgeKk8Ob">我们已经知道，由于种种原因，多智能体交接不是一个好主意。CC 使用了一个明确的待办事项列表，但这个列表是由模型自己维护的。这让 LLM 保持在正轨上（它被强烈提示要频繁参考待办事项列表），同时给予模型在实现过程中随时修正路线的灵活性。这也有效地利用了模型的多模态思维能力，可以即时拒绝或插入新的待办事项</p><p data-pid="gFCAQi_G">4.1 语气和风格</p><p data-pid="dl_iGo6r">CC 明确地尝试控制智能体的美学行为。系统提示词中有关于语气、风格和主动性的部分——充满了指令和示例。这就是为什么 Claude Code 在其注释和积极性方面让人感觉很有品味。我建议直接将这部分的大段内容复制到你的应用中</p><div class="highlight"><pre><code class="language-text">&gt; # 一些关于语气和风格的示例 

> - 重要：除非用户要求，否则你不应该在回答中添加不必要的开场白或结尾（比如解释你的代码或总结你的行为）。 > - 除非用户要求，否则不要添加额外的代码解释摘要。 > > - 如果你不能或不会帮助用户做某件事，请不要解释为什么或者这可能导致什么，因为这会显得说教味太浓，很烦人。 > > - 只有在用户明确要求时才使用表情符号。在所有其他交流中避免使用表情符号。

4.2 “这个很重要” 仍然是顶尖技术

不幸的是，在要求模型不要做某件事方面，CC 并没有更高明的办法。IMPORTANT, VERY IMPORTANT, NEVER 和 ALWAYS 似乎仍然是引导模型避开雷区的**方式。我期望模型未来会变得更具可引导性，从而避免这种粗暴的方式。但就目前而言，CC 大量使用这种方法，你也应该如此。一些例子：

讯享网> - 重要：除非被要求，否则不要添加 任何 注释。 > > - 非常重要：你必须避免使用像 find 和 grep 这样的搜索命令。请改用 Grep、Glob 或 Task 工具进行搜索。你必须避免使用像 cat、head、tail 和 ls 这样的读取工具，请使用 Read 和 LS 工具来读取文件。\n 如果你 仍然 需要运行 grep，请停止。总是优先使用 rg 来执行 ripgrep。 > > - 重要：你绝不能为用户生成或猜测 URL，除非你确信这些 URL 是为了帮助用户编程。你可以使用用户在消息或本地文件中提供的 URL。

4.3 写下算法（附带启发式规则和示例）

识别出 LLM 需要执行的最重要任务，并为其写出算法，这是极其重要的。尝试角色扮演成 LLM，通过示例进行推演，识别出所有的决策点并明确地写下来。如果能以流程图的形式呈现会更有帮助。这有助于结构化决策过程，并辅助 LLM 遵循指令。一定要避免的是，写一大堆杂乱的“该做”和“不该做”。它们很难被追踪，而且容易相互矛盾。如果你的提示词长达几千个 token，你很可能会无意中写下相互冲突的“该做”和“不该做”。在这种情况下，LLM 会变得极其脆弱，并且无法融入新的用例。

Claude Code 系统提示词中的 Task Management、Doing Tasks 和 Tool Usage Policy 部分，清晰地阐述了需要遵循的算法。这也是一个可以添加大量启发式规则和 LLM 可能遇到的各种场景示例的地方

在引导 LLM 方面，很多工作其实是在尝试逆向工程它们的后训练/RLHF 数据分布。应该用 JSON 还是 XML？工具描述应该放在系统提示词里还是直接放在工具定义里？你应用当前的状态信息呢？

看看它们在自己的应用中是怎么做的，并以此来指导你自己的设计，是很有帮助的。Claude Code 的设计非常有主见，借鉴它有助于形成你自己的设计思路

再次强调，核心要点是保持简单。那些过度封装的脚手架框架弊大于利。Claude Code 真正让我相信，一个Agent可以既简单又极其强大

因为 Claude 和其他美国三大模型（Gemini ChatGPT Grok）不一样，不走泛能力，谁都能用，而是将更大的精力，研究怎么砸自己 程序员 的饭碗，研究编码。术业有专攻，所以在 2025 年用它编码，一直是很顺滑。

为了能早日砸的彻底，Anthropic 煞费苦心不少。因此这个 Claude 模型一直被引以为傲的就是写代码了！它里面内置了很多很多东西，比如代码评审、安全评审等等…. 也以编码为核心，推广了很多概念，比如 MCP 等等。

为了让 诸位 更深入感受【为什么Claude的代码能力会这么强？】，我今天使用一个单线故事，来讲一下 Claude 在背后做的几个大事件级的努力。

它是一个很优秀的编码工具，可惜大部分人都 浅尝辄止。更多关于它的玩法，还得去阅读官方文档：

最开始 Claude 依然是在网页上对话框对话。和其他大模型没什么两样。

但是这个办法不行，因为逐渐我们会发现我们会不断重复发相同的提示词，比如 部署的步骤、替换某个文件、根据某某规范评审代码、新加一个 class…. 做这么多重复工作是没必要的。

于是 Claude 整了个【提示词仓库】，也就是 Slash Commands 斜杠命令，把我们事先写好的一个个提示词，放到一个 markdown 文件里。复用，之后我们在用的时候，直接在对话框里 斜杠 ，然后输入命令名称和参数。

这对于一个常年敲代码的人，真的友好不少啊！

后来，我们的 AI Claude 写的代码多了，需要各种评审测试，性能评估，OK ，这个过程会占用很多很多时间，20分钟、1 个小时都绰绰有余。

于是天才们又引入了一个新概念，【主会话 与 子代理】，也就是 sub-agents，就是 你干你的，我干我的，我们互不干扰！

我们甚至可以一种事，多个协助来做，比如一个评审安全、一个评审规范、一个评审性能…. 或者一个负责一个文件夹，这样效率大大提高，多线齐下，10 分钟搞定过去 3 个小时的活。更重要的是，这个不影响主会话的事儿，不受干扰。而这些「小兵」把活儿干完，会把干活儿的结果汇总发给主会话，很有那种老板在办公室里指挥作战一样的感觉。

多任务并行、上下文隔离！

（要注意一件事，子代理 sub-agents 里不能调用 sub-agents，也不能调用 Commands，否则会套娃。 ）

代码规范，也会一直在更新。而代码规范一般是一个工程项目的核心！一动，其他都得跟着动，各种命令提示词也会跟着动，而且由于提示词都是自然语言写的，维护起来比维护代码还要吃力！现在我们把麻烦移到了提示词维护工程上。

怎么解决这个问题？

天才们又发明了 MCP 这个玩意儿！这样 AI 能从文档系统里自己去查找最新的规范。你只需要部署一个 MCP Server 就可以！

MCP（Model Context Protocol）是一种基于 HTTP 的 JSON-RPC 协议，也就是我们常定义的 JSON 结构的后端接口。设计好 MCP Server 后，AI 就能通过 Server 接口获取到最新的数据。

当然，MCP 的发明初衷是做这个的，而现在已经发展成了 AI 和各个各界形色各异的软件打交道的工具！不仅可辅助查询规范，还能辅助评审，比如把结果发到 飞书 或者外企更喜欢的 slack 里！

MCP 主要用于接口鉴权的通知推送、少量数据的拉取。

然而，我们又无法确定 MCP 返回的内容，是否会「超载」？或者说浪费大量的 token 数，导致 上下文膨胀事件的发生？

怎么搞？天才想到，把内容先下载下来，先不急着去读，而是分次按需去阅读。

这便是【渐进式披露】 Agent Skills ！我们下载 规范 是使用 curl 这个纯粹的拉取命令，先把规范下载到 tmp 目录，然后分段读取。

这个 Agent Skills 非常适合 复杂任务处理，大量的上下文处理。当然，它的初衷是解决 MCP 的这个问题，但后台它索性就是啥都能做了，能帮你干活，MCP 当手和脚，剪视频、发文章、发评论、制作各种垃圾东西….. 一种初代 AGI。

Skills 起来后，我个人明显感受到各行各界业界的产能在10倍 ヽ(；´Д｀)ﾉ，甚至100倍增长。 网络的帖子开始海量增加，产研团队的产能开始十倍百倍增长。产能翻百倍，产出的垃圾也翻了百倍。skills有很强的泛化继承能力，而且易迁移，领域专家转化为 skill， 一下就放大了，现在是需要更多领域专家来构建 skill。

然而现在你的工作流给搞的非常完美（额… 其实就是整理调试了一大堆可用的 markdown 提示词），能够去用 AI 写很多很多项目了，但如果现在你想搞一个新项目，怎么办？从 0 开始搞吗？

天才们又想到了【提示词共享】这个概念，也就是打包 提示词 成一个插件 plugin。发布到 plugin 市场里，学名叫 Plugin Marketplace。

用户如果需要最新的提示词，就可以直接在市场里拿到最新的提示词。虽然吧，这些所谓插件，本质是就是一大堆文本文件，但确实好用！

不是claude强，而是在大模型这个领域，很多厂商一开始就走错路了，客户真正需要的是一个专业能力极强的工具，哪怕它会出错，哪怕它有各种各样的问题，只要能快速给客户提供看似正确的方案也行，让客户自行去修改都行，而不是今天写个小说，明天生个图，这些领域的c端付费意愿极低。

大部分愿意付费的客户要的是专长，是能真正解决痛点的工具，Claude Code出来之后Stackoverlfow 直接流量暴跌到公司刚开业的时候了，现在基本上到死亡线了，明年差不多就RIP，你说claude code跟gemini 还有codex 解决了stakcoverflow的客户痛点没有？

这也是我经常说的，未来大模型的战场不在文字生成，也不在图片生成这些领域，在强人工智能到来之前，很多领域要被迫DSL化，各个领域的工程师要学会使用领域专用语言来描绘他们的工程项目，配合LLM，很多工程项目就能使用自然语言来生成DSL描述的方案，然后根据DSL得出初步工程方案，这样LLM能在很多领域发挥作用。

我在另一个回答里面提到，AI编程现在是如何吊打人类的。

Redis 之父称「手写代码不再必要」，你如何看待 AI 对编程的影响？ - AI Coding的回答 - 知乎

Redis 之父称「手写代码不再必要」，你如何看待 AI 对编程的影响？

我以机械设计领域举例，我本身是学习机械设计毕业，后面转行做的程序员。

在机械设计领域，很多装配设计都要涉及到装配规范，例如如下的几种配合情况，都是根据工程项目实际来设计方案的，机械设计工程师需要 参考行业经验来进行参数设计，但是如果用DSL领域语言来描述这种图片，就能极大提升工程设计的文字信息的密度，再配合机械设计工程师提供的工程化的语料文档，LLM能够快速结合当前项目的上下文给出精准的配合设计方案，这在以前是完全不可能想象的，这些繁琐的基本工作，需要工程师查阅各种相关文档，根据经验参数以及公式来进行计算。

这里小小打个广告，如果你的网络环境使用claude code不方便，可以使用我建立的claude中转站

https://terminal.pub

进行购买，前面几个低价渠道都是逆向的，上游提供的稳定性质量不同，最后一个是帮朋友官方claude号池进行分发，买套餐下来，逆向3毛2一刀，官网号池1块4一刀，童叟无欺，市场均价

有paygo需求的，可以进我们的vibe-coding 微信群，一起交流vibe经验，顺带我可以提供一些paygo充值的折扣给你，paygo比套餐更方便