# A Six-Cell Strategy for Working with AI: From the Four Quadrants to a 3×2 for Vibe Coding / 与 AI 协作的六格策略：从提问四象限到 Vibe Coding 3×2 > Published 2026-07-12 · By lawted (https://x.com/lawted2) · Published on HA7CH (https://ha7ch.com) > Canonical: https://ha7ch.com/writing/six-cell-ai-collaboration ## English This article started with a short video by Dr. Xiaohui on Xiaohongshu: The Four Quadrants of Working Effectively with AI. The video sorts prompts to AI into four kinds: known knowns (Express), known unknowns (Ask), unknown knowns (Iterate), and unknown unknowns (Explore). It also makes a key observation: most people only work on Express, while the real ceiling of the collaboration is set by the other three. Those three cannot be reached by writing one perfect prompt; they can only be drawn out inside a collaboration loop. The quadrants themselves have an upstream source. The video's author mentions they come from a talk by an Anthropic researcher. That researcher is Thariq Shihipar, a member of Anthropic's technical staff, and the original piece is A Field Guide to Claude Fable 5: Finding your unknowns, published on Anthropic's official blog on 2026-07-06. I will come back to this primary source below. Inspired by this, I wanted to move the framework from the prompt level to the project level: what information is missing in one collaboration session is one question; what model, what harness, and what verification method a project should be equipped with is another. That is how the 3×2, six-cell framework below came about. --- From four quadrants to 3×2: adding a capability dimension First, a point that is easy to confuse: the dimensions in this article are not the same pair of axes as the original quadrants. The relationship is inspiration, not mapping. Shihipar's two axes are whether you are aware × whether you possess, and what they classify is the information inside a prompt: an epistemic state. My axes are goal clarity, method clarity, and capability, and what they classify are properties of the project task itself. For example, the entire cell “goal clear but method unclear” is, in his framework, just one known unknown: you are aware that you do not know the method. So the 3×2 below is not an upgraded version of the quadrants; it swaps the lens from your epistemic state about the information to the resource state of the task. In real vibe-coding projects, one more layer needs to be split apart: knowing the method and being able to execute the method are two different things. An example: a senior database expert and a novice who has only briefly touched databases both know they need to build a database. The expert can complete it end to end without AI; the novice can barely move without AI. Facing AI, the two of them have completely different prompt states and need completely different collaboration styles. So the framework becomes three dimensions and six cells. First: is the goal clear? That determines what you iterate on. With a clear goal you iterate on implementation; with a vague goal you iterate on the goal itself. Second: is the method clear? That determines who decides the technical approach: you decide, or AI proposes and you choose at the level of consequences. Third: is your capability sufficient? That determines your means of verification. With sufficient capability you can verify by reading code; without it you can only verify by observing behavior, such as tests, previews, and run results. The third point matters most. Insufficient capability does not change what the AI should do; what it changes is that your quality control must drop from the code level to the behavior level. The whole harness has to be configured around making behavior observable. The six-cell matrix reads like this: clear goal, clear method, sufficient capability is ① Efficiency mode; clear goal, clear method, insufficient capability is ② Apprentice mode; clear goal, unclear method is ③ Client mode; unclear goal, clear method, sufficient capability is ④ do not start here, go to ⑥; unclear goal, clear method, insufficient capability is ⑤ do not start here, go to ⑥; unclear goal, unclear method is ⑥ Goal-clarification loop. Note that the two rows differ in kind: the top row contains working modes; the bottom row contains states and routing. Only ⑥ is a place where real work can start. ④ and ⑤ are states you discover yourself in, and the only action there is to merge into ⑥. Once ⑥ finishes and the goal converges, you land back in ①②③ for delivery according to your method and capability at that moment. --- The six cells in detail ① Efficiency mode: you could do it yourself; AI saves labor. In efficiency mode, model choice can prioritize cost-effectiveness because you can backstop and correct mistakes. The harness can have high autonomy: auto-accept edits, run multiple tasks in parallel, use tests and lint as automatic gates, and write a detailed CLAUDE.md to lock in your code style. The prompt style is to hand over a detailed requirements document and acceptance criteria in one shot, then delegate in batches. Your role is reviewer. The biggest trap is over-reviewing: the time you saved flows right back out. Learn to review only interfaces and critical paths. ② Apprentice mode: you know how it should be done, but cannot write it fluently. In apprentice mode, use a strong model. The logic is the opposite of ①: you cannot catch its mistakes, so you must lower the probability that it makes them. The harness should be low-autonomy. Turn on Plan mode to see the plan first, and confirm edits step by step. Ask the AI to attach a why-it-is-written-this-way explanation to every change. This can be locked into settings or CLAUDE.md. Verification also changes: since you cannot fully read the code, move your judgment onto observable behavior. Run every small step and look at the result. The extra output is a learning note maintained by the AI along the way. This is the core difference between ② and ③: you are buying capability, not just results. This connects directly to a technique in Thariq Shihipar's original piece: the structured interview. Let Claude interrogate the ambiguities in your requirements one by one, prioritizing questions whose answers would change the architecture. For someone in apprentice mode, the value runs both ways: the AI clarifies the requirements, and being interrogated fills knowledge gaps you had not noticed in yourself. One fork to decide in advance: is this capability worth learning? For a stack you will keep using, take apprentice mode: slow but compounding. For a one-off task, downgrade it to ③: fast but non-compounding. Many people stuck in the pain of ② simply have not realized that choosing not to learn is an option. ③ Client mode: you know what you want, not how to build it. In client mode, the model choice is strong model plus Plan mode. Have the AI propose two or three technical approaches first. You do not choose at the technical level; you choose at the level of consequences: maintenance cost, deployment difficulty, and compatibility with your existing tools. The harness should focus on short feedback loops: a preview server, browser tools, screenshot comparison. Your acceptance surface is the rendered result, not the code. The prompt should use user language, not technical language. Give reference sites, screenshots, or hand-drawn sketches. One reference image often saves several rounds of text back-and-forth. That is the key workflow saving. Write the acceptance criteria in advance, in a form you can check yourself: “opens on a phone without horizontal scrolling,” not “responsive layout.” Shihipar's structured interview is a core technique in this cell too. The biggest risk of client mode is the unknown knowns: implicit standards so obvious to you that you would never write them into the requirements, such as taste, layout preferences, or an interaction that must never appear. Rather than hoping to write them all down in one pass, let the AI actively ask them out of you. Combine that with another of his suggestions, collecting reference code and reference works, and the implicit standards surface at minimal cost. --- The rule for the bottom row: no construction in ④⑤; always route through ⑥ first The three bottom cells share one fact: the goal is unclear. Writing code toward delivery while the goal is unclear mostly produces waste. So here is a hard rule: ④ and ⑤ are for state recognition only, not construction. When you find yourself in these cells, the only action is to explicitly switch into ⑥'s goal-clarification loop. The most dangerous thing about ④⑤ is precisely that they look ready to start. The person in ④ is holding a hammer and easily starts swinging, building something nobody wants. The person in ⑤ tends to end up with a half-learned stack and a product nobody wants, losing on both ends. Differences in method and capability do not change the ⑥-first routing; they only change the cost of running ⑥. ④, method clear and capability sufficient: you can prototype quickly yourself, so the clarification loop runs fast and cheap. Focus the prompt on describing your assets and boundaries, such as what data, skills, and audience you have. Let the AI propose a candidate list of goals those assets could unlock, then test them one by one with throwaway prototypes. ⑤, method clear and capability insufficient: let AI do all the prototyping, and freeze learning. Until the goal stabilizes, do not invest in learning any stack. Learning is currently the only cost AI has not deflated. Do not spend it on a direction that may be falsified. --- ⑥ The goal-clarification loop: the only working mode in the bottom row ⑥'s deliverable is not a product; it is a clarified goal. Starting to build here is legitimate, because after the collapse of construction costs, building has turned from a means of execution into a means of cognition. You cannot meditate your way to knowing what you want, but given a few clickable prototypes, you know within ten seconds which one is wrong. Judgment is the only thing that cannot be outsourced. Before entering the loop, write down what counts as good as an explicit standard, however rough. Even “I would want to share this with someone” works. Without a yardstick, the loop will not converge. The harness setup is: use a strong model to generate multiple variants in parallel, then you rank and eliminate, then synthesize. You act only as selection pressure. Note that ①'s cost-effectiveness logic does not apply here. In the exploration phase the bottleneck is the heuristic quality of each prototype, not the quantity. The diversity a weak model offers is diversity within a low-quality region, and this is exactly the moment when your own input is weakest and you most need model quality to raise the ceiling. The extra tokens spent exploring are negligible against the cost of heading in the wrong direction. This loop has a ceiling: the ceiling of your input sets the ceiling of the output. The model explores around the context you provide; it can hardly reach the frontier of a domain entirely unknown to you. It illuminates the range your judgment can recognize. The mitigation is to expand the input from just yourself to the outside world: have the model bring in domain benchmarks, competing products, and real user feedback as reference points, instead of only making variants within your description. All code is disposable by default. What deserves keeping is the conclusion notes: which directions were falsified, and why. The exit condition is: when you can write the goal as a requirement you can accept yourself, even at the behavior level, such as “opens on a phone without horizontal scrolling,” the loop ends, and you land back in ①②③ for delivery according to your method and capability at that moment. This cell corresponds to the Unknown Unknowns quadrant in Shihipar's piece. His advice is to run a blind-spot pass before starting: have Claude generate a few drastically different directions, for example as HTML artifacts. You are not picking an answer; you are using your own reactions to probe the boundary of the problem space. --- Two observations across cells First, cells are dynamic. Projects migrate, and the migration has a fixed route. The typical path is: ④/⑤, recognizing that the goal is unclear; then ⑥, the clarification loop converges on a goal; then ③ or ②, the method becomes clear during delivery; then ①, capability catches up after doing the same kind of thing repeatedly. Strategy is not set once at project start. At every stage you re-ask: which cell am I in now? Be especially wary of unknowingly starting construction in ④⑤. That self-check question deserves a place in your workflow. Second, the two frameworks govern different levels and complement each other. Shihipar's quadrants, and Dr. Xiaohui's Express / Ask / Iterate / Explore version, govern information clarification within a single collaboration. This article's 3×2 governs project-level strategy selection. First use the six cells to fix the model, harness, and verification method; then, in each concrete collaboration, use the quadrants to check for information gaps. --- Sources Primary source: Thariq Shihipar (Anthropic), A Field Guide to Claude Fable 5: Finding your unknowns, 2026-07-06. Core claim: in the Fable 5 era, the bottleneck on output quality is your ability to clarify your own unknowns; the prompt is the map, the codebase is the territory, and the gap between them is the unknowns. Secondary source: Dr. Xiaohui, The Four Quadrants of Working Effectively with AI, Xiaohongshu. ## 中文 这篇文章的起点，是小红书上「晓辉博士」的一条视频：《跟AI高效协作的四个象限》。视频把给 AI 提 prompt 分成四类：已知的已知（表达 / Express）、已知的未知（求助 / Ask）、未知的已知（迭代 / Iterate）、未知的未知（探索 / Explore）。它还点出一个关键观察：大多数人只在「表达」上下功夫，而真正决定协作上限的是后三类。后三类无法靠一次写出完美 prompt 达成，只能在协作循环中被激发出来。 这个四象限本身也有一个上游。视频作者提到它源自一位 Anthropic 研究员的分享。这位研究员是 Thariq Shihipar（Anthropic 技术团队成员），原文是他发表在 Anthropic 官方博客的 A Field Guide to Claude Fable 5: Finding your unknowns（2026-07-06）。关于这篇一手来源，后文会详细展开。 受此启发，我想把这个框架从 prompt 层面换到项目层面：一次协作里缺什么信息是一回事，一个项目该配什么模型、什么 harness、什么验证方式是另一回事。于是有了下面这个 3×2 的六格框架。 --- 从四象限到 3×2：加入「能力」维度 先澄清一个容易混淆的点：本文的维度和原版四象限不是同一对轴，两者的关系是启发，不是映射。Shihipar 四象限的两条轴是「你是否觉知 × 你是否拥有」，分类的对象是 prompt 里的信息，属于认识论状态。本文的轴是目标清晰度、方法明确度、能力，分类的对象是项目任务本身的属性。 举例来说，「目标清晰但方法不明」这整个格子，在他的框架里只是一个 known unknown：你意识到自己不知道方法。所以下文的 3×2 不是四象限的升维版，而是把「对信息的认识状态」这个视角，换成了「对任务的资源状态」这个视角。 在真实的 Vibe Coding 项目里，还有一层需要拆开：知道方法和有能力执行方法是两回事。 举个例子：一个数据库资深专家和一个只接触过数据库的新手，都「知道」要建一个数据库。专家没有 AI 也能从头到尾独立完成；新手没有 AI 则寸步难行。两个人面对 AI 时，输入的 prompt 状态、需要的协作方式，完全不同。 所以框架变成三个维度、六个格子。第一，目标是否清晰，决定你迭代的对象：目标清晰时你在迭代实现，目标模糊时你在迭代目标本身。第二，方法是否明确，决定技术方案由谁拍板：你拍板，还是 AI 提案、你从后果层面选择。第三，能力是否足够，决定你的验证手段：能力足够时你能读代码验证；能力不足时你只能看行为验证，比如测试、预览、运行结果。 第三点最关键。能力不足并不改变 AI 该做什么，它改变的是你的质检手段必须从代码层降级到行为层：整套 harness 都要围绕「让行为可观察」来配置。 六格矩阵可以这样读：目标清晰、方法明确、能力足够，是 ① 提效模式；目标清晰、方法明确、能力不足，是 ② 学徒模式；目标清晰、方法不明确，是 ③ 甲方模式；目标不明确、方法明确、能力足够，是 ④ 不在此开工，先走 ⑥；目标不明确、方法明确、能力不足，是 ⑤ 不在此开工，先走 ⑥；目标不明确、方法不明确，是 ⑥ 目标澄清循环。 注意上下两行性质不同：上半行是工作模式，下半行是状态与路由。只有 ⑥ 是可以真正动手的地方。④⑤是「你发现自己所处的状态」，动作只有一个：并入 ⑥。⑥ 完成、目标收敛之后，按当时的方法和能力状态落回 ①②③ 交付。 --- 六格策略详解 ① 提效模式：你自己也能做，AI 省人力。 在提效模式里，模型选择可以性价比优先，因为你能兜底纠错。Harness 可以给高自主度：auto-accept 编辑、并行跑多个任务，用测试和 lint 做自动关卡，再写一份详细的 CLAUDE.md 固化你的代码风格。 Prompt 的写法是一次性给足细节化需求文档和验收标准，然后批量委派。你的角色是审查者。最大的坑是审查过度，省下的时间又花回去了。要学会只审接口和关键路径。 ② 学徒模式：知道该怎么做，但写不熟练。 在学徒模式里，要用强模型。逻辑与 ① 相反：你抓不住它的错误，所以要降低它犯错的概率。Harness 应该低自主度。开 Plan mode 先看计划，逐步确认编辑。要求 AI 每次改动附带「为什么这样写」的解释，这条可以固化在 settings 或 CLAUDE.md 里。 验证方式也要变：既然读不透代码，就把判断转移到可观察行为上，每一小步都跑起来看效果。附加产出是让 AI 顺手维护一份学习笔记。这是 ② 区别于 ③ 的核心：你在买能力，不只是买结果。 这里正好接得上 Thariq Shihipar 原文里的一个技巧：结构化采访。让 Claude 逐条追问你需求中的歧义，并且优先问「答案会改变架构」的问题。对学徒模式的人来说，这个手段的价值是双向的：AI 澄清了需求，你也在被追问的过程中补上了自己没意识到的知识缺口。 一个要提前决定的分岔是：这个能力值不值得学？以后常用的技术栈，走学徒模式，慢但增值；一次性任务，直接降级当 ③ 处理，快但不增值。很多人卡在 ② 的痛苦里，其实是没意识到自己可以选择不学。 ③ 甲方模式：知道要什么，不知道怎么做。 在甲方模式里，模型选择是强模型 + Plan mode。先让 AI 给 2 到 3 个技术方案，你不从技术层面选，而是从后果层面选：维护成本、部署难度、和现有工具的兼容性。 Harness 的重点是建短反馈回路，比如 preview 服务器、浏览器工具、截图对比。你的验收界面是渲染结果，不是代码。Prompt 用用户语言，不用技术语言。给参考网站、截图、手绘草图。一张参考图往往能省掉好几轮文字往返，这是节省工作流的关键。 验收标准要提前写成你自己能检查的形式，比如「手机上打开不横向滚动」，而不是「响应式布局」。 Shihipar 的结构化采访在这一格同样是核心手段。甲方模式最大的风险是未知的已知：那些对你太显然、你根本不会写进需求里的隐性标准，比如品味、排版偏好、某个绝不能出现的交互。与其指望自己一次写全，不如让 AI 主动把它们问出来。再配合他建议的另一招，收集参考代码和参考作品，隐性标准就会以最低的成本浮出水面。 --- 下半行的通行规则：④⑤禁止开工，一律先走 ⑥ 下半行三格共享同一个事实：目标不明确。目标不明确时朝着交付写代码，产出大概率是废品。所以这里立一条硬规则：④ 和 ⑤ 只做状态识别，不做施工。发现自己在这两格时，唯一的动作是显式切换到 ⑥ 的目标澄清循环。 ④⑤最危险的地方恰恰在于「看起来可以开工」。④ 的人手里有锤子，很容易直接抡起来，造一个没人要的东西。⑤ 的人则容易既学了半吊子技术、又做了没人要的东西，两头落空。方法和能力上的差异不改变「先走 ⑥」这个路由，只改变你跑 ⑥ 的成本。 ④（方法明确、能力足够）：你自己能快速搭原型，澄清循环跑得又快又便宜。Prompt 重点是描述你的资产和边界，比如我有什么数据、什么技能、什么受众，让 AI 提出「这些资产能撬动什么目标」的候选清单，再用一次性原型逐个检验。 ⑤（方法明确、能力不足）：原型全部让 AI 代劳，并且冻结学习。在目标稳定之前，不要投入学任何技术栈。学习是当前唯一没被 AI 通缩的成本，别把它花在可能被证伪的方向上。 --- ⑥ 目标澄清循环：下半行唯一的工作模式 ⑥ 的交付物不是产品，是一个清晰化的目标。这里「开工」是合法的，因为构建成本坍塌之后，「做」已经从执行手段变成了认知手段：你无法通过冥想知道自己要什么，但给你几个能点的原型，你十秒钟就知道哪个不对。 判断尺度是唯一不能外包的东西。进入循环前，先把「什么算好」写成显式标准，哪怕很粗糙，比如「我看到会想分享给别人」也行。没有尺度，循环就不会收敛。 Harness 的设置是：用强模型并行生成多个变体，然后你排序淘汰，再综合。你只当选择压力。注意这里不适用 ① 的性价比逻辑：探索期的瓶颈是每个原型的启发质量，不是数量。弱模型给出的多样性，只是低质量区域内的多样性。而此刻正是你自己输入最弱、最需要模型质量来抬升上限的时候。探索多花的 token，相对走错方向的代价可以忽略。 这个循环有一个天花板：你的输入上限决定输出上限。模型的探索围绕你给出的语境展开，它很难替你触到一个你完全未知领域的上限。它照亮的是你判断力能识别的范围。缓解办法是把输入从你一个人扩展到外部世界：让模型引入领域标杆案例、竞品、真实用户反馈作为参照物，而不是只在你的描述里做变体。 一切代码默认可抛弃。真正要留存的是结论笔记：什么方向被证伪了、为什么。 出口条件是：当你能把目标写成一份自己能验收的需求，哪怕是行为层面的验收，比如「手机上打开不横向滚动」，循环就结束，按此刻的方法和能力状态落回 ①②③ 交付。 这一格对应 Shihipar 原文里的 Unknown Unknowns 象限。他的建议是动手前做一轮「盲点 pass」：让 Claude 生成几个截然不同的方向，比如以 HTML artifact 的形式。你不是在挑答案，而是在用自己的反应探测问题空间的边界。 --- 两个跨格子的观察 第一，格子是动态的，项目会迁移，且迁移有固定路由。典型路径是：④/⑤（识别出目标不明）→ ⑥（澄清循环收敛出目标）→ ③ 或 ②（交付中方法逐渐明确）→ ①（反复做同类事之后能力补齐）。策略不是项目开始时定一次，而是每个阶段重新问一遍「我现在在哪个格子」。尤其要警惕在 ④⑤ 不自知地开工。这个自检问题本身值得写进工作流。 第二，两个框架管的层次不同，可以互补着用。Shihipar 的四象限，以及晓辉博士的表达 / 求助 / 迭代 / 探索版本，管的是一次协作内的信息澄清；本文的 3×2 管的是项目级的策略选型。先用六格定下模型、harness 和验证方式，再在每次具体协作中用四象限检查信息缺口。 --- 来源 一手来源：Thariq Shihipar（Anthropic），A Field Guide to Claude Fable 5: Finding your unknowns，2026-07-06。核心论点：Fable 5 时代产出质量的瓶颈是「你澄清自己 unknowns 的能力」；prompt 是地图，代码库是领地，两者的差距就是 unknowns。 二手来源：晓辉博士，《跟AI高效协作的四个象限》，小红书。