本文件专门约束以下协作主体：
- AI 编码助手
- 代码代理
- 自动化修复脚本
- 半自动生成代码流程
目标是让 AI 在 vibecoding 场景下保持高效率，同时不破坏架构和可维护性。
在开始改动前，AI 必须先完成以下判断：
- 这次需求属于哪个边界上下文。
- 这次改动应该落在哪一层。
- 现有目录中是否已有可复用模型、端口、适配器或组件。
- 这次改动的最小闭环是什么。
如果以上四项不能回答清楚，禁止直接大面积生成代码。
- 允许先搭骨架再补细节
- 允许使用 stub 打通链路
- 允许小步重构
- 允许先实现最小可运行版本
但前提是：
- stub 放在正确层
- 命名清晰
- 替换点明确
- 不制造新的硬耦合
- 不先读现有代码就大面积改目录
- 不把业务逻辑塞进表现层组件
- 不在
domain中写 Node / Shell / 网络细节 - 不复制现有代码后仅改变量名
- 不生成大批未使用类型、接口、帮助函数
- 不为了“以后可能会用”预埋大量空抽象
- 不在一个任务里同时引入无关重构
AI 的默认改动粒度应满足：
- 单次优先解决一个主题
- 先修结构，再补功能
- 先保证可运行，再补增强
- 能复用时不新建同义文件
如果任务很大，优先分成：
- 文档与规划
- 骨架与接口
- 最小实现
- 验证与收尾
AI 新建目录前必须确认：
- 当前目录不能承载该职责
- 新目录是长期概念，不是一次性临时分组
- 新目录名符合领域语言
以下目录名默认禁止使用：
misccommontempallshared2newhelpers
除非能清楚证明该目录边界是稳定且合理的。
AI 只有在以下条件满足时才允许新增抽象层：
- 已出现第二个真实使用点。
- 抽象后比原来更清晰。
- 抽象没有增加跨层理解成本。
如果只是单点调用，优先保持直接实现。
AI 写中文注释时必须：
- 解释职责
- 解释设计意图
- 解释未来替换点
AI 不应写：
- 表面翻译式注释
- 无意义步骤注释
- 与代码矛盾的陈旧注释
只要改了代码，AI 至少执行以下一项：
bunx tsc --noEmitbun testbun run build
如果修改涉及架构、入口、依赖或构建链，优先执行两项及以上。
AI 不得在未验证的情况下直接宣称“完成”。
AI 完成任务时必须明确说明：
- 改了什么
- 为什么这样分层
- 做了什么验证
- 还有哪些后续建议
如果有未完成项，必须明确说清楚，不得模糊带过。
当用户要求与现有规则冲突时：
- 优先满足用户目标
- 但要尽量保持架构边界
- 如果冲突会造成长期负债，应先提示风险，再选择最小破坏方案
AI 只有在满足以下条件时才算完成：
- 代码已落地
- 结构未越层
- 没有明显重复
- 已做基础验证
- 必要文档已更新