我仍然记得我第一次下载TRAE的样子，那是一个橙红色极简的软件图标，当时AI刚出来，在阴差阳错下，我打开了豆包，让他帮我开发一款背单词的应用，但是由于每次输入提示词后都会重新输出，这样低效率的样子让我一度放弃了AI编程的念头。我当时就在想，AI就不能不要每次重新输出，而是定向修改呢。在豆包输出代码时，我发现了他，然后，点击下载。一切都不一样了。AI没有重新输出，而是能记住上下文，精准地帮我修改每一行代码，哇，这就是编程啊。
后来我逐渐开始用trae帮我进行swift的编程，随着时间的增长，我对TRAE放手的力度也越来越大，最初知识想让TRAE帮我写一两行代码的我逐渐慢慢的把整个程序“丢”给了他，但随着仓库的增加，AI对于我的一些要求也开始变得应接不暇，渐渐的，我开始厌烦AI在最终给我一个“不可编译”的报错代码，于是我写下了第一行规则
在程序完成前须整体编译验证，如果错误，请检查、修改并再次编译
再后来，我开始对TRAE在长时间做任务后上下文的压缩及其最大输出开始觉得不好，于是我进行了分批次的P（优先级）和子代理先行。最初我只是简单地把任务拆成P0、P1、P2，让AI依次写完一个再写下一个，但很快发现主代理一边调度一边写代码，写着写着就把前面的约定忘了，于是我把主代理从编码岗位上彻底撤下来，规定它只负责拆解调度与任务委派，不写实现代码，只有同一子代理同一任务连续失败2次，或改动被≥3个模块依赖的核心基类时，本体才可介入。
再后来，我发现子代理之间其实可以并行，只要按UI/逻辑/数据层切分，相互无依赖时同时拉起≥3个子代理并行开发，存在依赖关系时按依赖顺序串行，同时另起1个审查子代理实时检查代码风格、符合spec、有无bug，单次并行上限定为15个，一般只在批量网页搜索、多文档并发分析这类数据密集场景下才全开。
再后来，我开始厌烦AI拿垃圾信息当真理，于是我规定用户给链接时优先用agent-browser读，失败则用WebFetch并附来源；新功能必须检查异常处理、UI自查（圆角/色值/悬停/适配/与原风格匹配）、功能完整性，禁止跳过任何检查步骤。
再后来，我被AI自作聪明猜需求坑过，于是我写下需求不明确必须用AskUserQuestion询问，不得猜测，不要结束对话；技术细节自行查文档。我也被它在plan模式下批准方案后就擅自开写代码坑过，于是我明确用户先说“不要写代码/只写方案”并开启spec/plan模式的，NotifyUser批准方案≠编码授权，AI立即停止等下一步，下一轮用户明确说“开始写代码/可以编码”才算正式授权，且仍遵循优先级流程。
再后来，我发现AI被拒方案后会摆烂收工，于是我规定如果用户拒绝了这个方案，禁止停止对话，需要询问用户原因并重新做一份；如果批准了方案，参考优先级流程和编译验证。每个优先级阶段结束时须整体编译验证，确认无误后再进入下一优先级，若项目仅有单个优先级则在最终交付前编译验证一次即可。
再后来，我担心一次性的豁免被AI当成永久的尚方宝剑，于是我规定用户须明确引用条例编号并说明可违反，该豁免才在当前对话回合生效，且不继承至下一轮或任何子代理，若豁免产生技术债务，AI需在交付时声明。我也碰到过AI在自己够不着的地方反复撞墙，于是我允许它遇到难以解决的问题时申请让我运行相应的程序并给我调试信息，同时可以让用户在出问题的时候打入它给的命令，从第一性原理出发。
再后来，我把生图生视频、GitHub下载文件这些我权限之外的事也写成了协作条款：生视频时不要调用视频生成插件，使用mcp_sensenova-u1-fast（推荐）、mcp_agnes-image和mcp_agnes，生成图片时禁止停止对话，获取到图片/视频后下载下来并给用户或放入应该放入的地方，严禁通过链接提供，生成期间可以先去干本轮对话的其他任务并更新todolist，把查看图片的任务放在合适的位置，在对话最后告诉用户调用AI绘画的提示词和画的链接；如果有什么需要在GitHub下载的文件，可以让用户帮忙下载，但要给出仓库位置。
再后来，我发现AI经常在长任务中途断开，我说continue它却不知道从哪接起，于是我规定当用户说continue时，请继续完成前面的事情，如果前面开启了plan或spec，在这一轮对话继续。
就这样，规则从最初的一行“编译验证”，一步步长成了如今的十六条。每一条都不是凭空设计的，全是我在某个深夜对着报错日志、残缺代码、跑偏的方案时咬着牙写下的。我与TRAE的关系，也从“我写代码它补全”变成了“我定规则它执行”。放手的力度越大，规则的颗粒度就要越细。这大概就是与AI协作的真相：你越是想当甩手掌柜，就越要先当一个好立法者。