陌生前端项目最容易读错的并不是某段业务代码，而是项目边界、规则、执行方式、启动链和业务入口。本文给出我让 Codex 接手项目时优先确认的 5 个入口，以及每一步需要留下的证据、常见误判和暂停条件。

项目地图不是目录树的复述，而是对“代码如何被组织、解析并运行”的证据整理。本文把陌生前端项目的首次阅读拆成目录层、配置层和入口层，给出具体阅读顺序、交叉验证方法和一份可复用的最小项目地图模板。

文章摘要： 本文探讨了编写清晰AI编程需求的核心问题——信息分层与优先级管理。作者通过典型前端需求案例，揭示长需求常存在的五大混乱：主次目标混淆、事实与建议未区分、长期规则与临时任务混合、实现要求与验收标准模糊、隐藏的需求冲突。针对这些问题，提出六层需求结构法：明确主目标、限定上下文、标注硬约束、描述功能边界、规划执行顺序、制定可验证的验收标准，并强调用"本次不做"清单隔离次要

目标：把筛选、重置、分页、权限和导出连起来验证，清理无关改动。这一阶段不应该继续“顺手优化”。它只做三件事：查看完整代码差异，确认没有越界修改。运行项目已有的检查。按用户操作路径做页面回归。如果此时发现新的重构机会，我会记录成后续任务，而不是继续扩大当前差异。我现在不喜欢让 AI 拿到计划后无条件一路执行到底。在影响范围不清、现有实现与需求冲突、需要修改公共能力或无法运行关键检查时，应该停下来报告

上一篇我讲了怎样把一个完整的前端需求拆成可验收的小任务。任务拆开以后，还有一个问题很容易被忽略：每个小任务到底该怎样交给 Codex？不少人会继续在提示词上做加法。担心 AI 忘记项目规范，就把技术栈、目录结构、代码风格、组件规则、接口规则和测试命令全部复制进去；担心它理解不准确，再补几个示例；担心它擅自修改，又连续写几遍“不要改无关代码”。最后，一次局部修改的提示词可能比需求文档还长。我不否认长

上一篇我写了一个结论：给 Codex 的任务提示，不是越复杂越好。我现在只在当前任务里保留唯一目标、必要事实、硬边界和验收证据。但把提示词缩短以后，很多人马上会遇到另一个问题：不把所有信息都写进去，Codex 怎么理解我的项目？这个担心是合理的。前端代码很依赖上下文。同样是一个搜索列表，有的项目把分页放在查询对象里，有的单独维护；有的直接调用接口，有的必须经过模块服务层；有的使用 Element

本文探讨了AI编码工具Codex在前端项目开发中的局限性，强调其虽然能快速生成语法正确的代码，但往往缺乏对项目上下文的理解。作者指出成熟前端项目的复杂性主要体现在状态管理、业务约定和异常处理等隐性规则上，建议修改前进行针对性代码阅读，建立六个维度的项目认知，并将阅读结果区分为事实、推断和未知三类。文章提供了具体的阅读任务模板，并强调这种"先读后改"的方式能有效降低因错误假设导致

《前端修改前的项目地图：从目录摘要到行为追踪》摘要 本文提出让AI在修改前端代码前生成"项目地图"而非简单代码摘要，强调理解代码行为流而非文件结构。文章指出有效地图应包含六层关键信息：1)项目规则与限制；2)功能入口路径；3)模块职责边界；4)用户行为与状态变化；5)可复用模式与差异；6)影响范围与验证方法。作者提供了具体检查清单和模板，强调结论必须标注代码依据，区分现状与规范

验收标准不是“代码写完、功能正常”，而是任务完成前就约定可观察、可执行、可判断的证据。本文将前端验收拆成行为、数据、修改范围、自动检查和页面体验五类，并提供一份可直接交给 Codex 的模板。

多文件计划不能只列“改哪些文件”，还要写清依赖顺序、每一步的完成证据和必须暂停的条件。本文用 6 个检查点拆解前端多文件修改，并提供一份可直接交给 Codex 的执行计划模板。