把容易漏掉的条件，写进 Skill。

方案完整，不等于条件想清楚了

设计一个付费试点时，方案可能讲清客户能得到什么，却没有交代双方分别要做什么，或者在没有依据时替业务承诺了价格、周期和效果。

我在个人 GTM 项目里，把客户洞察、Offer 设计和定价包装拆成不同的 Skill。这里主要讲 Offer Design：怎样把一个客户愿意购买、团队也有条件交付的方案写清楚。

从场景和缺失信息开始

我先让 Skill 识别当前场景和缺失信息，再要求输出写清交付范围、双方责任，以及哪些条件还只是提案。

测试使用两个合成场景：一个营销服务付费试点，一个分期课程 Offer；每种配置重复运行三次，并保留不使用该 Skill 的对照输出。它们用来暴露规则遗漏，不是实际成交案例。

一次课程场景暴露的遗漏

方案拒绝了没有依据的效果保证，却没有完整说明双方未履约时如何处理。

合成课程场景 · 对照已记录的遗漏与规则调整。

测试中发现

拒绝效果保证之后，学员没有满足参与条件怎么办？课程方没有交付约定内容怎么办？这些条件仍然缺失。

写回执行规则

分别说明学员责任与服务方补救。价格、退款、补救等未获批准的条件，继续标为提案，不写成已生效承诺。

我补充规则后，重新运行这一场景。保留的一份输出写道：

课程方未履约时，按最终批准的交付补救条款处理。

这是一条原始输出摘录，来自合成课程场景。它说明这一份输出写到了服务方责任，不能代替对所有运行结果的逐项核验。

留下什么，下一次才能继续改

我把发现的遗漏写回规则，并保留输入、输出和修改记录。下一次看到类似问题时，可以回到具体条件，而不是只说“这次写得不好”。

场景与输入

业务前提、已知条件和仍未确认的信息。

执行规则

交付范围、双方责任、承诺依据与提案状态。

迭代记录

原始输出、遗漏条件、对应修改与重新运行。

结果与局限

这些是合成场景上的内部迭代记录，没有使用真实客户成交数据，也没有把输出分数当成商业效果。读取 Skill 与参考资料还增加了运行时间，是否值得使用，要看当前任务需要多严格的约束。

后续需要用未参与调试的新场景检查，再观察真实任务中的反馈。当前分享设计方法与案例，代码暂未公开。