摘要

本文总结 goal-loop skill 的实践经验：面对复杂 AI 研发任务，不应直接让 Agent 写代码，而应先把父目标、子目标、边界、验收方式和证据链固定下来。文章给出目标澄清清单、三类过程文件、执行门禁、归档结构和脱敏示例，帮助团队把一次 AI 辅助研发从“会话推进”变成“可复核交付”。

复杂 AI 研发任务最怕的不是做不动，而是做着做着失控。

一句“帮我做一个平台”“把这个流程自动化”“接一个测试工具”，听起来很明确，但真正执行时会很快遇到这些问题：

• 最终交付到底是什么？
• 第一版 MVP 到哪算完成？
• 哪些目录能改，哪些系统不能碰？
• 能不能引入依赖、调用外部服务、写生产数据？
• 做完之后靠什么证明已经完成？

goal-loop 解决的不是“AI 怎么写代码”，而是“AI 研发任务怎么被治理”。

面向读者：正在用 AI Agent 推动研发任务的平台研发、测试平台负责人、技术负责人、AI 工作流建设者。

一、为什么复杂任务不能直接开始实现

很多 AI 编程失败，不是模型能力不够，而是目标没有先被约束。

对简单任务来说，“改一个按钮文案”“修一个接口字段”可以直接进入代码。
但对跨模块、跨工具、跨验证链路的任务来说，直接实现会带来三个风险：

1. 目标漂移：一开始说做 MVP，最后变成重做整个平台。
2. 边界失控：本来只允许本地验证，过程中却碰到生产系统或外部服务。
3. 验收含糊：代码写完了，但没人能说明“为什么算完成”。

goal-loop 的价值，就是先把这些风险前置。

它把一次复杂任务拆成：

父目标澄清
-> 子目标拆解
-> 过程资产落盘
-> 分阶段执行
-> 真实验证
-> 发布门禁
-> 脱敏归档

这比“让 AI 直接开工”慢几分钟，但能省掉后面大量返工。

二、第一步不是写代码，而是问清 9 个输入

goal-loop 的第一条规则很关键：不要马上实现。

它会先要求确认父目标输入。可以抽象成这 9 个问题：

1. 最终结果是什么？
2. 第一版 MVP 范围是什么？
3. 第一个样例产品、用户流、接口或场景是什么？
4. 当前仓库的技术栈、脚本、文档、测试和约束是什么？
5. 哪些文件/目录允许改，哪些区域禁止碰？
6. 是否允许引入新依赖或开源工具？
7. 是否允许接外部系统、CI/CD、生产环境、通知或账号？
8. 敏感数据边界是什么？
9. 最后是否需要 commit、push 或 PR？

这些问题看起来像流程，但本质上是风险控制。

尤其是第 6、7、8 条，很多 AI 研发事故都出在这里：

• 未确认就装依赖
• 未确认就碰外部系统
• 未确认就读取真实数据
• 未确认就把私有日志写进报告

复杂任务里，AI Agent 不是越主动越好，而是要在边界内主动。

三、三份核心文件：GOAL、GOALS、REPORT

这个 skill 最值得借鉴的是三份过程文件。

1. GOAL.md：父目标契约

GOAL.md 解决的是“这次到底要交付什么”。

它至少应该包含：

父目标
首个 MVP
被验证样例
架构取向
工具策略
AI 能力边界
最终交付物
完成标准
允许修改范围
禁止事项
验收方式

这里最重要的不是写得漂亮，而是能约束执行。

例如“禁止事项”要写清楚：

不操作生产数据
不提交密钥
不自动部署
不接真实外部缺陷平台
不执行真实压测
不修改被测业务系统代码

这些内容一旦写入 GOAL.md，后续 Agent 执行时就有明确边界。

2. GOALS.md：子目标执行顺序

GOALS.md 解决的是“先做什么，后做什么”。

每个子目标都应该包含：

目标说明
完成标准
允许修改范围
禁止事项
依赖关系
执行顺序

一个典型拆法如下：

G0 父目标澄清与过程资产
G1 仓库上下文与约束梳理
G2 架构设计与工具评估
G3 本地门户与 API 服务
G4 样例项目接入
G5 自动化工具接入
G6 AI 生成与人工复核
G7 执行编排、报告、历史和问题记录
G8 验证与本地验收
G9 脱敏归档与收尾

这类拆解的好处是：每一步都能独立验收，而不是全部堆到最后。

3. REPORT.md：过程账本

REPORT.md 解决的是“过程中发生了什么”。

它不只是总结，而是持续记录：

当前状态
已完成事项
当前进度
阻塞问题
风险
验证记录
产物清单
下一步计划
需要用户确认的问题

这里最有价值的是“验证记录”。

每条验证最好包含：

时间
命令/检查
结果
说明
证据路径

这样结束时不是一句“已完成”，而是一组可追溯证据。

四、发布门禁：不是所有通过都等于可以发布

复杂 AI 研发任务里，验证通过不等于可以上线。

goal-loop 会把发布状态单独放到 RELEASE_GATE.md 里。

这个文件可以记录：

当前结论
本地验证
发布风险
门禁状态
是否执行上线动作

特别值得保留的是三类状态：

通过：已经验证且证据充分
Needs Review：结果存在，但需要人工判断
Needs Action：当前阻塞，需要后续处理

这比简单的 PASS/FAIL 更适合真实研发。

例如：

• 测试通过，但工作区不是 clean，可以标为 Needs Review
• 接口返回 401，可能是认证边界，不一定是产品缺陷
• 本地运行成功，但外部镜像拉取失败，可以标为 Needs Action

这样做能避免两个极端：

• 把所有异常都当失败
• 把所有能跑通都当完成

五、归档不是备份，而是交付证据

goal-loop 还要求维护本地运行记录：

ai-rd/runs/<run-id>/

推荐结构：

TASK.md
DESIGN.md
TEST_PLAN.md
CHANGELOG.md
RELEASE_GATE.md
HANDOFF.md
evidence/
outputs/

这里的 evidence/ 很关键。它应该放：

• 截图
• 测试结果 JSON
• 报告文件
• 失败样本
• 只读验证证据
• 脱敏后的上下文索引

归档时还要明确哪些东西不能复制：

密钥
真实客户数据
原始生产日志
私有 payload
浏览器 session
cookies
缓存目录
数据库 dump

这一步对公开分享尤其重要。经验可以公开，原始敏感材料不能公开。

六、一个脱敏后的执行示例

下面是一个脱敏版的 goal-loop 结构，用于说明它怎么落地。

场景：团队希望把一个本地研发工具改造成“AI 辅助测试平台”。

父目标：

将现有工具改造为本地优先的 AI 辅助测试平台。
支持项目接入、自然语言生成测试用例、人工复核、Web/API 执行、报告、历史和问题记录。

MVP 范围：

以一个脱敏样例项目作为被测对象。
默认只做只读 smoke。
平台仅本机运行，不部署到生产环境。
不接真实缺陷平台，不提交任何密钥。

子目标：

G0 明确父目标和边界
G1 梳理仓库上下文
G2 设计本地平台架构
G3 实现门户和 API
G4 接入样例项目
G5 接入测试执行器
G6 加入 AI 用例生成与人工复核
G7 生成报告、历史和问题记录
G8 执行本地验收
G9 脱敏归档

验收证据：

本地门户可访问
登录流程可用
样例项目可接入
测试用例可生成
用例需人工确认后才可执行
Web/API smoke 可运行
报告和历史可查看
本地测试命令通过
截图和 JSON 证据已归档
发布门禁明确写出是否上线

这个例子里的重点不是某个具体平台，而是闭环方式。

七、这个 skill 对外部团队的借鉴点

如果团队也在做 AI 辅助研发，更适合先复用它的思想，而不是照搬目录名。

最值得复用的是这 5 条：

1. 先确认父目标，再进入实现。
2. 子目标必须有完成标准和禁止事项。
3. 验证记录必须写命令、结果和证据。
4. Needs Review 和 Needs Action 要和 FAIL 区分开。
5. 归档只复制脱敏证据，不复制敏感原始材料。

可以把这套机制落成一个最小模板：

GOAL.md      目标契约
GOALS.md     子目标拆解
REPORT.md    过程账本
RELEASE_GATE.md 发布门禁
evidence/    验收证据
outputs/     交付产物

只要这几个文件稳定存在，AI 研发任务就不再只是一次对话，而是一条可追踪的交付链。

八、使用时的注意事项

goal-loop 不是所有任务都要用。

适合使用：

• 跨模块工程改造
• AI 工作流平台建设
• 测试平台、报告平台、数据平台类任务
• 有生产/外部系统/敏感数据边界的任务
• 需要验收证据和归档的任务

不太适合使用：

• 修改一个小文案
• 修一个简单 bug
• 生成一份临时说明
• 不需要过程资产的一次性任务

它的成本是前期要多问几句、多写几份过程文件。
但只要任务复杂度上来，这个成本是值得的。

最后给一个可复制清单

下次你准备让 AI Agent 执行一个复杂研发目标前，先问这张清单：

目标是否写成 GOAL.md？
MVP 范围是否明确？
禁止事项是否明确？
是否拆成可验收子目标？
每个子目标是否有完成标准？
是否记录验证命令和结果？
是否区分 PASS / Needs Review / Needs Action？
是否有 RELEASE_GATE.md？
是否有 evidence/ 证据目录？
是否能脱敏归档？

AI 研发的关键不是让 Agent “更努力”，而是让任务从一开始就进入可治理状态。

goal-loop 的经验可以概括成一句话：

先把目标变成契约，再让 AI 去执行；先把证据留下来，再讨论是否完成。