百灵口播提词已经在华为应用市场上架了。这款应用的开发时间不到一个月。我还有本职工作，工作日每天最多能拿出两个小时，周末会多一些，大概四五个小时。开发过程中没有突然爆发的灵感，也没有什么一次性解决所有问题的方法。功能一个个做，错误一个个查，提交审核后又连续被打回四次。
为什么选鸿蒙
关注鸿蒙有一段时间了。新生态里的应用数量、用户需求和开发者供给还在变化，对个人开发者来说，能看到一些空间。华为也在做开发者激励、应用市场资源和生态合作。如果产品做得合适，除了获取用户，还有机会被生态运营看到。
过去一直没有真正开始，理由很直接：学习一个新系统需要连续时间。ArkTS、ArkUI、应用生命周期、各种 Kit、签名、真机、上架流程，每一块都有自己的知识。平时上班，很难先留出几个月学完再动手。
大模型能力稳定之后，这个条件发生了变化。阅读工程、搜索调用关系、对照官方示例、分析编译错误和日志，这些工作可以由 AI 分担很大一部分。新 API 仍然需要查，不过已经不必等到知识储备完整后才能做项目。
所以这次直接选了一个真实产品。遇到相机就学相机，做画中画时去理解窗口和后台规则，上架前再补齐备案、隐私和资料。这种学法不够系统，却能马上看到哪里真的不会。
提词器这个想法怎么来的
想尝试做自媒体，拍口播时需要一个提词器。试了一些现有产品，发现很多都要付费。付费本身没有问题，它至少说明这个需求已经有人愿意花钱解决。但对刚开始拍摄的人来说，可能只是想先试几次，还不确定自己会不会持续更新。
这个场景很适合做第一款练手产品。需求比较具体，自己也是用户，能判断操作是否顺手。它还会用到相机、麦克风、画中画、本地数据、云同步和小艺等鸿蒙能力，做完以后能对平台有比较完整的体感。
百灵口播提词准备长期免费。第一款应用不急着承担收入目标，它要完成的是整条链路：立项、设计、开发、真机验证、备案、审核、上架，然后看看有没有人愿意下载。这些事只看文档很难有感觉，亲自走一遍才知道每个环节会卡在哪里。
确定要做之后，最初的想法其实很简单：做一个基本功能完整、打开就能用的免费提词器。但既然选了鸿蒙，我又不太想只把其他平台的产品照搬一遍，这个项目还承担着熟悉鸿蒙原生能力的任务。
最初的产品路线图就是这样一项项扩大的。写稿可以用小艺，拍摄可以接相机，语音识别可以让文字跟着人走。如果再加上平板显示和手表遥控，拍摄时就不需要频繁碰手机。实况窗可以显示拍摄进度，录完后还可以接自动字幕和导出。这些设想放在一起，已经超出了普通提词器的范围。当时给项目的定位也更大，叫"鸿蒙生态口播工作台"。
方案越做越大，首发范围需要重新算
进入具体开发后，一个问题慢慢变得清楚：最早的方案把三件事混在了一起。用户打开第一版后要完成什么，项目如何体现鸿蒙特色，未来还能发展成什么样，这三个问题的时间尺度不同。它们都有价值，也没必要在第一次上架时同时完成。
小艺生成口播稿、手机录制、平板提词、手表遥控、语音跟随、实况窗、自动字幕和导出，这套方案用来讲生态故事比较完整。对一个只有业余时间的人来说，全部放进首发后，稳定交付的风险很高。
有些能力必须组合真机才能验证。平板和手表会带来设备组合、状态同步和异常恢复问题；字幕和剪辑会把录制后链路拉得很长。如果同时铺开，最容易得到的结果是每个页面都能看，完整流程却跑不通。
最终上架的版本收敛到手机端，用户可以新建或导入脚本，编辑和保存，然后选择提词板、悬浮提词或提词拍摄。拍摄完成后，视频保存到系统相册，脚本可以继续在本地管理，用户也可以自己开启云同步。
三种提词入口对应的用法不一样。提词板适合手机专门用来显示文字，用户可以调字号、颜色、镜像和速度。当设备和系统支持画中画时，悬浮提词可以配合相机、直播或其他拍摄应用使用。提词拍摄把预览、文字和录制控件放在同一个页面，适合不想来回切换应用的场景。
脚本也不限于手工输入。已经写在文本、图片或 PDF 里的内容可以导入后继续编辑。编辑页保留了小艺帮写、润色和本地敏感表达检查。这些功能都围绕"把一份稿子顺利读完并录下来"展开，首发没有继续加模板市场、社区或复杂视频后期。
图片使用 Core Vision Kit 识别文字，PDF 使用 PDF Kit 解析，扫描版 PDF 也会进入文字识别。当前版本同时保留固定速度和语音识别跟随滚动两种方式，语音识别启动失败、麦克风未授权或音频采集被占用时，回退到固定速度。
平板、手表、实况窗、自动字幕和复杂剪辑暂时没有进入首发。
开发前先验证高风险能力
新项目很容易先做首页。首页能快速看到成果，图标、卡片、配色调整起来也有明显反馈。但对百灵口播提词来说，首页做得再完整，也回答不了几个核心问题：自定义相机能否稳定录像，画中画能否承载提词，开启云同步并成功上传的脚本能否在卸载重装后恢复，语音跟随和录制会不会抢占音频资源。
项目初期的顺序因此按风险来排。相机先做预览和录制的最小链路，不急着叠加完整提词样式。画中画先确认系统窗口能创建、能控制、能退出。云同步用几条测试脚本验证上传和回拉，不在早期就完善整套列表交互。
每个高风险能力都提前写一个停止条件。如果系统能力在目标设备上无法稳定运行，就改用更普通的方案，或者移出首发范围。语音跟随失败时回退到固定速度；云同步关闭时，本地脚本照常使用；小艺在设备上不可用时，编辑和保存不受影响。这些降级路径会直接影响数据和代码边界，放到功能做完后才考虑，通常要改更多东西。
准备工作还包括权限和数据。相机、麦克风、视频保存、云同步分别在什么时候申请，用户拒绝后页面怎样继续，脚本保存在本地还是云端，删除是仅移出当前列表还是同时删除云端数据，都需要在实现前说清楚。这些问题不会在视觉稿上自动出现。
AI 怎样参与开发
最开始，AI 只能比较可靠地写简单界面：用 ArkUI 搭页面，放几个按钮和卡片，修改间距与配色。到了相机、画中画、云同步和语音采集，模型即使能给出完整代码，也经常混入旧接口、其他平台经验或不存在的调用。那时它更像一个速度很快的界面助手。
变化出现在把官方示例放到模型前面以后。相机问题先查 CustomCamera，画中画先看 ArkUIWindowPipSamples，导航和多设备布局对照 HarmonyOSComponentUXExamples、MultiCommunityApplication，再读取当前 SDK 的类型声明。AI 有了可以核对的工程，才更容易找对对象关系、调用顺序和生命周期。
示例多起来后，又把这套检索流程封装成 harmonyos-sample-research Skill。AI 会先按能力搜索本地示例，阅读对应 README 和实现文件，再回到当前工程找负责模块。后续会话不需要每次重新解释去哪里查。
项目中后期，华为又发布了 DevEco CLI，随后我们接入鸿蒙开发者知识 MCP。前者负责文档、构建、运行和日志，后者补充官方资料查询，AI 开始能够连续完成查资料、修改代码和验证结果。
以相机为例。如果只说"做一个录像页"，模型很可能先选系统相机选择器。百灵口播提词需要在预览画面上叠加提词内容和录制控件，这条路一开始就不合适。对照官方自定义相机示例后，方案才确定为 Camera Kit 配合 AVRecorder，预览、录制和页面交互分开管理。
遇到复杂问题时，AI 更适合整理日志、搜索调用者和划分失败阶段。相机会话失败时，把日志按创建、准备、启动、暂停和释放分段；页面状态异常时，沿着入口、服务、仓库和刷新动作向下追。
每次交给 AI 的任务也尽量收窄。例如"在现有录制服务中补齐暂停和继续，不改相机页布局，编译通过后给出真机检查步骤"，比"优化一下相机"更容易得到可控结果。任务里会明确负责文件、成功标准、不需要改的部分和验证方式。
模型根据代码做出的解释如果和真机现象冲突，就继续查。官方资料用来确认接口和平台规则，构建、日志和真机操作负责确认项目是否真的跑通。
把日常开发固定成几个动作
项目开始时，遇到报错就搜报错，页面不对就改当前页面。问题复杂后，同一状态经常会在几个入口重复修。后来固定成一套动作：稳定复现，标出失败阶段，沿着入口、参数、状态和系统调用往下查，在负责文件里做最小改动，再回归其他使用相同状态的入口。
代码仓库保留当前实现，本地知识库记录版本边界、决策和真机证据。一个阶段完成后再更新长期记录，并留下 Git 检查点。这样第二天能直接继续，方向错了也可以只撤销对应改动。
ArkUI 是这套方案的界面底座
刚开始让 AI 写界面时，它很容易用 Row、Column、Stack 和点击事件拼出一个"看起来像"的控件。截图往往没问题，实际使用时还要继续处理焦点、滚动、按压反馈、深浅色和不同屏幕宽度。页面越多，这些自制控件的细节越难保持一致。
后来定下的规则是，常见交互先找 ArkUI 或 UI Design Kit 的现成组件。百灵口播提词的应用外壳使用 HdsNavigation、HdsTabs 和 NavPathStack；脚本列表使用 List、ListItem 和系统横滑能力；搜索使用 Search；脚本编辑使用 RichEditor；提词设置使用 SegmentButton、Slider 和 Toggle。提词浮层、相机控制和画中画内容没有合适的通用组件，才保留定制实现。
使用这些组件后，AI 主要处理数据、状态和页面回调，基础滚动、横滑、按压反馈和控件行为交给 ArkUI。华为的 ArkUI 官方说明 提到，声明式开发不需要额外的页面 DOM 管理，渲染更新链路更精简；UI Design Kit 则提供符合 HarmonyOS Design System 的导航、页签、列表和多设备适配组件。对个人开发来说，这些现成能力能更快搭出完成度较高的页面，交互也更接近系统应用。
颜色、字号、间距、圆角和组件尺寸集中放在设计令牌中，并优先映射系统资源。AI 修改页面时从同一套令牌中选择，避免不同页面慢慢长出各自的样式。
怎样避免代码变成一次性样品
为了避免 AI 把代码堆成一次性样品，项目划了几条边界：页面处理屏幕状态、路由和功能组合；组件管自己的显示和交互；数据模型约束状态和参数；服务封装相机、持久化、画中画、语音和文件等系统调用。
这些边界解决的问题很具体：AI 改动相机时，主要阅读录制功能的服务和模型，不需要同时改脚本数据库和首页。处理云同步时，先在脚本仓库中查数据流，页面只负责显示进度和结果。
这些边界是随着问题逐步拆出来的。当相机页开始同时处理 surface、录制器、方向、计时和页面按钮时，就把录制能力移到独立服务。全屏提词、画中画提词和拍摄提词需要共用字号、颜色、速度和镜像设置时，再统一提词模型和配置。此后改相机状态先找录制服务，改提词配置先找提词模型，避免在出现现象的页面上补临时特判。
几个实际踩过的坑
相机能显示，不代表能稳定录像
相机页刚开始做时，曾经遇到过黑屏、点击只闪一下、AVRecorder.prepare 报 IO 错误等问题。预览出图、录制准备、视频输出和保存入册是几个不同阶段，其中任何一段都可能失败。
最后的策略是页面进入后先建立独立预览，让用户尽快看到画面。开始录制时再按当前设备能力选择分辨率、帧率和画面比例，准备 AVRecorder，获取输入 surface，然后建立完整会话。不再固定写死 1920×1080，因为设备能力和预览比例并不总是一样。
暂停和继续录制也不能只改页面图标。暂停时需要调用 AVRecorder 的暂停，同时停止视频输出；继续时先恢复输出，再恢复录制。计时器要记录累计时长，不然暂停期间的时间也会被算进去。
这类问题只看源码或模拟结果很难确认。相机预览、麦克风、横竖屏方向、暂停继续和保存相册，最后都要用真机操作。
云同步成功了，列表却还是空的
脚本数据使用 ArkData 关系型数据库保存，再通过系统云空间同步。这样不需要单独做一套应用账号，用户即使关闭云同步，也能正常创建和使用本地脚本。
调试时遇到过一个很容易误判的现象：cloudSync 返回成功，卸载重装后的进度日志也明确显示 download=2/2，但脚本列表还是空的。如果只看页面，很容易判断为云端没有数据。
日志已经证明数据下发到端侧，所以排查重点放在落库后的刷新和清理逻辑。最后发现，代码把普通云端更新也当成了待清理的脏数据，刚下载的脚本又被删掉了。修复后只处理明确的删除标记，并在数据变化后重新查询本地库。后续用单台真机新建脚本，同步后卸载应用，重新安装再同步，脚本能够恢复。
这个问题也让我开始把"调用返回成功"和"用户看到正确结果"分开记录。前者只说明这一段 API 没有报错，后者还涉及数据落库、列表刷新和业务清理。
画中画首先是一个系统窗口
悬浮提词使用 PiPWindow。它能让提词内容在其他应用上方继续显示，用户可以拖动、缩放、收起和恢复。但这个窗口的模板、控制面板和状态变化都由系统规则约束，它不是一个可以任意往里放控件的普通容器。
开发时需要在创建控制器时设定内容比例，把系统控制面板的播放、暂停和前后跳转事件回写到提词状态，页面内的状态变化也要同步给系统。关闭画中画、页面销毁或系统报错时，节点、控制器和后台任务都要清理。
这部分的交互没有完全按最初的设计图还原。系统规则已经解决窗口层级、手势和异常退出，为了自定义外观重写一套悬浮窗，反而会增加不确定性。
小艺和语音合成带来了新的审核材料
脚本编辑页里有"帮写"和"润色"入口，通过 Agent Framework Kit 拉起已经配置的小艺智能体。用户在小艺中得到结果后，需要手动复制回脚本编辑页。开发和审核期间还曾使用 Core Speech Kit 做文本转语音的脚本朗读预演，这项功能后来已从当前发布工程中移除。它和前文用于控制滚动的语音识别是两项不同能力。
接入这两类能力时，技术边界看起来比较清楚：一个负责拉起系统智能体，一个调用官方文本转语音能力。进入应用市场审核后，问题变成了另一套：应用提供了哪些 AI 功能，内容由谁生成，是否需要显式标识，算法备案、安全评估、合作关系和实名材料怎样说明。
审核反馈主要分为两类：基础功能的复现问题，以及 AI 功能需要补充的声明、备案和资质材料。接入官方能力之后，应用仍然需要向审核方解释使用场景、数据流向和各方责任。一句"这是系统能力"无法代替材料。
这段经历对后续项目的影响很实际。以后确定接入 AI、语音、账号或其他受审核关注的能力时，会在开发中期就把声明、截图、资质和演示路径列出来。等代码完成后再补，时间很容易耗在等待和反复提交上。
编译通过只能说明工程能打包
这轮开发里，"已完成"曾经被用得太早。构建成功说明工程能够打包，安装成功说明应用包能进入设备，顺利启动后，相机、画中画、麦克风和云同步仍然需要按实际路径操作。
因此后来把证据分开写：代码已实现、工程已构建、已安装启动、指定真机路径已验证。某个阶段没跑，就保留"待验证"。
真机验证围绕完整路径展开：相机从授权、预览、录制一直走到保存相册；画中画检查进入其他应用后的控制和退出；云同步则验证新建、上传、卸载、重装和回拉。
开发过程中还遇到过 SDK 组件缺失和本地环境配置问题。先分清环境、签名、编译和业务行为，可以避免在环境出错时反复修改业务代码。
第一版的上架测试顺利通过，其中兼容性和性能的核心用例通过率均为 100%。
上架准备需要提前
第一版做到中后段时，工作重心一度仍然都在功能上。备案、隐私政策、用户协议、应用图标、市场截图、权限说明和审核备注，很自然地被放到"开发完了再做"。后来发现，它们会反过来要求代码和产品调整。
权限说明要对应真实的触发场景，隐私政策要和数据处理方式一致，应用市场截图上出现的功能需要在审核设备上可以进入。如果一个能力受设备、账号或系统版本限制，审核备注里就要说清前置条件和操作路径。
在此之前，我对"上架"的理解偏向于上传一个构建产物。实际经历几轮后，它更像一次完整交付：审核人员在没有项目背景的情况下，需要理解应用做什么，按材料进入功能，核对数据、权限和资质。任何一处对不上，都会进入新一轮沟通。
以后做新应用，首个可用版本出来后就会开始准备上架内容。名称、包名、隐私、权限和外部账号等问题尽早确认，核心功能稳定后开始截图和写商店文案。这些事和功能开发可以并行，没有必要在最后一周挤在一起。
一个人的开发节奏
这个项目无法按全职节奏排。工作日的两个小时，如果用一半时间重新理解上次做到哪里，真正可以动手的时间就不多了。每次结束前会留下下一步入口：当前错误、已经验证的判断、下次先改哪个文件。第二天可以直接继续。
工作日适合做边界清楚的任务，比如改一个交互、调整一个服务、补一段日志、跑一次编译。相机会话、云同步回拉、完整真机回归等任务更适合放在周末，因为它们很难在半小时内停下。
后来还加了一个限制：每天只推进一个主任务。项目做到中间时，新功能、宣传素材、备案、开发工具和其他创业想法会同时出现。每件事都做一点，一天很忙，版本距离上架仍然一样远。新想法先记下，当天仍然只解决已经选定的主问题。
任务也不按"写一个页面"来切。更有用的切法是一个纵向小闭环：用户从哪里进入，状态保存在哪里，操作由谁执行，页面如何拿到结果，失败时显示什么。比如"开启云同步"这个任务，至少要包括开关入口、持久化状态、系统权限、同步结果和云不可用时的处理。只画出一个开关不算完成。
上架之后，还没有用户侧正反馈
截至写作时，产品已经上架，但还没有带来明显的用户侧正反馈。上架前连续四轮审核未通过，每次修完再提交，都不知道下一轮还会出现什么。这种阶段很容易让人转去做新项目，因为新想法没有历史包袱，看起来永远比手上的审核问题有趣。
这次先给自己定了一个更低的要求：不用等待强烈的正反馈，先把第一款应用送过审核。上架是一个可验证结果，它还不能代表用户认可。不过没有上架，后面的下载、使用和留存都无法开始。
下一个目标是 100 次下载。这个数字不大，先看看产品能不能接触到第一批真实用户，再争取达到鸿蒙开发者激励的要求。
第一款应用给后续产品留下什么
后面还想做多个面向不同需求的独立应用，不会把它们强行塞进一个超级应用。可以复用的是这次走通的方法：设计令牌和代码边界、官方示例检索、AI 改动范围、真机验证方式，以及备案、隐私、市场素材和审核材料清单。相同的问题第二次出现，再考虑做成工具或自动化流程。
百灵口播提词没有承担收入目标，它完成的是第一款产品从立项、开发、真机验证到审核上架的整条链路。下一款产品能不能更快，等真正开始后再看。
如果刚好使用鸿蒙手机，也有拍口播或录视频的需求，可以在华为应用市场搜索"百灵口播提词"。它目前免费，正好也需要第一批真实使用反馈。