同一句描述交给 Eazo 生成的项目，别人机器上能起来、你这边起不来，通常不是“生成质量好不好”这一个变量，而是环境侧和生成侧两类原因叠在一起。建议的判断顺序是：先把运行环境和项目声明的版本对齐，再看控制台里第一条错误，接着用一个静态入口把框架与生成代码分开，最后才去怀疑生成结果里的硬编码。每一步都能拿到一个可验证的信号，用信号决定下一步查哪里，而不是反复重新生成。

先用可验证信号分层：安装阶段就失败、报错指向框架或运行时版本，优先按环境依赖处理；安装通过但启动或页面行为异常、报错落到某个业务文件的具体行，优先按生成结果处理。动作是比对声明文件与本地版本、读控制台第一条错误、用一个静态入口替换真实入口。静态入口跑得通，问题在生成代码；跑不通就先修环境。注意两类原因可能同时存在，改动前先备份或开分支，别覆盖原始生成结果。

一次完整启动的最小验证步骤（按顺序做，不跳步）：

1. 把项目解到一个干净目录，只按声明文件安装依赖，不额外手动加装任何包。
2. 读一遍 package.json、requirements.txt、pyproject.toml、Dockerfile，记下要求的运行时版本。
3. 用 node -v、python `--version` 等确认本机版本，不一致先切换版本再继续。
4. 只跑声明里的启动或构建命令，不做任何修改。
5. 打开控制台，复制从下往上数第一条 Error 的完整原文。
6. 用静态入口替换真实入口再跑一次，判断问题在框架层还是生成代码层。
7. 如果静态入口通过，回到生成代码里搜绝对路径、端口和接口地址。

先比对运行环境与项目声明的版本

版本错配是最容易被忽略、也最容易验证的一类原因。先读项目里的声明文件，再看本机实际版本，两者对上再往下查。

# 看本机版本
node -v && npm -v
python `--version` && pip `--version`

# 看项目声明
cat package.json
cat .nvmrc
cat requirements.txt
cat pyproject.toml
cat Dockerfile

package.json 里重点看 engines 字段和 scripts；node 项目如果带了 package-lock.json 或 pnpm-lock.yaml，锁文件里的版本比 package.json 里的版本范围更贴近实际能跑的组合。比对时先看主版本号，主版本不一致基本就要换运行时；次版本差异一般可以先忽略，但出现语法或模块解析报错时要回来确认。Python 项目以 pyproject.toml 里的 requires-python 和锁文件为准。

不一致时通常会看到这类提示：node 的 “The engine \"node\" is incompatible with this module”、较老 node 解析可选链或顶层 await 时的 SyntaxError: Unexpected token '?'、Python 侧的 “requires a different Python: 3.9.x not in >=3.11”，以及安装阶段的 “Could not find a version that satisfies the requirement”。看到这些，先别改业务代码。

看控制台第一条错误而不是最后一条

安装和编译日志很长，最后一行往往只是结果。要从下往上翻，找到第一条 Error、Exception 或 Module not found，那条才是失败起点，后面的报错大多是它的连带反应。

• 依赖缺失类：Cannot find module 'xxx'、ModuleNotFoundError: No module named 'xxx'、ERR_MODULE_NOT_FOUND，堆栈通常是 import 或 require 的解析链路。
• 语法与运行时类：SyntaxError: Unexpected token、TypeError: xxx is not a function，报错会直接指到某个文件的行列。

缺失依赖通常装一次就能过；如果是某个包里导出名不存在，多半是版本不一致，或者生成代码调用了一个并不存在的接口。语法错误定位到生成文件的具体行时，先看那一行是用了当前运行时版本不支持的写法，还是括号、逗号这类书写问题。请把第一条错误的完整原文、文件名、行号原样复制下来，后面整理给下一轮生成时要用。

用静态页面替换入口判断问题归属

环境与启动脚本是否通，可以用一个最小静态入口来验证。操作前先备份真实入口，或者在分支上做，避免覆盖原始生成结果。

<!-- 前端：把 index.html 的 body 临时改成 -->
<h1>static ok</h1>

// 后端（通用骨架）：只保留一个返回静态文本的路由
app.get('/', (req, res) => res.type('text').send('static ok'));

预期表现是：启动或构建命令正常退出、端口能监听、浏览器访问能看到 static ok、控制台没有报错。如果这个最小入口也起不来，问题在运行时、依赖安装或启动脚本这一层，先把环境修通，重新生成没有意义。如果最小入口能跑通，说明框架和打包链路是好的，再把真实入口换回来，问题范围就缩到了生成出来的业务代码及其调用上。确认之后记得把文件恢复原状。

检查生成代码里被写死的路径与端口

生成代码里常出现只在生成环境成立的写死值：绝对路径、localhost 端口、桌面或临时目录里的数据库文件、写死的接口地址。这些在别人机器上不一定成立。

grep -rn "localhost" src
grep -rn "127.0.0.1" .
grep -rn -E "/Users/|/home/|C:\\\\" .
grep -rn "process.env" . | head -50

搜索目标包括：以 /Users、/home、C:\ 开头的绝对路径，写死的 3000、5000、8000 端口，写死的数据库文件或日志目录，写死的接口域名和密钥。修改位置优先放在配置或环境变量里，代码里只读变量，并补一个 .env.example 说明需要哪些值。改完重启服务，验证方式是：端口按预期监听、页面能取到数据、日志里不再出现路径不存在的报错。

把失败信息整理成下一轮生成的输入

重新生成时，一句“跑不起来”信息量为零，生成结果大概率还是同样的结构。把失败信息整理成可复现的约束条件再交回去。

需要记录的字段：

• 操作系统与版本，运行时版本（node、python、java 等），包管理器与版本；
• 完整启动命令，以及执行命令时所在的目录；
• 第一条错误的原文，涉及的文件名与行号；
• 本地已经做过的改动，以及改动后现象是否变化。

描述可以按“环境 + 命令 + 现象 + 期望”四段来写：

环境：macOS，node 18.19，npm 10，项目目录不使用 Docker
命令：npm install && npm run dev（在项目根目录执行）
现象：install 成功；dev 启动后报 SyntaxError: Unexpected token '?'，
      位置 src/api/client.js:12；README 没有说明 node 版本要求
期望：给出一个在 node 18 上可直接启动的版本，
      不要使用需要更高版本运行时的语法；
      把端口和接口地址放到环境变量，并附 .env.example

这样写的好处，是把环境边界和失败锚点都放进约束里，重新生成的结果更容易在你自己的机器上复现。如果重新生成两轮后仍在同一个位置失败，建议先按前面的步骤确认运行时版本和硬编码，再决定要不要继续重新生成。