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>
178 lines
4.9 KiB
Markdown
178 lines
4.9 KiB
Markdown
# 09. 产品演示脚本
|
||
|
||
## 演示目标
|
||
|
||
用 5 分钟讲清楚 Heicode 的核心价值：
|
||
|
||
> 用户从一个想法开始，绑定自己的代码和云资源，由 Heicode 组织 AI 开发团队完成开发、部署和审计。
|
||
|
||
## 演示准备
|
||
|
||
演示账号：
|
||
|
||
- 使用演示专用账号。
|
||
- 不展示真实密码。
|
||
- 不使用真实生产密钥。
|
||
|
||
演示资源：
|
||
|
||
- 一个演示 Git 仓库。
|
||
- 一个演示 SK 仓库或技能包。
|
||
- 一个演示云资源列表。
|
||
- 一个可展示的模型余额或用量页面。
|
||
- 一个客户端安装包下载入口。
|
||
|
||
## 5 分钟脚本
|
||
|
||
### 0:00 到 0:30 开场
|
||
|
||
话术：
|
||
|
||
> 今天演示 Heicode。它不是一个普通聊天工具，也不是 CodeGW 后台，而是一个从想法到生产的软件生命周期工具。用户输入想法，平台组织 AI 开发团队，并在权限和审计边界内使用代码、文档和云资源。
|
||
|
||
展示：
|
||
|
||
- 首页或 Heicode 登录页。
|
||
- 一句话定位。
|
||
|
||
### 0:30 到 1:00 登录和首页
|
||
|
||
操作：
|
||
|
||
1. 登录 `https://code.xinghanlab.com`。
|
||
2. 进入 Heicode 工作区。
|
||
|
||
话术：
|
||
|
||
> 用户只登录 Heicode。模型、资源、任务、日志和客户端下载都从这里进入，普通用户不需要进入 CodeGW 后台，也不需要直接接触密钥保管器。
|
||
|
||
展示：
|
||
|
||
- 首页。
|
||
- 模型或余额摘要。
|
||
- 客户端下载入口。
|
||
|
||
### 1:00 到 1:45 输入想法
|
||
|
||
操作：
|
||
|
||
输入演示想法：
|
||
|
||
```text
|
||
我想做一个小团队任务管理 SaaS，
|
||
需要登录、项目、任务、评论、通知和后台管理，
|
||
希望部署到 Azure。
|
||
```
|
||
|
||
话术：
|
||
|
||
> Heicode 先把自然语言想法整理成产品目标、功能范围、开发任务和需要的资源。
|
||
|
||
展示：
|
||
|
||
- 需求摘要。
|
||
- 推荐角色。
|
||
- 资源需求提示。
|
||
|
||
### 1:45 到 2:30 资源绑定
|
||
|
||
操作：
|
||
|
||
1. 打开资源绑定。
|
||
2. 选择演示 Git 仓库。
|
||
3. 选择演示云资源。
|
||
4. 展示密钥保管状态。
|
||
|
||
话术：
|
||
|
||
> 资源绑定不是把密钥贴到页面里。用户授权后，真实凭证进入密钥保管器，Heicode 只保存 secret_ref。子 Agnet 能看到的是资源元数据和权限，不是长期密钥。
|
||
|
||
展示：
|
||
|
||
- Git 资源。
|
||
- 云资源。
|
||
- `secret_ref` 或密钥保管状态。
|
||
|
||
### 2:30 到 3:15 角色和权限
|
||
|
||
操作：
|
||
|
||
1. 展示推荐子 Agnet 角色。
|
||
2. 打开某个角色权限。
|
||
3. 展示 manifest 预览。
|
||
|
||
话术：
|
||
|
||
> Heicode 会把资源按角色授权。例如 Backend Agnet 可以读写后端路径，Ops Agnet 可以部署测试环境，生产部署需要客户端审批。
|
||
|
||
展示：
|
||
|
||
- Product、Backend、Frontend、Reviewer、Ops 角色。
|
||
- Resource Grant。
|
||
- manifest 预览。
|
||
|
||
### 3:15 到 4:00 客户端和审批
|
||
|
||
操作：
|
||
|
||
1. 展示客户端下载入口。
|
||
2. 展示客户端登录只指向 Heicode。
|
||
3. 展示高危审批弹窗或审批设计稿。
|
||
|
||
话术：
|
||
|
||
> 客户端不选择模型提供方，也不配置 CodeGW。它只登录 Heicode，使用 Heicode 提供的模型。高危操作，例如生产部署或访问生产密钥，必须在客户端确认。
|
||
|
||
展示：
|
||
|
||
- 客户端登录页。
|
||
- 模型选择。
|
||
- 审批弹窗。
|
||
|
||
### 4:00 到 4:40 执行和观测
|
||
|
||
操作：
|
||
|
||
1. 切回客户端，追加一句新要求。
|
||
2. 展示当前 Agnet 子环节和 SK 工具调用。
|
||
3. 展示任务状态、日志、模型用量和审计。
|
||
|
||
话术：
|
||
|
||
> 主体验在客户端。用户继续补充要求后，Heicode 会调用 Agnet 推进下一子环节，例如开发、测试或修复。Agnet 在过程中还可以调用已授权的 SK 工具，最后把中间结果、交付物和部署结果回传回来。Manager 负责辅助查看状态、日志、用量和审计。
|
||
|
||
展示：
|
||
|
||
- 客户端追加需求。
|
||
- 当前 Agnet 子环节和 SK 工具调用。
|
||
- 子 Agnet 状态。
|
||
- 日志。
|
||
- 用量。
|
||
- 审计记录。
|
||
|
||
### 4:40 到 5:00 总结
|
||
|
||
话术：
|
||
|
||
> Heicode 的核心不是只生成代码，而是把想法、代码、云资源、模型、密钥、权限、部署和维护组织成一个可审计的软件生命周期。
|
||
|
||
结束 CTA：
|
||
|
||
- 开始使用 Heicode。
|
||
- 查看产品文档。
|
||
- 下载客户端。
|
||
|
||
## 演示注意事项
|
||
|
||
1. 不展示真实密钥。
|
||
2. 不进入 CodeGW 管理后台。
|
||
3. 不展示 OpenBao token。
|
||
4. 不强调底层配置复杂度，强调用户流程。
|
||
5. 如果 Agnet 真实部署尚未联调，明确说当前展示的是 Heicode 侧 payload、manifest 和占位控制面。
|
||
|
||
## 备用 1 分钟版本
|
||
|
||
话术：
|
||
|
||
> Heicode 是从想法到上线的智能开发工具。用户主要在客户端输入想法和继续推进任务，在 Manager 绑定 Git、文档、SK 和云资源并部署 Agnet。Heicode 生成子 Agnet 团队、角色和权限，密钥进入密钥保管器，子 Agnet 只拿短期凭证。Agnet 在执行中可以调用 SK 工具，最后完成交付与部署；CodeGW 提供模型、余额和用量，Heicode 展示日志、状态和审计。用户不需要进入 CodeGW 后台，也不需要管理 OpenBao，只在 Heicode 和客户端完成整个开发流程。
|