> 2026-10-24 身份更正：字太白、Only 系列昵称、Redbin／Redbin🐉均为项目发起人本人，相关发言与责任统一归并，不能作为多人协同的证据。原群成员计数为账号数。下方历史角色分析应结合此更正阅读；新项目实名分工以“人员分工与阶段验收”网页为准。

输入法项目复盘与 Lovetips 一个月执行计划

编制日期：2026 年 10 月 24 日。资料来源：微信 2「输入法」群本机可访问记录；用户补充的兼职安排；Lovetips 官方商店页面和苹果官方审核指南。

阅读范围与结论边界

已沿时间线浏览本机可见文字，从最新的 10 月 23 日回溯到 1 月 4 日 11:49 的记录起点，并在顶部继续上翻确认没有更早内容。不是聊天数据库导出审计；没有逐一播放语音、视频、读取图片正文或打开所有附件、私聊和代码仓库。因此以下是对可见群文字的复盘，不能证明全年所有实际工作、附件中的全部要求或当前软件真实质量。群内昵称有变动，普通消息的可读界面也不总显示发送者，无法确认作者的发言不强行归因。

最重要的判断：项目已经产出实际成果，团队也有解决复杂问题的能力；持续拖延更像是低优先级兼职项目缺少稳定交付机制，叠加输入法基础工程被低估、需求反复补齐、上线依赖后置。不能仅凭聊天把责任归结为某个人“不努力”或“技术不行”。

用户补充“每天 4 小时”，本计划暂按两位客户端开发各自每天 4 小时理解。为避免把每天都能投入当作既定事实，正式承诺先按每周 5 天、每人 20 小时计算；周末不预支。尚未确认“完成”具体指内测、提审还是正式上架，本计划将这三项分别列出，不承诺审核结果。

一、项目实际上经历了什么

二、做得不错的地方

• 有能落地的技术团队。 iOS 从键盘、APP 到上架形成了实际成果；安卓定位了快速打字锁、多点触控和点击区域问题，持续发包；后端持续补字段、套餐和接口。评价应建立在这些交付上，而非群消息多少。

• 技术协作真实存在。 双端交流 Rime、词库、英语、包名、性能、皮肤和交互，不是各做各的。1 月就指出手写和上下文联想限制，并缩减过首版皮肤范围，这是好的取舍方式。

• 测试已经有雏形。 有反馈文档、腾讯表格、录屏、崩溃文件、不同机型复现；8 月出现明确验收，9 月强调修复后标记。可以升级现有流程，不必重新买复杂系统。

• 商业化意识强。 关注套餐后台配置、投放归因、转化和付费链路；4 月明确倾向苹果原生内购。下一个项目应保留这些能力，但提前确定最小方案。

• 协作关系有信任基础。 能坦承没时间、不了解、实现有问题，能直接沟通并配合解决。朋友关系是协作优势，适合用明确约定保护，而不是靠人情承担无限加班。

三、主要不足及其根因

1. 最大问题是没有一个持续负责“收口交付”的人

群里有很多催问和阶段性努力，却很少看到连续的每周目标、统一剩余任务清单、延期原因与重新承诺。3 月问“过完年动静没了”，8 月又承认较久没管项目，说明推进主要靠阶段性关注。

建议由公司内部指定一名每天可投入至少 45—60 分钟的推进负责人。你负责产品取舍和资源决策，不必亲自追每个 bug。推进负责人必须每天维护任务状态、拉齐依赖、组织安装包验收。

2. 对“完成”的理解相差太大

“接口完成”“页面完成”“键盘完成”“可以上架”在群里交替出现。2 月的接口完成仍不含客户端联调；4 月键盘可测不等于 APP 可测；9 月准备上架仍缺素材、支付和平台适配；10 月上架后仍补完整埋点和推广资质。

新定义：一个功能只有在真实手机、指定测试身份、真实接口、异常分支和数据上报均通过，并有验收人确认，才算完成。写完代码、发了截图、回复“1”均不等于验收。

3. 产品意图清晰，但首版范围没有冻结

你强调尽快上架，也多次要求先不增加优化，这个方向正确；但实际又不断增加价格动效、倒计时、组装动画、周会员、活动入口、未支付提醒等。9 月反复说“再改几处就行”，10 月仍出现功能语义来回变化。

对你的建议最直接：要让一个月成立，你需要承担删减责任。之后任何新需求都写入下一版；确需插入，就明确移出同等工作量的一项，并更新承诺。

4. 设计交付不仅缺页面，还缺状态、流程和平台差异

3 月缺按键状态和符号，4 月补暗色、高亮与动画，9 月继续确认活动页入口、静态演示与真实键盘的区别。10 月又明确指出 iOS 权限流程不适合安卓。

设计交付必须包含：入口、下一步、返回、未登录、无权限、空数据、加载、失败、成功、会员及非会员状态；另列 iOS、安卓、鸿蒙的不同处。首页看起来完整，不代表需求已可开发。

5. 兼职产能未被当成硬约束

记录里反复出现主业忙、出差、需要晚上回家处理、测试包顺延。P7 说明有经验，不能代表每天固定有时间，也不能使安卓和鸿蒙变成两个并行人的产能。

应约定每天固定 4 小时的时间段、缺席提前报告和周度可交付物。实际只能投入 2 小时时，立即减范围，不再继续按 4 小时排期。结算可讨论按验收里程碑分段，金额和条款由你与开发另行商定。

6. 双端靠抄实现结果，导致不必要的串行依赖

10 月 9 日、21 日安卓明确等 iOS 埋点后对齐命名。统一事件名和参数本可以在开发前形成表格，不应等待一个端写完。接口字段也不应长期靠聊天补充。

产品、后端、客户端先共同确定接口样例、错误码、会员状态和事件字典。三端对齐约定，各自实现，不必对齐每一行代码。

7. 上线与运营准备多次后置

1 月已提到上架材料，3—4 月有账号和官网依赖，9 月提审前仍补图和描述；软著资料早被提到，但 10 月投放开户仍发现缺项。这是跟进和用途识别的问题，不能只责怪行政或技术。

必须建立“主体—账号—应用—渠道—材料—负责人—提交时间—审核状态”清单。拿到上架链接也不等于能开户投放；多主体、多包也不应全部放进这一个月。

8. 质量与增长验证过晚

4 月提出等稳定后接日志，9 月才集中验证首装、归因与购买，10 月上线后补全漏斗。这样会把“无法判断为什么失败”的问题拖到最后。

新项目第一周就有日志、请求编号、识别与生成耗时；第二周支付闭合、最小漏斗可查。聊天内容本身不应成为默认全量埋点：10 月有记录提示词及生成内容的要求，但它与普通事件统计应分开设计，默认用脱敏、限量、可删除的测试样本。

四、对成员的公平判断与分工建议

以上是角色建议，不代表已经获得任何成员的时间或职责承诺。

五、Lovetips 首版怎样定义才有机会一个月完成

官方商店页面说明的核心是上传聊天截图、识别对话、推荐不同风格回复。页面不能证明所有后台技术或自动化能力；群内 10 月 22 日又提到录屏、无障碍与安卓权限差异，因此自动获取跨应用内容必须单独评估。

推荐一个月首版主流程：首次打开 → 清楚的说明与必要授权 → 用户选择聊天截图 → 识别并确认双方内容 → 选择少量风格 → 生成回复 → 复制 → 次数及会员购买／恢复。

必须交付

• 用户主动选图；识别不清时可编辑内容、重新选择，识别失败不会卡死。

• 先支持单图及少量固定风格，明确谁说的话、准备回复谁；先做微信典型文字对话。

• 生成、重试、超时、断网、无余额、重复点击均有清晰处理；一次使用次数的口径统一。

• 一个确定的登录方案、游客规则和购买后归属规则；复用成熟组件的前提是实际可复用。

• 先少量套餐；价格、续费说明、权益、购买及恢复路径一致。

• 最小后台：套餐、风格、次数、用户权益、服务开关和基础统计。

• 最小漏斗：首次启动、选图、识别成功／失败、生成成功／失败、复制、付费页、购买成功、恢复成功；端、版本、渠道和耗时可区分。

• 新品牌名称、图标、素材、文案；真实功能对应的上架图和完整审核演示。

第二版优先考虑

自动跨应用录屏／捕获、常驻悬浮、多图长聊天、丰富人设商城、复杂动效、动态降价、重复倒计时、未支付催付、广告换次数、多主体多包、多渠道同时铺开、自建模型或重新做输入法内核。

这一取舍必须由你确认：主动选图版不能宣称等同于 Lovetips 所有自动化功能。 如果你要求自动获取聊天作为首版必要能力，则第 1—3 天必须分别在三端真机演示，验证授权、中断、退出、耗电与上架说明；失败时需要缩小平台范围、增加有对应经验的人，或延后该能力，不能继续维持全量一月承诺。

苹果官方审核指南 4.1 明确反对简单复制热门应用；2.5.4 对后台用途有限制，2.5.14 要求记录活动前明确同意。输入法项目已经有相关审核往返。因此“参考成熟业务流程”可以作为需求方法，“所有界面全部照抄”不适合作为本次排期前提。品牌与主要视觉表达独立完成，自动捕获能力提前验证，可减少末期重做。

六、工时预算：每天四小时怎么用

每人每周 5 天 × 4 小时 × 4 周 = 80 小时，两位合计约 160 小时。两人的小时不能随意互换；安卓和鸿蒙共享同一个 80 小时。30 天里额外的周末时间先作为不确定余量，不提前承诺。

这是预算分配，不是已验证的工时估算。安卓／鸿蒙能否在合计 56 小时完成，是最大的未知数；需要在第 3 天用任务拆分及真机验证重新判断。若功能估算超过预算，优先删第二版功能；若首版核心仍超出，明确改成 iOS／安卓提审、鸿蒙内测，或给鸿蒙增加专人。不要把切换技术栈、AI 翻译代码当作已保证的节省。

后端、设计、测试和资质人员另需明确可投入时间；上述 160 小时不包含他们。后端“一周半”也必须落实为任务、交付物和可用时间。

输入法旧项目一个月内只处理影响使用、支付及上线的严重问题，进入统一队列，非严重优化每周集中一次处理。若旧项目超过每人 8 小时预算，由你当天决定减新项目范围或增人。

七、30 天执行日历

以下以 10 月 25 日为执行起点，11 月 23 日为 30 天结束日。群里 10 月 19 日已经启动的工作不重置、不重复开发，先验收现有成果并折入本表。原 iOS“11 月 20 日才给测试包”的安排应提前拆成周度包；不能等到该日再开始整体验收。

三端正式上架是争取目标，不是只靠内部努力就能保证的结果。新账号、渠道资质和自动化能力若未具备，必须在首三天公开为红项，而不是月底才解释。

八、把计划变成每天可执行的制度

• 一个任务入口。 沿用腾讯表格或团队已有工具即可；微信只通知和讨论。任务字段固定为：编号、平台、验收场景、负责人、依赖人、计划交付、剩余小时、状态、包版本、验收人、证据链接。

• 任务大小控制在 2—8 小时。 “做完安卓”“处理支付”太大；应拆为选图拒绝后恢复、生成失败不扣次数、购买后权益刷新等可验收项。两天以上的任务必须继续拆。

• 每天四小时先定时间段。 推荐 10 分钟确认当日任务，约 3 小时实现／修复，约 30 分钟自测与提交，约 20 分钟联调与更新。会议占用计入工时，避免白天碎片问答反复打断。

• 每天一条进度。 内容只有：今天完成哪个任务、安装包或证据、剩余小时、阻塞谁／什么、明天交付什么。允许直接说做不完，但必须提前给出影响。

• 每周两次实际安装验收。 每次控制在约 20—30 分钟；周中发现偏差，周末验收里程碑。演示成果，少讲百分比。

• 阻塞当天升级。 需要你拍板的原则上 24 小时内决定；客户端等接口时先依约定样例开发，但真实接口必须在第一周贯通；不可用模拟数据冒充联调完成。

• 延期看趋势。 当任务超过估算的 1.5 倍，或周中剩余工时已放不进本周，就报红并重排；两次错过可验收交付，需要缩减范围或调整人手，不能只再给一个新日期。

• 变更必须换出任务。 记录新增理由、成本、换掉哪项、谁确认。不接受群里一句“顺便加一下”直接进入首版。

• 减少上下文切换。 一人同时只推进一个核心开发任务；输入法旧项目集中窗口处理，严重线上故障例外并记录消耗。

九、验收口径与效果指标

功能交付门槛

• 三端分别有版本号、安装包／测试分发地址和可复现步骤。

• 首装、授权同意／拒绝／撤回、断网、超时、识别失败、生成失败、重复点击全部可恢复。

• 游客、非会员、会员三种身份可测；购买成功、取消、失败、恢复购买及权益刷新可验证。订阅状态变化用相应测试环境或可复现实验验证，不等待一个真实计费周期。

• 次数口径统一，失败和重试不会错误扣费；客户端展示与后端及支付平台一致。

• 新手首条真实截图能走通；样例演示与真实功能清晰区分。

• 最小事件能在后台核对，不默认采集聊天原文；测试样本脱敏并限量。

• 材料、演示、支持入口、隐私表述与真实行为一致。

建议在前两天确认的质量目标

以下是建议目标，不是当前测量结果：准备 30 条团队自建或授权、脱敏的对话样本，覆盖左右双方、长文本、表情、浅深背景、压缩图和无效截图；标准清晰截图中至少 90% 的样本能正确识别双方和主要文字。三人盲评时，至少 80% 样本有一条无需大改即可使用的回复。时间指标先在第一周测基线，再约定目标，例如常见网络下首条可用结果的 P90 在 10 秒以内，并明确设备与网络条件。

支付与权益用独立用例表逐项通过，不用一个“总体通过率”遮盖少量严重错误。性能、可用性和回复质量不达标时，先修主流程，不继续堆人设数量和动效。

小范围试用建议 10—20 位目标用户，记录从选图到复制的完成情况、失败原因和一句实际反馈。这个样本只能用于发现问题，不能据此证明商业 ROI。广告归因和留存需在真实渠道、足够样本及支出记录下另行验证。

十、我可以具体帮助落实什么

在你提供后续群更新、安装包反馈或代码访问后，我可以持续完成：

• 把群讨论整理成任务、负责人、依赖、验收条件，识别重复讨论和未关闭事项。

• 对照冻结范围审查新增要求，列出工时影响和应该换出的任务。

• 将开发估算汇总成每周剩余容量，提前指出一人负责安卓和鸿蒙的冲突。

• 制作识别／回复评测样本、异常与支付验收清单、上架材料清单。

• 从周度演示和日志提炼风险，帮助你每天只处理必须拍板的两三件事。

• 在明确授权和工具访问后协助原型、代码、接口文档、测试脚本及材料整理；客户端开发必须审核并真机验证 AI 产物。

当前未替你向群内发送消息、未替成员承诺排期、未设自动提醒，也没有验证代码完成度。要开始执行，最需要的是确认一位推进负责人、冻结范围、每天 4 小时的适用人员和工作日，以及三端“完成”的目标等级。

参考来源

• 群内日期为微信 2「输入法」群可见文字，按日期可回查；报告不重现账号密码、验证码和个人设备标识。

• Lovetips 官方 App Store 页面 ↗：截图识别与多种回复建议的公开功能说明。

• 苹果 App Review Guidelines ↗：4.1 Copycats、2.5.4 后台用途、2.5.14 记录活动的用户同意要求。

• 苹果 ReplayKit 安全说明 ↗：录制前的用户授权机制。