设想一个个人开发仓库，它的GitHub Issue和Pull Request连续编号已经接近四位数。
第一反应很容易变成：
“一个人快做了1000次开发？”
差一点，但不能这样直接换算。GitHub在编号体系里把每个Pull Request都视为一种Issue，同一个仓库中的Issue号和Pull Request号不会重叠。因此，编号接近1000，表示两者共用的连续编号走到了这里，并不表示已经完成了1000个Pull Request。[1]
真正有意思的问题反而在后面：
如果这种规模的修改、检查、修复、发布和运营主要由人类不用AI、靠手工完成，需要多少钱？商业上还能不能成立？
这正是AI时代个人开发很值得算的一笔账。
1. GitHub编号不是健身房的重复次数
仓库编号不是工作量计。
有人一个Pull Request改2000行，有人改一行CSS也开一个Pull Request。Bug、设计记录、功能请求、调查任务等Issue也会占用同一套编号。
所以：
接近1000号，不等于1000个人的工作量。
也不等于：
接近1000个完整功能。
这个数字更像闸机计数器，而不是体重秤。
不过，如果短时间内确实连续积累了大量小改动，它仍然说明一件事：
设计 → 实现 → 验证 → 修复的循环被重复执行了很多次。
计算人工成本时，应该看的是一次实质循环平均花多少时间，而不是只看编号。
2. 每件事看起来很小的时候，最容易低估人工成本
日本一项基于自由职业工程师项目列表的2026年9月报告显示，2026年8月的平均月度项目单价为78.9万日元。[2]
这不是所有工程师的工资，也不是任何具体个人的时薪，只是该市场中项目报价的平均值。
但它可以作为一种替代成本基准：如果购买类似的专业工程能力，大致是什么量级？
按每月160小时简单换算，约为每小时4930日元。
现在假设有 1000个实质性变更单元。注意，这只是计算例子，不等同于GitHub的#1000。
| 每次变更平均时间 | 总时间 | 按160小时/月折算 | 按78.9万日元/月估算 |
|---|---|---|---|
| 15分钟 | 250小时 | 1.56人月 | 约123万日元 |
| 30分钟 | 500小时 | 3.13人月 | 约247万日元 |
| 45分钟 | 750小时 | 4.69人月 | 约370万日元 |
| 1小时 | 1000小时 | 6.25人月 | 约493万日元 |
| 2小时 | 2000小时 | 12.5人月 | 约986万日元 |
| 3小时 | 3000小时 | 18.75人月 | 约1479万日元 |
| 4小时 | 4000小时 | 25人月 | 约1973万日元 |
哪怕每次只要15分钟，1000次也会变成250小时。
“每一件都很轻”不代表“总成本很轻”。
而且小任务也有固定流程：调查、建分支、审核、测试、合并、部署确认、回滚判断。
全部人工做下去，名片很快会变成折叠册：作者、翻译、前端、后端、QA、基础设施、主编，一张塞不下。
3. “我自己做，所以人工费为零”在现金账上可以成立，在经济比较里却是另一回事
一个个人网站每月服务器花1000日元，广告赚5000日元。
现金账上确实盈利4000日元。
但如果站长每月投入50小时，商业比较就需要另一套视角。
至少要分开看：
现金利润 = 收入 − 实际现金支出
劳动调整后利润 = 收入 − 实际现金支出 − 个人工作时间 × 选定的替代时薪
如果本来就是爱好，把自己的时间按0元计算完全合理。没人玩50小时游戏之后说自己产生了50小时人工亏损。
问题只在于：把爱好账直接当成“商业模式很赚钱”的证据。
学习、乐趣、作品感、声誉也是真实回报，只是它们不等于商业利润。
做商业比较时，不能因为没人给自己开工资单，就假装时间不存在。
4. 广告模式往往需要一个比想象中大得多的分母
广告收入可以先用一个简单公式理解：
广告收入 = 页面浏览量 ÷ 1000 × 实际RPM
实际RPM会随国家、设备、广告形式、季节、主题和用户群变化很大。
因此这里不假装存在一个统一市场价，只用几个假设值看数量级。
如果希望只靠广告每月回收78.9万日元：
| 假设的实际RPM | 每月回收78.9万日元所需PV |
|---|---|
| 100日元 | 约789万PV |
| 300日元 | 约263万PV |
| 500日元 | 约158万PV |
| 800日元 | 约99万PV |
这不是对任何具体网站广告收入的预测。
它说明的是：
如果把人工按市场替代成本计价，单靠广告回收成本有时需要非常大的流量。
因此很多人工运营的网站并不只靠广告，而是把联盟营销、商品销售、客户获取、会员、赞助、品牌价值甚至爱好价值放在一起。
5. AI改变的不只是“写文章的速度”
如果把AI价值理解成“30秒写一篇文章”，就漏掉了大部分经济意义。
运营一个Web媒体，真正重的是周边流程：
- 找选题
- 调研
- 写稿
- 核实事实
- 改代码
- 测试
- 多语言化
- 发布
- 检查线上实际结果
- 修复故障
- 分发到社交平台和邮件
- 看数据再改进
完全人工时，流程越多，变动人工成本通常越高。
AI与自动化结合后，前期系统设计可能更贵，但第二篇、第十篇、第一百篇的新增成本有机会下降。
这不只是“作者写快了”。
更接近：
一个人可以拥有一个小型编辑部和开发团队的操作系统。
人类并没有消失。
人类的工作逐渐转向输入、判断、规格、质量标准、异常处理与治理。
从“亲手敲每个东西的人”，变成“工厂设计师兼主编”。
6. AI不是插上就必定提速的魔法氮气
研究结果并不沿着一条直线，这一点很重要。
2023年公开的一项GitHub Copilot对照实验中，在指定的JavaScript HTTP服务器任务上，可以使用AI的一组完成速度比对照组快55.8%。[3]
但METR在2025年的随机对照试验得到相反结果：16名资深开源开发者在自己已经熟悉多年的成熟仓库里解决任务时，允许使用当时的AI工具后，平均反而多花了19%的时间。[4]
METR在2026年2月又说明，后续实验越来越难解释。越来越多开发者不愿参加“禁止使用AI”的条件，多代理并行工作也让实际投入时间更难测量。因此，较新的AI工具可能已经比2025年初带来更大的提速，但新的数据受选择偏差和测量问题影响，不能给出一个非常有把握的精确数字。[5]
所以结论不是：
AI永远快55%。
也不是：
AI会让专家慢19%。
结果取决于任务类型、对代码库的熟悉程度、代理工作流、审核负担、并行方式和测试环境。
AI可以高速制造正确结果；系统设计差的时候，也可以高速制造Bug。
真正该测的是自己的真实流程。
7. 纯手工网站并不会自动输掉
高度自动化的AI系统不保证比手工网站更赚钱。
下面这些场景里，手工可能很合理：
- 每月只发几篇
- 专家本人的文字就是商品
- 一篇文章就能卖出高价值产品或服务
- 不需要多语言和大规模分发
- 更新频率很低
- 制作本身就是兴趣
- 建自动化系统的成本比能省下的人工还高
而自动化更容易发挥价值的场景是：
- 同一流程反复出现
- 支持多个语言
- 内容数量持续增加
- 每次都要做QA、发布和线上验证
- 分发渠道越来越多
- 人类不断重复同一检查
本质上是固定成本与变动成本的竞争。
AI工厂前期贵。 手工工坊每一件贵。
还要记住：就算造出一座极其先进的全自动工厂，如果一个读者都没有，它也不是未来媒体，只是一座非常高科技的仓库。
8. 想看一个“不用AI、纯手工网站”的真实收益，问这几个数字就够了
没必要评价这个人。
如果只是比较运营模式，下面的数据已经很有用：
- 每月站长投入时间
- 每月PV或独立访客
- 月收入和现金支出
- 文章总数和每月新增文章数
- 运营语言数量
- 运营年限和初期建设大致耗时
然后可以算：
现金利润 = 收入 − 现金支出
站长现金回报时薪 = 现金利润 ÷ 站长工作时间
劳动调整后利润 = 现金利润 − 工作时间 × 比较时薪
每篇文章的边际成本 = 新增写作 + 翻译 + QA + 发布 + 分发所需的时间和费用
最后一个指标尤其重要。
过去花过1000小时，没有 现在再发下一篇需要几小时 那么能说明未来的经济性。
9. AI个人开发真正强的不是量，而是可重复
一夜生成大量文件，如今并不是最难的部分。
难的是让系统做到：
- 下次还能执行同一质量标准
- 只重做失败的范围
- 防止重复发布
- 能识别当前版本
- 检查真正上线后的结果
- 某个渠道阻塞时其他工作继续
- 只有必须由人完成的认证才交还给人
- 事后可以追踪发生过什么
这不是简单的生成量。
这是 运营资产。
手工网站也可以通过流程文档、模板、CMS、自动备份和检查清单逐步构建同样的资产。
AI时代的变化在于，一个人现在有机会把这种运营层做得非常深。
10. 结论：比“有没有到1000”更有意思的是“下一个单位多少钱”
Issue和Pull Request的连续编号接近四位数，视觉上确实很夸张。
但它不应该被当作生产力分数。
更值得看的数字是：
人类工作时间 单次变更成本 单篇文章边际成本 发布前返工率 站长每小时产出 相对于收入的劳动调整后利润
手工网站完全可能盈利。
使用AI的网站也完全可能亏损。
但每次都让人手工执行写作、翻译、开发、QA、发布、监控和分发，与先投入成本把这些流程系统化、之后不断降低边际成本，是两条完全不同的成本曲线。
接近1000的编号之所以有趣，不是因为它像一枚勋章。
真正值得看的问题是：
这么多次试错里，有多少最终变成了“下一次不需要人再重复同样动作”的系统？
这才是AI个人开发在经济上最有意思的地方。
参考资料（5条）
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
