用AI分析需求变更，先把“旧规则、新规则、生效范围”写成一条明确差异，再让它沿业务规则、页面状态、数据使用方和测试场景逐层寻找影响。不要直接问“这个需求会影响哪些功能”：没有版本和范围的材料，容易得到一张什么都要改的清单，也容易漏掉历史申请与上线前后的边界。
材料分散在本地PRD、接口说明和测试文档时，可以用墨刀AI客户端结合项目文件分析变更，指定要读取的文件并先生成影响报告。下面以“采购申请免审批阈值从5000元改为3000元”为例，说明怎样把一句需求整理成明确的修改范围，而不是立即让AI改完整项目。
同一句“阈值改成3000”，可能代表不同变更
“5000改3000”没有说明边界值，也没有说明申请何时适用新规则。小于3000免审批，和小于等于3000免审批，在恰好3000元时会得到相反结果。按创建时间生效，和按提交时间生效，也会影响不同的草稿。
先把本例约定写完整：旧规则为“含税人民币金额不超过5000元的采购申请可免审批”，新规则改为“不超过3000元可免审批”；金额超过阈值时进入部门审批；示例生效点为某次发布日的上午9点，按首次提交时间判断。上线前已经提交的申请继续沿用原规则，尚未提交的草稿使用提交时的规则。这是用于讲解的业务约定，实际项目应由规则负责人确定。
于是，变化的不是单独一个数字，而是“哪些申请进入审批”这个集合。3000元仍免审批，3000.01至5000元从免审批变为审批，5000.01元以上原本就需要审批。这个区间能同时指导界面、后端和测试，不必让每个角色再猜一次。
先准备两版规则和真正使用它的材料
把相关文件放到一个清楚的项目目录。可以保留旧版原件，再增加变更说明；不要提前把所有文档里的5000替换成3000，否则AI难以区分原规则与已修改内容。金额5000也可能只是报表示例或无关费用，不能全局替换。
采购阈值调整/
├─ 规则现状.md
├─ 变更说明.md
├─ 页面说明.md
├─ 申请字段说明.md
└─ 现有测试用例.md页面说明至少覆盖申请表单、提交结果、待审批列表和申请详情；字段说明解释金额单位、首次提交时间、申请状态与审批结果。若团队已有需求、页面和测试的追溯矩阵，把相关行一并提供，能减少从零寻找关联的工作。但矩阵只告诉你“有关联”，并不自动说明这次关联是否真的需要改。
文件不完整时，先列出缺了什么。例如只拿到表单原型，没有服务端规则或配置说明，就能判断提示文案的影响，却不能确认后台是否只改一个配置项。把缺失范围保留在报告里，后续补充相应材料，不要让AI把未知部分补成实现事实。
让AI分两轮找影响，不要一次生成全部改动
第一轮只提取差异和原有依赖。下面这段指令可以配合上述五份文件使用：
读取“规则现状.md”和“变更说明.md”，先列出旧规则、新规则、金额口径、边界值、生效时间以及新旧申请的适用范围。再阅读其余文件，找出实际依赖免审批阈值的页面、状态、字段和测试。每条说明文件名及对应章节，区分明确依赖、可能相关、材料不足。找不到的内容保持未知。先输出报告，不修改文件。
检查第一轮时，重点看它是否保留“不超过”的含义，以及是否把“首次提交时间”误写成“创建时间”。如果这两处错了，后面的影响分析即使很详细，也在分析另一项需求。
第二轮再沿已识别的依赖追踪下游，不重复让AI从头概括整个系统：
依据刚才确认的规则，逐条分析阈值变化如何影响申请表单、提交结果、待审批列表、申请详情和现有测试。对每项写明触发条件、当前行为、需要的新行为、影响的新旧申请范围，以及仍需谁确认。区分必须修改、仅需回归、无需变化；不能因为出现“金额”一词就判定需要修改。补充生效前后提交、边界金额和重复提交的场景。
两轮的区别很实际：第一轮解决“规则在哪里被用到”，第二轮解决“这一次使用方式是否要变”。没有依赖依据的推测可以成为询问线索，但不应直接进入开发任务。
把影响分成必须修改、仅需回归和不变三类
下面是按本例规则可整理出的影响表。它是示例项目的分析结果，不代表所有采购系统都采用同一种实现方式。
| 对象 | 本例应如何处理 | 理由与待确认处 |
|---|---|---|
| 免审批判断规则 | 必须修改：上线后首次提交，金额≤3000免审批 | 服务端如何存储规则需看实现；前端显示不能替代业务判定 |
| 申请表单说明 | 必须修改：提示新阈值；提交前说明将进入的流程 | 旧草稿恢复时也要显示本次提交适用的规则 |
| 提交结果与申请详情 | 必须核对并按需修改：3500元新单应显示待审批 | 若原来已经根据返回状态展示，可能仅需回归，不需改组件 |
| 待审批列表 | 至少回归：新增加的3000.01—5000元申请应出现 | 不要因为列表本身没改，漏掉新进入该列表的申请 |
| 已提交或已结束的旧单 | 保留原规则，不批量改写历史结论 | 若业务要求追溯重审，这是另一项迁移需求，不能暗中包含 |
| 审批量报表 | 核对统计含义与说明，未必修改计算 | 审批量增加可能来自政策变化，不能直接解读为业务量增长 |
| 供应商名称、收货地址 | 无需变化 | 本例没有改变字段含义或流程依赖 |
“仅需回归”很重要。如果申请详情本来就根据服务端返回的状态展示，规则变化不一定要求重做页面。把所有相关对象都写成修改任务，会扩大工期，也让真正需要变更的地方失去重点。反过来，没有代码差异也不等于不用测试；待审批列表就是典型例子。
历史申请和上线时刻最容易让范围失控
本例的草稿创建于上线前，却在上线后第一次提交，适用新规则。已经提交的申请不会因为页面刷新就改变审批结论。为此，分析报告应明确“首次提交”如何记录；如果现有字段只能记录最近修改时间，不能直接假设它足够区分新旧规则。
还要追问一次退回后的重新提交属于旧申请继续处理，还是重新适用当前规则。本例先不替业务做决定，单列为待确认。若金额从2800元改为3600元，是否重算审批路线尤其关键；它涉及新的条件变化，不能只看原申请时间。
另一个边界是发布过程中的重复请求：用户9点前提交，因网络超时9点后再次点击，第二次请求是否仍属于同一次业务提交？需求分析应提出这个问题，让研发结合已有幂等机制回答，避免文档一边写“旧单沿用”，界面却在重试后给用户一个不同结论。
多币种、未税金额或金额精度如果存在，也应独立说明。本例统一使用含税人民币，不在同一项变更里顺手引入汇率换算。新增币种支持、历史申请迁移、审批人组织调整，都是可能相关但不能自动并入的范围。
用一组具体申请确定回归范围
先覆盖会改变结论的区间，再覆盖保持不变的两端。下面的金额都按人民币元计，生效点用 T 表示。预期结果来自本例约定，不是对真实系统的测试结论。
| 申请场景 | 预期路线 | 重点看哪里 |
|---|---|---|
| T后首次提交，2999.99元 | 免审批 | 提交结果与详情一致 |
| T后首次提交，3000元 | 免审批 | “不超过”的等号没有丢失 |
| T后首次提交，3000.01元 | 进入部门审批 | 表单提示、审批列表、详情状态 |
| T后首次提交，5000元 | 进入部门审批 | 旧阈值不能残留在其他入口 |
| T前已提交，3500元 | 继续沿用原结论 | 刷新详情、查询历史记录不改变结果 |
| T前创建草稿，T后首次提交，3500元 | 进入部门审批 | 依据提交时刻，而非创建时刻 |
| 首次提交超时后重试 | 按同一业务提交约定处理 | 不重复创建申请；跨T的处理由研发确认 |
再选一笔5000.01元申请确认原本需要审批的路线没有被破坏；选一个未修改的地址字段确认表单没有被全局替换误伤。完整回归范围来自这些具体差异，而不是让AI泛泛列“正常、异常、边界”三个词。
最终留下一份能分派的变更说明
分析完成后，把结论整理成下面这张简表，按实际项目补上页面、文件或任务地址。开发可以据此领取范围，测试可以找到预期行为，产品也能清楚看见还没决定的部分。
变更：采购免审批阈值 5000 → 3000 元
范围：含税人民币；按首次提交时刻适用
必须修改：规则阈值、表单提示、相关说明
仅需回归：状态驱动的详情、审批列表、旧单查询
不在本次：历史申请重审、多币种、审批人组织调整
待决定：退回改金额后是否重新计算审批路线
待确认：跨生效点的超时重试如何认定首次提交
任务：每项附对象位置、预期变化与负责角色
测试：边界金额、新旧单、草稿和重试场景若需要继续用墨刀AI客户端协助修改文档，下一次指令应限定到已经确认的文件和段落，并保留原版供比较；先处理本次变更说明，再决定是否更新PRD和测试材料。需求影响分析的价值，在于把该动的地方找全，把不该顺带改变的地方划清。一个数字的变化，最终应该得到一份可解释的范围，而不是一长串无人能确认的修改建议。
