我是 dtsola，IT解决方案架构师，一人公司实践者。

在过去的职业生涯中，我既经历过大型企业的复杂系统架构设计，也在一人公司的实践中深度使用AI工具提升开发效率。这种双重视角让我对"AI辅助开发"有着独特的理解——我既看到了AI带来的巨大生产力提升，也深刻体会到从"能跑的代码"到"生产级系统"之间的鸿沟。

这篇文章源于两篇让我深有共鸣的文章：

• 《The New Calculus of AI-based Coding》（Joe Mag，Amazon工程师的实践）
• 《AI can code, but it can't build software》（Bytesauna的观察）

作为解决方案架构师，我在为客户设计系统时，越来越多地遇到这样的场景：

• 客户展示一个AI生成的原型："你看，功能都实现了！"
• 我审查代码后："这需要重构才能上生产环境。"
• 客户困惑："为什么能跑的代码不能直接用？"

作为一人公司实践者，我自己也大量使用AI工具（Cursor、GitHub Copilot、Claude等）来加速开发。我的个人项目中，约60-70%的代码由AI生成。但我发现，真正耗时的不是写代码，而是：

• 设计系统架构
• 处理边界情况
• 确保长期可维护性
• 集成各个模块
• 建立测试和部署流程

这两篇文章从不同角度验证了我的观察，促使我结合自身经验，系统性地思考这个问题。

目标读者

• 🎯 正在使用AI辅助开发的工程师
• 🎯 有AI生成原型但不知如何产品化的创业者
• 🎯 试图理解AI对软件工程影响的技术管理者
• 🎯 一人公司/独立开发者

核心问题

1. AI在软件开发中到底能做什么、不能做什么？
2. 为什么"能跑的demo"和"生产级产品"之间有巨大鸿沟？
3. 作为架构师/工程师，我们的价值在哪里？
4. 如何正确地利用AI提升真正的生产力？

---

目录

• 一、两个平行的信号

• • 1.1 信号A：技术联合创始人的需求激增
  • 1.2 信号B：10倍速团队的系统性困境
  • 1.3 核心论点

• 二、AI确实会编码

• • 2.1 编码能力的实质性突破
  • 2.2 AI擅长的编码场景
  • 2.3 古老智慧的验证

• 三、从Demo到产品：不可逾越的鸿沟

• • 3.1 "生产就绪"的残酷真相
  • 3.2 软件工程的本质：复杂度管理
  • 3.3 10倍速度的系统性风险

• 四、软件工程的多维挑战

• • 4.1 第一维：质量保障体系
  • 4.2 第二维：工程基础设施
  • 4.3 第三维：架构设计与决策
  • 4.4 第四维：团队协作与沟通

• 五、为什么AI（暂时）不会做软件

• • 5.1 问题的本质属性
  • 5.2 编码 vs 软件工程的本质区别
  • 5.3 高速开发暴露的真相

• 六、当前状态定位

• • 6.1 AI能力的清晰边界
  • 6.2 能力图谱
  • 6.3 客户常见的误解

• 七、真正的机会

• • 7.1 不是替代，是赋能
  • 7.2 以前"太贵"的实践现在可行
  • 7.3 用AI构建支撑AI的基础设施
  • 7.4 范式转变

• 八、结论：拥抱人机协作的新时代

---

一、两个平行的信号

1.1 信号A：技术联合创始人的需求激增

来自Bytesauna的观察：

最近，越来越多的人在寻找技术联合创始人或CTO。这些请求大多遵循一个模式："嘿，我有这个用AI编写的应用，你能帮我让它生产就绪吗？"

这些人通常有一个共同的画像：他们了解自己的业务，但一直缺乏将想法变为现实的技术技能——可能是法律顾问，也可能是客户经理。

这引发了一个关键问题：如果软件工程已经被AI自动化了，为什么还有人在寻找技术联合创始人？

我的类似经历：

作为解决方案架构师，我最近收到的咨询中，约30%是这类请求：

• "我用Cursor做了个SaaS原型，能帮我评估一下吗？"
• "这个AI生成的系统，上线需要改什么？"
• "为什么我的应用在本地跑得好好的，部署就出问题？"

每次收到这样的请求，我都能感受到提问者的困惑：他们认为自己已经完成了大部分工作，只需要"最后一公里"的帮助。但当我审查代码后，往往发现需要的不是"最后一公里"，而是重新规划整个旅程。

1.2 信号B：10倍速团队的系统性困境

来自Joe Mag的实践（Amazon Bedrock团队）：

在过去三个月里，Joe和他的团队一直在Amazon Bedrock内构建一些很酷的东西。他们团队的独特之处在于——大部分代码是由AI代理（如Amazon Q或Kiro）编写的。

但他们不是在"vibe coding"（随意让AI写代码）。相反，他们使用一种人类和AI代理协作生成代码变更的方法。每个提交都有工程师的名字，该工程师需要审查并为代码负责。

成就令人瞩目：

• 约80%的代码由AI生成
• 团队产出是典型高速团队的10倍
• Joe个人的编码吞吐量达到职业生涯的最高点

但困境也随之而来：

• 质量保障：以前一年一两次的生产事故，现在可能每周都会发生
• CI/CD瓶颈：传统pipeline需要几小时构建测试，但一次构建期间就产生几十个新commit
• 团队协作：决策频率提升10倍，沟通成为主要瓶颈

Joe意识到：在高速驾驶时，你需要大量下压力来保持赛车在赛道上。

我的一人公司实践：

我的经历与Joe的观察高度一致：

• 个人项目中60-70%的代码由AI生成
• 开发速度确实提升了3-5倍
• 但我发现真正耗时的是：

• • 架构设计和模块集成
  • AI生成的代码需要大量审查和重构
  • 测试和部署流程反而变得更重要

1.3 核心论点

两个信号 + 我的实践 → 同一个真相：

AI会编码，但还不会做软件

这不是对AI能力的贬低，而是对软件工程本质的重新认识。AI在编码层面的能力已经达到了令人印象深刻的水平，但从"能跑的代码"到"生产级软件系统"之间，仍然存在着一道需要人类跨越的鸿沟。

---

二、AI确实会编码

在深入探讨AI的局限之前，我们必须首先承认：AI在编码方面的能力是真实的、强大的，并且正在改变我们的工作方式。

2.1 编码能力的实质性突破

数据支撑：

• Joe的团队：80%代码AI生成，10倍产出
• 我的实践：60-70%代码AI生成，3-5倍速度提升
• 行业趋势：GitHub Copilot用户平均提升55%生产力

这些数字不是营销噱头，而是实实在在的生产力提升。

技术协同的关键：

Joe的团队使用Rust，我主要使用TypeScript。我们都发现了一个共同点：强类型语言的编译器为AI提供了快速反馈循环。

• Rust编译器 + AI：Rust编译器以关注正确性和安全性著称，在编译时捕获许多问题，并提供有用的错误消息帮助AI迭代
• TypeScript + AI：类型系统为AI提供了明确的约束，减少了运行时错误

这种协同效应让AI能够快速迭代修正错误，而不是陷入无休止的试错循环。

2.2 AI擅长的编码场景

从我的实践来看，AI在以下场景表现优异：

✅ AI的舒适区：

• CRUD操作和标准业务逻辑：创建、读取、更新、删除的标准模式
• 数据转换和格式化：JSON解析、数据映射、格式转换
• 重复性的样板代码：配置文件、接口定义、数据模型
• 标准算法实现：排序、搜索、常见数据结构操作
• 测试用例生成：基于函数签名生成单元测试
• 文档和注释：根据代码生成说明文档

工作流（Joe的方法，我深度认同）：

1. 人类：分解任务到清晰的子问题
2. AI：生成代码
3. 人类：审查每一行，确保质量
4. 迭代：人机协作优化
5. 原则：每一行代码都有工程师署名和负责

这不是"vibe coding"（随意让AI写代码然后直接使用），而是"agentic coding"（人机协作的工程化方法）。区别在于责任和质量把控。

2.3 古老智慧的验证

软件工程界有一句古老的智慧：

"Coding is easy, software engineering is hard"

AI的出现，以一种意想不到的方式验证了这句话。

重新定义：

• 编码（Coding）：写出能工作的代码，解决特定的、孤立的问题
• 软件工程（Software Engineering）：让代码可集成、可扩展、可长期维护，管理系统整体复杂度

AI的位置：

• AI已经能很好地完成"编码"——它能快速生成语法正确、逻辑清晰的代码
• 但"软件工程"仍然需要人类——需要权衡、决策、全局视角和长期思考

这就像说"会拧螺丝"和"会造汽车"的区别。AI现在非常擅长"拧螺丝"，但"造汽车"需要的是系统性工程能力。

---

三、从Demo到产品：不可逾越的鸿沟

3.1 "生产就绪"的残酷真相

Bytesauna的关键洞察：

"当你看到这些人发来的代码，你会意识到'让应用生产就绪'实际上意味着推倒重来。"

这句话道出了一个残酷的现实。作为架构师，我每次收到AI生成的代码进行评审时，都会发现类似的问题：

我作为架构师的评审经验：

问题类型	具体表现	生产风险
错误处理	只处理happy path，没有try-catch	边界情况导致系统崩溃
安全性	没有输入验证、存在SQL注入风险	数据泄露、被攻击
性能	N+1查询、内存泄漏、没有缓存	高负载下系统不可用
可观测性	没有日志、监控、告警	问题无法定位和诊断
可扩展性	硬编码配置、紧耦合	无法应对需求变化
测试	没有或很少测试	回归风险高，不敢重构
部署	只能本地运行，没有环境配置	无法自动化部署

对比：

• ✅ AI能做：展示一个功能（demo）——在理想条件下运行的代码
• ❌ AI不能：以支持集成、扩展和长期维护的方式构建功能（产品）

这就是为什么"让应用生产就绪"往往意味着"推倒重来"。不是因为AI写的代码完全没用，而是因为它缺少了生产系统所需的所有"非功能性"部分——而这些部分往往占据了80%的工作量。

3.2 软件工程的本质：复杂度管理

Bytesauna的核心定义：

"普通生产软件只做一堆简单的事，挑战在于同时做几百件简单的事，并保持整体可维护。"

这句话精准地抓住了软件工程的本质。软件工程师的真正工作不是解决一个难题，而是处理复杂度。

我的架构师视角——复杂度的四个维度：

3.2.1 空间复杂度（系统的广度）

• 多个模块如何集成？
• 不同服务如何协调？
• 如何保证数据一致性？
• API契约如何管理？

3.2.2 时间复杂度（系统的演进）

• 代码如何长期可维护？
• 技术债务如何管理？
• 如何保持向后兼容？
• 如何平滑升级？

3.2.3 不确定性复杂度（边界情况）

• 网络故障怎么办？
• 并发冲突如何处理？
• 数据损坏如何恢复？
• 第三方服务不可用怎么办？

3.2.4 人的复杂度（团队协作）

• 代码如何让他人理解？
• 知识如何传递？
• 决策如何记录？
• 团队规范如何统一？

AI能力分析：

复杂度维度	AI能力	说明
局部正确性	✅ 擅长	单个函数逻辑清晰
全局一致性	⚠️ 需要约束	需要steering rules指导
时间维度	❌ 难以预见	无法预测长期可维护性
不确定性	❌ 处理不足	边界情况和异常考虑不周
人的因素	❌ 无法理解	不理解团队协作和知识传递

AI在局部正确性上表现优异，但在其他四个维度上都力不从心。这就是为什么AI能写出"能跑的代码"，但写不出"生产级软件"。

3.3 10倍速度的系统性风险

Joe的数学关系：

如果你的代码速度提升10倍，会发生什么？

• 代码速度 ×10 → 决策频率 ×10
• 如果bug概率不变 → 生产事故频率 ×10
• 结论：需要质量保障能力 ×10

这不是理论推测，而是Joe团队的实际经验。他们发现，即使AI生成的代码经过人类审查，bug的绝对概率可能不会显著改变，但由于提交频率大幅增加，生产事故的频率也会相应增加。

我的一人公司经验：

我的数据与Joe的观察一致：

• 开发速度提升了3-5倍
• 但调试和重构时间也相应增加
• 需要更严格的代码审查流程
• 需要更完善的测试覆盖

三个生动的比喻：

比喻1：开200mph的赛车（Joe）

"开200mph，你需要大量下压力来保持赛车在赛道上！"

高速不是问题，问题是你的车是否有足够的下压力、足够好的轮胎、足够强的刹车来支撑这个速度。

比喻2：老车装涡轮（Joe）

"就像给老车装涡轮增压器，如果不升级轮胎和刹车，结果不是更快，而是车毁人亡。"

AI就像涡轮增压器，能让你的引擎输出更大功率。但如果你的其他系统（测试、部署、监控）还停留在原来的水平，结果不是更快交付，而是更快崩溃。

比喻3：骑共享单车 vs 开F1（我的比喻）

AI编码就像是从骑共享单车升级到开F1赛车：

• 速度确实快了10倍
• 但如果你还用骑车的心态（随意转向、突然刹车），必然翻车
• 你需要配套的：专业赛道、安全装备、维修团队、应急预案

这三个比喻都指向同一个真相：速度的提升必须伴随着整个系统的升级，否则速度本身就成了风险。

---

四、软件工程的多维挑战

当代码速度提升10倍后，软件工程的哪些维度会成为瓶颈？Joe的团队和我的实践都指向了四个关键维度。

4.1 第一维：质量保障体系

4.1.1 问题

Joe的观察：

• 原状：偶尔的bug，一年一两次生产事故，团队可以接受
• 10倍速：每周都可能出现生产事故，即使在测试环境被发现，也会影响共享代码库，需要调查，拖慢整个团队

我的实践：

• AI生成的代码往往只覆盖happy path（理想路径）
• 边界情况、异常处理常常缺失
• 需要人工补充大量防御性代码

Joe得出结论：为了让agentic开发将工程速度提高一个数量级，我们需要将有问题的提交概率降低一个数量级。

4.1.2 解决思路：借鉴飞机制造业

Joe的启发：

Joe是个飞机迷，他一直很欣赏飞机制造商使用的测试理念：

• 早期模拟
• 组件测试
• 风洞测试
• 破坏性测试
• 完整飞机的试飞

这些理念在软件行业也有尝试，但远未普及。

软件类比："风洞式"全系统测试

Joe的团队实现了"风洞式"测试：测试完全组装的系统在受控环境中的表现。

我的架构师方法——AI时代的测试金字塔：

测试金字塔（AI时代版）
         /\
        /E2E\        ← AI辅助生成场景测试
       /集成测\      ← AI生成fake依赖
      /组件测试\     ← AI快速生成测试用例
     /单元测试  \    ← AI生成基础覆盖
    /___________\
    
    人类负责：测试策略、关键场景、边界情况

关键变化：

• 以前：测试金字塔的每一层都需要人工编写，成本高昂
• 现在：AI可以快速生成大量测试用例，人类专注于测试策略和关键场景

4.1.3 实践案例

Joe的团队：

• 实现了外部依赖的高保真"fake"版本（认证、存储、链复制、推理引擎）
• 编写了测试harness，使用这些fake在开发者机器上启动整个分布式系统
• 构建时测试针对完全组装的堆栈启动canary，验证整个系统
• 成本变化：几年前，这样的想法会被认为"不错，但太贵"。这次，只用了几天就实现了

我的一人公司实践：

• 用AI生成API mock和测试数据
• 用AI编写集成测试脚本
• 用AI生成负载测试场景
• 关键：测试策略和关键场景由我设计，AI负责实现

Joe对这种方法非常看好，因为它能捕获一类以前只能在变更提交到测试环境后才能发现的bug。

4.2 第二维：工程基础设施

4.2.1 问题：CI/CD成为瓶颈

Joe的场景：

软件团队的CI/CD pipeline通常需要几个小时来构建、打包和测试软件变更，然后需要几天时间在预生产阶段和最终生产阶段推出一批变更。通常，拥有这种自动化水平的团队会被认为是健康的团队。

但agentic coding改变了这种动态：

• 在构建、打包和测试一组提交所需的时间内，可能又有十几个提交在等待
• 当一个变更集准备部署到生产环境时，它可能包含100个或更多提交
• 如果其中一个提交有问题，部署需要回滚，pipeline停摆
• 与此同时，更多变更积累，增加了混乱和风险

我的一人公司挑战：

作为一人公司，我没有专职DevOps团队，但AI让我能快速搭建CI/CD。关键是设计合理的流程，而不是手工操作。

4.2.2 比喻：F1黄旗

Joe的比喻：

"我是F1粉丝，这让我想起赛道上的事故如何导致黄旗。通常，赛车以极快的速度和加速度在赛道上疾驰。但如果发生事故，赛事干事会举起黄旗，要求所有赛车在安全车后面减速。激动人心的比赛变成悠闲的绕圈，直到清理完碎片，赛道再次安全。为了最小化这种减速，赛事组织者会为各种事故做好准备，确保他们能在几分钟内清理赛道并重新开始比赛。"

类比软件开发：

• 正常：高速提交代码，快速迭代
• 问题commit：黄旗，整个团队（或个人）必须减速
• 需要：像F1那样，分钟级清理赛道，而不是小时级

4.2.3 解决方向

Joe的要求：

就像全系统本地测试有助于收紧某些bug的反馈循环一样，我们需要类似地思考如何实现CI/CD pipeline。

当团队以每小时几十个提交的速度移动时：

• 需要在分钟而不是小时或天内识别、隔离和回滚有问题的问题
• 这意味着典型的构建和测试基础设施需要比今天快一个数量级

反馈循环的重要性：

"就像高延迟的在线视频游戏变得无法玩一样，如果每个提交仍然需要很长的延迟才能看到反馈，那么以10倍的速度移动真的很难。"

我的一人公司方案：

• 用GitHub Actions + AI生成workflow
• 增量构建和测试（只测试变更部分）
• 自动回滚机制
• 关键：架构设计要支持快速反馈

• • 模块化设计
  • 独立部署单元
  • 特性开关（feature flags）

4.3 第三维：架构设计与决策

4.3.1 问题：架构决策无法自动化

Joe的观察：

当你的吞吐量增加一个数量级时，你不仅仅是在写更多代码——你在做更多决策：

• 应该使用这个缓存策略还是那个？
• 应该如何处理这个边界情况？
• 这里正确的抽象是什么？

决策频率的变化：

• 正常速度：团队可能每周做一两个这样的决策
• 10倍速度：每天做多个决策

决策类型（AI无法自动化）：

• 缓存策略选择（Redis vs Memcached vs CDN）
• 边界情况处理方式（重试 vs 降级 vs 熔断）
• 抽象层设计（何时抽象，何时具体）
• 性能与可读性权衡
• 技术栈选择

我的架构师经验：

这些决策需要考虑：

• 业务上下文：这个功能对业务有多重要？
• 团队能力：团队熟悉哪些技术？
• 长期演进：这个决策会如何影响未来6个月、1年的开发？
• 成本约束：预算是多少？
• 风险承受度：能接受多大的风险？

AI的局限：

• AI可以列出选项
• AI可以解释pros/cons
• 但AI无法根据具体情况做出最优决策
• 因为这需要权衡，而权衡需要价值判断

4.3.2 架构决策的连锁反应

Joe的例子：

"许多这些决策会影响其他人正在做的事情。工程师A决定重构认证流程，这会影响工程师B即将扩展的API。这些不仅仅是实现细节——它们是在代码库中产生涟漪的架构选择。"

我的架构师视角：

一个看似局部的决策，可能影响：

• 系统性能特征
• 安全边界
• 部署复杂度
• 运维成本
• 团队学习曲线
• 未来扩展性

案例：选择数据库

决策：用PostgreSQL还是MongoDB？

表面上：技术选型

实际影响：
  - 数据模型设计（关系型 vs 文档型）
  - 查询性能特征（JOIN vs 嵌套文档）
  - 事务保证（ACID vs 最终一致性）
  - 运维复杂度（备份、恢复、扩展）
  - 团队技能要求（SQL vs NoSQL）
  - 未来扩展性（垂直 vs 水平扩展）
  - 成本结构（开源 vs 托管服务）

AI可以生成两种数据库的代码，但无法做这个决策。因为这个决策需要权衡多个相互冲突的目标，而权重取决于业务上下文。

4.3.3 解决方案：架构决策记录（ADR）

我的实践：

我使用架构决策记录（Architecture Decision Records, ADR）来管理这些决策：

• 用AI辅助编写ADR文档
• 但决策本身由人类做出

ADR包括：

• 上下文：为什么需要做这个决策？
• 决策：我们决定做什么？
• 理由：为什么这样决定？
• 后果：这个决策会带来什么影响？
• 替代方案：我们考虑过哪些其他选项？

好处：

• 知识传递（对未来的自己或团队成员）
• 决策可追溯（为什么当时这样决定？）
• 避免重复讨论（已经讨论过并记录了）

4.4 第四维：团队协作与沟通

4.4.1 问题：协调成本的数学

Joe的关键洞察：

"挑战在于，许多这些决策会影响其他人正在做的事情。传统的协调机制在这里引入了太多延迟。等待Slack回复或安排当天晚些时候的快速同步，意味着要么创建瓶颈——决策阻塞进度——要么冒着在意识到冲突之前走错路的风险。在高吞吐量下，协调成本可能占主导地位！"

协调需求：

• 架构决策的对齐
• 代码风格的一致性
• API契约的协商
• 技术债务的优先级

4.4.2 比喻：餐厅后厨

Joe的比喻：

"我喜欢观察运营良好的操作。如果你曾经窥视过繁忙餐厅的后台，乍一看你可能会认为那是混乱。但如果你花点时间注意细节，你会看到所有成员都在不断地相互协调。厨师、厨师、服务员、清洁工和经理在持续的流中来回传递信息。通过保持持续同步，运营良好的餐厅即使在高峰时段也能为顾客提供服务，而不会牺牲质量或延迟。"

软件开发的类比：

• 厨师长 = 架构师
• 各个岗位 = 不同模块的负责人
• 持续沟通 = 代码审查、设计讨论、站会

4.4.3 Joe的团队方案

高速协调的解决方案：

Joe认为，实现类似的速度提升需要对团队沟通方式进行约束：

"我们的团队坐在同一层楼，我认为这对我们的速度至关重要。当有人需要做出可能影响其他人的决策时，他们可以走过去，在白板前几分钟内解决。我们就方法达成一致，实时讨论权衡，两位工程师都回去工作。决策快速、正确地做出，不会造成阻塞工作的堆积。"

未解决的挑战：

"我认识到这并不能解决分布式团队的问题——这仍然是一个开放的挑战。"

4.4.4 我的一人公司优势与挑战

优势：

• ✅ 没有沟通成本（只有我一个人）
• ✅ 决策速度快（不需要对齐）
• ✅ 上下文切换成本低（都在我脑子里）

挑战：

• ❌ 缺少代码审查（需要自我审查）
• ❌ 容易陷入局部最优（缺少外部视角）
• ❌ 知识孤岛（只有我知道）
• ❌ 精力有限（一个人要做所有决策）

我的解决方案：

• 用AI作为"橡皮鸭"（rubber duck debugging）——向AI解释问题，帮助自己理清思路
• 定期重构和代码审查（自我审查，但要严格）
• 完善的文档和ADR（对未来的自己负责）
• 加入技术社区，获取外部视角（参加meetup、在线讨论）

---

五、为什么AI（暂时）不会做软件

5.1 问题的本质属性

Bytesauna的思考：

"我不太清楚为什么AI不能构建软件（目前）。也许这与工作的本质有关。当你为生活编写软件时，你的主要任务是处理复杂度。普通生产软件只做一堆简单的事。挑战是同时做几百件简单的事，并保持整体可维护。"

我的架构师分析：

软件工程的本质是在约束下做权衡：

• 性能 vs 可读性
• 灵活性 vs 简单性
• 快速交付 vs 长期可维护
• 成本 vs 质量
• 创新 vs 稳定

AI的局限：

• AI可以优化单一目标（比如"让这段代码更快"）
• 但软件工程往往需要多目标优化（快、可读、可维护、低成本）
• 而且目标的权重取决于业务上下文（创业公司 vs 大企业，核心系统 vs 辅助工具）
• 这需要价值判断，而不只是技术判断

举个例子：

场景：优化一个查询

AI可能建议：
- 添加索引（提升性能）
- 使用缓存（提升性能）
- 数据库分片（提升性能）

但人类需要权衡：
- 添加索引 → 写入变慢，存储增加
- 使用缓存 → 一致性问题，复杂度增加
- 数据库分片 → 运维复杂度大幅增加

正确答案取决于：
- 这个查询有多重要？
- 当前的瓶颈在哪里？
- 团队能维护多复杂的系统？
- 预算是多少？

AI可以给出选项，但无法做出权衡。

5.2 编码 vs 软件工程的本质区别

5.2.1 编码（AI擅长）

• ✅ 孤立的问题
• ✅ 定义明确的需求
• ✅ 局部正确性
• ✅ 短期可用性
• ✅ 单一优化目标

例子：

• "写一个函数，计算两个日期之间的天数"
• "实现一个用户登录接口"
• "生成一个数据转换脚本"

这些都是AI的舒适区。

5.2.2 软件工程（AI力不从心）

• ❌ 数百个相互依赖的决策
• ❌ 模糊的、演进的需求
• ❌ 全局一致性
• ❌ 长期演进能力
• ❌ 多目标权衡
• ❌ 意外交互的管理
• ❌ 业务上下文理解

例子：

• "设计一个能支持未来3年业务增长的用户系统"
• "重构这个模块，让它更容易扩展，但不要破坏现有功能"
• "在性能、成本和开发速度之间找到平衡"

这些是AI的困难区。

5.2.3 我的实践验证

AI生成代码的特点：

优点：
  ✅ 语法正确
  ✅ 逻辑清晰
  ✅ 运行快速
  
缺点：
  ❌ 缺少错误处理
  ❌ 没有考虑边界情况
  ❌ 硬编码多（配置、常量）
  ❌ 缺少抽象（重复代码）
  ❌ 没有考虑扩展性
  ❌ 测试覆盖不足
  ❌ 没有日志和监控

我需要做的：

• 重构代码结构（提取函数、模块化）
• 添加错误处理（try-catch、错误边界）
• 提取可配置项（环境变量、配置文件）
• 设计抽象层（接口、抽象类）
• 补充测试（单元测试、集成测试）
• 优化性能（缓存、索引）
• 添加可观测性（日志、监控、告警）

时间分配（我的实际经验）：

• AI生成代码：20%
• 审查和重构：40%
• 集成和测试：30%
• 文档和部署：10%

这个比例说明：AI帮我节省了20%的时间，但我仍需要投入80%的时间做工程化工作。

5.3 高速开发暴露的真相

Joe的洞察：

"10倍速度是放大镜"

放大了什么：

• ✅ commit间的意外交互
• ✅ 架构决策的重要性
• ✅ 协调成本
• ✅ 反馈循环的价值
• ✅ 技术债务的累积速度

我的补充：

高速开发也放大了：

• 架构设计的价值：好架构让集成容易，坏架构让每次集成都是噩梦
• 测试的价值：快速验证变更，避免破坏现有功能
• 文档的价值：快速理解上下文，避免重复问题
• 规范的价值：保持一致性，降低认知负担

结论：

AI能解决局部问题，但系统性复杂度需要人类。

更准确地说：

• AI能快速生成代码片段
• 但人类需要将这些片段组织成一个连贯的、可维护的系统
• 这需要架构视角、全局思维、长期规划

---

六、当前状态定位

6.1 AI能力的清晰边界

三个视角的一致结论：

1. Bytesauna：demo到产品的鸿沟

• • AI能做demo，但"生产就绪"意味着推倒重来

1. Joe：10倍速度需要10倍配套

• • AI让代码速度提升10倍，但需要整个开发生命周期同步升级

1. 我：编码快了，但工程挑战更大

• • AI让我编码速度提升3-5倍，但80%的时间仍在做工程化工作

两个平行的现实：

1. 技术乐观者："AI让我10倍速编码！"
2. 技术求助者："谁能帮我把AI代码变成产品？"

这两个现实并不矛盾 —— 它们共同定义了AI的边界：

• AI确实能让编码速度大幅提升
• 但编码只是软件工程的一小部分

6.2 能力图谱

编码能力谱系：

孤立函数  →  模块  →  系统  →  产品  →  平台
    ↓         ↓       ↓       ↓       ↓
  AI擅长   AI可以   需要人类  人类主导 人类必需
           (有指导)  (AI辅助)
           
例子：
孤立函数：计算两个日期的天数 ← AI完全可以
模块：用户认证模块 ← AI可以生成，但需要人类指导架构
系统：完整的用户管理系统 ← 需要人类设计架构，AI辅助实现
产品：生产级SaaS应用 ← 人类主导，AI加速部分环节
平台：支持多租户的企业平台 ← 人类必需，AI只能辅助局部

转折点：Demo → 产品

• 这是AI能力的边界
• 这是技术联合创始人的价值所在
• 这是"推倒重来"发生的地方
• 这是架构师的用武之地

6.3 客户常见的误解

作为架构师，我经常遇到这些误解：

误解1："AI写了代码，就完成了80%"

• 现实：可能只完成了20%，剩下80%是工程化
• 就像盖房子，砖头准备好了，但还需要设计、施工、装修、验收

误解2："AI代码能跑，就能上生产"

• 现实：能跑 ≠ 生产就绪
• 就像汽车，能启动 ≠ 能上路（需要安全检查、保险、维护）

误解3："找个程序员改改就行"

• 现实：需要架构师重新设计
• 就像建筑，不是"改改"，而是需要结构工程师评估和加固

误解4："AI能替代开发团队"

• 现实：AI是工具，不是团队
• 就像电钻能提升效率，但不能替代木匠

我的标准回答：

"AI帮你快速验证了想法（demo），证明了技术可行性。但要做成产品，需要系统性的软件工程工作：架构设计、错误处理、安全加固、性能优化、测试覆盖、部署流程、监控告警。这不是'改改代码'，而是重新设计架构、建立工程体系。"

---

七、真正的机会

7.1 不是替代，是赋能

错误理解：用AI替代软件工程师

正确理解：用AI降低最佳实践的成本

我的观点：

AI不是要替代工程师，而是：

• ✅ 让工程师专注于更高价值的工作（架构、决策）
• ✅ 让以前"太贵"的最佳实践变得可行（完整测试、完善文档）
• ✅ 让一人公司也能构建复杂系统（我的亲身体验）
• ✅ 让小团队也能实现大团队的产出（Joe的10倍速团队）

这是一个能力放大器，而不是替代品。

7.2 以前"太贵"的实践现在可行

7.2.1 Joe的团队经验

工程实践	以前	现在（AI辅助）
高保真fake依赖	太贵，不做	AI几天搞定
全系统本地测试	维护成本高	AI持续更新
更严格的测试覆盖	时间不够	AI快速生成
完善的文档	总是过时	AI同步维护

Joe的结论：

"这些想法在原则上是合理的，但实施和维护成本太高，大多数团队不会编写这样的测试。我认为我们正在看到agentic coding可以改变这里的计算的早期迹象。AI代理擅长输出大量代码，特别是当所需行为众所周知且几乎没有歧义时。原则上合理但实施和维护成本太高的想法，其成本刚刚降低了一个数量级。"

7.2.2 我的一人公司实践

以前做不到的：

• ❌ 完整的测试覆盖（太耗时，一个人写不完）
• ❌ 多语言支持（翻译成本高，维护困难）
• ❌ 完善的API文档（手写太累，容易过时）
• ❌ 多平台支持（iOS、Android、Web，开发量太大）
• ❌ 性能优化（需要专家，成本高）

现在可以做到：

• ✅ AI生成测试用例，我设计测试策略
• ✅ AI翻译文档和UI，我审校关键内容
• ✅ AI生成OpenAPI文档，我设计API契约
• ✅ AI生成平台适配代码，我处理特殊情况
• ✅ AI建议优化方案，我做权衡决策

关键变化：

• 从"做不做"变成"怎么做"
• 从"有没有资源"变成"如何设计"
• 瓶颈从执行转移到决策

这是一个根本性的转变。以前，很多好的工程实践因为"太贵"而被放弃。现在，AI降低了执行成本，让这些实践变得可行。

7.3 用AI构建支撑AI的基础设施

自举循环：

AI生成代码（速度快）
  ↓ 需要
更好的工程实践（质量保障）
  ↓ 需要
更多基础设施代码（测试、CI/CD、监控）
  ↓ 用
AI生成基础设施代码（降低成本）
  ↓ 支撑
更高速的AI编码（正向循环）
  ↓ 循环

Joe的实践：

• 用AI生成fake依赖
• 用AI生成测试harness
• 用AI维护测试基础设施

我的实践：

• 用AI生成CI/CD配置（GitHub Actions workflow）
• 用AI生成监控和告警规则（Prometheus、Grafana）
• 用AI生成部署脚本（Docker、Kubernetes）
• 用AI生成性能测试场景（k6、JMeter）

关键：

• 人类设计架构和策略
• AI实现具体细节
• 整个开发生命周期需要同步进化

这是一个良性循环：AI帮助我们构建更好的基础设施，更好的基础设施支撑更高速的AI编码。

7.4 范式转变

7.4.1 旧范式

人类编码 → 人类测试 → 人类部署
    ↓         ↓          ↓
  慢但可控   覆盖有限   手工为主
  
瓶颈：人的时间和精力

7.4.2 新范式

AI编码(×10) → 增强测试(×10) → 加速CI/CD(×10)
     ↓              ↓               ↓
人类架构决策    人类测试策略    人类部署策略
     ↓              ↓               ↓
   权衡判断      关键场景      风险控制
   
瓶颈：人的决策质量和架构能力

7.4.3 我的一人公司范式

传统一人公司：
  能力 = 个人技能 × 时间
  瓶颈 = 时间（24小时/天）
  结果 = 只能做小项目

AI时代一人公司：
  能力 = (个人决策能力 × AI执行速度) × 工程体系
  瓶颈 = 决策质量 + 架构设计
  结果 = 可以做中大型项目

成功的关键：

Joe的总结：

"成功使用agentic开发的团队，将是那些认识到整个软件开发生命周期需要协同演进的团队。"

我的补充：

"成功的一人公司，是那些用AI放大决策能力，而不是仅仅加快编码速度的人。"

---

八、结论：拥抱人机协作的新时代

8.1 核心结论

现在：AI会编码，但还不会做软件

为什么：

• 编码是解决孤立的、定义明确的问题
• 软件工程是管理系统复杂度、做权衡决策
• AI擅长前者，后者需要人类

未来：

• 可能有一天AI也能做软件工程
• 但那一天还没到来
• 当下是人机协作的黄金时代

8.2 三个视角的一致结论

Bytesauna的观察：

"Demo到产品的鸿沟，就是AI能力的边界。当你看到AI生成的代码，你会意识到'生产就绪'意味着推倒重来。"

Joe的实践：

"10倍速度需要整个开发生命周期的同步进化。就像给老车装涡轮增压器，如果不升级轮胎和刹车，结果不是更快，而是车毁人亡。"

我的经验：

"AI让我编码更快，但架构设计和工程化仍然是我的核心价值。AI节省了我20%的时间，但我仍需要投入80%的时间做工程化工作。"

8.3 软件工程的本质没有改变

仍然是：

• 管理复杂度
• 做权衡决策
• 确保长期可维护性
• 服务业务目标

改变的是：

• 工具更强大了（AI）
• 速度更快了（10倍）
• 要求更高了（需要配套设施）
• 机会更多了（以前做不到的现在可以做）

不变的是：

• 软件工程的核心——在约束下做权衡，管理系统复杂度——仍然需要人类
• 架构师的价值——系统性思维、全局视角、长期规划——更加凸显

8.4 给所有人的最后建议

8.4.1 拥抱AI，但保持清醒

拥抱：

• ✅ AI确实能大幅提升生产力
• ✅ AI确实能降低很多工作的门槛
• ✅ AI确实能让小团队做大事
• ✅ AI确实能让个人开发者实现以前不可能的项目

清醒：

• ⚠️ AI不是银弹
• ⚠️ 编码只是软件工程的一部分
• ⚠️ 质量和速度需要平衡
• ⚠️ 架构和决策仍需人类

8.4.2 投资正确的能力

短期（立即行动）：

• 学会高效使用AI工具
• 建立人机协作工作流
• 提升代码审查能力

长期（持续投资）：

• 架构设计和系统思维
• 复杂度管理
• 业务理解
• 权衡决策能力

永远重要：

• 好奇心和学习能力
• 解决问题的能力
• 沟通和协作能力

8.4.3 建立工程体系

不要：

• ❌ 只追求速度
• ❌ 忽视质量
• ❌ 跳过测试
• ❌ 省略文档
• ❌ 积累技术债务

要做：

• ✅ 建立代码审查流程
• ✅ 投资测试基础设施
• ✅ 完善CI/CD
• ✅ 记录架构决策
• ✅ 保持技术债务可控
• ✅ 建立监控和告警

8.5 最后的思考

Joe的展望：

"我对agentic开发的潜力感到非常兴奋。我认为它不仅能提高软件开发的效率，还能让我们解决以前太小众或太昂贵而无法解决的问题。收益是真实的——我们团队的10倍吞吐量增长不是理论上的，而是可衡量的。"

Joe的警告：

"但这些收益不会在我们简单地把AI代理嫁接到现有开发实践上时实现。就像给轮胎窄、刹车旧的车加涡轮增压器，结果不会是更快的圈速——而是撞车。在10倍代码速度下，我们当前的测试、部署和团队协调方法成为限制因素。瓶颈只是移动了。"

我的总结：

"AI会编码，但还不会做软件——这既是现实，也是机会。"

"现实是，软件工程师（尤其是架构师）的价值不会消失，反而更加凸显。我们的核心价值从'写代码'转移到'设计系统、做权衡决策、管理复杂度'。"

"机会是，我们可以用AI放大自己的能力，做以前做不到的事。作为一人公司，我现在能做以前需要小团队才能完成的项目。作为架构师，我能更快地验证想法、更好地服务客户。"

所以：

• 让我们拥抱这个人机协作的新时代
• 用AI增强我们的能力，而不是被AI的速度拖垮
• 专注于AI难以自动化的核心价值：架构、决策、复杂度管理
• 建立配套的工程体系，让高速开发可持续

记住：

• 编码只是软件工程的一小部分
• AI让我们更快编码，但也要求我们更好地做工程
• 真正的机会在于让以前"太贵"的最佳实践变得可行
• 软件工程的核心——在约束下做权衡，管理系统复杂度——仍然需要人类

AI会编码，但还不会做软件——这是挑战，更是机遇。

---

参考资料

1. The New Calculus of AI-based Coding
   Joe Mag, 2025
   https://blog.joemag.dev/2025/10/the-new-calculus-of-ai-based-coding.html
2. AI can code, but it can't build software
   Bytesauna
   https://bytesauna.com/post/coding-vs-software-engineering

---

如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！

---

我是 dtsola【IT解决方案架构师 | 一人公司实践者】 ；专注商业、技术、一人公司、个人成长分享。

经验交流https://www.dtsola.com

---

#AI编程 #软件工程 #架构师 #一人公司 #独立开发者 #技术管理 #程序员 #技术博客 #职场成长 #创业

---