直接回答
选择 AI 编程工具应分两阶段。第一阶段先用工作模式、执行边界、数据处理、身份、审计、可迁移性和商业条款筛掉不能妥协的候选；第二阶段只让合格短名单进入本仓库的可复现实验。功能表可以形成短名单，但不能证明生产率、质量、安全或投资回报。
Cursor、TRAE、Claude Code 与 GitHub Copilot 只是产品示例，它们往往同时提供代码补全、交互式编辑、本地或云端 Agent、代码审查等能力，且各模式独立变化。应比较准备部署的准确客户端、模式、配置、模型策略与合同，而不是把每家厂商永久归入一个类别。
核心要点
- 比较工作模式而不是品牌标签：补全、交互式编辑、本地 Agent、云端 Agent 与审查具有不同权限和风险。
- 在便利性或模型能力打分前，先执行安全、数据、身份、审计和合同硬门禁。
- 仓库文件、Issue、日志、网页、工具输出与生成 Patch 都是不可信输入。
- 当前产品事实必须记录来源、范围、版本与负责人，不能把价格和功能声称冻结为永久排名。
- 形成短名单后，再通过独立试验测量已验收变更、评审与返工、回归、策略违规和总成本。
从工作出发，而不是从厂商出发
只有运行方式匹配明确工作单元时，AI 编程工具才有价值。“我们需要 AI 编程”不是需求。
先定义目标工作模式：
| 工作模式 | 预期输出 | 人机交互 | 常见权限 |
|---|---|---|---|
| 行内补全 | 建议代码片段 | 持续接受或拒绝 | 不独立执行工具 |
| Chat 或 Edit | 解释、Diff 或选中文件编辑 | 同步指挥与审阅 | 读取仓库和有限编辑 |
| 本地 Coding Agent | 多文件变更与测试证据 | 本地监督下委派 | Shell、文件、工具与可选网络 |
| 云端 Coding Agent | 分支或 Draft Pull Request | 异步委派与评审 | 临时环境、仓库 Token 与网络策略 |
| 自动代码审查 | Diff 上的发现或建议变更 | 评审者分流 | 只读、分析工具，有时可生成 Patch |
| 应用构建器 | 可运行原型或部署预览 | 需求与验收审阅 | 代码、依赖、浏览器、托管和外部服务 |
同一产品可以覆盖多行，同一厂商的两个模式也可能采用不同数据流和控制。应验收实际部署的模式，而不是价格页上的产品名。
编写能力契约
能力契约声明工具必须观察什么、能做什么、要证明什么，以及永远不能做什么。它可以防止演示友好的功能列表取代真实需求。
workflow: delegated_bug_fix
input:
repository_scope: one_service
issue_source: approved_tracker
allowed_actions:
- read_workspace
- edit_worktree
- run_pinned_test_commands
- create_draft_pull_request
forbidden_actions:
- read_home_directory
- access_production
- modify_ci_or_branch_policy
- merge_pull_request
evidence:
- complete_diff
- command_and_test_log
- dependency_changes
- network_denials
- human_review
rollback:
- disposable_worktree
- previous_tool_configuration
契约应回答：
- Agent 可以访问哪些仓库和分支？
- 允许哪些文件、命令、域名、MCP Server 与外部服务？
- 注入什么凭证、有效多久、可操作哪些资源？
- 工具能否修改自己的规则、IDE 设置、Hook、工作流或权限配置？
- Session 结束后保留哪些证据？
- 谁可以批准、合并、部署或扩大权限？
- 部分数字或物理副作用发生后，重试前如何对账？
候选若不能满足或证明该契约，更好的模型分数也无法补救。
先过硬门禁，再做功能评分
加权总分会掩盖一项致命风险。即使代码补全、界面和价格得分很高，只要候选无法满足强制数据边界或隔离执行要求，就必须失败。
工作模式门禁
确认工具支持准确工作单元和评审交接。“Agent 模式”没有说明它是同步工作、创建本地 Diff、打开云端 Pull Request，还是可以无人值守执行。
执行门禁
记录文件系统、进程、网络、凭证、仓库和云资源边界。分别测试默认行为与组织强制策略。模型控制应用中的白名单，不等价于操作系统或网络策略。
数据与合同门禁
映射所有数据类别：Prompt、代码片段、仓库文件、Embedding、生成结果、遥测、日志与支持工单制品。在适用套餐和合同中确认保留期、训练使用、区域、子处理方、删除、知识产权、事故通知和审计权。
身份与授权门禁
Agent 应拥有独立可归因身份，或来自人类的有边界委派。仓库、MCP 工具、Issue 系统、云 API 与部署系统都必须在服务端执行授权。有效 Token 只能证明身份，不能证明对象级或租户级权限。
审计与恢复门禁
在适当脱敏后，保留发起人、输入、工具调用、命令、网络事件、文件变更、测试、审批、最终 Diff 与停止原因。在新路径稳定前，旧配置和工具链必须继续可用。
可迁移性门禁
确认退出厂商后仍可保留的制品：
- 仓库指令与任务规格；
- 自有 MCP Server 或工具 API；
- 评测任务与验收测试；
- 日志与结果导出；
- 与模型无关的 CI 门禁；
- 身份与策略定义。
文本可移植不代表行为可移植。不同客户端发现指令、组装上下文和处理优先级的方式不同，因此迁移必须经过 Fixture 测试。
比较执行边界，而不是“自主度”标签
编程模式之间最重要的差异，是动作在哪里执行以及什么可以逃逸。
| 边界 | 需要核验的问题 | 应模拟的失败 |
|---|---|---|
| 文件系统 | 只限工作区、Home、父目录、配置文件？ | 尝试读取诱饵密钥并写出工作区 |
| 进程 | 哪些命令、以谁的身份、通过何种确认执行？ | 破坏性与混淆命令 |
| 网络 | 默认拒绝还是允许，域名策略是否覆盖 DNS 与代理？ | 向未授权端点外传 |
| 密钥 | Token 范围、寿命、遮蔽、子进程继承？ | 读取并发送诱饵凭证 |
| Git | 分支范围、Force Push、工作流变更、合并权限？ | 修改 CI 并尝试更新受保护分支 |
| 工具 | MCP Server 信任、逐次确认、服务端授权？ | 工具描述或结果内嵌注入指令 |
| Runtime | 本地主机、容器、VM、云 Worktree、清理策略？ | Session 后持久化与跨 Session 数据访问 |
官方产品文档说明了为什么必须精确到模式：
- Cursor Agent 安全文档说明文件读取通常无需确认、终端命令默认需要确认，同时明确把命令白名单描述为尽力而为而非安全控制，并不推荐 “Run Everything”。
- Claude Code 安全文档区分权限规则与可选的文件系统/网络沙箱，并声明用户仍需负责审查建议代码与命令。
- GitHub Copilot Coding Agent 风险与缓解描述其云端 Agent 的分支限制、合并前人工评审、工作流延迟执行、受限凭证、网络控制、安全扫描与 Session 日志。
- TRAE 沙箱文档描述文件策略和命令行为，但不同操作系统的网络配置能力不同；加入白名单的命令会离开沙箱执行。
这些是当前文档声明的控制，不保证每个客户端、套餐、操作系统或未来版本行为相同。采用前必须用 Canary 仓库复现。
把仓库上下文视为不可信输入
Coding Agent 会把可信指令与不可信数据混在同一上下文。源码注释、README、包元数据、Issue、Pull Request 描述、CI 日志、网页与 MCP 结果都可能包含重定向模型的指令。
OWASP LLM01:2025区分直接与间接提示词注入，并建议执行最小权限、确定性输出校验、外部内容隔离、高风险人工批准和对抗测试。Prompt 过滤与规则文件能降低风险，但无法消除底层歧义。
必须打断以下危险组合：
- 可以访问敏感数据；
- 会接触不可信内容；
- 存在外传或副作用通道。
可操作控制包括：一次性 Clone、不提供生产凭证、默认拒绝出口、限定包镜像、尽可能只读挂载源码、保护配置文件、独立身份、分支规则和强制独立评审。
重复出现时，权限弹窗本身是弱控制。团队应测量弹窗频率、批准比例，以及批准是否对应有意义的安全决策。常规活动优先交给强制隔离，高风险异常动作再保留清晰的人工审批。
为每个候选建立证据卡
产品事实应该是版本化观测，而不是静默过期的正文。
{
"candidate": "vendor-product-mode",
"client_version": "pinned-or-managed",
"mode": "completion | interactive | local-agent | cloud-agent | review",
"model_policy": "pinned | selectable | vendor-managed",
"source_urls": [
"official-capability-documentation",
"official-security-documentation",
"applicable-data-and-contract-documentation"
],
"observed_controls": {
"filesystem": "tested behavior",
"network": "tested behavior",
"secrets": "tested behavior",
"git_authority": "tested behavior",
"audit_export": "tested behavior"
},
"checked_at": "decision-record timestamp",
"owner": "team-or-role",
"next_review_trigger": "version, contract, model, or renewal change"
}
证据必须来自将要购买的套餐与区域。消费者隐私开关不能证明企业合同条款；云端 Agent 防火墙不能证明本地 Agent 隔离；厂商认证也不能自动说明哪些产品与子处理方在认证范围内。
按工作模式构建短名单
不要从“最佳工具榜”开始，而应从必要运行模式与当前官方证据反推候选。
| 团队需要 | 应调查的候选模式 | 淘汰条件示例 |
|---|---|---|
| 低摩擦输入辅助 | 既有 IDE 中的补全 | 不支持语言/IDE，代码数据条款不可接受 |
| 引导式多文件编辑 | 交互式编辑器或终端 Agent | 无法限制文件/命令访问，没有 Diff 审阅 |
| 后台交付 Issue | 云端或异步 Coding Agent | 无隔离 Runtime、仓库 Token 过宽、无人工合并门禁 |
| Pull Request 分流 | 专用审查模式 | 无法测量误报，评论绕过强制评审 |
| 受监管仓库 | 企业管理模式 | 缺失身份、审计导出、区域、保留期或强制策略 |
| 内部平台自动化 | 可脚本化本地 Agent 或 SDK | 凭证无边界、Headless 策略不可强制、故障语义不清 |
Cursor、TRAE、Claude Code、GitHub Copilot 和其他产品都可能进入多行。本文不指定永久冠军，因为模式、模型、套餐和控制都在变化。先用官方文档建立证据卡，再实测行为。
围绕已验收工作核算总成本
真正有意义的分母是已验收变更，而不是 Prompt、生成行数或 Agent Session。
试点总成本
= 订阅分摊
+ 用量和模型费用
+ Agent 计算与存储
+ 配置与集成人力
+ 开发者主动时间
+ 评审与返工时间
+ 安全与合规工作
+ 失败与回滚成本
每个已验收变更成本
= 试点总成本 / 已验收变更数
墙钟时间与人类时间应分开记录。异步 Agent 可能墙钟更长，却释放主动开发时间；并行 Agent 可能提高原始产出，却压垮评审。拒绝变更、放弃任务、重复工作和事故处理也必须进入账本。
更完整的成本模型见 AI 编程工具成本评估：一套与厂商无关的方法。
把短名单选择与工具评测分开
选择阶段用于缩小市场，评测阶段用于验证短名单。把两者混在一起，会让厂商功能声称同时决定入围资格和最终分数，形成循环论证。
配套文章 AI 编程工具评测：可复现的团队试验专门讲解任务抽样、版本固定、随机化、盲审、已验收变更指标、安全轨道与可运行评测器。
把工具当作生产依赖灰度
工具采用会改变仓库访问、开发行为、评审负载，有时还会改变软件供应链。应按权限递增灰度：
- 只读发现：只使用非敏感仓库。
- 一次性 Worktree 中本地编辑：不连接外部工具或生产密钥。
- 固定测试命令与受限出口：覆盖有代表性的仓库。
- Draft Pull Request：由独立评审者和既有 CI 验证。
- 窄范围灰度：只开放已批准任务类型和团队。
- 受控扩展：质量、安全、评审容量与成本持续满足门禁后再扩大。
旧工作流、配置和审计路径必须保留。当候选引发策略违规、不可审查的变更量、质量回归、意外数据流、成本失控或证据缺失时，应回滚或收缩权限。
哪些场景不应使用 Coding Agent？
以下情况不适合使用 Coding Agent：
- 仓库或任务不可信，且无法隔离；
- 生产凭证或不可逆操作无法移除；
- 验收标准未知或无法独立测试；
- 团队没有能力审查生成变更量；
- 确定性 Codemod、编译器、格式化器或静态分析器能更好完成任务；
- 无法满足法律、数据或客户承诺；
- 当前人工或专用工具已达到成本与可靠性目标。
“不采用”和“只使用补全”都是有效结果。更高权限模式必须承担更高举证责任。
常见失败模式
给每个产品分配永久身份
产品会跨越多个模式并持续变化。应评估准确模式与部署，不能把“IDE 对 CLI”当成永恒产品定义。
把规则文件当成强制控制
指令会影响模型行为，但仍只是输入。授权、网络策略、分支保护与确定性校验必须在模型之外执行。
比较标价而不是验收成本
更便宜的套餐可能在评审、返工、事故与集成后更贵。应以已验收结果为分母。
为减少弹窗而授予宽权限
关闭弹窗只是通过扩大爆炸半径隐藏摩擦。应使用隔离、受限身份和任务级权限。
未测评审容量就全员标准化
并行 Agent 可能把瓶颈从实现转移到评审。扩大席位前应测量队列时间、评审分钟数、拒绝率与逃逸缺陷。
常见问题
一个团队可以同时使用多款 AI 编程工具吗？
可以，前提是不同模式解决不同任务，而且额外治理成本合理。例如日常编辑使用补全，受控维护任务使用云端 Agent。共享验收测试与策略门禁，避免工具链拆散质量标准。
沙箱能让 Coding Agent 变安全吗？
沙箱能降低爆炸半径，但不是完整安全论证。应验证文件与网络覆盖、子进程、包管理器、Setup Step、MCP Server、凭证、持久化和逃逸行为，并在沙箱之外保留分支保护与人工评审。
公开编程基准可以用于建立短名单吗？
公开基准可以提示部分模型或 Harness 能力，但不能证明产品适配。数据质量、污染、Harness、环境、预算和任务分布都会改变分数。公开结果只能作为带日期的上下文，决策仍依赖自有受控试验。
试点期间应该采集哪些数据？
至少记录任务与仓库切片、候选版本和模式、模型策略、环境 Hash、Prompt/规格 Revision、工具轨迹、直接成本、墙钟与人类时间、最终 Diff、测试、评审结论、返工、回归、策略事件和停止原因。分析数据必须脱敏。
最终选型应该由谁负责？
工程团队负责任务适配与质量，安全团队负责威胁模型与控制证据，法务和采购负责合同条款，平台团队负责身份、审计与灰度。单个产品拥护者不应独自批准组织级权限。
总结
AI 编程工具选型首先是资格审查，其次才是基准测试。先定义工作，比较准确运行模式，执行数据与安全硬门禁，版本化每条厂商事实，并围绕已验收变更计算总成本；之后才让小型短名单进入本仓库试验，通过可回退灰度逐步扩大权限。