上一篇我列出了 Codex 接手陌生前端项目时需要先确认的 5 个入口：项目边界、项目规则、执行入口、应用启动入口和当前业务入口。
接下来要解决一个更具体的问题：
真正打开仓库以后，这些入口应该怎样读，才能快速建立一张可信的项目地图？
我在第 008 篇文章里已经给过一张通用项目地图，它包含规则、入口、职责、行为与状态、复用与差异、影响与验证六层。那张地图回答的是“一个任务需要掌握哪些信息”。
今天这篇不重复列信息项，而是往前再走一步：第一次面对陌生项目时，怎样从最少的一组文件开始，得到第一个可以用于定位任务的子图。
我把这组阅读对象压缩成三层：
目录层：代码被分成了哪些边界；
配置层：这些边界怎样被解析和执行；
入口层：应用怎样真正启动并连接到业务页面。
三层不能分开看。目录给出候选结构，配置解释目录含义，入口证明哪条路径正在运行。
项目地图不是一棵漂亮的目录树
下面这种输出很常见：
src/ ├─ api/ 接口 ├─ components/ 组件 ├─ router/ 路由 ├─ stores/ 状态 ├─ utils/ 工具 └─ views/ 页面
它没有错，却几乎不能支持真实修改。
我仍然不知道：
api是否是唯一请求入口；components是全局组件、业务组件还是两者混合；路由是静态声明、模块扫描还是构建生成；
stores中的状态由谁安装、何时恢复；views中哪个页面真的挂在当前应用上；别名、环境变量和插件是否改变了实际引用关系。
如果项目地图只把目录名翻译成中文，它只是导航，不是证据。
我认可的最小项目地图，至少要能回答：
从项目脚本启动以后，配置怎样解析代码，入口怎样装配应用，用户怎样走到目标页面？
第一层：读目录，但只识别边界和异常
目录层的任务不是展开所有文件，而是识别项目的天然边界。
我会分三轮读。
第一轮：只看仓库顶层
先判断：
是单应用还是工作区；
应用与公共包怎样分布；
是否有服务端、移动端、脚本或文档共存在同一仓库；
是否有旧版、生成产物、缓存和依赖目录需要排除；
项目规则文件位于哪里。
这一轮不急着进入src。
假设看到下面的演示结构：
workspace/ ├─ apps/ │ ├─ console/ │ └─ portal/ ├─ packages/ │ ├─ shared-ui/ │ └─ request/ ├─ scripts/ ├─ docs/ ├─ package.json └─ workspace-config
我先得到的不是“有两个应用、两个包”这种描述，而是几个需要验证的判断：
当前任务属于
console还是portal；两个应用是否真的引用
shared-ui和request；顶层脚本是否统一调度子应用；
scripts是否参与生成路由、类型或环境配置；哪个目录中的规则对目标应用生效。
这些判断要在配置层验证，不能只凭名字确认。
第二轮：进入目标应用顶层
目标应用确定后，我只看它的第一层结构：
依赖清单与脚本；
构建和类型配置；
环境文件；
静态资源；
源码目录；
测试目录；
本地开发说明。
这一轮重点找“异常信号”：
应用内部还有第二个
package.json；存在多个源码根目录；
有多个构建配置或入口 HTML；
测试与源码不在同一包；
环境文件数量很多；
路由或类型可能由脚本生成；
同时存在新旧两套路由、状态或请求目录。
异常信号不是坏事，但它意味着不能套用框架默认结构。
第三轮：围绕当前任务展开源码
进入源码后，我不做全量文件清单，只展开与启动链和业务入口有关的目录：
脚本入口和根组件；
路由与权限；
状态装配；
目标页面与直接子组件；
相关请求与类型；
可复用实现；
对应测试。
目录层到这里就应该停止。它的产出是边界和候选路径，不是最终结论。
目录层应该留下什么证据
我会把结果整理成下面的格式：
| 边界 | 候选位置 | 当前判断 | 仍需验证 |
|---|---|---|---|
| 目标应用 | 具体应用目录 | 当前需求可能属于这里 | 由脚本和路由确认 |
| 公共组件 | 本地包或源码目录 | 可能影响目标页面 | 由依赖和引用确认 |
| 请求层 | 应用内或公共包 | 可能存在统一封装 | 由入口和调用确认 |
| 路由 | 路由目录或生成脚本 | 页面可能动态注册 | 由构建配置和入口确认 |
| 测试 | 应用内或顶层目录 | 可作为验证入口 | 由脚本作用范围确认 |
这里刻意使用“候选”“可能”和“仍需验证”。目录层能够提出问题，但不能替配置和引用关系作证。
第二层：读配置，解释代码为什么这样被找到和运行
配置层是项目地图中最容易被跳过、也最容易制造误判的一层。
很多人找到main.ts就直接向下读，但如果没有先看配置，下面这些问题可能都理解错：
@/实际指向哪个目录；同一个别名在构建与类型系统中是否一致；
哪些环境变量会切换接口、路由或功能；
是否使用插件自动导入组件、路由或 API；
入口 HTML 加载的是哪个脚本；
开发和生产构建是否使用不同配置；
测试环境怎样解析模块；
哪些文件由工具生成，不能直接编辑。
我会按四组读取配置
第一组：依赖与脚本
先看包管理、工作区、依赖和脚本，确认：
项目使用的框架与构建工具来自真实依赖，而不是目录猜测；
启动、构建和检查脚本作用于哪个应用；
脚本是否注入模式、环境或额外参数；
是否存在生成、预处理和联动脚本。
第二组：构建配置
构建配置主要回答：
源码根和公开路径；
别名；
插件；
开发代理；
构建输出；
多入口或条件配置；
自动导入和文件扫描。
我尤其关注插件，因为插件可能改变表面目录与运行代码之间的关系。路由文件没有显式导入页面，不代表没有路由；组件没有手动导入，不代表它来自全局注册；某些类型文件出现在源码中，也可能是生成产物。
第三组：类型与代码检查配置
类型配置、Lint 和测试配置会说明：
哪些文件被真正纳入检查；
路径别名在检查工具中怎样解析；
是否排除了某些旧目录或生成目录；
测试环境和源码环境有什么差异；
项目认为哪些错误必须阻断交付。
只运行一条命令，不看它覆盖什么，很容易得到过度结论。
第四组：环境配置
环境配置要回答：
当前脚本加载哪个模式；
哪些变量参与接口地址、路由基础路径、权限或功能开关；
是否存在本地、测试、预发和生产差异；
变量在哪里声明和使用；
哪些敏感值不应复制到文章、日志或任务上下文。
读取环境配置的目标是理解条件分支，不是输出其中的具体值。
配置不能单独下结论，要做三组交叉验证
构建别名与类型别名交叉验证
如果构建工具把@指向一个目录，类型配置却指向另一个目录，说明项目可能存在历史问题或多环境差异。不能只选一个看起来合理的解释。
脚本模式与环境文件交叉验证
脚本传入的模式，应该能对应实际加载的环境文件和代码分支。仅看到多个环境文件，不能判断当前任务使用哪一个。
插件扫描与真实文件交叉验证
配置声明扫描某个目录，还要确认该目录中生成或注册了什么，以及业务入口是否真正使用它。
配置层完成后，我会把“目录中的可能”收缩为“配置支持的候选路径”。下一步再用入口和引用关系证明哪条路径实际生效。
第三层：读入口，建立一条能跑通的启动链
入口层是最小项目地图的收尾。
它不是只找到main.ts，而是沿真实加载关系走完下面这条链：
执行脚本 → 构建入口 → HTML 容器 → 脚本入口 → 应用实例 → 根组件 → 插件与路由 → 目标业务页面
不同项目可能省略、合并或替换其中某些节点，顺序也应以真实配置为准。
第一步：从执行脚本反推构建入口
我先确认启动命令实际调用哪个工具、加载什么模式、工作目录在哪里。然后在构建配置中找到入口 HTML、脚本入口或多应用选择逻辑。
这样可以避免直接打开一个常见文件名，却没有证明它属于当前启动路径。
第二步：从脚本入口看应用装配
在入口文件中重点看：
应用怎样创建；
根组件是谁；
路由和状态何时安装；
权限、国际化、组件库和全局能力怎样注册；
挂载前是否执行初始化、配置加载或身份恢复；
是否存在环境条件分支。
我不会在这一阶段深入每个插件的实现，只记录它是否可能影响当前业务任务。
第三步：从路由或父级入口找到目标页面
目标页面必须通过可证明的路径定位：
静态路由中的组件引用；
模块路由的聚合关系；
文件扫描或生成路由的规则；
菜单与路由映射；
父页面对子组件的真实引用。
名称搜索可以辅助发现文件，但最终要回到引用和运行入口。
第四步：从页面向下一层跟踪数据和状态
最小地图不需要展开所有业务逻辑，只记录：
页面主要输入来自哪里；
使用哪个状态来源；
请求经过哪一层；
关键子组件怎样通信；
当前任务最可能影响哪些位置；
用哪些检查或页面路径验证。
到这里，项目地图就从“目录中可能有这个页面”变成了“这个页面由当前启动路径实际加载，并通过这些责任边界完成行为”。
一个演示项目，三层阅读怎样互相修正
下面只用于说明方法，不代表真实项目经历。
假设目录层看到：
src/ ├─ main.ts ├─ router/ ├─ pages/ ├─ stores/ └─ services/
最初可能得到几个猜测：main.ts是入口，router声明路由，pages存放页面，services负责请求。
进入配置层后发现：
构建插件会扫描
pages生成路由；@service别名实际指向一个本地公共包，而不是src/services；测试配置没有包含浏览器交互测试；
开发脚本根据模式加载不同接口代理。
目录层的两个判断被修正：路由不是完全手写，页面请求也不一定经过本地services。
进入入口层后又发现：
main.ts在挂载前加载运行时配置；生成路由还要经过权限过滤后才安装；
目标页面通过一个布局组件进入；
页面真正使用的是公共请求包中的封装。
这时最小地图才闭合：
开发脚本与当前模式 → 构建配置和页面扫描插件 → main.ts 加载运行时配置 → 安装状态与权限过滤后的路由 → 布局组件 → 目标页面 → 公共请求包
如果只读目录，我会得到一张看起来正确、实际缺少关键条件的地图。
我要求每一条地图结论都带证据级别
为了防止推断混入事实，我会给地图结论标三种状态。
已确认
有直接配置、代码引用或可运行结果支持。
例如：目标路由明确引用该页面；入口文件实际安装该路由；目标脚本能够启动对应应用。
待验证
当前证据支持一种解释，但还缺少运行、调用方或环境确认。
例如：某个请求封装看起来是统一入口，但尚未查完目标功能的所有调用。
有冲突
目录、配置、规则或稳定实现给出不同答案，需要人确认或继续调查。
例如构建别名与类型别名不一致，两个路由系统同时存在，文档与当前脚本不匹配。
只有“已确认”内容可以直接进入执行计划。“待验证”应该变成计划的前置检查，“有冲突”则应该成为暂停条件。
一份可复用的最小项目地图模板
# 当前任务最小项目地图 ## 0. 任务坐标 - 目标应用： - 当前任务： - 明确不进入的范围： ## 1. 目录层 ### 仓库边界 - 应用： - 公共包： - 脚本、文档、旧版和生成目录： ### 目标应用边界 - 源码根： - 配置与环境文件： - 测试位置： - 当前业务候选目录： ### 异常信号 - 多入口： - 新旧结构并存： - 生成代码或自动扫描： ## 2. 配置层 ### 依赖与脚本 - 包管理和工作区： - 启动、构建与检查脚本： - 脚本作用范围： ### 构建与解析 - 构建入口： - 别名： - 关键插件： - 环境和代理： - 自动生成或扫描： ### 检查范围 - 类型检查覆盖： - 测试覆盖： - 构建能证明什么： ## 3. 入口层 - 执行脚本： - HTML 或构建入口： - 脚本入口： - 根组件： - 路由和状态装配： - 权限、国际化和全局能力： - 目标业务入口： ## 4. 当前任务链路 - 用户入口： - 页面和组件： - 状态来源： - 请求与数据转换： - 预计修改位置： - 验证出口： ## 5. 证据状态 ### 已确认 - 结论 + 文件或配置依据： ### 待验证 - 推断 + 缺少的证据： ### 有冲突 - 冲突内容 + 下一步处理： ## 6. 是否进入修改计划 - 可以进入： - 仍需先解决：
这份模板不要求把所有栏目都写得很长。对于局部任务，地图可以只覆盖一条启动链和一条业务链；对于公共组件或高风险任务，再扩大到其他应用和调用方。
地图什么时候算够用，而不是继续无限阅读
陌生项目很容易让人陷入另一个极端：总觉得还没读完，不敢开始修改。
我会用五个问题判断最小地图是否足够：
能否证明目标页面属于当前启动的应用？
能否说明项目规则和配置怎样约束当前实现？
能否沿用户入口找到页面、状态和请求的主要责任边界？
能否列出预计修改位置和默认不修改范围？
能否说明完成后运行什么检查、走什么页面路径？
五个问题都有证据，就可以进入执行计划。阅读的目标不是掌握整个仓库，而是把当前任务从模糊位置放进一个可修改、可验证的坐标系。
如果某个问题无法回答，就继续读与它直接相关的文件，而不是无差别扩大上下文。
三种看起来像地图、其实还不能使用的输出
只有目录说明
“views放页面，api放接口”没有说明当前任务实际使用哪一条路径。
只有技术栈清单
列出 Vue、TypeScript、构建工具和组件库，不等于理解项目怎样装配这些能力。
只有文件列表
列出十几个“可能需要修改”的文件，却没有说明依赖顺序、用户入口和验证出口，只会把不确定性推给后续实现。
真正可用的地图必须包含关系：哪个配置解释哪个目录，哪个入口加载哪个页面，哪个状态或请求层对当前行为负责。
写在最后
目录、配置和入口文件并不是三个独立的阅读清单，而是三层互相校验的证据：
目录层发现边界和候选路径；
配置层解释模块怎样被解析、生成和执行；
入口层证明当前应用怎样启动并走到目标页面。
我让 Codex 建立最小项目地图时，不要求它复述整个仓库，而是要求它回答一条具体链路：
当前脚本启动哪个应用，配置怎样影响模块与环境，入口怎样装配路由和状态，用户最终怎样进入当前业务功能。
这条链一旦有证据，后面的修改计划才不需要建立在目录名称和框架习惯上。
下一篇会沿第 2 周 Day 2 继续推进：Codex 已经找到正确项目和入口以后，怎样识别并遵守现有代码风格；哪些内容应该写成明确项目规则，哪些只能作为局部参考，避免为了“统一”制造无关修改。
本系列持续更新。后续会继续把项目规则、调用链、代码差异和验证方式接入这张最小地图，逐步完成一次可交付的前端任务闭环。
每日好工具推荐：
在这里推荐一款超好用的图片压缩工具——“图压”在线图片压缩｜免费压缩 JPG、PNG、WebP - 图压工具。同事安利给我的，用过后真的觉得太香了！支持批量压缩、调整压缩百分比，最关键的是它是离线程序，下载到本地就能反复用。我平时做自媒体和写前端时经常用到，再也不用去网上找在线压缩工具了。它也带在线压缩功能，很方便。