现在，鹅厂的产品和设计，自己上手做开发了

AI编程的风，还是吹到了产品圈。

在腾讯，产品经理和设计师组团，两周时间就能上线23个小工具。

经过不断的积累，目前已经有40个小工具并上线（在QQ浏览器搜索页输入相关关键词如“星座运势”即可体验，点击小工具最下面的“更多小工具”就可以进入这个页面，看到所有小工具），而完成这些的主力，都是QQ浏览器团队的设计师。

本文将分享本次实战的全过程。

回到故事的起点，这是腾讯QQ浏览器的产品经理冬雪的一个“啊哈时刻”。

作为一个完全不会写代码的产品，“提前还贷计算器”的实现过程，出乎意料的简单，冬雪只做了两件事：

1）明确需求： 和元宝聊了几句，弄清了提前还贷的核心指标。

2）与AI对话： 用纯大白话和CodeBuddy交互了三轮。第一句是基础需求（请帮我设计一下提前还款计算器，尽可能通俗易懂，只保留用户必填字段，去除非必要的通过必填字段就能算出来的字段），第二句是补充“减少月供”和“缩短期限”两种还款方式，第三句是完善计息规则。

就这样，一个功能完备的“提前还贷计算器”雏形便呈现在眼前。

“看到它第一眼的惊喜至今仍记忆犹新，因为当时只是临时起意，也没想好具体怎么用CodeBuddy,所以只是随口和它聊几句，完全没有PE，没有预期只有好奇，而AI却为我构建了一个实实在在的工具。”

理想和现实：从“原型”到“产品”的差距

工具写好后，冬雪开始考虑：如何能把这个工具快速上线到QQ浏览器搜索结果页线上，于是迅速拉了设计和技术同学一起讨论，基于长线可复用角度考虑，敲定如下方案：前端在搜索结果页上线一张卡片框架，用iframe嵌入AI写的代码，这样当后续有新的AI工具/能力时，产品和设计同学都可以通过配置数据独立上线，实现“想法-AI实现-上线”的自闭环流程，不需要技术同学额外排期开发；

方案确认后，大家并行开搞，设计两小时出图，前端1天开发好框架，产品同步调功能，雄心勃勃地计划着两天把它搞上线，但其实最终用了4天的时间才把第一张卡推送上线，过程中遇到了各种各样的问题：UI组件与客户端样式不适配、边界场景计算错误、页面动态高度不生效、日夜间模式失灵……调试耗时最长的，恰恰是这些将AI代码移植到真实环境中的“适配性”问题。

这次“踩坑”之旅虽然艰辛，却为他们积累了第一手宝贵经验，也成为了他们下一阶段优化流程、思考如何体系化提效的直接驱动力。

思考：如何从“手工作坊”到“智能产线”？

第一个“提前还贷计算器”的成功上线，让冬雪 和同事们 看到了用AI去做浏览器卡片的可能，而这个能力背后巨大的想象空间让大家都很兴奋，搜索一直有一些低频但刚需的小需求，过去受限于ROI没能提早落地，现在有了AI后，这些都重新有了快速落地的可能。

一场头脑风暴被迅速组织起来。无数有意思的想法涌现，大家跃跃欲试。但他们也意识到一个关键问题：如果每开发一个新工具，都要从头摸索、重复踩坑，这与利用AI“提效”的初衷便背道而驰了。

于是，一个新命题摆在了他们面前：如何从打造单个“爆款”，升级为构建一个高效的AI工具“生产线”？  

为了搭建这条“生产线”，他们首先复盘了第一个工具的完整链路，将所有环节的痛点与可优化的空间一一拆解，最终确立了一套标准化的改进方案：

这个过程，像极了上学时解数学题。AI是那个聪明的解题者，而产品经理的角色，就是把题干（需求）描述得更清晰（需求结构化），并为它准备好各种通用的“简便公式”（能力模块化），最终让它解题解得又快又准。

下面展开讲下这里详细的思考与过程：

当有了AI Coding作为生产力，人力不再是卡点时，很多想法和方案都可以快速上线验证。第一步是如何把初步的想法，可以尽量准确的变成AI可以理解的需求。在第一个小工具的开发中，产品通过自然语言完善自己的想法，一轮一轮的告诉AI。这个过程中暴露了如下问题：

一是表述有难度，当用完全口语化的自然语言，来描述相对严谨的功能需求时，很容易有表述上的不清晰。AI的理解就会有折损。

二是有遗漏，在快速验证的前提下，无法对所有功能点都有完备的思考，非常容易遗漏。

而这些问题点，恰巧也是AI擅长的地方。将工作方式稍加改进，就可以让AI来完善需求的澄清。基本的原理是将最初步的概念告诉CodeBuddy，让CodeBuddy根据完成这个功能所需要的所有信息，来反向向用户提问并且给出选项。用户只需要依次回答CodeBuddy提出的问题，即可完成一份功能明确详细的需求文档。

于是冬雪和同事们把这个需求澄清的过程做成一个可复用的工具。

为了保证需求澄清的质量，他们调教了CodeBuddy的需求澄清文档，允许CodeBuddy智能判断需求的类型，根据不同类型来进行提问。并且让CodeBuddy使用ears语法来进行需求的提问，帮助需求的澄清过程描述更清晰准确。

为了每次可以更方便的复用这个能力，他们又让CodeBuddy把这个需求澄清的功能写成了脚本，安装脚本只需要通过输入 /需求澄清 快捷指令就可直接触发需求澄清的流程。例如输入 “ /需求澄清 今日黄历” ，CodeBuddy会提出一系列问题来完善需求。

作为面向非技术人员的开发流程，冬雪和同事制作AI开发模版系统的总体原则是：

● AI First：能在 Chat Box 完成的尽量在 Chat Box 完成，不要引入别的操作

● 最小化信息：对普通成员，仅需关心手里的唯一一个文件，别的信息能少就少

整个通用模块的内容和使用流程如下图。几位设计师对页面的颜色，布局系统和组件样式整理成为标准化css样式库，同时，产品和设计一起制作了小工具所需要的通用功能，以及预览结果用的iframe框架，配置环境所用的初始化文档，使用指南和打包上线工具（过程完全依赖CodeBuddy）。所有功能共同构成一套完整的开发工具，可以支持技术小白从零开始快速制作出符合产品和设计规范的，可上线交付的小工具。

搭建成功后，该模版流程可以做到：

1.  完全模拟了QB的搜索结果页，使用QB打开的话几乎以假乱真

2.  内置20+款供参考，通过下拉菜单可以快速切换不同工具

3.  完成自适应适配，手机电脑多端可用

4.  夜间模式JS配置调试成功

5.  模板本身经过精简，不需要任何依赖，可以直接使用

基于这套流程，部门内同事一起参与制作，发挥创意。短时间内就上线了23款小工具，下面会简要介绍下这套模版系统的具体构成和使用方法。

在AI Coding中的视觉UI部分，冬雪和同事在第一款手搓小工具时是先输出设计稿，之后在CodeBuddy中直接引用figma画布的方式。为了快速验证不同工具提升效率，希望可以把设计规范直接代码化，提升效率的同时保证样式的可控。

这个过程设计同学借助CodeBuddy探索了两种方式，第一种方式是将设计规范生成一套方便分享的设计规范.md文档。文档包含了QQ浏览器的设计规范和规范的使用说明，当不同的开发者需要开发符合浏览器规范的小工具时，直接将这套设计规范的md文档添加到资源库中进行引用即可。

第二种方式是针对前文提到的模板系统，设计同学直接根据设计规范生成一套css样式库，将样式库放在系统中的share目录中，并在系统的初始使用中增加了如何引用css的描述。之后当任何使用这个系统文件包开发工具时，都将直接使用这套css，保证了CodeBuddy在生成的页面直接是符合设计规范的要求。

为了进一步提升效率，他们对通用能力JS函数也进行了封装，进一步保证一致性和开发效率。由于通过iframe框架上线到产品里，通用的JS主要包含以下两个。

1. 卡片高度自适应通信函数

在iframe嵌入场景中，由于内容动态变化导致的高度适配是一个常见痛点。他们让ai开发了一套完整的高度自适应解决方案，通过直接DOM操作 + postMessage实现对iframe高度的控制。

2. 日夜模式同步函数

考虑到用户体验的一致性，他们实现了智能的日夜模式同步机制，能够自动适配用户的系统偏好和浏览器设置。

以上这两个功能通过封装以后，能自动初始化，无需手动调用。为了保证每次开发都能准确无误的使用的模版，他们为初次开发的用户提供了一套模版关键词：

基于tool-template.html模板以及Shared文件夹中的样式及配置文件，创建一款「工具主题」HTML工具，并使用README.md中的规则适配到结果页框架中：

1. 此工具可以「工具项目的功能总体描述」

2. 布局：「大致布局参考」

3. 交互：「交互方式参考」

4. 工具使用的样式、布局、配置应尽可能遵循shared文件夹中给出的样式及规范，但如果有特殊样式或样式文件夹中没有提及到的，则参考样式风格自行定义即可

5.  页面的初始化配置参考tool-template模板，重点关注页面边距、初始容器结构等

6.  除了工具本身HTML外，不要创建诸如说明、报告等文件

提供一份实际项目的Prompt，细节写得不算好，但是没关系，AI会出手

基于tool-template.html模板以及Shared文件夹中的样式及配置文件，创建一款「跨国时间速查」HTML工具，并使用README.md中的规则适配到结果页框架中：

1. 此工具可以帮助用户快速得知所需国家当前的时间、与自身所处时区的差值，并支持用户快速查看在任意时间时对方时区的时间

2. 布局：开始前：头部为标题和一段工具描述，下方为时间的展示：左侧展示我所在时区的时间（北京时间），右侧展示所查国家的时间（默认为美国），并附有时间调整功能以及所查国家的选择器

3. 交互：默认时间为当前时间，动态显示；当用户在选择器选择了对应国家后，显示对应国家的时间；当用户调整时间后，对应的时间也跟着变化

4. 工具使用的样式、布局、配置应尽可能遵循shared文件夹中给出的样式及规范，但如果有特殊样式或样式文件夹中没有提及到的，则参考样式风格自行定义即可

5.  页面的初始化配置参考tool-template模板，重点关注页面边距、初始容器结构等

6.  除了工具本身HTML外，不要创建诸如说明、报告等文件

调试/预览模版

制作第一个工具时，无法直接预览搭配工具的在用户设备上的真实形态，只能通过测试环境反复抓取代码进行预览，无论是对于调试还是对外宣讲，都非常麻烦。而产品形态和场景都是相对固定的搜索场景，因此完全可以一比一复刻产品所在场景的前端页面形态，形成一个通用的预览/调试模版，进一步降低设计到开发实现的调试成本。

为此，他们仿照线上环境的真实页面形态，搭建了一个本地运行的预览模版页面。工具包会将做好的工具自动嵌入模版页，可以选择本地浏览器预览。如果想要更逼真的模拟，或者分享他人评审，只需在CodeBuddy中一键部署到CloudStudio,在移动端打开链接就可以预览效果，使用QQ浏览器打开几乎做到以假乱真（见下图）。

工程化改造

当CSS样式库、JS函数库等通用能力搭建完成以后，他们建立了一套完整的使用流程文档，在部门做推广。起初他们简单将代码文件直接发送到使用者本地，导致了两个棘手问题：

1. AI Coding在开发时为了满足用户诉求，会改动通用能力的代码。

2.业务和需求的变动导致需要不断更新迭代通用代码，无法保证所有使用者手上的都是最新的版本。

为了使得在对通用能力进行更新迭代时，所有成员都能及时使用最新的代码，并且继续降低使用门槛，他们借助研发同事的力量，完成了对整个项目的工程化改造。

识别痛点与初步设想

研发同学介入后，根据现有的工具模板和聊天记录，大致识别到了如下痛点：

• 文件组织松散，命名混乱，可以整理整理

• 当前没有利用上 CodeBuddy 自带的 Rules 和 Command 机制，每次做新卡都得手动粘贴命令，略显繁琐

• 如上文所述，没有版本管理机制

  
  

为此，研发同学有了初步设想，来解决这些明面上的问题：

• 引入 Git 版本管理机制，方便多人协作

• 将现有的 Prompt 整理为 Command，免去手动复制粘贴的繁琐

• 重新组织部分目录结构，统一化命名规范

  
  

在完成上述简单设想后，研发同学与设计和产品同学开了个初步的碰头会，这一碰头就发现了更多问题。

碰头：ChatBox Is All You Need

在以往的传统需求开发中，设计、产品、研发往往各司其职，相互之间很少重叠；但此次尝试无疑是一次更彻底的配合。

在长达一个半小时的会议中，他们发现了一个之前忽略的问题：引入 Git 后，很多流程即使采用可视化工具，对于非研发同学来说，也显得太过复杂了。设计和产品同学现有的开发流程是完全基于对话框实现的，至于 CodeBuddy 的其他按钮，如 Git 分支状态、Git Graph、插件都完全不关心。

整个流程每引入其中的任何一部分，对大家都是一份心智负担。也就是此次碰头后，整个工程化改造的基调确定了：ChatBox First。让所有操作，能在 ChatBox里完成的就在那里完成，能用自然语言的就用自然语言，能不打开其他软件就不打开其他软件，真正做到小白友好。

改造后流程例子

在上述思想的指导下，在设计和产品同学的大力配合下，花了3天完成了项目的工程化改造。

改造后：

• 引入了 Git

• 规范了命名和文件夹组织结构

• 把上文中的 Prompt 作为 Command 引入 

• 新增了脚本用于实现资源上传/查看/删除、本地预览、真机预览

  
  

但与其他传统项目不同，改造后的操作均以 Command / Rules 为优先形式，通过底层执行 Python 脚本的形式完成复杂任务。比如，通过 `/提交到远程` 和 `/拉取最新代码` 即可完成 Git 相关操作、通过 `/资源文件管理 上传 xxx 到 xxx` 即可上传资源到 cdn，通过 `/预览` 即可起一个服务器完成本地和真机预览等。各 Command 间还做了必要的串联，使得可以自然流转。改造后提供的命令列表如下：

完成改造后，整理的开发流程如下所示：

基础环境配置

这是少数需要部分脱离 ChatBox 的步骤，参考文档，借助自然语言，让 CodeBuddy 安装好 Git、生成 ssh key、放到腾讯内部代码管理协作平台上并完成项目 Clone（也就是拉取项目代码到本地），后续全部在 CodeBuddy 对话框中操作。

初始化环境

使用 「初始化环境」自动检测并配置必要的 Python 环境和依赖（用于执行脚本）。

需求澄清 & 新建卡片

在所提需求澄清 Prompt 基础上，把它和创建卡片的 Prompt 分别做成 Command，并为二者添加关联：当需求澄清完毕后，AI 会把需求保存为独立文档，并建议用户新开对话，基于此文档完成卡片创建；当卡片创建时需求阐述不清，则会自动转回澄清流程。

以一个贪吃蛇作为例子，并直接进入创建卡片流程：

本地预览 & 真机预览

预览服务器可以方便的进行本地模拟页面预览，也可以通过注入线上代码的形式，完成真实环境的真机预览。

解耦 & 产出 CDATA

本地预览以及真机预览没问题后，也能够借助命令，快速完成文件的解耦（将涉及到的脚本、样式等打包为独立 HTML 文件），并进一步生成移动端和 PC 端的 CDATA 格式，方便产品粘贴到相应平台完成部署。

提交到远程

一张卡片完成，只需要再输入 `/提交到远程` ，即可在 AI 帮助下智能提交到远程（由于此卡片为演示，因此让 AI 跳过最后的提交步骤），无需理解复杂 Git 命令。

类似的，后续也可以通过 `/拉取最新代码` 获取最新更新，无需操作 Git 命令。至此，整个流程完成，做到了产品友好，不离开 ChatBox 的诉求。

现状与展望

当前的工程化改造是在原有纯 HTML + JS + CSS 模板上完成的，尽管可以跑起来，但当前的开发范式与现有其他卡片存在较大区别，部分能力，如上报、账号能力、接口调用等难以打通。

此外，在与设计稿配合时，由于 Figma Make 生成的项目为 React + TS，因此需要先基于模板转化为 HTML + JS + CSS 才能进一步开发，略显繁琐。在后续前端同学介入后，整个项目或许可以直接迁移到现有前端卡片工程中，这样也能统一开发语言和基础架构，复用现有能力。不过，在此类开发范式下，产品设计同学以及AI需要了解的上下文也会相应增多，具体表现还有待探索。

整一套流程下来，效果显著：两周上线23款小工具，效率提升370.5%，数字固然亮眼，但冬雪心里清楚，这次探索最引以为傲的，是它引发了团队里产品、设计、技术三个角色一次深刻的“集体进化”。

过去，团队是分工明确的流水线，一环扣一环，边界分明。而现在，为自己打造的这套AI工作流，就像一个“超级武器库”，让每个角色都获得了升级：

● 产品和设计，从“提想法的人”升级为“创造者”。能亲手把想法变成跑得动的原型，开始跨界探索DOM和异步的世界。

● 技术，从埋头实现的“执行者”升级为“赋能者”。打造并维护着这个强大的武器库，为整个团队的创造力提供燃料。

冬雪说：