docs: 更新TRA编程培训课程材料、课件与AI技能交付包
- 新增全套考试卷、评估卷、参考答案与考试培训包模板 - 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象 - 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求 - 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块 - 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语 - 新增考试输出模板与TRAE使用记录文档
This commit is contained in:
smart
@@ -0,0 +1,29 @@
|
||||
# CI 失败日志： Maven 环境错误
|
||||
|
||||
## 使用边界
|
||||
|
||||
这是一段实际保留的 Maven 构建失败记录，用于第六天的 CI 日志分析演练。
|
||||
|
||||
- 直接错误是本地 Maven 仓库文件无法写入。
|
||||
- 它是环境/文件权限问题，不是公务用车模块的业务代码或编译错误。
|
||||
- 不将它写入 `training/require-cancel-reason` 训练分支，因此该分支仍保持两处业务改动的真实 diff。
|
||||
|
||||
## 原始记录
|
||||
|
||||
```text
|
||||
[WARNING] Failed to write tracking file '/Users/smart/.m2/repository/org/bouncycastle/bcpkix-jdk18on/resolver-status.properties'
|
||||
java.io.FileNotFoundException: /Users/smart/.m2/repository/org/bouncycastle/bcpkix-jdk18on/resolver-status.properties (Operation not permitted)
|
||||
at java.io.RandomAccessFile.open0 (Native Method)
|
||||
at java.io.RandomAccessFile.open (RandomAccessFile.java:344)
|
||||
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:259)
|
||||
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update(DefaultTrackingFileManager.java:84)
|
||||
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write(DefaultUpdateCheckManager.java:529)
|
||||
at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:180)
|
||||
|
||||
[ERROR] java.io.FileNotFoundException: /Users/smart/.m2/repository/org/bouncycastle/bcpkix-jdk18on/resolver-status.properties (Operation not permitted)
|
||||
[ERROR] BUILD FAILURE
|
||||
```
|
||||
|
||||
## 来源说明
|
||||
|
||||
记录来源：`JeecgBoot-training` 仓库历史训练分支 `training/no-cross-order-ticket-reassignment` 中的 `training/ci-build-failure.log`。该历史分支仅作为环境错误材料来源，不作为第五、六天的业务案例。
|
||||
+51
-47
@@ -145,61 +145,62 @@
|
||||
|
||||
|
||||
|
||||
### 第 5 天：历史代码重构、测试覆盖与团队资产库建设
|
||||
### 第 5 天：可沉淀的 AI 工程资产：Rule、任务上下文契约、Skill、Agent 与 MCP
|
||||
|
||||
|
||||
|
||||
**目标：**
|
||||
|
||||
掌握用 TRAE 安全治理技术债、补齐测试覆盖，并将课程中的规则、Prompt、模板、案例和流程沉淀为可维护的企业资产库。
|
||||
以当前 JeecgBoot 的公务用车模块为真实素材，识别一次状态变更中的项目事实、反例与重复判断；重点拆解如何将这些信息分别沉淀为 Rule、任务上下文契约、检查单、示例和 Skill。案例只提供证据来源，不作为可复制的通用答案。
|
||||
|
||||
|
||||
|
||||
|内容|实操|产出|
|
||||
|---|---|---|
|
||||
|历史代码问题识别|分析长函数、重复判断、隐式规则、类型缺失、分支过深|代码坏味道清单|
|
||||
|重构方案生成|生成策略模式、composable 拆分、类型抽取方案|重构方案|
|
||||
|重构风险审查|检查行为一致性、影响范围、回滚方案、测试缺口|重构风险清单|
|
||||
|重构实操|对预置历史模块进行分层拆分和类型治理|重构 Diff|
|
||||
|TypeScript 类型治理|从接口响应、状态枚举、表单模型中抽取类型|TypeScript Interface|
|
||||
|测试用例生成|覆盖权限、状态流转、异常输入、边界值|单测用例清单|
|
||||
|Vitest 单测补齐|修正无效断言和脆弱测试|单测脚本与覆盖率报告|
|
||||
|团队资产库分层设计|将课程产物分为规则、Prompt、模板、案例、SOP、指标|资产库目录结构|
|
||||
|`.trae/rules.md` 生命周期|设计规则新增、评审、废弃、版本管理机制|规则维护机制|
|
||||
|Prompt 模板库建设|标准化读代码、拆需求、写代码、重构、测试、Review、CI 修复 Prompt|Prompt 模板库|
|
||||
|案例库沉淀|提取优秀案例、问题案例、幻觉案例、CI 失败案例|案例库|
|
||||
|资产评审机制|明确谁维护、多久评审、如何合入、如何淘汰|资产治理 SOP|
|
||||
|新人和项目推广机制|设计新人学习路径、项目接入流程、检查机制|TRAE 推广流程|
|
||||
|案例引子：识别资产原料|阅读取消派车的状态、入口、权限和写入顺序，区分项目事实与可迁移判断|事实与反例清单|
|
||||
|资产边界与选型|根据变化频率、误用风险、决策复杂度和证据来源，区分稳定约束、运行时事实与可沉淀资产|资产选型表|
|
||||
|Rule 设计契约|编写证据等级、适用场景、必须项、禁止项、来源与验收方式完整的 Rule|可执行 Rule 草案|
|
||||
|任务上下文契约|拆分固定约束与运行时事实，定义结构化输出、证据缺口与停止边界，并用代表性输入验证|影响分析任务契约与测试样例|
|
||||
|Skill 包拆解|理解 SKILL.md、发现配置、Prompt、检查单、模板、参考资料和脚本各自职责|Skill 包结构图|
|
||||
|Skill 组合与停止条件|用 Rule、Prompt、检查单和模板编排事实提取、方案比较、验证设计与结论输出|Skill 工作流与输出契约|
|
||||
|资产验证与演进|用完整输入、缺失证据、范围冲突和跨项目输入测试资产边界，明确可复用与必须重查的内容|资产测试矩阵与演进记录|
|
||||
|自定义 Agent 角色契约|拆解角色名称、用途说明、参数提示、模型、工具和默认指令，区分稳定配置与运行时事实|自定义 Agent 设计卡|
|
||||
|Agent 权限与停止边界|按职责配置最小工具集，明确证据不足、范围越界和验证缺失时的停止条件|Agent 权限矩阵与停止条件|
|
||||
|Agent 与 Skill 组合|明确 Agent、Skill、Rule、Prompt、检查单和运行时事实的权威位置，设计结构化交接结果|Agent-Skill 组合图与交接契约|
|
||||
|历史模块职责识别与方案比选|基于公务用车派车 Service 的现有校验、写入与事务边界，识别重构候选并比较最小方案|重构候选与方案比选表|
|
||||
|重构风险审查|围绕取消派车的输入保护、状态保护、双对象写入、权限与审计入口识别不可改变行为|重构风险清单|
|
||||
|跨端类型契约治理|核验审批结果与申请状态在 Java 常量、TypeScript 模型和表单配置中的表示差异|类型契约与核验项|
|
||||
|测试基线与定向补齐|区分当前 JUnit/Mockito 与 Jest 已证明的范围，补齐派车状态、副作用、请求载荷和类型契约测试|测试缺口矩阵与定向用例清单|
|
||||
|真实 Skill 包与资产库|拆解现有 Skill 包的目录、Prompt、模板、检查单与反例，用测试夹具验证资产边界|资产索引与验收夹具|
|
||||
|MCP 能力资产|围绕外部工具的能力说明、输入输出、权限、审计、故障降级与验证夹具编写 MCP 契约|MCP 能力契约与权限验收清单|
|
||||
|派车重构目标结构|在不改变事务边界、拒绝顺序、接口字段和状态写入语义的前提下，设计派车入口的候选职责拆分|候选职责结构图|
|
||||
|无损重构行为基线|将申请、车辆、司机的拒绝路径与派车成功后的车辆预占整理为可回归的行为基线|无损重构验收表|
|
||||
|命令与展示模型分离|基于派车 VO、实体和前端模型区分用户可提交字段与系统生成字段|命令与展示类型表|
|
||||
|类型契约核验用例|将审批结果大小写与申请状态表示差异转化为可执行的接受、拒绝和载荷检查|类型契约用例集|
|
||||
|取消派车测试矩阵|覆盖空白原因、任务不存在、非法状态、正常取消与车辆缺失等真实分支|取消派车测试矩阵|
|
||||
|测试层级与断言边界|区分 Controller 委派、Service 状态副作用与 API 契约各自应验证的内容|测试分层检查表|
|
||||
|
||||
|
||||
|
||||
### 第 6 天：企业研发效能、PR 闭环、CI 门禁与落地计划
|
||||
### 第 6 天：工程协作与质量闭环：PR、Git、CI、证据链与资产验证
|
||||
|
||||
|
||||
|
||||
**目标：**
|
||||
|
||||
建立 AI 辅助研发效能管理方法，能够基于 PR、CI、缺陷、需求流转数据分析团队产出率、质量和吞吐，并跑通开发、Review、CI、验收、资产沉淀、管理复盘的完整闭环。
|
||||
将 AI 参与的分析、实现和资产使用放入可审查、可验证、可追溯的工程交付链路，掌握 PR 说明、Git 合并控制、CI 失败分析、变更证据链、资产版本兼容性和可演进性审查的方法。AI Code Review 方法沿用第 4 天的既有流程，不再重复讲解。
|
||||
|
||||
|
||||
|
||||
|内容|实操|产出|
|
||||
|---|---|---|
|
||||
|研发效能指标体系|定义产出、质量、吞吐、周期、AI 使用、资产复用指标|指标字典|
|
||||
|产出效率分析|分析 PR 数、有效提交、需求完成数、人均交付量|产出分析模板|
|
||||
|需求吞吐分析|分析需求进入数、完成数、积压数、吞吐率|需求吞吐看板|
|
||||
|交付周期分析|分析 Lead Time、Cycle Time、Review 等待时间、CI 修复时间|周期分析模板|
|
||||
|质量指标分析|分析缺陷数、返工率、测试覆盖率、CI 失败率|质量分析模板|
|
||||
|AI 使用指标|设计 AI 采纳率、AI 修改率、Prompt 复用率、AI Review 命中率|AI 使用指标表|
|
||||
|团队资产指标|设计规则更新次数、模板复用次数、案例沉淀数、资产过期率|资产运营指标|
|
||||
|TRAE 辅助效能分析|将 PR、CI、缺陷样例数据输入 TRAE，生成分析报告|效能分析报告|
|
||||
|TRAE Code Review 方法|从安全、类型、性能、可维护性、测试缺口审查代码|AI Code Review 清单|
|
||||
|PR 模板与审查标准|编写需求说明、实现说明、测试结果、风险点、AI 使用记录|PR 模板|
|
||||
|CI 质量门禁设计|配置 lint、typecheck、unit test、coverage|CI/CD YAML|
|
||||
|TRAE 分析 CI 失败日志|将失败日志输入 TRAE，定位原因并生成修复方案|CI 失败修复记录|
|
||||
|标准 PR 闭环演练|完成代码整理、Review、测试、CI 修复和验收|可运行 PR|
|
||||
|Prompt 模板资产库沉淀|汇总读代码、拆需求、写代码、重构、测试、Review Prompt|Prompt 模板资产库|
|
||||
|ROI 测算方法|计算 AI 采纳率、PR 周期缩短、缺陷率变化、节省人日|ROI 测算报告|
|
||||
|AI 改动的工程闭环|建立从影响分析、变更实现到 PR、CI 和技术结论的交付链路|工程质量检查视图|
|
||||
|标准 PR 说明与 AI 使用记录|基于 diff、需求、测试结果和风险点生成可审查的 PR 描述|PR 模板与样例|
|
||||
|AI 变更 Git 协作|明确分支范围、提交粒度、冲突处理、合并前置条件和回退方式|Git 协作检查单|
|
||||
|CI 失败日志分析|结合日志、构建配置、相关 diff 和项目规则，区分源码、依赖与环境问题|CI 失败分析记录|
|
||||
|CI 质量门禁|理解 lint、typecheck、unit test、coverage 与人工检查各自覆盖的风险|CI 质量门禁清单|
|
||||
|共享资产的版本与兼容性|识别会改变 Agent 行为的资产 diff，说明版本边界、不兼容点、迁移与回退条件|资产兼容性说明|
|
||||
|变更证据链与可追溯说明|将需求、diff、测试、CI、日志和人工观察连接到可复核的技术结论|技术说明与证据地图|
|
||||
|AI 改动的可演进性审查|审查修改入口、规则权威位置、依赖隔离和回归定位能力，降低后续变化成本|可演进性审查清单|
|
||||
|资产变更的工程验证|审查 Rule、任务上下文契约、Skill、Agent 与 MCP 契约的行为变化、引用完整性、兼容性和测试夹具|资产变更审查清单|
|
||||
|
||||
### AI Native 技能清单
|
||||
|
||||
@@ -223,8 +224,8 @@
|
||||
|重构阶段|无损重构|重构 Diff、风险清单|
|
||||
|Review 阶段|AI Code Review|Review 问题清单|
|
||||
|CI 阶段|CI 失败分析|CI 失败原因与修复方案|
|
||||
|管理阶段|研发效能分析|效能分析报告|
|
||||
|管理阶段|ROI 测算|ROI 测算报告|
|
||||
|工程协作阶段|PR 与变更说明|可审查的变更记录|
|
||||
|工程协作阶段|CI 失败分析|失败原因与验证方案|
|
||||
|
||||
|
||||
|
||||
@@ -272,19 +273,25 @@
|
||||
|
||||
- \[ \] 可运行的工单/效能看板业务代码
|
||||
|
||||
- \[ \] 核心历史模块的重构 Diff 记录
|
||||
- \[ \] 项目知识库 README 与新人上手导览
|
||||
|
||||
- \[ \] 高质量 TypeScript 接口定义文件
|
||||
- \[ \] AI 任务委派模板
|
||||
|
||||
- \[ \] 达到标准覆盖率的单元测试脚本与报告
|
||||
- \[ \] 核心历史模块的坏味道清单、重构风险清单与最小重构方案
|
||||
|
||||
- \[ \] 跑通的 CI/CD 质量门禁 YAML 配置
|
||||
- \[ \] 测试安全网清单、单元测试脚本与覆盖率记录
|
||||
|
||||
- \[ \] 团队级 AI Code Review 标准清单
|
||||
- \[ \] Rule / Prompt / Command / Skill 设计卡与候选资产清单
|
||||
|
||||
- \[ \] 精选沉淀的 Prompt 模板资产库
|
||||
- \[ \] 标准 PR 模板与 AI 使用记录表
|
||||
|
||||
- \[ \] ROI 效能提升测算报告及落地计划
|
||||
- \[ \] 团队级 AI Code Review 标准清单与 Review 修复闭环记录
|
||||
|
||||
- \[ \] CI 失败分析记录与 CI/CD 质量门禁方案
|
||||
|
||||
- \[ \] 团队资产库目录、入库标准、版本维护与淘汰机制
|
||||
|
||||
- \[ \] 交付证据包与复用边界说明
|
||||
|
||||
---
|
||||
|
||||
@@ -306,13 +313,10 @@
|
||||
|
||||
8. **工程闭环力：** 能够将 AI Review 融入个人提交习惯，并掌握借助 CI 日志让 AI 自动修复代码的流水线能力。
|
||||
|
||||
9. **管理量化力：** 技术负责人能建立明确的 TRAE 落地方案，掌握代码产出比、交付周期等 ROI 测算方式。
|
||||
9. **工程协作力：** 学员能够把 AI 参与的变更说明、验证证据和可复用资产纳入可审查、可追溯的研发交付链路。
|
||||
|
||||
## 咨询费用
|
||||
|
||||
6 \* 12000 = 720000 元
|
||||
|
||||
付款方式：合同签订后付款50%，培训过半后付款30%，培训结束付款20%。
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,67 +0,0 @@
|
||||
# 安装说明
|
||||
|
||||
## 方式一：安装到 TRAE Skills 目录
|
||||
|
||||
把 `skills/` 下的 5 个 Skill 文件夹复制到本机 Skills 目录：
|
||||
|
||||
```text
|
||||
~/.trae/skills/
|
||||
```
|
||||
|
||||
安装后目录应类似：
|
||||
|
||||
```text
|
||||
~/.trae/skills/
|
||||
├── project-knowledge-builder/
|
||||
├── generate-project-constraints/
|
||||
├── design-complex-business-module/
|
||||
├── review-business-delivery/
|
||||
└── track-review-fix-loop/
|
||||
```
|
||||
|
||||
每个 Skill 文件夹必须保留完整结构：
|
||||
|
||||
```text
|
||||
skill-name/
|
||||
├── SKILL.md
|
||||
├── agents/
|
||||
│ └── openai.yaml
|
||||
└── assets/
|
||||
```
|
||||
|
||||
## 调用方式
|
||||
|
||||
在支持 Skill 的 AI 编程工具中，可以这样调用：
|
||||
|
||||
```text
|
||||
Use $generate-project-constraints 为当前项目生成 AI 开发约束。
|
||||
Use $project-knowledge-builder 为当前项目生成 docs/project-knowledge 项目知识库。
|
||||
Use $design-complex-business-module 设计这个业务模块的权限、状态、审计、异常态和看板。
|
||||
Use $review-business-delivery Review 这批阶段交付物。
|
||||
Use $track-review-fix-loop 根据 Review 报告生成修复闭环记录。
|
||||
```
|
||||
|
||||
## 方式二：作为团队资产库使用
|
||||
|
||||
如果当前 AI 工具暂不支持原生 Skill 机制，可以把本包作为团队资产库使用：
|
||||
|
||||
```text
|
||||
ai-engineering-assets/
|
||||
├── skills/
|
||||
├── rules/
|
||||
├── prompts/
|
||||
├── templates/
|
||||
├── checklists/
|
||||
└── examples/
|
||||
```
|
||||
|
||||
此时 `SKILL.md` 作为标准工作流说明，`assets/` 作为可复制模板、Prompt、检查清单和反例库。
|
||||
|
||||
`examples/` 目录只用于学习参考，不要复制到通用 Skills 安装目录。换项目复用时，应先用 `project-knowledge-builder` 建立项目知识库，再用 `generate-project-constraints` 重新扫描目标项目，最后使用其他 Skill 生成该项目自己的权限、状态、审计、Review 和修复闭环资产。
|
||||
|
||||
## 维护建议
|
||||
|
||||
- 每次项目规则变化后，重新运行 `generate-project-constraints`。
|
||||
- 每次复杂业务模块交付后，把高频问题沉淀到 `review-business-delivery` 或 `track-review-fix-loop` 的 assets。
|
||||
- 不要把某个项目的专用规则直接复制成通用规则。
|
||||
- 对无法从源码或配置证明的内容，统一标记为待确认。
|
||||
@@ -1,51 +0,0 @@
|
||||
# AI Engineering Skills Delivery
|
||||
|
||||
本交付包提供 5 个可复用 AI 工程 Skill，覆盖真实项目中从项目知识库、项目约束生成、复杂业务设计、交付 Review 到修复闭环的完整流程。
|
||||
|
||||
这些 Skill 不是单次 Prompt，而是可安装、可复制、可随项目持续维护的团队资产。
|
||||
|
||||
`skills/` 目录中的内容是通用资产，不能绑定某个训练项目或客户项目；具体案例只放在 `examples/` 目录，作为参考材料，不作为通用 Skill 安装项。
|
||||
|
||||
## 交付内容
|
||||
|
||||
```text
|
||||
客户AI工程Skill交付包/
|
||||
├── README.md
|
||||
├── INSTALL.md
|
||||
├── skills/
|
||||
│ ├── project-knowledge-builder/
|
||||
│ ├── generate-project-constraints/
|
||||
│ ├── design-complex-business-module/
|
||||
│ ├── review-business-delivery/
|
||||
│ └── track-review-fix-loop/
|
||||
└── examples/
|
||||
└── jeecgboot-work-order/
|
||||
```
|
||||
|
||||
## Skill 列表
|
||||
|
||||
| Skill | 用途 | 典型产物 |
|
||||
| --- | --- | --- |
|
||||
| `project-knowledge-builder` | 深度整理代码仓库，生成给人和 AI 复用的项目知识库 | 项目知识库 README、上下文图、架构/运行/前后端/数据/权限文档、RAG 索引建议、生成索引 |
|
||||
| `generate-project-constraints` | 从项目源码、配置、CI、文档中提取项目约束 | rules、约束提取表、验收清单 |
|
||||
| `design-complex-business-module` | 设计复杂业务模块的权限、状态、审计、异常态和看板 | RBAC 矩阵、权限控制方案、状态流转表、审计 SOP、异常态清单、看板指标字典、看板接口验收记录 |
|
||||
| `review-business-delivery` | 审查复杂业务交付物或 PR 的业务风险 | AI Review 报告、阶段 Review 报告、权限/状态/审计/异常态/看板检查清单、业务交付验收清单 |
|
||||
| `track-review-fix-loop` | 跟踪 Review 问题修复、验证和资产沉淀 | 修复记录、未闭环清单、资产更新建议、权限/状态/审计/指标反例库 |
|
||||
|
||||
## 推荐使用顺序
|
||||
|
||||
1. 使用 `project-knowledge-builder` 生成项目知识库，让团队和 AI 先理解项目。
|
||||
2. 使用 `generate-project-constraints` 为客户项目生成项目规则。
|
||||
3. 使用 `design-complex-business-module` 生成复杂业务设计资产。
|
||||
4. 使用 `review-business-delivery` 审查设计、代码或阶段交付物。
|
||||
5. 使用 `track-review-fix-loop` 跟踪修复、验证结果和资产沉淀。
|
||||
|
||||
## 适用项目
|
||||
|
||||
适用于后台管理系统、低代码平台二开、CRM、工单、审批、运营系统、数据看板等企业业务项目。
|
||||
|
||||
这些 Skill 不要求项目必须有 `CLAUDE.md`、`AGENTS.md` 或 `README.md`。如果项目没有显式说明文档，Skill 会从配置、源码模式、测试和 CI 中提取约束，并把无法证明的内容标记为待确认。
|
||||
|
||||
## 示例说明
|
||||
|
||||
`examples/jeecgboot-work-order/` 提供 JeecgBoot 工单案例参考，帮助理解这些 Skill 在真实后台项目中的使用方式。该示例不是通用 Skill 安装项。
|
||||
-44
@@ -1,44 +0,0 @@
|
||||
# JeecgBoot 工单模块开发审查 Skill
|
||||
|
||||
## 触发场景
|
||||
|
||||
涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。
|
||||
|
||||
## 输入材料
|
||||
|
||||
- PR diff 或相关文件。
|
||||
- 工单需求说明。
|
||||
- 数据模型与接口契约。
|
||||
- 当前 rules。
|
||||
- 前端页面文件。
|
||||
- API 模块文件。
|
||||
- 后端 Controller / Service。
|
||||
- 权限矩阵。
|
||||
- 状态流转表。
|
||||
- 审计日志 SOP。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 识别需求范围和非目标范围。
|
||||
2. 检查字段、接口契约和页面状态是否完整。
|
||||
3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态。
|
||||
4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限。
|
||||
5. 检查操作日志、数据权限和测试缺口。
|
||||
6. 检查看板指标口径和接口验收记录。
|
||||
7. 输出风险、不确定点和验收建议。
|
||||
|
||||
## 输出格式
|
||||
|
||||
- 需求范围确认。
|
||||
- 接口契约问题表。
|
||||
- 代码生成 Review 清单。
|
||||
- 权限风险表。
|
||||
- 状态流转风险表。
|
||||
- 审计日志风险表。
|
||||
- 测试缺口清单。
|
||||
- 不确定点清单。
|
||||
|
||||
## 验收标准
|
||||
|
||||
每个关键结论必须标注文件、函数、注解、配置或调用链依据。每条建议必须有验收方式。
|
||||
|
||||
-73
@@ -1,73 +0,0 @@
|
||||
---
|
||||
name: design-complex-business-module
|
||||
description: Use when designing a complex enterprise business module that needs RBAC permissions, frontend/backend permission controls, state transitions, illegal transition handling, audit logging, exception states, dashboard metrics, interface contracts, or acceptance-ready design assets.
|
||||
---
|
||||
|
||||
# Design Complex Business Module
|
||||
|
||||
## Core Principle
|
||||
|
||||
Design the control surfaces before designing code. For complex business modules, produce permission, state, audit, exception, dashboard, and acceptance assets before implementation planning.
|
||||
|
||||
Do not jump from a requirement to CRUD code. Every business rule must have an owner, a source, and a verification method.
|
||||
|
||||
## Inputs
|
||||
|
||||
Collect what exists, then mark gaps explicitly:
|
||||
|
||||
- Business requirement or user stories.
|
||||
- Target project paths and project constraints.
|
||||
- Existing roles, permissions, menus, routes, API layer, backend controllers/services, data model, and audit/logging patterns.
|
||||
- Known non-goals and delivery deadline.
|
||||
- Existing rules, checklists, or project knowledge docs.
|
||||
|
||||
If project evidence is missing, label outputs as `建议` or `待确认`, not `事实`.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define scope: module name, actors, key workflows, non-goals, and acceptance boundary.
|
||||
2. Build the RBAC matrix: roles x features, with `允许`, `拒绝`, or `条件允许`.
|
||||
3. Translate RBAC into a permission control plan: page/menu, button, backend API, and data scope.
|
||||
4. Design the state machine: states, actions, allowed roles, preconditions, post-actions, and terminal states.
|
||||
5. List illegal transitions and rejection behavior.
|
||||
6. Design audit logging: actions, write timing, actor, target, old/new values, source/request id, masking, and failure behavior.
|
||||
7. Complete exception states: permission denied, missing data, invalid state, duplicate submit, validation failure, concurrency, empty dashboard, empty audit log.
|
||||
8. Define dashboard metrics: meaning, formula, dimensions, filters, data source, permission, empty state, and manual verification.
|
||||
9. Produce interface and acceptance notes only after the above assets are consistent.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Generate these assets unless the user narrows scope:
|
||||
|
||||
```text
|
||||
RBAC权限矩阵
|
||||
权限控制方案
|
||||
状态流转表
|
||||
非法流转清单
|
||||
审计日志SOP
|
||||
异常态清单
|
||||
看板指标字典
|
||||
看板接口验收记录
|
||||
不确定点清单
|
||||
```
|
||||
|
||||
Use the templates in `assets/` when creating files.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
- Every sensitive action has frontend visibility control and backend enforcement.
|
||||
- Data permissions are not replaced by button hiding.
|
||||
- Every state transition has a reverse or rejection story, or is explicitly terminal.
|
||||
- Every illegal transition has expected system response and validation method.
|
||||
- Every successful critical operation has an audit record; failed operations do not write success audit.
|
||||
- Every dashboard metric has a formula or filter logic that can be manually checked.
|
||||
- Every output distinguishes `事实`, `推断`, `建议`, and `待确认`.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Do not design UI first and add permissions later.
|
||||
- Do not use "admin can do everything" as a complete RBAC design.
|
||||
- Do not put all status rules into prose; use a state table.
|
||||
- Do not write "record audit log" without naming fields and write timing.
|
||||
- Do not define dashboard cards without metric formulas and data scope.
|
||||
- Do not turn project-specific permission strings into facts without source evidence.
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "复杂业务模块设计"
|
||||
short_description: "生成权限状态审计异常态看板等复杂业务设计资产"
|
||||
default_prompt: "Use $design-complex-business-module to design permissions, state transitions, audit logs, exception states, and dashboard metrics for this business module."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
-19
@@ -1,19 +0,0 @@
|
||||
# <模块名称> RBAC 权限矩阵
|
||||
|
||||
## 使用说明
|
||||
|
||||
将列名中的 `<角色A>`、`<角色B>`、`<角色C>` 替换为目标项目真实角色。权限字符只能写成建议，除非源码、菜单配置或后端注解已经证明。
|
||||
|
||||
| 功能点 | <管理员角色> | <业务负责人角色> | <处理人角色> | <审核人角色> | <只读角色> | 权限字符建议 | 数据范围 | 来源证据 | 备注 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 查看列表 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | `<module>:<entity>:list` | 按授权范围 | | |
|
||||
| 查看详情 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | `<module>:<entity>:query` | 仅可见数据 | | |
|
||||
| 新建记录 | 允许 | 允许 | 条件允许 | 条件允许 | 拒绝 | `<module>:<entity>:add` | 通常无数据范围 | | |
|
||||
| 编辑记录 | 允许 | 条件允许 | 条件允许 | 拒绝 | 拒绝 | `<module>:<entity>:edit` | 创建人/负责人/授权范围 | | 需结合状态 |
|
||||
| 分配/转交 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | `<module>:<entity>:assign` | 管理范围 | | 高风险操作 |
|
||||
| 状态流转 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | `<module>:<entity>:transition` | 当前数据范围 | | 需结合状态表 |
|
||||
| 关闭/归档 | 允许 | 条件允许 | 拒绝 | 条件允许 | 拒绝 | `<module>:<entity>:close` | 当前数据范围 | | 终态动作 |
|
||||
| 删除记录 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | `<module>:<entity>:delete` | 管理范围 | | 高危操作 |
|
||||
| 查看审计日志 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | `<module>:<entity>:audit` | 当前数据范围 | | |
|
||||
| 查看统计看板 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | `<module>:<entity>:dashboard` | 按角色过滤 | | |
|
||||
| 导出数据 | 条件允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | `<module>:<entity>:export` | 管理范围或授权范围 | | 需脱敏 |
|
||||
-27
@@ -1,27 +0,0 @@
|
||||
# RBAC 权限矩阵生成 Prompt
|
||||
|
||||
```text
|
||||
请基于目标业务模块设计 RBAC 权限矩阵。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写，例如订单、客户、申请、任务>
|
||||
- 需求说明或用户故事：<粘贴>
|
||||
- 角色列表：<粘贴目标项目真实角色>
|
||||
- 功能点：<粘贴页面、按钮、接口、数据动作>
|
||||
- 项目依据：<粘贴权限、路由、菜单、接口、后端校验相关路径>
|
||||
|
||||
输出要求：
|
||||
1. 先列事实依据：权限、菜单、动态路由、接口、后端校验相关路径。
|
||||
2. 输出 RBAC 权限矩阵：角色 x 功能点，允许、拒绝、条件允许。
|
||||
3. 输出权限字符建议，并标注哪些是事实、哪些是建议。
|
||||
4. 输出页面级、按钮级、接口级、数据范围四层控制。
|
||||
5. 输出不确定点：哪些权限必须业务方确认。
|
||||
6. 输出验收方式：如何证明权限确实生效。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 不要把前端按钮隐藏当作安全边界。
|
||||
- 所有结论必须区分事实、推断、建议。
|
||||
- 不要把示例模块、示例角色或示例权限字符当成目标项目事实。
|
||||
```
|
||||
-41
@@ -1,41 +0,0 @@
|
||||
# <模块名称> 审计日志 SOP
|
||||
|
||||
## 记录原则
|
||||
|
||||
所有会改变目标业务对象关键状态、负责人/处理人、可见性、金额、结论或对外结果的动作都必须记录审计日志。
|
||||
|
||||
## 审计字段
|
||||
|
||||
| 字段 | 含义 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| target_type | 业务对象类型 | order / customer / request |
|
||||
| target_id | 业务对象 ID | 100001 |
|
||||
| actor_id | 操作人 ID | 1001 |
|
||||
| actor_name | 操作人名称 | zhangsan |
|
||||
| action | 操作类型 | ASSIGN / APPROVE / CLOSE |
|
||||
| field_name | 变更字段 | status / owner_id / amount |
|
||||
| old_value | 旧值 | lisi |
|
||||
| new_value | 新值 | wangwu |
|
||||
| source | 来源 | web |
|
||||
| request_id | 请求 ID | req-001 |
|
||||
| created_at | 操作时间 | 2026-07-01 10:00:00 |
|
||||
|
||||
## 必须记录的动作
|
||||
|
||||
| 动作 | 写入时机 | oldValue | newValue | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 创建记录 | 创建成功后 | 空 | 业务摘要 | 审计列表可见 |
|
||||
| 编辑字段 | 保存成功后 | 修改前字段 | 修改后字段 | 字段前后值正确 |
|
||||
| 分配/转交 | 分配成功后 | 原处理人 | 新处理人 | 审计记录处理人变化 |
|
||||
| 状态流转 | 状态变更成功后 | 原状态 | 新状态 | 审计记录状态变化 |
|
||||
| 结论/审核 | 结论保存成功后 | 原结论 | 新结论 | 审计记录结论变化 |
|
||||
| 评论/备注新增 | 保存成功后 | 空 | 摘要或脱敏内容 | 审计记录评论动作 |
|
||||
| 关闭/归档 | 操作成功后 | 原状态 | 目标终态 | 审计记录关闭或归档时间 |
|
||||
|
||||
## 验收方式
|
||||
|
||||
1. 执行关键操作后能在审计列表查询到记录。
|
||||
2. oldValue/newValue 和实际变更一致。
|
||||
3. 敏感字段已脱敏。
|
||||
4. 操作失败不写成功审计。
|
||||
5. 多步写入失败时审计和业务数据保持一致。
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# 审计日志检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建业务记录后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 分配记录 | 分配或转交记录原处理人和新处理人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
| 操作人 | actor_id 和 actor_name 可追溯 | |
|
||||
| 来源 | source 或 request_id 可追溯 | |
|
||||
| 脱敏 | 敏感字段不明文进入审计 | |
|
||||
| 失败处理 | 操作失败不写成功审计 | |
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# 异常态检查清单
|
||||
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示记录不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
| 参数缺失 | 返回参数错误，业务数据不变 | |
|
||||
| 并发修改 | 拒绝覆盖或提示刷新 | |
|
||||
| 看板无数据 | 图表显示空态，不显示假数据 | |
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
# <模块名称> 异常态清单
|
||||
|
||||
| 场景 | 触发条件 | 前端表现 | 后端响应 | 验收 | 来源证据 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 权限不足 | 无权限操作敏感功能 | 按钮不可见或提示无权限 | 403 或业务拒绝 | 不完成操作 | |
|
||||
| 记录不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 | |
|
||||
| 非法状态流转 | `<状态A> -> <状态C>` 不在状态表 | 提示非法流转 | 状态不变 | 数据状态不变 | |
|
||||
| 重复提交 | 连续点击提交或重复请求 | 按钮 loading/禁用 | 只处理一次 | 只生成一条有效审计 | |
|
||||
| 参数缺失 | 必填原因、金额、范围或结论缺失 | 表单校验提示 | 参数错误 | 不改变业务数据 | |
|
||||
| 并发修改 | 数据版本过期 | 提示刷新 | 拒绝覆盖或合并冲突 | 旧数据不覆盖新数据 | |
|
||||
| 统计无数据 | 无匹配记录 | 空状态 | 返回 0 或空集合 | 页面不显示假数据 | |
|
||||
| 审计日志为空 | 无审计记录 | 空状态 | 返回空集合 | 页面不报错 | |
|
||||
| 下游服务失败 | 外部接口超时或失败 | 错误提示且可重试 | 失败响应可追踪 | 不写成功审计 | |
|
||||
-31
@@ -1,31 +0,0 @@
|
||||
# 异常态补齐 Prompt
|
||||
|
||||
```text
|
||||
请基于目标业务模块，列出状态流转、分配/转交、删除/作废、查询详情、审计日志、统计看板相关的异常态和防御性逻辑。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- 角色与权限：<粘贴>
|
||||
- 状态流转表：<粘贴>
|
||||
- 接口契约或页面说明：<粘贴>
|
||||
|
||||
输出表格：
|
||||
场景 | 触发条件 | 前端表现 | 后端响应 | 用户提示 | 测试点 | 验收
|
||||
|
||||
必须覆盖：
|
||||
- 权限不足
|
||||
- 记录不存在
|
||||
- 非法状态流转
|
||||
- 重复提交
|
||||
- 参数缺失
|
||||
- 并发修改
|
||||
- 统计无数据
|
||||
- 审计日志为空
|
||||
- 下游服务失败
|
||||
|
||||
约束：
|
||||
- 先列异常态，不要直接改代码。
|
||||
- 给出每个异常态的验收步骤。
|
||||
- 标注事实、推断、建议和不确定点。
|
||||
```
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 权限上线前检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 目标模块菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、分配、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内数据 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/分配 | |
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# <模块名称> 权限控制方案
|
||||
|
||||
| 操作 | 前端入口 | 权限字符 | 后端接口 | 后端校验 | 数据权限 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 新增记录 | 新增按钮 | `<module>:<entity>:add` | `<POST /api/entity>` | 权限注解或统一鉴权 | 通常无数据范围 | 无权限账号看不到按钮且直接请求失败 |
|
||||
| 编辑记录 | 编辑按钮 | `<module>:<entity>:edit` | `<PUT /api/entity/{id}>` | 权限校验 + 状态校验 | 创建人/负责人/授权范围 | 越权账号返回 403 或业务拒绝 |
|
||||
| 分配/转交 | 分配按钮 | `<module>:<entity>:assign` | `<POST /api/entity/{id}/assign>` | 权限校验 | 管理范围或当前授权范围 | 未授权角色无法分配给他人 |
|
||||
| 状态流转 | 状态按钮 | `<module>:<entity>:transition` | `<POST /api/entity/{id}/transition>` | 权限校验 + 状态机校验 | 当前授权范围 | 非法流转失败且状态不变 |
|
||||
| 删除/作废 | 删除或作废按钮 | `<module>:<entity>:delete` | `<DELETE /api/entity/{id}>` | 权限校验 + 风险校验 | 管理范围 | 非授权角色返回 403 或业务拒绝 |
|
||||
| 查看审计 | 审计页签 | `<module>:<entity>:audit` | `<GET /api/entity/{id}/audit>` | 权限校验 | 当前授权范围 | 无权限不可见且接口拒绝 |
|
||||
| 统计看板 | 看板菜单 | `<module>:<entity>:dashboard` | `<GET /api/entity/dashboard>` | 权限校验 | 数据范围过滤 | 不同角色返回授权范围内统计 |
|
||||
-26
@@ -1,26 +0,0 @@
|
||||
# 权限控制方案生成 Prompt
|
||||
|
||||
```text
|
||||
请基于目标业务模块 RBAC 权限矩阵，生成权限控制方案。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- RBAC 权限矩阵：<粘贴>
|
||||
- 接口契约表：<粘贴>
|
||||
- 当前项目权限相关路径：<粘贴>
|
||||
- 当前 rules：<粘贴>
|
||||
|
||||
输出要求：
|
||||
1. 权限控制方案表，列为：操作、前端入口、权限字符、后端接口、后端校验、数据权限、验收。
|
||||
2. 影响范围：前端页面、API 文件、后端 Controller、Service、菜单配置、数据权限。
|
||||
3. 缺失风险：按钮隐藏、接口未校验、数据范围不清、权限字符不一致。
|
||||
4. 无权限访问验收步骤。
|
||||
5. 不确定点和需要人工确认的权限边界。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 后端接口权限必须单独说明。
|
||||
- 每个敏感操作必须有验收方式。
|
||||
- 权限字符、接口路径和角色名称必须来自输入材料；没有依据时标注为建议。
|
||||
```
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 状态流转检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 状态枚举 | 所有状态有统一枚举或字典 | |
|
||||
| 合法流转 | 状态流转表中的合法路径可执行 | |
|
||||
| 非法流转 | 非法路径被拒绝且状态不变 | |
|
||||
| 角色限制 | 不同角色只能执行被授权动作 | |
|
||||
| 前置条件 | 驳回原因、关闭条件、处理人、审批意见等校验完整 | |
|
||||
| 审计日志 | 每次成功流转写审计 | |
|
||||
| 重复提交 | 重复点击不会产生重复有效流转 | |
|
||||
-21
@@ -1,21 +0,0 @@
|
||||
# <模块名称> 状态流转表
|
||||
|
||||
| 当前状态 | 动作 | 目标状态 | 允许角色 | 前置条件 | 后置动作 | 验收 | 来源证据 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 草稿/新建 | 提交 | 待处理/待审核 | 创建人/提交人 | 必填字段完整 | 写审计日志 | 状态变为目标状态 | |
|
||||
| 待处理/待审核 | 分配/领取 | 处理中 | 管理员/负责人/处理人 | 处理人存在且有权限 | 写审计日志 | 处理人变化且状态正确 | |
|
||||
| 处理中 | 提交结果 | 待确认/待复核 | 处理人/负责人 | 处理说明或结果不为空 | 写审计日志 | 状态变为待确认 | |
|
||||
| 待确认/待复核 | 通过 | 已完成/已关闭 | 审核人/负责人 | 审核结论通过 | 写审计日志和完成时间 | 状态进入终态 | |
|
||||
| 待确认/待复核 | 驳回 | 已驳回/待修改 | 审核人/负责人 | 驳回原因不为空 | 写审计日志 | 状态变为驳回态 | |
|
||||
| 已驳回/待修改 | 重新提交 | 待处理/待审核 | 创建人/处理人 | 修改说明不为空 | 写审计日志 | 回到处理链路 | |
|
||||
| 已完成/已关闭 | 重新打开 | 草稿/新建/处理中 | 管理员/负责人 | 重开原因不为空 | 写审计日志 | 状态按规则回退 | |
|
||||
|
||||
## 非法流转清单
|
||||
|
||||
| 当前状态 | 尝试动作 | 问题 | 系统响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 已完成/已关闭 | 直接处理 | 终态不能直接进入处理中 | 返回非法流转 | 状态不变 |
|
||||
| 草稿/新建 | 直接通过 | 未提交或未处理不能通过 | 返回非法流转 | 状态不变 |
|
||||
| 待确认/待复核 | 重复提交结果 | 重复动作不应再次生效 | 返回非法流转或幂等结果 | 只保留原状态 |
|
||||
| 处理中 | 直接通过 | 未进入确认/复核节点 | 返回非法流转 | 状态不变 |
|
||||
| 已驳回/待修改 | 直接关闭 | 驳回后不能绕过修改或确认 | 返回非法流转 | 状态不变 |
|
||||
-33
@@ -1,33 +0,0 @@
|
||||
# 状态流转设计 Prompt
|
||||
|
||||
```text
|
||||
请为目标业务模块设计状态流转规则。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- 角色列表：<粘贴>
|
||||
- 当前需求或已有状态枚举：<粘贴>
|
||||
- 关键动作：<粘贴>
|
||||
|
||||
可参考但必须按项目替换的状态类型：
|
||||
- 草稿/新建
|
||||
- 待处理/待审核
|
||||
- 处理中
|
||||
- 待确认/待复核
|
||||
- 已完成/已关闭
|
||||
- 已驳回/待修改
|
||||
|
||||
输出要求：
|
||||
1. 状态流转表：当前状态、动作、目标状态、允许角色、前置条件、后置动作、验收。
|
||||
2. 非法流转清单：当前状态、尝试动作、问题、系统响应、验收。
|
||||
3. 接口设计建议。
|
||||
4. 测试点清单。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 先出状态表，不要直接写 if else。
|
||||
- 终态、越权、缺少说明、重复提交必须覆盖。
|
||||
- 每条规则必须有验收方式。
|
||||
- 没有需求依据的状态或动作必须标注为建议或待确认。
|
||||
```
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
# 看板指标口径检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 指标含义 | 每个指标有业务解释 | |
|
||||
| 计算口径 | 每个指标有公式或筛选条件 | |
|
||||
| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 | |
|
||||
| 数据范围 | 不同角色的数据范围清楚 | |
|
||||
| 空数据 | 空数据展示为 0 或空态，不误导 | |
|
||||
| 分组一致性 | 分组总和能和总数对齐 | |
|
||||
| 权限 | 无看板权限不能访问接口 | |
|
||||
| 验收证据 | 至少有一组样例数据手工校验 | |
|
||||
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# <模块名称> 看板指标字典
|
||||
|
||||
| 指标 | 含义 | 口径 | 数据来源 | 展示方式 | 权限 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 记录总数 | 当前筛选范围内业务记录数量 | count(target_id) | 主业务表 | 指标卡 | 看板权限 | 与列表同条件数量一致 |
|
||||
| 未完成数量 | 状态不在终态集合内的数量 | status not in `<terminal_statuses>` | 主业务表 | 指标卡 | 看板权限 | 过滤状态验证 |
|
||||
| 平均完成周期 | 从开始时间到完成时间的平均耗时 | avg(completed_at - started_at) | 主业务表 | 指标卡/趋势 | 看板权限 | 抽样计算一致 |
|
||||
| 按状态分布 | 各状态记录数量 | group by status | 主业务表/状态字典 | 饼图/柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 按类型分布 | 各业务类型数量 | group by type | 主业务表/字典 | 柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 趋势指标 | 按日期统计新增、完成或失败数量 | group by date_field | 主业务表 | 折线图 | 看板权限 | 日期范围正确 |
|
||||
| 逾期数量 | 超过 SLA 且未完成的数量 | due_at < now and status not in `<terminal_statuses>` | 主业务表 | 指标卡 | 看板权限 | SLA 口径明确 |
|
||||
| 人员处理负载 | 按负责人/处理人统计未完成数量 | group by owner_id / assignee_id | 主业务表 | 排行榜 | 管理员/负责人 | 数据范围正确 |
|
||||
-35
@@ -1,35 +0,0 @@
|
||||
# 看板指标设计 Prompt
|
||||
|
||||
```text
|
||||
请为目标业务模块设计业务看板指标。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- 角色与数据范围：<粘贴>
|
||||
- 状态枚举与时间字段：<粘贴>
|
||||
- 列表筛选条件：<粘贴>
|
||||
|
||||
指标方向可参考：
|
||||
- 记录总数
|
||||
- 未完成数量
|
||||
- 平均完成周期
|
||||
- 按状态分布
|
||||
- 按类型分布
|
||||
- 趋势指标
|
||||
- 逾期数量
|
||||
- 人员处理负载
|
||||
|
||||
输出要求：
|
||||
1. 指标字典：指标名、含义、口径、维度、过滤条件、数据来源、展示方式、权限。
|
||||
2. 看板统计接口契约建议。
|
||||
3. 空态、错误态、无权限态。
|
||||
4. 验收方式。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 每个指标必须可计算。
|
||||
- 不要只写页面 UI。
|
||||
- 指标口径不清必须写入不确定点。
|
||||
- 不要把示例指标名直接当成目标项目事实。
|
||||
```
|
||||
-29
@@ -1,29 +0,0 @@
|
||||
# 看板接口验收 Prompt
|
||||
|
||||
```text
|
||||
请为目标业务模块看板统计接口生成验收记录。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- 看板指标字典：<粘贴>
|
||||
- 看板接口契约：<粘贴>
|
||||
- 权限矩阵：<粘贴>
|
||||
|
||||
输出表格：
|
||||
验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论
|
||||
|
||||
必须覆盖：
|
||||
- 有数据
|
||||
- 空数据
|
||||
- 无权限
|
||||
- 过滤条件
|
||||
- 指标口径
|
||||
- 时间范围
|
||||
- 数据范围
|
||||
|
||||
约束：
|
||||
- 不要只说“接口正常”。
|
||||
- 每个指标至少有一个验收动作。
|
||||
- 每个验收动作都要说明账号/角色、请求参数、预期、实际和证据。
|
||||
```
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 看板接口验收清单
|
||||
|
||||
| 验收项 | 请求条件 | 通过标准 | 结果 |
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员或授权角色默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定业务类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
| 指标一致性 | 固定样例数据 | 与手工计算一致 | |
|
||||
-10
@@ -1,10 +0,0 @@
|
||||
# <模块名称> 看板接口验收记录
|
||||
|
||||
| 验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 记录总数 | 管理员或授权角色 | 默认筛选 | 返回总数 | | | |
|
||||
| 空数据 | 授权角色 + 无匹配条件 | 不存在的日期范围或筛选条件 | 返回空集合或 0 | | | |
|
||||
| 无权限 | 未授权角色 | 默认筛选 | 返回 403 或业务拒绝 | | | |
|
||||
| 时间过滤 | 授权角色 | start/end | 只统计范围内数据 | | | |
|
||||
| 数据范围 | 普通业务角色 | 默认筛选 | 只返回本人或授权范围内数据 | | | |
|
||||
| 指标口径 | 授权角色 | 固定样例数据 | 与手工计算一致 | | | |
|
||||
-114
@@ -1,114 +0,0 @@
|
||||
---
|
||||
name: generate-project-constraints
|
||||
description: Use when a user needs to extract project-specific AI coding constraints, team rules, repository rules, .trae rules, Cursor rules, CLAUDE.md/AGENTS.md content, or reusable rules/checklists from an existing software project, including projects without README or explicit instruction files.
|
||||
---
|
||||
|
||||
# Generate Project Constraints
|
||||
|
||||
## Core Principle
|
||||
|
||||
Generate constraints from evidence, not preference. Treat instruction files as optional inputs: if they exist, read them first; if not, use code-only mode and infer cautiously from config, source patterns, tests, CI, and runtime behavior.
|
||||
|
||||
Every output rule must be labeled as `硬约束`, `观察性约束`, or `待确认约束`, and every non-obvious rule must cite source paths.
|
||||
|
||||
## Evidence Order
|
||||
|
||||
Read available sources in this order:
|
||||
|
||||
1. Explicit instructions: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.trae/rules`, `.cursor/rules`, `.cursorrules`, `README*`, `CONTRIBUTING*`, team docs.
|
||||
2. Build/runtime manifests: `package.json`, lockfiles, `pom.xml`, `build.gradle`, `.env*`, `application*.yml`, Docker files, compose files.
|
||||
3. Quality gates: ESLint, Prettier, Stylelint, Checkstyle, Spotless, PMD, Jest/Vitest/JUnit/Playwright configs, CI workflows.
|
||||
4. Source patterns: API layer, response wrappers, auth/permission flow, routing, state management, controller/service/repository or mapper layers, error handling, audit/logging.
|
||||
5. Existing examples: representative modules that already implement the pattern requested by the user.
|
||||
|
||||
If a source category is absent, record it in `缺失证据`, then continue. Never block only because `README.md`, `CLAUDE.md`, or `AGENTS.md` is missing.
|
||||
|
||||
## Constraint Levels
|
||||
|
||||
| Level | Use When | Wording |
|
||||
| --- | --- | --- |
|
||||
| `硬约束` | Directly proven by config, build files, CI, runtime settings, or explicit team docs | `必须` / `禁止` |
|
||||
| `观察性约束` | Repeated pattern appears in existing code but no written rule exists | `默认采用` / `优先复用` |
|
||||
| `待确认约束` | Needed for delivery but not provable from the repo | `需团队确认` |
|
||||
|
||||
Do not upgrade an observed pattern into a hard rule unless a source explicitly requires it.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define scope: target repo path, output path, desired rule categories, and whether the user wants installable Skill assets or plain rules.
|
||||
2. Inventory sources with fast shell commands such as `rg --files`, `find`, `sed`, and focused `rg` searches.
|
||||
3. Extract facts into an evidence table: source path, observed fact, affected area, confidence, and candidate rule.
|
||||
4. Normalize candidate rules into the output contract below.
|
||||
5. Validate each rule against at least one source path or mark it `待确认约束`.
|
||||
6. Write rules and checklists. Prefer small files such as `rules/backend.md`, `rules/frontend.md`, `rules/security.md`, `rules/testing.md`, `rules/delivery.md`.
|
||||
7. Run verification: placeholder scan, broken-path spot checks, and a final pass that every hard/observed rule has evidence.
|
||||
|
||||
## Output Contract
|
||||
|
||||
When the user asks to generate constraints, produce these artifacts unless they request a lighter output:
|
||||
|
||||
```text
|
||||
ai-dev-assets/
|
||||
├── rules/
|
||||
│ ├── global.md
|
||||
│ ├── frontend.md
|
||||
│ ├── backend.md
|
||||
│ ├── security.md
|
||||
│ ├── testing.md
|
||||
│ └── delivery.md
|
||||
├── templates/
|
||||
│ └── 项目约束提取表.template.md
|
||||
└── checklists/
|
||||
└── 项目约束验收清单.md
|
||||
```
|
||||
|
||||
Each rule file should use this structure:
|
||||
|
||||
```md
|
||||
## 规则名称
|
||||
|
||||
- 级别：硬约束 | 观察性约束 | 待确认约束
|
||||
- 适用场景：
|
||||
- 必须：
|
||||
- 禁止：
|
||||
- 来源证据：
|
||||
- 验收方式：
|
||||
- 迁移说明：
|
||||
```
|
||||
|
||||
Use `assets/项目约束提取表.template.md` and `assets/项目约束验收清单.md` as copyable starting points when helpful.
|
||||
|
||||
## Code-Only Mode
|
||||
|
||||
Use this when no explicit instruction files exist.
|
||||
|
||||
Required behavior:
|
||||
|
||||
- State that explicit project docs were not found.
|
||||
- Build constraints from manifests, configs, CI, tests, and repeated source patterns.
|
||||
- Label all pattern-derived rules as `观察性约束`.
|
||||
- Create a `待确认约束` section for business delivery rules that the repo cannot prove, such as review gates, branch policy, audit requirements, test minimums, and release process.
|
||||
|
||||
Good wording:
|
||||
|
||||
```md
|
||||
本项目未发现 `AGENTS.md`、`CLAUDE.md`、`.trae/rules` 或 `README.md` 中的明确 AI 协作规则。以下约束来自配置文件和源码模式；未能由仓库证明的内容已标记为待确认。
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
Before claiming completion:
|
||||
|
||||
- List generated files.
|
||||
- Scan generated files for unfinished placeholders, dummy names, and empty headings.
|
||||
- Check hard and observed constraints cite source paths.
|
||||
- Confirm missing evidence is not silently converted into rules.
|
||||
- Report which sources were read and which rule categories remain `待确认`.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Do not require `CLAUDE.md`, `AGENTS.md`, or `README.md` to exist.
|
||||
- Do not turn general best practices into project rules without evidence.
|
||||
- Do not merge business constraints, technical constraints, and delivery constraints into one vague list.
|
||||
- Do not omit verification steps; rules are useful only if a learner or team can check them.
|
||||
- Do not copy one project's specific constraints into unrelated projects.
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "项目约束生成"
|
||||
short_description: "从项目证据提取可执行规则、模板和验收清单"
|
||||
default_prompt: "Use $generate-project-constraints to extract project-specific AI coding constraints, rules, and checklists from this repository."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
-43
@@ -1,43 +0,0 @@
|
||||
# 项目约束提取表
|
||||
|
||||
## 项目信息
|
||||
|
||||
| 字段 | 内容 |
|
||||
| --- | --- |
|
||||
| 项目名称 | |
|
||||
| 项目路径 | |
|
||||
| 提取日期 | |
|
||||
| 提取人 | |
|
||||
| 目标输出 | rules / prompts / checklists / Skill |
|
||||
|
||||
## 证据扫描记录
|
||||
|
||||
| 证据类型 | 文件或目录 | 是否存在 | 关键发现 | 备注 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 显式规则 | AGENTS.md / CLAUDE.md / .trae/rules / .cursor/rules | | | |
|
||||
| 项目说明 | README / CONTRIBUTING / docs | | | |
|
||||
| 后端构建 | pom.xml / build.gradle / settings.gradle | | | |
|
||||
| 前端构建 | package.json / lockfile / vite.config / tsconfig | | | |
|
||||
| 运行配置 | .env / application.yml / Dockerfile / compose | | | |
|
||||
| 质量工具 | ESLint / Prettier / Checkstyle / CI / test config | | | |
|
||||
| 源码模式 | API / Controller / Service / Router / Store | | | |
|
||||
| 权限与安全 | auth / permission / role / route guard / interceptor | | | |
|
||||
| 数据与迁移 | schema / migration / mapper / repository | | | |
|
||||
|
||||
## 候选约束
|
||||
|
||||
| 编号 | 分类 | 约束内容 | 级别 | 来源证据 | 影响范围 | 验收方式 | 迁移说明 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| C-001 | global / frontend / backend / security / testing / delivery | | 硬约束 / 观察性约束 / 待确认约束 | | | | |
|
||||
|
||||
## 缺失证据
|
||||
|
||||
| 缺失项 | 影响 | 处理方式 |
|
||||
| --- | --- | --- |
|
||||
| | | 标记为待确认 / 询问团队 / 暂不生成规则 |
|
||||
|
||||
## 待团队确认
|
||||
|
||||
| 问题 | 为什么需要确认 | 建议默认值 | 决策人 |
|
||||
| --- | --- | --- | --- |
|
||||
| 是否强制单测 | 仓库未发现 CI 或测试要求时无法证明 | 新增核心逻辑需补测试或说明豁免 | 技术负责人 |
|
||||
-61
@@ -1,61 +0,0 @@
|
||||
# 项目约束生成 Prompt
|
||||
|
||||
请为下面项目生成可复用的 AI 开发约束资产。
|
||||
|
||||
## 项目输入
|
||||
|
||||
- 项目路径：
|
||||
- 输出路径：
|
||||
- 目标项目类型：
|
||||
- 是否需要生成 rules：
|
||||
- 是否需要生成 checklist：
|
||||
- 是否需要生成 Skill：
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 先扫描项目中是否存在显式规则文件，例如 `AGENTS.md`、`CLAUDE.md`、`.trae/rules`、`.cursor/rules`、`README.md`、`CONTRIBUTING.md`。
|
||||
2. 如果不存在显式规则文件，不要停止，进入 code-only 模式。
|
||||
3. 从构建配置、运行配置、源码模式、测试配置、CI 配置中提取约束。
|
||||
4. 每条约束必须标注为：
|
||||
- `硬约束`：由配置、CI、构建或显式规则直接证明。
|
||||
- `观察性约束`：由多个源码样例归纳，但没有显式规则。
|
||||
- `待确认约束`：项目无法证明，但交付前必须团队确认。
|
||||
5. 每条硬约束和观察性约束必须标注来源路径。
|
||||
6. 不要把通用最佳实践当成项目事实。
|
||||
7. 不要把某个项目的专用规则复制到另一个项目。
|
||||
|
||||
## 输出格式
|
||||
|
||||
请生成：
|
||||
|
||||
```text
|
||||
rules/global.md
|
||||
rules/frontend.md
|
||||
rules/backend.md
|
||||
rules/security.md
|
||||
rules/testing.md
|
||||
rules/delivery.md
|
||||
templates/项目约束提取表.template.md
|
||||
checklists/项目约束验收清单.md
|
||||
```
|
||||
|
||||
每条规则使用：
|
||||
|
||||
```md
|
||||
## 规则名称
|
||||
|
||||
- 级别：
|
||||
- 适用场景：
|
||||
- 必须：
|
||||
- 禁止：
|
||||
- 来源证据：
|
||||
- 验收方式：
|
||||
- 迁移说明：
|
||||
```
|
||||
|
||||
最后输出：
|
||||
|
||||
- 已读来源。
|
||||
- 缺失证据。
|
||||
- 待确认问题。
|
||||
- 不能迁移到其他项目的项目特有约束。
|
||||
-44
@@ -1,44 +0,0 @@
|
||||
# 项目约束验收清单
|
||||
|
||||
## 基础完整性
|
||||
|
||||
- [ ] 已列出目标项目路径和输出路径。
|
||||
- [ ] 已说明是否发现显式规则文件。
|
||||
- [ ] 已记录缺失证据，没有因为缺失 README / CLAUDE.md / AGENTS.md 而停止。
|
||||
- [ ] 已区分 `硬约束`、`观察性约束`、`待确认约束`。
|
||||
- [ ] 每条硬约束都有明确来源路径。
|
||||
- [ ] 每条观察性约束至少有一个代表性源码样例。
|
||||
- [ ] 每条待确认约束都写明需要谁确认。
|
||||
|
||||
## 规则质量
|
||||
|
||||
- [ ] 规则包含适用场景。
|
||||
- [ ] 规则包含必须做什么。
|
||||
- [ ] 规则包含禁止做什么，或说明没有禁止项。
|
||||
- [ ] 规则包含验收方式。
|
||||
- [ ] 规则包含迁移说明，说明换项目时能否复用。
|
||||
- [ ] 规则没有把通用最佳实践冒充为项目事实。
|
||||
- [ ] 规则没有把某个单一代码样例冒充为全项目硬约束。
|
||||
|
||||
## 覆盖范围
|
||||
|
||||
- [ ] global 约束覆盖项目理解、证据引用、事实/推断区分。
|
||||
- [ ] frontend 约束覆盖包管理器、框架、路径别名、API 层、路由和状态管理。
|
||||
- [ ] backend 约束覆盖语言版本、框架、分层、响应结构、异常和数据访问。
|
||||
- [ ] security 约束覆盖认证、权限、敏感信息、数据范围和接口防护。
|
||||
- [ ] testing 约束覆盖已有测试工具、运行命令和缺失测试时的处理。
|
||||
- [ ] delivery 约束覆盖计划、Review、验收记录、发布或交付要求。
|
||||
|
||||
## 可复用性
|
||||
|
||||
- [ ] 某个项目特有规则没有写进通用规则。
|
||||
- [ ] 每条规则都标注了“可直接复用 / 需重新扫描 / 不可迁移”。
|
||||
- [ ] 换项目时必须重新扫描的内容已经列出。
|
||||
- [ ] 可以从本清单反推出生成步骤。
|
||||
|
||||
## 交付检查
|
||||
|
||||
- [ ] 生成文件中没有未完成占位符、示例假名或空标题。
|
||||
- [ ] Markdown 链接或路径经过抽样检查。
|
||||
- [ ] 规则文件标题不为空。
|
||||
- [ ] 交付说明列出已读来源、未读来源和仍需确认的问题。
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
name: review-business-delivery
|
||||
description: Use when reviewing complex business delivery artifacts, AI-generated plans, PR diffs, or module designs for permission gaps, illegal state transitions, missing audit logs, weak exception handling, unclear dashboard metrics, missing tests, or incomplete acceptance evidence.
|
||||
---
|
||||
|
||||
# Review Business Delivery
|
||||
|
||||
## Core Principle
|
||||
|
||||
Review behavior and risk before wording. Findings must be evidence-based, severity-ranked, and tied to a verification action.
|
||||
|
||||
The review output should help the team decide whether to accept, conditionally accept, or reject the delivery.
|
||||
|
||||
## Inputs
|
||||
|
||||
Use any available inputs:
|
||||
|
||||
- Requirement scope and non-goals.
|
||||
- RBAC matrix and permission control plan.
|
||||
- State transition table and illegal transition list.
|
||||
- Audit SOP and exception-state list.
|
||||
- Dashboard metric dictionary and API acceptance record.
|
||||
- Code diff, API contract, test result, Browser verification record, or PR description.
|
||||
- Project rules and constraints.
|
||||
|
||||
If source evidence is missing, create an `证据缺口` section instead of guessing.
|
||||
|
||||
## Review Flow
|
||||
|
||||
1. Confirm delivery scope: what is being reviewed and what is outside scope.
|
||||
2. Check source evidence: paths, rules, design tables, test results, and verification records.
|
||||
3. Review permission risk: page/menu, button, backend API, and data scope.
|
||||
4. Review state risk: legal transitions, illegal transitions, terminal states, duplicate submits, and role restrictions.
|
||||
5. Review audit risk: action coverage, field completeness, masking, failure behavior, and consistency with business writes.
|
||||
6. Review exception risk: empty, missing, invalid, forbidden, duplicate, concurrent, and downstream failure states.
|
||||
7. Review dashboard risk: formula, filter, dimension, data source, permission, empty state, and manual calculation.
|
||||
8. Review tests and acceptance: commands, roles, sample data, browser evidence, and unresolved risks.
|
||||
9. Output findings sorted by severity.
|
||||
|
||||
## Severity
|
||||
|
||||
| Level | Meaning |
|
||||
| --- | --- |
|
||||
| P0 | Data loss, privilege bypass, irreversible wrong state, or release-blocking failure |
|
||||
| P1 | Security, permission, audit, or state-machine defect with realistic business impact |
|
||||
| P2 | Missing acceptance evidence, unclear metric, weak exception handling, or test gap |
|
||||
| P3 | Maintainability, naming, documentation, or minor consistency issue |
|
||||
|
||||
## Output Contract
|
||||
|
||||
```md
|
||||
## Review 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 模块 | 问题 | 证据 | 风险 | 修复建议 | 验收方式 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## 证据缺口
|
||||
|
||||
| 缺口 | 影响 | 需要谁补充 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 待确认
|
||||
|
||||
| 问题 | 决策人 | 建议默认值 |
|
||||
| --- | --- | --- |
|
||||
```
|
||||
|
||||
Use the templates and checklists in `assets/` when writing files.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
- Findings lead the response; summaries are secondary.
|
||||
- Every P0/P1 finding cites a source path, table row, endpoint, role, state, metric, or verification record.
|
||||
- Every finding has a concrete fix direction and acceptance method.
|
||||
- Review does not accept frontend-only security controls.
|
||||
- Missing tests or missing evidence are called out explicitly.
|
||||
- Unclear business rules are marked `待确认`, not invented.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Do not write "整体不错" before listing risks.
|
||||
- Do not merge all issues into one generic recommendation.
|
||||
- Do not downgrade permission bypass, illegal state transitions, or missing audit for critical actions.
|
||||
- Do not claim an issue is fixed without verification evidence.
|
||||
- Do not review only code style when the requested delivery is business behavior.
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "业务交付 Review"
|
||||
short_description: "审查权限状态审计异常态看板测试与验收风险"
|
||||
default_prompt: "Use $review-business-delivery to review complex business delivery artifacts for permission, state, audit, exception, and dashboard risks."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
-28
@@ -1,28 +0,0 @@
|
||||
# AI Review 报告模板
|
||||
|
||||
## Review 输入
|
||||
|
||||
- PR diff：
|
||||
- 需求说明：
|
||||
- rules：
|
||||
- 测试结果：
|
||||
- 历史问题：
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 文件/模块 | 问题 | 触发规则 | 风险 | 建议 | 测试/验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 需要谁确认 | 验证方式 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 是否建议合入
|
||||
|
||||
说明理由。
|
||||
|
||||
-59
@@ -1,59 +0,0 @@
|
||||
# 业务交付验收清单
|
||||
|
||||
本清单用于判断复杂业务模块是否达到可验收状态，适用于后台管理、审批流、运营系统、CRM、低代码二开和数据看板等项目。
|
||||
|
||||
## 项目理解
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 能说明模块边界 | 说明模块负责什么、不负责什么 | |
|
||||
| 能定位关键目录 | 能指出前端页面、API 层、后端入口、服务层和数据层位置 | |
|
||||
| 能区分事实和推断 | 对没有源码依据的业务规则标注为推断或待确认 | |
|
||||
| 能记录不确定点 | 不确定内容没有被包装成确定事实 | |
|
||||
|
||||
## 需求与接口
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 用户故事完整 | 覆盖主要角色、关键动作和限制条件 | |
|
||||
| 非目标范围明确 | 明确本次不做的能力、数据迁移、生产部署或外部集成 | |
|
||||
| 接口契约完整 | 覆盖列表、详情、新增、编辑、分配、状态、审计和看板 | |
|
||||
| 失败场景明确 | 每个关键接口至少有权限、参数、状态或数据不存在失败场景 | |
|
||||
| 验收方式明确 | 每个关键需求都有可执行检查方法 | |
|
||||
|
||||
## 权限与状态
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 权限矩阵完整 | 覆盖页面级、按钮级、接口级和数据范围 | |
|
||||
| 权限字符合理 | 命名统一，并标注为建议或源码事实 | |
|
||||
| 后端权限未缺失 | 没有用前端按钮隐藏替代后端接口控制 | |
|
||||
| 状态流转表完整 | 覆盖初始态、处理中、确认/审核态、终态和驳回态 | |
|
||||
| 非法流转明确 | 列出关键非法流转、拒绝原因和验收方式 | |
|
||||
|
||||
## 审计、异常态与看板
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 审计操作覆盖关键动作 | 创建、编辑、分配、状态流转、关闭/归档等关键动作被覆盖 | |
|
||||
| 审计字段可追溯 | 包含 actor、action、targetId、oldValue、newValue、source | |
|
||||
| 敏感信息处理 | oldValue/newValue 有脱敏说明 | |
|
||||
| 异常态可测试 | 权限不足、重复提交、非法状态、数据不存在、并发修改均覆盖 | |
|
||||
| 看板指标可计算 | 每个指标有口径、维度、过滤条件和数据来源建议 | |
|
||||
|
||||
## Review 与交付
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| Review 有证据 | 问题能回到路径、表格、接口、角色或业务规则 | |
|
||||
| 风险按严重程度排序 | 高风险问题优先展示 | |
|
||||
| 建议可行动 | 每条建议有修复方向和验收方式 | |
|
||||
| 交付物齐全 | 设计表、Review 报告、验证记录和未闭环事项完整 | |
|
||||
| 能沉淀资产 | 高频问题能转成规则、检查清单、Prompt、反例或 Skill | |
|
||||
|
||||
## 判定原则
|
||||
|
||||
- 优先看证据，不优先看文字是否漂亮。
|
||||
- 优先看权限、状态、审计、异常态，不只看 CRUD。
|
||||
- 优先看不确定点是否被诚实标出。
|
||||
- 优先看结论能否被角色账号、接口请求、样例数据或浏览器操作验证。
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# 审计日志检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建业务记录后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 分配记录 | 分配或转交记录原处理人和新处理人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
| 操作人 | actor_id 和 actor_name 可追溯 | |
|
||||
| 来源 | source 或 request_id 可追溯 | |
|
||||
| 脱敏 | 敏感字段不明文进入审计 | |
|
||||
| 失败处理 | 操作失败不写成功审计 | |
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# 异常态检查清单
|
||||
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示记录不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
| 参数缺失 | 返回参数错误，业务数据不变 | |
|
||||
| 并发修改 | 拒绝覆盖或提示刷新 | |
|
||||
| 看板无数据 | 图表显示空态，不显示假数据 | |
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 权限上线前检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 目标模块菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、分配、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内数据 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/分配 | |
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 状态流转检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 状态枚举 | 所有状态有统一枚举或字典 | |
|
||||
| 合法流转 | 状态流转表中的合法路径可执行 | |
|
||||
| 非法流转 | 非法路径被拒绝且状态不变 | |
|
||||
| 角色限制 | 不同角色只能执行被授权动作 | |
|
||||
| 前置条件 | 驳回原因、关闭条件、处理人、审批意见等校验完整 | |
|
||||
| 审计日志 | 每次成功流转写审计 | |
|
||||
| 重复提交 | 重复点击不会产生重复有效流转 | |
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
# 看板指标口径检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 指标含义 | 每个指标有业务解释 | |
|
||||
| 计算口径 | 每个指标有公式或筛选条件 | |
|
||||
| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 | |
|
||||
| 数据范围 | 不同角色的数据范围清楚 | |
|
||||
| 空数据 | 空数据展示为 0 或空态，不误导 | |
|
||||
| 分组一致性 | 分组总和能和总数对齐 | |
|
||||
| 权限 | 无看板权限不能访问接口 | |
|
||||
| 验收证据 | 至少有一组样例数据手工校验 | |
|
||||
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
# 看板接口验收清单
|
||||
|
||||
| 验收项 | 请求条件 | 通过标准 | 结果 |
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员或授权角色默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定业务类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
| 指标一致性 | 固定样例数据 | 与手工计算一致 | |
|
||||
-32
@@ -1,32 +0,0 @@
|
||||
# 阶段 Review Prompt
|
||||
|
||||
```text
|
||||
请对目标业务模块阶段交付物做 Review。
|
||||
|
||||
输入材料：
|
||||
- 模块名称：<填写>
|
||||
- 业务对象：<填写>
|
||||
- RBAC 权限矩阵
|
||||
- 权限控制方案
|
||||
- 状态流转表
|
||||
- 非法流转清单
|
||||
- 审计日志 SOP
|
||||
- 异常态清单
|
||||
- 看板指标字典
|
||||
- 看板接口验收记录
|
||||
- 测试结果或验证记录
|
||||
|
||||
输出表格：
|
||||
等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收
|
||||
|
||||
要求：
|
||||
1. 问题按 P0/P1/P2/P3 分级。
|
||||
2. 每个问题必须说明触发了哪条规则。
|
||||
3. 每条建议必须有验收方式。
|
||||
4. 输出不确定点和需要人工确认的内容。
|
||||
|
||||
约束：
|
||||
- 不要只说整体不错。
|
||||
- 不要直接改代码。
|
||||
- 不要把示例模块、示例角色或示例接口当成目标项目事实。
|
||||
```
|
||||
-27
@@ -1,27 +0,0 @@
|
||||
# 阶段 Review 报告
|
||||
|
||||
## Review 输入
|
||||
|
||||
- RBAC 权限矩阵：
|
||||
- 权限控制方案：
|
||||
- 状态流转表：
|
||||
- 非法流转清单：
|
||||
- 审计日志 SOP：
|
||||
- 异常态清单：
|
||||
- 看板指标字典：
|
||||
- 看板接口验收记录：
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| P1 | 权限 | 敏感操作只做前端按钮隐藏，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端直接调用接口完成高风险操作 | 后端补权限校验和数据范围校验 | 无权限账号直接请求返回 403 或业务拒绝 |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 影响 | 需要谁确认 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
name: track-review-fix-loop
|
||||
description: Use when turning review findings into a fix-tracking record, deciding whether findings are valid, mapping fixes to files, verifying results, documenting unresolved items, or deciding which issues should become reusable rules, checklists, prompts, examples, or team assets.
|
||||
---
|
||||
|
||||
# Track Review Fix Loop
|
||||
|
||||
## Core Principle
|
||||
|
||||
A review issue is not closed by saying "fixed". It closes only when the team records validity, changed artifacts, verification evidence, unresolved risk, and whether the lesson should become a reusable asset.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Review report with numbered findings.
|
||||
- Requirement or acceptance criteria.
|
||||
- Code diff, design document, generated tables, or changed files.
|
||||
- Test results, Browser verification evidence, API response samples, or manual validation notes.
|
||||
- Existing team rules, checklists, examples, and asset index.
|
||||
|
||||
If validation evidence is missing, mark the item as `未闭环`.
|
||||
|
||||
## Status Model
|
||||
|
||||
Use one of these statuses for each review item:
|
||||
|
||||
| Status | Meaning |
|
||||
| --- | --- |
|
||||
| `成立-已修复` | Finding is valid, changed artifacts are listed, and verification evidence exists |
|
||||
| `成立-暂不修复` | Finding is valid but deferred with reason, owner, and follow-up date |
|
||||
| `不成立` | Finding is invalid with evidence |
|
||||
| `需确认` | Finding depends on business or technical decision not available in current evidence |
|
||||
| `未闭环` | Fix is claimed but evidence is missing |
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Normalize review findings: ensure each issue has an ID, severity, module, risk, and suggested verification.
|
||||
2. Decide validity: `成立`, `不成立`, or `需确认`; cite evidence.
|
||||
3. Map valid fixes to changed files, tables, prompts, rules, or templates.
|
||||
4. Verify each fix using commands, API checks, browser steps, role-based tests, or manual calculation.
|
||||
5. Identify regressions: related permissions, states, audit actions, dashboard metrics, and exception states to re-check.
|
||||
6. Decide asset sedimentation: rule, checklist, prompt, Command, Skill, example, or no asset.
|
||||
7. Output unresolved items with owner and next step.
|
||||
|
||||
## Output Contract
|
||||
|
||||
```md
|
||||
## 修复闭环结论
|
||||
|
||||
完成 / 部分完成 / 未完成
|
||||
|
||||
## 修复记录
|
||||
|
||||
| Review 编号 | 等级 | 问题 | 状态 | 修改文件/产物 | 验证证据 | 剩余风险 | 资产沉淀 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## 未闭环事项
|
||||
|
||||
| 编号 | 原因 | 负责人 | 下一步 | 截止时间 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
|
||||
## 资产更新建议
|
||||
|
||||
| 来源问题 | 资产类型 | 建议文件 | 更新内容 |
|
||||
| --- | --- | --- | --- |
|
||||
```
|
||||
|
||||
Use `assets/修复记录.template.md` and `assets/Review修复闭环检查清单.md` when creating files.
|
||||
|
||||
## Asset Decision Guide
|
||||
|
||||
| If the issue is... | Asset |
|
||||
| --- | --- |
|
||||
| Repeated project convention violation | rule |
|
||||
| Repeated review checklist miss | checklist |
|
||||
| Reusable question or generation pattern | prompt |
|
||||
| One-step repeatable agent action | command |
|
||||
| Multi-step judgment workflow | skill |
|
||||
| Good or bad teaching sample | example |
|
||||
|
||||
## Quality Gates
|
||||
|
||||
- Every fixed issue has verification evidence.
|
||||
- Every deferred issue has owner and next step.
|
||||
- Every invalid issue has source evidence, not opinion.
|
||||
- P0/P1 issues cannot be marked complete without direct verification.
|
||||
- Asset updates are specific file suggestions, not vague "沉淀经验".
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Do not close issues with "已修复" without evidence.
|
||||
- Do not erase invalid findings; keep why they are invalid.
|
||||
- Do not mark business decisions as technical fixes.
|
||||
- Do not create a Skill for a one-off checklist item.
|
||||
- Do not ignore regressions around permissions, state transitions, audit logs, and dashboard metrics.
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "Review 修复闭环"
|
||||
short_description: "跟踪Review问题成立判断修复验证未闭环与资产沉淀"
|
||||
default_prompt: "Use $track-review-fix-loop to turn review findings into verified fixes, unresolved decisions, and reusable team assets."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
-12
@@ -1,12 +0,0 @@
|
||||
# Review 修复闭环检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 问题编号 | 每个 Review 问题有编号 | |
|
||||
| 成立判断 | 每个问题说明是否成立 | |
|
||||
| 修改说明 | 成立问题说明修改文件和内容 | |
|
||||
| 验证结果 | 每个修复有验证证据 | |
|
||||
| 未修复说明 | 暂不修复的问题有原因和后续计划 | |
|
||||
| 资产沉淀 | 有复用价值的问题已进入检查清单或反例库 | |
|
||||
| 回归检查 | 修复后重新检查相关权限/状态/审计/看板 | |
|
||||
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
# Review 修复记录
|
||||
|
||||
| Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| R01 | 敏感操作接口缺少后端权限校验 | 是 | `<Controller/API handler>` | 增加权限校验和数据范围校验 | 无权限请求被拒绝 | 权限检查清单 |
|
||||
| R02 | 终态记录可被直接改回处理中 | 是 | `<Service/Domain logic>` | 补非法流转校验 | terminal -> processing 失败 | 状态流转检查清单 |
|
||||
| R03 | 看板关闭周期口径不清 | 是 | 指标字典/看板接口 | 明确 create_time 到 close_time | 指标说明已更新 | 看板指标口径清单 |
|
||||
-24
@@ -1,24 +0,0 @@
|
||||
# 修复记录生成 Prompt
|
||||
|
||||
```text
|
||||
请根据阶段 Review 报告生成修复记录。
|
||||
|
||||
输入材料：
|
||||
- Review 报告：<粘贴>
|
||||
- 已完成修改说明：<粘贴>
|
||||
- 验证结果：<粘贴>
|
||||
|
||||
输出表格：
|
||||
Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀
|
||||
|
||||
要求：
|
||||
1. 如果问题不成立，说明理由和依据。
|
||||
2. 如果问题成立，说明修改了哪些文件。
|
||||
3. 每条修复必须有验证结果。
|
||||
4. 判断是否需要沉淀为资产，例如权限检查清单、状态流转检查清单、审计日志检查清单。
|
||||
|
||||
约束：
|
||||
- 不要模糊写“已修复”。
|
||||
- 没有验证结果的修复不能算完成。
|
||||
```
|
||||
|
||||
-31
@@ -1,31 +0,0 @@
|
||||
# 审计日志缺失反例
|
||||
|
||||
## 场景
|
||||
|
||||
业务记录分配处理人成功，但没有记录审计日志。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 操作 | 结果 |
|
||||
| --- | --- |
|
||||
| 张三将记录分配给李四 | 处理人变更成功 |
|
||||
| 查询审计日志 | 没有处理人变更记录 |
|
||||
|
||||
## 风险
|
||||
|
||||
无法追溯处理人变化，出现延误或争议时无法定位责任。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 分配成功后写审计日志。
|
||||
2. 记录原处理人、新处理人、操作人、时间、来源。
|
||||
3. 分配失败不写成功审计。
|
||||
4. 多步写入需要事务一致性。
|
||||
|
||||
## 验收
|
||||
|
||||
| 操作 | 预期 |
|
||||
| --- | --- |
|
||||
| 分配成功 | 审计列表出现 ASSIGN 或同等业务动作记录 |
|
||||
| 分配失败 | 不出现成功审计 |
|
||||
| 查询详情 | 审计记录可在详情页查看 |
|
||||
-32
@@ -1,32 +0,0 @@
|
||||
# 权限遗漏反例
|
||||
|
||||
## 场景
|
||||
|
||||
敏感删除或作废按钮在前端按权限隐藏，但后端接口没有权限校验。
|
||||
|
||||
## 问题代码表现
|
||||
|
||||
| 层级 | 表现 |
|
||||
| --- | --- |
|
||||
| 前端 | 普通业务账号看不到删除按钮 |
|
||||
| 后端 | 直接请求删除或作废接口仍可成功 |
|
||||
| 审计 | 删除记录可能缺失 |
|
||||
|
||||
## 风险
|
||||
|
||||
攻击者或误操作用户可以绕过前端直接调用接口删除或作废业务数据。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 后端删除接口增加权限校验。
|
||||
2. 删除前校验数据范围。
|
||||
3. 删除成功写审计日志。
|
||||
4. 无权限账号直接请求接口返回 403 或业务拒绝。
|
||||
|
||||
## 验收
|
||||
|
||||
| 账号 | 操作 | 预期 |
|
||||
| --- | --- | --- |
|
||||
| 管理员或授权角色 | 删除允许删除的数据 | 成功并写审计 |
|
||||
| 普通业务角色 | 直接请求删除接口 | 失败 |
|
||||
| 只读角色 | 前端访问删除按钮 | 不可见 |
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# 看板指标口径不清反例
|
||||
|
||||
## 场景
|
||||
|
||||
看板展示“平均完成周期”，但没有说明从哪个时间到哪个时间。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 指标 | 当前说明 |
|
||||
| --- | --- |
|
||||
| 平均完成周期 | 最近记录平均处理时间 |
|
||||
|
||||
## 风险
|
||||
|
||||
不同人理解不同：可能是创建到完成，也可能是开始处理到完成，导致管理判断失真。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 明确定义为 `completed_at - created_at`、`closed_at - created_at` 或其他确定口径。
|
||||
2. 明确是否排除未完成记录。
|
||||
3. 明确时间范围过滤字段。
|
||||
4. 用样例数据手工校验。
|
||||
|
||||
## 验收
|
||||
|
||||
| 样例 | 预期 |
|
||||
| --- | --- |
|
||||
| 记录 A 创建 1 日、完成 3 日 | 周期 2 天 |
|
||||
| 未完成记录 | 不计入平均完成周期 |
|
||||
| 过滤 7 月 | 只统计 7 月范围内符合口径的数据 |
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# 非法状态流转反例
|
||||
|
||||
## 场景
|
||||
|
||||
已完成或已关闭的业务记录可以直接被改回处理中。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 当前状态 | 动作 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 已关闭 | 开始处理 | 状态变成处理中 |
|
||||
|
||||
## 风险
|
||||
|
||||
终态记录被重新打开但没有重开原因、没有审计、没有负责人确认，导致统计和责任链失真。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. Service 层集中校验状态流转。
|
||||
2. 已完成或已关闭记录只能通过“重新打开”动作回到指定状态。
|
||||
3. 重新打开必须填写原因。
|
||||
4. 所有成功流转写审计日志。
|
||||
|
||||
## 验收
|
||||
|
||||
| 操作 | 预期 |
|
||||
| --- | --- |
|
||||
| closed -> processing | 失败，状态不变 |
|
||||
| closed -> reopen -> new | 成功，必须有原因 |
|
||||
| 重开成功 | 审计记录 oldValue=closed, newValue=new |
|
||||
Binary file not shown.
@@ -1,8 +1,8 @@
|
||||
# 客户 AI 工程 Skill 交付包
|
||||
# 客户 AI 工程资产交付包
|
||||
|
||||
本交付包提供 4 个可复用 AI 工程 Skill，覆盖真实项目中从项目约束生成、复杂业务设计、交付 Review 到修复闭环的完整流程。
|
||||
本包是第五、六天课程配套的正式资产交付物，用于把 AI 编程中的项目理解、约束提取、复杂业务设计、交付 Review 和修复闭环沉淀为可维护的团队资产。
|
||||
|
||||
这些 Skill 不是单次 Prompt，而是可安装、可复制、可随项目持续维护的团队资产。
|
||||
它不包含客户代码、服务地址、账号、令牌、真实业务数据或未经验证的项目结论。所有业务字段、权限码、接口和状态均以占位符表达，使用时必须从目标项目重新取证。
|
||||
|
||||
## 交付内容
|
||||
|
||||
@@ -10,37 +10,46 @@
|
||||
客户AI工程Skill交付包/
|
||||
├── README.md
|
||||
├── 安装说明.md
|
||||
├── 交付清单.md
|
||||
├── skills/
|
||||
│ ├── generate-project-constraints/
|
||||
│ ├── design-complex-business-module/
|
||||
│ ├── review-business-delivery/
|
||||
│ └── track-review-fix-loop/
|
||||
│ ├── generate-project-constraints/ # 提取项目规则与约束
|
||||
│ ├── project-knowledge-builder/ # 建立源码依据的项目知识库
|
||||
│ ├── design-complex-business-module/ # 设计权限、状态、审计、异常态和指标
|
||||
│ ├── review-business-delivery/ # 审查业务交付与变更风险
|
||||
│ └── track-review-fix-loop/ # 跟踪 Review 修复与验证闭环
|
||||
├── mcp-assets/
|
||||
│ ├── MCP能力契约.template.md
|
||||
│ └── MCP工具权限与验收清单.md
|
||||
└── examples/
|
||||
└── jeecgboot-work-order/
|
||||
└── jeecgboot-official-vehicle/
|
||||
└── 公务用车取消派车案例.md
|
||||
```
|
||||
|
||||
## Skill 列表
|
||||
|
||||
| Skill | 用途 | 典型产物 |
|
||||
| -------------------------------- | ------------------------------------------------ | --------------------------------------------- |
|
||||
| `generate-project-constraints` | 从项目源码、配置、CI、文档中提取项目约束 | rules、约束提取表、验收清单 |
|
||||
| `design-complex-business-module` | 设计复杂业务模块的权限、状态、审计、异常态和看板 | RBAC 矩阵、状态流转表、审计 SOP、看板指标字典 |
|
||||
| `review-business-delivery` | 审查复杂业务交付物或 PR 的业务风险 | 阶段 Review 报告、风险清单、验收建议 |
|
||||
| `track-review-fix-loop` | 跟踪 Review 问题修复、验证和资产沉淀 | 修复记录、未闭环清单、资产更新建议 |
|
||||
| Skill | 解决的问题 | 典型产物 |
|
||||
|---|---|---|
|
||||
| `generate-project-constraints` | 从源码、配置、测试和 CI 中提取项目约束 | Rule、约束提取表、验收清单 |
|
||||
| `project-knowledge-builder` | 建立可追溯、可持续更新的项目知识库 | 项目地图、接口与权限索引、维护指南 |
|
||||
| `design-complex-business-module` | 设计高风险业务模块的工程边界 | 权限矩阵、状态流转表、审计 SOP、指标字典 |
|
||||
| `review-business-delivery` | 审查设计、代码或 PR 的业务风险 | Review 报告、风险清单、验收建议 |
|
||||
| `track-review-fix-loop` | 跟踪问题修复、验证和资产更新 | 修复记录、未闭环清单、资产更新建议 |
|
||||
|
||||
## 推荐使用顺序
|
||||
## MCP 资产
|
||||
|
||||
1. 使用 `generate-project-constraints` 为项目生成项目规则。
|
||||
2. 使用 `design-complex-business-module` 生成复杂业务设计资产。
|
||||
3. 使用 `review-business-delivery` 审查设计、代码或阶段交付物。
|
||||
4. 使用 `track-review-fix-loop` 跟踪修复、验证结果和资产沉淀。
|
||||
`mcp-assets/` 只提供能力契约和验收清单，不预置任何 MCP 服务地址、工具配置或凭据。接入外部能力前，必须明确输入输出、数据范围、权限、副作用、失败降级和验证夹具；写入、删除、发布和外发能力不应作为通用 Agent 的默认权限。
|
||||
|
||||
## 适用项目
|
||||
## 公务用车案例
|
||||
|
||||
适用于后台管理系统、低代码平台二开、CRM、工单、审批、运营系统、数据看板等企业业务项目。
|
||||
`examples/jeecgboot-official-vehicle/` 是基于现有 JeecgBoot 公务用车模块的单人训练案例。它展示如何把“取消派车时取消原因不能为空”的训练改造，转成源码依据、最小改动边界、验证证据和待确认项。
|
||||
|
||||
这些 Skill 不要求项目必须有 `CLAUDE.md`、`AGENTS.md` 或 `README.md`。如果项目没有显式说明文档，Skill 会从配置、源码模式、测试和 CI 中提取约束，并把无法证明的内容标记为待确认。
|
||||
该案例只说明已读取到的项目事实与已执行验证，不代表客户已提出相同业务需求，也不能直接替代目标项目的重新取证。
|
||||
|
||||
## 示例说明
|
||||
## 使用边界
|
||||
|
||||
`examples/jeecgboot-work-order/` 提供 JeecgBoot 工单案例参考，帮助理解这些 Skill 在真实后台项目中的使用方式。该示例不是通用 Skill 安装项。
|
||||
- Skill 保存可复用的判断流程，不保存某个项目的路径、字段、接口或权限码。
|
||||
- Rule、任务上下文契约、检查单、模板、Skill、Agent 和 MCP 职责不同，应保持单一权威位置。
|
||||
- 任何没有源码、日志、测试或明确规范支持的结论，都要标记为待确认。
|
||||
- 资产变更应检查行为变化、引用完整性、兼容性、迁移与回退，并使用完整、缺失、冲突和越界输入夹具复核。
|
||||
|
||||
安装与团队使用方式见 [安装说明.md](./安装说明.md)，本次正式交付范围见 [交付清单.md](./交付清单.md)。
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# 公务用车取消派车：影响分析与验证案例
|
||||
|
||||
## 案例边界
|
||||
|
||||
本案例来自当前 JeecgBoot 已接入的公务用车模块，用于单人练习“先取证、再限制改动范围、最后如实记录验证”的工作方式。
|
||||
|
||||
训练改造目标：取消已派车任务时，后端必须拒绝空值和全空白的取消原因。前端表单必填只用于减少误操作，不能替代 Service 入口的业务保护。
|
||||
|
||||
本案例不代表客户已提出相同需求；其他项目必须重新读取自身源码、配置和测试材料。
|
||||
|
||||
## 已确认的项目事实
|
||||
|
||||
| 维度 | 已读取依据 | 结论 |
|
||||
|---|---|---|
|
||||
| 前端入口 | `jeecgboot-vue3/src/views/official/vehicle/dispatch/DispatchList.vue`、`DispatchModal.vue`、`dispatch.data.ts` | 仅在有取消权限且派车状态为 `DISPATCHED` 时显示取消操作；弹窗已配置取消原因必填。 |
|
||||
| 前端 API | `jeecgboot-vue3/src/api/official/vehicle/dispatch.ts` | 页面外仍可直接调用取消接口，因此前端必填不是最终保护。 |
|
||||
| 后端入口 | `OfficialVehicleDispatchController.java`、`OfficialVehicleDispatchServiceImpl.java` | Controller 负责权限与请求转交；Service 负责状态写入和车辆状态释放。 |
|
||||
| 取消参数 | `OfficialVehicleCancelDispatchVo.java` | 请求体包含派车 ID 与取消原因，原有参数对象未限制空白文本。 |
|
||||
| 测试基座 | `OfficialVehicleDispatchControllerTest.java`、模块 `pom.xml` | 模块具备 JUnit 测试基础，原用例未覆盖空白取消原因。 |
|
||||
|
||||
## 可直接复用的任务上下文契约
|
||||
|
||||
```text
|
||||
请基于当前打开的项目，且只基于实际读取到的源码，完成一次变更影响分析；不要修改代码，不要猜测项目外逻辑。
|
||||
|
||||
训练目标：取消已派车任务时，取消原因必须为非空文本；前端必填不能替代后端业务保护。
|
||||
|
||||
请读取前端页面、前端 API、后端 Controller、Service、参数对象、实体、现有测试、模块构建配置和必要数据库脚本。
|
||||
|
||||
请输出：已读取源码；已确认事实及文件依据；必须检查的模块；接口、数据、权限、状态、配置和测试影响；明确不改动项；不超过四步的最小改动计划；人工待确认项。
|
||||
|
||||
要求：事实与推测分开；没有源码或验证证据时标记待确认；不编造测试结果；不直接实施修改。
|
||||
```
|
||||
|
||||
## 实际改动与证据
|
||||
|
||||
| 项目 | 记录 |
|
||||
|---|---|
|
||||
| 最小改动 | 在 `OfficialVehicleDispatchServiceImpl.cancel` 的状态写入前加入取消原因非空校验。 |
|
||||
| 对应测试 | 新增 Service 定向测试，传入全空白取消原因并断言请求被拒绝。 |
|
||||
| 已执行验证 | Maven 定向测试已执行成功，定向 Service 测试通过。 |
|
||||
| 保持不变 | 前端必填、既有取消权限、审计注解、车辆状态释放逻辑和数据库表结构未修改。 |
|
||||
|
||||
## 结论边界
|
||||
|
||||
下列事项没有被本案例写成“已通过”：实际数据库中非空取消原因的正常取消回归、HTTP 响应映射、浏览器提示、审计记录和车辆状态的集成环境验证。
|
||||
|
||||
这正是本案例的核心要求：已有证据支持多大的结论，就只形成多大的结论。
|
||||
@@ -1,44 +0,0 @@
|
||||
# JeecgBoot 工单模块开发审查 Skill
|
||||
|
||||
## 触发场景
|
||||
|
||||
涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。
|
||||
|
||||
## 输入材料
|
||||
|
||||
- PR diff 或相关文件。
|
||||
- 工单需求说明。
|
||||
- 数据模型与接口契约。
|
||||
- 当前 rules。
|
||||
- 前端页面文件。
|
||||
- API 模块文件。
|
||||
- 后端 Controller / Service。
|
||||
- 权限矩阵。
|
||||
- 状态流转表。
|
||||
- 审计日志 SOP。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 识别需求范围和非目标范围。
|
||||
2. 检查字段、接口契约和页面状态是否完整。
|
||||
3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态。
|
||||
4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限。
|
||||
5. 检查操作日志、数据权限和测试缺口。
|
||||
6. 检查看板指标口径和接口验收记录。
|
||||
7. 输出风险、不确定点和验收建议。
|
||||
|
||||
## 输出格式
|
||||
|
||||
- 需求范围确认。
|
||||
- 接口契约问题表。
|
||||
- 代码生成 Review 清单。
|
||||
- 权限风险表。
|
||||
- 状态流转风险表。
|
||||
- 审计日志风险表。
|
||||
- 测试缺口清单。
|
||||
- 不确定点清单。
|
||||
|
||||
## 验收标准
|
||||
|
||||
每个关键结论必须标注文件、函数、注解、配置或调用链依据。每条建议必须有验收方式。
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
# MCP 工具权限与验收清单
|
||||
|
||||
## 接入前
|
||||
|
||||
- [ ] 已确认该能力确实需要 MCP，而非 CLI、Rule、任务上下文契约 或 Skill。
|
||||
- [ ] 每个工具都有用途、输入、输出、副作用和错误语义说明。
|
||||
- [ ] 已确认数据范围、鉴权、审计和脱敏要求。
|
||||
- [ ] 未将密钥、Token、账号、完整个人信息或内部地址写入配置、示例或日志。
|
||||
- [ ] 已明确只读、可逆写入和不可逆操作，未根据工具名称猜测性质。
|
||||
|
||||
## Agent 授权
|
||||
|
||||
- [ ] 每个自定义 Agent 只绑定完成职责所需的 MCP 工具。
|
||||
- [ ] 读取受限信息时，调用身份和数据范围可被 MCP 服务校验。
|
||||
- [ ] 写入、删除、发布和外发操作不属于通用 Agent 默认权限。
|
||||
- [ ] 有副作用操作具备二次确认、幂等或明确的重复调用处理。
|
||||
- [ ] Agent 在 MCP 失败时输出“外部事实未取得”，不编造结果。
|
||||
|
||||
## 验收夹具
|
||||
|
||||
- [ ] 合法完整请求：返回结构、来源时间和范围符合契约。
|
||||
- [ ] 缺少必填参数：拒绝并指出缺口。
|
||||
- [ ] 越权请求：拒绝或触发确认，不泄露超范围数据。
|
||||
- [ ] 鉴权失败、限流、超时和服务错误：错误类型可区分。
|
||||
- [ ] 返回空结果：与工具故障明确区分。
|
||||
- [ ] 敏感字段：按契约脱敏，审计日志不暴露秘密信息。
|
||||
- [ ] 重复调用：符合幂等设计或被安全阻止。
|
||||
|
||||
## 结论
|
||||
|
||||
- [ ] 可接入：契约、权限、审计、失败处理和验收夹具完整。
|
||||
- [ ] 待确认：记录缺失的外部规范或验证材料。
|
||||
- [ ] 不接入：说明改用 CLI、Skill 或人工流程的原因。
|
||||
@@ -0,0 +1,34 @@
|
||||
# MCP 能力契约
|
||||
|
||||
## 基本信息
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| 服务名称 | `<名称>` |
|
||||
| 接入目的 | `<要解决的外部事实或操作>` |
|
||||
| 适用场景 | `<何时允许使用>` |
|
||||
| 不适用场景 | `<何时不得使用>` |
|
||||
| 来源依据 | `<接口文档、系统规范或已验证记录>` |
|
||||
|
||||
## 工具清单
|
||||
|
||||
| 工具 | 用途 | 输入契约 | 输出契约 | 副作用 | 权限与确认 | 错误语义 | 审计与脱敏 |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| `<tool>` | `<用途>` | `<必填、格式、范围>` | `<字段、时效、空值>` | `只读 / 可逆写入 / 不可逆` | `<调用资格与确认>` | `<鉴权、限流、超时等>` | `<留痕字段与脱敏规则>` |
|
||||
|
||||
## Agent 绑定边界
|
||||
|
||||
- 允许调用的自定义 Agent：`<名称或角色>`。
|
||||
- 不允许调用的 Agent：`<名称或角色>`。
|
||||
- Agent 调用前必须具备的运行时事实：`<数据范围、目标对象、确认信息>`。
|
||||
- Agent 调用后必须输出：`<来源、时间、结果、失败或待确认>`。
|
||||
|
||||
## 停止与降级
|
||||
|
||||
| 情况 | MCP 或 Agent 的行为 |
|
||||
|---|---|
|
||||
| 缺少关键输入 | 拒绝调用并列出字段缺口 |
|
||||
| 鉴权或数据范围不满足 | 拒绝调用，不尝试扩大权限 |
|
||||
| 限流、超时或服务不可用 | 区分故障类型，标记外部事实未取得 |
|
||||
| 有副作用但未确认 | 停止并请求确认 |
|
||||
| 返回敏感信息 | 按规则脱敏，避免写入任务记录或日志 |
|
||||
@@ -0,0 +1,29 @@
|
||||
# MCP 能力资产包
|
||||
|
||||
本目录用于沉淀可被 Agent 调用的外部能力边界，不保存任何服务地址、访问令牌、账号、内部域名或业务数据。
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 需要跨系统读取经授权的事实、日志或文档。
|
||||
- 需要调用具有结构化输入输出的外部工具。
|
||||
- 需要将浏览器、数据库、内部平台或其他服务能力提供给 Agent。
|
||||
|
||||
## 不适用场景
|
||||
|
||||
- 已有稳定命令且不需要交互式工具调用的任务，优先使用 CLI。
|
||||
- 只有知识、流程、模板或检查清单的任务，优先沉淀为 Rule、任务上下文契约或 Skill。
|
||||
- 未确认数据范围、鉴权方式、审计要求或副作用的外部服务。
|
||||
|
||||
## 使用顺序
|
||||
|
||||
1. 使用 `MCP能力契约.template.md` 描述每个拟接入的服务与工具。
|
||||
2. 使用 `MCP工具权限与验收清单.md` 审查权限、敏感数据、错误和副作用。
|
||||
3. 为完整请求、缺参、越权、故障和脱敏结果准备验证夹具。
|
||||
4. 只有契约与验收都满足时，才将对应工具分配给自定义 Agent 或 Skill。
|
||||
|
||||
## 基本原则
|
||||
|
||||
- 不根据工具名称推断只读或安全性。
|
||||
- 外部工具失败时，结论必须标记为“外部事实未取得”。
|
||||
- 写入、删除、发布和外发能力不应作为通用 Agent 的默认权限。
|
||||
- 日志、示例和夹具不得包含密钥、Token、账号、完整个人信息或内部地址。
|
||||
+13
-13
@@ -1,16 +1,16 @@
|
||||
# 工单 RBAC 权限矩阵
|
||||
# 业务对象 RBAC 权限矩阵
|
||||
|
||||
| 功能点 | 管理员 | 工单负责人 | 研发处理人 | 测试验证人 | 只读观察者 | 权限字符建议 | 备注 |
|
||||
| 功能点 | 管理员 | 业务对象负责人 | 研发处理人 | 测试验证人 | 只读观察者 | 权限字符建议 | 备注 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 查看列表 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | work:order:list | 按数据范围 |
|
||||
| 查看详情 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | work:order:query | 仅可见范围 |
|
||||
| 新建工单 | 允许 | 允许 | 允许 | 允许 | 拒绝 | work:order:add | |
|
||||
| 编辑工单 | 允许 | 条件允许 | 条件允许 | 拒绝 | 拒绝 | work:order:edit | 状态限制 |
|
||||
| 指派负责人 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | work:order:assign | |
|
||||
| 状态流转 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | work:order:transition | 按状态 |
|
||||
| 关闭工单 | 允许 | 条件允许 | 拒绝 | 条件允许 | 拒绝 | work:order:close | 测试验证后 |
|
||||
| 删除工单 | 允许 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | work:order:delete | 高危操作 |
|
||||
| 查看审计日志 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | work:order:audit | |
|
||||
| 查看看板 | 允许 | 允许 | 条件允许 | 条件允许 | 条件允许 | work:order:dashboard | 按数据范围 |
|
||||
| 导出数据 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | work:order:export | |
|
||||
| 查看列表 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | <module>:list | 按数据范围 |
|
||||
| 查看详情 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | <module>:query | 仅可见范围 |
|
||||
| 新建业务对象 | 允许 | 允许 | 允许 | 允许 | 拒绝 | <module>:add | |
|
||||
| 编辑业务对象 | 允许 | 条件允许 | 条件允许 | 拒绝 | 拒绝 | <module>:edit | 状态限制 |
|
||||
| 指派负责人 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | <module>:assign | |
|
||||
| 状态流转 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | <module>:transition | 按状态 |
|
||||
| 关闭业务对象 | 允许 | 条件允许 | 拒绝 | 条件允许 | 拒绝 | <module>:close | 测试验证后 |
|
||||
| 删除业务对象 | 允许 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | <module>:delete | 高危操作 |
|
||||
| 查看审计日志 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | <module>:audit | |
|
||||
| 查看看板 | 允许 | 允许 | 条件允许 | 条件允许 | 条件允许 | <module>:dashboard | 按数据范围 |
|
||||
| 导出数据 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | <module>:export | |
|
||||
|
||||
|
||||
+4
-4
@@ -1,11 +1,11 @@
|
||||
# RBAC 权限矩阵生成 Prompt
|
||||
# RBAC 权限矩阵生成 任务上下文契约
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。
|
||||
请基于 目标业务模块设计 RBAC 权限矩阵。
|
||||
|
||||
输入材料：
|
||||
- 工单模块需求：<粘贴需求>
|
||||
- 角色列表：管理员、工单负责人、研发处理人、测试验证人、只读观察者
|
||||
- 业务模块需求：<粘贴需求>
|
||||
- 角色列表：管理员、业务对象负责人、研发处理人、测试验证人、只读观察者
|
||||
- 功能点：查看列表、查看详情、新建、编辑、指派、状态流转、关闭、删除、查看审计、查看看板、导出
|
||||
- 项目依据：<粘贴权限、路由、菜单相关路径>
|
||||
|
||||
|
||||
+5
-5
@@ -1,14 +1,14 @@
|
||||
# 工单审计日志 SOP
|
||||
# 业务对象审计日志 SOP
|
||||
|
||||
## 记录原则
|
||||
|
||||
所有会改变工单关键业务状态、负责人、可见性或结论的动作都必须记录审计日志。
|
||||
所有会改变业务对象关键业务状态、负责人、可见性或结论的动作都必须记录审计日志。
|
||||
|
||||
## 审计字段
|
||||
|
||||
| 字段 | 含义 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| ticket_id | 工单 ID | WO-001 |
|
||||
| <business_id> | 业务对象 ID | <业务编号> |
|
||||
| actor_id | 操作人 ID | 1001 |
|
||||
| actor_name | 操作人名称 | zhangsan |
|
||||
| action | 操作类型 | ASSIGN |
|
||||
@@ -23,12 +23,12 @@
|
||||
|
||||
| 动作 | 写入时机 | oldValue | newValue | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 创建工单 | 创建成功后 | 空 | 工单摘要 | 审计列表可见 |
|
||||
| 创建业务对象 | 创建成功后 | 空 | 业务对象摘要 | 审计列表可见 |
|
||||
| 编辑字段 | 保存成功后 | 修改前字段 | 修改后字段 | 字段前后值正确 |
|
||||
| 指派负责人 | 指派成功后 | 原负责人 | 新负责人 | 审计记录负责人变化 |
|
||||
| 状态流转 | 状态变更成功后 | 原状态 | 新状态 | 审计记录状态变化 |
|
||||
| 评论新增 | 评论保存后 | 空 | 评论摘要 | 审计记录评论动作 |
|
||||
| 关闭工单 | 关闭成功后 | 原状态 | 已关闭 | 审计记录关闭时间 |
|
||||
| 关闭业务对象 | 关闭成功后 | 原状态 | 已关闭 | 审计记录关闭时间 |
|
||||
|
||||
## 验收方式
|
||||
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建工单后能查询审计记录 | |
|
||||
| 创建记录 | 创建业务对象后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 指派记录 | 指派负责人记录原负责人和新负责人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示工单不存在，页面不崩溃 | |
|
||||
| 详情不存在 | 提示业务对象不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
|
||||
+2
-2
@@ -1,9 +1,9 @@
|
||||
# 工单异常态清单
|
||||
# 业务对象异常态清单
|
||||
|
||||
| 场景 | 触发条件 | 前端表现 | 后端响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 权限不足 | 无权限操作 | 按钮不可见或提示无权限 | 403 或业务拒绝 | 不完成操作 |
|
||||
| 工单不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 |
|
||||
| 业务对象不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 |
|
||||
| 非法状态流转 | closed -> processing | 提示非法流转 | 状态不变 | 数据状态不变 |
|
||||
| 重复提交 | 连续点击提交 | 按钮 loading/禁用 | 只处理一次 | 只生成一条有效审计 |
|
||||
| 参数缺失 | 驳回缺少原因 | 表单校验提示 | 参数错误 | 不改变状态 |
|
||||
|
||||
+3
-3
@@ -1,14 +1,14 @@
|
||||
# 异常态补齐 Prompt
|
||||
# 异常态补齐 任务上下文契约
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块，列出状态流转、指派、删除、查询详情、审计日志、看板相关的异常态和防御性逻辑。
|
||||
请基于 目标业务模块，列出状态流转、指派、删除、查询详情、审计日志、看板相关的异常态和防御性逻辑。
|
||||
|
||||
输出表格：
|
||||
场景 | 触发条件 | 前端表现 | 后端响应 | 用户提示 | 测试点 | 验收
|
||||
|
||||
必须覆盖：
|
||||
- 权限不足
|
||||
- 工单不存在
|
||||
- 业务对象不存在
|
||||
- 非法状态流转
|
||||
- 重复提交
|
||||
- 参数缺失
|
||||
|
||||
+2
-2
@@ -2,10 +2,10 @@
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 工单菜单只对授权角色可见 | |
|
||||
| 菜单权限 | 业务对象菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内工单 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内业务对象 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/指派 | |
|
||||
|
||||
+8
-8
@@ -1,12 +1,12 @@
|
||||
# 工单权限控制方案
|
||||
# 业务对象权限控制方案
|
||||
|
||||
| 操作 | 前端入口 | 权限字符 | 后端接口 | 后端校验 | 数据权限 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 新增工单 | 新增按钮 | work:order:add | /workOrder/add | 权限注解 | 无 | 无权限账号看不到按钮且直接请求失败 |
|
||||
| 编辑工单 | 编辑按钮 | work:order:edit | /workOrder/edit | 权限注解 + 状态校验 | 负责人/创建人范围 | 越权账号返回 403 或业务拒绝 |
|
||||
| 指派负责人 | 指派按钮 | work:order:assign | /workOrder/assign | 权限注解 | 管理员/负责人范围 | 普通研发无法指派他人 |
|
||||
| 状态流转 | 状态按钮 | work:order:transition | /workOrder/transition | 权限注解 + 状态机校验 | 相关工单范围 | 非法流转失败 |
|
||||
| 删除工单 | 删除按钮 | work:order:delete | /workOrder/delete | 权限注解 | 管理员范围 | 非管理员返回 403 |
|
||||
| 查看审计 | 审计页签 | work:order:audit | /workOrder/audit/list | 权限注解 | 相关工单范围 | 无权限不可见且接口拒绝 |
|
||||
| 看板 | 看板菜单 | work:order:dashboard | /workOrder/dashboard | 权限注解 | 数据范围过滤 | 不同角色数据范围不同 |
|
||||
| 新增业务对象 | 新增按钮 | <module>:add | /<module>/add | 权限注解 | 无 | 无权限账号看不到按钮且直接请求失败 |
|
||||
| 编辑业务对象 | 编辑按钮 | <module>:edit | /<module>/edit | 权限注解 + 状态校验 | 负责人/创建人范围 | 越权账号返回 403 或业务拒绝 |
|
||||
| 指派负责人 | 指派按钮 | <module>:assign | /<module>/assign | 权限注解 | 管理员/负责人范围 | 普通研发无法指派他人 |
|
||||
| 状态流转 | 状态按钮 | <module>:transition | /<module>/transition | 权限注解 + 状态机校验 | 相关业务对象范围 | 非法流转失败 |
|
||||
| 删除业务对象 | 删除按钮 | <module>:delete | /<module>/delete | 权限注解 | 管理员范围 | 非管理员返回 403 |
|
||||
| 查看审计 | 审计页签 | <module>:audit | /<module>/audit/list | 权限注解 | 相关业务对象范围 | 无权限不可见且接口拒绝 |
|
||||
| 看板 | 看板菜单 | <module>:dashboard | /<module>/dashboard | 权限注解 | 数据范围过滤 | 不同角色数据范围不同 |
|
||||
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
# 权限控制方案生成 Prompt
|
||||
# 权限控制方案生成 任务上下文契约
|
||||
|
||||
```text
|
||||
请基于工单模块 RBAC 权限矩阵，生成 JeecgBoot 权限控制方案。
|
||||
请基于业务模块 RBAC 权限矩阵，生成 JeecgBoot 权限控制方案。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵：<粘贴>
|
||||
|
||||
+2
-2
@@ -1,8 +1,8 @@
|
||||
# 工单状态流转表
|
||||
# 业务对象状态流转表
|
||||
|
||||
| 当前状态 | 动作 | 目标状态 | 允许角色 | 前置条件 | 后置动作 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 新建 | 指派 | 新建 | 管理员/负责人 | 工单未关闭 | 写审计日志 | 指派人变化且状态不变 |
|
||||
| 新建 | 指派 | 新建 | 管理员/负责人 | 业务对象未关闭 | 写审计日志 | 指派人变化且状态不变 |
|
||||
| 新建 | 开始处理 | 处理中 | 研发处理人/负责人 | 已指派处理人 | 写审计日志 | 状态变为处理中 |
|
||||
| 处理中 | 提交验证 | 待验证 | 研发处理人/负责人 | 处理说明不为空 | 写审计日志 | 状态变为待验证 |
|
||||
| 待验证 | 验证通过 | 已关闭 | 测试验证人/负责人 | 验证结果通过 | 写审计日志和关闭时间 | 状态变为已关闭 |
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
# 状态流转设计 Prompt
|
||||
# 状态流转设计 任务上下文契约
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计状态流转规则。
|
||||
请为 目标业务模块设计状态流转规则。
|
||||
|
||||
状态候选：
|
||||
- 新建
|
||||
|
||||
+9
-9
@@ -1,13 +1,13 @@
|
||||
# 工单看板指标字典
|
||||
# 业务对象看板指标字典
|
||||
|
||||
| 指标 | 含义 | 口径 | 数据来源 | 展示方式 | 权限 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 工单总数 | 当前筛选范围内工单数量 | count(ticket_id) | 工单表 | 指标卡 | 看板权限 | 与列表同条件数量一致 |
|
||||
| 未关闭工单数 | 状态不是已关闭的数量 | status != closed | 工单表 | 指标卡 | 看板权限 | 过滤状态验证 |
|
||||
| 平均关闭周期 | 从创建到关闭平均耗时 | avg(close_time - create_time) | 工单表 | 指标卡/趋势 | 看板权限 | 抽样计算一致 |
|
||||
| 按优先级分布 | 高中低优先级数量 | group by priority | 工单表/字典 | 饼图/柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 按类型分布 | 缺陷/需求/支持数量 | group by type | 工单表/字典 | 柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 缺陷趋势 | 按日期统计缺陷工单 | type=bug group by date | 工单表 | 折线图 | 看板权限 | 日期范围正确 |
|
||||
| 逾期工单数 | 超过 SLA 未关闭数量 | due_time < now and status != closed | 工单表 | 指标卡 | 看板权限 | SLA 口径明确 |
|
||||
| 人员处理负载 | 按负责人统计未关闭数量 | group by assignee | 工单表 | 排行榜 | 管理员/负责人 | 数据范围正确 |
|
||||
| 业务对象总数 | 当前筛选范围内业务对象数量 | count(<business_id>) | 业务对象表 | 指标卡 | 看板权限 | 与列表同条件数量一致 |
|
||||
| 未关闭业务对象数 | 状态不是已关闭的数量 | status != closed | 业务对象表 | 指标卡 | 看板权限 | 过滤状态验证 |
|
||||
| 平均关闭周期 | 从创建到关闭平均耗时 | avg(close_time - create_time) | 业务对象表 | 指标卡/趋势 | 看板权限 | 抽样计算一致 |
|
||||
| 按优先级分布 | 高中低优先级数量 | group by priority | 业务对象表/字典 | 饼图/柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 按类型分布 | 缺陷/需求/支持数量 | group by type | 业务对象表/字典 | 柱状图 | 看板权限 | 分组总和等于总数 |
|
||||
| 缺陷趋势 | 按日期统计缺陷业务对象 | type=bug group by date | 业务对象表 | 折线图 | 看板权限 | 日期范围正确 |
|
||||
| 逾期业务对象数 | 超过 SLA 未关闭数量 | due_time < now and status != closed | 业务对象表 | 指标卡 | 看板权限 | SLA 口径明确 |
|
||||
| 人员处理负载 | 按负责人统计未关闭数量 | group by assignee | 业务对象表 | 排行榜 | 管理员/负责人 | 数据范围正确 |
|
||||
|
||||
|
||||
+5
-5
@@ -1,16 +1,16 @@
|
||||
# 看板指标设计 Prompt
|
||||
# 看板指标设计 任务上下文契约
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计研发效能看板指标。
|
||||
请为 目标业务模块设计研发效能看板指标。
|
||||
|
||||
指标方向：
|
||||
- 工单总数
|
||||
- 未关闭工单数
|
||||
- 业务对象总数
|
||||
- 未关闭业务对象数
|
||||
- 平均关闭周期
|
||||
- 按优先级分布
|
||||
- 按类型分布
|
||||
- 缺陷趋势
|
||||
- 逾期工单数
|
||||
- 逾期业务对象数
|
||||
- 人员处理负载
|
||||
|
||||
输出要求：
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
# 看板接口验收 Prompt
|
||||
# 看板接口验收 任务上下文契约
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单看板统计接口生成验收记录。
|
||||
请为 目标业务看板统计接口生成验收记录。
|
||||
|
||||
输入材料：
|
||||
- 看板指标字典：<粘贴>
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定工单类型 | 只统计对应类型 | |
|
||||
| 类型过滤 | 指定业务对象类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
|
||||
+2
-2
@@ -1,8 +1,8 @@
|
||||
# 工单看板接口验收记录
|
||||
# 业务对象看板接口验收记录
|
||||
|
||||
| 验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 工单总数 | 管理员 | 默认筛选 | 返回总数 | | | |
|
||||
| 业务对象总数 | 管理员 | 默认筛选 | 返回总数 | | | |
|
||||
| 空数据 | 管理员 + 无匹配条件 | 不存在的日期范围 | 返回空集合或 0 | | | |
|
||||
| 无权限 | 只读外角色 | 默认筛选 | 返回 403 或业务拒绝 | | | |
|
||||
| 时间过滤 | 管理员 | start/end | 只统计范围内数据 | | | |
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# 项目约束生成 Prompt
|
||||
# 项目约束生成 任务上下文契约
|
||||
|
||||
请为下面项目生成可复用的 AI 开发约束资产。
|
||||
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: project-knowledge-builder
|
||||
description: 当用户要求“项目知识库”“看项目”“整理项目”，或需要深度检查软件项目、构建/刷新项目知识库、创建入门文档、架构图、领域词汇表、ADR、API/配置/数据库生成索引或 RAG 友好仓库文档时使用。
|
||||
---
|
||||
|
||||
# 项目知识库构建
|
||||
|
||||
## 概览
|
||||
|
||||
构建一个有源码依据的项目知识库，帮助人和 AI 理解、扩展、排障和索引代码库。把知识库视为持续维护的系统资产，而不是 README 改写。
|
||||
|
||||
## 快速使用
|
||||
|
||||
用户不需要记住命令、脚本路径或 `$project-knowledge-builder`。
|
||||
|
||||
最短触发语即可：
|
||||
|
||||
- `项目知识库`
|
||||
|
||||
除非用户另有说明，将当前仓库作为目标，输出到 `docs/project-knowledge/`。由你运行 bundled inventory 脚本并写文档。只有用户明确要求命令行用法时，才展示手工命令。
|
||||
|
||||
## 语言和受众默认值
|
||||
|
||||
如果用户使用中文或要求中文，人类阅读的叙述文档默认使用中文：README、上下文、架构、运行、后端、前端、数据、认证/权限、扩展、排障、RAG 指南和 ADR。源码路径、类名、命令、API 路径、配置键、表名、权限码、元数据枚举值保持原样。
|
||||
|
||||
把新维护者作为主要受众。一个有用的知识库应该让新人无需额外辅导就能回答四个问题：
|
||||
|
||||
1. 这个项目是什么，主要模块在哪里？
|
||||
2. 如何本地运行，或如何识别当前运行模式？
|
||||
3. 如何找到某个功能对应的后端接口、前端页面、数据库表和权限码？
|
||||
4. 新增普通功能时通常需要修改什么，尤其是菜单/按钮权限？
|
||||
|
||||
生成索引不要为了友好而牺牲精确性。生成文件要便于机器刷新；叙述文档要便于人阅读。
|
||||
|
||||
## 核心规则
|
||||
|
||||
每个结论都必须能追溯到仓库，或明确标记为推断。优先使用源码路径、命令、生成索引和未解决问题清单，而不是自信散文。
|
||||
|
||||
## 工作流
|
||||
|
||||
1. **设定范围。** 确认或默认输出位置为 `docs/project-knowledge/`。如果用户提到 RAG、飞书/Lark、Dify、Notion、入门、架构 Review 或 API 文档，调整输出契约。
|
||||
2. **优先读取本地说明。** 检查根文档，以及 `AGENTS.md`、`CLAUDE.md`、`GEMINI.md`、`.codex/`、`.agents/`、包管理文件、构建文件、env 示例、Docker 文件和模块 README。
|
||||
3. **生成 inventory。** 对目标仓库运行本 Skill 的 `scripts/project_inventory.py`。用输出作为事实基础，再人工检查关键文件。
|
||||
4. **映射上下文。** 识别限界上下文、运行模式、主要模块、路径暗示的 owner、外部系统和数据存储。使用 `CONTEXT.md` 和 `CONTEXT-MAP.md` 风格文档。
|
||||
5. **提取生成索引。** 尽可能产出可机器刷新的文档：接口、前端路由/视图、配置键、环境变量、数据库表、权限码、定时任务、队列、扩展点。
|
||||
6. **编写人类指南。** 产出入门、架构、本地运行/部署、数据模型、认证/权限、扩展、排障和术语表文档。按用户语言书写；中文用户使用 `已观察来源`、`核心事实`、`操作影响`、`未知与风险` 等标题。
|
||||
7. **为真实决策创建 ADR。** 记录当前代码已经体现的重要架构决策。不要发明未来决策，除非标为 proposed。
|
||||
8. **添加 RAG 元数据指南。** 包括切块、source-path metadata、过期策略和排除规则。
|
||||
9. **验证。** 重新运行 inventory，扫描占位符、坏链接、过期路径和无依据结论。报告已验证内容和仍不确定内容。
|
||||
|
||||
## 输出契约
|
||||
|
||||
创建或升级完整知识库时读取 `references/output-contract_zh.md`。
|
||||
|
||||
最小有用集合：
|
||||
|
||||
```text
|
||||
docs/project-knowledge/
|
||||
├── README.md
|
||||
├── CONTEXT.md
|
||||
├── CONTEXT-MAP.md
|
||||
├── 01-architecture.md
|
||||
├── 02-runtime.md
|
||||
├── 03-backend.md
|
||||
├── 04-frontend.md
|
||||
├── 05-data-and-migrations.md
|
||||
├── 06-auth-permissions.md
|
||||
├── 07-extension-guide.md
|
||||
├── 08-troubleshooting.md
|
||||
├── 09-rag-indexing.md
|
||||
├── adr/
|
||||
│ └── 0001-current-runtime-architecture.md
|
||||
└── generated/
|
||||
├── project-inventory.md
|
||||
├── backend-endpoints.md
|
||||
├── frontend-routes.md
|
||||
├── config-reference.md
|
||||
├── database-dictionary.md
|
||||
└── permission-codes.md
|
||||
```
|
||||
|
||||
只有仓库较小或用户要求轻量产物时，才缩小范围。
|
||||
|
||||
## 来源依据标准
|
||||
|
||||
- 非显然结论必须内联引用来源路径。
|
||||
- 区分 **已观察**、**推断** 和 **未知**。
|
||||
- 不要凭记忆总结生成代码、依赖或配置，必须读取。
|
||||
- 如果不稳定事实需要外部文档，浏览一手来源并附链接。
|
||||
- 保留项目专用约定。如果仓库要求追踪注释、ADR 格式或 issue ID，记录并遵守。
|
||||
|
||||
## 跨平台兼容
|
||||
|
||||
当用户询问 macOS、Windows、Linux、CI、可移植性或跨机器安装/运行时，读取 `references/compatibility_zh.md`。bundled inventory 脚本面向 Python 3.9+，只使用标准库。
|
||||
|
||||
## Inventory 脚本
|
||||
|
||||
仅在手工刷新或用户询问命令时展示。请在目标仓库运行：
|
||||
|
||||
macOS/Linux：
|
||||
|
||||
```sh
|
||||
python3 /path/to/skill/scripts/project_inventory.py --root . --out docs/project-knowledge/generated
|
||||
```
|
||||
|
||||
Windows PowerShell：
|
||||
|
||||
```powershell
|
||||
py -3 C:\path\to\skill\scripts\project_inventory.py --root . --out docs\project-knowledge\generated
|
||||
```
|
||||
|
||||
常用选项：
|
||||
|
||||
```sh
|
||||
python3 /path/to/skill/scripts/project_inventory.py --root . --out ./kb-inventory --json
|
||||
python3 /path/to/skill/scripts/project_inventory.py --root . --out docs/project-knowledge/generated --max-files 20000
|
||||
```
|
||||
|
||||
脚本只是起点，不能替代阅读核心文件。编写叙述文档前，必须检查代表性文件。
|
||||
|
||||
## 质量门禁
|
||||
|
||||
最终回复前：
|
||||
|
||||
- 用适合平台的命令列出生成文档，例如 macOS/Linux 使用 `find docs/project-knowledge -type f | sort`，PowerShell 使用 `Get-ChildItem docs/project-knowledge -Recurse -File`。
|
||||
- 执行 `rg -n "TODO|TBD|待补|unknown|your/path|foo|bar" docs/project-knowledge`。
|
||||
- 编辑后重新运行 inventory 脚本。
|
||||
- 检查顶层 README 链接是否可解析。
|
||||
- 如果用户是中文用户，扫描叙述文档中是否仍有英文结构标题，例如 `Observed Sources`、`Core Facts`、`Operational Implications`、`Unknowns/Risks`、`Architecture`、`Runtime`、`Backend`、`Frontend`、`Troubleshooting`，除代码、元数据或生成输出外应翻译。
|
||||
- 检查新人可用性：README 给出阅读顺序；运行文档说明本地/Docker/云端模式；权限文档说明菜单/按钮权限流；扩展文档说明后端 CRUD、前端页面和权限变更。
|
||||
- 使用 `git status --short` 报告变更文件。
|
||||
|
||||
如果用户要求“深度”或“落地”，不要停在单页概览。必须交付生成索引和人类指南。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
# 跨平台兼容
|
||||
|
||||
在 macOS、Windows、Linux 或 CI 上运行或安装本 Skill 时使用本参考。
|
||||
|
||||
## 兼容性摘要
|
||||
|
||||
| 项目 | macOS | Linux | Windows |
|
||||
| --- | --- | --- | --- |
|
||||
| `SKILL.md` 工作流 | 支持 | 支持 | 支持 |
|
||||
| `project_inventory.py` | Python 3.9+ 支持 | Python 3.9+ 支持 | Python 3.9+ 支持 |
|
||||
| Python 依赖 | 仅标准库 | 仅标准库 | 仅标准库 |
|
||||
| 路径处理 | `pathlib` | `pathlib` | `pathlib` |
|
||||
| shell 依赖 | 脚本无依赖 | 脚本无依赖 | 脚本无依赖 |
|
||||
| 生成 Markdown 路径 | POSIX 风格相对路径 | POSIX 风格相对路径 | POSIX 风格相对路径 |
|
||||
|
||||
脚本故意使用带 `/` 分隔符的仓库相对路径，使生成 Markdown 在跨平台、GitHub URL 和 RAG metadata 中更稳定。
|
||||
|
||||
## Python 调用
|
||||
|
||||
macOS 和 Linux 通常使用：
|
||||
|
||||
```sh
|
||||
python3 skills/project-knowledge-builder/scripts/project_inventory.py --root . --out docs/project-knowledge/generated
|
||||
python skills/project-knowledge-builder/scripts/project_inventory.py --root . --out docs/project-knowledge/generated
|
||||
```
|
||||
|
||||
Windows PowerShell 通常使用：
|
||||
|
||||
```powershell
|
||||
py -3 skills\project-knowledge-builder\scripts\project_inventory.py --root . --out docs\project-knowledge\generated
|
||||
python skills\project-knowledge-builder\scripts\project_inventory.py --root . --out docs\project-knowledge\generated
|
||||
```
|
||||
|
||||
CI 应优先使用明确的 Python：
|
||||
|
||||
```sh
|
||||
python -m py_compile skills/project-knowledge-builder/scripts/project_inventory.py
|
||||
python skills/project-knowledge-builder/scripts/project_inventory.py --root . --out docs/project-knowledge/generated --json
|
||||
```
|
||||
|
||||
## 命令替换
|
||||
|
||||
| 任务 | macOS/Linux | Windows PowerShell |
|
||||
| --- | --- | --- |
|
||||
| 列出文档 | `find docs/project-knowledge -type f \| sort` | `Get-ChildItem docs/project-knowledge -Recurse -File \| Sort-Object FullName` |
|
||||
| 搜索占位符 | `rg -n "TODO|TBD" docs/project-knowledge` | `rg -n "TODO|TBD" docs/project-knowledge` |
|
||||
| 查看 git 状态 | `git status --short` | `git status --short` |
|
||||
| 删除临时输出 | `rm -rf ./kb-inventory` | `Remove-Item .\kb-inventory -Recurse -Force` |
|
||||
|
||||
优先使用 `rg`。如果环境中没有 `rg`，使用该平台可用的搜索工具。
|
||||
|
||||
## Skill 示例中应避免
|
||||
|
||||
- 在应支持 Windows 的命令中写死 `/tmp` 路径。
|
||||
- 在面向用户的说明中只给 POSIX 命令链，例如 `cmd1 && cmd2`，而不给 PowerShell 等价方式。
|
||||
- 假设 shell glob 在 zsh、bash、PowerShell、cmd 中行为一致。
|
||||
- 依赖 shebang 可执行行为的 Python 用法；Windows 用户应调用 `py -3 script.py`。
|
||||
|
||||
## 已知限制
|
||||
|
||||
- Java endpoint 提取基于正则，故意保持保守。它不会完整解析常量、组合注解或继承的 controller mapping。
|
||||
- SQL 表提取查找 `CREATE TABLE`；动态创建的表或其他迁移 DSL 需要人工文档化。
|
||||
- 前端路由提取会扫描 route-like 字面量和 view 文件；运行时由 API 生成的路由仍需要后端菜单/权限数据或数据库导出。
|
||||
- 超大仓库可能需要调整 `--max-files`，或增加忽略目录。
|
||||
+135
@@ -0,0 +1,135 @@
|
||||
# 项目知识库输出契约
|
||||
|
||||
生成完整代码库知识库时使用本参考。
|
||||
|
||||
## 语言策略
|
||||
|
||||
人类阅读的叙述文档应匹配用户语言。如果用户使用中文或要求中文，README、上下文、架构、运行、后端、前端、数据、认证/权限、扩展、排障、RAG 指南和 ADR 都应使用中文。
|
||||
|
||||
技术锚点保持原样：源码路径、命令、类名、方法名、API 路径、配置键、表名、权限码、JSON key 和元数据枚举值。
|
||||
|
||||
生成索引可以保持技术化和接近源码。不要为了翻译而破坏可刷新性。
|
||||
|
||||
## 文档职责
|
||||
|
||||
| 文件 | 用途 |
|
||||
| --- | --- |
|
||||
| `README.md` | 入口、阅读顺序、高价值链接、新鲜度说明。中文输出时标题和使用说明应为中文。 |
|
||||
| `CONTEXT.md` | 领域语言、业务能力、用户角色、核心名词、不变量。 |
|
||||
| `CONTEXT-MAP.md` | 限界上下文、模块归属、上下游依赖、运行边界。 |
|
||||
| `01-architecture.md` | 系统形态、模块图、请求/数据/控制流、扩展点。 |
|
||||
| `02-runtime.md` | 本地运行、构建、环境变量、Docker、部署模式、进程拓扑。存在时必须识别本地、Docker standalone 和云端模式。 |
|
||||
| `03-backend.md` | 后端模块、入口点、API 约定、service/mapper/entity 模式。 |
|
||||
| `04-frontend.md` | 前端启动、路由、状态、API client、组件/页面约定。 |
|
||||
| `05-data-and-migrations.md` | 数据库、迁移、schema 来源、种子数据、表族。 |
|
||||
| `06-auth-permissions.md` | 认证、授权、token/session 流、权限码生命周期。仓库存在后端驱动菜单时，必须解释菜单/按钮权限流。 |
|
||||
| `07-extension-guide.md` | 如何端到端新增功能，并给出有来源依据的示例。适用时必须覆盖后端 CRUD、前端页面和权限/菜单数据变更。 |
|
||||
| `08-troubleshooting.md` | 面向症状的排障手册，包含命令、文件和可能原因。 |
|
||||
| `09-rag-indexing.md` | 切块、元数据、排除规则、刷新频率、过期数据策略。 |
|
||||
| `adr/*.md` | 当前代码已经体现的架构决策。 |
|
||||
| `generated/*.md` | 可重新生成的数据索引。 |
|
||||
|
||||
## 必要章节
|
||||
|
||||
每份叙述文档应包含：
|
||||
|
||||
- **已观察来源**：使用过的具体文件或命令。
|
||||
- **核心事实**：简洁、有来源依据的陈述。
|
||||
- **操作影响**：开发者因这些事实需要采取的不同做法。
|
||||
- **未知与风险**：需要运行权限、数据库导出、产品负责人输入或外部文档才能确认的缺口。
|
||||
|
||||
## 新人可用性门禁
|
||||
|
||||
认为知识库可交接前，确认新维护者能回答：
|
||||
|
||||
1. 这个产品/项目是什么，哪些目录最重要？
|
||||
2. 如何启动，或如何识别当前运行模式？
|
||||
3. 后端接口、前端路由/页面、配置、数据表、权限码在哪里索引？
|
||||
4. 菜单、按钮和后端权限校验如何连接？
|
||||
5. 新增普通功能时，通常会改哪些后端、前端、数据库和权限产物？
|
||||
|
||||
如果 README 加叙述文档无法明显回答这些问题，先补充或修改人类阅读指南。不要通过加长生成索引来解决。
|
||||
|
||||
## 生成索引
|
||||
|
||||
### `project-inventory.md`
|
||||
|
||||
包含：
|
||||
|
||||
- 仓库根路径
|
||||
- 构建/包管理清单
|
||||
- 主要语言
|
||||
- 主要目录
|
||||
- scripts
|
||||
- Docker/compose 文件
|
||||
- env 文件
|
||||
- 测试文件
|
||||
|
||||
### `backend-endpoints.md`
|
||||
|
||||
包含路由方法、路径、类/文件、近似行号、认证注解和备注。不要在 class-level 与 method-level mapping 需要 Java 表达式解析时编造完整路径；展示已观察片段，并标记组合限制。
|
||||
|
||||
### `frontend-routes.md`
|
||||
|
||||
包含静态路由文件、动态路由加载器、`src/views` 索引、路由守卫文件和外部路由包加载器。
|
||||
|
||||
### `config-reference.md`
|
||||
|
||||
包含 env 文件、YAML/properties 文件、相关 key、默认值和风险说明。敏感信息必须脱敏。
|
||||
|
||||
### `database-dictionary.md`
|
||||
|
||||
包含 SQL 文件、迁移文件、表名、表族，以及表是初始化、迁移还是推断得出。不要把巨大 SQL 写进正文；摘要并链接来源。
|
||||
|
||||
### `permission-codes.md`
|
||||
|
||||
包含后端注解、前端权限 helper/usage、菜单/权限 SQL 命中和认证生命周期说明。
|
||||
|
||||
## ADR 模板
|
||||
|
||||
```markdown
|
||||
# ADR NNNN: 标题
|
||||
|
||||
Date: YYYY-MM-DD
|
||||
Status: Observed
|
||||
|
||||
## Context
|
||||
|
||||
说明该决策已经存在的来源事实。
|
||||
|
||||
## Decision
|
||||
|
||||
当前代码体现的架构决策。
|
||||
|
||||
## Consequences
|
||||
|
||||
收益、取舍、操作约束和迁移风险。
|
||||
|
||||
## Sources
|
||||
|
||||
- `path/to/file`
|
||||
```
|
||||
|
||||
## RAG 元数据
|
||||
|
||||
推荐每个 chunk 使用：
|
||||
|
||||
```json
|
||||
{
|
||||
"project": "name",
|
||||
"snapshot_date": "YYYY-MM-DD",
|
||||
"source_path": "path",
|
||||
"doc_type": "architecture|runtime|generated|adr|runbook",
|
||||
"domain": "backend|frontend|data|auth|deploy",
|
||||
"freshness": "manual|generated",
|
||||
"confidence": "observed|inferred|unknown"
|
||||
}
|
||||
```
|
||||
|
||||
## 反模式
|
||||
|
||||
- 只有长篇说明，没有生成索引。
|
||||
- 写与仓库无关的“最佳实践”建议。
|
||||
- 把 README 营销文案复制成架构文档。
|
||||
- 没有来源路径就声称某接口、表、权限或运行模式存在。
|
||||
- 隐藏未知问题，而不是列出来。
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建工单后能查询审计记录 | |
|
||||
| 创建记录 | 创建业务对象后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 指派记录 | 指派负责人记录原负责人和新负责人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示工单不存在，页面不崩溃 | |
|
||||
| 详情不存在 | 提示业务对象不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
|
||||
@@ -2,10 +2,10 @@
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 工单菜单只对授权角色可见 | |
|
||||
| 菜单权限 | 业务对象菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内工单 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内业务对象 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/指派 | |
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定工单类型 | 只统计对应类型 | |
|
||||
| 类型过滤 | 指定业务对象类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
# 阶段 Review Prompt
|
||||
# 阶段 Review 任务上下文契约
|
||||
|
||||
```text
|
||||
请对 JeecgBoot 工单模块阶段交付物做 Review。
|
||||
请对 目标业务模块阶段交付物做 Review。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵
|
||||
|
||||
+1
-1
@@ -15,7 +15,7 @@
|
||||
|
||||
| 等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| P1 | 权限 | 删除接口只隐藏按钮，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端删除工单 | 后端补权限校验 | 无权限账号请求返回 403 |
|
||||
| P1 | 权限 | 删除接口只隐藏按钮，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端删除业务对象 | 后端补权限校验 | 无权限账号请求返回 403 |
|
||||
|
||||
## 不确定点
|
||||
|
||||
|
||||
@@ -1,71 +1,35 @@
|
||||
# 验收清单
|
||||
# 业务交付验收清单
|
||||
|
||||
本清单用于判断学员是否真正掌握 JeecgBoot 工单案例，而不是只复制了 TRAE 输出。建议讲师在小组展示时逐项打分。
|
||||
本清单用于审查一个业务模块的设计、代码或 PR 是否具备可交付证据。它不替代目标项目的实际规则、接口规范或测试要求。
|
||||
|
||||
## 项目理解
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 能说明 JeecgBoot 前后端目录 | 至少指出 `jeecg-boot`、`jeecgboot-vue3`、`docs/project-knowledge` 的用途 | |
|
||||
| 能定位后端入口 | 能指出 `JeecgSystemApplication.java` 和后端启动模块 | |
|
||||
| 能定位前端入口 | 能指出 `src/main.ts`、路由、Pinia 和 API 请求层 | |
|
||||
| 能区分事实和推断 | 对没有源码依据的业务规则标注为推断或待确认 | |
|
||||
| 能记录不确定点 | 不确定内容没有被包装成确定事实 | |
|
||||
|---|---|---|
|
||||
| 模块边界明确 | 已定位前后端入口、接口、数据模型和必要配置 | |
|
||||
| 事实与推断分开 | 每个非显然结论能够回到源码、日志、配置或规范 | |
|
||||
| 待确认项明确 | 无证据内容没有被包装成确定事实 | |
|
||||
|
||||
## 需求与接口
|
||||
## 改动边界
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 用户故事完整 | 覆盖管理员、负责人、研发、测试、只读用户 | |
|
||||
| 非目标范围明确 | 明确课堂不做完整编码、生产部署、真实数据迁移 | |
|
||||
| 接口契约完整 | 覆盖列表、详情、新增、编辑、指派、状态、审计、看板 | |
|
||||
| 失败场景明确 | 每个关键接口至少有权限、参数、状态或数据不存在失败场景 | |
|
||||
| 验收方式明确 | 每个关键需求都有可执行检查方法 | |
|
||||
|---|---|---|
|
||||
| 目标与非目标明确 | 说明本次解决的问题及明确不修改的相邻范围 | |
|
||||
| 关键风险已识别 | 权限、状态、审计、异常、数据范围和兼容性按需核对 | |
|
||||
| 最小改动可解释 | 关键规则有权威入口，未引入无关重构 | |
|
||||
|
||||
## 权限与状态
|
||||
## 验证与交付
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 权限矩阵完整 | 覆盖页面级、按钮级、接口级和数据范围 | |
|
||||
| 权限字符合理 | 命名统一，并标注为建议而非源码事实 | |
|
||||
| 后端权限未缺失 | 没有用前端按钮隐藏替代后端接口控制 | |
|
||||
| 状态流转表完整 | 覆盖新建、处理中、待验证、已关闭、已驳回 | |
|
||||
| 非法流转明确 | 至少列出 5 条非法流转和拒绝原因 | |
|
||||
|---|---|---|
|
||||
| 验证覆盖匹配风险 | 正常、异常、权限、状态与边界场景按实际风险设计 | |
|
||||
| 执行结果如实记录 | 已执行命令、CI、日志或人工观察可复核；未执行项明确列出 | |
|
||||
| PR 或变更说明完整 | 包含目标、实现范围、验证证据和已知边界 | |
|
||||
| 资产沉淀有依据 | 仅将可复用且已验证的判断沉淀为 Rule、任务上下文契约、检查单、Skill 或 MCP 契约 | |
|
||||
|
||||
## 审计、异常态与看板
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 审计操作覆盖关键动作 | 创建、编辑、指派、状态流转、关闭、评论至少覆盖 5 类 | |
|
||||
| 审计字段可追溯 | 包含 actor、action、targetId、oldValue、newValue、source | |
|
||||
| 敏感信息处理 | oldValue/newValue 有脱敏说明 | |
|
||||
| 异常态可测试 | 权限不足、重复提交、非法状态、数据不存在、并发修改均覆盖 | |
|
||||
| 看板指标可计算 | 每个指标有口径、维度、过滤条件和数据来源建议 | |
|
||||
|
||||
## Review 与交付
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| Review 有证据 | 问题能回到路径、表格或业务规则 | |
|
||||
| 风险按严重程度排序 | 高风险问题优先展示 | |
|
||||
| 建议可行动 | 每条建议有修复方向和验收方式 | |
|
||||
| 交付物齐全 | [worksheets.md](./worksheets.md) 中最终交付记录完整 | |
|
||||
| 能沉淀资产 | 能说明哪些内容进入 [assets-index.md](./assets-index.md) 的资产库 | |
|
||||
|
||||
## 评分建议
|
||||
|
||||
| 等级 | 分数 | 描述 |
|
||||
| --- | ---: | --- |
|
||||
| A | 90-100 | 依据充分，设计完整，风险清楚，验收可执行 |
|
||||
| B | 75-89 | 主链路完整，少量不确定点或验收细节不足 |
|
||||
| C | 60-74 | 有基本产出，但权限、状态、审计或异常态明显薄弱 |
|
||||
| D | 0-59 | 泛泛总结项目，缺少源码依据或无法验收 |
|
||||
|
||||
## 讲师判定原则
|
||||
|
||||
- 优先看证据，不优先看文字是否漂亮。
|
||||
- 优先看权限、状态、审计、异常态，不只看 CRUD。
|
||||
- 优先看不确定点是否被诚实标出。
|
||||
- 优先看能否复用到团队资产库。
|
||||
- 对没有依据的自信结论扣分。
|
||||
## 判定原则
|
||||
|
||||
- 优先审查证据与边界，不以篇幅或术语数量判断质量。
|
||||
- 前端隐藏或必填不能替代后端权限和业务状态保护。
|
||||
- 局部测试、CI 通过和源码阅读分别只支撑相应范围的结论。
|
||||
- 发生资产变更时，补充行为、引用、兼容性和夹具验证证据。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 修复记录生成 Prompt
|
||||
# 修复记录生成 任务上下文契约
|
||||
|
||||
```text
|
||||
请根据阶段 Review 报告生成修复记录。
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## 场景
|
||||
|
||||
工单指派负责人成功，但没有记录审计日志。
|
||||
业务对象指派负责人成功，但没有记录审计日志。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 操作 | 结果 |
|
||||
| --- | --- |
|
||||
| 张三将工单指派给李四 | 工单负责人变更成功 |
|
||||
| 张三将业务对象指派给李四 | 业务对象负责人变更成功 |
|
||||
| 查询审计日志 | 没有负责人变更记录 |
|
||||
|
||||
## 风险
|
||||
@@ -28,5 +28,5 @@
|
||||
| --- | --- |
|
||||
| 指派成功 | 审计列表出现 ASSIGN 记录 |
|
||||
| 指派失败 | 不出现成功审计 |
|
||||
| 查询详情 | 审计记录可在工单详情查看 |
|
||||
| 查询详情 | 审计记录可在业务对象详情查看 |
|
||||
|
||||
|
||||
@@ -2,19 +2,19 @@
|
||||
|
||||
## 场景
|
||||
|
||||
工单删除按钮在前端按权限隐藏，但后端删除接口没有权限校验。
|
||||
业务对象删除按钮在前端按权限隐藏，但后端删除接口没有权限校验。
|
||||
|
||||
## 问题代码表现
|
||||
|
||||
| 层级 | 表现 |
|
||||
| --- | --- |
|
||||
| 前端 | 普通研发账号看不到删除按钮 |
|
||||
| 后端 | 直接请求 `/workOrder/delete` 仍可删除 |
|
||||
| 后端 | 直接请求 `/<module>/delete` 仍可删除 |
|
||||
| 审计 | 删除记录可能缺失 |
|
||||
|
||||
## 风险
|
||||
|
||||
攻击者或误操作用户可以绕过前端直接调用接口删除工单。
|
||||
攻击者或误操作用户可以绕过前端直接调用接口删除业务对象。
|
||||
|
||||
## 修复要求
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
|
||||
| 账号 | 操作 | 预期 |
|
||||
| --- | --- | --- |
|
||||
| 管理员 | 删除允许删除的工单 | 成功并写审计 |
|
||||
| 管理员 | 删除允许删除的业务对象 | 成功并写审计 |
|
||||
| 普通研发 | 直接请求删除接口 | 失败 |
|
||||
| 只读用户 | 前端访问删除按钮 | 不可见 |
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
| 指标 | 当前说明 |
|
||||
| --- | --- |
|
||||
| 平均关闭周期 | 最近工单平均处理时间 |
|
||||
| 平均关闭周期 | 最近业务对象平均处理时间 |
|
||||
|
||||
## 风险
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
## 修复要求
|
||||
|
||||
1. 明确定义为 `close_time - create_time` 或其他确定口径。
|
||||
2. 明确是否排除未关闭工单。
|
||||
2. 明确是否排除未关闭业务对象。
|
||||
3. 明确时间范围过滤字段。
|
||||
4. 用样例数据手工校验。
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
| 样例 | 预期 |
|
||||
| --- | --- |
|
||||
| 工单 A 创建 1 日、关闭 3 日 | 周期 2 天 |
|
||||
| 未关闭工单 | 不计入平均关闭周期 |
|
||||
| 业务对象 A 创建 1 日、关闭 3 日 | 周期 2 天 |
|
||||
| 未关闭业务对象 | 不计入平均关闭周期 |
|
||||
| 过滤 7 月 | 只统计 7 月范围内符合口径的数据 |
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 场景
|
||||
|
||||
已关闭工单可以直接被改回处理中。
|
||||
已关闭业务对象可以直接被改回处理中。
|
||||
|
||||
## 问题表现
|
||||
|
||||
@@ -12,12 +12,12 @@
|
||||
|
||||
## 风险
|
||||
|
||||
已关闭工单被重新打开但没有重开原因、没有审计、没有负责人确认，导致统计和责任链失真。
|
||||
已关闭业务对象被重新打开但没有重开原因、没有审计、没有负责人确认，导致统计和责任链失真。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. Service 层集中校验状态流转。
|
||||
2. 已关闭工单只能通过“重新打开”动作变为新建。
|
||||
2. 已关闭业务对象只能通过“重新打开”动作变为新建。
|
||||
3. 重新打开必须填写原因。
|
||||
4. 所有成功流转写审计日志。
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# 正式交付清单
|
||||
|
||||
## 版本信息
|
||||
|
||||
- 交付名称：客户 AI 工程资产交付包
|
||||
- 版本：V1.0
|
||||
- 整理日期：2026-08-06
|
||||
- 正式载体：本目录与同级 `客户AI工程Skill交付包.zip`
|
||||
|
||||
目录与 ZIP 内容一致；对外发送时任选一种载体即可，不应混用历史压缩包或旧目录。
|
||||
|
||||
## 正式交付范围
|
||||
|
||||
| 类别 | 内容 | 用途 |
|
||||
|---|---|---|
|
||||
| 项目约束 | `generate-project-constraints` | 从目标项目提取可验证的开发约束 |
|
||||
| 项目知识 | `project-knowledge-builder` | 建立源码依据的项目知识库与索引 |
|
||||
| 复杂业务设计 | `design-complex-business-module` | 设计权限、状态、审计、异常态和指标 |
|
||||
| 交付审查 | `review-business-delivery` | 审查设计、代码或 PR 的风险与验证缺口 |
|
||||
| 修复闭环 | `track-review-fix-loop` | 跟踪 Review 问题、修复、验证与资产更新 |
|
||||
| MCP 资产 | `mcp-assets/` | 描述外部能力、权限、副作用、失败降级和验收夹具 |
|
||||
| 实战案例 | `examples/jeecgboot-official-vehicle/` | 基于现有公务用车模块的单人影响分析与验证案例 |
|
||||
|
||||
## 使用边界
|
||||
|
||||
- 五个 Skill 与 MCP 资产均为通用工程资产；业务对象、路径、接口、权限码、状态和测试命令必须从目标项目重新取得。
|
||||
- 公务用车案例只保留已经读取和验证的事实，用于说明方法，不构成任何客户业务要求。
|
||||
- MCP 目录不包含服务地址、凭据、内部域名或真实数据。接入时必须先完成能力契约、权限审查和验证夹具。
|
||||
- 本包不包含客户源码、训练分支、构建产物、在线考试题或讲师逐字稿；这些材料按其使用场景独立管理。
|
||||
|
||||
## 交付前核验项
|
||||
|
||||
- [x] 五个 Skill 目录均包含 `SKILL.md`，并保留各自的 assets、references、scripts 或 agents 文件。
|
||||
- [x] `mcp-assets/` 包含能力契约模板、权限与验收清单及使用说明。
|
||||
- [x] 扫描确认未携带历史案例、多人协作要求、默认账号或系统元数据文件。
|
||||
- [x] 压缩包可完整解压，且内容与本目录一致。
|
||||
|
||||
## 交付后的首次动作
|
||||
|
||||
1. 阅读 `README.md` 与 `安装说明.md`，确认目标 AI 编程工具的 Skill 加载方式。
|
||||
2. 在目标项目先运行项目约束提取与项目知识构建，再选择复杂业务设计或 Review 类 Skill。
|
||||
3. MCP 接入前填写能力契约，未完成权限和夹具验证时不得给 Agent 授权高风险工具。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user