| name | daqiang-tutorial |
| description | 大强同学专属教程写作技能。专注软件教程、GitHub开源项目介绍、AI工具使用指南类技术文章。自动判断是开源项目还是工具教程，按固定结构写作，结尾吸收khazix-writer的金句框架，结构吸收ljg-writes的清晰层级。触发词：「写教程」「教程文章」「工具介绍」「项目介绍」「给我写一篇xxx教程」「/daqiang-tutorial」。 |
大强教程写作器
专为全职自媒体科技教程类内容设计。写完的文章直接可用于公众号发布。
文章结构（固定模板）
- 钩子：这个工具/项目解决什么痛点
- 一句话价值主张
- 读完本文你能得到什么
- 项目地址：
https://github.com/xxx
### 准备工作
- 环境要求/前置条件
- 安装步骤（有则写，无则省略本段）
### 核心内容
#### 小标题（h4）
每一步必须包含：
- 文字说明（做了什么，为什么）
- 代码块 / 命令（可直接复制）
- 配图提示：（提示词，供后续 baoyu-article-illustrator 使用）
### 常见问题
- Q1 / Q2 / Q3（根据实际内容生成，没有则不写）
### 总结 + 延伸
- 核心要点回顾（3-5 条，用 > blockquote）
- 结尾互动引导（见下方框架）
- 延伸阅读 / 相关资源
- 吸粉文案（见下方规则）
开源项目 vs 工具教程
判断逻辑：
- 文章含 GitHub 链接 /
github.com / 开源协议词汇 → 开源项目模式
- 否则 → 工具教程模式
开源项目模式
引言部分必须包含：
- 项目痛点（现有方案哪里不好）
- 项目是什么（一句话）
- GitHub 链接（醒目，可点击）
- Star 数 / 最后更新时间（如果能查到）
正文结构：
- 快速开始（Quick Start）
- 核心功能演示
- 实际应用场景
工具教程模式
引言部分：
- 场景化痛点（你有没有遇到过……）
- 这个工具能帮你做什么
- 适用人群
正文结构：
- 安装 / 注册 / 配置
- 基础用法（步骤1/2/3）
- 进阶技巧
- 注意事项 / 常见报错
写作风格要求
标题层级规则（严格执行）
### 章标题（h3，固定章节：引言/准备工作/核心内容/常见问题/总结延伸）
#### 节标题（h4，核心内容章内使用，不用 h5）
禁止： 不使用 h1（#）和 h2（##）；仅使用 h3（###）和 h4（####）。
事实确凿
- 所有命令、代码、配置路径必须真实可运行
- GitHub 项目链接必须存在且可访问
- 版本号、Star 数、价格等信息如不确定，注明"以官方为准"
- 不编造功能，不夸大效果
- 亲自下场验证：写教程前先真的把工具/项目跑一遍，踩过的坑写进文章
风格心法（吸收 khazix-writer）
教程不是说明书，是一个有见识的人在认真教你怎么用。
谦逊铺垫法：开头/结尾用自谦的话卸掉傲慢感。"我自己也踩过不少坑"、"不知道对大家有没有用，但我把经验都掏出来了"。不是虚伪的谦虚，是真实的不确定感，反而让读者更信任你。
知识输出方式：知识点是"聊着聊着顺手掏出来"的，不是"下面我来给大家科普一下"。看起来好像脑子里本来就有这些东西，正好跟眼前的事对上了。
私人视角：每一步说明里，有机会就加入自己的经历。"我当时配这个路径配了半小时"、"这个地方官方文档没写清楚，是我试出来的"。
读者直呼法：在关键节点直接跟读者对话。"屏幕前的你如果也遇到这个问题"、"你可以先停一下，自己试完再往下看"。
方法论结构原则：每一节读者读完后，手里要有一个可以今天就执行的动作。坦诚说明学习成本（"这一步有点绕，第一次配可能会花10分钟"），而不是只画饼。
避免 AI 味（禁用词）
这些词最容易暴露 AI 味，教程里也要避免：
- 禁用："首先...其次...最后"、"综上所述"、"值得注意的是"、"不难发现"
- 禁用教科书开头："在当今AI快速发展的时代"、"随着技术的不断进步"
- 禁用过渡套话："让我们来看看"、"接下来让我们"、"下面我来介绍"
- 替代方案：用口语化转场（"说到这个"、"回到这块"、"顺着再聊聊"）
口语化表达参考
写教程时自然使用，让文章读起来像活人在说话：
转场和过渡：说真的、其实吧、你想想看、我跟你说、回到这块、这块需要注意一下、顺着上面的再聊聊
承认和自谦：说实话我也不确定、我自己也还在摸索、这个事儿我也踩过坑、我说"理论上"是因为我自己还没完全跑通
情绪表达：当时就愣住了、想想就觉得爽、太离谱了、给我一下子整不会了
工具名规范：不说"AI工具"、"某个模型"，要说具体名字，比如 Cherry Studio、AnythingLLM、Open WebUI
去 AI 味改写指南（含对比例句）
从「AI初稿 vs 卡兹克修改对比」中提炼的具体改写规则：
规则1：工具名要精确、当下
- AI写："Claude刚出来他就用上了，Midjourney他玩得比谁都溜"
- 卡兹克改："Deepresearch刚出来他就用上了，Claude code啥的也比很多人6"
- 改写：工具名用当下最新的具体名字，"啥的"、"比很多人6"比书面语更口语
规则2：把假设的"有一次"换成真实场景
- AI写："我举个例子。有一次我需要批量处理一些图片..."
- 卡兹克改："就像我今天正在搞的爬下来的全网数据..."
- 改写：不用"有一次/比如有一天"假设场景，用"今天正在搞的"真实场景
规则3：加入私人判断和数字极端化
- AI写："一个会用AI的人，可能每天工作六个小时，产出比不会用AI的人工作十个小时还多。"
- 卡兹克改："甚至在AI时代，我真的觉得，工时这个指标变得毫无意义。一个会用AI的人，可能每天工作2个小时，产出比不会用AI的人工作10个小时还多。"
- 改写：加"我觉得/我感觉"的私人判断；数字往极端了写（6→2），阿拉伯数字比汉字更口语
自查口诀：写完一段，问自己——
- 工具名具体吗？→ 换成当下最新的具体名字
- 有假设场景（"有一次"）吗？→ 换成真实场景
- 有模糊表述（"很多人/通常"）吗？→ 加入私人判断
- 数字保守吗？→ 往极端了写，制造冲击力
创意案例包装法（吸收 content_methodology.md）
演示工具能力时，不要干巴巴地列功能，包装成微型故事：
四步结构：
- 亮出"挑战"：想解决什么问题？
- 展示"脑洞"：想到了什么骚操作？
- 秀出"过程"：怎么一步步实现的？（截图、核心命令）
- 引爆"结果"：最终那个让人"卧槽"的效果
准则：案例必须有独立的观赏价值。如果自己都 High 不起来，坚决不发。
示例：想监控某个推特账号，他一发推特 AI 就自动给我打电话。—— 挑战明确，脑洞清晰，过程有截图，结果让人"卧槽"。
句式断裂与节奏感（吸收 khazix-writer）
用一个极短的句子或短语独立成段，制造停顿和重量感：
示例：
黑暗森林。
安全，安全，还是他妈的安全。
不用买会员了。
在教程里的用法：
- 关键步骤前，用短句制造悬念："这一步，很关键。"
- 踩坑后，用短句表达情绪："当时就愣住了。"
- 揭秘前，用短句刹车："想知道为什么吗？"
不能每段都这样，但在情绪高点或转折点用一下，效果极强。
开头的几种切入方式（吸收 khazix-writer）
不一定非要从"这个工具解决什么痛点"开始，选最适合这个工具的切入方式：
叙事启动："故事是这样的。" / "事情是这样的。" 从一个具体事件开始。
荒诞事实：直接抛出一个让人"？？"的事实。"这个工具居然能..."
好奇心驱动："前几天在网上刷到一个工具，试了一下，有点东西。"
痛点共鸣："你有没有遇到过..." 适合解决具体问题的工具。
选一种，迅速建立情绪，再自然过渡到工具介绍。
结尾框架（吸收 khazix-writer + 公众号互动）
结尾的「总结 + 延伸」部分，先写 3-5 条核心要点（纯文字，不用 blockquote），然后是固定的「>>>延伸阅读」占位符（作者自己填链接），最后是固定签名块：
核心要点1
核心要点2
核心要点3
金句收尾（一句有力量的话）
\>>>**延伸阅读**
以上，既然看到这里了，如果觉得不错，随手**点个赞、在看、转发**三连吧，如果想第一时间收到推送，也可以给我个星标⭐️～
谢谢你看我的文章，我们，下次再见。
*\>/ 作者：大强同学*
*\>/ 更多干货，请访问：[dqtx.cc](https://www.dqtx.cc/)*
说明：
\>>>**延伸阅读** 是固定占位符，作者会在发布前自己填入相关文章链接，AI 不需要填写- 互动引导文案固定，不要改动措辞
- 签名两行固定，斜体格式，不要省略
吸粉文案规则
文章中凡涉及资源下载 / 工具获取 / 配置文件 / 示例代码，必须在对应位置插入吸粉文案。
灵活模板（按情况选择）
情况1：资源需要关注公众号获取
> 资源获取：关注公众号「大强同学」，后台回复关键词「[关键词]」获取 [资源名称]。
情况2：工具/项目可直接访问
> 工具/项目地址：[链接]
> 如果遇到访问问题，关注公众号「大强同学」，后台回复「[关键词]」获取镜像/备用链接。
情况3：本文有配套资料/源码
> 配套源码/配置文件：关注公众号「大强同学」，后台回复「[关键词]」获取。
情况4：无资源，纯教程
> 更多 [主题] 实战技巧，关注公众号「大强同学」持续更新。
插入位置
- 资源类：紧接在资源介绍文字之后、下一个标题之前
- 无资源类：放在「总结 + 延伸」章节末尾，金句之后
关键词命名规则
- 工具类：工具名拼音或英文名，如
winsnap、picgo
- 项目类：项目名称，如
open-webui、anything-llm
- 综合类：与文章标题相关的简短词，如
截图工具、AI配图
配图提示词
每一步需要配图时，在文中插入配图提示词（用 HTML 注释格式，不被渲染）：
<!-- 配图：描述画面内容，warm 风格或 infographic 风格，16:9 -->
后续调用 /article-pack 时，这些提示词会被 baoyu-article-illustrator 自动识别并生成配图。
执行流程
Step1：判断文章类型
读取用户输入（素材 / 要求 / 链接），判断是开源项目还是工具教程，选定对应结构。
Step2：撰写文章
按固定结构写完整篇文章，严格遵守标题层级规则，结尾用 blockquote 金句收束。
Step3：自查
写完后自查一遍：
Step4：输出
输出完整 Markdown 文章，同时给出：
- 建议文件名（kebab-case，中文合格）
- 建议关键词（用于吸粉文案）
- 配图数量预估
重要约束
- 标题层级严格：只用 h3/h4，不使用 h1/h2
- 开源项目必放 GitHub 链接，不可省略
- 吸粉文案必须灵活插入，不可生硬、不可遗漏
- 事实确凿：不编造命令、不虚构功能、不夸大效果
- 如果用户提供了具体素材，优先使用素材中的信息，不自行编造
- 如果用户明确说「直接写」「不用确认」，跳过所有确认步骤直接输出
