用 Codex 维护静态网站的安全流程

真实困境

静态网站最怕的不是改不了，而是改漏了

很多老板、内容运营和非技术站长第一次用 Codex 维护网站，会觉得这件事应该很简单：静态网站不就是一堆页面吗？我要新增一篇文章，改几句首页文案，补一个导航入口，让 AI 找到文件改掉不就行了。真正做起来才发现，网站维护的麻烦很少只在“那一段文字”上，而在它周围的一圈关联：页面入口、导航、列表、SEO 摘要、sitemap、构建检查、上线回退。

比如你新增了一篇客户案例，正文已经写好了，但首页没有入口，分类页没有出现，搜索摘要还是空的，sitemap 也没有更新。用户不知道从哪里进入，搜索引擎不知道这页存在，老板点开官网看不到新内容，最后大家会以为 AI 没干活。再比如你只是想把“产品介绍”改成“解决方案”，Codex 顺手改了 URL，外部投放链接全失效。这种事故不是因为 AI 不聪明，而是因为任务没有按网站维护流程来派。

这篇教程训练的能力很明确：让你用 Codex 维护静态网站时，能把一个需求拆成安全任务，明确 AI 和人的分工，检查页面入口、导航、SEO、sitemap 和构建结果，准备上线与回退，最后让老板能用非技术方式验收。读完后，你应该能产出一套静态网站维护 SOP，而不是只会说“帮我改一下”。

错误做法

新手常用的派活方式，为什么容易出事故

错误做法一，是只给 Codex 一个模糊目标：“帮我更新官网”“优化一下 SEO”“把这个页面弄好看点”。这些话在业务会议里勉强能聊，在项目里却不够用。Codex 不知道你要改哪个页面、允许动哪些文件、哪些旧链接不能碰、是否要同步导航，也不知道老板验收看什么。它会努力完成任务，但努力的方向可能和你想的不一样。

错误做法二，是只改正文，不管入口。很多静态网站的内容和入口是分开的：正文在一个文件里，文章元信息在另一个文件里，首页推荐在配置里，导航在组件里，sitemap 可能由数据生成，也可能需要额外处理。只让 AI 写正文，就像把新商品放进仓库但不上架，用户看不到。

错误做法三，是上线前只看一个页面。静态网站的好处是稳定，坏处是很多错误要到构建或真实链接检查时才暴露。一个页面本地能打开，不代表列表页、分类页、分享卡片、旧链接、移动端和构建都没问题。安全流程不是拖慢速度，而是防止小改动变成大返工。

• “优化一下”不是任务说明，只是愿望。
• 只改正文不检查入口，内容可能没人看见。
• 只看页面不跑构建，上线时可能失败。
• 只听 AI 说完成，不让它给证据，老板很难验收。

本质解释

静态网站到底是什么：提前生成好的线上资料架

用大白话说，静态网站像一套提前印好的宣传册和资料架。用户访问时，服务器通常不需要临时查数据库、临时拼页面，而是把已经生成好的页面交给用户。所以它常见于官网、博客、教程站、文档站、产品落地页和活动页。它的优点是快、稳、便宜、容易部署；它的维护难点是很多内容关系在构建前就要整理好。

你可以把静态网站想成一家展厅。页面是展板，导航是门口指示牌，SEO 是写给搜索引擎和分享平台看的展品说明，sitemap 是给搜索引擎看的全馆地图，构建检查是闭馆前巡检，上线是开门营业，回退是发现错误后先恢复昨天那版。这样一看，维护网站就不只是改一块展板，而是要确认观众能找到、说明没写错、地图能指路、开门前巡检通过。

这个本质很重要，因为它决定你怎么用 Codex。你不是让 AI 在一个孤立文本框里写内容，而是让它进入一个已经有结构的网站。它必须知道内容放在哪里、入口从哪里来、生成规则是什么、哪些旧链接要保留、改完后怎么证明没有破坏全站。

工作语言

维护静态网站，不是“改文件”，而是“改一个发布链路”

如果你只把网站维护理解成改文件，很容易漏掉上下游。一个新页面能不能发挥作用，取决于至少六件事：内容是否写好，元信息是否完整，入口是否存在，链接是否稳定，构建是否通过，上线后是否能观察和回退。Codex 很适合帮你跑这些细节，但前提是你把链路说清楚。

比如“新增一篇教程”不是一个动作，而是一串动作：确定标题和读者，写正文，补摘要和标签，确认 slug，加入文章列表，让它出现在正确分类或学习路径，检查详情页，检查首页或导航是否需要入口，检查 SEO 和 sitemap，跑构建，预览页面，最后由负责人确认上线。每一环都不复杂，但少一环就会出问题。

所以你派给 Codex 的任务，应该从“帮我新增页面”变成“请按静态网站发布链路帮我新增页面，先确认正文、元信息、入口、SEO、sitemap、构建和回退”。这句话听起来长一点，但它把风险提前摆到桌面上。

1. 确定业务目标和目标读者。
2. 确认最小修改范围和禁止动作。
3. 修改正文、元信息或页面内容。
4. 同步入口、导航、列表、推荐位。
5. 检查 SEO、sitemap、旧链接。
6. 运行构建，预览关键页面。
7. 负责人验收，上线后准备回退。

AI 分工

Codex 能帮你做很多事，但不能替你拍板

Codex 在静态网站维护里很有用。它能读项目结构，找到页面和数据文件，解释导航如何生成，检查某个 slug 是否被引用，补充元信息，修改正文，跑构建，汇报错误，整理上线清单。对非技术站长来说，这些能力等于多了一个懂项目细节的执行同事。

但 Codex 不能替你负责业务判断。它不能决定一个促销承诺是否合规，不能确认客户案例是否已授权，不能替老板决定是否修改旧 URL，不能保证 SEO 文案一定符合品牌策略，也不能在上线事故里替负责人承担后果。AI 可以发现风险、列出选项、提醒你确认；真正的承诺、审批和上线决定，仍然要由人负责。

最稳的分工是：人负责目标、边界、事实和验收；AI 负责阅读、执行、对照、提示风险。你给它清楚的任务说明，它给你可检查的改动和证据。这个分工清楚后，非技术用户也能安全地驱动一次网站更新。

• AI 负责：找文件、改内容、同步入口、跑检查、说明风险。
• 人负责：确认事实、确认品牌表达、确认链接策略、批准上线。
• AI 可以建议回退，人决定是否回退。
• AI 可以写 SEO 初稿，人确认是否符合业务和合规要求。

开始前准备

先准备四类资料，别让 Codex 靠猜

一次安全的网站维护，开始前至少准备四类资料。第一类是业务资料：为什么要改，面向谁，改完希望用户做什么。第二类是内容资料：标题、正文、图片、链接、案例授权、产品名称、价格或日期等事实。第三类是网站资料：当前页面地址、想新增或修改的位置、是否要出现在导航或首页、是否要保持旧链接。第四类是验收资料：老板看什么，运营看什么，构建通过算不算完成，是否需要截图或预览链接。

很多 AI 改网站的问题，不是发生在代码里，而是发生在资料缺失时。比如你没说活动结束时间，AI 可能沿用旧日期；你没说旧链接不能改，它可能把 slug 改得更好看；你没说导航不变，它可能为了方便用户顺手加入口。AI 的“贴心”在没有边界时会变成风险。

准备资料不需要写成长文，用一页任务卡就够。关键是把背景、目标、输入材料、允许范围、禁止动作、验收方式写清楚。越是非技术用户，越应该用任务卡管理 Codex，而不是用一句话临场发挥。

任务说明

第一步：把需求写成 Codex 能执行的任务说明

好的任务说明有六个要素：背景、目标、输入材料、修改范围、禁止动作、验收标准。背景告诉 Codex 这是什么网站；目标告诉它为什么改；输入材料给它事实依据；修改范围防止它扩大战场；禁止动作保护旧链接和协作者；验收标准让它知道怎样才算完成。

尤其要写清“先不要直接修改”。第一次接触任务时，先让 Codex 输出影响范围和执行计划。比如它应该先回答：这次会涉及页面入口吗？导航要不要改？SEO 要不要同步？sitemap 是否自动生成？构建检查命令是什么？它还不确定什么？你确认后，再让它动手。

这一步看起来像多问了一轮，实际上是在把一次模糊需求变成可控任务。老板和运营不需要懂代码，但需要会提出可执行任务。Codex 不怕任务复杂，怕的是任务含糊。

我要让 Codex 帮我维护一个静态网站，请先不要直接修改文件。

网站背景：
[这个网站是做什么的，主要用户是谁，现在已经上线还是准备上线]

这次任务：
[例如：新增一篇文章 / 修改首页文案 / 增加导航入口 / 修复一个旧链接 / 更新 SEO 摘要]

业务目标：
[说明为什么要改，改完希望用户看到什么，老板最关心什么]

允许修改范围：
[写清允许修改的文件或目录；如果不确定，请要求 Codex 先识别最小范围]

禁止动作：
1. 不要修改已发布页面的 slug 或 URL，除非我明确确认
2. 不要删除页面、重命名文件或重构目录，除非先征求确认
3. 不要顺手改样式、组件、配置或依赖
4. 不要覆盖别人正在修改的内容

请先输出：
1. 这次任务可能涉及哪些页面、数据、导航、SEO、sitemap 和构建检查
2. 最小安全修改范围
3. 你还不确定什么
4. 建议的执行步骤和验收方式

我确认后再开始写入文件。

页面入口

第二步：检查用户从哪里进入页面

页面入口，是静态网站维护里最容易被忽略的地方。你新增了页面，不代表用户能找到。入口可能来自顶部导航、底部导航、首页卡片、文章列表、分类页、标签页、学习路径、站内链接、外部投放链接、搜索结果或 sitemap。不同入口服务不同用户：导航服务主动浏览的人，列表服务按主题找内容的人，SEO 服务从搜索进来的人，sitemap 服务搜索引擎。

Codex 很适合帮你画入口地图。你可以让它回答：“这次新增或修改的内容，用户会从哪些地方进入？哪些入口需要同步？哪些入口不应该动？”它应该给出具体文件或配置位置，并说明每个入口的影响。比如新增教程可能要出现在教程列表和学习路径，但不一定需要进入顶部导航；新增核心产品页可能要同步导航、首页按钮和 sitemap。

验收入口时，不要只打开详情页。你要从用户路径反向走一遍：先打开首页，看能不能找到；再打开列表页，看排序是否正确；再打开分类或标签页，看是否归类；再点相关链接，看有没有断链。入口检查的目的，是确认内容真的进入了网站，而不是只存在于项目文件里。

请帮我为这次静态网站维护任务画一张入口地图。

任务：
[写清本次要新增或修改的内容]

请按下面格式输出：
1. 页面入口：用户从哪些页面能进入这次新增或修改的内容
2. 导航入口：顶部导航、底部导航、侧边栏、分类页、推荐位是否要同步
3. 列表入口：文章列表、教程列表、分类列表、标签页是否会出现
4. SEO 入口：标题、摘要、关键词、分享卡片是否要同步
5. sitemap 入口：是否需要进入 sitemap.xml 或类似站点地图
6. 旧链接影响：是否会影响已发布 URL、外部投放链接、收藏链接
7. 检查办法：改完后分别打开哪些页面验证

如果某一项不需要改，请写“不需要”，并说明原因。

导航

第三步：导航不是目录，导航是老板的取舍

很多人让 Codex 改导航时，会把它当成技术动作：加一个菜单、删一个菜单、换一个文案。其实导航是业务取舍。顶部导航告诉用户“这个网站最重要的几件事是什么”；底部导航承接补充信息；侧边栏或分类导航帮助用户在某个主题内继续阅读。导航不能因为新增一个页面就无限膨胀。

因此，Codex 可以帮你找到导航文件、修改链接、检查页面是否存在，但不应该替你决定“这个入口值不值得放进主导航”。这个判断要由老板、产品或内容负责人做。你可以让 Codex 给出建议，比如“这是核心产品页，建议放顶部导航；这是单篇活动复盘，建议只放列表页，不进顶部导航”。但最后选择要人来确认。

改导航还有一个风险：全站都会受影响。一个链接写错，所有页面的导航都错；一个文案变长，移动端可能挤不下；一个旧入口删除，用户可能找不到老内容。所以改导航后，要同时看桌面端和移动端，至少打开首页、列表页、详情页各一页验证。

SEO

第四步：SEO 不是堆关键词，是把页面说清楚

SEO 对非技术用户来说容易被神秘化。先用工作语言解释：SEO 标题和摘要，就是写给搜索结果、浏览器标签、社交分享和部分站内卡片看的页面说明。它不应该夸大，不应该堆关键词，也不应该和页面正文说两套话。好的 SEO 信息让用户在进入页面前就知道这里有什么。

静态网站里，页面可见标题和 SEO 标题可能在不同位置。你改了页面大标题，搜索摘要不一定自动改；你改了文章摘要，首页卡片可能用了另一份 excerpt；你新增了页面，如果没有 metadata，搜索和分享时可能显示默认信息。Codex 的作用，是帮你找这些字段并提醒是否需要同步。

让 Codex 做 SEO 时，要给它边界。比如“请根据正文起草 SEO 标题和摘要，保持真实、具体、不要夸大，不要承诺无法证明的结果”。然后由人检查：事实是否准确，品牌语气是否合适，是否包含用户会搜索的自然表达，是否和当前页面内容一致。

• 页面标题：用户打开页面后看到的主题。
• SEO 标题：搜索或浏览器标签里更容易识别的标题。
• 摘要：一句话说明页面价值，适合列表和搜索展示。
• 关键词：自然出现即可，不要硬塞。
• 分享信息：别人转发链接时看到的标题、摘要和图片。

请帮我检查这次内容更新是否满足静态网站上线要求。

更新内容：
[粘贴标题、摘要、正文要点、目标页面或文件路径]

请检查：
1. 页面标题是否和正文主题一致
2. 页面摘要是否适合显示在列表页和搜索结果里
3. 关键词是否自然，不要堆砌
4. 页面可见文案和 SEO 文案是否需要同步
5. 内部链接是否指向真实存在的页面
6. 图片或资源是否有合适说明
7. slug 或 URL 是否稳定，是否有改动风险
8. 是否需要同步导航、推荐位、分类、标签或 sitemap

请把结果分成：已通过、建议修改、必须人工确认。

Sitemap

第五步：sitemap 是给搜索引擎看的站点地图

sitemap 通常是一个告诉搜索引擎“我这个网站有哪些页面”的文件或生成规则。你可以把它理解成给搜索引擎看的楼层导览图。普通用户不一定打开它，但搜索引擎会用它更好地发现页面。对内容站、教程站、产品页比较多的网站来说，sitemap 是上线检查的一部分。

不同项目处理 sitemap 的方式不一样。有的项目会自动根据文章数据生成，有的需要在配置里补 URL，有的由框架或插件生成，有的部署平台会处理一部分。你不需要提前知道答案，但要让 Codex 先读项目再判断。不要让它凭经验说“应该没问题”。它应该告诉你：这个项目有没有 sitemap，在哪里生成，本次新增或改名是否会影响它，改完后怎么检查。

特别注意：改 slug 或 URL 会影响 sitemap，也会影响旧链接、搜索收录、外部投放和用户收藏。已发布页面的 URL 默认不要改。如果确实要改，必须有跳转、通知、回退和验收方案。对老板来说，URL 稳定性不是技术细节，而是线上资产保护。

构建检查

第六步：构建通过，是静态网站上线前的最低门槛

构建，就是把网站按项目规则生成一遍。你可以把它想成开门营业前的全站巡检：页面能不能生成，链接和数据有没有明显错误，类型和语法是否过关，缺失字段会不会让页面崩掉。构建通过不代表内容一定完美，但构建失败通常意味着不能放心上线。

让 Codex 修改静态网站时，一定要让它先读项目脚本，再决定跑什么检查。不同项目命令不同，不能凭经验乱猜。它应该汇报：我读到了哪些脚本，准备运行哪一个，检查目的是什么，结果如何。如果构建失败，它还要判断失败是否由本次改动引入，还是项目原本就存在问题。

除了机器检查，还要有人眼预览。构建通过后，打开关键页面：被修改页面、入口页面、列表页、首页、导航所在页面、移动端视图。机器能发现格式错误，但不能判断文案是否打动用户、按钮是否符合业务、案例是否真实授权、页面重点是否清楚。

上线回退

上线前先想好回退，不是悲观，是专业

很多小团队维护静态网站时，最大的风险不是不会上线，而是上线后出问题不知道怎么退。比如首页按钮点不开，新增文章导致构建失败，导航链接写错，SEO 摘要显示旧内容，或者老板上线后发现表述不合适。安全流程要求你在上线前就准备回退方案。

回退的工作语言很简单：如果新版本有明显问题，先恢复到上一个安全版本，再把问题留在本地继续修。你不需要在事故发生时临时想办法。上线前就让 Codex 输出回退条件和回退动作：什么情况必须回退，回退后哪些内容会暂时不可见，谁负责确认，如何通知业务方，修好后再如何重新上线。

对静态网站来说，回退尤其适合做成固定模板。因为很多改动是内容和配置，出问题时先恢复旧版本通常比线上硬修更稳。Codex 可以帮你整理修改文件、生成上线检查和回退清单，但是否上线、是否回退，必须由负责人确认。

• 上线前：确认修改范围、检查结果、预览页面、负责人同意。
• 上线后：打开关键页面，检查入口和链接，观察是否有明显异常。
• 回退条件：核心入口坏、构建失败、事实错误、重要链接失效、老板未批准。
• 回退原则：先恢复稳定版本，再分析问题，不在线上赌运气。

请为这次静态网站修改准备上线和回退方案。

本次修改范围：
[列出已修改或计划修改的文件]

请输出：
1. 上线前检查：要运行哪些检查、打开哪些页面、看哪些入口
2. 老板验收：用非技术语言说明老板应该确认什么
3. 上线后观察：上线后 10 分钟内看哪些页面或指标
4. 回退条件：出现哪些问题必须回退
5. 回退动作：如何恢复到上一个安全版本，哪些内容要暂缓
6. 沟通话术：如果上线延期，如何向业务方说明

要求：把机器检查、人眼检查和业务确认分开写。

老板验收

老板不看代码，也能验收一次网站维护

老板验收不应该停在“页面改了吗”。一次静态网站维护，老板应该看四层结果。第一层，看业务目标：这次修改是否解决原来的问题。第二层，看用户路径：用户能否从预期入口找到内容。第三层，看外部展示：搜索标题、摘要、分享信息是否准确。第四层，看上线安全：构建是否通过，旧链接是否没坏，出问题是否能回退。

你可以让 Codex 用老板视角写验收报告，而不是贴技术日志。好的汇报应该像这样：“本次新增了某教程正文，同步了文章元信息和列表入口；顶部导航未改，因为这不是核心栏目；SEO 摘要已按正文更新；sitemap 由文章数据自动生成，构建通过；需要老板确认的是标题是否符合品牌语气。”这比“已完成修改”可靠得多。

老板验收的重点不是亲自检查每行代码，而是要求证据：改了哪里、为什么改、哪些入口已检查、哪些地方没动、还有什么需要确认。Codex 的输出越能被非技术负责人看懂，团队越容易放心把日常维护交给它。

1. 先看业务目标是否达成。
2. 再看页面入口是否完整。
3. 再看 SEO、sitemap、旧链接是否安全。
4. 再看构建和预览结果。
5. 最后决定上线、暂缓或回退。

请用老板/内容负责人/非技术站长视角验收这次静态网站维护。

请按下面清单逐项回答：
1. 用户是否能从预期入口找到新内容或修改后的页面
2. 页面标题、正文、按钮、链接是否和业务目标一致
3. 导航、列表页、分类页、推荐位是否同步
4. SEO 标题和摘要是否准确，没有夸大或旧信息
5. sitemap 或站点地图是否需要同步，是否已处理
6. 旧链接是否没有被破坏
7. 本地预览和构建检查是否通过
8. 如果上线后出问题，是否知道如何回退
9. 还有哪些地方需要人工最终确认

不要只说“已完成”，请给出检查证据和剩余风险。

案例一

内容运营新增教程：正文写好了，但列表没有入口

一家培训公司的内容运营想新增一篇“新员工 AI 使用规范”。她把正文交给 Codex，让它创建教程页面。第一次做法很快，正文文件生成了，详情页直接打开也能看。但老板从网站首页和教程列表都找不到这篇文章，以为没有上线。后来检查才发现，项目里正文和文章元信息分开，列表页只读取元信息，不会自动扫描正文。

第二次，她按安全流程重新派活：先让 Codex 说明新增教程涉及正文、元信息、分类、学习路径、SEO 和构建检查。Codex 找到正文目录、文章数据文件和列表展示规则，确认 slug 不改旧内容，只新增一条数据。改完后，它打开详情页、教程列表和分类页检查，并跑了构建。

这个案例的关键不是“AI 会写文章”，而是“AI 会把文章放进网站”。内容运营最后沉淀了一条 SOP：新增教程必须同时确认正文、标题、摘要、分类、slug、列表入口、SEO、构建和老板验收。以后再发文章，就不会只把内容放进仓库。

案例二

老板改首页文案：页面显示和 SEO 摘要要分开确认

一位老板觉得官网首页首屏太虚，想把“释放组织智能潜能”改成更直接的“帮团队用 AI 做完真实工作”。他让 Codex 先读项目，不直接修改。Codex 发现首页可见文案在页面组件里，但浏览器标题和搜索摘要在另一处 metadata 里，首页按钮链接还连接到教程列表。

如果直接说“优化首页”，Codex 可能会同时改标题、摘要、按钮、布局甚至导航。老板实际想要的只是改主标题和副标题，暂时不改 SEO，因为市场同事还要确认搜索表达。于是任务被收窄为：只改首页可见文案，不改 URL、不改导航、不改按钮、不改 metadata。Codex 修改后只检查首页展示和移动端换行。

这个案例说明，安全流程不是每次都要多改，而是帮你决定哪些该改、哪些不该改。AI 负责揭示关联，人负责取舍。老板最后知道了一个重要常识：页面上看到的文案，和搜索结果里看到的文案，可能不是同一个字段。

案例三

非技术站长修导航：先问“该不该进主导航”

一个个人站长新增了一个“资源下载”页面，希望 Codex 把它放进顶部导航。Codex 先画入口地图后提醒：顶部导航已有五项，移动端空间紧张；这个页面更像补充资源，不一定适合进入主导航，可以先放在底部导航和相关文章入口里。如果确实要放顶部导航，需要检查移动端显示。

站长原本以为导航只是加链接，后来意识到导航代表网站重点。最后他决定不进顶部导航，只在教程详情页的相关阅读和底部导航增加入口。Codex 修改后检查了底部链接、相关页面入口和移动端展示，没有影响主导航。

这个案例适合所有非技术站长：不要把 AI 当成“你说加就加”的工具。让它先解释影响范围，再由你决定入口等级。主导航是稀缺位置，不是每个新页面都要占一个坑。

• 主导航适合长期、核心、高频入口。
• 底部导航适合补充信息和低频入口。
• 文章内链适合上下文相关内容。
• 移动端空间紧张，导航变更必须检查。

案例四

上线后发现旧链接失效：回退比硬修更稳

一家小公司把“about-us”页面改成了“company”，觉得新 URL 更正式。上线后才发现，公众号菜单、销售邮件、招聘帖子和客户收藏里都还指向旧链接。访问量不大，但每一个打不开的链接都在消耗信任。这个问题不是页面写得不好，而是已发布 URL 被轻易改了。

后来他们调整流程：凡是改 slug、改 URL、删除页面，都必须先让 Codex 列出旧链接影响、sitemap 影响、是否需要跳转、是否需要回退。真正上线时，如果发现外部入口失效，先回退到旧 URL，再评估是否做跳转迁移，而不是在线上临时修一堆链接。

这个案例提醒我们：静态网站里的 URL 是资产。AI 可以建议更清晰的命名，但不能替你承担旧链接损失。已发布页面默认保留原 URL，除非你有完整迁移计划。

常见错误

静态网站维护最常见的十二个坑

第一，只让 Codex 改正文，不确认元信息和入口。第二，新增页面但不检查导航、列表、分类和推荐位。第三，随手改 slug，以为只是名字更好看。第四，把 SEO 当成关键词堆砌，导致标题摘要不自然。第五，忽略 sitemap，以为搜索引擎会自动马上发现一切。

第六，改导航不看移动端。第七，删除旧页面不做跳转或回退。第八，构建失败还想先上线再说。第九，把 AI 的总结当验收，不看实际页面。第十，没有区分机器检查和业务检查。第十一，多人协作时让 Codex 顺手格式化或重构，覆盖别人改动。第十二，上线前没有写回退条件，出问题后全靠临场反应。

这些坑背后是同一个问题：把网站维护看成单点修改，而不是发布链路。解决办法也不复杂：每次任务都检查正文、入口、导航、SEO、sitemap、构建、上线、回退。只要这八个词在脑子里，很多事故会在上线前被拦下来。

检查清单

开始前、修改后、上线前三张清单

静态网站维护可以用三张清单管理。第一张是开始前清单，用来防止任务含糊。第二张是修改后清单，用来确认内容进入了正确位置。第三张是上线前清单，用来确认机器、人眼和业务都过关。你不需要每次都写长报告，但这三张清单最好成为固定动作。

开始前，确认背景、目标、资料、范围、禁止动作。修改后，确认页面、入口、导航、SEO、sitemap、旧链接。上线前，确认构建、预览、移动端、老板验收、回退条件。清单不是形式主义，它能让非技术负责人也参与质量控制。

你可以把清单直接交给 Codex，让它逐项自查并标明证据。注意，AI 自查不是最终验收。它帮你把问题列出来，负责人再决定是否上线。

模板库

五个模板覆盖一次完整维护

你可以把下面五个模板当成静态网站维护的基础工具箱。任务说明模板负责开局，入口地图模板负责防漏，内容与 SEO 模板负责外部展示，上线与回退模板负责安全，老板验收模板负责交付确认。它们不追求华丽，而是追求每次都能把关键问题问到。

使用模板时，最重要的是补齐方括号里的真实背景。不要把模板当咒语。比如同样是新增页面，产品页、文章、活动页、客户案例的入口和验收标准都不一样。模板给你框架，业务事实给 Codex 方向。

我要让 Codex 帮我维护一个静态网站，请先不要直接修改文件。

网站背景：
[这个网站是做什么的，主要用户是谁，现在已经上线还是准备上线]

这次任务：
[例如：新增一篇文章 / 修改首页文案 / 增加导航入口 / 修复一个旧链接 / 更新 SEO 摘要]

业务目标：
[说明为什么要改，改完希望用户看到什么，老板最关心什么]

允许修改范围：
[写清允许修改的文件或目录；如果不确定，请要求 Codex 先识别最小范围]

禁止动作：
1. 不要修改已发布页面的 slug 或 URL，除非我明确确认
2. 不要删除页面、重命名文件或重构目录，除非先征求确认
3. 不要顺手改样式、组件、配置或依赖
4. 不要覆盖别人正在修改的内容

请先输出：
1. 这次任务可能涉及哪些页面、数据、导航、SEO、sitemap 和构建检查
2. 最小安全修改范围
3. 你还不确定什么
4. 建议的执行步骤和验收方式

我确认后再开始写入文件。

请帮我为这次静态网站维护任务画一张入口地图。

任务：
[写清本次要新增或修改的内容]

请按下面格式输出：
1. 页面入口：用户从哪些页面能进入这次新增或修改的内容
2. 导航入口：顶部导航、底部导航、侧边栏、分类页、推荐位是否要同步
3. 列表入口：文章列表、教程列表、分类列表、标签页是否会出现
4. SEO 入口：标题、摘要、关键词、分享卡片是否要同步
5. sitemap 入口：是否需要进入 sitemap.xml 或类似站点地图
6. 旧链接影响：是否会影响已发布 URL、外部投放链接、收藏链接
7. 检查办法：改完后分别打开哪些页面验证

如果某一项不需要改，请写“不需要”，并说明原因。

请帮我检查这次内容更新是否满足静态网站上线要求。

更新内容：
[粘贴标题、摘要、正文要点、目标页面或文件路径]

请检查：
1. 页面标题是否和正文主题一致
2. 页面摘要是否适合显示在列表页和搜索结果里
3. 关键词是否自然，不要堆砌
4. 页面可见文案和 SEO 文案是否需要同步
5. 内部链接是否指向真实存在的页面
6. 图片或资源是否有合适说明
7. slug 或 URL 是否稳定，是否有改动风险
8. 是否需要同步导航、推荐位、分类、标签或 sitemap

请把结果分成：已通过、建议修改、必须人工确认。

请为这次静态网站修改准备上线和回退方案。

本次修改范围：
[列出已修改或计划修改的文件]

请输出：
1. 上线前检查：要运行哪些检查、打开哪些页面、看哪些入口
2. 老板验收：用非技术语言说明老板应该确认什么
3. 上线后观察：上线后 10 分钟内看哪些页面或指标
4. 回退条件：出现哪些问题必须回退
5. 回退动作：如何恢复到上一个安全版本，哪些内容要暂缓
6. 沟通话术：如果上线延期，如何向业务方说明

要求：把机器检查、人眼检查和业务确认分开写。

请用老板/内容负责人/非技术站长视角验收这次静态网站维护。

请按下面清单逐项回答：
1. 用户是否能从预期入口找到新内容或修改后的页面
2. 页面标题、正文、按钮、链接是否和业务目标一致
3. 导航、列表页、分类页、推荐位是否同步
4. SEO 标题和摘要是否准确，没有夸大或旧信息
5. sitemap 或站点地图是否需要同步，是否已处理
6. 旧链接是否没有被破坏
7. 本地预览和构建检查是否通过
8. 如果上线后出问题，是否知道如何回退
9. 还有哪些地方需要人工最终确认

不要只说“已完成”，请给出检查证据和剩余风险。

团队落地

把一次成功维护沉淀成团队习惯

当你用 Codex 成功维护一次静态网站后，不要只把它当成一次任务完成。真正的价值，是把流程沉淀下来。比如把“新增文章 SOP”“改首页文案 SOP”“导航变更 SOP”“上线检查 SOP”写成团队文档，或者写进给 AI 看的项目规则里。下次老板、运营、站长或开发同事再派活，就不用重新摸索。

团队习惯可以很轻量。每次任务开始前，统一要求任务说明；每次修改前，统一要求影响范围；每次上线前，统一要求构建和预览；每次完成后，统一要求老板验收报告。这样做不会让团队变慢，反而会减少反复问、反复改、反复救火。

对多人协作尤其要强调：不要让 Codex 顺手回滚、覆盖或清理别人改动。网站维护常常是内容、设计、开发同时推进，AI 子任务也可能并行。安全流程里必须写清唯一写入范围和禁止动作。越是使用 AI，越需要明确边界。

• 把成功任务整理成 SOP。
• 把常见禁区写进项目规则。
• 每次只做最小必要修改。
• 多人协作时只动自己负责的文件。
• 复盘每次漏检，更新清单。

课后练习

四个练习，把教程变成自己的维护能力

练习一：找一个你熟悉的静态网站，不让 Codex 修改，只让它画入口地图。要求它说明首页、导航、列表、详情页、SEO、sitemap 和构建分别在哪里。这个练习训练的是“看清网站结构”。

练习二：选择一个低风险任务，比如修正一段文案或新增一篇草稿。用任务说明模板派活，要求 Codex 先输出影响范围，再执行修改。改完后用老板验收模板检查。这个练习训练的是“从需求到验收”。

练习三：故意设计一个假任务：“把已发布文章 URL 改得更短”。不要让 Codex 直接改，而是让它列出旧链接、SEO、sitemap、跳转和回退风险。这个练习训练的是“识别高风险改动”。练习四：把你完成的一次维护整理成团队 SOP，包含开始前资料、执行步骤、检查清单、回退条件和验收话术。

1. 只读网站，输出入口地图。
2. 做一个低风险内容更新，完整跑任务说明和老板验收。
3. 用假 URL 修改任务练习风险识别。
4. 把一次成功维护沉淀成 SOP。

最后总结

安全流程的核心：先让网站完整，再让页面好看

用 Codex 维护静态网站，最重要的不是让 AI 写得多快，而是让它按发布链路工作。静态网站像一套提前生成的资料架，页面、导航、SEO、sitemap、构建和上线回退都连在一起。只改一个文件，不能保证用户能找到；只看一个页面，不能保证全站没坏；只听“已完成”，不能让老板放心上线。

这套流程可以浓缩成一句话：先说明任务，再画入口；先守住 URL，再同步 SEO；先跑构建，再给老板验收；先准备回退，再决定上线。Codex 负责读项目、找关联、执行修改、跑检查、汇报风险。人负责事实、取舍、承诺、审批和最终上线决定。

当你这样使用 Codex，它就不再只是帮你改几行文字的工具，而是一个能参与网站维护流程的执行同事。你不需要成为程序员，但要成为一个会派活、会设边界、会验收的网站负责人。AI 会干活，安全流程让它干对活。

• 不要只改正文，要检查入口。
• 不要轻易改 URL，要保护线上资产。
• 不要把 SEO 神秘化，要真实说清页面。
• 不要跳过构建，要让机器先巡检。
• 不要没有回退就上线，要给自己留后路。