你好，我是小雨青年。

作为这个系列的第一篇文章，我知道你可能已经迫不及待地想打开 DevEco Studio，想去敲下第一行 Text('Hello World')。但请先停一停，把手从键盘上拿开。在我的团队里，如果一个工程师在没搞清楚“为什么要做”之前就开始写代码，通常是要被我“请”去喝咖啡的。

写代码很容易，但写出有价值的代码很难。对于只有 3 年左右经验的开发者来说，你可能已经很熟悉 API 的调用，能熟练地画出界面，但你是否想过：为什么市面上已经有 1000 个录音 App 了，我们还要花时间去造第 1001 个？

这不仅仅是一个技术问题，更是一个生存问题。独立开发者的资源是极其有限的，如果我们只是在存量市场里做“微创新”，比如把按钮做得圆一点，或者把动效做得滑一点，那我们注定会被大厂的流量碾压。我们要做的，是换个维度打击。

今天，我不教你配置环境，也不教你写 UI。我们要像一个真正的产品经理那样，把“会议随记 Pro”的灵魂拆解开来。你看，当我们把产品逻辑想透了，后面的代码其实就是顺水推舟的事情。

一、 审视红海：市面上的录音 App 到底错在哪？

让我们先做一次残酷的竞品分析。

你可以现在就拿起手机，打开应用市场，搜索“录音机”或者“会议记录”。你会发现排名前列的应用，功能都非常强大：降噪算法一流、转文字准确率 98%、支持几十种语言。看起来，这个赛道已经拥挤得连插针的地方都没有了。

但是，作为一名在职场摸爬滚打多年的管理者，我手机里装了四五个这类 App，却依然感到痛苦。为什么？因为它们解决的只是**“物理层”的问题——把声波变成文件。它们并没有解决“认知层”**的问题——把信息变成资产。

请回忆一下你真实的工作场景：你刚结束一个关于“Q4 营销预算”的会议，紧接着又跑去参加“后端架构评审”。你用录音 App 记录了全过程。一个月后，当你想找“架构评审里关于 Redis 集群的那个决定”时，你打开 App，看到的是什么？

是一个长长的列表：

• 录音_20251024_100102.m4a
• 录音_20251024_143000.m4a
• 新录音 3

这时候你的内心是崩溃的。这些文件就像是一堆数据尸体，它们安静地躺在手机的存储角落里，毫无生命力。因为它们缺失了最重要的东西：上下文（Context）。

大多数 App 的逻辑是“线性”的：点击录音 -> 生成文件 -> 结束。它们把会议当成了一个孤立的事件。但现实工作不是这样的。会议从来不是为了开会而开会，会议是为了推进某个项目，或者是为了与某些人达成共识。

这就是我们的突破口。

我们要做的，不是一个更好的“录音机”，而是一个**“会议资产管理系统”。我们要解决的痛点，是检索的失效和上下文的丢失**。我们要让用户在录音的那一刻，就强制性地建立起数据的关联。

你看，当我们把视角从“工具”切换到“资产”时，竞争对手瞬间就变少了。我们不再是和那些做音频算法的大厂拼降噪，我们是在和那些做笔记、做管理的工具抢时间。

二、 铁三角模型：项目、人脉与会议的化学反应

既然找到了痛点，我们就需要构建一套新的产品模型来解决它。在“会议随记 Pro”中，我设计了一个稳固的**“铁三角模型”**。

这个模型的核心理念是：没有任何一个会议是孤立存在的。

1. 锚点一：项目（Project）—— 归档的容器

我们在设计 App 的时候，必须砍掉“直接录音”这个看似便捷的功能。这听起来很反直觉，对吧？通常我们都觉得操作越少越好。

但在这里，便捷是资产的大敌。如果允许用户随意录音而不归类，那么这些录音大概率永远不会被再次打开。所以，我们的逻辑是：无项目，不录音。

用户在开始录音前，或者在录音结束的瞬间，必须指定这条录音属于哪个“项目”。比如“HarmonyOS 重构”项目，或者“2026 春季招聘”项目。

这样做的好处是巨大的。三个月后，当用户想复盘“招聘情况”时，他不需要在几百条录音里大海捞针，只需要点开“春季招聘”这个项目卡片，所有相关的面试录音、评估笔记，全部按时间轴排列得整整齐齐。这种结构化的快感，就是我们产品的核心竞争力之一。

2. 锚点二：人脉（Contact）—— 价值的链接

很多时候，我们回想不起会议的主题，但我们一定记得是和谁开的会。

“上次和王总吵架那次……”

“就是面试那个 Java 候选人的时候……”

人，是记忆最强的索引。市面上的录音 App 很少有做联系人管理的，顶多就是让你在标题里打个字。我们要把“人脉”做成一级公民。

我们在 App 里内置一个完整的联系人管理模块。每一次会议，用户都可以关联多个参会人。这不仅仅是为了标记，更是为了统计。想象一下，当用户点开“王总”的头像，系统告诉他：“过去一年，你和王总开了 45 次会，累计沟通时长 120 小时。”

这是一个非常震撼的数据。这不再是冷冰冰的通讯录，这是人脉价值的数字化投影。对于商务人士、销售、管理者来说，这个功能简直是刚需。

3. 核心实体：会议（Meeting）—— 数据的载体

项目是容器，人脉是链接，而会议本身，则是承载音频、笔记、图片、待办事项的实体。

你看，通过这个铁三角模型，我们将碎片化的声音数据，用“事”（项目）和“人”（人脉）这两根线串了起来，编织成了一张知识网络。这就是我们说的“第二大脑”。

三、 用代码思维定义产品：核心数据结构设计

作为开发者，光有产品概念是不够的。我们需要把这些飘在天上的概念，落地成实实在在的代码结构。对于 3 年经验的开发者来说，能够迅速将业务逻辑转化为数据模型（Schema），是一项关键能力。

在 HarmonyOS 开发中，我们使用 TypeScript 来定义这些接口。虽然我们还没开始建数据库，但我们可以先在脑子里，或者在草稿纸上，把这三个核心实体的“形状”画出来。

这是我为“会议随记 Pro”设计的核心数据结构，你可以把它看作是产品的DNA：

1. 项目模型 (Project)

项目需要具备区分度，所以除了 ID 和名字，我设计了 color 字段。用户可以给不同的项目分配不同的颜色，比如紧急项目用红色，常规项目用蓝色。这种视觉上的区分能极大降低用户的认知负荷。

// features/project/model/Project.ts

export interface Project {
  /**
   * 项目唯一标识 (UUID)
   * 经验之谈：永远不要用自增 ID，分布式场景下 UUID 是永远的神
   */
  id: string;
  
  /**
   * 项目名称
   * 例如："HarmonyOS 原生适配专项"
   */
  name: string;
  
  /**
   * 项目描述
   * 用于列表页的副标题展示
   */
  description?: string;
  
  /**
   * 项目主题色 (Hex 字符串)
   * 例如："#0A59F7"。UI 渲染时会直接读取这个颜色值
   */
  color: string;
  
  /**
   * 创建时间戳
   * 用于排序，新创建的项目排在前面
   */
  createdAt: number;
  
  /**
   * 更新时间戳
   * 每次修改项目信息，或者该项目下新增了会议，都要更新这个时间
   * 这样可以让“最近活跃”的项目自动浮动到列表顶部
   */
  updatedAt: number;
}

2. 联系人模型 (Contact)

联系人不仅仅是名字。为了实现我们承诺的“人脉价值统计”，我们需要预留统计字段。虽然在关系型数据库中，统计数据通常是实时查询出来的，但在内存模型中，我们可以定义这些字段以便 UI 展示。

// features/contact/model/Contact.ts

export interface Contact {
  id: string;
  name: string;
  
  /**
   * 头像路径
   * 注意：我们只存沙箱路径，不存 Base64，防止数据库膨胀
   */
  avatar?: string;
  
  title?: string;   // 职位，如 "产品总监"
  company?: string; // 公司，如 "华为"
  phone?: string;
  
  /**
   * [UI专用] 关联的项目数量
   * 这是一个计算字段，不会直接存在数据库表中
   */
  relatedProjectCount?: number;
  
  /**
   * [UI专用] 累计沟通时长（秒）
   * 这就是我们“人脉价值”的核心体现
   */
  totalMeetingDuration?: number;
  
  createdAt: number;
  updatedAt: number;
}

3. 会议模型 (Meeting)

这是最复杂的实体。它需要同时持有 projectId 和 attendeeIds。注意，在 SQLite（鸿蒙的 RelationalStore）中，是不支持直接存储数组的。

这里有个实操的细节：对于参会人列表（List），我们在存数据库时通常会序列化成 JSON 字符串，但在 TypeScript 接口中，我们可以定义得更灵活一些，或者在存取层做转换。

TypeScript

// features/record/model/Meeting.ts

export interface Meeting {
  id: string;
  title: string;
  
  /**
   * 关联的项目 ID
   * 这是一个外键，指向 Project 表
   */
  projectId?: string;
  
  /**
   * 参会人 ID 列表
   * 在数据库中存为 JSON 字符串 "['id1', 'id2']"
   * 在业务层转为数组使用
   */
  attendeeIds: string[]; 
  
  startTimeMs: number;
  durationSec: number;
  
  /**
   * 录音文件的物理路径
   * 必须是应用沙箱下的相对路径或绝对路径
   */
  audioPath: string;
  
  /**
   * 核心功能：心情/状态
   * 比如会议气氛很火爆，打个 🔥；会议很无聊，打个 💤
   */
  emojis: string[];
  
  createdAt: number;
  updatedAt: number;
}

你看，通过这三段简单的代码，我们其实已经把“会议随记 Pro”的骨架搭起来了。这就是数据驱动开发的力量。

四、 进攻型功能：会议成本计算器的心理学

有了稳固的铁三角，我们还需要一个尖刀功能来撕开市场。这就是我在前言中提到的**“会议成本计算器”**。

这个功能的逻辑非常简单，技术实现上可能只需要几行代码：cost = duration * hourlyRate。但它的产品意义极其重大。

1. 痛点洞察

大多数人对“时间流逝”是不敏感的，但对“金钱流失”是极度敏感的。职场中充斥着大量的“垃圾会议”，大家坐在里面玩手机，因为觉得“反正工资照发”。

2. 解决方案

我们要把隐性的成本显性化。

我们在设置页允许用户输入一个“平均时薪”。假设是 200 元/小时。

当会议进行录音时，界面上不仅显示 00:30:00（时长），还要在旁边用醒目的红色字体显示 ¥ 100.00（成本）。

随着秒针跳动，金钱也在跳动。

3. 产品价值

这不仅仅是一个计算器，它是一种心理暗示。

• 对于管理者：它是一个监控工具，提醒自己控制会议时长，通过热力图把控团队节奏。
• 对于个人：它是一个自我驱动工具，看到时间如此昂贵，提升效率会成为本能。
• 对于自由职业者：它是精准的计费工具，核算投入产出比。

这个功能将成为我们 App 的“传播点”和“记忆点”。用户可能记不住你的 App 叫什么名字，但他们会记得“那个能算开会花了多少钱的 App”。

五、 原型草图：从抽象到具象

在写代码前，我们最后一步工作是将这些逻辑转化为页面流。我不建议直接上高保真的 UI 设计，对于独立开发者，白板草图就足够了。

我们可以构思四个核心页面：

1. 首页（项目看板）：
   • 这不是录音列表，而是项目卡片流。
   • 顶部是“所有项目”的概览。
   • 每个卡片显示项目名、颜色、会议数量。
   • 底部有一个巨大的、悬浮的“+”号，或者直接是一个“开始录音”的胶囊。
2. 录音页（核心战场）：
   • 巨大的声波纹（Canvas 绘制）。
   • 醒目的计时器和成本计算器。
   • 实时笔记区：这是关键交互。底部有一排按钮“记重点”、“拍照片”、“标记 TODO”。点击按钮，不仅记录文字，更要在时间轴上打一个点。
3. 详情页（复盘中心）：
   • 顶部是波形图和播放进度条。
   • 中间是“音文同步”的笔记流。点击笔记，音频直接跳转（Seek）。
   • 底部是关联信息：所属项目、参会人头像。
4. 人脉页（价值统计）：
   • 联系人列表。
   • 详情页展示“价值仪表盘”：沟通时长、频次。

六、 总结与下一步

今天这篇文章，我们没有打开编辑器，但我们做的事情比写 1000 行代码更重要。

我们拒绝了存量竞争，放弃了做一个简单的“录音机”，而是选择了一条更难但更有价值的路：构建一个基于“项目+人脉+会议”铁三角模型的资产管理系统。 我们还确立了“成本计算”这一差异化功能，并用 TypeScript 预演了我们的数据结构。

这就是中高级开发者与初级开发者的区别：先谋而后动。

如果你已经迫不及待想要把这些想法变成现实，那么请保持这股热情。

官方参考链接

• HarmonyOS ArkTS 语言指南