JetBrains AI：把 IDE 内代理接回项目证据链
一次很像“已经修好”的事故，往往发生在 IDE 的绿色对勾之后：开发者让代理把一个过时 API 批量迁移，Junie 改完几十个调用点，编辑器里也没有红线；合并前才发现运行配置仍把旧环境变量传给集成测试，测试其实没有启动目标服务。另一次更隐蔽，聊天附带了整个配置目录，包含了本机可用但不该上传的连接信息。AI 的回答是否流畅并不重要，真正要追问的是：它读到了什么、改了什么、执行的命令由谁批准、绿色结果对应哪一条运行链路，以及失手后怎样恢复。
JetBrains AI 把对话、项目模型、编辑器、终端和测试入口放在同一个窗口里，便利也使边界更容易被忽略。AI Assistant 可以基于选择文本或附加文件给出建议；Junie 则可以规划多步任务、编辑文件、运行命令，并在启用外部工具后调用 MCP。这里的“项目”不是一团可随意发送的文本，而是 SDK、模块、依赖、生成目录、运行配置、版本控制状态与本机凭据交织的执行环境。每一次 AI 辅助修改都应回到项目原本的编译、inspection、测试和 Git 证据。
从一处错误重构开始建立边界
先准备一个没有真实账号、私钥、客户数据、生产日志或内部地址的练习仓库。它至少有一个可替换的方法、一个覆盖该行为的测试，以及一条能从命令行运行的构建命令。不要把日常工作的完整 checkout 作为第一轮试验，也不要把尚未清理的终端输出贴进聊天。代理在错误仓库里成功执行，仍然是错误。
把任务缩到可判断的动作，例如“把 legacyFormat 的调用迁到 formatV2，不改变空值语义；只修改 src/main 与相邻测试；不要运行网络下载或发布命令”。这不是提示词修辞，而是让 diff 有明确的可审查边界。若变更包含数据库、授权、构建缓存或发布脚本，应拆开处理；一个聊天会话不该同时承担代码改造、环境排障和凭据配置。
在开始聊天前记录工作树，建立一个本地历史标签，并确认 IDE 的项目 SDK 与命令行运行时一致。下面命令只使用虚构项目名和占位分支，预期是干净的基线或可解释的既有差异；若出现未知文件，先停止让 AI 写入，不能把它们归因给尚未开始的任务。
git status --short
git diff --check
git branch --show-currentIDE 中可用 File | Local History | Put Label 写入例如 before-ai-format-migration 的标签。Local History 会记录 IDE 内外有意义的文件变化，适合恢复误删或对比某次本地修改；它是本机二进制历史，不是共享备份，也不替代提交、远端仓库或受保护分支。重装新版本、清理系统目录或磁盘故障都可能让它消失，因此真正可交付的恢复点仍要进入 Git。
安装、启用与账号许可不能混为一件事
在受支持的 JetBrains IDE 中，AI Assistant 以插件形态存在。先从 IDE 的 Settings | Plugins | Marketplace 搜索并安装 JetBrains 发布的 AI Assistant，再打开 AI Chat；产品能显示 AI Chat 或工具栏 widget，并不证明插件已安装，这两个入口本身不访问代码。官方 安装说明 给出的兼容基线是 IDE 版本标识 2023.3+，Community Edition 需要版本标识 2024.1.1+，PyCharm Unified 需要版本标识 2025.1+；Community Edition 使用组织订阅还要求版本标识 2024.2.1+。这些是最低入口，不是团队应长期钉死的版本。批准清单还要同时记录 IDE build、AI Assistant 插件版本、操作系统、项目 SDK 和回滚包，因为“满足最低版本”不能证明当前组合经过测试。
安装、激活和具体 Agent 授权是三个状态。AI Assistant 可以使用 JetBrains AI 订阅、组织批准的外部模型或集成 Agent；但官方 Agent 激活矩阵 将 Junie 单独列出：Junie 通过 JetBrains AI 激活，不支持把供应商 OAuth 或 BYOK 当成 Junie 的替代授权。由外部 key 驱动的 AI Chat 能回答问题，不代表 Junie 已可用；Junie 图标出现，也不代表组织已经分配许可或允许该项目发送上下文。团队应登记实际接入路径，避免个人 key、试用账号和组织账号在同一开发机上发生静默切换。
首次登录应核验账号归属和 IDE 许可状态。IDE 许可、JetBrains AI 许可和模型供应商授权并非同一张凭证：一个人拥有可运行的 IDE，不表示已经获准向 AI 服务发送项目上下文；一个组织开通 AI 服务，也不表示每个本地插件或第三方代理都自动获得同样权限。遇到“登录成功但请求被拒绝”，先检查 AI Chat 的激活状态、IDE 版本兼容性和组织管理策略，再检查网络，不要用来历不明的激活补丁、共享账号或长期个人 API key 绕过。
账号状态可以通过两个相互独立的动作验证。先打开一个无敏感代码的文件，选中几行纯示例逻辑，执行解释请求，确认 AI Chat 使用了批准的账号与模型入口；再切换到 Junie，要求它只生成计划而不编辑、不运行命令，确认 Agent 可用且没有触发个人 key 回退。关闭当前项目的 AI Assistant 后，这两个入口都应不可用。真正项目中，组织许可变化、额度耗尽或服务不可达都应呈现为明确失败，而不是静默切换到另一个个人账户。JetBrains 的 许可与用量说明 会随产品调整，团队记录座席、额度归属、负责人和停用条件即可，不把临时价格、请求次数或营销套餐写进项目配置。
Settings | Plugins | 搜索 "AI Assistant" | Install | Restart IDE
View | Tool Windows | AI Chat | Start with JetBrains AI | 登录组织批准的账号
Help | Register | 核对 IDE 许可主体；AI Chat | 核对 AI 服务激活主体出现以下反向证据时不要继续：插件来自未知发布者；登录页面跳到不受控账户；Chat 提示许可无效却仍要求填入个人 key；组织禁止 AI 时有人建议修改 hosts、注入 agent 或复制别人的 token。这些不是安装故障的修复路径，而是供应链、账号和审计边界已经失效的信号。
上下文是逐次附加的，而不是整个项目的默认授权
AI Assistant 与 Junie 会使用当前交互所附带的内容，但可见文件、已打开标签、索引结果与代理实际读取的文件并不是同义词。Junie 的官方说明指出，自动 IDE context 默认可包含当前打开文件及其中选择的文本；其他文件和更广的项目内容需要主动附加。这个默认足以支撑一个重要习惯：先关闭不相关标签，先选中要讨论的函数或测试，再用 @ 精确附加一个接口、实现和测试，而不是把模块根目录交给对话。
需要跨模块改造时，先写出“事实文件集”：公开接口、实现、调用点、测试、构建配置。让 AI 先只读地列出它认为需要修改的文件和理由，人工核对后再允许编辑。若它突然要求读取 .idea、*.env、日志、导出数据、证书、IDE 配置或用户目录，先问清代码任务为何依赖这些内容；大多数业务重构不需要它们。索引可以帮助发现符号，却不应成为把所有历史、缓存和密钥都交给模型的理由。
单仓库任务要确认 IDE 当前打开的项目就是目标 checkout，不能把提示词里的路径清单误写成文件系统权限。monorepo 要用 .aiignore、项目拆分、操作确认和 diff 共同收窄修改面，避免“修一个 package”时连同文档站、基础设施或另一个服务一起改动。对话中的“我只会修改 X”只是任务约束，不是强制控制；可观察的控制来自 IDE 的逐项确认、可见 diff、ignore 规则、受限账号和版本控制。
任务：仅迁移 packages/catalog/src 与 packages/catalog/test 中的 format 调用。
允许读取：接口、实现、调用点、单元测试、对应构建文件。
禁止读取：.env、secrets/、exports/、logs/、.idea/、用户目录。
先输出：候选文件清单与每个文件的修改理由；等待确认后再编辑。正向实验中，选择一个三文件的小改动：接口、实现、测试。关闭自动上下文或只保持当前文件，手工附加这三项，让 AI 先生成计划；预期候选清单不包含构建产物和配置目录。随后允许修改，预期 Git diff 只触及三项或其必需的相邻文件。反向实验把一份虚构的 secrets/demo.env 放入仓库并加入忽略规则，再在该文件中触发 AI 动作；预期动作被阻止或提示该文件受限。若仍能处理其内容，立即停止试验，记录 IDE、插件和规则状态，关闭该项目的 AI 功能并向产品支持渠道报告，不能假设忽略是绝对数据隔离。
陌生项目先经过 Safe Mode，再决定是否交给 AI
项目文件不只是源码。Gradle、Maven、sbt、启动任务、GDSL、File Watcher 和运行配置都可能在项目打开或导入时执行代码。IntelliJ IDEA 的 Project security 在首次打开未知项目时提供 Safe Mode：可以浏览源码，但构建工具导入、依赖解析、启动任务、VCS、GDSL 和 File Watcher 等能力受到限制。先在这里检查构建脚本、wrapper、.idea、.run、插件声明和外部工具配置，再决定是否 Trust Project；不要为了让 AI 或索引立即工作而直接信任下载目录。
Safe Mode 不是恶意插件沙箱，也不是 AI 数据防泄漏边界。它降低项目内容触发执行的机会，却不会替代插件准入、账号隔离和网络控制。Trusted Locations 还会让其子项目以后自动以可信方式打开，尤其不要把用户主目录、下载目录或共享盘根目录加入信任列表。JetBrains 官方还指出，命令行以 headless 方式启动项目时默认按可信模式打开，因此自动化检查必须在隔离账号、容器或专用工作区中运行，不能把 GUI 的信任弹窗当成 headless 流程的保护层。
可以做一个不执行未知代码的反向检查：复制脱敏练习仓库，在构建脚本里加入只输出固定标记的测试任务，首次以 Safe Mode 打开。预期是不发生构建导入、依赖解析或启动任务执行；只有人工审查并信任项目后，才允许明确运行该任务。若 Safe Mode 下已经出现标记输出，先查是否由 IDE 外部进程、已有终端、受信任父目录或插件触发，保留日志后退出项目，不要继续启动 AI 代理掩盖来源。
用规则描述工程事实，用忽略切断数据入口
规则和忽略解决两类不同问题。项目规则是告诉 AI 如何工作，例如必须保留空值语义、使用项目测试命令、不得修改生成代码、改完先展示 diff；忽略文件是告诉工具哪些路径不得处理。把“不得上传密钥”写在规则里并不能阻止读取，把“只改 src”写在 ignore 里也不能给出编码规范。两者都应随代码评审进入版本控制，并由代码 owner 审查。
JetBrains 的项目规则可放在 .aiassistant/rules/*.md。规则可以按总是应用、文件匹配、手动调用或由模型决定等方式触发；对安全和构建约束，宜使用稳定、易识别的文件匹配或总是应用，不让模型自行猜测。Junie 还可读取根目录 AGENTS.md 作为持续指令。两处不要相互矛盾：AGENTS.md 写任务边界和验证命令，规则文件写语言、模块或评审约束；同一条禁令只保留一个权威位置。
<!-- .aiassistant/rules/catalog.md -->
## Catalog 模块约束
- 保持 `null`、空字符串和缺失字段的既有区分。
- 不修改 `generated/`、锁文件或发布配置。
- 修改公共接口时，更新相邻单元测试。
- 完成编辑后只报告实际运行过的命令和退出码。.aiignore 使用与 .gitignore 相近的模式，用于限制 AI Assistant 对特定文件和目录的处理。官方 限制或禁用 AI Assistant 的说明 还说明，根目录的 .cursorignore、.codeiumignore 或 .aiexclude 可被识别。这是兼容便利而不是跨工具的统一安全策略：每个已安装的 AI 插件都必须单独验证其忽略语义，尤其是第三方插件并不会因 .noai 或 .aiignore 自动停用。
# .aiignore：只放不应进入 AI 上下文的内容
.env
.env.*
secrets/
exports/
logs/
*.pem
*.p12
.idea/将 .aiignore 创建出来还不够，需要在 Settings | Tools | AI Assistant | Project Settings 启用它，并做一次可见的拒绝实验。不要把整个 src/ 放进去再宣称安全，那会使工具不可用；也不要把 *.json 一概排除，因为项目可能需要公开的 schema。按数据分级列出真实类别：凭据、客户导出、调试日志、私钥、生成物、IDE 本机状态。反向模式常见于否定规则写错，例如先忽略 *.java 再只放行生产目录却漏掉测试目录，导致 AI 看不到验证文件并生成错误补丁；这时修正模式与测试边界，而不是让代理绕过忽略。
对完全不允许使用 JetBrains AI 的仓库，可在根目录放置 .noai，或在项目的 AI widget 中选择禁用。前者随仓库传播，后者只影响当前项目设置；两者都不约束第三方集成、浏览器聊天或复制粘贴。高敏感仓库还应在受管网络、插件准入和账号策略层阻断相应服务，形成多层控制。
Junie 的编辑和命令必须经过可回放的确认点
Junie 适合处理多步代码任务，也因此比补全更接近一个会修改工作树的协作者。官方 Junie 操作说明 明确说明它可编辑文件、运行测试或终端命令；默认会对建议的 bash 命令、文件修改、文件操作和外部工具请求批准，Always allow 会让同类操作以后不再询问，Brave Mode 则允许命令和文件修改不经确认。Always allow 是批准决策的持久化，不是“只允许这一个安全命令”；Brave Mode 更不是沙箱。真实仓库不应把二者当作省点击的默认值。文件写入、终端命令、网络访问、MCP 工具和 Git 操作应拆成不同确认点，任务越大，确认点越多。
一个受控的正向实验如下。先让 Junie 做只读调查，要求它回答调用链和测试入口；确认候选文件后，再授权应用补丁；补丁出现后不让它直接提交或推送，而是由开发者在 Diff 视图逐块接受。预期是每个修改都能解释为最初的任务约束，测试新增或调整能证明语义没有漂移。若代理改动锁文件、IDE 配置、远程脚本或无关模块，即使主目标看似完成，也视为失败证据，回退那些块并缩小下一轮权限。
先执行只读调查：列出 legacyFormat 的定义、全部生产调用点、相关测试与运行配置。
不要编辑、不要运行命令、不要访问 MCP。
确认后：只改已确认的文件；每修改一个文件展示差异；
运行测试前先显示完整命令、工作目录和是否需要网络；不执行 git commit、push、发布或删除命令。MCP 会把 IDE 外的能力引入代理：文件系统、工单、浏览器、数据库、部署或内部服务都可能变成工具调用。只有明确允许的、最小权限的 MCP server 才可暴露给 Junie；在 Settings | Tools | AI Assistant | Agents 开启 Pass custom MCP servers 后，已配置工具可由代理按需自动调用，并不会因为它们没有显示在 / 菜单中就失效。AGENTS.md、项目路径和 .aiignore 用来减少误读与误改，但都不能替代 MCP server 自身的鉴权：工具进程如果持有生产凭据，提示词里的“只读”不会把它变成只读。先在无敏感数据的环境中调用只读工具，记录输入、输出、实际身份和网络目标，再考虑写操作。不要因“只是 IDE 内的聊天”就把数据库查询或云控制台工具设为自动调用。工具失败时保留失败输出即可，禁止让代理用另一个具有更高权限的工具悄悄重试。
远程开发把索引、执行和插件搬到了后端
通过 JetBrains Gateway、SSH、WSL 或 Dev Container 打开项目时，源代码、项目加载、索引、分析、构建、运行和测试主要发生在远程主机上的 backend IDE，JetBrains Client 负责本地界面。于是“开发机没有源码副本”不等于“AI 没有源码访问”：AI 插件、项目索引、命令日志、缓存和网络出口应按 backend 所在环境审查。远端主机若能访问生产网络或云实例元数据，代理执行命令的风险还会高于普通笔记本。
插件位置也要区分。官方 Remote development overview 说明，提供 inspection 和 IDE 功能的插件安装在 backend；JetBrains Client 侧插件主要改变 UI、快捷键、主题等交互。试用 AI 功能前记录连接目标、backend IDE build、插件 ID 与版本、远端网络代理、缓存目录和账号来源。只在本地 Client 禁用一个 UI 插件，不能证明 backend 上的插件、代理会话或 MCP server 已停止。
远程正向实验使用脱敏仓库与无生产权限的主机：先在 backend 查看插件状态和运行配置，再让 Junie 读取一个测试文件并运行无网络单测；预期命令工作目录、进程和日志都落在远端，diff 能在客户端审查。反向实验断开远端网络或撤销测试身份后再次执行只读请求，预期明确失败且不回退到本地个人账号。退出时同时清理远端插件、AI 登录、MCP 配置、临时 checkout 和缓存，并从新会话验证旧能力不会恢复。
运行配置决定绿色结果到底测了什么
AI 最容易放大的错误不是语法错误，而是错误的执行入口。IDE 可以从编辑器运行一个测试、保存临时 run configuration、运行 Gradle/Maven/npm 脚本，或引用共享的 .run 配置。它们可能使用不同 JDK、工作目录、环境变量、模块 classpath、profile、容器或 mock。一个代理把代码改对了，却触发了错误配置，得到的成功仍不能证明任务完成。
先为代表场景建立命名清楚的配置，例如 catalog-unit、catalog-contract-no-network。共享配置只保留可公开的项目事实，敏感变量从系统环境或受管秘密服务注入；不要将 token、密码、真实 URL、开发者绝对路径或个人证书提交到 .run、.idea、脚本或聊天。配置中出现 API_TOKEN=example-placeholder 也不等于可以运行，验证时应从受控环境注入测试值。
<!-- .run/catalog-unit.run.xml：示意，敏感值不进入文件 -->
<component name="ProjectRunConfigurationManager">
<configuration name="catalog-unit" type="GradleRunConfiguration">
<ExternalSystemSettings>
<option name="externalProjectPath" value="$PROJECT_DIR$" />
<option name="taskNames"><list><option value="test" /></list></option>
<option name="scriptParameters" value="--tests *Catalog*" />
</ExternalSystemSettings>
</configuration>
</component>先从 IDE 运行一次，再从项目约定的 CLI 运行一次，比较测试数、失败数、运行时版本和关键日志。预期两条链路针对相同目标，且失败时都能定位到同一测试；若 IDE 绿而 CLI 红，优先检查运行配置的 JDK、working directory、Gradle delegation、环境变量和测试过滤条件。不要让 AI 通过删除失败测试、扩大 ignore、加入 -x test、吞掉异常或把断言改成空断言来换取绿色。
./gradlew test --tests '*Catalog*' --info
if ($LASTEXITCODE -ne 0) { throw "catalog tests failed" }反向实验可故意把一个虚构环境变量设错，或让测试断言一个未迁移的行为。预期是运行配置明确失败并保留堆栈；如果仍然通过，说明这条配置没有覆盖所声称的路径。恢复正确设置后再运行，预期失败测试转绿且测试数不减少。这个实验比让 AI 解释“测试应当通过”更接近可审查证据。
inspection、测试与 diff 分别抓住不同错误
Inspection 擅长发现静态问题：未使用代码、可疑空值、类型不一致、过时 API、代码风格和部分性能风险。测试验证的是在给定输入和依赖下运行行为是否符合预期。Diff 则回答“到底改变了什么”。三者不能相互替代：没有 diff 的绿色测试无法排除无关改动；没有测试的 inspection 无法证明业务语义；只看 diff 也看不出运行时拼错了环境变量。
AI Assistant 可用来解释 inspection 或提出修复，但不能替代 inspection 的实际执行。对较大变更，使用 IDE 的 Analyze | Inspect Code 选择项目配置，或用命令行 inspector 对未提交变更生成报告。命令行 inspector 依赖项目 SDK，并会启动后台 IDE 实例；运行中的 IDE 占用会使该入口失败，所以失败信息应保留并改用正在运行的 IDE 执行 inspection，不要忽略检查。
# 伪路径以本机安装实际 launcher 为准；只检查未提交改动并输出报告目录
inspect.sh . .idea/inspectionProfiles/Project_Default.xml -changes -format json -output inspection-reportDiff 审查应分层进行。先看文件清单，确认没有密钥、锁文件、生成物或无关目录；再看每个 hunk，确认空值、异常、并发、序列化和授权逻辑没有被“简化”；最后看测试 diff，确认新增测试在修复前会失败、修复后会通过。AI 生成的注释、重命名和格式化也可能遮住真实逻辑变化，必要时先把格式化拆出单独提交。审查者应能指出哪个断言覆盖哪个事故，而不是只接受“已增加测试”的总结。
git diff --check
git diff -- src/main src/test
git diff --name-only当 inspection 报告与测试相冲突，例如静态检查建议把一个显式 null 分支删掉但兼容测试要求保留，应以项目行为契约为准，写出具体抑制理由或调整规则，不要让模型在两者之间随意选择。涉及安全、权限、数据迁移、支付、删除和外部副作用的变化，还需要独立人工审查；AI 的 self-review 只可作为补充意见。
用 Local History、Git 与禁用动作处理撤销和泄露
发现代理误改后的第一反应不应是继续让它“自动修回来”。先停止当前任务和终端命令，保存当前 diff，判断改动是否已经进入暂存区、提交、远端或外部系统。未提交的少量编辑可在 IDE Diff 中逐块回退，或用 Git 恢复指定文件；本地历史适合找回已删除文件和对比一个标签前后的状态。外部系统已收到的请求、上传的内容或已泄露的 token，不能靠本地回滚消除，必须转入凭据撤销、会话注销和审计流程。
# 仅恢复明确确认误改的文件；执行前先检查 diff
git diff -- src/main/java/example/catalog/Formatter.java
git restore --source=HEAD -- src/main/java/example/catalog/Formatter.java
git status --short若 AI 请求中误带了秘密，立即停止继续对话，撤销相关 token 或 OAuth 授权，旋转受影响凭据，检查 Git diff、IDE 剪贴板历史、终端滚屏、日志、聊天附件和可共享报告。随后将对应路径加入 ignore，并复盘为什么秘密会位于可读项目中。不要在问题单或截图中再次粘贴秘密来证明事故。
停用 JetBrains AI 时，先在当前项目禁用以确认工具栏和动作消失；需要仓库级限制时添加 .noai；需要个人退出时从 AI Chat 注销并在插件设置中禁用或卸载。卸载前确认是否仍有第三方 AI 插件、MCP 配置或外部 CLI 能读取同一工作区。网络层阻断只对指定服务入口有效，不能替代插件盘点和账号撤销。
隐私、性能与额度都应成为可观察成本
隐私不只取决于“是否使用云模型”。请求中的代码、选择文本、文件名、聊天历史、命令输出、错误堆栈和 MCP 返回值都可能构成数据；本地索引、IDE 缓存、Local History 与日志也会留下副本。JetBrains 的 数据处理说明 区分了完成请求所必需的服务处理与可选的详细数据收集：前者会把请求及所需上下文发送给所选模型服务链，后者在用户选择加入时可能包含与模型的完整通信，包括文本和代码片段。关闭详细数据共享不等于停止模型请求，也不改变外部 Agent、BYOK、MCP server 各自的数据处理。应在 Settings | Appearance & Behavior | System Settings | Data Sharing 核对实际开关，并按账号、许可、模型提供方、Agent 和数据类别分别建立出口清单。对于不允许离开受控网络的数据，直接禁用对应服务，并给开发者提供不用 AI 也能完成诊断、重构和测试的路径。
长对话与广泛上下文会增加等待时间、成本和误关联。复杂任务可以分为调查、方案、编辑、验证四个短会话，每段都带上最小文件集和可见的退出条件；模型或推理级别提高时，观察它是否真的改善了 diff 和测试，而不是只让回答更长。对 Junie，运行命令、调用 MCP、扫描大型项目和反复重试都可能消耗更多资源，应在任务记录中保留持续时间、实际命令、失败次数和是否发生网络访问。
组织可把费用与质量一起复查：每类任务的人工审查时间、测试失败率、无关文件改动率、额度异常消耗、隐私事件和禁用恢复次数。成本过高不一定意味着工具无用，常见原因是任务过大、上下文过宽、规则不稳定或运行配置失真。先修复这些工程输入，再讨论是否扩大订阅或开放更高权限代理。
插件治理不能停在“推荐大家安装”。自建小团队可以维护插件 ID、来源、版本区间和升级窗口；使用 JetBrains IDE Services 的组织可以按全部插件、企业仓库、vendor 或具体插件配置规则。需要注意其能力边界：官方 插件管理说明 区分 Block (Forced)、Block on Restart、Disable 与 Allow，部分广域规则只支持本地环境，而具体插件规则才覆盖本地和远程的部分阻断场景；Disable 后开发者还可能手工重新启用，不能把它当作强制封禁。策略变更后必须重启并从本地、backend 和新建项目分别验证实际状态。
长期维护让工具始终能被安全地拿走
JetBrains AI 的团队基线应至少包含：允许的 IDE 与插件版本区间、账号接入方式、允许模型和外部代理、项目规则与 ignore 文件、MCP server 清单、默认确认策略、运行配置、检查与测试命令、审查责任人、升级观察窗口和退出步骤。它们属于项目工程资产，不应只藏在某位成员的聊天历史、个人设置或截图中。
每次插件、IDE 或规则升级，都在脱敏代表仓库先跑一轮：打开项目、索引、只读问答、小改动、diff 审查、inspection、测试、禁用恢复。升级后若出现自动附加更多上下文、确认窗口减少、运行配置变更、网络目的地新增、错误日志异常或测试结果漂移，应冻结推广并恢复上一组已知可用版本与配置。版本号本身不是安全结论，行为证据才是。
退场也要演练：移除组织授权后，AI Chat 是否确实拒绝请求；禁用项目后，Junie 是否不能编辑；删除 MCP 配置后，外部工具是否不再出现；清理账号后，新成员是否不会通过同步重新获得旧权限。所有结论都应来自实际 UI 状态、命令输出、diff 和测试报告。没有运行过的实验要明确标记为待执行，不把示例命令、预期现象或模型总结写成已经发生的事实。