夜雨聆风最近我在几个项目中尝试了 AI 编程助手的 /goal 功能，覆盖了 UI 还原、可视化生成、协议栈测试工具几个方向。下面把我的一些使用过程和想法整理出来，供参考。
/goal 是一种目标驱动的开发模式：你给定目标描述、约束和技术栈，AI 自动规划并执行多个步骤，最终产出一个完整的交付物。和逐步对话或分阶段 plan 不同，goal 更偏向“给定验收标准，放权让它跑完”，你最后去验证结果。这种方式比较适合那些一眼就能看出对不对的任务。如果验收成本很低，你就可以放心地把整个流程交给它；如果需要逐行审阅代码、细抠每个设计决策，goal 的长程自动执行就会变成一种负担。
案例一：UI 还原——验收简单，适合 goal
第一个任务是还原一份设计稿的 UI。前期我先用 DrawSkill 定义了还原度的评判方式，约定了整体架构、依赖组件、技术栈（Tailwind、React 等），并加入了 AI Element 相关约束。在正式启动 goal 之前，我和 AI 反复对话，细化目标，直到觉得目标描述足够清晰才放行。第一轮 goal 跑了约 31 分钟，中间我打断过几次，继续追问和修正。最终跑了两个 goal，总时长不到一小时。
验收过程很简单：把生成页面和设计稿截图放在一起对比就行了。大体上和截图比较接近，细节并不完全一致，但因为参照物明确，哪里不符合预期一眼就能看出来。这时候我可以选择继续迭代：让它重新细化目标，加入更多约束，然后把之前的代码全部抛弃，从头重来。因为验证成本低，推倒重来没什么负担。
小结：UI 还原这类视觉任务，验收直观，很适合 goal 模式。只要你能给出明确的验收截图，就可以把执行过程交给 AI。
案例二：工作流可视化——依赖规范文档
第二个任务是 CodeMode 可视化。我希望把任意一个工作流文件中的流程以图形化方式渲染出来，每个节点上的文字来自代码中的注释，最终效果类似我此前看到的一些参考图。因为我知道参考仓库在哪，也知道想要的效果，前期就先通过对话讨论技术栈和依赖，生成设计文档和规范。等到规范文档基本成型，我才让它推荐一个 goal。看到 goal 描述大致没问题后，就用 /goal 命令让它开始跑。第一次跑了 40 分钟，我主要看生成的截图，中间的详细日志没有细看。图的效果有点像预期，但有些地方跑偏了。
于是我没有在已有产出上修补，而是重新讨论：强调约束，更新规范文档，修正那些不可能从工作流代码里推导出来的多余元素，并让它把之前的产出全部放弃。然后再次设定 goal，又跑了 50 分钟。第二次的图虽然还不够美观，但方向对了——因为它已经开始调用真正的 CodeMode 官方内容。之后再经过一轮约束更新和目标细化，最终产出接近参考图的效果。整个过程累计跑了两三个 goal，总耗时约两个多小时。
小结：对于代码生成加可视化这类任务，规范文档很重要。你不需要规定每一步怎么实现，但验收标准、参考实现、技术依赖和“不能做的事”要写清楚。只要一看截图就知道对不对，就能用较低成本迭代。
案例三：tester 工具——验收困难时，谨慎用 goal
第三个任务是为已有协议栈构建一个外部的 tester 测试设备，相对独立，不会破坏主线代码。我同样先聊了几轮前期设计，让它给出完整的设计方案（而不是分步 POC），然后生成规范文档。因为我清楚自己不太可能逐行审阅整个 tester 的实现，所以特别强调了一条核心约束：修改不能影响已有协议栈，如果有任何怀疑，必须先停下来问我。同时让它把是否独立仓库、是否创建独立 crate 这类决策直接明确下来，不要模棱两可。
设定好 goal 之后，它就开始跑了，目前已经运行了近七个小时。对于这种长周期的任务，我的预期是：不指望产出能到 90 分，差不多 70、80 分就可以。因为最终我只会验收它有没有破坏约束，以及整体上离一个真正的 tester 还差多远、覆盖了多少原有规范。如果结果大差不差，我会拿去测试一下被测件的响应时间，不会再深度重构。
但过程中也暴露出问题：对于需要精细把控的后端逻辑，goal 的自动发挥容易产生大量冗余。之前在生成需求文档时，AI 就自行扩充了很多字段和设计，并不是我想要的，最后不得不回头核对删减。对于已有系统，这种风险尤其需要注意——你很可能在不知情的情况下，被改动了协议的某个角落，事后排查成本很高。所以对于已有系统的修改，除非已经设好基线、能随时回滚，否则我会更倾向于用 plan 模式：让它分阶段给出方案，自己审过之后再小步推进。
一些操作心得
- 目标描述要锁定边界：每次设定 goal 时，我会追问 AI：“这个目标需要参考哪些规范文档？有哪些依赖？”并把这些明确写进目标描述或规范中。光靠几段话太灵活，容易跑偏。
- 验收标准前置：决定用 goal 之前，先判断自己能不能在几分钟内判断产出对不对。如果能，大胆用；如果不能，考虑拆解成更容易验收的子目标，或者改用 plan。
- 不怕推倒重来：goal 模式试错成本低。一旦发现方向不对，就更新规范、调整约束，然后彻底抛弃旧代码重新 goal。舍不得抛弃反而会拖慢迭代。
- 区分任务类型：探索型任务可以跑一次 goal 看看方向，快速获得认知，即使代码最终不用也有收获。交付型任务需要稳定代码质量时，规范要落到足够细的颗粒度，并把验收脚本或截图对比纳入流程。
- 长期运行的 goal 设定满意线：对于 tester 这类无法快速全面验证的任务，提前给自己设一个心理预期分数（例如 70 分）。只要它满足核心约束、方向没有系统性偏离，就可以先收下，后续根据实际使用情况再决定是否需要新一轮修正。
总结
/goal 对任务的可验收性要求比较高。UI 与可视化类任务因为验收直观，用起来很顺手；后端逻辑或存量系统修改则需要更多克制和前置设计。在实际使用中，我通常会先通过多轮对话把规范文档磨清晰，再交给 goal 去执行，最后用很低成本去验证和迭代。如果打算尝试，建议先从一个“一眼就能判断对错”的任务开始，体会“设定目标—跑完—验收—必要时推倒重来”的节奏，这样能更具体地感知 AI 辅助开发的边界。
