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技能。该技能被设计为应用构建编排器其职责链是确定项目类型由 project-detection.md 完成即本文主题选择技术栈见 tech-stack.md规划目录结构见 scaffolding.md协调各领域智能体见 agent-coordination.md。从 app-builder/SKILL.md 的选择性阅读规则看project-detection.md在启动新项目时是必读文件其内容是关键词矩阵 项目类型检测。也就是说项目类型检测决定了后续技术栈、模板、智能体分工的走向误判会传导到整条流水线。2. 关键词矩阵16 类需求到模板的映射表project-detection.md的核心资产是一张关键词矩阵将自然语言触发词映射到项目类型与脚手架模板。仓库中 app-builder 技能实际提供了13 个模板templates 目录矩阵中的模板名与之一一对应关键词Keywords项目类型Project Type模板Templateblog, post, articleBlogastro-statice-commerce, product, cart, paymentE-commercenextjs-saasdashboard, panel, managementAdmin Dashboardnextjs-fullstackai, chat, bot, llm, rag, agent appAI / Chatbot Appnextjs-fullstackAI SDK / Streaminggame, 2d, 3d, canvas, phaser, godotGame Applicationgame-development skill经game-developer智能体api, backend, service, restAPI Serviceexpress-apipython, fastapi, djangoPython APIpython-fastapimobile, android, ios, react nativeMobile App (RN)react-native-appflutter, dartMobile App (Flutter)flutter-appportfolio, personal, cvPortfolionextjs-staticcrm, customer, salesCRMnextjs-fullstacksaas, subscription, stripeSaaSnextjs-saaslanding, promotional, marketingLanding Pagenextjs-staticdocs, documentationDocumentationastro-staticextension, plugin, chromeBrowser Extensionchrome-extensiondesktop, electronDesktop Appelectron-desktopcli, command line, terminalCLI Toolcli-toolmonorepo, workspaceMonorepomonorepo-turborepo2.1 关键解读一个模板可服务多个类型nextjs-fullstack同时承接 Admin Dashboard、AI/Chatbot App、CRMastro-static承接 Blog 与 Documentationnextjs-saas承接 E-commerce 与 SaaS。这符合 SKILL.md 中的模板定义如nextjs-fullstack Next.js Prismanextjs-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 各步骤的仓库佐证步骤 12分词与关键词提取这是纯 NLP 预处理矩阵中每行关键词即抽取的目标词典。实际使用中应与 app-builder/SKILL.md 的模板映射表13 个模板及其适用场景联合使用命中关键词后即可在模板表中找到对应技术栈。步骤 3类型判定判定结果会直接影响 project-planner.md 中组件分配表的智能体选择——例如检测为 MOBILE 时必须使用mobile-developer禁止frontend-specialist检测为 WEB 则使用frontend-specialist禁止mobile-developerAPI 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 APPnew 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给出了严格有序的三级冲突消解规则优先级规则示例1平台优先于领域Platform wins over domain具体平台mobile / desktop / cli / extension优先于 Web/业务领域e-commerce、crm、blogCLI to manage e-commerce →cli-toole-commerce 只是数据领域不是交付物2中心名词优先Head noun wins描述要构建什么的关键词语法主语优先于修饰语adashboardfor my Shopify store →nextjs-fullstackdashboard 才是产物Shopify 只是上下文3仍歧义则提问Still ambiguous → ask若以上规则仍无法消解绝不猜测通过 Socratic GatePhase 0向用户呈现选项让用户选择an app for my shop → 追问web、mobile 还是 desktop4.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 领域冲突规则 1User: a CLI to manage my e-commerce products ↓ 冲突cli-tool vs nextjs-saase-commerce ↓ Rule 1: Platform wins over domain 判定 → cli-toolNode.js Commander依据e-commerce 只是被管理的数据领域最终交付物是 CLI 工具。注意该判定也符合 project-planner.md 的组件分配逻辑——CLI 项目不涉及 UI可跳过 DESIGN.md 门禁agent-coordination.md 明确 DESIGN.md 仅对含 UI 的项目强制headless API 或 CLI 工具可跳过。5.3 中心名词 vs 修饰语规则 2User: a dashboard for my Shopify store ↓ 冲突dashboard → nextjs-fullstack vs e-commerce/shop → nextjs-saas ↓ Rule 2: Head noun wins 判定 → nextjs-fullstackdashboard 是语法主语Shopify 是修饰语境5.4 无法消解规则 3Socratic GateUser: an app for my shop ↓ 无平台关键词、无中心名词可判定 ↓ Rule 3: Still ambiguous → ask Socratic GatePhase 0追问web、mobile 还是 desktop6. 与智能体编排的衔接检测结果如何驱动后续阶段检测结果不是终点而是 agent-coordination.md 执行顺序表的输入。完整流水线为Phase环节与类型检测的关系0Socratic Gate检测信息不足时的追问环节规则 3 的落点1Project Planner依据检测出的类型做任务拆分强制生成{task-slug}.md1.5计划验证无计划文件则 STOP强制门禁1.8设计源真值含 UI 的项目强制生成DESIGN.md2Database Architect有数据需求的项目进入 schema 设计3Backend Specialist有后端需求的项目进入 API 开发4Frontend Specialist / Mobile Developer严格按检测类型二选一Web 与 Mobile 不可同时用5Security Auditor / Test Engineer并行质量门6DevOps Engineer部署与预览从源码结构看request-routing.md 还提供了配套的路由强化NEW APP请求必须经project-planner或orchestrator路由因为单独的专业智能体不具备项目检测、技术栈选择和模板知识——这些是app-builder的能力。这也解释了为何项目类型检测被放在app-builder技能内而不是某个领域智能体内部。7. 最佳实践与注意事项综合原文档与仓库配套文件使用项目类型检测时建议遵循以下实践先分类再检测仅对 NEW APP / COMPLEX / DESIGN-UI 类请求执行完整检测避免在简单修复场景中过度设计。关键词要双语 同义扫描矩阵中的英文关键词在实际中文/混合输入场景下应同时覆盖对应中文术语如 chat/AI 应用、管理后台、电商购物车等再对照矩阵判定。平台 中心名词 提问遇到多关键词命中时严格按三条优先级规则顺序消解最后一道防线是显式提问绝不静默猜测。检测与模板表联动判定出类型后回到 SKILL.md 的 13 模板表确认技术栈与适用场景再进入 scaffolding.md 的目录结构落地。特殊类型走特殊通道Game 类需求委派game-development技能与game-developer智能体MOBILE 类型必须锁定mobile-developer全栈负责防止领域智能体误用。8. 延伸阅读检测规则的原始定义.agents/skills/app-builder/project-detection.mdapp-builder 技能总览与 13 个模板表.agents/skills/app-builder/SKILL.md2026 默认技术栈与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考