非技术 PM 的 AI 构建法

作者把这套流程保存成代码库里的可复用 prompt 文件（/commands），用 /命令名 就能随时调用。六个阶段：

1. /create issue（记录问题）：当你正在做别的事、突然想到一个 bug 或功能点，不想打断当前工作，就用这个命令让 Claude 快速追问几个关键问题，把想法整理成 Linear 工单存起来，"不追求马上能开发，只追求'已经可以开始被探索'"。
2. /exploration phase（探索阶段）：真正要开始做这个工单时用。可以带着 Linear 工单号作为参数（如 exploration phase STU88），让 Claude 读工单、读代码库、理解现有实现方式，然后反过来问你一堆关键问题（范围、数据模型、UX/UI、验证方式等）。作者强调"这一步我通常会花很多时间过一遍，这才是区分'纯 vibe coding'和'认真做产品'的分水岭"。
3. /create plan（生成计划）：基于探索阶段的问答，让 Claude 输出一份 markdown 计划文件，包含 TLDR、关键决策、任务拆解和每个任务的状态跟踪字段。这份文件本身会留在代码库里，后续任何 agent 处理相关区域代码时都能读到"这里已经做过什么"。
4. /execute（执行）：针对不同任务特性切换执行模型（如用 Cursor 的 Composer 做简单/前端任务因为极快，用 Gemini 3 做 UI 因为审美好），照着计划文件写代码。
5. /review + peer review（自审 + 交叉评审）：先让写代码的模型自己 /review 一遍；再打开另外的工具（如 Codex、另一个 Cursor 会话）各自独立评审同一份代码；最后用 /peer review 命令，把其他"评审人"的意见喂给主开发模型，要求它不能盲目照单全收，而要么反驳解释为什么不是问题，要么真的修掉。
6. /update docs（更新文档）：功能完成后更新代码库里的说明文档，确保"下次有 agent 要在这块区域写代码时，能读到已经做过什么"，减少未来重复踩坑。