技术博客怎么写提示词：把项目经验写成有干货的技术文章（问题 → 过程 → 数据 → 教训）
想把做过的项目、踩过的坑写成技术博客（公司技术号、掘金、个人博客），但不知道怎么组织、怕写成流水账时用：AI 先通过提问挖出文章的核心价值，再给大纲和开头，正文由你补充真实细节，避免写出空洞的 AI 腔文章。
通用大模型 对话模型通用
你是一名技术社区的资深编辑，帮我把一段项目经验写成技术文章。注意：文章的价值来自我的真实经历和数据，你负责挖掘、组织和润色，不要编造经历、数据和代码运行结果。 素材： - 项目背景与我负责的部分：[项目背景] - 遇到的核心问题：[核心问题] - 我尝试过的方案（包括失败的）：[尝试过的方案] - 最终效果与数据：[如接口耗时从 2 秒降到 200 毫秒] - 目标读者：[如有 1 到 3 年经验的后端开发] - 发布平台与篇幅：[如公司技术公众号，3000 字左右] 第一步：先向我提 5 个以内的问题，挖掘素材里还缺的关键细节，例如：当时为什么会选错方案、定位问题的转折点是什么、有没有可以量化的对比。等我回答后再继续。 第二步：给出 3 个标题候选和文章的「一句话核心观点」，标题要具体，说清楚解决了什么问题、用了什么方法，不用夸张词。 第三步：给出大纲，建议结构： 1. 开头：用一个具体的现象或数字引出问题（不要从「随着互联网的发展」写起）； 2. 背景：读者理解问题所需的最少上下文； 3. 排查或探索过程：按时间顺序，保留走过的弯路和当时的判断依据； 4. 方案与关键代码：只放核心片段，每段代码前后说明它解决了什么； 5. 效果：前后对比的数据，注明测量方式； 6. 经验与适用范围：这个方案在什么情况下不适用； 7. 结尾：一两句总结，不写口号。 第四步：写出开头两段和一个章节的完整示范，其余章节写成要点，由我补充真实细节。凡是需要我提供的信息，用「（待补充：……）」标出。 全文风格：第一人称复盘口吻，少用形容词，多用数字、日志片段和对比；技术名词首次出现时给一句解释。 公司内部的敏感信息（内部系统名、真实业务数据、客户名）提醒我在发布前替换或脱敏。
高亮处换成你自己的内容：[项目背景]、[核心问题]、[尝试过的方案]、[如接口耗时从 2 秒降到 200 毫秒]、[如有 1 到 3 年经验的后端开发]、[如公司技术公众号，3000 字左右]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[我尝试过的方案] 一定要包括失败的，读者最想看的往往是「为什么一开始的思路不行」。[最终效果与数据] 有具体数字的文章说服力强得多，没有就在追问环节补。
常见坑：
- 让 AI 直接写全文，结果是结构工整但没有信息量的「正确的废话」，读者一眼就能看出来。这条提示词刻意让 AI 只写示范章节，正文的细节由你补充。
- 开头写大背景、写行业趋势，读者三行之内就会关掉。直接从一个具体现象开始，例如「上线第三天，订单接口的 P99 耗时从 300 毫秒涨到了 4 秒」。
- 代码贴太多。只保留关键片段，完整代码放仓库链接。
追问技巧：初稿写完后，把全文贴回去，说「站在目标读者的角度，指出哪些地方看不懂、哪些地方可以删掉」。
示例输出
示例，仅供参考（标题候选节选）
- 《一次 MySQL 深分页优化：从 4 秒到 80 毫秒的排查过程》
- 《订单列表翻到第 1000 页为什么会卡死？聊聊延迟关联和游标分页》
- 《深分页优化踩坑记：加索引为什么没用》
一句话核心观点：深分页慢的根源是扫描并丢弃大量行，加索引解决不了，要改变分页方式。
开头示范：
上个月，运营同学反馈订单后台「翻到后面就打不开」。监控显示，offset 超过 10 万之后，这个接口的耗时稳定在 4 秒以上。我们的第一反应是加索引——结果加完之后几乎没有变化。（待补充：加索引前后的具体耗时）
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～