smart
202 lines
6.8 KiB
Markdown
202 lines
6.8 KiB
Markdown
# 模块 6：Agent 参与度光谱
|
||
|
||
<div class="mt-6 text-sm">
|
||
|
||
用户可以按任务风险和信任程度，选择 AI 参与到哪个深度。
|
||
|
||
</div>
|
||
|
||
<div class="mt-6 text-sm">
|
||
|
||
| 纯手工 | AI Copilot 辅助 | 手动触发全托管 | Loops 全托管 |
|
||
|---|---|---|---|
|
||
| 人自己写 | AI 辅助补全和解释 | 人给目标，AI 执行 | AI 自主循环，人审阅 |
|
||
|
||
</div>
|
||
|
||
<div class="mt-4 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||
从左到右，Agent 参与度递增，人类需要更强的验收和边界设计。
|
||
</div>
|
||
|
||
<!--
|
||
这页讲 Agent 参与度光谱。
|
||
企业落地时，团队可以根据任务风险选择停在哪个位置。
|
||
低风险重复任务可以提高自动化程度，高风险任务需要更清楚的计划、审查和人工确认。
|
||
-->
|
||
|
||
---
|
||
|
||
# Plan 模式：先计划，再执行
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-6 text-sm">
|
||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||
<div class="font-bold mb-2">计划阶段</div>
|
||
|
||
- 理解目标
|
||
- 划定范围
|
||
- 列出步骤
|
||
- 标注风险
|
||
</div>
|
||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||
<div class="font-bold mb-2">执行阶段</div>
|
||
|
||
- 修改文件
|
||
- 运行检查
|
||
- 汇报 diff
|
||
- 给出验证结果
|
||
</div>
|
||
</div>
|
||
|
||
<!--
|
||
Plan 模式把“想清楚再动手”显性化。
|
||
它让用户能在代码修改前审阅目标、范围、步骤和风险。
|
||
对企业研发来说，这是控制 Agent 风险的关键交互。
|
||
-->
|
||
|
||
---
|
||
|
||
# Plan 模式适合的场景
|
||
|
||
<div class="mt-6 text-sm">
|
||
|
||
| 场景 | 计划里必须写清 |
|
||
|---|---|
|
||
| 多文件改造 | 文件范围、模块边界、测试方式 |
|
||
| 权限相关修改 | 前端权限、后端权限、审计日志 |
|
||
| 依赖升级 | 版本影响、兼容性、回滚方式 |
|
||
| 生产缺陷修复 | 根因、最小改动、验证路径 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
Plan 模式最适合高风险和多步骤任务。
|
||
尤其是权限、依赖、生产缺陷、跨模块改造。
|
||
这些任务都需要先把边界和验证方式说清楚。
|
||
-->
|
||
|
||
---
|
||
|
||
# 三方智能体：Git 工作流里的 Agent
|
||
|
||
<div class="mt-6 text-sm">
|
||
|
||
Cursor BugBot、Codex Connect Review 代表了独立代码审查 Agent 的方向：它们挂在 PR 和代码流转环节上。
|
||
|
||
</div>
|
||
|
||
<div class="grid grid-cols-3 gap-4 mt-8 text-sm">
|
||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">PR 审查</div>
|
||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">CI/CD 检查</div>
|
||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">发布前验收</div>
|
||
</div>
|
||
|
||
<!--
|
||
Agent 的位置会从 IDE 扩展到 Git 工作流。
|
||
代码进入 PR 后，可以由独立审查 Agent 做规则检查、风险提示和测试建议。
|
||
Trae CLI 企业版也可以嵌入流水线，形成类似能力。
|
||
-->
|
||
|
||
---
|
||
|
||
# 自动 Review 的输入输出
|
||
|
||
<div class="mt-5 text-sm">
|
||
|
||
| 输入 | 输出 | 验收 |
|
||
|---|---|---|
|
||
| PR diff | 风险点 | 有文件和行号 |
|
||
| 项目 rules | 规则命中 | 能解释触发原因 |
|
||
| 测试结果 | 缺口建议 | 能对应关键路径 |
|
||
| 历史问题 | 回归提醒 | 能指向相似案例 |
|
||
| 工单权限矩阵 | 权限缺口 | 能对应角色和接口 |
|
||
| 工单状态流转表 | 非法路径 | 能指出拦截位置 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
自动 Review 要结构化。
|
||
输入包括 diff、rules、测试结果和历史问题。
|
||
输出要能落到文件、行号、规则和验证建议。
|
||
这样审查 Agent 才能进入团队流程。
|
||
第四天处理工单复杂业务时，要把权限矩阵和状态流转表也放进 Review 输入。
|
||
-->
|
||
|
||
---
|
||
|
||
# JeecgBoot 工单承接：哪些任务必须先 Plan
|
||
|
||
<div class="mt-5 text-sm">
|
||
|
||
| 第 4 天任务 | 为什么不能直接改 | Plan 里必须写清 |
|
||
|---|---|---|
|
||
| RBAC 权限矩阵 | 影响菜单、按钮、接口和数据范围 | 角色、权限字符、接口、验收账号 |
|
||
| 状态流转 | 容易出现越权流转和脏状态 | 状态枚举、合法路径、非法路径 |
|
||
| 审计日志 | 事后追责依赖日志完整性 | 记录时机、字段、查询方式 |
|
||
| 异常态 | 代码成功但页面不可用 | 空态、失败态、无权限态、非法状态 |
|
||
| 看板指标 | 数字错误会误导管理判断 | 指标口径、权限过滤、数据来源 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这页是从第三天进入第四天的桥。
|
||
前面讲的是 Plan 和 Review 的通用方法。
|
||
这里明确第四天的 JeecgBoot 工单任务都属于高风险、多链路任务，必须先计划再执行。
|
||
-->
|
||
|
||
---
|
||
|
||
# 第 3 天交付物
|
||
|
||
<div class="grid grid-cols-2 gap-3 mt-6 text-sm">
|
||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">01 规则迁移清单</div>
|
||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">02 Token 成本与任务匹配表</div>
|
||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">03 Command / Skill / MCP 决策表</div>
|
||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">04 Agent 分工表</div>
|
||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">05 前端浏览器验证清单</div>
|
||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">06 Plan 与 Review 验收清单</div>
|
||
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">07 JeecgBoot 工单链路索引</div>
|
||
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">08 第 4 天任务 Plan 草案</div>
|
||
</div>
|
||
|
||
<!--
|
||
第三天的交付物偏能力体系和工作方式。
|
||
它承接前两天的代码理解、上下文工程和规则资产化，把 Trae 的产品能力映射到企业研发流程。
|
||
最后两个交付物用于承接第四天 JeecgBoot 工单复杂业务开发。
|
||
-->
|
||
|
||
---
|
||
layout: center
|
||
class: text-center
|
||
---
|
||
|
||
# 前三天到第四天
|
||
|
||
<div class="grid grid-cols-4 gap-4 mt-8 text-left max-w-6xl mx-auto text-sm">
|
||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||
<div class="font-bold mb-2">第 1 天</div>
|
||
用 TRAE 看懂若依权限链路
|
||
</div>
|
||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||
<div class="font-bold mb-2">第 2 天</div>
|
||
把若依经验沉淀成 rules
|
||
</div>
|
||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||
<div class="font-bold mb-2">第 3 天</div>
|
||
能力体系 + JeecgBoot 工单承接
|
||
</div>
|
||
<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30">
|
||
<div class="font-bold mb-2">第 4 天</div>
|
||
进入权限、审计、异常态与看板开发
|
||
</div>
|
||
</div>
|
||
|
||
<br/>
|
||
|
||
> **第 4 天目标：让工单模块从“能跑通”升级到“可控制、可审计、可验证”。**
|
||
|
||
<!--
|
||
第三天不是结束，而是把能力体系接到第四天项目。
|
||
第一、二天仍以若依为主线，第三天讲 Trae 能力体系，并在后半段把方法迁移到 JeecgBoot 工单。
|
||
第四天开始处理权限、审计、异常态和看板这些复杂业务开发。
|
||
-->
|