嗨，各位技术探险家们！我是提米哥。👋

我平时重度使用 AI 写代码助手，可能甚至有点过度依赖了。目前我最爱的是 Grok Build。🤖❤️

但我可不想把我的工作流死死绑定在某一个 AI 身上。毕竟大模型更新换代太快了，今天出一个新模型，明天跑个跑分测试，大家可能马上就变心了。😂

所以我的设置非常无聊，但核心就是“不绑定特定 AI”。

秘诀就是：用技能描述工作流，用钩子强制执行。

先规划，再干活 🏛️

我不喜欢直接给 AI 下达指令：

“给我实现 X 功能。”

这种做法通常只会换来两千行看起来很美，但完全文不对题的代码。🫠

相反，我会用一个“AI 评审团”技能。让多个 AI 同时独立看问题，挑刺架构设计，最后把结果转化成标准的技术任务单。

我说的“技术”，是真的具体到细节的那种：

• SQL 数据库表结构设计
• 数据迁移方案
• 结构体与类型定义
• 类与 API 接口
• 文件结构
• 边缘情况处理
• 验收标准

如果我们要建一张数据表，就把表结构写进任务里：

CREATE TABLE pizzas (
    id UUID PRIMARY KEY, -- 披萨的唯一标识符
    topping TEXT NOT NULL, -- 配料名称，不能为空
    delicious BOOLEAN NOT NULL DEFAULT true -- 是否好吃，默认为真
);

绝不要那种“构建一个稳健且可扩展的披萨管理解决方案”的废话。谢了，这简直是顾问机器人的作风。😂

在改架构成本还很低的时候，让 AI 们去争论吧。

规划好了，让机器人开干 👨‍🍳🤖

一旦技术任务单打磨锐利了，我就把它交给负责干活的 AI。目前通常用的是 Grok Build。

架构有了，类型有了，验收标准有了。去吧，给我做饭。🍕

代码写完后，紧接着就是“自动审查”环节：

审查 → 发现问题 → 修复 → 再审查

这比让同一个 AI 写代码、自己审查自己、自我表扬一番然后直接提交要好太多了。

我把这套流程应用到了我正在构建的几个项目里，效果很稳。不同项目，同一个小型机器人流水线。🏭🤖

没证据，就别提交 🧾🚢

这大概是我最近加的最有用的一个规则。

AI 最喜欢说：

测试通过了，应该没问题。✅

注意这个“应该”。🫠

所以我不再去“请求”它们验证。我强制要求它们在提交代码前拿出证据。

每个项目都有一个专门的验证技能，这个技能知道怎么证明这玩意儿真的能跑：

• 运行它
• 点一点它
• 调用它
• 查一查数据
• 截个图
• 拿出证据

单元测试当然很好。但是“测试通过”和“我亲自用了这玩意儿并且这里有它能用的证据”，根本不是一回事。

然后通过一个钩子来强制执行。没证据？就不允许提交代码。🚫🤖

在提交代码或打开合并请求之前，还会先进行“起飞前安检”。

机器人在干活的时候可以尽情发挥创造力。但当它准备收工走人时，我们要检查它的行李。🛂

这基本就是我的循环 🔁

💡 产生想法 → 🏛️ AI 评审团讨论 → 📝 形成技术任务单 → 👨‍🍳 开始构建代码 → 🛡️ 审查并修复 → 🧾 验证并拿出证据 → 🛂 起飞前安检 → 🚀 提交合并请求

就这么简单。我并不是想造一个完美的全能 AI。

我只想让围绕 AI 的工作流程变得靠谱。

AI 是随时可换的，技能是可移植的，钩子能让这些打工的小弟们保持诚实。 🤖

鸣谢 🙌

这套工作流很大程度上受到了 Lauren Tan、Peter Steinberger 和 Matt Pocock 的启发。Lauren 关于 AI 技能和工作流的理念，Peter 的自动审查方法，以及 Matt 在规划、规范和工程技能方面的工作，都深深影响了我的设置。

我主要是把他们喜欢的部分，加上我自己一些存疑的工程决策混在了一起，然后加上了最近最有用的规则：

没证据？不准提交。 🧾🚫