分享:你看到的10w+文章可能是这么来的……

　　分享:你看到的10w+文章可能是这么来的……

　　你打开了 Tweet 2 of All Things Deadline

　　伪原创 在流水线上

　　文/雨潮

　　一。

　　点击打开一个推送，越往下拉越熟悉；

　　搜索某个话题，看了文章的文章，总觉得文章的几篇文章的作者好像是同一个学校的。不仅观点一致，写文章的小习惯也是一模一样的；

　　一些已经成为常识的健康知识，还在健康频道的文章中反复出现……

　　在这些文章的背后，是活跃的伪原创产业。

　　二。

　　事实上，伪原创 的创作并没有什么花哨的。

　　相反，只需一组管道项目即可轻松创建数千个 伪原创文章。

　　笔者通过某大学*敏*感*词*组亲自参与伪原创，摸索出其流水线生产步骤：

　　第一步，由专人在网上采集整理同类型文章。感谢当今日益强大的 Internet，您可以通过搜索 关键词 找到所有相同类型的 文章。

　　做准备工作的人将这些文章制作成两张Excel表格，一张“关键词库”，并将每个文章的标题与文章的标题进行比较所有 关键词 都列在表中；另一个“内容库”，每个文章 的标题都列在与文章 的正文部分对应的表中。

　　

　　第二步是命名伪原创文章。相同的内容可以用很多标题来表达，比如介绍凉果。文章 的标题可以是“什么是凉爽的水果？” “柿子凉吗？” “吃柿子会拉肚子吗？？“ 等等。

　　在第三步中，出现了 伪原创 编写器。前两个步骤为这一步奠定了基础。作为一个伪原创作家，你只需要完成第一段的前100字原创，复制粘贴正文，5分钟即可完成一篇文章文章。

　　如何复制和粘贴以避免 原创 检测？

　　例如，伪原创的正文结构由原创的第一段+字幕1+第二段+字幕2+第三段组成。

　　完成第一段的创建后，伪原创作者根据标题提取了两个关键词，用Ctrl+F快捷键在Excel中“内容库”中搜索，发现相同的< 文章 的关键词，截取了 文章 片段复制和粘贴。

　　文章 积分越多，原创 度数越高。

　　一般来说，每个字幕下的内容来自2篇文章，可以通过原创的度数检测。

　　刚刚发布了一篇文章伪原创文章。

　　三。

　　当然，这是最底层的伪原创。

　　但是，它是最快的，一个熟练的伪原创作家甚至可以在一天内完成数百个伪原创文章。

　　这也意味着互联网上泛滥最多的伪原创是最底层、非技术性的伪原创，从未被科学鉴定过。

　　大家，你抄我，我抄你，写文章的人对文章所涉及的专业知识一窍不通，从不认真阅读文章的内容，更别提判断真假。

　　这类伪原创最大的市场在养生保健、婴幼儿教育等领域，这些领域不像美容化妆品领域会不断更新迭代，不像技术，这将被许多大牌所关注和识别。他们的受众是最普通的人，但正是因为这个广阔的“市场”和专业知识的特殊性，他们才成为伪原创文章的重灾区。

　　

　　四。

　　伪原创 对原创作者的劳动成果的没收和篡改，对原创作者本人是极大的伤害。

　　辛辛苦苦写的文章一被伪原创盯上，内容就被截取并以他的名字命名。

　　这无需重复打击原创 的市场热情。

　　然而，伪原创制作的危害绝不仅限于对原创作者的侵害。

　　更严重的是，如果伪原创“内容库”中收录的文章本身就是一个谣言，伪原创会将这个谣言放大一千倍。

　　我们从小就听说过三个人变成老虎的故事。同样的道理，如果同样的内容被不同的人、不同的文章不同的微博、即使是最聪明的人反复展示在读者面前，也有被混淆的风险。

　　“盐可以抵抗核辐射”、“艾滋病患者通过血液传播艾滋病”、“人体酸碱体质学说”……都在网络上广为流传，引起了社会的高度关注。

　　谣言在真相的幌子下流行，信徒的数量不详。最终，这成了彻头彻尾的谣言，造成的负面社会影响是不可逆转的。

　　当然，自媒体“造谣得利”，群众不辨别真假也是有原因的。

　　但毫无疑问，伪原创 绝对是有罪的。

　　我们常说互联网不是法外之地，但是这一次，逼迫原创内容的伪原创如果一步步在夹缝中生存、散播谣言，是否能逃过法律的制裁？质疑责任？

　　结束

　　总结:Pipenv: 吹嘘自己无所不能，实际上没什么卵用

　　Pipenv 是一个 Python 打包工具，它可以很好地完成一件事——应用程序依赖管理。然而，它也受到各种问题、限制和发展过程的影响。过去，Pipenv 的宣传材料对其目的和支持者具有高度误导性。

　　在这个 文章 中，我将探讨 Pipenv 的问题。真的推荐吗？每个人——或者至少是绝大多数人——都能从中受益吗？

　　内容

　　应用差异

　　运行脚本（差）

　　一切都完成了

　　“官方推荐工具”，或者我们如何做

　　《Pipenv - Python官方网站推荐的Python打包工具，免费（免费版）。》

　　上面的slogan经常在Pipenv的README文档中出现好几个月：这个slogan是在2017-08-31添加到README文档中，最后在2018-05-19被删除。有一段时间（2018-05-16），有说明（管理应用程序依赖项，Pypa 没有），大约 15 分钟后，口号变成了“Pipenv 是世界上最糟糕的”“或其他可能意味着（这是维护者的咆哮）。

　　口号 README 声称 Pipenv 是 Python 打包工具的关键。问题是：不是那样的。Pipenv 有时可能有点用，但对于其他许多人来说，尝试该工具只是令人沮丧。我们稍后会讨论这个问题。

　　这个口号值得吐槽“官”和“官”两点。使它成为“官方”的原因是关于 [1] 的简短教程，它是 Pypa 的打包用户指南。还值得注意的是，它引用了这个词，听起来像 Pipenv 得到了 Python 核心团队的认可。Pypa（Python Packaging Authority）是一个独立的组织——他们负责为 Python 打包文件（包括、setuptools、pip、wheel、virtualenv 等），因此这种背书具有误导性。当然，Pypa 是 Python 的重要组成部分；来自核心团队的认可——例如，收录在官方 Python 发行版中——更为重要。

　　这个口号引发了很多热烈的讨论，可能是自 5 月在 Reddit 上发布以来最受关注的帖子。这一变化是由 Reddit 上的这个帖子引发的。我建议完整阅读这篇文章。

　　Pipenv 能做什么

　　我们已经看到 Pipenv 用于管理应用程序依赖项。让我们找出这个词的真正含义。

　　应用程序依赖项

　　这是 Pipenv 的一个例子：我正在开发一个基于 Django 的 网站。我创建了 ~/git/website 并在该目录中运行 pipenv install Django。管道：

　　该过程的最后一部分是最耗时的。在锁定依赖版本时，Pipenv 暂停了 46 秒，这是 Pipenv 的显着问题之一：慢。当然，它不是唯一的，但它绝对没有帮助。损失 46 秒并不算多，但是当我们在计时测试部分做了更长的等待时，我们就会知道这个小问题会让用户觉得使用这个套件很麻烦。

　　运行脚本（差）

　　但让我们继续前进。pipenv run django-admin startproject foobanizer 是我现在要用的，打字不方便，芝麻绿豆这些小东西一定要运行pipenv。（manage.py 脚本框有 /usr/bin/env python。）我可以运行 pipenv shell 来获得一个新的 shell，它默认运行 activate 脚本，在虚拟激活中给你两个中最差的一个：笨拙新的 shell，以及 shell 构建者不喜欢的激活脚本。

　　使用 pipenv shell 意味着生成一个新的子 shell，执行 shell 启动脚本（例如 bashrc），并要求您使用 Exit 或 ^D 退出，如果您键入“deactivate”，则在虚拟程序之外使用额外的 shell。或者您可以使用 --fancy 模式在启动子 shell 之前操作 $PATH ，但它需要特定的 shell 配置，其中 $PATH 在非登录 shell 中不被覆盖 - 也经常更改终端模拟器的配置以运行登录 shell，因为许多 Linux 终端不这样做。

　　为什么会这样？因为命令不能操纵它生成的 shell 的环境。这意味着 Pipenv 必须假装它正在做的事情是合理的，而不是解决方法。这可以通过使用 source$(pipenv-venv)/bin/activate （可以变成整洁的别名）或 shell 包装器（类似于虚拟包装器）手动激活来解决。

　　全部完成

　　不管怎样，我想在我的 网站 上写一个博客。我想用 Markdown 语法编写它们，所以我运行了 pipenv install markdown，几秒钟后，它被添加到了两个 Pipfile 中。我可以做的另一件事是 pipenv install-dev IPython，并获得一个方便的 shell 来修改，但它将被标记为 dev 依赖项 - 因此，不会在生产中安装。最后一部分是使用 Pipenv 的一个重要优势。

　　

　　当我完成我的 网站 工作后，我将两个 Pip 文件提交到我的 git 存储库并将它们推送到远程服务器。然后我可以克隆到 /srv/website。现在，我可以运行 pipenv install 来安装所有生产包（但不安装开发包 - 将安装 Django、pytz、Markdown，但不会安装 IPython 及其所有依赖项）。只有一个警告：默认情况下，虚拟服务器仍将在当前用户的主目录中创建。在这种情况下这是一个问题，因为它需要由 nginx 和 uWSGi 访问，它们无法访问我的（或根）主目录，也无法访问它们自己的。这可以通过导出 PIPENV_VENV_IN_project=1 来解决。但是请注意，每当我通过 Pipenv 在 /srv 中使用应用程序时，我都需要导出此环境变量。该工具支持加载 .env 文件，但仅在运行 pipenv shell 和 pipenv 运行时。你不能用它来配置 Pipenv。要使用 nginx 或 uWSGI 运行我的应用程序，我需要知道确切的虚拟路径，因为我无法将 pipenv 作为 uWSGI 配置的一部分运行。

　　Pipenv 不能做什么

　　上面提到的工作流程看起来很合理，对吧？有一些缺陷，但除此之外，它似乎工作得很好。Pipenv 的主要问题是：它运行在一个工作环境中，而且只有一个工作环境。尝试做任何其他事情，你会遇到很多麻烦。

　　Setup.py、资源分配和轮子文件

　　Pipenv 只关心管理依赖项。这不是包装工具。如果你想把你的东西放在 PyPI 上，那么 Pipenv 用处不大。您仍然需要使用 install_Requires 编写 setup.py，因为 Pipfile 格式仅指定依赖项和运行时要求（Python 版本），因此包名称没有位置，并且 Pipenv 不会强制/期望您安装项目。在管理开发环境时很方便（作为 Requiments.txt 的替代品，或者用来编写上述文件的东西），但是如果您的项目有 setup.py 文件，您仍然需要手动管理 install_Requires。Pipenv 也不能自己创建 Wheels 文件，而且 pip freeze 会比 Pipenv 快。

　　在项目场地外运营

　　Pipenv 的另一个问题是使用工作目录来选择虚拟环境。[3] 假设我是图书馆的作者。我的 foobar 库的用户刚刚报告了一个错误并附加了一个 repro.py 文件让我重现该问题。我将文件下载到文件系统上的 ~/Download 目录。这可以很容易地在具有以下语句的普通旧虚拟器的备用 shell 中重现：

　　然后我可以启动我的高级 IDE 来修复错误。我不需要 cd 在这个项目中。但是对于 Pipenv，我真的做不到。如果我使用命令行选项将 dummy 添加到 .venv，我可以输入 ~/git/foobar/.venv/bin/python~/Download/Replei.py。如果我使用集中式目录 + 分片，并且还没有存储分片，那么 Tab 实现就成为强制性的。

　　如果我有两个 .py 文件或 reple.py 文件，这取决于在当前工作目录中怎么办？

　　那是相当丑陋的。而且，使用虚拟包装器，我可以这样做：

　　不要忘记 Pipenv 不能帮助我编写 setup.py 文件、分发代码或管理版本。它只是管理依赖关系，而且做得很糟糕。

　　尼古拉

　　我是静态站点*敏*感*词*的副维护者：Nikola。作为其中的一部分，我需要在以下位置运行 Nikola：

　　名单很长。Nikola 的最终用户可能没有那么长的列表，但他们可能拥有多个 Nikola 站点。Pipenv 不适用于我和上述用户。要使用 Pipenv，所有这些存储库都需要位于一个目录中。我还需要为 Nikola 用户创建一个单独的 Pipenv 环境，因为这需要 Django。另外，如果我们想利用项目中的文件，Pip 文件必须与 ~/git/Nikola 链接。所以，为了让 Pipenv 整洁，在 SSD 上测试/错误复制（并更快地磨损它）等......我想要一个 ~/Nikola 目录。我也可以直接使用虚拟环境。但在这种情况下，Pipenv 失去了它的用处，使我的工作流程更加复杂。我不能使用虚拟包装器，因为我需要在其上添加一个模糊匹配系统，或者记住附加到我的虚拟名称的随机字符串。

　　希望使用 Pipenv 的 Nikola 最终用户也将被迫使用特定的目录结构。如果该站点充当项目的文档，并在另一个项目中复制怎么办？两个虚拟环境，浪费了 100 兆字节。或者更糟糕的是，Nikola 最终出现在另一个项目的 Pipfile 中，这在技术上对我们的下载统计数据是有利的，但对于其他项目的贡献者来说却不是很好。

　　我试着测试那部分时间

　　Pipenv 以速度慢着称。但它到底有多慢？我测试了它。我使用了两个测试环境：

　　远程：DigitalMarine VPS，这是法兰克福最便宜的（1 VCPU），Python 3.6/Fedora 28

　　本地：我的 2015 13" Apple 笔记本电脑（基本型号）上的 Python 3.7，在相当慢的互联网连接上（在好的时候为 1000 万 bps，但没有进行一次测试）

　　两者都在运行由 pip 于 2018 年 7 月 1 日安装的 Pipenv。

　　还安装了以下缓存：

　　

　　事实证明，Pipenv 喜欢用缓存和锁定做一些奇怪的事情。查看活动监视器会发现，虽然 Pipenv 显示其锁定的 [包] 依赖项，但网络活动正在进行......线程挂起。没有文件会告诉你。最糟糕的例子是两次运行完成的本地 Nikola 安装：Pipenv InstallNikola 的第一次运行在安装包 [4] 后立即中断，因此缓存中有所有必要的轮子文件。安装耗时 10 分 7 秒，其中 9 分 50 秒是通过锁定依赖项和安装锁定的依赖项完成的 - 所以大约 9 分半钟盯着静态屏幕，工具在后台执行某些操作 - Pipenv 不会告诉你在这个阶段会发生什么。

　　（2018-07-22 更新：在 Pipenv 测量中：第一项是 Pipenv 可执行的总时间。第二项是等待 Pipenv 完成其“主要”任务：锁定依赖项并安装它们。 Pipenv 开始锁定的时间出现依赖时开始，出现提示时结束。第三项是 Pipenv 报告的安装时间。因此，Pipenv install time ⊇ lock/install time ⊇ Pipfile.lock install time。）

　　替代工具和新工具

　　似乎没有人对 Python 封装感到满意。因此，“最佳新包装工具”的角色出现了许多新的竞争者。除了 Pipenv，还有 Hatch 工具（Ofek Lev）和 Poetry 工具（Sébastien Eustace）。两者都在“官方”教程中列为备用轮胎选项。

　　孵化¶ 工具

　　Hatch 工具尝试管理整个打包过程。它可以说是一种资产，因为它有助于替代其他工具。但是，也可以说是增加了单点故障。Hatch 工具根据 requments.txt 和 setup.py 等标准文件工作，因此可以很容易地被其他文件替换。它不像 Pipenv 那样花哨，但更易于配置。Hatch 工具做出的一些选择是可疑的（例如手动解析 pkg/_init_.py 的版本号，将测试套件安装到 Site-Package（相当普遍的疏忽），或者它的外壳功能与 Pipenv 一样丑陋），而且它不做任何管理依赖项的工作。它不一定适用于我前面提到的 Django 用例，也不一定适用于软件的最终用户。

　　诗歌¶工具

　　诗歌工具介于两者之间。它的主要目标是接近 Pipenv，但也可能将工作分配给 PyPI。它竭尽全力隐藏它在幕后使用 Pip 的事实。它的 README 带有一个“关于 Pipenv”的扩展阅读部分，我建议您阅读它——它有更多 Pipenv 的坏特性。Poetry 工具声称使用标准化 (PEP 518) pyproject.toml 文件代替通常的批量文件。不幸的是，唯一标准化的是文件名和语法。Poetry 工具使用自定义的 [tool.poetry] 部分，这意味着人们需要 Poetry 工具来充分使用它创建的包，因此他们离不开供应商。（上面的 Hatch 工具还会生成一个 pyproject.tmpl，其中收录元数据部分...）这里有一个构建功能，可以生成一个带有设置的 sdist。

　　在一个简单的 Poetry 工具加上 Nikola 测试中，修复依赖项需要 24.4s/15.1 s/15.3 s（根据 Poetry 工具计数、远程环境、缓存删除），完成有保证的输出，没有静默锁定。不如 pip，但比 pipenv 好。此外，代码库和布局非常复杂。Poetry 工具生成工具包而不仅仅是管理依赖项，因此它通常比 Pipenv 更有用。

　　皮普在这里留下来！

　　但是在所有关于新工具的讨论中，我们忘记了旧工具，它们做得很好——事实上，新工具仍然需要它们。

　　Pip 做事又快又好。它不支持拆分生产和开发包（如 Pipenv 和 Poetry 工具）。这意味着 pip freeze 和 pip install 是即时的，代价是：(A) 需要两个独立的环境，或者 (B) 在生产中安装开发依赖项（这应该是对 HDD 空间的浪费，而在架构良好的环境中）系统，仅此而已）。

　　虚拟环境管理功能可以由虚拟包装器提供。这个工具的主要优点是shell脚本实现，这意味着WorkonFoo不需要生成新的子shell来激活Foo虚拟程序（Pipenv、Hatch工具和Poetry工具中的一个问题，我在“运行脚本”中描述了Pipenv操作（差）”章节中提到）。 Pipenv 倡导者经常提出的一个论点是，创建一个虚拟环境不需要关心它自己或它在哪里。不幸的是，许多工具都需要用户有这方面的知识，或者强制特定位置，或要求它与主目录不同。

　　我有我自己的名字，用于自动发布的合理项目模板，称为 (伪原创's) Python 项目模板 (PyPT)。

　　是的，setup.py 文件并不理想，因为它们是使用 .py 代码和函数执行的，因此很难访问元信息（./setup.py egg_info 创建一个可以访问工具的文本文件）。它们的主要优点是它们是唯一被广泛支持的格式 - pip 实际上是默认的 Python 包管理器（预安装在 windows 和 mac 上），需要先安装/引导其他工具。

　　Pipenv的死亡率

　　一个好的打包工具是稳定的。换句话说，它不会不断变化，它会努力维持现有的环境。重新下载系统上的所有东西一点都不好玩，“/usr”现在变成了“/stuff”，“/usr”中的所有文件都没有用，不能删除。这是 Pipenv 的杰作：

　　在一个月的时间里，虚拟主机的位置发生了两次变化。如果用户没有阅读变更日志，也没有手动干预（还值得注意的是问题和 v3.3.4 变更日志中提到了选项名称），那么他们会有一个旧的 .venv 目录，因为他们采取了新的计划。然后，在切换到 v3.5.0 后，他们会在主目录中隐藏一个陈旧的 vhost，因为 pipenv 决定添加分片。

　　此外，这是不可配置的。即使用户想禁用路径中的分片，也无法禁用。非常适合那些想要混合 Pipenv 和虚拟包装器的人。

　　Pipenv 是一个非常有主见的工具，如果开发团队改变主意，旧的方法是不支持的。

　　Pipenv更新很快，非常不负责任。比如 2018-03-13:21 到 2018-03-14 13:44 之间（24 小时多一点）， Pipenv 更新了 10 次，从 11.6.2 到 11.7.3，根本没有通知用户什么在这个版本中发生了变化。