创意工作流程
Claude Fable 5.2 创意反馈：把冲突意见整理成修改清单
一位评审希望画面更明亮，另一位却想保留深色氛围。把两条意见直接合成一个修改请求，可能让整张图都变了却谁也不满意。应先弄清要解决什么问题、由谁决定。
本文依据 2026 年 11 月 12 日核对的文档和示意练习编写，不报告 Fable 的现场测试结果。请在支持 Fable 的 Claude 界面使用该模型，再将确认后的资料手动交给 Ciyo。
先看做法
按受影响的元素对评论进行分组，区分请求的更改和未解决的冲突，并要求审批者解决冲突。将一项已接受的更改发送到 Ciyo，并附上必须保持不变的明确列表。
1. 收集带背景的反馈
以虚构花店活动为例，为已确认图片和每条反馈编号，保留评审角色、涉及元素与日期。“白色标题压在花束上看不清”这样的理由也要留下，不能只摘出“改亮”。
分清事实与偏好。店名拼错需要纠正，背景暖一点属于偏好。涉及活动条件的反馈仍需由对应负责人确认，即使设计师改几个字很快。
2. 编辑前先建决定记录
让 Fable 合并重复意见，保留矛盾意见，列出建议操作、依据、决定人和状态。新提出的偏好，不会自动推翻另一位有权限者先前确认的版本。
遇到明暗冲突，先问双方要解决什么问题。如果只是标题难读，局部文字处理也许足够，不必改变整个摄影氛围。这只是待确认的方案，不是模型有权自行裁定。
3. 只做已同意的修改，再前后对照
在 Ciyo 中明确指出已接受的原图和本次唯一修改，列明产品、摆放、文案与裁切哪些必须保持。把结果和原图放在一起看，不靠记忆判断。
记录新版本及其解决的反馈编号。如果花束被改了，或出现新文字，就拒绝这次结果或回到已接受版本。未解决的意见继续保留，不能让整洁清单造成已经全部签字确认的假象。
复制并调整此请求
将方括号中的字段换成自己的已确认资料。请求的结果是待核对草稿；这些示例并未作为模型性能测试运行。
合并关于[资产版本]的[IDS评论]。对重复项进行分组，保留矛盾，并将事实更正与偏好区分开来。返回受影响的元素、建议的操作、源评论 ID、审批者和状态。不要自己解决权力冲突。起草一份范围修订请求，仅包含已已确认的更改和明确的未更改列表。示意性反馈日志
这些示例检查描述了验收标准，而不是观察到的模型结果。
| 评论 | 状态 | 下一步行动 |
|---|---|---|
| 企业名称拼写错误 | 确认更正 | 替换确切的文本 |
| 背景更亮 | 偏好冲突 | 询问活动批准者 |
| 保持阴暗的心情 | 偏好冲突 | 与可读性需求一起审查 |
| 已确认的报价不变 | 锁定 | 在每次修订中保留 |
常见错误与处理方法
不要将友好的致谢视为认可。记录实际决定及其适用的版本。
当已确认的任务是一项修正时，避免提出改善图像的一般要求。它使得意外的变化更难以识别。
选择工作方式并进行交接
对于单独的商店，从一件物品开始，并将来源事实保留在草稿旁边。团队应该指定一名审批者并保留一个过时的版本，以便旧的评论不能默默地覆盖当前的决定。如果输入不完整，请在完善艺术品之前返回给该事实的所有者。
使用 Ciyo 进行此处描述的视觉工作以及您帐户中当前提供的控件和模型。单独保留 已确认的文案，并在需要时使用 可编辑的画布文字 添加准确的措辞。生成的图片是视觉草稿；在使用之前检查其导出的文件。
资料来源与延伸阅读
以下为本文参考的官方文档与相关指南。不同账号的功能和控件可能不同，开始前请核对自己所用的界面。
常见问题
Fable能决定哪位审稿人获胜吗？
它可以组织冲突并提出选择。您的团队必须定义谁有权批准相关变更。
我应该立即应用每条评论吗？
只有当已确认的变更是兼容的并且易于一起验证时。拆分独立的更改可以使故障更容易隔离。
如果图像编辑更改了其他细节怎么办？
将其与接受的源进行比较，拒绝不需要的更改并缩小请求范围或在适当的情况下使用精确的画布控件。
在 Ciyo 中准备一版视觉草稿
带入已确认的资料，按本文清单核对一版，再决定是否制作更多版本。