大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



大家好，我是人月聊IT。

今天整理和分享一个完整的基于源代码项目进行AI辅助逆向工程的方案和实践，包括后续附录分享完整的参考提示词可以使用。

实际在去年我就分享过AI逆向工程，但是当时的重点是通过AI逆向设计文档，用户手册等，这些文档的目的一方面是给内部团队使用；一方面是用户项目实际的客户交付输出物。而本次分享的逆向重点是逆向一套AI能够清楚理解业务语义的参考文档和模型文件。方便后续AI再不详细阅读完整源代码的情况下快速的理解项目。

而我今年一个重点研究就是对于大型上100万行代码的存量项目，如何去逆向一条这样的语义文件。 让AI能够快速地参考这套模型去做变更，去修改Bug。里面一个核心就是语义分层和上下文压缩，这个实际是借鉴了Claude Code源代码实现的思路。如果不做这个逆向，那么面对大型项目我们修改一个Bug可能都要耗时30分钟1个小时，耗费10元，20元钱。那么这个时候AI辅助的成本和效率上都是不合适的。而有了这套逆向模型，可以让AI更加高效快速，低成本的修改Bug和变更。

在企业软件建设过程中，源码长期存在但业务知识逐渐流失，是一种非常普遍的现象。系统最初上线时，往往有较完整的需求文档、概要设计、接口文档和数据库设计说明；但随着多轮迭代、团队更替、架构演进、项目并行复制和紧急需求插入，这些文档很容易逐步失真。最终留下的“真实系统说明书”只剩源代码本身。

对于大型 Java 微服务项目来说，这个问题尤其突出。一个项目可能同时包含网关、主业务服务、分发服务、安全服务、大量领域模块、前端页面、配置中心、消息队列、工作流和调度器。单纯依靠人工通读代码，成本极高，且很难快速还原系统真正的业务结构。

传统逆向方法通常有三类。第一类是人工阅读源码，从包结构、控制器、服务、数据库脚本一点点梳理。这种方式可靠但慢，对人员经验依赖很强。第二类是静态扫描和 UML 类图生成，能够帮助理解依赖关系，但很难抽取真正的业务语义。第三类是让大模型直接“读源码然后总结”，这种方式虽然快，但如果缺少约束，结果很容易退化成源码摘要、菜单罗列或控制器清单，无法沉淀为可复用的业务知识模型。

因此，真正的问题不是“AI 能不能读代码”，而是“如何让 AI 以稳定、低漂移、低噪声的方式，从源代码中提取系统级业务语义，并把结果沉淀为可持续复用的知识结构”。这也是本方案的出发点。本文所总结的 Reverse 方法论，就是围绕这个问题构建的一套提示词体系、执行流程、结构化产出规范和交叉验证机制。它的目标不是让 AI 生成一份给人看的泛化总结，而是让 AI 形成一组适合 AI 持续阅读、引用、补全和演化的逆向文档。

这套方案的核心目标可以概括为三句话。

第一，从“源码细节阅读”切换到“业务语义建模”。逆向的重点不是某个方法怎么实现，不是某个 Mapper SQL 写得多复杂，也不是某个工具类用了什么框架技巧，而是系统服务于哪些核心业务场景，系统有哪些核心能力，哪些服务和模块负责这些能力，这些能力通过哪些接口和数据对象落地。

第二，从“单轮总结”切换到“多文档结构化产出”。一份长篇总结很快就会失效，也很难让后续 AI 稳定复用。相比之下，按架构、业务语义、数据库、功能、接口、映射、术语归一、开放问题等多个维度拆分的 YAML 文档，更适合作为 AI 的中间知识表示。

第三，从“自由发挥”切换到“强约束执行”。AI 的问题不是能力不够，而是没有稳定边界时容易漂移。因此，需要一套前置约束文件明确输出字段、ID 规范、枚举值、引用关系、术语归一、执行顺序、检查规则和终止条件，让不同轮次、不同模型、不同代理都能按同一框架完成逆向。

基于上述目标，这套方案采用了“索引优先、最小上下文、渐进下钻、场景驱动、结构化输出、开放问题收敛”的总体策略。它不要求 AI 通读整个仓库，而是要求 AI 先扫描高价值入口文件，建立候选池和系统骨架，然后只围绕核心场景去验证功能、接口、表和服务的关系，最后把无法闭合的问题集中沉淀为开放问题，而不是在各处散落“待确认”。

当前项目 reverse 目录下的方法论已经形成了比较完整的体系，可以分为五层。

第一层是总控层，用来规定逆向的总体方向和执行原则。代表文件包括 0_Reverse_Master_Prompt.md 和 0a_Reverse_Fast_Scan_Prompt.md。总控层回答的是“逆向什么、不逆向什么、先做什么、后做什么、什么时候停止”。

第二层是约束层，用来降低输出漂移。代表文件包括 0b_YAML_Schema_Contract.md、0c_Semantic_Aliases_Template.md、0d_Open_Questions_Template.md。这一层回答的是“YAML 应该长什么样、术语如何归一、未决问题怎么收敛”。

第三层是执行层，用来标准化整轮逆向流程。代表文件包括 0e_Reverse_Execution_Playbook.md、0f_Reverse_Output_Templates.md、0g_Reverse_Review_Checklist.md、0h_New_Project_Starter_Kit.md。这一层回答的是“按什么顺序推进、每一步输出什么、如何自检、如何作为新项目启动包使用”。

第四层是任务层，对各个子对象分别建模。代表文件包括 1_Reverse_Tech_Arch_Prompt.md、2a_Reverse_Business_Semantics_Prompt.md、2_Reverse_DB_Design_Prompt.md、3_Reverse_Func_List_Prompt.md、4_Reverse_API_List_Prompt.md、6_Reverse_Mapping_Prompt.md、5_Reverse_Consistency_Check_Prompt.md。这一层回答的是“如何提取架构、业务语义、表、功能、接口以及跨对象主链路”。

第五层是样例层，用来告诉 AI 一个最小闭环的结果应该长什么样。代表目录是 reverse/example/。样例层并不是装饰，而是降低大模型首次产出不稳定的重要工具。相比只给规则，给出一套可互相引用的最小样例，更容易让 AI 进入正确输出轨道。

4.1 语义优先，而不是源码摘要

AI 最常见的失败方式，是把逆向做成“控制器列表 + 方法说明 + 数据表罗列”。这种输出看起来很多，实际上业务价值很低。真正有价值的逆向结果，应该先回答业务问题：系统解决什么问题，系统有哪些核心域，哪些场景是主链路，哪些能力是平台核心，哪些接口是真正的业务入口，哪些表是关键数据锚点。

4.2 索引优先，而不是全仓通读

大型微服务系统的复杂性不在于“某个类很复杂”，而在于“候选入口太多”。所以第一步必须建立索引。网关配置、应用配置、启动类、Swagger、Controller、FeignClient、Listener、DDL、Entity、Mapper、前端 API 定义，这些比通读 ServiceImpl 更重要。先有全局索引，再决定要补读哪些文件，才能控制逆向成本。

4.3 场景驱动，而不是菜单驱动

很多系统都有复杂前端菜单，但菜单结构不等于业务结构。一个“新增”“导出”“分页查询”按钮，不应该直接成为一级功能。正确的做法是以业务场景为核心，例如“数据 API 发布开放”“外部系统接入与分发”“敏感数据识别与扫描”“主数据配置与资产治理”。页面和菜单只作为证据，帮助定位场景入口，而不是替代场景建模。

4.4 结构化优先，而不是自然语言堆砌

这套方案最终产出的是一组 YAML 文档，而不是一篇口语化长文。原因很简单：自然语言总结难以进行交叉引用，也不利于后续 AI 按对象补齐。结构化文档至少带来三个好处。其一，所有对象都有稳定 ID；其二，跨文件关系可以用 _id 和 _ids 建立；其三，后续任何补充都能增量回填，而不必重写整篇文档。

4.5 收敛不确定性，而不是掩盖不确定性

逆向不是证明自己“全都知道”，而是要清楚区分“已确认”和“待确认”。因此方案要求每个对象都有 status 和 confidence，并要求关键未决问题集中进入 open_questions.yaml。这样做的结果是，系统知识并不是非黑即白，而是能够持续迭代演进。

5.1 快速扫描阶段

第一步不是建模，而是建立候选池。使用 0a_Reverse_Fast_Scan_Prompt.md 后，AI 会优先扫描根目录结构、子模块、pom.xml、配置文件、启动类、控制器、Entity、Mapper、前端 API 定义等高价值入口，然后输出 scan_candidates.yaml。这个文件不是最终成果，而是一个候选池，通常包括服务候选、业务域候选、场景候选、功能候选、接口候选、表候选、实体候选，以及下一轮最值得补读的文件。

快速扫描阶段的关键不是“找到全部”，而是“找到高价值入口”。只要候选池足够支撑下一轮骨架建模，就应该进入下一阶段。

5.2 系统骨架阶段

第二步使用 1_Reverse_Tech_Arch_Prompt.md 产出 archetype.yaml。这个文件的作用，是把系统分成服务、模块、组件、集成关系和运行机制几个层次。对于微服务项目来说，这一步非常关键，因为很多业务能力并不对应一个独立服务，而是作为模块嵌入主服务。只有先把服务和模块边界建起来，后续功能、接口和表的归属才不会混乱。

5.3 业务语义阶段

第三步使用 2a_Reverse_Business_Semantics_Prompt.md 产出 business_semantics.yaml。这是整套体系最核心的文档。它要回答五个问题：有哪些业务域、有哪些能力、有哪些核心场景、有哪些核心实体、有哪些关键业务规则。业务域决定“系统按什么业务边界来理解”，能力决定“系统能做什么”，场景决定“业务流程怎么启动和结束”，实体决定“业务对象是什么”，规则决定“系统有哪些强约束”。

5.4 数据模型阶段

第四步使用 2_Reverse_DB_Design_Prompt.md 产出 database.yaml。这里不是做数据库全量设计说明，而是识别核心业务表、关系表、配置表、日志表和调度表，并给出表的归属、实体映射、关键关系和证据来源。对 AI 来说，数据库表是最稳定的数据锚点之一，很多模糊业务语义最终都需要落到表上。

5.5 功能与接口阶段

第五步和第六步分别使用 3_Reverse_Func_List_Prompt.md 和 4_Reverse_API_List_Prompt.md，产出 functions.yaml 和 apis.yaml。功能模型强调“做什么”，接口模型强调“怎么进入”。一个功能可以对应多个入口，一个接口也可能只是某个功能的一部分。把两者分开建模，能有效避免“接口=功能”的误判。

5.6 Mapping 映射阶段

第七步使用 6_Reverse_Mapping_Prompt.md 产出 mappings.yaml。这是整套方案中第二个最关键的文档。它要求把场景、功能、接口、服务、表串成 step 级主链路。与摘要式流程说明相比，step 级结构更适合后续 AI 推理。AI 可以直接回答某个场景由哪个接口触发、哪个服务执行、读写了哪些表、产生了什么事件，避免再次从源码中做临时拼接。

5.7 一致性检查阶段

最后一步使用 5_Reverse_Consistency_Check_Prompt.md 和 0g_Reverse_Review_Checklist.md，做结构、引用、主链路、术语归一和证据质量检查。这里的重点不是语法正确，而是模型正确。例如是否存在悬空 ID、是否同义对象重复建模、是否每个核心场景都能落到至少一个明确数据对象、是否有大量低置信度对象没有进入开放问题清单等。

6.1 统一 Schema Contract

0b_YAML_Schema_Contract.md 的作用，是把所有输出变成“受约束的对象集合”。如果没有这个文件，不同模型、不同轮次很容易出现字段漂移、命名不统一、引用风格不一致的问题。一旦字段不稳定，后续 AI 很难把这些 YAML 当成长期知识库来使用。Schema Contract 本质上是在给逆向输出做数据建模。

6.2 术语归一机制

企业系统里最容易出现的知识噪声，不是事实错误，而是同义对象多套命名。比如“开放 API”“能力开放服务”“对外接口”“开放能力”，它们可能指向同一个业务对象。semantic_aliases.yaml 的作用，就是建立标准术语、同义词、历史命名和禁止混用词的映射关系。这样一来，AI 在多轮输出时就不会把同一对象拆成多套模型。

6.3 开放问题清单

open_questions.yaml 是整套体系里非常实用但常被忽视的部分。它把“当前无法确认但影响较大”的问题集中管理起来。这样做的好处有三个。第一，避免各个文件里到处出现“待确认”；第二，明确下一轮该补读哪些文件；第三，让逆向结果具备演化性，而不是假装一次性完成。

6.4 step 级 Mapping

很多逆向文档会写“系统先创建任务，再调用接口，最后写表”，这类描述对人看够用，对 AI 则太模糊。step 级 scenario_chains 则把它显式拆开：第几步、哪种动作、由哪个 API 触发、对应哪个功能、归属哪个模块、读写哪些表、产生什么事件。这样 AI 就能把主链路当作可推理结构，而不仅是文本说明。

6.5 Review Checklist

逆向结果最大的问题往往不是“没写”，而是“看似写了，其实不稳”。检查清单的价值在于用一组短问题，强制回看结果质量。比如是否先有 scan_candidates.yaml，是否每个核心场景都有主功能，是否 reverse_index.yaml 真能作为入口，是否主链路可以解释“谁触发、谁执行、影响什么数据”。这些问题很简单，但非常有效。

为了便于实际使用，可以把当前 reverse 目录下的提示词按职责理解为如下分工。

0_Reverse_Master_Prompt.md 负责总控编排，定义目标、边界、执行顺序和统一输出。

0a_Reverse_Fast_Scan_Prompt.md 负责快速扫地形，建立候选池，不让 AI 一上来就全量递归源码。

0b_YAML_Schema_Contract.md 负责输出结构约束，是所有 YAML 的最高格式标准。

0c_Semantic_Aliases_Template.md 负责术语归一，解决同义对象重复建模问题。

0d_Open_Questions_Template.md 负责开放问题收敛，让不确定性有统一容器。

0e_Reverse_Execution_Playbook.md 负责执行流程说明，规定逆向推进的顺序和停止条件。

0f_Reverse_Output_Templates.md 负责最小产出模板，帮助 AI 直接按模板填充。

0g_Reverse_Review_Checklist.md 负责结果自检，避免把低质量结果继续传递。

0h_New_Project_Starter_Kit.md 负责新项目启动场景，便于把整个方法论打包给另一个 AI 代理。

1_Reverse_Tech_Arch_Prompt.md、2a_Reverse_Business_Semantics_Prompt.md、2_Reverse_DB_Design_Prompt.md、3_Reverse_Func_List_Prompt.md、4_Reverse_API_List_Prompt.md、6_Reverse_Mapping_Prompt.md、5_Reverse_Consistency_Check_Prompt.md，分别对应架构、业务、数据、功能、接口、映射和一致性检查七个建模视角。

这套分工的意义在于，把“大而笼统的逆向任务”拆成多个明确子任务。AI 并不是靠一个超级提示词完成全部工作，而是在统一规则下分阶段完成。

为了验证这套方法是否真正有效，我们在当前工作区的数据中台项目上做了一轮完整实践。该项目是一个典型的 Java 微服务加多领域模块的企业级系统，后端主体位于 dmp-backend-main，包含网关、主业务服务、数据分发服务、数据安全服务，以及元数据、数据集市、开放平台、API 开发、主数据配置、数据质量、数据标准、可视化、工作流、表单开发等多个模块。

在实践过程中，第一轮逆向并没有试图穷举所有控制器、所有表和所有菜单，而是先围绕核心链路建立最小闭环。这一轮识别了元数据治理、数据 API 发布开放、外部系统接入与分发、敏感数据识别与扫描等核心场景，并生成了一组基础 YAML 文档。随后在第二轮和第三轮中，逐步补齐了网关核心前缀、开放 API 发布到 Kong 的实际写路径、ETL 的真实 HTTP 入口、安全扫描任务执行链，以及新增大域的代表性 API、表和链路。

截至当前，docs 目录下的逆向结果已经形成较完整的结构化文档集，包括 reverse_index.yaml、scan_candidates.yaml、semantic_aliases.yaml、archetype.yaml、business_semantics.yaml、database.yaml、functions.yaml、apis.yaml、mappings.yaml、open_questions.yaml、frontend_backend_mapping.yaml 和 System_Overview.md。覆盖摘要显示，当前成果已经覆盖 10 个业务域、10 条核心场景、23 个功能、69 个代表性 API、70 张代表性数据表以及 18 个架构模块对象。

从数据中台项目的逆向结果来看，系统可以稳定收敛为 10 个主要业务域：元数据治理、API 开发与开放、数据分发与集成、数据安全治理、API 设计开发、主数据配置与资产、数据质量与清洗、数据标准治理、数据可视化、流程工作流。

在这些业务域之上，又能形成若干稳定主链路。比如“数据 API 发布开放链路”可以抽象为：内部数据 API 选择与发布、Kong route/service 元数据读取、ACL 插件挂载、开放 API 元数据落库、消费者授权同步。比如“外部系统接入与分发链路”可以抽象为：业务系统注册、API Token 配置、外部接口定义、项目创建、ETL 任务创建、上下线发布、MQ 主题或队列形成。比如“敏感数据识别与扫描链路”则体现为：敏感字段查询、规则读取、扫描任务启停、即时执行、按 ruleSet 扫描元数据字段并生成敏感记录。又比如“数据质量规则治理链路”体现为：核查规则查询、手动执行、规则模板复用、阻断记录回看、调度任务控制。

这些链路之所以重要，是因为它们证明逆向结果不是静态对象堆积，而是已经具备了“过程解释能力”。后续任何 AI 拿到这些 YAML，都可以直接回答一个场景是如何从前端页面进入、经过哪些接口和模块、最终影响哪些数据对象。

仅从后端逆向，会有两个盲点。第一，很多接口虽然存在，但并不是实际业务入口。第二，很多页面虽然不复杂，却把真正的业务组合关系暴露得更直观。因此，本次实践专门增加了 frontend_backend_mapping.yaml，把代表性页面、菜单入口与后端接口、功能、核心表建立对应关系。

例如，开放平台服务中心页面直接映射到开放 API 发布、保存和授权接口；业务系统管理页面对应业务系统主档、支持人、凭证和 API Token 表；数据质量规则页面不仅调用质量规则自身接口，还会反查 apidev 模块中的数据链路、实体和字段信息；表单设计相关组件则直接调用 /frmdev/frmvue/download，说明表单开发模块虽然不是最核心业务域，但确实参与了实际运行链路。

这类前后端反查的意义在于，它能帮助验证“哪些后端接口是真正在业务中被消费的”，也能帮助发现从后端单侧不容易注意到的组合关系。

逆向工作的最终价值，不在于产出数量，而在于结果是否稳定可信。为此，本方案设计了多层交叉验证机制。

第一层是结构交叉验证。通过 reverse_index.yaml 检查当前文档集合是否完整，文档之间是否有稳定入口，覆盖摘要是否与实际对象规模大体一致。

第二层是引用交叉验证。检查 scenario_id、function_id、api_id、module_id、entity_id、table_id 是否都能在对应文件中解析，避免悬空对象和断链关系。

第三层是术语交叉验证。对照 semantic_aliases.yaml，检查是否存在“开放 API”“能力开放服务”“对外服务”这类同义对象多套建模，或者“任务”“项目”“节点”“实例”这类层级被混用的情况。

第四层是主链路交叉验证。检查每个核心场景是否至少关联一个主功能，每个主功能是否至少关联一个接口或事件，每条主链路是否至少落到一个明确表对象。只要有场景无法落到数据对象，这条链路就不够稳。

第五层是证据交叉验证。核心对象应具备 source_evidence 或 source_indexes。如果某个对象只有名字推断，没有控制器、实体、SQL、配置或前端调用等证据支撑，就应该降低置信度，或者直接转入 open_questions.yaml。

第六层是前后端交叉验证。用前端页面实际调用去印证后端接口是否真实被消费，用后端控制器和实体去印证前端页面是否对应真实业务对象。这一步对发现死接口、边缘页面和组合场景特别有用。

第七层是开放问题收敛验证。所有重大不确定性都应该集中进入 open_questions.yaml，并给出影响范围、当前**判断和下一轮建议补读文件。一个看似完整但没有开放问题清单的逆向结果，往往意味着不确定性被掩盖了，而不是不存在。

从实践结果看，这套方案最适合以下场景：存量 Java 微服务系统业务文档缺失；系统规模较大、模块较多；需要快速让新成员或 AI 代理理解业务；希望把逆向结果沉淀为长期复用的结构化知识资产；需要在多轮迭代中逐步补齐，而不是一次性做完。

它的优势主要体现在四个方面。第一，逆向效率高，因为它不要求全仓通读，而是按高价值入口和核心场景下钻。第二，结果更稳定，因为有 Schema、术语、模板和检查清单约束。第三，便于持续演化，因为开放问题和 YAML 结构天然支持增量补齐。第四，更适合 AI 协同，因为输出本身就是给 AI 继续读的。

当然，这套方案也有边界。它不适合还原极细粒度算法实现，不适合替代审计级代码审查，也不适合在没有任何源码访问条件下做精确结论。对于外部配置中心、Kong 实际运行状态、第三方任务补偿等仓库外事实，仍然需要保留开放问题，而不能强行闭合。

AI 辅助下的源代码逆向工程，真正需要的不是一个更会“总结代码”的模型，而是一套能把源码、配置、前端调用、数据库、场景链路和不确定性统一组织起来的方法。当前 reverse 目录下形成的这套方法论，已经证明了一条可行路径：通过总控提示词、Schema Contract、术语归一、开放问题清单、执行说明、模板样例、检查清单和分任务提示词的协同，可以把大型存量系统的逆向工作，从“人工经验驱动的零散整理”升级为“AI 可重复执行的结构化建模流程”。

在数据中台项目上的实践进一步说明，这套方案不仅能快速抽取核心业务域、功能、接口、数据和映射关系，还能通过前后端反查和交叉验证机制，持续提高结果的稳定性和可用性。对于后续任何新项目，这套 Reverse 方法论都可以作为标准逆向启动包使用；对于已经逆向过的项目，它也可以继续作为知识演化框架，支持多轮补齐、质量提升和业务理解传承。

如果说源码是系统的事实基础，那么这套方法论的价值，就是把这些分散在代码、配置和页面中的事实，重新组织成一个既适合人理解、又更适合 AI 长期消费的业务语义模型。

这套提示词用于对 Java 微服务项目做“语义优先”的逆向，优先抽取：

不以局部实现细节为重点。 不要求完整阅读整个源代码仓库。

推荐执行顺序

1. 0_Reverse_Master_Prompt.md
2. 0a_Reverse_Fast_Scan_Prompt.md
3. 0b_YAML_Schema_Contract.md
4. 0c_Semantic_Aliases_Template.md
5. 0d_Open_Questions_Template.md
6. 0e_Reverse_Execution_Playbook.md
7. 0f_Reverse_Output_Templates.md
8. 0g_Reverse_Review_Checklist.md
9. 0h_New_Project_Starter_Kit.md
10. 1_Reverse_Tech_Arch_Prompt.md
11. 2a_Reverse_Business_Semantics_Prompt.md
12. 2_Reverse_DB_Design_Prompt.md
13. 3_Reverse_Func_List_Prompt.md
14. 4_Reverse_API_List_Prompt.md
15. 6_Reverse_Mapping_Prompt.md
16. 5_Reverse_Consistency_Check_Prompt.md

最终目标

形成以下 YAML 文件，供后续 AI 直接读取理解系统核心语义：

• reverse_index.yaml
• scan_candidates.yaml
• semantic_aliases.yaml
• archetype.yaml
• business_semantics.yaml
• database.yaml
• functions.yaml
• apis.yaml
• mappings.yaml
• open_questions.yaml

本次优化重点

1. 从“菜单驱动”改为“业务场景/能力驱动”
2. 引入统一 ID 规范与跨 YAML 引用约束
3. 补充 business_semantics.yaml 与 mappings.yaml
4. 强化一致性检查，不只检查悬空引用，还检查语义覆盖和主链路完整性
5. 引入“快速扫描 + 最小上下文 + 索引优先”策略，避免全量读库
6. 引入统一 YAML Schema Contract，降低多轮输出漂移
7. 引入术语归一与别名字典，降低重复建模与命名分裂
8. 引入开放问题清单，沉淀未决断点而不是分散在各文档中

快速扫描原则

1. 先扫入口、契约、配置、DDL、Entity、Mapper、路由，不扫全量实现类
2. 先建立候选清单，再抽样确认核心对象
3. 每个核心对象保留 source_evidence 和 source_indexes
4. 当主场景、主功能、主接口、主表、主链路已闭环时停止继续下钻

入口文件建议

1. reverse_index.yaml 作为总入口
2. scan_candidates.yaml 作为快速扫描候选池
3. semantic_aliases.yaml 作为业务术语归一入口
4. open_questions.yaml 作为未决问题与补读建议入口
5. 0h_New_Project_Starter_Kit.md 作为新项目启动入口
6. 后续 AI 先读入口文件，再按需展开具体 YAML

本版新增要求

1. 所有 YAML 输出优先遵循 0b_YAML_Schema_Contract.md
2. 所有业务名词优先遵循 semantic_aliases.yaml，避免同义重复建模
3. mappings.yaml 的核心场景主链路应尽量采用 step 级描述
4. 不确定点优先沉淀到 open_questions.yaml，而不是散落在各文件备注中
5. 优先按“执行说明 -> 产出模板 -> 检查清单”三层方式驱动整轮逆向
6. 新项目优先从 0h_New_Project_Starter_Kit.md 启动，并结合 example/ 目录对照落地

希望以上分享对你有所启发。