生成重构文档

围绕用户指定的页面及其直接调用的接口，以本地 Markdown 文档交付。可读取项目源码、已有文档和用户提供的验证证据。业务代码实施、测试执行、部署和外部文档发布超出此技能范围。与页面迁移无关的纯后端工作按项目自己的流程处理。

范围与文档组织

以用户确认的本次迁移业务范围为总锚点，页面、端和项目用于定位内容与实施责任；适用于单页面及多页面、单项目及多项目。业务范围只含指定目标、页面、直接接口及必要交接链路，不扩展为整个业务域。按内容职责拆分文档，保持已确认的迁移范围。

涉及文档集合或目录设计时，读取Markdown 文档组织；涉及内容分配或共享说明时，读取文档归属与同步。只生成用户要求的交付物，不因推荐层级补建整套资料；按已确认的文档目录树在用户授权的本地位置创建子目录和 Markdown 文件。

选择迁移范围

迁移范围与交付类型分别选择。依据用户已给的页面、接口及项目限定，记录本次修改对象、仅依赖项目、保留消费者、必要交接和验收停止点；不因要写方案就默认全栈。范围不明时先核对已有证据，只询问会改变任务归属或实施/验收边界的缺失信息，不重复确认已给范围。

页面关联须由任务范围、消费关系或证据确定；不能把任意后端任务归入本技能，也不能因前端不改就排除页面相关后端任务。关联不明时先问消费页面或迁移链路。只生成所选交付物，按上述范围裁剪文档、章节和验收；裁剪不豁免实际契约、旧消费者兼容、权限、副作用或已确认业务结果。缺少这些依据时保留具体缺口，不以“不改该端”记不适用。其他端需要修改才能满足目标时报告范围冲突及依赖，不自行扩展。

选择交付模式

按用户要求选择交付物，只读取对应指导及涉及问题的小节。

共用证据与边界

迁移重构不得额外添加业务逻辑；只有用户明确要求新增或改变业务逻辑时，才纳入重构范围。方案、审查和测试均按此约束核对。

取证与方案遵循以下尺度，具体方法按后文引用读取：

• 取证有终点：围绕具体结果补证，已有证据足以判定即停止；证据仅适用于对应版本和环境，局部未知只限制相关结论，确实影响兼容结果时仍须补齐。
• 实现条件不等于需求：以确认目标和边界反例筛选路径，区分路线前提与业务要求；不无据认定必须新增或保证复用，也不为可避免的机制制造业务选择。
• 最小完整方案：先核实际消费者、既有契约和完整调用链，再判断复用、新增或删除；本页未使用不授权删除公共字段。保留兼容、安全、权限及异常核查，按实际变更及关联影响复核。

旧行为与目标：旧代码证明迁移前现状，已落地代码证明实际实现；两者都不能自行证明目标需求已获确认。用户明确“只迁移”或“沿用旧逻辑”时，查明的旧行为是目标兼容基线；来源不足、互相冲突或确需改变的规则，列出具体待确认项及影响。Bug 的成立、修复对象与实施状态分别记录；修复须已获确认且目标口径与实际兼容影响明确。登记 Bug 或其他消费方不自动授权改造，按Bug 文档指导确定修复与验收范围。

目标来源：规划迁移前文档时，不用本次迁移的已落地代码、测试、方案或变更规格填补目标决策；目标项目与本次迁移无关的通用约定可作为技术依据。用户要求整理已落地结果时，应读取实际改动并标明实施状态。

历史用例：历史测试用例只是待核对的线索；与已核实的旧行为冲突时，先核实争议分支，再按已确认的目标决定是否改变行为，不能用旧用例覆盖兼容基线。

产品与技术：产品文档只写业务条件、用户操作、准确的可见文案与结果，不写 Bug、问题编号或修复过程；代码证据和实施差异放在现状梳理或开发方案；内部错误码、接口字段、技术映射及 Bug 内容按下述文档归属维护，不进入产品正文。

变更与错误码契约：迁移方案不能替代项目要求的需求或变更契约。方案与审查须核对旧错误码是否仍被页面、公共请求层或其他调用方用于特殊业务动作，并保留其语义或说明兼容映射；详见对应参考文件。

生成初稿前，按初稿前关键取证核对项目归属、操作差异、必要提供方契约和页面资源；复用已有证据，不为检查另建交付物。

涉及动态展示、计算、输入处理、字段类型、员工权限、错误消费或跨页交接时，按取证指导读取相关小节。

涉及首次初始化、后续请求、异步弹框或单项位置排序时，按页面状态与交互读取相关小节；产品交付只提取用户可见规则。

按任务规模决定是否委派前端、后端或测试视角：能独立取证且需要独立复核时才委派；小任务由主 Agent 依次检查。主 Agent 负责跨端契约一致性及最终交付，不把自己的复核称作独立审查，也不安排多个 Agent 同时编辑同一交付物。

文档表述与歧义处理

适用于本技能生成或更新的所有文档。说明性文字须让读者明确本次范围内的主体、条件、动作和结果；已确定规则不能因表述省略而产生不同的实现或验收判断。

• 同一概念统一称谓，代词、简称和“相关”等指代须能定位具体对象及范围。多条件写清“同时满足”或“任一满足”，多分支分别写结果；有业务影响的数量、时间、顺序及边界写明判断口径。
• “正常”“及时”“适当”“必要时”“默认”“按原逻辑”等词不能替代具体规则。“成功”“刷新”“空值”等存在多种含义时，写清本条指哪一种；例如“空值”须区分字段缺失、null、空字符串及空白文本，不能自行合并。
• 先用已有证据和有效决定消除歧义；仍缺事实或决策时，列出具体问题、已知部分及受影响的行为或验收范围，分别标待核实或待确认。仅缺运行验证的标待验证；不猜测阈值、默认行为或文案，也不把已确定部分一并降为未知。
• 用户可见文案、字段名、枚举值及引用原文保持准确，不按模糊词名单改写。原文本身有疑义时，在说明中交代其含义或待确认点；修改原文仍须有对应依据和授权。

交付前按表述歧义检查逐条复核，不能以关键词扫描代替语义判断。

文档归属与同步

只更新用户已授权且受本轮内容影响的文档；新证据与决定归入对应主题，替换失效说明，未获授权的关联文档列待同步。技术变化不要求机械同步全部篇。

生成、更新或正式审查文档时，按完整归属与同步规则确定主描述、摘要和引用。需求与接口仍须各自独立可用；归并保留独有信息、稳定编号、锚点及原引用语义。

Markdown 交付与验收

按Markdown 交付生成或更新本地 .md 文件。交付前回读正文与相对链接，按文档审查与验收区分设计缺陷、待决策、待实施验证和已接受的限制。

同一次迁移新增或修改「重构后产品 / 新接口 / 测试用例 / 开发方案」任一文档，交付前按四类文档集合交叉验收记录适用项、实际核对范围及结论；局部修改须检查关联影响，不能以固定四篇抽检或作者「已做绿场抽检」宣称整套合格。