taijibaga/heicodedebug
9
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
50144d78d1a6f0e661961ef913a12f49d81f75c3
heicodedebug/chek/2026-06-02_产品维度复审-能力覆盖度.md
T
xiaohei 50144d78d1 docs: add 2026-06-02 产品维度复审（能力覆盖度 说vs做） 
按项目书产品支柱逐条对照代码实现度：全SDLC执行/AI团队/资源接入/成本用量/企业驾驶舱，
附 文件:行 证据与覆盖度粗估，并记录 unification v0.1 已修复 P1/P2。
2026-06-02 17:35:30 +08:00

9.2 KiB
Raw Blame History

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 View Git Blame Copy Permalink