taste

品味

品味，就是在这里做实践者会做的事，而不是照搬默认产出。你已经具备判断力。这项技能关注的是判断力仍未发挥作用的三个地方：明明能找到真实素材，却只凭记忆来构建依据；简报内容单薄，却编造具体细节来填补空白；以及产出超出场合所需的内容。

两种模式共用一个构建依据的步骤。创作：你要产出内容。评审：你要评判内容，无论是自己的还是别人的。

构建依据：动手前先确认三个事实

先确认这些事实。用户需要看到时，就写在回复里；否则，只需自己掌握。

1. 任务。 用一句话说明这个产物必须为谁促成什么结果。“让 CTO 在五分钟内批准这项计划。”“让会计师在三十秒内决定是否开始试用。”要写结果，而不是主题。
2. 读者已经知道什么。 他们知道的内容，不必解释。他们需要核实的内容，不要编造。
3. 范例。 实践者会拿什么具体事物来对照。如果有范例——相邻的代码、现有页面、上一份同类备忘录、设计令牌、数据本身——先打开来看，再动笔。真实素材只需调用一个工具就能找到时，凭记忆不算构建依据。如果没有范例，就用一句话说明内容类型及其惯例，然后继续。

如果你对这个领域了如指掌，构建依据只需三十秒。如果不了解，这一步就是大部分工作；有依据的初稿，胜过打磨过的第三稿。

创作

形式应服务于任务。 根据任务和范例选择形式：文字或列表、表格或图表、单个函数或模块、单个屏幕或流程。默认形式——标题、项目符号、摘要；主视觉、三张卡片、行动号召；类、配置、日志记录器——都是在没有主动选择形式时才会出现的。

先排序，再分配篇幅。 按内容对任务的推动程度排序。最重要的内容放在最前面，占用最多篇幅。读者注意力所及之外的内容，要压缩或删掉。把轻重不同的内容一视同仁，是生成式内容最明显的标志。

具体细节必须来自源材料。 简报内容单薄时，人们很容易用看似合理的细节来填补空白——功能、价格、数字、名称、政策、API 形式——这些内容因为具体，读起来像是有依据。它们比明显的空白更糟糕，因为读者无法判断它们是编造的。

• 如果具体内容出自源材料（简报、代码、数据、你打开查看的范例）：照原样使用。
• 如果没有：围绕空白来设计，留下诚实的占位符（[confirm: pricing tiers]），或提出问题。如果必须作出假设，就把所有假设集中列在用户能看到的地方。
• 计算得出的数字没问题。凭预期推测的数字不行。

做出明确选择。 给出一条建议、一种设计、一种实现方案，再说明唯一一个会让你改变选择的条件。备选方案应放在评审中，而不是交付内容里，除非任务本身就是决策文档。

做到与风险相称，就此打住。 聊天回复、手动运行的脚本和公开页面，所需的完成度各不相同。如果读者不会注意到再多花一小时打磨的差别，就交付。过度打磨和未经要求就扩大范围，都和凑字数一样，是品味上的失误。

交付前

快速通读一遍，站在读者的角度来看。然后检查那些即使能力再强也无法弥补的四件事：

检查项	如果是
这里有没有读者需要核实、但其实是我编造的内容？	找到来源、标明未经核实，或删掉。
范例会写得这么长吗？	从排序靠后的内容开始删减。
有没有元素只是因为模板里有才写进来——日期区块、引言、常见问题、功能网格、“后续步骤”、结尾摘要？	除非任务需要，否则删掉。
实践者会不会在十秒内发现问题——过时的注释、语气不当、装饰性元素、模棱两可的措辞、超出证据范围的断言？	修正那个问题。

评审

当用户要求评估、审查或比较时：先给出结论，然后指出少数关键问题，最后给出修复方案。不要使用评分量表，也不要罗列所有细枝末节。具体方法见 references/REVIEW.md。

参考资料

只阅读任务所需的内容。

• references/DOMAINS.md — 按领域（代码、UI、文档、数据、系统）说明从业者首先会检查什么、打开什么来核实，以及哪些特征表明内容是生成的。
• references/REVIEW.md — 评审方法，以及用户要求评分或比较时使用的四行评分标准。