跳至内容
VisionUnion
  • 首页
  • 商店
  • 服务
  • 组织
    • 关于我们
    • 联系我们
    • 课程
    • 活动
    • 博客
    • 论坛
  • 0
  • 0
  • 简体中文 English (US)
  • 登录
  • 联系我们
VisionUnion
  • 0
  • 0
    • 首页
    • 商店
    • 服务
    • 组织
      • 关于我们
      • 联系我们
      • 课程
      • 活动
      • 博客
      • 论坛
  • 简体中文 English (US)
  • 登录
  • 联系我们

我用AI写代码的三年:从步履蹒跚到唱跳RAP

  • 所有博客
  • AI
  • 我用AI写代码的三年:从步履蹒跚到唱跳RAP
  • 2026年6月8日 由
    我用AI写代码的三年:从步履蹒跚到唱跳RAP
    Admin

    前言

    我其实是一名证券事务代表,双硕士学历——法学(白俄罗斯国立大学)和金融(吉林大学)。我的技术栈是Python、Rust、Vue3、Docker、PostgreSQL。听起来像程序员的简历,但这些代码大部分都不是我自己写的。

    **我的原则:尽量不自己写代码,只做架构师和提示词工程师。**

    这不是偷懒,而是一种工作方式的彻底重构。从2024年初开始解除AI编程,到2026年已经用这套方法完成了量化交易系统架构设计、企业董办管理系统、BPM 系统、风控系统需求拆解、个人品牌官网搭建等多个项目。本文是我三年实践的系统性总结。

    ---

    一、核心理念:先想清楚,再让AI动手

    很多人(包括我之前也是这样)用AI写代码的方式是:打开IDE,把需求往对话框里一扔,等代码输出,然后复制粘贴。

    **这是最差的用法。**

    我踩坑后逐渐摸索出来的工作流程中,时间花最多的环节永远是**市场调研和技术选型**,而不是写代码。在告诉AI"写什么"之前,必须先回答三个问题:

    1.**为什么做**——这个功能解决什么痛点?不做的代价是什么?

    2.**做给谁**——用户画像是什么?他们现在的替代方案是什么?

    3.**怎么做**——技术栈是什么?架构边界在哪里?哪些东西绝对不做?

    这三个问题想不清楚,AI写出来的代码再多也是废代码。

    ### 实际工作流

    ```Figma 画草图 → AI 抽卡打磨视觉 → 做前端 demo → 补全项目文档 → 拆成模块 → 交给 AI IDE 分批开发```

    关键在于**拆成模块**这一步。一个"做好用户模块"的任务,AI大概率会做出你不需要的东西。但如果你拆成"用户注册接口,接收邮箱和密码,返回JWT token",AI几乎不会出错。

    ---

    二、工具分工:前端Gemini,后端Claude

    不同AI模型有不同的"性格",用对地方事半功倍:

    | 任务 | 模型 | 原因 ||------|------|------|| 前端页面初始化 | Gemini 2.5 Pro | 有"灵气",视觉审美在线 || 前端美化/交互细节 | Gemini 2.5 Pro | 对CSS和动画的理解更自然 || 后端工程结构 | Claude | 架构严谨,接口设计稳定 || 数据库Schema | Claude | 对关系型数据库的理解更深 || 代码审查 | Claude | 更善于发现逻辑漏洞 |

    这不是绝对的,但这是我反复验证后的最优分工。**没有最好的模型,只有最合适的场景。**

    ### 多Agent并行策略

    当不考虑成本时,可以让多个AI同时做同一任务,挑最优的推进。这就像让三个工程师同时做一道题,取最好的答案。效率飞快,但有个前提——

    ---

    三、刹车系统:越高速越需要安全网

    AI写代码的速度是人类的10倍,犯错的效率也是10倍。我踩过的坑包括:AI自作主张新建了十几个不需要的文件、修改了核心配置导致系统无法启动、在三个文件里同时改动导致冲突无法合并。我还记得有一天晚上,我改了十几版代码,但是忘了做 git。AI 也不会主动去做,即便是前面要求过它每次修改必须要做 git,但随着上下文的增长,它还是会逐渐遗忘的。

    所以:
    一方面,还是要盯着终端,以防 AI 幻觉遗忘;

    另一方面,还要通过钩子持续进行 git 任务的注入。

    **教训:AI越快,你的安全网越要牢。**

    ### Git是最后的安全网

    ```bash# 每次验证通过后立刻提交gitadd.gitcommit-m"feat: 用户注册接口完成,能跑"

    # AI乱来就回退gitlog--onelinegitcheckout<commit-id>```

    这不是可选项。如果你不能在30秒内回退到上一个能跑的版本,你就没有安全网。

    ### 原子化提交

    ```❌ "feat: 完成用户模块和数据库配置"✅ 拆成两条: - "feat: 完成用户模块 CRUD" - "feat: 添加数据库连接配置"```

    一个Commit解决5个问题 = 垃圾。每次Commit只做一件事,出了问题能精准定位。

    ### 实验沙盒SOP

    所有破坏性改动必须在feature分支上做:

    ```1. git checkout -b feature/new-experiment2. 在分支上做所有改动3. 测试通过 → 合并到 main4. 测试失败 → git checkout main + 删除分支```

    **失败了不丢人,失败了污染了主线才丢人。**

    ---

    四、任务拆解:5到30分钟一个单元

    这是我最核心的经验。AI编程的失败,90%是因为任务太大。 我很多时候尝试过在晚上睡觉前给 AI 布置一个长任务,但第二天起床的时候发现,它十几20 分钟就认为任务已完成就停止了运行,剩下的时间都在摸鱼。下面就是我摸索出来的让 AI 自主执行长时间任务的经验。

    | 维度 | 正确 | 错误 ||------|------|------|| 时间 | 5-30分钟 | 超过2小时 || 文件 | 1-2个文件 | 10+个文件同时改 || 功能 | 一个明确功能 | "做好XX模块" || 可验证 | 有明确输出标准 | "优化一下" |

    ### 四步执行流程

    **第一步:派活前先定交付标准**

    告诉AI"先输出文件结构,确认后再写代码"。这一步能过滤掉80%的方向性错误。

    **第二步:让AI先画目录结构**

    确认后再施工。禁止AI新建或修改文件夹——这个权限必须由人控制。

    **第三步:完成后立刻验证**

    能跑吗?输出对吗?文件结构对吗?通过后立即Git提交。

    **第四步:AI乱来立刻止损**

    说"停" → 清理现场 → `git checkout <commit-id>` 回退。不要试图修补AI的烂摊子,回退永远比修补快。

    ---

    五、规则体系:给AI立规矩

    AI不是人,它没有常识,没有"这应该不对吧"的直觉。所以你必须把规则写死。

    ### 我的规则分层

    ```┌──────────────────────────────────────┐│ 全局铁律(所有AI工具必须遵守) ││ → 安全红线、禁止事项、强制规范 │└─────────────────┬────────────────────┘ │┌─────────────────▼────────────────────┐│ 工具链规范(UV-First Policy) ││ → Python环境管理、依赖声明 │└─────────────────┬────────────────────┘ │┌─────────────────▼────────────────────┐│ 项目规则(各项目CLAUDE.md) ││ → 项目专属架构和业务逻辑 │└─────────────────┬────────────────────┘ │┌─────────────────▼────────────────────┐│ 执行检查清单 ││ → 派活前自问 + 完成后必做 │└──────────────────────────────────────┘```

    ### 铁律示例

    | # | 禁止 | 原因 ||---|------|------|| 1 | 禁止用 pip/conda/venv | 必须用 uv 管理 Python 环境 || 2 | 禁止使用 Redis/gRPC/中间件 | 每多一个组件多一个故障点 || 3 | 禁止在 main 分支直接改代码 | 必须开 feat/ 分支 || 4 | 禁止 .env 进 Git 历史 | 密码/Token 必须隔离 || 5 | 禁止 Public Repo 推送代码 | 安全红线 |

    这些铁律不是写在文档里看看的,而是**写入AI的规则文件**,每次启动AI IDE时自动加载。AI违反任何一条,立刻停止当前任务。

    ### 规则编写原则

    -**规则是用来"卡死"逻辑的,不是用来"描述"逻辑的**- 极简表达:5个字能说明白就不用20个字- Token敏感:规则越短,AI理解业务的"脑容量"越大

    ---

    六、深度人机协作:一行行审计AI代码

    用AI写代码不等于甩手不管。恰恰相反,AI写完之后,**一行行审计**才是真正学东西的环节。

    我的做法是跟着AI的执行过程理解它的思考逻辑:

    1.**看AI为什么做这个选择**——它选了PostgreSQL而不是SQLite,为什么?

    2.**看AI遗漏了什么**——错误处理、边界条件、并发安全

    3.**看AI的编码习惯**——变量命名、函数拆分、模块组织

    这个审计过程比看任何教程都有效,因为你在看的是一个"能运行的思路",不是纸面理论。

    ---

    七、独立开发者方法论

    这套方法不仅适用于编程,更是一种独立开发者的生存哲学:

    1.**选题最重要**:写代码前必须全面调研,先思考再动手。代码是最不值钱的部分,判断力才是。

    2.**从垂直领域来,到大众中去**:垂直切入积累专业口碑,再面向大众推广。

    3.**做减法,不完美主义**:快速验证,实践中不断修正定位。完美主义是独立开发者的最大的敌人。

    4.**提前准备传播素材**:清晰直观的演示视频,让别人帮你宣传。

    5.**代码是冷的,故事是热的**:学会讲好代码背后的故事,是独立开发者必修课。

    ---

    八、一句话总结

    | 领域 | 核心原则 ||------|---------|| AI编程 | 任务拆小,每步验收,Git做安全网 || Python环境 | uv是唯一管理器,uv.lock必须提交 || 工具分工 | 前端Gemini有灵气,后端Claude更稳 || Git | 原子化提交,分支管理,乱了就回退 || 实验 | 乱就开分支,失败就删,成功才合并 || 规则 | 卡死逻辑不描述逻辑,极简表达 |

    ---

    后记

    我是个证代,传统的划分是法律金融人,而不是程序员。但我发现AI编程这件事,最重要的能力不是写代码,而是**想清楚**。法律训练教给我的——严谨的逻辑、对边界条件的敏感、对风险的偏执;金融训练交给我的是计算风险收益和数学期望——恰恰是AI编程最需要的素质。

    代码可以交给AI,但判断力不能。

    这是一个人人都能写代码的时代,但不是人人都能写对代码的时代。区别在于:你是AI的指挥者,还是AI的搬运工。

    ---

    作者:Jack Chen

    在 AI
    # AI Vibe Coding
    我用AI写代码的三年:从步履蹒跚到唱跳RAP
    Admin 2026年6月8日
    分析这篇文章
    标签
    AI Vibe Coding
    我们的博客
    • 旅行
    • AI
    存档
    Copyright ©
    由 VisionUnion VisionUnion 提供支持