接到一家 80 人规模鞋服批发企业的电话，老板开口就问：「我手上有个 80 多万的项目，要把进销存、CRM 和钉钉打通，再叠一层 AI 客服。市面上几家有名气的服务商报过价，少的 60 万、多的 120 万，工期普遍 5 到 7 个月，团队配置 15 到 25 人。你们 5 个人，凭什么说能干？」
这种质疑很正常。过去 20 年，软件行业的潜规则一直是「项目预算 ÷ 8000-15000 元/人天 = 需要多少人天」，再除以工期，反推出团队规模。100 万的项目，按这个公式硬算就是 80-120 人天每个月，需要 15-25 人才"看起来安全"。但这套公式建立在一个静默假设上：每个工程师的产出能力是相对固定的。AI Coding 彻底打破了这个假设。
一、人月神话为什么撑了这么久
软件工程界有个老掉牙的说法叫「人月神话」——多加人不一定能让项目更快，反而可能让沟通成本指数级上涨。但这个说法只解释了「多加人为什么不快」，没回答「为什么过去 100 万项目就是要 15-20 人」。
真实原因是工序切割。一个传统中型定制项目，通常被切成需求调研、UI 设计、前端、后端、测试、实施、运维 7-8 道工序，每道工序需要专人专岗。前端不写后端，后端不调 SQL，测试不动代码，实施不懂业务。每个工序之间靠文档和会议传递信息，光是「需求传到代码」这一段就要经过产品经理、UI、前后端、测试 5 双手。这种流水线模式在工业时代是高效的，因为它降低了对单个人的能力要求，让公司可以批量招 3-5 年经验的中级工程师。
代价是什么？是单个工程师的有效产出非常低。一个典型的后端工程师，一天真正写有效业务代码的时间可能只有 2-3 小时，剩下时间在开会、写文档、对齐接口、等设计稿、修测试用例反馈。这些"协作税"占掉 60-70% 的工时，是项目大规模团队真正的隐形成本。这也是为什么传统软件外包的报价里 30%-40% 其实是沟通成本。
二、AI Coding 改写的 4 个交付环节
AI Coding 不是简单的"写代码更快了"，它重新分配了项目里每个环节的时间结构。
| 交付环节 | 传统方式典型耗时 | AI Coding 后耗时 | 关键变化 |
|---|---|---|---|
| 需求-原型 | 2-3 周（产品+UI） | 3-5 天（PM 直接出可点击原型） | AI 把需求文档直接编译成 Demo |
| 代码生成 | 12-16 周（前后端串行） | 4-6 周（全栈并行） | 模板代码、CRUD、表单组件由 AI 写 |
| 测试 | 3-4 周（手工用例） | 1-2 周（AI 生成回归用例） | 单元测试和接口测试自动覆盖 70%+ |
| 实施维护 | 2-3 周首期 + 长期工单 | 1 周首期 + AI 自助答疑 | 配置文档由 AI 生成并随版本更新 |
需求环节的变化最容易被低估。过去产品经理花两周写出来的 PRD，到了开发手里还要再翻译一遍，途中失真严重。现在 PM 把需求描述给 AI，几小时就能拿到一个可以点击交互的高保真原型，直接拉客户看。客户在原型上勾画修改意见，AI 再迭代——需求和原型在同一个回合里收敛，不再是"先文档、再设计、再开发"的串行接力。
代码生成环节，AI Coding 的真正威力不在于「写一个登录页快」，而在于「把项目里 60-70% 的样板代码（CRUD、表单、列表、权限、日志）变成接近零成本的产出」。开发者把时间留给真正需要思考的部分：业务规则的边界、并发场景的处理、数据一致性、和第三方系统的对接。
三、5 人小团队的真实分工
我们自己的团队就是 5 个人的配置。不是为了省成本硬凑，而是发现这个规模刚好能撑住多线项目并行。
具体怎么分？
- 1 个项目经理：直接和客户对接，写需求、画原型、跑节奏。同时承担一部分 QA 角色，每个 Sprint 结束亲自走完整业务流程。
- 2 个全栈工程师：每人能独立完成一个完整业务模块的前后端。AI Coding 把代码量摊掉之后，全栈不再是"什么都懂一点"，而是"每个领域都能做决策"。
- 1 个 PM 兼 QA 兼实施：在项目中期切换角色，前期帮 PM 梳理需求，中期做集成测试，上线前做客户培训。
- 1 个实施工程师：负责部署、客户现场配置、数据迁移、上线后第一个月驻场。
这 5 个人靠 AI 工具把产出放大 3-5 倍——换句话说，从交付角度看相当于一支 15-25 人的传统团队。但区别不止在产能。5 人小团队的决策链只有 1-2 层，客户提的问题最迟当天晚上就能拿到明确回复。而传统 20 人项目组，客户问个需求要走「客户→销售→项目经理→产品→开发→测试→项目经理→销售→客户」的 9 步链路，光中间环节就能拖一周。
四、AI Coding 没法替代的 3 件事
把 AI Coding 吹得能取代一切的人，要么是在卖工具，要么是没真正交付过项目。AI Coding 至少有 3 件事干不了：
第一是业务理解。鞋服批发的串码逻辑、医疗器械的批号追溯、五金件的工序倒推——这些行业的"潜规则"AI 不会主动告诉你。一个老板在客户现场用方言聊半小时挖出来的"客户其实是这么干的"，是任何提示词都问不出来的。这也是为什么行业纵深远比工具熟练度重要。
第二是客户对话。客户提"这个表加个字段"的时候，他真正想要的可能不是字段而是一张新报表；提"流程审批太慢"的时候，可能根本不是流程问题而是组织问题。这种翻译工作 AI 做不了，必须是有经验的项目经理坐在客户对面慢慢挖。
第三是工程判断。AI 会写代码，但不会判断"这个性能瓶颈未来半年会不会出问题"、"这个架构改了之后会不会拖垮老模块"、"这个第三方接口的限流规则要不要提前加缓存"。这些判断需要工程师有 3-5 年以上的实战积累，AI 只能辅助验证。
五、对甲方的实际意义
5 人 AI 原生团队对甲方意味着什么？三件事：周期缩短、成本下降、迭代加速。
| 维度 | 传统 15-20 人团队 | AI 原生 5 人团队 | 对甲方的实际含义 |
|---|---|---|---|
| 一期交付周期 | 5-7 个月 | 2.5-4 个月 | 上线时间缩半年，业务现金流更早受益 |
| 沟通往返 | 销售→PM→开发，3-5 层 | 直接对接 PM/工程师 | 需求确认从一周变成当天 |
| 修改成本 | 改个表单走 2-3 天流程 | 当天提当天上 | 上线后还能持续打磨 |
| 后期维护 | 重新走采购流程 | 同一个团队持续跟进 | 不会出现"换团队接锅"问题 |
| 单点风险 | 团队大但分工细 | 团队小但密度高 | 不依赖某个人不可替代 |
但要注意，团队规模不是越小越好。如果项目本身是组织级 ERP 替换、或者要做核心交易系统改造，5 个人确实不够看；这类项目的复杂度在于多业务部门并发协调，不只是代码量。这时候反而应该选择有完整 ERP 实施方法论的服务商。
六、尽调 AI 原生团队该看什么
很多甲方第一次面对"5 人团队报 100 万"的时候本能怀疑：人这么少能扛吗？这个怀疑很合理，但用错了尺度。判断 AI 原生团队不能看人头数，要看交付节奏。
具体看 6 件事：
- 核心成员的项目密度：过去 12 个月这 5 个人一共交付了几个项目、什么类型、客户在用没在用？密度高说明节奏稳。
- 代码 review 流程：是不是每个 PR 都过 review？AI 生成代码进生产前有没有人工把关？
- 客户能不能直接联系工程师：能直连说明决策链短；只能走客户经理说明分层重。
- 过往项目的二期续约率：愿意续二期的客户比例越高，说明一期交付质量越扎实。
- 遇到突发 bug 的响应时间：48 小时内能不能定位+给方案？这是真正考验 AI 原生团队工程能力的地方。
- 业务理解的深度：让对方讲 30 分钟你所在行业的痛点，能讲到多深？讲不深的就是用 AI 包装的快餐团队。
附上一份简易尽调清单，照着问完一轮基本能筛掉八成不靠谱的小团队。
七、AI Coding 时代 100 万项目的合理结构
回到甲方最关心的问题：100 万的项目，AI 原生团队应该怎么花、花在哪？
一个相对合理的拆解（基于行业公开人天区间 8000-15000 元/人天）：
| 阶段 | 人天投入 | 占总预算 | 关键交付物 |
|---|---|---|---|
| 需求与原型 | 25-35 人天 | 8%-12% | 可点击高保真原型、PRD、业务规则书 |
| 核心开发 | 90-120 人天 | 35%-45% | 主业务模块、集成接口、数据模型 |
| 测试与集成 | 25-35 人天 | 10%-15% | 自动化用例、性能压测报告、集成联调 |
| 实施部署 | 25-40 人天 | 12%-18% | 数据迁移、培训、上线驻场 |
| 一年维护与小版本 | 包年报价 | 15%-20% | bug 修复、配置调整、季度小迭代 |
| 应急储备 | - | 5%-10% | 用于扩需求或意外集成 |
注意几点：
- 实施工作量不能省。AI 能压缩开发，但客户那边的数据迁移、培训、流程切换不会因为 AI 而变快。这一段通常占预算的 25%-40%，AI 原生团队也省不掉。
- 维护要单独包年算。把维护塞进开发预算里看着便宜，但一年后续费的时候往往会出现争议。合理的做法是开发和维护分开报价、合同写清楚 SLA。
- 应急储备要有。任何项目都会有 5%-10% 的需求是签合同时没想到的，预留这部分比中途撕逼好。
八、什么样的项目适合交给 AI 原生小团队
不是所有项目都适合 5 人 AI 原生团队。最后给一份决策清单，对照着打勾：
- 项目预算在 30 万-150 万之间（再大需要看团队储备深度）
- 业务复杂度集中在 1-2 个核心场景，不是全公司 ERP 大替换
- 甲方有一个能说话算数的对接人，不是"七八个老板各有想法"
- 接受敏捷迭代，不强求"瀑布式一次交付"
- 工期预期 3-6 个月，不是"3 个月必须全部上线"也不是"无限期慢慢做"
- 看重后期持续优化，不是"做完就一锤子买卖"
- 已经评估过标准 SaaS 和定制开发的取舍，确认走定制路线
- 愿意把 AI Agent 接入业务系统去做经营分析、自动化报告这些出结果可衡量的场景
打勾 6 个以上，基本可以放心和 AI 原生小团队聊。打勾 4 个以下，建议再想想是不是真的需要定制开发。
写在最后
软件交付这件事，本质上一直在比拼「单位时间产出有效价值」。过去 20 年靠人海堆，是因为没有别的办法；现在 AI Coding 让小团队也能扛大项目，是因为单个工程师的有效产出被放大了 3-5 倍。但工具的进步不会自动变成交付能力——它需要团队同时具备业务理解、客户沟通、工程判断这三件 AI 替代不了的能力，再叠上 AI 工具的乘数效应。
对甲方来说，AI 原生小团队不是"便宜的选项"，而是"决策链短、迭代快、和你绑定深"的选项。它换来的不是单纯的省钱，而是项目过程中那种"你提的事情明天就能看到效果"的踏实感。这才是 AI Coding 真正改写软件交付的地方：把昂贵的协作税还给了甲方，让定制不再等比例贵。
