AI 产品先写设计，再选模型：Tastemaker、Replit 与岗位变化｜7月29日精选

7 月 29 日的几条高信号推文，把 AI 产品的工作顺序说得很具体：先把需求、页面和核心流程写成可检查的工件，再让模型进入实现；模型本身也开始被当作任务配置来选，而不是一个固定的品牌标签。Peter Yang 用 Tastemaker 展示了前一种流程，Amjad Masad 则把后一种选择直接放进 Replit。

Peter Yang 是 AI 教程与访谈作者。7 月 29 日，他发布了一个 25 分钟教程，介绍自己从问题定义、design.md、Claude Design 原型，到 HTML 规格、核心流程设计和 Claude Code 实现的产品方法，并用 Tastemaker 作为完整案例。他特别提醒，先把需求和设计展开，能减少 AI 过早写代码带来的「slop」。1

同一窗口里，Amjad Masad 说 Replit 正从 Kimi K3 开始提供模型选择，让用户按工作匹配模型和成本；swyx 则把视线移到组织层，认为 AI-native 工程师和能直接带 agent 的 player-coach 正在受益，而传统的「heads of X」管理岗承压。2 3

下面覆盖北京时间 7 月 29 日 00:05 至 7 月 30 日 00:05 的窗口。本篇只讨论已完成详情核对、且能形成清晰事实链的入选原帖；未进入正文的白名单账号，不据此判断其窗口内是否发过值得收录的内容。公司负责人、自媒体作者和投资人的单帖都保留原作者口径，不把个案升级成行业统计。

Peter Yang 这次公开的不是一个提示词，而是一条从想法到产品的工作流。他说自己把过程拆成六步，公开列出的环节包括：定义问题并创建 design.md，在 Claude Design 中做原型，写交互式 HTML spec，设计核心流程，之后再进入构建与迭代。这里的关键变化是，设计文档和 HTML 规格不再只是交付给工程师的说明，它们同时成了后续 agent 可以读取和修改的中间产物。1

他用 Tastemaker 验证这套方法。这个产品把电影、电视剧和电子游戏放在同一个个人资料页里，支持评分、评论、创建列表和发现内容；由于外部接口配额，首发只开放前 100 个 profile。4 这条信息的价值不在产品品类，而在于它给出了一个可复用的验收顺序：先把需求和页面写清楚，再让 Claude Design 帮忙探索界面，最后交给 Claude Code 实现。

Peter Yang 还单独发帖说明，他做 Tastemaker 的目的之一，就是检验能否用 Claude Design 和 Claude Code 把粗略想法变成有用产品；他把 design.md、HTML spec、原型和迭代过程放进了同一支教程。5 这仍然是个人项目和个人方法，不是对这套工具在所有团队里效果的评测，但它把「AI 帮忙做产品」拆成了几个可以逐项检查的文件和阶段。

对产品团队来说，可以直接借用其中一个判断：如果 agent 一上来就开始写代码，团队有没有一份足够具体的需求文件和页面规格，能在第一轮产出后检查它是否走偏？如果没有，问题通常不在于模型还不够强，而在于中间的设计工件没有被建立起来。

Amjad Masad 是 Replit CEO。7 月 28 日，他说 Replit 最近加入了支持 open-weight AI 的阵营，并把这种立场落实到产品里的模型选择功能，首个接入的是 Kimi K3。他给出的判断是，未来应当为不同工作选择合适的模型，并同时考虑成本。2

这条帖子的变化点很明确：用户面对的入口不再只有「使用 Replit 的模型」，而是「这个任务该选哪一个模型」。模型的差异因此被放到了工作流里，和任务类型、价格及结果要求一起考虑。至于选择器具体如何排序、模型覆盖哪些任务，原帖没有展开，不能据此推断 Replit 已经建立了完整的自动路由系统。

在另一条推文里，Masad 用自己的比喻给模型分工：Kimi K3 被称为「四分之一价格的 frontier」，DeepSeek V4 flash 是「低工资的 workhorse」，其余位置留给 GPT 系列和 Anthropic 模型。6 这些标签是他的产品判断，不是独立评测；「四分之一价格」也没有在推文中说明对应哪一款模型、哪种调用方式或哪个价格基准。

把这两条推文和 Peter Yang 的流程放在一起看，产品团队需要管理的对象变多了：需求文件决定任务边界，页面规格决定交付形状，模型选择决定实现成本与能力上限。模型名称本身越来越像配置项，真正需要记录的是它在什么任务上完成了什么结果，以及为此付出了多少调用成本。

swyx 在 7 月 28 日讨论招聘时写道，AI-native individual contributor 和 player-coach 正处于「巨大牛市」，传统的「heads of X」管理岗位则处于「巨大熊市」。他用一个明显带有个人判断色彩的对比来说明趋势：有一年管理 10 个 agent 的经验，可能比管理 10 至 100 个人的十年经验更有价值。3

这不是就业数据，也没有样本、职位统计或招聘平台的验证。它更像是对岗位评价方式的预测：管理范围仍然重要，但如果 agent 成了日常生产单元，能不能把任务拆开、给 agent 设边界、检查结果并持续迭代，会进入对工程和产品负责人的评价标准。

这个判断与本窗口的产品信号是相互衔接的。Peter Yang 展示的是一套个人构建流程，Masad 展示的是把模型选择放到产品里，swyx 讨论的则是掌握这类流程的人会如何被组织定价。三者都没有证明「未来所有团队都要这样工作」，但它们把招聘问题从「会不会用 AI」推进到了「能否把 AI 变成可交付的工作单元」。

Nikunj Kothari 是 FPV Ventures 合伙人。7 月 28 日，他说自己在两周旅行期间把 Claude Code 当作主要界面，回来后又让它对这段使用经历做完整复盘，询问下一次还能怎样改进。7 原帖没有列出具体任务和复盘结果，所以这里只能确认一种使用方式：把 agent 当作持续存在的工作台，而不是只在写代码时打开的工具。

Peter Steinberger 在 7 月 29 日只写了一句「Serving large models is hard」。8 这句话与模型选择、服务成本和运行复杂度有关，但没有上下文，不足以展开成产品判断，先留作后续观察。

今天真正值得带走的，不是哪一家工具的名称，而是三个需要在团队里写下来的问题：需求是否已经变成可检查的文件，模型是否按任务而非品牌被选择，负责 agent 的人是否能把结果验收并继续迭代。当前这些问题仍由个人案例和产品方判断拼出轮廓，距离统一方法还有一段距离。