AI正以前所未有的速度重塑开发领域，AI工程化自然成为各业务团队优先探讨的命题。搜狗输入法团队从实际需求出发，在基于Kuikly的跨端项目中逐步探索并沉淀出一套AI工程化方案，目前已有不少需求按此流程完成开发并上线。我们希望通过此文分享其中的实践经验与思考，为同样在AI Coding工程化路上探索的团队提供一些可参考的思路。
Kuikly是腾讯内部广泛使用的跨端开发框架，它允许开发者使用Kotlin语言开发Android、iOS、鸿蒙、Web等多端应用。目前已在QQ、腾讯新闻、QQ音乐、搜狗输入法、QQ浏览器等20+业务深度使用，服务业务的总页面数超过1000个，日活用户超5亿，满足了这些业务在各种复杂场景下的需求。
一、背景：从Vibe Coding到工程化协作
在AI时代，各业务团队都在积极探索AI Coding，目标相似——希望实现从需求、生成到测试的一站式自动化愿景，达到“L3级别”的代码生成。网上各类Vibe Coding演示，从零开始搭建Demo应用的过程已经相当流畅，似乎印证了这一方向的可行性。
搜狗输入法的Kuikly跨端项目同样面临这样的机遇。作为一个横跨Android、iOS、鸿蒙、H5的复杂跨平台工程，跨端本身已大幅提升了开发效率，新页面通常由单人完成多端交付。而在AI时代，我们希望更进一步——借助AI Coding的能力，将开发效率再提升一个台阶。
从2025年下半年起，团队开始逐步落地实践。辅助问答、文档查询、代码生成等能力确实带来了一定提效，但在面对完整页面需求时，AI生成的代码虽然能运行，但距离真正“可用”仍有差距。这主要体现在两方面：
- 存量工程理解有幻觉。输入法Kuikly工程经过多年积累，封装了大量基础能力。但AI对我们工程的理解仍存在明显偏差，常出现API调用幻觉，遇到需求时倾向于重复造轮子。对于客户端常见的页面迭代场景，AI也难以有效处理。
- 需求缺乏结构化输入。Vibe Coding模式下，需求细节往往依赖开发人员自己补全。模糊的需求交给AI，产出的代码同样缺乏准确性。当发现方向偏离时，往往已经经历了多轮修改。需求中未澄清的部分越多，返工成本越高。
基于以上问题，我们开始思考：要让AI在真实工程中真正发挥作用，实现真正的工程化，需要满足哪些条件？这也是搜狗输入法跨端项目在后续实践中重点探索的方向。
二、AI工程化的四个关键层面
在正式探索Spec coding之前，我们最初直接以Vibe Coding的方式使用AI，随后接入了Kuikly团队提供的AI工具，在组件开发和小需求场景中已经有效果。在此基础上，我们希望更进一步，通过更规范的流程让AI协作真正走向工程化。结合真实需求开发的实践，我们梳理出推进Spec coding落地的几个关键层面。
推进AI友好型工程
讨论AI编程效果不佳时，很多人第一反应是模型不行、提示词没写好。但实际用下来，影响最大的往往是工程本身的质量。AI写代码会读取项目上下文——已有代码、模块结构、依赖关系。如果工程本身质量不佳，会把AI带偏，生成出同样混乱甚至相互矛盾的代码。在人工开发时代，可以凭借个人经验和约束规避，但在AI时代，这些混乱会被直接放大为幻觉和错误。
因此，如果你打算认真用AI来提效，与其研究各种高级的提示词技巧，不如先回头审视自己的工程，为AI做些针对性的优化。在这一点上，输入法的Kuikly跨端项目具备较好的基础。从项目立项之初，到多个平台、多个模块的逐步扩展中，我们始终保持较为彻底的架构设计——页面与业务逻辑分离、系统能力统一封装、模块间依赖关系清晰。正因如此，即使在尚未引入任何额外流程、对工程做额外调整的情况下，仅让AI参考现有模块生成代码，就已经能有不错的效果。
构建精准的AI Context
随着模型能力的提升，上下文窗口也变得越来越大，似乎可以将整个项目一股脑塞给AI，但实践中效果可能并非如预期。对开发者来说，哪些系统能力已经封装、哪些基础组件可以复用、哪些服务模块应该优先使用，往往是“默认常识”。但对于AI，它只能在庞杂代码里盲目猜测和搜索，不仅容易漏掉已有能力、重复造轮子，也消耗大量token。
另一方面，模型基于概率生成输出，输入信息的质量直接影响结果。塞入大量无关代码，AI无法自行判断重要性，输出质量反而下降。因此，我们在AI上下文文档生成器Skills的基础上构建了系统，为各模块生成结构化文档，保留AI需要的关键信息：模块职责、核心API、参数含义、模块依赖关系。将这些内容提前沉淀，为AI建立对项目的准确理解。
同时，这类高质量的Context不只是服务于当前需求。在后续模块迭代、修改、扩展时，它们也会成为稳定的“工作记忆”，帮助AI保持实现思路一致、减少偏航，并在多轮协作中持续输出更可靠的结果。
该系统的核心机制借鉴了GAN（生成对抗网络）的思想——文档并非一次生成即定稿，而是通过生成器与评估器的多轮对抗迭代持续打磨。协调器设定逐轮递增的质量门槛（第1轮 ≥75 → 第2轮 ≥82 → … → 第5轮 ≥95），每一轮由生成器产出文档，评估器打分并给出改进建议，生成器据此修订后再次提交评审，如此往复直至达到质量标准，最终输出高质量的文档。文档从模块职责、核心API、参数含义、依赖关系等多个维度进行结构化描述，为AI提供更精准的上下文支持。
经过验证，通过本系统改造后生成的文档在多个指标上取得了显著提升：质量层面，文档准确性达到与源码完全一致、完整性覆盖全部公开API、示例代码可直接复制使用。效率层面，新人上手项目提速50%，理解模块功能提速107%，AI编码准确率提升114%，文档更新维护效率提升137%，真正实现了“让AI更懂工程、让开发更高效”的目标。
标准化需求流程
工程化的一个特点是流程。在没有流程约束的“提示词开发”中，人与AI的协作是点对点、即兴且不可复刻的。这带来几个问题：一是质量无法保证，产出高度依赖单次需求描述的准确性和AI的“临场发挥”，代码质量波动巨大；二是知识无法沉淀，个人摸索出的有效提示词经验掌握在个人手里，无法建立一套可复用、可持续的机制。
真正的工程化目标，并不是“让大家都会写提示词”，而是要有一条标准化的AI参与流程。只有这样，AI的能力才能从个人技巧走向工程化的稳定输出。在流程选择上，我们结合近期的任务形态做了考量：当前大多需求是新页面开发，而一个客户端页面天然就是边界清晰、目标明确、适合独立交付的微型项目。因此我们最终采用了Spec-Kit，它能很好地把AI协作纳入标准流程，让开发从“提示词即兴发挥”变成“基于明确规格的稳定执行”。关于Spec-Kit的原理和流程此处不再赘述，其效果也已得到Kuikly其他团队同事的验证。
Kuikly开箱即用的AI工具
在初步应用AI辅助编程的过程中，我们注意到，往往需要人工介入修改的地方集中在框架规则与实现技能两个层面。有些问题虽然可以通过人工在后续迭代中修正，但如果能提前通过工具补齐，整体效率会更高、代码产出也会更稳定。
原因在于，即使AI理解了具体需求和项目上下文，但模型本身的训练语料覆盖仍然有限，对于项目中特定的能力边界和最佳实践认知不完整。针对这类问题，Kuikly框架已经提供了一整套AI辅助工具，包括基础的AI能力：MCP服务、Rules、Skills，也提供了AI调试、D2C和AI转码这类针对特定场景的工具，覆盖了从编码、调试到迁移的多个环节。
目前我们主要使用了Rules、Skills和MCP这几项核心能力，AI调试工具、D2C和AI转码等能力也在规划接入中。实际使用下来，即便是直接以Vibe Coding的方式，配合这些工具也已经能取得相当不错的生成效果。它们可以为AI补充Kuikly层面的知识，帮助它在生成代码时更准确地理解组件、API和相关约束条件，从而大幅减少调用幻觉和错误用法的出现。因此，在框架侧的代码生成上，业务并不需要过多操心模型理解Kuikly框架的能力，可以将更多精力聚焦在业务逻辑和存量工程的适配。
现在Kuikly也提供了一键配置的CLI工具，Kuikly团队持续对这些AI能力进行维护和迭代更新。当框架侧有新的优化或规则补充时，可以通过CLI一键更新即可同步到最新版本，无需手动关注变更细节，实现真正的开箱即用。同时，我们也结合自身项目在过往开发中积累的实际经验和规范，进一步沉淀了业务使用上的Rules，明确了架构层级和代码层级的各项约定，从而在更细的粒度上引导和约束AI的编码行为。
三、实践案例：灵感词库功能开发
以输入法最新一期“灵感词库”功能页面开发为例。灵感词库是搜狗输入法键盘端的一个新功能面板，页面细节上涉及动态多列布局适配、多种页面状态管理、暗黑模式切换，同时需要对接网络请求、路由跳转、输入客户端交互、KV存储、埋点上报等多项服务能力。此外，作为一个持续迭代的功能，在页面架构设计上也需充分考虑可扩展性。
我们通过Spec-Kit的 /speckit.spec → /speckit.plan → /speckit.tasks 三个阶段，将产品需求文档、设计稿和交互稿转化为结构化的工程文档。整个过程由AI主导，我们在关键节点做了人工确认。最终输出了一套完整的Spec-Kit文档体系，明确了实施路径。
随后进入编码实施阶段，基于上述结构化文档和Kuikly的AI工具支持，我们得到了一个UI与功能还原度都较高的版本。模块组织、页面核心框架、组件结构、布局逻辑均无需大改，开发工作主要集中在UI细节调整上。
该模块的核心数据如下：
| 指标 |
数据 |
| Kotlin 源文件 |
16 个 |
| 代码总行数 |
~ 2000 行 |
| 覆盖功能点 |
卡片列表、动态布局、词义浮层、骨架屏、错误/空态、暗黑模式 |
| 数据模型 |
3 个 |
| UI 组件 |
7 个 |
对比传统开发模式，同等规模的新需求模块页面搭建通常需要3天的纯编码和技术方案时间。而借助AI工程化流程，1天即完成了主体开发。同时，得益于Spec文档的前置约束和Rules的规范引导，生成的代码在架构分层、状态管理、跨端规范等方面都符合项目要求，代码Review阶段基本不需要做架构层面的返工。
需要说明的是，上述显著效果主要体现在新模块、新页面的场景中。这类任务边界清晰、依赖可控，AI的完成度也比较高。而对于存量代码的修改和跨模块的深度重构等场景，AI的完成度目前因情况而异，稳定性还不够理想，后续还需要持续沉淀各类场景的Skills，帮助AI更好理解复杂任务。
四、未来展望
相较于传统的Vibe Coding，当前模式在迭代开发新模块、新页面搭建效率上取得了不错的提升。当然，距离AI全流程工程化的完整落地仍有一段路要走，我们也在以下几个方向持续探索：
1. 打通D2C工具，减少UI修正成本
现阶段，仍有大量工作集中在UI层面的修正与调优上。如果能够打通D2C工具链，将设计稿自动转化为高质量的代码产物，就能从源头上减少UI还原过程中的人工介入，进一步提升开发效率。Kuikly团队已推出视觉稿转码工具，未来我们的流程也会持续向此方向探索。
2. 构建自动化验证机制
随着整体流程的跑通，仍有一部分环节依赖人工验证。下一步我们计划结合Kuikly预览、Inspector等现有工具能力，逐步构建自动化验证机制。通过AI对UI渲染结果、交互行为、布局一致性等进行自动化校验与反馈，逐步替代人工验证环节，实现从“生成→预览→验证→修正”的全流程自动化闭环。
3. 将AI能力扩展至更多研发场景
实际开发工作远不止于新页面开发。后续我们计划逐步将AI的能力延伸到更多场景——包括需求文档的自动解析与任务拆分、线上BUG的自动定位与修复、跨端工程与端侧工程的联动等。在实践过程中持续沉淀更多的Skills和工具，将各项能力与研发流程深度编排集成，让AI逐步覆盖更完整的研发交付链路。
五、关于Kuikly
Kuikly框架致力于为开发者提供高效、稳定的跨端开发解决方案，并持续探索与人工智能结合的工程化实践。当前Kuikly已经开源，欢迎有需要的开发者访问其仓库和文档，进行Star、Watch与体验。
此次在搜狗输入法中的AI工程化实践，是我们在云栈社区分享的一次具体技术落地案例。我们相信，通过清晰的工程结构、精准的上下文构建、标准化的流程以及趁手的工具，AI能够在真实、复杂的生产环境中发挥出更大的价值，切实提升研发效能。
发表于 5 小时前
|
查看: 4|
回复: 0
