 chengmaandClaude Opus 5
|
ab988b39de
|
docs: 新增多模型协作规则，回填 Gitea 约定
CLAUDE.md（新增）
按"错了多久才会被发现"划分角色，而不是按任务难度：
设计错要几周后买错货才发现，实现错跑测试就红，复述错人一看就知道。
所以 Opus 设计和审查、Sonnet 实现、Haiku 只读查询。
关键几条：
- 工单里每条约束必须写清"在防什么"。下游没有上游的上下文，
理由不明的约束会被当成冗余优化掉
- 实现角色不得改工单范围、不得删改看不懂的约束或测试
（本项目测试名就是规则本身，删掉等于删掉一条业务规则）
- 审查五步，第一步是架构角色亲自跑验证，不采信报告结论
- 打回必须说清：哪条没达到、当前是什么、期望是什么
- 同一个点打回两次仍不达标，问题在工单不在实现，
这时该改工单或自己接手，继续打回只是消耗
AGENTS.md §0 重写
Gitea 一直可用（#1~#13 在正常使用），但 §0 还留着 <待填写>，
于是"未配置"成了跳过建单的长期借口。这次 PDD 那批就是靠聊天里的
草稿直接开工的，没有工单号。
- §0.1 填上真实地址和仓库；写明工单层级靠标题前缀区分，
不使用标签和里程碑（13 条工单实测两者均为空，也不要去建）
- §0.2 聊天里的草稿不算工单；不得默认直通，
不得因为上次直通过就默认这次也行
- §0.3 防呆：任何地方看到本仓库的工单链接就说明 Gitea 可用，
必须立刻回填 §0.1 并停止直通。提交信息里不得再出现
"Gitea 未配置 / 无工单号"这类说法
两份文档边界划清：CLAUDE.md 只讲协作方式，项目规则一律指向
AGENTS.md 不复述——复述一次就走样一次。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 10:28:05 +08:00 |
|