Auf dieser Seite8 Abschnitte
本文基于 2026 年 9 月的资料整理。价格、模型和界面名称可能变化；这是一份操作指南，并非实时产品状态。
向 Agent 提供有用的项目约束，无需把每次提示都写成完整规格。
编写能够验证的规则
先写明验证修改所需的命令、重要源码目录，以及一两项架构约束。“使用已有的表单校验函数”比“编写整洁代码”更容易执行。这些是建议的编写方法，不同工具的文件名和规则启用方式并不相同。
起始指令示例
按照代码仓库情况调整此示例，再通过工具文档说明的规则或指令功能保存。
Before editing, inspect the nearest existing implementation.
Use the package manager already configured in this repository.
Run the relevant checks for changed behavior.
Report any check you could not run and why.
Do not edit generated output directly.验证规则确实生效
尝试一个能看出规则影响的小任务，检查输出和执行的命令。如果规则影响了无关工作，就缩小其适用范围。项目规则应像构建说明一样随代码仓库一起维护。
完成第一个真实任务：修改、验证与审查
-
选择一个已经能够构建的小仓库，先保存干净的 Git 检查点，并记录当前可以通过的检查命令。这样才能判断后续问题是项目原有故障，还是本次生成代码引入的回归。
-
只描述一个可观察的结果，例如给已有表单增加必填项，并在输入无效时展示错误且阻止提交。提供相关文件、现有校验函数，以及必须保持不变的行为，避免把多个重构目标混在一起。
-
在编辑前要求一个简短计划，确认计划覆盖受影响的组件、数据流和验证命令。缺少上下文时先定位入口，不要直接让代理大范围改造项目结构。
-
分批查看差异，除了页面效果，还要检查新增依赖、生成文件、环境变量和异常处理。运行项目检查，并分别验证正常提交、无效输入、请求失败等路径。
-
完成后查看用量记录，记下被接受的结果、人工审查时间和消耗。再用第二个有代表性的任务复测，之后才决定是否购买更高套餐或迁移整个团队的工作流。
可直接改写的任务说明
目标：描述用户能看到的变化。
上下文：列出相关文件和已有实现。
约束：保持公开 API，沿用现有依赖。
验证：运行仓库文档中的检查，并覆盖失败路径。
完成标准：说明改动文件、已执行检查和剩余限制。生成结果不可用时如何定位
请求成功不等于代码正确。代理改错文件时，缩小范围并明确提供入口；命令失败时，先在相同终端环境中手工复现；MCP 连接失败时，把服务启动、凭据和客户端配置分开检查；用量不足时，先查看账号余额与当前模型，不要反复重试同一请求。把失败补丁控制在可以单独回退的范围，避免丢失其他尚未提交的工作。
迁移前的常见问题
付费订阅是否等于无限使用 Agent？
不是。订阅价格、包含用量、模型权限和额外用量是不同概念。无限自动补全也不意味着模型请求或云端任务无限。
需要一次接入所有 MCP 服务吗？
先接入当前任务真正需要的一个服务。验证它能启动、暴露正确工具、只接收预期项目上下文之后，再逐个增加其他集成。
怎样公平比较两个 AI 编辑器？
使用相同仓库、相同任务和相同验收标准，比较有效改动、审查成本、配置阻力和实际用量。功能列表更长，不代表在你的项目里生成的代码更好。
TRAE 站内延伸阅读
Weiterlesen
Weitere Artikel zu verwandten Themen und Tools.
Erwähnte Tools
Einträge passend zum Thema dieses Artikels.
