企业官网建设流程全解析

1. 换工具这件事，真正让人头疼的不是配置

把主力编码助手从 Claude Code 切到 Codex，很多人第一反应是去翻配置文件、改环境变量、重新装依赖。这些确实要做，但真正让人抓狂的场景往往发生在切换之后的第二天：你打开新工具，面对一个做到一半的项目，脑子里清楚还有三件事没做完，可新工具完全不知道你昨天干到哪、为什么那么干、下一步该动哪个文件。

我见过太多人在这时候选择"凭记忆硬接"，结果就是重复劳动、改错分支、把已经验证过的方案又推翻重来。更糟的是，有些决策是当时权衡了半小时才定下来的，比如"为什么这个模块不用现成的库而手写"，过一夜你自己都忘了理由，新工具更不可能猜出来。

所以这篇要聊的核心不是"怎么装 Codex"，而是怎么用一份 Backlog.md 把项目进度、决策上下文、待办优先级完整交接过去。这套方法我自己在多个项目里反复用过，从个人小工具到多人协作的中型系统都验证过，适合任何需要在不同编码助手之间迁移工作流的开发者。哪怕你只是临时换工具试两天，这份交接文档也能帮你省下大量重新对齐的时间。

先说结论：交接的本质是把"隐性上下文"变成"显性文本"。Claude Code 和 Codex 都是读代码、改代码的工具，它们缺的从来不是能力，而是"你脑子里那些没写进代码的信息"。Backlog.md 就是把这些信息落地的载体。

2. 为什么是 Backlog.md，而不是聊天记录或注释

2.1 聊天记录为什么靠不住

很多人第一反应是"我把之前的对话记录导出来给新工具看不就行了"。理论上可行，实操上问题一堆。

聊天记录是线性且冗余的。你和上一个工具来回几十轮，里面夹杂着大量试错、废弃方案、重复确认。新工具读进去，很难分辨哪句是最终决策、哪句是中途被否掉的想法。我实测过把一段两千行的对话丢给新工具，它确实读了，但抓重点的准确率明显下降，经常把已经废弃的方案又提出来。

而且聊天记录的格式各家不统一，导出后结构混乱，工具解析起来效率低。相比之下，一份结构化的 Markdown 文档，信息密度高、层级清晰，工具能快速定位到"当前状态""待办事项""关键决策"这几个核心区块。

2.2 代码注释解决不了进度问题

那有人会说，我把进度写进代码注释里不就行了。这也不对。

代码注释适合解释"这段代码在干什么"，不适合承载"项目整体走到哪了"。注释是局部的、贴着具体文件的，而进度是全局的、跨文件的。你不可能在某个文件的注释里写清楚"整个项目还剩三个模块没做，其中模块 B 依赖模块 A 的接口先冻结"这种全局信息。

更重要的是，注释会随着代码重构被删掉或错位，而 Backlog.md 作为独立文档，生命周期和代码解耦，不会因为某次重构就丢失上下文。

2.3 Backlog.md 的定位：项目的"外置大脑"

我给 Backlog.md 的定位是项目的外置大脑。它不追求记录所有细节，而是记录那些"不看就会走弯路"的关键信息。具体来说，它要回答四个问题：

• 这个项目现在处于什么状态？
• 已经做了哪些关键决策，为什么这么决策？
• 接下来要做的事，优先级怎么排？
• 有哪些坑已经踩过，别再踩第二次？

这四个问题答清楚了，任何编码助手接手都能快速进入状态。下面这张表是我总结的 Backlog.md 核心区块和它们各自解决的问题：

3. 一份能直接抄的 Backlog.md 结构拆解

3.1 项目概览区块：三句话讲清楚

项目概览不需要长篇大论，三句话足够：这是什么、给谁用、当前阶段目标。我通常这么写：

## 项目概览 - 项目名：某数据处理工具（内部代号） - 一句话描述：把多来源的日志数据清洗后汇总成统一报表 - 当前阶段目标：完成数据清洗模块，跑通端到端流程 - 技术栈：Python 3.11 + Pandas + 本地 SQLite

这里的关键是技术栈要写清楚版本。我踩过一次坑：交接时只写了"用 Python"，新工具默认按最新语法写，结果项目环境是 3.9，好几个新特性用不了，又得回头改。版本号这种细节，写一行省半小时。

3.2 当前状态区块：用"能跑/不能跑"说话

状态描述最忌讳模糊。别说"基本完成"，要说"哪个文件能跑、哪个函数还没实现"。我的写法是分三档：

## 当前状态 ### 已完成且验证通过 - data_loader.py：能从 CSV 和 JSON 读取数据，已用样本数据测试 - cleaner.py 的 dedupe 函数：去重逻辑已验证，边界情况覆盖 ### 已完成但未验证 - cleaner.py 的 normalize 函数：写完了但没跑过真实数据 ### 未开始 - report.py：报表生成，完全没动 - 端到端集成测试

这种分档的好处是，新工具一眼就知道哪些代码可以放心依赖、哪些需要先验证再用。特别是"已完成但未验证"这一档，很多人会漏掉，结果新工具直接拿未验证的代码当基础往上搭，最后发现底层有问题，全盘返工。

3.3 关键决策区块：记录"为什么"，不只是"是什么"

这是整个 Backlog.md 里最有价值、也最容易被忽略的部分。代码能告诉你"用了什么方案"，但告诉不了你"为什么不用另一个方案"。而后者恰恰是新工具最容易踩雷的地方。

我举个例子。之前有个项目，我选择手写一个简单的解析器而没用现成的库。如果只交接代码，新工具很可能觉得"这写得不够优雅，换个库吧"，然后引入新依赖、改一堆代码，最后发现那个库处理不了我们的特殊格式。但如果我在 Backlog.md 里写了决策理由，它就不会动这块：

## 关键决策 ### 决策1：手写解析器而非用现成库 - 背景：数据格式有非标准的分隔符，主流库都不支持 - 尝试过的方案：试了两个流行库，都在特殊分隔符上失败 - 最终选择：手写约 80 行的解析器 - 影响：解析逻辑集中在 parser.py，改动需谨慎

每条决策我都建议按"背景-尝试-选择-影响"四段写。这样新工具不仅知道结论，还知道边界在哪，不会轻易去动已经验证过的部分。

3.4 待办清单区块：优先级比清单本身重要

待办清单不是把所有没做的事列出来就完事，关键是排优先级和标依赖。我习惯用 P0/P1/P2 三档，并且明确标出依赖关系：

## 待办清单 ### P0（必须做，阻塞后续） - [ ] 完成 normalize 函数的真实数据验证 - [ ] 冻结 data_loader 的输出接口（report 模块依赖它） ### P1（重要但不阻塞） - [ ] 实现 report.py 的基础报表 - [ ] 补充单元测试 ### P2（有空再做） - [ ] 性能优化 - [ ] 日志美化

依赖关系一定要写。我遇到过新工具同时开工两个有依赖关系的任务，结果接口对不上，白干半天。明确写"X 依赖 Y"，工具就会先做 Y 再做 X。

3.5 已知坑区块：把踩过的雷标出来

这个区块是纯经验输出，但价值极高。每个项目都有那么几个"看起来能走、实际走不通"的路，写下来能帮新工具省下大量试错时间：

## 已知坑 - 不要用 pandas 的默认 read_csv 读我们的数据，分隔符会错乱，必须指定 sep - SQLite 并发写入会锁，单线程处理即可，别想着多线程加速 - 时间字段有时区问题，统一转 UTC 再处理

这些坑往往来自实际调试，文档里查不到，只有踩过的人知道。交接时写下来，等于把经验直接传递过去。

4. 从 Claude Code 迁移到 Codex 的实操步骤

4.1 迁移前的准备：先冻结当前状态

在切换工具之前，第一件事是冻结当前状态。什么意思？就是确保你交接的那一刻，项目处于一个明确、可复现的状态。

具体操作：先把当前所有改动提交或暂存，跑一遍现有测试确认基线是绿的，然后记录下当前分支和 commit 号。这一步的目的是给交接一个明确的锚点，万一新工具接手后出了问题，你能快速回退到这个点。

我踩过的坑是：有次没冻结状态就直接交接，结果 Claude Code 那边还有未保存的改动，Codex 接手后基于旧代码工作，两边对不上，排查了半天才发现是状态没同步。

4.2 生成 Backlog.md 的实操流程

生成这份文档不需要什么工具，手写就行，但有几个提效技巧。

第一，从最近的对话记录里提取决策。翻一遍你和上一个工具的对话，把那些"最终确定用 X 方案"的节点挑出来，每条整理成决策区块。这个过程本身也是对自己思路的梳理。

第二，用代码结构反推待办。打开项目目录，看哪些文件是空的、哪些函数是 TODO，这些就是待办清单的素材。比凭记忆列要全得多。

第三，把调试时的临时笔记整理进已知坑。很多人调试时会随手记点东西，比如"这里不能用 X"，这些零散笔记整理一下就是高质量的坑位记录。

整个流程熟练后大概 15 到 20 分钟，比起接手后重新对齐动辄一两个小时的浪费，非常划算。

4.3 在 Codex 中加载 Backlog.md 的正确姿势

文档写好了，怎么让 Codex 用起来也有讲究。我的做法是在第一次交互时就把 Backlog.md 作为上下文传入，并且明确告诉它这是项目交接文档。

不要指望工具自动去读项目根目录的某个文件，主动传入更可靠。传入后，我通常会加一句引导："这是项目交接文档，请先通读，然后告诉我你理解的当前状态和下一步该做什么。"

这一步很关键。让工具复述一遍它理解的状态，你能立刻发现它有没有读偏。如果它复述的和你写的不一致，说明文档某处表述有歧义，当场修正，比后面做错了再改成本低得多。

4.4 迁移后的第一次验证：小步快跑

新工具接手后，别急着让它做大任务。先给它一个 P0 里的小任务，比如"验证 normalize 函数"，看它的处理方式是否符合你的预期。

我一般会观察三点：它有没有先读相关代码再动手、它有没有遵守已知坑里的约束、它完成后有没有更新状态。这三点都对了，说明交接成功，可以放心让它做更大的任务。如果哪点不对，回到 Backlog.md 补充说明，再试一次。

这个"小步验证"的环节很多人会跳过，直接让新工具干大活，结果方向偏了才发现，返工成本高。花十分钟验证，省几小时返工，这笔账很好算。

5. 让交接文档真正被"用起来"的几个细节

5.1 文档要短到能被读完

Backlog.md 最大的敌人是"写太长没人读"。工具虽然有耐心读完，但信息太多反而稀释了重点。我的经验是控制在 200 行以内，超过就说明你在记录细节而不是上下文，细节应该留在代码里。

判断标准很简单：如果某条信息删掉后，新工具会走弯路，那就留着；如果删掉也不影响它做对事，那就是冗余，删掉。用这个标准筛一遍，文档自然就精简了。

5.2 状态要实时更新，别攒着

Backlog.md 不是写完就扔的一次性文档。项目推进过程中，状态会变、待办会增减、新坑会出现。我习惯每完成一个 P0 任务就更新一次，保持文档和实际状态同步。

这样做的额外好处是：下次再换工具，你手上已经有一份最新的交接文档，不用临时抱佛脚。相当于把交接成本平摊到了日常，而不是集中在切换那一刻。

5.3 决策区块要写"反面"，不只写"正面"

大多数人写决策只写"我选了什么"，但真正有价值的是"我为什么不选另一个"。因为新工具最容易犯的错，就是重新提出那个你早就否掉的方案。

所以每条决策我都强制自己写一句"尝试过但放弃的方案"。哪怕只是"试过 X，太慢，放弃"这么简单，也能有效阻止工具走回头路。这个习惯我坚持了挺久，实测能减少不少无效讨论。

5.4 用统一的标记符号，方便工具解析

虽然是给人看的文档，但既然要给工具读，用一些统一的标记能提升解析效率。我常用的几个：

• [ ]和[x]标记待办完成状态
• P0/P1/P2标记优先级
• 依赖：前缀标记依赖关系
• 坑：前缀标记已知问题

这些符号不复杂，但能让工具快速抓取结构化信息。比起纯自然语言描述，解析准确率高不少。

6. 几个我踩过的真实坑和应对

6.1 坑一：交接文档写成了"代码说明书"

刚开始用这套方法时，我把 Backlog.md 写成了代码说明书，逐文件解释每个函数干什么。结果工具读完还是不知道项目整体走到哪，因为说明书里全是局部信息，没有全局视角。

后来我调整了思路：代码能说清楚的，文档里不写；代码说不清楚的，文档里重点写。函数干什么，工具读代码就知道；但"为什么这个函数要这么设计""它和另一个模块的依赖关系"，代码里看不出来，这才是文档该承载的。

6.2 坑二：待办清单没有优先级，工具乱做

有次我列了十几条待办但没排优先级，结果新工具从第一条开始做，而第一条恰好是个 P2 的优化项，做完对项目推进毫无帮助。P0 的关键任务反而被晾在一边。

从那以后我强制自己排优先级，而且P0 最多三条。超过三条说明你没想清楚什么最重要，得再砍。优先级的意义就是逼你做取舍，列一堆 P0 等于没排。

6.3 坑三：已知坑写得太笼统，工具照样踩

"注意数据格式问题"这种坑位记录等于没写，工具看了也不知道具体注意什么。有效的坑位记录必须具体到可操作：哪个函数、什么输入、会出什么错、怎么规避。

比如"注意数据格式"应该写成"read_csv 必须指定 sep='|'，否则默认逗号分隔会错乱"。后者工具一看就知道怎么做，前者看了还是懵。

6.4 坑四：忘了同步环境信息

这个坑比较隐蔽。有次交接时项目依赖了几个特定版本的库，但我没写进文档，新工具按最新版本写代码，跑起来各种不兼容。后来我在项目概览里固定加一行"环境依赖"，把关键库的版本列清楚，这类问题就再没出现过。

环境信息包括：语言版本、关键依赖版本、有没有特殊的环境变量、数据库类型和版本。这些看似琐碎，但任何一个不对都可能导致代码跑不起来。

7. 把这套方法固化成习惯

用了几次之后，我发现这套方法的价值远不止"换工具"这一个场景。它其实是一种项目上下文管理的通用做法。

比如团队里来了新成员，一份 Backlog.md 能让他快速上手；比如你自己隔了一周回来继续做，文档能帮你快速回忆；比如项目要暂停一段时间再重启，文档就是最好的记忆载体。

所以我现在养成了一个习惯：任何超过一天工作量的项目，开工时就建一个 Backlog.md，边做边更新。这样无论什么时候需要交接，文档都是现成的，不用临时整理。

具体到日常维护，我的节奏是这样的：每天收工前花两分钟更新状态和待办，每做一个关键决策就补一条决策记录，每踩一个坑就加一条坑位。这些动作加起来每天不超过五分钟，但积累下来的上下文价值极高。

回到最初的问题：从 Claude Code 换到 Codex，进度怎么接？答案不是某个神奇的工具或命令，而是一份写清楚状态、决策、待办和坑位的 Backlog.md。它把散落在你脑子里的隐性信息变成显性文本，让任何工具都能快速接手。

我个人的体会是，交接做得好不好，直接决定了换工具这件事是"提效"还是"添乱"。花二十分钟写文档，换来的是新工具第一天就能干对活，而不是花半天重新对齐。这笔投入产出比，在编码这件事上算是相当高的了。

最后分享一个小技巧：如果你不确定 Backlog.md 写得够不够清楚，可以拿给一个不熟悉项目的同事看，让他复述一遍项目状态。如果他能说个八九不离十，说明文档合格；如果他说得含糊，那就是文档还有歧义，回去补。这个"人肉验证"比任何工具测试都直接。