Files

T

smart 67837df8d0 docs: 更新TRA编程培训课程材料、课件与AI技能交付包

- 新增全套考试卷、评估卷、参考答案与考试培训包模板
- 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象
- 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求
- 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块
- 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语
- 新增考试输出模板与TRAE使用记录文档

2026-08-08 11:00:36 +08:00

9.2 KiB

Raw Blame History

模块 7：AI 改动的可演进性审查

业务行为通过验证，只说明本次任务得到了正确结果。

可演进性关心的是下一次规则变化时，能否找到唯一入口、控制影响范围、替换依赖并准确定位回归。

修改入口

单一权威

依赖隔离

回归定位

四类会放大后续修改成本的风险

风险	典型表现	更好的处理
修改入口分散	一个业务变化要在多个页面、接口或服务中同步修改	明确唯一的规则入口和调用边界
平行规则	同一校验在多个位置各自维护一份	让关键规则只有一个权威实现
隐藏依赖	逻辑依赖环境、全局状态或外部服务却不可见	把依赖显式注入、记录或隔离
回归难定位	失败只能靠全项目搜索和猜测	保留可观察结果、场景夹具与最小影响范围

从“本次通过”到“下次可改”

本次交付已确认	可演进性还要确认
当前行为符合预期	下一次规则变化从哪里修改最清楚
本次 diff 已通过构建与测试	影响范围能否被调用关系和夹具限制
新逻辑放进了可运行的位置	关键规则是否有唯一权威位置
用例覆盖当前结果	失败时能否回到具体场景和依赖定位

可演进的改动，不是为未来过度设计，而是不给下一次变化留下多份解释。

可演进性审查的四个问题

规则变化时，第一处应修改哪里？

关键约束是否只有一个权威实现？

外部依赖能否替换、观察或明确失败？

回归能否缩小到具体场景、diff 与依赖？

审查的目标，是让 AI 生成的改动成为下一次可靠修改的起点。

公务用车案例：规则入口与状态写入相邻

已读取的实现事实	对后续修改的意义
`OfficialVehicleDispatchServiceImpl.cancel` 首行使用 `Assert.hasText` 校验取消原因	取消原因规则有明确的后端最终保护入口
同一方法随后读取派车单、校验 `DISPATCHED` 状态、写入取消状态与原因，并释放车辆	规则与其保护的状态写入相邻，影响范围容易阅读
`OfficialVehicleDispatchServiceImplTest` 直接传入全空白原因并断言异常	规则变化可以从同一测试文件开始定位回归

下一次调整“取消原因”规则时，应先从 Service 与这项聚焦测试开始；不应在页面、Controller 和 Service 中维护多份独立规则。

案例结论：已获得的可维护性证据

已经由源码与测试支持

证据	可形成的结论
本次训练分支仅改动 Service 参数保护和对应测试	改动范围聚焦，未混入页面、SQL 或状态协议调整
空白原因在读取派车单与写状态前被拒绝	无效输入不会进入后续状态变更路径
定向 Maven 测试记录为成功	该 Service 场景具备可重复的回归起点

尚不能由现有材料证明

缺少的证据	不能写成的结论
取消接口的 HTTP / 统一异常验证	前端会收到何种错误码和提示
非空正常取消的集成验证	派车、车辆状态与审计已完整回归
浏览器与数据库观察记录	页面交互和持久化链路已通过

可维护性审查也要按证据说话：明确规则入口与回归起点，不把局部验证扩大成全链路结论。

何时需要重构，何时保持聚焦？

观察到的证据	适合的处理	不应做的事
当前只新增一条取消原因非空规则，且规则入口就在状态变更方法中	保持 Service 中的最小改动，并维护同一聚焦测试	为单一校验新建没有复用对象的抽象层
后续出现多个取消入口且重复表达同一规则	先核对全部调用方、状态效果与测试，再评估抽取唯一规则入口	未确认重复语义就机械合并代码
发现外部调用方、异常协议或审计要求会影响规则	补齐接口与集成证据，再调整边界	用猜测替代兼容性和回归验证

可演进性不是预先堆叠抽象，而是让每次重构都有明确的重复、耦合或回归证据。

9.2 KiB Raw Blame History Unescape Escape