作为软件工程师，我一直以为，如果有一天我做了自己的产品，最难的部分会是把它做出来。
架构、认证、离线支持、同步、移动端发布、基础设施、AI 集成。这些是我们花好几年才学会的东西。
结果我发现，我之前几乎完全想反了。
过去几个月，我一直在开发 BubSync，一个共享的婴儿追踪和日记应用，目的是帮助父母、家人和看护人保持同步。
而这段经历给我最大的教训是：
做软件本身是最容易的部分。围绕软件去建立一门生意，则要难得多。
AI 已经彻底改变了开发软件的成本结构。
但它没有改变"让任何人关心你的产品"的成本结构。
想法
BubSync 的起点是一个很简单的问题。
婴儿追踪应用确实有用，但很多应用都是围绕单一主要用户来设计的。
现实生活并不是这样。
一个家长记录喂奶。另一个家长哄孩子入睡。祖父母下午帮忙照看一下午。总会有人需要知道孩子上一次睡觉是什么时候，白天发生了什么，或者奶瓶是不是已经喂过了。
我想围绕这样一个想法来构建产品：
养育一个孩子需要一群人。软件应该让这一群人保持同步。
这就是 BubSync 诞生的原因。
这个应用渐渐加入了共享活动追踪、喂养记录、睡眠记录、尿布记录、回忆记录、看护人交接，以及一个基于全家自身数据的 AI 层。
从工程角度看，要做的内容相当多。
但我的构建方式和一两年前做副项目的方式，已经完全不同了。
AI 彻底改变了开发环节
我开始用 GitHub Copilot 大量辅助开发 BubSync。
一开始，它感觉就像拥有一个特别好用的自动补全。
后来我开始把更大的任务交给它。
生成这个组件。
写这些测试。
重构这个服务。
帮我理解为什么会出现这个 React Native 的行为。
搭建 API 端点。
写基础设施配置。
开发循环变得快了很多。
后来，我把相当大一部分开发流程转移到了 Claude 上，这种变化变得更加明显。
我不再是一个文件一个文件地工作，而是越来越多地按意图来工作。
我会描述我想要的东西，提供周边的架构和约束，让 AI 实现其中很大一部分，然后由我来审查、测试、迭代。
这并不意味着就不需要工程知识了。
恰恰相反，经验丰富的开发者反而收获更多，因为你仍然需要知道：
-
这个架构是否合理
-
这个实现是否安全
-
这个抽象是否恰当
-
哪些边界情况被漏掉了
-
什么东西该建、什么东西不该建
-
生成的代码是否真的解决了底层问题
但它改变了精力投入的地方。
我花在物理产出代码上的时间变少了，更多时间用在设计系统、审查实现和把握产品方向。
对独立开发者来说，这强大得不可思议。
但它也制造了一个危险的错觉。
你会开始想：
"如果我能很快把它建出来，那我就能很快把它变成生意。"
这是两件完全不同的事。
然后，你做完了这个产品
总有一天，你会到达一个奇怪的节点。
应用能跑了。
也许并不完美。软件永远没有真正完成的时候。
但它能跑了。
而且作为工程师，你有一种天然的本能，想要不断改进它。
再加一个功能。
重构点什么。
提升性能。
修复那个影响你还没有的 0.2% 用户的边界情况。
因为写代码是舒服的。
你清楚怎么做。
这时，你才意识到那个让人不舒服的真相：
没有人知道你的产品存在。
就在这一刻，BubSync 从一个个软件工程项目，变成了一件大得多的东西。
你需要一个线上形象
"我就做个落地页嘛。"
听起来挺容易。
直到你开始问问题。
大标题该写什么？
你到底在解决什么问题？
网站应该描述功能，还是讲述结果？
你该怎么展示可信度？
该用哪些截图？
行动号召应该是什么？
用户应该立刻下载应用，还是先了解更多？
谷歌期望看到哪些页面？
你需要定价页吗？功能页？对比页？FAQ？
突然之间，网站本身变成了一个产品。
而且和开发应用不同，这里不一定有一个等你去实现的标准答案。
你必须做判断。
然后再去衡量这些判断到底对不对。
然后是应用商店
我之前也做过移动应用。
但以一家真实企业主的身份去发布，是另一回事。
有证书。
预置描述文件。
开发者账户。
商店元数据。
隐私声明。
订阅配置。
针对多种设备尺寸的截图。
应用描述。
关键词。
内容分级。
测试轨道。
审核指南。
测试版发布。
正式版发布。
然后你提交。
就在这一步，另一个人类来判定，你是否把所有规则都理解对了。
如果被拒绝，你就去弄清楚原因，修正，然后再试一次。
通过应用商店发布软件，几乎是一门独立的工程学科。
而且所有这些，都不会让你的产品成功。
这只是给了你一张参赛的许可。
然后你发现，你需要一门生意
到目前为止，你都可以假装自己在做一个项目。
但金钱迟早会进场。
现在你得去理解这些：
这是让我最意外的部分之一。
作为工程师，我们习惯了进入新的技术领域。
给我一个陌生的 API，我去读文档。
给我一个新的云服务，我自己摸索。
但法律和会计体系感觉完全不同。
一旦理解错了某个东西，后果可能比一次部署失败严重得多。
而且并不是总有一个编译器来告诉你，你做错了。
营销可能是最难的部分
然后，工程师们本能地最排斥的那个词就来了：
营销
我以前以为，营销基本上等于打广告。
不是的。
营销开始得要早得多。
它是搞清楚你的产品到底为谁而做。
他们觉得自己有什么问题。
他们会怎么描述这个问题。
他们会去哪里找答案。
他们为什么要信任你。
他们为什么选你而不是选竞争对手。
什么会让他们愿意把产品告诉别人。
你可以做出一个客观上非常优秀的软件，却仍然把上面的所有问题都回答得很糟。
市场不会因为你的架构优雅而给你加分。
用户不关心你的后端有多聪明。
他们关心的是，这个产品有没有让他们的生活变得更好。
这话写下来看着显而易见。
但当你整个职业生涯都在因为解决技术问题而得到奖励时，要把这句话内化，就难得多了。
然后你需要流量
如果没人访问，一个再好的网站也没多大用。
所以我开始认真学 SEO。
不是那种：
"往页面上堆些关键词。"
而是真正的 SEO。
搜索意图。
内链。
外链。
域名权重。
结构化数据。
页面标题。
Meta 描述。
Canonical URL。
索引。
站点地图。
Search Console。
内容集群。
话题权威性。
技术 SEO。
页面加载速度。
然后你会发现，光靠 SEO 已经不够了。
现在又有了 AEO，也就是答案引擎优化。
你希望你的内容不仅能被传统搜索引擎理解，也能被直接回答问题的 AI 系统理解。
这又引入了一系列新的问题。
你要怎么做，才能成为 AI 系统信任的信息来源？
你要怎么组织信息，才容易被引用？
品牌提及跟外链相比，到底有多重要？
你该怎么建立实体权威性？
当越来越多的用户直接得到一个答案，而不再点开十条蓝色链接时，产品被发现的方式又发生了怎样的变化？
我是个软件工程师。
一年前，我根本没想过这些东西。
现在，我连 Canonical 标签都有了观点。
外链自带一条兔子洞
最终，SEO 会把你引向外链。
然后你就会发现，互联网上围绕外链有一整条经济链。
目录站。
投稿文章。
数字公关。
记者约稿。
播客。
合作。
友情链接交换。
联盟分成。
赞助文章。
有人给你发邮件，说 19.99 美元能给你 50 条外链。
有些网站的域名权重高得离谱，上面的文章写出来好像根本没有人类读者。
而谷歌高高在上，实际上是在说：
请自然地获取外链。
行吧。
于是你就发现自己正在做一件对工程师来说极度反自然的事：
去互联网上求陌生人提及你。
销售外联甚至更让人不舒服
工程师习惯了把事情做出来，让作品自己说话。
但生意不一定是这样运作的。
有时候，你得发邮件给人。
然后跟进。
然后再跟进一次。
你需要联系潜在的合作方。
媒体。
社区。
客户。
以及那些能把你引荐给别人的人。
你开始写出这样的话：
"你好，我注意到你最近发布了……"
然后，你就突然开始做销售了。
外联邮件写得好不好，没有单元测试可以验证。
你把它发出去。
然后，对方要么回复，要么不回复。
大多数时候，他们不回复。
你要学着别把这件事当成针对你个人的。
改一改措辞。
再试一次。
最难的转变：从确定性工作到概率性工作
我觉得这对想创业的工程师来说，是最大的调整之一。
工程工作往往是确定性的。
你修好了一个 bug。
bug 就修好了。
你实现了端点。
端点就能用了。
你优化了查询。
查询就变快了。
这里有反馈回路，有可衡量的结果。
而创业的工作，大概率是概率性的。
你写了一篇文章。
也许能得到排名。
你联系了十家媒体。
也许有一家会回复。
你在社交媒体上发了东西。
也许根本没人看。
你改了 App Store 的截图。
也许转化率会提升。
你发布了一个功能。
也许没人在乎。
你也许执行得无可挑剔，却仍然得不到任何立竿见影的结果。
当你的职业生涯一直让你期待，付出和结果之间存在着相当直接的关系时，这一点就很难接受。
AI 还没有解决这部分
AI 确实帮了大忙。
我一直在用它。
它帮我：
-
研究陌生的领域
-
起草内容
-
批评我的落地页
-
分析定位
-
生成内容创意
-
理解会计术语
-
梳理 SEO 策略
-
准备外联
-
分析竞品
-
制作营销素材
-
自动化重复性的任务
但这里有一个重要的区别。
做软件时，AI 常常能直接产出成品。
做营销时，AI 能帮你产出一个"有可能有用的东西"。
你仍然需要现实告诉你，它到底有没有用。
这就是为什么我觉得，如今关于"AI 取代软件开发"的讨论，错过了一个重要的点。
软件的生产成本确实在变便宜。
但软件生产从来都不是唯一的一道瓶颈。
当几乎任何人都会写软件时，分发反而变得更值钱，而不是更不值钱。
知道该做什么，变得更加重要。
知道怎么触达用户，变得更加重要。
拥有可信度，变得更加重要。
拥有关注你的用户，变得更加重要。
理解一个市场，变得更加重要。
产品只是开始
从 BubSync 里，我学到的最重要的一课之一是：发布一个产品，并不是：
点子
↓
开发
↓
发布
它看起来更像：
点子
↓
调研
↓
开发
↓
测试
↓
定位
↓
品牌
↓
网站
↓
公司设立
↓
法务
↓
会计
↓
应用商店
↓
内容
↓
SEO
↓
AEO
↓
外链
↓
外联
↓
分发
↓
衡量
↓
学习
↓
调整
↓
无限重复
应用只是这门生意的一个组成部分。
而对工程师来说，它恰好是你最拿手的那一部分。
下次我会怎么做
如果明天我再启动一个产品，我不会一上来就埋头开发六个月。
我会把更多时间花在，先验证分发这件事上。
我会问：
最初的那 100 个用户，会从哪里来？
不是理论上。
而是字面意义上。
他们是谁？
我怎么触达他们？
他们已经在哪些社区里？
他们在搜索什么？
谁已经握有他们的注意力？
我能不能在做产品之前，先建立一批用户？
我能不能做出一些有用的工具或内容，把同样的用户吸引过来？
在解决每一个边界情况之前，我能不能先验证，人们确实足够在乎这个问题？
这些问题，现在在我看来，跟"我该用什么样的技术栈？"至少一样重要。
很可能重要得多。
早一点开始建。早一点开始推。
我还掉进了另一个坑，我猜这在工程师里很常见。
我们想把一个好东西展示给人看。
所以我们等。
再加一个功能。
再多打磨一遍。
再多修一个 bug。
再多发一个版本。
然后我们才开始聊它。
问题是，营销本身同样需要迭代。
你的第一个落地页，大概不会是对的。
你的第一次定位，大概不会是对的。
你的头几条社交媒体内容，大概不会有用。
你的头几条外联消息，大概不会有用。
你必须足够早地开始在这些事情上失败，才能从中吸取教训。
如果你在做产品，营销就不该在产品做完之后才开始。
它应该在产品开始的那一刻就开始。
做 BubSync 值得吗？
绝对值得。
无论 BubSync 最终走向何方，我已经从开发和发布它的过程中，学到了比再做一打技术副项目还要多的东西。
不是因为这个工程的难度没有意思。
里面确实有大量真正困难的工程难题。
而是因为它逼我走了出去，跳出工程本身。
我必须去学，生意到底是怎么运作的。
产品是怎么被发现的。
市场是怎么运转的。
应用商店是怎么工作的。
搜索是怎么工作的。
定位是怎么工作的。
去吸引一个人的注意力，到底有多难。
而也许最重要的是：
做出一个东西，和做出一个有人用的东西，是完全不同的两种技能。
来源：Building BubSync：AI Made the Coding Easier. Everything After Was the Hard Part 作者：Ashley Rowe 发布平台：alt-dev.com.au 原文链接：https://alt-dev.com.au/building-bubsync-ai-made-the-coding-easier-everything-after-was-the-hard-part
相关阅读：
一个运行了一年的个人 AI Agent：自动整理日历、邮件、会议和工作记忆
