SCHEDULE-AND-DECISIONS.zh.md 7.3 KB
决策建议与 AI 开发工期估算（回应 OPEN-1/2/3）
调研日期：2026-08-23 ｜ 依旧只调研不行动：本文件全部为建议，未改动 DSHohos 工程任何配置
1. 命名建议（OPEN-1）
现状
工程名 DSHohos，bundleName 为 com.example.dshohos（DevEco 模板占位）。
生态命名惯例（实测归纳）
DSH 生态的事实命名模式是 dsh-<平台/形态>，且已被官方生态认可：
| 项目 | star | 命名 |
|---|---|---|
| dsh-TUI（官方公众号收录） | 2,343 | dsh-形态 |
| dsh-web-ui | 5,668 | dsh-形态 |
| dsh-market | 1,936 | dsh-功能 |
| dsh-desktop / dsh-desk | 21 / 16 | dsh-平台 |
| dsh-ohos-patch（鸿蒙 CLI 适配） | 5 | dsh-平台(ohos) |
建议
- 推荐：DSH Harmony（仓库名 dsh-harmony）。理由：a) 精确对齐生态 dsh-<平台> 惯例；b) Harmony 是华为官方平台词（HarmonyOS），而我们目标是 HarmonyOS PC 商业版——ohos 实为 OpenHarmony 开源社区缩写，语义上略偏；c) 开发方案文档与工作区目录已在用 dsh-harmony，一致性好。
- 保留 DSHohos 也完全可行：语义无误、已有工程在手，切换有成本。两者差异主要在生态辨识度，不影响功能。
- bundleName 无论选哪个都必须在首发前改：com.example.* 是保留前缀，华为应用市场不接受。建议自有域名反写（如 com.<你的域名>.dshharmony），此项等你定域名/厂商名后再改，不急。
- 审核风险提示：应用名含 DSH/DeepSeek 指向词，上架审核可能要求品牌资质（anywhere-labs 特意声明与 DeepSeek 无隶属即为此因）。建议准备一个中性备选显示名（如「鸿蒙智能体工作台」）作为 Plan B，首发若受阻即切换。
2. API 版本建议（OPEN-3）
版本对应关系（官方 Release Notes + 社区数据交叉确认）
| API | 正式版本 | 渗透情况 |
|---|---|---|
| 20 | HarmonyOS 6.0.0 | 当前主力存量（6.1 占比仅约 23%，大量设备在 6.0） |
| 23 | HarmonyOS 6.1.0 | 推广中 |
| 26 | HarmonyOS 7（Beta，本机模拟器即此版） | 未大规模推送 |
建议：compatibleSdkVersion = 20，targetSdkVersion = 26
- compatible = 20（HarmonyOS 6.0.0）：精准命中「必须支持鸿蒙原生 6 以上」——再低（17/18）覆盖 5.x PC 但你已排除；再高（23）会把 6.0 主力存量挡在门外
- target = 26（HarmonyOS 7）：用最新工具链编译、按最新平台行为对齐（官方推荐模式：target 高、compatible 低，向前兼容运行）
- 本地已验证可行性：SDK 20 中本产品所需全部 12 个 API 模块（http/webSocket/socket/UIAbility/window/webview/picker/preferences/relationalStore/notificationManager/asset/childProcessManager）齐备且 API 面完整（各文件最大 @since 均 ≤ 20）
兼容性纪律（开发方案 8 节技术选型的补充）
- 模拟器是 API 26，无法本地验证 API 20 行为差异——三重替代：a) 编译期检查（DevEco 对超过 compatibleSdkVersion 的 API 调用会标红/告警，作为 CI 门禁）；b) 运行时 canUse 特性探测；c) HarmonyOS 6.x 真机回归每阶段一轮（需你配合）
- HarmonyOS 7 (API 26) 新增的悬浮窗/闪控球等能力只作增强（如审批提醒悬浮窗——这是个不错的差异化点），基础功能绝不依赖 21+ API
- 每次发版前跑一次全 API 调用扫描（脚本可自动化：grep 所有 @ohos.* 调用对照 @since 表）
3. AI 开发工期估算（OPEN-2，双速策略）
估算模型（先声明假设，才谈得上严谨）
AI 加速项（本 harness 可自主完成，5-10 倍于人日产出）：
- 全部代码产出（ArkUI 页面/组件、协议适配层、Supervisor/升级管家移植）——本机可直接跑 hvigorw 编译自校验
- 协议 fixture 录制：本机 dsh web + Playwright 抓 /api 流量，全自主
- 单元测试与契约测试编写
不可压缩项（决定下限）：
- 真机验证回路：MateBook Pro 模拟器已部署（HarmonyOS 7 Beta），构建→部署→hdc 截图→读图验证的闭环 AI 可自主跑；但 HarmonyOS 6.x 真机回归与 hnp 常驻服务安装验证需你执行命令，每轮异步等待 0.5-2 天
- 关键决策等待（如本文件三项决策）：每个 0.5-1 天
- 未知坑探索（ArkTS 严格类型边界、PC 窗口行为）：P50 每阶段 1-2 天冗余
- 应用市场审核：外部因素 3-7 天，不在开发估期内
- dsh 官方 rc 演进的协议适配：随发处理，每次约 0.5-1 天，不在估期内
双速计划排期
| 阶段 | 内容 | 工期（工作日，P50） | P90 | 里程碑 |
|---|---|---|---|---|
| P0 链路 Spike | 协议 fixture 录制；ArkTS HTTP+WS 客户端编译通过；模拟器加载 dsh web 验证；hnp 常驻服务方案真机验证 | 3-5 | 7 | 技术不确定性清零 |
| P1 Web 壳首发版 | 工程骨架+Web 组件；Supervisor（attach+首启向导）；daemon 控制通道+升级管家 v1+冒烟回滚；托盘/通知/签名打包 | 6-9 | 12 | 鸿蒙首发卡位（对齐 macOS 薄壳产品形态） |
| P2a 协议适配层 | Typert 编解码+投影分发+重连代际+契约 fixtures 全量+单测 | 4-6 | 8 | 协议层 90% 覆盖 |
| P2b 原生会话体验 | 消息流/Markdown 渲染器（最大单体）/工具卡片/审批弹层 | 8-10 | 13 | 日常可用，替换壳版主界面 |
| P2c 功能完整 | todo/goal/plan/子代理/jobs/附件引用/设置/主题 | 4-6 | 8 | 对照功能基线 P0+P1 全绿 |
| P2d 升级体系 | 契约矩阵 CI+版本适配器+能力协商+WebView 逃生舱 | 3-4 | 6 | 官方发版 24h 内适配闭环 |
| P2e 打磨发布 | 性能（万级事件）/异常恢复/本地化/签名分发 | 3-4 | 6 | 稳定版 |
汇总
| 路线 | 总工期 P50 | 总工期 P90 | 对比原人力估算（16 周） |
|---|---|---|---|
| 双速（先壳后原生，推荐） | 约 7-9 周 | 约 10-11 周 | 压缩近一半，且 2-3 周即有首发卡位与真实反馈 |
| 单速（直接方案C） | 约 6-8 周 | 约 9-10 周 | 省去壳版 2-3 周，但放弃首发卡位与早期用户验证 |
关键路径与并行度
- 关键路径：hnp 常驻服务真机验证（P0）→ daemon 控制通道（P1）→ 协议 fixture 全量（P2a）→ Markdown 渲染器（P2b）
- 可并行：协议层与 UI 组件可由子代理并行推进（协议层零 UI 依赖的设计正为此）；真机回归等待期与下一阶段开发重叠
- 最大不确定项：Markdown 流式渲染器性能（长代码块场景）——P2b 内已含 2 天探索冗余，若超预期则首版降级为「完成态高亮」策略
结论
双速策略下：2-3 周出鸿蒙首发壳版（抢唯一空窗），7-9 周达成完整原生版。你判断的「AI 开发用不了那么久」成立——原 16 周是按人力估算的保守值，AI 模式下瓶颈从编码转移到真机验证与决策等待，本估算已按此重排。
附：本轮调研新增事实
- 本机已部署 MateBook Pro 模拟器（HarmonyOS 7.0.0 Beta1 / API 26 / 2in1 形态，2026-08-23 配置）——AI 验证闭环可自主运转
- hdc v3.2.0e 可用（DevEco SDK toolchains 内），当前无真机连接
- HarmonyOS PC 始于 5.0.5(17)（2025-05 首发），HarmonyOS 6.0(20) 为当前主力版本，7(26) 尚在 Beta