大功能别一口气开改：让 Codex 拆成可逐步合并的小改动

教程定位

这篇教程解决什么问题

中型功能最危险的地方，常常不是代码量大，而是它会把很多层同时搅在一起。一个看起来简单的需求，落到工程里可能横跨数据库字段、数据迁移、后端接口、权限判断、前端页面、灰度开关、监控告警和回滚策略。你如果把整件事交给 Codex，说“帮我实现这个功能”，它可能真的开始写代码，而且写得很快。但这种快有时会把风险放大：数据库结构还没确认，接口已经改了；权限逻辑还没想清楚，页面入口已经露出来了；灰度策略还没有，测试环境已经堆出一大包难以审查的改动。

更稳的做法，是先让 Codex 不写代码，只做“工程拆解”。把大功能拆成一串能逐步合并的小改动，每一步都有明确输入、输出、验收点和回滚方式。你要的不是一份宏观路线图，也不是一堆泛泛的待办，而是一份可以交给工程团队执行的提交顺序：先补数据结构和兼容读取，再加服务层能力，再加受保护的接口，再做隐藏入口的界面，再打开配置开关，最后补验收和清理旧逻辑。

这篇教程讲的就是这个用法。场景是：你负责一个中型功能交付，需求要让后台支持“项目审批例外处理”。它需要新增一类审批例外原因，记录处理人和处理时间；后端要提供查询和提交接口；前端要在审批详情页展示入口；权限上只有具备审批处理权限的人可以操作；发布上要求能灰度打开，出问题时能快速关闭入口，并且不能影响现有审批流程。这个例子是安全虚构的，不包含真实公司、真实客户、真实邮箱、手机号、密钥或内部数据。

这时 Codex 最适合承担的任务不是替你一口气写完整功能，而是帮你把实施顺序拆清楚。它可以阅读需求说明、现有代码结构、发布窗口和回滚要求，然后输出一份分步实施清单。清单要回答四个问题：第一，哪些改动必须先做，哪些必须后做；第二，每一步怎样做到可以独立审查和合并；第三，每一步的验收点是什么；第四，如果这一步出了问题，怎么回退或止损。

和“先澄清需求”的文章不同，本文默认需求目标已经大体明确。重点不是继续问“业务到底要什么”，而是进入工程实施层，把已经确认的目标变成低风险落地顺序。你可以把它用在准备拆 PR、排开发任务、和同事评审方案、或让 Codex 后续分批改代码之前。先把顺序拆对，后面的 AI 编码才不容易变成一坨大改动。

使用场景

什么情况下最适合用这一套

这篇文章适合负责中型功能交付的工程师。你不是只改一个按钮文案，也不是从零做一个完全独立的小页面。你手上的需求已经有一定范围，可能涉及多个模块和多人协作。业务方希望这周或下周看到结果，产品文档给了主要流程，但工程细节还有不少需要落地判断。

典型场景是这样的：现有系统里有一个审批流程，过去只有“通过”和“驳回”。现在业务希望支持“例外处理”：某些项目虽然缺少一项材料，但如果符合条件，可以由有权限的人记录原因、上传说明，并让流程继续往下走。这个功能听起来只是多一个动作，但工程上会牵出很多层。

数据库层可能要新增例外处理记录表，或者在现有审批表上增加状态字段。服务层要确保状态流转合法，不能让普通用户绕过审批。接口层要提供查询例外原因、提交例外处理、撤销例外处理等能力。前端要在审批详情页展示入口、原因选择、提交结果和错误提示。权限层要判断谁能看、谁能操作、谁只能看到历史记录。发布层要决定是否先对内部角色开放，是否需要配置开关，是否有回滚脚本。测试层还要覆盖老流程不被影响。

如果你让 Codex 直接“实现例外处理功能”，它很可能会同时改数据库、接口、页面和权限。生成出来的 diff 也许能跑，但会很难评审。评审者要在一个大 PR 里同时判断数据模型是否合理、权限是否安全、UI 是否符合流程、迁移是否可逆、老流程是否兼容。任何一个环节有争议，整包改动都卡住。更糟的是，如果你已经改了数据库和接口，但最后发现权限模型不成立，就会出现一连串返工。

你真正需要的是让 Codex 先变成“拆单助手”。它不急着写实现，而是根据材料输出一个有顺序的实施清单。例如：

这样的顺序有一个明显好处：每一步都能单独审查，单独验证，单独合并。即使中间发现问题，也不会让整个功能陷入“全都做了一半”的状态。你可以把前两步先合进去，因为它们对用户不可见；也可以把前端入口先藏在开关后面，等预发验收通过再打开。功能不是被切碎，而是被切成有防护栏的小块。

这篇教程不会教你用 Codex 替代架构评审。重要决策仍然要由你和团队负责。Codex 的价值在于：它能帮你把隐藏的依赖关系列出来，把“应该先做什么”说清楚，把每一步的验收点写成可执行检查。你拿到这份清单后，再判断是否符合团队习惯、代码库边界和发布要求。

1. 先只新增后端可兼容读取的领域模型和测试，不暴露入口。
2. 再新增数据迁移和回滚说明，确认旧数据不受影响。
3. 再加服务层状态流转，但接口仍不对外开放。
4. 再加受权限保护的接口，并用 feature flag 默认关闭。
5. 再做前端隐藏入口，只在开关打开且权限满足时展示。
6. 再补端到端验收和监控点。
7. 最后在发布后清理临时代码或补长期文档。

材料准备

开始前先把材料和边界备齐

开始之前，先准备四类材料。材料越接近真实工程状态，Codex 拆出来的顺序越靠谱。不要只给它一句“做例外处理功能”，那样它只能用通用经验猜。

第一类是需求说明。这里不需要完整 PRD，但至少要有目标、主要用户、核心流程和非目标。比如：目标是支持有权限的审批处理人记录例外原因，让符合条件的项目继续流转；主要用户是审批处理人和审批查看人；核心流程是查看审批详情、选择例外原因、填写说明、提交、记录审计日志；非目标是不改原有审批通过和驳回流程，不做批量例外处理，不开放给普通申请人。

第二类是现有代码结构。你可以把目录结构、关键模块和已有命名约定交给 Codex。它不一定需要读完整代码，但要知道系统里哪里管数据库迁移，哪里写服务逻辑，哪里定义接口，哪里做权限中间件，哪里放前端页面，哪里写测试。比如：`db/migrations/` 放迁移，`server/modules/approval/` 放审批服务，`server/routes/approval.ts` 放接口，`web/pages/approval-detail/` 放详情页，`server/auth/permissions.ts` 放权限常量。

第三类是发布窗口和环境限制。中型功能的拆分和发布时间强相关。如果发布窗口很短，就更应该先做不可见的兼容改动，再把可见入口放在开关后。如果系统只允许每周固定时间发布，就要把迁移、配置、回滚和验收安排到窗口之前。你要告诉 Codex：最早什么时候合并，什么时候上预发，什么时候上生产，是否允许多次小发布，是否需要 DBA 或运维配合。

第四类是回滚要求。很多实施顺序的优劣，只有放到回滚场景里才看得出来。你要说明：出问题时希望只关闭入口，还是要回滚代码；数据库迁移是否必须可逆；新字段是否允许保留；新接口是否可以继续存在但不暴露；已经写入的新数据如何处理；用户是否可能在灰度期间提交一半。Codex 需要这些约束，才能把“先加开关”“后暴露入口”“保留兼容读取”这类顺序安排清楚。

建议你还准备一个“本次拆解目标”，明确告诉 Codex 不要进入实现：

这个边界很重要。Codex 如果看到完整需求，常常会自然进入“我来实现”的状态。你要把它拉回计划层：先拆，再写。拆解本身就是一项工程工作，不是写代码前的客套话。

• 只输出实施顺序，不写代码。
• 每一步必须能形成一个小 PR 或一组小提交。
• 每一步必须有验收点。
• 每一步必须说明是否用户可见。
• 涉及数据库、接口、权限、页面、开关和测试时要标出依赖关系。
• 对风险较高的步骤要给出回滚或止损方式。

实操流程

按这套步骤把工作跑起来

第一步，要求 Codex 先画出改动面，而不是先排工期。改动面包括数据、服务、接口、权限、前端、配置、测试、发布和监控。让它把每个改动面写成“需要改什么、依赖什么、对用户是否可见、失败后影响什么”。这一步会暴露很多隐藏风险。例如前端入口看似简单，但依赖接口权限；接口看似简单，但依赖服务层状态校验；状态校验又依赖数据模型能记录例外原因和审计信息。

第二步，让 Codex 区分“支撑性改动”和“用户可见改动”。支撑性改动是用户暂时看不到，但后面必须依赖的内容，比如新增枚举、兼容读取逻辑、测试夹具、内部服务方法、配置项骨架。用户可见改动是页面入口、按钮、提示、接口暴露、权限开放。一个稳的顺序通常会先合支撑性改动，再合可见入口。这样即使后面入口暂时不上线，底层准备也不会浪费。

第三步，要求它按依赖关系排序，而不是按模块喜好排序。很多人习惯“先写后端，再写前端”，但真实顺序要更细。比如数据库迁移不能晚于依赖它的服务测试；权限常量要早于接口保护；feature flag 要早于前端入口；审计日志要早于生产灰度；验收样例要早于人工测试。你可以让 Codex 输出“前置条件”和“完成后解锁什么”，这比单纯编号更有用。

第四步，要求每一步都小到能审查。一个好的步骤不一定只改一个文件，但应该有单一目的。例如“新增例外处理记录模型和迁移”是一个目的；“新增服务层提交例外处理并覆盖状态校验”是一个目的；“在审批详情页展示例外入口并接入接口”可能已经偏大，如果页面复杂，可以拆成“隐藏入口和状态展示”和“提交表单交互”两步。你要让 Codex 主动标出哪些步骤过大，需要继续拆。

第五步，给每一步加验收点。验收点不能只写“测试通过”。它要说明怎么确认这一步完成，而且最好能和本步目的一一对应。数据迁移的验收点可以是：迁移后旧审批记录可正常读取；回滚脚本在本地空库和含样例数据的库都能执行；新增表或字段没有写入真实敏感样例。服务层验收点可以是：非法状态不能提交例外；无权限调用会被拒绝；重复提交返回明确错误。前端验收点可以是：开关关闭时入口不可见；权限不足时入口不可见；有权限且开关打开时可以看到入口和提交结果。

第六步，要求每一步标注回滚方式。不是每一步都需要完整回滚脚本，但每一步都要有止损方式。对不可见代码，可以通过回滚 PR 解决；对数据库迁移，要说明是否可逆、是否保留空字段、是否需要数据修复；对接口和前端入口，要说明是否可以通过 feature flag 关闭；对权限放开，要说明是否能通过配置撤回。回滚方式会反过来影响拆分顺序：如果某个入口无法快速关闭，就不应该太早暴露给用户。

第七步，把清单变成 PR 或提交建议。让 Codex 为每一步给出建议标题、改动范围和评审重点。标题要能看出目的，例如“approval: add exception decision model behind no-op path”，而不是“update approval feature”。评审重点要提醒审查者看什么：数据兼容、状态流转、权限边界、开关默认值、用户可见文案、回滚路径。

第八步，让 Codex 输出“不要合并到同一步”的提醒。中型功能经常失败在混合改动：把迁移、权限、页面和文案塞在一个 PR；把重构和新功能混在一起；把接口命名调整和业务逻辑变更混在一起。你可以要求它列出本需求中最容易混在一起但应该分开的改动。这个提醒能帮助你在后续让 Codex 写代码时保持边界。

第九步，人工审查清单。Codex 给出的顺序是草案，不是命令。你要检查它是否误判代码库惯例，是否漏掉团队的发布规则，是否把一个实际强依赖拆开了，是否建议了你们没有的工具或流程。尤其要看数据库和权限部分，不能因为 AI 写得流畅就默认正确。

第十步，锁定第一步，再让 Codex 开始改代码。实施顺序确认后，下一次提示词要只给第一步。例如“只实现第 1 步：新增例外处理记录模型和迁移，不改接口、不改页面、不开放入口”。这样 Codex 的工作会小很多，评审也更清楚。大功能不是不能用 AI 做，而是要把 AI 的工作面压到每次都能看懂。

输入示例

可以直接参考的输入材料

下面是一份可以交给 Codex 的安全虚构材料。你可以按自己的项目替换模块名，但不要放真实密钥、真实用户资料、真实客户名单或内部隐私。

这份输入里有三个关键点。第一，它明确了“不要写代码”，避免 Codex 直接进入实现。第二，它给了发布窗口和回滚要求，方便拆出开关和不可见改动。第三，它给了现有代码结构，让输出更像工程清单，而不是通用项目管理列表。

需求名称：
审批例外处理

业务目标：
现有审批只有“通过”和“驳回”。现在需要支持有权限的审批处理人在少数情况下记录“例外处理原因”，让项目继续流转。所有例外处理必须留下审计记录。

主要用户：
- 审批处理人：可以提交例外处理。
- 审批查看人：可以查看例外处理记录，但不能提交。
- 普通申请人：不能提交例外处理，也不应该看到操作入口。

核心流程：
1. 审批处理人打开审批详情页。
2. 如果项目处于“待处理”状态，且配置开关打开，且用户有权限，则显示“例外处理”入口。
3. 处理人选择一个例外原因，填写说明，提交。
4. 系统记录处理人、处理时间、原因、说明和审批记录 ID。
5. 审批状态进入“已例外处理”，后续流程继续。

非目标：
- 不做批量例外处理。
- 不改现有“通过”和“驳回”流程。
- 不给普通申请人开放入口。
- 不在本轮做复杂报表。

现有代码结构：
- db/migrations/：数据库迁移。
- server/modules/approval/：审批领域逻辑。
- server/routes/approval.ts：审批相关接口。
- server/auth/permissions.ts：权限常量和判断。
- web/pages/approval-detail/：审批详情页。
- tests/approval/：审批模块测试。

发布窗口：
- 本周三可以合并不可见改动。
- 本周四上预发验收。
- 本周五上午生产发布窗口 30 分钟。
- 允许多个小 PR，不希望一个大 PR。

回滚要求：
- 生产出问题时优先关闭入口。
- 数据库新增字段或表可以保留，但不能破坏旧审批读取。
- feature flag 默认关闭。
- 已写入的例外记录需要可追溯，不做硬删除。

请不要写代码。请把这个功能拆成可逐步合并的小改动，输出实施顺序、每步验收点、每步风险和回滚方式。

提示词

可复制使用的提示词

你可以直接复制下面这段提示词。使用时把方括号里的内容替换成你的项目材料。建议先让 Codex 输出清单，再决定是否让它开始改第一步。

如果你已经让 Codex 读了代码库，也可以在提示词里补一句：“请优先使用当前仓库已有目录、命名、测试框架和权限模式；如果不确定，请标注需要人工确认。”这句能减少它凭空建议新架构的概率。

你现在不是实现功能，而是帮我做工程拆解。

背景：
[粘贴需求说明：目标、用户、核心流程、非目标]

现有代码结构：
[粘贴相关目录、模块、测试位置、权限位置、配置位置]

发布和回滚要求：
[粘贴发布窗口、是否允许多次合并、feature flag 要求、数据库回滚要求、生产止损方式]

请输出一份“可逐步合并的小改动实施清单”，要求：
1. 按依赖顺序拆分，不要按你想到的模块随意排列。
2. 每一步都要说明：目的、改动范围、是否用户可见、前置条件、完成后解锁什么。
3. 每一步都要给出验收点，验收点必须可执行，不能只写“测试通过”。
4. 每一步都要说明主要风险和回滚或止损方式。
5. 标出哪些改动不应该混在同一个 PR 里。
6. 如果某一步太大，请继续拆小。
7. 不要写代码，不要虚构不存在的工具，不要引入真实密钥、真实用户数据或公司隐私。

输出格式：
- 先给“改动面总览”。
- 再给“推荐合并顺序”。
- 再给“每步验收点”。
- 再给“高风险点和回滚策略”。
- 最后给“第一步建议提示词”，用于后续只实现第一步。

输出样例

AI 应该输出到什么程度

下面是一份理想输出的缩略样例。真实项目里可以更长，但结构应该类似：先看全局，再按顺序，再落到每步验收。

改动面总览：

数据层需要支持记录例外处理。它是后续服务和审计的基础，但在入口开放前可以先以不可见方式合并。服务层需要新增状态流转和重复提交保护。接口层需要受权限保护，并且默认受 feature flag 控制。前端层需要在审批详情页展示入口、提交表单和结果提示，但必须在开关关闭时完全不可见。权限层需要区分“可提交例外处理”和“可查看例外记录”。发布层需要先合不可见能力，再灰度打开入口。测试层需要覆盖旧流程不受影响、新流程权限边界、开关关闭状态和回滚止损。

推荐合并顺序：

目的：为例外处理记录提供存储结构，同时不改变现有审批行为。 改动范围：数据库迁移、领域类型、基础读取兼容测试。 用户可见：否。 前置条件：确认新增字段或表不会影响旧审批读取。 完成后解锁：服务层可以写入例外处理记录。 验收点：旧审批列表和详情读取正常；迁移可在含样例数据的本地库执行；回滚或保留策略清楚；没有写入真实敏感样例。 风险和止损：迁移失败会阻塞发布；若是新增独立表，优先保留空表并回滚代码，避免破坏旧数据。

目的：把状态流转、重复提交、原因校验和审计记录集中在领域服务中。 改动范围：审批服务、状态枚举、单元测试。 用户可见：否。 前置条件：第 1 步数据结构已存在。 完成后解锁：接口层可以调用稳定服务方法。 验收点：待处理状态可以提交例外；已通过、已驳回、已例外处理状态不能重复提交；缺少原因时返回明确错误；旧通过和驳回测试仍通过。 风险和止损：如果状态枚举影响旧逻辑，先保持旧路径不引用新状态；必要时回滚服务层改动，不回滚数据结构。

目的：先建立保护边界，避免接口或页面提前暴露。 改动范围：权限定义、配置默认值、测试夹具。 用户可见：否。 前置条件：确认团队现有权限命名和配置加载方式。 完成后解锁：接口和前端可以使用同一个开关与权限判断。 验收点：默认配置下功能关闭；没有权限的测试用户不能通过权限判断；现有审批权限不被改变。 风险和止损：配置误开会导致入口提前出现；默认值必须是关闭，生产配置变更需单独确认。

目的：提供提交例外处理和读取记录的后端能力。 改动范围：接口路由、请求校验、权限中间件、接口测试。 用户可见：间接可见，但开关默认关闭。 前置条件：第 2 步服务方法和第 3 步权限开关已完成。 完成后解锁：前端可以接入接口。 验收点：开关关闭时返回不可用；无权限用户返回权限错误；有权限用户在合法状态下可以提交；重复提交返回明确错误；接口不泄露无关审批数据。 风险和止损：接口暴露过早会增加误调用风险；通过开关关闭和路由回滚止损。

目的：让有权限用户看到例外处理入口，让查看人看到历史记录。 改动范围：审批详情页、接口调用、错误提示、前端测试。 用户可见：仅在开关打开且权限满足时可见。 前置条件：接口已可用，权限和开关已验证。 完成后解锁：预发环境可以做完整人工验收。 验收点：开关关闭时入口不可见；普通申请人不可见；审批查看人只能看记录不能提交；处理人可以提交并看到结果；错误提示不暴露内部信息。 风险和止损：页面入口异常会影响审批详情体验；通过关闭开关隐藏入口，必要时回滚前端改动。

目的：让上线前后都有明确观察点。 改动范围：验收脚本或手工清单、日志字段、监控说明、发布说明。 用户可见：否。 前置条件：前后端流程已在预发可跑通。 完成后解锁：生产灰度和正式打开。 验收点：预发完成三类用户验证；旧审批通过和驳回仍可用；开关打开和关闭都验证过；上线后能看到提交成功数和错误数。 风险和止损：缺少观察点会让生产问题发现太晚；如果监控不具备，至少保留可查询日志和人工检查步骤。

不要混在同一个 PR 里的改动：

第一步建议提示词：

“只实现实施清单第 1 步：新增例外处理数据模型和迁移，保持用户不可见。不要改接口、不要改前端、不要开放权限入口。完成后运行现有审批读取相关测试，并说明迁移回滚或保留策略。”

这类输出的好处是，它没有替你做所有决定，但把工程顺序摆到了桌面上。你可以马上看出哪些地方要和团队确认：数据模型是独立表还是扩展旧表，权限常量是否符合现有体系，feature flag 由谁配置，生产开关什么时候打开。

1. 新增例外处理数据模型和迁移，保持用户不可见。
2. 新增服务层例外处理方法，但不暴露外部接口。
3. 增加权限常量和 feature flag 默认关闭。
4. 增加受保护接口，开关关闭时不可用。
5. 增加审批详情页入口和只读记录展示，入口受开关和权限控制。
6. 补齐端到端验收、监控点和发布检查清单。

• 不要把数据库迁移和前端入口混在一起。迁移需要单独确认兼容和回滚，入口需要单独确认用户可见范围。
• 不要把权限模型调整和 UI 文案调整混在一起。前者是安全边界，后者是体验细节，评审重点不同。
• 不要把旧审批流程重构和新例外处理混在一起。重构会放大 diff，让问题归因变困难。
• 不要把 feature flag 默认值改为开启和功能实现放在同一个 PR。开关打开应该是单独、可审计的发布动作。

人工验收

人要怎么检查和改到可用

拿到 Codex 的拆解后，不要直接照单执行。你至少要做七类人工检查。

第一，检查它有没有误读需求边界。比如需求说“不改通过和驳回流程”，但清单里如果出现“重构审批状态机”，你就要压回去。重构可能有价值，但不应混进这次上线目标。你可以把它改成“只在服务层新增例外处理分支，旧状态流转保持现状，重构另开任务”。

第二，检查它有没有忽略现有代码惯例。Codex 可能建议新增一个 `feature_flags` 模块，但你的仓库其实已经有配置中心；它可能建议新建权限中间件，但项目已有统一权限守卫。实施清单要改成贴合现有结构，否则后续实现会制造多余抽象。

第三，检查数据库步骤是否真的可回滚。很多团队说“可回滚”，实际只能回滚代码，不能轻易删字段或删表。如果新增字段不会影响旧逻辑，生产止损方式可能是“保留字段，关闭入口，回滚代码”；如果迁移会改写旧数据，就必须更谨慎，甚至需要单独评审和备份。不要让清单轻描淡写地写“回滚迁移”。

第四，检查权限和开关是否顺序正确。安全功能一般要先有保护边界，再有可见入口。接口层不能晚于前端入口才加权限，feature flag 也不能在 UI 做完后才补。最好让权限、开关和默认关闭策略提前落地，后面每一步都使用同一套判断。

第五，检查每一步验收点是否可执行。如果某一步写“确认体验良好”，这不算验收点。你要把它改成可观察动作：用审批处理人账号打开详情页，开关关闭时看不到入口；打开开关后，在待处理审批上可以提交例外；在已通过审批上提交会失败；普通申请人无法看到入口。越能实际操作，越适合交给人或自动化检查。

第六，检查步骤大小是否适合评审。一个 PR 如果同时新增迁移、服务、接口、页面、权限和测试，即使清单写得很完整，也仍然太大。你可以要求 Codex 继续拆：“第 4 步包含接口、权限、请求校验和测试，是否还能拆成接口只读和提交接口两个 PR？”拆分不是为了形式，而是为了让评审者能在有限时间内看懂风险。

第七，检查发布动作是否被混入代码改动。打开 feature flag、修改生产配置、变更权限授予，通常应该是单独动作，且需要明确批准和记录。代码合并不等于功能对用户开放。清单里如果把“合并前端入口”和“生产打开开关”写成同一步，你应该拆开。

修改完以后，可以把最终清单变成团队内部执行表。每一行包括：步骤编号、建议 PR 标题、负责人、是否用户可见、前置依赖、验收方式、回滚方式、状态。这样 Codex 的输出就从“好像有道理”变成了可以管理的交付材料。

失败反例

这些失败反例要提前避开

【反例 1：让 Codex 直接实现完整功能】

错误提示词是：“帮我实现审批例外处理功能，包含数据库、接口、页面和权限。”这个提示看起来省事，但会让 Codex 把所有风险集中到一次改动里。你得到的可能是一个很大的 diff：迁移、服务、接口、页面、权限判断、测试夹在一起。评审者很难判断每个决策是否合理，也很难局部合并。只要数据库模型有争议，前端和接口也会一起卡住。

更好的做法是先说：“不要写代码，先拆实施顺序。”等顺序确认后，再让 Codex 一次只实现一个步骤。AI 的速度应该用来减少机械劳动，而不是放大审查负担。

【反例 2：按前后端分工拆，而不是按风险和依赖拆】

常见拆法是：“后端一个 PR，前端一个 PR，测试一个 PR。”这比一个大 PR 好一点，但仍然粗糙。后端 PR 里可能同时包含迁移、服务、接口、权限和配置，依然很大；前端 PR 可能在接口权限还没稳定时就开始做交互，后面不断返工。

更好的拆法是按依赖和可见性拆。数据库兼容改动先合，服务层规则再合，权限和开关提前合，接口在保护下合，前端入口最后接入。这样每一步都能解释“为什么现在做它”，而不是只按团队分工切块。

【反例 3：没有 feature flag，却提前露出入口】

有些清单会写：“做完接口后直接在页面上加按钮，测试没问题就发布。”这在中型功能里很危险。只要生产环境出现接口错误、权限误判或状态流转问题，你就只能回滚整包前端或后端代码。回滚期间用户可能已经看到入口，甚至提交过一部分数据。

更稳的做法是默认关闭入口。前端入口、接口能力和服务逻辑可以先存在，但必须受同一个开关和权限控制。生产出问题时，第一止损动作应该是关闭开关，让用户看不到入口，随后再判断是否需要回滚代码或补数据修复。

【反例 4：验收点只写“测试通过”】

“测试通过”不是没用，但它不等于验收。尤其是跨数据库、接口、页面和权限的功能，自动化测试可能覆盖不到真实发布顺序。只写“测试通过”，会漏掉开关关闭时入口是否隐藏、普通用户是否看不到操作、旧流程是否仍可用、错误提示是否安全、生产配置是否默认关闭。

更好的验收点要能让人照着操作。例如：“使用审批处理人账号，在预发环境打开一条待处理审批，开关关闭时不显示例外入口；开关打开后显示入口；提交有效原因后状态变为已例外处理；再次提交返回重复提交错误；普通申请人账号始终看不到入口。”这才是能保护上线的检查。

主题边界

它和相邻主题的区别

这个主题和“让 Codex 问出验收标准”相邻，但关注点不同。验收标准那类用法适合需求还很模糊的时候，例如老板只说“列表更好用”。那时 Codex 应该先帮助你澄清用户、场景、成功标准和边界，避免过早进入实现。

本文的前提是需求已经比较明确，至少知道要做什么、服务谁、主要流程是什么。这里不再把重点放在“业务到底想要什么”，而是放在“工程上怎样安全地做”。你关心的是提交顺序、依赖关系、用户可见范围、开关、回滚和每步验收。它更像工程实施计划，而不是需求澄清清单。

它也和“让 Codex 读代码找到入口”不同。读代码入口关注的是理解现有系统：从哪里开始看、哪些模块相关、数据怎么流动。本文默认你已经知道大致代码结构，下一步要把改动拆成可合并的小步。如果代码结构还不清楚，应该先让 Codex 做代码地图，再做本文这种实施拆解。

它还和“让 Codex 生成测试用例”不同。测试用例关注单个功能点如何验证，本文则关注功能从无到有如何分阶段落地。测试是每一步的组成部分，但不是全部。一个好的实施清单会告诉你什么时候加数据测试，什么时候加接口测试，什么时候做前端验收，什么时候做发布后观察。

实际工作中，这几个主题可以串起来用：先澄清需求，确认验收标准；再读代码，找到改动入口；再用本文方法拆出安全实施顺序；最后让 Codex 按第一步、第二步、第三步逐步改代码。这样 AI 不是一次性替你冲进复杂功能，而是被你放进一个清晰、可审查、可回滚的工程节奏里。