GEI 是一个质量工程系统,不是聊天机器人,也不是一次性代码生成器。 它读你本来就在产出的会议纪要、设计稿、聊天记录,沿四阶段流水线输出一个完整的 AI Agent—— 含多个协作 Skill、知识库、人格设定、质量报告与 14 份标准交付文档。
定位 · positioning
GEI 是一个把客户需求
自动变成可交付 AI Agent 的质量工程系统。
你可以把 GEI 想成一个"AI Agent 的代工厂"。输入是原始需求材料——会议纪要、产品文档、设计稿、 聊天记录——输出是可以直接投入使用的 AI Agent:它含多个协作 Skill、配套知识库、 人格设定(SOUL.md)、以及覆盖每个 Skill 的质量报告。你不需要写 prompt 工程模板,也不需要手工定义 skill 结构,GEI 在四阶段流水线里把这些事情做完。
三个常见误解要先澄清:
Evidence · 已交付
下表是 GEI 跑过的 6 个真实客户项目加 GEI 自身的一次 meta-run。客户名称做匿名化处理;
所有分数由 Phase C 的 gei-evaluate 自动产生,不是自评。
| 项目(匿名) | 行业 | Skill 数 | 评分 | Phase D 轮次 | 备注 |
|---|---|---|---|---|---|
| 消费电子品牌 · LINE 客服 AIconversational + webapp | 日本消费电子 | 17 | 100.00 | 60 轮 | SPEC-v13 完成, 含完整 WebApp |
| SaaS CRM · 销售辅助hybrid + agent + script | 国内 SaaS | 10 | 均值 89.0 区间 87–92 |
1 轮 | 混合 Skill 类型, Phase C 全通过 |
| 消费推荐 · 吃饭决策food-associator + restaurant-finder | 个人 consumer | 2 | 97.6% 94.4% |
2 轮 | 双 Skill 协同, 迭代一轮加一轮 |
| B2B 销售 POC · 日企desk review complete | 日企营业 | 10 | P0 avg 90.9 P1 avg 87.7 |
— | A→B→C 完成, 数据实测待 2026-09 |
| 零售连锁 AI コンシェルジュ POCbridge → normal hybrid | 日本零售 | 1 多 Phase |
信頼度 0.75 → 0.85 |
1 轮 | Bridge + Normal 混合模式, 精緻化 |
| 内部 VOC 分析工具voc-sync / by-product / by-customer / overview | 内部工具 | 4 | 全 pass | — | 4 个 Skill 按产品/客户维度拆分 |
| GEI 自身(meta-run)自我维护 · 跑自己 | 自我维护 | — | pytest 42 → 52 +10 |
4 轮 | 自审发现 15 个缺陷, 修掉 12 个 |
Get Started · 3 步
PM 视角
会议纪要、聊天记录、设计稿、既有文档——你已经在产出的东西,不需要为 GEI 专门写什么。
GEI 会在 Phase A(需求工程)里把这些原始材料归纳成一份 requirements-spec.md。
paths# 把源文档整理到项目根的这个目录 PRD/{项目名}/ ├─ meeting-notes.md ├─ product-brief.docx └─ figma-export.png
输入触发词:"生成客户 agent" 或 "客户交付"。
技术视角
gei-orchestrator 会读输入目录、通过
AskUserQuestion 问你 output_dir,然后接管整条流水线——
你不需要写代码、不需要定义 skill。
terminal生成客户 agent # orchestrator → 检查 pipeline-state.json # → 没有 = 全新项目, 从 Phase A 开始 # → 有未完成 = 询问续传 / 重开 # → 有已完成 = Phase D 进化模式
四个阶段(A 需求 · B 构建 · C 质量 · D 进化)各有一个 Reflection 检查点。 PM 视角 每个检查点都是你审核阶段性成果的机会——GEI 把事实摆出来,决策权仍在你手里。 你选一个动作,流水线按那个分支继续:
Phase C · 质量工程
Phase C 是 GEI 的核心。每个 Skill 生成后,
gei-evaluate 自动产出评估套件、跑多轮、算出评分;不达标就交给
gei-improve 用漏斗诊断定位瓶颈层、修补,然后再评估。循环直到达标或你决定
PARTIAL_DELIVERY。
pass@k 是"至少一次通过"的宽松指标——测下限; pass^k 是"每次都通过"的严格指标——测上限。两个数同时高,才算稳。
技术视角 评估代码本身也是 GEI 生成的,源码对你可见、可审计。你可以读、可以改、可以加自己的 rubric。 没有"黑盒打分"这回事。
gei-package · v4.1+
Pipeline 完成后,一句"生成交付报告"触发 gei-package,
自动读取 pipeline-state + 全部产物 + git 元数据,按模板产出 14 份标准交付文档。
Non-UI 项目 14 份全自动,有 UI 的项目附 Playwright starter 供客户补截图。
Demo 剧本不再是占位符。v4.5b 起根据项目类型自动选择最优 Demo 生成策略:
index.html,浏览器打开即看完整交付——
内嵌 CSS + 左侧目录,无需额外工具。Bridge 模式也自动产出。
Automation · 非交互
除了用户手动触发的 Normal 模式,GEI 还支持 Bridge 模式: 一个 Python daemon 订阅上游系统(如 SalesRoom)的事件流, 自动接收会议纪要,fork CLI 子进程,非交互式跑完 Phase A→B→C 并打包交付。
Memory · 跨项目经验
这是 GEI 和"一次性工具"最大的区别。
gei-memorize 这个 meta-skill 在每次 run 之后做三件事:
read(读出过往经验)、observe(被动观察当次得失)、write(经你审批后写入)。
跨客户的规律、失败模式、成功模板。团队共享的集体经验,不含任何真实客户身份。
客户档案、用户偏好、项目注册表、复盘记录。只在本机,允许写真实名称,不进仓库。
记忆不只来自 pipeline 内部。v4.5a 起 gei-memorize 从 5 个数据源采集经验: pipeline reflections、Phase C 评估结果、Phase D CEO 轮次、 用户反馈、交付打包过程中的 gap 发现。
R1反复出现的问题 → 升级为 patternR2高价值复盘 → 抽象为经验R3重复成功链路 → 固化为 playbookR4客户档案增量更新R5用户偏好采集R6大文档过载的切分策略R7Phase D 产物缺失检查R8新 UI 必须接入已有 AI Skill 的门禁R7 管"Phase D 跑了但文档没同步"的问题;R8 管"UI 做得漂亮但其实没调用真 AI"的假 Demo 问题。 所有写入都需要用户审批,GEI 不会偷偷改自己。
Stack · 边界
52 tests)+ 2 个 shell dry-run。
GEI 可以积累经验、追加记忆、新增运行模式——但不能修改自己的骨架
(skills/*/SKILL.md 主体逻辑、contracts/*.md)。
核心逻辑变更必须走人工 PR 流程。这是防 agent 失控的硬约束。
memory/ 和 local/gei-memory/ 下新增文件memory/gei-memory.mdskills/*/modes/ 下新增 mode 文件config/modes-registry.yamlscripts/builder_daemon/ 下任意代码与配置skills/*/SKILL.md 主体逻辑contracts/*.mdconfig/modes-registry.yaml 的已有条目superseded_by 代替)plugin.json 之外的 configAnti-use-cases · 说人话
GEI 不是所有场景都合适。以下几种情况,直接用别的工具更快,或者根本不该用这条技术路径:
需求只跑一次、不需要质量迭代——直接写 prompt 更快,走不到 GEI 的四阶段流水线就能交付完。
GEI 的生成阶段是"工程批处理",跑完一轮几分钟到几十分钟。生成出来的 agent 可以是低延迟的,但 GEI 自己不是实时推理系统。
如果你只是要做个"能动起来的 demo"给客户看一眼、之后扔掉——Phase C 的质量循环会成为负担。
GEI 读的是你已有的文档。如果需求还在脑子里、没有任何书面材料,先做 10 分钟需求澄清再来。