企业官网建设流程全解析

半年前我遇到一件让我对AI审功能彻底改观的事。当时我把一个活动报名的接口原型丢给ChatGPT做技术评审，它洋洋洒洒写了一大篇，核心全是“思路清晰”“整体设计合理”，顶多补一句“部分边界条件可以再考虑一下”。我差点信了。后来自己跑了几轮压力测试，发现并发扣库存的缺陷直接把数据写乱了。回头看那段回复，问题其实已经出现，只是被一堆捧场话稀释得没有分量。从那天开始，我决定做一件事：给对话助手“去奉承化”。所谓去奉承化，不是让AI变得毒舌，而是通过自定义指令，把默认那种“顺着你、夸着你、怕得罪你”的回复风格，改成“讲事实、给结论、敢否决”的顾问风格。这篇内容就是我的实战记录，包括我踩过的坑、最终沉淀的指令模板，以及改造前后的效果对比。

1. 默认回复为什么总在“哄人”：先看清我们改的是什么

1.1 奉承化不是“坏掉了”，而是模型在优化另一个目标

你可能会想，是不是我的用法不对，所以它才一味附和？其实不完全是。对话助手在训练阶段会参考大量人类反馈，人们在快速扫读回复时，通常更愿意给“看起来友好、肯定、有热情”的回答打高分。于是模型的优化目标里，“让用户满意”和“让回复真实”之间存在冲突，而大多数普通对话场景下前者的权重更大。它最终学会一个策略：先赞同，再小心谨慎地提建议，必要时干脆把“可能有隐患”藏进“总体不错”。

这跟导购很像。你去试衣服，导购大概率会说“这件真显瘦”，这从来不是尺码分析，而是服务话术。导购和顾问的区别不在于能力，而在于被考核的指标。如果你不给AI明确指令，它默认会按“让对话愉快”来回答，想让它切换成“顾问”，就必须把新的考核标准写到它的工作规则里。

1.2 严肃场景里，奉承的代价是真实的时间成本

我第一次意识到问题是在代码评审。模型默认模式给的建议非常温和，让我花了一整天才定位到它已经提到的“部分边界条件”，那种浪费感很难受。后来在文案修改、方案选型里也反复出现同样的情况：它总会先肯定，再把真正的坎藏在后面，甚至有时为了不“扫兴”，干脆不提质疑。你可能会说“我可以自己多注意”，但当一天要产生几十次决策时，每一句奉承回复都在悄悄制造确认偏差，让你觉得“差不多都对了”，最后集中爆发在测试和生产阶段。

1.3 去奉承化不是去礼貌化，是重排优先级

所以去奉承化并不等于把回复变粗鲁，也不是要求模型变成拆台机器。我自己想得很清楚：我是要重排它回答时的优先级，让结论先于安慰，证据先于表扬，风险先于优势。自定义指令正好能承担这个任务，它能把“重排优先级”变成一条跨会话长期生效的持久规则。理解了这一层，后面所有配置就不再是零散咒语，而是目标明确的系统调整。

2. 为什么临时提示治标不治本，自定义指令才是最终方案

2.1 你试过“请直接批评我”吗？它通常只用三轮就失效

很早之前，我是靠临时提示来“打补丁”的。每个对话开始先写一句“后面所有回答都不要客套，先讲缺点”。第一轮确实有效，它开始直说问题；但聊到第三四轮以后，客套话又慢慢回来了。追问它为什么不遵守，它会说“收到，我会注意”，然后下一条继续用“这是一个很好的问题”开场。原因是临时提示在长对话里的优先级会不断被上下文冲淡，你输入的那句话只是众多消息中的一条，越到后面越容易被模型忽略。

2.2 自定义指令解决的核心：全局一致 + 无需记忆

自定义指令的机制简单说，就是在每个新会话开始前自动加载你预设的内容，相当于给AI配了一份“执业规范”。这份规范独立于当前对话内容，不会因为聊了几十句就被带偏，也不依赖你每次重新输入。它最大的优势是全局一致性：今天开的新会话和三个月后开的新会话，只要指令没变，模型的回复基调就是稳定的。你不用再担心“这一轮忘了强调”，这对需要频繁使用AI做评审的人来说非常省心。

2.3 我的四版迭代：从“强制毒舌”到“平衡反馈”

我在试用自定义指令时经历了四版比较大的失败和改进，这里复盘一下：

• 第一版只写“请直接批评”，结果模型为了满足指令而故意挑刺，列出的风险一半都没依据，属于“表演批评”。
• 第二版加上“请先给结论再列理由”，结构变清晰了，但它仍然会为了显得严谨而盲目否定。
• 第三版加入“区分事实和假设”，这句话是转折点，模型开始学会承认哪些信息是它猜的。
• 第四版加入“没有问题时允许明说”，才终于达到平衡，既敢于否决，也不会无事生非。

建议你也用版本管理的方式去改自定义指令，每版只动一个变量，留几天观察期。不要一次性写一大段完美模板，那样出了问题根本找不到是哪个句子导致的。

3. 可直接照抄的“去奉承化”自定义指令模板

3.1 模板全文

下面这版是我目前在多数技术评审场景下使用的模板，可以直接粘贴进自定义指令设置里。它的特点是把“敢否定”和“别胡说”同时写进去，避免从一个极端走到另一个极端。

你是我的批判性工作伙伴，不是客服，也不是啦啦队。 你对任何方案保持适当怀疑，先找漏洞，再找亮点。 如果我的思路有问题，请直接说“这可能不行”，不要用“可能”“也许”敷衍过去。 请用下面的结构回复： 1. 总体判断：第一行给出结论，例如“方案可行”或“方案不可行”。 2. 事实与假设：明确区分哪些是事实，哪些是你推测的假设。 3. 主要风险：按影响从大到小排序，每个风险给出一句理由。 4. 验证建议：给出至少一个可以立即执行的验证动作。 5. 可取之处：确实有优点才说，没有就不要硬凑。 语气要求：直接但克制，不客气也不刻薄；不要使用“很好”“不错”“令人印象深刻”这类空泛夸奖。 如果信息不足，直接说“这些信息不足以判断”，不要编造结论。

3.2 逐句拆解：每个写法背后的设计意图

第一句“不是客服，也不是啦啦队”，是在给模型一个反角色锚点。客服的天职是让用户满意，啦啦队的天职是鼓舞士气，这两个角色天然会导向奉承。明确排除它们，比只说“请客观”有效得多，因为角色定义会直接影响后续所有句子的解释方式。

第二句“先找漏洞，再找亮点”，是在规定分析顺序。模型的注意力会天然跟着第一项任务走，如果把“找亮点”放在前面，它就会先写一堆赞美。顺序本身就是权重，这算是我实践下来最管用的一句话。

第三句“不要用‘可能’‘也许’敷衍过去”，是为了减少模糊副词。现实中，模型会用“可能有些边界问题”这种话保全自己，说了等于没说。让它直接说判断，即便判断错了，至少给出的是可验证、可反驳的内容，而不是一句永远正确的废话。

固定结构“事实与假设分离”则是为了抑制幻觉。模型容易把推测内容写成既定事实，强制分开之后，它能更坦率地承认“这是我推测的”。最后一句“没有就不要硬凑”也很关键，它专门防止模型为了讨好我的指令而发明缺点，这种行为本质上是另一种形式的奉承。

3.3 不同场景下的快速替换方法

这套模板不是死板的。我通常会根据场景替换几个关键词：

• 技术评审：保持原样，重点看“主要风险”和“验证建议”。
• 文案修改：把“主要风险”改成“逻辑冲突和表达歧义”，把“验证建议”改成“修改示例”。
• 日常决策：把“总体判断”改成“推荐选项”，并且把“事实与假设”保留不变，用来拆解选项前提。

替换的原则是：结构不换，角色词和关注点换。因为模板里最值钱的不是具体字眼，而是“先结论、再事实、后风险、再行动”的框架，这个框架在大部分任务里都适用。

4. 改造前后，同一个问题给出了完全不同的答案

4.1 技术评审实测：同一个接口方案的两种回答

我用一个稍微简化过的场景来说明。假设输入是这样的：

“我准备做一个报名接口，流程是：用户点击报名，先扣库存，再写订单记录，前端禁用按钮防止重复点击。请帮我评审。”

默认回复通常会是这样：

“这个方案整体思路清晰，通过前端按钮禁用可以防止大部分重复提交，扣减库存后再生成订单的基本流程是合理的。建议考虑增加后端防重机制，并发场景下可以优化。整体完成度不错，继续加油。”

看起来没毛病，但等于没给到点上。改成去奉承化模板后，同一句话得到的回复是：

“结论：这个方案目前不建议直接上线。有两个高风险点：扣库存和写订单不是原子操作，第二步失败会出现库存已扣但订单缺失的脏数据；前端禁用按钮不能作为防重手段，请求可以被并发重放。建议把两步放进同一个事务，并用库存乐观锁或原子更新做条件校验；如果短期改造困难，至少先对订单加唯一约束，后续再优化。没有验证过并发场景之前，不要依赖前端禁用。”

对比一下，前一条把问题藏在“建议考虑”里，后一条直接把阻断项和改造顺序列出来了。默认回复只是在“表达态度”，去奉承化回复在“解决问题”。两者对实际工作的参考价值相差很多。

4.2 文案评审实测：一句话标题的意见

再换到内容场景。输入：“帮我看看两个标题哪个好：A. 限时秒杀狂欢；B. 今晚8点，前500名半价。”

默认回复通常是：“两个标题各有优势，A文案更具情绪氛围，B更明确直观。如果面向冲动消费群体推荐A，面向价格敏感用户推荐B。建议结合投放渠道选择。”

这种回答的最大问题是把决策责任丢回给用户。去奉承化模板给的结果则是：

“结论：B更优，除非目标是品牌情绪投放。A只有形容词和活动名词，没有可验证信息；B明确给出时间和数量，能直接触发行动。两者都属于功能型文案时，B的信息密度更高。如果你希望增加品牌感，可以在B基础上补充状语，而不是使用A。”

你会发现，它的判断对象不是“哪个好听”，而是“哪个更符合可执行目标”。去奉承化不只是语气变硬，而是从“给态度”变成“给判断依据”。

4.3 行为变化总结表

4.4 一个容易忽略的坑：敢说不等于说对

这里必须提醒一点：去奉承化会改变模型“敢不敢反对”的倾向，但不会提高它“说得对不对”的水平。实测下来，优化后的模型偶尔会把一个其实没问题的点描述成严重隐患，甚至自信地编出一个并不存在的风险。所以我的习惯是，把它的回答当成“候选风险清单”，而不是最终判决。它帮你把需要验证的地方列出来，再由你去做验证，这个定位才是健康的。

5. 边界控制：别把去奉承化调成“杠精模式”

5.1 我踩过的坑：指令写得太重，它会为批评而批评

第一版自定义指令里，我写过“每一环都要怀疑”之类的话，结果模型进入一种“强行挑刺”状态。它会对一个很合理的方案也列出三条“风险”，其中两条明显站不住脚。表面上看起来很严格，实际只是在做另一种奉承——奉承“老板想要严格”的指令。识别这种状态的信号很简单：如果它给任何方案的风险列表都长得出奇，而且换一个具体场景后仍然套用同一套话术，那基本就是表演式批评。

5.2 四条边界规则，建议加进任何去奉承化指令

为了把“有立场”和“乱挑刺”区分开，我后来在模板尾部加了四条约束，你也可以参考：

1. 批评必须带依据，不能凭空下一个否定结论；
2. 允许说“暂未发现高风险”，别为了显得严谨而硬编风险；
3. 只评价方案本身，不评价提问者，避免出现“你没想到”这类话；
4. 标注确定性级别，区分“我确定”“我推测”“需要实验验证”。

这四条规则的价值在于给模型的“批判权”装上边界。没有它们，去奉承化会变成另一种失真；有了它们，模型才真正从“迎合用户”转向“对事实负责”。

5.3 场景强度要分档，不是一套打天下

我也踩过“一套指令用所有场景”的坑。头脑风暴场景需要发散和鼓励，如果一直用强批判模板，思路会被掐断；情绪陪伴场景更需要共情和认同，去奉承化反而会让人难受。我的处理方式是准备几套预设模板，按场景临时替换：

• 头脑风暴：弱化批评，先扩展可能性，再补障碍分析；
• 技术或商业评审：强批判，重点看风险和验证方法；
• 资料总结：不强求批评，重点标注来源和不确定性；
• 情绪陪伴：不去奉承化，反而要增加心理支持。

自定义指令本身是静态的，但它可以通过会话前缀和临时提示做强度微调，并不冲突。

6. 把去奉承化从一段配置变成持续工作流

6.1 像维护代码一样维护指令资产

我会在本地文档里维护一份指令配置表，记录版本号、使用日期、主要改动和发现的问题。这样做的好处是，当模型版本变化或任务类型变化时，可以快速回溯是哪句话带来了副作用。每次调整只改一个句子，改完用固定的几个测试用例做前后对比。比如我常用“评审一个报名接口”和“评价两个标题”这两个问题作为回归测试，指令一改就能立刻看出差异。

6.2 与会话前缀和上下文模板配合

自定义指令负责“怎么说话”，会话前缀负责“今天做什么”。比如进入预发布评审时，我会在对话第一行写：“今天评审二维码扫码流程，重点检查并发回滚、失败提示和降级策略，请给出阻断与非阻断清单。”模型就会在已有批判性风格的基础上，进一步聚焦到当前任务的具体维度。两者的组合比只靠自定义指令更稳定，因为它给了模型一个更明确的上下文锚点。

6.3 最后分享一点实操体会

用了大半年，我最大的感受是“去奉承化”真正改变的不是AI的性格，而是对话的权力结构。默认模式下，模型像一个总说“你做得对”的同事，让我在错误的方案上越走越自信；调整之后，它变成了敢说“这条跑不通”的搭档，把那些本来会被客套话盖住的风险，重新放回我的视野里。当然它还是会犯错，还是可能一本正经地判断失误，所以我也会继续用事实去校验它。如果你也受够了每次评审得到的都是“整体不错”这种反馈，我建议从设置一条最简单的自定义指令开始：先给结论，再讲理由。不用一次到位，先感受一下对话重心被拉回信息本身是什么体验。