五大GitHub仓库:用提示词与脚本构建AI内容创作工作流
最近在拆解 Greg Isenberg 那期《五大 GitHub 仓库告别 AI 烂文作品爆火顺便赚钱》时最有感触的不是某个具体工具多厉害而是他反复强调的一句话AI 只是“编辑”不是“作者”。很多人用 AI 写出来的东西被打回、被读者嘲讽“一股机器味”并不是大模型能力不行而是整个内容生产链条缺少了三样东西高质量提示词、人类感校验、变现闭环。这篇文章会围绕内容创作者和开发者的真实需求把五大类 GitHub 仓库整理成一套可落地的“中文实践版”工作流。不管你是写技术博客的开发者还是做小红书、公众号、知乎的内容运营都能直接套用里面的方法、代码和检查清单。文章的重点不是告诉你“有哪些仓库”而是告诉你拿到仓库后怎么配置、怎么改、怎么接入自己的创作流程。1. 为什么 AI 生成的内容总被人说“烂文”先说一个很常见的现象同样是用 ChatGPT、Claude、Kimi 这类模型有人写出来的文章数据很好有人写出来的东西一眼假。这不是玄学而是大量 AI 文本存在共性通病关联词堆砌“首先”“其次”“再者”“综上所述”排着队出现。排比句失控每段都是“不仅……而且……更是……”读起来像口播稿。缺少有效信息讲了半天没有案例、没有数字、没有个人经验只有正确的废话。结构同质化每一篇都是“引言—分点—总结”连小标题套路都一模一样。没有观点风险什么都不敢否定什么都不敢承诺最终内容没有记忆点。这些问题的根源不是 AI 模型不够聪明而是使用者的“生产过程”不像一个编辑流程。真正能持续稳定产出优质内容的团队会把选题、写作、改写、分发拆成多个独立环节。而 GitHub 上大量的开源仓库正好可以帮助我们把每个环节标准化、自动化。Greg 的思路本质上是用开源工具搭建一条内容生产线用“提示词仓库”解决创作起点问题用“文本改写仓库”解决机器感问题用“数据挖掘仓库”解决选题问题用“模板仓库”解决生产效率问题用“变现仓库”解决内容商业化问题。下面五个部分会逐一展开。2. 环境准备与版本说明在围绕仓库折腾之前先花几分钟准备环境。这一节不是多余的很多同学看到代码跑不通90% 是环境不一致。本文的示例环境如下不一定要求你完全一致但思路是一样的工具版本建议用途Python3.9 或更高版本运行脚本与调用大模型 APIGit2.30克隆仓库、查看历史记录pip21安装 Python 依赖OpenAI SDKopenai1.0.0调用 ChatGPT 系列模型Node.js可选18部分前端模板仓库需要如果网络访问 GitHub 不稳定可以优先做两件事使用国内可信的开源镜像站阅读仓库代码只读模式不要登录个人账号优先用git clone下载公开仓库不要用第三方“加速下载工具”输入密码。需要说明的是本文涉及的外部 API 密钥如 OpenAI API Key请放到环境变量中不要直接写在代码里避免泄露。示例中的模型名“gpt-4o-mini”“claude-3-5-sonnet”等只是常见选项你要根据自己账号可用的模型进行替换。3. 仓库一提示词工程类仓库解决“不会写提示词”3.1 这类仓库是做什么的最典型的一类仓库就是收录了大量高质量提示词模板的“提示词大全仓库”代表作之一是awesome-chatgpt-prompts。这种仓库把“角色设定”“输出格式”“约束条件”写成现成的提示词拿来就能用。它解决的核心问题很简单你不需要每次从零开始想提示词只需要找到合适场景然后微调即可。比如你想让 AI 扮演“资深科技编辑”一个非常普通的提示词是请帮我写一篇关于人工智能的文章。而使用提示词模板后可以变成你是一位拥有 10 年经验的中文科技媒体主编擅长把复杂技术讲得通俗易懂。 请围绕“人工智能对普通人的影响”写一篇 1500 字左右的文章。 要求 1. 开头用真实场景引入不要用“随着科技的发展”开头。 2. 每个论点都需要配一个具体案例或数据。 3. 禁止使用“首先、其次、最后”这类关联词。 4. 结尾给出一个可执行的建议。相比之下后者的输出质量会明显提升。这不是玄学而是因为大模型的输出高度依赖上下文约束。3.2 如何把提示词仓库变成自己的模板库直接用别人的提示词有个问题角色设定和风格要求往往不符合你的个人表达习惯。建议拿到提示词后按照下面三步定制拆解把提示词拆成“角色”“任务”“格式”“风格”“禁忌”五个部分。替换把“英文科技编辑”换成你自己的领域比如“Java 后端开发”“Python 数据分析”。测试准备三篇历史文章让 AI 用新提示词生成对比风格是否接近。下面是一个简单的 Python 示例演示如何把提示词模板放入代码中批量生成文章# 文件路径prompt_engine.py import os from openai import OpenAI client OpenAI( api_keyos.environ.get(OPENAI_API_KEY), # API Key 通过环境变量注入 ) STYLE_PROMPT 你是一位中文技术文章编辑写作风格需要满足以下要求 1. 不使用空洞的套话和排比句 2. 每个段落必须有具体案例、代码或数据支撑 3. 段落控制在 4 行以内长段落必须拆行 4. 结尾给出可操作的建议而不是喊口号。 def generate_article(topic: str) - str: response client.chat.completions.create( modelgpt-4o-mini, # 根据自己的账号权限调节 messages[ {role: system, content: STYLE_PROMPT}, {role: user, content: f请围绕以下主题写一篇技术文章{topic}}, ], temperature0.7, # 控制随机性技术文建议 0.5~0.7 top_p0.9, # 控制候选词范围 max_tokens2000, ) return response.choices[0].message.content if __name__ __main__: print(generate_article(为什么大多数人用不好 AI 写代码))这里有几个参数需要说明temperature越大回答越发散适合创意文案越小越稳定适合技术教程。top_p与 temperature 类似一般二选一调节即可。max_tokens控制输出长度太长可能被截断。实际使用中建议不要把 API 调用写死在业务代码里而是把模板存入独立的prompts/文件夹用配置文件管理。这样更换模型、调整风格时不需要改主逻辑。4. 仓库二文本“去机器感”改写仓库解决“一眼 AI”问题4.1 什么是“AI 味”怎么去掉第二类仓库是各种“去 AI 味”“文本润色”“风格转换”的脚本集合。它们在中文社区里有各种版本有的是关键词过滤有的是长句拆分有的是调用大模型做二次润色。严格来说这里要说明一下边界我们讨论“去机器感”是为了提升文章的可读性而不是为了欺骗平台检测系统。一篇内容是否有价值最终取决于信息量和个人见解。用工具去掉“首先、其次、综上所述”等口头禅本质是在还原人类写作的自然状态。常见“AI 味”语言特征包括随着科技的飞速发展…… 综上所述我们可以得出以下结论…… 值得注意的是…… 不难发现…… 赋能、抓手、闭环、颗粒度下面用一个可运行的 Python 脚本演示初级“去 AI 味”处理。它的思路是先按高频词替换再把超过 80 个字符的长分句自动拆开。# 文件路径de_ai.py import re AI_WORDS { 首先: , 其次: , 再次: , 最后: , 综上所述: , 总而言之: , 不难发现: 你会发现, 众所周知: 每个人都知道, 值得注意的是: 需要注意的是, } def de_ai_text(text: str) - str: # 第一步替换高频 AI 套路词 for word, replacement in AI_WORDS.items(): text text.replace(word, replacement) # 第二步把过长分句拆短在逗号后新增换行 text re.sub(r([^。]{80,}?), r\1\n, text) # 第三步去掉连续空行 text re.sub(r\n{3,}, \n\n, text) return text.strip() if __name__ __main__: sample 首先随着人工智能技术的不断发展越来越多的内容创作者开始使用大模型生成文章。其次这些文章往往存在语言重复、内容空洞的问题。综上所述我们需要建立一套完整的写作工作流。 print(de_ai_text(sample))运行后输出大致长这样随着人工智能技术的不断发展 越来越多的内容创作者开始使用大模型生成文章。 这些文章往往存在语言重复、内容空洞的问题。 我们需要建立一套完整的写作工作流。但请注意这类脚本只是“兜底工具”不能替代真正的编辑工作。更好的做法是把 AI 生成的初稿当作一个“话痨同事”你需要动手改写删除冗余补充自己的案例。4.2 加入“人类证据”的改写清单无论用多少工具最有效的“去 AI 味”方式是加入三类内容类型示例个人经历“上周我排查一个内存泄漏问题时……”真实数据“在我维护的电商项目里接口响应时间从 800ms 降到 120ms……”具体决策“最终我们没有选择 Redis Cluster而是用了普通主从加本地缓存……”如果说 AI 负责“完成初稿”那作者就应该负责“提供经历”。一篇完全没有个人痕迹的文章即使句子再通顺读者也很难产生信任感。5. 仓库三选题与受众挖掘仓库解决“不知道写什么”5.1 GitHub 本身就是一座选题金矿第三类值得收藏的仓库是“挖掘受众需求”的数据分析类仓库。很多人忽略了一个事实GitHub 上每天都有大量开发者讨论自己的痛点、工具、库这些讨论就是天然的选题来源。简单说一个操作思路用 GitHub 搜索topic:写作、topic:chatgpt、topic:api等关键词找到近期热门仓库。看仓库的 Issues 和 Discussions记录用户反复提的问题。把这些问题转成文章标题。举个例子如果很多人在某个“一键生成文章摘要”的仓库 Issues 里问“支持中文吗”那你就可以写一篇《我用 Python 给 AI 生成器加上中文摘要能力附完整代码》。这类文章因为紧扣痛点流量的起点通常不会太差。下面用 GitHub 官方搜索 API 演示获取仓库列表。注意公开 API 有请求频率限制建议使用requests并控制调用频率。# 文件路径github_trending_search.py import requests import time # 如果你的请求频率较高最好配置自己的 GitHub Token HEADERS { Accept: application/vnd.githubjson, # Authorization: token 你的token } def search_repos(keyword: str, per_page: int 10): url https://api.github.com/search/repositories params { q: ftopic:{keyword}, sort: stars, order: desc, per_page: per_page, } response requests.get(url, headersHEADERS, paramsparams, timeout10) response.raise_for_status() for repo in response.json().get(items, []): print(f{repo[full_name]} stars: {repo[stargazers_count]}) print(f description: {repo[description]}) print(---) time.sleep(0.5) # 避免触发限流 if __name__ __main__: search_repos(writing)通过这类脚本你可以定期把“当前热点领域内的高星仓库”抓下来放到表格里形成自己的选题池。不需要太复杂的模型简单整理即可日期仓库名定位可写方向2025-xx-xx某写作工具AI 辅助写作安装教程、API 接入、对比测评6. 仓库四标题与内容结构生成仓库解决“起标题难、没框架”6.1 标题生成器的核心代码第四类仓库是内容工程模板。标题、大纲、社群文案、视频脚本这些内容都有套路可循所以可以直接程序化生成。写标题这件事不一定全靠人工憋。我们可以把历史爆款标题喂给大模型让它学习模式。下面是一个支持批量生成标题的 Python 示例# 文件路径title_generator.py import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) TITLE_RULES 请根据下面的要求为文章生成 10 个中文标题 1. 每个标题不超过 20 个字 2. 必须在标题中出现具体的数字或收益 3. 风格在“干货教程”和“经验分享”之间切换 4. 不要使用标题党词如“震惊”“重磅”“免费送”。 def generate_titles(content: str) - list[str]: response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一位公众号资深编辑。}, {role: user, content: f文章内容\n{content}\n\n{TITLE_RULES}}, ], temperature0.9, ) text response.choices[0].message.content return [line.strip().lstrip(0123456789.、 ) for line in text.splitlines() if line.strip()] if __name__ __main__: article 我在个人项目中用 Python 写了一个定期抓取 GitHub 热榜的脚本把数据存进 SQLite并生成日报。 for idx, title in enumerate(generate_titles(article), 1): print(f{idx}. {title})运行后可能会得到这样一组标题1. 我用 Python 抓 GitHub 热榜做了个自动日报 2. 每周省 2 小时我的 GitHub 热榜脚本方案 3. 从 0 到 1搭建一个 GitHub 热点监控工具 4. 别再手动刷 GitHub 了试试这个脚本 ...注意这种生成结果只能作为“候选池”。最后发布在平台时你要用平台自带的数据反馈去判断如果一层标题没数据就换一个角度重新生成。把标题选择当成 A/B 测试不要追求一次性完美。7. 仓库五变现启动套件仓库解决“内容怎么赚钱”7.1 从内容到产品的转发路径第五类仓库严格说是“启动器”或“样板间”包括落地页模板、支付对接示例、会员内容管理后台等。内容做到一定阶段后最自然的变现方式是文章/视频公域流量 - 用户关注 - 私域或邮件订阅 - 数字产品 - 复购GitHub 上有很多现成的落地页开源项目你可以用极低成本快速上线一个小产品页面。比如一个简单的“建站引导页”可以只包含三个核心模块一句话说明产品价值一个邮箱输入框一个支付/购买按钮。下面是一个最小可用的 HTML 模板片段放在landing/index.html中!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / titleAI 写作工具箱/title style body { font-family: sans-serif; max-width: 640px; margin: 80px auto; padding: 0 16px; line-height: 1.8; } .cta { display: inline-block; padding: 12px 24px; background: #1677ff; color: #fff; border-radius: 8px; text-decoration: none; } /style /head body h1AI 写作不走样提示词模板 改写脚本/h1 p包含 30 个写作场景提示词和一套可直接运行的“去 AI 味”脚本。/p a classcta hrefhttps://你的支付链接立即购买 19.9/a /body /html这里要特别强调不要一开始就做大而全的“知识付费平台”。正确节奏是先用一篇文章验证需求如果你的读者愿意为某份模板付费再花时间优化产品。很多技术人容易陷入“开发功能”的快乐反而忽略了内容分发和需求验证。7.2 订阅制内容的开源思路如果你有后端开发能力还可以考虑把内容仓库做成“订阅制”例如用 GitHub Private Repo 存放付费文档通过脚本检查用户是否在付费名单内在本地或 CI 中自动生成读者包。不过这里要注意把 GitHub 当作内容承载平台时不要存放涉及密钥、用户隐私、商业机密的资料。开源仓库不等于加密保险箱。8. 从“AI 初稿”到“好内容”的四步工作流前面五类仓库单独使用各有价值但真正爆发威力的是组合成一个完整流程。下面是我的日常内容生产工作流8.1 第一步用选题仓库确认“做什么”每周固定花 30 分钟用 GitHub 搜索 API 收集目标领域的高星仓库和 Issues 关键词。整理出一个不少于 20 条的选题池。选择标准不是“我喜欢”而是“目标读者是否有明确痛点”。8.2 第二步用提示词模板生成初稿从提示词仓库选一个最接近的模板加入领域限定和风格要求调用大模型生成初稿。生成时长控制在 5-10 分钟千万不要追求“一次生成、一次发布”。8.3 第三步人工修订并引入“个人证据”这是最关键的一步删除 AI 生成的开头套话加入你自己遇到的问题插入具体的代码、截图或数据把长段落拆成短句把“总而言之”换成“我的建议是”。不要在这里偷懒。读者愿意花时间阅读本质上是在为你的“真实经历”付费而不是为 AI 的词句重组付费。8.4 第四步多渠道测试与数据回收同一个主题的文章可以按平台调性重新修改标题和开头。下面是一个简单的分发参考平台标题策略内容重点CSDN强调技术方案和排错经验代码完整、步骤清晰公众号强调个人经历和心得故事感强、短句多知乎强调问题解决过程有理有据、客观分析小红书强调“看完就会”清单体和图片截图发布后收集两三个核心数据阅读量、收藏量、评论关键词。用数据反向修正选题和标题。9. 常见问题与排查思路实际运行这些仓库和脚本的时候大家会遇到一些高频问题。这里整理成一张表格方便检索问题现象常见原因解决思路GitHub 仓库克隆很慢网络不稳定或仓库体积过大只克隆必要分支改用镜像站阅读避免用第三方上传密码API 返回 401 错误API Key 配置错误或权限不足检查环境变量确认模型是否对当前 Key 开放生成内容被截断max_tokens 设置太短提高 max_tokens或把文章拆成多段生成提示词过长导致报错系统提示词超过模型上下文限制精简提示词把示例放到用户消息中脚本报 ModuleNotFoundError未安装依赖使用 venv 建虚拟环境再执行 pip install -r requirements.txt去 AI 味脚本把句子改成病句规则过于机械只保留高频词替换长句拆分需要人工校对批量生成标题重复率高temperature 设置过低把 temperature 调整为 0.9~1.0增加随机性内容发布后数据很差选题偏离读者需求回到 GitHub Issues 和评论区重新挖掘真实痛点10. 最佳实践与工程建议10.1 内容生产也要“配置化”建议把提示词、风格要求、禁用词列表统一放到配置文件中不要散落在代码和聊天记录里。示例结构content_workspace/ ├── prompts/ │ ├── article_system.md │ ├── title_rules.md │ └── video_script.md ├── scripts/ │ ├── generate_article.py │ ├── de_ai.py │ └── github_search.py ├── data/ │ ├── topics.md │ └── published_log.csv └── output/ ├── draft/ └── final/这样做的价值在于几个月后你想复现一种风格不需要重新“调教” AI只需读取当时的配置文件即可。10.2 API 调用要控制成本和频率大模型 API 不是无限免费的。建议使用异步批量调用时加入time.sleep并且设置单次运行的最大请求数。对于每天都要跑的任务优先考虑先本地缓存结果避免重复请求。10.3 内容版权与合规边界使用开源仓库时要注意三个原则查看仓库开源许可证尤其是“禁止商用”类许可证抓取 GitHub 数据时遵守 API 使用条款不要高频请求自己写的提示词模板和脚本再小也可以开源回报比想象中大。10.4 用“读者反馈”驱动仓库选型不同垂直领域的读者偏好差异很大。写技术教程的读者更看重代码能跑写职场成长的读者更看重案例真实。建议每两周复盘一次看看哪类内容收藏率高然后回到 GitHub 找对应领域的仓库做深度研究。11. 一点收尾建议很多内容创作者把 AI 当成“一键生成工具”这是对 AI 最大的误解。真正稳定的创作方式是把 AI 嵌入一个可迭代的内容系统用开源仓库持续挖掘选题用提示词工程控制风格用脚本去机械感用数据反馈调整方向最后再思考变现产品。如果你想从今天开始动手不需要一下子收藏几十个仓库。建议先做三件事在 GitHub 上搜索awesome-chatgpt-prompts克隆一份挑出 3 个适合你领域的提示词。把上面第四节里的“去 AI 味”脚本复制到本机用自己最近的一篇文章跑一遍。用 GitHub 搜索 API 爬 20 条你领域里的高星仓库整理成下周的选题池。这五个方向全部跑通之后你收获的不只是一篇“不那么 AI”的文章而是一套可持续的内容生产系统。祝创作顺利。