我放弃了造轮子,反而更快

一、我曾经是个"造轮子狂魔"

我的 HomeSense 项目,从 L1 规则引擎到 L2 向量经验库,从状态 TTL 到 ADB 工具封装,几乎每一行代码都是自己写的。

不是不能造。三层意图缓存、ReAct 循环、CLI 工具集------我全造出来了,跑得还挺稳。

但我发现一个问题:太慢了。

写一个 ADB 工具,要研究 Android 调试协议。写一个工作流调度器,要想清楚 DAG 的拓扑排序怎么处理循环依赖。写一个 Skills 加载器,要设计 Markdown 的 YAML frontmatter 怎么解析。

每一个轮子都在消耗我的时间,也在消耗 AI 的 Token。我的中转站额度本来就不稳,每次让 AI 帮我设计一个模块,几千 Token 就没了。

我陷入了"造轮子陷阱":能造,但投入产出比越来越低。

二、转折点:我收集了 31 个项目,但决定不看它们

为了不再闭门造车,我收集了 31 个开源项目。

从工作流编排的 dify,到工具注册的 agentmesh,从多 Agent 联邦的 openclaw,到记忆系统的 mempalace。每一层的工业级参照我都准备好了。

然后我做了一个决定:不让 AI 看它们。

不是舍不得 Token------好吧,就是舍不得。但更重要的原因是,我发现了一个被忽略的事实:

架构设计完成之后,参考项目就不再是"小说",而是"字典"。

小说需要从头读到尾,字典只需要在遇到生词时翻开。

我之前的心态是"让 AI 读完这些项目,帮我设计架构"。但我已经自己设计完架构了。我现在需要的不是"帮我思考",而是"帮我翻译"------把 Spec 里定义好的接口,翻译成具体的代码实现。

三、新的工作流:用到时才查,精准打击

我改掉了"提前研读"的习惯,换成了"按需查阅"。

当我要写 我去翻哪个项目 看什么
tools/registry.ts agentmesh toolset.go 的注册模式
skills/loader.ts claude-code-agents 渐进式披露的加载逻辑
workflow/scheduler.ts dify scheduler.py 的调度循环
memory/search.ts mempalace searcher.py 的混合搜索权重

写到哪,翻到哪。不提前读,不泛泛读。

这让我的 Token 消耗从"每次几千"变成了"每次几百"。省下的 Token,够我多写 10 个模块。

更重要的是,我避免了"闭门造车"的冲动。以前遇到一个设计问题,第一反应是"自己想一个"。现在第一反应是"翻翻那个项目怎么做的"。

不是照搬。是看它的接口设计、看它的模块边界、看它的错误处理模式,然后融进我自己的架构里。

四、造轮子和不造轮子的边界在哪

我不是彻底不造轮子了。我的三层意图缓存、状态 TTL、会话冷却------这些核心差异化能力,依然是自己写的。

边界在这里

自己造 用别人的
核心差异化能力(三层缓存) 通用基础设施(数据库、消息队列)
定义行业最佳实践的(状态 TTL) 已有成熟模式的(工作流调度器)
你比所有人都懂的场景 你只是"需要这个功能"的场景

核心你自己造,外围你借鉴模式。

我放弃了造"通用轮子",把精力集中在造"只有我能造的轮子"上。

五、融会贯通,而不是照搬

"参考项目"和"照搬项目"的区别是什么?

照搬是:dify 的调度器用 Python 写的,我也用 Python 重写一个。融会是:dify 的调度器把节点执行和状态管理分离了,我把这个模式用 TypeScript 实现一遍。

照搬的是代码,融会的是设计模式。

我的 DeviceRegistry 借鉴了 HA 的设备抽象思想,但代码全是我自己的。我的 WorkflowEngine 借鉴了 dify 的 DAG 调度模式,但实现只用了我需要的 20% 功能。

这就是"融会贯通":把别人的设计思想消化掉,用自己的技术栈和场景重新表达。

六、我的 AI 分层使用策略

这套方法还有一个好处:让我能用更少的 Token 撬动更大的产出。

我把 AI 分成两层:

层级 做什么 用哪个 AI
架构设计 定义模块边界、接口契约、验收标准 我自己 + 贵的 AI 确认
编码实现 把 Spec 翻译成代码 免费 AI 批量生成

贵的 AI 只用在"决策"上,不用在"执行"上。

参考项目也是一样:贵的 AI 不读源码,我自己去翻关键文件,提取出设计模式,喂给免费 AI 去实现。

思考是我和贵 AI 的事,翻译是免费 AI 的事。

七、写在最后

造轮子是能力,不造轮子是智慧。

能力证明你能走多远,智慧决定你能走多快。

我现在的方法是:

  1. 自己设计架构,把核心差异化能力握在手里

  2. 收集优秀项目,作为"设计模式字典"

  3. 按需查阅,写到哪翻到哪,不提前读

  4. 融会贯通,把别人的思想用自己的代码表达

  5. 分层使用 AI,贵的做决策,免费的做执行

这套方法让我从"造轮子狂魔"变成了"架构师 + 组装工"。

造轮子的能力依然在,但我只在真正需要的地方造。

省下的时间,用来写 Spec。省下的 Token,用来做决策。

这才是 AI 时代的"节俭主义开发法"。

相关推荐
cup1115 小时前
[技术复盘] Windows Python 打包实战:Nuitka 环境踩坑总结与 CI 自动化构建全指南
python·ai·环境变量·ci·nuitka·skill
IT王师傅19 小时前
从 豆包 到 Codex CLI:一名普通开发者的 AI 工具进化路线
ai·codex cli·openclaw
岳小哥AI21 小时前
Siri要接入AI了,苹果手机上一句话让GPT写文案、DeepSeek写代码的时刻来了
ai·ai基础
Artech21 小时前
[MAF预定义的AIContextProvider-03]ChatHistoryMemoryProvider——赋予Agent从经验中学习的能力
ai·c#·agent·memory·maf
哥布林学者2 天前
深度学习进阶(三十一)FlashAttention:IO 感知的精确注意力
机器学习·ai
岳小哥AI2 天前
AI大模型"幻觉"从何而来?解密GPT-4、DeepSeek一本正经胡说八道的真相
ai·ai基础
JaguarJack2 天前
Openai Codex 重大更新 已支持接入任意开源大模型
ai·openai·codex
Artech3 天前
[MAF预定义的AIContextProvider-02]AgentSkillsProvider——将Agent Skills引入MAF
ai·c#·agent·agent skills·maf
岳小哥AI3 天前
读懂计算机视觉CV、语言感知(ASR/TTS)、多模态,就能理解AI是如何“看到”与“听到”世界的
ai·ai基础
大树883 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai