---
title: "我用人类文字审美改坏了AI指令"
author: "冯智勇Geo"
published: "2026-08-01T00:00:00.000Z"
description: "我把“自检并修正直至通过”压缩成“逐条校正成果”，才发现追求简洁、对仗和留白，会删掉AI指令需要的动作、范围、异常出口和完成条件。"
tags: ["AI","提示词","AI协作"]
url: "https://fengzhiyonggeo.com/posts/human-writing-aesthetics-ai-instructions/"
---

# 我用人类文字审美改坏了AI指令

**核心结论：** 写 AI 指令时，简洁不等于字数少，而是去掉废话后仍保留动作、范围、完成条件和异常出口。

事情开始于我修改自己的工作流程模板。我不断要求 AI 去掉注解、压缩用词，并让每一行长度接近、句式对称。

我原本就喜欢简洁、对仗。这几年，这种偏好变得更明显：我更愿意读简单、直接、情绪鲜明的文字，对严谨但冗长的表达反而越来越没有耐心。在我这里，去掉注解、追求对称和使用精巧短语，首先满足的是人类阅读审美。

所以，AI 给出压缩版后，我仍然觉得不够。我继续追问：“没有更简洁的表达了吗？”于是，“自检并修正成果直至逐条通过或标注无法通过项”，被压成了“逐条校正成果”。

这几个字看上去很漂亮，动作和对象都有，放进流程里也整齐。但它没有说明依据什么检查、发现问题后是否修正，更没有说明什么时候停止。

![小黑用对称裁纸机把长指令裁成整齐短条，依据、修正和停止条件被剪落，说明文字美感可能删掉执行边界](https://img.fengzhiyonggeo.com/piclist/260801234911938.png)

## 少掉的不是废话

我后来发现，在这条指令里，“校正”不足以单独表达检查、修正和重新验证三个动作。我以为自己只是在删除重复信息，实际删掉的是执行边界。

```text
压缩后：
AI 逐条校正成果。

保留执行边界：
AI 逐条对照验收标准检查成果。
AI 修正未通过项并重新检查。
AI 重复检查和修正，直至全部通过或说明无法通过的原因。
```

后一个版本更长，却回答了四个不同问题：依据什么检查，未通过时做什么，什么算完成，无法完成时如何处理。只要某段文字决定了动作、范围、完成条件或异常出口，它就不是可以随意删除的注解。

这不等于指令越长越好。无关背景和重复解释仍然应该删除。简洁的标准不是字数少，而是没有废话，同时保留完成任务所需的全部信息。

## 更可执行的用词对比

“AI 友好用词”不是固定词典。这里比较的也不是某些词是否天然更适合 AI，而是表达是否写清了动作、范围、异常出口和完成条件。

| 表达目的 | 模糊表达 | 更可执行的表达 |
| --- | --- | --- |
| 说明动作 | 处理素材 | 读取素材并提取事实 |
| 限定范围 | 不要大改 | 仅纠正错别字和语法错误，不调整观点、结构和语气 |
| 处理异常 | 有问题就处理 | 文件无法读取时，停止并说明原因 |
| 规定终止 | 逐条校正成果 | 修正并重新检查，直至全部通过或说明原因 |

更可执行，不等于语气更强或字数更多。关键是把原本留给 AI 猜测的部分写出来。“不要大改”仍然把什么算“大改”交给 AI 判断；“仅纠正错别字和语法错误，不调整观点、结构和语气”则直接划定了边界。

## 我现在如何判断

人和 AI 使用同一种自然语言，不意味着文章和指令应该遵循同一套文本标准。写给人看的文章可以保留节奏、情绪和留白；当 AI 是执行方时，指令要优先消除歧义、写全约束。

所以，我现在不再先问一条指令是否漂亮，而会先问：AI 要做什么，哪些事情不得做，允许做到什么范围，凭什么判断完成，遇到什么异常应停止并说明原因？如果这些问题没有答案，再整齐的句子也只是符合人类文字审美，却未必是一条可执行的 AI 指令。

## 相关文章

- [为什么 AI 做不好个人计划？](<https://fengzhiyonggeo.com/posts/why-ai-cannot-plan-my-day/>) — 让 AI 做个人计划不划算，因为真正决定计划的疲惫、回避、拖延和状态上下文，往往只有自己知道。
- [Pi Agent 能在终端里显示图片了](<https://fengzhiyonggeo.com/posts/pi-agent-inline-terminal-images/>) — Pi Agent 内置终端图片显示，在兼容终端中默认开启。一次真实使用经历说明，小工具也可能在局部交互上领先主流 AI 编程 CLI。
- [开门造车：为什么不用等做完再说](<https://fengzhiyonggeo.com/posts/open-garage-build-in-public/>) — 公开构建（Build in Public）不等于每天发布成品。我的文章分发系统已经跑通但未跑顺，我决定从调试阶段开始记录问题、试错和修改。
