企业官网建设流程全解析

ag-kit 项目类型检测：app-builder 技能的关键词矩阵、检测流程与冲突消解实战

【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit

项目类型检测（Project Type Detection）是 ag-kit 中 app-builder 技能的"第一道工序"：它把用户的自然语言请求映射为具体的项目类型（Blog、E-commerce、AI App……）与脚手架模板（astro-static、nextjs-saas……），是整个从"一句话需求"到"可运行应用"流水线的入口。读完本文，你将掌握 ag-kit 的关键词矩阵、五步检测流程、三优先级冲突消解规则，以及检测结果如何与智能体编排、技术栈选择联动，从而能准确判断任意需求的落地类型。

1. 检测的定位：为什么需要项目类型检测

在 ag-kit 的智能体体系中，NEW APP类请求（"build me a/an"、"from scratch"、"new app"）会按照 request-routing.md 的路由规则进入project-planner或orchestrator，二者都会加载app-builder技能。该技能被设计为"应用构建编排器"，其职责链是：

1. 确定项目类型（由 project-detection.md 完成，即本文主题）；
2. 选择技术栈（见 tech-stack.md）；
3. 规划目录结构（见 scaffolding.md）；
4. 协调各领域智能体（见 agent-coordination.md）。

从 app-builder/SKILL.md 的"选择性阅读规则"看，project-detection.md在启动新项目时是必读文件，其内容是"关键词矩阵 + 项目类型检测"。也就是说，项目类型检测决定了后续技术栈、模板、智能体分工的走向，误判会传导到整条流水线。

2. 关键词矩阵：16 类需求到模板的映射表

project-detection.md的核心资产是一张关键词矩阵，将自然语言触发词映射到项目类型与脚手架模板。仓库中 app-builder 技能实际提供了13 个模板（templates 目录），矩阵中的模板名与之一一对应：

2.1 关键解读

• 一个模板可服务多个类型：nextjs-fullstack同时承接 Admin Dashboard、AI/Chatbot App、CRM；astro-static承接 Blog 与 Documentation；nextjs-saas承接 E-commerce 与 SaaS。这符合 SKILL.md 中的模板定义（如nextjs-fullstack= Next.js + Prisma，nextjs-saas= Next.js + Stripe），说明检测到的是"类型"，模板负责给出"骨架"。
• 跨技能委派：Game 类需求不直接落到某个模板，而是委派给game-development技能及game-developer智能体，表明检测结果可能跳出一对一的模板映射，进入另一条技能流水线。
• 同义词覆盖：同一列关键词覆盖了高频口语表达，如service/rest之于 API、promotional/marketing之于 Landing、workspace之于 Monorepo，降低了自然语言输入的解析门槛。

3. 检测流程：从 Token 到技术栈建议的五步管道

原文档给出了标准的五步检测流程，是整篇方法论的主干：

1. Tokenize user request → 对用户请求做分词 2. Extract keywords → 提取关键词 3. Determine project type → 判定项目类型 4. Detect missing information → 检测缺失信息，转交 project-planner / orchestrator 5. Suggest tech stack → 建议技术栈

3.1 各步骤的仓库佐证

• 步骤 1～2（分词与关键词提取）：这是纯 NLP 预处理，矩阵中每行关键词即抽取的目标词典。实际使用中应与 app-builder/SKILL.md 的模板映射表（13 个模板及其适用场景）联合使用，命中关键词后即可在模板表中找到对应技术栈。
• 步骤 3（类型判定）：判定结果会直接影响 project-planner.md 中"组件分配"表的智能体选择——例如检测为 MOBILE 时必须使用mobile-developer（禁止frontend-specialist），检测为 WEB 则使用frontend-specialist（禁止mobile-developer），API only 则只用backend-specialist。项目类型检测因此是智能体分工的前置条件。
• 步骤 4（缺失信息检测）：检测到信息不足时不猜测，而是转交project-planner或orchestrator。这与 agent-coordination.md 中的Phase 0: Socratic Gate直接衔接——该门要求"Ask 3 questions"，通过追问澄清需求后再进入 Phase 1 计划阶段。
• 步骤 5（技术栈建议）：tech-stack.md 提供了 2026 默认栈（Next.js 16 + TypeScript 5.7+ + Tailwind CSS v4、Node.js 24、PostgreSQL + Prisma/Drizzle、Auth.js v5/Clerk、Turborepo 2.0），并对 AI 应用给出streamText/useChat/pgvector 等标准模式。检测出的类型将决定套用哪套默认栈。

3.2 请求分类上下文

检测并非对所有请求生效。从 request-routing.md 的请求分类器看，只有NEW APP（"new app"、"from scratch"、多页面）和部分COMPLEX CODE / DESIGN/UI请求才要求走project-planner→orchestrator（加载app-builder）并强制生成{task-slug}.md计划文件；简单的单文件修复（SIMPLE CODE）则直接内联编辑，不经过类型检测。理解这一边界，才能避免在错误场景套用检测流程。

4. 冲突消解：当请求同时命中多个关键词

现实中的自然语言请求常常同时命中多类关键词（如 "a CLI to manage my e-commerce products" 同时包含cli与e-commerce）。project-detection.md给出了严格有序的三级冲突消解规则：

4.1 三条规则的内在逻辑

• 规则 1 与规则 2 都指向同一个原则：以"交付物形态"为判据，而非"业务背景"。e-commerce、crm、shop 描述的是数据域/业务域，而 cli、dashboard、mobile app 描述的是产物形态——前者决定功能，后者决定工程骨架，所以后者优先。
• 规则 3 是兜底防线，体现"宁问勿猜"的工程原则。这与 project-planner.md 中"对话历史 > 计划文件 > 任何文件 > 文件夹名"的上下文优先级一脉相承：绝不从文件夹名推断项目类型，只用提供的上下文。一旦缺失关键信息（如平台形态），检测流程应显式停止并提问。

5. 实战推演：从请求到模板的完整链路

结合以上机制，给出三类典型请求的完整推演：

5.1 单关键词命中（最简路径）

User: "I want a landing page for my product launch" ↓ Tokenize & Extract keywords: [landing, promotional, marketing]（也含 page） ↓ Determine Project Type: Landing Page → Template: nextjs-static ↓ Tech Stack Next.js + Framer（见 SKILL.md 模板表） ↓ 流水线 project-planner 制定计划 → DESIGN.md 源真值 → frontend-specialist 实现

5.2 平台 vs 领域冲突（规则 1）

User: "a CLI to manage my e-commerce products" ↓ 冲突：cli-tool vs nextjs-saas（e-commerce） ↓ Rule 1: Platform wins over domain 判定 → cli-tool（Node.js + Commander）

依据：e-commerce 只是被管理的数据领域，最终交付物是 CLI 工具。注意该判定也符合 project-planner.md 的组件分配逻辑——CLI 项目不涉及 UI，可跳过 DESIGN.md 门禁（agent-coordination.md 明确 DESIGN.md 仅对含 UI 的项目强制，headless API 或 CLI 工具可跳过）。

5.3 中心名词 vs 修饰语（规则 2）

User: "a dashboard for my Shopify store" ↓ 冲突：dashboard → nextjs-fullstack vs e-commerce/shop → nextjs-saas ↓ Rule 2: Head noun wins 判定 → nextjs-fullstack（dashboard 是语法主语，Shopify 是修饰语境）

5.4 无法消解（规则 3，Socratic Gate）

User: "an app for my shop" ↓ 无平台关键词、无中心名词可判定 ↓ Rule 3: Still ambiguous → ask Socratic Gate（Phase 0）追问：web、mobile 还是 desktop？

6. 与智能体编排的衔接：检测结果如何驱动后续阶段

检测结果不是终点，而是 agent-coordination.md 执行顺序表的输入。完整流水线为：

从源码结构看，request-routing.md 还提供了配套的路由强化：NEW APP请求必须经project-planner或orchestrator路由，因为"单独的专业智能体不具备项目检测、技术栈选择和模板知识——这些是app-builder的能力"。这也解释了为何项目类型检测被放在app-builder技能内而不是某个领域智能体内部。

7. 最佳实践与注意事项

综合原文档与仓库配套文件，使用项目类型检测时建议遵循以下实践：

1. 先分类，再检测：仅对 NEW APP / COMPLEX / DESIGN-UI 类请求执行完整检测，避免在简单修复场景中过度设计。
2. 关键词要"双语 + 同义"扫描：矩阵中的英文关键词在实际中文/混合输入场景下，应同时覆盖对应中文术语（如 chat/AI 应用、管理后台、电商购物车等），再对照矩阵判定。
3. 平台 > 中心名词 > 提问：遇到多关键词命中时，严格按三条优先级规则顺序消解，最后一道防线是显式提问，绝不静默猜测。
4. 检测与模板表联动：判定出类型后，回到 SKILL.md 的 13 模板表确认技术栈与适用场景，再进入 scaffolding.md 的目录结构落地。
5. 特殊类型走特殊通道：Game 类需求委派game-development技能与game-developer智能体；MOBILE 类型必须锁定mobile-developer全栈负责，防止领域智能体误用。

8. 延伸阅读

• 检测规则的原始定义：.agents/skills/app-builder/project-detection.md
• app-builder 技能总览与 13 个模板表：.agents/skills/app-builder/SKILL.md
• 2026 默认技术栈与 AI 应用模式：.agents/skills/app-builder/tech-stack.md
• 智能体流水线与强制门禁（Phase 0 Socratic Gate / 1.5 / 1.8）：.agents/skills/app-builder/agent-coordination.md
• 新项目目录结构与路径别名规范：.agents/skills/app-builder/scaffolding.md
• 请求分类与路由规则（NEW APP 如何进入 app-builder）：.agents/rules/request-routing.md
• 计划智能体的组件分配与"不猜文件夹名"原则：.agents/agent/project-planner.md

【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit