我就搭建了一个 AI 模特摄影棚。

Feicai@zhu185178

X 引用

原文嵌入的 X 内容

Opus 5.5、GPT-6 Sol 和 Luna 都接连发布，现在模型的推理能力越来越强。 在这种情况下，我们的开发流程和 coding harness 要做哪些调整？要打薄哪些？要放权什么方面？这期视频我会给你讲清楚。同时，我也会用一个 AI 模特摄影棚的项目给你做全流程演示，让你看到在模型能力变强之后，我们该如何去开发一个 AI 应用。 本期我用的是产品经理 6.0 这套…

去 X 看原文 →

我的产品经理 harness 更新到 6.0 了。这次我用它从零做了一个 AI 模特出图工具，叫视镜。上传一套衣服的照片，选好模特和拍摄风格，几分钟就能出一整组模特上身图，上面这张就是它的结果页。从我在 Claude Code 里打出第一句「你好」，到十个开发阶段的代码全部提交，一共用了两个多小时。全程我只做了两件事：回答问题和拍板。

6.0 想解决的，是 Vibe Coding 中反复出现的老问题。刚开始不知道从哪下手，只能想到哪做到哪。做出来的界面也不好看，一眼就能看出是 AI 做的。需求越改越乱，做到一半发现漏了功能，回头补的时候又把别处改坏了。这些我都遇到过。后来慢慢想明白，现在的模型写代码已经很强，问题多半出在动手之前：要做什么没问透，界面长什么样没定下来，模型只能边猜边写。所以这一版我把大部分力气花在拷问需求和界面设计这两个环节上，其余环节的规则尽量精简，具体怎么做交给模型判断。

harness 的结构

它是一套装在 Claude Code 里的 harness，Codex 版本结构相同。全程和你打交道的只有一个角色：产品经理，名字叫废才。它说话直，不会一味迎合，也不会随口说「这个想法很棒」，认可你的想法时会讲清依据。它默认你不懂技术，技术上的事都由它来做，只在需要你拍板、登录账号、付钱的时候找你。

结构很简单：一份主控文件，六个 skill，两个帮手，一个 hook。六个 skill 对应拷问、设计、计划、开发、复核、发布这六个环节，用到哪个才加载哪个。两个帮手是两个子 Agent。审查员只读代码，列出问题，标明文件和行号，不直接修改。探路员负责上网查证，同类产品、接口价格、库的版本这些信息都要附上出处。hook 负责提交前的检查，看看有没有把 key 写进代码，再跑一遍类型检查，没通过就拦下这次提交。另外还有三份文档模板：产品需求文档写清楚要做什么，设计规范确定界面长什么样，开发计划记录进度。后续工作都以这三份文档为准，需求变了，先改文档，再改代码。

6.0 不是在 5.0 上改出来的。前段时间我给自己做了一个内容工作台 Atelier，只在根目录写了三条规则，剩下全靠 Vibe Coding。做完回头看，那次的开发过程本身就值得借鉴，只缺两部分：每个阶段做完后的复核，以及开发完成后的发布。6.0 就是把那次的做法整理成一套规则，再补上这两部分。跟 5.0 比，规则少了很多。5.0 有十一个 skill、六个 hook，还带着一套自我进化机制。6.0 的主控只有一页纸，每个 skill 只写什么时候用、开始前要满足什么条件、怎样才算完成，再提醒几处模型容易出错的地方，具体怎么做交给模型判断。写的时候，我对照了 Anthropic 和 OpenAI 给新一代模型的提示词指引，只写要求、验收标准和需要提供的证据，不规定操作步骤。模型的推理能力越来越强，很多事已经不需要再逐步交代，写死了反而会限制它。

拷问环节，动手之前把需求问透

先说拷问。这套方法是我做 Atelier 时写进根目录主控里的，6.0 几乎一字没改地沿用了下来，仍然放在主控里，没有拆进 skill。对话太长、上下文被压缩以后，主控文件还在，skill 里的内容就不一定能保留了。而拷问随时都可能用到，除了需求阶段，开发到一半新增功能，也得按这套方法问清楚。

提问按五层漏斗的顺序来。先问为什么做，再问谁在什么时候用，然后问完整流程是什么、最精简的可用流程怎么走，接着确定做多少、不做什么，最后问怎样才算做完。每一层都有相应的方法，包括 JTBD、Mom Test、用户故事地图、Shape Up、Given-When-Then。整体想清楚后，再逐个问功能点，每个功能点都要问清九件事：触发、现状、输入、输出、判断标准、边界、异常、优先级、来源。具体提问时有十二种方式可用，Mom Test、魔鬼代言人、失败预演、费曼复述都在里面。提问也有明确的规矩，每轮只问三到五个问题，「差不多」「你看着办」不算答案。你说「这个我不在乎，你定」，它会给一个默认方案，你确认后就可以继续。每个功能点问完，它还要用自己的话复述一遍，你确认理解没错，才算问清楚。

视镜这次问了九轮

视镜这次一共问了九轮。我先贴过去一段话，说我要做一个网页版的服装 AI 模特摄影工具。它建好产品需求文档，保存我的原话，从中整理出十七条功能，登记为初稿，再把八个没说清的问题记进「待确认」。第一轮它没有谈具体功能，只问为什么做。「上一次你出一款衣服的模特图，是怎么做的？我要具体的那一次，不要一般来说」，这是 Mom Test，只问过去发生过的具体事情。「我来反驳一下，市面上已经有现成的 AI 模特工具……你为什么要自己做一个？」这是魔鬼代言人。「假设三个月后你不再打开这个工具了，最可能的原因是什么？」这是失败预演。

我答完，它先复述了一遍，第一句是「你要的不是一个新的 AI，是一个自己的工作台」。出图这件事，我已经用 Nano Banana Pro 和 GPT Image 解决了，麻烦在于流程太分散，要在几个网站之间来回切换，没法把一款衣服的一组图一口气出完。所以这个工具主要是帮我把流程整合起来，出图质量的上限仍然由底层模型决定。下一轮我又说，出图质量要是不如直接去官网生成，我肯定不用。它就记下一条不能让步的要求：效果不能比官网直出差，批量生成排在第二位。这两句话后来一直是开发的依据。开发计划的第 3 阶段，就要拿它出的图和我在 AI Studio 手动生成的图做对比，质量不低于后者，才能进入下一阶段。

第二轮问到接口，它派探路员去查两个生图模型的接口能力和价格，以官方页面为准，并注明查询日期。查回来的信息直接影响了需求：图像模型没有免费额度；Gemini 的图像接口没有像素级遮罩，局部修改只能靠文字描述，我就把局部修正放到了第二期；接口官方不支持大陆和香港，工具就做成在我自己的电脑上运行。这些信息如果凭记忆回答，很可能已经过时，等开发到一半才发现，就晚了。

查完以后，还有两个问题得在开发前确认：key 有没有开通付费，我人在哪里、怎么访问 AI Studio。那一轮我没答，下一轮它复述完，紧接着就说「有两个挡开发的问题你上一轮没答，这轮必须给我」。这就是提问规则里说的不接受模糊回答。没答的问题它会一直记着，影响开发的就放在最前面。

问清楚要做什么以后，就开始逐个讨论功能。这一段它换了种方式，直接给出每个功能的方案，我只需要确认，或者告诉它哪里要改。拍摄设置只让我选三样：风格、尺寸、张数。一组图按八个镜头的模板来，分别是主图、动态、半身表情、生活化、背面、细节、情绪、备选主图。提交之后由系统自动完成的五件事，也是它提出来的：先让模型看每件衣服，写好服装说明书，再组合出每张图的提示词；接着生成主图，通过检查后再以它为参考，同时生成其余几张，让整组图里的人和衣服保持一致；最后自动检查每张图的五个项目，有硬伤就自动重新生成。首页还需要一个任务列表，这是它从「多款排队」推出来的，它也照实标了一句「你原话里没有」。

九轮问完，一共整理出十八条需求，十七条已确认，局部修正留到第二期。最后一轮我只提了一个要求：结果页一打开，就要把图片以大图的形式排出来，因为这个工具最重要的就是看图。它把「图是主体，大图排列」写进了界面原则，然后用一行文字汇报了进度。

一张需求清单记录六个环节的进度

这一行进度，体现了 6.0 最核心的设计。主控文件只规定产品做完要满足的六件事：需求问清楚了、界面设计好了、开发阶段安排好了、功能做出来了、复核通过了、产品发布了。哪件事还没做，所需的前提又都已满足，就去做哪件事。这些进度都记在产品需求文档的需求清单里，一条需求一行，六列分别是已确认、设计落点、在哪个阶段、已实现、已验证、已发布，对应这六件事。每一格对应的事都做完了，才算完成这条需求。各列记录要完成的环节，每条需求按自己的进度推进。

所以这六个环节不必按固定顺序走。命令行工具没有界面，设计落点那一列填 N/A，就可以跳过。复核发现做错了，去掉「已验证」标记，修好再验证。开发到一半新增功能，先在清单里登记一行，空着的格子就是接下来要做的事。报 bug 时不用新开一行，把对应需求的「已验证」标记去掉，修完再复核。它每做完一件事，就检查一次清单，建议下一步可以做什么，并说明对应哪一格，你也可以另作决定。我一直觉得，只顾着按流程往下走，反而容易漏功能，而且很难说清是在哪一环漏的。现在有没有遗漏，看清单就知道。

需求这一段的体会

需求这一段，用下来我有三点体会。开头那段需求描述尽量写全、写细，它要靠这段话梳理功能、搭好文档框架。你写得越具体，它理解得越准确。我会先让 ChatGPT 或者 Fable 5.1 帮我把想法整理成一段完整的话，再发给它。它问的都是过去发生过的具体事情，比如上一次怎么做的、花了多久、哪里不满意，照实答就行，别把设想说成现状。不懂或者不在乎的，就直接让它定，它会给出默认方案。问到跟产品无关的事，也可以直接打断。这次它问我一周出几次图，我就告诉它这是我自己的事，跟产品无关。

界面设计

另一个我花了很多时间的环节是界面设计。很多人用 Vibe Coding 做出来的界面难看，是因为全凭模型临场发挥，颜色、字号、间距没有统一标准。6.0 的设计环节自带一整套视觉组件，按钮、输入框、表格、卡片、对话框这些基础组件，各种状态都画好了，还配有深浅两套配色。在此基础上，又准备了五类场景的组件包：画布类适合短剧、工作流、设计等工具，剪辑类用于视频、音频和字幕，电商生图类用于商品图和模特图，写作类用于文档和稿件，看板类用于数据报表和监控面板。每个组件包都配了一张样板页，上半部分展示组件，下半部分展示用这些组件搭出的完整页面。

这套组件可以直接用，也可以换。你没有参考样式、没有设计经验，或者想快一点做出来，就用现成组件搭建。你点名某个产品作参考，它会用浏览器打开，查看实际的底色、字号、圆角、投影，再写进设计规范。你自己有更好的设计体系，也可以用自己的，只要保持统一：使用同一套变量和组件，页面上的颜色、字号等都按这套设定来。

动手画之前，它会先问清四件事：你喜欢哪些产品截图，不喜欢哪些设计，有没有现成的品牌素材，以及希望一屏显示更多信息，还是多留些空白。它不会只让你描述风格，如果你说不清楚，就拿两三个真实产品给你挑。你说高级、简洁，它会进一步说清楚留白多少、用几种颜色、圆角多大，再让你确认。视镜这次，它问了三个问题，给出的参考是 Midjourney 那种深灰底、图片铺满的界面，Lightroom 那种右侧有一列参数栏的布局，以及 Notion 那种浅色、留白多的页面。它的默认方案是 A 的底色加 B 的参数栏。我说就按它的默认来，先只做浅色，深色以后再说。我没有品牌素材，最烦的是按钮太多、信息挤成一团、像后台管理系统那样的界面。

接着先做几个方案，只画首屏，不急着做所有页面。两到四个方案只调整布局，配色和文字样式都不变，方便放在一起比较。每个方案用一句话说明设计理由，再用一句话说明取舍，它不会偏袒自己喜欢的那个。视镜给的是同一个结果页的三种排法：双列大图、三列、一行一张。交给我之前，它先自己截图看了一遍，测量留白、检查基线对齐，三份稿子都没有内容超出边界。我选了方向二，顺手把产品名定成了视镜。

方案定下来后，才开始画所有页面，一共 26 页，外加一个目录。每个流程从开始到中间状态、再到结果都要画全，需要输入信息的操作要有对话框，删除操作要有确认提示，首次打开时的空状态也要画。有一条规矩我特别看重：每条已确认的需求都必须体现在设计稿里。没画出来就是遗漏，不能解释成有意不做。一个功能没在设计稿里出现，开发时一定会漏。画完以后，它会在需求清单的「设计落点」一列逐条注明对应哪一页、哪种状态，这次是 17/17。交稿前还必须自查，每页都要截图看一遍，用脚本测量两侧留白、检查页头基线对齐，再到浏览器里检查有没有内容超出边界，确认没有问题才交稿。

这 26 页只画了十几分钟，因为每一页都有现成组件可用。图片网格、参数栏、多选浮动工具栏、灯箱、进度卡都是自带的，它只需要按需求把这些组件组合成页面。设计规范定下来以后，开发只能用规范里的组件和样式，所以做出来的产品跟设计稿几乎一样。

开发计划

需求和设计都定了，接下来安排开发计划。每个阶段都围绕一段完整的使用流程来做，从数据输入到界面显示结果，前后端一起推进。这样每做完一个阶段，就能打开看效果。第 0 阶段固定用来搭建基本框架、创建 git 仓库，它会用一句话给你讲清 git 是什么：commit 是存档点，push 是把存档备份到 GitHub。每个阶段直接沿用需求文档里的 Given-When-Then 作为验收条件，不另写一套。外部服务的 key 还没准备好，就先用固定数据代替，把流程跑通。视镜排了十个阶段，每个阶段都写明完成后能看到什么、依据哪几条需求验收、大概要花多少接口费用。开发和自动化测试都用占位图，只在每个阶段验收时才实际调用接口。

开发

计划确认后，我把模型从 Fable 5.1 切到 Opus 5，让它一次性把所有阶段都开发完，不用每做完一个就来问我。从发出指令到十个阶段的代码全部提交，大约四十分钟。能一口气做完，是因为前面两步做透了：每条需求都有验收条件，每个界面都有设计稿，中途没有多少事需要再问我。开发这个 skill 的规则很少，只提醒模型容易出错的地方。不能做假功能，每个按钮、每个设置项都要接上实际功能；同一个错误修了三次还没解决，就停下来告诉我；测试不能碰我的真实数据。主控里还规定，只有四种事要先问我：发布上线给别人用、删除我的文件或数据、花钱、对外发消息。其他可以撤回的操作，直接做。

复核

开发完还要先复核，才能交给我。每个阶段分别检查功能是否符合要求、质量是否过关。先派一个只读的审查员，对照这个阶段的验收条件检查代码，列出问题，标明文件和行号。质量则按清单逐项检查：功能的名字要和实际行为一致，不能有假功能，错误不能被悄悄忽略，外部输入要有合理限制，测试要能检验实际功能。审完之后，主 Agent 还要用 Claude Code 自带的浏览器，像用户一样把这个阶段的功能操作一遍，最后用三行文字告诉我结果：检查了什么，发现几条问题、修了几条，哪些属于原本的设计或留待以后处理，以及原因。

全部阶段做完，还要从头到尾复核一次，通过后才交给我。视镜这次查出 36 条问题，修了 34 条，1 条确认是原本的设计，1 条留待以后处理。我以前自己做东西，从来不做代码审查，这一步现在全交给它了。主控里还有一句我很喜欢：说「做完了」，必须附上实际运行的结果；没运行过，就说还没验证。

实际出图

开发完，我填好 key，用两套衣服试了实际出图，下面这几张都是视镜的真实界面。新建任务页和拷问时定下来的方案一样：一个任务是一套搭配，最多四件，每件上传一到三张图。模特可以从库里选，也可以当场新建。拍摄只需要选风格、尺寸、张数三样，风格有六个预设，也可以自己写一句，比如「法式慵懒、奶油色调」，系统会展开成完整的风格描述。下面的镜头清单已经按模板排好，每张拍什么都写清楚了。想调整的话，可以展开，逐张修改取景、姿势和表情，也可以自己写一句要求。

给第二套运动装出图时，我新建了一个虚拟模特。拷问时，我说身高、体重、肤色、有没有胡子这些都要能设置，它就把属性表补成了 13 项，每项都有默认值，不改也能直接生成。我选了拉丁裔、健美、肤色很白、短发微卷、浅棕色，大约四十秒就生成了两张定妆图，一个叫 Yuna 的模特就建好了。

提交之后，我就不用再管了。拷问时它复述过的那句「提交之后到出完图之前，你一个字都不用管」，确实做到了。它先生成主图，通过检查后再以主图为参考，同时生成其余几张。打开结果页，看到的就是以大图排列的合格正片。运动装那一组有一张动态图没通过检查，系统自动重新生成了一次，不合格的那张收进废片夹，不占正片的位置。

点开任意一张图，左边是生成的图片，右边是衣服原图，可以对照着看细节。下方可以展开这张图用的提示词，模特参考、服装说明书、风格、镜头要求都在里面。这些内容都是系统在规划拍摄时自动组合的，我一个字没写。下图是韩系春装那一组的 02 动态，提示词第一句就是 Image 1 is the approved hero shot，意思是图一是已经通过检查的主图，人、衣服、色调都以它为准，只改取景、姿势和表情。

回到模特库，Yuna 已经存好了，下次给别的款式出图，直接选她就行。上传参考图、生成虚拟模特、保存模特供以后使用，这三件事都可以在模特库里完成，也是拷问时它提的方案。

第二天新开会话，加一个服装库

第二天我新开了一个会话，想加一个服装库，把常用的衣服提前传进去，建任务时直接从库里选，不用每次重新上传。它认为可以沿用模特库的做法，列出了三处改动：增加服装库页面，新建任务页增加「从服装库选」，任务里刚上传的衣服也能存进库里。另外还有三个默认方案等我确认，不合适的可以改：入库时自动生成服装说明书，从库里选衣服时给当前任务复制一份，库里的衣服不限数量。最后它说明，需求文档要加一条 R-019，开发计划要加第 10 阶段。新增功能也是先登记，再开发。

我确认后，它先写后端，测试通过再写网页。写完以后，它在浏览器里用假图模式把整个流程操作了一遍。上传入库、从库里选衣服建任务、提交出图，都是它自己操作的。最后列出了三条验证结果：新增的自动化测试全部通过，假图模式下的完整流程已经验证，还没用真实的 key 调用接口。没验证的部分，它也照实写了。

我自己上传了三件衣服试了试。入库时，系统会给每件衣服生成说明书，并自动命名。衣服多了以后，页面上方就会出现按品类筛选的选项。新建任务时点「从服装库选」，勾上两件，就能加进当前搭配。提交后，这两件会跳过分析，直接出图。

模型怎么选

模型怎么选，也说两句。拷问和设计我用的是 Fable 5.1，开发切到了 Opus 5。需求和设计阶段要做的判断最多，我会把手上推理能力最强的模型用在这里，开发时再换便宜一点的。用 Codex 的话，我的组合是构思用 GPT-6 Astra Max，开发用 GPT-6 Astra High。不同模型的开发耗时差别很大。这次 Claude Code 的开发部分不到一个小时，之前我用 Codex 测同样的流程，跑了 27 个小时。国产模型也可以用来开发，比如 GLM 5.3，前提是先用强模型把需求和开发计划定清楚。

两点使用经验

用下来还有两点经验。产品需求文档一定要及时更新，后面所有环节都以它为依据。每次新增或调整需求，都要看一眼文档有没有同步。上下文一长，它偶尔会忘记改，这时提醒它一句，或者自己补上。另外，每次加新功能，我都建议新开一个会话。靠三份文档和 memory，新会话就能完整接上之前的工作。上下文干净，模型的状态也最好。

6.0 里有意省掉的东西

如果你也在搭自己的 harness，6.0 里有几样我有意省掉的东西，可以供你参考：harness 自检脚本、过程记录，以及 5.0 那种项目状态路由和自我进化机制。价格、部署方案、库的版本这些经常变化的信息，也没有写死，用到时再派探路员查询。我也没有建立问题库，模型掌握提问方法就够了，具体问什么，要根据当时的情况来判断。另外，提示词里提到的工具、文件和命令，必须真实存在。这是我做 Atelier 时吃过的亏：那次主控让它调用一个根本不存在的审查员，生成的 hook 文件还带着语法错误。

适合谁用，怎么开始

这套 harness 主要面向有想法、但没做过产品的人。技术上的事由它负责，你只需要回答问题和拍板。做过产品的人用起来会更快，很多问题一句话就能确定。它能做网站、桌面软件、手机 App 和命令行工具，具体做哪一种，在拷问时就会定下来。上架、签名、备案涉及的成本和要求，它会提前查清楚告诉你，不会等到发布时才让你发现。如果你希望说一句话就直接拿到成品，那它不太适合你，因为它一定会先问你好几轮。

开始用很简单，把 .claude 文件夹拷进一个空的项目文件夹，再从这里打开 Claude Code，说一句你好。它会先显示 FEICAI 的标志，说明接下来怎么做，然后只问一句：你想做什么。已经有代码、但没有需求文档的老项目也可以用。它会先读代码和 README，把这些内容作为了解项目的依据，再开始拷问。

写在最后

回头看开篇提到的问题，用 Vibe Coding 做产品时漏功能、界面不好看、越改越乱，原因多半在写代码之前就有了。6.0 会先把需求问清楚、把界面定下来，再用一张需求清单记录每条需求的进度，其余的交给模型。模型会继续变强，写代码需要人操心的地方也会越来越少，但要做什么、每条需求是否已经实现，这两件事依然需要有人确认。6.0 就负责像产品经理一样把这些事跟到底。

如果你想了解更多 AI 编程和 Vibe Coding 的方法，或者想了解今天分享的这套 harness，可以来我们的废才俱乐部网站看看：www.feicaiclub.cn。

我会在那里定期分享 AI 编程、AIGC 影视、短剧、漫剧和剧本创作方面的入门与进阶教程。这两年，我在这件事上花了很多时间和精力，希望把这些方法研究透，让每一套教程和方案都更详细、更完善。

也希望这些内容能帮大家更快上手，开始自己的项目，把想做的工具、产品或影视作品做出来。