业务限制没人说清时，让 Codex 从代码里挖出规则和影响范围

教程定位

这篇教程解决什么问题

很多系统里的业务规则并不在需求文档里，而是散在代码的判断条件、接口参数、权限中间件、测试用例、数据库字段默认值和前端提示文案里。产品问一句“为什么试用团队最多只能建 3 个项目”，工程师打开文档找不到说明，搜 `3` 又会搜出一堆分页大小、重试次数和 UI 间距。真正的限制可能藏在 `canCreateProject`、`PlanLimitGuard`、`billingFeatureFlags`、`project.spec.ts` 和一段很久没人改过的迁移脚本里。

这篇文章讲的不是“怎么让 Codex 读懂整个仓库”，而是一个更窄、更实用的动作：当业务规则藏在代码里时，让 Codex 帮你把规则条件、判断入口、调用方、测试覆盖和影响范围挖出来，整理成一份可复核的业务规则索引。它适合要改计费、权限、审核、风控、配额、状态流转、优惠资格这类逻辑的工程师。你最终要拿到的不是一句“规则是这样的”，而是一张清单：规则在哪里判断，什么条件触发，哪些页面和接口依赖它，哪些测试证明它存在，哪些边界还没被测试覆盖，改动后可能影响哪些模块。

这里最关键的是克制。不要一开始就让 Codex “解释这套计费规则”或“帮我改成新规则”。如果规则来源不清，直接改代码很容易把局部判断当成全局规则，把临时补丁当成业务约束，把测试里的旧假设当成现在仍然有效的产品口径。更好的方式是先让 Codex 只读搜索：围绕业务关键词和可疑条件，找出判断点、调用路径、测试用例、前端文案、后端错误码和数据字段，再按证据强弱归类。等规则索引被人确认后，再进入修改阶段。

本文会用一个虚构的订阅系统举例：产品问“为什么基础套餐的成员邀请会被限制”，工程师手上只有几个业务关键词、相关页面截图、代码仓库和部分测试文件。我们会让 Codex 搜索规则判断、调用方和测试用例，最后输出“业务规则索引”和“影响模块清单”。这个方法也可以迁移到审核逻辑、权限策略、额度控制和状态机判断上。

使用场景

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

你负责一个 SaaS 后台的计费和权限模块。某天产品同事在需求讨论里问：“基础套餐为什么只能邀请 5 个成员？我们能不能把这个限制调到 8 个？”你打开产品文档，发现最新版本只写了“不同套餐有不同成员上限”，没有说明具体数字。更早的需求单里提过 5，但那是两年前的版本。运营文档里又写“基础套餐建议团队人数 1 到 6 人”，客服话术里写“最多 5 位协作者”。代码里没有一个叫 `basicPlanMemberLimit` 的常量，只有一堆 `canInvite`、`seatLimit`、`quota`、`subscriptionTier`、`ownerCount`、`activeMemberCount` 之类的名字。

这时你不能只靠全文搜索 `5`。数字 5 可能出现在分页、倒计时、重试次数、评分星级、缓存时间里。你也不能只看后端接口，因为前端可能提前禁用了邀请按钮；更不能只看前端文案，因为真正阻止请求的是服务端。你需要同时回答几个问题：

Codex 在这里的价值是快速建立线索网络。它可以沿着关键词、函数名、错误码、测试描述和调用关系，把散落的规则点拉到一张表里。但判断仍然要由人完成，因为代码里常常同时存在“当前规则”“旧规则残留”“测试辅助规则”“灰度规则”“特殊客户豁免”和“前端展示规则”。你要让 Codex 把这些东西分开，不要让它替你拍板。

这篇教程特别适合这些场景：

它不适合直接生成法律、财务或安全领域的最终规则口径。高风险规则可以用这个方法做代码事实梳理，但最终解释必须由对应负责人确认。

1. 成员上限到底在哪里判断？
2. 这个判断是否只针对基础套餐，还是还受试用期、赠送席位、企业白名单影响？
3. 前端、后端、定时任务、导入工具、管理员后台是否都使用同一套规则？
4. 现有测试覆盖了哪些边界，例如 4 人、5 人、6 人、禁用成员、待接受邀请、团队 owner 是否计入？
5. 如果把上限从 5 改到 8，会影响哪些模块、错误提示、埋点、接口返回和客服说明？

• 计费规则要改，例如套餐额度、试用限制、免费转付费条件、优惠资格。
• 权限规则要改，例如角色能否审批、能否导出、能否邀请外部成员。
• 审核逻辑要改，例如内容进入人工审核的条件、退款审批阈值、异常订单拦截。
• 产品问“这个限制为什么存在”，但需求文档、代码注释和历史记录都说不清。
• 你需要在改动前给产品或技术负责人一份影响范围，而不是只给一句“代码里有判断”。

材料准备

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

开始前先把材料收窄。业务规则搜索最怕范围太大，如果你只说“帮我看看权限逻辑”，Codex 会被路由、中间件、角色枚举、测试 mock、文档示例淹没。你要给它一个具体问题和一组可疑关键词。

最少准备四类材料。

第一类是业务关键词。关键词不要只给中文，也要给英文变量可能使用的说法。例如“基础套餐成员邀请限制”可以拆成：`basic`、`starter`、`free`、`member limit`、`seat limit`、`invite`、`invitation`、`quota`、`subscription tier`、`canInvite`、`PlanLimit`。如果产品用语和代码用语不一致，要把两套词都列出来。

第二类是相关页面截图或文字描述。截图本身可以不交给 Codex，至少要转写关键文案、按钮状态和错误提示。例如：“基础套餐邀请第 6 个成员时，按钮仍可点击，但提交后弹出 Upgrade required；成员管理页顶部显示 5/5 seats used。”这些文案常常能反向定位到前端组件和翻译文件。

第三类是代码仓库和大致目录。告诉 Codex 项目根目录、可能相关的前端应用、后端服务、共享包和测试目录。比如 `apps/web`、`services/api`、`packages/billing`、`packages/permissions`、`tests/billing`。如果你不知道，也可以让它先读工作区结构，但要明确“只读，不修改”。

第四类是已有测试文件或测试命名线索。业务规则经常在测试里说得比代码清楚。测试标题可能写着 `does not allow starter workspace to invite more than five active members`，而代码里只有一个 `if (usage >= limit)`。让 Codex 搜索测试能帮你找边界条件，也能暴露未覆盖的情况。

准备材料时还要设定边界：

推荐你先写一个“规则调查卡”，结构如下：

这个准备动作会让 Codex 更像一个做证据整理的助手，而不是一个到处猜业务含义的聊天机器人。

• 不要贴真实用户邮箱、手机号、客户名称、合同编号、支付账号、内部密钥或生产 token。
• 不要让 Codex 一开始就改代码。第一轮只读搜索和整理证据。
• 不要把截图里的真实组织名、成员姓名、订单号原样输入。可以替换成 `demo_workspace`、`user_demo`、`order_example_001`。
• 如果涉及计费、权限、审核、合规或安全，输出必须有“待人工确认”和“未验证边界”字段。

要调查的规则：
基础套餐成员邀请上限。

业务问题：
产品想知道为什么基础套餐第 6 个成员邀请失败，以及是否可以把上限改为 8。

已知现象：
成员管理页显示 5/5 seats used；提交邀请后接口返回 PLAN_MEMBER_LIMIT_REACHED。

业务关键词：
基础套餐、成员上限、邀请、seat、member limit、starter、basic、quota、PLAN_MEMBER_LIMIT_REACHED。

可能相关目录：
apps/web、services/api、packages/billing、packages/permissions、tests/billing。

本轮目标：
只读搜索，整理规则判断点、调用方、测试覆盖和影响模块，不修改代码。

实操流程

按这套步骤把工作跑起来

第一步，把业务问题翻译成可搜索的规则假设。

不要直接问“为什么不能邀请第 6 个成员”。先让 Codex 把问题拆成若干可搜索假设。例如：

这一步的输出应该是一组搜索词和候选文件类型，而不是结论。你可以要求 Codex 列出它准备搜索的关键词，先让人看一眼，避免它只搜中文或只搜一个函数名。

第二步，让 Codex 先找“规则信号”，不要急着解释完整链路。

规则信号包括这些东西：常量、枚举、配置、错误码、条件判断、guard、policy、validator、feature flag、数据库字段、迁移脚本、测试标题、前端提示文案。让 Codex 用业务关键词在仓库里搜索，按信号类型归类。

例如它可能找到：

这时先不要合并成“规则就是基础套餐最多 5 人”。你要让 Codex 继续找：这个 5 是不是只针对 active member？pending invitation 算不算？owner 算不算？禁用成员算不算？企业白名单是否覆盖？是否还有后台导入绕过？

第三步，沿着判断点向上找调用方。

找到规则判断函数以后，要反向追踪谁调用它。业务限制的风险通常不在单个函数，而在入口是否统一。成员邀请可能有这些入口：

你要让 Codex 输出调用方清单，并标注入口类型。尤其要区分“直接调用规则判断”和“绕过判断”。如果后台导入没有调用 `canInviteMember`，这不是马上要改的 bug，但一定是影响范围里的风险点。

第四步，沿着判断点向下找依赖数据。

业务规则不是只有 `if`。同一个条件背后可能依赖套餐配置、订阅状态、席位购买数、成员状态、团队类型、灰度开关、缓存和数据库聚合。让 Codex 继续追踪判断函数读取了哪些数据。

例如成员上限规则可能依赖：

这些依赖决定了改规则时要看哪些模块。把 `5` 改成 `8` 只是最表层的动作。如果实际规则是 `plan.memberLimit + extraSeats`，就不能只改常量；如果前端使用实时成员数，后端使用缓存快照，就要检查两边口径是否一致。

第五步，用测试文件确认边界。

测试用例是业务规则调查的重点，不是附属材料。让 Codex 搜索相关测试标题和断言，尤其关注边界值和反例。比如：

你要让 Codex 不只列“有测试”，还要列“没有测试”。没有测试不代表规则不存在，但代表改动风险更高。最终影响清单里要写清楚：哪些边界已有测试保护，哪些需要补测试后再改。

第六步，检查前端展示和后端拦截是否一致。

很多业务规则会有两层：前端显示限制，后端真正拦截。前端可能根据 `/billing/usage` 返回的 `memberLimit` 禁用按钮；后端可能在提交邀请时重新计算；翻译文件里可能写死了“最多 5 人”。如果只改后端配置，页面还会显示旧文案；如果只改前端，用户仍然会被接口拒绝。

让 Codex 搜索错误码、文案、按钮禁用条件和接口返回字段。输出时至少分成三类：

这能帮助你判断改动需要同步到哪些地方，而不是只盯着一个 `if`。

第七步，要求输出“规则索引”，每条规则只写可证据化内容。

规则索引不是自然语言总结，而是可复核表。建议字段包括：

让 Codex 明确不要写“应该”“可能是产品设计”这类没有证据的说法。它可以写“推测”，但必须放在未验证字段里。

第八步，输出“影响模块清单”，按改动风险排序。

规则索引回答“规则是什么”，影响清单回答“改它会碰到哪里”。对于成员上限，影响模块可能包括：

排序时优先放“会阻止用户操作或造成口径不一致”的模块，其次是文案和测试，最后是可后续整理的历史记录。

第九步，人工复核后再进入修改阶段。

拿到 Codex 输出后，不要马上让它改。你至少要做三件人工检查：

第一，打开关键文件确认判断条件。看 Codex 是否把测试 helper、mock 配置、旧迁移脚本误认为线上规则。

第二，用本地测试或最小复现确认边界。比如基础套餐有 5 个 active 成员时接口是否真的拒绝，第 6 个 pending invitation 是否计入。

第三，找产品或业务负责人确认规则口径。代码能证明“现在系统这么做”，不能证明“业务上应该继续这么做”。尤其是计费和权限规则，代码事实只是讨论基础。

第十步，把索引保留下来，作为改动说明的依据。

如果后续真的要改规则，你可以把这份索引用在变更说明、测试计划和代码审查里。PR 描述里不要只写“修改基础套餐成员上限”，而要写清楚“已确认规则判断来自套餐配置，影响邀请接口、成员页展示、用量接口和 4 个测试用例；管理员后台导入仍需单独确认”。这样审查者能快速看懂改动范围，也能指出遗漏。

• 是否存在按套餐读取成员上限的配置？
• 是否存在邀请前检查 active members 或 pending invitations 的逻辑？
• 是否存在前端展示的 seats used 和后端拦截使用不同口径？
• 是否存在错误码 `PLAN_MEMBER_LIMIT_REACHED` 或类似文案？
• 是否存在测试覆盖第 5 个、第 6 个成员的边界？
• `PLAN_MEMBER_LIMIT_REACHED` 出现在 `services/api/src/errors/billing.ts`。
• `starter: { memberLimit: 5 }` 出现在 `packages/billing/src/plan-config.ts`。
• `canInviteMember(workspaceId, userId)` 出现在 `services/api/src/modules/invitations/invite.service.ts`。
• `memberCount >= plan.memberLimit` 出现在邀请服务里。
• `Starter plan allows up to 5 members` 出现在翻译文件里。
• `rejects starter workspace when active members reach limit` 出现在测试里。
• 前端成员管理页点击邀请。
• 后端公开 API `POST /workspaces/:id/invitations`。
• 管理员后台替客户添加成员。
• 批量导入成员脚本。
• 邀请链接接受流程。
• 定时任务把待邀请用户转成 active member。
• 测试或 seed 数据绕过校验。
• `workspace.subscription.plan`：当前套餐。
• `workspace.subscription.status`：试用、正常、逾期、取消。
• `planConfig.memberLimit`：套餐默认成员数。
• `workspace.extraSeats`：额外购买席位。
• `workspace.flags.ignoreMemberLimit`：特殊豁免。
• `members.status in ("active", "pending")`：计数口径。
• `billingUsageSnapshot.memberCount`：缓存后的用量。
• 4 个成员时允许邀请。
• 5 个 active 成员时拒绝新邀请。
• 4 个 active 加 1 个 pending 时是否拒绝。
• owner 是否计入成员数。
• disabled 或 removed 成员是否计入。
• 试用期和基础套餐是否相同。
• 额外席位是否增加上限。
• 管理员后台是否有单独测试。
• 展示层：页面文案、提示、按钮状态、升级引导。
• 校验层：后端 guard、service、validator、policy。
• 数据层：套餐配置、用量统计、缓存、数据库字段。
• 规则编号：例如 R-01。
• 规则描述：用业务语言写一句，但必须标注证据来源。
• 判断条件：列出代码里的实际条件，例如 `activeOrPendingCount >= memberLimit`。
• 触发入口：页面、接口、脚本、后台工具。
• 依赖数据：套餐、成员状态、额外席位、灰度开关。
• 证据位置：文件路径、函数名、测试名、错误码或文案 key。
• 当前置信度：高、中、低。
• 未验证边界：还没找到证据的情况。
• 套餐配置：默认上限从 5 改为 8。
• 邀请服务：边界判断可能自动跟随配置。
• 成员用量接口：返回的 `memberLimit` 和 `memberCount`。
• 前端成员管理页：按钮禁用、提示文案、升级入口。
• 账单页：套餐权益展示。
• 测试：边界值从 5/6 更新为 8/9，或补充额外席位测试。
• 客服 FAQ 或帮助中心：如仓库内有文案源文件，需要同步。
• 管理员后台和批量导入：确认是否绕过规则。
• 埋点和告警：事件名或属性是否依赖旧阈值。

输入示例

可以直接参考的输入材料

下面是一个安全虚构样例。它不包含真实公司、真实邮箱、手机号、密钥、客户名称或生产地址。

这个输入保留了定位所需的信息：错误码、接口路径、业务关键词、目录线索和测试线索。真实使用时，如果页面截图里有组织名、成员名、邮箱、订单号，要先替换成虚构值。不要为了让 Codex 更好理解而粘贴完整 cookie、Authorization header 或生产日志。

目标：
请只读搜索，不要修改代码，不要安装依赖，不要启动服务。我要调查一个业务规则：基础套餐成员邀请上限为什么是 5，以及如果改到 8 会影响哪些模块。

业务问题：
产品问：基础套餐为什么邀请第 6 个成员会失败？是否可以把上限改成 8？

已知页面现象：
- 成员管理页显示 "5/5 seats used"。
- 点击 Invite member 后，输入虚构地址 user_demo@example.test，提交时弹出 "Upgrade required"。
- Network 里 POST /api/workspaces/ws_demo/invitations 返回 403。

已知接口返回：
{
  "code": "PLAN_MEMBER_LIMIT_REACHED",
  "message": "Starter plan member limit reached",
  "requestId": "req_demo_20260702"
}

业务关键词：
基础套餐、starter、basic、free、member limit、seat limit、seat、invite、invitation、quota、PLAN_MEMBER_LIMIT_REACHED、canInvite、PlanLimit、workspace members。

可能相关目录：
- apps/web
- services/api
- packages/billing
- packages/permissions
- tests/billing
- tests/invitations

已知测试线索：
我看到过一个测试文件名里有 invitation，另一个测试文件名里有 billing，但不确定具体在哪里。

请输出：
1. 规则信号清单。
2. 规则判断点和调用方。
3. 测试覆盖和缺失边界。
4. 影响模块清单。
5. 人工复核建议。

提示词

可复制使用的提示词

下面这段提示词可以直接复制给 Codex。它的重点是限制动作、强制证据化输出，并让 Codex 同时查规则条件、调用方和测试。

如果你的仓库很大，可以先让 Codex 做第一轮“关键词和候选文件索引”，确认方向后再让它继续追调用链。这样比一次性要求它读完整个项目更稳。

你是一个只读代码调查助手。请不要修改代码、不要安装依赖、不要启动长期进程、不要写入文件。你的任务是调查一个藏在代码里的业务规则，整理规则来源和影响范围。

要调查的业务规则：
[用一句话描述规则，例如：基础套餐成员邀请上限为什么是 5，以及是否能改成 8]

读者背景：
我是要修改计费、权限或审核逻辑的工程师。产品问这个限制为什么存在，但文档里没有明确说明。

已知现象：
[粘贴页面提示、按钮状态、接口返回、错误码、用户操作步骤。请先脱敏，不要包含真实邮箱、手机号、cookie、token、客户名称或密钥]

业务关键词：
[列出中文业务词、英文变量词、错误码、文案、接口路径、可能的函数名]

代码仓库信息：
[粘贴项目根目录、可能相关目录、可能相关测试目录。如果不确定，请先让你读取目录结构并列出候选]

已有测试线索：
[粘贴测试文件名、测试标题片段，或说明还不知道测试在哪里]

请按以下步骤工作：

1. 先列出你会搜索的关键词和文件类型，并说明每组关键词对应什么规则信号。
2. 只读搜索仓库，找出规则信号：常量、配置、枚举、错误码、条件判断、guard、policy、validator、feature flag、前端文案、接口返回字段、测试标题。
3. 找到最可能的规则判断点后，向上追踪调用方：页面、接口、后台工具、脚本、定时任务、测试 helper。标注哪些入口直接使用规则，哪些入口可能绕过规则。
4. 向下追踪依赖数据：套餐配置、订阅状态、成员状态、额度字段、额外席位、灰度开关、缓存、数据库查询。
5. 搜索测试文件，列出已覆盖边界和缺失边界。特别关注等于阈值、超过阈值、禁用状态、待处理状态、特殊豁免、管理员入口。
6. 输出一份业务规则索引，字段包括：规则编号、规则描述、判断条件、触发入口、依赖数据、证据位置、置信度、未验证边界。
7. 输出一份影响模块清单，按风险排序，说明如果修改该规则，哪些文件、接口、页面、文案、测试和数据口径需要检查。
8. 不要把推测写成事实。没有代码或测试证据的内容，请放到“待人工确认”里。

输出格式请包含：
- 规则信号清单
- 业务规则索引
- 调用方和入口清单
- 测试覆盖与缺失边界
- 影响模块清单
- 待人工确认问题
- 建议的下一步安全验证

输出样例

AI 应该输出到什么程度

下面是一段理想输出样例。注意，它不是最终业务结论，而是代码事实索引。示例里的路径、函数名和错误码都是虚构的。

这类输出最有用的地方，是它把“已找到证据”和“还没确认”放在同一张图上。你可以直接拿它和产品、测试、后端负责人讨论：哪些是当前系统事实，哪些是业务口径，哪些是需要补测试的风险。

规则信号清单：

S-01 套餐配置
- 位置：packages/billing/src/plan-config.ts
- 证据：starter.memberLimit = 5；team.memberLimit = 20
- 置信度：高
- 说明：这是目前找到的最直接额度来源。

S-02 错误码
- 位置：services/api/src/errors/billing-errors.ts
- 证据：PLAN_MEMBER_LIMIT_REACHED -> HTTP 403
- 置信度：高
- 说明：与接口返回一致。

S-03 后端判断点
- 位置：services/api/src/modules/invitations/invitation-policy.ts
- 函数：canInviteMember(workspaceId)
- 判断条件：activeMemberCount + pendingInvitationCount >= plan.memberLimit + extraSeats
- 置信度：高
- 未验证边界：disabled member 是否被 activeMemberCount 排除，需要继续看 members repository。

业务规则索引：

R-01 基础套餐成员邀请上限
- 规则描述：starter 套餐在 active 成员与 pending 邀请合计达到 memberLimit 时，拒绝新邀请。
- 判断条件：activeMemberCount + pendingInvitationCount >= plan.memberLimit + extraSeats
- 触发入口：
  1. POST /api/workspaces/:workspaceId/invitations
  2. apps/web 成员管理页的 InviteMemberDialog
- 依赖数据：
  - plan-config.ts 的 memberLimit
  - billing subscription 的 plan
  - extraSeats
  - invitation repository 的 pending count
- 证据位置：
  - packages/billing/src/plan-config.ts
  - services/api/src/modules/invitations/invitation-policy.ts
  - services/api/src/modules/invitations/invitations.controller.ts
  - tests/invitations/invitation-policy.spec.ts
- 置信度：高
- 未验证边界：
  - 管理员后台批量导入是否复用 canInviteMember
  - 接受邀请时是否再次检查额度
  - 旧 workspace 的 legacyPlan 是否映射到 starter

调用方和入口清单：

1. 用户邀请入口
- 页面：apps/web/src/pages/settings/members.tsx
- 组件：InviteMemberDialog
- 接口：POST /api/workspaces/:workspaceId/invitations
- 状态：直接受规则影响

2. 管理员后台添加成员
- 位置：apps/admin/src/workspaces/add-member-action.ts
- 发现：调用 adminAddMember，暂未看到 canInviteMember
- 状态：可能绕过规则，需人工确认是否设计如此

3. 批量导入脚本
- 位置：scripts/import-members.ts
- 发现：只检查 workspace 存在和 email 格式，未看到套餐额度判断
- 状态：高风险待确认

测试覆盖与缺失边界：

已覆盖：
- starter 计划达到 5 个 active 成员后拒绝新邀请。
- starter 计划 4 个 active 成员时允许邀请。
- team 计划使用 20 个上限。
- extraSeats = 2 时允许 starter 达到 7 个成员。

缺失或不明确：
- pending invitation 是否计入上限只有 service 测试，没有 controller 测试。
- disabled member 是否排除，测试未覆盖。
- 管理员后台添加成员是否绕过规则，未找到测试。
- 接受邀请时如果额度已满，是否阻止转 active，未找到测试。

影响模块清单：

高风险：
1. packages/billing/src/plan-config.ts
   如果只改 starter.memberLimit，后端主规则可能自动变成 8，但需要确认缓存和前端展示。
2. services/api/src/modules/invitations/invitation-policy.ts
   规则依赖 active + pending 计数，改阈值后需跑 invitation-policy 测试。
3. apps/web/src/pages/settings/members.tsx
   页面展示 5/5 seats used 依赖 billing usage 接口，需确认是否硬编码。
4. apps/admin/src/workspaces/add-member-action.ts
   可能绕过额度规则，需确认是否产品允许。

中风险：
5. apps/web/src/i18n/billing.zh-CN.json
   存在 "Starter plan allows up to 5 members" 文案，改到 8 时需同步。
6. tests/invitations/invitation-policy.spec.ts
   需要把 5/6 边界更新为 8/9，并补 pending invitation 边界。

待人工确认问题：
- 基础套餐成员数是否包含 pending invitation？
- extraSeats 是否仍然适用于 starter 套餐？
- 管理员后台绕过额度是特意设计，还是历史遗漏？
- 接受邀请时额度已满是否应该失败？
- 客服和帮助中心是否有独立文案源，不在当前仓库内？

建议的下一步安全验证：
- 只运行 invitation-policy 单测和成员邀请 controller 单测。
- 本地用测试数据验证 7 人、8 人、9 人三个边界。
- 找产品确认新规则是“上限改为 8”，还是“基础套餐默认 5，可赠送 3 个额外席位”。

人工验收

人要怎么检查和改到可用

Codex 的规则索引只能作为调查结果，不能直接当业务决定。拿到输出后，建议按下面顺序人工检查。

第一，检查证据位置是否真的指向生产路径。很多仓库里有 demo、fixture、mock、storybook、老版本迁移脚本和测试 helper。Codex 可能搜到了 `starter.memberLimit = 5`，但这个配置只用于测试数据生成；也可能搜到了旧文案，但线上已经从接口动态返回。你要打开文件，看 import 路径、构建配置和运行入口，确认它是否真的被产品路径使用。

第二，检查条件表达式是否被简化错了。业务规则常常不是一个数字，而是一串组合条件。例如 `activeMemberCount + pendingInvitationCount >= plan.memberLimit + extraSeats`，Codex 可能总结成“超过 memberLimit 就拒绝”。这句话少了 pending invitation 和 extraSeats，就会误导后续改动。人工复核时要把实际判断条件原样抄到索引里。

第三，检查调用方是否完整。至少要看用户主入口、服务端接口、管理员后台、批量脚本、定时任务和接受回调。不是每个系统都有这些入口，但凡有，就要确认是否复用同一套规则。特别是权限和审核规则，后台工具经常有特殊通道；这可能是设计，也可能是漏洞，不能让 Codex 自己判断。

第四，检查测试是否真的断言了规则。测试标题写“reject over limit”不够，要看断言里是否检查了正确错误码、正确状态码、正确边界值。测试里如果只 mock 了 `canInviteMember` 返回 false，并没有覆盖真实计数逻辑，就不能算规则本身已被测试保护。

第五，检查文案和接口口径是否一致。页面写“最多 5 位成员”，接口按 active + pending 计算，账单页按 active only 展示，这种不一致会造成用户困惑。改规则时不仅要改判断，还要同步使用同一口径展示。

第六，检查缓存和异步数据。额度类规则常见问题是“页面显示还有名额，提交时被拒绝”，原因可能是前端用缓存，后端实时计算；也可能是后端用用量快照，定时任务延迟刷新。Codex 可以帮你找到缓存字段和刷新任务，但你要用本地复现或日志确认实际行为。

第七，确认业务口径。代码只能说明“当前系统如此运行”，不能说明“规则为什么存在”或“是否应该改变”。如果产品问“为什么是 5”，你可以回答“代码证据显示当前上限来自套餐配置，最早可追到某个配置和测试；没有在仓库里找到明确业务原因”。不要把代码现状包装成产品理由。

如果要进入修改阶段，建议把改动拆成三步：

这个顺序可以避免“功能改了，测试还证明旧规则正确”的尴尬，也能让代码审查更容易。

1. 先补或更新测试，覆盖新旧边界。
2. 再改规则配置或判断逻辑。
3. 最后同步前端展示、错误文案、帮助说明和变更说明。

失败反例

这些失败反例要提前避开

**反例 1：只搜数字，不搜业务词和错误码。**

工程师想查“为什么上限是 5”，于是让 Codex 搜索 `5`，得到几十个结果：分页大小、星级评分、重试次数、CSS 间距、测试数据、mock 工厂。最后它挑了一个看起来像配置的 `MAX_MEMBERS = 5`，但这个常量只用于 storybook 示例，不影响生产接口。正确做法是把数字和业务词组合起来搜，例如 `memberLimit`、`seat limit`、`PLAN_MEMBER_LIMIT_REACHED`、`canInvite`、`starter`，再让 Codex 按证据类型归类。

**反例 2：只看前端禁用按钮，就以为规则在前端。**

成员页按钮在 5/5 时变灰，Codex 找到 `disabled={usage.memberCount >= usage.memberLimit}`，于是输出“规则在前端组件里”。但后端邀请接口还有一层 `canInviteMember`，真正拒绝发生在服务端。前端只是提前提示。如果只改前端，用户看到按钮可点，但提交仍然 403。正确做法是同时追展示层和校验层，明确哪个是用户体验，哪个是强制规则。

**反例 3：把测试里的旧规则当成当前规则。**

Codex 找到一个三年前的测试 `starter allows five members`，就断言基础套餐上限是 5。后来人工检查发现当前配置已经改成 8，但旧测试文件被跳过，或者属于 legacy billing 模块。正确做法是检查测试是否仍在当前测试命令里运行，测试引用的模块是否仍被生产路径使用，不能只凭测试标题下结论。

**反例 4：忽略特殊入口，导致影响范围漏掉后台工具。**

用户邀请接口复用了额度规则，但管理员后台的“代客户添加成员”直接写数据库。Codex 如果只沿着用户页面追链路，会输出“改配置即可”。上线后客服仍能通过后台加到超过上限，账单页和成员页出现不一致。正确做法是让 Codex 搜索所有创建成员、接受邀请、导入成员的入口，并标注哪些入口可能绕过规则。

**反例 5：把代码事实写成业务理由。**

Codex 输出“基础套餐最多 5 人是为了控制成本”。但仓库里只有配置、测试和错误码，没有任何成本说明。这种解释听起来合理，却没有证据。正确写法应该是：“代码事实显示 starter.memberLimit 当前为 5；仓库内未找到业务原因说明；是否因成本、定价或历史合同限制，需要产品或商业负责人确认。”

主题边界

它和相邻主题的区别

这篇文章和“让 Codex 找出前端页面、接口和启动命令的对应关系”很像，但关注点不同。入口梳理的目标是从一个 URL 找到路由、组件、接口和服务端 handler，重点是链路定位；本文的目标是从一个业务限制找到规则条件、数据口径、调用入口、测试边界和影响模块，重点是判断条件和边界。

如果你的问题是“这个页面报错对应哪个接口”，应该先做入口梳理。你要知道页面在哪里、接口在哪里、本地怎么跑。等入口清楚后，如果进一步发现报错来自某个计费、权限或审核判断，再进入本文的方法，调查这个判断为什么存在、依赖哪些数据、改动会影响哪里。

它也和“README 和脚本说法不一致时，先让 Codex 建事实清单”不同。事实清单处理的是文档、脚本、CI、部署记录之间的说法冲突；本文处理的是代码内部的业务规则。前者更关注材料来源和时间线，后者更关注条件表达式、调用方、测试覆盖和边界值。

它还不同于让 Codex 直接改规则。直接改规则通常从“把 5 改成 8”开始，风险是漏掉前端文案、测试边界、后台入口和缓存口径。本文是在改动之前做规则索引，目的是让你知道该改哪里、不该改哪里、还有哪些必须找人确认。对于计费、权限和审核逻辑，这个前置步骤往往比直接写代码更省时间。

最后，它比一般的“代码搜索”更业务化。普通搜索关心文件在哪里，规则调查关心为什么这个条件会触发、哪些用户会被挡住、哪些入口会绕过、哪些测试保护了边界。让 Codex 做这件事时，一定要让它输出证据表，而不是输出一段看似顺畅的业务解释。顺畅不等于准确，能被复核才有用。