Code Agent 的 Goals 功能一直对我有着比较强的吸引力，原因是我认为我们最终会进入一种状态：人的主要精力花在前期的设计上，包括功能，架构，测试，部署，验收方式的设计，剩下的事全都交给 Agent 来完成，只有这样，人的能力才会通过 Agent 实现 Scaling，如果像早期人与 Code Agent 的交互那样，隔几分钟就不断被 Code Agent 要求决策，那人的能力是难以被放大的，就像你管理一个研发团队，如果每隔几分钟，就来个程序员问这问那，你这一天也别干别的了。
这周我经历了一次失败的 Goals 的使用经历，记录下来是为了进行反思，避免再有类似问题，让我下一次能更成功地使用 Goals。
这个项目并不是一个复杂的项目，他的目标是对某种事件做概率预估，我们需要构建一个数据集，用机器学习方法进行建模，从而对未来的事件发生的概率做预测，在前期我已经做了大量实验，实验代码以及实验记录都要完整保留，由于实验效果不错，现在要把这些实验代码变成一个独立的工程项目，完成模型定期更新，数据定期批量预估，增量预估。这是个不大不小的项目，不是几百行的小工具，也不会大到超级复杂，因此我使用 goals 功能来完成这个项目。
由于前期已经有大量代码和实验记录，因此在使用 goals 时，并没有把每个环节都说的非常清楚，因为我觉得这些信息已经在历史代码和文档里有了，以模型现在的能力，完全可以参考以前的信息完成新项目，但事实证明我错了。我花了一天时间和 code agent 讨论设计，并通过 HTML 的方式查看，审核，修改设计，然后通过 goals 来实现这个设计，快是真快，然而这个快，有点类似周星驰电影里那个著名的“我的船是出了名的快“，结果并不是很快到达目的地，只是”沉的快“，在花了一天时间完成代码后，我花了 4 天时间去改各种问题，才正确实现了所有功能。
回顾这一周的经历，我形成了以下反思:
- Goals 的目标
Goals 的目标，并不是运行很久，然后 “完成任务”，而是“正确地完成任务”。
- 关键环节要说清楚
尽管模型能力已经比较强，但它毕竟是个基于概率的模型，你不知道他是否真的能把关键信息找对，找全，而一个 Goals 任务，是有很多步骤的，步骤之间可能有前后依赖关系，如果一步出错，可能后面就全错了，例如我遇到的，模型在第一步构建数据集的时候就搞错了，后面做再多任务又有什么用？在 Claude Code 那些官方示例中，有很多 case 都表明了这样一种态度，能明确的事，不要让模型去猜。
- 关键环节要有明确验证办法
即使关键环节的设计完全说清楚了，也不能保证设计和实现一定正确，所以要有强有力的验证办法，即使无法完全精确，也要追求尽可能的正确。你可以不说正样本率是 1.1% 还是 1.2%，但大致范围应该是明确的，这样一旦构建完数据集发现正样本率是 0.1%，agent 马上能意识到有可能有哪些出错了。