Serena 在跨文件重构中的真实增益:GLM 5.1 对 Tianshou 代码库的 20 项任务对比评测

发布时间:2026/9/11 18:40:37
Serena 在跨文件重构中的真实增益:GLM 5.1 对 Tianshou 代码库的 20 项任务对比评测 Serena 在跨文件重构中的真实增益GLM 5.1 对 Tianshou 代码库的 20 项任务对比评测【免费下载链接】serenaA powerful MCP toolkit for coding, providing semantic retrieval and editing capabilities - the IDE for your agent项目地址: https://gitcode.com/GitHub_Trending/ser/serena本评测报告由 GLM 5.1运行于 Claude Code CLI 中的编码 AI Agent生成被测代码库为 Tianshou——一个约 2.6 万行、43 个源文件的 Python 强化学习库评测日期为 2026-04-14。该评测属于 Serena 项目「评估」章节中 JetBrains 后端系列评测之一完整的方法论与提示词见 评估方法论 与 评估提示词。这篇文章拆解 GLM 5.1 在真实 Python 代码库上、用「Serena 语义工具」与「Agent 内置工具Read/Edit/Grep/Glob/Bash」双轨并行执行的约 20 项任务的量化对比哪类操作被 1 次原子调用取代了 8 步手写链路哪类操作毫无增益以及 token 效率的交叉点在哪里。读完你会得到一张清晰的「何时用 Serena、何时用内置工具」的决策表并能把结论映射到 Serena 的源码实现上。1. 结论速览Serena 改变了什么GLM 5.1 把全部任务按三类归档结论如下(a) Serena 带来新增能力的任务跨文件重构重命名、移动从 N 次「读取-查找-编辑-验证」循环坍缩为单次原子调用语义查询类型层级、查找实现、查找引用返回结构化、符号级精确的结果这是纯文本搜索无法在无需人工过滤的前提下做到的符号级寻址name path在多次编辑后依然稳定消除了多步骤会话中「行号失效返工」的问题。(b) Serena 适用但无改善的任务单文件小改动改一行错误信息、用replace_all重命名局部变量、在已知插入上下文时新增函数两者速度相当。对一个 22 行方法做 1 行微调时Edit只需发送约 200 字符而 Serena 的replace_symbol_body需要约 800 字符整个方法体。但这一开销在「大方法整体重写」场景反转——Serena 只需发送新方法体Edit则需要同时发送旧新。(c) Serena 设计范围之外的任务读取非代码文件config、TOML、文档、自由文本模式搜索FIXME、魔法常量、日志字符串、Shell 操作、git 工作流。这些是内置工具的领地不是 Serena 的短板——它们本就不在 Serena 的设计范围内。总体判定Serena 在两个领域带来了可量化、可感知的能力增量——跨文件重构1 次调用 vs 5–8 次与语义代码查询结构化、符号精确的结果 vs 扁平文本匹配而在单文件小改动与非代码任务上两者没有有意义的差异。这一判定与 Serena 工具实现的结构完全吻合跨文件原子重构依赖 JetBrains 语言服务器后端的原生重构能力见 jetbrains_plugin_client.py 中/moveSymbol、/renameSymbol、/safeDelete、/inlineSymbol等端点的封装而语义查询则建立在符号检索器之上相关工具类集中在 symbol_tools.py。2. 分领域增量对比2.1 跨文件重命名1 次调用取代 5–8 次变化把CollectStatsBase重命名为BaseCollectStats涉及 4 个文件、10 处出现。Serena 只用 1 次调用内置工具链需要 1 次 Grep 3 次 Read 4 次 Edit 8 次调用。频率中等。任何非平凡的重命名都会触及 3–10 个文件。单次价值节省 4–7 次调用并消除「链路中途失败导致部分更新」的风险。原子性Serena 的重命名是「全有或全无」。内置链路不是——如果 4 次 Edit 中的第 3 次失败就会有 2 个文件已更新、2 个未更新。从源码看Serena 的跨文件重命名并不自己做文本替换而是把 name path 与目标文件名转发给 JetBrains 插件执行语言服务器级重构RenameSymbolTool 调用code_editor.rename_symbolJetBrains 侧对应rename_symbol封装/renameSymbol端点。语言服务器会在整个项目范围内统一改写这正是「原子性」与「零误伤」的来源。2.2 符号移动1 次调用取代 5 次变化把_nullable_slice移到另一个模块Serena 1 次调用完成移动定义 同时更新源文件与目标文件的 import。内置等价操作读函数 → 写入目标文件 → 编辑源文件删除定义 增加 import→ 编辑目标文件增加依赖 import 5 次调用。频率低。模块重组不常发生。单次价值节省 4 次调用并自动化了最容易出错的一步——把 import 写对。注意事项移动工具制造了一个循环 import源文件 import 目标文件目标文件又 import 源文件。工具不检测、也不阻止这种情况。2.3 查找引用符号精确 vs 文本匹配变化用 Serena 查找CollectStats的引用返回 10 个按语义分类的结果IMPORT_ELEMENT、REFERENCE_EXPRESSION、NAMED_PARAMETER 等对LoggedCollectStats零误报Grep 返回 70 行包含来自LoggedCollectStats的误报以及 docstring/注释噪声。频率高。「谁在用它」是最常见的代码库问题之一。单次价值免去人工过滤误报。代价是输出体积Serena 输出约 64KB带上下文片段Grep 约 5KB——这是「精确度 vs 冗余度」的取舍。实现层面FindReferencingSymbolsTool 先通过find_unique定位符号见 symbol.py 中find_referencing_symbols再基于引用位置向语言服务器请求引用并按relative_path kind分组输出每条引用还会附带引用点前后各 1 行的代码片段content_around_reference这正是输出偏大的来源也是「零误报 可读上下文」的代价。2.4 类型层级1 次调用 vs 2 次 grep-and-parse 循环变化获取BaseCollector的完整类型层级父类型链ABC → object子类型链Collector → AsyncCollectorSerena 1 次调用。内置做法解析类定义行拿基类 grep 继承者 递归 2–3 次调用且无法访问外部库类型。频率中等。在不熟悉的代码中导航时很常见。单次价值节省 1–2 次调用并返回内置工具不迭代就无法产出的传递闭包。JetBrains 侧对应/getSupertypes与/getSubtypes两个端点jetbrains_plugin_client.py均支持depth深度限制由 IDE 的类型解析引擎直接给出传递层级。2.5 结构概览层级化 vs 扁平变化对一个 1551 行的文件执行get_symbols_overview(depth1)1 次调用返回结构化层级类 → 方法 属性对^(class |def | def )的 Grep 返回扁平 60 行定义列表带行号但无属性信息、无嵌套关系。频率高。打开任何陌生文件的第一个动作。单次价值Serena 能展示 Protocol 字段、类属性与方法分组Grep 的行号便于导航但要理解结构需要更多人工工作。对应实现是 GetSymbolsOverviewTooldepth参数默认 -1 时按语言选择Java/Kotlin 为 1其他语言为 0返回按 kind 分组的紧凑 JSON并内置max_answer_chars截断与「符号种类计数」等渐进披露降级策略。2.6 方法体获取定向读取 vs 区间读取变化读取Collector._collect330 行只需 1 次find_symbol用 name path。内置做法先 Grep 得知行区间773–1103再Read(offset773, limit330)。频率高。「把这个方法展示给我」是日常操作。单次价值Serena 使用稳定寻址name path内置使用会随编辑失效的临时行号。单次读取时差别很小但在「编辑后再次读取」的工作流中会被放大。find_symbol的工具定义见 FindSymbolTool支持 name path 模式简单名method、相对路径class/method、绝对路径/class/method、重载索引MyClass/my_method[1]、include_body、substring_matching、include_kinds/exclude_kinds过滤以及max_matches上限。2.7 单文件重命名无实质差异变化重命名_nullable_slice单文件内 4 处出现Serena rename 1 次调用Edit replace_all 1 次调用。结果完全相同。频率高。单次价值零。两个工具集都处理得一样好。2.8 小改动1–3 行Edit 更省 token变化改一个 22 行方法里的错误信息Edit发送约 200 字符旧字符串 新字符串Serenareplace_symbol_body发送约 800 字符整个方法体。频率非常高。单次价值每次小改动Edit省约 600 字符。这个对比在 50 行方法的整体重写时会反转。2.9 插入稳定地址 vs 文本锚点变化在refresh_all_sequence_stats之后插入新方法Serena 用 1 次insert_after_symbolname path无需行号Edit用 1 次 Read 1 次 Edit以周围上下文作为唯一性锚点。频率中等。单次价值省 1 次 Read。两者结果相同。insert_after_symbol的工具封装见 InsertAfterSymbolTool其文档明确提示「不要用于在赋值常量、字段之后插入」且插入内容从符号定义的下一行开始。小节判定Serena 的价值集中在跨文件操作与语义查询上。对单文件文本编辑内置工具同样能干而且通常更省 token。3. 按能力分组的详细证据3.1 代码库理解任务 1仓库概览— 两套工具用同样方法ls、find、目录列举。Serena 无优势。任务 2大文件结构概览collector.py1551 行步骤Serena内置调用get_symbols_overview(depth1)Grep ^(class \|def \| def )结果层级化14 个类、它们的方法、属性与模块级函数60 行扁平 class/function 定义列表带行号输出体积约 1.5KB 结构化 JSON约 3KB 文本下一步find_symbol(Collector/_collect, include_bodyTrue)— 直达Read(offset773, limit330)— 需预先知道行区间Serena 优势能展示 Grep 看不到的属性如CollectStats.collect_time、CollectStats.returns。层级嵌套让文件架构一目了然。内置优势行号可直接用于Read。扁平输出紧凑。判定Serena 单次调用提供严格更多的结构信息。对深层嵌套类或 dataclass 字段较多的文件差距更大。任务 3获取特定方法体步骤Serena内置前置条件已知 name pathCollector/_collect已知行号来自先前 Grep773调用find_symbol(name_pathCollector/_collect, include_bodyTrue)Read(offset773, limit330)发送载荷约 50 字符名字 路径约 30 字符offset limit接收载荷精确方法体约 330 行773–1102 行约 330 行正确性总是精确必须知道/猜对 limit判定在行号已知时功能等价。Serena 的 name path 寻址在多次编辑后优雅降级行号不会。任务 4查找CollectStats的所有引用指标Serenafind_referencing_symbols内置Grep调用次数11输出体积64KB带上下文片段约 5KB70 行误报0排除LoggedCollectStats5 行来自LoggedCollectStats噪声注释/文档少量docstring 被分类显著docstring、注释被匹配语义分类有IMPORT、PARAMETER、DECLARATION、REFERENCE无Serena 优势零误报语义分类把 import 路径与参数使用同代码引用分开呈现。内置优势输出小 10 倍视觉扫描更快。判定Serena 更精确但更啰嗦。回答「代码里谁在用」两者都行回答「如何安全重命名」Serena 的精确性是必须的。任务 5BaseCollector的类型层级指标Serenatype_hierarchy内置Grep 链调用次数12–3grep 子类、解析父类、递归结果ABC → object父、Collector → AsyncCollector子部分——只有直接父/子类型无传递链外部依赖能显示来自abc.pyi的ABC无法访问判定Serena 一次调用返回完整传递层级含外部库类型。内置做法需要迭代且无法检视外部依赖。任务 6外部依赖符号查找Serena 只有在已有先前工具结果给出路径时如type_hierarchy返回的ext:abc.pyi|16198efc才能读取外部依赖符号用search_depsTrue直接搜索numpy.array、torch.Tensor返回空结果——JetBrains IDE 索引仅限于语言服务器已解析的内容。 内置做法知道路径就可以Readsite-packages 文件但发现路径全靠手动。判定Serena 有轻微优势——外部符号可通过工具链访问但不能直接搜索。两个工具集都不让这件事变得容易。3.2 单文件编辑任务 7a小改动22 行方法内改 1 行指标EditSerenareplace_symbol_body前置条件1 次 Read6 行上下文1 次find_symbol取完整方法体发送载荷约 200 字符旧 新字符串约 800 字符完整方法体接收载荷成功消息OK总载荷编辑约 200 字符 读取约 300 字符 ≈ 500编辑约 800 字符 读取约 800 字符 ≈ 1600判定方法内小改动Edit 的 token 效率约为 Serena 的 3 倍。任务 7b中等重写20 行方法内改约 6 行指标EditSerenareplace_symbol_body发送载荷约 700 字符旧 新完整方法约 500 字符仅新方法体前置读取约 500 字符约 500 字符来自先前的find_symbol判定大致相当。中等重写时载荷收敛。任务 7c大重写55 行方法的整体重写Edit旧约 55 行 新约 55 行 发送约 110 行Serena只发送新方法体约 55 行。判定整体重写时 Serena 的 token 效率约为 2 倍且优势随方法体大小线性增长。replace_symbol_body在 ReplaceSymbolBodyTool 中实现工具契约明确要求「只有先用include_bodyTrue做过检索、确知方法体边界后才能替换」——这也是该工具必然多一次前置find_symbol的原因。值得注意的是它是一个EditingToolWithDiagnostics会在替换后自动拉取诊断信息作为结果的一部分返回。任务 8在现有函数后插入新函数步骤Serena内置1find_symbol(refresh_all_sequence_stats)确认目标Read(offset250, limit10)找插入点2insert_after_symbol(name_path, body)Edit(old_string锚点, new_string锚点新函数)总调用22发送载荷仅新函数体约 300 字符锚点上下文 新函数约 400 字符判定无实质差异。两者都需要 2 次调用结果相同。任务 9重命名私有辅助函数单文件4 处出现指标SerenarenameEditreplace_all调用次数11前置条件无必须先 Read 该文件结果4 处全部重命名4 处全部重命名判定功能等同都是 1 次调用。Edit 的「先读文件」要求通常已由此前的探索满足。3.3 多文件改动任务 10跨文件重命名CollectStatsBase→BaseCollectStats4 个文件、10 处出现步骤Serena内置查找引用自动1 次 Grep读取文件不需要3 次 ReadEdit 的前置要求应用编辑1 次重命名调用原子4 次 Edit每文件一次验证返回 Success手动4 条成功消息总调用181 grep 3 reads 4 edits判定Serena 把 8 次调用的人工管线变成 1 次原子操作。这是本次评测观察到的最大效率增益。任务 11把符号移到另一个模块Serena 的move工具把_nullable_slice从collector.py移到converter.py在源文件加 importfrom tianshou.data.utils.converter import _nullable_slice在目标文件加依赖 importfrom tianshou.data.collector import _TArrLike从源文件删除定义。内置等价操作读函数体 → 写入目标 → 编辑源文件删定义 加 import→ 编辑目标文件加依赖 import 5 次调用。问题移动造成了循环 import源 ↔ 目标。Serena 不检测、不阻止。判定Serena 自动化了最繁琐的部分import 管理但不防护循环依赖。省 4 次调用代价是需要人工复查循环 import。JetBrains 侧由/moveSymbol端点承载jetbrains_plugin_client.py要求插件版本至少为 2023.2.14通过targetParentNamePath与targetRelativePath指定移动目标。任务 12移动文件segtree.py移到父目录Serena 的move工具移动文件更新__init__.py中唯一一处直接 importtianshou.data.utils.segtree→tianshou.data.segtree其他文件prio.py、测试通过 re-export 引用无需改动。内置等价操作git mv grep 旧 import 路径 逐个编辑文件 3 次调用。判定Serena 省 1–2 次调用并自动发现哪些 import 需要更新。任务 12安全删除Serena 的safe_delete正确拒绝删除_HACKY_create_info_batch因为它在第 730 行有使用。propagatetrue模式删除符号 所有调用点对被测代码库中的所有符号都失败了。判定使用检查很有价值避免误删仍在使用的符号。传播propagation功能对被测 Python 符号不可用。实现上SafeDeleteSymbol 先用find_unique精确定位符号再向语言服务器请求全部引用位置一旦发现引用就返回形如Cannot delete, the symbol ... is referenced in: {...}的拒绝消息绝不执行删除——这就是「使用守卫」的源码级依据。JetBrains 端点在/safeDelete带deleteEvenIfUsed与propagate两个开关jetbrains_plugin_client.py。任务 13内联inlineSerena 的inline_symbol对所有被测符号_nullable_slice、BaseCollector/env_num都失败了。该工具对 Python 的内联支持似乎有限。判定本次未演示成功的内联。手动内联仍是唯一选项。3.4 可靠性与正确性任务 14作用域精度Serena 用 name path 区分BaseCollector/_collect、Collector/_collect与AsyncCollector/_collect对def _collect的 Grep 会同时命中三者必须人工按类过滤。判定Serena 的 name path 寻址消除了文本搜索无法解决的歧义。任务 15原子性Serena 的跨文件重命名是原子的1 次调用更新 4 个文件全有或全无。内置做法是 4 次独立 Edit——第 3 次失败时2 个文件已更新、2 个未更新。判定Serena 为跨文件操作提供原子性。内置链路天然非原子。任务 16成功信号两者都返回明确的成功/失败指示。无实质差异。判定持平。3.5 工作流影响任务 17在单文件内串联三次编辑Edit的文本匹配3 次顺序调用中间无需重读。文本锚点不受先前编辑导致的行号偏移影响。 Serenareplace_symbol_body3 次顺序调用中间无需重读。name path 寻址同样不受行号偏移影响。判定单文件串联编辑两者无实质差异。任务 18跨编辑的多步探索Serena 探索得到的 name path 结果在编辑后依然有效。内置的行号会失效但Edit用文本匹配而非行号因此实际影响仅限需要更新 offset 的Read调用。判定Serena 有轻微优势。name path 的稳定性省去编辑后重新扫描。3.6 非关注类任务任务 19读取非代码文件Serena 工具不适用。Read才是正确工具。任务 20自由文本模式搜索在整个代码库搜索FIXME|HACK|TODO是文本搜索。Serena 的语义工具不针对这类需求。Grep才是正确工具。判定这些任务牢牢属于内置工具领地。它们约占日常编码工作的 20–30%读配置、搜字符串、Shell 操作、git 工作流。4. Token 效率分析不同编辑规模下的载荷差异编辑类型Edit 载荷Serena 载荷胜者22 行方法内改 1 行约 200 字符约 800 字符Edit4 倍20 行方法内改 6 行约 700 字符约 500 字符大致相当55 行方法整体重写约 2200 字符约 1100 字符Serena2 倍330 行方法整体重写约 13,000 字符约 6,500 字符Serena2 倍被迫读取forced readsEdit编辑前必须先读取文件每文件增加约 300–2000 字符开销。Serena 编辑前无需读取name path 寻址。对已读过文件的单文件编辑这项为中性。对未读过的文件的跨文件操作Serena 省 3–4 次被迫读取。稳定寻址 vs 临时寻址Serenaname pathCollector/_collect跨编辑稳定探索结果始终有效。内置行号是临时的Read结果在编辑后失效Edit用文本匹配相对稳定。实际影响一次性编辑为低「编辑后再次读取」工作流为中等。判定小改动Edit胜token 效率 4 倍整体重写 Serena 胜2 倍跨文件操作 Serena 胜消除被迫读取。交叉点大约在「方法体改变量约 50%」低于它Edit更高效高于它 Serena 更高效。5. 正确使用下的可靠性与正确性匹配精度Serena 符号级精确——find_referencing_symbols(CollectStats)排除LoggedCollectStats本次未观察到误报。Grep 是文本匹配——CollectStats会命中LoggedCollectStats、CollectStatsBase和 docstring 引用需人工过滤。Edit 是文本匹配——replace_all替换精确字符串匹配对唯一符号名可靠对常见字符串可能过度匹配。作用域消歧Serena 用类作用域 name path 正确区分Collector/_collect与AsyncCollector/_collect内置的def _collect会命中所有实现必须人工核对类上下文。原子性Serena 跨文件操作原子单次调用、全有或全无内置多文件链路非原子一次调用失败即可能进入部分状态。外部依赖查找Serena 可通过其他工具返回的路径读取外部 stub如abc.pyi直接搜索search_depsTrue对torch.Tensor、numpy.array返回空受限于 JetBrains 已索引内容。内置可在知道路径后Readsite-packages 文件但没有语义索引。判定Serena 提供严格更精确的语义匹配与原子跨文件操作。外部依赖查找在两个工具集中都受限。6. 会话级工作流影响优势叠加的场景探索 → 编辑 → 再探索循环Serena 的 name path 结果在编辑后存活。长会话多次改动时省去每次编辑后的重新扫描。内置的文本匹配同样跨编辑存活Edit 用文本而非行号实际差距比表面看起来小。跨文件重构链重命名类 → 移动它 → 更新所有引用——Serena 的每次调用都是原子的并建立在前一次结果之上。内置则每步都要找全部位置、读文件、编辑——这正是 Serena 自动化的手动等价物。优势消减的场景单文件内重复小编辑Edit 的文本匹配同样稳定且小改动更省 token。Serena 无优势。只探索不编辑两者都能给出可用结果。Serena 更结构化但更啰嗦。非 Python 文件Serena 的 JetBrains 后端对 config 文件、Shell 脚本、Markdown、notebook 不提供价值。判定Serena 的优势在多步骤跨文件重构会话中叠加在单文件迭代编辑或非代码工作中不叠加。7. 独特能力清单原子跨文件重命名/移动——内置无对应物。最接近的手动流程是 grep-查找-编辑链路非原子且易错。频率中等。影响高消除部分更新风险。带分类的语义引用查找——find_referencing_symbols返回零误报、按用途类型import、parameter、declaration、reference分类的结果。内置 Grep 无法区分这些。频率高。影响中等省人工过滤。类型层级遍历——一次调用返回传递父/子类型链含外部库类型。内置需要迭代且够不到外部依赖。频率中等。影响中等。符号作用域方法体获取——按 name path 读取特定方法无需读取整个文件。内置Read需要行区间知识。频率高。影响低两者都 1 次调用差异在稳定寻址 vs 临时寻址。判定四项独特能力全部是语义代码操作。影响最大的是原子跨文件重构。它们都没有实用的内置等价物。8. Serena 范围之外的任务仅内置工具任务工具频率占日常工作量读取 config/TOML/yaml 文件Read高自由文本搜索日志字符串、TODO、URLGrep高按名称模式发现文件Glob中等Shell 命令git、pip、pytestBash高从零写新文件Write中等读取图片、notebook、PDFRead低内置专属任务约占日常工作的20–30%。其余 70–80% 涉及 Serena 语义工具可适用的代码阅读、编辑与导航。判定Serena 覆盖会话中的代码编辑与代码导航部分配置读取、文本搜索与 Shell 操作仍是内置工具领地。9. 实用使用规则Serena 用于任何跨文件重构重命名、移动、任何「谁在用这个符号」查询、任何类型层级导航、任何完整方法体重写以及任何需要零误报符号精确结果的场景。内置工具用于方法内小改动1–3 行、自由文本搜索、读取非代码文件、文件发现、Shell 操作。混合模式最高效用 Serena 探索overview、find symbol、find references用 Edit 做小型定向修改任何跨文件重构都用 Serena非代码任务与文本搜索用Read/Grep/Glob。这一组合同时捕获两个工具集的优势。判定最优工作流是——Serena 语义工具负责代码导航与跨文件重构内置 Edit 负责单文件小改动。两个工具集互补Serena 处理结构化代码操作内置处理文本与系统操作。附录调用次数汇总任务Serena 调用内置调用差值结构概览1 个文件110方法体获取110查找引用1 个符号110但 Serena 0 误报 vs Grep 5类型层级12–3−1 至 −2小编辑22 行方法内改 1 行11 读取11 读取0中等编辑20 行方法内改 6 行110插入新方法11 确认11 读取0单文件重命名4 处出现110跨文件重命名4 文件、10 处出现18−7把符号移到另一模块15−4移动文件 更新 import13−2安全删除使用检查11 grep0最大单项差值跨文件重命名省 7 次调用并提供原子性。如何复现与延伸本次评测属于 Serena 项目评估体系中的一环。评估采用「Agent 自我评估」方法论详见 评估方法论向任意 AI 编码 Agent 投递一份 评估提示词让它对任意代码库、用双工具集执行约 20 个任务并记录调用次数、载荷大小与前置步骤再用 汇总提示词 生成一句话结论。全部评测使用 Serena 的 JetBrains 后端评估结果索引 中对此有明确说明。你可以在自己的项目上以同一提示词重跑验证本文结论是否适用于你的 Agent 与代码库组合。【免费下载链接】serenaA powerful MCP toolkit for coding, providing semantic retrieval and editing capabilities - the IDE for your agent项目地址: https://gitcode.com/GitHub_Trending/ser/serena创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询