程序员做 AI 副业，第一单不要做什么

先说结论。

程序员做 AI 副业，第一单最该避开的不是技术难题，而是没有边界的责任：替客户做“一个 AI 平台”、承诺完全自动化、需求未清就报总价、免费咨询到方案完整、把第三方成本和长期维护全包进去。

第一单更适合卖一个可结束的小阶段：流程诊断、原型验证、知识库清理或可审核的自动化。

不要从“大平台”开始

“做一个公司内部 AI 平台”通常同时包含账号、权限、数据接入、知识库、模型调用、工作流、报表和运维。客户说的是一个名词，程序员接到的是多个产品线。

第一单缺少信任、业务知识和交付模板，任何模块都可能扩张。即使做出聊天页面，也很难证明平台产生了什么价值。

更合适的收口是一个部门、一个流程、一个输出，例如客服文档问答的旁路原型，或会议纪要到待办的审核流程。

不要接“先做出来再看”的需求

没有目标用户、真实样本、验收人和使用场景时，开发者会用自己的理解填空。客户看到成品后才开始说真正需求，返工就变成必然。

至少先问清：原来怎么做、谁在做、输入从哪来、输出交给谁、哪些错误不能接受、谁能验收。答不清时，先提供付费诊断，不进入固定价开发。

探索可以收费，也应该有交付物：访谈记录、流程图、风险清单和下一阶段范围。

不要承诺“完全自动化”

AI 输出会受输入质量、模型变化、外部接口和业务规则影响。邮件发送、价格承诺、删除数据、付款和权限变更更不能只凭模型判断执行。

第一单应优先设计草稿、候选标签、异常提醒和人工审批。客户得到的是更短的准备流程，而不是一名虚构的数字员工。

如果客户只接受无人值守，要先说明适用范围、停止条件和风险责任；无法达成一致就不接。

不要在一次报价里包掉所有未知项

数据是否可用、接口是否开放、历史文档是否干净、审批规则是否统一，都会影响工作量。把诊断、原型、生产交付和维护合成一个固定总价，等于让开发者承担所有不确定性。

更稳妥的是分阶段：诊断确认问题；原型验证关键假设；交付补权限、日志、测试和运维；维护处理变化。每阶段单独定义输入、输出、验收和变更方式。

具体金额取决于地区、复杂度和责任范围，本文不提供脱离场景的价格数字。

不要免费咨询到方案已经可以执行

第一次沟通可以帮助双方判断是否匹配，但完整流程梳理、技术路线、风险分析和实施计划已经是专业交付。

可以把免费沟通限制为确认问题、预算级别、决策人和下一步。需要读取材料、访谈多人或画方案时，进入付费诊断。

边界不是冷漠，而是防止双方在未建立责任关系时投入大量时间。

不要忽略第三方费用和数据责任

模型 API、云服务、向量数据库、短信邮件和自动化平台可能持续计费。账号归谁、费用由谁承担、额度如何限制，要写进范围。

客户数据能否发送给第三方模型、日志保存多久、谁有权查看，也不能默认由开发者决定。敏感行业还需要客户自己的法务、安全和合规人员参与。

不要用个人账号长期托管客户生产系统，也不要在代码或日志中留下密钥。

不要把维护写成“永久免费修 Bug”

模型、API、业务规则和数据都会变化。需要区分缺陷修复、需求变更、第三方变化和日常运营。

交付时写清质保范围、响应方式、维护周期、监控责任和超出范围后的计费方式。没有维护安排的 AI 项目，很容易在第一次接口变化后失效。

若客户不需要长期维护，也要交付运行手册、配置位置、日志入口和回退方式。

第一单更适合卖三类小结果

一是流程诊断：输出原流程、问题、候选场景和优先级。二是受控原型：用真实去敏样本验证一个关键输出。三是小型工作流：规则校验、AI 摘要、人工确认和写回。

它们共同特点是能在短周期结束，有明确验收，风险动作可控，也能自然延伸到下一阶段。

反例是客户已有成熟产品团队、明确规格和完善测试，此时可以承接更完整模块。但那不再是典型的“第一单探索”。

还可以在签约前做一次“最坏情况走查”：客户晚交数据怎么办，接口没有权限怎么办，模型达不到预期怎么办，第三方服务停用怎么办。每个问题都对应暂停、缩减范围、改用规则方案或结束项目的条件。

这份走查不是为了罗列免责条款，而是确认双方对不确定性的处理方式一致。客户若要求开发者独自承担所有外部变化，项目即使技术上能做，也可能不是一笔健康的第一单。

用这份清单决定接不接

• 是否能用一句话描述业务流程变化？
• 是否有决策人、使用人和验收人？
• 是否能提供合法、去敏的真实样本？
• 是否明确不做事项和高风险动作？
• 第三方账号、费用和数据责任归谁？
• 需求变化如何确认和计费？
• 项目结束后谁维护、如何回退？

下一步不是马上找客户，而是把自己能稳定交付的一项能力写成服务卡：适合谁、解决哪一步、客户要提供什么、你交付什么、不包含什么。边界越清楚，第一单越有机会成为案例，而不是长期返工。

发生了什么、真正变化与后续观察信号

发生了什么：程序员开始从实现者变成直接面对客户的交付方。真正变化不是多会一个模型 API，而是需要同时承担需求、数据和交付边界的判断。后续观察信号有三项：

1. 信号一：客户补充需求时能否回到书面范围。
2. 信号二：第三方费用与账号是否由约定方承担。
3. 信号三：交付后问题能否区分缺陷、维护和新增需求。

反例是与熟悉伙伴做一次低风险验证，可以简化合同，但数据授权和费用仍要说清。下一步用服务卡模拟一次客户追问，凡是只能回答“到时再看”的部分，都补成前置条件、排除项或单独诊断阶段。