Files

T

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

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

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

5.5 KiB

Raw Blame History

模块 3：Rule 的设计契约

Rule 不是“代码要规范”这类口号。

一条可执行 Rule 必须说明：它基于什么证据、在哪些场景生效、必须做什么、不能做什么，以及如何验收。

来源可信

边界明确

结果可验

先给 Rule 标注证据等级

等级	什么时候使用	典型写法
硬约束	配置、构建、CI 或显式规范直接证明	必须 / 禁止
观察性约束	多处源码反复出现，但没有书面规范	默认采用 / 优先复用
待确认约束	对交付很重要，但当前项目无法证明	需确认 / 不下结论

不要把“一个代码样例”或“通用最佳实践”直接升级成项目硬规则。

一条 Rule 的六个字段

## 状态变更必要信息保护

- 级别：观察性约束
- 适用场景：Service 方法会写入业务状态或释放、占用资源。
- 必须：在任何写入前校验本次状态变更必需的信息。
- 禁止：仅依赖前端必填；将条件必填扩大为全表非空。
- 来源证据：状态更新、资源更新与现有调用链。
- 验收方式：无效输入被拒绝；正常路径及副作用单独验证。

常见的 Rule 失效方式

写法	为什么失效	改写方向
“后端要做好校验”	没有触发点、位置和验收	指出状态写入前的必要信息保护
“所有字段都不能空”	把条件规则扩大为数据模型规则	写清具体状态与字段条件
“统一使用 Service”	把架构偏好误当业务约束	说明为什么该规则需要覆盖复用入口
“严格测试”	无法判断是否满足	写出无效输入、正常路径和副作用验证

好的 Rule 约束行为，不替人猜业务，也不替项目做架构重写。

Rule 的验收不是“读起来像规范”

能触发
知道什么时候应用

能约束
必须与禁止清楚

能取证
来源不是主观偏好

能验证
可用代码、测试或检查确认

5.5 KiB Raw Blame History Unescape Escape