我把 AI 变成了开发体系，而不是工具
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
过去一段时间，我在用 AI 做两件事：
- 做 App
- 写代码
一开始，我和大多数人一样。
把 AI 当成一个更聪明的搜索引擎。
直到有一天，我意识到一个问题：
如果 AI 只是用来“回答问题”，那它的价值其实很有限。
真正的变化，是从这句话开始的：
我不再问：AI 能帮我做什么 我开始问：AI 应该放在我的系统哪里
从那一刻起，我的开发方式彻底变了。
一、绝大多数人，都在用错 AI
现在很多人用 AI 的方式是这样的：
- 写一个 prompt
- 让 AI 生成代码
- 复制粘贴
- 不行就再问一次
这种方式的问题在于：
你在“碰运气”，而不是在“构建系统”。
结果就是：
- 输出不稳定
- 代码不可控
- 越用越乱
二、我做的第一个改变：不再写 prompt，而是设计规则
我后来做了一件事：
停止研究 prompt，开始设计约束（constraints）
比如：
- ViewController 不能写业务逻辑
- 所有外部调用必须走 Service 层
- 强制 async/await
- 一个类只做一件事
这些规则，本来是我自己写代码时遵守的。
现在，我让 AI 也必须遵守。
结果很明显：
- 代码结构开始稳定
- 输出质量显著提升
- 几乎可以直接用在生产环境
三、AI 不再是工具，而是一层“能力层”
很多人理解 AI，是“一个工具”。
但我现在的理解是：
AI 是一层能力（Capability Layer）
我的开发结构，大概是这样：
- UI 层（UIKit / SwiftUI）
- 业务层（UseCase / Domain）
- 服务层（API / StoreKit / 语音识别）
- 数据层（CoreData / Supabase）
而 AI，是横在所有层之上的一层能力：
- 帮我生成代码
- 帮我重构逻辑
- 帮我分析错误
- 帮我做架构判断
不是某一个点，而是贯穿整个系统。
四、我现在的开发方式（真实工作流）
现在我写代码，基本是这样一个循环：
定义 → 生成 → 校验 → 重构 → 上线
举个很实际的例子：
我要做一个订阅功能，我不会这样问：
帮我写一个订阅系统
我会这样拆：
- 写一个 SubscriptionManager
- 使用 StoreKit 2
- 支持月订阅、年订阅以及终身买断
- 提供 async 的 purchase() 方法
- 不和 UI 耦合
然后交给 AI。
再由我来做：
- 结构校验
- 代码调整
- 边界处理
这时候 AI 的角色就很清晰：
它不是“帮我写代码”，而是“帮我填空”
五、调试效率的变化，是最夸张的
以前遇到报错：
- StackOverflow
- 各种尝试
现在：
- 截图
- 丢给 AI
- 直接给出原因 + 解决方案
最明显的变化不是“快一点”。
而是：
反馈闭环从几小时，变成几分钟
六、真正的瓶颈，已经不在写代码了
当 AI 能帮你把代码效率提升之后，你会发现：
真正卡住你的，是这些：
- 架构能力
- 产品判断
- 优先级选择
这些东西，AI 目前帮不了你。
但它会放大你的能力水平：
- 你强，它更强
- 你乱，它更乱
七、AI 做得很好的地方 & 做不好的地方
说清楚这点很重要。
AI 擅长：
- 模板代码
- 重构
- Debug
- 快速试错
AI 不擅长：
- 长期架构
- 产品方向
- 复杂 trade-off
如果把方向交给 AI：
你只会更快地走错路
八、一个很多人不愿意承认的事实
AI 不会淘汰开发者。
但会淘汰：
- 没有结构的人
- 没有方法论的人
- 只会堆代码的人
未来的差距，不是：
会不会用 AI
而是：
有没有一套“AI 能放进去运行”的系统
九、我现在的核心方法
如果你只想带走一件事，可以记这个：
小任务 + 强约束 + 控制上下文
具体就是：
- 一次只做一件小事
- 明确结构规则
- 限制 AI 读取范围
你会发现：
- 输出稳定了
- 成本下降了
- 代码质量上来了
最后
AI 并没有让我写代码更快。
它做的事情是：
让我更快地构建系统
而一旦你有了系统：
你就不再是一个人在开发。
如果你也在做：
- AI 应用
- iOS 开发
- 独立开发
我会持续分享：
- 从 0 到上线的完整过程
- 实战踩坑
- 可复用的开发体系
欢迎关注，一起把产品做出来。
2026.04.13 11:20
📍 沪 · 赵巷
📌 声明：本文由 AI 辅助完成