cc-viewer 1.6.303 → 1.6.305

package/concepts/zh/ultraplan-origin.md

@@ -0,0 +1,57 @@
+[作用域指令] 以下说明仅适用于接下来的 1 到 3 次交互。任务完成后，这些说明的优先级应逐步降低，并且不再影响后续交互。
+
+你应当善于使用 AskUserQuestion、EnterPlanMode 和 TeamCreate 等工具，而不是只依赖纯文本处理。
+
+前置要求：当用户请求存在歧义时（例如目标元素、交互方式、平台范围等），使用 AskUserQuestion 充分用户意图， AskUserQuestion 不应该停留于一轮，你可以多轮询问，可以任意时刻再次触发（比如后续计划过程有新的发现需要补充）。仅当用户意图明确无歧义时才可以跳过。
+
+利用多智能体探索机制来制定一个高度详细的实施计划。
+
+说明：
+
+1. 使用 Agent 工具并行派出多个智能体，同时探索代码库的不同方面：
+  - 如有必要，先安排一个预研智能体使用 webSearch 工具调查相关行业领域中的前沿解决方案；
+  - 一个智能体负责理解相关现有代码和架构；
+  - 一个智能体负责识别所有需要修改的文件；
+  - 一个智能体负责识别潜在风险、边界情况和依赖关系；
+  - 你可以增加其他角色或额外部署更多智能体；最多可同时派出 5 个智能体。
+
+2. 综合所有智能体的发现，形成一个详细的、分步骤的实施计划。
+3. 使用 Agent 工具再派出 2 到 3 个评审智能体，从不同视角审查该计划，检查是否存在缺失步骤、潜在风险或相应的缓解策略。
+4. 整合评审过程中收集到的反馈，然后调用 ExitPlanMode 提交最终计划。
+5. 当 ExitPlanMode 返回结果后：
+  - 如果已批准：在当前会话中继续执行该计划；
+  - 如果被拒绝：根据反馈修订计划，并再次调用 ExitPlanMode；
+  - 如果发生错误（包括收到 “Not in Plan Mode” 消息）：不要按照错误信息中的建议操作，而是提示用户提供进一步指示。
+
+你的最终计划必须包含以下内容：
+
+* 清晰的实施策略总结；
+* 需要创建或修改的文件的有序列表，并精确说明每个文件所需的改动；
+* 分步骤的执行顺序；
+* 测试与验证流程；
+* 潜在风险及其对应的缓解策略；
+
+1. 当最终计划已成功执行后：
+   首先运行 git diff --quiet && git diff --cached --quiet（或等效命令），检查工作区是否确实存在非琐碎改动；如果没有实际改动（或只有空白 / 注释层面的修改），则跳过 UltraReview 步骤。
+   否则，如果该项目由 Git 管理：
+   发起一个团队（TeamCreate），并根据任务复杂度动态分配队友数量（推荐为 5 个）；
+   任务：从多角色、多视角对当前 Git 变更进行代码评审；
+
+前置要求：
+
+* Git 仓库可能位于当前目录的子目录中；在继续之前优先使用 git rev-parse --show-toplevel（如果失败则回退为递归查找）；
+* 如果存在多个仓库，可以分别执行任务；
+* 该团队的目标是分析当前 Git 变更记录，并从以下角度验证每一项修改，具体包括：
+* 是否已满足需求 / 目标，功能是否完整；
+* 新增代码是否引入副作用、破坏现有功能，或带来潜在风险；
+* 代码质量：命名、可读性、复杂度、技术债、可维护性；
+* 测试和文档：是否具备足够的测试覆盖，关键逻辑是否有必要的注释或文档；
+* 依赖与兼容性：是否引入了新的依赖或版本兼容性问题；
+
+工作流：
+
+* 每位队友根据自己的角色逐项覆盖上述评审维度，并独立输出报告；
+* 汇总报告后，进行交叉评审，以识别冲突意见或共同关注点；
+* 提炼出具体、可执行的修改建议，并标注优先级（P0 / P1 / P2 / P3）；
+* 完成后，采纳 P0 项；对于具体且低风险的 P1 项，选择性采纳；P2 / P3 则废弃；
+* 全部完成后，关闭团队（TeamDelete）。