Codex 入门：先让 AI 读懂你的项目

先换一个起点

第一次用 Codex，不要急着让它改项目

很多人第一次打开 Codex，会马上输入一句：“帮我把这个网站改一下。”这句话看起来直接，实际上很危险。一个项目不是一篇孤立文档，它有页面入口、数据来源、公共组件、样式规则、运行命令、构建检查，也可能有团队约定和不能碰的文件。AI 如果还没读懂这些上下文，就开始动手，结果很容易像一个新同事第一天上班就改合同模板：速度很快，但你不一定敢用。

更稳的方式，是先让 Codex 当一名项目阅读员。第一轮不改任何文件，只读项目、画地图、解释关键文件、说明运行方式、指出风险边界。你要的不是炫技，而是让它先回答几个朴素问题：这个项目是做什么的？页面从哪里来？内容存在什么地方？如果我想改首页、加文章、调导航，应该先看哪里？哪些地方一改就会影响全站？

这篇教程就是教你完成这件事。目标读者不是专业程序员，而是老板、产品经理、网站维护者、运营同学、刚接触 Codex 的职场人士。你不需要听懂所有代码细节，但要学会安排 AI 读项目、判断它是否真的读懂、把阅读结果变成后续安全修改的基础。

概念解释

什么叫“读懂项目”：不是背目录，而是知道业务怎么运转

很多新手会以为，Codex 把目录结构列出来，就算读懂项目了。其实不够。真正的项目理解，不是把 `src`、`app`、`components` 这些名字背出来，而是能解释它们之间怎么配合：用户打开页面时，哪一个文件决定页面地址，哪一个文件提供内容，哪一个组件负责展示，哪一份样式影响视觉，哪一个配置影响搜索和上线。

你可以把一个网站项目想成一家小店。门头和货架是页面，货品是内容数据，装修风格是样式，收银流程是运行和构建，店规是团队约定。只看平面图不够，Codex 要知道客户从门口进来会看到什么、货放在哪里、改一个货架会不会挡住通道、换一个招牌会不会影响老客户找到店。

所以你要求 Codex 读项目时，不要只问“有哪些文件”。更好的问题是：“如果我要新增一篇教程，路径是怎么生成的？如果我要改首页文案，会不会同时影响搜索摘要？如果我要改一个按钮，哪些页面都会变？”当它能用业务语言回答这些问题，并给出文件路径作为证据，才算真正进入了项目现场。

• 目录结构：知道东西放在哪里。
• 功能链路：知道一个页面或功能是怎么跑起来的。
• 数据来源：知道内容、配置、分类、链接来自哪里。
• 影响范围：知道一处修改会影响哪些页面或流程。
• 验证方法：知道改完后用什么方式确认没出错。

角色定位

把 Codex 当成新来的项目同事，而不是许愿机器

对非技术用户来说，最重要的心法是：Codex 很能干，但它不是读心术。你不能只说“优化一下”，然后期待它自动理解老板意图、品牌语气、历史链接、团队禁区和上线风险。更合理的做法，是像带新同事一样带它：先介绍背景，再让它熟悉现场，再安排小任务，最后检查交付物。

新同事入职时，你不会第一小时就让他改报价单、删客户资料、重做官网。你会先让他看产品资料、组织架构、客户案例、工作流程，问他有没有理解。Codex 也是一样。它能看文件、跑命令、改代码，所以更需要你给它边界。边界不是束缚能力，而是把能力放到正确的轨道上。

在真实工作里，你和 Codex 的分工应该很清楚：你负责业务判断，它负责项目阅读和执行细节；你负责说明目标和限制，它负责找证据和提出步骤；你负责最终验收，它负责说明检查结果和剩余风险。只要这个分工清楚，哪怕你不懂代码，也能把 Codex 用得稳。

工作故事线

一个常见开局：老板想让 AI 接手公司官网维护

假设你是公司老板，或者负责官网的产品经理。公司有一个已经上线的网站，平时由外包或开发同事维护。现在你想试试 Codex：以后改文案、加教程、改案例、补 FAQ，能不能不用每次排开发？你打开项目，看到一堆文件夹，心里没底，于是想让 AI 先帮你看看。

如果你直接说“以后这个项目你来维护”，Codex 很可能会开始概括项目，也可能会尝试找可修改点，但它不知道你最关心什么。更好的开局是：“请先只读这个项目，不要修改文件。我的目标是理解这个网站怎么维护。请告诉我首页、文章、导航、样式、运行检查分别在哪里，哪些文件不能随便动。”这句话把它从“执行修改”拉回了“建立认知”。

读完后，Codex 应该能给出一张项目地图：这个网站用什么框架，页面大概在哪，文章数据在哪，教程正文在哪，首页精选怎么来，运行命令是什么，构建检查怎么跑，团队规则在哪里。你拿到这张地图后，再决定下一步是新增文章、修改首页、还是先补一份团队维护说明。这个顺序很朴素，但它把风险从一开始就降下来了。

只读模式

第一轮提示词：明确告诉 Codex“先不要动手”

只读模式是新手最应该养成的习惯。它的意思不是让 Codex 什么都不做，而是让它只看、只分析、只汇报，不写入文件。很多项目事故都发生在第一轮，因为用户还没搞清项目结构，AI 就已经开始改了。只读模式相当于给第一次接触项目加了一个缓冲区。

你在提示词里要直接写：“请先不要修改任何文件。”不要以为 Codex 会自动克制。它是为完成任务而设计的，如果你说“帮我解决这个问题”，它自然会倾向于行动。你要把第一轮任务定义成阅读任务，而不是修复任务。比如“先读 README、配置、页面目录、内容目录和运行脚本，然后输出项目地图”。

只读输出也要有标准。它不应该只是“这个项目看起来是一个 Next.js 应用”。你要它讲清：业务功能是什么，用户访问路径是什么，主要文件负责什么，哪些地方还没确认，下一步如果要修改应该怎么做。这样你才能判断它读得深不深。

我要让 Codex 先读懂这个项目，请先不要修改任何文件。

项目背景：
[说明这个项目是做什么的，谁在用，为什么现在要了解它]

我的目标：
[例如：准备维护官网 / 新增教程 / 排查页面问题 / 交接给新同事]

请先只读并输出：
1. 这个项目大概是什么类型，主要功能是什么
2. 入口页面、内容数据、公共组件、样式、配置分别在哪里
3. 用户打开一个页面时，内容大概是怎么被组织出来的
4. 如果我要做常见维护，通常会改哪些文件
5. 哪些文件风险高，不应该随便动
6. 本项目怎么运行、预览、检查
7. 你现在还不确定什么，需要继续看哪些文件

要求：
请用非技术人员能听懂的话解释；每个判断都尽量给出文件路径作为依据；不要执行修改。

项目地图

让 Codex 画一张普通人能看懂的项目地图

项目地图是后续所有工作的导航。它不是技术炫耀文档，而是一张“以后改东西该去哪里”的工作地图。对老板来说，它回答“这个项目有没有被 AI 读懂”；对产品经理来说，它回答“我提需求时应该指向哪些页面和数据”；对网站维护者来说，它回答“新增、修改、检查的固定流程是什么”。

一张好的项目地图，至少包含八类内容：项目一句话说明、重要目录、页面入口、数据来源、公共组件、样式位置、运行检查、风险边界。每一类都要尽量对应真实路径。比如“教程正文在某个教程正文目录里”，“文章元信息在文章数据文件里”，“首页精选由 featured 或类似字段控制”。路径是证据，证据能防止 AI 凭经验乱猜。

项目地图还有一个重要作用：帮助你发现盲区。如果 Codex 说“我还没确认部署配置在哪里”“我还没看到测试命令”“我不确定 SEO 信息是否自动生成”，这不是坏事。相反，它说明这次阅读有边界。真正危险的是它什么都没读完，却用很自信的语气说“没问题”。

请把刚才读到的内容整理成一张项目地图。

请按下面结构输出：
1. 项目一句话说明
2. 目录地图：重要目录负责什么
3. 页面地图：首页、列表页、详情页、后台或工具页分别在哪里
4. 数据地图：文章、产品、案例、配置、导航、分类等数据在哪里
5. 组件地图：哪些组件被多个页面共用
6. 样式地图：全局样式、页面样式、组件样式在哪里
7. 运行地图：开发预览、构建、检查命令是什么
8. 风险地图：哪些文件牵一发而动全身
9. 待确认问题：哪些地方还没读透

请把每一项写成老板、产品经理、网站维护者都能看懂的语言。

关键文件

先找关键文件：README、配置、入口、数据、组件、样式

Codex 读项目时，不应该漫无目的地把所有文件都扫一遍。更有效的方式是先找关键文件。第一类是项目说明，比如 README、AGENTS.md、贡献指南或部署说明。第二类是配置，比如 package.json、框架配置、构建配置、环境变量示例。第三类是页面入口，比如首页、列表页、详情页、路由文件。第四类是内容和数据，比如文章列表、教程正文、产品数据、导航配置。第五类是公共组件和样式，比如页头、页脚、卡片、按钮、全局样式。

这些文件之所以关键，是因为它们决定项目的日常维护方式。README 告诉你项目怎么启动；package.json 往往能告诉你有哪些运行脚本；页面入口告诉你用户看到什么；数据文件告诉你内容怎么组织；公共组件告诉你一处改动会不会影响很多页面；样式文件告诉你视觉规则在哪里。

你可以让 Codex 按任务倒推关键文件。比如你不需要它抽象地找“所有重要文件”，而是说：“如果我要改首页文案、新增教程、调整导航、检查 SEO，请分别告诉我可能涉及哪些文件。”这样输出更贴近真实工作，也更容易验收。

• 说明类：README、AGENTS.md、部署说明、团队约定。
• 配置类：package.json、框架配置、环境变量示例。
• 页面类：首页、列表页、详情页、布局文件。
• 数据类：文章、教程、案例、导航、分类、SEO 元信息。
• 共享类：页头、页脚、按钮、卡片、全局样式。

请帮我找出这个项目的关键文件，但先不要修改。

我关心这些日常任务：
1. 修改首页文案
2. 新增一篇教程或文章
3. 调整导航入口
4. 修改分类、标签或推荐位
5. 检查 SEO 标题和摘要
6. 本地预览和上线前检查

请输出一个表格式清单：
- 任务名称
- 可能涉及的文件路径
- 这些文件各自负责什么
- 修改时最容易漏掉什么
- 修改后应该怎么检查

如果某个判断不确定，请明确写“不确定”，并说明还需要读哪里。

运行检查

读懂项目，必须读懂怎么跑起来、怎么检查

一个项目如果只看文件、不知道怎么运行，就像只看菜单、不知道厨房能不能出菜。Codex 读项目时，一定要确认运行方式。通常它会从 package.json、README 或项目脚本里找到开发预览、构建、检查、测试等命令。你不需要背这些命令，但要让 Codex 解释每个命令的用途：哪个用于本地预览，哪个用于上线前构建，哪个用于发现代码或类型问题。

运行检查对非技术用户特别重要，因为它是你判断“AI 有没有改坏”的客观证据之一。比如 Codex 后续新增了一篇教程，页面看起来正常，但构建失败，说明上线可能有问题。反过来，构建通过也不代表内容一定好，只能说明机器层面没有发现某些错误。所以验收要同时看两件事：机器检查是否通过，真实页面是否符合业务目标。

还有一个细节：不要让 Codex 凭经验乱跑命令。不同项目脚本不同，Next.js、Vite、Astro、老项目、内部工具都可能有自己的约定。正确做法是让它先读项目脚本，再说明准备运行什么，为什么运行。如果命令失败，也要让它区分“项目原本就有的问题”和“本次改动引入的问题”。

风险边界

读项目时就要标出禁区：哪些地方不能随便改

项目阅读不是只找“能改哪里”，还要找“不能乱改哪里”。对网站和内部工具来说，风险最高的往往是共享组件、路由规则、数据结构、认证逻辑、支付或表单逻辑、构建配置、环境变量、旧链接规则。很多时候，一个按钮组件看起来只是小文件，但它被全站几十个页面使用；一个 slug 字段看起来只是短文本，但它决定外部链接是否还能打开。

你可以要求 Codex 把风险分成低、中、高三类。低风险通常是未发布草稿、单篇正文、明显错别字；中风险是新增内容、改页面文案、调整推荐位；高风险是删除页面、改 URL、改全局组件、改数据结构、改构建配置、改权限相关代码。风险分级的意义不是吓唬自己，而是决定下一步要不要先确认、要不要加检查、要不要准备回退。

读项目阶段就标风险，有一个额外好处：它能防止后续提示词太粗。比如你以后说“帮我改导航”，Codex 如果已经知道导航组件被全站共用，就会提醒你影响范围，而不是只改完了事。项目地图里的风险边界，会变成 AI 后续工作的护栏。

• 低风险：单篇正文、草稿、错别字、说明文案。
• 中风险：新增内容、调整排序、改入口文案、替换图片。
• 高风险：删除页面、修改 URL、改共享组件、改数据结构、改构建配置。

请在动手前帮我做一次风险边界确认。

这次我想做的事：
[写清本次任务]

请先回答：
1. 这次任务的最小修改范围是什么
2. 哪些文件允许修改
3. 哪些文件不应该修改
4. 哪些改动可能影响旧链接、页面入口、SEO、构建或其他功能
5. 如果发现必须扩大范围，你会先停下来问我什么
6. 改完后要运行哪些检查

在我确认前，不要写入文件。

AGENTS.md

把团队规则写进 AGENTS.md，让 Codex 先读规矩再干活

很多项目会有一份 AGENTS.md 或类似说明，用来告诉 AI 助手在这个项目里应该遵守什么规则。你可以把它理解成“给 AI 同事看的员工手册”。它不替代人的判断，但能把常见要求提前写清楚：哪些目录能改，哪些文件不能改，改之前要读什么文档，是否必须先跑检查，是否禁止顺手重构，是否要保留别人改动。

AGENTS.md 的价值，在多人协作时尤其明显。真实工作里，可能同时有老板、产品、开发、设计、多个 AI 子任务在同一个项目里推进。没有规则时，一个 AI 可能为了完成自己的任务改了公共文件，另一个 AI 又覆盖了别人正在做的内容。把规则写进 AGENTS.md，至少能让每次任务从同一套边界出发。

不过，AGENTS.md 不是越长越好。它应该写最重要、最稳定、最容易出事故的规则。比如“首次修改前先阅读本地 Next.js 文档”“不要改映射表”“只允许写入指定文件”“不要回滚别人改动”“改完说明检查结果”。如果你把所有偏好都塞进去，反而会让真正关键的禁区被淹没。

判断理解

怎么判断 Codex 真的读懂了，而不是说得像懂了

AI 很擅长把话说得顺，所以你不能只看它语气自信不自信。判断 Codex 是否真正读懂项目，要看它能不能回答带证据的问题。比如“首页文案在哪里改？”“新增教程需要同时更新哪些地方？”“这个字段会不会影响链接？”“运行构建失败会影响上线吗？”如果它能用具体路径和项目规则回答，可信度就高很多。

一个简单的验收方法是让它反向解释。不要只让它概括项目，而是给它三个真实任务，让它说每个任务应该怎么做，但仍然不要修改。比如：改首页一句话、新增一篇教程、删除一个旧案例。它如果能分别说出涉及文件、影响入口、风险点和检查方式，说明它已经建立了项目模型。

还要看它是否会主动承认不确定。成熟的项目阅读结果里，经常会出现“我还没确认部署平台配置”“我没有看到测试脚本”“这个 SEO 字段可能在构建时生成，需要继续确认”。这不是扣分项。真正需要警惕的是，它没有路径证据、没有不确定项、没有风险提示，却直接建议动手。

请用老板/产品经理/站长视角帮我验收你对这个项目的阅读结果。

请按下面结构输出：
1. 你是否已经能解释这个项目是怎么工作的
2. 你能否说清常见维护任务应该改哪里
3. 你列出的关键文件是否都有路径证据
4. 你是否知道如何运行、预览和检查
5. 你是否指出了高风险文件和禁止动作
6. 还有哪些地方没有读透
7. 如果下一步要修改，建议从哪个最小任务开始

不要只说“我已理解项目”，要给我能复查的证据。

老板验收

老板不看代码，也能验收项目阅读结果

老板验收 Codex 的项目阅读，不需要读代码。你只要问五个问题：第一，这个项目是给谁用的，主要页面是什么？第二，如果要做三类常见维护，分别去哪里改？第三，改完怎么预览和检查？第四，哪些地方不能随便动？第五，下一步最安全的小任务是什么？如果 Codex 能回答清楚，这次阅读就有实际价值。

老板最不应该接受的汇报是“我已经了解项目”。这句话没有证据。更好的汇报应该是：“我已经确认教程正文、文章元数据、首页精选、学习路径、运行脚本分别在哪里；新增教程通常要同步正文和元数据；高风险点是 slug、共享组件和文章映射；下一步建议先做一处低风险内容更新。”这才是可验收的理解。

对管理者来说，项目阅读的成果不是技术文档，而是降低沟通成本。以后你提需求时，可以说“只改正文，不改 slug”“新增内容要出现在列表和学习路径”“先跑构建再汇报”。这些话不需要你会写代码，但会显著提高 Codex 和团队协作的准确度。

1. 让 Codex 用一句话解释项目。
2. 让它列三类常见维护任务的文件路径。
3. 让它说明运行、预览、构建检查。
4. 让它列高风险文件和禁止动作。
5. 让它建议下一步最小安全任务。

真实案例

案例一：产品经理接手一个教程站，先做维护地图

一位产品经理接手公司教程站，老板希望以后能快速上新文章。她一开始以为只要找到文章正文目录就行，后来发现每篇教程还有标题、摘要、分类、学习路径、推荐状态和 SEO 信息。如果只写正文，新文章可能不会出现在列表页；如果只改标题，首页卡片可能还是旧描述；如果误改 slug，外部链接可能失效。

她让 Codex 先只读项目，输出维护地图。Codex 找到文章元数据、教程正文、详情页生成逻辑、首页精选规则和学习路径配置。更重要的是，它指出 slug 是链接稳定性的关键字段，已发布文章默认不要改。产品经理拿到地图后，把“新增教程”整理成固定流程：准备标题、摘要、正文、分类和读者；确认 slug；写正文；同步元数据；检查首页、列表页、详情页和学习路径。

这次阅读本身没有改任何代码，但价值很大。之后每次新增教程，沟通都从“你知道文章在哪吗”变成“按教程 SOP 走”。老板验收也更简单：新文章能否从正确入口进入，标题摘要是否一致，旧链接是否没坏，构建是否通过。项目阅读把一次摸索变成了可复用流程。

真实案例

案例二：老板想改首页，读项目后发现文案和 SEO 分开管理

一位老板觉得官网首页首屏文案太虚，想让 Codex 改得更直接。按直觉，他可能会说“优化首页文案”。但 Codex 先读项目后发现，首页可见文案写在一个页面组件里，而 SEO 标题和网页摘要在另一处 metadata 配置里。也就是说，用户打开页面看到的一句话，和搜索引擎、社交分享看到的标题摘要，不一定来自同一个地方。

如果不先读项目，Codex 可能只改了页面上的主标题，搜索结果里仍然显示旧描述；也可能顺手改了 SEO，却没有告诉老板。读项目之后，任务变得更清楚：这次只改首屏主标题和副标题，不改布局、不改按钮、不改导航；SEO 标题是否同步，由老板单独确认。这样既能满足业务目标，又不会把一个文案任务扩大成全站改版。

这个案例说明，项目阅读不仅帮助 AI 找文件，也帮助人做决定。老板原本以为“改一句话”就是一个动作，读完才知道它可能分成“页面文案”和“搜索摘要”两个决策。Codex 的价值不是替老板决定，而是把隐藏关联摆出来，让老板做更清楚的选择。

真实案例

案例三：网站维护者排查报错，先让 Codex 还原功能链路

还有一种常见场景：网站突然构建失败，或者某个页面打不开。新手很容易把错误信息直接丢给 Codex，让它马上修。这样做有时能解决，但也容易头痛医头。更稳的方式是先让 Codex 还原功能链路：这个页面是怎么生成的，数据从哪里来，最近可能改过哪些字段，构建时会检查什么。

比如一个文章详情页打不开，原因可能不是详情页模板坏了，而是某篇文章缺少必填字段、slug 重复、分类值不合法、正文导出名写错，或者映射表没有对应条目。只有先读懂链路，Codex 才能判断应该改数据、正文、映射、页面模板，还是构建配置。否则它可能在错误的位置修一个表面问题。

维护者的提示词可以这样写：“请先不要修，先解释这个页面从数据到渲染的完整链路，并指出哪些环节最可能导致当前报错。”这句话能让 Codex 从“动手改”切换到“定位原因”。定位清楚后，再做最小修复，风险会小很多。

• 页面打不开，不一定是页面文件坏了。
• 构建失败，不一定是最后修改的文件有问题。
• 先还原链路，再定位原因，最后最小修复。
• 修完要用同一条链路反向检查。

常见错误

新手最容易犯的十个错误

第一个错误，是把 Codex 当搜索引擎，只问“这个项目是什么”，却不要求它给路径证据。第二个错误，是把 Codex 当自动执行器，一上来就让它改。第三个错误，是任务描述太空，比如“优化”“升级”“整理”“美化”，没有具体范围。第四个错误，是没有写禁止项，导致 AI 顺手改了你没要求的文件。第五个错误，是只看它的总结，不让它承认不确定。

第六个错误，是不让 Codex 读运行命令，后续改完也不知道怎么检查。第七个错误，是忽略 AGENTS.md 或团队约定，导致它违反项目规则。第八个错误，是把一次项目阅读做成一次性产物，没有沉淀成地图或 SOP。第九个错误，是多人协作时让 AI 清理、回滚、重排文件，误伤别人改动。第十个错误，是老板验收只听“已完成”，没有要求证据。

这些错误背后的本质都一样：没有把 AI 的工作变成可管理流程。你不需要用复杂术语解决它们，只要坚持四件事：先只读、给范围、要证据、做验收。每次都这样做，Codex 的稳定性会明显提升。

检查清单

项目阅读总清单：从打开项目到准备修改

下面这张清单，可以作为你每次让 Codex 接手新项目的固定流程。它适合老板、产品经理、运营和网站维护者使用，不要求你会写代码。你只要按顺序问，基本就能把“AI 乱猜”变成“AI 有证据地读项目”。

第一，确认背景和目标。第二，进入只读模式。第三，找项目说明和团队规则。第四，画目录、页面、数据、组件、样式、配置地图。第五，确认运行和检查方式。第六，列出常见维护任务对应的关键文件。第七，标出风险边界。第八，要求 Codex 承认不确定项。第九，用老板视角验收阅读结果。第十，选择一个最小安全任务进入修改。

这张清单的价值，在于把项目阅读变成可复用的管理动作。以后每来一个新项目、一个新同事、一个新 AI 子任务，都可以先跑这张清单。先把地图画好，再让 AI 干活，团队会少很多返工和误会。

模板库

五个可复制模板：从只读到验收

你不需要每次从零写提示词。把下面五个模板保存下来，就能覆盖大多数项目阅读场景：只读启动、项目地图、关键文件识别、风险边界确认、阅读结果验收。它们的共同点是：先限制动作，再要求证据，最后要求不确定项。

使用模板时，不要机械复制完就结束。你要把方括号里的背景补全，比如项目是谁用的、你最关心什么、这次是不是多人协作、有没有唯一写入范围。模板提供骨架，真实背景提供方向。没有背景的模板，仍然可能变成空话。

我要让 Codex 先读懂这个项目，请先不要修改任何文件。

项目背景：
[说明这个项目是做什么的，谁在用，为什么现在要了解它]

我的目标：
[例如：准备维护官网 / 新增教程 / 排查页面问题 / 交接给新同事]

请先只读并输出：
1. 这个项目大概是什么类型，主要功能是什么
2. 入口页面、内容数据、公共组件、样式、配置分别在哪里
3. 用户打开一个页面时，内容大概是怎么被组织出来的
4. 如果我要做常见维护，通常会改哪些文件
5. 哪些文件风险高，不应该随便动
6. 本项目怎么运行、预览、检查
7. 你现在还不确定什么，需要继续看哪些文件

要求：
请用非技术人员能听懂的话解释；每个判断都尽量给出文件路径作为依据；不要执行修改。

请把刚才读到的内容整理成一张项目地图。

请按下面结构输出：
1. 项目一句话说明
2. 目录地图：重要目录负责什么
3. 页面地图：首页、列表页、详情页、后台或工具页分别在哪里
4. 数据地图：文章、产品、案例、配置、导航、分类等数据在哪里
5. 组件地图：哪些组件被多个页面共用
6. 样式地图：全局样式、页面样式、组件样式在哪里
7. 运行地图：开发预览、构建、检查命令是什么
8. 风险地图：哪些文件牵一发而动全身
9. 待确认问题：哪些地方还没读透

请把每一项写成老板、产品经理、网站维护者都能看懂的语言。

请帮我找出这个项目的关键文件，但先不要修改。

我关心这些日常任务：
1. 修改首页文案
2. 新增一篇教程或文章
3. 调整导航入口
4. 修改分类、标签或推荐位
5. 检查 SEO 标题和摘要
6. 本地预览和上线前检查

请输出一个表格式清单：
- 任务名称
- 可能涉及的文件路径
- 这些文件各自负责什么
- 修改时最容易漏掉什么
- 修改后应该怎么检查

如果某个判断不确定，请明确写“不确定”，并说明还需要读哪里。

请在动手前帮我做一次风险边界确认。

这次我想做的事：
[写清本次任务]

请先回答：
1. 这次任务的最小修改范围是什么
2. 哪些文件允许修改
3. 哪些文件不应该修改
4. 哪些改动可能影响旧链接、页面入口、SEO、构建或其他功能
5. 如果发现必须扩大范围，你会先停下来问我什么
6. 改完后要运行哪些检查

在我确认前，不要写入文件。

请用老板/产品经理/站长视角帮我验收你对这个项目的阅读结果。

请按下面结构输出：
1. 你是否已经能解释这个项目是怎么工作的
2. 你能否说清常见维护任务应该改哪里
3. 你列出的关键文件是否都有路径证据
4. 你是否知道如何运行、预览和检查
5. 你是否指出了高风险文件和禁止动作
6. 还有哪些地方没有读透
7. 如果下一步要修改，建议从哪个最小任务开始

不要只说“我已理解项目”，要给我能复查的证据。

课后练习

四个练习，把“会看教程”变成“会带 Codex 干活”

练习一：找一个你正在维护的网站或内部工具，只让 Codex 只读项目，输出项目地图。你不要求它改任何东西，只检查它是否能说清项目类型、关键目录、页面入口、数据来源、运行方式和风险边界。这个练习训练的是“让 AI 先建立上下文”。

练习二：给 Codex 三个假任务，但仍然不让它修改。比如“改首页一句话”“新增一篇文章”“删除一个旧页面”。让它分别说出可能涉及的文件、风险和检查方式。这个练习训练的是“判断 AI 是否真的能把项目地图用于实际工作”。

练习三：选择一个低风险小任务，比如修正文案错别字或补充一段说明。让 Codex 先说明范围，再修改，再汇报实际改动和检查结果。这个练习训练的是“从只读进入小步执行”。练习四：把这次阅读和修改流程沉淀成一份简短 SOP，写给下一位同事或下一次 AI 任务使用。

1. 只读项目，输出项目地图。
2. 用三个假任务测试它是否能定位关键文件。
3. 做一个低风险小修改，练习范围控制和验收。
4. 把成功流程整理成团队 SOP 或 AGENTS.md 规则。

最后总结

会派活之前，先会验活；会修改之前，先会阅读

Codex 的强大之处，不只是能写代码，而是能进入项目现场，读文件、找关系、跑检查、解释风险。对老板、产品经理和网站维护者来说，真正值得掌握的不是某个技术命令，而是一套协作流程：先只读，画地图；再找关键文件，确认运行检查；接着标风险边界，验收理解；最后才进入小步修改。

当你这样使用 Codex 时，它不再是一个让人紧张的黑盒，而像一个可以被安排的新同事。它会告诉你项目怎么工作、哪里能改、哪里不能乱动、改完怎么检查。你仍然负责业务判断和最终验收，但大量查找、梳理、解释和第一轮执行工作，都可以交给它完成。

记住这句话：先让 AI 读懂项目，是为了让后面的每一次修改都有依据。项目地图越清楚，任务边界越清楚，验收标准越清楚，Codex 就越能稳定帮你干活。AI 会干活，但真正让它干对活的，是你给它的上下文、规则和检查。

• 先读项目，再改项目。
• 先要证据，再信结论。
• 先定边界，再让 AI 执行。
• 先看检查和页面，再说完成。
• 先沉淀流程，再扩大使用范围。