feature-emerge

name	feature-emerge
description	通用涌现式功能设计技能。面向任意模块（文档空间、CDS 面板、PR 审查、工作流、视觉创作等）—— 扫描目标模块的现有能力、与全局基础设施（LLM Gateway / Bridge / Attachment / Run-Worker）交叉相乘， 浮现出"独有且可落地"的新功能。反对抄袭竞品，强调组合本系统已有砖块。每次调用产出一个可执行方案。 触发词："涌现"、"emerge"、"发散想一下"、"下一个功能"、"/emerge"、"feature emerge"。

通用涌现式功能设计

版本：v1.0.0 | 状态：已落地 | 触发：/emerge、"涌现"、"emerge"、"发散想一下"、"下一个功能"、"feature emerge"

通过扫描本系统已有能力 → 交叉相乘 → 浮现涌现点，为任意模块设计下一个最有价值的功能。

目录

• 核心哲学
• 适用场景
• 涌现工作流
• 能力扫描方法
• 交叉相乘与发散
• 过滤与排序
• 输出模板
• 示例

核心哲学

涌现 ≠ 抄袭竞品功能清单。 涌现的核心是：

1. 扫描 — 先看清目标模块已经有什么砖块，再看全局有什么横向能力（LLM Gateway / Bridge / Attachment / Run-Worker / SSE / 权限系统……）
2. 相乘 — 把"模块自己的砖块"和"全局横向能力"两两相乘，不是抄清单
3. 发散 — 基线层 → 差异化层 → 智力层 → 疯狂层，每层都要有想法，禁止只给安全牌
4. 收敛 — 每个想法必须回答："没这个功能之前用户怎么做？这个功能比原路径省多少步？"
5. 验证 — 每个方案必须回答："我系统里已经有的哪几块砖能拼出它？"

反模式：

• 打开 Notion / Railway / Linear 抄一条"它有我也要有" → 功能孤岛
• 只想"必做项"不想"亮眼项" → 产出平庸
• 抽象地谈价值不说具体复用了哪些代码 → 无法落地

正模式：

• 先看目标模块已有的 Model/Service/Controller，和全局的 ILlmGateway / Bridge / Run-Worker 等横向能力
• 两两相乘写 10-20 个想法，不自我审查
• 最后按"独特性 × 可落地性"筛出 3-5 个推荐

适用场景

场景	触发
规划某模块下一阶段功能	"CDS 面板下一步做什么"、"PR 审查怎么演进"
对一组痛点做方案爆破	"用户抱怨看不清容器关系，想想"
从一个灵感反推组合	"我们有 Bridge 能做什么新功能"
跨模块能力重组	"文档空间的解析能力能不能给缺陷管理用"
整条路线图铺开	"给 VisualAgent 做个 6 个月路线图"

涌现工作流

涌现进度：
- [ ] Step 1: 明确目标模块（用户说 / 从语境推断）
- [ ] Step 2: 扫描目标模块的本地能力
- [ ] Step 3: 扫描全局横向能力（Gateway / Bridge / Run-Worker / Attachment / 权限）
- [ ] Step 4: 发散 — 两两相乘，分 4 层写 10+ 个想法
- [ ] Step 5: 收敛 — 按"独特性 × 可落地性"筛 3-5 个
- [ ] Step 6: 输出方案模板，用户确认
- [ ] Step 7: 落地执行（可选）

Step 1：明确目标模块

如果用户没说，主动问：

"你想给哪个模块涌现新功能？

• 已建成模块：prd-api 的 Controller 列表任选一个
• 自定义：告诉我你关心的痛点，我帮你定位模块"

Step 2：扫描目标模块的本地能力

禁止凭记忆写能力清单，必须实际扫描代码：

# 模型层（决定数据天花板）
Glob: prd-api/src/PrdAgent.Core/Models/<Module>*.cs
Read: 每个 Model 看字段

# 接口层（决定当前用户能做什么）
Glob: prd-api/src/PrdAgent.Api/Controllers/**/<Module>Controller.cs
Grep: "HttpGet|HttpPost|HttpPut|HttpDelete"

# 服务层（决定已封装的业务能力）
Glob: prd-api/src/PrdAgent.Infrastructure/Services/<Module>*.cs

# 前端入口（决定已有的 UI 形态）
Glob: prd-admin/src/pages/**/<Module>*.tsx

CDS / 视频 / 桌面模块类似，换对应目录。扫描结果写成一张表放到输出里。

Step 3：扫描全局横向能力

全局能力是涌现的"乘数"。读取 .claude/rules/codebase-snapshot.md 或直接扫：

横向能力	位置	能用来做什么
ILlmGateway	prd-api/...Core/Interfaces/ILlmGateway.cs	给任何功能加 AI 问答、摘要、建议、诊断
Run / Worker	RunController + Worker 基类	长任务异步化 + SSE 断线续传
Attachment + ExtractedText	attachments 集合	文件上传 + 文本提取 + 全文搜索
Bridge 浏览器操作	cds/src/services/bridge.ts	自动化 + 嵌入预览 + 脚本录制
ShareLink 模式	share_links 集合	任何实体一键公开分享
ParsedPrd / Sections	documents 集合	结构化文本能力
Run-Worker + SSE	Worker 基类	任何长任务可异步 + 流式推送
IForkable / Marketplace	IMarketplaceItem.cs	任何配置一键"叉"出副本
Webhook 投递	webhook_delivery_logs	任何事件可外推
权限系统	AdminPermissionCatalog	任何功能可按角色隔离
Watermark	watermark_configs	任何输出可盖水印

Step 4：发散（两两相乘）

核心方法论：左列是目标模块的砖块，右列是全局能力，交叉点就是涌现。

模块砖块 A	× 全局能力 B	= 涌现功能 C
列表数据	× ILlmGateway	AI 问答框 / 智能排序 / 自动摘要
任意详情	× Bridge	嵌入式实时预览
长操作	× Run-Worker	异步化 + 断线续传
任意实体	× ShareLink	公开分享 + 外部验收
任意事件	× Webhook	外推到飞书 / 钉钉
任意配置	× IForkable	模板化 + 市场化
任意上传	× Attachment.ExtractedText	文件秒变全文检索源

硬要求：必须分 4 层发散，每层至少 3 个想法：

基线层 — 没有会被投诉的基础能力
差异化层 — 竞品做过但我们做得更好的
智力层 — 借 LLM Gateway 做的、竞品没法做的
疯狂层 — 值得记录但可能暂时不做的激进想法

禁止只写基线层就收手。疯狂层即使最后不做，也要写出来让用户看到可能性。

Step 5：收敛

按 独特性 × 可落地性 两维评分，挑 3-5 个推荐落地：

• 独特性：别人抄不走的程度（复用我们 Bridge / LLM Gateway / Run-Worker 越多，独特性越高）
• 可落地性：用现有砖块能否 1-2 周做完（新数据模型越少越高）

过滤与排序

可用表格呈现：

| 想法 ID | 名称 | 层级 | 独特性 | 可落地性 | 推荐波次 |
|--------|------|------|--------|--------|---------|
| E1 | 基础画板 | 基线 | 低 | 高 | 第一波 |
| E4 | 连线即契约 | 差异化 | 高 | 中 | 第二波 |
| E8 | AI 拓扑问答 | 智力 | 高 | 中 | 第三波 |

输出模板

## 涌现分析：[模块名]

### 目标模块能力基线
| 类型 | 名称 | 状态 |
|------|------|------|
| Model | ... | 已有 |
| API | ... | 已有 |
| UI | ... | 缺失 |

### 可用的全局横向能力
- ILlmGateway / Bridge / Run-Worker / ShareLink / ...（列出实际要用到的）

### 发散池（分层脑暴）

#### 基线层
- **E1. 名称** — 一句话描述 + 复用了哪几块砖
- **E2. ...**
- **E3. ...**

#### 差异化层
- **E4. ...**
- **E5. ...**
- **E6. ...**

#### 智力层（借 LLM）
- **E7. ...**
- **E8. ...**

#### 疯狂层
- **E9. ...**
- **E10. ...**

### 收敛评分

| ID | 独特性 | 可落地性 | 推荐波次 |
|----|--------|---------|---------|
| E1 | 低 | 高 | 第一波 |
| ... |

### 推荐落地顺序

**第一波（立即做）**：E1 + E2 + E3
**第二波（下一迭代）**：...
**第三波（差异化加分项）**：...

### 每个推荐项的技术方案

#### [ID. 名称]
- **涌现路径**：A（xxx）× B（xxx） = C
- **复用的砖块**：文件路径列表
- **新增代码量估计**：前端 X 个组件 / 后端 Y 个端点
- **用户感知变化**：之前 → 之后

确认后执行。

示例

示例 1：文档空间 — "文档要能下载"

跳过全部发散，直接给单一 Quick Win：

涌现路径：ParsedPrd.RawContent（已有 MD 原文）× Attachment.Url（已有文件 URL）= 多格式下载 复用的砖块：DocumentStoreController.cs 新增：1 个端点 GET /api/document-store/entries/{id}/download?format=... 象限：Quick Win

文档领域的完整竞品对比参见 reference/feature-matrix.md

示例 2：CDS 面板 — "看不清容器和数据库关系"

需要完整发散（篇幅所限只列摘要）：

能力基线：compose-parser.depends_on + topo-sort.layers + RoutingRule + Bridge + ILlmGateway

发散池（15 个想法，略）：

• 基线层 E1 基础画板、E2 容器抽屉、E3 子域名独立管理
• 差异化层 E4 连线即契约、E5 Live vs Desired diff、E6 反向拓扑、E7 容器嵌入式预览
• 智力层 E8 AI 拓扑问答、E9 AI 拓扑建议、E10 故障传播模拟
• 疯狂层 E11 时间轴回放、E12 跨分支 diff、E13 双层画板、E14 拓扑模板市场、E15 拓扑即 PR

第一波推荐：E1 + E2 + E3（纯前端，零数据模型改动） 第二波：E5 + E6（差异化，Railway 都没做） 第三波：E8 + E9（借 Gateway，独有优势）

示例 3：PR 审查 — "审查历史只有列表"

能力基线：pr_review_items + github_user_connections + ILlmGateway + ShareLink

发散池（示意）：

• 基线层 时间轴视图 / 审查卡片
• 差异化层 PR 健康度热力图 / 审查人工作量看板
• 智力层 AI 审查差异解释 / AI 代你回复 reviewer
• 疯狂层 审查决策树回放 / 跨团队审查市场

---

使用指南

1. 用户说"涌现一下 XX 模块" → 进入 Step 1
2. 用户说"我有个痛点" → 从痛点反推目标模块
3. 用户说"发散想一下" → 强制走完 4 层发散，不能只给基线
4. 用户说"给我路线图" → 把发散结果按波次铺开
5. 用户确认某个推荐项 → 走标准开发流程（model / service / controller / changelog / commit）

什么时候不用这个技能

• 明确的 bug 修复任务
• 已经知道要做什么，只差实现细节 → 直接做
• 无目标模块、无痛点的纯聊天