AI辅助开发实战：打造PDF合并工具并实现变现

1. 为什么是“AI辅助开发”和“PDF合并工具”这个组合

先说结论：AI辅助开发最适合的项目类型，不是那些“看起来很酷”的大系统，而是需求明确、逻辑闭环、用户能立刻感知价值的小工具。MergePDF-Pro 就是这样一个典型样本——它只有一个核心功能“把多个PDF合并成一个”，但覆盖了从需求分析、技术选型、编码调试、打包分发到变现上线的完整闭环。用这个案例讲AI辅助开发，是因为它足够简单，简单到你可以在一个周末跑通全流程；同时它又足够完整，完整到你能体验AI开发中几乎所有关键环节：让AI帮你写代码、让AI帮你排查bug、让AI帮你做界面、让AI帮你生成打包配置，甚至让AI帮你写商品文案。

说实话，我见过太多人一上来就想用AI做一个“颠覆行业”的产品，结果Prompt写了一屏，AI生成了一堆架构图，自己却连第一步都跑不起来。真正务实的做法是反过来：先锁定一个足够小的痛点，再让AI帮你把所有脏活累活干完。为什么选PDF合并？因为PDF处理是一个永远不会过时的高频需求，无论是学生交作业、职场人整理资料、还是HR收集简历，几乎每天都有大量需要合成PDF的场景。而且市面上的PDF工具要么收费贵、要么带水印、要么需要联网上传，一个轻量、本地、免费的桌面工具天然就有用户愿意下载。

从变现角度来说，工具类应用可能是最适合个人开发者的品类。没有库存、没有物流、没有客服压力，你的边际成本几乎为零。只要工具真的好用，用户口碑会自然扩散。MergePDF-Pro 的思路很简单：免费版提供基础合并功能，Pro版解锁批量拖拽排序、自定义输出目录、加密PDF支持等高级特性，用一次性买断的方式变现。这套模式在国内外都有大量成功案例，也是我想通过这篇文章完整展示的一条可行路径。

这篇实战记录适合谁看？如果你有基本的编程概念（哪怕只会一点Python或Java），想试试用AI辅助开发做出自己的第一款软件；或者你已经是程序员，但想知道怎么用AI把开发效率再翻几倍；又或者你完全没有编程基础，只想验证“AI能不能帮我做个能卖钱的工具”——这篇文章都能给你一套可以直接照搬的流程和方法。

2. 项目整体设计与技术选型思路

2.1 核心技术路线：Python + pypdf + Tkinter + PyInstaller

选技术栈这件事，如果是传统开发，可能需要纠结很久。但AI辅助开发有一个隐藏优势：你不需要选“最佳技术栈”，你要选的是“AI语料最充足、生成质量最稳定”的技术栈。Python毫无疑问是当前AI辅助编程的首选语言，因为全球海量的开发者都在用Python写脚本，AI模型见过的Python代码远超其他语言，生成质量自然更高。

具体到PDF合并这个场景，核心库我选了 pypdf，它是老牌 PyPDF2 的继任者。这里有一个很多人容易踩的坑：PyPDF2 在2022年后基本停止新功能开发，pypdf 才是活跃维护的分支，API更干净、文档更全，AI也更容易生成正确用法。用 pypdf 做合并本质上就两步：读取源文件，然后逐个把页面append到新文件中，核心代码不超过二十行。

界面层用了Tkinter，这是Python自带的GUI库，不需要额外安装。可能有人会问：为什么不选PyQt、PySide这种更漂亮的框架？原因有两个：第一，Tkinter是Python标准库，用户机器上装Python就有，打包时体积也更小；第二，AI对Tkinter的理解非常成熟，因为它出现在无数教程和开源项目里，AI生成的Tkinter代码几乎没有语法层面的错误，这能极大降低AI开发中“改bug改到怀疑人生”的几率。

打包分发选PyInstaller，原因更直接——它是Python桌面应用打包的事实标准，AI对其参数了然于胸。我可以直接在Prompt里让AI生成打包命令和spec文件配置，生成结果基本可以直接执行。

2.2 功能清单与用户价值排序

项目规划阶段，我没有自己去罗列功能，而是先问了一个问题：用户会用这个工具做什么？想清楚这个问题，功能自然就有了。模拟一下真实用户的路径，应该是：打开软件，把PDF文件拖进去，排好顺序，点一下按钮，就拿到合并后的文件。

所以第一版核心功能只保留四件事：支持多文件拖拽导入、支持列表排序、支持批量或单个合并、合并完成后自动打开输出目录。其他花哨的功能比如OCR、压缩、拆分，一概不做，因为每多做一件事，就多一分AI生成代码出错的概率，也拖延了产品上线的时间。

Pro版功能怎么定？我定位的是两类用户需求：一类是高频使用场景的刚需，另一个是办公场景中的常见痛点。于是加入了批量文件序号重命名、输出目录自定义、加密PDF合并支持。这三个功能各有明确的付费理由：第一个帮你省时间，第二个让你保存文件更顺手，第三个则是真正卡脖子的需求——很多人电脑里的PDF是有密码保护的。

2.3 为什么这个项目适合跑通AI辅助开发的完整链路

说实话，如果纯粹为了做一个PDF合并工具，没必要写这么多分析。但既然是拿这个例子来演示AI辅助开发的完整流程，就要看这个项目是否覆盖了所有关键环节。我复盘了一下，MergePDF-Pro 的完整链路覆盖了五个阶段：需求定义（想清楚做什么）—> 技术选型（跟AI商量怎么做）—> 编码实现（让AI写代码）—> 测试修复（让AI调试问题）—> 打包发布（让AI辅助配置环境）。每一个阶段在AI辅助开发中都有完全不同的方法和要点，所以这个项目非常适合当教学案例。

更重要的是，这个项目“失败成本”极低。如果AI生成的代码有问题，不会影响到线上服务，不会损失付费客户，最多就是在本地多跑几次，把bug暴露出来再进行修复。这种低风险的环境特别适合第一次尝试AI开发的朋友，可以放心大胆地让AI按各种思路改代码，直到跑通为止。

3. 用AI从0到1搭建项目的实操细节

3.1 第一轮Prompt：先写需求文档，而不是代码

很多人用AI写代码的失败经历，都源于同一个错误：第一句话就让人家直接生成完整代码。AI确实能生成，但生成出来的大概率是个六边形战士——什么都有，什么都不精，而且一旦出错，你根本不知道从哪里下手排查。

正确做法是先让AI帮你写需求文档和开发计划。我自己在实际操作中会用一个固定句式：我准备做一个XX软件，目标用户是XX，核心功能是XX，请帮我写出功能清单、技术选型建议、开发步骤和每步的验收标准。这样一轮对话下来，你手里就有一份可以执行的开发路线图了。

我当时给AI的Prompt大致是这样的：我正在开发一个Windows桌面应用MergePDF-Pro，它的功能是将多个PDF文件合并为一个PDF，目标用户是需要处理日常文档的普通办公人员。请先帮我做技术选型，对比Python和C#的优劣，然后列出这个项目从0到1的完整开发步骤，每个步骤都要有明确的交付物。这一步主要是借AI的行业知识做决策，而不是让它直接写代码。

AI给出的建议和我预期基本一致：用Python + pypdf + Tkinter，开发步骤分为环境准备、核心功能实现、UI打磨、打包测试四个阶段。它还额外提示了一点，让我走了不少弯路——Python版本建议用3.10或更高，避免某些旧版解释器和pypdf新版本之间的兼容问题。

3.2 环境准备与项目初始化

环境这块没有太多悬念，装好Python 3.11，创建一个虚拟环境来装依赖，这里我让AI直接把环境准备命令写给我。AI给出的命令是：

bash复制python -m venv venv
venv\Scripts\activate
pip install pypdf pyinstaller

这里有一个实操细节值得说：一定要用虚拟环境。如果不建虚拟环境，PyInstaller打包时会把系统里所有无关的包都塞进exe，体积会大得离谱，而且可能出现依赖冲突。使用虚拟环境之后，打包的时候只会引入当前项目真正用到的库，体积小、问题少。

项目结构也很简单，AI给了一个标准的单文件起步方案：

text复制MergePDF-Pro/
│── main.py              # 程序入口与GUI逻辑
│── pdf_merger.py        # PDF合并核心逻辑
│── requirements.txt     # 依赖清单
│── build.spec           # PyInstaller打包配置

为什么要把核心逻辑拆成单独文件？因为AI刚开始生成的代码经常需要调试，如果GUI代码和业务逻辑全塞在一起，改一个功能可能要滚动几十行，而且AI在修改时也容易把无关代码改坏。拆开之后，核心的合并功能可以单独用命令行测试，大大提高调试效率。

3.3 让AI写出高质量代码的Prompt小技巧

经过这个项目，我总结出给AI写代码Prompt的三条核心经验，可以算是我自己在AI辅助开发中摸索出来最实用的方法。

第一，要给AI一个“角色和场景”。不要让AI觉得自己在真空里写代码，而是告诉它“你是一名有经验的Python桌面应用开发者，正在为用户开发一个简单的PDF工具”。这样做的好处是AI会更注意代码规范和边界处理，而不是只输出一个能跑的demo。

第二，要求AI“标注注释说明意图”。很多AI生成的代码几乎没有注释，出问题了完全看不懂。在Prompt里明确要求AI给关键代码加中文注释，而且注释要解释为什么这么写，而不是重复代码本身。这样即使用户不熟悉这段代码，也能快速理解逻辑。

第三，把验收标准写在Prompt里。比如告诉AI“合并后的PDF必须保持原始文件顺序”“拖拽时要能正常显示文件路径”“合并不成功时要弹出明确错误提示，而不是静默失败”。AI写代码时会更注意这些功能的实现，而不是只顾着完成主流程。

4. 核心模块实现与问题复盘

4.1 合并逻辑的实现与处理边界

PDF合并的核心代码，pypdf实现起来确实非常简单。AI交付的第一版长这样：

python复制from pypdf import PdfReader, PdfWriter

def merge_pdfs(pdf_list: list[str], output_path: str):
    writer = PdfWriter()
    for pdf_path in pdf_list:
        reader = PdfReader(pdf_path)
        for page in reader.pages:
            writer.add_page(page)
    with open(output_path, "wb") as f:
        writer.write(f)

这段代码功能上没问题，但实际用起来会暴露几个问题。第一个是有密码保护的PDF会抛异常，这要求我加上解密判断，第二是如果PDF文件损坏或格式异常，这个逻辑会直接崩掉进程，需要让AI加上异常捕获。我把问题抛回给AI：“如果其中一个PDF有密码怎么办？如果一个文件已经损坏怎么办？”AI很快就给出了修正版，加入了try/except和密码检测逻辑。

这其实是AI辅助开发中很关键的一个工作方式：AI负责写正向流程，而人类负责追问边界情况。AI不会主动考虑各种异常可能，但如果你把它当作一个“可以无限快速迭代的同事”，不断问它“如果XX怎么办”，它就能把边界补得很完整。这一点用熟之后，AI产出代码的健壮性甚至比不少初级程序员还要好。

4.2 GUI界面的设计思路与实现

GUI这块是AI辅助开发最热闹的地方，因为写GUI是纯体力活。Tkinter的代码量不小但模式化很强，非常符合AI的强项。我先让AI做了一个基础版本：顶部是文件列表，中间是导入和移除按钮，底部是合并按钮和进度条。

功能倒是很快做出来了，但视觉效果只能用“能用但不好看”来形容。后来我想明白一件事：对于面向普通用户的桌面应用，视觉效果直接影响用户对软件专业度的判断。于是我没有让AI继续在原生Tkinter里折腾，而是让AI帮我在网上找开源美化方案——实际就是问问它是否听说过ttkbootstrap这个库，它能让Tkinter界面现代化。

换用ttkbootstrap后，按钮有了圆角、主题色，列表也有了网格线，整个软件看起来像模像样。这里有一个经验：AI辅助开发时不要接受AI第一次给出的默认方案，随时问一句“有没有更好看的方案”，AI会给你很多意想不到的选择。

在线程处理方面，这里有一个Tkinter老手都知道的坑。合并大量PDF时如果把耗时操作直接放在主线程，界面会卡死，用户会以为程序崩溃了。我让AI用threading模块把合并操作放到后台线程，进度条通过queue队列和主线程通信，在运行中随时能显示进度。AI生成的这版代码结构很标准，稍加修改就能复用。

4.3 一次真实bug排查：中文文件名与路径异常

打包后的exe发给朋友测试，结果他反馈说“合并带中文文件的PDF时总是失败”。这个问题在我的开发环境里并没有出现，但朋友是在中文Windows环境下运行的，而我在macOS开发时确实没办法完全模拟Windows的中文路径行为。

我把报错截图发给AI，AI很快指出：Windows控制台默认编码可能是GBK，而Python在处理字符串时如果直接打印非UTF-8字符就可能出现编码错误。解决办法是设置环境变量PYTHONUTF8=1，或者在代码开头强制设置：

python复制import sys
if sys.platform == "win32":
    import io
    sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')

在PyInstaller打包spec里加上一句话，让程序运行时自动设置UTF-8模式，这个问题才算彻底解决。这段排查经历让我意识到，在AI辅助开发中，人并不是完全没活干，你最核心的任务是帮助AI理解实际用户环境里才能暴露的问题，然后引导AI给出修复方案。

4.4 核心异常类型速查表

我在整个开发中遇到了不少问题，整理成一个速查表，给后来的人省点时间：

排查这些问题时，我的习惯是每次看到异常信息，先把原始报错完整地复制给AI，让AI先解释报错含义再给修复方案，而不是自己猜。AI对于异常报错的解释能力相当出色，基本是专家级的。

5. 打包发布与产品化的关键环节

5.1 PyInstaller打包的完整配置与避坑要点

将代码打包成Windows可执行exe是桌面应用从代码到产品的最后一公里。我给AI下达需求：请帮我生成一个PyInstaller的spec文件，要求包含项目图标、排除不需要的模块、生成单文件模式。AI给出了一份配置，我做了几处调整后，关键参数如下：

python复制# build.spec
a = Analysis(
    ['main.py'],
    pathex=[],
    binaries=[],
    datas=[],
    hiddenimports=['ttkbootstrap', 'pypdf'],
    hookspath=[],
    runtime_hooks=[],
    excludes=['numpy', 'pandas', 'matplotlib'],
)
pyz = PYZ(a.pure)

exe = EXE(
    pyz,
    a.scripts,
    a.binaries,
    a.datas,
    name='MergePDF-Pro',
    debug=False,
    strip=False,
    upx=True,
    console=False,
    icon='assets/icon.ico',
)

用这份spec文件，打包命令为：

bash复制pyinstaller build.spec --clean

这里几个参数非常关键。console=False表示不弹出命令行窗口，否则用户每次打开软件都会看到一个黑框，极其掉价。icon='assets/icon.ico'给程序定制图标，这是产品专业度的基本要求，一个没有图标的exe一看就让人觉得不靠谱。excludes把用不到的重量级库排除了，我们这里排除了numpy、pandas等，目的就是降体积。实测下来，排除前exe是68MB，排除后直接降到18MB，对用户下载转化率的影响是实实在在的。

还有一个高频坑：很多杀毒软件会把PyInstaller打包出的exe误报为木马，因为这个打包机制确实会被很多恶意软件利用。这个问题没有100%的解决方案，但实测对比发现，用UPX压缩后的exe误报率反而更高，所以如果有条件，可以关闭upx=True，再用正规代码签名证书签名。个人开发者可以申请一个OV代码签名证书，虽然需要一笔年费，但对下载转化率影响很大。

5.2 产品信息与帮助文档生成

产品要有名称、版本号、公司信息、界面文字、用户协议。这些AI都能帮上大忙。我让AI帮我拟了软件内的所有文案，包括按钮文字、错误提示、关于弹窗。AI生成后我过了一遍，把一些过于机器人味的文案改成更口语化的表达。

这里最有价值的是让AI生成“用户帮助文档”和“常见问题FAQ”。虽然这只是一个小工具，但帮助文档的存在能显著减少用户的困惑和售后问题。AI生成的FAQ初稿质量很高，涵盖了安装问题、使用问题、兼容性问题，我再根据实际反馈补了两条进去。整个产品化包装过程大概只花了一个小时，如果没有AI帮我起草，光写这个文档可能就要半天。

5.3 从本地工具到“可卖的产品”还需要什么

把代码打包成exe只是产品化的起点。要让用户愿意付费，还需要解决以下几个问题：软件图标和视觉风格要统一，安装包要放在一个可信的下载渠道，需要有收款方式或授权码机制，需要制定价格和版本策略。

授权码机制我这里用了一个很轻量的方案：Pro版在启动时要求输入授权码，授权码由我这边的小程序生成，基于一个固定密钥对机器码做HMAC签名。用户在下单时把机器码发过来，我生成一个授权码发给用户，程序本地验证签名后就解锁Pro功能。这个方案不依赖网络，也不需要服务器，实现成本很低，但对用户来说已经足够正规了。

具体代码大概是这样的：

python复制import hashlib
import hmac

SECRET_KEY = b"your-secret-key"

def get_machine_code():
    # 根据主机名+MAC地址生成机器码（简化版）
    import uuid, socket
    raw = socket.gethostname() + str(uuid.getnode())
    return hashlib.md5(raw.encode()).hexdigest().upper()

def generate_license(machine_code: str) -> str:
    mac = machine_code.upper().replace("-", "")
    sig = hmac.new(SECRET_KEY, mac.encode(), hashlib.sha256).hexdigest()[:24]
    return f"{mac[:8]}-{mac[8:16]}-{sig[:8]}-{sig[8:16]}"

def verify_license(machine_code: str, license_code: str) -> bool:
    expect = generate_license(machine_code)
    return hmac.compare_digest(expect, license_code)

这个方案的主要作用是防止随机乱填，不能防止技术高手逆向破解，但对于个人工具类应用来说，已经足够形成付费边界了。我对这个方案的理解是：正确定价的核心是让“顺手付费”变得足够方便，而不是把破解做得足够难。所以别把精力花在加密对抗上，把精力花在产品体验和触达渠道上更划算。

6. 变现路径与渠道运营实战

6.1 定价策略与版本区分

价格这个东西，我一直觉得是想清楚了就能定。工具类软件有一个经典的定价区间：免费版引流、低配版跑量、Pro版盈利。参考市面同类工具，PDF合并类软件的付费区间在19到69元之间比较容易被接受，我最后定了29.9元买断，并承诺后续版本免费升级。

为什么不定9.9元？因为如果定价过低，用户反而会怀疑软件质量，觉得是不是哪里有问题才卖这么便宜。29.9元这个价位既能体现产品价值感，又处于大多数用户“顺手就能付”的心理区间。实际上跟我预期的差不多，第一批用户里反馈最多的竟然是“本来还以为要更贵”。

免费版和Pro版的区分核心在于：免费版必须足够好用，让用户愿意下载；Pro版则要有足够的附加价值，让用户觉得付费是值得的。我的免费版只提供基础的追加合并、固定输出目录功能；Pro版增加了自定义输出目录、拖拽排序、批量重命名输出文件和加密PDF支持。在实际用户反馈中，拖拽排序和自定义输出目录这两个功能是付费的主要理由，这验证了产品设计里“高频需求做付费点”的思路是对的。

6.2 分发渠道与推广方式

对于独立开发的桌面应用，分发渠道基本决定了你的用户从哪里来。国内的话，常见渠道包括：

• 网盘下载+扫码支付：适合起步期，缺点是网盘链接容易失效，体验一般
• 个人官网下载+当面付或收款码：适合有一定技术能力的开发者，体验可控
• 软件下载站：如一些老牌下载站，能带来自然流量，但要注意下载站会捆绑全家桶的风险
• 开源平台/社区+赞助链接：适合愿意走开源路线的开发者，靠影响力变现
• 视频平台教程引流：在短视频平台发一个小教程，展示软件可以解决什么问题，然后在简介放下载链接

我自己是从网盘和官网双通道开始的。官网用GitHub Pages搭建了一个极其简洁的落地页，介绍一下功能、放两个截图、列出下载按钮，然后把收款二维码放在授权码购买区。整个过程没有花钱投广告，第一批流量几乎全部来自我在一些办公软件交流群里分享的免费使用体验。

有个经验想多说一句：这类工具型软件最适合的推广方式是“场景化内容”。不要干巴巴地发一个“好用的PDF合并软件”，而是写一个具体场景“如何把5个PDF合并成一个，30秒搞定”，让用户看完觉得“这正好是我的需求”，然后给出软件下载方式。这种内容最直接也最高效。

6.3 用户反馈驱动迭代：不要闭门造车

第一批用户开始使用后，我建立了一个简单的用户反馈渠道：软件里的“用户反馈”按钮是一个邮件链接，官网留了微信联系方式。用户反馈里最有价值的不是那些功能建议，而是“我在什么情况下用时报错了”这类真实环境信息。

举例来说，有一个用户反馈的是：他从财务系统导出的PDF页面大小不一致，合并后页面尺寸错乱。这个问题我在开发时完全没有考虑到。通过AI协助，我用pypdf的page.scale_to为每次添加页面时做尺寸归一化处理，加了一个“统一页面大小”的选项。这个功能后来在Pro版的宣传文案里成了核心卖点。所以，产品迭代一定要听用户的真实需求，而不是自己坐在那里闷头设计功能。

还有一次，一个用户反馈他希望选择多个PDF时，能按文件名自然排序，而不是按字母排序。这里涉及一个经典排序问题：文件名的数字部分应该按数值比较，而不是按字符串比较。AI帮我生成了一段自然排序的算法，还处理了类似“第1章”和“第2章”这种混合文本场景。这类细节功能面世后，带了很多口碑传播，很多用户就是因为这些“小而实用”的细节而推荐给同事的。

7. AI辅助开发的核心心法与Limits认知

7.1 人和AI的正确分工：你把关需求，AI负责执行

做完MergePDF-Pro这个项目，我对AI辅助开发的本质有了一个更清晰的认知：AI是一个极其擅长执行、但不太会主动思考“为什么”的超级助理。它的强项是快速生成代码、查找资料、解释报错、给出多种方案；它的弱项是不知道你的真实用户是谁，不知道你的商业目标是什么，更不会替你判断哪些功能该做、哪些不该做。

所以在AI辅助开发中，人最重要的职责是“定义问题和验收结果”。你越是能把需求描述清楚，AI就越是能把代码写得贴合需求；你越是能设计好验收标准，AI就越是不容易跑偏。我甚至养成了一个习惯：每次让AI做一件事之前，先用两句话告诉自己“我到底要它解决什么问题”，想不清楚就先别开工。

7.2 AI代码的三大常见问题与应对方式

用AI写了这么多代码，踩过很多坑，总结出AI生成代码最常见的三个问题。

第一，AI会一本正经地胡说八道。比如使用一个不存在的API函数，或者混用两个不同库的语法。这种情况在写业务逻辑时不多见，但在使用冷门库的最新版本时发生率极高。应对方式只有一种：每生成一段代码，先跑一个最小化示例验证，再集成到主程序。

第二，AI写的代码不够健壮。AI的默认输出是理想路径：输入正常它就能工作，输入不正常它就崩溃。所以在让AI写代码时，要养成追加条件“请把所有异常情况处理好并给出友好提示”的习惯，能显著提高代码质量。

第三，AI对项目上下文的理解会漂移。同一个会话里，可能一开始AI理解得很清楚，但聊了50轮之后它可能会忘记最初的需求，生成与目标无关的代码。应对方式是定期让AI总结当前项目状态：请总结一下我们现在已经完成的功能、正在做的任务和下一步计划。这段话相当于给AI做一次checkpoint，能把漂移的AI拉回正轨。

7.3 AI辅助开发的正确心态

最后想聊一点心态层面的东西。很多人试过用AI写代码之后，要么过度乐观，觉得程序员要失业了；要么过度失望，觉得AI写的就是垃圾。这两种极端心态我都有过，但做完MergePDF-Pro后，我的感受更接近一个朴素的判断：AI辅助开发真正的价值不是替代人，而是放大人。它给人节省了大量的“找资料、写模板、调错配置”的时间，让你可以把精力集中在真正需要判断力和审美的地方——比如产品怎么设计、用户会怎么用、代码结构怎么维护。

一个很直观的对比是：传统开发中，我做一个这样的桌面工具至少需要三到五天；AI辅助开发下，第一版只用了三个小时，后续打磨迭代用了三个晚上。效率提升是数量级的，但这里的前提是我知道这个工具该怎么设计、用户需要什么功能、代码会在哪里出问题。AI做的，是让我“想清楚”之后不必自己动手敲每一个字。

我个人在实际操作中还有个体会：AI辅助开发这个能力，和所有技能一样，用进废退。你用得越多，就越了解怎么问它它才听得懂，越了解它容易在哪里犯错，也就越能发挥它的优势。MergePDF-Pro只是我的第一个实验品，但这个开发模式我已经在持续使用，在后续的许多小工具和个人项目中，它始终让我以一个很小的成本，把一个想法快速变成用户愿意使用的东西。

最后再分享一个小技巧。如果你准备尝试用AI开发自己的第一个小应用，别从那些“太简单”的Hello World开始，也别从“太复杂”的全栈系统开始，找一个自己工作生活中确实会频繁用到的痛点工具，比如文本批量处理、文件整理、小报表生成、本地格式转换，把这些做出来、用起来、分享出去。你会发现，AI辅助开发的回报率远超你的预期。