当我的工作台同时贴上三张便签——“为什么必须写这个”“按什么规则写”“生成完谁来审”——我突然意识到过去半年反复打磨的AI辅助创作流程本质上是一套由“诘问、协议、生成”拼起来的流水线。我把它整理成《元创力》纪实录的第六卷主题叫“根基”因为它解决的不是“这一篇怎么写”而是“任何一篇应该怎么被生产出来”。如果你也在用生成式工具产出内容或者正在搭建属于自己的创作SOP你会发现大部分教程都在教“提示词怎么措辞”却很少有人讲清楚你在打开生成工具之前应该先向自己提哪些问题你在按下生成按钮之前应该把哪些规则固定下来。这篇博文分享的正是这三个环节之间的空隙——那些最容易被忽略、却又最决定作品质量的细节。我会把整套流程尽量写得可以直接抄作业也会把踩过的坑一并说透。1. 先看整体为什么“诘问、协议与生成”能凑成一条创作链路很多人第一眼看到“诘问、协议、生成”会觉得它们只是流程的三段先问问题再定规则最后输出。我自己在最开始也是这样理解的直到连续做废了三四个项目才发现把三者当成线性步骤看待恰恰是最容易翻车的地方。举个我实际踩过的例子。某次我想做一组介绍本地美食的系列文第一步“诘问”做得非常细问了自己“目标读者是谁”“他们需要什么”“我的信息优势在哪里”第二步“协议”也写得像模像样把风格、字数、结构全部定死了可“生成”环节效果依旧很糟内容虽然工整却像一杯放了三天糖的白开水。后来我重新复盘才意识到问题不是某一步做错了而是三个环节根本没有互相咬合。1.1 三要素不是三个步骤而是三种能力真正的“元创力”指的是创造者对创造过程本身的反省与控制能力。诘问决定方向协议决定边界生成决定呈现。方向一偏边界再清晰也是白搭边界一松方向再清楚也保不住质量。这三者应该组成一个闭环而不是一条直线。生成的结果反过来会被新的诘问审视新的诘问又会推动协议迭代。我在卷六里把这个闭环压缩成一句话生成永远服从协议协议永远接受诘问。顺着这个逻辑你会发现三个要素对应的能力各不相同。诘问考验的是信息识别力你能不能从一团混乱的冲动里拎出真正有用的需求协议考验的是抽象表达能力你能不能把模糊的“我想要好看”翻译成机器能执行的判定规则生成考验的则是判断力你面对模型输出的概率候选能不能快速决定留下什么、改掉什么、弃掉什么。大多数人只盯着第三种能力练忽略了前两种才是根。1.2 这套框架适合谁解决什么问题先说清楚边界免得你照着做的时候产生错误预期。这套框架最适合三类场景一是长期输出内容的人无论是公众号、博客还是社群分享都需要稳定且可复用的生产节奏二是正在尝试用生成式工具辅助写作的新手他们缺的往往不是工具而是“怎么定义任务”的方法三是需要带团队做内容项目的人协议本身可以当作团队内部的交接文档让协作分工更明确。不适合的场景也有。如果只是随手写一条朋友圈或者需要十分钟内快速得到一个灵感碎片那大可以跳过诘问和协议直接去和模型聊天。框架是用来解决“反复性、规模性、一致性要求高”的创作任务的不是给每一条消息都上纲上线的枷锁。我自己现在的习惯是把诘问模板和协议模板做成工作目录里的两个固定文件遇到重任务就打开遇到轻任务就忽略。维护成本很低但收益非常稳定尤其是当你要在一个月内连续产出十几篇同主题内容时这套框架几乎能帮你省掉一半的返工时间。2. 诘问动手生成之前先给需求做一次全面体检大多数失败案例的共同特征是什么我总结了四个字需求模糊。需求模糊并不等于“不知道自己要什么”而是“以为自己知道实际却无法用一句话说清”。有一个被我反复使用的小测试开始创作之前要求自己把这次任务的目标压缩成不超过二十个字的一句话。举个例子“写给刚入门咖啡的人让他们了解手冲咖啡的器具清单和流程”这是合格表述“写一篇关于咖啡的文章”这是不及格表述。别小看这个压缩过程它能逼出你脑子里真正沉淀过的信息。2.1 为什么必须先问“为什么”再问“写什么”把“为什么”放在“写什么”前面是因为动机决定了内容的骨架。同一个主题写给刚入门的小白和写给从业五年的老手选取的信息、案例密度、术语比例完全不同。如果你不先确认受众生成器只会按一个模糊的“大众口味”去平均化表达结果就是谁都看不懂或者谁都觉得废话太多。我在诘问阶段通常会逼自己完成三件事。第一确认目标读者是谁以及他们最在意的三个问题是什么注意是“他们最在意的”不是“我觉得他们应该知道的”第二确认这次内容的唯一核心结论是什么如果连自己都说不清这篇内容到底想让读者带走什么协议阶段就必然摇摆第三确认自己有哪些素材、哪些经验是别人不容易复制的这决定生成出来的内容有没有差异化价值。这三个问题做完生成任务的提示词才算有了根。否则你给模型再详细的结构要求它产出的也只是“正确的平庸”。2.2 我常用的“需求诘问单”我把实际工作中反复用到的提问整理成了一张“需求诘问单”每次开始新项目前都填一遍大概用时十五分钟。这份表单不算精巧但胜在全面对象这篇内容给谁看他们现在的认知水平是初级、中级还是专家级目标读者看完之后你最希望他们记住的一件事是什么差异同类型内容已经很多我的切入点或信息优势到底在哪里约束有没有必须避开的表述、必须包含的案例、必须符合的调性验证什么情况下我会判定这篇内容失败了有没有可衡量的标准这五条里面最容易偷懒的是最后一条。人在创作时天然倾向于“把内容写完就算完成”却很少设置检验标准。我现在会把验证放在作品完成之后二十四小时用“重读一遍会不会想动笔大改”作为第一道事实检验再用“有没有人愿意转发或追问”作为第二道效果检验。这套双重标准不能说绝对可靠但确实帮我筛掉了很多自嗨式的内容。2.3 诘问不能闭门造车也要借助外部反馈诘问阶段还有一个很多人都忽略的动作去外面问一圈。你当然可以自己坐在电脑前把问题单填完但如果条件允许我更建议你在启动一个较大的内容项目之前至少找两个代表性用户聊一聊。这个动作的成本很低收益却往往出人意料。我试过一次最典型的例子计划写一个关于“整理房间方法论”的系列自己填诘问单的时候我一直以为目标读者想要的是“更高效的收纳技巧”后来问了几个朋友才发现他们真正的困惑是“整理了三天之后很快又乱了”核心需求根本不是技巧而是如何维持秩序感。这个反馈直接改变了整个系列的方向。你看如果完全依赖自己脑补答案往往是错的借助外部反馈才能让诘问落到真实的地面上。3. 协议把想法转译成可执行的创作规则如果说诘问是在寻找“做什么”协议就是在回答“怎么做”。生成式工具的中文使用者大多有这样一个经验转变早期我们把提示词当咒语到处搜集模板期待某个神奇句子能点石成金中期我们开始意识到提示词不过是上下文协商本质上是用系统性的规则告诉模型你要什么后期才会理解真正能让作品长期保持稳定质量的不是某一条提示词而是一套成文成体系的协议。3.1 从提示词到协议一次认知升级协议与提示词的区别说白了就是提示词是一次性的协议是可复用的。提示词回答“这一篇怎么写”协议回答“这一类怎么写”。举个例子我写人物对话时会定义说话风格、句长偏好、称呼习惯这些规则不会只服务某一个具体场景而是沉淀成一份“对话生成协议”后续凡是遇到类似的人物对白任务都可以直接加载。这样做的好处是减少了每一次从零开始的认知负担代价则是用协议之前需要花一点时间搭建框架。我见过一些朋友第一次听到这个思路就兴奋地把所有流程都协议化结果没几天就放弃了因为维护协议本身变成了负担。所以我建议从最小协议开始只覆盖三件事角色设定、输出结构、禁止事项。先跑通一套再逐步扩充。协议不是越全越好而是越准越好。3.2 写协议的三个基本原则我改了五版协议模板之后才摸索出几条相对稳定的原则。第一规则要能被机器判断不能被个人审美左右。“语言优美”就不是好规则它太主观改成“每段不超过四行禁止连续三个形容词堆叠”就非常可操作。机器看到前者不知道怎么执行看到后者则能稳定落笔。第二固定部分和变量部分分开。协议里大多是固定不变的骨架但也必须有可替换的插槽比如主题、关键词、案例引用。我一直用占位符标出变量例如【主题目标】【目标读者】【禁忌清单】每次启用协议只需要填这几个插槽其余部分不用动。第三协议要有版本号。我自己文件里的协议文件名都是这种格式人物设定_协议_v3.2.md。每次修改都保留旧版本并写清改动原因。你可能觉得小题大做但当你手上有七八份协议、每份迭代三轮以上时版本管理真的能救命。它能帮你找回一个月前那一版更好用的旧规则也能让你复盘到底是哪次改动让效果变好或变坏。3.3 一份可以直接改用的精简协议模板我在这里放一个实际能用的精简协议模板你可以直接复制改成自己的不需要讲究什么辞藻重点是结构目标输出800字左右的产品介绍短文读完让读者准确知道“这个东西是什么、解决了什么问题、和竞品有什么不同”。 对象对产品零基础、但正被某个痛点困扰的普通用户。 结构开头用一个具体场景切入第二段说明痛点第三段介绍产品第四段给两到三个核心卖点第五段写一句行动号召。 风格短句为主每段不超过五句话禁止使用“颠覆”“赋能”“生态”这类空词可以用具体数字禁止夸张表达。 变量插槽【产品名称】【核心卖点3项】【场景示例1个】 验证随机找一个目标读者请他用不超过三句话复述文章复述不清则重新写。这个模板看起来很朴素但效果比很多花哨的大段提示词好得多。因为它把模糊的“写得好”翻译成了明确的结构节拍和禁忌清单生成器能稳稳地落在目标区间里而不是靠运气瞎碰。4. 生成按下按钮之后才是考验的开始协议书再完美最终都要落到生成这一步。很多人的体验落差都集中在启动阶段觉得协议写得辛苦生成出来却一般般。这是正常的因为生成环节本来就带有一定的不可控性关键不在于消除它而在于管理它。4.1 生成模型是一次概率掷骰不是复印机不管我们如何精雕细琢协议生成模型的天然机制都带有概率性。同一个协议同一份上下文你提交两次得到的不可能完全一样。这个特性让很多初学的人不适应觉得模型“不听话”可是反过来想它也是创作素材多样性的来源。我在卷六里把生成阶段比喻成一位风格固定但运气不稳定的合作画师。协议决定了这位画师的画风和尺幅但他落笔时总有自己的随机发挥。成熟的创作者看到随机发挥不是立刻返工而是先判断这个随机是否带来了协议之外的新价值。如果带来了就顺势采纳甚至考虑把这段反馈进协议如果偏离了就直接把结果打回重来。所以真正重要的不是一次生成得好不好而是你有没有建立一套“生成—检验—反馈”的小循环。协议里的验证标准在前面已经预设好了到这里正好派上用场帮我快速判断这版结果是采纳、修改还是推倒。4.2 参数与模型选择少调微参数多选对基座很多人在生成环节迷恋参数微调温度调低、采样率调高、重复惩罚改来改去。我的实测经验是在现阶段不同模型能力之间的差异远超单个参数差异你应该优先选择更合适的基座模型而不是纠结于小数点后的参数。以我常用的语言模型为例写严肃教程类内容时我会选推理能力更强、回答结构更稳的模型写创意文案时反而愿意选发散性更强、措辞更生动的模型。参数方面我通常只改两个一是“输出长度上限”设为目标字数的1.2倍左右给模型留出组织语言的空间二是“随机性”根据任务类型设置在中低水平过高的随机性容易让专业内容出现事实性漂移太低则会让语言变得机械。需要特别提醒的是不同工具的参数名称并不通用有的叫“temperature”有的叫“创意度”有的干脆隐藏不显示。不要照搬别人的参数设置而是要拿自己的协议跑几组对照找一组在“稳定”和“自然”之间最平衡的值。4.3 长文生成的“检查点”与局部重生成长文生成时最怕什么不是开头写得差而是写到中段开始跑题。跑题的原因多半是模型在长上下文中丢失了原始协议里的关键约束。我的处理办法是在生成过程中设置“检查点”把长文切成若干小节每生成完一个小节就快速核对协议中的三到五个关键条款比如结构是否还对、风格是否还稳、有没有出现禁忌词。如果发现某段跑偏我不会整段删除而是保留已经正确的前文单独重生成偏离的部分。用“局部重生成”比“全文重生成”效率高得多也更能保住已经运行正确的部分。还有一个更进阶的操作长文生成前先让模型生成一份“内容大纲关键论点”拿到结构骨架之后再逐节填充。这等于把生成任务拆成了两层模型压力小了输出的整体一致性会明显提升。5. 完整实操复盘一次“诘问-协议-生成”全流程记录理论说再多不如看一次真实操作。我挑一个比较有代表性的案例来讲帮朋友写一篇“新手怎么选手冲壶”的内容用于社群分享。这个任务表面看起来很简单但走完整套流程之后我对“诘问、协议、生成”为什么必须咬合有了更直观的体会。5.1 一个真实需求进入诘问环节接到需求的第一反应很多人会直接去查资料、列参数、写提示词但我在动手之前用诘问单走了一遍立刻发现了一些关键事实。对象不是泛泛的“咖啡爱好者”而是“刚刚接触手冲、预算在100到300元之间、不希望一开始就烧钱的上班族”目标不是“把全类型手冲壶讲全”而是“帮他选出一把不容易买错、不容易被劝退的第一只手冲壶”差异是市面上测评文大多在列参数缺少“新手最容易踩的坑”的视角。这三个信息直接决定了我后续协议的内容怎么写。我还额外问了自己一句“如果全文只允许给出一个核心结论我选什么”思考之后得出的答案是买一把细嘴、可控温、壶盖可拆卸的入门壶优先考虑耐用与打磨宽容度而不是追求极致的萃取均匀度。这个结论成了全文的靶心后续所有段落都围绕它展开不敢往旁枝上乱跑。5.2 协议怎么根据诘问结果落笔基于上面的诘问结果我写出了一份非常具体的生成协议最终版本接近三百字。这里只列出最关键的几段结构全文六段依次为“新手碰到的三个典型问题”“为什么第一个问题常出在壶嘴”“细嘴与宽嘴的实际差异”“温控功能是否必要”“入门价位里的可选项”“一条给新手的行动建议”。 风格全文使用“你”字视角不出现夸张形容词每段不超过六句话用“实测”“我见过”等经验型表达替换绝对化判断。 禁忌不提具体商业品牌不用“智商税”“神器”等词不出现复杂的物理参数解释不写拉花与研磨相关内容。 验证生成完成后请一位完全没接触过手冲的朋友读一遍看他能否顺利复述出“该买哪种水壶”。协议写完我才开始和生成工具对话。这一套流程走下来生成结果的第一版就已经有七成可用后面主要是通过局部调整来打磨而不是推倒重来。整个过程真正验证了那句话花更多时间在协议上就能花更少时间在返工上。5.3 三段生成的迭代过程第一版生成结果结构基本符合协议但第三段“宽嘴与细嘴差异”写得过于学术出现了类似“萃取流速曲线”这种会让新手感到压力的词。我对照协议里的禁忌把这一段单独重生成要求换成一个更生活化的解释方式最终改成了用“倒水时水流像被削尖的铅笔和像圆珠笔”做类比效果立刻好了很多。第二版的问题出在开头虽然引出了痛点但缺少具体场景。我又单独生成了三个开头候选挑中一个“周六早上收到手冲壶快递拆开一试水倒歪了”的情境开头。这两处局部修改之后内容整体已经变得很稳没有再出现大的漂移。第三版重点放在标题与结尾行动号召。这是生成工具最容易发挥的地方我让它基于全文列出十个候选标题再人工挑选合并。最后定下的标题是“新手第一次买手冲壶别急着追求高端先看清壶嘴和温控”。整个过程耗时大约两小时协议占了一小时生成和修改只占一小时。这个比例让我意识到健康的创作流程本来就应该是“大头在准备小头在生成”。5.4 这次案例给我留下的三个教训第一个教训是诘问阶段如果只做了一半协议阶段一定会返工。我一开始写协议时曾想当然地把“写给新手”直接写成“语言简单”结果生成的内容过于口语缺乏信息密度。后来回到诘问单把对象细化成“理解力正常但时间紧张的上班族”语言风格才最终落定。第二个教训是协议不要太长。超过四百字的协议模型执行起来会出现前后不一致前两段严格遵守后两段开始松懈。解决办法不是把协议写更长而是精简条款把最关键的约束提到最前面。第三个教训是局部重生成时要把上下文喂足。我在修改第二段时曾经只在对话里发一句“重写这一段”结果模型因为丢失了前文语境生成风格直接跑偏。后来改用“完整协议前文段落待改段落”的结构模型才能保持一致性。这个过程没什么技术含量纯粹是经验换来的。6. 高频问题与排查实录任何框架落到实际操作中都会遇到问题我把几个典型的坑整理成一张速查表和三条排查经验你可以先收藏遇到情况再回来对照。6.1 一张问题速查表下面这张表覆盖的是我在实际项目中反复遇到的典型问题。表格里的“处置动作”非常直接基本拿来就能用现象可能原因处置动作前后风格不一致协议过长后段约束被模型忽略精简协议把核心禁忌放在最前面内容正确但平淡目标读者与风格定义太泛回到诘问单细化对象画像跑题或钻牛角尖上下文过长模型丢失关键信息增加检查点按小节生成频繁出现禁忌词协议只给了否定表达缺少正面示例同时给正面示例和负面示例结构全是一二三四的并列感只写了结构编号没写各段比例在协议里写明每段大概的信息占比二次生成反而更差所有段落同时重生成导致整体漂移改局部重生成保留已经正确的部分这张表并不神奇它只是把反复踩坑的结果沉淀下来让下一次不用重新趟一遍路。6.2 三个容易被忽视的排查角度除了上面那张表还有三个更偏经验的排查角度一般说明书里不会写。第一检查你的验证标准是否真的可执行。如果判断“好或不好”完全靠感觉就很难说清楚问题到底出在协议还是生成。我的建议是设定一个旁观者视角请身边的人读完转述一次转述不清就说明信息没有在内容里被有效传递。第二检查你是否把“模型风格”误当成了“个人风格”。生成模型天然带有平庸化倾向会把所有内容拉向平均值。如果你觉得成品太像“AI写的”那不是模型不听话而是协议里缺了你的个人表达痕迹比如特定的口癖、反复使用的例子、偏好的叙事顺序。把这些东西明确写进协议机器反而能帮你放大风格。第三检查你的工作节奏是不是太快了。我见过很多人在生成之后五分钟内就宣布失败但其实只给了一两版的随机结果。模型生成有概率性同一份协议多跑两三版再下结论才算公平。这个角度听起来简单做起来却很难因为它挑战的是大多数人“做一次就要成功”的思维定势。6.3 协议也要持续迭代维护最后提一个很多人会忽略的点别让你的协议写完就躺在文件夹里吃灰。协议应该随创作复盘持续迭代我自己的习惯是每次生成任务结束后花五分钟在协议文件末尾追加一条“本轮改动记录”写下为什么改、改了哪里、下轮要注意什么。比如我现在的“人物对话协议”已经迭代到第五版中间经历过“风格过于拖沓”“省略号使用太频繁”“吐槽过头显得刻薄”三处重要修正。每次改动都基于真实作品的反馈而不是凭空想象。这样维护一个月之后协议本身的稳定性和你运用协议的技术熟练度会同时上升。这种体验有点微妙创造过程本身也在被创造也许这正是所谓“元创力”这个名字真正想表达的东西我们不光创造作品也在创造能够创造作品的系统。