chenchenandClaude Opus 4.7
4827682de5
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>
192 lines
4.1 KiB
Markdown
192 lines
4.1 KiB
Markdown
# 05. 产品 PPT 文案
|
|
|
|
## Slide 1：标题
|
|
|
|
标题：
|
|
|
|
> Heicode
|
|
|
|
副标题：
|
|
|
|
> 从一个想法，到可上线的软件产品
|
|
|
|
讲述：
|
|
|
|
Heicode 是一款全流程智能开发 Code 工具。它让用户输入想法，接入自己的代码和云资源，由 AI 开发团队完成需求、开发、检查、部署和维护。
|
|
|
|
## Slide 2：问题
|
|
|
|
标题：
|
|
|
|
> AI 已经会写代码，但软件交付仍然很难
|
|
|
|
要点：
|
|
|
|
- 想法到需求、原型、代码之间仍然断裂。
|
|
- AI 工具通常不能安全使用真实 Git、云资源和密钥。
|
|
- 多 Agent 协作缺少角色、权限、状态和审计。
|
|
- 模型用量、余额和日志分散在后台系统。
|
|
- 部署和后续维护没有统一生命周期。
|
|
|
|
## Slide 3：解决方案
|
|
|
|
标题：
|
|
|
|
> Heicode 把开发过程变成可编排的 AI 团队任务
|
|
|
|
要点：
|
|
|
|
- 用户输入自然语言目标。
|
|
- Heicode 生成任务、角色、权限和执行上下文。
|
|
- 客户端是主体验，Manager 负责资源、部署和审计辅助。
|
|
- 子 Agnet 按角色推进开发、测试、修复和部署，并可调用 SK 工具。
|
|
- 密钥进入密钥保管器，子 Agnet 只拿短期凭证。
|
|
- Heicode 展示模型用量、日志、事件和审计。
|
|
|
|
## Slide 4：产品工作流
|
|
|
|
标题：
|
|
|
|
> 一条从想法到上线的主流程
|
|
|
|
流程：
|
|
|
|
```text
|
|
登录
|
|
-> 客户端输入想法
|
|
-> Manager 绑定资源
|
|
-> Manager 部署 Agnet
|
|
-> 客户端继续推进任务
|
|
-> Agnet 执行开发/测试/修复并调用 SK
|
|
-> 审批高危操作
|
|
-> Agnet 交付与部署
|
|
-> 观测与维护
|
|
```
|
|
|
|
讲述：
|
|
|
|
用户不需要直接操作 CodeGW 后台，也不需要直接管理 OpenBao。所有操作都在 Heicode 和客户端内完成。
|
|
|
|
## Slide 5：核心能力
|
|
|
|
标题：
|
|
|
|
> Heicode 的四个核心能力
|
|
|
|
1. 想法转开发任务。
|
|
2. 资源绑定和权限分配。
|
|
3. 子 Agnet 编排和执行。
|
|
4. 用量、日志、安全和审计闭环。
|
|
|
|
## Slide 6：系统架构
|
|
|
|
标题：
|
|
|
|
> Heicode 产品面连接执行、模型和密钥底座
|
|
|
|
架构：
|
|
|
|
```text
|
|
用户 / 客户端
|
|
-> Heicode Manager
|
|
-> Agnet 平台
|
|
-> CodeGW
|
|
-> OpenBao
|
|
-> Git / SK / 云资源
|
|
```
|
|
|
|
讲述：
|
|
|
|
客户端是主体验，Manager 是辅助控制台。Agnet 平台是执行层，执行过程中可调用 SK。CodeGW 是模型网关和计费服务。OpenBao 是密钥保管器。
|
|
|
|
## Slide 7：安全模型
|
|
|
|
标题：
|
|
|
|
> 资源可用，密钥不外泄
|
|
|
|
要点：
|
|
|
|
- Heicode 服务端数据库只保存 `secret_ref`。
|
|
- 长期密钥进入 OpenBao。
|
|
- 子 Agnet 只获得短期、最小权限凭证。
|
|
- 高危操作必须在客户端审批。
|
|
- 日志、Markdown、前端响应不包含明文密钥。
|
|
|
|
## Slide 8：用户价值
|
|
|
|
标题：
|
|
|
|
> 让小团队拥有完整软件交付能力
|
|
|
|
对独立开发者：
|
|
|
|
- 更快从想法到 MVP。
|
|
|
|
对创业团队：
|
|
|
|
- 用更少人力完成产品迭代。
|
|
|
|
对企业团队：
|
|
|
|
- 在权限和审计边界内使用 AI 开发。
|
|
|
|
对技术负责人：
|
|
|
|
- 控制资源、成本、质量和风险。
|
|
|
|
## Slide 9：当前 MVP
|
|
|
|
标题：
|
|
|
|
> 当前 MVP 先闭环三件事
|
|
|
|
1. Heicode、CodeGW、OpenBao 解耦部署。
|
|
2. 资源绑定、Resource Grant、manifest 和密钥保管。
|
|
3. 客户端只登录 Heicode，只使用 Heicode 模型。
|
|
|
|
延期项：
|
|
|
|
- Heicode 到 Agnet 平台真实部署 API 的完整联调。
|
|
|
|
## Slide 10：路线图
|
|
|
|
标题：
|
|
|
|
> 从可用工具到生命周期平台
|
|
|
|
阶段：
|
|
|
|
1. 资源绑定和密钥保管。
|
|
2. CodeGW 用户侧模型和用量展示。
|
|
3. 客户端登录、审批和下载闭环。
|
|
4. Agnet 平台真实部署联调。
|
|
5. 自动维护、升级、成本和质量观测。
|
|
|
|
## Slide 11：演示故事
|
|
|
|
标题：
|
|
|
|
> 5 分钟看懂 Heicode
|
|
|
|
演示：
|
|
|
|
1. 登录 Heicode。
|
|
2. 客户端输入产品想法。
|
|
3. Manager 绑定 Git 和云资源。
|
|
4. Manager 部署 Agnet 并展示权限。
|
|
5. 客户端继续推进任务。
|
|
6. 展示 Agnet 调用 SK 和当前子环节。
|
|
7. 客户端审批高危操作。
|
|
8. 查看交付、部署结果、日志和模型用量。
|
|
|
|
## Slide 12：结束页
|
|
|
|
标题：
|
|
|
|
> Heicode，让想法进入真实开发流程
|
|
|
|
收尾语：
|
|
|
|
> 不是只生成代码，而是把产品、代码、权限、模型、部署和维护组织成一个可审计的软件生命周期。
|