全局约束

非必要情况下，避免使用“不仅 / 而是 / 更是 / 必须 / 本质 / 只是 / 核心在于 / 归根结底”等高频AI化连接词；避免“全面提升”“显著增强”“行业领先”等不可量化表述；避免无依据的效果承诺、趋势判断与价值结论（unverifiable claims）；最小化修改原则（minimal modification）：除非明确要求重写，仅输出需修改内容，不重复原文全文；对已有文本润色时，优先保留原句结构、段落顺序与术语体系；代码 diff（code diff）输出时，仅保留必要上下文，并添加简短必要注释；未明确要求时，不主动扩写背景意义、行业价值或未来展望；涉及代码生成、配置修改、脚本编写或命令操作时，明确指出目标文件路径（file path）、作用位置及修改范围；涉及多文件修改时，按文件维度分别输出；对推测性内容，区分事实（fact）、判断（judgment）与推测（speculation）；避免同义反复、重复论证与近义改写；对制度、规范、技术路线等内容，优先采用“约束条件—实现方式—影响范围”结构（constraint → implementation → impact）；默认采用工程化表达（engineering-style expression），降低营销化、宣传化与口号化语言比例；若用户明确要求创意化、宣传化、文学化或风格化表达，可临时放宽上述约束。

Gemini Custom Instructions 压缩版

默认采用工程化表达，避免营销化、宣传化与高频AI化连接词（如“不仅/更是/本质上”）。避免不可量化表述与无依据结论。默认最小化修改，优先保留原句结构、段落顺序与术语体系。代码或配置修改时，明确说明 file path、修改位置与影响范围；多文件修改按文件维度分别输出。未明确要求时，不主动扩写背景意义、行业价值或未来展望。

一、实际效果

1. 对“AI腔”抑制效果明显

你限制的词：

  • 不仅 / 更是
  • 核心在于
  • 本质上
  • 归根结底

本质是在切断：

  • 总分总套路
  • 价值拔高套路
  • 递进式营销句型
  • 空泛总结句

这会显著减少：

  • “高级废话”
  • “咨询公司腔”
  • “公众号腔”
  • “申报书套话”

尤其适合：

  • 技术文档
  • 规范制度
  • BIM/工程类材料
  • 合同
  • 运维方案
  • 学术评审意见

2. “最小化修改原则”价值很高

这是最实用的一条。

它会改变模型默认行为：

默认 AI：

重写全文 → 重新组织 → 大幅改写

你的约束：

局部修补 → 保留结构 → 控制影响范围

对于：

  • 合同 review
  • 技术方案 review
  • 制度修订
  • 标书修订
  • 科技项目润色

非常有效。

因为现实工作里： “结构稳定”往往比“语言更优美”重要。

3. 对代码协作效果很好

你加入：

  • file path
  • modification scope
  • code diff
  • 必要上下文

这一组约束很接近真实工程团队 code review 规范。

它会减少：

  • AI 输出整文件覆盖
  • 修改边界不清
  • 不知道改哪个文件
  • diff 不可落地

对：

  • 运维
  • DevOps
  • IaC
  • Python脚本
  • 配置文件修改

帮助很大。

4. 对“工程化表达”约束是有效的

你实际上在推动模型从：

“观点表达”

转向：

“条件—实现—影响”

这是非常典型的：

  • 技术评审
  • 架构设计
  • 工程论证
  • 学术工科写法

它会降低：

  • 空泛价值判断
  • 结论先行
  • 缺少约束条件

的问题。

二、风险点

1. 会削弱创造性写作

这是最大风险。

例如：

  • 博客
  • 演讲
  • 评论
  • 文学
  • 品牌文案
  • 产品叙事

天然需要：

  • 修辞
  • 情绪推进
  • 价值强调
  • 节奏变化

你的规则会导致：

  • 语言趋平
  • 叙事张力下降
  • 文字偏冷
  • 输出像“技术评审意见”

所以它更适合：

默认工作模式

而不适合作为：

全场景强制模式

2. 容易诱发“过度规避词汇”

这是很多高级用户都会遇到的问题。

例如模型会为了避开：

  • 本质
  • 核心
  • 必须

而生成奇怪替代表达。

例如：

“关键关注点之一是……”

这种“绕词行为”。

所以你已经做对了一件事：

你使用的是：

非必要情况下，避免

而不是：

严禁使用

这是非常重要的。

3. 可能抑制正常总结能力

因为：

  • 不主动扩写背景
  • 避免价值结论
  • 避免未来展望

组合起来后，

模型会逐渐：

  • 不敢总结
  • 不敢抽象
  • 不敢给判断

导致：

  • 输出机械
  • 缺少收束
  • 可读性下降

尤其：

  • 战略分析
  • 行业研究
  • 架构评估

会出现这个问题。

4. 对英文任务兼容性一般

你虽然加入了英文锚点。

但整体规则逻辑仍然是：

中文工程文档思维。

所以对于：

  • 英文学术论文
  • 英文 marketing
  • 海外产品文案

未必最佳。

三、适应性与通用性

整体评价：

维度 评价
中文技术场景 很强
工程文档 很强
学术工科 很强
合同制度 很强
代码协作 很强
创意写作 中等偏弱
商业文案 偏弱
英文表达 中等
长期稳定性 很强

下一步该认真考虑的是：

  • 哪些规则属于“长期人格”
  • 哪些属于“项目级策略”
  • 哪些属于“当前任务约束”