AI IDE 可以检查仓库、提出修改并调用工具，但不能替代工程控制。可靠的工作流需要明确范围、假设、权限、验收测试和回滚路径，也要把 Cursor 与 TRAE 的功能视为版本敏感的集成，而不是所有客户端都一致的行为。

核心要点

  • 可验证的任务契约比戏剧化角色扮演或要求模型输出隐藏思维链更有用。
  • 依赖规则路径、文件引用、快捷键或自动加载前，先核对当前客户端版本。
  • 指令应短小且贴合仓库；可确定执行的规则交给 Formatter、Lint、类型检查和 CI。
  • 先要求简短计划和假设，再审阅 diff 并测试变更行为。
  • 生成代码、检索文件和工具结果在通过仓库门禁前都只是未经信任的提案。

AI IDE 为什么会“翻车”

常见原因包括：

  1. 范围不清：“修复登录”没有说明入口、支持行为和非目标。
  2. 项目事实缺失：模型看到的依赖图、文档或配置不完整或已过期。
  3. 指令冲突：厂商规则、仓库约定和当前任务互相矛盾。
  4. 验收不足：只看视觉上合理的 diff，没有测试异常、授权和兼容路径。
  5. 工具权限过大：Agent 可以编辑、执行或检索超出任务需要的内容。

上下文工程的作用是降低这些不确定性，不是保证模型永远正确。

先核验厂商功能

Cursor 与 TRAE 可能在规则文件名、目录、Glob 触发、聊天命令、模型路由和工具权限上不同。针对实际版本记录：

契约 需要核对
规则加载 路径、优先级、触发条件和是否需要重新加载
文件引用 语法、支持的文件类型及内容是否离开工作区
命令 快捷键、操作系统差异和自定义方式
工具权限 终端、网络、文件系统和确认策略
模型行为 模型/版本、上下文限制、留存和供应商政策

仓库中先维护与厂商无关的项目契约，厂商适配文件只保留必要内容并指向事实源：

markdown 
## 项目契约
- 运行时和包管理器版本记录在仓库中。
- 修改前先阅读目标模块及其测试。
- 授权必须在服务端执行，不能信任客户端声明。
- 未经明确决策，不新增依赖或修改公共接口。
- 合并前运行文档列出的 lint、类型检查和测试命令。

可验证的工程任务 Prompt

text 
目标：替换 `src/forms/LegacyForm.tsx` 中的旧邮箱校验。
范围：
  - 阅读 `src/forms/userSchema.ts` 和现有表单测试；
  - 保持公共 props 与现有错误信息行为；
  - 不修改无关文件或依赖。
约束：
  - 使用仓库已批准的 Schema 库；
  - 保留无障碍标签和 test ID；
  - 不记录提交值。
修改前：
  - 返回简短计划、影响文件、假设和待运行命令。
修改后：
  - 展示 diff 摘要并报告未解决的边界问题。
验收：
  - 现有测试通过；
  - 对空值、非法值和国际化输入有明确测试。

要求模型提供计划、假设和不确定性报告，可以帮助审阅者决策；不需要要求模型输出隐藏思维链，后者也不是可靠的审计产物。

规则应当可验证

好的规则描述行为和检查方法：

markdown 
## API 变更
- 使用此包已有的 Schema 库校验请求体。
- 返回项目规定的错误结构。
- 为未认证和错误租户增加负向测试。
- 验证命令：`npm test -- api && npm run lint`

避免“模型总能看到整个仓库”或“每个模型都会加载该文件”之类的断言。安全规则、数据处理、支持版本、命令和架构边界应放在经过审阅的文件中；格式、类型和确定性质量要求交给工具与 CI。

重构工作流

1. 建立基线

先阅读目标实现、调用方、测试、配置和公共接口，并运行最小相关测试，避免把既有失败归因于模型。

2. 限定变更

列出允许修改的文件和非目标。让 IDE 先给出计划与假设；如果发现授权、迁移或数据模型变化超出范围，就暂停并做决策。

3. 生成草稿

只提供必要代码片段和合成 fixture。没有批准的数据政策时，不要把生产 Token、客户记录、私有证书或事故细节放入模型上下文。

4. 审阅 diff

检查 API 兼容性、错误路径、输入校验、授权、日志、并发、可访问性、本地化和依赖变化。Diff 工具只能展示文本差异，不能证明语义等价。

5. 验证行为

运行格式化、类型检查、单元/集成测试和针对性负向用例。重构应使用 fixture 对比新旧行为，而不是依赖视觉相似；生成的改动必须可回滚。

测试生成不能盲信

先要求测试矩阵，再要求生成测试代码：

维度 示例
有效输入 普通、边界、Unicode、允许范围内的大输入
非法输入 缺失、畸形、超大、类型错误
安全 未认证、错误租户、重放、注入形状数据
状态 重试、超时、重复请求、部分失败
兼容 公共 API 与支持的运行时版本

生成的测试可能复制生成代码的错误假设。至少加入人工审阅的 fixture，并确认断言在行为错误时确实会失败。

上下文预算与敏感数据

上下文被截断时，不要简单粘贴更多文件。按权威性和新鲜度排序来源，压缩稳定事实，把任务证据放在请求附近，并在需要复现时记录所包含的文件和版本。

代码、注释、Issue 文本、检索 Markdown、工具结果和生成补丁都应视为不可信内容。不得让文档覆盖系统或项目安全规则；限制终端与网络权限，破坏性操作要求确认，日志中脱敏凭据。

常见问题

客户端使用不同的规则文件约定怎么办？

以该版本的官方文档为准。事实源与适配器分离，并增加集成检查或手动验证，确认文件确实被加载。

如何防止 AI 删除无关代码？

定义允许修改的文件集合，要求先给计划，审阅 diff，并拒绝范围外变更。“其余保持不变”有帮助，但仓库审查和测试才是实际控制。

让模型审查自己的补丁可以吗？

可以作为第二个信号，但不具备独立性。应结合确定性检查、必要时的独立审阅者/模型，以及会在已知错误行为下失败的测试。

延伸阅读

总结

AI IDE 的高阶用法不是命令技巧，而是受控协作：核验客户端行为，定义范围和验收，最小化上下文与工具权限，审阅 diff，并保留可回滚路径。快捷键、模型和规则文件格式变化时，这些工程原则仍然成立。