Reference anchoring
Rather than saying "make it cleaner," say "reference a specific part of a specific thing."
What you'll run into
- 说了一堆形容词，做出来还是那个通用模板样子
- 来回改了五轮，每轮都在用另一组形容词描述同一件事
- 你心里有个大概的样子，但说不出来
The problem with adjectives is that they describe feelings, and feelings differ from person to person. "Clean" to you means more whitespace; to it, maybe fewer elements. "Professional" to you means high information density; to it, maybe a darker blue palette. You are using the same word for different things.
A reference has no such ambiguity. It is an objective thing — you can point at it and say "like this," or point and say "not this."
What to anchor
| 锚定什么 | 怎么说 | 比说形容词好在哪 |
|---|---|---|
| 结构 | 参考邮件客户端的左导航加列表加详情 | 「布局清晰」说不出该有几栏 |
| 密度 | 信息密度参考某个任务管理工具的列表 | 「简洁」既可能是留白多，也可能是内容少 |
| 语气 | 文案语气参考某个产品的错误提示 | 「友好」是个方向，不是个标准 |
| 代码风格 | 参考项目里已有的某个文件 | 「保持一致」不说清跟谁一致等于没说 |
| 反面参考 | 别做成某类页面那样，理由是什么 | 排除法有时比正面描述更快收敛 |
How to give it
- Point to a specific part, not the whole product. "Reference product X" is too big; "reference its task-list screen" is actionable.
- Say what to borrow and what not to. Borrow the structure, not the features; borrow the density, not the color palette. Without that clarity, it copies the features too (see borrow the form).
- Use screenshots. If you can show an image, show one — a screenshot is far more precise than a paragraph. And after sharing it, point out which part of it you care about.
- References from inside the project work best. "Follow the existing OrderList component's pattern" is the strongest anchor — it's right there in the codebase, zero room for interpretation.
- Have it paraphrase first. Ask it to state what it plans to borrow and what to skip; you catch the misread in seconds.
PROMPT · with references
做：[要做的东西] 参考对象： - 结构参考 [具体产品的具体部分]，我看中的是 [具体哪一点] - 密度参考 [具体产品的具体部分] - 代码风格参考项目里的 [具体文件路径] 明确不借的： - 它的功能列表。我的功能范围见 [规格文件] - 它的配色。配色用项目现有的设计令牌 请先复述一遍：你打算借哪些、不借哪些， 以及你对「我看中的那一点」的理解是什么。 我确认之后再动手。