如何与开发者合作开发 AI 构建的应用

要与开发者顺利合作，请把代码放在 Git 仓库中，提供一页纸的应用功能与目的说明，并给出范围清晰、带有“完成标准”的具体任务。提前约定好谁修改哪些部分，以免你和 AI 覆盖他们的工作；代码仓库和托管账户要以你的名义开设；机密信息应通过正确的设置来共享，而不是通过消息发送。

很多人先用 AI 做出应用的第一个版本，然后再引入开发者——用于添加支付功能、修复 AI 总是出错的地方、进行安全审查，或在应用成长时接手维护。如果你还在考虑是否要雇用开发者，请参见 雇用开发者还是用 AI 构建。本指南假定你已经做出决定，并希望合作过程顺利。

什么时候值得引入开发者

引入开发者的常见原因：

• AI 在几次清晰的尝试和回滚之后仍然解决不了的问题。
• 风险较高的领域：支付、权限、敏感数据、数据库迁移。
• 上线前或承接更大客户前的安全或代码审查。
• 真实流量到来后的性能问题。
• 增长：应用已经变成一门生意，需要有人为代码负责。

弄清楚是哪一种情况，会影响下面的每一步。

第一步：把代码放到可以共享的地方

开发者通常以 Git 仓库为工作基础。在联系任何人之前：

1. 把项目连接到一个私有的 GitHub（或类似）仓库，或者导出项目。
2. 确保代码和历史记录中没有机密信息。参见 如何妥善保管 API 密钥。
3. 确认项目可以从一份全新的副本运行——让 AI 写出安装步骤。

为即将加入项目的开发者编写一份 README：应用是做什么的、技术栈、如何在本地安装和运行、需要哪些环境变量（只列名称）、目录结构，以及任何脆弱或特别之处。

如果你对 Git 还不熟悉，如何在 AI 构建的应用中使用 Git 讲解了基础知识。

第二步：写一份一页纸的简介

开发者没有参与你和 AI 的聊天过程。请用一页纸把背景交代清楚：

• 应用做什么，为谁服务，有多少人使用。
• 最重要的是什么——绝不能出问题的流程。
• 已知的问题，以及你已经尝试过什么。
• 任务内容，以及你如何判断它已经完成。
• 限制条件：预算、期限，以及他们不应改动的内容。

一个好的“完成标准”应当是可以测试的：“已登录用户可以通过 Stripe Checkout 购买月度套餐，该套餐会显示在其账户页面上，而在客户门户中取消后，套餐会在当前周期结束时降级。”而不是“把支付搞定”。

第三步：安全地授予权限

• 代码： 把他们添加为仓库的协作者。工作开始后，不要再通过压缩包来回传递。
• 构建工具： 如果你的 AI 应用构建工具支持团队成员，就邀请他们加入一个只包含这个项目的工作区。
• 机密信息： 在托管平台的设置中添加，或者通过密码管理器共享。绝不要把密钥粘贴到电子邮件或聊天中。
• 测试账号： 用测试数据创建账号，而不是共享你自己的登录信息。
• 生产数据： 只有在确实需要时才提供，并且只提供必需的部分。

代码仓库、域名和托管账户都要保留在 你的 名下。可以添加人员，但不要把账户交出去。

第四步：约定谁修改什么

最大的摩擦来源，是两方——你和 AI，以及开发者——同时修改同一份代码。选择一种规则：

无论选择哪种方式：每次开始提示的会话前都要拉取最新代码，并且较大的改动应放在分支上，供对方审查。

第五步：以书面形式沟通

• 报告问题时写清步骤、预期结果和实际结果。参见 如何写好一份错误报告。
• 把决策记录在同一个地方：问题跟踪器、共享文档，或拉取请求的评论中。
• 要求他们在每个拉取请求中用通俗的语言解释改动。
• 约定好你们多久沟通一次进度。

第六步：审查他们的工作

你不需要阅读代码就能审查工作。请检查：

• 它是否符合简介中的要求，可以在预览或测试副本上确认。
• 没有其他地方被弄坏——运行你最关键的流程。
• 他们是否解释了 改动了什么以及为什么。
• 代码中没有出现机密信息。

如需更仔细的检查，如何审查 AI 生成的代码 提供了一份检查清单，同样适用于人工编写的代码。你也可以让 AI 构建工具用通俗的语言为你解释开发者的拉取请求。

第七步：明确所有权

• 代码仓库、托管、域名以及第三方账户始终归你所有。
• 在工作开始之前，以书面形式明确他们所编写代码的归属。如有合同问题，请查阅当地法规或咨询顾问。
• 工作结束时，撤销他们的访问权限，并更换他们可能看到过的所有密钥。

示例提示词

开发者在上一次拉取中修改了结账代码。请用通俗的语言解释他们改动了什么，以及应用中是否有其他部分依赖于它。

列出这个应用中最复杂或风险最高的部分，以便我告诉开发者审查时应重点关注哪里。

我会把支付交给开发者。从现在起，不要修改 src/payments 下的任何文件或 /api/billing 路由。如果某项改动需要涉及它们，请告诉我，而不是直接修改。

常见错误

• 没有简介。 开发者需要花费付费的时间去反推你想要的东西。
• 范围模糊，例如“修复所有 bug”或“让它达到可以上线的水平”。
• 双方同时修改，却没有先拉取，结果因冲突而丢失工作。
• 共享自己的登录信息，或把密钥粘贴到聊天里。
• 账户登记在开发者名下，以后很难分开。
• 忘记在工作结束后撤销访问权限 并更换密钥。

检查清单

• 代码位于我名下的私有仓库中，且不包含任何机密信息。
• README 说明了安装步骤；一页纸的简介说明了应用和任务。
• 任务有可测试的完成标准。
• 通过协作者邀请授予访问权限，机密信息通过设置或密码管理器共享。
• 我们约定了谁修改什么，并且我在写提示词之前会先拉取。
• 工作成果按照简介和关键流程进行了审查。
• 所有权已书面明确；工作结束时撤销了访问权限并更换了密钥。

在 Mythex 中与开发者合作

• 邀请他们加入工作区。 所有者可以邀请无限数量的协作者，且没有按席位收费；成员在工作区的项目上工作。建议使用单独的工作区，这样他们只能看到这个项目。已发布应用的积分由工作区所有者承担。参见 邀请。
• GitHub 同步与导出（Pro）。 连接一个仓库进行推送和拉取，或导出项目（不包含机密信息）。参见 GitHub、导出与导入。
• 分享预览链接，可以向没有 Mythex 账户的人展示进行中的工作；完成后请删除该链接。
• 提问模式 可以在不修改代码的前提下回答关于代码的问题，适合用来理解开发者的改动。

如果开发者会在其他地方运行应用，请参见 如何导出并自托管 AI 构建的应用。

常见问题