工程师怎么把 AI 用进日常开发？

每次打开开发环境，都要跟 AI 重新交代一遍：去哪里看需求，这个项目怎么启动，改完跑哪些测试。

说完这些，它开始写代码。写完以后，再问一次：测了吗？测了什么？还有什么没做？准备交 PR，又得把前面的聊天翻出来整理。

小红书「三花」分享的 Chloe Cursor 进阶工作坊，讲的就是怎么省掉这部分反复交代。演示围绕一个 .NET 电商项目展开，从 Jira 里挑出迁移任务，一直做到验证和提交 PR。Skills、子代理、云代理，都用在了这件具体的事上。

每天都要说的话，先存下来

演示开头，代理先读 Jira，把待办列出来，讲者再选要做的任务。

读工单用的是一个很小的 Skill，里面写了去哪里读、按什么格式返回。讲者以前每次打开开发环境，都要重新说一遍；换个模型，列出来的格式还可能不一样。

这种重复很适合先处理。工单照常写在 Jira 里，代理自己去读。下次开始工作，就少解释一遍。

同样的办法也可以用在启动项目、查日志、跑测试上。挑一个已经做熟的动作，把命令、需要的信息和检查结果的方法写进去。用过几次，发现漏了什么，再补什么。

至于这次到底该做哪项需求，工单里有没有说清楚，还是得在动手前确认。

接手陌生仓库，常常要先花时间找入口、找调用方。直接让 AI 改，它也可能从一个看起来相关的文件开始，一路猜下去。

工作坊里，探索代理读取项目后，通过 Canvas Skill 做了一张交互式架构图，把项目、依赖和信息流放在一起。讨论迁移位置时，有了可以共同指认的对象。

日常改一个接口，用不着每次都画整张架构图。先让它找到接口入口、调用方、数据流和相关测试，列出具体文件，就能开始讨论修改范围。页面出错，也可以直接指出控件和出错区域，省去双方猜“你说的是哪里”。

这张图还需要对着代码核对。漏掉一个调用方，后面的迁移计划也会跟着漏。

演示用迁移 Skill 安排前置检查、规划、实施和验证，也让不同代理分担执行与复核。

其中一个检查值得单独看：演示报告显示，30 项单元测试通过。随后移除迁移后依赖的 Rust 库，测试因为缺少库而失败。

这样做，是为了确认测试确实经过了新的调用路径。否则，改了一堆代码，测试也全绿，可能只是两件碰巧同时发生的事。

修 Bug 也可以这样问：把修复撤掉，原来的问题会回来吗？哪项测试会失败？这比一句“测试已通过”多说明了不少东西。

报告里也保留了未完成的部分：Docker 没有运行，相关功能测试没执行；C# 和 Rust 之间增加了互操作层，代码也因此更难读。这些都是工作坊报告中的结果，不能据此认定整个迁移已经验证完毕。

到了 PR，改了哪些文件、为什么改、测过什么、还欠什么，都要放到一起。工作坊也展示了 Bugbot 对 PR 的代码审查。

如果这些信息还散在聊天里，接手的人就得从头翻。看完文件差异，还要猜哪条测试命令真的跑过、哪段解释已经过时。

云代理适合把一部分长任务放到后台做，过一会儿回来查任务和 PR。开始之前，要把仓库、环境、修改范围和遇到问题时怎么处理交代好。

演示里还有一个处理问题消息的流程：先分出 Bug、普通提问和缺少复现材料的消息，确定属于哪个仓库；对 Bug 再调查、复现。根因明确、修复较小时，才修改并开 PR，不自动合并。

这一步让工程师回来以后，可以直接审查修改，或者补充缺失的信息。

看完这些功能，很容易想一次全接上。下次开发时，可以先留意自己又跟 AI 说了哪句说过很多遍的话。

是“先去看工单”？是“别忘了跑这个测试”？还是“把没做完的也写进 PR”？选一个，把它放进现有流程里，下一次直接用。

我们最近整理媒体工作流，也卡过类似的地方。稿子、图片、发布步骤都准备好了，仍会反复确认哪份是最新版、哪些平台已经发过、工具超时后应该查哪里。把这些地方理顺，才少了一些来回追问。

软件开发里也一样。先让一件重复的事不用再交代，再看下一个经常卡住的地方。

来源：Chloe 的 Cursor 进阶工作坊，小红书「三花」分享。具体演示与测试结果来自该工作坊，文中的日常开发做法据此整理。