Vibe Coder Planner内置免费AI模型GLM 5.3：七步搭建首个项目

AI编程工具正在从「补全代码」转向「管理整个开发流程」。Vibe Coder Planner 的最新更新把这一趋势又推进了一步：Pro 订阅用户现在可以直接使用内置的 GLM 5.3 开发模型，不必再单独申请 API key、配置另一个 AI 服务商账户。

从「提示词堆叠」到「结构化开发流程」

原文点出了一个很多独立开发者熟悉的困境：一开始用 AI 写代码很顺畅，但项目一旦涉及认证、数据库、权限和仪表盘，提示词越写越长，每次对话都在重复之前已经确定过的决策，最后花在「解释项目」上的时间反而超过了「推进项目」本身。再算上多家 AI 服务商的账户注册、API 配置和分别计费，一个本应轻量的小项目变得异常沉重。

Vibe Coder Planner 的思路是把软件开发拆成几个连贯环节：描述想法、拆解任务、准备编码提示词、跟踪执行进度。内置模型的意义在于打通「规划」到「执行」之间那道原本需要外部配置才能跨过的门槛——计划写好之后，同一个产品里就有可用的执行工具。

内置模型改变了什么

最直接的变化是启动成本。据原文说明，Pro 订阅包含 GLM 5.3 的使用权限，用户无需自行生成外部 API key；同时，其他受支持的 AI 服务商仍可作为可选项，用用户自己的密钥接入，费用另计。

这背后的产品逻辑值得注意：它押注的是「先验证想法，再决定投入」的工作方式。对一个副业项目来说，第一个真正需要回答的问题不是架构是否优雅，而是「这个最小工作流能不能跑通」。内置模型降低了回答这个问题的门槛。

七步搭建一个客户门户

原文以一个自由开发者或小型代理商的客户门户为例，演示了完整流程。这个示例可以替换成任何自己的点子。

第一步：注册并描述一个足够小的版本

访问 vibecoderplanner.com 创建账户。免费预览包含一份 AI 生成的项目计划、任务大纲以及前三个任务提示词；内置开发模型需要 Pro 或 Enterprise 订阅。

项目描述要说清两件事：谁用、用来完成什么。原文给出的示例是：用 Laravel 和 Vue 搭建客户门户，客户可登录、提交支持请求、查看自己请求的状态；管理员可查看全部请求、分配状态并回复客户。首个版本只聚焦这些流程，计费、在线聊天和文件上传留到后续版本。

这个描述的价值在于边界清晰——用户、主流程、技术栈、可延后项都写明白了。如果已有代码库，还应该说明现状，例如「登录已实现，新功能应复用现有用户账户」。

第二步：生成计划并先审阅再执行

工具会把描述转成开发任务，附带复杂度评估、模型推荐和任务专属提示词。但原文强调，要以产品负责人的视角读这份计划：它描述的是你想做的应用吗？有没有塞进你没要求的功能？依赖关系是否被正确排序？

客户门户的合理顺序是先搭应用结构，再处理认证与权限，然后建立请求数据模型，最后做客户端和管理端界面。

权限部分尤其值得停下来推敲。「客户能看到请求」这句话漏掉了关键问题：能看到谁的请求？更清晰的写法是：每个客户只能查看自己的请求，管理员可查看全部；即使用户直接通过 URL 打开某条请求，访问限制也必须生效。原文直言，花几分钟澄清这个需求，可以避免后面大得多的返工。

第三步：激活 Pro 使用内置模型

准备用内置模型执行任务时激活 Pro 即可。据原文公布的信息，Pro 当时定价为每月 4.99 美元，包含订阅期内的无限项目规划、全部任务提示词以及 GLM 5.3 模型。用内置模型执行时选择 GLM 5.3，不需要额外生成外部凭证。

第四步：连接 GitHub 并关联仓库

要让 AI 操作项目文件并以 pull request 形式交付改动，需要连接 GitHub：在仪表盘侧边栏打开 AI Integrations，选择 Connect GitHub 完成授权，然后进入项目选择 Link GitHub Repo 并指定仓库。新项目建议使用专用仓库；已有产品则务必在执行任务前确认选对了仓库。

Pull request（PR）是 GitHub 上的代码变更提案机制：开发者从主分支切出特性分支，提交改动后发起 PR，评审者可以逐行查看差异、留评论、要求修改，通过后再合并。把 AI 的产出限制在 PR 里，等于给自动化改动加了一道人工闸门——改动不会直接落到主分支，而是以可审阅、可回滚的形式呈现。

分支保护规则（branch protection）是配套的另一半：仓库管理员可以要求 PR 必须通过 CI 检查或至少一人批准才能合并。原文所说的「任务移入 Completed 会触发合并请求，GitHub 侧的检查依然适用」，指的就是这层约束仍然生效，自动化并不能绕过它。

第五步：从单个定义清晰的任务开始

选择前置条件已就绪的最早任务。客户门户的例子中，如果请求数据模型还没建好，就不该先做管理员仪表盘。

执行前通读任务提示词，确认它描述的成果是可以验证的。比如请求管理任务应说明哪些字段必填、谁可以创建请求、创建后谁可以访问。按原文记录的流程，把配置好的任务从 Backlog 移到 In Progress，代理就会操作关联仓库、创建分支、实现改动并开启 pull request，执行面板会显示进度和变更文件。

第六步：对照原始需求验收

pull request 就绪后，检查改动并实际试用功能。客户门户的验收方法很具体：创建两个测试客户账户，用第一个提交请求，再以第二个登录——它能看到吗？把第一个请求的 URL 粘贴到浏览器会发生什么？然后走一遍正常流程：客户能否提交带必填信息的请求？请求是否出现在管理员列表中？状态更新是否正确显示给客户？

原文提醒，生成出来的界面或一条成功的执行日志，本身都回答不了「功能是否满足需求」。如果验证失败，把失败转成具体的修正指令，例如：「客户 B 可以通过 URL 访问客户 A 的请求。将请求访问限制为所有者或管理员，并补充覆盖未授权访问的测试。」这样下一个任务就拿到了可复现的问题和明确的预期结果。

第七步：完成任务，再往上叠加

审阅和测试通过后完成任务。按文档中的 GitHub 流程，任务移入 Completed 会触发对应 pull request 的合并请求，GitHub 侧要求的检查或评审依然适用——原文提示，应把这个动作当作对代码的批准。

这个示例的第一个有用里程碑很朴素：客户提交请求、代理商回复、客户看到更新。在加入计费、附件、通知或更复杂的仪表盘之前，先让这条链路跑通。到那时，你可以把东西演示给潜在用户，并问出一个更好的问题：「这能帮你管理请求吗？」

工具之外，流程仍是核心

内置模型去掉的是一项配置负担，但原文的立场很明确：工作流的价值仍来自清晰定义工作、执行可控任务、检查实际结果。你决定应用该做什么，计划让工作更易跟进，内置模型只是让你不必先张罗另一个 AI 服务商账户就能开始执行。

对于在笔记里躺了几周的点子，起点就是它最小的有用工作流：描述它、审阅计划、完成第一个任务。

背景补充

GLM 是智谱 AI 推出的大语言模型系列，早期以 ChatGLM 名义开源，后续迭代出面向代码与智能体场景的版本。与通用对话模型相比，代码向模型通常在仓库级上下文理解、多文件改动和工具调用上做过针对性训练。原文中的「5.3」属于该系列的版本标识，具体能力边界应以厂商发布说明为准。

内置模型的另一种常见实现是「平台代管凭证」：用户不接触 API key，调用由平台统一转发并计入订阅额度。这种模式省去了注册、充值和密钥保管，但也意味着模型选择、速率上限和数据处理方式由平台决定，对合规敏感的项目仍需确认数据流向。