本文定义 Java 项目中的 AI Agent 开发工作流。文中的路径和名称均为通用示例，落地时必须替换为目标仓库的真实入口、规则和脚本。

Java 项目的工作流模型

Java 任务按“入口 → 自判档位 → 语义触发规则 → 同类实现或必要知识 → 最小修改 → 分层验证 → 收尾交付”执行。规则由仓库入口和规则目录管理，知识读取按任务触发条件执行。

责任	当前落点
统一入口与仓库边界	AGENTS.md
通用执行内核	agent/rules/core.md
Java 与平台约定	agent/rules/packs/ 中的适用规则
版本 SQL 与 Entity	agent/rules/packs/release-sql.md 及版本目录
数据范围与权限	agent/rules/packs/data-scope.md
索引覆盖	agent/rules/packs/index.md
任务编排	agent/skills/task-start/SKILL.md
路由、审计与知识	docs/engineering/
自动收尾	tools/agent/finish.sh 及其调用的检查脚本

不同 Agent 工具可能支持不同的自动加载机制；不能假设规则会自动生效，必须验证入口读取、条件规则加载和检查执行。

Java 任务的当前判定规则

Agent 内部先回答五个问题：交付物是什么、最少改哪些文件、是否改变表结构或关联、是否涉及受保护资金数据、是否新增代码读取的配置。然后自行选择轻量、单点或完整流程，不让用户选择档位。

特别注意：修改已有查询或已有 Job 仍可能是单点；新增 Job、改表或表关联才通常进入完整档。写 Mapper XML、原生 SQL、结构迁移或批量扫描热数据时，立即加载相应数据和索引规则并核对覆盖，不因此自动升级任务档位。

当前收尾口径

• 有文件变更：执行 diff 检查、经验检查并展示 diff。
• 单点：在上述基础上执行相关模块 compile；涉及版本 SQL 时执行版本检查。
• 完整：执行统一收尾入口，按项目审计清单输出变更审计和最终交付清单。
• 新增或变更接口路径、索引 DDL 等特殊信号，按入口和内核规则追加对应检查。

未运行、运行失败或工具缺失都不能写成“已通过”。不擅自提交、推送或发布；外部调度已准备与已经生效也必须分开表述。

Java 项目接入 AI Agent，首先需要建立一套可持续运行的开发模型：需求如何进入、规则如何加载、业务知识如何获取、修改如何验证，以及本次经验怎样被下一次任务复用。

本文围绕这个模型展开，再把每个环节落到 Java 工程中的对象分层、Mapper、Maven 模块、版本 SQL 和调度交付。案例只用于说明环节之间怎样衔接，所有目录、模块和业务名称均为虚构示例。

面向人的阅读顺序是“理解整体 → 看清职责 → 学会搭建 → 验收闭环”；面向 AI 的执行入口和任务书也包含在文中。

1. 先看整体：两条闭环，共同支撑持续开发

这套工作流有两条互相连接的闭环。

任务闭环负责把一次需求完成：理解需求、选择流程、读取依据、修改、验证、交付。

知识闭环负责让后续任务受益：发现新事实或纠正、更新权威资料、维护 LLM Wiki、重新检索确认，再供下一次任务使用。

图中展示的是完整路径。简单文案或局部字段任务，已有明确依据时可以直接读取目标文件，不必每次检索整个 Wiki。

这里的“全 AI Agent 开发”意味着 Agent 主动承担流程中的执行工作。人仍然提供无法从仓库确认的业务事实、评估重要取舍，并决定需要授权的提交、发布或外部环境操作。

为什么 Java 工程需要把这两条闭环连接起来

Java 的一次交付经常跨越多种文件：Java、XML、POM、SQL、配置和调度清单。代码可能编译成功，但数据库没有新字段；Mapper 可能能执行，但业务归属关系错误；Job 首次运行可能正常，但重跑语义没有定义。

因此，工作流必须同时处理三件事：

问题	主要机制
怎样稳定地执行任务	统一入口、任务分级、规则包与 Skill
怎样获取正确的项目背景	LLM Wiki、来源追溯与同类实现
怎样判断交付是否达标	diff 检查、模块构建、行为验证与审计

只有某一项做得很好，其他部分仍然可能成为缺口。

2. 模型中的六个组成部分

先理解各部分的职责，再决定创建哪些文件。

组成部分	回答的问题	Java 项目中的落点
入口	从哪里开始，何时读取什么	根目录 AGENTS.md
规则	哪些约束必须遵守	内核、Java、数据范围、平台与版本规则包
知识	业务为什么这样实现	LLM Wiki 中的领域口径、表关系、历史问题及来源
执行	本次按什么步骤完成	开任务 Skill、任务路由、同类实现
验证	当前改动实际满足了什么	lint、Maven、测试、版本物与 CI
连续性	下次如何继续、如何少犯同样的错	交接文件、经验收件箱及知识更新

这些职责可以落在少量文件中。一个文件是否值得存在，取决于它是否承担了明确职责，而非目录树是否看起来完整。

一个渐进扩展的目录模型

repository/
├── pom.xml
├── booking-contract/             # 教学示例：共享契约
├── booking-service/              # 教学示例：业务实现
├── portal-service/               # 教学示例：入口与调用方
├── AGENTS.md
├── agent/
│   ├── rules/
│   │   ├── core.md
│   │   ├── packs/
│   │   ├── team/
│   │   └── local/
│   ├── skills/task-start/SKILL.md
│   └── state/
├── docs/engineering/
│   ├── task-routing.md
│   ├── patterns/
│   ├── domains/
│   └── lessons-inbox.md
├── database/releases/<release-id>/
└── tools/agent/
    ├── lint-diff.sh
    ├── compile.sh
    ├── audit-change-scope.sh
    ├── lint-release.sh
    ├── check-precipitate.sh
    ├── finish.sh
    └── ci-lint.sh

目录中的脚本是待实现或复用的职责入口，不是创建同名空文件就获得相应能力。已有 Maven Wrapper、检查脚本和 CI 应优先复用。

仓库里的工程资料与 LLM Wiki 项目不必处在同一目录。两者需要通过来源引用和明确的更新机制连接，避免各自保存一份互相漂移的权威正文。

3. 规则模型：通用内核与 Java 规则分开维护

规则有四层：

层	内容	维护原则
L1 内核	判范围、必要阅读、最小修改、验证与交付	保持通用，不写业务表名单
L2 已启用规则包	Java、数据范围、平台、数据库交付	按语义或路径触发
L3 团队补充	当前团队的附加约定	进入版本控制
L4 个人补充	个人环境与表达偏好	通常本地保存，不包含秘密

团队与个人补充可以增加要求，不能关闭适用硬门禁。这个层次首先是执行约定；真正的检查约束还要由脚本和交付平台实现。

3.1 内核保持简短

# 执行内核

- 开始时检查 Git 状态，保留与当前任务无关的已有改动。
- 明确交付物和验收条件，自行判断轻量、单点或完整流程。
- 修改前读取适用规则与相关实现，不凭印象生成代码。
- 范围扩大时，先补读新触发的规则，再继续实现。
- 只做满足需求的最小正确修改，不顺手重构。
- 关键业务事实无法确认时询问事实，不让用户选择流程档位。
- 有变更必须运行适用检查；无法执行与失败不得写成通过。
- 交付结果、验证证据和剩余项，遵守当前授权范围。

3.2 Java 规则包解决实现分歧

下面是一组可选的团队约定，应根据已有代码库取舍：

规则领域	可写入的约定	作用
对象分层	DTO、VO、Entity 职责分开；DTO/VO 不继承 Entity	避免持久化字段意外成为接口契约
字段说明	Javadoc 写清单位、时区、状态及空值语义	保存接口与业务含义
数据访问	新查询统一 Mapper XML，保留无关存量	让口径集中、便于审查
Service	CRUD 与领域编排按已有模式组织	避免所有服务机械套同一种基类
异常	复用领域错误码与异常体系	保持调用方和日志语义一致
接口	分别核对接口权限与资源归属	防止只关注路由可访问
配置	新增 Java 缓存读取时才按现有体系增加键常量	避免只改数据却额外生成代码

“新 SQL 全部集中在 XML”是团队策略，不是 Java 或 MyBatis 的普遍要求。Agent 应遵循当前业务模块的约定，也不应借机重写历史实现。

平台规则单独存放，只在修改平台层时加载。业务模块和平台核心的对象体系可能不同，需要明确适用边界。

3.3 语义触发优先于文件路径

| 规则包 | 触发条件 |
|---|---|
| java-business | 修改业务 Java 或 Mapper XML |
| data-scope | 查询、统计、导出或修改受保护数据 |
| release-sql | 修改 Entity、结构或版本数据 |
| platform | 修改公共平台实现 |
| knowledge | 改变领域事实、关联关系或长期行为 |

例如，Agent 正准备设计统计 SQL，尚未打开 XML 文件，数据范围规则已经应当加载。触发点是任务涉及什么，路径只是补充证据。

4. 任务模型：流程按规模缩放，约束按影响生效

每次需求进入后，Agent 先回答五个问题：

1. 交付物是什么：配置、数据、接口、缺陷、Job，还是文档？
2. 最少影响哪些文件、模块和调用方？
3. 是否改变结构、关联或共享契约？
4. 是否涉及受保护数据或权限边界？
5. 配置是否新增 Java 消费逻辑，如何读取与生效？

这些问题用于决定必要动作，不需要让用户填写流程表。

4.1 三档任务的执行差别

档位	典型范围	阅读	收尾
轻量	局部文档、已确定的配置或数据补充	目标文件及直接规则	lint、适用数据检查、经验检查
单点	局部代码行为	规则与一至两个同类实现	上述检查，加相关构建与行为验证
完整	新接口、跨模块、结构关系或复杂行为	路由、领域知识、参考实现链	完整收尾与必要交付物核对

文件数只是信号。一行权限变化也可能需要很强的边界验证；一次批量文档修订可能不需要 Java 编译。

**任务规模决定流程投入，领域约束决定不可省略的要求。**两者分别判断。

4.2 用小例子看边界

“增加一条后台展示配置”：如果只是既有参数机制的数据补充，通常无需新增 Java 常量或接口。

“列表增加结束时间”：先确认数据库、VO 和共享契约现状，再修改最少的映射与字段；不为形式完整新建 Entity 或迁移。

“日报改变统计范围”：哪怕只改一段 XML，也必须核对数据口径和关联关系，执行适用的边界验证。

这些例子说明的是判定方式。不要把需求名称固化成档位；实际检查后发现更大影响时，及时扩展流程。

5. 知识模型：让 LLM Wiki 进入每次任务的决策过程

在启用并触发知识库的任务中，知识库是任务闭环与知识闭环的连接点；它不是每次 Java 修改的必经步骤。稳定工程知识优先放在受版本控制的文档中，完整任务按路由决定是否检索。

规则规定“写 JOIN 前核对关系”，Wiki 帮助找到“关系为什么成立、历史上错在哪里”；当前代码和验证结果再提供本次修改的依据。

关于知识整理与使用经验，可结合阅读 LLM Wiki 经验总结。这里重点说明它如何接入 Java 开发模型。

5.1 Java 知识应该组织成什么

知识类型	保存内容	使用时机
领域事实	数据范围、时间窗口、状态与空值语义	统计、权限、复杂业务变化
关系说明	连接键、基数、当前与历史语义	新 JOIN 或关系调整
参考链路	Controller → Service → Mapper 的适用样板	新增接口或同类能力
问题与反例	症状、根因、错误写法、修复依据	排查缺陷、防止重犯
交付约定	版本、配置、调度及兼容要求	新能力交付

Wiki 要保存经过核实的解释与来源。它不会自动从任意代码片段推导出正确的业务结论。

5.2 从资料到可用知识

已核实的工程说明、需求事实、关系资料与复盘
                        ↓
         来源管理与知识整理
                        ↓
  LLM Wiki 专题页、实体页、问题页及相互链接
                        ↓
       按任务检索 → 读正文 → 回读来源和当前代码

可以把受版本控制的工程资料作为权威来源，Wiki 提供提炼后的检索与关系导航。无论采用哪种布局，都应明确：原文由谁维护、派生页怎样更新、如何识别旧结论。

页面关系图适合帮助 Agent 找到关联知识；图中的链接不自动证明数据库外键、运行时调用或因果关系。

5.3 让 Agent 按最小阅读集使用 Wiki

# 知识读取协议

本仓库启用 LLM Wiki 作为开发上下文来源。
涉及口径、关系、跨模块行为或历史缺陷时：
1. 确认任务对应的 Wiki 项目。
2. 搜索主题、业务实体或症状，选择少量相关结果。
3. 阅读正文，按需跟随关系与反例链接。
4. 核对来源、适用版本和当前源码。
5. 记录本次采用的依据；冲突未解决时不猜测。

关键词搜索、向量或混合检索只是找到资料的方式，实际能力取决于应用配置。命中分数不等于业务可信度；搜索片段不能代替正文与来源。

直接的局部修改已有充分依据时，可以读对应样板，不必绕一圈全库检索。检索未命中时，继续查看仓库资料与实现，不能推断不存在约束。

5.4 一个简短例子：为什么不能直接拿相似字段 JOIN

假设预约记录同时有“资源 ID”和“空间快照 ID”。Wiki 说明当前报表按资源当前空间统计，快照只服务于历史展示。

Agent 从统计页读到这个事实，再沿链接核对关系页，最后查看当前 Mapper。这样它能在写 SQL 前选择正确路径，并知道需要验证快照为空、空间变化等边界。

工作流的价值在于，已确认的语义可以再次被发现。至于“当前归属”还是“历史归属”，仍由具体需求决定，不能推广成所有报表的通用规则。

5.5 更新知识要验证结果

长期事实变化时，先修改现有权威说明，再按当前能力维护 Wiki 页面或刷新来源处理。需要检查：旧结论是否已替换或标记为历史，相关链接是否仍然有效，重新检索能否读到修正后的内容。

不要假设 Wiki 连接器一定支持写入。若实际接口仅支持读取与来源扫描，文件编辑、应用内维护和重新扫描应按各自支持的方式完成。扫描成功也可能只是进入队列，应回读确认处理结果。

Wiki 暂时不可访问时，可以直接读取已授权仓库资料继续有依据的工作；关键事实仍然缺失或必要更新未完成时，应明确报告。

6. 执行模型：Skill 编排动作，样板指导具体实现

规则定义约束，Skill 把重复步骤编排起来，样板展示它们在当前代码库中如何落地。

6.1 开任务 Skill 的职责

# 开任务

1. 读取根入口与基线规则，检查当前工作状态。
2. 明确交付物与验收条件，自行判断任务规模。
3. 加载语义和路径触发的规则包。
4. 单点任务读取直接相关的同类实现。
5. 完整任务读取任务路由，按需检索 LLM Wiki 并回读来源。
6. 完整且预计跨会话时，读取或建立本任务交接文件。
7. 实施最小正确修改，范围扩大时回到规则加载步骤。
8. 执行适用验证，修复失败项，整理必要交付与知识更新。

只有所用 Agent 环境实际加载并执行这个 Skill，流程才会发生。不能假设某个目录或扩展名在所有工具中自动生效；工具入口应指向同一套权威规则。

6.2 任务路由连接知识和代码

| 任务 | 先读什么 | 再看什么 |
|---|---|---|
| 局部列表修改 | 当前接口约定 | VO 与 Mapper |
| 新管理接口 | 接口与权限约定 | 同类 Controller、Service、Mapper |
| 统计变化 | 领域口径、关系与反例 | 同类统计实现 |
| 新 Job | 日期、重跑与失败语义 | Handler 和领域服务 |
| 跨服务或 MQ | 契约与失败处理说明 | 调用方、实现方或消费样板 |
| 结构变化 | 版本规则与关系说明 | 当前发行目录和迁移样板 |

样板是一条已经核实、适用条件明确的实现路径，不等于复制整套 CRUD 文件。新任务只使用需要的部分，源码现状与规则冲突时应先核实。

6.3 范围扩大必须显式回到上游

例如，开始以为只需要修改 VO 和 XML，检查后发现字段尚未落库。此时回到规则加载阶段，增加结构、版本和知识更新要求，再继续修改。

不能先把所有代码写完，最后才发现缺少迁移、权限或共享契约。这个回路是模型本身的一部分。

7. 交付模型：把代码与运行所需材料一起纳入范围

Java 的交付单元应由行为依赖决定。

变化触发点	需要核对的关联交付物
Entity 或表结构	数据库迁移、兼容与恢复、关系说明
共享 DTO 或接口契约	服务端、调用方、下游构建及接口说明
新配置消费逻辑	默认值、校验、读取与刷新、版本配置
新 Job 或调度变化	Handler、日期与参数、并发策略、调度清单
MQ 或远端副作用	幂等、失败、重试与补偿契约
领域口径变化	对应知识页、反例与行为验证

这张表是触发映射，不是每个任务都必须提交的长清单。

7.1 版本物跟随明确的发行标识

database/releases/<release-id>/
├── changes.sql
├── configuration.md
└── scheduling.md

发行标识来自既定的分支映射或发布清单，不从最大目录号猜测，也不自动等同于父 POM 的平台版本。

已发布版本应按团队策略冻结，修正通过新的增量交付。SQL 同时考虑正向操作和恢复方案；若采用双段文件，执行工具必须明确选择正向或回滚，不能无差别执行整份内容。

反向 DDL 不等于数据无损恢复。目标数据库的语法、锁影响、权限和兼容条件，需要进入适用验证。已有迁移工具时复用其体系，避免并行维护会重复执行的旁路。

7.2 以 Job 为例理解“完整交付”

新增日报 Job 时，Handler 只是入口。工作流还会从领域知识中取得默认日期、重跑、失败和合法空结果的语义，再据此确认需要哪些 Service、Mapper、结构和调度材料。

这不要求每次自动增加所有文件。如果结果表已经存在，就复用；没有新增配置，就不创建空配置清单。最终要证明运行依赖已被覆盖，而非文件数量足够多。

外部状态单独记录：调度清单已准备，与调度平台已配置，是两种不同的完成状态。

8. 验证模型：让“完成”具有可复现的证据

验证由几个不同层次组成，不能互相替代。

层次	检查对象	证据边界
diff lint	已知违规模式、受保护变更、版本路径	只能覆盖已实现的规则
构建	Java、依赖、代码生成及相关编译链	不证明业务语义或 XML 查询正确
行为验证	本次改变的输入、输出和边界	只覆盖实际执行的场景
交付审计	SQL、配置、调度、契约和知识一致性	需要结合真实变更判断
CI	在明确基线上重跑必需检查	只有配置为必需检查才形成对应合并门禁

8.1 检查范围先于检查命令

日常收尾需要纳入暂存、未暂存和未跟踪文件。合并前检查整个分支时，应使用明确的共同祖先或指定基线。

代码已经提交，工作区可能为空，但分支仍然有变更。不能空审通过。基线不存在、工具缺失或读取失败时，也不能吞掉错误后报告“没有改动”。

audit-scope.sh 可以输出变化文件、模块和候选标签，但标签只是提示。Agent 仍需读取 diff，判断语义风险与实际依赖。

8.2 Maven 按受影响范围执行

先从实际 POM 确认 JDK、模块关系、profile 和构建入口，再封装团队命令。

在已具备 Maven Wrapper 的教学仓库中，可用这样的命令表达“目标模块及其 reactor 依赖”：

./mvnw -B -pl booking-service -am compile

模块名需要替换为真实值。-am 不自动覆盖全部下游消费者；共享契约或公共模块变化时，要补充调用方的构建范围。相关含义见 Maven 多模块官方指南。

compile 不表示已经执行测试。Mapper XML 变化还需要适用的加载与查询验证；POM、生成源码或公共契约变化可能要求更大的构建范围。团队选择本地、CI 或专用环境承担哪类验证，应在规则中明确，并分别记录结果。

8.3 收尾入口的职责

确定范围与基线
→ 识别适用规则和模块
→ 执行 diff 门禁
→ 执行相关构建与行为验证
→ 核对必要版本物与知识更新
→ 检查经验收件箱
→ 输出总体状态

必需检查失败时修复，再运行受影响的验证。独立步骤可以继续收集结果，但任何失败或必需项无法执行，都必须反映到总体状态和退出码。

AUDIT_SCOPE=branch
LINT=passed
BUILD=passed
BEHAVIOR_CHECK=not_run
RELEASE_CHECK=passed
KNOWLEDGE_REFRESH=not_applicable
OVERALL=incomplete

这是状态格式示例：假设行为检查是必需项，未运行就不能整体通过。摘要必须由实际执行结果生成。

8.4 审查投入按风险分配

局部字段修改通常以适用脚本、构建和局部验证为主。复杂数据范围、统计、Job 重跑、MQ 或权限模型变化，可以增加独立审查。

独立审查应点明 diff 范围、已读样板、业务问题和输出要求。它不能替代基础检查，也不需要每个任务都启动多个 Agent。

门禁脚本本身同样需要验证：合法修改应通过，已知违规和错误基线应失败，未跟踪文件不能漏扫。脚本报告的是其实际覆盖范围，不能把关键词出现当作关联或鉴权正确的证明。

9. 连续性模型：交接保存进度，Wiki 保存长期知识

两种信息有不同的寿命。

信息	位置	更新时机
当前目标、已完成、剩余步骤、验证状态	本任务交接文件	长任务进度变化时
稳定业务事实、结构关系、反例、样板依据	权威工程资料与 LLM Wiki	事实或长期行为变化时
新发现但尚未评估的经验	经验收件箱	有真实新信号时

9.1 完整且跨会话时才维护交接

# 任务交接

目标与验收条件：
当前分支和最后核对的提交：
已确认事实及引用的 Wiki 页面：
已完成与当前文件变化：
已运行验证及其覆盖范围：
未完成、阻塞与下一步：

新会话先核对当前工作状态，再使用交接内容。其他任务的进行中状态不意味着应自动切换任务。验证之后继续修改了相关代码，原结果也不能无条件沿用。

9.2 经验如何进入长期知识

用户纠正或发现新的险些出错场景
→ 记录现象、证据与建议
→ 评估适用范围
→ 更新领域知识、规则、样板或检查
→ 回读知识并验证规则
→ 关闭待评估条目

Agent 负责提供有证据的候选经验。是否将特殊情况升级为全局要求，需要明确评估，不能自动把每条纠正都写成硬门禁。

同类问题反复出现但尚未处理，可以设置提醒；次数只是维护信号，不代表严重程度。已经被规则覆盖的普通失败，不必每次重新记一条经验。

这一层真正的验收是：换一个会话处理相似需求，Agent 能找到上次修正后的知识与依据，不让用户重新解释一遍。

10. 把模型压缩成一个可执行入口

理解前面的职责后，可以用下面的模板连接各部分。所有路径必须替换或落实为目标仓库中的真实文件。

# Agent 工作入口

用户只描述需求，Agent 自行承担流程动作。

## 基线

1. 阅读 `AGENTS.md`、内核规则与已声明的全局数据约束。
2. 检查 Git 状态，保留无关已有改动。
3. 明确交付物与验收条件，自判轻量、单点或完整流程。

## 按需规则

业务 Java / Mapper → `agent/rules/packs/java-business.md`
数据范围 / 统计 / 权限 → `agent/rules/packs/data-scope.md` 或适用规则包
Entity / 结构 / 版本数据 → `agent/rules/packs/release-sql.md`
平台实现 → `agent/rules/packs/platform.md`

语义触发先于路径；范围扩大时先补读再实现。
团队和个人补充不能关闭适用硬门禁。

## 知识与执行

单点先读一至两个同类实现。
完整任务读取 docs/engineering/task-routing.md。
涉及口径、关系、跨模块或历史问题时，检索对应 LLM Wiki 项目。
阅读正文、核对来源与当前源码；冲突未解决时询问关键事实。
通过内部 task-start Skill 编排动作，不让用户记触发命令。

## 验证与交付

有变更执行 `tools/agent/lint-diff.sh` 与经验检查脚本。
代码或构建变化执行适用模块的 compile.sh 及行为验证。
版本物变化执行 lint-release.sh。
完整任务执行 `finish.sh`；合并前使用明确基线的 CI 检查。
以上脚本均位于 `tools/agent/`，缺失或失败不能视作通过。

改变长期事实时更新权威资料及 Wiki，并确认结果。
完整多轮任务维护 agent/state/ 中本任务的交接。
报告结果、验证范围和剩余项；不擅自提交、推送或发布。

对于不同编辑器或 Agent 工具，保留薄入口适配，统一指向这份协议。不要在多个工具配置中复制整套业务规则，造成版本分歧。

11. 从零搭建：每一阶段都先跑通再扩展

模型解释了各部分如何配合，落地时可以分四轮完成。

阶段	建设内容	验收方式
第一轮：任务闭环	入口、内核、真实 lint 与构建入口	一个局部修改能自动读规则、修改并验证
第二轮：领域与知识	适用规则包、一个 Wiki 主题、少量样板	一个关系或口径任务能找到依据并回读源码
第三轮：交付闭环	版本物映射、完整收尾、分支审计与 CI	代码与必要运行材料都被检查，违规可阻断
第四轮：持续积累	交接、经验评估、知识更新验收	新会话复用已修正结论并继续长任务

LLM Wiki 可以从第二轮的一个小主题开始，尽早验证价值；不必等待整理完整个仓库才接入。

每增加一个脚本或规则，都应说明它解决什么已知问题、如何触发、由什么结果验收。没有实际需求的结构先不创建。

给 AI 的落地任务书

请基于当前 Java 仓库实施本文的工作流模型。

先读取现有入口、规则、POM、构建脚本与 Git 状态。
确认模块边界、JDK、共享契约、数据访问和版本交付现状。
优先复用，保护已有无关工作，不因引入工作流重构业务代码。

按四轮推进：
1. 跑通统一入口、任务分级、最小修改与真实验证。
2. 只启用适用规则包，接入一个 LLM Wiki 主题和已核实样板。
3. 将代码变化映射到 SQL、配置、调度、契约及分支检查。
4. 对长任务增加交接，对真实新经验完成评估和知识更新闭环。

每轮都用具体小任务验证，不仅创建模板文件。
规则加载必须实测；Wiki 来源、项目和刷新方式必须确认。
未知接口、缺失脚本、未运行测试均不得虚构成功。
检查范围覆盖未跟踪文件和已提交的分支变化。
共享契约变化核对下游，编译结果不替代行为验证。

交付实际文件、检查证据、知识引用与剩余事项。
外部配置按授权执行，明确区分“材料已准备”和“已经生效”。

12. 用一个任务走完整条链，而不是再学一套案例

假设需求是“新增每日资源使用报表，支持补跑”。下面只观察工作流如何运转：

环节	Agent 的动作	留下的结果
入口	检查状态，确认跨查询、任务和交付	明确任务范围与验收条件
规则	加载 Java、数据范围、调度和必要版本规则	已知约束
Wiki	搜索时间窗口、归属和重跑语义	引用页与来源
样板	回读适用 Handler、Service、Mapper	可复用实现路径
实施	只增加所需代码和版本材料	最小正确 diff
验证	检查构建、日期边界、范围与重复执行	实际检查证据
知识更新	新语义补进原主题，回读确认	后续可检索的结论
交付	列出代码、版本物、验证及外部配置状态	可审阅结果

如果业务确认过程发现新结构需求，就返回规则与范围判断；如果验证失败，就返回修改；如果资料已经充分且语义未改变，就无需新增知识页。

最终验收模型是否成立

• 小任务自动走小流程，领域约束仍然生效。
• 复杂任务在编码前取得必要知识并核对当前实现。
• 代码、契约和运行材料随实际依赖一起交付。
• 验证失败或无法执行时，结果不会被描述为全部完成。
• 新会话能够继续任务，也能复用过去核实过的经验。

从一个真实 Java 模块开始，把这几项逐一跑通，再扩展到其他模块。工作流的成熟度体现在每次任务都能遵循同一套判断、依据与验证机制。