一句话理解AI 不是不聪明是它对你的项目一无所知。每次开工它都在用统计直觉猜你用的是什么——猜错的代价要你来承担。一、根因AI 为什么必然会猜理解 P0 技术栈检测的必要性要从语言模型的工作方式说起。大语言模型本质上是一个概率引擎。当你让它运行测试它不会去读你的文件系统——它在训练数据中寻找统计上最常出现的答案。如果训练数据里 Maven 项目占比更高它就更倾向于输出mvn test。这不是 bug是 LLM 的基本工作原理。问题在于你的项目不是统计数据它是一个具体的、唯一的存在。你用的是 Gradle 还是 MavenJava 17 还是 21javax还是jakarta命名空间——这些信息在模型的权重里只是概率不是事实。这个认知很重要技术栈误判不是 AI 变蠢了是我们在用一个概率工具做精确性工作而没有给它提供让它精确的信息。P0 检测就是把概率变成事实的那一步。在 AI 写第一行代码之前先把你的项目用什么语言、什么框架、什么构建工具这些精确信息注入给它。二、一次没有 P0 检测的 AI 协作会发生什么 模拟推演基于作者在多个项目中观察到的常见场景的典型化汇总非单一事故记录下面是一个复合场景它不是某次具体的事故但你在任何存量项目上工作超过一小时就可能遇到其中的一个或几个。项目背景Spring Boot 3.2 Gradle JUnit 5 PostgreSQL运行在 Java 21 上。场景一构建命令错误。你让 AI “帮我运行测试”。AI 输出mvntest执行失败。AI 认为是 Maven 配置问题开始尝试修 pom.xml。问题是项目根本没有 pom.xml它是 Gradle 项目。AI 花了七分钟在一个不存在的文件上调试。场景二框架 API 版本幻觉。AI 帮你写 JPA Entity生成了importjavax.persistence.Entity;importjavax.persistence.Id;Spring Boot 3.x 把所有javax命名空间迁移到了jakarta。编译报错。AI 看到报错以为是依赖版本冲突开始调整 build.gradle 里的版本号——方向完全错了。场景三测试框架误判。AI 生成了Before注解JUnit 4 风格你的项目是 JUnit 5应该用BeforeEach。测试无法运行。这三个场景的共同特点每一次 AI 都在错误的方向上寻找解法消耗的调试时间超过了它生成代码节省的时间。现在同样的项目P0 检测先运行一次LANGjava FRAMEWORKspring-boot FRAMEWORK_VERSION3.2 BUILD_TOOLgradle TEST_TOOLjunit5 JAVA_VERSION21 DBpostgresqlAI 收到这个上下文后构建命令直接给出./gradlew testEntity 注解直接用jakarta.persistence测试注解直接用BeforeEach一次通过。差距不在于 AI 的能力在于它是否被告知了正确的事实。三、P0 检测30 秒给 AI 建立项目地图P0Prime 0检测是 AI 开工前运行的一次性探测目标是生成 9 个核心变量供后续所有 AI 交互使用。项目文件系统P0 检测脚本30 秒9 个核心变量.ai/tech-stack.yamlAI 上下文注入CLAUDE.mdAI 开工命令/代码全部正确9 个核心变量三层重要性第一层决定方向LANG、FRAMEWORK、BUILD_TOOL。这三个变量决定了 AI 绝大部分行为——用什么语言语法调哪些框架 API执行什么构建命令。这三个错了后续所有生成都会有方向性偏差。第二层精确对齐TEST_TOOL、DB、JAVA_VERSION / NODE_VERSION。决定测试注解、数据库驱动、语言特性的可用范围。Java 17 和 Java 21 在record、switch表达式、SequencedCollection等特性上有实质差异。第三层工具链校准MODULE_TYPE、PACKAGE_MANAGER。决定是否是 monorepo、用什么包管理器命令。对 monorepo 项目来说这一层尤其重要。检测逻辑的四个阶段检测不是简单的 if-else而是一个带置信度的四阶段推理管道Phase 1文件系统扫描特征文件识别Phase 2文件内容解析版本号·依赖·插件Phase 3技术栈归约9 变量赋值 置信度Phase 4命令生成构建·测试·运行·部署人工确认30 秒校验写入配置.ai/tech-stack.yamlPhase 1扫描根目录的特征文件pom.xml、build.gradle、package.json、go.mod、Cargo.toml、pyproject.toml。广度优先深度限制 3 层自动跳过 node_modules 和 .git。Phase 2解析文件内容从 pom.xml 提取groupId、spring-boot-starter-parent版本从 package.json 提取dependencies和devDependencies从 pyproject.toml 提取tool.poetry.dependencies。版本号在这一步确定。Phase 3是关键的归约步骤。不是简单映射而是带权重的推理检测到的特征推断结论置信度pom.xml spring-boot-starter-parentJava Maven Spring Boot0.95build.gradle.kts spring-bootKotlin Gradle DSL Spring Boot0.90package.json vite.config.tsTypeScript ViteVue/React 待进一步确认0.85pyproject.toml fastapiPython Poetry FastAPI0.85Dockerfile FROM maven:3.9-eclipse-temurin-21Java 21 Maven 3.90.95置信度低于 0.7 的变量脚本会标注为需要人工确认而不是默默给出一个可能错误的答案。Phase 4根据 9 个变量的组合动态生成命令技术栈组合构建测试运行Java Maven Spring Bootmvn clean compilemvn testmvn spring-boot:runJava Gradle Spring Boot./gradlew build./gradlew test./gradlew bootRunNode pnpm Vue 3pnpm buildpnpm testpnpm devNode yarn Next.jsyarn buildyarn testyarn devPython Poetry FastAPIpoetry buildpoetry run pytestpoetry run uvicorn main:appGo Gingo build ./...go test ./...go run main.go这些命令不是硬编码的映射表。如果 package.json 的 scripts 字段里有自定义的dev: vite --port 3001脚本会直接提取npm run dev而不是猜测一个通用命令。四、Monorepo最容易误判的项目结构Monorepo 是技术栈检测中最容易误判的场景因为多个 package.json既可能意味着 monorepo也可能只是 node_modules 里的依赖。判断 monorepo 的真正标准不是文件数量而是层级继承关系根目录和子目录都有构建配置并且子目录的配置继承了根目录的公共部分统一的 TypeScript 配置、统一的 ESLint 规则、统一的构建工具版本。一旦确认是 monorepoAI 的行为模式需要切换识别根级别的公共配置避免每个子模块重复安装公共依赖为每个子模块独立生成命令pnpm --filter app/web build而不是根目录的pnpm build理解模块间的依赖顺序app/shared必须先构建app/web才能正常运行处理 workspace 协议app/shared: workspace:*不是一个普通的版本号五、边界场景P0 检测的压力测试大多数项目的检测是直接的但有几类边界场景需要特殊策略。多语言混合项目是最常见的压力场景。一个典型全栈项目可能同时包含 Java 后端Maven、Vue 3 前端pnpm、Python 数据处理脚本Poetry。P0 脚本必须为三个部分分别生成独立的检测结果不能互相覆盖。AI 也需要明确知道切换到frontend/目录时用 pnpm切换到backend/目录时用 maven。无构建文件的降级策略当项目缺少标准的构建配置时通过源码特征推断。扫描到SpringBootApplication→ Spring Boot Java扫描到from fastapi import FastAPI→ Python FastAPI。置信度降为 0.7但在大多数情况下足以给出正确的基础命令。容器化项目的额外信息Dockerfile 的 FROM 指令是比 pom.xml 更快、更直接的技术栈来源。FROM maven:3.9-eclipse-temurin-21一行就确定了 Java 版本 21 和 Maven 3.9不需要任何进一步解析。私有依赖源企业内网项目通常有私有 Maven 仓库或 npm registry。P0 脚本需要读取settings.xml或.npmrc把私有源地址同样写入 AI 上下文否则 AI 生成的依赖安装命令在内网环境里会失败。六、反直觉结论帮助 AI 的工具不能用 AI 来写你可能会想这个帮助 AI 的辅助脚本为什么不让 AI 自己来写和维护原因在于一个根本性的限制AI 无法检测它自己所处的环境。如果项目的构建系统坏了——pom.xml 格式损坏、package.json 丢失关键字段、Gradle wrapper 脚本缺失——AI 依赖这些文件来理解项目但它不能在这些文件失效时向你报告我发现文件有问题。它只会尝试构建、失败、再尝试、再失败然后给出一个可能完全错误的诊断。一个独立的 Shell 脚本在 AI 介入之前就完成检测。如果 pom.xml 解析失败脚本会在第一步报告无法解析 pom.xml请手动确认技术栈——而不是让 AI 花 20 分钟在一个损坏的文件上调试。这是 P0 脚本的定位它不聪明但它可靠。它不负责理解代码逻辑只负责读懂文件名和配置格式。正因为不聪明它的失败模式是简单的、可预期的、可调试的。AI 失败时你很难知道它在哪一步出了问题Shell 脚本失败时报错信息直接指向那一行。帮助 AI 工作的基础工具最好用最笨的方式实现。七、集成从检测到 AI 上下文注入P0 检测的输出不是终点而是 AI 工作流的起点。完整链路检测结果持久化将 9 个核心变量写入.ai/tech-stack.yaml。每次 AI 启动时读取该文件不重复检测。这确保了跨会话的一致性——今天和明天的 AI 对话用同一份技术栈信息。人工确认是必须的P0 检测的准确率不是 100%。检测完成后有一个 30 秒的人工确认步骤核实 9 个变量是否正确。一个错误的 FRAMEWORK_VERSION 会让后续所有 AI 生成的 API 调用出现命名空间错误。30 秒的确认换来数小时的准确率。三种集成方式对应不同的使用场景一是CI/CD 自动触发在 GitHub Actions 中PR 创建时自动运行 P0 检测结果写入项目配置。适合团队协作确保每个人的 AI 上下文一致。二是CLI 手动运行开发者在新项目上手动执行检测脚本生成配置文件。适合个人项目轻量灵活。三是AI 首次对话触发AI 启动时扫描根目录在第一次对话中生成检测结果并请求确认。适合快速上手不需要额外配置。无论哪种方式核心原则不变检测结果必须经过人工确认后才能作为 AI 的上下文使用。八、这类问题到底有多普遍诚实地看数据关于技术栈误判具体拖慢了多少 AI 协作效率目前没有一项公开研究是专门针对这个变量做量化测量的——所以本节不给出一个精确的百分比而是把能找到的、方向相关的证据摆出来供你自行判断。在AI 辅助编码到底能提升多少效率这个更大的问题上公开研究的结论并不统一而且高度依赖上下文。一篇 2025 年综合多项元分析的评述指出人类与 AI 协作在多数任务上的表现反而常常不如人类或 AI 单独工作创意类任务是例外而AI的生产力提升高度依赖使用者技能水平和任务复杂度人类与AI协作在多数情况下表现不及任何一方独立工作。另一篇 2025 年发表的元分析汇总了 16 项独立研究的效应量发现生成式 AI 辅助对编程效率总体呈正向但中等程度的提升Hedges’ g 0.3395% 置信区间 [0.09, 0.58]但研究之间的差异极大I² 99%——也就是说AI 到底提升了多少效率这个问题答案严重依赖具体场景不存在一个放之四海而皆准的数字。一份针对软件开发场景的系统综述给出了一条更细粒度的解释开发者确实减少了在样板代码生成和 API 查找上花的时间但代码质量问题引发的返工经常抵消了这部分收益任务越复杂这种抵消越明显。这与本章开头三个场景的逻辑是一致的——AI 生成代码的速度快但如果方向错了用错构建工具、用错 API 命名空间返工成本会侵蚀掉大部分速度优势。GitHub 官方博客的一篇分析也提到类似的权衡AI 辅助开发通常能带来 20%–30% 的吞吐量提升但吞吐量提高意味着如果没有合适的护栏架构漂移会积累得更快因此建议团队在扩大 AI 使用规模之前先把架构约定和模式显式记录下来。把这些证据放在一起看能得出的诚实结论是AI 辅助编码的效率增益是真实存在的但极不稳定且高度依赖AI 是否被给到了准确的上下文这个前提条件。“技术栈信息越准确、上下文越干净AI 输出的返工成本越低”——这是本章作者基于多个存量项目实践归纳出的经验推断而不是某一项具体研究给出的量化结论。如果你所在团队想验证这个假设比较直接的方式是自己做 A/B 观察同一批任务一组带 P0 检测上下文、一组不带记录调试时间和返工次数。一个 30 秒的检测脚本投入产出比是不是软件开发里最划算的一笔值得每个团队用自己的数据说话而不是套用一个别人给的百分比。下一章预告技术栈检测解决的是AI 知道你用什么工具的问题。但知道工具不代表理解你的代码组织方式、架构约定和团队规范。Agent 三层体系架构——让 AI 真正理解你的项目是怎么想的而不只是用什么建的。本专栏的开源落地工具IvyFlow本专栏的整套方法论——多角色工作流、阶段守卫、OpenSpecSuperpowers 双驱动、Skill/Rule/Agent 三层分层——并非纸上谈兵。它们的落地载体是 IvyFlow一个 AI-Native 开发工作流 CLI 工具也是本专栏作者的开源项目。IvyFlow 用一条命令ivy init在项目中部署 5 种角色Developer / PM / QA / Architect / DevOps共 20 条命令和约 30 个 Skill将专栏中讨论的Phase Gate、Delta Spec 反写、TDD 强制循环、SubAgent 并行扇全部编码为脚本校验而非纯 Prompt 约定——守卫脚本会硬性拦截 AI 跳过阶段的行为让流程纪律从建议变成物理约束。GitHubgithub.com/jseko/IvyFlow官方网站jseko.github.io/IvyFlow安装npm install -g ivyflow-cli ivy init如果你读完本专栏想立刻落地IvyFlow 就是这套体系的开箱即用入口。