AI 编程工作流：从怀疑到实践

自 2022 年 AI 编程开始流行以来，我一直对此持怀疑态度。后来，我改变了看法：从大部分代码都由自己手写，转变为 90% 的代码交给 AI 生成。说实话，我很喜欢这种开发速度。

2023 年，我大约有 40% 的代码是用 ChatGPT 生成的，但整个过程令人沮丧。我花在向 ChatGPT 解释代码库上的时间，甚至比真正写代码的时间还多。LLM 给出的通常是泛泛的解决方案，几乎无法适配我的项目结构。我主要只是复制粘贴一些样板代码，再调整其中的值。

不过，ChatGPT 在后端开发方面表现得非常出色。我开发自己的第一个 Python 包 drf-api-key 时，ChatGPT 完成了大约 60% 的工作。它搞定了 Fernet 加密，正确组织了代码结构，为我节省了数小时的研究时间。

真正的突破发生在我休假 8 个月期间，当时我发现了 Cursor。有人向我介绍了这个工具，它帮助我快速搭建创业项目的后端样板，并处理基础设施相关工作。最初几次使用时，感觉简直像魔法。

Cursor 对现有代码库的理解，是 ChatGPT 从未达到过的。它能识别代码模式、保持一致性，甚至真正改进代码，而不仅仅是生成代码。

但即使是 Cursor 也有局限。它不擅长处理较新的框架，而且无法访问最新文档（现在可以通过 Context7 实现）。我仍然需要手动编写配置，因为 Cursor 生成的配置有时完全是错的。

然后，时间来到 2024 年 11 月。MCP server 正式推出，Anthropic 改进了它们的编程模型，Claude Code 问世，而 Gemini 2.5 的效率也确实非常高。现在，我 90% 的代码都来自 AI，而且我已经找到了许多不止是让它们编写函数的使用方式。

如果你还没有充分利用 AI 编程，下面就是你应该开始这么做的原因。

在深入讨论之前：我主要写 AI 辅助开发、产品构建和软件工程方面的内容。如果你想看到更多类似内容，可以订阅我的 newsletter。

AI 编程像魔法，但你才是魔术师

使用 AI 编程 12 个月，并观察其他开发者如何艰难地使用它之后，我意识到了一件令人不太舒服的事：你的 AI 编程体验，其实是你真实软件工程能力的一面镜子。

而且，我说的不只是编程能力，而是所有方面：

• 如果你做事没有章法，给 AI 的指令就不会奏效。AI 会生成垃圾，因为你的需求本身就是垃圾。

• 如果你不了解自己的代码库，就无法引导 AI 保持一致性。最终得到的代码可能单独运行没问题，却会破坏其他所有东西。

• 如果你跳过准备和规划阶段，AI 就会完美地做出错误的东西。你会浪费数小时，调试那些用来解决一个从未被正确定义的问题的方案。

• 如果你缺乏耐心，只想立刻得到结果，就会在第一次 prompt 失败后直接放弃，而不是通过反复迭代逐渐逼近正确答案。

• 如果你的代码审查习惯很差，就会因为想当然地认为 AI 做对了，而把 AI 生成的 bug 发布出去。

我一开始也抱着一种“AI 应该看一眼就懂”的幻想，以为 AI 理应知道我想要什么，结果只有挫败感。你向 LLM 提交一次 prompt，得到平庸的结果，然后开始责怪工具。

现实是：AI Agent 就像速度极快的初级开发者，但它们需要清晰的指导。你不会只对一名初级开发者说一句“把这个功能做出来”，然后转身离开。你会向他解释代码库、展示现有模式，并给出具体需求。

80/20 法则在这里非常适用。软件工程通常有 80% 是准备工作，20% 才是编码。大多数开发者跳过准备阶段，直接开始写 prompt，然后疑惑为什么 AI 生成的都是垃圾。

我的工作流正好反过来：我用 AI 协助完成那 80% 的规划工作，从而让剩下 20% 的编码变得轻而易举。

接到任务时，我不会立刻开始写代码。我会让 AI 参与准备阶段，向它提供问题、代码库和约束条件的上下文，然后让它通过起草详细计划，帮助我梳理实现思路。

我会让 Agent 帮我起草详细的 PRD（Product Requirements Document，产品需求文档）。PRD 不是我亲自写的——我向 Agent 提供上下文，再由它生成计划。这会迫使我认真思考自己究竟需要什么，而 Agent 则会以一种让实现方式变得显而易见的结构，将这些内容组织起来。

• 把 ticket 描述、Figma 设计稿和文档交给 Agent。

• 让它起草 PRD 和实施计划。

• 和它一起审查并完善计划。

• 让 Agent 放手干活，再根据结果不断迭代。

准备阶段才是你真正扮演魔术师的地方。你在教 AI：你需要什么、你如何思考，以及优秀的结果应该是什么样子。完成这些之后，编码几乎就变成了机械执行。

那些彻底改变了我工作方式的工具

我目前的 AI 编程技术栈如下。

它是我的主要编程环境，尤其擅长理解庞大且已经存在的代码库。

实际编码时，我使用 Claude Sonnet 4.5；起草 PRD 或调试复杂问题时，我使用 Gemini 2.5 Pro。Cursor 有时会在某些任务上表现不佳，例如跨多个文件的大规模重构。它可以修改代码，但不一定总会考虑到更广泛的架构影响。

这是 2025 年真正改变游戏规则的技术。MCP（Model Context Protocol）把 LLM 与外部工具和 API 连接起来，让它们拥有超越文本生成的实际能力。

• Figma MCP——Agent 可以直接读取设计稿，并理解组件结构。

• Context7——让 Agent 能够访问任何框架的最新文档。

• AWS CloudWatch、Sentry、Resend——用于基础设施监控和通知。

它负责处理基础设施和部署工作。

我在项目根目录中维护了一个 CLAUDE.md 文件，用于定义我的基础设施标准和部署工作流。文件开头如下：

# Deployment Workflow
- Create timestamped database backup in /root/.backups-db/
- Pull latest changes from git (main branch)  
- Rebuild and restart Docker containers
- Run Django migrations and collect static files
- Verify all containers are healthy and services respond

## Critical Rules
- Never expose secrets in code or commits
- Always backup before deployment
- Use placeholders in documentation

部署时，Claude Code 会读取这个文件，并严格按照工作流执行。它会备份数据库、部署必要的更新、运行健康检查，再通过电子邮件向我发送报告。

我还设置了一个 cron job，每 6 小时运行一次健康检查。整个可观测性流水线都由 Claude Code 和 Markdown 指令管理。

AI 擅长什么，又不擅长什么

后端：AI 的舒适区

LLM 在后端开发方面表现极其出色。API、数据库 schema、业务逻辑——这些都是具有明确模式的结构化问题，而这恰恰是 AI 最擅长的领域。

关键在于向 AI Agent 提供代码库的完整上下文。把项目采用的模式、编码标准和架构决策记录下来。当 Agent 理解了你组织项目的方式后，就能在不同功能之间保持一致性。

处理集成任务时，我会把 API 文档交给 coding agent。它会阅读文档、理解身份验证流程，然后实现集成。如果供应商提供了 MCP server（例如 Sentry），Agent 就可以直接研究相关的实现模式。否则，Context7 也能让 Agent 访问任意框架的文档。

始终审查 Agent 生成的内容。它可能会创建出能够运行却无法扩展的代码；如果你没有明确设置约束，它也可能把简单任务过度设计。

要告诉 Agent 应该做什么，但更重要的是告诉它不该做什么。否则，它们往往会把事情变得过于复杂，生成一些没有必要的解决方案。请明确说明约束，例如：“使用现有的身份验证 middleware，不要新建一个”，或者“把代码控制在 50 行以内”。

前端：很好，但还没有那么好

使用 AI 进行前端开发是一件复杂的事。现在我的前端开发速度提高了 5 倍，但生成出难以维护代码的风险也更高。

我会从小处开始，让 Agent 构建单个组件，而不是一口气完成整个功能。先构建一个 button 组件，理解它的工作方式，然后再把它组合到更大的结构中。

对于复杂功能，我会使用 Figma 的 MCP server，为 Agent 提供视觉上下文。但不要指望它仅凭一张截图就能理解完整的 design system。应该把设计拆分成组件，再逐个实现。

用 AI 开发前端，需要比后端更多的迭代。你必须仔细审查生成的代码，并愿意根据需要不断完善 prompt。如果你觉得这听起来很烦琐，那还是坚持手动构建组件吧。

基础设施：出乎意料地强大

这是最让我意外的地方。AI Agent 非常擅长基础设施任务。

当我让 Claude Code 或 Cursor 创建 VPC、配置 security group，或者编写 CloudFormation template 时，它们正确处理细节的概率往往比我手动操作还高。基础设施本来就很复杂，即使是经验丰富的工程师，也很少能在第一次尝试时就把部署完全做对。

我实际构建了什么

自动化交易系统（7 小时）

我从 2018 年起就一直在研究市场走势，最近还学习了算法交易课程。算法交易真正的工作，是开发自己的策略：理解指标、对参数进行回测，并找出在真实市场中真正有效的方法。这需要数月的专注学习。

但我不打算等 6 个月之后才开始交易。

我的方法是：先构建基础设施，包括资金管理、交易执行和监控；使用第三方信号作为辅助工具；等自己的算法开发完成后，再把第三方信号替换掉。

手动构建交易基础设施的问题，在于需要集成的东西实在太多：Telegram API、消息解析、MetaAPI 交易执行、电子邮件监控、数据库追踪和自动化部署。任何一项都可能需要几天时间，才能正确实现。

借助 AI，我在 7 小时内完成了这一切。现在，系统在使用外部信号运行的同时，我可以学习技术指标并开发自己的策略。准备就绪之后，只需接入自己的算法，而整套基础设施届时已经历过实战检验。

我现在先把枯燥的部分做完，这样就能专注于真正有趣的部分：实际的交易策略。

• 从交易频道读取 Telegram 消息。

• 使用 OpenAI Agent，把信号解析成我想要的格式。

• 执行前验证交易。

• 通过 MetaAPI 自动下单。

• 监控持仓，并调整 stop-loss 和 take-profit 水位。

• 每 6 小时发送一次健康报告。

Cursor 在几小时内构建了 Django 后端（PostgreSQL + Celery）。我提供架构文档和需求，它则生成了 API、数据库 model 和后台任务。

Claude Code 负责部署和监控。我设置了一个运行健康检查的 cron job：

claude --dangerously-skip-permissions --print "Perform a health check for the trading application and send an email report. Read /root/MONITORING_EMAIL_PROMPT.md to understand the format and information required. Use the sender email onboarding@resend.dev and recipient myemail@gmail.com. Important: Approve all file read operations and email sending automatically."

下面是我收到的一封示例邮件：

Claude Code 会读取监控指令、检查系统状态，再通过电子邮件向我发送详细报告。整个可观测性流水线无需人工干预即可运行。

我甚至还构建了一个托管在 Gram 上的 MCP server。我只需要提供包含待公开 endpoint 的 OpenAPI 文档，Gram 就能生成 MCP server。

现在，我可以直接从 Claude Desktop 监控交易或执行下单。

让 Claude Code 负责部署也引发了一些有意思的问题。我使用 Telethon 从 Telegram 接收信号，而 Telethon 会创建一个 session 文件。每次部署时，这个文件都会被删除，导致 cron job 在尝试读取消息时失败。

结果发现，Claude Code 为了维持干净的状态，主动清理了这个文件。我花了大约一个小时才调试出这个问题。我的解决办法是：把 session 文件移到项目目录之外，并在构建 container 时将它复制进去。

• 虚构的函数：Cursor 编造了根本不存在的 validation function。我不得不强制它通过 Context7 阅读真实文档，然后修复问题。

• 错误的环境配置：Claude 在生产环境中设置了 USE_SQLITE=true，导致我的数据被写入文件，而不是 PostgreSQL。幸好我每次部署前都会执行备份，因此最终恢复了数据。

MCP 配置生成器（45 分钟）

我构建了很多 MCP server，逐渐厌倦了为不同工具手动编写配置文件。

我把 MCP specification 和自己写过的配置示例交给 Cursor。它生成了一个工具，可以为我需要的任何 MCP server 输出有效配置。只花了 45 分钟，却能在我每次启动新项目时节省 15～20 分钟。

我绝不打破的规则

我会在所有事情上使用 AI：为技术写作构建 POC、开发后端和前端，以及部署基础设施。下面是我始终遵循的两条规则。

规则一：深入理解项目、代码库和需求

如果你不知道要去哪里，就不可能给出正确的方向。AI Agent 会放大你的理解，但无法代替你的理解。如果你不了解自己的架构，coding agent 生成的代码也许今天能工作，明天却会出问题。

规则二：绝不给 AI Agent 破坏性权限

我会配置 IAM policy，允许 coding agent 创建和更新资源，但绝不允许删除资源。当某件事出错时——而它一定会出错——Agent 会先尝试几种解决办法。但连续多次失败后，它往往会默认采用“核弹选项”：删除并重新创建。数据就是这样丢失的。

我只会设置一个例外：为了实现基础设施自动化，允许它在服务器上使用 sudo。这很危险，但对于部署脚本来说是必要的。不过绝不能在生产环境中这么做。在生产环境里，我会创建特定的用户角色并明确定义权限。

编写代码从来都不是我在软件工程中最喜欢的部分。我真正关心的是构建解决问题的方案。AI 让我可以把更多时间花在这件事上，而不是消耗在样板代码上。

我只花了 7 小时，就构建出一个手动开发可能需要数周的交易系统。现在，我可以把时间花在完善策略上，而不是调试 Django model。这才是 AI 编程真正带来的价值：减少琐碎工作，把更多精力放在真正重要的事情上。

找一件你一直拖着没做、只是因为前期配置工作太多的事情。让 AI 生成整体结构，然后再把它变成真正属于你的东西。你很快就会弄清楚 AI 擅长什么，以及哪些地方需要自己介入。工具已经出现了，问题只在于：你是否愿意改变自己的工作方式。

如果你已经在使用 AI 编写相当一部分代码，也请在评论区分享你的经验：你采用的方法、使用的工具，以及从中学到了什么。

如果你喜欢这篇文章，并希望获得更多类似的见解，可以订阅我的 newsletter。每周的技巧、教程和故事都会直接发送到你的 inbox！

本文提到的工具

• Cursor——由 AI 驱动的代码编辑器。

• Claude Code——使用 Claude 实现基础设施自动化。

• Context7——为 AI Agent 提供文档访问能力。

• MCP Protocol——Model Context Protocol specification。

• Gram——MCP server 托管服务。

• Gareth Dwyer 的《Claude Code Is All You Need》——深入介绍基础设施自动化。

• MCP Quickstart Guide——MCP server 入门指南。

• Anthropic Prompt Engineering Guide——如何编写更好的 prompt。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。