首版交付之后的活，才是真正拉开差距的地方
文章目录
- 首版交付之后的活，才是真正拉开差距的地方
- 一、先把口径说清楚，不然数据没有意义
- 1. 对比范围
- 2. 传统模式的计算规则
- 3. 工作量计算公式
- 4. 优先级分层
- 5. 评估局限性
- 7. AI 模式的计算规则
- 4. 成本单价怎么来的
- 9. AI 工具费用怎么计算
- 二、结果先摆出来：这次到底做了多少东西
- 三、传统研发流程和 AI 原生流程，具体差在哪里
- 1. 传统流程是什么样
- 2. AI 原生流程是什么样
- 3. 两种流程逐项对比
- 四、首版闭环之后，真正花时间的是后续关键改进
- 1. 查询性能优化
- 2. 调度稳定性治理
- 3. 契约与兼容性加固
- 4. 布局与页面打磨
- 五、样式和布局不是一回事
- 六、AI 能解决什么，人还要负责什么
- 七、最后的结论
前一篇公众号文章已经写过从零搭起网络监控系统的过程、经验和踩坑。
这一篇不再重复前面的内容，重点只补三件事：
- 这次对比的数据到底怎么算
- AI 为什么能把首版交付拉快、把成本压下来
- 首版闭环之后，真正拉长周期的后续关键改进是什么
一、先把口径说清楚，不然数据没有意义
这篇文章里的所有比较，统一按下面这套规则来算。
1. 对比范围
对比的不是"理想中的完整系统"，也不是所有未来增强项。
对比的是 v1 首版闭环这部分核心范围：
- ICMP / TCP / HTTP GET / HTTP POST 四类探测
- SSL 证书检测和告警
- Dashboard、任务列表、任务详情、告警历史、SSL 看板
- 每周可用性报告
- 登录认证、敏感字段加密和基础安全基线
也就是说，两边比较的是同一套核心范围。
2. 传统模式的计算规则
传统模式数据来 "项目详设核心项 - 工作量评估清单“的核心范围估算。
这份估算把工作量拆成了 10 个维度：
- 功能清单
- 页面清单
- 接口清单
- 数据库设计
- 核心业务流程
- 外部依赖
- 非功能要点
- 安全与权限
- 数据处理
- 部署与迁移
只取核心范围，不取可选增强，最后合并得到：
- 93 人天
- 约 18-20 周日历周期
3. 工作量计算公式
单项工作量 = 数量 × 复杂度系数 总工作量 = Σ(各维度工作量)复杂度系数参考：
| 复杂度 | 系数 | 说明 |
|---|---|---|
| 低 | 0.5 人天 | 简单CRUD、标准组件复用 |
| 中 | 1-1.5 人天 | 中等交互、需要联调 |
| 高 | 2-3 人天 | 复杂逻辑、多系统集成 |
4. 优先级分层
P0（核心）> P1（重要）> P2（增强） ↓ ↓ ↓ 必须做 建议做 可选做 4周排期 +2-4周 按需排期5. 评估局限性
⚠️可能低估的场景：
- 跨模块联调问题
- 性能优化返工
- 第三方接口变更
- 需求变更
⚠️可能高估的场景：
- 组件复用（如弹窗组件）
- 代码生成工具
- 已有封装好的工具函数
7. AI 模式的计算规则
AI 模式不按"理论效率"算，直接按这次项目的实际记录算。
这里统一按下面的口径：
- 时间范围：
2026-03-12 ~ 2026-03-28 - 人力投入：
1 人全程投入 - 首版交付：
16 个日历日 - 人天折算：
16 天 × 1 人 = 16 人天
注意，这里的 16 天指的是首版闭环交付，不把后续持续迭代混进去。
后续为了补性能、稳定性、兼容性和页面质量，提交次数从 54 次继续增加到 105 次，这部分单列描述，不和首版交付混算。
4. 成本单价怎么来的
为了避免岗位单价一会儿一个口径，这次统一用一线城市 SaaS 外包市场的加权均价计算。
加权均价口径：
- 产品：
¥2,000 / 天 - UI：
¥1,800 / 天 - 前端：
¥2,500 / 天 - 后端：
¥3,000 / 天 - 测试：
¥1,800 / 天 - 运维：
¥2,200 / 天 - PM：
¥2,500 / 天
统一折算后，采用：
- ¥2,414 / 人天
这意味着：
传统模式显性成本 = 93 人天 × ¥2,414 = ¥224,502 ≈ ¥224,500 AI 模式人力成本 = 16 人天 × ¥2,414 = ¥38,624数据来源：CSDN《IT外包费用：1000元/天/人，高了还是低了？》（2024）、BOSS 直聘 / 猎聘 2025-2026 招聘薪资反推、SaaS 行业项目外包报价参考。一线城市后端高级岗位实际成交价常达 ¥2,500-3,500/天，此处取中值偏保守。
9. AI 工具费用怎么计算
AI 工具费用这次不按 token 算，也不按"如果放大到全年要花多少"来算。
只按这次交付阶段实际用到的月订阅费用来算。
| 工具 | 用途 | 费用口径 |
|---|---|---|
| GLM-5 Pro | 前后端开发、数据库设计 | ¥149 / 月 |
| GPT-5.4 (Codex) | Bug 排查、代码审查 | 约 ¥145 / 月 |
| Gemini 3.1 Pro (TRAE) | 前端微调、UI 实现 | 约 ¥145 / 月 |
| Kimi-K2.5 | 文档整理、长文本处理 | ¥199 / 月 |
| Figma Professional | 原型设计 | 约 ¥87 / 月 |
| 合计 | ¥725 |
所以 AI 模式的显性总成本按下面的公式算：
AI 模式显性总成本 = 人力成本 ¥38,624 + 工具订阅 ¥725 = ¥39,349二、结果先摆出来：这次到底做了多少东西
到2026-03-28为止，仓库里实际沉淀出来的结果包括：
- 36 个 API 接口
- 8 个核心页面
- 9 张核心表 + 11 个 Alembic 迁移
- 30 个 Vue 组件
- 232 个测试文件
- 首版阶段 54 次提交，后续累计到 105 次提交
这些不是"预计会做"，而是仓库里实际存在的交付结果。
如果把传统模式和这次 AI 辅助首版放在同一张表里看，差异会更清楚：
| 指标 | 传统模式（核心范围估算） | AI 模式（首版实际） | 差异 |
|---|---|---|---|
| 人天投入 | 93 人天 | 16 人天 | 减少 82.8% |
| 日历周期 | 18-20 周 | 16 天 | 从周级压到天级 |
| 显性成本 | ¥224,500 | ¥39,349 | 减少 82.5% |
| 工具结构 | 人工主导，工具辅助 | 人主导判断，AI 接执行 | 分工变化 |
| 交付方式 | 阶段化推进 | 并行推进 | 节奏更紧凑 |
如果再把比例拆开一点看：
效率倍数：
93 / 16 = 5.81
也就是说，按统一人天口径看，这次首版交付效率大约是传统模式核心范围估算的5.8 倍成本倍数：
224,500 / 39,349 = 5.70
显性成本大约压到了传统模式的17.5%AI 工具费用占比：
725 / 39,349 = 1.84%
也就是说，在 AI 模式总成本里，工具订阅只占1.84%，大头仍然是人的时间
这几个数字放在一起，能支持一个比较稳的判断：
AI 辅助开发对前期交付的提效和降本是实打实的，不是概念层面的"好像更快"。
三、传统研发流程和 AI 原生流程，具体差在哪里
说到 AI 辅助开发，讨论很容易只盯着"代码生成快不快"。
但这次项目里，真正拉开差距的，不只是编码速度，而是流程组织方式。
1. 传统流程是什么样
如果按传统方式做，这类项目通常是下面这条链：