作者拿到的成绩
这篇值得看在哪里
阿杰从几乎不懂编程起步，用一个多月借助 Codex 和 Claude 做出公司正式使用的业务系统。系统已有28个账号和8种角色。它沉淀了12000多位达人等真实数据。真正的转折是从能运行到公司敢用，靠的是业务梳理和持续测试。
产品来自公司长期存在的排期难题
作者负责浪莎品牌达人溯源专场，日常工作包括达人筛选、商务沟通、合作谈判、选品排期、直播执行和数据复盘。团队每天大约对接6—10位主播，商务登记达人和直播档期，主管审批，接待、中控、运营等岗位按档期准备，播后还要录入数据、计算提成和复盘。原先主要靠飞书表格和微信群协作，随着角色、流程和统计口径增加，重要信息容易被刷走，作者还要在群和表格之间反复传话、统计。这个项目解决的核心不是“做一个看起来很完整的软件”，而是把客户、档期、审批、执行和复盘从个人记忆中转移到统一的业务载体里。
一天做出Demo，产品化还要继续
作者完全不懂前端、后端、数据库、服务器和部署，第一次使用Codex时没有从技术架构或专业需求文档开始，而是先用大白话描述岗位、流程和信息流转，再让AI复述理解，发现角色遗漏或流程错误后继续补充。这样反复澄清后，第一版档期登记、列表、审批和角色权限Demo在一天内出现。但Demo只证明页面和主流程能运行，真实上线还要回答字段由谁填写、审批驳回如何处理、重复合作如何判断、统计按哪个时间口径计算等问题。接下来的半个月，作者几乎每天晚上与AI沟通约两个小时，很多需求是在实际操作Demo后才被发现。这说明业务熟悉度可以替代部分技术背景，但不能替代对规则、权限和数据口径的持续确认。
真实用户反馈推动产品进入公司
部署阶段，作者让Codex按纯小白能理解的方式逐步指导，并用截图确认每一步。系统通过域名打开后，又花了一个多星期修复上线环境问题；同一功能由20多个人从不同入口、以不同角色操作时，暴露出草稿不清空、CRM保存无响应、AI分析像卡住、审批后人员信息丢失、日期格式导致白屏、列表与看板数据不一致等问题。作者随后采用小范围真实使用、收集反馈、一次只改一类问题、重新走完整流程并确认不影响旧功能后再发布的方式迭代。最终系统有28个正式账号和8种角色，已承载12000多位达人、2100多条档期记录、1600多条客户跟进记录和370多次AI客户分析，作者据此判断它已经成为公司的业务系统，而不是个人实验。
先跑通档期闭环，再把CRM和AI销售分析接进来
作者没有一开始把档期、CRM、电话、AI和数据看板全部堆进首版，而是先让“商务登记档期—主管审批—档期进入日历—后端查看执行”这一核心闭环稳定，再扩展客户开发和CRM。系统后来形成从电话资源与客户开发、CRM跟进，到达人合作、档期审批、后端执行、下播数据和团队看板的链路。CRM中的AI客户分析会结合聊天截图识别、客户资料、历史跟进和业务知识库，输出客户价值判断、顾虑、下一步动作、话术和风险提示。第一版分析效果并不好，原因不是单纯的模型能力，而是AI不了解达人合作业务；作者用真实对话、案例和错误反馈持续调整知识库和提示词，最终让分析大部分时候具备参考价值，但仍明确成交受客户需求、商品、价格、时机和商务能力等因素共同影响。这个项目更适合熟悉具体业务、愿意持续测试并对数据结果负责的人，而不是只想用一句话生成完整系统的人。
根据作者原帖及所附飞书文档整理。完整实操与材料见原文。
原文还会展开这些问题
- 飞书表格和微信群为什么难以支撑达人溯源业务协同？
- 零代码小白如何把口头业务转成可验证的系统需求？
- 为什么本地 Demo 正常仍可能在正式上线后暴露问题？
- 真实用户反馈如何改变系统迭代和发布方式？
- AI 销售分析为何需要业务知识库和多轮提示词调整？
- 如何用最小闭环控制公司系统的首版范围？
原作者原话
重要的是需要参与业务流转的人已经在使用
这也是我后来对 AI 开发最大的一个认知变化
以上为原帖简短摘引。作者：阿杰。完整内容及访问条件以生财有术原帖为准。
