装好工具之后，怎样确认项目真的能运行

“依赖装完了”只能说明安装步骤结束，不能证明项目能构建，也不能证明启动的是正确入口。编辑器给出补全、AI 工具修改了文件，都属于过程反馈。判断项目能否运行，需要把环境、依赖、启动命令和可观察结果连接起来。

教学案例是一份资料目录应用：读取合成目录，显示三条记录，并能搜索一个不存在的标题。我们先定义运行契约，再选择帮助完成契约的工具，不做缺乏统一任务与环境的速度排名。

清单与锁文件解决不同问题

依赖清单说明项目要求什么，锁文件记录某次解析得到的依赖图。一个顶层版本声明可能使用范围，锁文件通常还包含传递依赖与完整性信息。只看清单上的几个名称，不能判断整棵依赖树是否一致。

锁文件也不包办整个环境。运行时版本、操作系统、原生依赖、包管理器选项、环境变量和外部服务仍会影响结果。把“有 lockfile”写成“任何电脑一定完全一样”是不准确的。可复现说明应同时记录运行时与安装策略，必要时约定平台条件。

安装前查看项目的包管理器约定与脚本，不要随手混用多个工具生成新锁文件。依赖变更应由清单和锁文件共同表达，审阅时检查是否出现意外的大范围更新。来源可信也不意味着安装过程中不会执行代码；生命周期脚本和原生构建都需要相应权限。

npm ci 的条件和实际影响

npm 官方文档说明，npm ci 需要现有锁文件；清单与锁文件不匹配时会报错，不会替你更新锁文件。已有 node_modules 会在安装前被移除。因此应在一次性或已确认可重建的工作副本验证，不能在包含手工改动的依赖目录里盲目执行。

若锁文件由影响依赖解析的选项生成，后续安装也需要匹配相应设置。先读项目配置，再选择命令。网络、注册源、平台构建和安装脚本都可能造成失败；每种失败需要保留相应错误与退出状态，而不是不停删锁文件重试。

安装成功后依次执行项目声明的检查、构建和启动步骤。脚本名并没有行业统一保证：名为 test 的脚本可能只打印占位文字。读实际脚本内容，确认它验证什么。构建退出成功还要查看产物是否存在，启动成功还要验证页面与接口行为。

编辑器工具各自提供什么证据

语言服务器负责类型与符号分析，格式化器统一文本样式，调试器暂停并检查运行状态，终端运行项目命令。它们互相补充，但格式整齐不能证明业务正确，补全可用也不能证明依赖已安装到启动进程使用的环境。

VS Code 调试配置可以指定入口、参数和环境。对于资料目录应用，普通终端使用项目根目录，调试器却从子目录启动时，配置读取可能不同。把工作目录和入口明确写进项目说明，再核对调试器实际使用的设置。不要把临时本机绝对路径当成团队通用配置。

浏览器中的结果还要与预期数据对应。旧进程、旧缓存和错误端口都可能呈现一个“看起来正常”的页面。使用合成资料 ID 或明确的版本标记验证新构建，并检查失败状态，例如无结果、加载错误和重新尝试。

AI CLI 的任务范围要可检查

AI 编码工具可能读取代码、编辑文件、运行命令；具体能力、认证和权限依供应商与版本而异。工具名称不能代替能力核实，也不应据此编造谁最快、谁更适合所有任务。比较时使用同一个小需求和相同验收条件。

例如让工具修复空查询返回行为，任务应包含允许修改的文件、输出语义和检查命令。结束后查看 diff、运行记录、退出状态与失败样本。文本回答“已完成”不是完成证据；命令运行了也要确认它有没有真正覆盖原来的错误。

编辑器插件和 CLI 都可能以当前用户权限执行代码。选择工具时检查来源、访问范围、是否需要联网以及任务记录如何保存。只提供合成数据与必要上下文，别为了快速配置把密钥写进项目文件或截图。可撤销的局部试用适合先验证工作流。

用离线契约检查暴露不一致

示例把清单与锁记录简化为依赖名和精确版本的映射。函数检查所有声明是否有相同的解析版本；先验证一致，再单独把清单改成新版本。这是教学契约，未实现 npm 的版本范围、传递依赖、完整性校验或安装行为。

manifest = {"library": "1.2.0"}
lock = {"library": "1.2.0"}
def agrees(declared, resolved):
    return all(resolved.get(name) == version for name, version in declared.items())
assert agrees(manifest, lock)
manifest["library"] = "1.3.0"
assert not agrees(manifest, lock)
print(agrees(manifest, lock))

输出是 False。锁记录仍为 1.2.0，而清单变成 1.3.0，所以检查拒绝一致性结论。它只表明简化映射中的版本不同，不能把这个函数当成真实 package-lock 校验器，更不能用它替代 npm 安装。

这个例子刻意不在每次失败后自动同步锁记录。自动修改会让检查变成自我证明，掩盖到底由谁决定依赖更新。真实项目应通过包管理器完成有意的依赖变更，并审阅解析结果。

对需要后端服务的应用，还要区分本地进程启动和依赖服务可达。可以使用项目提供的教学桩或合成数据完成基础验证，但必须明确哪些请求没有经过真实后端。把外部服务不可用写成前端构建失败，会引导读者反复重装无关依赖。

练习：交付一份运行证据

准备一次性副本，记录运行时、包管理器版本、清单与锁文件状态、安装命令和退出状态。按照项目定义运行检查、构建与启动，再验证三条合成记录可见、未知查询返回空状态、刷新后行为一致。

随后制造清单与锁记录不一致、错误入口、缺少必需配置三种失败。验收要求每种失败都能定位到安装、启动或运行行为阶段，并有修复后重新执行原始步骤的记录。最后比较一种编辑器调试方式与一种 AI CLI 工作流，依据可见证据、权限与恢复成本解释选择，不用主观“更智能”代替结论。