在上一篇文章里，我豪言壮语地说要“Build in Public”。今天，是时候兑现承诺了。

作为一名产品经理（PM），我过去的工作是动嘴皮子和画原型图，然后把文档甩给开发。但当我决定做一名“独立开发者”时，我发现——没人可甩了。

我的第一个练手项目是 “StoryGlint（小说大纲助手）” 的一个核心模块：角色一致性检查器。 痛点很明确：写长篇小说时，经常写着写着就把配角的瞳色搞错了，或者把反派的性格写崩了。我想做一个工具，能自动扫描章节，对比人设卡，指出不一致的地方。

听起来很简单，对吧？ 然而，现实给了我三记响亮的耳光。

第一关：不仅要会写代码，还要会修环境

我在 Google Cloud 的 Vertex AI Workbench 上搭建了开发环境。我以为有 AI 辅助写代码（Code Generation），我只需要负责复制粘贴。

现实是：AI 写的代码是对的，但环境是错的。

前几天，在调试 Gemini CLI 工具时，我一直遇到一个诡异的报错： TypeError: fetch failed 以及随后的 400 INVALID_ARGUMENT。

如果我有技术合伙人，我此时应该在 Slack 上 @他 骂街了。但现在，我只能盯着那个黑底白字的终端发呆。 我不得不花了一整天时间去查文档、去 Stack Overflow 翻答案，最后发现是 API 调用参数格式的问题，以及本地网络代理的配置冲突。

启示： AI 可以帮你写出逻辑完美的 Python 函数，但它无法帮你解决“网线没插好”这种物理世界的环境问题。作为独立开发者，Debug 环境的能力比写算法更重要。

第二关：数据灾难与“时光倒流”

1 月 24 日那天，我经历了一个所有开发者的噩梦：误删代码。

在一次重构文件目录时，我手滑覆盖了核心的逻辑文件。更糟糕的是，我当时还没来得及推送到 GitHub。 看着瞬间变空的代码框，我脑子里一片空白。

那一刻，我被迫学会了如何使用 Google Cloud 的快照功能。我疯狂地搜索“Vertex AI Workbench restore version”，在经过惊心动魄的半小时操作后，终于把项目回滚到了三天前的版本。

启示： 也是从那天起，我养成了每写完一个功能就 git commit 的肌肉记忆。数据备份，是比代码质量更底层的生存法则。

第三关：PM 的“贪婪” vs 开发的“贫穷”

作为 PM，我的职业病是“既要又要”。 在设计 MVP（最小可行性产品）时，我列了一堆功能：

  • 支持 PDF/Word 上传
  • 自动提取 50 种人设维度
  • 支持多语言…

但作为（菜鸟）开发，我的能力预算只有“1”。 当我试图把所有功能都塞进去时，代码逻辑变得无比复杂，Token 消耗量爆炸，运行速度慢得像蜗牛。

最后，我不得不挥刀自宫，砍掉了 90% 的功能。 MVP 最终只保留了一个按钮：粘贴纯文本 -> 输出不一致的句子。

没有 PDF 解析，没有多语言。但它能用，而且跑得通。

启示： 以前做 PM 讲究“完美闭环”，现在做独立开发讲究**“单点突破”**。一个丑陋但能解决问题的工具，胜过一个华丽但跑不起来的系统。

四、 成果与反思

经过一周的折腾，这个简陋的“角色一致性检查器”终于能在我的本地跑通了。

虽然它经常误报，虽然 UI 界面还是原始的命令行，但看着它第一次准确地指出：“警告：第二章里你说主角不吃辣，为什么第五章他点了一份麻辣火锅？” 那种成就感，比我以前在大厂发布一个百万级用户的版本还要强烈。

写给想动手的你：

  1. 别怕报错： 每一个红色的 Error，都是你进阶的台阶。
  2. 拥抱 AI，但别依赖 AI： 它可以是你的副驾驶，但方向盘必须在你手里。你必须理解代码的逻辑，否则出错时你连怎么问都不知道。
  3. 先完成，再完美： 烂代码上线了也是产品，好代码躺在硬盘里只是字节。

下一步： 既然工具跑通了，下一篇博文，我想聊聊**“商业化”。既然是“一人公司”，这玩意儿怎么赚钱？是收订阅费，还是卖 API？ 我也在思考关于支付渠道**的问题（比如最近在研究的跨境支付成功率），希望能找到一个对中国开发者友好的方案。

敬请期待。

P.S. 如果你也遇到过 Gemini API 的 400 错误，或者在 Google Cloud 上踩过坑，欢迎在评论区留言，我们可以以此建立一个“避坑互助小组”。