删除 chek/2026-06-02_产品维度复审-能力覆盖度.md
This commit is contained in:
@@ -1,117 +0,0 @@
|
||||
# Heicode 产品维度复审：能力覆盖度（说 vs 做）
|
||||
|
||||
> 复审日期：2026-06-02
|
||||
> 评审范围：`HeiCode-Swarm`、`heicode-mananger`、`heicode-macos-release`、`heicode-winos-release`
|
||||
> 评审依据：《Heicode 项目书 v0.2》产品承诺 + 《ASCE v0.1》
|
||||
> 关联文档：`chek/2026-06-01_Heicode全链路代码评审报告.md`（P1–P7 缺陷）、`chek/2026-06-01_需要统一定义的标准清单.md`
|
||||
> 性质：只读代码核查，结论附 `文件:行` 证据。
|
||||
|
||||
---
|
||||
|
||||
## 0. 总判断
|
||||
|
||||
> **Heicode 现在强在“控制面 / API 契约 / 状态裁决”，弱在“真正的执行”。**
|
||||
> 产品叙事是“覆盖软件生命周期的 AI 团队交付平台”，代码现实是“单 Agent 让模型返回文件改动 + Manager 记录状态与契约”。
|
||||
> **越靠近“说什么、记什么”越完整；越靠近“真做了什么”越空。**
|
||||
|
||||
这与项目书 §10「当前状态：单 Agent MVP」自述基本吻合；但**对外产品叙事（AI 团队 / 全生命周期 / 企业驾驶舱）显著超前于执行现实**，做演示/验收时须警惕把“控制面记录”当成“真交付”。
|
||||
|
||||
---
|
||||
|
||||
## 1. 产品支柱覆盖度总表
|
||||
|
||||
| 产品承诺（项目书） | 实现度 | 真相 | 关键证据 |
|
||||
|---|---|---|---|
|
||||
| 全 SDLC（需求→设计→开发→审查→测试→部署→维护） | 🔴 ~20% | 各 stage 多为 callback 字符串标签；执行层对所有角色/阶段跑同一段“让模型返回 files JSON”逻辑 | `HeiCode-Swarm/agent/task_executor.py:248-286`；`agent_role` 仅用于 HTTP 头 `:396-410` |
|
||||
| ├ 需求 / 产品文档 / 原型 / 维护 | 🔴 仅标签 / 缺失 | Product 角色只有模板文案；原型、维护阶段无实现 | `heicode-mananger/heicode/controller/agent_role_template.go:54-64` |
|
||||
| ├ 前 / 后端开发 | 🟡 部分真做 | 确实写文件到 workspace，但前后端同一逻辑、无专属行为 | `HeiCode-Swarm/orchestrator/swarm_runtime.py:602-629` |
|
||||
| ├ Reviewer 审查 | 🔴 仅角色名 | 有 `get_diff` 实现但无人调用；无静态检查、无 review 产物 | `HeiCode-Swarm/agent/git_operations.py:280-302`（无调用方） |
|
||||
| ├ Test 测试 | 🔴 缺失 | 无测试执行环境；`test_report` 是 Manager 模拟器造的 | `heicode-mananger/heicode/controller/agent_control_plane.go:1528-1539` |
|
||||
| └ Ops / 部署 | 🔴 占位 | 只验参 + 落库 + 审批门，Deploy Worker 未接，状态停在 `pending_worker` | `heicode-mananger/heicode/controller/heicode_cloud_deploy.go:14-17,123` |
|
||||
| AI 团队化协作（多角色 Agnet） | 🟡 部分 | 多 Agent 仅在 `ENABLE_SUBTASK_HANDOFF=true` 时按 role 拆任务 + 依赖 + 能力调度；默认单 Agent，无角色专属能力 | `swarm_runtime.py:77-83,602-629` |
|
||||
| 真实资源接入（Git / 云 / SK） | 🟡 部分 | Git 真 clone/commit/push 但靠环境变量、与 Manager 的 resource_grants 未打通；云资源 / SK 只有元数据，Agent 不能真访问云、不能真调 SK | `git_operations.py:32-35`；grants 仅格式校验 `swarm_runtime.py:714-719`；SK 解析拼随机 sha `agent_control_plane.go:1883-1904` |
|
||||
| 安全边界（见 P6） | 🟡 部分 | secret_ref / 明文字段校验补上；值级扫描、lease 真凭证、高危 Manager 阻断仍缺 | `heicode-mananger/heicode/controller/resource.go:170,183` |
|
||||
| 成本与用量可见 | 🟡 ~50% | 余额 / 日志 / 14 天用量图可用（mcp-server 代理 + 内嵌 NewAPI 回退）；CodeGW 四接口不在 Manager Go 内；Agnet 计费（X / EU / 5·8 上限）完全没有 | `web/default/src/lib/heicode-mcp.ts:254-338`；`agent_control_plane.go:695-699`（只校验 instance_count>0） |
|
||||
| 企业研发管理驾驶舱 | 🔴 ~15% | 审计链路有；项目进度 / 里程碑 / Bug 趋势 / ETA / 风险预警 / 质量趋势全仓库找不到；进度 snapshot 的 `failure_rate/avg_duration` 硬编码 0；`CockpitView` 为 dead code | `agent_control_plane.go:1832-1860`（占位） |
|
||||
| 计费版本 / 团队·个人 / tenant | ⚪ 明确不在范围 | 文档明确不引入 tenant/project 作主轴 | `docs/heicode-runtime-auth-newapi-secret-design.md:20-61` |
|
||||
| 三代模式（链式 / Sub / 蜂群） | 🟡 Sub 可用、蜂群灰度 | Sub 单 Agent 跑通；蜂群 DAG 需开关且鲁棒性有缺陷（见 P7） | — |
|
||||
|
||||
图例：🔴 缺失/占位/仅标签 ｜ 🟡 部分 ｜ ⚪ 明确不在范围
|
||||
|
||||
---
|
||||
|
||||
## 2. 最扎眼的「说做不一致」
|
||||
|
||||
### 2.1 “AI 开发团队”实为一个通用写文件 Agent
|
||||
Product / Architect / Frontend / Backend / Reviewer / Ops 六角色在执行层**没有任何行为差异**——同一个 prompt、同一段 `_apply_file_changes`。`context` 里的 `agent_role`/`orchestration_plan` 不进入 prompt，只用于 HTTP attribution。
|
||||
|
||||
- 统一执行逻辑：`HeiCode-Swarm/agent/task_executor.py:232-311`
|
||||
- 角色仅模板文案：`heicode-mananger/heicode/controller/agent_role_template.go:52-124`
|
||||
|
||||
→ Reviewer 不审查、Test 不测试、Ops 不部署。
|
||||
|
||||
### 2.2 “从想法到上线”断在“上线”
|
||||
云部署是控制面草稿：验参、绑 credential binding、落库、审计，然后等一个**尚未实现的 Deploy Worker**。响应固定 `executor: "pending_worker"`，状态停在 `deployment_requested` / `waiting_approval`，云上不会真实发生任何事。
|
||||
|
||||
- `heicode-mananger/heicode/controller/heicode_cloud_deploy.go:14-17,117-124`
|
||||
- `heicode-mananger/heicode/model/agent_cloud_deployment.go:3-7`
|
||||
|
||||
### 2.3 “企业研发管理驾驶舱”几乎是空的
|
||||
项目书 §6.3.1 的整套 PM 指标（项目进度 / 里程碑 / Bug 趋势 / ETA / 风险预警 / 质量趋势）后端聚合与前端页面**基本不存在**。
|
||||
|
||||
- 唯一的进度 snapshot：`failure_rate_1h` / `avg_task_duration` **硬编码 0**，前端未调用 — `agent_control_plane.go:1832-1860`
|
||||
- `CockpitView` 全仓库仅 1 处定义、无 `import` 引用（dead code）
|
||||
- deployment metrics `platform_estimated: true`、CPU/内存为 0 — `agent_control_plane.go:1803-1821`
|
||||
|
||||
### 2.4 “真实资源接入”没接到执行（两张皮）
|
||||
Manager 把 Git / 云 / SK 的绑定、授权、`secret_ref`、credential lease 都建好了，但 **Agent 运行时根本不消费这些**：
|
||||
|
||||
- Git 凭证来自 `GIT_USERNAME`/`GIT_TOKEN` 环境变量，不是 Manager grants — `HeiCode-Swarm/agent/git_operations.py:32-35`
|
||||
- grants 在 Runtime 仅校验 `azkv://` 格式后塞进 context，Agent 不读 — `swarm_runtime.py:714-719`
|
||||
- 云资源：Python Runtime 无 cloud SDK、无 secret 解析
|
||||
- SK：解析只拼随机 `@sha_`，不拉取技能内容；无 skill/tool-call 执行链 — `agent_control_plane.go:1883-1904`
|
||||
|
||||
→ 安全 / 授权链路与实际执行**脱节**：审批、lease、manifest 做得很认真，但执行侧用不到。
|
||||
|
||||
---
|
||||
|
||||
## 3. 本轮 unification spec v0.1 的定位
|
||||
|
||||
团队最近一批提交（`agnet→agent` + client/runtime 统一）是**真交付**，但集中在**客户端入口契约层**，不是执行层：
|
||||
|
||||
| 闭环 | 成熟度 | 说明 |
|
||||
|---|---|---|
|
||||
| 能力发现 → 建任务 → workflow → 审批 inbox → 产物浏览/下载 | ✅ 可用 | 统一入口 `/api/heicode/{sub-agile,swarm}/*`；Runtime 单 markdown → Manager 解析成 `project_folder` 树 + zip |
|
||||
| 本地编辑修订 | 🟡 部分 | Manager 存取 + 冲突检测闭环；但改完 Runtime 不读新基线、manifest 不反映修改、续跑依赖 Runtime 未支持 |
|
||||
| 云部署 | 🔴 占位 | 只发请求看列表，无真实 provisioning |
|
||||
|
||||
证据：`heicode-mananger/heicode/controller/heicode_client_routes.go`、`heicode_task_create.go`、`heicode_project_artifacts.go`、`heicode_artifact_edits.go`、`heicode_cloud_deploy.go`；统一文档 `docs/integration/heicode-desktop-unified-api.md`。
|
||||
|
||||
并且这轮已修复 P1/P2：Manager 成为唯一裁判 `agentDeploymentDisplayStatus`（无产出的 completed 降级为 `needs_codegen` / `completed_without_deliverable`）— `agent_runtime_client.go:782-808`。
|
||||
|
||||
---
|
||||
|
||||
## 4. 结论
|
||||
|
||||
- **契约 / 控制面 / API 成熟度**：高，且 unification 后在收敛，值得肯定。
|
||||
- **执行 / 交付真实度**：低。当前能力 ≈ “给一个仓库，让单个模型生成一批文件，可下载”。
|
||||
- 距项目书“多角色协作完成 需求→测试→部署→运维”的全生命周期，还差**审查、测试、部署 Worker、资源注入到执行、企业指标**这几大块——多为**缺失或占位**，属结构性缺口，非小修。
|
||||
|
||||
### 粗估实现度（相对项目书）
|
||||
| 维度 | 估计 |
|
||||
|---|---|
|
||||
| 客户端入口 / 契约 / 状态裁决 | ~70%+ |
|
||||
| 成本与用量可见 | ~45–55% |
|
||||
| 全 SDLC 执行 | ~20% |
|
||||
| 企业研发驾驶舱 | ~10–20% |
|
||||
| 真实资源注入执行 | ~20% |
|
||||
|
||||
### 优先补齐建议（执行层，最影响“产品是否成立”）
|
||||
1. **执行侧角色分化**：Reviewer 真读 diff/出结论、Test 真跑测试（需执行环境/沙箱）、按 stage 切 prompt 与工具。
|
||||
2. **资源注入打通**：Agent 运行时消费 Manager 的 grants/lease/secret_ref（Git/云/SK），结束“两张皮”。
|
||||
3. **Deploy Worker**：把 `pending_worker` 接成真实 provisioning（至少 Azure 一条路径）。
|
||||
4. **企业指标最小集**：先把项目进度/Bug/ETA 做成基于真实事件的聚合（对齐 ASCE §13、项目书 §6.3.1）。
|
||||
|
||||
---
|
||||
|
||||
*本报告为只读代码核查结论，证据可在对应仓库 `文件:行` 复核。*
|
||||
Reference in New Issue
Block a user