从"给我写个工具"到"帮我发布博客"：我用 AI Agent 完成了一个完整项目
目录
- 缘起：我为什么尝试让 AI Agent 写代码
- 协作全程：从需求到下线的 6 个环节
- 经验一：需求说得越具体，AI 越省心
- 经验二：让 AI 自己发现并修复 Bug
- 经验三：UI 重构交给"有审美的 Agent"
- 经验四：文档输出是隐藏的超能力
- 几个仍然需要人类把关的坑
- 尾声：人机协作的正确姿势
1. 缘起：我为什么尝试让 AI Agent 写代码
我平时有一个坚持了很久的习惯：工具类小项目尽量自己动手，因为"自己写的才可控"。
但这次需求有点特殊——我要做一个纯离线二维码工具，功能不算难，但琐碎：编码解码、二维码生成、二维码解析、条形码生成与解析，外加一个能看的界面。全做完最少要大半天，而且大部分时间花在重复的样板代码上。
于是我做了一个决定：把"从 0 到 1"交给 AI Agent，把"从 1 到 10"留给自己。Agent 负责产出可运行的完整页面，我负责验收、提需求、review 和上线。
结果超出我的预期。这篇文章就是这次协作的完整复盘。
2. 协作全程：从需求到下线的 6 个环节
整个任务实际走过了 6 个环节：
| 环节 | 我的输入 | Agent 的产出 |
|---|---|---|
| 1. 需求描述 | 一句话 + 场景说明 | 完整单文件 HTML 页面 |
| 2. 元素优化 | “优化一下清空按钮” | 按钮新样式（含微交互） |
| 3. 主动诊断 | 无输入（Agent 主动发现） | 3 个潜在缺陷清单 |
| 4. Bug 修复 | “修复已知缺陷” | 修复后的代码 + 语法校验 |
| 5. 界面重设计 | “重新设计 UI，功能不变” | 全新视觉版本，功能零回归 |
| 6. 文档产出 | “写一篇技术博客” | 可直接发布的 Markdown |
我印象最深的是第三步——我没有要求"找 bug"，Agent 在读完代码后主动列出了一份"已知缺陷清单"，其中包括一个我完全没有察觉的异步时序问题。
结论先行：AI Agent 不是简单的"代码生成器"，如果使用得当，它可以扮演编码者、代码评审、视觉设计师、文档工程师四个角色。
3. 经验一：需求说得越具体，AI 越省心
给 AI 的第一条指令，我原话是：“我要做一个二维码工具。”
跑出来的页面确实能用，但和"我想要"有差距。后来我把需求补全为：
纯离线运行、单 HTML 文件、包含 URL 编码/解码、二维码与条形码的生成和解析，界面风格统一。
同样的能力，产出的质量立刻上了一个台阶。
结论：与 AI 协作，本质是"把隐含假设显式化"。它不像人那样会追问，所以约束条件（离线、单文件）、验收标准（能跑通）、边界场景（图片格式、空输入）越早说明，返工越少。
4. 经验二：让 AI 自己发现并修复 Bug
开发到中后期，Agent 在 review 自己生成的代码时，提出了一条让我印象深刻的诊断：
new Promise(...)只是声明了异步流程，后续代码在图片加载完成前就执行了，canvas.width会是 0，解析必然失败。
我当时的第一反应是"这么隐蔽的坑它怎么知道的"。但仔细想想，这正是 AI Agent 的价值：它能以"评审者"的视角回看自己生成的代码，而人类开发者很难对自己刚写的代码保持同样程度的怀疑。
更关键的是，Agent 修复后会自动做验证：
node -e "..." # 语法校验通过
修复不再是"我觉得好了"，而是"我用工具确认好了"。这种 修复 → 验证 → 输出结论 的闭环，极大地减少了人的重复试错。
5. 经验三：UI 重构交给"有审美的 Agent"
界面环节我提了一个开放式需求：“重新设计 UI，功能保持一致。”
Agent 没有沿用常见的白色渐变模板，而是挑选了一条明确的视觉路线——暗色精密风格（Linear Aesthetic），并给出了和原版逐项的对比：
| 维度 | 原版 | 重构后 |
|---|---|---|
| 基调 | 白底 + 紫蓝渐变 | 深色 + 微光晕，工具感更强 |
| 布局 | 竖排堆叠 | 2×2 Bento 卡片网格 |
| 反馈 | 底部一次性状态栏 | 顶部常驻状态胶囊 + 呼吸圆点 |
| 按钮 | 同质化 | 主操作/次操作/危险操作三级分层 |
我几乎没有返工。原因在于它把"设计决策"作为产出的一部分显式呈现给我，而不是默默改完再说。这让"审美"成为可评审的对象。
6. 经验四：文档输出是隐藏的超能力
整个协作中最让我意外的一环是最后一步——写作。
我说：“写一篇博客分享技术心得。” Agent 基于项目真实的代码和踩坑记录，产出了一篇带标题、摘要、标签、目录、代码块、配图占位的完整文章。它引用的代码和修复前后对比，都是项目中真实存在的，不是编造的。
对于"写博客"这类任务，AI Agent 的独特优势是：它既了解代码，又能组织成面向人的叙事。传统方式里"开发"和"写作"是两次完整的上下文切换，在 Agent 这里只是一条指令。
7. 几个仍然需要人类把关的坑
AI Agent 很强，但它不是万能的。这次协作中我明确观察到以下边界：
- 环境依赖仍需确认：Agent 生成页面依赖
qrcode.min.js等库，这些库文件得确保已存在，AI 不会帮你下载； - "沉默的成本"需要提示：有些设计选择（比如把功能合并成 Tab）如果不是看它的对比说明，我可能注意不到行为变化；
- 它擅长的范围有边界：让它问"实时天气"这类需要外部数据的能力，它的工具集里没有就得明确告诉你，而不是编造结果；
- 最终验收是人的责任：AI 能跑语法校验，但"这个交互是否顺手""这个配色是否喜欢"最终仍是我的判断。
一句话总结：AI Agent 是不错的执行者、不错的构想过，但它是一个"顺从不质疑"的专家。你需要扮演产品经理和测试经理。
8. 尾声：人机协作的正确姿势
这次项目的最大收获，不是"AI 帮我写了个工具"，而是我验证了一套可复用的人机协作流程：
明确约束 → 交给 Agent 实现 → 让它主动 review →
修复并验证 → 重构体验 → 沉淀文档
在这条流水线里，我的角色不是"打字员"，而是需求定义者、验收者、决策者和把关人。AI 负责把"想法"变成"作品"，我负责告诉它"作品该长什么样"。
如果你也在犹豫"要不要让 AI 参与我的项目"，我的建议是：挑一个小而完整的任务试一次。你会发现的不是"AI 替我做了一切"，而是**“原来我可以把时间花在真正需要人的判断力的事情上”**。
- 点赞
- 收藏
- 关注作者
评论（0）