企业官网建设流程全解析

一句话理解：AI 不是不聪明，是它对你的项目一无所知。每次开工，它都在用统计直觉猜你用的是什么——猜错的代价，要你来承担。

一、根因：AI 为什么必然会"猜"

理解 P0 技术栈检测的必要性，要从语言模型的工作方式说起。

大语言模型本质上是一个概率引擎。当你让它"运行测试"，它不会去读你的文件系统——它在训练数据中寻找统计上最常出现的答案。如果训练数据里 Maven 项目占比更高，它就更倾向于输出mvn test。这不是 bug，是 LLM 的基本工作原理。

问题在于：你的项目不是统计数据，它是一个具体的、唯一的存在。你用的是 Gradle 还是 Maven，Java 17 还是 21，javax还是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 检测先运行一次：

LANG=java FRAMEWORK=spring-boot FRAMEWORK_VERSION=3.2 BUILD_TOOL=gradle TEST_TOOL=junit5 JAVA_VERSION=21 DB=postgresql

AI 收到这个上下文后，构建命令直接给出./gradlew test，Entity 注解直接用jakarta.persistence，测试注解直接用@BeforeEach，一次通过。

差距不在于 AI 的能力，在于它是否被告知了正确的事实。

三、P0 检测：30 秒给 AI 建立项目地图

P0（Prime 0）检测是 AI 开工前运行的一次性探测，目标是生成 9 个核心变量，供后续所有 AI 交互使用。

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扫描根目录的特征文件：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是关键的归约步骤。不是简单映射，而是带权重的推理：

置信度低于 0.7 的变量，脚本会标注为"需要人工确认"，而不是默默给出一个可能错误的答案。

Phase 4根据 9 个变量的组合动态生成命令：

这些命令不是硬编码的映射表。如果 package.json 的 scripts 字段里有自定义的"dev": "vite --port 3001"，脚本会直接提取npm run dev而不是猜测一个通用命令。

四、Monorepo：最容易误判的项目结构

Monorepo 是技术栈检测中最容易误判的场景，因为"多个 package.json"既可能意味着 monorepo，也可能只是 node_modules 里的依赖。

判断 monorepo 的真正标准不是文件数量，而是层级继承关系：根目录和子目录都有构建配置，并且子目录的配置继承了根目录的公共部分（统一的 TypeScript 配置、统一的 ESLint 规则、统一的构建工具版本）。

一旦确认是 monorepo，AI 的行为模式需要切换：

• 识别根级别的公共配置，避免每个子模块重复安装公共依赖
• 为每个子模块独立生成命令：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.33，95% 置信区间 [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

本专栏的整套方法论——多角色工作流、阶段守卫、OpenSpec+Superpowers 双驱动、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 跳过阶段的行为，让流程纪律从"建议"变成"物理约束"。

• GitHub：github.com/jseko/IvyFlow
• 官方网站：jseko.github.io/IvyFlow
• 安装：npm install -g ivyflow-cli && ivy init

如果你读完本专栏想立刻落地，IvyFlow 就是这套体系的开箱即用入口。