Files

6.4 KiB
Raw Permalink Blame History

本局创作方案

meta

name: 本局创作方案
id: creation-plan
artifact: 设计.本局创作方案
declaration: >
  先抽出用户要的核心体验,再主动找出有帮助的内容能力并分档,形成本局专用创作方法;它指导取舍,不规定固定流程。
when: |
  尚无本局创作方案,且用户已经给出有效创作方向;或用户改口、新增方向,导致现有方案明显不再成立。
when_not: |
  只是在既定方向内补充局部材料,现有方法与能力分档仍成立时,不重复改写。
boundary: |
  本能力只决定本局怎么做、哪些内容能力重要以及还缺什么;不代替任何能力生成正文,不安排 DAG,不进入游玩上下文。
feeds: design_only

task

根据用户当前材料生成或整份重写「本局创作方案」,写入 `设计.本局创作方案`。方案用于指导后续创作取舍:先定本局要兑现的体验,再形成针对这份体验的方法,并把程序提供的全部内容能力各分到一个档位。

先抽出核心体验,再扫能力目录找有帮助的能力,最后才写方法和分档。核心体验是用户想反复感到、扮演或达成的那一件事;从角色、限制、例子和题材里抽,即使用户没把它叫做体验。写进 `brief`。不要停在原话点到的题材词和能力名上。

然后用这份体验逐项看能力目录。用户没点名、但缺了会使体验立不住、持续不了或跑不起来的能力,标成「必须」或「有必要」,把还没选定的具体内容写进 `missing`。用户点到、却不承载这份体验的能力,降到「有一定效果」或「没有意义」。只写真实语义依赖;`items` 的排列不表示执行顺序,也不是本轮要写完的清单。缺口留给后续询问,不在生成方案的同一轮起草那些能力。

必须原样覆盖能力目录中的每个 `module_id` 各一次。目录外 id、本能力、机械工具节点和旧工序节点都不纳入。用户改变目标且旧方案不再成立时,按新的核心体验重写完整方案,不在旧 JSON 上追加补丁。

principles

1. 配方必须针对抽出的核心体验:说明靠什么方法兑现它,不复述通用创作常识,也不复述用户点到的词表。
2. 四档按对这份体验和可运行性的贡献分,不按原话有没有出现这个能力:
   - 必须:缺少后无法运行,或核心体验会崩。用户没点名、但体验直接压在上面的能力也放这里。
   - 有必要:缺少仍可运行,但体验明显变弱。主动把有帮助、用户没提到的能力放这里。
   - 有一定效果:对体验有增益,缺了核心仍在。可顺带询问一次。
   - 没有意义:对这份核心体验没有帮助。不是「用户没提到」。
3. `why` 写该能力怎样服务抽出的核心体验;`missing` 只写仍会影响实施的具体缺口,没有则写空字符串。前三档里还没选定的做法,用能直接拿去问的具体选择写入 `missing`。
4. `instances` 只列已经能判断的具体实例需求;生成规则、具体实例等可反复能力可以列多项,其余通常为空数组。
5. 旧配方只能作为方法案例引用、混合或改写;公共规则不从案例复制进本局配方。案例里的档位倾向只供对照,与本局体验冲突时以本局体验为准。
6. 材料少时仍形成方案:从已有材料推断核心体验,不编造世界设定。推断出的有帮助能力照样上档,还没定的具体内容写进对应 `missing`。这些缺口在后续对话里按用户原话和已抽出的体验给 2~3 个选项询问,选定后再写对应能力。

output

{
  "schema": "creation-plan.v1",
  "技能": "本局创作方案",
  "brief": "一句话写出抽出的核心体验,以及靠什么兑现它",
  "recipe": {
    "primary": "主要创作方法",
    "secondary_traits": ["可混合的次要体验特征"],
    "method": ["针对本局的做法,不是固定节点顺序"],
    "references": ["采用或改造过的旧配方案例 id"]
  },
  "items": [
    {
      "module_id": "variable-design",
      "tier": "必须",
      "why": "任务时限与暴露度必须跨轮保存",
      "missing": "暴露度达到哪一档会被识破尚未确定",
      "instances": []
    }
  ]
}

硬规则:

  1. 输出合法 JSON,schema 固定为 creation-plan.v1,技能 固定为 本局创作方案。
  2. recipe.method 描述本局做法,不写节点序列、阶段编号或统一流水线。
  3. items 必须覆盖程序给出的全部能力各一次;tier 只能是四档之一。
  4. why、missing、instances 每项都必须存在;没有缺口时 missing 写空字符串。
  5. 产物中不写自评分、追问、回复话术或游玩正文。

score

能力覆盖:
- 5:全部应覆盖能力恰好一次,排除项正确,档位合法。
- 3:主体齐全,但有边界能力误分、重复或理由过于笼统。
- 1:明显漏项,或纳入机械工具与旧工序节点。

配方针对性:
- 5:`brief` 里的核心体验能解释主要方法;用户没点名但承载体验的能力已在「必须」或「有必要」,换一个作品就不成立。
- 3:体验可辨,但分档仍主要跟着原话点到的词走。
- 1:只有用户原话的复述或泛泛原则,没有主动找出有帮助的能力。

依赖克制:
- 5:只表达真实语义依赖,不暗示固定执行顺序。
- 3:大体灵活,但夹有弱顺序或阶段暗示。
- 1:恢复成统一流水线或 DAG。

缺口可行动性:
- 5:前三档缺口具体,涉及选择时能给出明确实例方向。
- 3:部分缺口笼统,仍需再次解释才能行动。
- 1:缺口缺失、虚构,或变成无差别问卷。

checklist

- [ ] brief 先写出抽出的核心体验,而不是复述用户点到的题材词?
- [ ] recipe 是兑现这份体验的本局方法,而不是固定节点流程?
- [ ] 用户没点名、但缺了体验会明显变差的能力,已在「必须」或「有必要」,并写了具体 missing?
- [ ] 「没有意义」表示对这份体验没有帮助,而不是「用户没提到」?
- [ ] 能力目录中的每个 module_id 恰好出现一次,且没有目录外 id?
- [ ] missing 具体且不重复 why,没有缺口时为空字符串?
- [ ] 产物不含评分、追问、回复话术或游玩正文?