那天下午我正在改教程里第三章的一个示例代码手机弹出一条通知提示我的教程仓库收到了一个新的 Star。我随手点进后台看了一眼结果发现了一个让我愣住的情况——不只是新增了几个 Star而是流量曲线突然拉出了一条陡峭的直线。顺着流量来源往下翻看到了那行字豆包在回答“零基础如何入门 AI 编程”时推荐了我的教程。说实话第一反应不是高兴是怀疑。我以为统计出错了或者是某个论坛的网友帮忙推了一贴。我连续刷新了几次页面又去翻了一下豆包那边的回答引用才确认我的教程真的被一款主流 AI 助手收录推荐了。也就是在那天仓库的 Star 数正式超过了 20000。这篇内容不是来报喜的。坦白讲我更想借这个机会把自己从 0 到 20000 Star 的整个过程摊开来看一遍教程当初是怎么构思的为什么要那样设计哪些增长是运气哪些坑是真实踩出来的。如果你正在考虑做开源教程、写技术内容或者只是想弄明白“AI 编程到底应该怎么学”希望这篇复盘能给你一点参考。1. 收到豆包推荐提醒那天我差点以为是统计出错1.1 推荐前后的 24 小时数据发生了什么变化我先放一组记录下来的对比数据。因为每周都会记录一次仓库数据所以那段时间的变化我记得特别清楚时间范围页面访问量新增 Star新增提问/讨论推荐前一天日均稳定低位个位数几乎为零推荐后 1 小时大幅上涨开始密集增加陆续出现推荐后 24 小时持续高位累计新增近千明显增多这里面具体的数值我做了模糊化处理但方向是真的。为什么数据会这么猛因为豆包这种入口带来的不是“刷到一条内容然后划走”的泛流量而是带着明确问题来的用户。用户正在找答案我的教程恰好就是那个答案于是 Star、收藏、提问都变得非常密集。这和我以前在技术社区发帖获得的流量完全不是一个量级。1.2 我更在意的是“被推荐”背后的含义被 AI 助手推荐和一次普通社交媒体转发性质完全不同。AI 助手在回答里引用外部教程往往要经过一套相对严格的内容筛选结构清晰、步骤可复现、信息相对稳定、没有明显的标题党痕迹。这些综合起来才可能被选中。所以“被豆包推荐”最大的价值不是那波流量而是告诉我一件事我的教程在 AI 看来是“可靠”的。这对做内容的人来说是个很重要的信号——以后的内容创作除了写给搜索引擎、写给读者可能还要多一个“写给 AI 的维度”。当然我也给自己泼过冷水被推荐只是因为某一次回答引用了你不代表从此一劳永逸。AI 会持续更新语料和推荐规则内容要长期被推荐靠的还是持续维护。2. 回忆起点那时候的 AI 编程内容缺的不是信息是路径2.1 我看到的三个断层动笔写教程之前我花了两周时间把当时能找到的相关内容几乎都翻了一遍。市面上的 AI 编程内容大概分成三类第一类是短视频。用 AI 几分钟写了个小游戏或者网页看起来非常爽但看完之后观众只会觉得 AI 很厉害自己还是不知道怎么开始。因为它没有展示过程中那些失败、调试、返工的内容那些才是真实编程的主旋律。第二类是工具说明书。介绍模型有哪些功能、有哪些参数、有哪些使用技巧信息很全但和真实开发场景严重脱节。读者学会了一堆“功能”回到自己的项目里还是不知道第一步该干什么。第三类是课程大纲式的目录。把“提示词工程”“代码生成”“AI 辅助测试”一个个列出来看起来面面俱到但每个主题都浮在表面章节之间也没有逻辑递进。我管这种现象叫工具层面的热闹和能力层面的荒芜。还有一个更大的断层很多人把 AI 编程理解为“输入一段需求AI 吐出一段代码”然后这件事就结束了。但在真实的软件项目里生成代码只是最前面的 5%后面还有 95% 的工作怎么把代码放进已有项目、怎么处理依赖冲突、怎么设计数据结构、怎么写测试验证它是对的、怎么在报错之后一步步修好。当时几乎没有人系统性地教这个而这恰恰是大家真正卡住的地方。2.2 我给教程定的三条原则基于上面的观察我给教程定了三条规则这几条规则后来贯穿到了两万 Star。与其说是内容策略不如说是我的底线。第一条每个结论必须能复现。我写的每一个提示词、每一段代码示例一定是我自己实际跑通过的。失效的案例我会单独标出来并写清楚在哪个版本下失效。教程里宁可少写也不写一个我自己没验证过的结论。这一条在后期起了很大作用很多读者正是因为“照着做真的能成”才愿意转发。第二条以“做完一个东西”为章节目标。每一章结尾读者都应该亲手得到一个能运行、能看、能用的成果。哪怕只是一个极小的命令行工具它也比十个空洞的技巧有价值。读者需要的不是知识列表而是一条能走完的路。第三条只追踪稳定能力不追逐新功能。模型几乎每个月都有新功能教程如果天天追新只会被拖垮。我选择围绕那些短期不会变的底层能力来设计——比如怎么清晰地表达需求、怎么验证 AI 的输出、怎么把大任务拆小。事实证明这个原则让教程过了一年依然没有被淘汰。我后来跟别人开玩笑说别人教的是“这把锤子怎么握”我教的是“用这把锤子盖一栋能住的房子”。锤子会换但盖房子的流程不会。3. 教程的核心设计我把 AI 编程拆成了四层能力模型3.1 为什么是“能力模型”而不是“功能清单”如果教程只是罗列“AI 能做什么”读者很快就会迷失。因为功能背后是能力能力背后是思维方式。我开始想一个问题一个人想真正用 AI 完成编程项目到底需要具备哪几层能力反复推翻了很多框架之后我最后留下了四层。这不是说我的分层是唯一正确的但它是我实践验证过的而且是有效的。四层分别是提问层、工程层、评估层、迭代层。3.2 四层模型具体讲什么第一层提问层。这是所有人接触 AI 的第一道门也是后续一切能力的基础。它的核心不是“会说话”而是“把需求结构化”。我总结了提问四要素角色、任务、约束、交付格式。很多读者反馈说光是学会这个四要素AI 产出的代码质量就明显提升了一截。举个例子新手一上来通常这样问帮我写个爬虫这个提问的产出大概率是一段“看起来能跑但哪都不对”的代码不知道爬哪个网站、存成什么格式、怎么处理超时和反爬最后拿回来一堆没法用的东西。如果按四要素改一下效果立刻不同你是一名 Python 开发工程师。 请帮我写一个抓取某网站新闻标题的小程序 - 只需要抓取标题和发布时间 - 输出为 CSV 文件 - 需要处理超时和反爬导致的异常 - 代码带上清晰注释方便我维护任务的边界、输入输出、异常处理一次性交代清楚AI 生成的代码就会接近可用状态。这个对比我在教程里放了很多遍因为它真的是一学就会、一会就有效的技巧。第二层工程层。AI 生成的代码从来不是终点而是起点。读者要学会怎么把它放进自己的项目目录怎么组织、依赖怎么管理、版本怎么回滚、运行环境怎么搭。这一层很多人都忽略了因为它听起来不够“AI”但它恰恰是 AI 编程新手翻车最多的地方。我在教程里专门安排了一个章节让读者用 AI 辅助搭建一个极小的项目骨架从初始化目录开始一步步把它变成一个可以维护的代码仓库。做完这个过程读者才会真正理解“AI 写代码”和“工程化”之间隔着的距离。第三层评估层。模型经常会一本正经地给出看起来很对的错误答案。评估层的核心就是四个字不要轻信。我教了三件事小步验证、测试优先、代码审查意识。这里讲一个我自己实际遇到的案例。我让某模型写一个排序算法它给出的代码整体很漂亮看起来完美无缺。但我拿边界数据一测在输入为空、只有一个元素、存在大量重复值三种场景下分别出现了不同的错误。如果我不做边界测试直接把这代码当成“AI 生成的正确代码”用进项目后面排查会非常痛苦。所以我后来在教程里反复强调一句话AI 生成代码的价值不在于它可以不用检查而在于它可以替你省掉大量重复劳动把精力留给更需要判断力的检查环节。第四层迭代层。从“拿到一段能用的代码”到“完成一个完整的产品”中间靠的是迭代。我把大任务拆成小任务的方法讲成“一次只让 AI 走一步”先描述整体目标再拆分模块逐模块生成、验证、整合。每完成一个模块就把新需求作为增量让 AI 继续修改。这样做的好处在于每个步骤的上下文都是干净可控的AI 出错的概率和排查的难度都会小很多。3.3 为什么这套模型过了很长时间依然没有被淘汰原因很简单AI 工具是不断变化的但“人机协作”的能力结构相对稳定。无论以后模型变成什么形态人依然需要学会表达需求、理解结构、验证结果、持续迭代。我教的是稳定方法论而不是某个特定版本的 API 用法。这大概也是教程能被豆包这类 AI 助手看中的一个原因——结构化的、稳定的知识比零散的工具技巧更有资格成为“参考资料”。4. 从 0 到 20000 Star 的增长复盘哪些是运气哪些是方法4.1 冷启动阶段01000 Star把第一个案例做成“极端完整”第一步最难没有流量、没有口碑、没有任何背书。我当时的做法是与其做一个覆盖很多主题的“大而全”不如先把第一个章节做成一个“极端完整”的案例——从痛点、思路、提问、踩坑、修正到最终成果全部铺开。这是一个任何人照着走都能走通的完整闭环。内容发出去之后最初一批反馈来自三个渠道我自己写的一篇长文、两个技术社区以及教程仓库的 README。前 1000 个 Star 里有相当一部分是读者读完那个案例后自然点亮的而不是我主动求来的。这段经历让我学到一件事冷启动阶段内容必须“一刀见血”。与其讲一百个表面的技能不如把一件事做到任何人照着做都能成。前一千个 Star 不是靠推广大而是靠解决一个具体痛点积累来的。4.2 破圈阶段100010000 Star让教程“能被搜索到”跨过 1000 Star 之后我撞上了一个明显的瓶颈增长非常缓慢。后来我找到了根源——教程内容不错但整个信息架构是给“已经来的人”看的而不是给“还没来的人”搜的。于是我说服自己做了一次比较伤筋动骨的重构优化 README让项目的定位和目标读者在第一屏就讲清楚把每一章的标题从“我要讲什么技术名词”改写成“读者会遇到什么具体问题”额外整理了一份 FAQ把读者反复问的高频问题直接放在文档开头。除了内容结构我还做了一套配套的讲解视频把复杂概念用比较口语化的方式重新讲了一遍。视频本身没有带来多少 Star但它极大地降低了读者使用教程的心理门槛间接推高了转发率。那个阶段我最大的体会是知识类开源项目被动流量才是持续增长的核心引擎。搜索引擎、AI 助手推荐、社区引用都在为一个信息架构清晰的内容加分。4.3 口碑阶段1000020000 Star让读者成为传播节点从一万到两万靠的不再是流量而是可信度。这个阶段我想明白了一件事读者愿意转发你的教程不是因为它免费而是因为它真的有用、且这种有用可以被证明。我当时做了什么第一接受志愿者勘误每一条被确认有效的反馈都记入文档的致谢名单。第二持续更新让教程始终和最新的主流实践保持同步。第三在每个章节末尾设置一个小挑战让读者带着目标去动手而不是看完就关。阶段核心杠杆增长形状01000 Star第一个完整案例缓慢但实在的爬坡100010000 Star信息架构优化 视频讲解阶段性跃升1000020000 Star持续更新 社区信任长期稳定上升这张表我看了很多次它反复在说明一件事两万 Star 不是任何一次爆款带来的而是三个阶段各自积累的结果。5. 被豆包推荐之后教程里有什么肉眼可见的变化5.1 用户画像从“开发者”扩展到“泛知识工作者”豆包推荐带来的用户和我以前的用户很不一样。以前来 Star 的基本都是程序员留言里讨论的是 Python 语法、接口设计、性能优化。推荐之后新增的关注者里出现了很多并不是专业开发者的群体做产品的、做运营的、在校学生甚至还有几位是内容创作者。他们的共同诉求不是“提升编程水平”而是“我能不能用 AI 做出点东西来”。这其实是一个比“学会编程”更朴素也更广泛的需求。这件事让我意识到AI 编程教程的受众已经悄悄变化了不是只有程序员需要学而是每一个想让机器替自己干活的人都需要学。这个发现直接影响了我之后的内容方向和 FAQ 扩展。5.2 新读者问得最多的三个问题推荐后那几天我收到的问题数量超过了之前半年的总和。我统计了一下最高频的三个问题分别是第一个“我完全没有编程基础能学吗”我的回答是能但请把目标调小。不要想着一个月做出一个商业产品而是先照着教程做出第一个极小的可运行工具。基础不是门槛期望才是。第二个“AI 这么强程序员会不会被替代”我每次都会认真回答AI 不会替代会用它做事的人。它真正替代的是那些把写代码当作打字速度、对项目整体没有判断力的人。这个逻辑在工具升级的历史阶段里反复出现。第三个“你的教程是用 AI 写的吗”这个问题很尖锐。我的回答是AI 帮我做了很多整理、翻译和初稿起草工作但教程里的每一个代码案例我都亲自在真实环境里跑过每一个失效的案例我会标注版本和原因。然后我会补一句——这恰恰就是教程一直在教的第一课不要因为来源是 AI 就放弃验证。5.3 这批反馈如何反过来改进了教程因为新读者的出现我随后给教程加了一节“零基础快速通道”让没有任何编程经验的人可以直接跳到最适合自己的章节不必从头啃到尾。同时我把原本散落在各章节的验证方法集中起来独立成了“评估层”那一章也就是前面说的第三层能力。FAQ 库也扩展到了原来的三倍左右很多新问题已经能被文档本身直接回答掉。一句话总结被动流量不仅带来了 Star还带来了用户真实需求的方向这比 Star 本身珍贵得多。6. 两万 Star 之后我复盘过的那些坑6.1 最大的坑内容会迅速过时这是写技术教程的人最常遇到、也最头疼的问题。AI 的迭代速度比你写文档的速度快得多。我开篇时认为“很稳定”的一些提示词技巧半年后效果就明显变差了有些示例代码在新模型版本下会跑不出预期的结果。后来我把内容拆成两层底层能力层和工具示例层。底层能力层尽量写得稳定讲原理和思维工具示例层则明确标注“当前版本的实测结果”和“更新日期”一旦失效就及时修改说明。这样做既保证了核心内容不被快速淘汰也让读者清楚哪些部分需要自己在当前环境下手动验证。6.2 Star 不等于学会收藏和动手之间的距离我从一些零星收集的反馈里得到过一个模糊的认知收藏过教程的人里真正动手把第一个项目做完的可能只有两成左右。很多人是“收藏即学会”存了一堆资料之后再也没有打开第二次。这个数字一开始确实让我有点失落但后来我释然了哪怕只有两成以两万 Star 的基数来算真正受益的人也已经有好几千个了。这本身就有意义。从那以后我在每个章节开头都加了一句话收藏之后请从这一章的第一个练习开始哪怕它看起来很简单。这话不是口号是真的劝动过一部分人。6.3 维护时间是一个持续被低估的成本Star 涨上来之后最消耗我的不是写新内容而是维护旧内容。每一条 Issue、每一封私信、每一轮模型更新后的复查时间成本远超出想象。有大概半年的时间我每周都要耗掉大半天来处理这些事一度想放弃。后来我给自己做了一个取舍把维护工作分成必须做的回复严重问题、修复失效案例和非必须做的参与无休止的讨论、回应每一个“建议增加功能”的留言然后有勇气对非必须的说“不”。这个决定救了我也救了教程。6.4 被推荐之后的“被审视”被豆包推荐是一把双刃剑。它带来的不只有新用户还有更严格的审视。推荐之后的一段时间里评论区开始出现“这教程是不是被高估了”“这里其实有个更优解”之类的讨论。我确实有过一小段不适期但后来想明白了一件事被审视其实是免费的审计。读者挑出的每一个错都在帮我补上盲区。我的消化办法很朴素每周只看一次数据其余时间全部用来改内容。这个方法对我个人很有效它既让我躲开了数据焦虑也不会让我漏掉真正重要的问题。7. 如果你也想做一套 AI 编程教程我把实话放在这里7.1 先想清楚你的教程是写给“学习的人”还是“收藏的人”大多数技术教程失败的原因不是内容不够好而是写作者没有完成视角转换。写作者站在自己的认知水平上会觉得“这么简单的步骤读者肯定能懂”但读者并不是这样的。教程的本质不是展示你知道什么而是让读者能复现你的过程。我建议在动笔之前把读者想象成一个“有一定基础、但完全没有经过你思维训练的朋友”然后在每一个章节里回答他可能卡住的问题。这个视角转换会全面提升内容的可用性。7.2 一套最小可行的教程生产方式我后来反复使用的一套流程给自己起了个名字叫“脚手架法”。它本质上不是知识整理而是搭一座让读者能自己走过去的桥。第一步找一个你亲自完整做过的小项目。小到周末就能完成但必须存在真实的坑。第二步在做的过程中记录你的每一步你怎么想的、怎么向 AI 提问的、AI 输出的结果有什么问题、你又是怎么修正的。第三步把记录整理成“问题→尝试→结果→修正”的结构每一节都围绕一个具体问题展开而不是围绕知识点展开。第四步找人试读全程观察他在哪里卡住了。他卡住的地方就是你接下来要补充说明的地方。这四步做完你的教程就已经有了“能真正教会人”的底子。剩下的传播、运营、增长都只是让更多人看到它而已。7.3 最后想说的关于耐心和心态回看整个历程两万 Star 不是一个爆发的结果而是几百天里每一次小更新、每一条 FAQ、每一轮纠错累积出来的。最开始那几个月我并没有感觉到明显增长只觉得是在不停地回答问题、修改错别字和微调章节顺序。如果你现在也在做一个看起来没什么人看的教程我的建议只有一句先做完一个能跑的东西再谈教程先让十个人真的学会再谈传播。数字是结果不是目标。当你真的把“帮助人把事情做成”这件事做扎实了数字会以它自己的方式向你走过来。写到这里我又把那天的那条通知翻出来看了一眼。说实话被豆包推荐、Star 破两万这些数字确实让我开心。但让我真正觉得值的是另外一些画面有人在私信里告诉我他照着教程做完了第一个小工具虽然简陋但他第一次觉得自己摸到了一点门还有一位并不是程序员的朋友把教程转发给了自己的团队。这些才是这件事持续下去的真正动力。接下来我还会继续维护这套教程但会把更多精力放在两件事上一是让教程更容易被 AI 准确地理解和引用二是想办法把“收藏”变成“动手”。如果你有这方面的建议欢迎在评论区或者仓库里告诉我内容上的问题我也会尽量尽快回复。