夜雨聆风AI让一个人做出软件，确实比以前容易了。
整理需求、画原型、写代码、补测试，很多过去需要几个人配合的事，现在一个人带着AI也能往前推。第一版出来得越来越快。
但软件做出来以后，问题才刚刚开始。
谁会看到它？为什么愿意付钱？买完以后能不能用起来？出了问题谁处理？明年为什么还要续费？
这些问题不解决，手里有的可能只是一套软件，还不是一门软件生意。
这也是我做OPC小岛的原因。我想沿着两条正在发生的实践路线，把开发以后的这些问题持续写清楚。
第一条：完整经营一套软件产品
我正在运营一套自己的软件产品。这件事不会停在开发，前后至少有六段工作。
产品设计。先决定给谁用、解决什么问题，以及第一版只做到哪里。功能多不多不是起点，用户在意的问题能不能先解决才是。
市场。产品做出来，还要让合适的人知道。定位怎么说，演示什么，去哪个渠道讲，都会影响它能不能被看见。
销售。有人来问，不等于愿意付钱。还要确认真实需求，把价值、价格和服务边界说清楚。
开发。把已经答应的价值变成真正能用的软件，同时处理速度、稳定性和以后维护之间的取舍。
交付与售后。客户付钱只是开始。实施、培训、问题处理和支持成本，最后都会回到这门生意能不能长期做。
运营与续费。上线以后继续看使用和反馈，再决定改什么。第二年有没有继续付费的理由，会直接影响现金流能不能稳定。
我在这条线上要盯到最后：软件能不能从一个想法走到交付和续费。
第二条：深入客户现场做FDE
另一条路线发生在客户现场。我在跨境电商行业积累这方面的FDE经验。
FDE全称Forward Deployed Engineer，可以理解为“前沿部署工程师”。名字有点陌生。说得直白一点，就是进入客户的业务现场，把一个真实问题一路变成能够运行、能够使用的系统。
它也要写代码，但不会从“需求已经确定”开始，也不会在“功能已经写完”结束。
问题发现。先回到实际流程里，看谁在做、卡在哪里，不能把客户的一句话直接写成功能。
技术界定。把哪些能做、哪些暂时不能做划清楚，也要确认数据、接口、权限和交付标准。
系统设计。把业务流程翻译成系统：谁在什么环节操作，数据怎么流转，异常由谁处理。
构建。写代码、接系统、补测试，把方案做成可以运行的东西。AI能加快不少动作，工程质量和关键取舍仍然要由人负责。
上线。系统进入真实环境后，还要处理部署、数据、权限、培训以及真实使用者遇到的问题。
反馈迭代。哪些流程跑通了？哪些地方还卡着？上线后要继续回现场看。这个过程也会暴露哪些能力值得沉淀成标准产品。
前面的问题和边界如果没弄清楚，后面开发得越快，返工也可能越快。
我先拿这六件事来查漏
把手上的两件事摆在一起看，卡住我的地方并不一样。
做自己的软件，功能写完只是中间一步。后面还有人从哪里来，为什么愿意付钱，交出去能不能正常用，第二年有没有续费的理由。
FDE现场不一样。很多时候，还没到写功能那一步。问题到底在哪儿，哪些能做，得先弄清楚。数据和流程怎么进系统，也不能等写代码时再补。
我先把它记成六段：
问题 → 产品 → 获客 → 成交 → 交付与售后 → 续费
这六段不是我总结出来教别人的。我自己做事的时候，先拿它对一遍。软件卡住了，我就往前找：是根本没人看到，还是有人来问却没谈成。已经交付了，就看客户是不是真的在用，明年还有没有继续付钱的理由。
FDE不会把这六件事全包下来。它不负责我怎么获客、怎么卖，但客户的问题有没有找对、系统是不是做成了、交到现场能不能用，这几件事躲不开。
哪些事必须我来，哪些可以交出去
以前说起一人公司，我最容易盯着“一个人能做多少”。最近真做起来，我反而更在意另一件事：最后出了问题，谁来认账。
对我来说，这个人是我。至于是不是每一步都要我亲手做，没那么重要。
就拿这篇文章来说。三张配图、排版、传进微信草稿箱，我已经让AI去跑了。这些事可以交出去。可两条路线怎么定义，哪些经历能写，哪些客户信息必须隐去，还得我自己判断。
我也不会因为叫“一人公司”，就把每个按钮都自己点一遍。能写成流程的，让软件和AI接。偶尔才做的，就找外包或现成服务。省下来的时间，我得留给选项目、想清楚答应客户什么、定价格和盯续费。
我手上正好有两个现场。一边是自己的软件产品，从产品怎么定，一直管到交付和续费。另一边是跨境电商客户现场的FDE。客户说出来的一句话，往往还不能直接开发。我得先跟着业务把问题弄清楚，再把系统做出来，看它到了现场能不能用。
这两条路我都还在走。有些地方踩过坑，有些还没跑通。没跑通的，我就写没跑通，不提前整理成一套成功方法。
至少现在，这个号不卖课，也不卖会员。我先把过程留下来，也想认识一些正在做软件型一人公司的人。
如果你手里已经有软件，拿上面六段对一遍。最先断在哪儿，就先盯哪儿。还没开始写代码，也不用急。
下一篇就从这里往前走：在决定做什么软件之前，先想清楚自己到底想经营一家什么样的公司。
一个人，一座岛，一位AI。