AI 开发创业：先让一个小工具解决真实问题

找一位确实在重复处理问题的人，让他展示最近一次从输入到结果的过程：例如店员从聊天里抄下预约、整理当天排班，或者同事把一批文件复制到不同目录。记录输入来自哪里、哪里需要判断、出现错误怎样补救，以及谁能确认结果正确。这里的观察方法是教学建议，不是已有客户访谈或成交案例。

把首版写成一句带终点的话：不是“做一个商家系统”，而是“顾客提交预约后，店员能确认，双方重新打开仍看到同一条记录”。如果现有表格已经能满足需求，也要说明新工具究竟改善哪一步。用 AI 降低写代码门槛，并不会自动证明有人需要产品；先明确使用者、发生频率与可接受结果，才知道应该把精力投入哪里。

如果参与者主要在微信内完成服务，先看微信小程序报名；如果商家需要一个普通链接承接预约，看商家预约网站。手工粘贴短文字并保存，可以从浏览器便笺扩展练习；文件目录与本机权限占主要工作量，则看桌面文件工具。

Phaser 网页小游戏讨论的是游戏循环与可玩性，不套用表单业务的成功标准。订阅与 API 比较则为以上开发工作选择投入方式，并不单独代表一种产品。下表是任务导航和交付建议，具体平台版本与要求在各任务页保留官方来源和日期，正式发布时还需再次核对。

截至 2026-09-12，本组已有真实生成代码与本地检查记录。便笺扩展实际加载后保存了两条内容，第一条在刷新后保留，空输入不增加记录，所测页面没有运行错误；小程序只通过本地 Page 模拟的空输入、重复姓名和单页两个名额检查。两种证据分别对应不同环境，不能互相补齐缺失项。

预约网站、桌面文件工具和 Phaser 小游戏提供的是独立教学设计与待执行验收；订阅与 API 提供的是固定任务比较协议，没有双路线实测成本结论。读教程时先确认自己要复现哪一层：代码可读、文件存在、环境能运行、业务可用、已经发布、真实用户使用，是逐级增加的证据，不是一句“已完成”可以包含的全部状态。

先让工具读清楚已有目录、运行命令与测试方法，再明确允许改哪些模块。给它一份代表性输入和可观察结果，比堆砌“专业、完整、商业级”更有效。任务不要只写正常流程，还要写失败时哪些状态不能改变：报名失败不占位，复制失败不删除原文件，游戏重开不遗留旧计时器。

下面是交付导向的通用需求单，可结合各任务页的独立提示词细化。每一轮改动后看实际文件、命令退出状态和业务结果。执行被权限、环境或账户条件挡住时，保留阻断记录；不能把手工推理或模拟环境改名为真实运行。新增依赖、联网调用和发布行为，也应符合你预先确认的范围。

开发 Agent 管理上下文、文件修改和命令执行，模型提供推理与代码建议，产品运行程序处理真实用户操作。这三者的职责不同：模型回复了“报名成功”不等于数据库有记录，开发工具执行测试通过也不等于生产已经更新。像本组便笺保存和文件复制这样的任务，开发时可以借助模型，产品运行时仍由确定性代码完成。

需要给开发工具接入模型时，先检查工具官方支持的配置。以 Cline 为例，其官方文档列出 Base URL、API Key 与 Model ID 等配置项，参见 Cline OpenAI Compatible 文档，核对日期 2026-09-12。本站的 Cline 配置、OpenCode 配置提供接入入口，模型和协议以模型目录、接口文档为准；具体文件修改与工具调用能力仍需按实际版本验证。

接开发订单时，把交付功能、支持环境、修订次数和维护期限写进工作单，避免用“整套系统”掩盖双方理解差异。做自己的产品时，先让真实使用者完成一次任务，记录哪里需要帮助、结果能否被采用、下次是否仍愿意使用，再决定收费方式。一次性项目交付与长期订阅承担的支持责任不同，应对应自己的服务能力。

本组教程没有成交额、客户数量或盈利记录。验证收益要使用真实收入和持续成本，验证节省时间要比较同一任务的人工处理与工具处理，并计入纠错与学习时间。某人愿意试用只说明有探索意愿，不等于已经形成付费需求；用户反复使用且愿意为明确价值付费，才有依据讨论商业模式。

开发账本记录模型尝试、人工调试、测试、返工和环境适配；运行账本记录托管、存储、消息服务和客户支持。一次生成代码的费用很小，也不能推出后续经营成本很小。接单时还要预留交接与维护，尤其是浏览器、操作系统、平台环境变化带来的复核工作。

如果产品本身调用模型，按实际通过任务核算全部相关尝试，失败和重试不要从成本里删除，未知账单不当作零。当前单价统一查看价格页，开发方案按订阅与 API 的同任务方法比较。涉及付款时，创建订单、回调、重复通知、入账与退款分别验证，收费页面能打开不是资金流程完成的证据。

验收演示由使用者实际操作：店员确认预约并取消，活动组织者核对名单，便笺用户刷新并回读，文件工具用户取消任务后检查原文件，游戏玩家完成一局并重开。每种产品都有自己的失败路径，不必机械堆叠测试数量，但要覆盖数据会损坏、权限会越界或状态会重复变化的关键边界。

交付材料包括源码版本、配置说明、账户归属、数据保存位置、日志与备份、恢复步骤及维护联系人。部署单独安排授权窗口，先在本地构建测试，再发布已验证产物，发布后检查实际入口。数据格式变化时说明旧版本的读取能力，不能只承诺换回旧程序就一定恢复。最终完成记录应明确哪些功能已验收、哪些仍待执行，以及出了问题由谁响应；让这份记录成为后续维护的起点。