Meldwork/docs/product-iteration-plan.md

Meldwork 技术迭代与可靠性验证计划

日期：2026-09-11。状态：技术修复与验证计划；商业验证和长期产品路线仅作为后置记录，不是本轮开发目标。

依据：产品战略、商业调研。本版替代已经锁定 Merge Readiness 的阶段路线，先用客户任务选出入口。

1. 本轮目标

在不影响群聊和私聊主链路的前提下，修复会导致错误完成、重复上下文、Agent 误识别、运行状态不准确和恢复不可靠的技术问题。运行核心保持跨 Agent 通用性，先用真实 Electron 和 focused tests 证明行为，再考虑产品或商业扩展。

商业试点、长期产品定位和付费实验留在现有策略文档中，本轮不因商业假设增加 Agent、Connector、角色或云端能力。

技术验证的判断顺序。 以下是基于当前代码审查和 GitHub issue 的修复顺序；技术开发的完成状态以实际 diff、focused tests 和 Electron 运行记录为准。

需要验证的判断	最小可检查证据	证据不足时的选择
群聊不会错误完成	明确失败、空结果、预算停止和用户采用是不同状态；成功路径仍保留完整结果	先阻止错误完成，再处理商业或定位问题
持久 session 不重复广播	continuation 只发送增量上下文，群聊历史不会被每个 Agent 重复注入	保留必要的来源和 provenance，避免全量回放
Agent 发现与运行前提一致	探测结果、认证状态、能力契约与真实 invocation 使用同一判定	不扩展目录，先修错误识别和错误归因
中断与重试可解释	unknown outcome、retry、cancel 和恢复状态可持久化且不重复产生副作用	不能证明时停在 Human Gate，不自动假设成功

前三项决定近期是否值得扩大投入；第四项需要持续观察，不能由一次演示证明。访谈数量、案例数量和复购门槛用于控制投入，不能替代上述证据。

2. 前两周 复现与修复技术问题

本轮优先处理 GitHub issue #57、#58，并复核 #59、#60、#61 是否能在不改变群聊/私聊契约的前提下纳入同一修复批次。商业客户访谈不阻塞技术修复。

围绕每个 issue 建立最小可复现用例：

1. 输入中包含明确失败回复、空结果、历史提及和真正完成回复时，群聊终态是否准确。
2. 持久 session 在群聊 continuation 中是否只接收必要增量，私聊是否保持原有上下文。
3. Agent 探测、认证、能力声明与实际 invocation 是否一致。
4. 中断、重启、retry 和 unknown outcome 是否保持 durable 状态且不重复副作用。
5. 每个修复是否有 focused regression test 和真实 Electron 验证记录。

先记录现有方法再展示方案。拒绝、偏好单 Agent、不愿换入口、没有预算的回答全部保留。

只有通过上述技术验收后，才把结果提供给商业试点或长期产品路线使用。

3. 产品可靠性优先项

以下是代码审查与市场反馈支持的待办方向，实施前仍须复现。

顺序	用户结果	通用约束	验证
P0	原生可用 CLI 被正确识别，失败明确	安装、协议、认证、当前运行分别留证；普通正文不污染认证状态	已/未登录、同名程序、网络受限、Keychain 失败、部分 Agent 失败；真实 Electron
P0	任务不被外层擅自替换	不靠品牌、Skill 名或媒体词决定路由	换契约兼容 Agent 仍成立；普通任务无意外外部副作用
P0	群聊结束状态准确	明确协作请求队列为空时触发 AI 收尾判断；正文提及不直接派发；完成依据与人类采用分离	沉默无产出、否定/历史提及、明确继续请求、只读阻塞、真实成功、预算停止分别验证
P1	中断或重启后可继续	任务与原生 session 区分；恢复可解释；避免重复回放全部历史	会话连续、引用有效、取消后不重复执行、版本限制可见
P1	单 Agent 与按需协作均顺畅	同一套任务和结果，不强制角色轮次	单 Agent/手动双 Agent/Meldwork 路径记录人工与质量

代码修复遵守现有边界、聚焦测试与桌面验收；不以增加认证 Agent 数量作为本阶段结果。

4. 第三至六周 标准试点

选定群体完成至少 6 个同类案例，争取至少 3 个独立客户实际付款。可以人工补位，但动作和时间逐次记录。

标准交付包：冻结输入与版本、约定交付、依据、未解决事项、客户采用决定和一次约定复核。只规定结果，不固定 AI 推理步骤或角色。

报价实验：国内 1,500–3,000 元/项、海外 250–500 美元/项。写清范围、人工和模型费用，记录拒绝及折扣，不能把报价当作已验证支付意愿。

可报价的非代码首单候选（2026-09-09 讨论补充）。 一项 AI 技术选型或产品方案的证据复核：限定一个决策问题、最多三个备选方案和约定材料范围，交付建议及适用条件、可追溯依据、主要分歧、未解决事项，以及一次约定范围内的修订。客户在开始前确定验收人、决策时间和新增调研边界；超出范围重新报价。此候选便于验证专业服务收益，不代表非代码买方或价格已被市场验证，也不立即建设专用行业功能。

首单同时记录每项人工工作由谁完成。若客户付费主要购买创始人的专业判断，按服务收入评价；只有客户能重复自行完成任务、愿为软件能力付费，才推进订阅。客户当前原生 Agent 加普通文档/Git 的最佳方法也必须进入对照，防止将已有工具可以低成本完成的工作误当成独立工作台的优势。

对照设计：

• 客户当前最好用的单 Agent 方法作为基线，允许惯用 Skills 和工具。
• 手动双 Agent 用于区分多一个模型与 Meldwork 协调各自的收益。
• Meldwork 记录 Agent、模型版本、实际参与数、人工补位及成本。
• 优先用匹配难度的不同真实任务；重复同一任务时冻结输入、独立会话并随机展示，记录学习效应。不重复真实不可逆操作。
• 同时记录固定预算下质量与达到同一验收标准的成本，不将更高 Token 预算收益等同架构收益。
• 尽量由不知道工具标签的人验收；缺少独立评价者时注明偏差，保留漏检、误报、失败和放弃任务。

分开记录人工分钟、模型等待和总日历时间。6 个案例只能指导下一步，不宣称统计证明。

5. 第七至十二周 复购与软件价值

观察下一项真实工作是否再次购买或主动使用。重复使用分母为首次成功后 30 天内有下一次任务机会的客户，同时报告全部激活客户、尚无后续任务者和失败者，避免筛选出“好看的留存”。

只将至少两个独立客户反复需要的步骤产品化，如任务恢复、交付版本、依据引用、采用记录和本地导出。用户能自行操作后，再测试国内 49–99 元/月、海外 15–25 美元/月。

投入闸门属于团队管理假设，不是行业标准：

观察结果	决策
3 个独立客户付费，至少 2 个第二次付费；多数案例同质量下少人工；计入工时后贡献为正	围绕同一客户群小幅扩大并软件化
持续购买人工专业判断但不自行用软件	按服务业务评估，不宣布软件 PMF
主要收益来自单 Agent 连续工作	默认单 Agent，复核与群聊按需
认可但不付费，或支持成本吞噬毛利	修订问题、交付范围或价格
两轮同范围试点仍无复购/重复净收益	停止当前定位投入，重新发现客户问题

6. 本地数据与评价

建议记录任务标识、客户/项目本地标识、目标、输入版本、验收标准、Agent/模型及调用方式、人工操作与分钟、运行成本、交付引用、完成判断、采用决定和后续返工/复购。

缺少后果不能写成质量改善；Agent 自评不是人类采用；文档生成不等于创造客户价值。默认本地、可导出，未经授权不上传群聊/资料或跨客户合并数据。

贡献利润计入创始人工时和获客支持。固定研发、税及机会成本另列，不把正贡献利润写成企业净利润。

7. 暂不投入

云会话、远程群成员、固定自动组队/竞价、跨客户声誉排行榜、Skill 市场、企业多租户、基于媒体关键词的专属服务，不进入本轮路线。

业务模板可定义材料、输出和评价方法，不要求特定 Agent 品牌，也不把行业推理写入核心业务分支。必要协议适配不属于应消除的定制。

8. 实施边界

本次仅更新研究与策略。开始代码改动前重新读取工作树、复现问题、明确文件，再按项目规则做测试和 Electron 验证。旧 V4/分支/测试数字属于历史记录，不是当前发布能力证明。