GaleHarnessCLI
巨风科技研发团队提效工具 —— 基于 Compound Engineering 工作流与 HKTMemory 向量知识库的 AI 驱动开发套件。
目录
核心理念
每一次工程实践都应该让后续工作变得更简单，而不是更复杂。
传统开发累积技术债务，每个功能增加复杂度。HarnessCLI 反转这一模式：
- 80% 精力投入规划与审查
- 20% 精力投入执行
- 通过知识沉淀实现复利效应
工作流
Brainstorm -> Plan -> Work -> Review -> Compound -> Repeat
^
Ideate (可选 -- 用于发现改进点)
每个阶段都与 HKTMemory 向量知识库双向交互：阶段开始前检索相关记忆，阶段完成后存储新产生的知识。
命令一览表
| 命令 | 用途 | HKTMemory 交互 |
|---|
/gh:ideate | 通过发散思维和对抗性过滤发现高影响力改进点 | 检索历史建议，存储新发现 |
/gh:brainstorm | 在规划前探索需求和方案，通过交互式问答细化想法 | 检索相关需求，存储需求文档 |
/gh:plan | 将功能想法转化为详细实施计划，带自动置信度检查 | 检索相似方案，存储技术规划 |
/gh:work | 系统化执行工作项，使用 worktree 和任务追踪 | 检索实现模式，存储实现总结 |
/gh:work-x | iOS Morph-X 实施模式：在保留工作流能力的同时降低模板化代码重复风险 | 检索历史模式标签，存储蓝图/策略指纹 |
/gh:review | 多代理代码审查，分层角色和置信度门控 | 检索审查模式，存储审查发现 |
/gh:compound | 记录已解决问题，沉淀团队知识 | 检索相关解决方案，存储完整知识 |
/gh:debug | 系统性查找根本原因并修复缺陷 | 检索类似问题，存储调试经验 |
/gh:debug-x | iOS Morph-X 调试模式：保持根因定位纪律，并在修复产出后执行变换和相似度审计 | 检索历史模式标签，存储蓝图/策略指纹 |
/gh:optimize | 迭代优化循环，并行实验和 LLM 评分 | 检索优化策略，存储优化结果 |
/document-review | 多角色并行评审需求/方案文档 | 无 |
/gh:sessions | 搜索历史 Claude Code/Codex/Cursor 会话 | 无 |
/gh:slack-research | 搜索 Slack 获取组织上下文 | 无 |
入口说明：/gh:brainstorm 是主要入口 —— 它通过交互式问答将想法细化为需求文档，在不需要时自动跳过。/gh:ideate 效果显著但使用较少 —— 基于代码库主动发现改进建议。
iOS Morph-X 降低代码重复风险
/gh:work-x 和 /gh:debug-x 是面向 iOS Swift/ObjC 代码产出的特殊工作流。它们先根据项目 seed、历史模式标签和 .morph-config.yaml 选择实现蓝图，再在代码产出后运行 gale-harness morph --apply 与 gale-harness audit --similarity，输出相似度风险报告。
Morph-X 的定位是降低模板化代码重复风险并提供自检证据，不保证 Apple App Review 通过，也不能替代真实的产品、UI、内容和功能差异。
工程师实战指南
以研发导师的视角，指导工程师在不同开发场景下如何高效使用。
场景一：新需求开发
需求理解 -> 技术规划 -> 编码实现 -> 代码审查 -> 知识沉淀
| 步骤 | 命令 | 产出 |
|---|
| 需求探索 | /gh:brainstorm "实现用户登录功能" | 检索历史案例，输出结构化需求文档到 docs/brainstorms/ |
| 技术规划 | /gh:plan docs/brainstorms/user-login-requirements.md | 检索相似方案，输出任务分解和置信度评估到 docs/plans/ |
| 编码实现 | /gh:work docs/plans/user-login-plan.md | 创建 git worktree，检索实现模式，存储实现总结 |
| 代码审查 | /gh:review | 多代理并行审查（安全/性能/正确性/可维护性） |
| 知识沉淀 | /gh:compound "用户登录功能的实现经验" | 记录解决方案供未来参考 |
场景二：Bug 修复
# 推荐：使用完整工作流
/gh:debug
# 支持多种输入方式
/gh:debug "用户登录时偶尔出现 500 错误"
/gh:debug
> Error: Connection timeout at UserService.authenticate()
> Stack trace: ...
/gh:debug https://github.com/org/repo/issues/123
/gh:debug 会自动检索 HKTMemory 中类似历史问题，系统性定位根因，修复后自动存储调试经验。
场景三：需求讨论与评审
# 需求文档评审
/document-review docs/brainstorms/new-feature.md
# 技术方案评审
/document-review docs/plans/implementation-plan.md
多角色代理并行评审：产品视角（挑战假设/战略影响）、安全视角（数据暴露/认证漏洞）、可行性视角（技术可行性/架构冲突）、范围视角（复杂度/过度设计）。
场景四：知识归档与复用
# 归档已解决的问题
/gh:compound "解决大文件上传超时问题"
# 以上命令都会自动检索 HKTMemory
/gh:brainstorm "..."
/gh:plan "..."
/gh:debug "..."
场景五：代码优化
/gh:optimize "优化首页加载速度"
定义可测量目标，构建测量脚手架，并行运行多个实验方案，用 LLM 评分评估效果，自动保留改进方案。
场景六：研究现有代码
# 查询历史会话
/gh:sessions "上次我们是怎么处理认证问题的？"
/# 搜索 Slack 讨论
/gh:slack-research "团队对微服务拆分的讨论"
场景七：一人十线 —— 并行开发（Worktree 隔离）
一个工程师同时驱动 10+ 条需求流水线。每条流水线在独立 worktree 中运行，共享代码库和知识库，互不阻塞、互不干扰。
flowchart TB
Lead["🎯 技术负责人\n1 人"]
Lead --> W1["Worktree 1\nbrainstorm/user-auth\n需求探索中"]
Lead --> W2["Worktree 2\nfeat/payment\n编码实现中"]
Lead --> W3["Worktree 3\nfix/email-bug\n审查中"]
Lead --> W4["Worktree 4\nfeat/search\n规划中"]
Lead --> W5["Worktree 5\nbrainstorm/analytics\n需求探索中"]
Lead --> Wn["Worktree N\n...\n并行推进"]
W1 --> HKT["🧠 HKTMemory\n共享知识库"]
W2 --> HKT
W3 --> HKT
W4 --> HKT
W5 --> HKT
Wn --> HKT
W1 --> R1["PR #37"]
W2 --> R2["PR #38"]
W3 --> R3["PR #39"]
W4 --> R4["PR #40"]
W5 --> R5["PR #41"]
Wn --> Rn["PR #N"]
为什么能做到？
| 传统模式 | GaleHarness 并行模式 |
|---|
| 1 人 = 1 个分支 = 串行切换 | 1 人 = N 个 worktree = 并行推进 |
| 切换分支需要 stash / commit | 每条线独立目录，直接 cd 切换 |
| 知识靠记忆和文档搜索 | HKTMemory 向量检索，跨流水线复用经验 |
| 代码审查排队等待 | AI 代理即时审查，置信度门控 |
| 每次从零开始 | 每条流水线自动检索历史方案 |
跨阶段无缝衔接：gh:brainstorm → gh:work 时自动检测已在 feature 分支，直接沿用 worktree，不重复创建。分支名风格不匹配时提示 rename（如 brainstorm/xxx → feat/xxx）。
# 第 1 条线：启动需求探索
/gh:brainstorm "实现用户登录"
# → 选择 worktree → brainstorm/user-auth 分支 + 隔离工作目录
# 第 2 条线：同步启动另一个需求（互不干扰）
/gh:brainstorm "接入支付系统"
# → 选择 worktree → brainstorm/payment 分支 + 隔离工作目录
# ... 第 N 条线