让 AI 沿着同一套规范开发

规范应该解决什么问题

AI 需要知道事实从哪里来、代码放在哪里、哪些约定必须遵守，以及怎样证明任务完成。开发人员还需要理解这些边界背后的职责分工。

开始前先阅读项目的 AGENTS.md（如果存在）、Core 的 docs/ai/task-routing.md 和对应主题文档。网页入门说明不能替代具体仓库的最新规则。

提供足够明确的任务输入

下面的模板可以复制到任务说明中：

任务目标：
- 要改变的业务行为，以及触发这个行为的场景。

事实来源：
- 对应需求文档、Core 规范路径与最接近的已验证模块。

实施边界：
- 允许修改的模块 / 文件。
- 选定运行时：WebMVC + JDBC（示例，按任务替换）。
- 数据归属、身份上下文与事务边界。

代码约定：
- 阅读 Core 当前代码格式与命名规范。
- 沿用相邻实现；不要引入未约定的依赖或抽象。
- 处理此次变更引入的编译与静态检查警告。

验收条件：
- 正常、异常、权限边界的可观察结果。
- 要执行的构建、检查与针对性测试命令。
- 提交结果时附实际执行结果与未覆盖范围。

先找相近实现，再动手

让 AI 说明目标模块的职责位置、已有调用链和可复用实现。新增字段、接口或规则时，列出关联对象和数据实现，防止只改接口声明而漏掉持久化行为。

遇到文档与代码冲突，应记录冲突和证据，确认事实来源，再继续实现。不要为了匹配过时示例而修改正确的业务行为。

格式与警告也属于验收

代码格式按仓库规范执行，测试文件同样适用。不要通过无意义读取或全局压制警告掩盖未使用字段；先判断测试是否遗漏了应该断言的行为，或者辅助状态本身已经多余。

优先运行项目已有的格式和质量检查，结合此次修改范围补充验证。检查失败时，区分本次引入的问题与已有环境或历史问题，并给出证据。

人工 Review 关注什么

实现是否满足业务目标，而不只是编译通过。
规则是否位于正确层级，事务和上下文是否完整。
查询、转换与持久化是否同步更新。
测试是否验证外部可观察行为，而不只是复述实现。
文档是否与最终实现一致，遗留限制是否写清楚。

和 AI 协作的交付物是可以阅读、运行和验证的代码变更。规范提供共同依据，Review 与实际验证决定变更是否成立。