企业官网建设流程全解析

1. 先把“聊天”变成“指挥”：进阶操作的底层心法

我大概是从两年前开始把 ChatGPT 当成日常生产工具来用的。最开始那半年，使用方式跟大多数人一样：打开对话框，敲一句“帮我写个文案”“解释一下这个概念”，然后对着屏幕上那种四平八稳、挑不出错但也没什么用的回答发呆。真正让我效率翻倍的转折点，不是换了什么新模型，而是我意识到一件事——ChatGPT 的进阶操作，本质上不是“问得更好”，而是“把对方当成一个聪明但没有背景信息、没有上下文、也不会主动追问的实习生来指挥”。

这个认知转变很关键。你带过一个刚入职的实习生就明白了：你不能说“帮我搞个方案”，你得说清楚这份方案给谁看、要多长、什么风格、哪几块必须有、哪几块绝对不要写。ChatGPT 的进阶操作，整套方法论都建立在这个类比之上。它懂的东西比你想象的多，但它不知道你此刻在做什么项目、你的读者是谁、你上一版被老板骂在哪里。这些信息，你不给，它就自己编；你给得模糊，它就还你一个模糊的答案。

所以这篇东西写给谁？写给已经能正常对话、但输出质量始终卡在一个水平线上不去的朋友。不管你是写文案的、做运营的、写代码的、做研究的，还是纯粹想把日常杂活外包出去一部分的人，下面这些操作都能直接抄。我不讲“AI 有多厉害”这种废话，只讲我实打实跑过、验证过、踩过坑的那部分：提示词怎么搭结构、复杂任务怎么切、输出怎么稳定成你要的格式、出错的时候怎么排查。

我个人的判断标准很粗暴：如果一个操作不能让你少改两遍稿子，那它就不算进阶操作。按这个标准往下筛，能留下来的东西其实不多，但每一条都值钱。

1.1 为什么大多数人的输出质量卡在原地

先说一个我观察到的现象。身边用 ChatGPT 的人，输出质量差得特别悬殊，但他们的提问长度其实差不多。有人一句话能换回一份能直接发的稿子，有人写了两百字提示词，拿回来的东西还得重写。差别不在长度，在信息密度和约束质量。

我复盘过自己早期那些失败的提问，问题基本集中在三类。第一类是只给了目标，没给评价标准。“写一篇产品介绍”是目标，“写一篇 800 字、面向非技术采购、不要形容词堆砌、必须包含价格区间和交付周期”才是评价标准。模型不知道你要拿什么尺子量它，它只能按训练数据里最常见的那种平庸写法交付。第二类是上下文一次性倾倒。很多人喜欢把一堆材料全粘进去，然后说“参考这些写”。材料之间是什么关系、哪些是权威的、哪些只是参考，模型分不清，最后写出来的东西是几份材料的大杂烩。第三类是不做迭代，一次定生死。第一版不满意就换模型、换工具，从来不告诉它“上一版哪里不行”。这就像你跟设计师说“不好看，重做”，重做一百遍也还是不好看。

反过来说，那些用得特别顺的人，往往有一个共同点：他们输出的提示词，读起来像一份需求文档，而不是一句请求。有背景、有角色、有交付物定义、有边界条件、有示例。这不是什么玄学技巧，就是把人类之间协作时本来就该说清楚的事，说清楚了而已。

提示：判断你的提示词够不够格，有个土办法——把它发给一个完全不了解你项目的新同事，看他能不能照着做出你想要的东西。他做不出来，模型大概率也做不出来。

1.2 四个真正起作用的杠杆

我把所有能提升输出质量的手段，收敛成四个杠杆。这四个东西你调好了，80% 的场景就够用了，剩下的都是锦上添花。

第一个杠杆是角色与视角。不是让你写“你是一位资深专家”这种空话，而是明确它站在谁的立场上说话。是站在甲方采购的立场挑毛病，还是站在技术负责人的立场解释原理，还是站在新手用户的立场提问，输出的内容和语气完全不同。角色设定真正的价值是切换知识域和评价标准，不是给它发个工牌。

第二个杠杆是任务拆解。一个包含五个子目标的大任务，一次性丢进去，模型会平均分配注意力，每个子目标都做到六十分。拆成五轮，每轮只干一件事，每件事都能做到八十五分以上。这个原理在后面的章节我会用具体例子展开。

第三个杠杆是约束条件。字数、格式、禁用词、必须包含的要素、不要碰的雷区。约束越具体，输出越收敛。但这里有个反直觉的点：约束不是越多越好。堆二十条约束，模型会顾此失彼，反而漏掉关键的。我一般控制在五到八条，且按重要性排序，最要命的那条放在最前面。

第四个杠杆是示例。给一到两个“这就是我要的样子”的样例，效果远超任何形容词描述。你写十句“风格要简洁有力”，不如贴一段你认可的旧稿。模型对样例的模仿能力，比对形容词的理解能力强得多。

1.3 我现在常用的一套提示词骨架

跑了这么久的各种场景，我最后沉淀下来一个还算通用的骨架，分五段。它不是什么标准答案，但胜在每次都能让我少想一会儿。

第一段写背景：我在做什么、给谁看、现在卡在哪。第二段写角色：你以什么身份来回应我。第三段写任务：具体要产出什么，颗粒度到“一份 600 字的产品说明，包含三段正文和一句总结”。第四段写约束：格式、字数、禁止项、必须项。第五段写示例或参考：贴一段样例，或者明确指出“不要参考任何我给的材料，只按上面的要求写”。

这套骨架我用了大概几十次之后就形成肌肉记忆了，现在写一个复杂提示词大概两分钟。听起来比一句话提问慢，但省下来的是后面三四轮返工的时间，怎么算都划算。而且这套骨架有个好处：当输出不对时，你能快速定位是哪一段出了问题。是背景没交代清楚，还是约束写矛盾了，还是示例给错了方向，一眼就能看出来。一句话提问出了问题，你只能干瞪眼猜。

2. 提示词的进阶结构：从一句话到一份“施工图”

提示词这个东西，被讲得太玄了。什么“咒语”“魔法词”，搞得好像有什么隐藏开关。我的看法很朴素：提示词就是一份用自然语言写的需求文档，写得好不好，取决于你需求表达得清不清楚，跟玄学没关系。这一章我把结构拆开讲，每个部分给你能直接套的写法。

2.1 五段式结构的逐段拆法

背景段最容易被人跳过，但它恰恰是最值钱的一段。我通常这么写：“我在给一家做工业设备的中小企业写官网首页文案，读者是工厂的采购负责人，他们最关心的是交期和售后，不是技术参数。” 就这么两句，模型立刻知道该往哪个方向使劲。你不写这两句，它就默认往“科技创新、引领未来”那个方向跑，写出来的东西你看着就烦。

角色段我建议写得具体一点，但别写成小说。“你是一位有十年经验的工业品销售”比“你是顶级文案大师”有用得多，因为前者携带了一整套真实的知识结构和话术习惯。后者只是个空洞的头衔，模型对你的期待一无所知。这里有个小技巧：角色最好和读者形成对位关系。读者是采购，角色就可以是销售；读者是新手，角色就可以是带教老师。这种对位能让语气自动校准。

任务段的关键是交付物定义。不要写“写点介绍”，要写“产出一份 600 字左右的首页文案，结构为：一句主标题、一段痛点描述、三条卖点、一句行动号召”。你把交付物的形状描述得越清楚，拿回来的东西越接近成品。这一步其实是在替模型做产品设计，你设计得越细，它执行得越准。

约束段我一般控制在一屏以内。常用的几类：字数范围、格式要求（是否用列表、是否用表格、段落数量）、语言风格（口语/书面、禁用某些词）、事实边界（不确定的信息必须标注、不许编造数据）。这里必须提一句：“不许编造”这条约束，一定要显式写出来。不写的话，模型在信息不足时会倾向于用看起来合理的假信息填坑，尤其是在数字、日期、引用这类地方。

示例段是可选的，但只要你有样例，就一定要给。哪怕只是一段你觉得“就这个味儿”的旧文案，也比十行形容词管用。

【背景】我在给一家做工业设备的中小企业写官网首页文案，读者是工厂采购负责人， 他们最关心交期和售后，不关心技术参数。 【角色】你是一位有十年经验的工业品销售，说话务实、不吹牛。 【任务】产出 600 字左右的首页文案，结构为：一句主标题 + 一段痛点描述 + 三条卖点 + 一句行动号召。 【约束】 1. 全文不超过 650 字； 2. 不使用“引领”“赋能”“生态”这类词； 3. 涉及具体数字的地方，如果没有我提供的信息，一律写“以实际报价为准”，不许编造； 4. 卖点用短句，每条不超过 20 字。 【示例】参考语气：“设备坏了等三天，生产线停三天，这个账我们算过。”

2.2 角色设定的分寸感：别把人设写过头

我见过不少人把角色段写成人物小传：“你是一位毕业于名校、曾在多个行业深耕、性格温和又不失锐利的资深顾问……” 这种写法的问题在于，信息量太低而干扰太大。模型会花注意力去扮演这个“人”，而不是解决你的问题，输出里容易多出一堆无关的寒暄和铺垫。

我的经验是，角色段只需要交代三件事：专业领域、经验层级、说话风格。三样各一句，够了。“你是做跨境电商物流的运营，做过五年，说话直接、爱举例子。” 这个角色立刻就能干活了。至于它毕业于哪里、性格如何，对你的输出没有任何帮助，纯属浪费上下文。

还有一个更进阶的用法：让角色承担“挑错”的职责。写完初稿之后，我会开一个新对话，把角色换成“严格的审稿人”，立场设定成“你的任务是把这份稿子里所有含糊、夸大、经不起追问的地方挑出来，逐条列出，不要改稿，只挑错”。这个操作的效果比让同一个对话“自己检查一下”好得多，因为新对话没有“我刚写完这份稿子”的包袱，挑错更狠。

注意：同一个对话里让模型自评，它往往倾向于说“整体不错，可以再优化以下几点”，然后给你一堆不痛不痒的建议。换新对话、换角色、明确要求“只挑错不改稿”，才能逼出真问题。

2.3 用示例把风格“焊死”

风格这件事，形容词是没用的。“简洁”在模型眼里可能是短句，也可能是没有修饰语，也可能是信息密度高，三种理解出来的东西完全不一样。但你贴一段样例，它立刻就能抓住那种语感。

我一般这样操作：贴一段 100 到 200 字的旧稿，然后写一句“模仿这段的文字节奏和信息密度，不要模仿内容”。加这后半句很重要，不然它会把你样例里的观点也搬过去。如果你手头没有合适的样例，还有个替代方案：让它先写三版不同风格的短样例，你挑一版，然后让它按挑中的那版重写全文。这个来回多花一轮，但比你在长文里反复修改要省事得多。

还有一类场景特别适合用示例，就是结构化输出。比如你要一批固定格式的条目，与其用文字描述格式，不如直接给一条完整的样例：

请按下面的格式输出，每条一行，字段之间用竖线分隔： 产品名 | 核心卖点（15字内） | 适用场景（10字内） | 价格区间 示例： 便携式发电机 | 静音省油，启动快 | 户外施工、应急 | 3000-6000元

给了这条样例，输出的整齐程度会有肉眼可见的提升。不给的话，你可能拿到三种不同的格式混在一起，还得手动整理。

2.4 输出格式约束：让结果能直接进表格

如果你的产出最终要进表格、进文档、进代码，那格式约束就不能靠“请用表格输出”这种模糊说法。我的做法是把格式写成可校验的规则：字段有几个、顺序如何、分隔符是什么、空值怎么表示、超长怎么截断。

举个我常用的例子。做竞品信息整理时，我会要求输出成固定五列的表格，并且明确规定“如果某项信息在原文中找不到，填‘未提及’，不要推测”。这条规则救过我很多次，因为默认情况下模型会顺着上下文“合理推测”一个值填进去，而你根本分辨不出哪些是原文有的、哪些是它补的。

格式约束还有一个隐藏收益：它能反过来暴露你的需求是否清晰。当你试图把“我想要什么”写成规则时，很多原本模糊的想法会被逼着具体化。我有好几次是在写约束的过程中，才意识到自己其实没想清楚要什么。

3. 复杂任务的拆解与流程化：把大活切成小活

单个提示词能解决的问题是有上限的。一旦任务超过某个复杂度——比如写一份完整的行业分析、把一堆杂乱访谈整理成结构化纪要、从零设计一套方案——单轮对话就开始崩了：前面写的和后面写的自相矛盾，细节越写越虚，最后你还得从头捋一遍。这时候要上的不是更长的提示词，而是流程。

3.1 三层拆解法：目标、阶段、动作

我的拆解习惯是三层。最上面是目标层：最终要交付什么，一句话说清。中间是阶段层：这个交付物要经过哪几个阶段才能成型，一般三到五个。最下面是动作层：每个阶段具体让模型干什么，一次只干一件。

拿“写一份行业分析”举例。目标层是“一份 3000 字的行业分析，给内部决策用”。阶段层拆成：先定框架，再填事实，再做分析，最后收敛成文。动作层就是四次独立的对话：第一次只讨论框架该有哪几个部分、每个部分回答什么问题；第二次只整理事实材料，明确哪些有来源、哪些是空白；第三次只做分析，基于已有事实推导结论；第四次才是成文。

这个拆法最大的好处是每一步都能单独验收。框架不对，当场改框架，不用等三千字写完才发现方向错了。事实有空白，在第二阶段就能发现，可以去补材料，而不是让模型在成文阶段硬编。我踩过的最大的坑就是跳过阶段直接让它写全文，结果三千字里有一半是车轱辘话，剩下一半里有几处数据看着特别像真的，其实全是编的。

拆解的时候有个判断标准很好用：如果某一步的产出，你没法用一句话判断它对不对，那这一步就拆得不够细。“写一份分析”你没法判断对错，“列出这份分析应该包含的五个部分，每个部分用一句话说明它回答什么问题”你就能判断了。

3.2 迭代式追问：把返工变成定向修改

绝大多数人对迭代的理解是“不满意就让它重写”。这是最浪费的做法。有效的迭代是定向修改：指出具体位置、具体问题、具体期望。

我的追问话术基本固定成三段式：“第二段的问题是把结论说在了证据前面，读者会觉得你在硬下判断；改成先摆两条事实，再给结论；其余段落不要动。” 这句话里包含了定位、诊断、指令、边界四个信息，模型执行起来非常准。而“这段写得不太好，改改”这种说法，它只能猜，猜错的概率极高。

还有一种更狠的迭代方式，我管它叫对抗式迭代。定稿之前，我会专门开一轮，让它扮演最难缠的读者，针对我的稿子提十个问题，越刁钻越好。然后我挑出其中真正戳中要害的三四个，回到主对话里定向补强。这一轮下来，稿子的结实程度会明显不一样。它挑出来的问题里大概有一半是无效的，但剩下那一半往往就是你自己看不见的盲区。

心得：迭代时一定要明确“其余部分不要动”。不写这句，模型经常顺手把你满意的段落也重写一遍，越改越回去。

3.3 长材料的处理：分块、索引、再汇总

处理长文档是另一个高频痛点。直接把几万字粘进去，常见的结局是：开头的内容被反复引用，中间的内容被忽略，结尾的内容基本没消化。这跟上下文长度没关系，是注意力分配的问题。

我的处理方式分三步。第一步分块：按逻辑单元切，一章一块、一节一块，不要按字数硬切，切在句子中间会丢信息。第二步逐块提炼：每块单独一轮，只做一件事——提炼这一块的核心观点、关键数据、待确认的疑点，输出成固定格式的三行。第三步汇总：把所有提炼结果拼起来，再让它做整体归纳和交叉比对，找出块与块之间的矛盾点。

这个过程听起来笨，但准确性比一次性投喂高出一个量级。而且中间产物是可复用的，下次做同类分析，提炼好的结构直接拿来套就行。我现在的习惯是，任何超过五千字的材料，一律走这个流程，不图快。

3.4 上下文预算的粗略估算

有个实际问题很多人忽略：上下文是会“挤”的。对话越长，早期信息被稀释得越厉害。我不去算精确的 token 数，只用一个粗略的经验值：中文大概一个字一个单位，英文大概四个字符一个单位，你心里有个数就行。

在此基础上我给自己定了几条规矩。第一，一个对话只服务一个任务，任务完成就归档，别在同一个对话里连着干三四件不相干的事。第二，关键约束要重复，如果对话已经进行了十几轮，把最重要的那两三条约束再贴一遍，成本很低，收益很高。第三，长材料不要常驻，用完就删，需要时再贴，避免它一直占着位置稀释后面的指令。第四，快到上限时主动收口，让它先把已有结论整理成一段结构化摘要，然后拿这段摘要开新对话继续，比硬撑到截断要好。

这几条规矩看起来琐碎，但它们是稳定性的来源。很多“模型变笨了”的抱怨，其实是对话太长、上下文太脏导致的。

4. 把输出接进工作流：模板化、批量化与半自动化

单次用得好，只是省了一点时间。真正拉开差距的，是把它变成工作流的一部分——同样的活，别人做两小时，你做二十分钟，而且质量更稳定。这一章讲三件事：怎么攒模板、怎么批量跑、怎么验收。

4.1 建一个自己的提示词库

我从第三个月开始建提示词库，现在里面有四十多条，按场景分类：写作类、分析类、整理类、审校类、代码类。每条都带三个信息：用途一句话、完整提示词、适用边界（什么情况下别用）。

建库的关键不是数量，是沉淀失败经验。我每条模板下面都会记一行“踩过的坑”，比如“这条模板千万别加‘尽量详细’，一加就写到两千字，收不住”“这条在材料超过三块时会漏掉最后一块，要单独跑”。这些备注比模板本身更值钱，因为它们是别人抄不走的。

模板也不是一成不变的。我的习惯是每次用完，如果中途改过提示词，就把改动合并回模板。三个月下来，模板会自己“长”成贴合你工作习惯的样子。这件事的复利效应特别明显，前期投入几天，后面每次用都省时间。

4.2 批量处理与半自动化

重复性强的活，比如给一百条商品写短描述、把五十份访谈记录整理成统一格式、给一批文章生成摘要，就不该一条条手动跑了。这时候可以走接口批量处理，思路很简单：读输入、拼提示词、发请求、存结果、记录失败项。

下面这段是通用写法，函数名和地址按你实际用的平台替换就行，逻辑是通的：

import json, time, requests API_URL = "https://你的接口地址/v1/chat" HEADERS = {"Authorization": "Bearer 你的密钥", "Content-Type": "application/json"} def build_prompt(item): return f"""你是电商运营，请为下面的商品写一条 40 字以内的卖点描述。 要求：不夸大、不含绝对化用语、必须包含一个具体使用场景。 商品信息：{item['name']}，{item['spec']} 只输出描述本身，不要任何解释。""" def call(item, retry=3): payload = { "model": "你的模型名", "messages": [{"role": "user", "content": build_prompt(item)}], "temperature": 0.4 } for i in range(retry): try: r = requests.post(API_URL, headers=HEADERS, json=payload, timeout=60) r.raise_for_status() return r.json()["choices"][0]["message"]["content"].strip() except Exception as e: time.sleep(2 ** i) # 指数退避，别死循环重试 return None if __name__ == "__main__": items = json.load(open("items.json", encoding="utf-8")) ok, fail = [], [] for it in items: out = call(it) (ok if out else fail).append({**it, "desc": out}) time.sleep(1.2) # 控速，别把接口打爆 json.dump(ok, open("out_ok.json", "w", encoding="utf-8"), ensure_ascii=False, indent=2) json.dump(fail, open("out_fail.json", "w", encoding="utf-8"), ensure_ascii=False, indent=2) print(f"成功 {len(ok)}，失败 {len(fail)}")

这段代码里有几个地方是我踩坑之后加的。指数退避是必须的，早期我写死循环重试，一波失败请求直接把账号打到限流。控速的 sleep也是必须的，批量任务最忌讳猛冲，稳一点反而整体更快。失败项单独落盘更重要，一百条里挂三条，你只需要补跑那三条，不用整体重来。

还有一点：批量跑之前，先拿五条试跑，人工看一遍质量，确认没问题再放开跑全量。这个习惯帮我省过好几次大规模返工。

4.3 结果验收的四个维度

批量产出的东西，绝对不能直接就用。我固定从四个维度抽检：格式是否合规（字段数、分隔符、长度）、事实是否可靠（数字、日期、专有名词逐条核）、风格是否统一（一百条里有没有几条画风突变）、边界是否守住（有没有出现被明确禁止的表述）。

抽检比例我一般取 10%，但边界维度是 100% 全查。格式错了能批量修，风格飘了能重跑，事实错了和越界表述出了问题，麻烦就大了。这里我必须强调一句：涉及对外发布的内容，最终一定要有人过一遍，模型负责起草和提速，责任不能外包出去。

5. 常见问题与排查实录

下面这些坑，几乎每一个我都亲身趟过。有些是熬到半夜才想明白的，写在这里省得你再走一遍。排查的核心思路只有一个：先判断是“输入问题”还是“任务问题”。输入问题靠补信息解决，任务问题靠拆分解決，绝大多数情况下不需要换模型。

5.1 输出跑偏、变短、变啰嗦

输出跑偏最典型的表现是答非所问，你问 A，它给你讲 B。八成是因为背景段缺失或者约束之间打架。我遇到过最离谱的一次，要求“写得克制一点”，同时要求“要有感染力”，结果输出一会儿冷静一会儿激昂，非常割裂。约束之间必须自洽，写之前花十秒扫一遍。

输出变短通常发生在长对话的后期。前面几轮还挺丰满，后面越来越敷衍，一句话打发。原因基本是上下文稀释，早期约束被冲淡了。解决办法很简单：把核心要求再贴一遍，或者干脆开新对话，带上已有成果继续。

输出变啰嗦则是另一个极端。常见诱因是我自己手贱加了“尽量详细”“充分展开”这类词。这几个词在模型眼里约等于“无限展开”。真需要详细的时候，我会改成量化表述：“每个要点展开到三句话，总长控制在 800 字”。用数字代替形容词，这一条能解决掉一大半啰嗦问题。

还有个小技巧：如果你发现它总在开头加一段“好的，我来帮你……”的铺垫，就在约束里加一条“直接输出正文，不要任何开场白和结束语”。加上这条，输出立刻干净。

5.2 表格和代码块被打断

结构化输出被破坏是很常见的问题。表格输出到一半突然变成段落、代码块里混进解释文字、列表层级乱掉。原因通常是格式要求没写死在最后。

我的做法是把格式要求放在提示词的最末尾，并且单独成段，写清楚“只输出表格，不要表格之外的任何文字”。位置很关键，末尾的指令权重更高。另外，表格列数最好控制在五列以内，列太多容易被压扁变形。如果确实需要宽表，就拆成两张窄表，或者改成“一行一条、竖线分隔”的形式，稳定得多。

代码块被打断的情况，多半是因为它想给你加注释说明。加一句“代码块内不要写任何注释，说明文字放在代码块之外”，基本能解决。

5.3 事实性错误的识别与核查

这是最需要警惕的一类问题。模型的错误有个特点：错得特别像对的。语气笃定、格式规整、细节丰富，你要是不查，根本看不出来。我现在的做法是分三层核查。

第一层是高风险项全查：所有数字、日期、人名机构名、引用出处，一律对照原始材料核，一个都不放过。第二层是逻辑自洽性检查：让它把结论和支撑证据分列出来，你看着对不对得上，很多时候一列出来就露馅了。第三层是追问来源：“这条信息的依据是什么？如果材料里没有，直接说没有。” 加上这句，它会老实很多。

还有个习惯我保持了挺久：凡是我不熟悉的领域，输出的每一个事实性陈述都当成“待核实”处理，不管它说得多有把握。这个习惯有点费时间，但比事后返工便宜。

5.4 边界与信息安全的几条硬规矩

这部分我特别想多说两句，因为出问题的代价往往是不可逆的。

第一条，不要把不该外传的东西贴进去。客户名单、内部财务数据、未公开的方案、别人的个人信息，这些都不行。需要用它处理这类材料时，先做脱敏：把名字换成代号、把数字做比例缩放、把可识别特征抹掉，只保留结构。我现在的习惯是，任何涉及真实业务的材料，进对话之前先过一遍脱敏，形成条件反射。

第二条，对外发布的内容必须人工终审。模型不知道你的行业有哪些表述禁区，也不知道哪些话在特定语境下会引发误读。它能帮你提速，但把关这件事只能人来干。

第三条，涉及专业判断的内容，别把它当唯一依据。法律、医疗、财务这类领域，它的输出可以作为思路参考，但不能作为决策依据。这个界限要清楚。

第四条，用别人的材料要留意授权。让它改写、总结网上的内容，产出物的使用范围你自己心里要有数。

5.5 几个提升稳定性的小习惯

最后分享几个不太起眼但很管用的习惯。

固定开场白。我在做重复任务时，会在提示词最前面加一句固定的任务标识，比如“任务：商品卖点生成”。这看起来没什么用，但它能帮模型快速进入状态，也方便我自己在历史记录里检索。

保留中间产物。每一轮的输出都存下来，别只留最终版。返工时经常需要回溯到某一轮的某个片段，有存档能省很多事。

定期清空对话。一个对话干到十几轮就该考虑收尾了。我的做法是让它先把结论整理成一段结构化摘要，然后拿这段摘要去开新对话。这一步花两分钟，能避免后面一堆莫名其妙的问题。

给它明确的“停止条件”。很多任务之所以跑得没完没了，是因为没说什么时候该停。“如果信息不足以支撑结论，就停下来告诉我缺什么，不要继续往下编。” 这句话我几乎每条复杂提示词里都会加。

别迷信一次成型。我现在对任何复杂任务的预期都是三轮：第一轮出框架，第二轮填内容，第三轮挑错收敛。接受这个节奏之后，反而不焦虑了，因为每一轮都有明确的验收点，进度是可见的。这个心态上的转变，可能比任何一个具体技巧都重要。