两种骨架：生成式 vs 代理式，先选一个
AI 做产品，骨架就两种：生成答案，还是替你多步做事。选对骨架是第一步。
拿到一个想法，先问一句：你要做的这个产品，核心是「给问题出答案」，还是「替你一步步做事」？骨架选不对，后面再调架构、prompt、模型都没用。vibe coding 想顺，第一步先把骨架选对。
读完你能回答：
- 你现在做的这个产品，到底是哪种骨架？
- 两种骨架在开发、验证、上线上差别在哪？
- 混着用的时候，边界划在哪？
生成式骨架
一句话：用户输入 → 模型生成一段输出 → 用户看输出、做判断。没有副作用，不写状态。
典型例子：
- 问答机器人、写作助手、文案生成、设计稿转代码提示、代码解释器
- 给一段代码，解释它写了什么
- 给一段需求，生成 PRD 或技术方案
- 总结一篇长文章，抽关键词
特点：
- 输入处理完就结束，不会留下状态给下一轮
- 副作用可控：模型生成错了，下一轮重新生成就完了
- 验证简单：输出通顺、不跑题、不 hallucinate，就算成了
- 开发快：你 vibe coding 几分钟就能把骨架搭起来
缺点也很直接：它做不了多步、做不了有状态、做不了依赖外部工具的事。你让一个纯生成式骨架帮你「把仓库里所有 console.log 删掉」，它做不了——它读不到你的文件。
代理式骨架
一句话：用户给目标 → AI 自己拆成多步 → 读文件、调工具、改代码、调用 API → 一步步做到你要的目标。能读能写能改状态。
典型例子：
- Coding Agent：在你仓库里读代码、改文件、跑测试
- 自动化工作流：替你处理 GitHub Issue → 开 PR → 跑 CI → 报告结果 google-patterns
- 数据分析 Agent：读数据库 → 跑查询 → 生成图表 → 写总结
- 项目脚手架：根据你的需求生成整个项目目录结构
特点：
- 能处理复杂任务、能复用已有环境、能读写状态
- AI 自己规划路径，你只需要定目标、验收结果
- 验证复杂：每一步都要验证，最后还要验证整个目标是否达到
- 开发慢：需要工具定义、权限控制、错误重试，骨架本身就要搭一会儿
缺点：简单问题用它，就是杀鸡用牛刀——本来一分钟能出结果，它要十分钟读文件想路径 vibe-report。
怎么选
一个简单判断：用户点一下按钮，要不要改什么东西？
- 不用改 → 生成式
- 要改 → 代理式
比如：
- 用户问「这个 PR 改了什么」→ 生成式（它只是回答你的问题，不改代码）
- 用户点「帮我 review 这个 PR 并提出修改建议」→ 生成式（输出建议，不改代码）
- 用户点「帮我把这个 PR 里 review 提出来的问题都修掉」→ 代理式（它要改代码）
混着用
很多产品本来就是混着用：前端问答用生成式，后台操作用代理式。这没问题，只要边界划清：
- 生成式只管输出内容，不碰状态和副作用
- 代理式管执行，复杂推理可以丢给生成式帮它想
比如一个「帮我 refactor 代码」功能：
- 代理式读文件（副作用：读）
- 生成式分析代码、给出重构方案（无副作用：生成答案）
- 代理式按方案修改文件（副作用：写）
这样分工，各自发挥长处：生成式擅长分析和表达，代理式擅长执行和状态变更。
选好骨架，下一步：AI 真能加分的问题，才值得做，别什么问题都拿来蹭 AI。