CLI 日常工作方法

把任务目标、范围和验证要求放在提示里，能让 Copilot 更容易判断工作是否完成。复杂变更先调查，再规划；简单且边界明确的修改可以直接实施。

从现有项目事实开始

先询问具体入口、调用关系、数据模型或测试位置，例如“定位登录流程，解释 session 在哪里创建和校验”。需要修改时指出目标行为和不应改变的约束。

用 /init 或手工指令整理真实的构建、测试和风格规范；保持简洁，避免互相冲突。不要把模板中的 npm 命令当作所有项目都存在。

一轮完整工作

1. 探索相关实现和调用方。
2. 用 /plan 形成包含验证步骤的方案。
3. 审阅范围与假设，补齐缺失条件。
4. 实施改动，必要时用 Fleet 拆分独立任务。
5. 执行适合变更的测试与检查，审阅 diff。
6. 明确哪些验证通过、哪些仍无法完成，再按项目流程提交或发 PR。

需要写测试时，先描述应观察到的行为，而不只要求模仿实现。发现问题后要求提供文件位置和复现证据。

保持会话聚焦

自动压缩支持长会话，但不相关工作仍应 /new。/context 查看占用，/compact 可带聚焦说明；checkpoint 是压缩摘要，不是文件回滚点。

旁支概念解释可用 /ask，需要进入后续任务的需求必须用普通提示。明确区分会话分叉和新建空对话。

权限与工具

只预批准任务所需的工具或命令模式，结合 deny 明确排除不希望自动执行的操作。宽泛 shell(git:*) 包含写操作，不能把它当成只读 Git 权限。

权限批准和沙箱是独立机制。外部 MCP 提供更多能力，也带来外部数据和操作，应明确具体服务与所需工具。

多仓库与视觉输入

从共同父目录启动，或用 /add-dir 添加已审阅目录，可处理跨服务接口变更。/list-dirs 检查范围；新添加目录的 Skills 和 Agents 也会作为可信配置加载。

图像可拖入、粘贴或通过 @ 引用。描述希望匹配的布局与交互，但模型和组织策略仍须支持 vision，附件成功加入不保证模型一定能读取。

选择执行方式

本地交互适合持续纠偏；长任务可使用明确目标的 Autopilot；互相独立的工作可用 Fleet；云端异步任务用 delegate。BYOK 的 delegate 仍转给 GitHub 端 Copilot，不会把自带 provider 一起迁移。

通过 /usage 查看本次用量，使用明确的续作和额度限制，并核对当前版本口径。团队评估效果时观察从 issue 到 PR 的时间、评审迭代和实际缺陷，而不只统计生成代码行数。