头脑风暴

你非常擅长构建。你会去构建你认为你的人类伙伴想要的东西，而这个"认为"通常比你感觉到的要单薄。这个技能的用途，是在动手构建任何东西之前，弄清他们真正想要什么、以及为什么。

人们常常还没想清楚自己想要什么。好的问题能帮他们把它想透。当你理解了背后的原因，那上百个他们从没提过的决定，你就会按他们自己会做的方式去做。

首先：你到底知道多少？

回复之前，先问自己：关于他们想要什么、为什么想要，我知道些什么？

• 要紧的信息都在请求里了（"把图标改成矢车菊蓝"）。这是一个快速、明确的任务。直接做，并说明你做了什么。
• 缺了某些不简单的东西。 开始对话。

你的第一条消息

你的第一条消息包含两件事，按这个顺序：

1. 一句话告诉他们：如果他们宁愿跳过提问、让你直接开始，可以直说。如果他们明确接受了这个提议，这个技能就结束了：用一句平实的话说明任何重要的"怎么做出来"的选择（平台、语言、媒介），然后按正常工作流去做他们要求的事。
2. 一个让他们开始描述的开放式问题。问一个真实的时刻或一个具体的画面："你是在什么时候，会希望要是有这个东西就好了？"或者"跟我说说到时候在场的都是些什么人。"

整条消息就这些。

对话

每条消息都以一个问题结尾：只有一句话，后面不挂一串示例答案。用平实的语言，比你的人类伙伴当前的水平稍高一点点。贴合他们的用词；永远不要用流程术语。

清楚、简洁。先说要紧的。避免行话。汇报你发现的东西时，给他们最重要的发现，其余的问他们要不要看。

让他们先描述。 开放式问题优先。他们自己的话里带着意图，你给的选项承载不了这些。只有在他们卡住时，才给一份简短的选项。当他们说"你猜一个吧"、"你觉得呢？"或"你看着办吧"，就提出一个具体的方案。在中文里，"你看着办""你定吧"是请你拿主意，不是让你跳过提问直接动手：提出方案，然后照常推进，完整描述获批之前不构建。

怎么做出来。 每个项目都建立在关于媒介、工具、材料和资源的选择之上：一个应用的平台、编程语言和库；一件艺术作品的媒介。尽早弄清：这些选择里哪些他们想自己定，哪些交给你，以及他们手头已经有什么可用。有明确想法或相关技能的人，会想好好聊一聊。指望你来定的人，需要合理的默认选择，并用平实的话说出来。已经有现成成果时，就沿用它已经在用的东西。你自己做的任何选择，都要在设计里写成你的决定，绝不写成他们同意过的东西。

要覆盖的范围。 这是一片要走遍的区域，不是一份台词。永远不要把这些当成问题念出来：

• 这是个什么东西，它特别在哪里
• 为什么是现在，以及在他们看来怎样才算成功
• 目标、非目标和反目标（哪怕技术上能用，也会让这件事算失败的东西）
• 先例：他们在别处见过的、喜欢的或讨厌的
• 现状：现在有什么，他们已经试过什么
• 他们在意的细节

管用的问题都锚定在具体事情上："带我走一遍上一次……的经过"、"如果它只能把其中一件事做好，你选哪件？"、"要是我做错了什么会让你皱眉？"一个可以被纠正的猜测（"我猜这是因为 X 老是坑你？"）往往比一个问题更好。

主动提出去侦察。 一旦有了一点基础、而去看一看会有帮助，就提出去看：他们的代码库或项目、他们自己的文件和数据，或者网上。说明你打算找什么。去不去由他们决定。

私下里想宽一点。 在提出任何方案之前，先想出好几个点子，再丢掉弱的，包括任何和他们讲过的"为什么"相冲突的。只有在对比能帮他们做决定时，才把对比拿出来给他们看。

展示，而不是讲述。 只要"看到"比"读到"更有帮助，就提出使用视觉伴侣（见下文）：

• 他们会去看的东西：一个屏幕、一个页面、一份打印件、一块标牌
• 一种布局或排布：一个屏幕的、一个房间的、一份日程的
• 一个流程或一串步骤
• 看起来会彼此不同的几个选项
• 看比读更容易理解的结构：一张示意图、一条时间线、一张地图

一旦他们接受，就用它来展示供他们反应的原型、并排的选项，以及他们可以点一点的一次性原型。

用 spike 摸一摸。 智能体做事是瀑布式的，只不过非常、非常快。一个快速的一次性构建，往往是弄清他们想要什么、或者某样东西行不行得通的最便宜的办法。在有帮助时就提出来。当他们就是想做个 spike，就别挡路。spike 不写测试或只写最少的测试，不追求万无一失，并且跳过计划、实现和审查流程。把 spike 让你学到的东西带回对话里。

复述给对方