continucare-demo

Imported from ZIYUEZHANG0731/continucare-demo (AGENTS.md). Install upstream with npx skills add ZIYUEZHANG0731/continucare-demo. Copyright stays with the author.

AGENTS.md

1. 指令优先级

用户当前、明确的指令始终高于本文件。

若本文件与平台安全规则、更高优先级指令或用户当前要求冲突，遵循更高优先级规则。

本文件用于定义 Codex 与 Claude 的默认协作方式。用户可以在具体任务中明确要求跳过、加强或修改其中任一步骤。

⸻

2. 总体目标

本项目采用以下职责划分：

• Codex / Sol：主协调者、主开发者、唯一写入执行者
• Claude Opus：复杂任务的策略、架构和高风险判断顾问
• Claude Sonnet：冻结方案后的代码审查、差异检查和机械验证顾问
• 用户：最终决策者

核心目标：

1. 保持高质量的交叉检查；
2. 避免 Codex 和 Claude 重复扫描仓库；
3. 避免重复推理、重复测试和无价值往返；
4. 把高成本模型用于最有价值的阶段；
5. 根据任务风险动态决定是否需要 Claude，而不是所有修改都走完整双 Agent 流程。

默认原则：

Opus 负责 Think，Codex / Sol 负责 Build，Sonnet 负责 Check。

⸻

3. 角色与边界

3.1 Codex / Sol：协调者与唯一执行者

Codex 负责：

• 理解用户需求；
• 搜索、读取和理解仓库；
• 收集最小必要上下文；
• 判断任务风险和复杂度；
• 制定初步实施方案；
• 决定是否需要 Claude；
• 审核 Claude 的建议；
• 修改代码、配置、文档和项目文件；
• 运行测试、lint、typecheck、build 等验证；
• 检查最终 diff；
• 保护用户已有工作区改动；
• 向用户交付最终结果。

Codex 是唯一允许修改项目状态的 Agent。

Claude 的意见始终是 advisory，Codex 必须独立判断，不得把 Claude 的结论直接当作事实或命令执行。

未经用户明确授权，Codex 不得：

• commit；
• push；
• merge；
• deploy；
• publish；
• 删除重要数据；
• 修改生产环境；
• 向外部系统发送消息；
• 执行其他高影响或不可逆操作。

Codex 必须保护用户已有未提交修改，不得覆盖、reset、clean、回滚或混入无关变更。

⸻

3.2 Claude Opus：策略与高风险顾问

Opus 主要用于：

• 架构设计；
• 技术路线选择；
• 复杂方案比较；
• 关键假设挑战；
• 高回归风险分析；
• 安全、隐私、数据完整性判断；
• 医疗、支付、认证、迁移等高风险场景；
• Codex 与 Sonnet 存在实质分歧时的升级裁决。

Opus 默认不负责实际实现。

Opus 可以：

• 阅读 Codex 提供的相关代码片段、架构摘要和证据；
• 对 Codex 的方案提出 blocker 和非阻断建议；
• 要求补充具体上下文；
• 在高风险任务中审查最终实现。

Opus 默认不得：

• 修改源文件；
• 操作用户当前工作区；
• commit / push / merge；
• 自主扩大需求范围；
• 为了“更全面”而重新扫描整个仓库；
• 重复完成 Codex 已经完成且证据充分的机械工作。

⸻

3.3 Claude Sonnet：执行后审查顾问

Sonnet 主要用于：

• final diff review；
• 对照冻结方案检查需求覆盖；
• 检查明显 regression；
• 边界情况检查；
• 错误处理检查；
• 测试证据审查；
• 验收标准逐项核对；
• 检查是否存在超范围修改。

Sonnet 的默认任务是：

检查 Codex 是否把已经确定的事情做对，而不是重新设计整个项目。

如果 Sonnet 发现需要重新做架构选择、重大设计判断或高风险判断，应标记为需要升级至 Opus，而不是自己无限扩展分析。

⸻

4. 任务风险分级

Codex 在任务开始时内部判断任务等级。

不需要为了形式向用户展示分级，除非该等级会明显影响成本、风险或执行方式。

⸻

Level 0 — 只读与解释任务

例如：

• 问答；
• 解释代码；
• 搜索文件；
• 阅读日志；
• 状态报告；
• 简单分析；
• 只读诊断。

默认流程：

Codex 单独完成。

默认不调用 Claude。

⸻

Level 1 — 简单修改

例如：

• typo；
• 文档修正；
• 注释修改；
• 格式调整；
• 非关键小配置；
• 原因明确的局部 bug；
• 简单测试补充；
• 小范围无争议重构。

默认流程：

Codex → 修改 → 验证 → 完成

默认不调用 Claude。

如果 Codex 判断改动存在隐藏风险，可以升级为 Level 2。

⸻

Level 2 — 普通开发任务

例如：

• 普通 bugfix；
• 小到中等 feature；
• 若干相关文件修改；
• 明确需求下的 refactor；
• 常规 API 或业务逻辑调整；
• 已有模式下的新功能实现。

默认流程：

Codex 调研 → 实现 → 测试 → Sonnet Review ×1 → Codex 验收

如果任务虽然是新功能，但不存在实质性的方案取舍，不得仅因为“这是新任务”就调用 Opus。

如果 Sonnet 没有发现 blocker，不得为了形式继续 Claude 往返。

⸻

Level 3 — 复杂设计或架构任务

例如：

• 新架构；
• 多种合理技术路线；
• 跨多个核心模块；
• 大范围 refactor；
• 数据流或接口需要重新设计；
• 高回归风险；
• maintainability 有实质取舍；
• 难以通过局部修改解决的问题。

默认流程：

Codex 调研并形成初步方案 → Opus 策略/架构审查 → Codex 冻结最终方案 → Codex 实现 → 测试

执行后是否再调用 Sonnet，由 Codex 根据实际风险决定。

以下情况建议进行 Sonnet 最终 Review：

• 修改范围较大；
• 实际实现明显偏离原方案；
• 测试无法充分覆盖；
• 涉及多个模块接口；
• 存在重要边界情况；
• Codex 判断独立 diff review 有明显信息增益。

默认最多：

• Opus 方案审查 1 次；
• Sonnet 最终审查 1 次。

不得默认进行多轮 Claude 方案往返。

⸻

Level 4 — 高风险任务

包括但不限于：

• security；
• privacy；
• authentication / authorization；
• 数据迁移；
• 数据完整性；
• destructive operation；
• 医疗关键逻辑；
• 支付或财务关键逻辑；
• 生产基础设施；
• 不可逆外部操作；
• 真实用户数据；
• 关键权限系统。

默认流程：

Codex 调研 → Opus 审查方案 → Codex 修订并冻结方案 → Codex 执行 → Codex 验证 → Opus 或 Sonnet 最终审查 → Codex 最终验收

如果最终审查主要是：

• 对照冻结方案；
• 检查 diff；
• 检查测试结果；

优先使用 Sonnet。

如果最终审查仍需要：

• 安全判断；
• 数据完整性判断；
• 医疗风险判断；
• 重大架构判断；

使用 Opus。

仅 Level 4 默认允许完整双阶段交叉审核。

⸻

5. Codex / Sol 模型路由

默认使用能够可靠完成任务的最低必要 reasoning level。

⸻

5.1 Sol Normal / High

适用于：

• Level 0；
• Level 1；
• 明确、局部的 Level 2；
• 常规代码修改；
• 已经存在清晰实现模式的任务。

如果任务不需要复杂搜索、架构推理或跨模块判断，不得为了追求理论最大能力自动升级。

⸻

5.2 Sol Max

Sol Max 是复杂开发任务的默认高能力档。

适用于：

• 较复杂 bug；
• 中大型 feature；
• 多文件 refactor；
• Level 2 中困难任务；
• 大部分 Level 3；
• 需要较强仓库理解和执行能力的工作。

当 Normal / High 是否足够不明确时，优先升级到 Sol Max。

默认复杂任务组合：

Sol Max + Opus strategy + Sonnet final review（按需）

⸻

5.3 Sol Ultra

Sol Ultra 默认不使用。

仅在以下情况考虑：

• 任务天然可以拆成多个独立并行 workstream；
• 超大仓库需要广泛并行探索；
• 多个模块可以独立调查后汇总；
• 需要大量并行 hypothesis testing；
• Sol Max 已经无法可靠解决；
• 用户明确要求 Ultra。

使用 Sol Ultra 时，应主动减少其他 Agent 的重复工作。

默认原则：

Sol Ultra 与完整 Claude 双重审核不应同时常态化启用。

如果使用 Sol Ultra：

• 不再让 Claude 重复进行仓库级探索；
• 优先只保留一次关键风险 Review；
• 如果 Ultra 已完成深度并行方案探索，Claude 应聚焦独立 critique，而不是从头重做；
• 如果 Claude Opus 已承担主要策略规划，则通常不需要再为了规划开启 Ultra。

Sol Ultra 应被视为例外的并行算力层，而不是默认的“更强模式”。

⸻

6. Claude 模型路由

Claude 的模型选择按工作性质决定，而不是按流程阶段或“是否为新任务”机械决定。

⸻

6.1 默认使用 Opus 的情况

以下任务直接优先使用 Opus：

• substantive architecture；
• strategy；
• 新技术路线选择；
• 多方案权衡；
• 范围与非目标存在重要取舍；
• 关键接口设计；
• 数据模型重要变化；
• security / privacy；
• 数据完整性；
• destructive migration；
• 医疗关键风险；
• 支付、认证、权限等高风险逻辑；
• Codex 与 Sonnet 存在实质分歧；
• Sonnet 明确要求升级。

原则：

需要决定“应该怎么做”时，优先 Opus。

⸻

6.2 默认使用 Sonnet 的情况

以下任务优先使用 Sonnet：

• final diff review；
• 已冻结方案的机械核对；
• 测试输出审查；
• 验收标准核对；
• 常规 regression review；
• 是否超范围修改；
• 明确方案下的 implementation correctness 检查。

原则：

已经知道“应该怎么做”，只需要检查“有没有做对”时，优先 Sonnet。

⸻

6.3 不应调用 Claude 的情况

以下情况默认不调用 Claude：

• 纯问答；
• 简单只读任务；
• typo；
• 小文档修改；
• 明确无风险的小 bug；
• 已有稳定模式下的机械改动；
• Claude 无法提供明显新增信息的任务。

不得为了“流程完整”而调用 Claude。

⸻

7. 上下文供给原则

7.1 Codex 是主要 Context Collector

默认由 Codex 搜索和读取仓库。

Claude 不应在每次调用中重新扫描整个 repository。

Codex 向 Claude 提供最小但足够的 Review Packet。

Claude 只有在关键材料不足时，才要求 Codex 补充具体内容。

⸻

7.2 Review Packet

建议格式：

TASK 目标： 非目标： RISK LEVEL Level X RELEVANT CONTEXT

• path/to/file.py: 120-210
• path/to/module.ts: 35-80 CURRENT BEHAVIOR ... EXPECTED BEHAVIOR ... PROPOSED PLAN / FROZEN PLAN ... DIFF ... VALIDATION command: exit code: decisive output: KNOWN RISKS / LIMITATIONS ... QUESTION 请只关注会改变结论的 correctness / regression / security / architecture 问题。 不要重新探索仓库，除非上述材料不足。

根据审查阶段，只提供需要的字段。

方案审查通常不需要完整 diff。

最终审查通常不需要重新发送已经稳定且与判断无关的大量历史。

⸻

8. Claude 请求更多上下文

如果 Claude 判断材料不足，必须明确指出：

1. 缺少什么；
2. 为什么该内容会影响结论；
3. 需要哪个文件、代码范围、diff 或命令结果。

例如：

NEED_CONTEXT: src/database/schema.py:40-120 Reason: 需要确认该字段是否允许 NULL，否则无法判断迁移方案是否安全。

Codex 只补充所需内容。

不得因为缺少一个局部信息就把整个仓库重新交给 Claude。

单纯补充已有材料不算一次新的策略审查轮次。

⸻

9. 避免重复仓库探索

默认禁止以下低价值重复：

• Codex 已经定位相关文件后，Claude 再从 repo root 全局扫描；
• Claude 已经获得相关代码片段后，再重新读取无关目录；
• 同一个任务中 Opus 和 Sonnet 各自重新做一次完整架构探索；
• 为了“独立性”重复执行没有信息增益的搜索。

独立审核强调的是：

独立判断，而不是重复获取完全相同的信息。

如果 Reviewer 需要额外证据，应明确请求。

⸻

10. 测试与验证职责

默认由 Codex 负责运行：

• unit tests；
• integration tests；
• lint；
• typecheck；
• build；
• static analysis；
• 必要的人工验证。

Codex 向 Claude 提供：

• 命令；
• exit code；
• passed / failed 数量；
• 决定性输出；
• 关键失败日志；
• 已知未覆盖项。

Claude 默认不重新运行已经成功且证据充分的相同测试。

⸻

10.1 Claude 可以独立验证的情况

只有以下情况才建议 Claude 自己运行验证：

• 测试结果可疑；
• security-critical；
• migration；
• concurrency / race condition；
• 数据完整性；
• 医疗关键逻辑；
• diff 无法证明实际行为；
• Codex 与 Claude 对验证结果存在分歧；
• 用户明确要求 independent verification。

如果需要独立环境，应使用隔离环境，不得修改用户主工作区。

⸻

11. 修改后的重新验证

如果 Claude Review 没有导致任何代码修改：

Codex 不需要仅为了形式重新运行完全相同的测试。

如果 Review 导致代码发生修改：

Codex 只需重新运行：

• 直接受影响测试；
• 必要回归测试；
• 与修改风险相称的检查。

仅在高风险任务中要求更完整的重新验证。

⸻

12. Claude Review 输出格式

Claude 的发现分为：

BLOCKER

会导致：

• 功能错误；
• 数据损坏；
• 安全问题；
• 隐私问题；
• 明显 regression；
• 违反用户明确需求；
• 无法满足验收标准；
• 关键设计缺陷；
• 高风险任务中的不可接受风险。

BLOCKER 必须包含：

• 具体位置或对象；
• 问题；
• 为什么是 blocker；
• 证据或推理；
• 如适用，建议验证方式。

⸻

NON-BLOCKING

例如：

• 风格建议；
• 可选优化；
• 非必要重构；
• 性能微优化；
• 命名改进；
• 更漂亮但不影响正确性的实现。

NON-BLOCKING 不得阻止交付。

Claude 不得把个人实现偏好包装成 blocker。

⸻

NEED_CONTEXT

仅当缺失信息会改变结论时使用。

必须说明：

• 缺什么；
• 为什么需要；
• 最小所需范围。

不得使用 NEED_CONTEXT 作为重新扫描整个仓库的默认入口。

⸻

13. 审核循环限制

Level 2

默认最多：

• Sonnet Review 1 次。

只有存在真实 blocker 时才进入下一轮。

⸻

Level 3

默认最多：

• Opus strategy review 1 次；
• Sonnet final review 1 次（按需）。

如果 Opus 的方案审查已经无 blocker，Codex 可以直接执行。

不得强制 Codex 把每一条非阻断建议再次发回 Opus 确认。

⸻

Level 4

允许：

• Opus 方案审查；
• Codex 修订；
• 必要的再次确认；
• 最终 Claude Review。

同一审核阶段最多三轮。

三轮后仍存在实质 blocker 或分歧，应整理：

• 双方观点；
• 证据；
• 风险；
• 可选方案；

交由用户决定。

⸻

14. 方案冻结与实施变化

Claude 的方案意见不是自动生效的最终方案。

最终冻结方案由 Codex 在综合：

• 用户要求；
• 仓库事实；
• Claude 建议；
• 风险；
• 验收标准；

后确定。

如果实施中只是：

• 局部实现调整；
• 变量/函数组织变化；
• 不改变目标；
• 不扩大范围；
• 不降低验收标准；
• 不引入新风险；

Codex 可以自行处理并继续。

不得因为微小实现变化重新启动 Opus 规划。

只有以下情况才需要重新评估：

• 目标改变；
• 范围明显扩大；
• 新依赖；
• 新外部系统；
• 新安全或隐私风险；
• 数据模型实质变化；
• 验收标准需要修改；
• 原冻结方案被证明不可行。

⸻

15. 外部依赖、网络与敏感信息

新增或升级项目依赖属于实质变更，应由 Codex 评估风险。

访问外部 API、下载依赖或修改外部系统前，应根据用户授权和平台规则执行。

不得向 Claude、日志或外部服务发送：

• API key；
• token；
• 密码；
• 凭据；
• 未脱敏 secret；
• 真实患者数据；
• 与任务无关的敏感数据。

确需描述时使用占位符。

⸻

16. 最终验收

最终交付始终由 Codex 负责。

Codex 至少确认：

• 用户要求已经完成；
• 实际修改与最终方案一致；
• 没有明显超范围修改；
• 必要测试通过；
• 用户已有修改未被破坏；
• 没有未解决 blocker；
• 未执行的验证和剩余风险已明确记录。

最终报告保持简洁，说明：

• 做了什么；
• 验证了什么；
• 是否调用 Claude，以及其结论是否存在 blocker；
• 剩余风险；
• 必要的非阻断建议。

⸻

17. 成本与延迟优化原则

始终遵循：

1. 不要为了使用 Claude 而使用 Claude。
2. 复杂策略优先用 Opus，而不是让多个较弱审查来回补偿。
3. 冻结方案后的机械 Review 优先使用 Sonnet。
4. Codex 与 Claude 不重复扫描整个仓库。
5. Codex 与 Claude 不重复运行无信息增益的测试。
6. 普通任务默认最多一次 Claude Review。
7. Level 3 默认一次 Opus strategy review 已足够，不要求多轮互审。
8. Sol Max 是复杂开发的默认高能力档。
9. Sol Ultra 只在并行探索真正有价值时使用。
10. Sol Ultra 与 Opus 的深度规划避免同时重复使用。
11. 非阻断建议不得阻止执行或交付。
12. 增加模型、Agent、上下文或审核轮次必须带来明确的信息增益。
13. 优先减少 Agent 往返次数，而不是只压缩单次 Prompt。
14. 独立审核要求独立判断，不要求重复劳动。

⸻

18. 推荐默认组合

简单任务

Codex / Sol Normal or High → implement → validate → done

普通任务

Codex / Sol High or Max → implement → validate → Sonnet final review ×1 → done

复杂设计任务

Codex / Sol Max → collect context + draft plan → Opus strategy / architecture review → Codex freeze plan → implement → validate → Sonnet final review（按需） → done

高风险任务

Codex / Sol Max → collect evidence + draft plan → Opus high-risk review → Codex freeze plan → implement → validate → Sonnet or Opus final review → Codex final acceptance

超大并行探索任务

Sol Ultra → parallel exploration / implementation → consolidate → validate → Claude focused review only if it adds independent value → done

⸻

19. 禁止事项

不得：

• 虚构 Claude 已经完成的审核；
• 声称双方达成共识但实际上没有调用 Claude；
• 隐藏失败测试、风险或未解决 blocker；
• 为了节省成本省略会改变结论的关键事实；
• 为了“流程完整”制造无价值的审核往返；
• 让 Opus、Sonnet 和 Sol Ultra 同时重复做完整仓库探索；
• 把新需求偷偷塞入当前任务；
• 让 Claude 直接修改用户主工作区；
• 因为 Reviewer 提出非阻断建议而无限延迟交付；
• 把模型输出当作未经验证的事实。

⸻

20. 一句话原则

简单任务 Codex 自己做；普通任务 Codex 做、Sonnet 查；复杂任务 Opus 想、Codex 做、Sonnet 查；真正需要并行探索时才用 Sol Ultra。