企业官网建设流程全解析

1. 跨端开发的老问题，为什么值得用 AI 重做一遍

做移动端的人对“跨端”这两个字大概都有点复杂情绪。业务要快，iOS、Android、Web、小程序一个都不能少；但真到了落地阶段，每个端一套 UI、一套逻辑、一套构建流程，人力像被撕成好几份。Kotlin Multiplatform 这类方案把共享逻辑这件事往前推了一大步，可它解决的主要还是“代码复用”，没有解决“开发流程本身还是人肉流水线”的问题。

Kuikly 是腾讯开源的一套跨端框架，基于 Kotlin Multiplatform，用一套代码去覆盖 Android、iOS、Web、小程序等多个端。它本身已经比“每个端重写一遍”高效很多，但真正让我感兴趣的是它和 AI 结合之后的样子——也就是这次要聊的 Kuikly AI。它想做的事情不是“给跨端加一个 AI 助手”这么简单，而是把 AI 变成整条开发生产线的一部分：从需求理解、代码生成、跨端适配，到构建、调试、验证，AI 都在流程里承担具体角色，而不是停在聊天窗口里给你贴一段代码。

关键词里出现了 MCP Server、Kotlin Multiplatform、AI Agent 这些词，其实已经把技术轮廓勾出来了。MCP（Model Context Protocol）是让 AI 模型能够安全、结构化地调用外部工具和数据的协议，把它接到 Kuikly 的工程体系上，AI 就不再是“只会说话”，而是能真正读工程、改代码、跑构建、看结果。这套组合的价值在于：跨端开发里那些重复度高、规则明确、但又特别耗时的环节，终于可以交给一条可编排的 AI 原生流水线去做。

这篇文章适合两类人看。一类是正在用或准备用 Kuikly / KMP 做跨端、想搞清楚 AI 到底能帮上什么忙的工程师；另一类是对 AI Agent、MCP Server 感兴趣，想知道怎么把大模型能力接进真实工程流水线、而不是停留在 Demo 阶段的技术负责人。我会尽量把“为什么这么设计”“实际怎么落地”“哪些坑我踩过”讲清楚，而不是只给一堆概念。

2. Kuikly AI 到底在流水线的哪些环节动了刀

2.1 先分清：代码复用和流程复用是两回事

很多人第一次接触跨端，会默认“一套代码跑多端”就等于效率翻倍。实际做过就知道，代码复用省下的是“写业务逻辑”的时间，但一个功能从需求到上线，写代码可能只占一半。剩下的时间花在哪？花在查文档、对齐各端差异、写适配层、调构建脚本、跑真机验证、修那些只在某一个端出现的诡异 bug。

Kuikly 解决的是前半段——用 Kotlin 写一份逻辑，编译到多个端。Kuikly AI 想解决的是后半段——把“人围着流程转”变成“流程自己往前跑，人只在关键节点做决策”。这就是我理解的“AI 原生生产线”：不是给现有流程贴一个 AI 标签，而是让 AI 成为流程的默认执行者。

2.2 一条 AI 原生生产线的四个关键工位

把 Kuikly AI 拆开看，它在流水线上主要占四个位置，每个位置解决的问题都不一样：

这张表不是纸上谈兵。真正让这套东西跑起来的，是 MCP Server 把“工程能力”暴露成了 AI 能调用的工具。没有这一层，AI 再聪明也只能猜；有了这一层，AI 能读文件、能跑命令、能看结果，才谈得上“生产线”。

2.3 为什么是 MCP，而不是自己写一堆接口

这里要解释一个关键选型。你完全可以自己写一套 HTTP 接口，让 AI 去调。但 MCP 的价值在于它把“工具描述”标准化了：每个工具叫什么、参数是什么、返回什么，模型能直接理解，不需要你为每个模型单独适配一遍。Kuikly 工程里那些操作——读某个模块的源码、查某个 API 的跨端支持情况、触发一次构建——都可以包装成 MCP 工具。

我自己的体会是，MCP 最大的好处不是“省事”，而是“可组合”。当工具是标准化的，AI Agent 就能自己决定先调哪个、后调哪个，遇到失败还能换一个工具重试。这种自主编排能力，才是“生产线”和“脚本”的本质区别。脚本是死的，Agent 是活的。

3. 把 MCP Server 接进 Kuikly 工程：环境准备里最容易翻车的地方

3.1 工程结构要先理清楚，别急着接 AI

我见过太多人一上来就想着“怎么让 AI 写代码”，结果工程本身一团乱，AI 读进去全是噪音。接 MCP Server 之前，先把 Kuikly 工程的结构理清楚：哪些是共享模块（commonMain），哪些是各端特有实现（androidMain、iosMain 等），构建脚本放在哪，产物输出到哪。

这一步不是形式主义。MCP 工具要读工程，它得知道“去哪读”。如果你的共享逻辑和端特有逻辑混在一起，AI 生成的代码很可能放错位置，编译直接挂。我的建议是，先画一张工程模块图，标清楚每个目录的职责，再决定哪些目录要暴露给 AI。

3.2 MCP Server 的配置：参数少即是多

配置 MCP Server 的时候，新手容易犯的错是“把所有能力都打开”。工具越多，模型选择越困难，出错概率反而上升。我的做法是分阶段开放：

• 第一阶段只开放“只读”工具：读文件、查目录、搜索符号。让 AI 先能看懂工程。
• 第二阶段开放“构建与测试”工具：触发编译、跑单测、读日志。
• 第三阶段才开放“写”工具：改文件、生成代码。

这样做的理由是，AI 在“看不懂工程”的阶段就去改代码，几乎必然出错。先让它读，再让它写，符合人的学习曲线，也符合 Agent 的可靠性要求。

提示：MCP Server 的权限边界一定要卡死。只读工具和写工具分开配置，写操作最好加上“先备份再修改”的机制，避免 AI 一次误操作把工程改乱。

3.3 一个容易忽略的细节：上下文窗口和工程规模

Kuikly 工程稍微大一点，源码量就上来了。AI 的上下文窗口是有限的，你不可能把整个工程塞进去。这时候 MCP 的“按需读取”就很重要——AI 需要哪个文件才读哪个，而不是一次性全加载。

实操上，我会给 MCP Server 配一个“符号索引”工具，让 AI 先通过索引定位到相关文件，再精读。这比让它盲目搜索高效得多。索引可以基于 Kotlin 的编译产物或者简单的文本索引来做，关键是让 AI 有“地图”，而不是在森林里乱撞。

4. 让 AI 写出能编译的 Kuikly 代码：提示词和上下文怎么给

4.1 通用大模型写 Kotlin 的问题在哪

直接让通用大模型写 Kuikly 代码，结果通常不能直接用。原因有三个：第一，Kuikly 有自己的 API 约定和目录规范，模型没见过；第二，跨端代码要考虑各端差异，模型容易写出“只在 Android 能跑”的代码；第三，模型不知道你工程里已有的工具类和封装，容易重复造轮子。

所以关键不是“换个更强的模型”，而是“把工程上下文喂对”。这也是 MCP Server 存在的意义——它让 AI 在生成代码前，能先读到工程里已有的模式。

4.2 提示词要包含的三类信息

我总结下来，让 AI 生成可用 Kuikly 代码的提示词，至少要包含三类信息：

1. 工程约定：目录结构、命名规范、共享模块和端模块的边界。这些可以写成一段固定的“系统提示”，每次调用都带上。
2. 参考实现：让 AI 先读一个已有的类似功能，照着它的模式写。这比任何文字描述都管用。
3. 验收标准：明确告诉 AI“生成后要能通过编译”“不能引入新的端特有依赖”。有了标准，AI 在生成时会自我约束。

一个实际的提示词骨架大概是这样：

你正在一个 Kuikly 跨端工程中工作。 共享逻辑放在 commonMain，端特有实现放在对应端目录。 请先阅读 [参考文件路径]，理解本工程的代码风格。 现在实现以下需求：[需求描述] 要求： - 只使用 commonMain 中已有的依赖 - 如需端差异，使用 expect/actual 机制 - 生成后说明你修改了哪些文件

4.3 生成之后必须做的验证动作

AI 生成代码只是第一步，验证才是关键。我的流程是：生成 → 编译 → 读报错 → 让 AI 根据报错修复 → 再编译。这个循环可能跑两三轮，但比人工从头写快得多。

这里有个经验：不要让 AI 一次改太多文件。改动范围越大，出错后越难定位。我通常让它一次只动一个模块，编译通过再动下一个。慢是慢一点，但稳。

5. 跨端适配这个老大难，AI 能帮到什么程度

5.1 端差异的本质：不是代码不同，是能力不同

跨端最烦的不是“写两遍”，而是“两个端的能力不一样”。比如某个系统 API 只有 Android 有，iOS 要用另一套；某个 UI 组件在小程序上表现不同。这些差异靠人记很容易漏，靠文档查又慢。

AI 在这里的价值，是它能基于一份“端能力描述”去判断：这段代码在目标端能不能跑，不能跑的话该用什么替代。这份描述可以是结构化的表格，也可以是工程里已有的 expect/actual 声明。关键是让 AI 有据可依，而不是凭感觉。

5.2 用 expect/actual 做适配，让 AI 填 actual 部分

Kotlin Multiplatform 的 expect/actual 机制天生适合做端适配。我的做法是：人来定义 expect 接口（因为这是架构决策），让 AI 去填各端的 actual 实现（因为这是重复劳动）。

比如定义一个获取设备信息的 expect 函数，AI 分别生成 Android 和 iOS 的 actual 实现。因为接口是固定的，AI 只需要关注“这个端怎么拿到这个信息”，任务边界清晰，出错率低。

5.3 适配结果怎么验证：别只信编译通过

编译通过不代表适配正确。有些端差异是运行时的，编译期发现不了。所以验证要分两层：编译期验证交给 AI 自动跑，运行时验证还是得靠真机或模拟器。

我的折中方案是，让 AI 生成适配代码的同时，生成对应的单元测试或简单的验证用例。测试跑通，至少说明逻辑层面没问题，剩下的真机验证再人工补。这样能把人工验证的范围缩小很多。

6. 构建、调试、修复：Agent 循环怎么跑才不失控

6.1 构建失败时，AI 读日志的正确姿势

构建日志往往很长，直接丢给 AI 效果不好。我的做法是先用 MCP 工具做一层过滤：只提取 error 和 warning 级别的行，再交给 AI。这样既省上下文，又让 AI 聚焦在真正的问题上。

AI 拿到精简后的报错，结合它读过的代码上下文，通常能给出靠谱的修复建议。但要注意，有些报错是“连锁反应”——一个根因引发一堆错误。这时候要让 AI 先找根因，而不是逐个修表面错误。

6.2 Agent 循环的刹车机制

Agent 自己跑构建、自己修、自己再跑，听起来很美，但必须有刹车。我设了三条线：

• 最大循环次数：比如 5 轮，超过就停下来交给人。
• 改动范围限制：单轮改动超过 N 个文件就暂停。
• 关键文件保护：构建脚本、配置文件这类，AI 只能建议不能直接改。

没有刹车机制的 Agent，很容易陷入“改一个错、引入两个错”的死循环。这不是 AI 不行，是流程设计的问题。

6.3 修复建议的可信度怎么判断

AI 给的修复建议，不能无脑采纳。我的判断标准是：它能不能解释“为什么这样改”。如果只是“把 A 改成 B”，但说不出原因，我会打个问号。如果它能说清“因为这里用了端特有 API，在共享模块里不可用，所以改成 expect/actual”，那可信度就高很多。

这个判断标准其实也反过来指导提示词设计——我会在提示词里要求 AI“解释修改理由”，逼它想清楚再动手。

7. 实测下来，这套流水线真正省时间的地方在哪

7.1 省时间的不是“写代码”，是“查和试”

跑了一段时间之后，我发现 AI 省下的时间，大头不在“生成代码”，而在“查资料”和“试错”。以前遇到一个跨端 API 不确定能不能用，要翻文档、搜 issue、写个小 Demo 试。现在 AI 结合工程上下文和 MCP 工具，几秒钟就能给出判断，还能顺手生成验证代码。

这个变化的意义在于，它把工程师从“信息检索”里解放出来，让人能专注在架构和决策上。写代码这件事本身，反而成了流水线里比较快的一环。

7.2 哪些环节 AI 还不靠谱

也得说清楚 AI 目前不靠谱的地方。复杂的状态管理、涉及多模块交互的重构、性能敏感的代码，AI 给的建议经常需要大改。这些环节我目前还是人工主导，AI 只做辅助。

还有一个坑是“过度自信”。AI 有时候会用很确定的语气给一个错误答案。所以关键决策点，一定要人工复核，不能因为它说得笃定就信。

7.3 团队协作里的实际影响

这套流水线对团队协作的影响，比我想的大。以前跨端开发，各端工程师各管一摊，沟通成本高。现在共享逻辑和适配层由 AI 辅助生成，规范统一了，各端工程师更多是在“审核”和“补充端特有逻辑”，而不是从头写。角色从“实现者”往“审核者”和“架构者”偏移。

这个转变需要适应，但方向是对的。人做判断，AI 做执行，各司其职。

8. 如果你也想搭一条，我的几条实操建议

第一，别追求一步到位。先把 MCP Server 的只读能力接好，让 AI 能看懂工程，这一步的收益就已经很明显了。写能力可以慢慢开。

第二，提示词和工程规范要一起维护。工程规范变了，提示词也得跟着改，否则 AI 会按老规范生成代码。我习惯把工程约定写成一个文件，提示词直接引用它，改一处就够。

第三，验证环节不能省。AI 生成的东西，编译、测试、真机验证，该走的流程一个都不能少。省了验证，后面修 bug 的时间会加倍还回来。

第四，把 AI 当同事而不是工具。工具是你让它干啥它干啥，同事是你可以让它先想想、给建议、再动手。提示词里多问一句“你觉得这样合理吗”，结果往往更好。

这套东西我还在持续打磨，Kuikly 和 MCP 的生态也都在快速演进。但有一点我比较确定：跨端开发的未来，不是“写更少的代码”，而是“让流程自己跑起来，人只做关键决策”。Kuikly AI 这条路线，至少方向是对的。