常见问题

MS WebX 是一家 IT 公司。我们开发网站和 Web 平台、iOS 与 Android 原生应用，并把 AI 集成进去，同时负责让成果能被搜索到的 SEO 工作。我们还在为客户使用的同一套平台上运营自己的产品，因此在别人依赖它之前，这套底座已经在真实生产环境中跑过。

两者都是，这是有意为之。我们提供的东西先在自己的产品里跑：多语言页面系统、API 层、后台工具、数据分析。客户项目不会从未经验证的底座开始；核心一旦出问题，先发现的是我们，而不是客户。

有三种方式，都不依赖我们在这里的说法。本站的法律声明页面载有公司的正式信息。我们自己的产品是公开的，不用联系我们就能直接使用。联系页面直达写代码的人，中间没有客服中心。

你描述目标，而不是技术方案。我们会一直问到范围真正清楚，然后在动手之前写下来。如果我们认为你要的做法通向错误的方向，会在你付钱之前说出来——这场对话比它避免的返工便宜得多。

以小而可见的步骤推进。工作成果会先进到一个你随时能用浏览器打开的预发布环境，只有你点头才会上线。没有人会在项目结束时才第一次看到成品——到那时任何改动都很贵。

我们做的东西是要长期维护的：依赖更新、监控，以及业务变化带来的改动。这些之后由我们继续做，还是由你们自己的团队接手，会在项目里说清楚，不会事后默认。任何东西都不会做成只有我们能碰的样子。

我们先读现有代码，然后直说：按系统的整个生命周期算，是继续用更划算，还是换掉更划算。两种结论都出现过——接手来的代码常常本身没问题，只是文档太差。我们不会条件反射地建议重写，因为重写是别人能卖给你的最贵的东西。

服务端 PHP，浏览器端 TypeScript，iOS 与 Android 用 Flutter，数据用 MariaDB，服务层是 nginx 和 FrankenPHP。刻意选用当下且广为人知的技术，这样我们之后谁都能接手维护。质量靠机器把关，而不是靠自觉：静态分析以最严格的等级运行，且没有豁免清单，另有两百多条项目自有规则，代码一偏离就被拒绝。

一套代码：共享的内核，加上每个品牌之上一层很薄的定制。品牌各有自己的设计、内容、数据库和域名；而安全修复、性能优化和内核新功能会同时到达所有站点，不需要逐个手工搬运。新增一个品牌是配置和内容的事，不是 fork。

是，而且比这句话通常的意思更严格。API 只在 PHP 里定义一次，Web 的 TypeScript 客户端和 App 的 Dart 客户端都由这份定义生成。两者都不允许手写——手写的 API 类型会被 linter 拒绝。所以 App 不可能悄悄和服务端对不上：不一致会让构建失败，而不是让线上出事。

是真的。每个页面按语言各有独立的记录，文本和网址都是各自的——这份常见问题在英文下位于 /frequently-asked-questions，在德文下位于 /de/haeufig-gestellte-fragen，而不是藏在一个翻译参数后面。因此每种语言都能按当地人真正的搜索说法来写，也能只改一种语言而不动其余十七种。

它就是为此而建的。每个品牌有自己的数据库、自己的域名和自己的内容，所以一个品牌读不到另一个品牌的数据，一处内容出错也不会跑到另一处。共享的是引擎部分：路由、API 层、后台工具，以及安全方面的工作。

Cannabivo 已经上线：一个社交俱乐部的搜索引擎，访客按地点查找并比较俱乐部，俱乐部自行维护自己的资料。Steel 是面向工程与采购的材料等效对照参考，目前仍在开发中，尚未对外开放。两者都运行在本节所描述的同一套系统上。

归你们。我们处理这些数据，只为运行你们委托的服务，不做别的用途。不会和其他客户的数据混在一起，不出售，也不会用来向你们的用户投放广告。合作结束时，数据由你们带走。

连接走 HTTP/3，域名已进入浏览器预置的 HSTS 列表——也就是说，浏览器从第一次访问起就拒绝以明文通信，连跳转都没有被劫持的机会。密钥交换是后量子的：X25519 与 ML-KEM-768 组合。这样选择，是为了让今天被截获的流量，在量子计算机有能力发起攻击时仍然扛得住。

绝不放进源代码——这由构建流程强制，而不是靠自觉：把密钥硬写进代码，在合并之前就会被拒。机密以加密形式存放在配置存储中，运行时只在真正需要的地方解密。因此轮换一把密钥是在一个地方改一次，而不是在整个代码库里翻找。

能。应用事件、错误和管理操作都写入数据库，而不是散落在各台服务器上的文本文件，所以真的可以检索。管理操作会记录谁做的、改了什么、什么时候。「上个月这个价格是谁改的」这种问题有答案，而不是靠猜。

非必要 Cookie 只在访客同意之后才会设置，选择会被记录，并且我们做的每个站点都有页面可以随后修改或撤回。拒绝只需一次点击，不用在设置菜单里翻找；选择拒绝的访客，看到的仍然是一个能正常使用的网站。

指模型在你的产品里承担一件明确的工作，并且可衡量地胜过替代做法：分拣进来的消息、起草由人最后拍板的文本、让搜索理解用户想表达什么而不是敲了什么。它不是往做完的网站上贴一个聊天气泡。真正有用的问题从来不是「能不能加 AI」，而是「现在哪件重复的事在消耗你的时间」。

在内容上。我们的多语言资料借助模型来生产和保持更新，然后在公开之前按语言逐一人工审校——从不把模型输出直接发出去。这也是我们谈 AI 时比较克制的原因：从自己的实践里，我们清楚它在哪里靠得住，在哪里还离不开人。

在动手之前，我们会以书面形式写明：哪家服务商处理哪些数据、哪些会被保留。如果这个答案你们不能接受，这个功能就换一种设计，或者干脆不做。不会有数据以你们没同意的方式离开你们的系统——「不知道它被发出去了」这种结果，我们不打算制造。