The 2026-05-08 product package (docs/product-package/) redraws the client / Manager boundary. Per 08-client-guide.md §1-7, the client explicitly does NOT carry resource binding, permission grants, or any account / security surface — those move entirely to Manager. This commit removes the client-side resources surface that landed in slices 2-4 (commitsd1db2c1,c0363be,a28c900): Deleted: - cc-haha/desktop/src/api/heicodeResources.ts (API client) - cc-haha/desktop/src/stores/resourceStore.ts (zustand) - cc-haha/desktop/src/pages/ResourceBindings.tsx (page) - cc-haha/desktop/src/components/resources/Modals.tsx (3 modals) - cc-haha/src/server/api/heicode-resources.ts (proxy) Reverted: - Sidebar.tsx: drop the Resources nav item + RESOURCES_TAB_ID import - ContentRouter.tsx: drop the 'resources' branch + import - tabStore.ts: drop RESOURCES_TAB_ID + 'resources' from TabType - router.ts: drop 'heicode-resources' case + handler import - i18n zh.ts + en.ts: strip ~63 keys (sidebar.resources + resources.* + grants.*) Kept (still useful for the new spec's Manager-side data needs): - mcpAuth schema in types/provider.ts - mcpAuth wired through CreateProviderInput / UpdateProviderInput - providerService persistence of mcpAuth on add/update - Path A login flow that decodes JWT exp claims and stores the pair on the saved provider Why keep token persistence even though the client doesn't expose binding/grant UI any more? Per product spec the Manager will surface 余额 / 模型 / 用量 / 调用日志 (§2.3.1 in mcp-server's 待办 doc), and the client will surface high-risk approvals (08-client-guide.md §5). Both flows need a JWT pair we can refresh without re-prompting for password — that machinery is already in place. Next slice candidates per product spec (08 + 10 + 11): - High-risk approval dialog (新增 Tier 1, mock-wired UI first) - Task card + intent input as main client surface - Execution feedback panel (Agnet sub-stage status) - Delivery result panel None of those are in this commit; this commit is purely cleanup. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.4 KiB
4.4 KiB
01. 产品说明文档
产品名称
Heicode
产品定位
Heicode 是一款覆盖软件生命周期的智能开发 Code 工具。它面向的是“从想法到上线”的完整开发过程,而不是单个模型聊天窗口、CodeGW 管理后台或简单的 Agent 控制台。
用户只需要注册登录,输入想法和约束,Heicode 就帮助用户组织子 Agnet 团队,接入用户授权的 Git、SK、项目文档和云资源,完成产品设计、代码开发、代码检查、部署、观测和后续维护。
目标用户
| 用户 | 典型问题 | Heicode 价值 |
|---|---|---|
| 独立开发者 | 有想法但缺工程团队 | 用 AI 团队完成从需求到上线 |
| 创业团队 | 人少、迭代快、交付压力大 | 用 Heicode 编排产品、开发、测试、部署流程 |
| 企业创新团队 | 有资源和代码,但协作成本高 | 在既有 Git 和云资源边界内受控开发 |
| 技术负责人 | 担心权限、成本、质量和审计 | 统一资源授权、模型用量、日志和审计 |
核心价值
- 把自然语言想法变成可执行的软件开发任务。
- 把 Git、文档、SK、云资源变成可授权、可撤销、可审计的资源。
- 把子 Agnet 的角色、权限、模型和上下文组织成可运行的开发团队。
- 把持续开发拆成需求、设计、开发、测试、修复、部署等子环节,由 Agnet 持续推进。
- 让 Agnet 在执行过程中可以调用项目 SK 工具和外部能力,而不是只做一次性任务分发。
- 把模型调用、余额、额度和日志统一展示给用户。
- 把长期密钥放入密钥保管器,只给子 Agnet 短期、最小权限凭证。
- 把开发、检查、部署、维护纳入同一个生命周期闭环。
产品形态
| 产品面 | 说明 |
|---|---|
| Heicode 客户端 | 用户主体验,负责本地对话、输入想法、继续开发、查看执行反馈、接收交付结果和高危审批,只登录 Heicode,只使用 Heicode 提供的模型 |
| Heicode Manager / 浏览器控制台 | 辅助控制台,负责账号与安全、客户端下载、Git/云资源绑定、Agnet 部署、任务状态总览、模型余额与用量、审计与日志查看 |
| Agnet 平台 | 执行层,负责部署和运行子 Agnet,在任务推进过程中完成需求、开发、测试、修复、交付与部署,并回传日志、状态、事件和指标 |
| CodeGW | 内部模型网关与计费服务,普通用户不直接进入后台 |
| 密钥保管器 | OpenBao 实现,保存长期凭证,按审批和权限提供短期凭证租约 |
说明:Heicode 客户端是用户主体验,用户不在网页上编码。Heicode Manager 是浏览器里的辅助控制台,承担资源、部署、状态、余额、审计和下载等辅助操作。真正持续推进任务的是 Heicode 调度下的 Agnet 执行闭环,Agnet 在过程中还可以调用已授权的 SK 工具和外部能力,最终完成交付与部署并把结果回传到客户端。
核心流程
注册登录
-> 输入产品想法
-> 生成产品文档和任务计划
-> 在 Manager 绑定 Git 和云资源
-> 在 Manager 部署 Agnet
-> 客户端继续追加需求和修正方向
-> Agnet 按子环节执行需求、开发、测试、修复
-> Agnet 按需要调用已授权 SK 工具
-> 客户端确认高危操作
-> Agnet 完成交付物整理和部署
-> Manager 查看状态、余额、审计和下载
-> 客户端展示执行反馈和交付结果
-> 持续维护和升级
差异化
| 对比对象 | 差异 |
|---|---|
| 普通 AI 聊天工具 | Heicode 不只回答问题,而是组织资源、权限和执行团队 |
| IDE 插件 | Heicode 不局限于本地代码编辑,而覆盖部署、审计和生命周期 |
| CodeGW 后台 | Heicode 不管理渠道后台,面向用户完成开发任务 |
| 传统 DevOps 平台 | Heicode 以自然语言和 AI 团队为核心,自动生成任务和执行上下文 |
产品承诺
- 用户不需要理解底层模型供应商。
- 用户不需要把密钥交给子 Agnet 长期保存。
- 用户可以清楚知道哪些资源被哪个角色使用。
- 高危操作必须经过客户端审批。
- 所有关键动作都能审计。
当前一句话卖点
从一个想法开始,让 Heicode 组织 AI 开发团队,持续调用 Agnet 完成开发、测试、交付与部署,安全接入你的代码和云资源,把产品推进到生产环境。