作者拿到的成绩
这篇值得看在哪里
阿杰从几乎不懂编程起步，用一个多月借助 Codex 和 Claude 做出公司正式使用的业务系统。系统已有28个账号和8种角色。它沉淀了12000多位达人等真实数据。真正的转折是从能运行到公司敢用，靠的是业务梳理和持续测试。
从兴趣电商痛点起步
作者阿杰在浪莎集团负责达人溯源专场，日常涉及达人筛选、商务沟通、选品排期、直播执行和数据复盘。原先业务依赖飞书表格与微信群，客户信息、档期、审批、执行和复盘分散在不同位置，很多同步工作要靠他记忆和催办。随着商务和客户增加，协同成本上升，于是他先把一个真实闭环交给 AI：商务登记档期、主管审批、档期进入日历、后端查看执行。
一天的Demo如何变成系统
作者用大白话描述岗位、流程和信息流转，让 Codex 先复述需求，再根据纠正结果制作可操作的 Demo，一天内看到登记、审批和角色权限等核心功能。但 Demo 只证明流程有可能实现，正式使用还涉及真实登录、权限、数据库、异常处理和多人协作。上线时，他通过截图逐步完成部署，域名可以打开后又花了一个多星期修复生产环境问题，说明本地正常不等于上线可靠。
真实用户推动迭代与AI校准
系统推行后，商务、主管、中控、接待和运营分别使用并反馈问题，作者逐项复现、修改，再回归旧流程。草稿未清空、审批后人员信息丢失、数据口径不一致等问题，都是实际操作才暴露出来的。AI 销售分析也经历了先失效再校准：作者把业务模式、优秀对话、案例和经验加入知识库，提示词调整超过10次，判断标准转向顾虑识别、建议可执行和话术符合业务。
成果口径与适用边界
截至原文记录，公司有40多个人，系统有28个正式账号和8种角色，已沉淀12000多位达人、2100多条档期、1600多条客户跟进记录，并完成370多次 AI 客户分析。作者披露的订阅费约560元，另有服务器和域名费用，但没有给出利润、节省工时或长期经营收益。这个案例更适合已有具体业务、愿意持续测试并为数据负责的业务人员，不能直接等同于低成本稳定盈利方案。
根据作者原帖及所附飞书文档整理。完整实操与材料见原文。
原文还会展开这些问题
- 飞书表格和微信群为什么难以支撑达人溯源业务协同？
- 零代码小白如何把口头业务转成可验证的系统需求？
- 为什么本地 Demo 正常仍可能在正式上线后暴露问题？
- 真实用户反馈如何改变系统迭代和发布方式？
- AI 销售分析为何需要业务知识库和多轮提示词调整？
- 如何用最小闭环控制公司系统的首版范围？
原作者原话
重要的是需要参与业务流转的人已经在使用
这也是我后来对 AI 开发最大的一个认知变化
以上为原帖简短摘引。作者：阿杰。完整内容及访问条件以生财有术原帖为准。
